Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】

Anthropicが2026年4月10日に公開したブログ「Multi-agent coordination patterns: Five approaches and when to use them」は、マルチエージェントの協調設計を5つのパターンに整理し、「まずOrchestrator-Subagentから始めよ」と明言しました。本記事は、その5パターンをOrchestrator-Subagent中心に読み解き、各パターンが解く問題・弱点・選定基準を、公式の記述に沿って実装者視点でまとめます。

まとめ：5パターンの早見と選定の起点

結論から示すと、迷ったらOrchestrator-Subagentから始め、実運用で詰まった箇所を観測してから他パターンへ進化させるのがAnthropic公式の推奨です。5パターンと推奨適用領域は次のとおりです。

5パターンは別々の技術というより、コンテキスト境界と情報の流れをどう制御するかという一つの軸の変奏です。まず単一エージェントで足りるかを判断し（シングルエージェントとマルチエージェントの違いで詳述）、足りない場合にこの5パターンから最小構成を選びます。マルチエージェント全体の位置づけはマルチエージェントとは？仕組み・構成パターンと採用判断を参照してください。

マルチエージェント化の分岐条件とAnthropic公式ブログの位置づけ

協調パターンを選ぶ前に、そもそも複数エージェント化すべきかを判断します。分岐の中心は、単一のコンテキストウィンドウに目的が収まるかです。一つの会話履歴で扱える情報量を超え、独立した探索・並列処理・専門分業が要るなら複数化の価値が立ちます。逆に手順が短くコンテキストに余裕があれば、複数化はトークン消費とデバッグ難度を上げるだけになりがちです。

今回のブログはCara Phillips氏らが2026年4月10日に公開したもので、前提として過去記事「Building multi-agent systems」の判断軸を引き継いでいます。登場背景は、開発チームが「高度に聞こえるアーキテクチャ」を中身より先に選んでしまう過剰設計への警鐘です。だからこそ公式は「最もシンプルなパターンから始め、詰まった箇所を観察し、必要に応じて進化させる」という運用哲学を打ち出しています。

もう一つの重要概念がcontext-centric decomposition（コンテキスト中心の分解）です。作業種別で「コードを書く係」「テストを書く係」と割ると、共通の前提情報が重複して流通しコンテキストを浪費します。代わりに、認証モジュール担当・決済モジュール担当のように各エージェントが必要とするコンテキストの境界で分けると、注意が集中しトークン効率も上がります。5パターンはこの境界と情報流通の制御方式が違うだけ、と捉えると選定の議論が混乱しません。

Anthropic公式が示す5つの協調パターンの全体像

5パターンは「品質統制（Generator-Verifier）」「階層分業（Orchestrator-Subagent）」「持続的並列（Agent Teams）」「疎結合連携（Message Bus）」「分散協調（Shared State）」という異なる軸を持ちます。パターン数を覚えるより、自社の課題がどの軸の問題かを先に特定するほうが、選定は速く決まります。以降の章で各パターンを、動作原理・適用例・弱点の順に見ていきます。まず公式が起点に推すOrchestrator-Subagentからです。

Orchestrator-Subagent型：階層分業とClaude Code実装例

Orchestrator-Subagentは、公式が「多くのユースケースでまずここから」と推奨するパターンです。中央のlead agent（Orchestrator）がタスクを受け取り、自ら処理する部分と別エージェントへ委譲する部分を判断し、委譲されたサブタスクはsubagentが専用のコンテキストウィンドウで処理して要約結果を返します。Orchestrator本体のコンテキストを汚さず、必要な情報だけを蒸留して戻す役割分担が成立します。

lead agentによる分解とsubagentの並列起動

核心は、Orchestratorが「何を・いくつのsubagentに任せるか」をタスクの性質に応じて動的に決める点です。固定分業ではないため柔軟性とトレーサビリティを両立できますが、この判断品質が全体効率を左右するため、委譲ルールの明文化が要諦になります。動作を擬似コードで示すと、依存のないサブタスクだけを並列に走らせるのが要点です。

