なぜサブエージェント・オーケストレーションなのか
Claude Code を日常的に使っていると、「もっと速く、もっと賢く動かせないか」という欲求が生まれます。単一のエージェントが逐次的にタスクをこなすのは確かに強力ですが、現実のソフトウェア開発プロジェクトには並列処理が効果的な場面が多くあります。
サブエージェント・オーケストレーションとは、Claude Code の Task ツールを活用して複数のサブエージェントを同時に起動し、それぞれに専門的なタスクを委任して協調させるアーキテクチャです。これにより、同じ作業が従来の3〜10倍のスピードで完了するケースが出てきます。
第1章：Task ツールの基本と設計思想
Task ツールとは何か
Task ツールは Claude Code がサブエージェント（別の Claude インスタンス）を起動するための機能です。親エージェントから子エージェントへタスクを委任し、子エージェントが完了した結果を親に返します。
基本的な動作は次の通りです：
親エージェント
├─ Task("コンポーネントAのテスト作成") ─→ サブエージェント1
├─ Task("コンポーネントBのテスト作成") ─→ サブエージェント2
└─ Task("APIドキュメントの更新") ─→ サブエージェント3
↓（全完了後）
結果を統合・検証
重要なのは、**サブエージェントは独立したコンテキストを持ち、互いを「見えない」**という点です。これはメリット（干渉しない）でもあり、設計上の制約（明示的な情報共有が必要）でもあります。
オーケストレーション vs シーケンシャル処理
シーケンシャル処理（従来のやり方）:
タスクA → 完了 → タスクB → 完了 → タスクC → 完了
所要時間: A分 + B分 + C分
オーケストレーション処理:
タスクA ─┐
タスクB ─┼─→ 同時実行 → 全完了 → 統合
タスクC ─┘
所要時間: max(A, B, C) + 統合時間
依存関係のないタスクを並列化するだけで、理論上は $N$ タスクを $1/N$ の時間で完了できます（実際にはオーバーヘッドがあるため $1/(N \times 0.7)$ 程度）。
第2章：実践オーケストレーションパターン
パターン1：Fan-out（扇形分散）
最も基本的なパターンです。1つの入力を複数のサブエージェントに分散し、並列処理させます。
ユースケース: 複数ファイルの一括リファクタリング、多言語翻訳、マルチモジュールのテスト作成
実装例（Claude への指示プロンプト）:
以下の8つのコンポーネントに対して、それぞれ独立したサブエージェントを起動し、
ユニットテストを並列作成してください：
- src/components/Button.tsx
- src/components/Input.tsx
- src/components/Modal.tsx
- src/components/Table.tsx
- src/components/Card.tsx
- src/components/Dropdown.tsx
- src/components/Tooltip.tsx
- src/components/Badge.tsx
各サブエージェントの指示：
- 対象ファイルを読み込んでコンポーネントの仕様を理解する
- Jest + React Testing Library でテストファイルを作成する
- エッジケース（空文字、null、境界値）を含める
- テスト完了後にテストの数と網羅されたケースを報告する
成果: 8コンポーネント分のテスト作成が、逐次処理の約7〜8倍のスピードで完了。
パターン2：Pipeline（パイプライン）
前段の出力を後段の入力として連鎖させつつ、各段階内では並列処理を行います。
ユースケース: データ収集 → 分析 → レポート生成のような多段階処理
Stage 1（並列）: 各ソースからデータ収集
↓ 統合
Stage 2（並列）: データの各側面を分析
↓ 統合
Stage 3（並列）: レポートの各セクションを生成
↓ 最終統合
実務での活用事例:
筆者が運営する4つのAIブログサイト（claudelab.net など）のコンテンツ自動生成システムでは、このパターンを採用しています。
- Stage 1: 各サイトの既存記事スラッグ収集（4並列）
- Stage 2: 重複チェック＋SEOキーワード分析（4並列）
- Stage 3: 記事本文の日英版生成（8並列 = 4サイト × 2言語）
- Stage 4: generate-content.mjs 実行＋push（4並列）
このパイプラインにより、4サイト × 日英2言語 = 8記事の生成が約45分（以前は逐次処理で約3時間）で完了するようになりました。
パターン3：Map-Reduce（集約処理）
大量のデータを並列処理（Map）し、結果を集約（Reduce）するパターンです。
ユースケース: コードベース全体の静的解析、大規模リファクタリングの影響調査
入力: 500ファイルのコードベース
Map（50並列 × 10ファイル）:
- 依存関係を分析
- コードスメルを検出
- TypeScript エラーを収集
Reduce:
- 結果を集約
- 影響度順にソート
- 修正優先度レポートを生成
実装上の注意点:
Reduce フェーズで各サブエージェントの出力フォーマットを統一する点が肝心です。バラバラなフォーマットを後から統合しようとすると、親エージェントの処理が複雑になります。
// サブエージェントへの指示に含める統一フォーマット指定例
出力形式（必ず守ること）：
{
"file": "ファイルパス",
"issues": [
{"type": "error|warning|info", "line": 行番号, "message": "説明"}
],
"summary": "1行サマリー"
}
パターン4：Specialist Delegation（専門家委任）
タスクの種類に応じて「専門家」サブエージェントに委任するパターンです。
親エージェント（コーディネーター）
├─ セキュリティ専門家エージェント → 認証・権限ロジックのレビュー
├─ パフォーマンス専門家エージェント → ボトルネック分析・最適化提案
├─ テスト専門家エージェント → テスト網羅率チェック・追加テスト作成
└─ ドキュメント専門家エージェント → コメント整備・API ドキュメント生成
各専門家エージェントには、その専門分野に特化したシステムプロンプトやコンテキストを与えます。これにより、汎用エージェントよりも深い専門性を発揮させることができます。
第3章：情報共有と状態管理
サブエージェントは独立したコンテキストを持つため、エージェント間での情報共有には工夫が必要です。
ファイルベースの共有状態
最もシンプルで確実な方法は、共有ファイルを通じた情報交換です。
/tmp/work/
├── input/ # 入力データ（親が用意）
├── intermediate/ # 中間成果物（各エージェントが書き込む）
│ ├── agent1_result.json
│ ├── agent2_result.json
│ └── agent3_result.json
└── output/ # 最終成果物（親が集約）
実装パターン:
// 親エージェントの指示
各サブエージェントは処理完了後、結果を以下のパスに保存してください：
/tmp/work/intermediate/{エージェントID}_result.json
全サブエージェントの完了を確認したら、intermediate/ の全ファイルを読み込み、
output/final_report.json に集約してください。
並行書き込みの競合回避
複数エージェントが同時に同じファイルに書き込むと競合が発生します。これを避けるために：
- エージェントごとに異なるファイルパスを割り当てる（推奨）
- ファイル名にエージェントIDやタイムスタンプを含める
- 書き込み対象のディレクトリを分ける
# エージェントIDをパスに含める例
/tmp/work/intermediate/agent_001_result.json
/tmp/work/intermediate/agent_002_result.jsonもう一つの並列化軸：git ワークツリーでエージェントを物理的に分離する
前節ではファイルパスを分けて書き込み競合を避けました。もう一段踏み込むと、作業ディレクトリそのものを分けてしまう方法があります。git のワークツリーです。
Task ツールで起動したサブエージェントは、同じ作業ツリー（同じチェックアウト）を共有します。読み取り中心のタスクなら問題ありません。ですが、複数のブランチにまたがる変更や、依存関係のインストールを伴う実装を並行させると、同じディレクトリを取り合ってしまいます。
git worktree は、1 つのリポジトリに対して複数の作業ディレクトリを同時に持てる仕組みです。ブランチ切り替え（git checkout）が同じディレクトリの中身を入れ替えるのに対し、ワークツリーは物理的に別のフォルダを作ります。それぞれが独立したブランチを持ち、同時に別のコードを編集できます。
# 機能ごとにワークツリーを切る
git worktree add ../wt-auth -b feature/auth
git worktree add ../wt-payments -b feature/payments
# 現在のワークツリー一覧を確認
git worktree list各ワークツリーで Claude Code を別々に走らせれば、認証の実装と決済の実装が互いのファイルに触れることはありません。ファイル単位のロックを考える必要が減り、統合はマージという既存の仕組みに任せられます。
ワークツリーごとに CLAUDE.md を分ける
ワークツリーは独立したディレクトリなので、それぞれに固有の CLAUDE.md を置けます。認証用のワークツリーには「スキーマは変更しない」「カバレッジ 90% 以上」といったそのタスク専用の指針を書いておくと、サブエージェントの脱線を防げます。親リポジトリの CLAUDE.md を全体方針、各ワークツリーの CLAUDE.md をタスク方針として二層で使うと、指示の解像度が上がります。
終わったワークツリーは必ず片付ける
ワークツリーの弱点は、放置すると増え続けることです。マージが終わったワークツリーを消し忘れると、ディスクを圧迫し、git worktree list の見通しも悪くなります。
# 統合が終わったワークツリーを削除
git worktree remove ../wt-auth
git branch -d feature/auth
# 削除に失敗して残った不要なワークツリーを掃除
git worktree prune
git worktree remove --force ../wt-orphaned私自身、個人開発で Dolice のサイト群を触っているとき、ワークツリーを切りっぱなしにして半日後に「どのフォルダが本番用だったか」を見失ったことがあります。作るときのコマンドを覚えるより、終わったら消すという後片付けを習慣にするほうが、結局は速く回せます。
並列化には二つの軸があります。1 つのツリーの中で Task ツールがサブエージェントを分ける論理的な分離。もう 1 つがワークツリーでディレクトリごと分ける物理的な分離です。読み取りや解析は前者、ブランチをまたぐ実装は後者、と使い分けると競合そのものが起きにくくなります。
第4章：エラーハンドリングと堅牢性
分散処理では単一エージェントより障害点が増えます。適切なエラーハンドリングが不可欠です。
リトライ戦略
サブエージェントへの指示に含めること：
- 処理が失敗した場合、最大2回リトライする
- リトライ時は前回の失敗原因を踏まえたアプローチを取る
- 3回失敗した場合、エラー詳細を result.json の error フィールドに記録して終了する
部分失敗の処理
オーケストレーターは全エージェントの成功を前提にせず、部分失敗を想定した設計が重要です：
全10サブエージェントの完了を待つ。
結果の評価：
- 成功: 8件以上 → 失敗したエージェントのタスクのみ再実行
- 成功: 5〜7件 → 失敗タスクを再実行し、全完了後に統合
- 成功: 4件以下 → 人間にレビューを求め、処理を一時停止
各サブエージェントの出力には success: true/false フラグを必ず含める。
タイムアウト管理
長時間実行するサブエージェントへの対応：
各サブエージェントへの制約：
- 処理時間の目安: 10〜15分
- 20分経過しても完了しない場合は、途中結果を保存して終了
- タイムアウト時の出力: {"status": "timeout", "partial_result": {...}}
第5章：実務プロジェクトでの適用事例
事例1：Next.js プロジェクトの全面型安全化
背景: 5万行規模の Next.js プロジェクトで TypeScript の any 型を一掃したい。
オーケストレーション設計:
Phase 1（分析）:
20並列エージェント × ディレクトリ単位
→ any 型の使用箇所を全て列挙
→ 影響度（型チェーンの長さ）でスコアリング
Phase 2（修正）:
上位50箇所を10並列で同時修正
→ 各エージェントは5箇所担当
→ 型推論できるものは自動修正
→ 判断が難しいものはコメント付きで保留
Phase 3（検証）:
5並列エージェント × ディレクトリ単位
→ TypeScript コンパイルエラーチェック
→ 修正箇所の単体テスト実行
結果:
- 作業時間: 従来推定6日 → 実績8時間（約18倍の高速化）
any型削減率: 82%（残り18%は意図的な any または複雑な型推論が必要なもの）- 新規バグ: 0件（テストカバレッジが事前に十分あったため）
事例2：多言語ドキュメントの同期更新
背景: 日本語・英語・中国語・スペイン語の4言語でドキュメントを維持。日本語版が更新されるたびに他言語を同期する作業が煩雑。
オーケストレーション設計:
入力: 日本語版の差分（git diff）
Stage 1:
3並列（英語・中国語・スペイン語の翻訳者エージェント）
→ 各自が変更箇所の翻訳を生成
→ ローカライズ（慣用表現・文化的配慮）も含む
Stage 2:
1エージェント（品質チェッカー）
→ 3言語版を読み比べ、翻訳の一貫性チェック
→ 不自然な箇所を指摘
Stage 3:
3並列（各言語ファイルへの書き込み）
→ チェック済みの翻訳を適用
結果:
- 翻訳同期時間: 従来2〜4時間 → 約12分（最大20倍の高速化）
- 翻訳品質: ネイティブレビュアーによる満足度4.2/5.0（翻訳者による作業と比較）
事例3：コードレビューの自動化
背景: プルリクエストのレビュー待ち時間が開発ボトルネックに。
オーケストレーション設計:
PR の diff を入力として受け取り：
並列レビューチーム:
├─ セキュリティエージェント: 脆弱性・権限昇格・SQLインジェクション等
├─ パフォーマンスエージェント: N+1クエリ・メモリリーク・不要な再レンダリング
├─ テストエージェント: テスト網羅率・エッジケース不足
├─ アーキテクチャエージェント: SOLID原則違反・責務分離
└─ スタイルエージェント: コーディング規約・命名規則・コメント品質
集約エージェント:
→ 全レビューを統合
→ 重要度順にソート（Critical / Major / Minor）
→ GitHub PR コメントとして出力
結果:
- レビュー時間: 平均3.5時間 → 平均18分
- Critical 指摘の発見率: 従来の人間レビューと比べて94%（一致率）
- 開発者の主観評価: 「初歩的なミスを事前に潰せるので、人間のレビューがより本質的な議論に集中できるようになった」
第6章：オーケストレーション設計のベストプラクティス
1. 依存グラフを明確に描く
「何が何に依存するか」を明確にしないと、並列化できるはずのタスクを直列実行してしまいます。
// 依存グラフの例（Mermaid）
A(データ収集) --> C(統合分析)
B(設定ファイル読み込み) --> C
C --> D(レポート生成)
C --> E(アラート生成)
A と B は互いに依存しないので並列実行可能。D と E も並列実行可能。
2. 粒度を適切に設定する
タスクが細かすぎると、オーバーヘッドが支配的になり並列化の恩恵が薄れます。逆に大きすぎると並列化の効果が限定的になります。
目安: 1サブエージェントあたりのタスクが5〜20分程度になるよう設計。
3. 中間成果物を明確に定義する
各エージェントの「入力」と「出力」を事前に仕様化します。出力フォーマットが曖昧だと、集約フェーズが複雑になります。
4. 同時起動数は段階的に増やす
初めてのオーケストレーション実装では、まず3〜5エージェントから始め、安定したら増やしていくことをお勧めします。
5. モニタリングを組み込む
長時間実行するオーケストレーションでは、進捗ログを定期的に出力させ、どのエージェントが遅延しているかを把握できるようにします。
第7章：よくある失敗パターンと対策
失敗1: サブエージェントへの指示が曖昧
症状: サブエージェントが期待と異なる成果物を返す
対策: 指示に「期待する出力例」を含める。「○○してください」ではなく「○○してください。出力例：[具体例]」と書く。
失敗2: 親エージェントのコンテキスト肥大化
症状: 多数のサブエージェントの出力を受け取ることで、親エージェントのコンテキストウィンドウが溢れる
対策: サブエージェントの出力は要約形式にします。詳細はファイルに保存して、親にはパスのみ返す。
// Bad: 全文を返す
"分析結果: [5000行のデータ]"
// Good: 要約＋パス
"分析完了。概要：エラー12件、警告34件。詳細: /tmp/work/result_001.json"
失敗3: 競合状態の未考慮
症状: 複数エージェントが同じリソースを同時変更してコンフリクト
対策: リソース分割（各エージェントの担当範囲を明確に区切る）または、書き込みはメインエージェントのみが行う設計にします。
失敗4: エラー伝播の設計漏れ
症状: サブエージェントが失敗しても親が検知できず、不完全な状態で処理が進む
対策: 全エージェントの出力に success: true/false フラグを義務付け、親は必ずこれをチェックします。
まとめ：サブエージェント・オーケストレーションで開発の次のステージへ
Claude Code のサブエージェント・オーケストレーションは、単なる「自動化の高度化」ではありません。個人や小チームが大組織に匹敵するソフトウェア開発スピードを実現できる、パラダイムシフト的な手法です。
本記事で紹介した Fan-out・Pipeline・Map-Reduce・Specialist Delegation の4パターンは、実際のプロジェクトで即座に活用できます。まずは小さなタスクから試し、徐々に複雑なオーケストレーションへと発展させていくことをお勧めします。
AIエージェントの力を最大限に引き出す旅は、まだ始まったばかりです。ぜひ一緒に探求していきます。
Claude Lab プレミアムメンバーシップのご案内
本記事は「プレミアム記事の品質体験版」として無料公開しています。Claude Lab のプレミアム会員になると、このレベルの記事が毎日3本配信されます。
プレミアム会員が得られる価値:
- Claude Code・Claude API・Cowork の実践的な深掘り記事（毎日3本）
- エージェント設計・自動化システム構築の実践ガイド
- 読者限定のコード例・プロンプトテンプレート集
- 新機能の即時解説（Anthropic の発表から24時間以内）
永久プレミアム: ¥1,480 / Pro月額: ¥280
一度プレミアムに登録すれば、過去記事も含めた全コンテンツへのアクセスが永久に続きます。1杯のコーヒー代で、Claude との仕事の質が変わる体験をしてみませんか。