マルチエージェント協調ガイド：5つの主要モードの選び方・使い方

以前の記事で、マルチエージェントシステムが最大の価値を発揮するのはどのような場合か、そして単一エージェントの方が適しているのはどのようなケースかを検討しました。今回の記事は、「マルチエージェント」の道を選んだチーム向けです：現在抱えている問題に対して、どの協調パターンを選ぶべきでしょうか？

私たちはよく、あるチームがパターンを選定する際、「高級感」があるものばかりを選び、実際に手元の問題に適合しているかどうかを無視しているのを目にします。私たちのアドバイスは、動作可能な最もシンプルなパターンから始め、どこでボトルネックが発生するかを観察し、その後段階的にアップグレードすることです。本記事では、5つの一般的なパターンの動作原理と限界を分解します：

ジェネレーター・ベリファイア（Generator-verifier）：出力の品質を重視し、明確な評価基準があるシナリオに適しています。

オーケストレーター・サブエージェント（Orchestrator-subagent）：タスクの分解が明確で、サブタスクの境界がはっきりしているシナリオに適しています。

エージェントチーム（Agent teams）：並列処理が可能で互いに干渉せず、長時間実行されるサブタスクがあるシナリオに適しています。

メッセージバス（Message bus）：イベント駆動型のパイプライン作業や、システムが継続的に新しいエージェントを追加しているシナリオに適しています。

共有状態（Shared-state）：高い協調性が必要で、エージェント同士が他の発見を参照し合う必要があるシナリオに適しています。

パターン1：ジェネレーター・ベリファイア（Generator-verifier）

これは最もシンプルなマルチエージェントパターンであり、現在実装例が最も豊富なパターンの一つです。以前の記事では「検証サブエージェントパターン」と呼んでいましたが、ここでは「ジェネレーター」が必ずしも全体を指揮するオーケストレーターである必要がないため、より広義の「ジェネレーター・ベリファイア」という名称を使用します。

ジェネレーター（Generator）はタスクを受け取ると、まず初期結果を出力し、それをベリファイア（Verifier）に渡して評価させます。ベリファイアは、その結果が規定された基準を満たしているかを確認します。基準を満たせば承認し、満たさなければ具体的な修正意見（フィードバック）をジェネレーターに戻します。ジェネレーターはこれらのフィードバックを受け取って再修正を行います。この「修正・審査」のループは、ベリファイアが満足するか、システムが設定した最大修正回数の制限に達するまで続きます。

顧客からのサポートチケットに対応する自動メールシステムを想像してみてください。ジェネレーターは製品ドキュメントとチケットの詳細情報を用いて下書きを作成します。ベリファイアは「品質管理担当者」として機能し、ナレッジベースを確認して事実の正確性を検証し、トーンがブランド要件に適合しているかチェックし、顧客が提起したすべての問題に対応しているか確認します。審査に通らなかった場合、ベリファイアは具体的な問題をジェネレーターに戻し、「ある機能を誤って基本版に分類している」や「特定の質問への回答を漏らしている」といった指摘を行います。

出力の品質が極めて重要であり、「良い結果とは何か」を明確な基準で記述できる場合、このパターンは間違いなく適しています。これはコード生成（1つのエージェントがコードを記述し、もう1つがテストを記述して実行する）、事実確認、固定スコアシートに基づく採点、コンプライアンス監査、そして「1回の失敗のコストが複数回の修正プロセスを上回る」あらゆる分野に非常に適しています。

このシステムの下限は、完全に検証者の審査基準がどの程度細密かにかかっています。（注：もし検証者に「これが良いかどうか見て」とだけ伝えて、具体的な基準を与えなければ、それは往々にして目を閉じて「合格」の判を押すだけの形骸化したプロセスになってしまいます。）チームがこのモードを適用する際、最も犯しやすい誤りは、ループメカニズムは構築したものの、「検証」が何を意味するかを明確に定義しなかったことです。これでは、「品質管理を行っている」という偽りの繁栄を生むだけです。