# Orchestrator（lead agent）がサブタスクを分解し、独立なものだけ並列委譲する擬似コード
def orchestrate(task):
    subtasks = lead_agent.decompose(task)          # 境界の明確な単位へ分解
    results = []
    for group in independent_groups(subtasks):     # 依存関係のない束ごとに
        results += run_parallel(                    # 独立サブタスクは並列起動（直列化を避ける）
            subagent.run(st, context=st.needed_context)  # subagentは専用コンテキスト
            for st in group
        )
    return lead_agent.synthesize(results)          # 要約結果だけを統合

Claude Codeの背景探索subagent、コードレビュー自動化

公式が挙げる具体例がClaude Code自身です。メインエージェントがOrchestratorとして振る舞い、コード編集・ファイル操作・コマンド実行を自ら処理しつつ、大規模コードベースの検索や独立した調査が要る瞬間にsubagentをバックグラウンド起動します。本体は主作業を止めず、subagentの結果をストリーミング受信して判断材料に組み込む非同期協調です。各subagentが独自コンテキストで動くため、本体を膨らませずに探索範囲を広げられます。

もう一つの典型が自動コードレビューです。Pull Request到着時に、セキュリティ脆弱性・テストカバレッジ・コードスタイル・アーキテクチャ整合性を、それぞれ専門のsubagentへ振り分け、Orchestratorが結果を統合して総括を生成します。各検査は必要な知識もコンテキストも異なるため、コンテキスト分離が自然に成立します。手順が事前に予測できる固定パイプラインである点も、中央集約型と相性が良い理由です。Claude Code系の実装例はCodexサブエージェントの使い方やClaude Code Agent Teamsの仕組みも参考になります。

情報集約ボトルネックと直列化という弱点

構造的な弱点は二つです。第一に、Orchestratorが情報集約のボトルネックになります。あるsubagentの発見が別のsubagentの作業に関係する場合、その情報は一度Orchestratorへ戻り、関連性を認識して転送する必要があります。ハンドオフを重ねるうちに重要な詳細が要約で失われるリスクが累積し、subagent同士が密に関連する場面ほど遅延と劣化を招きます。第二に、明示的に並列化しない限りsubagentは直列実行され、トークンコストだけ増えて速度の利点が得られない最悪のトレードオフに陥ります。並列化の境界条件はサブタスク間の依存の有無に集約されるため、入出力依存を設計時にマップ化しておくと判断が容易になります。

Generator-Verifier型：品質ゲートとrubber-stampの失敗

Generator-Verifierは5つで最もシンプルながら実装数の多い構造です。Generatorが初期出力を生成し、Verifierが評価基準に照らして合否を判定、不合格なら具体的フィードバックを添えて差し戻す二者構成で、合格するか最大反復回数に達するまでループします。上限を欠くと改善が頭打ちのまま永続する危険があるため、公式も上限とフォールバック戦略の併設を求めています。Verifierは必ずしもGeneratorより賢い必要はなく、「合格基準を満たすか」という狭く明確な問題に向き合う点が効きます。

有効な用途と、rubber-stamp・同難度という弱点

有効なのは評価基準を事前に言語化でき、誤出力の損失が再生成1回分を大きく上回る領域です。テスト実行で合否判定するコード生成、ナレッジベース整合を検証するサポート応答、引用元照合のファクトチェック、ルーブリック採点、コンプライアンス項目のチェックなどが該当します。

公式が最も警戒する失敗は、Verifierに「出力が良いか確認して」とだけ指示した場合です。具体的な評価項目を欠くと、ほぼ無条件で合格を出すrubber-stamp（ゴム印）状態になり、品質ゲートとして機能しないのに運用コストだけ二重にかかります。「事実はこのソースと一致するか」「必須項目A・B・Cを網羅したか」といった粒度まで基準を落として初めて機能します。もう一つの弱点は、生成と検証が同程度に難しい場面です。新規性の高い表現や未確立領域の仮説など「正解」が外部に存在しないタスクでは、Verifierが照合できる基準がなく欠陥が素通りします。正解の輪郭が外部にある領域に強く、正解そのものを発見する領域では別パターンとの併用が要る、と整理できます。

