「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）。
本記事では、Vercelのコンテナ対応が何を意味するのか、これまでのNext.js開発と何が変わるのか、中小企業のシステム開発にどう関係するのかを整理します。
これまでのVercelは「サーバーレス」が前提だった
Vercelはこれまで、Next.jsをはじめとするフレームワークのコードを検知して自動でビルド・デプロイする「サーバーレス」中心のプラットフォームでした。開発者はインフラの構成をほとんど意識せず、コードをプッシュするだけで本番環境が立ち上がる手軽さが強みです。
一方でこの手軽さには制約もありました。特定のシステムライブラリ（動画処理のFFmpeg、ブラウザ操作のChromiumなど）が必要なアプリや、Vercelが自動認識できないフレームワーク（Go、Ruby on Rails、Spring Bootなど）で作られた既存システムは、これまで別のホスティング環境を用意する必要がありました。
Dockerfile.vercelで何が変わるのか
Dockerfile.vercelは、この制約を取り払うものです。プロジェクトにDockerfile.vercelを追加するだけで、Next.js以外の任意のHTTPサーバー（Go・Ruby on Rails・Spring Boot・Expressなど）を、Vercel上で自動ビルド・デプロイ・オートスケールできるようになります。
料金体系も従来と異なり、CPUを実際に使った時間だけ課金される「Fluid compute」方式が採用されています。アイドル状態（処理をしていない待機時間）は課金対象にならないため、常時起動が前提の一般的なコンテナホスティングと比べて、利用状況によってはコストを抑えられる可能性があります。
想定されている主な用途は次のとおりです。
- FFmpeg・Chromiumなど、特定のシステムライブラリが必要なアプリ
- Vercelが自動認識できないフレームワークで作られたアプリ
- 社内で運用してきた既存システムを、そのままの構成でデプロイしたい場合
既存のNext.jsデプロイはどうなるのか
重要なのは、これはNext.jsのサーバーレスデプロイに取って代わるものではなく、選択肢が追加されたという点です。従来どおりNext.jsアプリはこれまでの方法でデプロイでき、Dockerfile.vercelは「サーバーレスでは対応しづらかったワークロード」への拡張として位置づけられています。
中小企業のシステム開発にとっての意味
私たちは「Next.js フルスクラッチ × AI駆動開発」を軸に受託開発を行っていますが、実際の現場では、Next.js単体では完結しない要件に出会うことも少なくありません。動画・画像処理を伴う業務システム、既存の社内システム（Go・Railsなどで組まれたもの）とNext.js製の新しいフロントエンドを同居させたいケース、フレームワークの制約でこれまで別途インフラを立てる必要があったケースなどです。
Dockerfile.vercelは、こうしたケースをNext.jsアプリと同じVercel環境内で完結させられる可能性を広げるものです。インフラを分散させず、開発・運用の窓口を一本化できれば、中小企業にとっては保守のしやすさやコスト管理のわかりやすさにつながります。ただし発表されたばかりの機能であり、実際の料金・安定性・既存システムとの相性は、案件ごとに見極める必要があります。
システム刷新の進め方については老朽化した業務システムをNext.jsで作り直す価値もあわせてご覧ください。
まとめ
- Vercelは2026年6月30日、Dockerコンテナを自動ビルド・デプロイ・オートスケールする「Dockerfile.vercel」を発表（先行して5月29日にはプレビュー環境でのDocker実行にも対応）
- Go・Ruby on Rails・Spring Boot・Expressなど、Next.js以外の任意のHTTPサーバーもVercel上で動かせるようになった
- 料金はCPUの実行時間に応じた課金方式で、アイドル時間は課金されない
- 既存のNext.jsサーバーレスデプロイに取って代わるものではなく、これまで別インフラが必要だったワークロードへの選択肢が追加された、という位置づけ
- 業務システムの刷新や、既存システムとNext.js製フロントエンドの共存を検討している中小企業にとっては、インフラを一本化できる可能性がある新しい選択肢
ゼットリンカーでは、Next.jsを軸としたフルスクラッチ開発から、既存システムとの共存を前提としたインフラ構成のご相談まで、貴社の状況に合わせてお手伝いしています。「今の仕組みを活かしながら刷新したい」という段階からでも、お気軽にご相談ください。
※本記事に記載した機能・料金体系は、2026年6月時点の公開情報（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を実際に使った時間に応じて課金される「Fluid compute」方式で、アイドル状態（待機時間）は課金対象になりません。常時起動が前提の一般的なコンテナホスティングと比べ、利用状況によってはコストを抑えられる可能性がありますが、実際の料金感は案件ごとに見極める必要があります。
この記事を書いた人
株式会社ゼットリンカー