Claude Codeで複数のサブエージェントをオーケストレーションする：複雑なワークフローの構築（2026年）

- Claude Codeのエージェントオーケストレーション周りは進化が速く（エージェントチーム、動的ワークフロー、深さ制限など）、本記事の数値は執筆時点でClaude Code公式ドキュメントとAnthropicのリサーチ記事に照らして再確認したものです。実際に頼る前に最新のドキュメントを確認してください。

サブエージェントのオーケストレーションとは何か

単一のサブエージェントを作成して動かすことに慣れたら、次のステップはClaude Codeでのサブエージェントのオーケストレーションです。1つのメインエージェントに複数のワーカーサブエージェントを同時に連携させたり、それらを連結させたりします。これは古典的なオーケストレーター・ワーカーパターン（リードエージェントがワーカーを統括する、とも呼ばれます）です。

覚えておくべき簡潔な定義：サブエージェントのオーケストレーションとは、1つの調整役エージェント（オーケストレーター）が複数のサブエージェントを起動し、それぞれが独立したコンテキストウィンドウで作業の一部を担い、メインエージェントがまとめられるように簡潔なサマリーを返すことを指します。

すべての鍵は「独立したコンテキスト」という言葉にあります。各サブエージェントは独立したコンテキストウィンドウを持つため、数十のファイルを読み、多数のコマンドを実行し、長い出力を生成しても、メインセッションのコンテキストを膨張させることがありません。メインエージェントは要約された部分だけを受け取ります。これが、元のセッションのコンテキストをクリーンに保ちながら、大規模で複数ブランチにまたがるタスクに取り組む方法です。

これは高度な機能です。サブエージェントとは何か、基本的なものをどう宣言するかがまだ明確でない場合は、まず初心者向けサブエージェントガイドを読んでから、ここに戻ってきてください。この記事では、すでに少なくとも1つのサブエージェントを作成済みで、今度は複数を同時に指揮したいという前提で説明します。これは実践的なチュートリアルではほとんど最後まで取り上げられていないテーマです。

複数のサブエージェントをオーケストレーションすべきとき・すべきでないとき

複数エージェントの連携は常に有利とは限りません。トークンを大量に消費し、レイテンシも増えるため、タスクが本当にブランチに分かれる場合にのみ効果があります。ここは最も価値のある判断ポイントであり、ドキュメントやブログが通常さらっと飛ばしてしまう部分です。

15倍というトークンの数値と状態共有に関する警告は、いずれもAnthropicのマルチエージェント・リサーチ・システムに関する記事（2025年6月13日）に基づいています。同じ記事では、性能のばらつきの大半（約80%）は消費トークン量に起因すると述べられています——つまりトークンはコストであると同時にレバーでもあります。実用的なルール：タスクを明確に分離したブランチとして表現できないなら、オーケストレーションはやめて、1つの直線的なセッションを使いましょう。サブエージェントがスキル、フック、MCPとどう位置づけられるかを見るには、スキル・サブエージェント・フック・MCPの違いをお読みください。

2つのオーケストレーションパターン：並列 vs パイプライン

基礎となるパターンはちょうど2つあります。それぞれをいつ使うべきかを知っているだけで、すでに大半の開発者より一歩先に進めます。

並列（ファンアウト／ファンイン）：メインエージェントが複数のサブエージェントを同時に起動し、それぞれが独立したブランチを処理したのち、メインエージェントがサマリーを1つの結果に集約（ファンイン）します。

 ┌─→ subagent: auth ────┐
main agent ├─→ subagent: database ─┤─→ synthesize
 └─→ subagent: API ─────┘
 (parallel fan-out) (fan-in)

パイプライン（連結／逐次）：サブエージェントが順番に実行され、ある工程の出力が次の工程の入力になります。メインエージェントが各リンク間でコンテキストを受け渡します。

main → subagent: reviewer → subagent: optimizer → result
 (find issues) (fix based on issues)

一文でのテスト：ブランチが互いの結果を知る必要がないなら並列、工程Bが工程Aの結果を必要とするならパイプライン。現実のワークフローの多くはハイブリッドです。収集フェーズでは並列にファンアウトし、最後の統合工程だけを連結します。

例1 — サブエージェントを並列で実行する（ゼロから）

現実的なタスク：バックエンドのリポジトリを素早く監査したい。3つの独立した領域——auth、database、API——を同時にチェックします。これら3つの領域は互いに依存しないため、まさに並列実行の教科書的なケースです。