Agent Teams型：worker持続性による長期並列

Agent TeamsはOrchestrator-Subagentを拡張した形で、独立性が高く長時間に及ぶ並列タスクに向きます。coordinatorが複数のteammateを独立プロセスとして起動し、teammateは共有キューからタスクを取得して複数ステップを自律処理し、完了をシグナルで通知します。coordinatorは割り当てと結果収集に役割を限定し、Orchestratorのような細かい指示やフィードバック仲介は行いません。

Orchestrator型との最大の差＝worker持続性

最大の違いがworker persistence（持続性）です。Orchestrator-Subagentのsubagentは一つのサブタスクのために起動し結果を返すと消滅しますが、Agent Teamsのteammateは複数の割り当てをまたいで生存し、コンテキストとドメイン知識を蓄積します。同種タスクの反復で依存関係の把握や規約への適応が進み、公式表現でいう「real familiarity（実際の馴染み）」を獲得していきます。これは一回起動型のsubagentでは原理的に得られない性質です。逆に、サブタスクが完全に異質で蓄積が活きない場面では優位性が消えます。

コードベース移行の実務例と、衝突という弱点

代表例が大規模コードベースのフレームワーク移行です。coordinatorが各サービスをteammateへ割り当て、各teammateが依存更新・書き換え・テスト修正・検証まで自律処理し、最後にcoordinatorが結合テストを実行します。担当サービスの依存グラフやデプロイ設定への習熟が蓄積されるため、後半ほど効率と品質が上がります。弱点はteammate同士が中間発見を共有しづらい点です。teammate Aが共通ライブラリに破壊的変更を加えても、直接の通信経路がないため、結果を持ち寄った段階で初めて衝突が発覚し手戻りになります。完了時刻のばらつきや共有リソース競合もあり、タスク分割時点で「触れる範囲」を分離し、lockやバージョン管理で競合を検出する設計が前提になります。teammate同士が頻繁に意見交換を要し始めたら、Shared Stateへの進化シグナルです。Claude Code上の具体的な運用はClaude Code Agent Teamsの全体像で解説しています。

Message Bus型：イベント駆動連携と拡張容易性

Message Busは、エージェント数が増え相互作用が複雑化した場面で、直接調整に代わる選択肢です。各エージェントは関心のあるtopicを購読し、別のエージェントがそのtopicへイベントを発行すると、routerが購読者へ配送します。発行側は受信者を知らず、購読側は発行者を知らなくても、共通のtopic定義さえあれば連携が成立する疎結合が特徴です。

セキュリティtriage事例と拡張容易性

公式例がセキュリティ運用の自動化です。triage役がアラートを重要度・種別で分類し、ネットワーク系はネットワーク調査へ、認証系はアイデンティティ分析へと振り分け、各エージェントが補強情報の要求イベントを発行し、最終的にレスポンス調整役がアクションを決めます。適合する理由は、アラート種別や調査経路を事前に完全予測できないからです。新しい脅威カテゴリが出ても対応エージェントを追加してtopicを購読させるだけで、既存の配線を変えずに組み込めます。チームごとに独立して開発・デプロイできる点も、分散した運用組織と噛み合います。Orchestrator型が新subagent追加のたびにプロンプトとルーティングを更新する必要があるのと対照的です。

トレース困難・router誤分類・LLM routerの評価

最大の弱点は、柔軟性の裏返しでトレーサビリティが落ちる点です。あるアラートが5つのエージェントをカスケードした場合、何が起きたかの再構築には注意深いロギングと相関付けが要ります。さらに深刻なのがrouterの誤分類によるサイレント失敗で、配送漏れが起きても「何もしないがエラーも出さない」状態になり、品質クリティカルな領域では特に危険です。routerをLLMで実装すると自由記述の分類に対応できる反面、レイテンシ・コスト・判断ばらつきを持ち込みます。種別フィールドや重要度ラベルが整っていればルールベースで十分に速く正確、曖昧な分類が必要ならLLM、という判断軸になり、明確な部分はルール・曖昧な部分だけLLMというハイブリッドも実務的です。

