マルチエージェント オーケストレーション

単一エージェントは、コンテキストの膨張、直列処理、多岐にわたって専門性に欠けるという3つの壁にぶつかる。マルチエージェント オーケストレーションは、作業を連携するエージェントに分散する——決定論的オーケストレーション（チェーンリング/ルーティング）からエージェンティックなオーケストレーション（オーケストレーター-ワーカー）へ。中核的な利点は、コンテキストの分離と並列処理である。

概要

単一エージェント（エージェント ループ）はすべてを自分で行おうとし、3つの壁にぶつかる。⁠コンテキストの膨張⁠（1つのウィンドウに全作業を詰め込み、中間部分の情報が希釈される）、⁠直列処理⁠（ステップバイステップでしか進めず、遅い）、⁠多岐にわたって専門性に欠ける⁠（同じシステム プロンプトで探索、計画、実行、審査を兼務し、どの側面も極限まで最適化されない）。マルチエージェント オーケストレーションは、作業を複数の連携するエージェントに分散し、これらの3つの壁を突破する。

しかし、まず冷水を浴びせよう：⁠多くのタスクにマルチエージェントは必要ない。 単一エージェント＋優れたツールセットで解決できる場合は、マルチエージェントを採用すべきではない——マルチエージェントは調整オーバーヘッド、コンテキスト同期のコスト、およびデバッグの複雑さを導入する。まず便益を確認する（判断基準は エージェント ループ の「ワークフロー vs エージェント」の4つの関門：複雑さ／価値／実現可能性／エラーのコスト に同じ）、そして着手する。このページでは、どのようなオーケストレーション パターンが存在するか、それぞれが何を解決するのか、そして Claude エコシステム内でどのように実装され、どのような失敗を招く可能性があるかを明確にする。

決定論的オーケストレーションからエージェンティックなオーケストレーションへ

Anthropic の「Building Effective Agents」では、マルチパターンを簡素なものから複雑なものへと並べている。⁠重要な区別⁠：最初のいくつかはコード制御による決定論的オーケストレーション（ワークフロー）——ステップと分岐はコードでハードコードされており、各ステップでモデルを呼び出すだけである。最後の1つ（オーケストレーター-ワーカー）こそが、モデル自身が動的に作業を分解する「エージェント」的なマルチパターンである。

まず決定論的オーケストレーションを使用する。 タスクがチェーンリング/ルーティングでハードコードできる場合は、オーケストレーター-ワーカーを採用すべきではない——決定論的アプローチの方が制御可能で、キャッシュ可能、デバッグしやすい。事前に「いくつのサブタスクに分解するか、それぞれが何か」をハードコードできない場合にのみ、モデルをコーディネーターとして必要とする。

オーケストレーター-ワーカー：エージェンティックなマルチパターンの中核

flowchart TD
    O["オーケストレーター<br/>目標を理解 → 動的分解 → スケジューリング → 集約"]
    O -->|サブタスク A + 必要なコンテキスト| W1["ワーカー A<br/>独立ウィンドウ"]
    O -->|サブタスク B + 必要なコンテキスト| W2["ワーカー B<br/>独立ウィンドウ"]
    O -->|サブタスク C + 必要なコンテキスト| W3["ワーカー C<br/>独立ウィンドウ"]
    W1 -->|結果の要約| O
    W2 -->|結果の要約| O
    W3 -->|結果の要約| O
    O --> R["総合出力"]

これが有用である理由を、3つのメカニズム的観点から説明する。

• コンテキストの分離⁠：各ワーカーは独自のウィンドウを使用してサブタスクを処理し、⁠結果の要約のみをオーケストレーターに返す。メインのコンテキストは20個のファイルの生内容で埋め尽くされない——これは コンテキストエンジニアリング の「ウィンドウを溢れさせない、中間部分を希釈させない」と直接対応する。これが、「単一エージェントがすべてを読む」ことに対するマルチパターンの最大の利点である。
• 並列ファンアウト⁠：独立したサブタスクが同時に実行され、ウォールクロック時間が「直列和」から「最遅のもの」に低下する。
• コスト削減（かつキャッシュを破壊しない）：サブタスクはより安価なモデルで実行できる。ただし、プロンプト キャッシュ という制約がある：⁠同じループ内で途中でモデルを切り替えると、セグメント全体のキャッシュが無効になる⁠（キャッシュはモデルごとにバケツ分けされる）。正しい方法は、⁠別のサブエージェントを立ち上げて安価なモデルを使用し、メインループでは単一モデルを維持すること——これによりメインループのキャッシュは維持され、サブタスクのコストは削減される。Claude Code の Explore サブエージェントは、読み取り専用ファンアウト検索に Haiku などのより安価なモデルを使用するが、これがまさにこのパターンである。

Claude エコシステム内での実装

