Dockerfileの6つの代替手段（そもそも不要な場合も）【2026年版】

Dockerfileの6つの代替手段（そもそも不要な場合も）【2026年版】

Dockerfileを書くのが面倒な作業に感じてこの記事を開いたなら、朗報です。2026年現在、ほとんどのアプリにDockerfileは不要です。Railwayでは、デフォルトのビルドツールは手書きのnode:20-slimイメージではなく、Railpackになりました。RailpackやCloud Native Buildpacksのようなツールは、コードを読み取り、言語を検出し、コンテナイメージを自動生成してくれます。つまり、本当の問いは「Dockerfile怎么写くの？」ではなく、「これらのDockerfile代替手段のうち、どれが自分のアプリに合うのか？」です。それを整理していきましょう。

手っ取り早い答え：

• ほとんどの場合、Dockerfileを手書きする必要はありません。ゼロコンフィグビルダーがコードを検出し、イメージをビルドしてくれます。
• RailwayではRailpackが現在のデフォルトです（Nixpacksはメンテナンスモード）。Heroku FirとPaketoはCloud Native Buildpacksを使用しています。
• 静的サイト（Astro、Next export、プレーンHTML）は、コンテナビルド自体が不要なことが多いです。

そもそもDockerfileは必要か？

いいえ、通常はDockerfileを書く必要はありません。Railway、Render、Herokuのようなプラットフォームにデプロイする場合、ゼロコンフィグビルダー（Railpack、Nixpacks、Cloud Native Buildpacks）が言語を検出し、イメージをビルドしてくれます。Dockerfileを書くのは、きめ細かな制御が必要なときだけにしましょう。

これが、多くのガイドが見落としている視点の転換です。Dockerfileとは、FROM、COPY、RUNといった命令が並ぶテキストファイルで、Dockerにイメージの組み立て方をレイヤーごとに指示するものです。強力ですが、すべての行を自分で書き、メンテナンスしなければなりません。ゼロコンフィグビルダーはその逆を行きます。package.jsonやrequirements.txtを調べ、適切なベースイメージとコマンドを推測し、あなたが何も書かなくてもビルドしてくれます。

つまり、Buildpacks vs Dockerfileの選択は、多くの場合「制御 vs 手軽さ」に帰着します。Google Cloud自身のコンテナ化手法の比較も同じ結論に達しています。スピードと一貫性ならBuildpacks、ルールを曲げたいならDockerfile、という棲み分けです。

それでも本物のDockerfileが必要になるのは、カスタムベースイメージ、特定のシステムパッケージ（ffmpegやマイナーなCライブラリなど）、あるいはメガバイト単位を削る精密なマルチステージ制御が必要な場合です。それ以外は？ビルダーがほぼ対応できます。Modalのようなプラットフォームはさらに先を行き、Modalはコードから直接イメージをビルドし、Dockerfileは一切不要です。

Dockerfileは、もはやコンテナをビルドするデフォルトの方法ではありません。ゼロコンフィグでは足りないときの逃げ道です。

6つのDockerfile代替手段一览

すべての手法を並べて比較したので、じっくり読む前にざっと確認してください。（そう、「Dockerfileを書く」もリストに入っています。今でも選択肢の一つですが、唯一の選択肢ではない、ということです。）

では、6つを詳しく見ていきます。それぞれ「これは何か」と「こんな人向け」をわかりやすく説明します。

1. Dockerfile（完全マニュアル制御）

Dockerfileは、すべての命令を自分で書く、元祖にして基本の手法です。「このベースイメージから始めて、これらのファイルをコピーし、これらのコマンドを実行し、このポートを公開する」というスクリプトです。何も自動検出されませんが、それがまさに目的です。

すべてのレイヤーを制御できるため、最適化したDockerfileはここで紹介するどの手法よりも小さいイメージを生成できます。マルチステージビルド（太ったビルダーステージでコンパイルし、出力だけを小さな最終ステージにコピーする）を使えば、Nodeイメージを120MB付近まで絞り込めます。レイヤーキャッシュにより、初回ビルド以降の再ビルドも高速です。

代償はメンテナンスです。ベースイメージの更新、セキュリティパッチ、あらゆる癖の対応を自分で担います。5行のExpressアプリには過剰です。特定のOSパッケージや固定バージョンのコンパイラが必要なアプリには、唯一の正直な選択肢です。

こんな人向け： カスタムベースイメージ、特定のシステム依存関係、または最終イメージサイズに対する精密なマルチステージ制御が必要な場合。

