multi-agent-patterns

マルチエージェントアーキテクチャパターン

マルチエージェントアーキテクチャは、それぞれが独自のコンテキストウィンドウを持つ複数の言語モデルインスタンスに作業を分散します。うまく設計すれば、この分散によって単一エージェントの限界を超える能力が実現します。設計が不適切であれば、調整のオーバーヘッドが生じ、利点が打ち消されます。重要な洞察は、サブエージェントは主にコンテキストを分離するために存在するのであり、役割分担を擬人化するためではないということです。

使用すべき場面

以下の場合にこのスキルを有効にします。

• 単一エージェントのコンテキスト限界がタスクの複雑さを制約している
• タスクが自然に並列サブタスクへ分解できる
• 異なるサブタスクが異なるツールセットやシステムプロンプトを必要とする
• 複数のドメインを同時に処理する必要があるシステムを構築する
• エージェントの能力を単一コンテキストの限界を超えて拡張する
• 複数の専門化されたコンポーネントを持つ本番エージェントシステムを設計する

中核となる概念

マルチエージェントシステムは、分散によって単一エージェントのコンテキスト制約に対処します。支配的なパターンは3つあります。集中的な制御を行うスーパーバイザー/オーケストレーター、柔軟なハンドオフを行うピアツーピア/スウォーム、そして階層的な抽象化を行う階層型です。重要な設計原則はコンテキストの分離であり、サブエージェントは組織上の役割を模倣するためではなく、主にコンテキストを分割するために存在します。

効果的なマルチエージェントシステムには、明示的な調整プロトコル、お世辞を避ける合意メカニズム、そしてボトルネック、発散、エラーの伝播といった障害モードへの注意深い配慮が求められます。

詳細なトピック

マルチエージェントアーキテクチャを採用する理由

コンテキストのボトルネック 単一のエージェントは、推論能力、コンテキスト管理、ツール連携において本質的な限界に直面します。タスクが複雑になるにつれて、コンテキストウィンドウは蓄積された履歴、取得されたドキュメント、ツールの出力で埋まっていきます。パフォーマンスは予測可能なパターンに従って低下します。それは、lost-in-the-middle 効果、注意の希薄化、コンテキストポイズニングです。

マルチエージェントアーキテクチャは、複数のコンテキストウィンドウに作業を分割することで、こうした制約に対処します。各エージェントは、自身のサブタスクに集中したクリーンなコンテキストで動作します。結果は調整レイヤーで集約され、どの単一のコンテキストも全負荷を負うことはありません。

トークンエコノミクスの現実 マルチエージェントシステムは、単一エージェントのアプローチよりもはるかに多くのトークンを消費します。本番データは次のことを示しています。

アーキテクチャ	トークン倍率	ユースケース
単一エージェントチャット	1× ベースライン	単純なクエリ
ツール付き単一エージェント	約 4× ベースライン	ツールを使用するタスク
マルチエージェントシステム	約 15× ベースライン	複雑な調査・調整

BrowseComp 評価に関する研究では、パフォーマンスの分散の 95% を 3 つの要因が説明することが判明しました。それは、トークン使用量（分散の 80%）、ツール呼び出しの回数、モデルの選択です。これは、並列推論のための容量を追加するために、別々のコンテキストウィンドウを持つエージェント間で作業を分散するというマルチエージェントのアプローチを裏付けています。

重要な点として、より優れたモデルへアップグレードすることは、トークン予算を倍増させるよりも大きなパフォーマンス向上をもたらすことがしばしばあります。Claude Sonnet 4.5 は、以前の Sonnet バージョンでトークンを倍増させるよりも大きな向上を示しました。GPT-5.2 の思考モードも同様に、生のトークン増加を上回る性能を発揮します。これは、モデルの選択とマルチエージェントアーキテクチャが補完的な戦略であることを示唆しています。

並列化の論拠 多くのタスクには、単一のエージェントでは逐次実行しなければならない並列化可能なサブタスクが含まれています。調査タスクでは、複数の独立した情報源を検索したり、異なるドキュメントを分析したり、競合するアプローチを比較したりする必要があるかもしれません。単一のエージェントはこれらを逐次的に処理し、各ステップでコンテキストを蓄積していきます。

マルチエージェントアーキテクチャは、各サブタスクを新規のコンテキストを持つ専用のエージェントに割り当てます。すべてのエージェントが同時に動作し、その後、結果をコーディネーターに返します。実時間での合計は、すべてのサブタスクの合計ではなく、最も長いサブタスクの所要時間に近づきます。

専門化の論拠 異なるタスクは、異なるエージェント構成から恩恵を受けます。それは、異なるシステムプロンプト、異なるツールセット、異なるコンテキスト構造です。汎用エージェントは、考えられるすべての構成をコンテキストに保持しなければなりません。専門化されたエージェントは、必要なものだけを保持します。

マルチエージェントアーキテクチャは、組み合わせ爆発を起こすことなく専門化を可能にします。コーディネーターは専門化されたエージェントへルーティングし、各エージェントはその領域に最適化された無駄のないコンテキストで動作します。

