Home LangChain公式解説: マルチエージェントアーキテクチャの4パターン — Subagents・Skills・Handoffs・Router徹底比較
投稿
キャンセル

✍️ LangChain公式解説: マルチエージェントアーキテクチャの4パターン — Subagents・Skills・Handoffs・Router徹底比較

投稿日 17/02/2026
投稿者 0h-n0
20 分読了時間

ブログ概要（Summary）

LangChainのSydney Runkleが2026年1月に公開した「Choosing the Right Multi-Agent Architecture」は、マルチエージェントシステムの4つのアーキテクチャパターン — Subagents、Skills、Handoffs、Router — を体系的に比較分析した記事である。各パターンの強み・弱み・適用場面を明確に定義し、実装時のトレードオフ（モデル呼び出し数、トークン消費、コンテキスト管理）を定量的に比較している。

この記事は Zenn記事: Claude Octopus: 複数AIを並列実行するオーケストレーションプラグイン の深掘りです。Claude Octopusは複数のパターンを組み合わせたハイブリッドアプローチを採用しており、本記事の分類フレームワークを使ってClaude Octopusの設計を分析します。

情報源

技術的背景（Technical Background）

マルチエージェントシステムへの移行は、単一エージェントが以下の限界に直面したときに検討される：

  1. コンテキスト管理の限界: 各機能に必要な専門知識が単一プロンプトに収まらない
  2. 分散開発の必要性: チームが独立して各機能を開発・テスト・デプロイしたい

ただし、LangChainは「単一エージェント → ツール追加 → マルチエージェント」という段階的な移行を推奨している。Anthropicのリサーチでも、Claude Opus 4をリーダー、Claude Sonnet 4をサブエージェントとするマルチエージェント構成が単一のClaude Opus 4を90.2%上回ったことが報告されており、適切なアーキテクチャ選択の重要性が裏付けられている。

4つのアーキテクチャパターン

パターン1: Subagents（サブエージェント）

概要: スーパーバイザーエージェントが専門化されたサブエージェントをツールとして呼び出す。メインの会話コンテキストを維持しつつ、サブエージェントはステートレスに実行される。

graph TB
    User[ユーザー] --> Main[メインエージェント<br/>スーパーバイザー]
    Main -->|ツール呼び出し| SA1[サブエージェント A<br/>カレンダー管理]
    Main -->|ツール呼び出し| SA2[サブエージェント B<br/>メール管理]
    Main -->|ツール呼び出し| SA3[サブエージェント C<br/>CRM管理]
    SA1 -->|結果| Main
    SA2 -->|結果| Main
    SA3 -->|結果| Main
    Main --> User

特徴:

  • 中央集権的制御: スーパーバイザーが全体の流れを管理
  • 並列実行: 独立したサブエージェントは同時実行可能
  • コンテキスト分離: サブエージェント間でコンテキストが漏れない
  • 分散開発: チームが独立して各サブエージェントを開発可能

トレードオフ: サブエージェントの結果は必ずメインエージェントを経由するため、1リクエストあたり最低4回のモデル呼び出し（メイン→サブ→サブ結果→メイン応答）が必要。

適用場面: パーソナルアシスタント（カレンダー/メール/CRM）、ドメインエキスパートによるリサーチシステム

実装例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

from typing import Any

class SubagentOrchestrator:
    """Subagentsパターンの実装

    メインエージェントがサブエージェントをツールとして呼び出す。
    サブエージェントはステートレスに実行され、
    結果はメインエージェントに返される。

    Args:
        main_model: メインエージェント用のLLM
        subagents: サブエージェントの辞書
    """
    def __init__(
        self,
        main_model: str,
        subagents: dict[str, "SubAgent"]
    ):
        self.main_model = main_model
        self.subagents = subagents
        self.conversation_history: list[dict] = []

    async def run(self, user_input: str) -> str:
        """ユーザー入力を処理

        Args:
            user_input: ユーザーのメッセージ

        Returns:
            最終応答
        """
        self.conversation_history.append({
            "role": "user",
            "content": user_input
        })

        # メインエージェントがツール選択
        tool_calls = await self._plan(user_input)

        # サブエージェントを並列実行
        import asyncio
        results = await asyncio.gather(*[
            self.subagents[call["name"]].execute(call["args"])
            for call in tool_calls
        ])

        # メインエージェントが結果を統合
        response = await self._synthesize(results)
        return response