2. Railpack：Railwayのゼロコンフィグデフォルト

RailpackはRailwayのオープンソース（MIT）ビルドツールで、Railwayのドキュメントによれば、現在デフォルトです。「Railway uses Railpack to build and deploy your code with zero configuration.」と明記されています。BuildKit（Dockerのモダンなビルドエンジン）上に構築され、Miseを使って言語バージョンを固定します。Railwayは2025年3月にNixpacksの後継として発表し、Railpackのリポジトリでは2026年を通じた活発なリリースが確認できます。ベータのサイドプロジェクトではありません。

なぜ重要かというと、Railwayによれば、RailpackはBuildKitのレイヤー分割の改善により、Nixpacksと比べてNodeで約38%小さく、Pythonで約77%小さいベースイメージを生成します。その数字の背景にある深い理由はNixpacks vs Dockerの徹底比較で解説しているので、内部の仕組みはそちらに任せ、ここではまとめ記事として簡潔に保ちます。

小さいイメージは単にきれいというだけではありません。プルが速く、コールドスタートが速く、保存と転送のコストも下がります。これはクラウドコストを抑えるうえで重要です。完全にゼロコンフィグのまま使うことも、必要に応じてrailpack.jsonを置いてバージョンやコマンドをオーバーライドすることもできます。

railpack build

こんな人向け： Railwayにデプロイしている場合、またはBuildKitキャッシュを備えた最小のゼロコンフィグイメージが欲しい場合。

3. Nixpacks：旧世代のゼロコンフィグビルダー

NixpacksはRailwayの以前のデフォルトで、幅広い言語の自動検出（Node、Python、Go、PHPなど）を備えた、今なお有能なゼロコンフィグビルダーです。Railpackがまだ検出しないニッチなスタックを使っている場合、Nixpacksなら認識してくれるかもしれません。

正直な注意点として、メンテナンスモードに入っています。NixpacksリポジトリのREADMEには今やそう明記されており、代替としてRailpackを推奨しています。死んではいません。今も動きますし、ビルドもできます。ただ、新機能は入らないということです。また、Nixpacksのイメージは大きくなりがちで、これはNixストアを最終イメージにレイヤーとして積み重ねる仕組みに起因します。これは既知のトレードオフで、全容はNixpacks vs Dockerの詳細比較で解説しており、ここでは繰り返しません。

つまり、Nixpacksは「まだサポートされているが、後継はこちら」という位置づけのオプションとして扱ってください。Railwayの新しいプロジェクトは自動的にRailpackになります。Nixpacksに手を伸ばすのは、主にレガシーな構成の場合です。

こんな人向け： レガシーなRailway構成を使っている場合、またはRailpackがまだ自動検出しない言語が必要な場合。

4. Heroku & Cloud Native Buildpacks

Herokuの新しいFir世代は、**Cloud Native Buildpacks（CNB）**でアプリをビルドします。これはソースコードをDockerfileなしでOCIコンテナイメージに変換するためのオープンスタンダードです。Heroku Dev Centerによれば、Firはheroku/builder:24ビルダーを使用します。クラシックBuildpacksはFirでサポートされていないため、Cedarアプリはその場で移行するのではなく、Firに再デプロイする形になります。

良い点は、CNBがHerokuのサーバーだけでなく、どこでも動くことです。buildpacks.ioのpack CLIを使えば、Herokuがクラウドでビルドするのと同じイメージをローカルで正確にビルドできます。Buildpacksは強力なキャッシュを持ち、組み合わせ可能なので、ベースレイヤーへのセキュリティパッチが個々のリポジトリに触れることなく、すべてのアプリにロールアウトできます。

pack build myapp --builder heroku/builder:24

この再現性こそが、チームにとっての本当の魅力です。リポジトリごとにDockerfileを同期させる必要もなく、開発者間のドリフトもありません。

こんな人向け： Heroku Firを使っている場合、またはプロジェクトごとにDockerfileをメンテナンスせずに、組織全体で標準化された再現可能なビルドが欲しい場合。

5. Paketo Buildpacks

Paketo Buildpacksはもう一つのCloud Native Buildpacks実装で、CNCF Incubatingプロジェクトです（CNCF Buildpacksページによる）。CNBの仕様に準拠しているため、同じPaketoビルドがBuildpacksをサポートする任意のプラットフォームで実行できます。Cloud Foundry、Kubernetes、Tektonパイプライン、あるいはpack経由であなたのノートPCでも。