アーキテクチャパターン

パターン 1: スーパーバイザー/オーケストレーター スーパーバイザーパターンでは、中央のエージェントが制御を担い、専門エージェントに委任して結果を統合します。スーパーバイザーはグローバルな状態と軌跡を維持し、ユーザーの目的をサブタスクに分解し、適切なワーカーにルーティングします。

User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output

使用すべき場面: 明確に分解できる複雑なタスク、複数のドメインにまたがる調整が必要なタスク、人間による監督が重要なタスク。

利点: ワークフローを厳密に制御できる、human-in-the-loop の介入を実装しやすい、事前定義された計画の遵守を確実にする。

欠点: スーパーバイザーのコンテキストがボトルネックになる、スーパーバイザーの障害がすべてのワーカーに連鎖する、スーパーバイザーがサブエージェントの応答を誤って言い換える「伝言ゲーム」問題。

伝言ゲーム問題とその解決策 LangGraph のベンチマークでは、スーパーバイザーアーキテクチャは、スーパーバイザーがサブエージェントの応答を誤って言い換えて忠実性を失う「伝言ゲーム」問題により、当初は最適化されたバージョンより 50% 性能が低いことが判明しました。

解決策: サブエージェントが応答をユーザーに直接渡せるようにする forward_message ツールを実装します:

def forward_message(message: str, to_user: bool = True):
    """
    Forward sub-agent response directly to user without supervisor synthesis.
    
    Use when:
    - Sub-agent response is final and complete
    - Supervisor synthesis would lose important details
    - Response format must be preserved exactly
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

このパターンでは、サブエージェントがユーザーに直接応答するため翻訳エラーが排除され、スウォームアーキテクチャがスーパーバイザーをわずかに上回ります。

実装上の注意: 適切な場合には、サブエージェントがスーパーバイザーの統合を経由せずに応答をユーザーへ直接渡せるようにする直接パススルー機構を実装してください。

パターン 2: ピアツーピア/スウォーム ピアツーピアパターンは中央制御を排除し、事前定義されたプロトコルに基づいてエージェント同士が直接通信できるようにします。どのエージェントも、明示的なハンドオフ機構を通じて他の任意のエージェントに制御を移譲できます。

def transfer_to_agent_b():
    return agent_b  # Handoff via function return

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

使用すべき場面: 柔軟な探索が必要なタスク、厳格な計画が逆効果になるタスク、事前の分解が難しい創発的な要件を伴うタスク。

利点: 単一障害点がない、幅優先の探索に対して効果的にスケールする、創発的な問題解決行動を可能にする。

欠点: エージェント数が増えるにつれて調整の複雑さが増大する、中央の状態保持者がないと発散するリスクがある、堅牢な収束制約が必要。

実装上の注意: 状態の受け渡しを伴う明示的なハンドオフプロトコルを定義してください。エージェントが自身のコンテキストの必要性を受け取り側のエージェントに伝えられるようにしてください。

パターン 3: 階層型 階層構造は、エージェントを抽象化の層に整理します: 戦略層、計画層、実行層です。戦略層のエージェントは目標と制約を定義し、計画層のエージェントは目標を実行可能な計画に分解し、実行層のエージェントはアトミックなタスクを実行します。

Strategy Layer (Goal Definition) -> Planning Layer (Task Decomposition) -> Execution Layer (Atomic Tasks)

使用すべき場面: 明確な階層構造を持つ大規模プロジェクト、管理層を伴うエンタープライズワークフロー、高レベルの計画と詳細な実行の両方を必要とするタスク。

利点: 組織構造を反映している、関心の分離が明確、異なるレベルで異なるコンテキスト構造を可能にする。

欠点: 層間の調整オーバーヘッド、戦略と実行の間の不整合の可能性、複雑なエラー伝播。

設計原則としてのコンテキスト分離

マルチエージェントアーキテクチャの主な目的は、コンテキストの分離です。各サブエージェントは、他のサブタスクから蓄積されたコンテキストを持ち込むことなく、自身のサブタスクに集中したクリーンなコンテキストウィンドウで動作します。

分離のメカニズム 完全なコンテキスト委譲: サブエージェントが完全な理解を必要とする複雑なタスクでは、プランナーが自身のコンテキスト全体を共有します。サブエージェントは独自のツールと指示を持ちますが、意思決定のために完全なコンテキストを受け取ります。

指示の受け渡し: 単純で明確に定義されたサブタスクでは、プランナーが関数呼び出しを介して指示を作成します。サブエージェントは、その特定のタスクに必要な指示のみを受け取ります。

ファイルシステムメモリ: 共有状態を必要とする複雑なタスクでは、エージェントが永続ストレージに対して読み書きを行います。ファイルシステムが調整メカニズムとして機能し、共有状態の受け渡しによるコンテキストの肥大化を回避します。

分離のトレードオフ 完全なコンテキスト委譲は最大限の能力を提供しますが、サブエージェントの目的を損なうことになります。指示の受け渡しは分離を維持しますが、サブエージェントの柔軟性を制限します。ファイルシステムメモリはコンテキストの受け渡しなしに共有状態を可能にしますが、レイテンシと一貫性の問題が生じます。

適切な選択は、タスクの複雑さ、調整の必要性、許容できるレイテンシによって決まります。

コンセンサスと調整

投票の問題 単純な多数決投票は、弱いモデルによるハルシネーションを、強いモデルによる推論と同等に扱ってしまいます。介入しなければ、マルチエージェントの議論は、合意への生来のバイアスにより、誤った前提へのコンセンサスに陥ってしまいます。

重み付け投票 エージェントの投票に信頼度や専門性に基づく重みを付けます。信頼度やドメインの専門性が高いエージェントは、最終的な意思決定においてより大きな重みを持ちます。

ディベートプロトコル ディベートプロトコルでは、エージェントが複数ラウンドにわたって互いの出力を批判することが求められます。敵対的な批判は、協調的なコンセンサスよりも複雑な推論において高い精度をもたらすことがよくあります。

トリガーベースの介入 マルチエージェントの相互作用を、特定の行動マーカーについて監視します。停滞トリガーは、議論が進展しない場合に作動します。追従トリガーは、エージェントが独自の推論なしに互いの回答を模倣した場合を検出します。

フレームワークに関する考慮事項

異なるフレームワークは、これらのパターンを異なる哲学で実装しています。LangGraph は、明示的なノードとエッジを持つグラフベースのステートマシンを使用します。AutoGen は、GroupChat を用いた会話型／イベント駆動型のパターンを使用します。CrewAI は、階層的なクルー構造を持つロールベースのプロセスフローを使用します。

実践的なガイダンス

障害モードとその緩和策

障害: スーパーバイザーのボトルネック スーパーバイザーはすべてのワーカーからコンテキストを蓄積し、飽和や劣化の影響を受けやすくなります。

緩和策: ワーカーが蒸留された要約のみを返すように、出力スキーマの制約を実装します。チェックポイントを利用して、完全な履歴を持ち込むことなくスーパーバイザーの状態を永続化します。

障害: 調整のオーバーヘッド エージェント間の通信はトークンを消費し、レイテンシを生じさせます。複雑な調整は、並列化の利点を打ち消してしまうことがあります。

緩和策: 明確なハンドオフプロトコルを通じて通信を最小化します。可能な場合は結果をバッチ処理します。非同期の通信パターンを使用します。

障害: 逸脱 中央の調整なしに異なる目標を追求するエージェントは、意図された目的から逸脱する可能性があります。

緩和策: 各エージェントに対して明確な目標の境界を定義します。共有目標に向けた進捗を検証する収束チェックを実装します。エージェントの実行に生存時間制限を使用します。

障害: エラーの伝播 あるエージェントの出力におけるエラーは、その出力を消費する下流のエージェントに伝播します。

緩和策: コンシューマーに渡す前にエージェントの出力を検証します。サーキットブレーカーを備えたリトライロジックを実装します。可能な場合は冪等な操作を使用します。

例

例 1: リサーチチームのアーキテクチャ

Supervisor
├── Researcher (web search, document retrieval)
├── Analyzer (data analysis, statistics)
├── Fact-checker (verification, validation)
└── Writer (report generation, formatting)

例 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)

ガイドライン

1. マルチエージェントシステムの主要な利点として、コンテキストの分離を設計する
2. 組織のメタファーではなく、連携の必要性に基づいてアーキテクチャパターンを選択する
3. 状態を引き継ぐ明示的なハンドオフプロトコルを実装する
4. 合意形成には重み付き投票またはディベートプロトコルを使用する
5. スーパーバイザーのボトルネックを監視し、チェックポイントを実装する
6. エージェント間で受け渡す前に出力を検証する
7. 無限ループを防ぐために有効期限を設定する
8. 障害シナリオを明示的にテストする

統合

このスキルは context-fundamentals と context-degradation を基盤としています。以下と連携します:

• memory-systems - エージェント間の共有状態管理
• tool-design - エージェントごとのツールの専門化
• context-optimization - コンテキスト分割戦略

参考資料

内部リファレンス:

• Frameworks Reference - 詳細なフレームワーク実装パターン

このコレクション内の関連スキル:

• context-fundamentals - コンテキストの基礎
• memory-systems - エージェント間メモリ
• context-optimization - 分割戦略

外部リソース:

• LangGraph Documentation - マルチエージェントパターンと状態管理
• AutoGen Framework - GroupChat と会話パターン
• CrewAI Documentation - 階層型エージェントプロセス
• Research on Multi-Agent Coordination - マルチエージェントシステムのサーベイ

---

スキルのメタデータ

作成日: 2025-12-20 最終更新日: 2025-12-20 作者: Agent Skills for Context Engineering Contributors バージョン: 1.0.0

制限事項

• このスキルは、タスクが上記のスコープに明確に一致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、または成功基準が欠けている場合は、停止して確認を求めてください。