あるクライアントが1月初旬に電話をくれました。とても興奮した様子で。「Gautam、Vercelがいまやdocker対応だって読んだよ。DigitalOceanのdropletを全部シャットダウンできるよね?」彼は3つのdropletを実行していて、2つは月$24ずつ、1つは月$48でした。スプレッドシート準備万端。コストを削減したかったし、すぐに削減したかったのです。
実際にテストするため2週間待つよう彼に告げました。幸い彼は聞き入れてくれました。
ここが重要な点です:Vercelのコンテナサポートはほんとに素晴らしい。そしてVPSはまだ死んでいない。この2つの文は同時に真実で、その間のニュアンスを理解することは、すべてをVercelのインフラストラクチャに docker push して、WebSocket接続が何度も切れる理由に首をかしげる前に価値があります。
Vercelが実際にアナウンスしたこと
Vercelの Docker サポート(Build Output APIを通じてロールアウトされ、後に一般向けに正式化)は、Dockerfileを送出し、Vercelがコンテナランタイムを処理させることを可能にします。Next.jsの規約やサーバーレス関数ファイル構造に縛られることはもうありません。Dockerfileを書き、Vercelがビルドして実行します。
それは本物のシフトだ。これまでは、FastAPIバックエンドやカスタムNodeサーバーで何か特殊なことをやっていたら、サーバーレス関数の形に無理やり合わせるか、Vercelフロントエンドの横にVPSを走らせ続けるかのどちらかだった。ほとんどの人は後者をしていた。うっとうしかったが、機能した。
ランタイムの実際の姿
VercelのコンテナランタイムはベアメタルDockerではない。マネージドコンテナサービスで得られるものに近い。コンテナがリクエストを受け取り、Vercelがそれをルーティングし、コンテナがそれを処理する。永続的なプロセスは機能する。Python WSGIサーバーやGo HTTPバイナリのようなものを実行できる。単一のリクエストライフサイクル内での長時間実行タスクは問題ない。
だが制約は重要だ。コンテナはゼロまでスケールできる。コールドスタートが存在する。そして決定的に:永続的なディスクストレージは得られない。アプリがローカルファイルシステムに書き込み、次のリクエストでそれらのファイルが存在することを期待しているなら、つらい目に遭うことになる。
Vercelコンテナが本当に輝く場面
3月からVercelコンテナでDjango REST APIを実行している。メディアクライアント向けの比較的シンプルな読み取り中心のサービスで、ほとんどはGETリクエスト、Neon Postgresデータベースにアクセスしている。ファイル書き込みなし。バックグラウンドジョブなし。WebSocketなし。
優秀だ。デプロイプレビューが機能する。GitHubインテグレーションは全てのPRが独自の環境を得ることを意味する。このコンテナのコールドスタートレイテンシはアイドル後の初回ヒット時に800msから1.2秒程度で、悪く聞こえるかもしれないが、クライアントのトラフィックがバースト的で予測可能な場合は受け入れ可能だ。
そのサービスのコスト?Vercelのプロプランを考慮して月額約$20。DigitalOcean App Platformの同等サービスは同程度だ。ローの$6ドロップレットの方が安いが、自分たちで管理する必要がある。
これが明確な勝利となるシナリオ
典型的なエージェンシープロジェクトを考えてみてほしい。ヘッドレスCMSを備えたマーケティングサイト、問い合わせフォームやカスタムロジック向けの軽量API、そして高速デプロイの必要性。以前はフロントエンドにVervel、ちょっとしたAPIに$6ドロップレットを使うことになっていた。今はすべてをVercelに置き、1つのダッシュボードを使い、API向けのデプロイプレビューも持つことができる。維持する物が少ない。更新を忘れる物が少ない。
5~15のクライアントサイトを扱うフリーランサーにとって、その運用上のシンプルさは、たとえコンピュート費用がやや高いとしても、実際の価値がある。
VPSがまだ優位な場面。明白だ。
そうだ。ここは率直に言う必要がある。Vercelコンテナへの熱狂が、一部の開発者に高くつく間違いを犯させている。
ファイルシステムの永続化操作。アプリがPDFを生成してローカルに保存してからS3にプッシュするなら、その特定の操作は機能する。だが、ディスクにインデックスを書き込む自托ホスト型Meilisearchインスタンスのようなものを実行している場合、永続ストレージが必要だ。Vercelはマウントされたボリュームを提供しない。マネージドMeilisearchサービスを追加するか、VPS上で実行する必要がある。それ以外にない。
WebSocketと長時間接続。Vercelのサーバーレスおよびコンテナ環境にはリクエストタイムアウトがある。これを経験したのは2024年後半のSeahawkプロジェクトで、Dockerサポートが提供される前のことだ。小規模なSaaSクライアント向けにリアルタイム協調ツールを構築していた。サーバーレスインフラで動作させるためあらゆる手を尽くした。最終的にWebSocketサーバーを月12ドルのHetzner VPSに移した。問題は解消した。そのVPSはそれ以来ずっと途切れることなく稼働している。
バックグラウンドワーカーと大規模クーン。Vercelにはクーン機能がある。シンプルなスケジュール済みタスクなら問題ない。だが、キューの仕事を継続的に処理するCeleryワーカーのようなものを実行しているなら、ただ動き続けるプロセスが欲しい。VPSならそれを簡単にやってくれる。Vercelコンテナではそれは逆流する。
大量トラフィック時のコスト。これが人を驚かせる。低~中程度のトラフィックでは、Vercelコンテナは競争力がある。だが、本当に大量のリクエスト時には、リクエスト単価が累積し始める。月48ドルのHetzner専用サーバーは、Vercelでピーク時に数百ドルかかるトラフィックを処理できる。ドロップレットをシャットダウンしたいと言っていたクライアントがいる。その一つは高トラフィックの内部ダッシュボードを実行していた。数字を出してみた。メンテナンス時間を考慮してもドロップレットを保持する方が月18ポンド安い。
Vercelに絶対に移行しない具体的なワークロード
具体例を挙げよう。Vercelが何をリリースしようと、VPSに積極的にルーティングするものはこれらだ。
- 自托ホスト型データベース。読み取り性能用の小さなPostgresレプリカですら。Vercelはデータベースホストではない。Neon、Supabase、PlanetScaleで使用するが、Postgres自体をそこで実行しようとはするな。
- メディア処理。FFmpegジョブ、画像リサイズキュー、実行時間が予測不可能なCPU集約的なもの。$20のHetzner VPSで2vCPU構成なら、これらをより良く、より安く処理できます。
- 24時間365日稼働する内部ツール。監視エージェント、ログアグリゲーター、カスタムプロキシサーバー。これらは単に稼働していればいい。常に。ゼロスケーリングはここでは敵です。
- GPUに触れるもの。説明不要ですが、言及する価値はあります。
逆に、今日Vercelコンテナに自信を持って置くなら、こういったものです:
- 永続状態を持たない軽量REST API(FastAPI、Express、Gin)
- カスタムサーバー設定付きコンテナ化されたNext.jsまたはRemixアプリ
- 営業時間中にのみアクセスされる内部API(ゼロスケーリングが実際に効果的)
- PR単位でのデプロイプレビューが本当に欲しいサービス
誰もが話さない隠れたコスト:オペレーショナル複雑性
私はSeahawkで長年にわたり12,000以上のサイトを構築してきました。エージェンシーとフリーランサーを悩ませる第一の問題は、計算コストではなく、運用オーバーヘッドです。
VPS は月額 6 ドルで安く聞こえる。実際に安い。だが、パッチを当てたり、監視したり、Nginx を設定したり、fail2ban をセットアップしたり、たまに夜 11 時に SSH で入って何かおかしな動作を調査したりする。それは無料ではない。時間であり、時間は高くつく。
Vercel はそのすべてを排除する。Railway、Render、Fly.io も同じだ。ここでの本当の競争は「VPS 単体での Vercel vs VPS」ではない。「マネージドプラットフォーム税 vs オペレーション時間税」だ。ソロオペレーターと小規模エージェンシーにとって、マネージドプラットフォーム税はたいてい良い取引だ。
2019 年に顧客から Ubuntu サーバー管理を含むブリーフを受け取った。それに応じて見積を出した。6 ヶ月後、技術的には「管理」していたが優先順位を完全に下げていたサーバーのディスク容量アラートについてのページングをまだ受け取っていた。それ以来、私は自分がインフラの所有権を取るのか、プラットフォームに所有を払うのかについて、もっと意図的になっている。
実際に使用しているフレームワーク
魔法のフローチャートではない。すべての新しいプロジェクトで聞く質問のセットに過ぎない。
- このサービスはディスクに書き込み、その書き込みが永続することを期待するか?イエスの場合、VPS またはマネージドストレージが必要。
- このサービスは長期間接続(WebSocket、SSE、gRPC ストリーム)を保持するか?イエスの場合、VPS または Fly.io のように明示的にサポートするプラットフォーム。
- このサービスは長期間 CPU バウンドか?Vercel コンテナは CPU 上限を持つ。VPS の勝ち。
- チームがデプロイプレビューと GitOps を考えずに必要とするか?Vercel の勝ち。
- トラフィックは一貫性があり、高ボリュームか?数字を実行する。一定の閾値以上では VPS はたいていより安い。
- これは個人でやっているのか、サーバーのことは考えたくない小さなエージェンシーなのか?Vercelはプレミアム価格に見合う価値がある。
質問1、2、3のいずれかがイエスなら、HetznerかDigitalOceanに手を出す。それ以外は相談の余地がある。
2026年のインフラストラクチャの実像
プラットフォームはパーシステントストレージの面で改善されている。Fly.ioはFly Volumesを持っている。Renderはパーシステントディスクを持っている。Vercelもリクエストが頻繁に上がることを考えると、おそらく最終的に同様のものを追加するだろう。「マネージドプラットフォーム」と「フルコントロールのVPS」の差は縮まっている。
しかし縮まることと閉じることは別だ。そして生のコンピュート経済学は根本的には変わっていない。Hetzner CAX11 ARMインスタンスの€3.79/月は、適切なワークロードなら今もなお異常なほどの良い値だ。マネージドプラットフォームで同等のコンピュートをこの価格で提供している企業はない。
2026年の正直な世界の状態はこうだ:VPSは死んでいない。VPSはますますオプショナルになっている。これらは別のことだ。
Seahawk Mediaで今立ち上げるほとんどの新規プロジェクトは、上の質問リストの何かが別の答えをトリガーしない限り、デフォルトではVercelかRailwayに乗っかる。ここ18ヶ月間で、我々が管理する稼働中のVPSインスタンスの数をおよそ40%削減しただろう。しかし残っているものは正当な理由があってここにあり、どこにも行かない。
FAQ
VercelのコンテナはDockerComposeをローカルから本番までのパリティのために置き換えられるか?
ある程度はそうだが、実際にはそうではない。DockerComposeは複数のサービスをローカルで一緒にオーケストレーションすることについてだ。Vercelはデプロイメントあたり1つのコンテナを実行する。スタックにComposeファイルで定義されたWebサーバー、ワーカー、Redisがある場合、Vercelはウェブサーバーの部分を処理できる。それでもマネージドRedis(一般的な選択肢はUpstash)を指すことと、ワーカーを別に処理することが必要だ。ローカルパリティは以前よりは改善されているが、ComposeからVercelへは直接的な翻訳ではない。
Vercelのコンテナがゼロスケーリングされるとどうなるか?
コンテナプロセスが停止します。新しいリクエストが来ると、Vercelが再起動します。この起動時間がコールドスタートレイテンシーです。コンパイル済みバイナリ(Go、Rust)の場合、通常500ミリ秒未満です。JVMベースのアプリなどの大きなランタイムの場合、2~4秒かかることがあります。クライアントが3秒の初回ロードに気付く可能性があるため、本番導入の前にステージング環境で必ずテストする価値があります。
Vercelのコンテナサポートは無料のHobbyプランで利用できますか?
2026年初時点では、いいえ。コンテナデプロイメントには最低でもProプラン以上が必要です。Hobbyティアはサーバーレス関数と静的サイトをサポートしています。この仕様は過去に変更されたことがあり、今後も変更される可能性があるため、Vercelの料金ページで直接確認する価値があります。
Vercelまたは生のVPSではなく、Fly.ioを使うべき時はいつですか?
永続的なプロセスが必要で、ユーザーに近い世界規模の分散が必要で、サーバー設定を管理したくない場合、Fly.ioが私の第一選択です。興味深い中間的な立場です。コンテナをデプロイしますが、リージョン、マシンサイズ、永続ボリュームについてVercelが提供するものより多くの制御ができます。WebSocket要件がある長時間実行APIや、複数リージョンに展開する必要があるものに使用しています。トレードオフはDX(開発者体験)がVercelのGitHub統合より少し複雑になることです。
---
VPSは習慣で默認値として選ぶべきものではありません。ただし、興奮して放棄すべきものでもありません。ワークロードを理解してください。数字を計算してください。そして、何かをシャットダウンする前に2週間待つほうがいいかもしれません。
関連記事:2026年のAI検索キーワード調査:その概要、従来のSEOとの違い、テクニカルSEO、およびAI検索