Paketoは、HerokuのBuildpacksのプラットフォーム非依存版のいとこのようなものです。「言語を検出し、イメージをビルドし、Dockerfile不要」という同じ体験が得られますが、特定のホストに縛られません。この移植性こそ、KubernetesやCI/CD環境で多くのサービスにわたって一貫したビルドを求めるチームに採用される理由です。

HerokuのCNBより制御のスケールで一段上に位置し、Buildpacksを混ぜて使ったり、ビルダーを調整したりできます。

こんな人向け： Cloud Native Buildpacksを使いたいがHerokuにはいない場合。たとえばKubernetes、Tekton、またはプラットフォーム非依存のビルドパイプラインで。

6. 静的（ビルド自体なし）

最良のDockerfile代替手段は、何もビルドしないこと、という場合があります。アプリが静的ファイルにコンパイルされる場合（Astroのような静的サイトジェネレーター、Next.jsの静的エクスポート、あるいはプレーンなHTML、CSS、JS）、コンテナイメージがまったく不要なことが多いです。

Netlify、Cloudflare Pages、GitHub Pages、Vercelの静的ティアのような静的ホストは、ビルド済みファイルを受け取り、CDNからそのまま配信します。サーバーランタイムもなく、公開するポートもなく、出荷するイメージもありません。プッシュすれば、デプロイされます。最速かつ最安の道であり、コンテナを完全に迂回するため、ほとんどの「Docker代替」リストには載りません。

落とし穴は明白です。サーバーサイドのランタイムがない場合にしか使えません。API、データベース接続、あるいはリクエストごとのサーバーレンダリングが必要になった瞬間、上記のビルダーオプションのいずれかに戻ることになります。

アプリが静的ファイルにコンパイルされるなら、最速のコンテナビルドとは、完全にスキップするビルドです。

こんな人向け： 出力が純粋に静的ファイルで、実行するサーバーランタイムがない場合。

どう選ぶ？シンプルな判断ツリー

選択は、出力、制御の必要性、プラットフォームに関する4つの簡単な質問に帰着します。静的出力ならコンテナをスキップ。細かい制御が必要ならDockerfile。それ以外はプラットフォームがビルダーを決めます。以下の分岐をたどってください。

• 静的サイトやSSGの出力（HTML、Astro、Next export）を出荷する？ → 静的ホスティング。コンテナビルド不要。
• きめ細かな制御が必要（カスタムベースイメージ、システム依存、マルチステージ）？ → Dockerfile。
• Railwayを使っている？ → Railpack（デフォルト。Nixpacksはレガシープロジェクトのみ）。
• Heroku Firを使っている？ → heroku/builder:24経由のHeroku CNB Buildpacks。
• それ以外、Kubernetes上、またはポータブルなCNBが欲しい？ → Paketo Buildpacks（またはpack CLI）。

まだプラットフォームすら決めていない？その決定がデフォルトでどのビルダーを継承するかを形作るので、そこから始めましょう。Railway vs Render vs Fly.ioの比較記事で、ビルド手法を考える前の「どこにデプロイするか」という問いを整理しています。

私たちの見解：実際に何を使うか

同じ小さなExpressの「hello world」を3通りの方法でビルドし、それぞれを計測しました。アプリは毎回同一です。index.jsが1つ、依存関係が1つ（Express）、トリックなし。Apple Silicon MacでDocker 29.4、Nixpacks 1.41、Railpack 0.23を使い、キャッシュなしで毎回ゼロからイメージをビルドしました。結果は以下の通りです。

いくつか正直な注記を。手書きのDockerfileは予想通りサイズで勝ちましたが、そこに至るためにマルチステージビルドを書いて調整しています。Railpackのイメージは、まったく同じアプリでゼロコンフィグのまま、Nixpacksより約40%小さく（416 MB vs 689 MB）なりました。これこそRailwayがデフォルトを切り替えた理由そのものです。Nixpacksは圧倒的に最も重く、その理由はNixpacks vs Dockerの詳細解説で確認できます。ビルド時間はあくまで目安として扱ってください。単発の実行であり、キャッシュやネットワークで変動するため、ここで実際に信頼している数字はイメージサイズです。

では、実際に何を使うか？ほとんどのPaaSデプロイでは、Railpackです。ゼロコンフィグで、テストした中で最小のゼロコンフィグイメージであり、そもそもRailwayのデフォルトです。Dockerfileを書くのは、カスタムベースイメージやビルダーが追加してくれないシステム依存関係が本当に必要なときだけです。静的出力の場合は、コンテナを完全にスキップします。

