マルチエージェントアーキテクチャパターン
マルチエージェントアーキテクチャは、複数の言語モデルインスタンスにワークを分散し、それぞれが独自のコンテキストウィンドウを持ちます。適切に設計されれば、この分散により単一エージェントの限界を超える機能が実現します。設計が不適切だと、調整のオーバーヘッドがメリットを打ち消します。重要な洞察は、サブエージェントは主にコンテキストを分離するために存在するのであって、役割を擬人化するためではないということです。
アクティブ化の条件
以下の場合にこのスキルをアクティブにします:
- 単一エージェントのコンテキスト制限がタスクの複雑さを制約する場合
- タスクが自然に並列サブタスクに分解できる場合
- 異なるサブタスクに異なるツールセットやシステムプロンプトが必要な場合
- 複数のドメインを同時に処理するシステムを構築する場合
- エージェント機能を単一コンテキストの限界を超えてスケーリングする場合
- 複数の特殊化されたコンポーネントを持つ本番エージェントシステムを設計する場合
以下の隣接する作業にはこのスキルをアクティブにしないでください:
- トポロジが決まる前のタスクとモデルの適合性、パイプラインの形状、プロジェクトレベルのコストの決定:
project-development。 - ホステッドサンドボックス、ウォームプール、リモートセッション、バックグラウンドランタイムインフラの設計:
hosted-agents。 - 制御されたランタイムでのKVキャッシュ圧縮によるオーケストレーター状態の共有:
latent-briefing。 - 各エージェントが公開するツールの設計:
tool-design。
コアコンセプト
単一エージェントのコンテキストウィンドウがタスク関連情報をすべて保持できない場合に、マルチエージェントパターンを使用します。コンテキスト分離が主なメリットです。各エージェントはクリーンなコンテキストで動作し、他のサブタスクからのノイズが蓄積されません。これにより、情報が繰り返しの要約で劣化する電話ゲーム問題を防ぎます。
調整の必要性に基づいて、3つの主要なパターンから選択します。組織のメタファーではありません:
- スーパーバイザー/オーケストレーター — タスクが明確に分解され、人間による監視が重要な場合に、集中制御のために使用します。単一のコーディネーターが専門家に委任し、結果を統合します。
- ピアツーピア/スウォーム — 厳格な計画が逆効果になる柔軟な探索のために使用します。どのエージェントも明示的なハンドオフメカニズムを通じて他のエージェントに制御を移せます。
- 階層型 — 抽象化の階層（戦略、計画、実行）を持つ大規模プロジェクトに使用します。各層は独自のコンテキスト構造で異なる詳細レベルで動作します。
すべてのマルチエージェントシステムは、明示的な調整プロトコル、お世辞に抵抗する合意メカニズム、エラー伝播のカスケードを防ぐ障害処理を中心に設計します。
詳細トピック
なぜマルチエージェントアーキテクチャか
コンテキストボトルネック 単一エージェントのコンテキストが、蓄積された履歴、取得されたドキュメント、ツール出力で満たされ、パフォーマンスが低下するポイントに達したら、マルチエージェントアーキテクチャに手を伸ばします。3つの低下シグナルを認識します: lost-in-middle効果（コンテキスト中央のコンテンツへの注意が弱まる）、注意不足（競合するアイテムが多すぎる）、コンテキスト汚染（無関係なコンテンツが有用なコンテンツを追い出す）です。
複数のコンテキストウィンドウにワークを分割し、各エージェントがサブタスクに集中したクリーンなコンテキストで動作するようにします。単一のコンテキストが全負荷を負うことなく、調整レイヤーで結果を集約します。
トークン経済の現実 大幅に高いトークンコストを予算化します。本番データによると、マルチエージェントシステムは単一エージェントチャットよりもはるかに多くのトークンを消費する可能性があります（claim-multi-agent-token-multiplier）:
| アーキテクチャ | トークン倍率 | ユースケース |
|---|---|---|
| 単一エージェントチャット | ベースライン | シンプルなクエリ |
| ツール付き単一エージェント | ベースラインより高い | ツールを使用するタスク |
| マルチエージェントシステム | ベースラインよりはるかに高い | 複雑な調査/調整 |
閲覧エージェントの評価研究によると、トークン使用量、ツール呼び出し、モデル選択がパフォーマンスのばらつきの大部分を占めます（claim-evaluation-browsecomp-variance）。これは、追加のエージェントが役立つと仮定するのではなく、マルチエージェント設定を単一エージェントのベースラインと測定することを支持します。
アーキテクチャ設計とともにモデル選択を優先します。より良いモデルにアップグレードすると、トークン予算を2倍にするよりも大きなパフォーマンス向上が得られることがよくあります。BrowseCompのデータは、モデルの品質向上が生のトークン増加よりも頻繁に優れた結果をもたらすことを示しています。モデル選択とマルチエージェントアーキテクチャを補完的な戦略として扱います。
並列化の議論 並列化可能なサブタスクは、単一のエージェントで順次処理するのではなく、新しいコンテキストを持つ専用エージェントに割り当てます。複数の独立したソースにわたる検索、異なるドキュメントの分析、競合するアプローチの比較を必要とする調査タスクは、並列実行の恩恵を受けます。実際の経過時間は、すべてのサブタスクの合計ではなく、最も長いサブタスクの所要時間に近づきます。
特殊化の議論 各エージェントには、特定のサブタスクに必要なシステムプロンプト、ツール、コンテキストのみを設定します。汎用エージェントはすべての可能な設定をコンテキストに保持する必要があり、注意が希釈されます。特殊化されたエージェントは必要なものだけを保持し、ドメインに最適化されたリーンなコンテキストで動作します。コーディネーターから特殊化されたエージェントへルーティングすることで、組み合わせ爆発を起こさずに特殊化を実現します。
アーキテクチャパターン
パターン1: スーパーバイザー/オーケストレーター グローバル状態と軌跡を維持し、ユーザーの目的をサブタスクに分解し、適切なワーカーにルーティングする中央エージェントを配置します。
ユーザークエリ -> スーパーバイザー -> [専門家, 専門家, 専門家] -> 集約 -> 最終出力
このパターンを選択するのは、タスクが明確に分解できる場合、ドメイン間の調整が必要な場合、または人間による監視が重要な場合です。
以下のトレードオフを予想します: 厳格なワークフロー制御と容易なヒューマンインザループ介入が可能ですが、スーパーバイザーのコンテキストがボトルネックになり、スーパーバイザーの障害がすべてのワーカーにカスケードし、「電話ゲーム」問題が発生し、スーパーバイザーがサブエージェントの応答を誤って言い換える可能性があります。
電話ゲーム問題とその解決策 スーパーバイザーアーキテクチャは、電話ゲーム問題（LangGraphベンチマーク）により、最初は最適化されたバージョンよりも約50%パフォーマンスが低下すると予想されます。スーパーバイザーはサブエージェントの応答を言い換えるため、パスごとに忠実度が失われます。
これを修正するには、サブエージェントが応答をユーザーに直接渡せるようにするforward_messageツールを実装します:
def forward_message(message: str, to_user: bool = True):
"""
スーパーバイザーの合成なしで、サブエージェントの応答をユーザーに直接転送します。
以下の場合に使用:
- サブエージェントの応答が最終的で完全である場合
- スーパーバイザーの合成が重要な詳細を失う場合
- 応答形式を正確に保持する必要がある場合
"""
if to_user:
return {"type": "direct_response", "content": message}
return {"type": "supervisor_input", "content": message}
サブエージェントがユーザーに直接応答できる場合は、スーパーバイザーよりもスウォームアーキテクチャを優先します。これにより、翻訳エラーが完全に排除されます。
パターン2: ピアツーピア/スウォーム 中央制御を排除し、エージェントが事前定義されたプロトコルに基づいて直接通信できるようにします。どのエージェントも明示的なハンドオフメカニズムを通じて他のエージェントに制御を移せます。
def transfer_to_agent_b():
return agent_b # 関数の戻り値によるハンドオフ
agent_a = Agent(
name="Agent A",
functions=[transfer_to_agent_b]
)
このパターンを選択するのは、タスクが柔軟な探索を必要とする場合、厳格な計画が逆効果になる場合、または要件が動的に発生し事前の分解が不可能な場合です。
以下のトレードオフを予想します: 単一障害点がなく、効果的な幅優先スケーリングが可能ですが、エージェント数の増加に伴い調整の複雑さが増し、中央状態保持者なしでは発散リスクが高まり、堅牢な収束制約が不可欠になります。
状態を渡す明示的なハンドオフプロトコルを定義します。エージェントがコンテキストニーズを受信エージェントに伝達できるようにします。
パターン3: 階層型 エージェントを抽象化の階層に編成します: 戦略（目標定義）、計画（タスク分解）、実行（アトミックタスク）。
戦略層 (目標定義) -> 計画層 (タスク分解) -> 実行層 (アトミックタスク)
このパターンを選択するのは、プロジェクトに明確な階層構造がある場合、ワークフローに管理層が含まれる場合、またはタスクに高レベルの計画と詳細な実行の両方が必要な場合です。
以下のトレードオフを予想します: 関心事の明確な分離と、異なるレベルでの異なるコンテキスト構造のサポートが可能ですが、層間の調整オーバーヘッド、戦略と実行の潜在的なミスアライメント、複雑なエラー伝播パスが発生します。
設計原則としてのコンテキスト分離
コンテキスト分離をマルチエージェントアーキテクチャの主目的として扱います。各サブエージェントは、他のサブタスクからコンテキストを引き継ぐことなく、サブタスクに焦点を当てたクリーンなコンテキストウィンドウで動作する必要があります。
分離メカニズム 各サブタスクに適した分離メカニズムを選択します:
- 完全コンテキスト委任 — プランナーのコンテキスト全体をサブエージェントと共有します。サブエージェントが完全な理解を必要とする複雑なタスクに使用します。サブエージェントは独自のツールと指示を持ちますが、決定のために完全なコンテキストを受け取ります。注: これはコンテキスト分離の目的を部分的に無効にします。
- 指示受け渡し — 関数呼び出しを介して指示を作成します。サブエージェントは必要なものだけを受け取ります。シンプルで明確に定義されたサブタスクに使用します。分離を維持しますが、サブエージェントの柔軟性を制限します。
- ファイルシステムメモリ — エージェントは永続ストレージに対して読み書きを行います。共有状態を必要とする複雑なタスクに使用します。ファイルシステムが調整メカニズムとして機能し、共有状態の受け渡しによるコンテキストの肥大化を回避します。レイテンシと一貫性の課題が生じますが、メッセージパッシングよりもスケーラブルです。
タスクの複雑さ、調整の必要性、許容できるレイテンシに基づいて選択します。デフォルトは指示受け渡しとし、共有状態が必要な場合はファイルシステムメモリにエスカレーションします。サブタスクが本当に必要としない限り、完全コンテキスト委任は避けます。
合意と調整
投票問題 単純な過半数投票は避けます。弱いモデルからの幻覚を、強いモデルからの推論と同等に扱うことになります。介入がなければ、マルチエージェントの議論は、同意への固有のバイアスのために誤った前提で合意に至る可能性があります。
重み付き投票 エージェントの投票を信頼度や専門性で重み付けします。信頼度やドメイン専門知識が高いエージェントは、最終決定でより大きな重みを持つべきです。
ディベートプロトコル 複数ラウンドにわたってエージェントが互いの出力を批評するように構造化します。協調的な合意よりも、敵対的な批評が複雑な推論で高い精度をもたらすことがよくあります。エージェントが正しさよりも協調的であるために同意する、お世辞的な収束に注意します。
トリガーベースの介入 マルチエージェントの相互作用を行動マーカーについて監視します。議論が進展しない場合にストールトリガーをアクティブにします。エージェントが独自の推論なしに互いの回答を模倣する場合にお世辞トリガーを検出します。
フレームワークの考慮事項
異なるフレームワークは、異なる哲学でこれらのパターンを実装します。LangGraphは、明示的なノードとエッジを持つグラフベースのステートマシンを使用します。AutoGenは、GroupChatを使用した会話/イベント駆動型パターンを使用します。CrewAIは、階層的なクルー構造を持つロールベースのプロセスフローを使用します。
実践的なガイダンス
障害モードとその軽減策
障害: スーパーバイザーボトルネック スーパーバイザーはすべてのワーカーからのコンテキストを蓄積し、飽和と劣化の影響を受けやすくなります。
ワーカーの出力スキーマを制約して、ワーカーが要約された結果のみを返すようにすることで軽減します。チェックポイントを使用して、コンテキストに完全な履歴を保持せずにスーパーバイザーの状態を永続化します。
障害: 調整オーバーヘッド エージェント間の通信はトークンを消費し、レイテンシを増加させます。複雑な調整は並列化のメリットを無効にする可能性があります。
明確なハンドオフプロトコルを通じて通信を最小限に抑えることで軽減します。可能な場合は結果をバッチ処理します。非同期通信パターンを使用します。マルチエージェント調整が、より長いコンテキストを持つ単一エージェントと比較して実際に時間を節約しているかどうかを測定します。
障害: 発散 中央調整なしに異なる目標を追求するエージェントは、意図された目的から逸脱します。
各エージェントに明確な目標境界を定義することで軽減します。共有目標への進捗を検証する収束チェックを実装します。無限の探索を防ぐために、エージェント実行に有効期限（TTL）を設定します。
障害: エラー伝播 あるエージェントの出力のエラーが、その出力を消費する下流のエージェントに伝播し、結果的にますます間違った結果へと拡大します。
消費者に渡す前にエージェント出力を検証することで軽減します。サーキットブレーカーを備えたリトライロジックを実装します。可能な場合は冪等な操作を使用します。重要な出力がパイプラインに入る前にクロスチェックする検証エージェントの追加を検討します。
例
例1: リサーチチームアーキテクチャ
スーパーバイザー
├── リサーチャー (ウェブ検索、ドキュメント取得)
├── アナライザー (データ分析、統計)
├── ファクトチェッカー (検証、妥当性確認)
└── ライター (レポート生成、フォーマット)
例2: ハンドオフプロトコル
def handle_customer_request(request):
if request.type == "billing":
return transfer_to(billing_agent)
elif request.type == "technical":
return transfer_to(technical_agent)
elif request.type == "sales":
return transfer_to(sales_agent)
else:
return handle_general(request)
ガイドライン
- コンテキスト分離をマルチエージェントシステムの主なメリットとして設計する
- アーキテクチャパターンは組織のメタファーではなく、調整の必要性に基づいて選択する
- 状態を渡す明示的なハンドオフプロトコルを実装する
- 合意には重み付き投票またはディベートプロトコルを使用する
- スーパーバイザーボトルネックを監視し、チェックポイントを実装する
- エージェント間で受け渡す前に出力を検証する
- 無限ループを防ぐために有効期限（TTL）を設定する
- 障害シナリオを明示的にテストする
注意点
- スーパーバイザーボトルネック - スーパーバイザーはすべてのワーカー出力をコンテキストに保持する。ワーカー出力スキーマを制約し、チェックポイントを使用する。
- 電話ゲーム問題 - スーパーバイザーはサブエージェント出力を誤って言い換える。転送ツールを使用するか、スウォームパターンを採用する。
- コストの増加 - マルチエージェントシステムは非常に多くのトークンを消費する可能性がある。常に単一エージェントのベースラインに対して測定する。
- お世辞的な合意 - エージェントは互いに同意する傾向がある。重み付き投票またはディベートプロトコルを使用する。
- エラー伝播 - あるエージェントのエラーがシステム全体に拡大する可能性がある。出力を検証し、リトライロジックを実装する。
- 無限ループ - 適切な有効期限（TTL）なしでは、エージェントは無限にループする可能性がある。常にタイムアウトを設定する。