# VercelのWebSocketサポートが正式リリース 制約と設計の勘所を整理する

元のページ: <https://chot-inc.com/columns/vercel-websocket-ga-design-considerations>

開発 2026.10.21

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 が使えない」という前提が変わっただけで、常時接続を前提にしたアーキテクチャの難しさ自体は残っています。

## 検証の進め方

1. 対象プロジェクトで Fluid compute が有効かを確認する

2. WebSocket を扱うルートの maxDuration を明示的に設定する (既定の300秒に暗黙に依存しない)

3. クライアントに再接続と再購読を実装し、意図的に時間切れを起こして挙動を確認する

4. 共有状態を外部ストアへ移し、インスタンスをまたぐ配信が必要かを切り分ける

5. デプロイ中に既存接続と新規接続がどう分かれるかを、本番相当の環境で確認する

6. 同時接続数と接続時間から Active CPU・Provisioned Memory・転送量を試算し、既存の構成と比較する

いちばん小さなリアルタイム機能を1本だけ移して、この6項目を実測するのが安全な進め方です。

既存アプリへのリアルタイム機能の追加や、WebSocket を前提にした構成の見直しで判断に迷う場合は、chot Inc. の[お問い合わせ](https://chot-inc.com/contact)からご相談ください。要件に対して Vercel Functions で完結させるべきか、別構成を併用すべきかの整理からお手伝いできます。

## 出典

- [Vercel Changelog: WebSocket サポートが一般提供開始](https://vercel.com/changelog/websocket-support-is-now-generally-available)

- [Vercel Docs: WebSockets (Vercel Functions)](https://vercel.com/docs/functions/websockets)

- [Vercel Docs: Vercel Functions の制限](https://vercel.com/docs/functions/limitations)

- [Vercel Docs: Vercel Functions の最大実行時間の設定](https://vercel.com/docs/functions/configuring-functions/duration)

- [Vercel Docs: 料金体系](https://vercel.com/docs/pricing)

この記事をシェア

## 最新の記事

[セキュリティ 2026.10.21](https://chot-inc.com/columns/vulnerability-threat-risk-incident)

### [脆弱性・脅威・リスク・インシデントの違い｜Web担当者のための4つの使い分け](https://chot-inc.com/columns/vulnerability-threat-risk-incident)

[セキュリティ 2026.10.20](https://chot-inc.com/columns/contact-form-spam-protection-comparison)

### [問い合わせフォームのスパム対策を比べる — CAPTCHA・時間判定・レート制限の選び方](https://chot-inc.com/columns/contact-form-spam-protection-comparison)

[開発 2026.10.20](https://chot-inc.com/columns/apple-app-review-guidelines-nudify-2-5-19)

### [AppleがApp Reviewガイドラインを改定、AI「ヌード化」アプリと審査後の機能追加を明文で禁止](https://chot-inc.com/columns/apple-app-review-guidelines-nudify-2-5-19)

[コラム一覧](https://chot-inc.com/columns)