JA EN
shiichan

Responses API に WebSocket 登場、エージェントのループが 40% 速く！

OpenAI News ★★★ Markdown で見る
#openai#ai#infrastructure

やっほー、しぃちゃんだよ！今日は「速さ」のお話だよ。エンジニアにとって待ち時間って地味にストレスだよね。その待ち時間をどうやって削ったのか、ワクワクする裏側の話が出てきたから紹介しちゃうね！

OpenAI News openai.com

なにが発表されたの？

OpenAI の News で、Responses API に WebSocket を使った新しいモードを入れて、エージェントのループを end-to-end で 40% 速くしたよ、っていう発表があったの。

Codex にバグ修正をお願いすると、コードベースを探して、ファイルを読んで、編集して、テストを走らせて…って、裏では Responses API へのリクエストが何十往復もするんだって。この積み重ねが、複雑なタスクだと「数分の待ち時間」になっちゃう。そこにメスを入れた、っていうお話なの。

今までどうだったの？

エージェントのループの遅さは、大きく 3 つの段階に分かれるんだって。API サービス側（リクエストの検証や処理）、モデルの推論、そしてクライアント側（ツールの実行やコンテキスト作り）。

昔は GPU で動くモデル推論がいちばん遅かったから、API 側のオーバーヘッドはその陰に隠れて目立たなかったの。ところが推論がどんどん速くなると…隠れていた API 側のコストが急に目立つようになっちゃったんだ。

実際、これまでの主力モデル GPT-5 や GPT-5.2 は毎秒 65 トークン（TPS）くらい。でも高速コーディングモデルの GPT-5.3-Codex-Spark は、専用の Cerebras ハードウェアで 1,000 TPS 超えを狙ってたの。モデルがこんなに速くなると、API 側が足を引っ張っちゃうんだよね。

これで何が変わるの？

いちばん大きいのは、Responses API に「持続的な接続」ができるようになったこと。今までは follow-up のたびに HTTP で新しく接続して、会話の履歴を丸ごと送り直してたの。だから会話が長くなるほど、同じ処理を何度も繰り返して重くなってた。

新しい WebSocket モードでは、接続している間はサーバー側が状態をメモリにキャッシュしておいて、新しく必要になった情報だけを送ればよくなったの。結果、みんなが体感する推論速度は 65 TPS から 1,000 TPS 近くまでジャンプ！ しかも本番トラフィックでは瞬間的に 4,000 TPS まで出たんだって。

深く潜ってみよう

まず 2025 年 11 月ごろ、OpenAI は単発リクエストの最適化スプリントをやったの。レンダリング済みトークンやモデル設定をメモリにキャッシュ、中間サービスへの呼び出しを減らして推論サービスを直接叩く、安全性の分類器を速くする…。これで time to first token（TTFT、最初の 1 トークンが返るまでの時間）が約 45% 改善。でも GPT-5.3-Codex-Spark にはまだ足りなかったの。

そこで transport 自体を見直したんだ。WebSockets と gRPC 双方向ストリーミングを比べて、最終的に WebSockets を採用。単純なメッセージ転送プロトコルだから、開発者が入出力の形を変えなくて済むのが決め手だったよ。

最初の試作は、エージェントの一連の動きを「1 つの長いレスポンス」として扱う大胆なもの。ツール呼び出しが出たら asyncio でサンプリングループを止めて、response.done をクライアントに送る。クライアントがツールを実行して response.append で結果を返すとループが再開…という仕組み。ローカルのツール呼び出しを、web search みたいなホスト型ツールと同じように扱うイメージなんだって。これで API の重い処理を「前処理 1 回・後処理 1 回」に減らせた。

でもこの形は API の使い勝手がガラッと変わって難しかったから、本番版では見慣れた形に戻したの。response.create を同じボディで呼びつつ、previous_response_id で前の状態を引き継ぐ方式だよ。WebSocket 接続中はサーバーが前のレスポンスの状態（レスポンスオブジェクト、入出力アイテム、ツール定義、レンダリング済みトークンなど）をメモリに持っていて、次のリクエストではそれを再利用するの。おかげで安全性の分類器や検証は新しい入力だけを処理、トークン化もスキップ、課金みたいな後処理は次のリクエストと重ねて実行…と、無駄をどんどん削れたんだ。

この WebSocket モードは、最新の GPT-5.3-Codex や GPT-5.4 を使うときにも効いてくるよ。

まとめ

  • Responses API に WebSocket モードが登場、エージェントのループが end-to-end で 40% 高速化
  • 持続的な接続でサーバーが状態をキャッシュ、follow-up ごとの会話履歴の送り直しをやめたのがカギ
  • previous_response_id で見慣れた API の形はそのまま、内部だけ賢く再利用
  • GPT-5.3-Codex-Spark で 1,000 TPS を達成、本番では瞬間 4,000 TPS も
  • 反響も大きくて、Vercel の AI SDK は最大 40% 高速化、Cline は 39% 速く、Cursor 上の OpenAI モデルは最大 30% 速く

エージェントを実運用に載せてる開発者や、Codex みたいなコーディングエージェントの遅延に悩んでる人にはとくに刺さる話だと思うな。推論が速くなるほど、その周りの仕組みも速くしないと恩恵が届かない…っていう視点、すごく勉強になったよ！

関連記事