OpenAI WebSocket Mode for Responses API
OpenAI · コーディング
OpenAI の Responses API 向け WebSocket モードは、反復的な HTTP リクエストの代わりに単一の WebSocket で、長くツールを多用するエージェントワークフローを動かせる常時接続モードだ。Responses エンドポイントに接続を一本開き、各ターンでは新しい入力項目と previous_response_id だけを送って軽く保つ。同じタスクが何十回もツールを呼ぶエージェント型コーディングやオーケストレーションのループ向けに作られており、store=false と組み合わせればプライバシーに敏感な環境でも動く。
OpenAI WebSocket Mode for Responses API について
Responses API 向け OpenAI WebSocket モードとは
OpenAI WebSocket モードは Responses API のトランスポート選択肢であり、独立した製品ではない。Responses API はエージェント風のアプリを作るための OpenAI の状態保持型プリミティブで、新しいプロジェクトの多くがここから始めるエンドポイントだ。変わるのはその下の配管だけ。それだけである。プロンプトやツールに関するそれ以外はすべて同じままだ。
これが解決するのは継続のオーバーヘッドだ。標準の HTTP モードでは、ターンごとに接続を開き直し、膨らみ続けるコンテキストを毎回送り直す。単発の質問なら問題ない。ツールを二十回、三十回と連続で呼ぶエージェントでは、その往復が積み重なる。WebSocket モードは Responses エンドポイントへの接続を開いたままにし、各続きでは差分だけを送らせる。previous_response_id でつなぐ仕組みだ。難解な話ではない。ただ良い配管なだけだ。
最大の制約は適用範囲にある。このモードは長くツールを多用するワークフロー向けで、何にでも向くわけではない。OpenAI 自身の指針も、単発のリクエストや短い会話は標準 HTTP の Responses API にとどめるべきだとしており、そこでは最適化の効果は小さい。接続には時間制限もあるため、長時間の実行では再接続を扱う必要がある。多少面倒だが、対処はできる。
はじめかた
- OpenAI の API キーを取得し、Python なら websocket-client パッケージなどの WebSocket クライアントをインストールする。
- Responses の WebSocket エンドポイントにソケットを開き、Authorization ヘッダーにキーを渡す。
- response.create イベントで最初のターンを送る。モデル、ツール、最初の入力を含める。
- 会話を続けるには、前のターンの previous_response_id を参照し、function_call_output など新しい入力項目だけを含めた新しい response.create を送る。
- サーバーイベントがストリームで戻るのを読み、接続の時間制限に達したらソケットを閉じるか再接続する。
AIツール情報
OpenAI WebSocket Mode for Responses APIの料金、対応プラットフォーム、性能を簡単に確認できます。
こんな人におすすめ
このツールが最も力を発揮するユーザー、タスク、シーン。
ユーザー
- 低遅延のツールループを必要とするエージェントを作るバックエンドおよび AI エンジニア。このモードはサーバー間の通信を狙っている。
- 同じジョブが1回の展開で何十回もツールを呼ぶオーケストレーション負荷を動かすプラットフォームチーム。
- store=false とデータゼロ保持に対応するトランスポートを必要とする、プライバシー制約のある開発者。
タスク
- エージェント型コーディング：各ステップで HTTP 呼び出しをやり直す代わりに、分析・修正・検証のサイクルを1本の接続で回す。
- ツール呼び出しの処理：function_call_output をストリームで返し、履歴をすべて送り直さずにモデルを続行させる。
- マルチターンのオーケストレーション：モデルとツールの往復が多い中でも、長時間動くエージェントセッションを生かしたまま安く保つ。
シーン
- ファイル分析、パッチ生成、テスト実行を生きたソケット上で繰り返すコーディングエージェント。
- ターンあたりの遅延が重要な場面で、ユーザーリクエストごとに複数のツール呼び出しを調整するバックエンドサービス。
- モデルもプロンプトも変えずに、大量のエージェント通信のオーバーヘッドを削りたいチーム。
主な機能
Responses エンドポイントへの常時接続
WebSocket モードは、Responses API への接続を何ターンにもわたって一本開いたままにする。response.create イベントで操作し、最初のイベントは通常のリクエストと同様に新しいターンを始める。ソケットが開いたままなので、標準ストリーミング API が毎ターン払う接続のセットアップを省ける。そのオーバーヘッドは一度なら小さい。長いエージェント実行ではそうではない。
previous_response_id による差分入力
続きのターンは新しい入力項目と、前のターンにひもづく previous_response_id だけを送る。コンテキスト全体は送り直さない。長い連鎖で節約の大半が生まれるのはここだ。最初のターンのペイロードは標準の create ボディをなぞり、ここでは当てはまらない stream や background といったトランスポート専用の項目を除く。だから会話が伸びてもリクエストは軽いままだ。
ツールを多用するワークフローの継続を高速化
目玉の利点は、ワークフローがモデルとツールの往復を多く含むようになって現れる。それが低遅延エージェントワークフローの世界で、このトランスポートはそのために作られた。OpenAI の指針はツール呼び出しの多い展開で相応の高速化を示しており、利得は最初のトークンだけでなく継続の経路から来る。エージェントが同じツールを何度も回り直すとき、最も時間を無駄にするのはまさにその部分だ。どのワークフローでも実感できるわけではない。ツールをほとんど呼ばないエージェントなら大して変わらない。絶えず呼ぶなら、そこが本題である。
store=false とデータゼロ保持に対応
WebSocket モードは store=false とデータゼロ保持の構成で動く。OpenAI に応答の状態を保持させられない場合に効いてくる。サーバーは接続の存続期間だけ直近の応答状態をメモリに置くので、ターンをリクエストをまたいで保存せずに高速な継続が得られる。そうしなければデータがサーバーに残ってしまう。規制下やプライバシーに敏感な環境のチームにとって、この組み合わせがこのトランスポートを選ぶ理由になる。
ストリーミングイベントと順序が HTTP モデルと一致
サーバーイベントとその順序は既存の Responses ストリーミングモデルと一致する。HTTP でストリーミングイベントをすでに扱っているなら、イベントの形は見覚えのあるものだ。だからクライアントのロジックを一から書き直す必要はない。違いは配信チャネルで、メッセージ形式ではない。ではなぜ移るのか。効く場面での速度のためだ。それで移行コストは低く保てる。
メリットとデメリット
メリット
- ツール呼び出しの多いワークフローで継続の遅延が下がる。HTTP モードが最も苦しいのはそこだ。
- 差分の入力だけを送ることで、繰り返しの送信と接続セットアップのオーバーヘッドを減らす。
- store=false とデータゼロ保持に対応し、プライバシーに敏感なチームでも使える。
- サーバーイベントと順序が HTTP ストリーミングモデルと一致し、既存のクライアントコードを活かしやすい。
- 開いたままのソケット1本は、積み重なった HTTP リクエストよりエージェント型コーディングやオーケストレーションのループに向く。
デメリット
- 長くツールを多用するワークフローでないと割に合わない。短い会話や単発の呼び出しでは利得が小さい。
- 接続に時間制限があるため、長時間動くエージェントには再接続のロジックを組む必要がある。
- トランスポートは単純な HTTP 呼び出しより管理するコードが多く、クライアントの複雑さが増す。
- 標準の API 利用料金はそのままかかる。このモードが削るのは遅延で、トークン単価ではない。
よくある質問
ターンごとに新しい HTTP リクエストを出す代わりに、Responses API への常時 WebSocket 接続を保つトランスポートモードだ。新しい入力項目と previous_response_id だけを送るので、長いエージェント実行でのターンあたりのオーバーヘッドを削る。電話を切ってかけ直すのではなく、回線につなぎっぱなしにするイメージだ。
関連コンテンツ
OpenAI WebSocket Mode for Responses APIに関連するツール、スキル、記事を探す。
OpenAI WebSocket Mode for Responses APIの代替ツール
Forefront
Forefront · コーディングForefrontはオープンソースAIで構築するためのウェブプラットフォームだ。主要なオープンソース言語モデルを自分のデータで微調整し、性能を評価し、API経由で実行したり、エクスポートして自分でホストしたりできる。クローズドなプラットフォームの手軽さを求めつつ、モデルとデータの所有権にはこだわる開発者が対象だ。
Startkit
StartKit.AI · コーディングStartkitは、AI SaaSとAIラッパー製品を作るためのボイラープレートだ。面倒な部分をあらかじめ配線済みにしたAIスタートアップボイラープレートと考えればいい。認証、StripeとLemon Squeezyの決済、利用制限、トランザクションメール、そしてOpenAI、Anthropic、Groq、Llamaと通信するAI APIスターターキットが含まれる。リポジトリをクローンして価格を設定し、ユーザーが実際にお金を払う部分に取りかかれる。ReactとTailwind上のNext.jsで作られているため、ボイラープレートコードの多くはすでに見慣れたものだ。
Testim
Tricentis · コーディングTestimは、Web・モバイル・Salesforceアプリ向けにエンドツーエンドテストを構築して実行するAIテスト自動化プラットフォームだ。機械学習を頼りに、インターフェースが変わってもテストを安定させ、チームが壊れたセレクターの修正に費やす時間を減らす。今日から使い始められる自動テストツールとしては悪くない。ブラウザで操作を録画してテストを作り、より細かい制御が必要なときはJavaScriptを足す。忙しいQAチームにとって堅実な選択肢である。