パターン2: Skills（スキル）

概要: 単一のエージェントが動的にスキル（専門プロンプト + 知識）をロードし、異なるペルソナを切り替える。複数のエージェントインスタンスは不要。

graph TB
    User[ユーザー] --> Agent[単一エージェント]
    Agent -->|ロード| S1[Skill: コードレビュー]
    Agent -->|ロード| S2[Skill: テスト作成]
    Agent -->|ロード| S3[Skill: ドキュメント]
    Agent --> User

特徴:

  • 軽量: 追加のエージェントインスタンスが不要
  • ユーザーとの直接対話: スキル切り替え中もユーザーと直接やり取り
  • Progressive Disclosure: 必要なスキルのみをオンデマンドでロード

トレードオフ: スキルがロードされるたびにコンテキストに蓄積される。マルチドメインクエリでは最大15,000トークンに膨らむことがある。

適用場面: コーディングエージェント、クリエイティブアシスタント、単一エージェントで複数の専門性が必要な場合

パフォーマンス比較:

シナリオモデル呼び出し数トークン消費
単一リクエスト3回~6K
リピートリクエスト2回（40%削減）~4K
マルチドメインクエリ3回~15K（コンテキスト蓄積）

パターン3: Handoffs（ハンドオフ）

概要: アクティブなエージェントがツール呼び出しを通じて別のエージェントに制御を移譲する。状態は自然に引き継がれる。

graph LR
    User[ユーザー] --> A1[Agent: 受付]
    A1 -->|ハンドオフ| A2[Agent: 技術サポート]
    A2 -->|ハンドオフ| A3[Agent: 決済処理]
    A3 --> User

特徴:

  • 逐次的ワークフロー: ステージ間の自然な遷移
  • 状態の引き継ぎ: 前のエージェントのコンテキストが次のエージェントに渡る
  • 直接対話: 現在アクティブなエージェントがユーザーと直接やり取り

トレードオフ: ステートフルな設計のため、状態管理が複雑になる。並列実行には不向き。マルチドメインクエリでは7回以上のモデル呼び出しが必要。

適用場面: マルチステージカスタマーサポート、前提条件のある逐次的会話フロー

パターン4: Router（ルーター）

概要: ルーティングステップが入力を分類し、専門エージェントに振り分け、結果を合成する。

graph TB
    User[ユーザー] --> Router[ルーター<br/>入力分類]
    Router -->|並列ディスパッチ| E1[Expert: 製品知識]
    Router -->|並列ディスパッチ| E2[Expert: 技術文書]
    Router -->|並列ディスパッチ| E3[Expert: FAQ]
    E1 --> Synth[結果合成]
    E2 --> Synth
    E3 --> Synth
    Synth --> User

特徴:

  • 高並列性: 独立したエキスパートを同時実行
  • ステートレス: リクエストごとに完結（一貫した性能）
  • 明確な分離: 各エキスパートが独立した知識ドメインを管理

トレードオフ: ステートレスのため、会話履歴が必要な場合はリクエストごとにルーティングのオーバーヘッドが発生。

適用場面: エンタープライズナレッジベース、マルチバーティカルカスタマーサポート、並列マルチソースクエリ

パターン選択フレームワーク

定量比較

要件SubagentsSkillsHandoffsRouter
並列実行★★★★★★★☆☆☆★☆☆☆☆★★★★★
逐次ワークフロー★★★☆☆★★★☆☆★★★★★★★☆☆☆
コンテキスト分離★★★★★★★☆☆☆★★★☆☆★★★★★
直接対話★★★☆☆★★★★★★★★★★★★☆☆☆
分散開発★★★★★★★★★☆★★★☆☆★★★★★
状態管理の簡素さ★★★★☆★★★☆☆★★☆☆☆★★★★★

シナリオ別モデル呼び出し数

シナリオSubagentsSkillsHandoffsRouter
単一リクエスト4回3回3回3回
リピートリクエスト4回2回2回3回
マルチドメインクエリ5回3回7回+5回