Shared State型：中央不在の分散協調と反応的ループ

Shared Stateは5つで最も分散度が高く、中央コーディネータが存在しません。各エージェントが共有データベース・共有ファイルシステム・共有ドキュメントのいずれかに対してread/writeを行い、初期化ステップでstoreに質問やデータをseedしたところから、各エージェントが自律的にstoreを参照して動き、結果を書き戻します。Orchestratorもcoordinatorもrouterもなくstoreそのものが情報集約点になる点が、他パターンと根本的に異なります。

研究合成の実務例と、単一障害点の排除

代表例が研究合成システムです。学術文献・業界レポート・特許・ニュースをそれぞれ別エージェントが調査し、学術エージェントが重要研究者を発見すればstoreへ書き込み、業界エージェントが次回参照時に即座に利用する、という発見の相互反映が遅延や情報損失なく成立します。もう一つの利点が単一障害点の排除です。Orchestrator・coordinator・routerはいずれも停止すれば全体が止まりますが、Shared Stateは中央役割がないため、一部のエージェントが落ちても他はstoreの読み書きを続けられます。24時間365日の継続稼働が要る分析パイプラインで効いてくる性質です。

反応的ループとtermination conditionの設計

調整役がないため、複数エージェントが同じ対象を独立に追う重複作業や、同時書き込み競合が起きます。これらはlocking・versioning・partitioningといった、データベース分野で確立された既知の工学的対処（公式のいう「known engineering fixes」）で解けます。一方、より厄介なのが反応的ループです。AがB向けの発見を書き、BがAへの応答を書き、が延々続いて収束しない振る舞いレベルの問題で、公式は「reactive loops are a behavioral problem」と明言しています。対策は、設計初期から終了条件を一級市民として組み込むことです。具体的には(1)時間予算、(2)収束しきい値（Nサイクル新規発見がなければ終了）、(3)「storeに十分な答えが揃ったか」を専門に判断する終了判定エージェント、の3つが公式の挙げる選択肢です。終了条件を後回しにしたシステムは、ほぼ確実に暴走するか、特定エージェントのコンテキストが溢れた時点で恣意的に止まります。

5パターンの選び方と段階的な進化戦略

個別理解を踏まえた横断的な選定は、隣接する2パターンの決め手となる一軸で判断すると迷いません。

Message BusとShared Stateの違いには、中央コンポーネントの有無も効きます。Message Busにはrouterが残るのに対し、Shared Stateは完全分散で単一障害点を排除できます。「Message Bus上のエージェントが、行動を起こすためでなく発見を共有するためにイベントを発行し始めた」なら、Shared Stateへの移行シグナルです。

Orchestrator-Subagent起点の段階的拡張ロードマップ

公式が一貫して推すのは、Orchestrator-Subagentから始めて実運用のボトルネックを観測し、必要になったパターンだけを足していくアプローチです。理由は、このパターンが最小の調整オーバーヘッドで最も広い問題を扱え、中央集約ゆえにログ追跡とコスト管理が直線的だからです。進化は次の順に、実際に詰まってから判断します。

1. 単一エージェントで実装し、機能と精度の基準値を確立する
2. 品質クリティカル要件が出たらGenerator-Verifierを足す
3. タスク分解が必要になったらOrchestrator-Subagentへ拡張する
4. subagentの持続性が要るならAgent Teamsへ進化させる
5. イベント駆動の拡張性が要るならMessage Busを導入する
6. 協働性と耐障害性が要るならShared Stateを採用する

本番システムでは複数を組み合わせるハイブリッドが一般的です。たとえば全体はOrchestratorで管理し、協働性の高い調査フェーズだけShared Stateにする構成や、Message Busのルーティング上でAgent Teams型のworkerが各イベント種別を持続処理する構成が典型です。パターンを排他的な選択肢ではなく組み合わせ可能なビルディングブロックと見る視点が、現実的な設計を支えます。