さらに、このモードは「生成」と「検証」が切り離可能な二つのスキルであると仮定しています。しかし、もしあなたが卓越したアイデアを評価しようとする場合、それを評価する難しさは、そのアイデアを生み出す難しさと同等かそれ以上になる可能性があり、この場合、検証者の信頼性は必ずしも高くありません。

最後に、このループは「行き詰まり」に陥りやすいです。生成者が検証者の指摘する問題を解決できない場合、システムは両者の間でボールを蹴り合い続け、永遠に収束しません。したがって、最大ループ回数の制限を設定し、バックアッププラン（例えば、人間への手渡しや、プロンプト付きで現在最良のバージョンを返す処理など）を用意して、無限ループに陥るのを防ぐ必要があります。

モード2：オーケストレーター - サブエージェント (Orchestrator-subagent)

このモードの核心は「階層制」にあります。「チームリーダー」のような中核エージェントが業務の計画立案、タスクの割り当て、そして結果の最終的な集約を担当し、各サブエージェント (Subagents) は具体的な分担業務を処理して上司に報告します。

主導するオーケストレーター (Orchestrator) はタスクを受け取ると、どのように着手すべきかを考えます。一部は自身で解決し、残りを異なるサブエージェントに割り当てます。部下たちが作業を完了して結果を提出した後、オーケストレーターはそれらの断片を組み合わせて完全な最終回答を作成します。

Claude Code はこのモードを採用しています。主エージェントはコードの記述、ファイルの変更、コマンドの実行を自身で担当しますが、膨大なコードベースでの広範な検索や、独立した問題の調査が必要な場合、バックグラウンドでサブエージェントに委任します。これによりメインの作業が停止することなく、検索結果が絶え間なく送られてきます。各サブエージェントは独自のコンテキストウィンドウ (Context window) で動作し、精査された調査結果のみを返します。（注：これはまるで、上司の頭脳（コンテキスト）が大きな方向性に集中し、資料調査などの複雑な情報は従業員の頭脳内で処理されるため、上司の思考が細かな事柄で埋め尽くされないようにするようです。）

自動化されたコードレビュー (Code review) システムを想像してみてください。新しいコードが提出されると、システムはセキュリティ脆弱性のチェック、テストカバレッジの検証、コードスタイルの評価、アーキテクチャの一貫性確認を行います。これらのチェック方向は互いに干渉せず、必要な背景知識も異なり、明確なレポートを出力できます。この場合、オーケストレーターはタスクを複数の専門サブエージェントに分配し、それらが調査を終えた後、レポートを融合して包括的な審査意見を作成します。

タスクの分解が非常に明確で、サブタスク間の相互依存関係が少ない場合、このモードは非常に効果的です。オーケストレーターは大目標を常に掌握し、サブエージェントは細分化された作業に集中して遂行できます。

オーケストレーターは情報の「ボトルネック」になりやすいです。あるサブエージェントが他のサブエージェントの作業に影響を与える可能性のある情報を発見した場合、その情報はまずオーケストレーターに報告され、そこから再配布されます。例えば、セキュリティ調査を行うエージェントが認証の脆弱性を発見し、それがアーキテクチャ分析を行うエージェントの分析に影響する場合です。情報が上下の間で頻繁にやり取りされると、重要な詳細が繰り返される「要約報告」の過程で見失われやすくなります。

さらに、専用の並列処理を行わない場合、サブエージェントは順番に作業を行います。これは、マルチエージェントでデータを処理（Token）するコストを支払いつつ、「人手が多ければ仕事が速い」という速度の恩恵を受けられないことを意味します。

モード3：エージェントチーム (Agent teams)

大規模な作業が複数の並列サブタスクに分解可能であり、かつこれらのタスクが長時間の独立した完了を要する場合、「リーダーによる業務配分」の階層制は硬直しすぎてしまいます。

コーディネーター（Coordinator）は、独立したプロセスとして動作する複数のチームメンバー（Teammates）を作成します。これらのメンバーは共有されたタスクキューから自ら「注文」を受け取り、受領後には多段階の操作を自律的に完了し、終了時にシグナルを送ります。

