VercelのDockerfile対応とは｜HTTPアプリ・Sandbox・課金を分けて確認

先に、要点をまとめます。

• Vercelでは、プロジェクト直下に Dockerfile.vercel（または Containerfile.vercel）を置くと、そのコンテナイメージがVercel Functionsとして実行され、トラフィックが自動で転送されます。Vercel公式ドキュメントでは、この Container Images 機能は2026年9月23日時点で Beta（権限の有効化が必要） と案内されています。
• 「Docker対応」と一言で言っても文脈が2つあります。HTTPアプリをコンテナで公開する Container Images と、隔離環境でコードを実行する Vercel Sandbox は別物です。用途も制限も料金も同じではありません。
• コンテナにすれば既存環境がそのまま移るとは限りません。 ポート、ステートレス前提、5分でのスケールダウン、Secure ComputeとStatic IPsの非対応といった条件を先に確認してください。

この記事は2026年9月23日時点の公式情報をもとに整理しています。提供状況・制限は変わるため、採用の直前には公式ドキュメントで再確認してください。

VercelのDocker対応とは、具体的に何ができることか？

任意のHTTPサーバーをコンテナイメージとしてビルドし、Vercel Functionsとして実行・自動スケールできることです。

Vercelの Container Images ドキュメントによると、プロジェクトのルートに Dockerfile.vercel（または Containerfile.vercel）を置くと、Vercelがこれを自動検出し、すべてのトラフィックをそのコンテナイメージへ転送するリライトルールを追加します。ビルドされたイメージは Vercel Container Registry（VCR）へ保存されます。

デプロイはVercel CLIまたはGitリポジトリへのpushで行い、ローカルでは vercel dev でも動かせます（この場合は手元にdocker CLIとDockerデーモンが必要です）。

同ページでは、vercel.json の services を使って1つのVercelプロジェクト内に複数のアプリケーションを配置し、rewrites でパスごとに振り分ける構成も案内されています。たとえば /api/(.*) をバックエンドのコンテナへ、それ以外をフロントエンドへ回す、といった書き方です。フロントはNext.js、APIは既存のコンテナ、という同居のしかたはここに該当します。

提供状況には注意が必要です。 同ドキュメントの冒頭には Container Images (Beta) として権限が必要である旨が記載されています（2026年9月23日時点）。本番採用を前提に検討する場合は、自社のチームで機能が有効化できるか、Betaという位置づけが要件と合うかを先に確認してください。

Container Images と Vercel Sandbox は何が違うのか？

前者は自社アプリを公開する仕組み、後者は信頼できないコードを隔離して実行する仕組みです。

自社の状況に合わせて相談する検討の途中でも構いません。いま困っている業務と、決まっている条件・決まっていない条件をお聞かせください。無料で相談する →

同じ「Vercelでコンテナを動かす」という話に見えて、目的が違います。混同すると、制限と料金の見積もりを取り違えます。

	Container Images	Vercel Sandbox
目的	自社のHTTPアプリを公開・スケールさせる	信頼できないコード・AIエージェント生成コードを隔離実行する
実行の単位	Vercel Functionsとして実行される	Firecracker microVMとして起動する
典型的な用途	既存のGo・Rails等のAPIをNext.jsと同居させる	コードプレイグラウンド、エージェントの作業環境、一時的な検証
提供状況	Beta（2026年9月23日時点、権限の有効化が必要）	一般提供（公式ブログで案内済み）

Vercel Sandboxのドキュメントでは、Sandboxは分離されたLinuxのmicroVMで信頼できないコードやエージェント生成コードを実行するものと説明されており、Dockerのようなコンテナランタイムを含むシステム権限が必要なワークロードも動かせるとされています。業務システムを公開する用途とは前提が異なります。「VercelでDockerが動く」という情報を見たら、どちらの文脈かを必ず確認してください。

移行前に確認すべき制約は？

ポート、ステートレス前提、スケールダウンの挙動、ネットワーク機能の非対応の4点です。

公式ドキュメントから、2026年9月23日時点で確認できる制約を整理します。

