multi-agent-patterns

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

マルチエージェントアーキテクチャでは、それぞれが独自のコンテキストウィンドウを持つ複数の言語モデルインスタンスに作業を分散します。重要な洞察は、サブエージェントが主にコンテキストを分離するために存在し、役割分担を擬人化するためではないということです。

有効化するタイミング

• 単一エージェントのコンテキスト制限によって、タスクの複雑さに対応できない場合
• タスクを自然に並列サブタスクへ分解できる場合
• サブタスクごとに異なるツールセットやシステムプロンプトが必要な場合
• 複数のドメインを同時に扱う必要があるシステムを構築する場合
• 単一コンテキストの制限を超えてエージェントの能力を拡張する場合
• 複数の専門コンポーネントを備えた本番環境向けエージェントシステムを設計する場合

他のスキルが担当する、関連する作業にはこのスキルを有効化しないでください。

• 各エージェントが公開するツールの設計：tool-design。

コアコンセプト

単一エージェントのコンテキストウィンドウに、タスクに関連するすべての情報を収められない場合は、マルチエージェントのパターンを使用してください。主な利点はコンテキストの分離です。それぞれのエージェントは、他のサブタスクから蓄積されたノイズのないクリーンなコンテキストで動作するため、繰り返し要約するうちに情報が劣化する伝言ゲームの問題を防げます。

組織上の比喩ではなく、調整の必要性に基づいて、次の3つの主要なパターンから選択してください。

• スーパーバイザー／オーケストレーター — タスクを明確に分解でき、人間による監督が重要な場合に、一元管理に使用します。単一のコーディネーターが専門エージェントにタスクを委任し、結果を統合します。
• ピアツーピア／スウォーム — 厳密な計画がかえって逆効果になる、柔軟な探索に使用します。明示的なハンドオフ機構を通じて、任意のエージェントから別のエージェントへ制御を移せます。
• 階層型 — 抽象化の層（戦略、計画、実行）を持つ大規模プロジェクトに使用します。各層は、独自のコンテキスト構造を使って、異なる詳細度で動作します。

すべてのマルチエージェントシステムは、明示的な調整プロトコル、迎合に抗するコンセンサスメカニズム、そしてエラーの連鎖的な伝播を防ぐ障害処理を中心に設計してください。

詳細トピック

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

コンテキストのボトルネック 単一のエージェントのコンテキストが、蓄積された履歴、取得したドキュメント、ツールの出力でいっぱいになり、パフォーマンスが低下する場合は、マルチエージェントアーキテクチャを検討してください。パフォーマンス低下の兆候は3つあります。ミドル・ロスト効果（コンテキストの中間にある内容への注意が弱まる）、注意の希薄化（競合する項目が多すぎる）、コンテキスト汚染（無関係な内容が有用な内容を押しのける）です。

作業を複数のコンテキストウィンドウに分割し、各エージェントがサブタスクに集中したクリーンなコンテキストで動作できるようにします。単一のコンテキストにすべての負荷を負わせず、調整レイヤーで結果を集約します。

トークンコストの実情 トークンコストが大幅に増えることを見込んでください。実運用データによると、マルチエージェントシステムは単一エージェントのチャットよりはるかに多くのトークンを消費する可能性があります（claim-multi-agent-token-multiplier）。

アーキテクチャ	トークン倍率	ユースケース
単一エージェントのチャット	基準値	単純なクエリ
ツールを使う単一エージェント	基準値より高い	ツールを使うタスク
マルチエージェントシステム	基準値より大幅に高い	複雑な調査／調整

ブラウジングエージェントの評価研究では、トークン使用量、ツール呼び出し、モデルの選択がパフォーマンスのばらつきを大きく左右することが示されています（claim-evaluation-browsecomp-variance）。これは、エージェントを増やせば効果があると決めつけず、マルチエージェント構成を単一エージェントのベースラインと比較して測定することを裏付けています。

アーキテクチャ設計と同様に、モデルの選択も優先してください。より優れたモデルへのアップグレードは、多くの場合、トークン予算を2倍にするより大きなパフォーマンス向上をもたらします。BrowseCompのデータによると、モデル品質の向上は、単純なトークン数の増加を上回ることが少なくありません。モデルの選択とマルチエージェントアーキテクチャは、相互補完的な戦略として扱ってください。

