エージェントオーケストレーションとは？マルチエージェントとの違いは「分けたあとの制御」｜実行順序・受け渡し・停止・監視の実装
複数のAIエージェントに役割を分けて動かす「マルチエージェント」という構成について、すでに聞いたことがあるかもしれません。
そこで次に出てくるのが、実際に動かすときの疑問です。誰がどの順で動くのか、あるエージェントの結果は次のエージェントにどう渡るのか、途中で失敗したらどうなるのか。
この記事では、複数のエージェントに分けたあとの「制御」の部分を、誰が次に動くかの決め方、結果の受け渡し方、失敗や無限ループの止め方、監視すべきものという4つの観点から、主要フレームワークの公式ドキュメントの記述で整理します。
「分ける」のはマルチエージェント、「分けたあとどう動かすか」がオーケストレーションと考えると整理しやすくなります！
この記事の監修者
AIリスキル株式会社 代表取締役
AIツールギャラリーを運営するAIリスキル株式会社の代表取締役。企業・自治体向けの生成AI研修とAI導入支援を手がけています。
実績: 大阪・関西万博 公式プログラム「AI HEROES COLLECTION」司会進行 / 神戸市デジタル人材育成エコシステム構築事業の運営 / MBS「せやねん!」「よんチャンTV」に生成AIの専門家として出演 / Felo日本初コアアンバサダー / Genspark第1期公式アンバサダー / Skywork公式アンバサダー / AKOOL公式パートナー など
エージェントオーケストレーションは、その構成を分けたあとに必要になる制御の部分を指す言葉です。
具体的には、誰がどの順で動くか、あるエージェントの結果を次のエージェントにどう渡すか、失敗や無限ループをどう止めるか、動作をどう監視するかという4つです。
「なぜ複数に分けるのか」「単一エージェントとの違い」といった構成そのものの話は、マルチエージェントの記事に譲り、この記事では扱いません。
誰が次に動くかを決める2つの方法：コードで固定するかLLMに委ねるか
OpenAI Agents SDKのドキュメントは、複数エージェントの制御方法を大きく2つに分けています。
1つは、LLM自身に次のエージェントを判断させる方法です。もう1つは、コードであらかじめ流れを決めておく方法です。
同ドキュメントは、コードで決める方法を、速度・コスト・性能の面で「より決定的で予測しやすい」としています。
Google ADKのWorkflow Agentsも同じ考え方に立っています。実行順をモデルの判断に任せず、あらかじめ決まったロジックで動かすことで、決定的で予測可能な実行パターンを作る仕組みだと説明されています。
この「誰が次に動くかを決める方法」は、AIワークフローで扱った「手順を先に人が決めるか、AIがそのつど決めるか」という軸とは別の、より狭い話です。
すでに複数のエージェントに分かれていることを前提に、そのエージェント間の制御をコードで固定するかLLMに委ねるかという選択にあたります。
結果の受け渡し方：パイプライン型とhandoff型
結果の受け渡し方には、いくつか代表的な型があります。
1つはパイプライン型です。Google ADKのSequentialAgentは、渡されたサブエージェントを順番どおりに実行し、前段の出力を後段が参照できるようにします。
同ドキュメントの例では、コードを書く担当・レビューする担当・書き直す担当という3つのエージェントに、それぞれ結果を渡しながら順番に処理させています。
もう1つはhandoff型です。OpenAI Agents SDKのhandoffsは、あるエージェントが会話そのものを別のエージェントに委譲する仕組みです。
同ドキュメントによると、handoffが起きると新しいエージェントがそれまでの会話履歴を引き継ぎ、以降の会話の主体になります。渡す範囲を絞る設定も用意されています。
どちらも代表的な型の例であり、これ以外の受け渡し方を排除するものではありません。
なお、複数のエージェントを同時に走らせる並列実行では、状態は自動的には共有されません。Google ADKのParallelAgentのドキュメントは、ブランチ間でのデータ共有が必要な場合は開発者が明示的に実装する必要があると明記しています。
失敗や無限ループをどう止めるか
ここは実装する上で見落としやすいところです。
Google ADKのLoopAgentのドキュメントは、LoopAgent自体はいつループを止めるかを判断しないとはっきり書いています。無限ループを防ぐ終了条件は、実装者が自分で用意する必要があるという明記です。
終了条件の実装例として、回数の上限（max_iterationsパラメータ）を設定する方法と、サブエージェントが条件を判定してループの終了を要求する方法が挙げられています。
失敗した処理の扱いについては、LangGraphのドキュメントに手がかりがあります。ある処理の途中で1つのステップが失敗しても、同じ段階で成功していた他の処理の結果はチェックポイントとして保存されており、再開時にそれらをやり直さずに済むという仕組みが説明されています。
これは「失敗した箇所から再開できる」という仕組みであって、失敗しなくなるわけではありません。Google ADKのLoopAgentでは終了条件を実装者が用意し、LangGraphで再開の仕組みを使う場合はチェックポイントの設計を実装者が行う必要があります。
何を監視すればよいか：セッション・トレース・スパン
複数のエージェントが連携して動くと、どこで何が起きているかを追う仕組みも必要になります。
Amazon Bedrock AgentCoreのドキュメントは、監視の単位を3層に分けて説明しています。
セッションは、ユーザーとエージェントの一連のやり取り全体です。トレースは、その中の1回のリクエストと応答のやり取り（他のエージェントへの呼び出しを含むこともあります）です。スパンは、トレースの中のさらに細かい処理単位です。
同ドキュメントは、監視できる指標の例として、セッション数・レイテンシ・処理時間・トークン使用量・エラー率を挙げています。
トレースには、リクエストの詳細、処理ステップの順序、ツール呼び出しの入出力、エラー情報と復旧の試みが含まれるとされています。
これはAmazon Bedrock AgentCoreという特定の製品の設計であり、監視の型がこれ1つに決まっているわけではありません。
代表的な実装パターン：Supervisor型とワークフロー型
実装パターンとしてよく紹介されるものを2つ紹介します。
1つはSupervisor型です。1体のsupervisor agentが複数のcollaborator agentを束ねる構成です。
Amazon Bedrock Agents Classicのドキュメントでは、質問の内容に応じて適切なcollaborator agentへ振り分ける例が説明されています。
この機能は**Amazon Bedrock Agents（現称Classic）**という特定世代の製品の機能です。同ドキュメントには、Classicが新規顧客の受付を終了し、既存顧客のみ利用を継続しているという注記があります（2026-09-13確認）。
もう1つはワークフロー型です。Google ADKのSequentialAgent・LoopAgent・ParallelAgentのように、決まった順序・条件でサブエージェントを実行する構成です。
どちらか一方が業界標準というわけではなく、それぞれ異なる製品・フレームワークが提供している選択肢の例です。
よくある質問
マルチエージェントとエージェントオーケストレーションは同じ言葉ですか
同じではありません。マルチエージェントは複数のエージェントに分ける「構成」を指し、エージェントオーケストレーションは分けたあとの「制御」を指す言葉です。
構成そのものの違いや向く場面はマルチエージェントで扱っています。
オーケストレーションの仕組みを入れれば、失敗しなくなりますか
なりません。Google ADKのLoopAgentのドキュメントも、終了条件は実装者が用意する必要があると明記しており、自動で止まる仕組みではありません。
LangGraphのようなチェックポイントの仕組みも、失敗した箇所から再開しやすくするものであって、失敗そのものをなくすものではありません。
人の承認を挟みたい場合はどうすればよいですか
Human-in-the-loopで扱っている、AIの処理に人の確認を挟む仕組みが該当します。オーケストレーションの流れの中に、承認を待つ地点を組み込む形になります。
まとめ
エージェントオーケストレーションとは、複数のAIエージェントに分けたあとの、実行順序・結果の受け渡し・停止・監視という制御を指す言葉です。
誰が次に動くかは、OpenAI Agents SDKではコードで固定する方法とLLMに判断させる方法があり、Google ADKのWorkflow Agentsも同じ考え方に立っています。
結果の受け渡しには、Google ADKのSequentialAgentが採る、出力を次の入力にするパイプライン型と、OpenAI Agents SDKのhandoffsが採る、会話の主体を移すhandoff型という代表的な型があります。
いずれも各SDKが提供する選択肢の例であり、これがすべて、あるいは業界標準というわけではありません。
失敗や無限ループは自動では止まりません。Google ADKのLoopAgentのドキュメントが明記しているとおり、終了条件は実装者が自分で用意する必要があります。
監視の単位としては、セッション・トレース・スパンという3層で捉える考え方がAmazon Bedrock AgentCoreのドキュメントに示されています。
エージェントオーケストレーションの実装や監視の設計についてご相談がある場合はお問い合わせはこちらからご相談ください。
この記事の出典
- Agent orchestration（OpenAI Agents SDK Documentation、2026-09-13確認）
- Handoffs（OpenAI Agents SDK Documentation、2026-09-13確認）
- Workflow agents（Google ADK Documentation、2026-09-13確認。google.github.ioからadk.devへの301リダイレクト先で取得）
- Sequential agents（Google ADK Documentation、2026-09-13確認。同上）
- Loop agents（Google ADK Documentation、2026-09-13確認。同上）
- Parallel agents（Google ADK Documentation、2026-09-13確認。同上）
- Use multi-agent collaboration with Amazon Bedrock Agents（AWS Documentation、2026-09-13確認）
- Understand observability for agentic resources in AgentCore（AWS Documentation、2026-09-13確認）
- Durable execution（LangGraph Documentation、2026-09-13確認。本文の該当記述は直接取得できず、検索結果スニペット経由で内容を確認）
この記事は役に立ちましたか？
感想は、今後の記事改善に活用します。
関連記事
責任あるAI（Responsible AI）とは？原則は1つではない｜Microsoft・Google・NISTの違いと実務チェック項目
責任あるAI（Responsible AI）とは、企業や国際機関がAIを社会に受け入れられる形で開発・提供するために掲げる原則群の総称です。Microsoft・Google・NIST・OECDが掲げる原則の違いと、AIガバナンスとの関係、実務チェック項目を一次情報から整理します。
コネクタとは？MCPとの違いと権限の範囲｜Anthropic・OpenAI・Manusの仕様で整理
コネクタとは、AIツールが外部のアプリやサービスへあらかじめ用意した接続です。最近よく聞くMCPとは何が違うのか、つなぐと自分のアカウントのどこまでアクセスされるのかを、Anthropic・OpenAI・Manusの公式ドキュメントの記述から整理します。
AIメモリとは？チャット履歴との違いは「会話をまたいで覚えるか」｜安全性は製品ごとに違う
AIメモリと呼ばれる機能は、あるチャットで得た情報を別のチャットでも参照できるようにするものです。今のやり取りを覚えているコンテキストウィンドウとは別物で、何が保存され誰が消せるかも製品ごとに異なります。OpenAI・Anthropic・Googleの公式ドキュメントの記述から整理します。
GraphRAGとは？通常のRAGとの違いは「関係をたどってつなぐ」こと｜向くデータと実装の限界
Microsoft ResearchとNeo4jの説明によれば、GraphRAGはナレッジグラフを検索の土台に使うRAGの一種です。Neo4jの説明では通常のRAGとの違いは断片を集めるだけでなく関係をたどる点で、Microsoft Researchの比較では複数の情報源をまたぐ質問に効果が示されています。実装は一つではなく、精度にも限界があることを公式資料から整理します。
次のAIツール選びへ
気になるツールを並べて、料金や特徴の違いを確認できます。