このパターンと「スケジューラ-サブエージェント」模式の最大の違いは、メンバーの永続性にあります。スケジューラは通常、小さなタスクのために一時的にサブエージェントを呼び出し、完了後に解散させます。しかし、チーム模式ではメンバーは長期的に存在し、タスクを引き受ける過程でドメイン知識やコンテキストを蓄積し、経験を積むにつれて熟練していきます。コーディネーターはタスクの割り当てと結果の回収のみを行い、各タスク完了後にメンバーの記憶をクリアすることはありません。

例えば、巨大なコードベースをあるフレームワークから別のフレームワークへ移行する場合を考えます。各チームメンバーは、独立して1つのサービスモジュールの移行を担当し、依存関係の処理、コード修正、テストバグの修復、検証を自分で行います。コーディネーターはモジュールをメンバーに分配し、メンバーはその一連の移行プロセスを自律的に完了します。最後にコーディネーターはすべての移行済みモジュールを集め、システムレベルの統合テストを実行します。

サブタスクが互いに独立しており、多段階かつ長時間の処理を必要とする場合、この模式が最も効果的です。各メンバーは毎回新人のように振る舞うのではなく、自身の小さな領域での経験を蓄積し続けるためです。

「独立性」はこの模式の生命線であり、同時に弱点でもあります。スケジューラ模式のように調整役が仲介して情報を共有するのではなく、チームメンバーは各自黙々と作業を行うため、中間進捗を互いに共有することは困難です。もしAの作業がBに影響を与える場合、両者がそれを認識していなければ、最終的な出力で競合が発生する可能性があります。

進捗管理も頭痛の種です。作業完了までの時間がメンバーによって異なり、2分で終わるものもあれば20分かかるものもあるため、コーディネーターはこうした「ばらつきのある」部分的な完了状態を忍耐強く処理する必要があります。

さらに、共有リソースの競合が発生すると問題が深刻化します。複数のメンバーが同時に同じコードベース、データベース、またはファイルを変更する場合、2人が同じファイルを編集したり、互いに矛盾する変更を行ったりすることが容易に発生します。これに対応するためには、タスク割り当て時に明確な境界線（「楚河漢界」）を定め、競合解決メカニズムを準備しておく必要があります。

模式四：メッセージバス (Message bus)

エージェントの数が増加するにつれて、相互に連携する方法は複雑さを増し、直接対話による通信は破滅的なものになりかねません。そこで登場するのがメッセージバス (Message bus) です：これは共有の通信ホールを提供し、エージェントが「公開（Publish）」と「購読（Subscribe）」を通じて作業を調整できるようにします。

エージェントは公開（Publish）と購読（Subscribe）という2つの基本的な動作のみで通信を行います。エージェントは関心のある「トピック」を購読し、ルーター（Router）が関連するメッセージを正確に配信します。（注：これは大規模な企業チャットグループで、誰かがニーズを投稿し、関連部門の担当者がそれを見て自動的に引き受けることに似ています。誰が注文を引き受けたかを知る必要はありません。）将来、新機能を持つエージェントが参加した場合、それらは関連するトピックを購読するだけで直接業務を開始でき、既存のネットワーク構成を変更する必要はありません。

自動化されたセキュリティ運用システムは、この模式にとって完璧な舞台です。さまざまなチャネルから警报が雪崩のように届きます。「トリアージエージェント」は重大度とタイプを評価し、高リスクのネットワーク警报を「ネットワーク調査エージェント」に送り、「アカウント関連警报」を「アイデンティティ分析エージェント」に送ります。調査エージェントが作業中、「より多くの背景情報が必要」というメッセージを公開することがあり、インテリジェンス収集を担当する専用エージェントがそれを見て支援します。最後に、すべての発見は「レスポンスコーディネーションエージェント」に流れ、そこで最終的な処理方針が決定されます。

このパイプラインはまさにメッセージバス用に設計されています：イベントは前のステージから次のステージへスムーズに流れ、新しい脅威が登場すればチームはいつでも新たなセキュリティエージェントを追加でき、各エージェントの開発とデプロイメントも互いに干渉することなく進められます。

