OpenAI APIOpenAI の機能

FEATURE

Multi-agent (Responses API)

Multi-agent は、Responses API のリクエストの中で、モデルがサブエージェントを起動して並行して調整し、その作業をまとめて最終回答を返す機能です。

プレビュー・先行提供公式発表と照合済み
初出2026年7月9日
ページ更新
提供状態プレビュー・先行提供
公式の記載で確認できた環境API
提供を確認できたプラン公式に記載なし
目次 CONTENTS
  1. できること
  2. 機能解説
  3. 使い方
  4. 利用シーン
  5. Claude・Anthropic の対応する機能
  6. これまでの変更
  7. 関連する機能
  8. 出典
CAN DO

できること

POINT 01

作業を並行して委任

ルートエージェントが複数のサブエージェントを起動し、作業を委任して同時に進めさせます。各サブエージェントの作業はまとめられ、最終回答として返されます。

POINT 02

調整を API 側に任せる

ルートエージェントは、サブエージェントの作成、追加情報の送信、結果の待機、最終回答の統合を行います。アプリケーション側でオーケストレーションを実装する必要はありません。

POINT 03

作業ごとに独立した文脈

各サブエージェントは範囲の決まったタスクを受け取り、自分のコンテキストを保持します。互いに関係のない作業の間で、コンテキストの干渉を抑えます。

GUIDE

機能解説

概要

ルートエージェントが複数のサブエージェントに作業を委任し、各サブエージェントは同時に作業を進めます。オーケストレーションをアプリケーション側で実装せずに、複数の作業の分担と統合を API に任せる場面に関わります。

エージェントの構成と動き

ルートエージェントの名前は /root で、起動されたサブエージェントには階層的なパスが付きます。サブエージェントはリクエストのモデルと利用可能なツールを共有し、エージェント同士は spawning (起動)、messaging (メッセージ送信)、waiting (待機) などの協調用の基本操作で連携します。ツリー内のすべてのエージェントが、API リクエストのモデル呼び出しで設定したツールを使えます。

  • Multi-agent モードを有効にすると、Responses API は 6 種類のホスト型の協調アクションを提供します。これらは multi_agent_call アイテムとして現れる場合があります。アプリケーションはこれらを実行せず、出力も送信しません。
  • 一方、ツリー内のどのエージェントも function_call を出す場合があります。アプリケーションはその呼び出しを実行し、対応する function_call_output を送信する必要があります。
  • Multi-agent の応答には、追加の出力アイテムとして multi_agent_call、multi_agent_call_output、agent_message の 3 種類が含まれる場合があります。

同時実行数の上限

max_concurrent_subagents は、エージェントツリー全体で同時に動作できるサブエージェントの最大数を設定します。この数には子・孫やさらに深い階層のサブエージェントがすべて含まれ、ルートエージェントは含まれません。

HTTP と WebSocket

HTTP と WebSocket は同じ Multi-agent の機能に対応しています。ツールを多く使うワークフローや長時間のワークフローには、WebSocket が推奨されています。

  • HTTP では、エージェントが開発者定義の関数を呼び出した場合、保留中の呼び出しをすべて実行し、その出力を含む継続リクエストを作成します。
  • WebSocket では、関数の出力が得られた時点で、実行中の応答の完了を待たずに応答へ注入できます。接続は Python の beta SDK では client.beta.responses.connect、TypeScript の beta SDK では ResponsesWS で開き、接続ヘッダーに OpenAI-Beta: responses_multi_agent=v1 を渡します。
  • WebSocket では、response.created イベントの応答 ID を保存し、その応答に送るすべての response.inject イベントに含めます。関数の結果は response.inject イベントで実行中の応答に送り、応答が完了し、すべての注入が response.inject.created または response.inject.failed を返すまで読み取りを続けます。
  • response.inject.failed が response_already_completed を返した場合は、失敗イベントで返された input を、完了した応答から続ける新しい response.create リクエストで送ります。

導入時に確認したい点

  • multi_agent.enabled を true にすると、リクエストで context_management を設定していなくても、サーバー側の自動 compaction (コンテキストの圧縮) が暗黙に有効になります。compaction はルートエージェントと各サブエージェントに個別に適用され、それぞれのコンテキストは分かれたまま保たれます。
  • Multi-agent を有効にすると、ルートエージェントとサブエージェントに、システムが指示を新しい developer message として自動で追加します。この指示は編集も削除もできません。

提供状況の注意

Multi-agent はベータとして提供されています。GPT-5.6 で Responses API 向けに追加され、GPT-6.1 Sol もベータで対応しています。対象プランについては、公式のリリースノートには記載がありません。

HOW TO USE

使い方

HTTP リクエストで Multi-agent を有効にする基本の流れです。

  1. HTTP リクエストでは client.beta.responses を使い、betas 引数に responses_multi_agent=v1 を渡します。
  2. Responses API のリクエストで multi_agent.enabled を true に設定し、Multi-agent を有効にします。
  3. developer message を追加し、ルートのモデルがどのような場合にサブエージェントを起動するかを調整します。
公式ヘルプを開く ↗
USE CASES

利用シーン

CASE 01

互いに関係のない複数の調査や作業を分担させ、結果を 1 つの回答にまとめる場面に向いています。

CASE 02

作業ごとにコンテキストを分けて進めたい処理を、1 回の Responses API リクエストで扱う場面に使えます。

CASE 03

アプリケーション側でエージェント間の調整ロジックを持たずに、作業の委任と統合を組み込みたい場面に向いています。

CASE 04

開発者定義の関数を多く呼び出す長時間のワークフローを、WebSocket で動かす場面に使えます。

COMPARISON

Claude・Anthropic の対応する機能

比較の単位となる業務: API リクエスト内でのサブエージェントへの作業委任 (マルチエージェントオーケストレーション)

Claude Managed Agents でも、Multiagent orchestration が標準の managed-agents-2026-04-01 ベータヘッダーのもとでベータ提供です。Claude Managed Agents では、エージェントの作成、コンテナの設定、セッションの実行を API を通じて行います。

Multi-agent は、Responses API のリクエストの中で multi_agent.enabled を指定して有効にし、HTTP では betas 引数に responses_multi_agent=v1 を渡します。どちらもベータとして、専用のベータ指定を付けて使う形です。

TIMELINE

これまでの変更

  1. GPT-6.1 Sol も Multi-agent にベータで対応しました。あわせて、Responses API のリクエスト内でモデルにサブエージェントへ作業を委任させる機能として案内されています。

  2. GPT-5.6 で、Responses API 向けのマルチエージェントオーケストレーションがベータとして追加されました。

SOURCES

出典

出典 4 件を表示