Skills と Handoffs はリピートリクエストで40%の効率改善を示す（状態保持の恩恵）。一方、Subagents と Router はマルチドメインクエリで並列実行により効率的（~9Kトークン vs Skills の ~15K）。

決定木

1
2
3
4
5
6
7
8

タスクの性質は？
├── 複数の独立ドメイン + 並列実行が重要
│   ├── 中央集権的制御が必要 → Subagents
│   └── ステートレスで一貫した性能が重要 → Router
├── 単一エージェントで複数の専門性
│   └── → Skills
└── 逐次的なワークフロー（状態遷移）
    └── → Handoffs

Claude Octopusのアーキテクチャ分析

LangChainの4パターン分類を使って、Claude Octopusの設計を分析する：

Claude Octopusが採用するパターン

Claude Octopusはハイブリッドアーキテクチャであり、複数のパターンを組み合わせている：

機能対応パターン理由
3プロバイダ並列実行（Codex/Gemini/Claude）Router独立したAIに並列ディスパッチ
29種類のペルソナ自動選択Skills意図検知でスキルをロード
Double Diamond 4フェーズHandoffsDiscover→Define→Develop→Deliver
/octo:embrace フルライフサイクルSubagentsOrchestratorが各フェーズを制御

最適化の余地

LangChainの定量比較に基づくと：

  1. トークン効率: Skillsパターンの部分（ペルソナロード）でコンテキスト蓄積が問題になる可能性。29ペルソナすべてをロードせず、上位3-5に絞ることで改善
  2. 並列実行の活用: Router + Subagentsの組み合わせにより、3プロバイダの並列実行とフェーズ内の並列実行を両立可能
  3. 状態管理: Handoffsパターン（Double Diamond）では状態管理が複雑になる。.octo/STATE.mdによる永続化は良い設計だが、各フェーズ間の明示的な状態スキーマの定義が推奨される

実運用への応用（Practical Applications）

パターン選択のガイドライン

プロトタイプ段階:

  • 最初はSkillsパターン（単一エージェント + スキルロード）で開始
  • 複雑さが増したらSubagentsに移行

プロダクション段階:

  • Routerパターンでユーザーリクエストを分類・振り分け
  • 各ドメイン内でSubagentsが専門的なタスクを処理
  • 逐次ワークフロー（サポートフロー等）にはHandoffsを併用

Deep Agents: 実用的な統合パターン

LangChainはDeep Agentsという実装を紹介している。これはSubagents + Skillsの組み合わせで、即座に利用可能なマルチエージェントフレームワークを提供する。Claude Octopusのように、複数パターンの統合が実用的なマルチエージェントシステムの鍵となる。

学術研究との関連（Academic Connection）

  • Mixture-of-Agents (Wang et al., 2024): 階層的なLLM協調。Subagentsパターンの理論的基盤
  • Magentic-One (Fourney et al., 2024): Orchestrator + 専門エージェント。Subagentsパターンの実装例
  • ToolOrchestra (Diao et al., 2025): RL訓練された小型オーケストレータ。Routerパターンの高度な実装
  • Evolving Orchestration (Dang et al., 2025): 動的なエージェント指揮。Handoffsパターンの進化形

これら4つの研究は、LangChainの4パターンにそれぞれ対応しており、理論と実践が収束していることを示している。

まとめと実践への示唆

LangChainの4パターン分類は、マルチエージェントアーキテクチャの選択を体系化する実用的なフレームワークである。重要なポイントは：

  1. 単一パターンに固執しない: Claude Octopusのように複数パターンの組み合わせが最も効果的
  2. 段階的に複雑さを増す: Single Agent → Skills → Subagents/Router の順で移行
  3. 定量的にトレードオフを評価: モデル呼び出し数とトークン消費で比較

マルチAIオーケストレーションの設計者にとって、この4パターンは「どのアーキテクチャをいつ使うか」の意思決定を支援する強力なツールとなる。

参考文献

blog tech_blog
langchain langgraph multi-agent architecture design-pattern orchestration ai
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次

論文解説: LLMの完全バイナリ化に挑む — W(1+1)A(1×4)ポストトレーニング量子化の技術詳細

Microsoft Research解説: LLM評価のための完全メトリクスフレームワーク — GPU利用率からユーザー満足度まで