2026 年 5 月、InfoQ が OpenAI Introduces Websocket-Based Execution Mode to Reduce Latency in Agentic Workflows を公開し、OpenAI が agentic workflow 向けに WebSocket ベースの実行モードを提供開始したことを発表しました。HTTP ラウンドトリップを排除して双方向ストリーミングにすることで、ツール呼び出しのレイテンシが大きく改善され、「リアルタイム性が要件になるエージェント」が現実的な選択肢になりました。
弊社では受託の AI エージェント案件で、音声・チャット・コールセンター連携といった 「待ち時間がそのまま体験品質になる」用途の相談が増えています。本記事では、Websocket Execution Mode を受託でどう設計し、HTTP モードとどう使い分けるか、運用上の落とし穴を整理します。
何が変わったのか — レイテンシの構造
WebSocket 実行モードがもたらす変化は、「同じ処理でも待ち時間が違う」という単純で重要な点です。
| 観点 | HTTP モード | WebSocket モード |
|---|---|---|
| 接続 | 都度確立 | 単一接続で多重化 |
| ツール呼び出し | リクエスト毎に往復 | 双方向ストリーミング |
| 体感レイテンシ | 数百 ms 〜 1 秒 | 数十 ms 〜 数百 ms |
| 並列ツール実行 | 個別呼び出し | 並列ストリーミング |
| 接続維持コスト | 不要 | 必要（idle / heartbeat 設計） |
| デバッグ容易性 | リクエストログで追える | 専用ツールが必要 |
特に 「並列ツール実行」は、エージェントが複数のデータソースを同時に参照する受託案件で大きな差を生みます。HTTP の直列呼び出しで 5 ツール × 200ms = 1 秒待たせていたものが、並列ストリーミングで 200ms に圧縮できる、という構造です。
これは Computer Use 4.5x コスト時代の受託エンジニアリング で扱った “コスト × レイテンシ” の論点の続きで、「コストが上がる代わりに体験が劇的に良くなる」選択肢が増えたと整理できます。
受託で「WebSocket vs HTTP」を判断する基準
全案件で WebSocket にすればよいわけではありません。受託では以下の判断軸で振り分けます。
[WebSocket を採用すべき案件]
├ 音声 / 動画リアルタイム連携
├ コールセンター / カスタマーサポート
├ ライブチャット (体感 1 秒以内必須)
├ 多数ツールの並列呼び出しが必要
└ ストリーミング UI が前提
[HTTP で十分な案件]
├ バッチ処理 / 夜間ジョブ
├ 非同期メール返信生成
├ 報告書 / レポート自動生成
├ 単発のコード生成 (PR レビューなど)
└ レイテンシ要件 > 2 秒 OK特に **「ライブチャット」は実は判定が難しい領域で、「タイピング表示」**で体感を吸収できる場合は HTTP でも問題ない、というケースが多々あります。実機テストで体感レイテンシを計測することが、受託の標準フローです。
受託の標準アーキテクチャ — WebSocket 採用時の 4 層
WebSocket 実行モードを受託で組む場合、以下の 4 層で構成します。
[Layer 1: クライアント層]
├ ブラウザ / モバイルアプリ
├ 音声 SDK / WebRTC
└ ストリーミング UI 描画
[Layer 2: WebSocket ゲートウェイ]
├ 認証 / 認可 / レートリミット
├ 接続管理 / heartbeat
└ 障害時の自動再接続
[Layer 3: エージェント実行層]
├ OpenAI WebSocket Mode
├ ツール呼び出しの並列化
└ メモリ / コンテキスト管理
[Layer 4: ツール / データソース層]
├ MCP サーバー
├ 業務 API / DB
└ ベクトル検索 / RAG特に Layer 2 の WebSocket ゲートウェイを自前で持たずに OpenAI 直結する設計は、認証・監査・コスト管理の観点で受託では推奨できません。必ずゲートウェイを挟むのが受託標準です。
これは MCP サーバー OAuth 2.1 認証を受託で実装する で扱った “認証層を必ず挟む” と同じ思想です。
レイテンシ計測 — 受託が顧客と握る 4 指標
受託契約に書く レイテンシ KPI は、以下の 4 指標で構成します。
| 指標 | 定義 | 目標値の例 |
|---|---|---|
| First Token Latency | 最初のトークンが届くまで | 300ms 以内 |
| Tool Call Round-trip | ツール呼び出しの往復 | 200ms 以内 |
| End-to-End Response | 完全な応答が完了するまで | 2 秒以内 |
| Connection Stability | WebSocket の切断率 | 月次 0.5% 以下 |
特に 「First Token Latency」は 「沈黙の時間」として体感に直結し、ここで 1 秒待たせるとほぼ確実に離脱します。契約に明記する KPIとして最も重要です。
運用上の 5 つの落とし穴
WebSocket 実行モードを受託で運用するときに踏みやすい落とし穴を共有します。
落とし穴 1: 接続維持コストを見積もり忘れる
WebSocket は idle 時間も接続を維持します。1 万同時接続を想定するなら、ゲートウェイのスケール設計が HTTP と全く異なります。事前に負荷試験を必ず実施します。
落とし穴 2: 切断時の状態復旧が雑
ネットワーク断で WebSocket が切れたとき、「会話の続きをどう復元するか」を設計しないと、ユーザーが文字を打ち直す羽目になります。サーバー側に会話状態を保持し、再接続時に同期します。
落とし穴 3: HTTP 互換ラッパーで隠す
「WebSocket は難しいから HTTP で隠そう」とすると、WebSocket のメリットが消えるだけでなく、両モードのハイブリッド地獄になります。WebSocket を使うなら最後まで WebSocketを貫きます。
落とし穴 4: 観測性の設計不足
HTTP はリクエストログで追えますが、WebSocket は メッセージ単位のログを別途設計する必要があります。OpenTelemetry の trace / span を WebSocket メッセージと紐付けます。
これは OpenTelemetry 移行の Airbnb 観測性事例 で扱った観測性の設計と整合する論点で、WebSocket は最初から観測性を組み込む必要があります。
落とし穴 5: バックエンド側の long-lived 接続の管理
サーバー側で 何万もの WebSocket を 1 プロセスで保持するのは限界があります。Cloudflare Durable Objects / WebSocket gateway 専用 PaaS など、接続管理に特化したインフラを選定します。
価格モデル — 低レイテンシエージェント受託パッケージ
弊社では低レイテンシエージェントの受託案件を、以下の 3 段階で提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| Realtime PoC | 200 万円 / 0 円 | 単発の PoC 構築 | WebSocket 実装 + レイテンシ計測 + 改善提案 |
| Realtime Standard | 600 万円 / 50 万円〜 | チャット / コールセンター本番 | PoC + ゲートウェイ構築 + 24h 監視 |
| Realtime Enterprise | 1500 万円〜 / 150 万円〜 | 大規模 / 規制業界 | Standard + 認証連携 + 監査ログ + DR |
特に Realtime PoC は、「WebSocket でどこまで体感が変わるかを実測したい」という相談に刺さるレンジです。
まとめ — 「速さは契約の対象」の時代へ
WebSocket Execution Mode の登場で、「エージェントの速さ」は技術選定ではなく契約の対象になりました。First Token Latency や切断率を KPI として明記し、実測値で評価する運用が、受託の新しい標準になります。
弊社では Realtime PoC / Standard / Enterprise の 3 段階で 低レイテンシエージェント受託パッケージを提供しています。「音声エージェントの待ち時間でユーザーが離脱する」「コールセンターに AI を組み込みたいがレイテンシが懸念」というご相談は お問い合わせフォーム からお気軽にどうぞ。
