OpenAI Responses API に非同期ツール呼び出し・ターン途中ステアリング・推論強度の途中変更が追加

要約

OpenAI は 2026-09-03、フラッグシップモデル GPT-6 Astra の公開と同じタイミングで、Responses API に3つの新機能を追加しました。モデルの話題に隠れがちですが、こちらは API でエージェントを組んでいる開発者にとって、実装の前提が変わる種類の変更です。

追加されたのは、非同期ツール呼び出し（async tool calling）、ターン途中ステアリング（mid-turn steering）、推論強度の会話途中変更の3点です。共通しているのは「1ターンの中でモデルを止めない・やり直させない」という方向性です。これまでのツール呼び出しは、モデルがツールを呼んだらそこでターンが止まり、アプリケーションが結果を返すまで何も進みませんでした。ユーザーが途中で方針を変えたければ、レスポンスが終わるのを待ってから次のターンで指示し直すしかありませんでした。推論強度を変えたければプロンプトを組み直すことになり、プロンプトキャッシュが効かなくなっていました。

3つの機能は、それぞれこの3つの「待ち」を外します。遅いツールを待つ間もモデルが別の作業を進められる、実行中のレスポンスへ後から要件を追加できる、難所だけ推論を厚くしてもキャッシュが生きたまま、という状態になります。エージェントの体感速度とトークンコストの両方に効く変更です。

なお ターン途中ステアリングは GPT-6 Astra 専用で、GPT-5.6 以前のモデルでは使えません。非同期ツール呼び出しと推論強度の途中変更については、公式のモデルガイドが Astra の「What’s new」として説明しています。3つとも公式ドキュメントに個別ガイドが用意されており、サンプルコードもそこで確認できます。

何が変わったか

1. 非同期ツール呼び出し（async tool calling）

• 関数ツール／カスタムツールの定義に async: true を付けると、モデルはそのツールの結果を待たずに推論を継続する
• 継続中にモデルは、別のツールを呼ぶ・リクエストのうち独立した部分に答える、といった作業を進められる
• ツールを実行するのは従来どおりアプリケーション側。OpenAI 側がバックグラウンドジョブを預かるわけではない
• 結果は後続の Responses リクエストで、元の call_id に紐づけて返す。関数ツールは function_call → function_call_output、カスタムツールは custom_tool_call → custom_tool_call_output
• レスポンス生成そのものを非同期化する Background mode とは別物である点に注意

2. ターン途中ステアリング（mid-turn steering）

• gpt-6-astra + WebSocket 接続（wss://api.openai.com/v1/responses）限定の機能。GPT-5.6 以前は非対応
• response.create の実行中に、そのレスポンス ID を previous_response_id に指定した response.steer イベントを送ると、追加指示を差し込める
• イベントが受け付けるのは type / previous_response_id / input の3つのみ
• API は response.steer.accepted を返すが、これはキューに入ったという意味であって、モデルが反映したという意味ではない
• サーバーは実行中の出力アイテムとホストツールの処理を終えてから、自動的に継続レスポンスを生成する。クライアント側から response.create を再送してはいけない
• ステアリングが元のレスポンスを中断した場合、そのレスポンスは response.incomplete かつ incomplete_details.reason: "steered" で終わる
• すでに送出された出力の巻き戻し、実行済みアクションの取り消し、開始済みツールのキャンセルはできない
• 自動継続は元のリクエスト設定を引き継ぐ。トークン上限とツール呼び出し上限はレスポンスごとに個別適用される

3. 推論強度の会話途中変更

• configuration_update 入力アイテムを追加すると、元のプロンプト接頭辞を書き換えずに reasoning_effort を変更できる
• プロンプトキャッシュを維持したまま、難所で推論を厚くし、定型的な追い質問では薄くする、という運用ができる
• 設定は次の configuration_update が上書きするまで持続する

4. GPT-6 Astra 側の制約（あわせて明記されたもの）

