LESSON 30分

ストーリー

田
田中VPoE
ここまで単一のエージェントの設計と実装を学んできた。しかし実務では、1つのエージェントだけでは対応しきれない複雑なタスクが多い
あなた
複数のエージェントが協力して働くということですか？
あ
田
田中VPoE
その通り。カスタマーサポートエージェント、注文管理エージェント、在庫管理エージェントがそれぞれ専門性を持って協調する。これがマルチエージェントシステムだ
あなた
人間の組織と似ていますね。それぞれの専門家がチームで仕事をする
あ
田
田中VPoE
まさにそうだ。マルチエージェントには複数の設計パターンがある。組織構造と同じように、適切なパターンを選ぶことが重要だ

マルチエージェントシステムとは

単一エージェント vs マルチエージェント

観点単一エージェントマルチエージェント
ツール数少数（5-10個）各エージェントが少数ずつ
専門性汎用的各エージェントが専門特化
複雑なタスクステップ増で精度低下タスク分割で精度維持
プロンプト1つの巨大なプロンプト各エージェントに最適化
デバッグ困難エージェント単位で可能
スケーラビリティ限界ありエージェント追加で拡張

いつマルチエージェントが必要か

判断基準:

ツール数が10個を超える？
├── Yes → マルチエージェントを検討
└── No → 1つのタスクに異なる専門性が必要？
          ├── Yes → マルチエージェントを検討
          └── No → 処理が複数のフェーズに分かれる？
                    ├── Yes → マルチエージェントを検討
                    └── No → 単一エージェントで十分

主要なマルチエージェントパターン

1. Supervisorパターン

1つの「監督者」エージェントが、複数の「作業者」エージェントにタスクを振り分けます。

              ┌─────────────┐
              │  Supervisor  │
              │ (監督エージェント) │
              └──────┬──────┘
         ┌───────────┼───────────┐
         ↓           ↓           ↓
   ┌──────────┐ ┌──────────┐ ┌──────────┐
   │ 注文管理  │ │ 配送管理  │ │ 顧客対応  │
   │ エージェント │ │ エージェント │ │ エージェント │
   └──────────┘ └──────────┘ └──────────┘

特徴:

  • Supervisorが全体の制御を持つ
  • 作業者エージェントは自分の専門領域のみ担当
  • タスクの振り分けと結果の統合をSupervisorが行う
from langgraph.graph import StateGraph, END

class SupervisorState(TypedDict):
    messages: Annotated[list, add_messages]
    next_agent: str | None
    results: dict

def supervisor(state: SupervisorState) -> SupervisorState:
    """Supervisorが次に呼ぶべきエージェントを決定"""
    response = llm.invoke([
        SystemMessage(content="""あなたは監督エージェントです。
        以下のエージェントにタスクを振り分けてください:
        - order_agent: 注文の検索、詳細確認、キャンセル
        - shipping_agent: 配送状況の追跡、配送手配
        - support_agent: 一般的な質問への回答、FAQ検索
        - FINISH: タスク完了時
        次に呼ぶエージェント名のみ回答してください。"""),
        *state["messages"]
    ])
    return {"next_agent": response.content.strip()}

def route_to_agent(state: SupervisorState) -> str:
    next_agent = state.get("next_agent", "FINISH")
    if next_agent == "FINISH":
        return END
    return next_agent

2. Swarmパターン

エージェント同士が直接タスクを引き渡し合う、自律的な協調パターンです。

   ┌──────────┐    handoff    ┌──────────┐
   │ エージェントA │ ──────────→ │ エージェントB │
   └──────────┘              └──────────┘
        ↑                         │
        │         handoff         │
        │    ┌──────────┐         │
        └─── │ エージェントC │ ←────┘
             └──────────┘

特徴:

  • 中央の監督者がいない
  • 各エージェントが自分の能力を超える要求を他エージェントに委任
  • 柔軟だがフロー制御が複雑

3. Hierarchyパターン（階層型）

複数の階層を持つ組織構造です。

              ┌──────────────┐
              │  統括マネージャー  │
              └──────┬───────┘
         ┌───────────┴───────────┐
    ┌─────┴──────┐         ┌─────┴──────┐
    │  営業チームリーダー │         │  技術チームリーダー │
    └─────┬──────┘         └─────┬──────┘
    ┌─────┼─────┐          ┌─────┼─────┐
    ↓     ↓     ↓          ↓     ↓     ↓
  注文  配送  顧客対応    障害対応  API  DB管理

特徴:

  • 大規模組織向け
  • 各階層が自分のスコープ内で意思決定
  • チームリーダーがサブタスクを管理

パターンの比較と選定

観点SupervisorSwarmHierarchy
制御構造中央集権分散階層
適するタスク明確な振り分けルール柔軟な協調大規模・多階層
実装の複雑さ低中高
スケーラビリティ中高非常に高
デバッグ容易さ高低中
障害の影響Supervisor停止で全停止部分的な影響影響範囲を階層で限定

選定ガイドライン

エージェント数が3-5体？
├── Yes → Supervisorパターン（シンプルで管理しやすい）
└── No → エージェント数が5-10体？
          ├── Yes → タスクの振り分けが明確？
          │         ├── Yes → Supervisorパターン
          │         └── No  → Swarmパターン
          └── No → Hierarchyパターン（10体以上の大規模）

まとめ

ポイント内容
マルチエージェントの必要性ツール数の増加、専門性の分離、複雑なタスクの分割
Supervisor監督者がタスクを振り分け。シンプルで管理しやすい
Swarmエージェント同士が自律的に協調。柔軟だが複雑
Hierarchy階層組織構造。大規模向け

チェックリスト

  • マルチエージェントが必要な条件を判断できる
  • 3つのパターン（Supervisor、Swarm、Hierarchy）の違いを説明できる
  • Supervisorパターンの基本実装を理解した
  • パターン選定のガイドラインを把握した

次のステップへ

次は「A2Aプロトコル」を学びます。エージェント間の標準的な通信プロトコルを理解しましょう。

推定読了時間: 30分