導入前チェックリストと現場の落とし穴

公式が各所で発した警告を逆算すると、導入前に確認すべき論点が整理できます。

• 過剰設計：「高度に聞こえる構成」を中身より先に選んでいないか。現在の構成の何に困っているかをレイテンシ・トークン消費・エラー率など具体的な指標で言語化できなければ、進化判断の基盤がない。
• early victory（rubber-stamp）：Verifierへの指示に合格基準が具体的に列挙されているか。抽象的な評価語だけなら形だけの品質管理に陥る。
• トークンコスト：マルチエージェント構成は代償を伴う。公式のエンジニアリングブログ「How we built our multi-agent research system」では、マルチエージェント構成はチャット会話比で約15倍のトークンを消費すると報告されている。調査の広さ・深さが事業価値に直結する用途でのみ正当化されると考え、コスト天井・精度SLA・速度予算を明文化してから採否を決める。
• トレース・デバッグ：特にMessage BusとShared Stateでは、各イベントに一意の相関IDを付与し、判断根拠まで構造化ログに残す設計を導入前に用意する。後付けでは過去の問題を遡及調査できない。
• 採用しない判断：単一コンテキストに収まり手順が短いタスク（一般的なFAQ応答、定型ドキュメント生成、明確な指示のコード補完）は、シングルエージェントで十分。運用体制が伴わないまま複雑な構成を入れると、運用負荷で別の問題を生む。

コーディング支援エージェント全般の種類と選び方はCoding Agentとは｜種類・主要ツール比較と選び方も併せて確認してください。

よくある質問

Orchestrator-Subagentとは何ですか？

中央のlead agent（Orchestrator）がタスクを分解し、境界の明確なサブタスクを専用コンテキストを持つsubagentへ委譲して、結果を統合する階層分業パターンです。Anthropic公式が「多くのユースケースでまずここから始めるべき」と推奨する起点のパターンで、Claude Code自身もこの構造で背景探索用のsubagentを起動しています。

orchestratorとsubagentの違いは何ですか？

orchestrator（lead agent）は全体の計画・委譲・統合を担う中央役で、subagentは委譲された個別サブタスクを自分専用のコンテキストウィンドウで処理して要約結果だけを返す実行役です。subagentは一つのサブタスクのために起動して消滅するため、コンテキストを持ち越しません（持ち越すのはAgent Teamsのteammate）。

シングルエージェントとマルチエージェントはどう使い分けますか？

目的が単一のコンテキストウィンドウに収まり手順が短いならシングルエージェントで十分です。情報量がコンテキストを超える、独立した探索や並列処理が要る、検証や専門分業で品質が上がる、のいずれかが成立して初めてマルチエージェント化の価値が立ちます。判断軸の詳細はシングルエージェントとマルチエージェントの違いを参照してください。

Claude Codeはどの協調パターンですか？

Orchestrator-Subagentです。メインエージェントがOrchestratorとしてコード編集やコマンド実行を自ら行いつつ、大規模コードベースの検索や独立調査が必要になった瞬間にsubagentをバックグラウンド起動し、結果をストリーミングで受け取って判断に組み込みます。

マルチエージェントにするとコストはどれくらい増えますか？

Anthropicのエンジニアリングブログ「How we built our multi-agent research system」によれば、マルチエージェント構成はチャット会話と比較して約15倍のトークンを消費します。調査の広さと深さが価値に直結する用途では正当化されますが、定型的なタスクではシングルエージェントのほうが経済的に合理的です。

関連記事

• マルチエージェントとは？仕組み・構成パターンと採用判断を実装者視点で解説
• シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード
• Claude Code Agent Teamsの全体像と従来のサブエージェントでは不可能だった協調開発の仕組み
• Codexサブエージェントとカスタムエージェントの使い方｜TOML定義・並列実行
• Coding Agentとは｜種類・主要ツール比較と選び方