システムがイベント駆動型のパイプライン（ワークフローは固定された順序ではなく、突発的なイベントによって決定される）であり、かつエージェントチームが今後さらに拡大する見込みがある場合、このパターンを選択します。

このイベント駆動型の通信はあまりにも柔軟であるため、問題のトラブルシューティングが非常に困難になります。あるアラートがドミノ倒しのように5つのエージェントの連鎖反応を引き起こした場合、中間で何が起こったのかを把握するには、非常に詳細なログ記録を確認し、それらを関連付けて比較する必要があります。これは「オーケストレーター」に従って順番にバグを追跡するよりもはるかに苦痛です。

ルーターの分发（ルーティング）精度も極めて重要です。もしルーターがメッセージを誤って分類したり、完全に送信し忘れたりした場合、システムは「サイレントクラッシュ（静かなる停止）」に陥します。エラーは発生せず、システムもダウンしませんが、何もしない状態になります。大規模言語モデル（LLM）に基づくルーターは意味理解において柔軟性が高い反面、LLM固有の失敗リスク（解釈の偏りやハルシネーションなど）も伴います。

パターン5：共有状態 (Shared state)

前述のどのパターン（オーケストレーター、コーディネーター、ルーター）においても、本質的には情報フローの「仲介者」が機能しています。一方、共有状態 (Shared state) パターンは仲介者を完全に排除し、すべてのエージェントが永続的なストレージ領域（データベース、ファイルシステム、またはドキュメントなど）を共有してアクセスできるようにします。各エージェントはそこから直接情報を読み取り、結果を書き込むことができます。

このパターンでは「中央指揮官」は存在しません。エージェントたちは公共の黒板の前で作業しているかのように振る舞います：黒板上の线索（手がかり）を確認し、自分たちが処理できるものを取得して作業を行い、新しい発見があればそれを黒板に書き戻します。通常、起動プロセスは黒板上に大きな問題文を書くか、初期データを一括配置することで行われます。特定の終了条件が満たされた時点で作業は停止します。例えば、時間切れになった場合、誰も新しい発見をしなくなった場合（収束閾値）、または特定のエージェントが「黒板上の答えは十分良い」と宣言した場合などです。

分野横断的な総合調査を担当するシステムを想像してみてください。複雑な問題を調べるために、あるエージェントは学術論文を検索し、別のエージェントは業界レポートを確認し、さらに別のエージェントは特許文献を解析し、また別のエージェントがニュース動向を追跡します。各エージェントが調査した内容は、他者にとって重要な线索となる可能性があります。例えば、学術論文を検索するエージェントが核心研究者を偶然発見した場合、業界レポートを確認するエージェントは直ちにその研究者の背後にある企業を深く掘り下げることができます。

共有状態では、すべての発見が直接黒板に記録されます。業界レポートを確認するエージェントは、学術論文を検索するエージェントの新しい発見を即座に確認でき、コーディネーターを介して情報をやり取りする必要はありません。各エージェントは互いの成果を活用しながら進歩し、この共有黒板は次第に進化し続ける知識ベースへと変貌していきます。

このパターンのもう一つの利点は、単一障害点（Single Point of Failure）を排除できることです。あるエージェントがダウンしても、他のエージェントは黒板に対して読み書きを続けることができます。しかし、オーケストレーションパターンやメッセージバスパターンでは、指揮官やルーターが機能停止すれば、システム全体が麻痺してしまいます。

統一された指揮系統を失うと、エージェントは容易に同じ作業の繰り返し（輪造り）や、正反対の方向への進捗を引き起こします。例えば、2つのエージェントが偶然にも同じ线索を調査する可能性があります。システムの最終的な振る舞いは、各要素の相互作用によって生み出されるものであり、上から下へ設計されたものではないため、結果の予測が困難になります。

