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

マルチエージェント・アーキテクチャは、複数の言語モデル・インスタンスにわたって作業を分散させます。各インスタンスは独自のコンテキスト・ウィンドウを持ちます。適切に設計されたとき、この分散によってシングルエージェント限界を超えた機能が実現します。不十分に設計されたとき、調整オーバーヘッドが利点を相殺します。重要な洞察は、サブエージェントは主に役割の擬人化ではなく、コンテキスト分離のために存在するということです。

使用時機

以下の場合にこのスキルを有効化してください:

• シングルエージェント・コンテキスト限界がタスク複雑度を制約している
• タスクが並列サブタスクに自然に分解できる
• 異なるサブタスクが異なるツールセットまたはシステム・プロンプトを必要とする
• 複数ドメインを同時に処理しなければならないシステムを構築している
• エージェント機能をシングルコンテキスト限界を超えてスケールしている
• 複数の専門部門を持つ本番エージェント・システムを設計している

主要概念

マルチエージェント・システムは、分散によってシングルエージェント・コンテキスト限界に対処します。3つの支配的なパターンが存在します: 集中制御のためのスーパーバイザー/オーケストレータ、柔軟なハンドオフのためのピアツーピア/スワーム、層状抽象化のための階層的。重要な設計原則はコンテキスト分離です。サブエージェントは主に組織的役割をシミュレートするのではなく、コンテキストを分割するために存在します。

効果的なマルチエージェント・システムには、明示的な調整プロトコル、イエスマン化を回避するコンセンサス・メカニズム、ボトルネック、発散、エラー伝播などの障害モードに対する注意深い配慮が必要です。

詳細トピック

マルチエージェント・アーキテクチャが必要な理由

コンテキスト・ボトルネック シングルエージェントは、推論能力、コンテキスト管理、ツール調整の継承的な上限に直面します。タスクがより複雑になるにつれて、コンテキスト・ウィンドウは蓄積された履歴、検索ドキュメント、ツール出力で満杯になります。パフォーマンスは予測可能なパターンに従って低下します: ロストイン・ザ・ミドル効果、アテンション・スカーシティ、コンテキスト・ポイズニング。

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

トークン経済学の現実 マルチエージェント・システムはシングルエージェント・アプローチよりも大幅に多くのトークンを消費します。本番データが示すもの:

アーキテクチャ	トークン乗数	ユースケース
シングルエージェント・チャット	1× ベースライン	シンプルなクエリ
ツール機能付きシングルエージェント	~4× ベースライン	ツール使用タスク
マルチエージェント・システム	~15× ベースライン	複雑な研究/調整

BrowseComp評価の研究によると、3つの要因がパフォーマンス分散の95%を説明します: トークン使用量 (分散の80%), ツール呼び出し数, モデル選択。これはエージェント間で作業を分散し、並列推論のための容量を追加する別個のコンテキスト・ウィンドウを備えたマルチエージェント・アプローチを検証します。

重要なのは、より優れたモデルにアップグレードすることは多くの場合、トークン予算を2倍にするより大きなパフォーマンス向上をもたらします。Claude Sonnet 4.5はトークンを2倍にするより大きな向上を示しました。GPT-5.2のシンキング・モードは同様に生のトークン増加を上回ります。これはモデル選択とマルチエージェント・アーキテクチャが補完戦略であることを示唆します。

並列化議論 多くのタスクは、シングルエージェントが順次実行しなければならない並列化可能なサブタスクを含みます。研究タスクは複数の独立したソースの検索、異なるドキュメントの分析、または競合するアプローチの比較を必要とするかもしれません。シングルエージェントはこれらを順次処理し、各ステップでコンテキストを蓄積します。

マルチエージェント・アーキテクチャは各サブタスクを専用エージェントにフレッシュ・コンテキストで割り当てます。すべてのエージェントは同時に作業し、その後結果をコーディネーターに返します。実時間の総時間は、すべてのサブタスクの合計ではなく、最長サブタスクの継続時間に接近します。

特化議論 異なるタスクは異なるエージェント構成から利益を得ます: 異なるシステム・プロンプト、異なるツールセット、異なるコンテキスト構造。汎用エージェントはすべての可能な構成をコンテキストで保持しなければなりません。特化したエージェントは必要なものだけを保持します。

マルチエージェント・アーキテクチャは組み合わせ爆発なしに特化を有効にします。コーディネーターは専門エージェントにルーティングします; 各エージェントは自身のドメインのために最適化されたリーンなコンテキストで動作します。

アーキテクチャ・パターン

パターン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="エージェント A",
    functions=[transfer_to_agent_b]
)

使用時機: 柔軟な探査を必要とするタスク, 厳格な計画が逆効果なタスク, 事前分解を拒否する創発的要件を持つタスク。

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

欠点: エージェント数の増加とともに調整複雑度が増加する, 中央状態キーパーなしでの発散のリスク, 堅牢な収束制約が必要。