• Claude Code：Explore / サブエージェント——広範な検索や独立したサブタスクをサブエージェントに委任（一般的により安価なモデルを使用）、結果の要約をメインエージェントに返す。メインエージェントのコンテキストとキャッシュは汚染されない。
• OMC (oh-my-claudecode)：Claude Code 上で明示的なチーム オーケストレーションを行い、探索/計画/実行/審査を専門のエージェントに分散し、以下の原則を堅持する——⁠記述と審査は別のレーンで行う⁠：実行エージェントは自身を審査せず、別のレビュアー/検証者が独立したコンテキストで評価を行う。
• Managed Agents multiagent（マネージド）：⁠エージェント上で multiagent: {type: "coordinator", agents: [...]} を宣言し、委任可能な名簿を作成する。ランタイムでは、委任された各サブエージェントが独自の スレッド で実行される——コンテキスト分離されたイベント ストリームで、⁠独立したモデル/システム プロンプト/ツール/スキル を持つ。メカニズムの詳細：
  • 共有コンテナとファイルシステムを共有するが、⁠会話履歴は共有しない⁠；
  • 名簿は1〜20個のエージェントで構成され、同一エージェントの複数のコピーを生成でき、最大 25 個の並行スレッド をサポート；
  • 1層の委任のみをサポート⁠（サブエージェントの名簿はカスケードしない）；
  • スレッド間通信は agent.thread_message_sent/received を介して行われ、ツール確認などはメインスレッドに戻されて処理される。

ベストプラクティス

• 多くのタスクにマルチエージェントは必要ない。 単一エージェント＋優れたツールセットで解決できる場合はマルチエージェントを採用すべきではない。まず複雑さ／価値／実現可能性／エラーのコストの4つの関門を通過する。
• まず決定論的オーケストレーション、その後動的調整。 チェーンリング/ルーティングでハードコードできる場合はオーケストレーター-ワーカーを採用すべきではない——より制御可能で、キャッシュ可能、デバッグしやすい。
• コンテキスト分離によって便益を得る。 各ワーカーは独自のウィンドウを使用し、⁠結果の要約のみを返す。メインのコンテキストは生内容で埋め尽くされない。
• コスト削減にはサブエージェントを別途立ち上げ、メインループ内でモデルを切り替えない。 モデルの切り替えはセグメント全体のキャッシュを無効にする。Claude Code の Explore は、読み取り専用ファンアウトに安価なモデルを使用するが、これがまさにこのパターンである。
• オーケストレーターは、必要なコンテキストを委任メッセージに明示的に記載する。 スレッド間で履歴やツールは共有されないため、ワーカーは「経緯を知らない」。必要なコンテキストはメッセージに書き込むか、共有ファイルに落とし、ワーカーに読ませる。
• 記述と審査は別のレーンで行う。 実行エージェントは自身を審査せず、別のレビュアー/検証者が独立したコンテキストで評価を行う（評価と観測可能性 を参照）。

トレードオフと失敗パターン（修正方法付き）

• 過剰な委任⁠：grep/read だけで解決できるケースでもサブエージェントを起動する → 明確なガイダンスを与える：「並列または独立したワークフローの場合のみ委任する。単一ファイルの読み取りや順序操作は直接実行する。」
• 調整オーバーヘッド > 便益⁠：階層が深すぎ、往復が多すぎるため、単一エージェントよりも遅く、高価になる → 委任の深さを制御する（Managed Agents では1層のみ許可）。決定論的オーケストレーションで対応できる場合は動的調整を採用しない。
• コンテキスト非共有の罠⁠：スレッド間で履歴やツールが共有されず、ワーカーが「経緯を知らない」 → オーケストレーターは必要なコンテキストを委任メッセージに明示的に記載するか、共有ファイルに落とし、ワーカーに読ませる必要がある。
• モデル切り替えによるキャッシュ破壊⁠：コスト削減のためにメインループ内でモデルを切り替えると、キャッシュがすべて無効になり、逆に高価になる → サブエージェントで安価なモデルを隔離し、メインループでは切り替えない。
• 自己審査による背书⁠：実行エージェントが自身の作業を自己評価する → 審査は別のレーンで行う（OMC の実践、評価と観測可能性 を参照）。

参考文献

• Anthropic 公式ドキュメント⁠：「Building Effective Agents」、Managed Agents Multi-Agent (platform.claude.com)

Keywords: マルチエージェント, オーケストレーション, プロンプト チェーニング, ルーティング, 並列化, オーケストレーター-ワーカー, 評価者-最適化者, サブエージェント, Explore, コンテキスト分離, ファンアウト, プロンプト キャッシュ不変条件, モデル切り替えによる無効化, Managed Agents multiagent, コーディネーター, スレッド, スレッド間メッセージ, 1層の委任, OMC チーム, 記述 vs 審査レーン