Techsyでは、クライアントアプリのためにこうしたビルド＆デプロイの判断を毎週下しており、イメージを小さく保ち、出荷を速くするデプロイプラットフォームとビルド手法を選んでいます。どのパスが自分のスタックに合うか迷っているなら、無料相談でお話ししましょう。

著者について

Mert Batur GurbuzはTechsy.ioの共同創業者で、チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを出荷しています。University of Birminghamで学びつつ、Techsyチームが実際に本番環境で使っているLLMツールスタックについて執筆しています。LinkedInでつながってください。

Mert Batur Gurbuz、共同創業者、Techsy.io、University of Birmingham

よくある質問

Dockerfileは必要か？

通常は不要です。Railway、Render、Herokuにデプロイする場合、Railpack、Nixpacks、Cloud Native Buildpacksのようなゼロコンフィグビルダーが言語を検出し、コンテナイメージをビルドしてくれます。Dockerfileを書くのは、カスタムベースイメージ、特定のシステムパッケージ、または最終イメージに対するきめ細かなマルチステージ制御が必要なときだけです。

BuildpacksとDockerfileの違いは？

Dockerfileは、すべてのビルド命令を自分で書く手動のスクリプトです。Buildpacksは言語とフレームワークを自動検出し、1つのコマンド（pack build）でDockerfileなしにイメージをビルドします。Buildpacksは制御とイメージサイズをある程度犠牲にして、一貫性とメンテナンスゼロを得るもので、これがBuildpacks vs Dockerfileの核心的な選択です。

RailpackはNixpacksより優れているか？

ほとんどの新しいRailwayアプリでは、はい。RailpackはRailwayの現在のデフォルトで、BuildKit上に構築され、明らかに小さいイメージを生成します（RailwayはNodeで約38%小さいと記載）。Nixpacksは今も動作し、幅広い言語を検出しますが、メンテナンスモードに入っているため、推奨される道はRailpackです。

Nixpacksは死んだのか？

いいえ。Nixpacksはメンテナンスモードであり、放棄されてはいません。GitHubのREADME自体が、活発な開発下にはなく、代替としてRailpackを推奨すると明記しています。既存のアプリは今も問題なくビルドでき、言語検出も幅広いですが、新機能は来ないため、Railwayは新しいプロジェクトのデフォルトをRailpackにしています。

ビルドステップなしでデプロイできるか？

はい、アプリが静的であれば可能です。静的サイトジェネレーター（Astro、Next静的エクスポート）やプレーンHTMLの出力は、Netlify、Cloudflare Pages、GitHub Pagesのような静的ホストにコンテナビルドなしでそのままデプロイできます。これはサーバーランタイムがない場合にのみ機能します。APIやサーバーレンダリングページが必要になった瞬間、ビルダーが必要になります。

pack CLIとは？

pack CLIは、buildpacks.ioが提供する公式のコマンドラインツールで、Cloud Native Buildpacksを使ってローカルでイメージをビルドするためのものです。pack build myapp --builder heroku/builder:24を実行すると、Herokuのようなプラットフォームがクラウドでビルドするのと同じOCIイメージが生成され、ローカルテストと再現可能なビルドが容易になります。

BuildpacksはDockerfileより遅いのか？

多くの場合、初回のコールドビルドではやや遅くなります。Buildpacksがレイヤーを自動で検出・組み立てるためです。ただし、Buildpacksごとのレイヤーキャッシュにより再ビルドは高速で、キャッシュが効いたBuildpacksビルドは最適化したDockerfileに匹敵できます。ほとんどの日常的なアプリにとって、より大きなトレードオフはイメージサイズと制御であり、生の速度ではありません。

Podmanはどうなのか、Dockerfileの代替か？

厳密には違います。PodmanはDockerエンジン（コンテナのビルドと実行を行うランタイム）を置き換えるものであり、Dockerfile自体の代替ではありません。同じDockerfile構文を読み取ります。Dockerfileを書くことから解放されたいなら、RailpackやBuildpacksのようなゼロコンフィグビルダーが求めているものです。PodmanはDockerというランタイムの代替であり、まったく別の問いです。

どのDockerfile代替手段が最小のイメージを作るか？

手で最適化したマルチステージDockerfileが、すべての手法の中で最小のイメージを生成できます（私たちのテストでは255 MB）。ゼロコンフィグビルダーの中では、Railpackが勝ちです（Nodeアプリで416 MB、同じアプリでNixpacksは689 MB）。静的ホスティングはイメージ自体が不要なので、出力が静的なら、それが圧倒的に最小のフットプリントです。