並列化の論拠 並列化できるサブタスクは、単一のエージェントで順番に処理するのではなく、新しいコンテキストを持つ専用エージェントに割り当てます。複数の独立した情報源を検索する、異なるドキュメントを分析する、あるいは競合するアプローチを比較する必要がある調査タスクでは、並列実行が有効です。実際の所要時間は、すべてのサブタスクの所要時間の合計ではなく、最も長いサブタスクの所要時間に近づきます。

専門化の論拠 各エージェントには、特定のサブタスクに必要なシステムプロンプト、ツール、コンテキストだけを設定します。汎用エージェントは、考えられるすべての構成をコンテキストに保持する必要があり、そのぶん注意が分散します。専門化されたエージェントは必要なものだけを保持し、各分野に最適化された簡潔なコンテキストで動作します。コーディネーターから専門エージェントにタスクを振り分けることで、組み合わせの爆発を避けながら専門化を実現できます。

アーキテクチャパターン

パターン 1：スーパーバイザー／オーケストレーター グローバルな状態と軌跡を維持し、ユーザーの目標をサブタスクに分解して、適切なワーカーに振り分ける中央エージェントを配置します。

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

次の場合にこのパターンを選びます：タスクを明確に分解できる場合、ドメイン間の連携が必要な場合、または人間による監督が重要な場合です。

次のようなトレードオフがあります：ワークフローを厳密に制御しやすく、人間が介入しやすくなりますが、スーパーバイザーのコンテキストがボトルネックになり、スーパーバイザーの障害がすべてのワーカーに波及します。また、スーパーバイザーがサブエージェントの応答を誤って言い換える「伝言ゲーム」の問題が発生します。

伝言ゲームの問題と解決策 伝言ゲームの問題により、スーパーバイザーアーキテクチャは、最適化されたバージョンと比べて当初は約 50％性能が低下することを想定してください（LangGraph のベンチマーク）。スーパーバイザーはサブエージェントの応答を言い換えるため、受け渡しのたびに忠実度が失われます。

応答がすでに最終的かつ完全な場合に、スーパーバイザーによる言い換えを回避して、サブエージェントがユーザーに直接応答できるようにする forward_message ツールを実装して解決します。

実装については、references/frameworks.md（§ Forward Message Pattern）を参照してください。

サブエージェントがユーザーに直接応答できる場合は、スウォームアーキテクチャをスーパーバイザーより優先してください。これにより、伝達時の誤りを完全に排除できます。

パターン 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)

並列エージェントのディスパッチ

共有状態や逐次的な依存関係なしに進められる独立したタスクが2つ以上ある場合は、並列ディスパッチを使用します。

ディスパッチする場合

• 根本原因が異なる、3つ以上の失敗中のコンポーネント（それぞれ個別に調査する必要がある）
• 複数のサブシステムがそれぞれ独立して機能しなくなっている（フロントエンド、バックエンド、インフラストラクチャなど。共通の原因はない）
• 無関係な分野にまたがるリサーチタスク
• あるエージェントの出力が別のエージェントの入力にならないタスクの集合

ディスパッチしない場合

• 複数の失敗が同じ根本原因を共有している（一つの修正ですべて解決する）
• タスク N にタスク N-1 の出力が必要である
• エージェントが同じファイルや共有状態に書き込む
• システム全体のコンテキストが必要である（分割すると全体像が失われる）

ディスパッチのパターン

1. 分野ごとにグループ化する — 明確な境界を持つ独立したサブタスクを特定します
2. 焦点を絞ったプロンプトを作成する — 各エージェントに、具体的な範囲、明確な目標、明示的な制約、期待する出力形式を指定します
3. 並行してディスパッチする — すべてのエージェントを並列に起動します
4. 要約を確認する — 各エージェントの出力レポートを読みます
5. 競合がないことを確認する — 統合前に変更の重複がないか確認します
6. 統合する — 結果をマージし、境界部分での競合を解決します

効果的なエージェントプロンプト

ディスパッチするすべてのエージェントプロンプトは、次の条件を満たす必要があります。

• 自己完結している — 「上記の会話」や共有状態を参照しません
• 分野に焦点を絞っている — 明確な問題領域を一つ指定し、「すべてを確認する」としません
• 成果物を明示している — 「調査して報告する」ではなく、「X のリストを返す」と指定します
• 制約を設けて範囲を定めている — 変更対象のファイルやディレクトリと、変更しない対象を指定します

避けるべき例：範囲が広すぎる指示（「バックエンドを修正する」）、曖昧な制約（「注意する」）、コンテキストの不足（プロンプトだけではエージェントが問題を理解できない）。