最も致命的な故障モードは、「反応型ループ（Reactive loops）」に陥ることです。例えば、エージェントAが一つの発見を記録し、それを見たエージェントBが補足を追加し、その補足を見たAがさらに返信する……という状況です。システム全体がまるで2つのロボットが無限にネストされたチャットを行い、高価な計算リソース（トークン）を浪費しながらも結論に到達しない状態になります。重複作業や並行書き込みに対しては、ロックの追加、バージョン管理、パーティショニングなど、エンジニアリング界には確立された解決策があります。しかし、「無限のネスト」というのは動作パターンに関する問題であり、システム設計の初期段階で「一票否决」の終了条件を定義する必要があります。具体的には、固定された時間予算を与える、連続数ラウンドで新たな発見がない場合に強制停止する、あるいは「審判者」エージェントを配置して回答が完結したかどうかを随時判定させるなどの方法があります。（注：終了メカニズムの設計を無視すると、システムは破産するまで無限ループに陥るか、あるいはあるエージェントの脳（コンテキストウィンドウ）が溢れてシステムがクラッシュします。）

どのパターンを選ぶかは、システムに対するいくつかの核心的な構造的問題への判断に依存します。以前の投稿で私たちは、「コンテキスト中心型分解（Context-centric decomposition）」を提唱しました。これは、エージェントが「どのような種類の作業を行うか」ではなく、「どの背景情報を必要とするか」という観点で役割を分担するアプローチです。この原則は今回の議論でも同様です。これら5つのパターンの最大の違いは、コンテキストの境界をどのように区切り、情報の流れを管理するかという点にあります。

オーケストレーション - サブエージェント vs. エージェントチーム

両者には「作業の割り当て」を行うコーディネーターが存在します。どう選べばよいでしょうか？ 次の問いに自問してください：作業を行うエージェントは、長期間にわたって記憶（コンテキスト）を保持する必要があるか？

オーケストレーション - サブエージェントを選ぶ場合：サブタスクが短く、焦点が絞られており、出力が明確な場合に適しています。コードレビューシステムがその例です。各チェックは単発的であり、分析を実行しレポートを生成して提出するだけです。サブエージェントは複数のタスク間で記憶を保持する必要はありません。

エージェントチームを選ぶ場合：サブタスクが複数のステップにまたがり、長期的な処理を経て成果が出る場合に適しています。コードベースの移行がその例です。メンバーは同じサービスモジュールと長期間向き合い、依存関係、テストの法則、デプロイ設定などを徐々に把握していきます。こうした蓄積された背景知識は、「使い捨て」のオーケストレーションモードでは提供できません。

サブエージェントが複数回の起動間で以前の状態を記憶する必要がある場合、エージェントチームの方が適した選択肢となります。

オーケストレーション - サブエージェント vs. メッセージバス

両者ともマルチステップワークフローを処理できます。どう選べばよいでしょうか？ 次の問いに自問してください：あなたのワークフローは事前に予測可能か？

オーケストレーション - サブエージェントを選ぶ場合：ステップが事前に決定されている場合に適しています。コードレビューシステムのように、常に同じ3つの手順（コミットリクエストの受信、チェックの実行、結果の集計）が繰り返されます。

メッセージバスを選ぶ場合：ワークフローが突発的なイベントによってトリガーされ、方向性が常に変化する可能性がある場合に適しています。セキュリティ運用システムは、次に来るアラートや展開すべき調査を事前に予測できません。さらには、新しいタイプのアラートを随時受け入れる必要すらあります。メッセージバスは、イベントを処理可能なエージェントにプッシュすることでこうした変数に対応し、固定されたシナリオに縛られません。

特殊なケースが増えるにつれて「オーケストレーター」内のIf-Else分岐が肥大化している場合、それはメッセージバスへ移行し、分散メカニズムをより明確かつ拡張可能にする時期です。

両方のパターンにおけるエージェントは自律的に作業を行います。どう選べばよいでしょうか？ 次の問いに自問してください：エージェント同士は互いに答え合わせや参照を行う必要があるか？

