【Claude Code中級編 #6】マルチエージェント構成を作る——役割分担の設計
前回はAgent toolの仕組みと並列実行の基本を扱った。今回は一段上の話——複数のエージェントをどう設計するか、役割分担をどう決めるかを整理する。
マルチエージェント構成を意識して設計すると、大規模なタスクを安全かつ効率的に進められる。
オーケストレーターとワーカー
マルチエージェント構成の基本はオーケストレーターとワーカーの2役。
オーケストレーター（指揮役）
├── タスクを分解する
├── ワーカーに委譲する
└── 結果を集約・判断する
ワーカー（実行役）
├── 委譲されたタスクを実行する
└── 結果だけを返す
オーケストレーターは「何をやるか」を決め、ワーカーは「それをやる」。オーケストレーターは実行の詳細に立ち入らず、ワーカーは全体像を知らなくていい。
Claude Codeでは、メインセッションが全体の指揮役として振る舞い、Agent toolで起動したサブエージェントにタスクを委譲することで、オーケストレーター／ワーカーに近い構成を実現できる。
3つの構成パターンのうち、ファンアウト型・パイプライン型はAgent toolで実現できる。Agent Teams型はClaude Code専用のAgent Teams機能を使う（別途セットアップが必要）。
3つの構成パターン
1. ファンアウト型
1つのオーケストレーターが複数のワーカーを並列起動するパターン。
オーケストレーター
├── ワーカーA（APIエンドポイントAを調査）
├── ワーカーB（APIエンドポイントBを調査） ← 同時実行
└── ワーカーC（APIエンドポイントCを調査）
↓
結果を集約してまとめる
向いている場面:
- 同じ種類の作業を複数対象に適用する
- 互いに依存しない調査・実装が複数ある
- 大量ファイルのレビューや検証
指示例:
「以下の5ファイルをそれぞれ別のエージェントで並列調査して、
各ファイルの責務と依存関係をまとめて:
- src/user.ts
- src/auth.ts
- src/payment.ts
- src/notification.ts
- src/logging.ts」
2. パイプライン型
前のワーカーの出力が次のワーカーの入力になる直列チェーン。
ワーカーA（調査）
↓ 調査結果を渡す
ワーカーB（設計）
↓ 設計案を渡す
ワーカーC（実装）
↓ 実装結果を渡す
オーケストレーター（最終確認）
向いている場面:
- 「調査 → 設計 → 実装」のような前後依存があるタスク
- 各フェーズで品質を確認しながら進めたい
- 途中のフェーズで別の専門知識が必要
指示例:
「認証機能の改修を以下のステップで進めて:
1. まず現在の認証の実装を調査してまとめる
2. 調査結果をもとに改修方針を設計する
3. 設計に従って実装する」
3. Agent Teams型
サブエージェントはさらに別のサブエージェントを起動することはできない。これはClaude Codeのアーキテクチャ上の制約。
複雑な協調が必要な場合のために、公式が用意しているのが Agent Teams。1つのセッションがチームリードになり、複数のサブエージェントが共有のタスクリストを通じて連携する構成。
チームリード（1セッション）
├── タスクリスト（共有）
│ ├── タスクA（サブエージェントAが担当）
│ ├── タスクB（サブエージェントBが担当）
│ └── タスクC（サブエージェントCが担当）
└── 各サブエージェントが完了したタスクを確認しながら進行
向いている場面:
- フロント・バックエンドなど担当が明確に分かれている
- 各担当が互いの進捗を見ながら動く必要がある
- ファンアウト型より連携の密度が高いプロジェクト
3つのパターンの違いまとめ
| ファンアウト型 | パイプライン型 | Agent Teams型 | |
|---|---|---|---|
| 実行順 | 並列 | 直列 | 並列＋連携 |
| ワーカー間の依存 | なし | 前→次に依存 | 共有タスクリストで協調 |
| 向いているタスク | 同じ種類を複数対象に | 段階的に進めるタスク | 担当が分かれて進捗を参照 |
| 使う仕組み | Agent tool | Agent tool | Agent Teams機能 |
一番の違いはワーカー同士の関係：
- ファンアウト: ワーカーはお互いを知らない・関係ない
- パイプライン: 前のワーカーの出力が次の入力になる一方向の依存
- Agent Teams: 共有タスクリストを通じてワーカーが互いの状態を把握しながら動く
設計のポイント
タスクの境界を引く
ワーカーへの委譲がうまくいくかどうかは、タスクの境界の引き方で決まる。
良い境界:
- 入力と出力が明確
- 他のワーカーと編集するファイルが重ならない
- 「これが終わったら完了」が判定できる
悪い境界:
- 「全体的にいい感じにして」（曖昧すぎる）
- 複数のワーカーが同じファイルを編集する（コンフリクト発生）
- 前のワーカーの結果を待たないと始められないのに並列化している
ワーカーへの指示は自己完結させる
ワーカーはオーケストレーターとのやり取りを前提としない。指示の中に必要な情報をすべて含める。
悪い例:
「さっき話した認証の問題を修正して」
（「さっき話した」がワーカーには伝わらない）
良い例:
「src/auth.ts の JWTトークン検証ロジック（72行目付近）に
有効期限チェックが抜けている。expiresAt フィールドを
参照して検証を追加して」
結果の受け渡しを設計する
ワーカーが返す結果のフォーマットを統一しておくと、オーケストレーターが集約しやすくなる。
「調査結果は以下の形式でまとめて:
- ファイル名
- 主な責務（1行）
- 外部依存（他モジュールへの参照）
- 気になった点」
フォーマットを指定することで、複数ワーカーの結果をオーケストレーターが比較・統合しやすくなる。
向いているプロジェクト規模
マルチエージェント構成が効果を発揮するのは、ある程度の規模感から。
| プロジェクト規模 | 推奨構成 |
|---|---|
| 単一ファイルの修正 | 通常のClaude Code |
| 複数ファイルの関連修正 | Agent toolで並列調査 |
| 機能単位の実装 | ファンアウト or パイプライン型 |
| 大規模リファクタ・複数領域 | 階層型 |
小さなタスクにマルチエージェント構成を使うとオーバーヘッドが上回る。「このタスクは1人でやれる規模か」を先に判断する。
まとめ
- マルチエージェントの基本はオーケストレーター（指揮）とワーカー（実行）の役割分担
- 構成パターンは3種類：ファンアウト・パイプライン・Agent Teams
- タスクの境界を明確に引くことが設計の核心
- ワーカーへの指示は自己完結させる
- 小さなタスクには不要——規模感を見て使い分ける
次回はHooksとSkillsを組み合わせたセキュリティ設計——allowed-toolsとPreToolUseでスキルを安全に作る方法を扱う。
← 第5回：サブエージェントで並列処理する——Agentツールの使い方 ｜ 第7回：HooksとSkillsで安全なスキルを作る——セキュリティ設計 →