第1章：はじめに
前回、AI Agent Jump Start：応用編#2 AIエージェント設計の課題解決：18パターンによる体系的アプローチ では、Agent Design Pattern Catalogueで提示された18のパターン中からシングルAIエージェントのパターンを中心に解説してきました。
今回の記事では、マルチAIエージェントのデザインパターンについて解説します。AIエージェントは単独で複雑な処理をこなすことも可能ですが、適切にエージェントを分けることにより、開発生産性、柔軟性などが向上します。前回ご紹介した18パターン中でマルチエージェントになっているのは、「協調とコラボレーション」の3つのパターンになります。
- 投票ベース協力（Voting-based Cooperation）
- 役割ベース協力（Role-based Cooperation）
- ディベートベース協力（Debate-based Cooperation）
以上の3つのパターンを前回と同様に以下の観点で解説します。 - パターンの意図：問題と解決策の概要
- 解決策の詳細
- メリット・デメリット
その次に、エージェント間の関係性を整理したパターンの紹介とエージェントを連携させるためのプロトコルであるA2Aを紹介します。
第2章：協調とコラボレーションのデザイン・パターン
2.1 投票ベース協力（Voting-based Cooperation）
出典：Agent Design Pattern Catalogue
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | 複数エージェントが多様な意見を持つため、意思決定に公平性や一貫性を欠くリスクがある |
| 解決策 | 各エージェントが候補案や意見を提示し、投票によって合意形成を行う | |
| 適用場面 | ・マルチエージェント協調タスク（同じ課題に複数エージェントが取り組む場合） ・合意形成が不可欠な分野（都市計画、裁判シミュレーション、生成結果の選択） ・多様な知見を統合し、より信頼性の高い決定を導く必要がある状況 |
|
| 解決策の詳細 | 1. 候補案の提示 各エージェントがユーザ要求に応じた応答や解決策を生成。 2. 投票の実施 提示された案に対し、エージェントが多数決・重み付け投票・スコアリングなどの方式で投票 3. 集約と決定 コーディネータ役が投票を集計し、最終案を確定して全体に反映 4. 透明性の確保 投票過程を記録し、追跡可能にすることで公平性と説明責任を担保 |
|
| メリット | 公平性 | 投票プロセスを通じ、全エージェントの意見を反映できる |
| 説明責任 | 投票記録が残るため、監査や追跡が可能 | |
| 集合知 | 複数エージェントの知識を統合し、精度や信頼性が高まる | |
| デメリット | 中央集権化のリスク | 一部のエージェントが影響力を持ちすぎる可能性がある |
| オーバーヘッド | 投票に時間や通信コストがかかる | |
| 操作リスク | 投票方法次第で結果が偏る可能性がある |
2.2 役割ベース協力（Role-based Cooperation）
出典：Agent Design Pattern Catalogue
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | 複数のエージェントが異なる専門性を持つ場合、役割分担が不明確だと効率が下がる |
| 解決策 | 各エージェントに明確な役割（プランナー、アサイナー、ワーカーなど）を割り当て、分業体制を構築する。必要に応じて新しいエージェントを生成し、ワークフローを拡張可能にする | |
| 適用場面 | ・ソフトウェア開発や医療など、複数の専門領域が関与する複雑なタスク ・組織的なワークフローを模倣し、効率的にタスクを遂行したい場面 |
|
| 解決策の詳細 | 1. 役割の明確化 各エージェントに役割を定義する（例： ・プランナー（Planner）：ユーザの要求を受け取り、目標をタスクに分解する ・アサイナー（Assigner）：分解されたタスクを適切なエージェントに割り当てる ・ワーカー（Worker）：実際の作業や処理を実行する ・クリエイター（Creator）：必要な場合、新しい役割を持つエージェントを生成する） 2. 階層的なワークフローの構築 プランナーが計画を立案し、アサイナーがタスクを配分、ワーカーが遂行するという階層的プロセスを確立 3. 動的なエージェント生成 特定の役割に対応するエージェントが存在しない場合、クリエイターが新たなエージェントを作成。作成されたエージェントには初期リソースや目標が与えられ、既存のワークフローに統合される 4. 拡張性と柔軟性の担保 役割は固定的ではなく、タスクや状況に応じて追加・変更可能。新しい役割を持つエージェントを導入することで、システム全体の能力を拡張できる |
|
| メリット | 分業 | 分業により専門性を活かしやすく、効率と精度が向上 |
| フォールトトレランス | 役割を持つ他のエージェントで代替できる | |
| スケーラビリティ | 新しい役割を追加することで容易に拡張可能 | |
| 説明責任 | 役割ごとに責任範囲が明確になる | |
| デメリット | 通信オーバーヘッド | 役割間の調整にコストがかかる |
| コスト増 | 役割の異なるエージェントがサービスとして有料の場合、運用コストが高まる |
2.3 ディベートベース協力（Debate-based Cooperation）
出典：Agent Design Pattern Catalogue
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | 複数エージェントが協力する際、多様な意見をどう整理して合意形成するかが難しい |
| 解決策 | エージェント同士が生成した応答や意見を持ち寄り、討論を通じて相互に検証・修正する。複数ラウンドの議論を経て、最終的に合意した解答を導く | |
| 適用場面 | ・複雑で答えが一つに定まらない問題（政策決定、研究課題の検討など） ・多様な視点や批判的検討が必要なタスク |
|
| 解決策の詳細 | 1.初期応答の生成 ユーザからの質問やタスクに対し、各エージェントが独自に初期応答や提案を生成する 2. 討論の開始 生成した応答をエージェント間で共有し、相互に 批判・検証・補足 を行う 3. 反復的な議論 議論は複数ラウンド繰り返される 4. 合意形成 議論を規定回数まで行うか、あるいはエージェント間で 合意が得られるまで継続する 5. 透明性と記録 議論の過程（各エージェントの意見や反論、合意形成の経緯）は記録される |
|
| メリット | 適応性 | 他のエージェントの意見から学び、推論を進化させられる |
| 説明性 | 議論の記録が残り、根拠や過程を説明可能 | |
| 批判的思考の促進 | 相互の反論により、より精度の高い結論を得やすい | |
| デメリット | 能力依存 | 議論の質は各エージェントの推論・評価能力に左右される |
| プライバシー懸念 | 機密情報を共有できない場合、議論が制約される | |
| オーバーヘッド | 議論が複雑化すると通信・計算コストが増大 | |
| スケーラビリティの制限 | 参加エージェントが増えると調整が難しくなる |
第3章 エージェント間の関係
ここまではマルチエージェントの課題解決視点からデザインパターンを解説してきましたが、ここでは、マルチエージェントのエージェント間の関係について解説します。エージェント間の関係については複数の説明がありますが、ここではLangGraphのマルチエージェント デザインパターン記事 を紹介します。
出典：LangGraph Multi-agent systems
記事では、5つのパターンを説明しています。なお、シングルエージェント(Single Agent)は、マルチエージェントの対比として描かれているのだけのため省略します。
-
ネットワーク型: 各エージェントは他のすべてのエージェントと通信できる。任意のエージェントが、次にどのエージェントを呼び出すかを決定できる。
-
スーパーバイザー型: 各エージェントは単一のスーパーバイザーエージェントと通信する。スーパーバイザーエージェントが、次にどのエージェントを呼び出すべきかを決定する。
-
スーパーバイザー型（ツール呼び出し）: これはスーパーバイザーアーキテクチャの特別なケースである。個々のエージェントをツールとして表現できる。この場合、スーパーバイザーエージェントはツール呼び出し対応のLLMを用いて、どのエージェントツールを呼び出すか、またそのエージェントに渡す引数を決定する。
-
階層型: スーパーバイザーを監督するスーパーバイザーを持つマルチエージェントシステムを定義できる。これはスーパーバイザーアーキテクチャの一般化であり、より複雑な制御フローを可能にする。
-
カスタムマルチエージェントワークフロー: 各エージェントは限定されたサブセットのエージェントとだけ通信する。フローの一部は決定的であり、一部のエージェントだけが次にどのエージェントを呼び出すかを決定できる。
パターンにより他のエージェントを呼び出す条件が違ってきます。そのため、LangGraphを使用する場合は、利用するパターンにより実装の方法が変わってきます。他のエージェント開発フレームワークでも採用パターンにより実装方法に影響を受ける場合があるので、実装前にパターンを決めておく必要があります。これらのパターンは単独で使用するだけでなく、複数のパターンを組み合わせてより複雑なアーキテクチャを実現することも可能です。
なお、他にもエージェント間の関係パターンを解説した説明はあり、似たような分類になっていますがパターン名は異なっていることがあるので注意してください。
第4章 A2A(Agent2Agent)
マルチエージェントのシステムを開発する場合、上記のように複数の連携パターンがあります。１つのシステム（=１つのフレームワーク）上に構築する場合は、他エージェントの呼び出しは利用フレームワークの方法で実装可能です。
しかし、共通処理を行うエージェントや外部サービスのエージェントを呼び出す場合は状況が異なります。別々のシステムで実装されているためエージェントの呼び出し方法も異なり、エージェント連携の開発生産性に影響します。そこでエージェント間で呼び出しプロトコルを共通化する目的で作成されたのが、A2A(Agent2Agent)プロトコルです。エージェントのツール呼び出しでMCPが標準化されたように、エージェント間の呼び出しにおいてはA2Aが標準的な仕様となるでしょう。
出典：Google Announcing the Agent2Agent Protocol (A2A)
A2Aは、Googleが2025年4月に発表した、AIエージェント同士が協調して通信・タスク共有・長期処理を行うためのオープンプロトコルです。HTTP／JSON‑RPC／Server‑Sent Eventsなどを基盤としています。A2Aのプロトコルでは、機能として以下を定義しています。
・エージェント呼び出し（invoke）
・長時間ジョブのハンドリング
・状態の問い合わせ（progress, status, result）
・ストリーミングレスポンス
・双方向通信（将来的には WebSocket も検討中）
・認証・認可のセキュリティ
現在、A2Aの実装プロジェクトはLinux Foundationによって中立的に作業が進められており、今後のマルチエージェントの実装の標準となっていくと考えられています。そのため、各エージェント開発フレームワークや基盤などでこのプロトコルを採用するものが増えていくと思われます。
Discussion