• none の推論強度は非対応
• EU データレジデンシー環境では Fast mode が使えない
• 強化された安全策の一環として、misalignment monitoring（非同期の逸脱監視とアラート）が動作する
• ツール呼び出しは Chat Completions ではなく Responses API が前提

業務インパクト（一般企業向け）

エージェント基盤を内製している企業には、設計の見直し材料が3つ同時に来た形です。

非同期ツール呼び出しが効くのは、社内システムへの問い合わせが遅いケースです。基幹システムの照会、社内検索、承認待ちを含むワークフローなど、数秒から数十秒かかるツールをエージェントから呼んでいる場合、これまではその間モデルが完全に止まっていました。async: true を付ければ、遅い照会を先に投げつつ、独立した部分の回答を先に組み立てられます。ユーザーから見た「無言の待ち時間」が短くなります。ただしジョブ管理はアプリケーション側の責任のままなので、タイムアウト・リトライ・結果の突き合わせ（call_id の管理）は自前で設計する必要があります。ここを曖昧にすると、結果が返らないままターンが進む事故になります。

ターン途中ステアリングは、人が監督につくエージェント運用で意味を持ちます。長時間動くタスクに対して、途中で「その方向ではない」と割り込める設計は、実務では「全部やり直し」を減らします。一方で運用設計上の注意も明確です。response.steer.accepted は受理通知にすぎず、反映保証ではありません。そしてすでに実行されたアクションは取り消せません。外部システムへの書き込みを伴うエージェントでは、「ステアリングで止められる」と誤解した設計は危険です。取り消せない操作の前には、従来どおり承認ステップを置く必要があります。加えて WebSocket 前提なので、HTTP しか通していないネットワーク構成では、情シス側にファイアウォール・プロキシの見直しが発生します。

推論強度の途中変更は、コスト管理に直接効きます。従来はプロンプトを組み直すたびにキャッシュが切れ、入力トークンの単価優遇を失っていました。configuration_update なら接頭辞を保ったまま強度だけ動かせるため、「長い社内文書をコンテキストに載せた状態で、難しい判断のときだけ推論を厚くする」という運用が現実的になります。社内の AI 利用コストを見ている部門にとっては、モデルを乗り換えるより先に検討すべき最適化です。

**ガバナンス面では、none 非対応と EU データレジデンシーでの Fast mode 非対応の2点が具体的な制約になります。**EU 拠点を含むグローバル運用では、リージョンによって使える処理モードが違う状態になるため、リージョンごとの構成差を運用ドキュメントに明記しておく必要があります。

副業・個人活用視点

個人開発のエージェントでも、体感速度とコストの効き方が大きい変更です。

副業でチャットボットや業務自動化ツールを受託している場合、クライアントが最も不満を口にするのは「反応が遅い」です。非同期ツール呼び出しは、外部 API（天気、在庫、スクレイピング結果など）を待つ構成でそのまま効きます。コードの変更はツール定義に async: true を足し、結果を call_id で後から返す形に直すだけなので、既存実装への導入コストが低いのも利点です。

推論強度の途中変更は、個人の API 予算管理に直結します。長いコンテキストを毎回積む使い方（社内マニュアル QA、コードベース質問など）では、キャッシュが効くかどうかで月額が数倍変わります。「重い作業だけ強度を上げ、普段は低強度」という運用をキャッシュを壊さずにできるようになったのは、個人規模ほど恩恵が大きい変更です。

ターン途中ステアリングは WebSocket が必要なぶん実装のハードルが上がるので、まずは非同期ツール呼び出しと configuration_update の2つから触るのが現実的です。この2つは HTTP のままで導入できます。逆に、「実行中のエージェントに割り込める UI」は差別化しやすい機能でもあるので、受託案件の提案材料としては、WebSocket 対応を含めた見積もりを作っておく価値があります。

なお、これらはGPT-6 Astra の提供が自分のアカウントに来ているかどうかとは別の話です。ステアリングは Astra 専用のため、Astra が使えるまでは試せません。提供状況を確認したうえで着手してください。