1. 調整用のプロンプトを入力する。明示的にファンアウトするようClaudeに依頼し、3つのブランチを指定し、各サブエージェントにはサマリーだけを返すよう伝えます：

   Audit this repo in parallel using 3 independent subagents:
   1) auth: check login flow, sessions, permission holes
   2) database: check schema, N+1 queries, missing indexes
   3) API: check input validation, rate limiting, error handling
   Each subagent should return only a short summary (~10 bullets max),
   NOT a full log dump. Then combine into one report.

2. Claudeがファンアウトするのを見る。Claude Codeは3つのサブエージェントを起動して並列実行し、それぞれが独自のコンテキストでコードを読みます。セッション内で3つの作業ストリームが同時に走るのが見えます。
3. 統合されたサマリーを読む。3つすべてが完了すると（ファンイン）、メインエージェントがそれらを1つのレポートにまとめます。各サブエージェントは簡潔な箇条書きだけを返したため、メインセッションのコンテキストは軽いままです。

統合工程の凝縮された出力は、おおよそ次のようになります（形式を示すためのもので、あなたのリポジトリの実際の数値ではありません）：

Audit report (merged from 3 subagents):
[auth] - Sessions not setting HttpOnly/Secure flags
 - Missing permission check on /admin/* endpoints
[database] - Order list query has N+1 (findOne in loop)
 - users table missing index on email column
[API] - 4 endpoints not validating the request body
 - No rate limit on the login route

ここで並列が適する理由：3つのブランチは互いのデータを必要としないため、並行して実行することで実時間を短縮でき、各長大なレポートをそれぞれのコンテキストに分離できます。これを無理に逐次実行しても、遅くなるだけで正確になるわけではありません。

例2 — 逐次パイプライン（連結）：reviewerからoptimizerへ

現実的なタスク：あるモジュールにパフォーマンス上の問題があると疑っています。工程1ではcode-reviewerサブエージェントがボトルネックを見つけます。工程2ではoptimizerサブエージェントが、そのリストに基づいてそれらを修正します。これは明確な依存関係です——optimizerはreviewerが何を見つけたかを知る必要があります——ので、並列ではなく逐次でなければなりません。

1. まずreviewerを実行する。調整用プロンプト：

   Use the code-reviewer subagent to find performance bottlenecks
   in the src/services/ directory and return a prioritized list.

2. 結果をoptimizerに渡す。メインエージェントはreviewerのリストを次の工程の入力として受け取ります：

   Hand the list above to the optimizer subagent:
   fix in priority order, add one line explaining each change,
   and do NOT change any public API behavior.

3. 最終結果を得る。optimizerはreviewerが指摘したまさにその内容に取り組みます。Claudeはリレー役として、2つのリンク間でコンテキストを受け渡します。

[reviewer] Found 3 bottlenecks:
 P1 - parseAll() re-reads the file inside a loop
 P2 - sequential API calls that could be batched
 P3 - JSON.parse repeated on the same payload
[optimizer] Fixed:
 P1 → cache file contents outside the loop
 P2 → merge into a single batch request
 P3 → parse once, reuse the object

核心的なポイント：後の工程が前の工程の出力を必要とするときにパイプラインを使いましょう。この依存関係のある2工程を無理に並列化しようとすると、reviewerのリストがまだ存在しないため、optimizerは手探りで修正することになります。オーケストレーションは単独で存在するものではなく、ブレインストーム→プラン→クック→シップのワークフローの一部です。通常はまず計画を立て、それからサブエージェントを放ってブランチをクックします。

応用 — オーケストレーターエージェント、ネストされたサブエージェント、深さ制限

毎回調整用のプロンプトを入力する代わりに、調整だけを専門にする専用のオーケストレーターエージェントを宣言できます。.claude/agents/coordinator.mdにファイルを作成します：

---
name: coordinator
description: Coordinates worker subagents for large, multi-branch tasks.
 Only splits work, spawns workers, and merges summaries - does NOT write code itself.
---

You are a coordinating agent. Your job:
1. Decompose the request into independent branches (if any).
2. Independent branches → dispatch in parallel; dependent branches → chain.
3. Require each worker to return ONLY a tight summary.
4. Merge everything into a single result for the user.
Do not do the detailed work yourself; always delegate to workers.

フロントマターのnameとdescriptionは、Claudeがこのエージェントをいつ呼ぶべきかを判断するのに役立ちます。「調整のみ」という制約により、エージェント自身が作業に飛び込んで自分のコンテキストを膨張させるのを防ぎます。

ネストされたサブエージェント：サブエージェントは自身の子サブエージェントを起動できます。これは強力ですが制御を失いやすいため、Claude Codeは深さに上限を設けています。サブエージェントに関するClaude Code公式ドキュメント（2026年8月確認）によると、デフォルトの起動深さは3階層で、CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH環境変数で調整可能です。高く設定しすぎると、エージェント数の爆発とトークンの浪費を招きやすくなります。現実のワークフローのほとんどはデフォルトを超える必要がありません。

持続的な並列タスクや、単一のコンテキストウィンドウに収まりきらないタスクには、このパターンが止まるところを引き継ぐ2つの新しいネイティブプリミティブがあります——後述の「オーケストレーションの新機能（2026年）」を参照してください。

オーケストレーター・ワーカーモデルの他にも、委任した実行ではなく助言が欲しいときのための、あまり一般的でないパターンがあります：アドバイザリーパターン：チェックポイントでkongmingに助言を求める。

オーケストレーションの新機能（2026年）：動的ワークフローとエージェントチーム

上で取り上げたプロンプト＋コーディネーターのパターンは、説明したとおり今も問題なく機能し、日常的な複数ブランチの委任にとって今も正しいデフォルトです——ほとんどのタスクはそれ以上を必要としません。このガイドが最初に公開されて以降、Claude Codeはオーケストレーションをさらにスケールさせる2つの新しいネイティブプリミティブを投入しました：Claude Codeの動的ワークフロー（Claudeがスクリプトを書いて作業をプログラム的にファンアウトする）と、Claude Codeのエージェントチーム（実験的なマルチセッションモード）です。どちらも上記のパターンを置き換えるものではなく——より大規模または長時間実行のジョブのために、その上に乗るものです。

このガイドの2つの例のような日常的な複数ブランチ作業には、上記のプロンプト＋コーディネーターのパターンを使い続けてください。タスクが1つのコンテキストウィンドウに収まりきらなくなったり、本格的な規模でのクロスチェック付きバックグラウンド実行が有益な場合には、動的ワークフローに手を伸ばしましょう。単発の委任・返却の実行ではなく、長時間にわたる協調的なマルチセッション構成が必要な場合には、エージェントチームに手を伸ばしましょう。どちらのプリミティブも、正確なエージェント数や同時実行の上限を含め、まだ進化の途中にあります。本番で依存する前に最新のドキュメントを再確認してください。

オーケストレーション時のトークンとコストの最適化

マルチエージェント実行は通常のチャットセッションのおよそ15倍のトークンがかかるため（Anthropicによる）、トークンの最適化は任意ではありません——それこそがオーケストレーションをコストに見合うものにする条件です。実用的な手立てをいくつか：

• サブエージェントの数を制限する——1回のファンアウトあたり3〜5に。エージェントを増やしても品質が比例して向上することはめったにありませんが、トークンは線形に増加します。
• ワーカーをより安価なモデルに振り分ける。単純なブランチ（ファイルを読む、一覧を作るなど）はHaikuのような安価なモデルに任せ、強力なモデルは統合工程のために温存できます。
• サブエージェントにはサマリーだけを返させる——完全なログ／差分のダンプをメインエージェントに返させない。これはトークン浪費の最大の要因であり、誰もが陥りがちです。
• 多数のサブエージェントがそれぞれ長い出力をメインに返すのを避ける——複数の長い出力をファンインするとメインコンテキストが詰まり、分離の意義そのものが台無しになります。

マルチエージェントセッションのトークン予算をさらに深掘りするには、多数のエージェントを動かす際のトークン最適化のガイドをご覧ください。

自分で作りたくない？既製のオーケストレーターエージェントキット（AgentKit）

まともなコーディネーターとワーカーの一群を書くには時間がかかります。すぐに使えるものが欲しいなら、これをパッケージ化したキットがあります。混同を避けるために一言：ここでのAgentKitはClaude Code向けのキット（agentkit.best、ak CLI）であり、OpenAIのAgentKit（Agent Builder／ChatKit、2025年10月6日ローンチ）ではありません。

AgentKitのEngineer Kitには17のエンジニアエージェント（プラットフォーム全体の45＝エンジニア17＋マーケティング28のうち）とオーケストレーションのワークフロー——ak-orchestrateスキルなど——が付属しており、コーディネーターをゼロから書く必要がありません。表示されているEngineer Kitの価格は99ドルで、ページに継続課金の記載はありません。率直に言えば、上記のセクションに従えばオーケストレーターは自分で十分作れます。キットに価値があるのは、セットアップ時間を節約し、あらかじめ調整されたエージェントを使いたい場合だけです。中身を正確に確認するにはEngineer Kitレビューを読むか、AgentKitの既製オーケストレーターエージェントを直接ご覧ください。

複数のサブエージェントをオーケストレーションする際のよくある間違い

• サブエージェントを起動しすぎる。全員が一斉に結果を返すと、メインコンテキストが燃え尽きます。回避策：1ラウンドあたり3〜5エージェントに抑え、サマリーを強制する。
• 依存する作業に並列を使う。誤った結果やデータ競合を招きます。回避策：「後の工程は前の工程の出力を必要とするか？」と問う——もしそうなら、パイプラインを使う。
• サブエージェントがサマリーではなく長いログを返す。トークンの浪費とコンテキストの詰まりを招きます。回避策：出力の上限をプロンプトやエージェント定義に明示する。
• 深さ制限を忘れる。ネストされたサブエージェントが階層をあふれさせ、エージェント数が爆発します。回避策：明確な理由がない限りCLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHをデフォルトのままにする。
• 不釣り合いなトークン消費。小さな変更にマルチエージェントを使う。回避策：小さく手早いタスクには、オーケストレーションせず1つの直線的なセッションを実行する。

よくある質問（FAQ）

いくつのサブエージェントを並列で実行できますか？

実務上は、1回のファンアウトあたり3〜5のサブエージェントに抑えましょう。厳密な上限ではありませんが、それを超えると通常、品質は比例して向上しない一方でトークンは急増し、統合されたコンテキストは過負荷になりやすくなります。1回の巨大なラウンドより、小さなファンアウトを数回に分けるほうが優れています。

並列とパイプラインではどちらがトークンを多く消費しますか？

並列は通常、多数のエージェントがそれぞれ独自のコンテキストで同時に動くため、トークンの急増がより激しくなります。パイプラインはある一時点で見ればトークン消費はより穏やかですが、工程を重ねるごとに累積し、また遅くなります。トークンだけでなく、タスクの依存関係に基づいて選びましょう。

サブエージェントは自身の子サブエージェント（ネスト）を起動できますか？

はい。サブエージェントは子サブエージェント（ネストされたサブエージェント）を起動できます。Claude Codeは深さに上限を設けており——デフォルトで3階層——CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH変数で調整可能です。ほとんどのワークフローはデフォルトを超える必要がありません。

オーケストレーションにエージェントチームは必要ですか？

いいえ、必須ではありません。調整用のプロンプト、または自分で宣言したオーケストレーターエージェントだけでオーケストレーションできます。エージェントチームは、単一のコンテキストウィンドウに収まりきらない、持続的で大規模な並列処理のための仕組みです。機能は新しく変化が速いため最新のドキュメントを確認してください——完全な比較は上記の「オーケストレーションの新機能（2026年）」を参照してください。

動的ワークフローはサブエージェントのオーケストレーションと同じですか？

いいえ。本ガイドのオーケストレーター・ワーカーパターンはプロンプト駆動で——Claudeが毎ターン次に何を実行するかを決めます。動的ワークフローは別の新しいプリミティブです：Claudeが先にJSスクリプトを書くため、計画はClaudeのコンテキストではなくスクリプトに存在し、手作業で調整するよりはるかに多くのエージェント（執筆時点のドキュメントによると最大1,000）にファンアウトできます。セットアップと制限については動的ワークフローの完全ガイドをご覧ください。

小さなプロジェクトで複数エージェントのオーケストレーションは価値がありますか？

通常はありません。小さく手早い変更では、連携とトークンのコスト（マルチエージェント実行はAnthropicによると通常のおよそ15倍のトークンがかかる）が利点を上回ります。タスクが本当に独立したブランチに分かれる、または多くの領域にまたがる場合にのみオーケストレーションしましょう。

既製の調整用エージェントキットはありますか？

はい。AgentKitのEngineer Kit（agentkit.best、ak CLI——OpenAIのAgentKitとは別物）は、17のエンジニアエージェントとオーケストレーションのワークフローをパッケージ化しており、コーディネーターを自分で書く必要がありません。上記のようにすべて自分で作ることもできます。キットは単にセットアップ時間を節約するだけです。

まとめと次のステップ

10エージェントのオーケストラから始めてはいけません。まず2工程のパイプライン（reviewerからoptimizerのような）を作り、それが消費するトークンを測定し、タスクが本当に独立したブランチに分かれるときにだけ並列のファンアウトへ拡張しましょう。初心者向けサブエージェントガイドで基礎を固め、ブレインストーム→プラン→クック→シップのワークフローの中でオーケストレーションを適切な位置に据えてください。コーディネーターを自分で書きたくないなら、Engineer Kitレビューをチェックしてみてください。