OpenAIが、Responses APIに WebSocketベースの実行モード を追加しました。
これはざっくり言うと、AIとの会話や処理のたびに毎回HTTPで「送る→返す」を繰り返すのではなく、つながったまま会話し続ける通信方式 に切り替える、という話です。
InfoQの記事では、この変更によって agentic workflows、つまりAIが単発で答えるのではなく、
といった 複数ステップの処理 で、遅延とオーバーヘッドを減らせると説明しています。
正直、これはかなり筋のいい改善だと思います。
AIモデルそのものが速くなっても、実運用では「ネットワークの往復」が地味に足を引っ張ることが多いんですよね。特にエージェント系は、1回の応答で終わらず、何度もやり取りするので、通信の待ち時間が積み重なって効いてくる。そこを叩きにいったのが今回のポイントです。
/filters:no_upscale()/news/2026/05/openai-websocket-responses-api/en/resources/1openaibeforewebsocket-1777845419017.jpeg)
専門用語をかみ砕くと、WebSocketは “つなぎっぱなしで会話できる通信方式” です。
普通のHTTPは、イメージとしてはこんな感じです。
一方WebSocketは、
という形です。
つまり、毎回の「接続の準備」や「お作法のやり直し」が減る。
この差が、リアルタイム性が大事なAIシステム ではかなり効くわけです。
/filters:no_upscale()/news/2026/05/openai-websocket-responses-api/en/resources/1openAIwebsokcet-1777845419017.jpeg)
記事によると、AIモデルの推論速度自体は改善してきた一方で、次のような処理がボトルネックになってきたそうです。
ここで面白いのは、「モデルの賢さ」ではなく「通信の設計」が勝負を分ける場面が増えている ことです。
AI業界って、どうしても「より賢いモデルが出た！」という話に目が行きがちですが、実際のプロダクトでは、こういう地味な基盤改善がユーザー体験を大きく左右します。私はここがいちばん現実的で、いちばん重要な話だと思います。
OpenAIは、初期の本番利用で 最大40%のlatency reduction（遅延削減） を確認したとしています。
さらに、1,000 TPS前後を安定的に処理 し、バースト時には4,000 TPS に達したとも説明されています。
TPSは transactions per second の略で、1秒間にどれだけ処理できるかを示す数字です。
要するに、「人が増えてもさばけるか」「急にアクセスが増えても耐えられるか」という話ですね。
ここで大事なのは、単に“速くなった”だけでなく、高負荷時のスループットも改善している ことです。
AIシステムは、1回の応答速度だけではなく、混雑したときの安定性がかなり大事なので、この点は実運用ではかなり魅力的です。
開発者側は、複数回のHTTP呼び出しをやめて、1つのpersistent session（長生きする接続） を使う形で統合します。
これによって、
というメリットがあります。
特にストリーミングは重要です。
これは、答えを全部まとめて返すのではなく、生成された分から順に見せる 仕組みのこと。コード生成や対話型のAIでは、ユーザーが「途中経過」を見られるだけでも体感速度がかなり違います。
個人的には、ここはかなり“地味だけど効く”改善だと思います。
AIの応答って、最終結果の品質だけじゃなくて、「待たされている感じ」 がUXを悪くするんですよね。WebSocketは、そのストレスを減らす方向に効きます。
この変更は、すでに周辺ツールにも波及しています。
記事では、以下のような例が挙げられていました。
この流れを見ると、今回のポイントは「OpenAIが新機能を出した」だけではありません。
むしろ、AIツール全体が、モデル中心から“通信と実行の最適化”へと関心を広げている のが面白いところです。
要するに、AI開発はもう「どのLLMが一番賢いか」だけでは戦えない、ということですね。
どの接続方式を選ぶか、どう状態を持つか、どうツールを呼ぶか。こういう基盤設計が、かなり差を生む時代になってきたのだと思います。
もちろん、WebSocketにすれば全部ハッピー、ではありません。
記事でも、新しい設計課題として次のような点が挙げられています。
つまり、WebSocketは速いけれど、状態を持つぶん難しさも増える んです。
HTTPはシンプルで壊れにくい一方、WebSocketはリアルタイム性と引き換えに運用の考慮点が増える。ここはエンジニアなら「たしかにそう」とうなずくところではないでしょうか。
私は、今回の話は「WebSocketが偉い」というより、AIの性能改善がモデル単体からシステム全体へ移ってきた象徴 だと感じました。
この視点はかなり大事です。AIはもう、モデルの賢さだけでなく、インフラ・通信・オーケストレーションまで含めて“製品”なんですよね。
OpenAIはこの機能を alpha として、まず選ばれたパートナーに提供しました。
その中には Codex も含まれていて、Codexはすでに Responses APIトラフィックの大半をWebSocketモードに移行 しているとのことです。
つまり、これは実験室だけの話ではなく、本番でも使われ始めている ということ。
こういうのは、単なる「発表」よりずっと重みがあります。プロダクトに入っているなら、少なくともOpenAI自身は「これはいける」と見ているわけですから。
今回の更新は、AIの応答をちょっと速くする小手先の改善ではありません。
“エージェントが何度もやり取りしながら動く” という現代的なAIの使い方に、通信レイヤーから本気で最適化をかけた という話です。
しかも、効果が最大40%というのはかなり大きい。
AIプロダクトは見た目には派手でも、実際に勝敗を分けるのはこういう基盤の差だったりします。私はこの方向性、かなり本命だと思います。
これからのAI開発は、「賢いモデルを呼ぶ」だけではなく、どうつなぎ、どう流し、どう待ち時間を減らすか がますます重要になっていきそうです。
参考: OpenAI Introduces Websocket-Based Execution Mode to Reduce Latency in Agentic Workflows
