Multi-agent coordination patterns: Five approaches and when to use them¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Claude Blogによる、マルチエージェントシステムの協調パターン整理。 Generator-Verifier、Orchestrator-Subagent、Agent Teams、Message Bus、Shared Stateの5つを、適した場面と失敗しやすい点で比較している。 結論としては、最初から複雑な構成にせず、まずOrchestrator-Subagentから始め、詰まる場所に応じて他パターンへ進化させる方針が勧められている。
本文¶
この記事は、マルチエージェントを使う判断をしたあとに、どの協調パターンを選ぶべきかを整理している。ポイントは、かっこよさや複雑さではなく、問題の構造に合う一番単純なパターンから始めること。
記事で扱う5つのパターンは次の通り。
- Generator-Verifier: 明示的な評価基準で品質を上げる
- Orchestrator-Subagent: 明確に分解できる短いサブタスクを委譲する
- Agent Teams: 独立した長時間の並列作業を継続文脈で進める
- Message Bus: イベント駆動で増えるエージェント群をルーティングする
- Shared State: エージェントが共通ストアで発見を共有する
1つ目はGenerator-Verifier。生成役が成果物を作り、検証役が基準に照らして受け入れるか差し戻す。コード生成とテスト、事実確認、コンプライアンスチェックのように、評価基準を明示できる領域に向く。弱点は、検証基準が曖昧だと品質保証のふりになること。反復が収束しない場合に備えて、最大回数や人間へのエスカレーションも必要になる。
実装時は、検証役に「良いかどうか」ではなく、検証項目を渡す必要がある。例えばコード生成なら、テストが通ること、仕様に書かれた入出力を満たすこと、既存APIを壊さないこと、セキュリティ上の禁止事項がないこと、などを明文化する。失敗時は、検証役が修正方針まで書きすぎるより、どの基準に違反したかを明確に返す方がループが安定しやすい。
サポートメール生成の例では、生成役がドキュメントとチケット文脈を使って返信案を作り、検証役がナレッジベースとの整合、ブランドトーン、問い合わせへの回答漏れを確認する。価格プランの誤帰属や未回答の論点があれば、検証役は具体的な失敗理由を返す。
2つ目はOrchestrator-Subagent。中心となるエージェントが計画、委任、結果統合を担当し、サブエージェントが限定された調査や作業を行う。コードレビューや大規模コードベース調査のように、分解しやすく、各サブタスクの出力が明確な場合に向く。弱点は、中心エージェントが情報のボトルネックになること。サブエージェント同士に関係する発見があっても、いったん中心に戻す必要がある。
実装時は、サブエージェントに渡す作業を短く、独立したものに切る。入力、調査対象、期待する出力形式を明確にし、中心エージェントは結果の統合と最終判断に集中する。サブエージェントの結果はそのまま貼るのではなく、矛盾、重複、未確認事項を中心側で整理する必要がある。
Claude Codeはこのパターンを使う例として説明されている。メインエージェントはコード編集やコマンド実行を自分で行い、大規模コードベース調査や独立した調査をサブエージェントへバックグラウンド委譲する。サブエージェントは別コンテキストで動き、要約された発見を返すため、メインのコンテキストを主作業に集中させられる。
3つ目はAgent Teams。複数のエージェントがそれぞれ長めの作業文脈を持ち、並列に進む。サービス単位の移行や大規模リファクタのように、担当領域への慣れが成果に効く場合に向く。Orchestrator-Subagentよりも、各エージェントが継続的な文脈を持てる点が重要になる。
実装時は、担当領域を明確に分ける。例えばサービスA、サービスB、フロントエンド、インフラのように境界を切り、同じファイルや同じ意思決定を複数エージェントが同時に触らないようにする。長期作業になるほど、各エージェントが何を決めたか、未解決の依存が何かを外部に残す仕組みが必要になる。
Agent Teamsでは、コーディネータが複数のワーカーを独立プロセスとして起動し、チームメイトが共有キューからタスクを取って自律的に進める。Orchestrator-Subagentと違い、ワーカーは1タスクで終了せず、複数タスクをまたいで生き続ける。これにより、担当領域の依存関係、テスト、デプロイ構成などの文脈が蓄積される。
弱点は独立性が崩れると衝突すること。中間発見を共有しにくいため、あるチームメイトの変更が別のチームメイトに影響しても気づきにくい。完了検知も難しく、2分で終わるタスクと20分かかるタスクを同時に扱う必要がある。同じコードベース、DB、ファイルシステムを触る場合、同じファイル編集や互換性のない変更を避けるタスク分割と衝突解消が必要になる。
4つ目はMessage Bus。イベントを中心に、ルーターが適切なエージェントへ処理を流す。セキュリティ運用や通知・調査パイプラインのように、処理の流れがイベントによって変わる場合に向く。オーケストレーターに条件分岐が増えすぎたら、イベントルーティングとして明示する方が拡張しやすい。
実装時は、イベントの種類、ペイロード、担当エージェント、再試行、重複排除を設計する。新しいイベント種別が増える前提なら、巨大な条件分岐よりも、イベントタイプとハンドラの対応表を持つ方が保守しやすい。反対に、手順が固定で少数ならMessage Busは過剰になりやすい。
Message Busでは、エージェントはpublishとsubscribeでやり取りする。各エージェントは関心のあるtopicを購読し、ルーターが該当イベントを配送する。新しい能力を持つエージェントを追加しても、既存エージェント同士の接続を直接書き換えなくてよい。
セキュリティ運用の例では、複数ソースからアラートが届き、triage agentが重大度と種類を分類する。ネットワーク系の高重大度アラートはnetwork investigation agentへ、認証情報系はidentity analysis agentへ送られる。調査エージェントは追加情報を要求し、context-gathering agentが補完する。最終的にresponse coordination agentが対応を決める。
弱点はトレースとルーティング精度。1つのアラートが5つのエージェントに連鎖すると、何が起きたかを追うには相関IDやログ設計が必要になる。ルーターが誤分類したりイベントを落としたりすると、システムはクラッシュせず何もしないまま失敗する。LLMルーターは柔軟だが、独自の失敗モードを持つ。
5つ目はShared State。エージェントが共通のストアを読み書きし、互いの発見を直接参照する。調査やリサーチ統合のように、あるエージェントの発見が別のエージェントの探索方向を変える場合に向く。中心の単一障害点を減らせる一方で、重複作業、矛盾、反応ループが起きやすい。終了条件、ロック、バージョン管理、収束判定が必要になる。
実装時は、共有ストアを単なるログにしない。発見、仮説、確定事実、却下した案、未解決質問を区別して保存する。エージェントが互いの書き込みに反応し続けると無限ループに近い挙動になるため、時間予算、更新なしの終了条件、十分な答えかを判定する役割が必要になる。
Shared Stateでは、オーケストレーターやルーターを介さず、全エージェントが同じDB、ファイルシステム、ドキュメントを読む。初期化ステップで問いやデータセットを置き、エージェントがそこから読み、作業し、発見を書き戻す。終了条件は、時間制限、一定サイクル新しい発見がないこと、指定エージェントが十分な答えだと判断することなど。
研究統合の例では、学術文献担当、業界レポート担当、特許担当、ニュース担当がそれぞれ調査する。学術文献担当が重要人物を見つけたら、その発見は共有ストアに置かれ、業界担当が即座に企業調査へ反映できる。中心ルーターを待たずに知識ベースが育つ。
弱点は、明示的な調整がないため、重複調査や矛盾した方針が出やすいこと。より厄介なのは反応ループ。Aが発見を書き、Bがそれに反応し、Aがさらに反応する、という形で収束しない作業が発生する。ロックやバージョニングは技術的衝突に効くが、反応ループは行動設計の問題なので、終了条件を最初から設計する必要がある。
パターン選択の軸は、作業が短いか長いか、固定手順かイベント駆動か、各エージェントの成果が互いに影響するか、単一障害点を許容できるか。実運用では単一パターンだけでなく、全体はOrchestrator-Subagent、特定の調査部分はShared Stateのようなハイブリッドも自然に起こる。
記事の実務的な結論は、最初はOrchestrator-Subagentから始めること。対応できる範囲が広く、協調コストも比較的低い。運用してみて、情報ボトルネック、長期文脈の必要性、イベントルーティングの複雑化、共有知識ベースの必要性が見えてきたら、別パターンへ進化させる。
| 状況 | 向くパターン |
|---|---|
| 明確な評価基準で品質を上げたい | Generator-Verifier |
| 分解しやすく短いサブタスクが多い | Orchestrator-Subagent |
| 独立した長時間の並列作業がある | Agent Teams |
| イベントに応じて処理経路が変わる | Message Bus |
| 調査結果をエージェント間で共有したい | Shared State |
| 中心コンポーネントを単一障害点にしたくない | Shared State |
要点¶
- マルチエージェントは、問題の構造に合わせて協調パターンを選ぶ必要がある。
- Generator-Verifierは評価基準が明確な品質保証に向く。
- Orchestrator-Subagentは、短く分解しやすい作業に向く。
- Agent Teamsは、担当領域に長期文脈が必要な並列作業に向く。
- Message Busは、イベント駆動で処理経路が増えていくシステムに向く。
- Shared Stateは、エージェント間で発見を即時共有したい調査系に向く。
- 最初はOrchestrator-Subagentで始め、詰まりに応じて進化させるのが現実的。