--- title: "マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】" url: "https://www.issoh.co.jp/tech/details/13600/" published: 2026-07-13 updated: 2026-10-12 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】 マルチエージェントオーケストレーションとは、複数のLLMエージェントのうち「次にどれを動かすか」「何を渡すか」「いつ終えるか」を決める制御層のことです。調査・執筆・検証のように役割を分けたエージェントを並べただけでは仕事は終わりません。順序と委譲と終了条件を誰が決めるかを設計して、はじめて1つの業務として回ります。 この記事では、Microsoft Agent Frameworkが公式に定義する5パターン、OpenAI Agents SDKのドキュメントが区別する「LLM主導」と「コード主導」の違い、主要フレームワークのオーケストレーション機能と2026年10月9日時点の版を整理します。そのうえで、再試行・タイムアウト・打ち切りを入れたオーケストレーターの最小実装を、実行結果つきで示します。 ## まとめ：オーケストレーションの要点（2026年10月時点） - オーケストレーションの中身は、実行順・委譲先・受け渡す文脈・終了条件の4つを決める制御です。各エージェントの性能だけでなく、この4つの設計も結果と費用を左右します。 - 制御の主体は2通りあります。LLMに次の手を選ばせる「LLM主導」と、アプリのコードで流れを固定する「コード主導」です。OpenAIは後者について、速度・コスト・性能の面で挙動がより決定論的になり、予測しやすいと説明しています。 - 定番の型は逐次（Sequential）・並行（Concurrent）・ハンドオフ（Handoff）・グループチャット（Group Chat）・Magenticの5つです。Microsoft Agent Frameworkはこの5つをビルダーとして提供しています。 - AutoGenはメンテナンスモードに入り、新機能は追加されません。新規に組むならMicrosoft Agent Framework、OpenAI Agents SDK、LangGraph、CrewAIから選びます。 - 本番で詰まりやすいのは、終了条件の欠落による往復の暴走、ハンドオフで会話履歴が丸ごと渡ることによるトークン増、どのエージェントが判断したか追えないことの3点です。 - 削除・送金・本番反映のような副作用のある操作の順序は、LLM主導に任せずコードで固定してください。 ## マルチエージェントオーケストレーションの定義と制御層の役割 マルチエージェントは「複数のエージェントで構成されたシステム」という構成の話です。オーケストレーションは、その構成を動かす制御の話になります。構成の全体像や役割分担の考え方は[マルチエージェントとは？仕組み・構成パターンと採用判断](/tech/details/13604/)で扱っているので、ここでは制御層に絞ります。 制御層が決めることは4つです。どのエージェントをどの順で動かすか（実行順）、どの担当に任せるか（委譲先）、前の結果や会話履歴をどこまで渡すか（文脈）、何を満たしたら止めるか（終了条件）。この4つのうち1つでも暗黙のままにすると、同じ担当の間で依頼が往復し続けたり、必要な前提を持たない担当が誤った結論を返したりします。 ### LLM主導とコード主導の2つの制御方式 [OpenAI Agents SDKのドキュメント](https://openai.github.io/openai-agents-python/multi%5Fagent/)は、オーケストレーションを2方式に分けています。1つはLLMに計画・推論させて次の手順を決めさせる方式（Orchestrating via LLM）、もう1つは「determining the flow of agents via your code」、つまりコードでエージェントの流れを決める方式です。後者について同ドキュメントは「more deterministic and predictable, in terms of speed, cost and performance」と書いています。 | 観点 | LLM主導 | コード主導 | | ---------- | -------------- | -------------- | | 次の担当を決めるもの | オーケストレーターのLLM | if文・ループ・グラフ定義 | | 向く業務 | 手順を事前に書けない調査 | 手順が決まっている定型処理 | | LLM呼び出し回数 | モデルの判断と実行上限に依存 | 分岐・反復・再試行に依存 | | 制御経路のテスト | モデルの選択を含めて評価 | 分岐・反復条件を検証 | | 主な失敗 | 堂々巡り・担当の取り違え | 想定外の入力で分岐が足りない | 実務では二者択一にしません。外枠の工程はコードで固定し、「どの専門家に聞くか」のように判断が要る一部だけをLLMに選ばせる組み合わせが扱いやすい構成です。同ドキュメントも両方式を組み合わせられると明記しています。 ## 主要5パターンの動き方と向く業務 パターンの名前はベンダーごとに少しずつ違うため、本記事では[Microsoft Agent Frameworkの公式ドキュメント](https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/)が組み込みのオーケストレーションとして挙げる次の5つを基準にします。 | パターン | 公式の定義（要約） | 制御の主体 | 向く業務 | | -------------- | ---------------- | ----------- | ----------- | | Sequential（逐次） | 定めた順に1体ずつ実行 | コード | 抽出→整形→検証 | | Concurrent（並行） | 複数体を並列に実行 | コード | 独立した複数観点の調査 | | Handoff | 文脈に応じて互いに制御を移譲 | 各エージェントのLLM | 問い合わせの振り分け | | Group Chat | 共有の会話の中で協働 | マネージャー | 草案と批評の反復 | | Magentic | マネージャーが専門体を動的に調整 | マネージャーのLLM | 手順が未知の複雑な課題 | Anthropicはこれとは別の切り口で、Orchestrator-Subagent・Generator-Verifierなど5つの協調パターンを公開しています。その選び方は[Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方](/tech/details/12108/)で解説しています。LangChainのドキュメントもSubagents・Handoffs・Skills・Router・Custom workflowの5つに分けています。比較では「誰が次を決めるか」「並行か逐次か」に加え、文脈の共有範囲と、どのエージェントが利用者に直接応答するかも確認します。 ### 逐次と並行：コードで順序を固定できる2パターン 逐次は前段の出力を次段の入力にする直列の流れ、並行は同じ入力を複数のエージェントに同時に渡して結果を集める流れです。どちらも担当の実行順がコードで決まり流れを追いやすいので、最初に組むならこの2つです。ただし、LLM呼び出し回数と費用を見積もるには、実行順に加えて各担当の内部ループ・再試行回数・入出力トークン数の条件も必要です。並行の所要時間は一番遅い担当で決まり、再試行が入るとその分だけ延びます。後述の実装例では、初回に失敗した担当の再試行で並行区間が0.3秒から0.6秒に延びています。 ### ハンドオフ：会話の主導権ごと専門エージェントへ移す方式 ハンドオフは、受付役が専門の担当へ会話そのものを引き渡す方式です。OpenAI Agents SDKのドキュメントでは、引き継いだ専門エージェントがそのターンの残りを担う「active agent」になると説明しています。似た仕組みに、親エージェントが主導権を持ったまま子エージェントを道具として呼ぶ `Agent.as_tool()` があります。最終回答を1か所でまとめたいならas\_tool、窓口ごと担当を替えたいならハンドオフを選びます。両者の書き方はOpenAI Agents SDKの使い方｜handoff・as\_tool・ガードレールで、実行結果つきで比べています。 注意点は、引き継ぎ先に渡る文脈の量です。同SDKのハンドオフは既定で、新しいエージェントがそれまでの会話履歴をすべて見る挙動になっています。担当を何度も替える構成では履歴が伸び続けるので、`input_filter` で渡す項目を絞ります。 ### グループチャットとMagentic：マネージャーが次の手を決める方式 グループチャットは、複数のエージェントが1つの会話を共有し、マネージャーが次の発言者を選ぶ方式です。草案を書く担当と批評する担当を交互に回すような反復に向きます。Magenticは、AutoGenのMagentic-Oneを基に設計された方式で、マネージャーが計画を立て、進捗台帳（progress ledger）で「要求を満たしたか」「同じ所を回っていないか」を毎ラウンド判定しながら、次に動かす専門エージェントを選びます。手順を事前に書けない課題を扱える一方で、LLM呼び出しの回数が実行ごとに変わり、費用の上限を見積もりにくくなります。Microsoft Agent FrameworkのPython版 `MagenticBuilder` が `max_round_count`（最大ラウンド数）・`max_stall_count`（進捗が止まったと見なすまでの回数）・`max_reset_count`（計画の作り直し回数）を受け取るのはこのためで、どちらの型でも上限は必ず指定してください。 ## フレームワーク別のオーケストレーション機能と2026年10月時点の版 同じパターンでも、フレームワークによって組み込みで用意されているか、自分で書くかが違います。版と公開日は2026年10月9日に[PyPI](https://pypi.org/)の各パッケージの公開履歴と[Microsoft Agent FrameworkのGitHub Releases](https://github.com/microsoft/agent-framework/releases)で確認した値です。 | フレームワーク | 最新版（公開日） | オーケストレーションの提供形態 | 注意点 | | ------------------------- | ------------------------------------- | ----------------------- | ---------------------- | | Microsoft Agent Framework | Python 1.21.0（10/8）・.NET 1.24.0（10/7） | 5パターンのビルダー | Pythonは別パッケージ | | OpenAI Agents SDK | 0.23.1（10/2） | handoffs・as\_tool | max\_turns既定10 | | LangGraph | 1.2.14（10/6） | グラフで自分で組む | supervisorライブラリは非推奨 | | CrewAI | 1.15.26（10/8） | sequential・hierarchical | hierarchicalはmanager必須 | | AutoGen | autogen-agentchat 0.7.5（2025/9/30） | GroupChat系 | メンテナンスモード | Microsoft Agent Frameworkは2026年4月2日に1.0がGAになりました。PythonではオーケストレーションのビルダーがPyPIの別パッケージ `agent-framework-orchestrations` に分かれており、こちらの1.0.0は2026年6月18日公開と本体より遅れています。本体の位置づけは[Microsoft Agent Framework 1.0とは](/tech/details/11675/)で整理しています。 LangGraphには中央のsupervisorが担当を振り分ける構成を作る `langgraph-supervisor` がありますが、そのREADMEは「多くの用途ではライブラリでなくツール呼び出しでsupervisorパターンを直接組むこと」を推奨しており、GitHubのリポジトリはアーカイブ済み（読み取り専用）です。新しく組むならグラフとツールで自分で書きます。手順は[LangGraphでAIエージェントを実装する手順](/tech/details/17447/)にあります。 CrewAIのProcessはsequentialとhierarchicalの2種類で、hierarchicalを使うにはマネージャー用のモデル（`manager_llm`）か独自のマネージャーエージェント（`manager_agent`）の指定が必要です（[CrewAIとは？Agent・Task・Crewの仕組み](/tech/details/13598/)）。AutoGenはREADMEで「maintenance mode」と明記し、新機能や機能強化を受けないこと、新規利用者にはMicrosoft Agent Frameworkを勧めることを掲げています。既存のAutoGen資産をどう扱うかは[AutoGenとは？Microsoftのマルチエージェント基盤の現在地](/tech/details/5020/)を参照してください。8種のフレームワークを動作コードつきで比べたい場合は[AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準](/tech/details/15367/)が向いています。 ## コードで組むオーケストレーターの最小実装 フレームワークが隠している制御を、標準ライブラリだけで書くと次のようになります。専門エージェントはLLMを呼ぶ代わりに挙動だけを模したスタブで、調査担当の1体は初回だけ出力形式の誤りで失敗するようにしてあります。オーケストレーター側は、並行での調査、担当ごとのタイムアウトと再試行、執筆と検証の反復、反復回数の上限による打ち切りを受け持ちます。 ``` import asyncio import time # --- 専門エージェント（実際はLLM呼び出し。ここでは挙動だけ模したスタブ） calls = {"market": 0} async def market_agent(task): calls["market"] += 1 await asyncio.sleep(0.3) if calls["market"] == 1: raise ValueError("出力がJSONスキーマに合わない") # 初回だけ失敗させる return "市場規模の要点" async def competitor_agent(task): await asyncio.sleep(0.3) return "競合3社の要点" async def writer_agent(task): return f"草案（{task}）" async def reviewer_agent(draft): return "OK" if "修正2" in draft else "NG: 根拠不足" AGENTS = {"market": market_agent, "competitor": competitor_agent, "writer": writer_agent, "reviewer": reviewer_agent} # --- オーケストレーター（制御はすべてコード側が持つ） async def call(name, payload, trace, timeout=2.0, retries=1): for attempt in range(retries + 1): t0 = time.perf_counter() try: out = await asyncio.wait_for(AGENTS[name](payload), timeout) trace.append(f"{name} try={attempt} ok {time.perf_counter() - t0:.1f}s") return out except (asyncio.TimeoutError, ValueError) as e: trace.append(f"{name} try={attempt} {type(e).__name__}") raise RuntimeError(f"{name} が再試行上限に達した") async def orchestrate(goal, max_rounds=3): trace = [] # 1) 並列：独立した調査を同時に投げる t0 = time.perf_counter() market, comp = await asyncio.gather(call("market", goal, trace), call("competitor", goal, trace)) trace.append(f"parallel {time.perf_counter() - t0:.1f}s") # 2) 逐次＋検証ループ：レビューが通るまで最大max_rounds回 note = f"{market}/{comp}" for i in range(max_rounds): draft = await call("writer", f"{note} 修正{i}", trace) verdict = await call("reviewer", draft, trace) if verdict == "OK": return draft, trace note += f" | {verdict}" return None, trace + ["打ち切り：人の確認へ回す"] draft, trace = asyncio.run(orchestrate("新規事業の市場調査")) print(draft) print("\n".join(trace)) ``` Python 3.9.6で実行した出力の先頭は次のとおりです（以降は執筆と検証の行が交互に3回ずつ続きます）。 ``` 草案（市場規模の要点/競合3社の要点 | NG: 根拠不足 | NG: 根拠不足 修正2） market try=0 ValueError competitor try=0 ok 0.3s market try=1 ok 0.3s parallel 0.6s ``` 読み取るべき点は3つあります。1つ目は、並行区間が再試行を含む最も遅い担当の完了を待つため、0.6秒になったことです。担当ごとのタイムアウトは通常時の所要時間と業務の締切から決め、短すぎる設定による不要な再試行を避けます。2つ目は、検証担当の「NG: 根拠不足」を次の依頼に付け足して渡していることです。差し戻し理由を渡さないと、執筆担当は同じ草案を繰り返します。3つ目は打ち切りで、`max_rounds=2` にして実行すると戻り値は `None` になり、トレースの末尾に「打ち切り：人の確認へ回す」が残ります。この例の打ち切り処理は、検証ループの上限でNoneとログを返すところまでです。人への通知や確認待ち状態の保存は別途実装し、担当呼び出しの再試行上限で発生するRuntimeErrorも呼び出し元で処理します。 このコードの `call()` がフレームワークの実行ランタイムに、`orchestrate()` がSequentialやConcurrentのビルダーに相当します。LLM主導に切り替える場合は、`orchestrate()` の中の固定順序を、オーケストレーターのLLMが次の担当名を返す処理に置き換えます。単体エージェントの内側で回るループの設計は[エージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計](/tech/details/13602/)、どの粒度で担当に分けるかは[タスク分解とは？AIエージェントの分解粒度・3手法・妥当性検証](/tech/details/16330/)で扱っています。 ## 本番運用で詰まる論点：終了条件・渡す文脈・トレース 本番運用に向けて、ここでは終了条件・受け渡す文脈・トレースの3点を確認します。 ### 終了条件と最大ターン数の設定 OpenAI Agents SDKの `Runner.run` は `max_turns` の既定値が10で（v0.23.1のソースで `DEFAULT_MAX_TURNS = 10`）、超えると例外で止まります。止まること自体は安全側の挙動ですが、上限に達したときに何を返すかを決めていないと、利用者にはただのエラーとして見えます。グループチャットやMagenticのようにマネージャーが次の手を決める型では、ラウンド数の上限に加えて「検証担当がOKを出したら終了」のような完了条件をコードで判定してください。LLMの「完了しました」という発言だけを終了条件にすると、早すぎる終了と終わらない議論の両方が起きます。 ### エージェント間で渡す文脈の量 各段で履歴が追加され、その全体を次段へ渡す構成では、後段ほど入力トークンが増えます。総費用と遅延への影響は、履歴の増加量・モデル・キャッシュの利用状況などによって変わります。前段の結論だけを構造化して渡す、ハンドオフでは `input_filter` でツール呼び出しの履歴を落とす、共有したい事実は会話とは別の状態（グラフのstateや外部ストア）に置く、のいずれかで渡す量を抑えます。記憶の持たせ方は[エージェントメモリとは？短期記憶と長期記憶の設計・実装判断](/tech/details/16053/)が参考になります。 ### どのエージェントが何を判断したかのトレース 最終出力が誤っていたとき、どの担当の出力が原因かを追えなければ直せません。先の実装例で `trace` に担当名・試行回数・所要時間を残したのはこのためです。フレームワークを使う場合も、委譲・ツール呼び出し・再試行を1本の実行単位で記録できるトレース基盤をPoCの段階から入れておきます。LangSmithでの設定は[LangSmithとは？トレース送信の設定・評価の実行・料金](/tech/details/17585/)、記録した軌跡を評価する方法は[AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標](/tech/details/15942/)にまとめています。 ## オーケストレーションを入れない判断とLLM主導を避ける場面 1つのプロンプトとツール数本で片づく処理に、オーケストレーターを足す理由はありません。担当を分けるたびにLLM呼び出しと受け渡しが増え、遅延・費用・検証の手間が積み上がります。単体と複数の分かれ目は[シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード](/tech/details/4261/)で詳しく扱っています。 複数に分けると決めた場合でも、LLM主導を選ぶべきでない場面ははっきりしています。 - 削除・送金・本番環境への反映など、取り消せない操作を含む業務。実行順と承認の位置はコードで固定し、LLMには中身の生成だけを任せます。 - 1件あたりの費用や応答時間に厳しい上限がある業務。LLM主導でも外側のコードで回数は制限できますが、上限を守るにはトークン予算・ツール費用・締切と中断処理まで設計する必要があり、コード主導の方が少ない手間で収まります。 - 監査で「なぜその順で処理したか」を説明する必要がある業務。コード主導なら分岐条件をそのまま説明に使えます。 逆に、調べる範囲が事前に決まらない調査や、問い合わせ内容で担当が変わる窓口業務は、LLM主導の型が生きる場面です。どの工程をコードで固定し、どこをエージェントに委ねるかの切り分けに迷う場合は、[AIエンジン開発の支援](/service/ai/recommend/)で業務の棚卸しから相談できます。 ## よくある質問 ### LLMオーケストレーションとマルチエージェントオーケストレーションは違いますか？ LLMオーケストレーションは、LLM呼び出し・検索・ツール実行などを順につなぐ処理全般を指す広い言葉です。マルチエージェントオーケストレーションはその一部で、自分で判断してツールを使う複数のエージェントの実行順・委譲・終了を制御するものを指します。 ### マルチエージェントのオーケストレーターは何をしますか？ 要求をサブタスクに分け、どの専門エージェントに任せるかを決め、結果を集めて検証し、終了か差し戻しかを判断します。オーケストレーター自体をLLMにするか、コード（ループやグラフ定義）にするかは設計次第で、手順が決まっている業務ではコードにした方が費用と結果が安定します。 ### ハンドオフとエージェントのツール化はどう使い分けますか？ 担当そのものを替えて以降の応答を任せたいならハンドオフ、親が主導権を持ったまま専門エージェントに部分作業だけ頼みたいならツール化（OpenAI Agents SDKの `as_tool`）を使います。最終回答の文体や責任を1か所にまとめたい場合はツール化が向いています。 ### AutoGenで組んだオーケストレーションは使い続けられますか？ 動作はしますが、AutoGenはメンテナンスモードで新機能や機能強化は入りません。新規の開発は、MicrosoftがAutoGenの後継と位置づけるMicrosoft Agent Frameworkか、ほかのフレームワークで始めるのが無難です。 ### オーケストレーションとワークフローエンジンの違いは何ですか？ 対立する仕組みではありません。ワークフローエンジンは定義した手順を確実に実行する実行基盤で、マルチエージェントオーケストレーションは複数エージェントの協調をどう制御するかという設計の対象です。Microsoft Agent Frameworkもオーケストレーションをワークフロー機能の上に実装しており、ワークフローの中でエージェントに分岐を判断させる構成も取れます。 ## 関連記事 - [マルチエージェントとは？仕組み・構成パターンと採用判断を実装者視点で解説【2026年版】](/tech/details/13604/) - [Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】](/tech/details/12108/) - [AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準【2026年9月版】](/tech/details/15367/) - [シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】](/tech/details/4261/) --- 出典: [マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】]()（株式会社一創）