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

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

概要

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

しかし、まずは冷水を浴びせましょう。⁠多くのタスクにマルチエージェントは不要です。 単一エージェント＋適切なツールセットで解決できることに、マルチエージェントを持ち込むべきではありません。マルチエージェントは、調整オーバーヘッド、コンテキスト同期のコスト、およびデバッグの複雑さを導入します。まず便益を確認してください（判断基準は エージェント・ループ の「ワークフロー 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ファイルの生データで埋め尽くされることはありません——これは コンテキストエンジニアリング の「ウィンドウを溢れさせない、中間部分を希釈させない」という原則に直接対応しています。これが、マルチエージェントが「単一エージェントがすべてを読む」アプローチに対して持つ最大の利点です。
• 並列ファンアウト⁠：独立したサブタスクを同時に実行し、ウォールクロック時間を「直列処理の合計」から「最も遅い1つの処理時間」まで短縮します。
• コスト削減（かつキャッシュを破壊しない）：サブタスクはより安価なモデルで実行できます。ただし、プロンプト・キャッシュ には厳格な制約があります。⁠同じループ内で途中でモデルを変更すると、セグメント全体のキャッシュが無効になります⁠（キャッシュはモデルごとにバケット分けされます）。正しい方法は、⁠別のサブエージェントを立ち上げて安価なモデルを使用し、メインループでは単一モデルを維持することです——これにより、メインループのキャッシュは維持され、サブタスクのコストも削減されます。Claude Code の Explore サブエージェントが、読み取り専用の扇状検索に Haiku などの安価なモデルを使用するのは、まさにこのパターンです。

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

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