実装上の注記: 状態パッシングで明示的なハンドオフ・プロトコルを定義します。エージェントが受信エージェントにコンテキスト・ニーズを伝える能力を確認します。

パターン3: 階層的 階層的構造は、エージェントを抽象化のレイヤーに組織します: 戦略、計画、実行レイヤー。戦略レイヤー・エージェントは目標と制約を定義します; 計画レイヤー・エージェントは目標を実行可能な計画に分割します; 実行レイヤー・エージェントはアトミック・タスクを実行します。

戦略レイヤー (目標定義) -> 計画レイヤー (タスク分解) -> 実行レイヤー (アトミック・タスク)

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

利点: 組織構造を反映, 関心の明確な分離, 異なるレベルで異なるコンテキスト構造を有効にする。

欠点: レイヤー間の調整オーバーヘッド, 戦略と実行間のミスアラインメントの可能性, 複雑なエラー伝播。

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

マルチエージェント・アーキテクチャの主な目的はコンテキスト分離です。各サブエージェントはクリーンなコンテキスト・ウィンドウで動作し、そのサブタスクに焦点を当て、他のサブタスクから蓄積されたコンテキストを保持しません。

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

指示パッシング: シンプルでよく定義されたサブタスクの場合、プランナーは関数呼び出しを通じて指示を作成します。サブエージェントは特定のタスクのための指示のみを受け取ります。

ファイル・システム・メモリ: 共有状態を必要とする複雑なタスクの場合、エージェントは永続ストレージの読み書きを行います。ファイル・システムは調整メカニズムとして機能し、共有状態パッシングからのコンテキスト・ブロートを回避します。

分離トレードオフ 完全なコンテキスト委任は最大の能力を提供しますが、サブエージェントの目的を打ち消します。指示パッシングは分離を維持しますがサブエージェント柔軟性を制限します。ファイル・システム・メモリはコンテキスト・パッシングなしで共有状態を有効にしますが、レイテンシーと一貫性の課題が生じます。

正しい選択はタスク複雑度、調整ニーズ、許容可能なレイテンシーに依存します。

コンセンサスと調整

投票問題 シンプルな多数決投票は、弱いモデルからの幻覚を強いモデルからの推論と同等に扱います。介入なしで、マルチエージェント・ディスカッションは合意への固有の偏見のため、虚偽の前提についてのコンセンサスに陥ります。

重み付き投票 エージェント投票を信頼度または専門知識で重み付けします。より高い信頼度またはドメイン専門知識を持つエージェントは、最終決定でより多くの重みを持ちます。

討論プロトコル 討論プロトコルは、エージェントが複数ラウンドにわたって互いの出力を批評することを要求します。敵対的な批評は多くの場合、協調的なコンセンサスより複雑な推論でより高い精度を生成します。

トリガーベースの介入 マルチエージェント相互作用を特定の行動マーカーでモニタリングします。停止トリガーは、ディスカッションが進捗を保たないときにアクティブ化します。イエスマン化トリガーは、エージェントが一意の推論なしに互いの答えを模倣するときを検出します。

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

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

実践的ガイダンス

障害モードと緩和

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

緩和: ワーカーが蒸留されたサマリーのみを返すように出力スキーマ制約を実装します。チェックポイントを使用して、完全な履歴を保持せずにスーパーバイザー状態を永続化します。

障害: 調整オーバーヘッド エージェント通信はトークンを消費し、レイテンシーを導入します。複雑な調整は並列化の利点を相殺することができます。

緩和: クリアなハンドオフ・プロトコルを通じた通信を最小化します。可能な場合、結果をバッチ処理します。非同期通信パターンを使用します。

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

緩和: 各エージェントの明確な目的境界を定義します。共有目標への進捗を検証する収束チェックを実装します。エージェント実行の有効期間制限を使用します。

障害: エラー伝播 1つのエージェントの出力エラーが、その出力を消費するダウンストリーム・エージェントに伝播します。

緩和: 消費者に渡す前に、エージェント出力を検証します。サーキット・ブレーカー付き再試行ロジックを実装します。可能な限り冪等操作を使用します。

例

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

ガイドライン

1. マルチエージェント・システムの主な利点としてコンテキスト分離のために設計します
2. 組織的メタファーではなく調整ニーズに基づいてアーキテクチャ・パターンを選択します
3. 状態パッシング付き明示的ハンドオフ・プロトコルを実装します
4. コンセンサスのための重み付き投票または討論プロトコルを使用します
5. スーパーバイザー・ボトルネックをモニタリングし、チェックポイントを実装します
6. エージェント間パッシング前に出力を検証します
7. 無限ループを防ぐための有効期間制限を設定します
8. 障害シナリオを明示的にテストします

統合

このスキルはcontext-fundamentalsとcontext-degradationに基づいています。次のものに接続します:

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

参考資料

内部参考:

• フレームワーク・リファレンス - 詳細なフレームワーク実装パターン

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

• 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

制限事項

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