• 待ち受けポート：コンテナはHTTPサーバーを開いてトラフィックを受け取る前提です。既定のポートは 80 で、プロジェクト設定の環境変数 PORT で変更できます。
• ステートレス前提：関数はステートレスで、各インスタンスはリクエストを処理した後に状態を破棄します。永続的なデータは、外部のデータベースやキャッシュなど別のサービスが必要です。
• スケールダウン：本番環境では5分間、プレビュー環境では30秒間トラフィックが無いと自動的にスケールダウンします。スケールダウン時、コンテナには SIGTERM が送られ、強制終了までの猶予は30秒です。
• ネットワーク機能の非対応：Secure Compute（プライベート接続）と Static IPs（固定送信元IP）は、カスタムコンテナイメージではまだサポートされていません。 社内DBへIP制限付きで接続する要件がある場合は、この点が判断の分かれ目になります。
• イメージのサイズ上限：Container Registryの制限では、圧縮済みレイヤー1つあたり2GB、イメージ合計15GB、マニフェスト本体4MB、イメージconfig blob 1MBが上限です。レイヤーはgzipまたはzstdで圧縮されている必要があり、非圧縮のOCIレイヤーはサポートされません。

制約を踏まえた確認表です。

項目	確認すること	判断例
入口	HTTPで受ける処理か。待受ポートは何番か	PORT で合わせられるなら対象になる
状態	ローカルファイルやプロセス内メモリに依存していないか	依存があれば外部ストレージ・DBへ切り出す
バックグラウンド	常駐処理、長時間ジョブ、定期実行があるか	5分で縮退するため別基盤を比較する
ネットワーク	固定送信元IP・閉域接続が必須か	必須なら現時点では別の基盤を検討する
終了処理	SIGTERM から30秒で片付けられるか	書き込み中断時の再実行設計を用意する
秘密情報	実行時の環境変数とビルドイメージへの混入	イメージに焼き込まない構成へ直す

つまり「どんなコンテナでも動く」のではなく、HTTPリクエストを受けて応答するステートレスなサーバーなら、フレームワークを問わず動くと理解するのが正確です。

料金はどう見積もるか？

Vercel Functionsと同じ課金モデルが適用され、「待機中は無料」ではありません。

公式ドキュメントでは、カスタムコンテナイメージにもVercel Functionsと同じ制限と Active CPU の課金モデルが適用されると説明されています。Fluid computeの料金説明によると、課金項目は Active CPU・Provisioned Memory・Invocations に分かれます。

• Active CPU：コードが実際に動いている時間だけ課金されます。データベース照会やAIモデル呼び出しなどのI/O待機中は課金が止まります。
• Provisioned Memory：割り当てたメモリに対して、インスタンスの生存期間全体にGB時間で課金されます。I/O待機中も課金は続き、最後の処理中のリクエストが完了するまで止まりません。
• Invocations：リクエストごとに数えられる別項目です。

Tokyo（hnd1）リージョンの単価は、Active CPUが1時間あたり0.202米ドル、Provisioned Memoryが1GB時間あたり0.0167米ドルです（税別）。加えて、Container Registryの料金ではイメージ保存が1GBあたり0.10米ドルと案内されています。

「待っている間はすべて無料」「常駐サーバーを無条件に置き換えられる」とは考えないでください。 正確には「待っている間はCPUぶんの課金が止まる」であり、メモリ・呼び出し・転送・イメージ保存は別に積み上がります。アクセスに波があるサービスではアイドル時の課金が無いぶん有利になりやすく、24時間フル稼働に近づくほど常時起動型の構成が相対的に安くなります。この損益分岐の考え方はVercelとAWSの費用比較で整理しています。

帳票PDFを生成するAPIで何を検証するか

起動して応答が返ることと、業務で使えることは別に検証します。

HTTP要求を受けてPDFを返すAPIを例に考えます。コンテナ化の判断で確認する項目は次のとおりです。

• 生成時間とメモリ：1件あたりの処理時間と最大メモリ。関数の実行時間の上限に収まるか。
• フォント：日本語フォントをイメージに含めているか。含めるとイメージサイズが増えます。
• 一時ファイル：生成途中のファイルをローカルに置いていないか。ステートレス前提なので、外部ストレージへの保存に切り替える必要があります。
• 二重発行：同じ要求が再送されたとき、帳票が二重に発行されないか。
• 中断後の再開：SIGTERM を受けた後に処理を再開・再実行できるか。処理中に縮退した場合の扱いを決めます。

