複数のAIエージェントを組み合わせるシステムを設計するとき、多くのチームが「高度に見えるから」という理由でパターンを選んでしまう。その結果は過剰な複雑さと無用な障害だ。
Anthropicは2026年4月10日、マルチエージェントシステムの協調パターンを5種類に整理したガイドを公式ブログで公開しました。「どのような場合にマルチエージェントが有効か」を論じた前作の続編として位置づけられており、マルチエージェントを採用した後に直面する「どの協調方式を選ぶか」という問いに答えた内容です。
この記事でわかること：
- 5つの協調パターンそれぞれの仕組みと適したユースケース
- 各パターンが機能しなくなる条件
- パターンを選ぶための構造的な判断基準
Generator-verifier：品質を担保する最もシンプルな分業
最もシンプルで広く使われているパターンです。ジェネレーターが出力を生成し、ベリファイアーが評価して合否を判定します。不合格なら具体的なフィードバックをジェネレーターに返し、再生成させるループが続きます。
コード生成でいえば、片方がコードを書き、もう片方がテストを実行して検証する構成がこれにあたります。サポートメールの生成と正確性チェックも典型例です。
このパターンが機能するのは、評価基準を明文化できる場面に限られます。「良いかどうか」という曖昧な基準しか与えなければ、ベリファイアーはジェネレーターの出力をそのまま通過させるだけになります。品質管理の形を作っても中身が伴わない状態です。
反復が収束しない問題も起きます。最大試行回数と代替戦略（人間へのエスカレーションやベストアンサーの返却）を設計に組み込んでおく必要があります。
Orchestrator-subagent：タスク分解と委譲の階層構造
階層型の構造を持つパターンです。オーケストレーターが計画を立て、サブエージェントにタスクを委譲し、結果を統合します。Claude Codeがこの方式を採用しており、メインエージェントがコードを書きながら、大規模コードベースの探索はバックグラウンドのサブエージェントに任せています。
プルリクエストのレビュー自動化がわかりやすい例です。セキュリティチェック、テストカバレッジ検証、コードスタイル評価、アーキテクチャ整合性確認——それぞれを専門のサブエージェントに委譲し、オーケストレーターが結果をまとめます。
弱点は情報のボトルネックです。サブエージェントが発見した内容は必ずオーケストレーター経由で他に伝わるため、複数の委譲を経るうちに重要な文脈が失われやすくなります。また明示的に並列化しない限り、サブエージェントは順番に実行されます。マルチエージェントのコストを払っても速度の恩恵が得られない状態に陥りがちです。
Agent teams：長期稼働で蓄積される専門性
並行かつ長期間稼働する独立タスクがある場合に適したパターンです。Orchestrator-subagentとの違いはワーカーの持続性にあります。サブエージェントはタスクを終えると終了しますが、Agent teamsのワーカーは稼働し続けます。タスクを跨いでコンテキストを蓄積し、担当ドメインの専門性を高めていきます。
大規模なコードベースの移行が典型的なユースケースです。各エージェントが担当サービスについて継続的に学習しながら、依存関係の更新・コード変更・テスト修正を進めます。コーディネーターは完成した移行を受け取り、システム全体の統合テストを実施します。
独立性が確保できないときは機能しません。複数のエージェントが同じファイルやデータを触ると競合が発生します。タスクの分割と競合解消の仕組みが不可欠です。
Message bus：イベント駆動で広がるエコシステム
エージェント同士がイベントを介して疎結合に連携するパターンです。エージェントはトピックを購読し、マッチするイベントが届いたら動作します。新しいエージェントを追加しても既存の接続を変更せずに済むため、エコシステムを拡張しやすい点が特徴です。
セキュリティ運用の自動化に向いています。複数ソースからのアラートを種別ごとに専門エージェントへルーティングし、調査結果を対応エージェントへ流す——このように処理が動的に展開するシステムと相性が良いです。
デバッグが難しくなる点は注意が必要です。イベントの連鎖が複数エージェントに及ぶと、何が起きているか追跡するために詳細なログと相関付けが必要になります。ルーティングが誤分類やドロップをしても、システムが静かに何もしないまま止まらないという無言の失敗が起きることもあります。
Shared state：中央コーディネーター不要の協調
共有ストアをエージェント同士の協調手段とするパターンです。中央のコーディネーターを置かず、エージェントが直接読み書きすることで互いの発見を即座に参照できます。コーディネーターが単一障害点にならないため、いずれかのエージェントが停止しても他は動作し続けます。
リサーチシンセシスに適しています。学術文献を調べるエージェント、業界レポートを分析するエージェント、特許情報を追うエージェントが並走し、それぞれの発見が即座に他の調査に影響します。
最大の落とし穴は収束しない反応ループです。エージェントAの書き込みにエージェントBが反応し、さらにAが反応する——という連鎖が延々と続くことがあります。時間予算や収束閾値（N周期以内に新情報がなければ終了）を終了条件として最初から組み込む必要があります。終了条件を後付けで考えるシステムは、無限に回り続けるか唐突に止まるかのどちらかになります。
どのパターンを選ぶか
AnthropicはOrchestrator-subagentを出発点として推奨しています。最も広い問題に対応でき、協調コストが低いためです。
Orchestrator-subagentかAgent teamsかを判断する軸は、ワーカーが複数のサイクルにわたってコンテキストを保持する必要があるかどうかです。タスクをまたいだ文脈の蓄積が重要なら、Agent teamsを選びます。
Orchestrator-subagentかMessage busかの判断軸は、ワークフローの手順が事前にわかっているかどうかです。手順が固定されているならOrchestrator-subagent、イベントによって次の処理が変わるならMessage busです。
Orchestrator-subagentかShared stateかは、エージェントが互いの発見を参照しながら進める協調作業かどうかで判断します。エージェントが独立して動くならOrchestrator-subagent、発見を積み重ねながら協調するならShared stateを検討します。
Anthropicは「実際のプロダクションシステムはパターンを組み合わせることが多い」とも述べています。Orchestrator-subagentで全体のフローを管理しつつ、協調が密なサブタスクはShared stateで処理するといった構成です。
洗練された構造に見えるほど良いわけではありません。このガイドが一貫して示す出発点は、「問題に合った最もシンプルなパターン」です。複雑さを正当化できる問題が来たときに、初めて次のパターンへ移ればよいというのがAnthropicの立場です。