エージェントチームの選択：各メンバーが自分の領域だけを守り、互いに干渉しない場合。コードリポジトリの移行では、各人が自分のサービスを担当し、最後に統合してマージすればよい。

共有状態の選択：これは高度な協調が必要なタスクであり、手がかりがリアルタイムで流れる必要がある場合。総合研究システムが非常に適している。論文を読むエージェントに新しい発見があれば、業界を分析するエージェントはすぐにそれを利用できる。

チームメンバーが単に作業完了時に結果をまとめ合うだけでなく、作業中に頻繁に情報交換を行う必要がある場合、すぐに共有状態パターンに変更すべきだ。これにより、コミュニケーションがはるかにスムーズになる。

両方とも複雑なマルチエージェント協調を処理することに優れている。どう選ぶか？自分に問うてみよ：タスクはイベントを一つずつ解決するアセンブリラインのようなものか、それとも知識ベースをゆっくりと構築するためのものか？

メッセージバスの選択：エージェントがアセンブリライン上のイベントに反応する場合。セキュリティシステムは連鎖的に動作し、前のステップが処理されて初めて次のステップがトリガーされる。このパターンは「正確なタスク割り当て」に非常に強い。

共有状態の選択：エージェントが蓄積された手がかりに基づいて継続的に深く掘り下げる場合。総合研究システムは知識を絶えず集約している。エージェントたちは何度もホワイトボードの前に戻り、他の人が何を見つけ出したかを確認し、自分の調査方向を調整する。

覚えておこう。メッセージバスには依然として「ルーター」が中心にあり、誰がタスクを引き受けるかを決めている。一方、共有状態は完全に分散型だ。「単一障害点」を排除することに非常に注力している場合、共有状態が最大の安心感をもたらす。

さらに、メッセージバスシステムにおいて、メンバーが情報を公開する主な目的が「他のアクションをトリガーすること」ではなく「情報の共有」である場合、それは選択ミスだ。そのような作業には共有状態パターンの方が適している。

実際のビジネス環境（プロダクション環境）では、これらのパターンを混在させて使用することが多い。一般的な組み合わせとしては、大まかなワークフローに「オーケストレーター - サブエージェント」を使用し、多くの協調が必要なサブタスク内で「共有状態」を適用するケースがある。また、一部のシステムではイベントの配布にメッセージバスを使用し、各イベント処理の末端にエージェントチームを接続する。これらのパターンは本質的にレゴブロックのようなもので、互いに排他的ではない。

以下の表は、各種パターンの適用シーンをまとめたものである：

出力の品質を重視し、明確な評価基準がある場合

ジェネレーター - ベリファイア (Generator-Verifier)

タスクの分解が明確で、サブタスクの境界がはっきりしており、短く迅速な場合

オーケストレーター - サブエージェント (Orchestrator-Subagent)

作業量が並列化可能で、サブタスクが独立しており、長時間実行が必要な場合

エージェントチーム (Agent Teams)

イベント駆動型のパイプラインであり、エージェントエコシステムが成長し続けている場合

メッセージバス (Message Bus)

協調型研究であり、エージェント間で新しい発見を頻繁に共有する必要がある場合

共有状態 (Shared State)

単一障害点によるシステム停止が絶対に許されない場合

共有状態 (Shared State)

大多数の初期段階にあるニーズに対して、「オーケストレーター - サブエージェント (Orchestrator-subagent)」から始めることを強く推奨する。これは極めて低い調整コストで、最も広範な問題を解決できる。まずこれを実行してシステムがどこで瓶颈を起こすかを観察し、その後、具体的な課題に応じて他のパターンに進化させる。

次の記事では、プロダクションレベルの実例を交え、各パターンの具体的な実装方法について深く掘り下げる。もし「なぜマルチエージェントシステムに投資する価値があるのか、いつ使うべきか」を振り返りたい場合は、『マルチエージェントシステムの構築：いつ、どのようにそれらを使用するか』を参照されたい。

本記事はCara Phillipsによって執筆され、Eugene Yang、Jiri De Jonghe、Samuel Weller、およびErik Schluntzが寄稿している。