コンテナが起動しただけでは業務の合格とはしません。これは説明のための例であり、当社案件の測定値ではありません。

どの構成を選ぶかをどう判断するか？

既存の実行基盤を維持する案と、公開・監視・復旧を含む運用工数で比べます。

判断の分かれ目は、フレームワークの制約ではなくネットワークと常駐処理の要件に移ります。

状況	先に確認すること	判断例
Next.jsだけを運用している	現状で困っていることがあるか	従来のデプロイのままでよい
特殊なライブラリが必要なHTTPアプリ	ステートレスにできるか	コンテナでの公開を検証対象に入れる
既存のGo・Rails等を同居させたい	固定IP・閉域接続の要否	要件がなければ同一プロジェクト内の構成を比較
常駐ワーカー・長時間バッチがある	5分の縮退と実行時間の上限	その処理だけ別基盤へ分ける
固定送信元IPが必須	接続先のIP制限の条件	現時点ではコンテナ以外の選択肢を検討

インフラの窓口が1つにまとまること自体には、保守・請求・段階的な刷新のしやすさという利点があります。既存システムをコンテナのまま載せ、画面から順にNext.jsで作り替える二段構えの進め方は、投資を分割したい場合に検討できます。構成全体の設計はNext.js・Supabase・Vercelで業務システムを作るで扱っています。

ただしBetaという提供状況を踏まえると、まず小さな検証環境で動かし、料金と安定性を自社の条件で確かめるのが現実的です。移行費と継続費を分け、公式の上限・提供条件は採用時に必ず再確認してください。

工数と費用を見積もる

コンテナ化そのものの工数と、ステートレス化・外部ストレージ対応の工数を分けて積み上げます。

既存アプリをそのままイメージに固めるだけで済むケースは多くありません。ローカルファイルへの依存を外す、セッションを外部へ移す、再送時の重複を防ぐ、といった修正が実際の工数になります。検証環境での動作確認、性能・復旧テスト、切替も含めて見積もってください。

当社の作業単価は 1時間11,000円（税込） です。要件定義・契約後のすり合わせ・開発・テスト・バッファの時間を積み上げて見積もります。バッファは未確定事項ごとに理由を示し、クラウド・API等の実費と保守契約は別に確認します。初回相談・認識合わせの無料モック・お見積もりは無料です。見積もりの進め方と相談シートで整理できます。

動く試作や社内ツールを実業務に載せる段階でつまずいている場合は、PoCから本番移行・本番化の支援で、セキュリティ・運用・保守の観点から点検・補強を行っています。老朽化した既存システムを止めずに作り変える段階なら、システムリプレース・移行もあわせてご覧ください。

よくある質問

Q. Dockerならどんなアプリでもそのまま動きますか？

動きません。前提は「HTTPで待ち受けるステートレスなサーバー」です。本番では5分間、プレビューでは30秒間トラフィックが無いとインスタンスが縮退するため、コンテナ内にデータやセッションを保持する設計は避ける必要があります。またSecure ComputeとStatic IPsはカスタムコンテナイメージでは未対応です（2026年9月23日時点）。常駐処理や固定IPが必要な要件は、別の基盤が引き続き選択肢になります。

Q. 待機中は課金されませんか？

CPUの扱いとメモリなどの課金は別です。Active CPUはI/O待機中に課金が止まりますが、Provisioned Memoryはインスタンスの生存期間中ずっと課金され、呼び出し回数とイメージ保存も別項目です。待機中の全費用がゼロという意味ではありません。

Q. 既存のNext.jsのデプロイ方法は使えなくなりますか？

使えます。Dockerfile.vercel は既存のデプロイ方法を置き換えるものではなく、サーバーレスでは対応しづらかったワークロードへの選択肢の追加です。純粋なNext.jsアプリだけを運用している場合、何かを変更する必要はありません。

自社の状況を整理して相談する

まず、HTTP処理、保存先、長時間ジョブ、CPU・メモリ・転送を書き出してください。この記事に合う検討シートとAI相談用プロンプトで、未確認の項目を残したまま整理できます。シートを完成させる前でも、お気軽にご相談いただけます。