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

マルチエージェント・アーキテクチャは、複数の言語モデル・インスタンスにわたって作業を分散させ、各インスタンスが独自のコンテキスト・ウィンドウを持ちます。適切に設計されば、この分散により単一エージェントの限界を超える機能を実現できます。設計が不適切な場合、メリットを打ち消すコーディネーション・オーバーヘッドが発生します。重要な洞察は、サブエージェントは役割分担を人間化するのではなく、主としてコンテキストを分離するために存在するということです。

アクティベーション時期

以下の場合にこのスキルをアクティベートしてください:

• 単一エージェントのコンテキスト制限がタスクの複雑性を制約している
• タスクが並列サブタスクに自然に分解できる
• 異なるサブタスクが異なるツールセットまたはシステム・プロンプトを必要とする
• 複数のドメインを同時に処理する必要があるシステムを構築している
• 単一コンテキストの限界を超えてエージェント機能をスケーリングしている
• 複数の特化したコンポーネントを持つプロダクション・エージェント・システムを設計している

コア概念

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

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

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

パターン1: スーパーバイザー/オーケストレーター

スーパーバイザー・パターンは、中央のエージェントに制御を置き、スペシャリストに委譲し、結果を統合します。スーパーバイザーはグローバル状態と軌跡を維持し、ユーザーの目的をサブタスクに分解し、適切なワーカーにルーティングします。

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

使用時期: 明確な分解が可能な複雑なタスク、ドメイン間のコーディネーションが必要なタスク、人間による監視が重要なタスク。

メリット: ワークフローの厳密な制御、ループ内の人間による介入の実装が容易、事前定義されたプランへの準拠を確保。

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

電話ゲーム問題と解決策

ベンチマークではスーパーバイザー・アーキテクチャが最初、スーパーバイザーがサブエージェントの応答を誤って言い換えて忠実性を失う「電話ゲーム問題」により最適化版より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)

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

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

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

分離メカニズム

• 完全なコンテキスト委譲: サブエージェントが完全な理解を必要とする複雑なタスク用
• 指示渡し: シンプルで明確に定義されたサブタスク用
• ファイルシステム・メモリ: 共有状態を必要とする複雑なタスク用

障害モードと軽減策

障害: スーパーバイザー・ボトルネック スーパーバイザーがすべてのワーカーからのコンテキストを蓄積し、飽和と性能低下に陥りやすくなります。 軽減策: 出力スキーマ制約を実装して、ワーカーが蒸留要約のみを返すようにします。

障害: コーディネーション・オーバーヘッド エージェント間通信はトークンを消費し、レイテンシを導入します。 軽減策: 明確なハンドオフ・プロトコルを通じて通信を最小化します。可能な限り結果をバッチ処理します。

障害: 発散 中央コーディネーションなしで異なる目標を追求するエージェントは意図された目標から逸脱する可能性があります。 軽減策: 明確な目標境界を定義します。収束チェックを実装します。タイム・トゥ・リブ制限を使用します。

障害: エラー伝播 1つのエージェントの出力のエラーが下流のエージェントに伝播します。 軽減策: コンシューマーに渡す前にエージェント出力を検証します。サーキット・ブレーカーを備えたリトライ・ロジックを実装します。

ガイドライン

1. マルチエージェント・システムの主要なメリットとしてコンテキスト分離用に設計する
2. 組織的なメタファーではなく、コーディネーション・ニーズに基づいてアーキテクチャ・パターンを選択する
3. 状態渡しを伴う明示的なハンドオフ・プロトコルを実装する
4. コンセンサス用に加重投票またはディベート・プロトコルを使用する
5. スーパーバイザー・ボトルネックを監視し、チェックポイント処理を実装する
6. エージェント間で渡す前に出力を検証する
7. 無限ループを防ぐためにタイム・トゥ・リブ制限を設定する
8. 障害シナリオを明示的にテストする