「Next.jsのアプリはVercelにデプロイする」——これは今や、フルスクラッチでのシステム開発における定番の選択肢のひとつです。そのVercelが2026年6月、開発の前提を広げる発表をしました。
2026年6月30日、Vercelは「Dockerfile.vercel」を発表しました（Vercel公式ブログ）。プロジェクトにDockerfile.vercelというファイルを1つ置くだけで、Vercelが自動でビルド・デプロイ・オートスケールしてくれる機能です。これに先立つ2026年5月29日には、開発中のプレビュー環境（Vercel Sandbox）でDockerコンテナを実行できるようにする発表もありました（Vercel Changelog）。
先に、この記事の要点をまとめます。
Dockerfile.vercelを置くだけで、Go・Rails・Spring Boot等の任意のHTTPサーバーをVercel上で自動ビルド・デプロイ・オートスケールできる（2026年7月時点、公式ドキュメント上は通常機能として提供）- 料金は実際にCPUを使った時間だけ課金される方式（Fluid compute／Active CPU）。アイドル時間は課金されない
- 既存のNext.jsデプロイの置き換えではなく選択肢の追加。ただし「ステートレスなHTTPサーバー」が前提で、常駐処理や固定IPが必要な要件には向かない
本記事では、Vercelのコンテナ対応が何を意味するのか、これまでのNext.js開発と何が変わるのか、そして「従来のVercel Functions・コンテナ・AWS移行」をどう使い分けるかを、2026年7月時点の情報で整理します。
これまでのVercelは何が制約だったのか？
Vercelはフレームワークを自動検知してデプロイする「サーバーレス」中心の設計で、特定のシステムライブラリが必要なアプリや、自動認識できないフレームワークは別のインフラを用意する必要がありました。
Vercelはこれまで、Next.jsをはじめとするフレームワークのコードを検知して自動でビルド・デプロイする「サーバーレス」中心のプラットフォームでした。開発者はインフラの構成をほとんど意識せず、コードをプッシュするだけで本番環境が立ち上がる手軽さが強みです。
一方でこの手軽さには制約もありました。特定のシステムライブラリ（動画処理のFFmpeg、ブラウザ操作のChromiumなど）が必要なアプリや、Vercelが自動認識できないフレームワーク（Go、Ruby on Rails、Spring Bootなど）で作られた既存システムは、これまで別のホスティング環境を用意する必要がありました。
Dockerfile.vercelで何が変わるのか？
プロジェクトにDockerfile.vercelを1枚追加するだけで、Next.js以外の任意のHTTPサーバーをVercel上で自動ビルド・デプロイ・オートスケールできるようになります。
Dockerfile.vercelは、前述の制約を取り払うものです。ビルドされたコンテナイメージはプロジェクトのレジストリに保存され、Vercel Functionsと同じ実行基盤（Fluid compute）の上で動作します。Go・Ruby on Rails・Spring Boot・Expressなど、フレームワークを問わずHTTPサーバーであればデプロイでき、トラフィックに応じて自動でスケールアウトし、止まればゼロまで縮退します。
料金体系も従来のコンテナホスティングと異なり、CPUを実際に使った時間だけ課金される「Active CPU」方式が採用されています。アイドル状態（処理をしていない待機時間）は課金対象にならないため、常時起動が前提の一般的なコンテナホスティングと比べて、利用状況によってはコストを抑えられる可能性があります。
想定されている主な用途は次のとおりです。
- FFmpeg・Chromiumなど、特定のシステムライブラリが必要なアプリ
- Vercelが自動認識できないフレームワークで作られたアプリ
- 社内で運用してきた既存システムを、そのままの構成でデプロイしたい場合
2026年7月時点の提供状況と、導入前に確認すべき制約は？
公式ドキュメント上は通常機能として案内されています。ただし「$PORTでHTTPを待ち受けるステートレスなサーバー」が前提で、常駐処理・プライベート接続・固定送信元IPには対応していません。
発表から約1週間が経過した2026年7月2日時点で、VercelのナレッジベースではDocker（OCI互換）イメージのデプロイが通常機能として案内されています。一方で、導入前に押さえておくべき前提・制約がいくつかあります。
- コンテナは環境変数
$PORT（デフォルト80番）でHTTPリクエストを待ち受ける必要がある - コンテナはVercel Functionsとして実行されるため、ステートレスが前提。トラフィックが約5分間途絶えるとインスタンスは自動で縮退するため、コンテナ内にデータやセッションを保持する設計は避ける必要がある
- Secure Compute（プライベート接続）とStatic IPs（固定送信元IP）は非対応（2026年7月時点の公式ドキュメント）。「社内DBにIP制限付きで接続する」ような要件がある場合は注意が必要
- 常時起動が前提のワークロード（常駐バッチ、長時間の接続を保ち続ける処理など）には向かない可能性が高い
つまり「どんなコンテナでも動く」のではなく、「HTTPリクエストを受けて応答するステートレスなサーバーなら、フレームワークを問わず動く」と理解するのが正確です。
既存のNext.jsデプロイはどうなるのか？
従来どおりのデプロイ方法はそのまま使えます。Dockerfile.vercelは置き換えではなく、対応しづらかったワークロードへの「選択肢の追加」です。
重要なのは、これはNext.jsのサーバーレスデプロイに取って代わるものではなく、選択肢が追加されたという点です。従来どおりNext.jsアプリはこれまでの方法でデプロイでき、Dockerfile.vercelは「サーバーレスでは対応しづらかったワークロード」への拡張として位置づけられています。純粋なNext.jsアプリだけを運用している場合、何かを変更する必要はありません。
従来のFunctions・コンテナ・AWS移行、どう選ぶ？
通常のNext.jsアプリは従来どおり、特殊ライブラリや既存システムの同居はコンテナ、常駐処理・固定IP・複雑なネットワーク要件が出てきたらAWS等への移行——が基本の整理です。
インフラの選択肢が3つになったことで、かえって迷いやすくなりました。移行判断の観点を表に整理します。
| 従来のVercel Functions（サーバーレス） | Vercelコンテナ（Dockerfile.vercel） | AWS等への移行（ECS/Fargate等） | |
|---|---|---|---|
| 向くワークロード | Next.js等の対応フレームワーク | 特殊ライブラリ依存・非対応フレームワークのHTTPサーバー | 常駐処理・複雑なネットワーク要件 |
| 構築の手間 | 最小（プッシュするだけ） | 小（Dockerfile 1枚） | 大（インフラ設計と構築が必要） |
| 運用の手間 | 最小 | 小（Vercelに集約） | 中〜大（監視・更新体制が必要） |
| 課金の考え方 | 実行時間ベース | Active CPU（実際に使ったCPU時間のみ） | 常時起動分も課金（インスタンス単位） |
| スケール | 自動 | 自動（ゼロまで縮退） | 設計・設定しだい |
| 主な制約 | ランタイム・ライブラリの制約 | ステートレス前提・固定IP不可 | 制約は少ないがすべて自前 |
※2026年7月時点の各社公開情報に基づく整理です。
判断の分かれ目は「アクセスの波」と「コスト構造」です。アクセスが波打つサービスはアイドル課金のないVercel側が有利になりやすく、24時間フル稼働に近づくほど常時起動型が相対的に安くなります。この損益分岐の考え方はVercelとAWSのスケーリングとコスト比較で詳しく解説しているので、あわせてご覧ください。
言い換えると、Dockerfile.vercelの登場で「Vercelでは無理だからAWSへ」と判断すべき境界線が、「フレームワークの制約」から「常駐・固定IP・ネットワーク要件の有無」へ移動したということです。以前ならAWS移行しかなかったケースの一部が、Vercel内で完結できるようになりました。
中小企業のシステム開発にとっての意味は？
「フロントは新しいNext.js、裏側は既存のGo・Railsシステム」という構成を1つのVercelプロジェクトに集約でき、インフラの窓口を一本化できる可能性が広がります。
私たちは「Next.js フルスクラッチ × AI駆動開発」を軸に受託開発を行っていますが、実際の現場では、Next.js単体では完結しない要件に出会うことも少なくありません。動画・画像処理を伴う業務システム、既存の社内システム（Go・Railsなどで組まれたもの）とNext.js製の新しいフロントエンドを同居させたいケース、フレームワークの制約でこれまで別途インフラを立てる必要があったケースなどです。
Dockerfile.vercelの構成図：利用者からのアクセスをNext.jsフロントエンドが受け、同じVercel内のコンテナ（既存のGo/Rails等のAPIサーバー）を呼び出し、外部のマネージドDBに接続する。監視・請求・デプロイの窓口がVercelひとつにまとまる
Dockerfile.vercelは、こうしたケースをNext.jsアプリと同じVercel環境内で完結させられる可能性を広げるものです。インフラを分散させないことのメリットは、中小企業にとって具体的です。
- 保守の窓口が1つになる: デプロイ手順・監視・障害対応がVercelに集約され、属人化しにくくなる
- 請求が1つにまとまる: 複数クラウドの請求を突き合わせる手間がなくなり、コスト管理が単純になる
- 段階的な刷新がしやすくなる: 既存システムをコンテナのままVercelに載せ、フロントだけNext.jsで刷新する「二段構え」の移行が組みやすい
とくに3点目は、老朽化した業務システムの刷新を検討している企業に効きます。全面刷新は費用もリスクも大きいですが、「まず既存APIをそのまま同居させ、画面から順に作り替える」進め方なら、投資を分割できます。システム刷新そのものの考え方はオーダーメイドシステムが法人価値を底上げする5つの理由で、Vercelを使った業務システムの技術構成はNext.js × Supabase × Vercel で作る業務システムで解説しています。
ただし発表されたばかりの機能であり、実際の料金感・安定性・既存システムとの相性は、案件ごとに見極める必要があります。まずは小さな検証環境で動かして確認するのが現実的です。
まとめ
- Vercelは2026年6月30日、Dockerコンテナを自動ビルド・デプロイ・オートスケールする「Dockerfile.vercel」を発表（先行して5月29日にはプレビュー環境でのDocker実行にも対応）。2026年7月時点で通常機能として案内されている
- Go・Ruby on Rails・Spring Boot・Expressなど、Next.js以外の任意のHTTPサーバーもVercel上で動かせるようになった
- 料金はCPUの実行時間に応じた課金方式で、アイドル時間は課金されない
- ただし
$PORTでのHTTP待ち受け・ステートレスが前提で、Secure Compute・固定送信元IPは非対応。常駐処理や固定IP要件がある場合はAWS等が引き続き選択肢 - 業務システムの刷新や、既存システムとNext.js製フロントエンドの共存を検討している中小企業にとっては、インフラを一本化しながら段階的に刷新できる新しい選択肢
ゼットリンカーでは、Next.jsを軸としたフルスクラッチ開発から、既存システムとの共存を前提としたインフラ構成のご相談まで、貴社の状況に合わせてお手伝いしています。「今の仕組みを活かしながら刷新したい」という段階からでも、お気軽にご相談ください。
※本記事に記載した機能・料金体系は、2026年7月時点の公開情報（Vercel公式発表・公式ドキュメント）に基づく整理です。技術トレンドは変化が速いため、導入の判断にあたっては必ず公式情報で最新の内容をご確認ください。
FAQ
Q. Dockerfile.vercelを使うと、これまでのNext.jsのデプロイ方法は使えなくなりますか？
A. いいえ、従来どおりNext.jsアプリはこれまでの方法でデプロイできます。Dockerfile.vercelは、サーバーレスでは対応しづらかったワークロード（特定のシステムライブラリが必要なアプリや、Vercelが自動認識できないフレームワークなど）への選択肢が新たに追加されたものです。
Q. どんな会社にとって関係のある発表ですか？
A. 動画・画像処理などでシステムライブラリが必要なアプリを運用している企業や、Go・Ruby on Rails・Spring Bootなど既存のシステムをNext.js製の新しいフロントエンドと同居させたい企業にとって、インフラを一本化できる可能性がある選択肢です。純粋なNext.jsアプリのみを運用している場合は、これまでどおりのデプロイ方法で問題ありません。
Q. 料金はどうなりますか？
A. CPUを実際に使った時間に応じて課金される方式（Active CPU）で、アイドル状態（待機時間）は課金対象になりません。常時起動が前提の一般的なコンテナホスティングと比べ、アクセスに波があるサービスではコストを抑えられる可能性がありますが、24時間フル稼働に近いワークロードでは常時起動型が有利な場合もあり、実際の料金感は案件ごとに見極める必要があります。
Q. どんなコンテナでも動きますか？制約はありますか？
A. 「$PORT（デフォルト80番）でHTTPを待ち受けるステートレスなサーバー」が前提です。トラフィックが約5分間途絶えるとインスタンスは自動で縮退するため、コンテナ内にデータを保持する設計は避ける必要があります。またSecure Compute（プライベート接続）や固定送信元IPには非対応です（2026年7月時点）。常駐処理や固定IPが必要な要件は、AWS等のコンテナ基盤が引き続き選択肢になります。
運営・編集