VercelのWebSocketサポートが正式リリース 制約と設計の勘所を整理する
2026年10月20日、Vercel Functions の WebSocket サポートが正式版 (GA) になりました。公開ベータは2026年6月下旬に始まり、Vercel CDN はこれまでに累計3億接続、現在は1日あたり1500万接続を処理しているとされています。結論から言うと、「GA になったからサードパーティのリアルタイム基盤が不要になる」わけではありません。接続は関数の最大実行時間で切れ、1接続は1つの関数インスタンスに固定されます。この2点を前提に設計できるかどうかが、Vercel 上で WebSocket を使えるかの分かれ目です。
発表された内容
changelog に書かれている要点は3つです。1つ目は、Vercel Functions で WebSocket 接続を受けられる機能がベータから GA に移行したこと。2つ目は、用途として AI チャット、ストリーミング、リアルタイムのマルチプレイヤーアプリが挙げられ、AI Gateway の realtime モデルもこの仕組みの上で動いていること。3つ目は課金で、WebSocket 接続は通常の Function 実行と同じ制限・料金体系に従い、Active CPU 課金のもとでは CPU はメッセージを処理している時間だけ課金されます。
なお、公式ドキュメントの WebSockets ページは本稿執筆時点で「Beta」表記が残っている箇所があります。機能の可用性は changelog が最新なので、表記の差異を見かけたら更新日を確認してください。
前提となる仕組み: Fluid compute と接続の寿命
WebSocket を使うには Fluid compute が有効である必要があります。2025年4月23日以降に作成されたプロジェクトでは既定で有効ですが、それ以前のプロジェクトは設定を確認してください。
接続の挙動で押さえるべき点は次のとおりです。
1つの WebSocket 接続は1つの関数インスタンスに固定され、その接続のメッセージは同じインスタンスに届く。Fluid compute により1インスタンスが複数接続を扱える
接続は関数の最大実行時間に達すると閉じる。Fluid compute 環境では既定300秒、Hobby は300秒が上限、Pro・Enterprise は最大800秒。1800秒 (30分) はベータで、関数単位の設定と対応ランタイムが必要
再接続は同じインスタンスに届く保証がない。新しいデプロイ後は、新規接続が新デプロイに向かう一方、既存接続は閉じるまで旧デプロイに残る
アップグレードは Upgrade ヘッダ付きの HTTP GET として始まるため、Routing Middleware、rewrite、Firewall ルール、レート制限を通る
最後の点は実務上の利点です。認証やボット対策、パス単位のファイアウォールルールを、通常の HTTP リクエストと同じ仕組みで接続開始時にかけられます。
実装で先に決めるべき4つのこと
再接続の扱い。接続が時間で切れる以上、クライアント側の再接続は必須です。公式ドキュメントも、接続を作り直し、チャンネルやトピックを再購読し、必要な状態を読み直す実装を推奨しています。指数バックオフを入れて、切断時に一斉再接続が集中しないようにします。
状態の置き場所。presence、ルーム、カウンタ、pub/sub の調停をインスタンスのメモリに置くと、再接続やデプロイで壊れます。Redis などの外部ストアに持たせ、関数側は接続とメッセージ処理に専念させる構成が前提になります。インスタンスをまたいだブロードキャストも、この外部ストア経由で自前に組む必要があります。
フレームワークごとの作法。ws や Socket.IO はそのまま使えますが、Socket.IO はクライアントで WebSocket トランスポートを明示する必要があります (既定の HTTP ロングポーリングはアップグレードになりません)。Next.js は WebSocket アップグレード用の API を公開していないため、@vercel/functions 3.10.0 以降の upgradeWebSocket() を使います。Nitro や Nuxt、Hono、h3、Bun の Bun.serve()、Python の ASGI/WSGI 系 (FastAPI、Django Channels、Flask-Sock) は Vercel 固有の API なしで動きます。
コストの見積もり方。接続中は Function の使用量に加えて、送受信データの Fast Data Transfer と Fast Origin Transfer が発生します。Active CPU はメッセージ処理時のみの課金ですが、インスタンスが生きている間の Provisioned Memory は時間で積み上がります。つまり、ほとんどメッセージが流れない接続を長時間張り続ける設計は、CPU が安くてもメモリ側で効いてきます。想定同時接続数×平均接続時間と、ハートビートの頻度を先に見積もってください。
Vercel で完結させるか、別構成にするか
判断軸はシンプルです。セッション単位で完結し、数分〜十数分で切れても再接続で回復できるものは Vercel Functions で十分です。AI チャットの双方向ストリーミング、1対1の編集セッション、進捗通知などが該当します。
一方、数時間切らしたくない常時接続、多数の購読者への大規模なファンアウト、presence や厳密な順序保証が要件に入る場合は、外部ストアでの自前調停を含めた運用コストと、専用サーバーやマネージドのリアルタイムサービスを使う構成とを比較する価値があります。GA によって「Vercel では WebSocket が使えない」という前提が変わっただけで、常時接続を前提にしたアーキテクチャの難しさ自体は残っています。
検証の進め方
対象プロジェクトで Fluid compute が有効かを確認する
WebSocket を扱うルートの maxDuration を明示的に設定する (既定の300秒に暗黙に依存しない)
クライアントに再接続と再購読を実装し、意図的に時間切れを起こして挙動を確認する
共有状態を外部ストアへ移し、インスタンスをまたぐ配信が必要かを切り分ける
デプロイ中に既存接続と新規接続がどう分かれるかを、本番相当の環境で確認する
同時接続数と接続時間から Active CPU・Provisioned Memory・転送量を試算し、既存の構成と比較する
いちばん小さなリアルタイム機能を1本だけ移して、この6項目を実測するのが安全な進め方です。
既存アプリへのリアルタイム機能の追加や、WebSocket を前提にした構成の見直しで判断に迷う場合は、chot Inc. のお問い合わせからご相談ください。要件に対して Vercel Functions で完結させるべきか、別構成を併用すべきかの整理からお手伝いできます。