ガイドライン

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

注意点

1. スーパーバイザーのボトルネックによるスケーリング — ワーカー数が増えると、スーパーバイザーのコンテキスト負荷は非線形に増大します。ワーカーが5人以上になると、スーパーバイザーは実際のタスクに費やす時間よりも、要約の処理に多くのトークンを費やします。スーパーバイザーあたりのワーカー数に上限（3〜5人）を設け、1人に負荷を集中させるのではなく、スーパーバイザーをもう1階層追加してください。
2. トークンコストの過小見積もり — マルチエージェントの実行コストは、ベースラインの約15倍です。チームは、調整のオーバーヘッド、再試行、合意形成のラウンドを考慮せず、エージェントごとのコストだけで見積もるため、一貫して予算を過小に設定します。15倍の予算を確保し、それを下回った分はボーナスと考えてください。
3. 迎合的な合意形成 — 議論パターンのエージェントは、正しい答えよりも、賛同を得やすい答えに収束する傾向があります。LLMには、もともと同意を好むバイアスがあります。明示的に敵対的な役割を割り当て、収束を認める前にエージェントが意見の相違を述べるよう求めて、この傾向を抑えてください。
4. エージェントの増やしすぎ — エージェントを3〜5人以上に増やしても、効果は逓減し、調整のオーバーヘッドが増えます。エージェントを1人追加するごとに、通信チャネルは二次関数的に増加します。実用上必要最小限のエージェント数から始め、コンテキストを分離する明確なメリットがある場合にのみ追加してください。
5. メッセージパッシングにおける伝言ゲーム — エージェント間を情報が受け渡されるたびに、繰り返しの要約によって情報が劣化します。各エージェントが言い換えることで、細かなニュアンスが失われます。複数のエージェントが忠実に参照する必要のある状態には、メッセージパッシングではなくファイルシステムによる連携を使用してください。
6. エラー伝播の連鎖 — あるエージェントの幻覚が、別のエージェントにとっての「事実」になります。後続のエージェントには、上流の幻覚と本物の情報を区別する方法がありません。エージェント間に検証チェックポイントを設け、検証せずに上流の出力を信頼しないでください。
7. 過剰なタスク分割 — タスクを細かく分割しすぎると、タスクそのものよりも調整のオーバーヘッドが大きくなります。10人のエージェントによる10段階のパイプラインでは、実際の作業よりも受け渡しに多くのトークンを費やします。サブタスクごとにコンテキストを分ける明確なメリットがある場合にのみ、タスクを分割してください。
8. 共有状態の欠如 — 共有ファイルシステムや状態ストアなしで動作するエージェントは、作業を重複させ、一貫性のない出力を生成し、完了済みの内容を把握できなくなります。マルチエージェントのワークフローを構築する前に、永続的な共有ストレージを用意してください。

統合

このスキルは、エージェントのトポロジーと調整プロトコルを担当します。隣接するスキルは、共有状態とツールの契約を担当します。

• memory-systems：エージェント間で共有する永続的な状態。
• tool-design：ツールの特化、および起動／状態確認ツールの契約。
• context-optimization：トークン効率化の手法の一つとしての分割。
• evaluation：調整コストを踏まえ、複数のエージェントが成果を向上させるかどうかの測定。

参考資料

内部リファレンス：

• フレームワークリファレンス - LangGraph、AutoGen、またはCrewAIで特定のマルチエージェントパターンを実装する際に、フレームワーク固有のコード例が必要な場合に参照してください

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

• context-optimization（基礎リファレンス） - エージェントの分割を設計する前に、コンテキストウィンドウの仕組みを理解する必要がある場合に参照してください
• memory-systems - エージェントがコンテキストの境界を越えて状態を共有する必要がある場合や、実行間で情報を保持する必要がある場合に参照してください
• context-optimization - 個々のエージェントのコンテキストが大きすぎて、分割または圧縮の戦略が必要な場合に参照してください

外部リソース：

• LangGraphドキュメント - 明示的な状態機械を使ったグラフベースのマルチエージェントワークフローを構築する場合に参照してください
• AutoGenフレームワーク - 会話型のGroupChatパターンや、イベント駆動型のエージェント調整を実装する場合に参照してください
• CrewAIドキュメント - 役割ベースの階層型エージェントプロセスを設計する場合に参照してください
• マルチエージェント調整に関する研究 - マルチエージェントシステムの理論と評価について学術的な基盤が必要な場合に参照してください