Claude Code v2.1.172解説｜5階層ネストサブエージェントとAgent Viewの実力
- Claude Codeのサブエージェントを既に使っており、より深い分業を試したいエンジニア
- 長時間の調査タスクをClaude Codeに任せたいテックリード・PM
- マルチエージェント設計でコストとノイズの両方に悩んでいる開発者
この記事の結論（3行まとめ）
- v2.1.172（6月10日）でサブエージェントが入れ子になった。設計思想は「並列化」ではなく「ノイズ隔離」
- 5階層まで使えるが、トークン消費が最大7倍に跳ね上がる。実用は2〜3階層+Haikuルーティングが現実解
- Agent Viewと組み合わせれば、長時間タスクの「樹形図」を可視化しながら管理できる
「subagents cannot spawn other subagents (no recursion)」
Claude Codeの公式ドキュメントには、長らくこの一文が書かれていた。サブエージェントは並列実行のための「フラットな枝」であり、入れ子にはできない。これは設計上の制約というより、コンテキスト爆発を防ぐためのガードレールだった。
2026年6月10日、その制約が外れた。v2.1.172のリリースノートに、こう書かれている。
Subagents can now spawn their own subagents. Nesting is supported up to 5 levels deep.
これだけ読むと「並列性が増えた」と誤読しがちだ。だが、Anthropicの説明はまったく違う方向を向いている。目的は深さによる並列化ではなく、ノイジーなツール呼び出しを深い階層に押し込めて、結論だけを浅い階層に上げることだ。
DevelopersIOのClaude Code v2.1.172解説記事は、この変更を「Agent Viewと組み合わせて長時間タスクを管理するためのインフラ整備」と位置づけている。本記事では、PMの視点から、この機能の意図、運用上の落とし穴、そして実務での使いどころを整理する。
ネストサブエージェントの仕組み：5フレームの再帰スタック
「フラット並列」と「ネスト分業」の違い
これまでのClaude Codeでは、主スレッドから複数のサブエージェントを並列起動するパターンが基本だった。例えば、リポジトリ全体のセキュリティ監査を依頼すると、主スレッドがsecurity-reviewer、refactor-cleaner、build-error-resolverを同時にディスパッチし、各サブエージェントが結果を主スレッドに返す。これがフラット並列だ。
v2.1.172以降は、サブエージェントがさらに子サブエージェントを呼べる。security-reviewerが暗号化レビュー、認証レビュー、入力検証レビューを別々の子サブエージェントに任せ、各子が独自のツール呼び出し（ファイル読み込み、grep、Web検索）を行ったうえで、結論だけを親に戻す。
公式ドキュメントとofox.aiの技術解説記事はこれを「5フレームの再帰スタック」と表現する。各フレームは独自のシステムプロンプトとモデルを持ち、親は子の最終的なサマリだけを受け取る。中間の煩雑な情報は、親のコンテキストには一切残らない。
なぜ「並列化」が目的ではないのか
5階層と聞くと「指数関数的に並列度が上がる」と期待する人がいる。だが実態は逆だ。サブエージェントの並列上限は依然として主スレッドから10セッション程度で、深さを使うほど合計セッション数は増えるものの、各セッションは個別のコンテキストウィンドウ（約200kトークン）を消費する。
つまり、深さは「処理時間の短縮」ではなく「コンテキストの分離」に効く。深いデバッグや影響範囲調査のような、大量のファイルを読まないと結論が出ない調査タスクで、主スレッドのコンテキストを汚さずに済む。これが本来の用途だ。
v2.1.172以降、サブエージェントの定義（Markdownのfrontmatter）にtools: Agent(child_name)の形で許可リストを書ける。これを書かないと、子サブエージェントが好き勝手にさらなる子を起動して、5階層フルに膨れ上がる可能性がある。実務では、明示的に呼び出してよい子の名前だけをホワイトリスト化することが推奨されている。
Agent Viewとの連携：可視化されない多階層は地獄になる
claude agentsコマンドの位置づけ
2026年5月、AnthropicはAgent Viewを発表した。claude agentsコマンドで、マシン上で動いている全てのClaude Codeセッションを一覧表示できる。ターミナルを閉じてもセッションは生き続け、ユーザー単位のスーパーバイザープロセスがバックグラウンドで管理する設計だ。
ネストサブエージェントは、このAgent Viewなしでは運用が成立しない。理由はシンプルで、親エージェントの視点からは孫以下が見えないからだ。何が起きているかをユーザーが把握するには、独立した観測手段が必要になる。
Agent Viewの画面では、各セッションが「ワークツリー単位」で隔離される。書き込みは.claude/worktrees/<id>/配下に閉じ込められ、複数のセッションが同じチェックアウトを読みつつ独立してファイルを書ける。ネストサブエージェントの孫が同じファイルを書き換えても、ワークツリーが違えば衝突しない。
v2.1.172で修正されたエージェントパネルの幽霊
DevelopersIOのリリースノート要約には、次の修正が明記されている。
Fixed a bug where a background sub-agent stayed stuck as ‘active’ in the agent panel after a nested agent it spawned was stopped.
ネスト解禁の直前まで、孫を停止しても親がactiveのまま残るゴーストが発生していた。Agent Viewのダッシュボードが嘘の状態を表示し続け、ユーザーは「動いているのか止まっているのか」判断できなくなっていた。これがv2.1.172で解消され、ようやくネストとAgent Viewが整合する。
リリースのタイミングを見ると、5月のAgent View、6月のネスト解禁、6月のゴースト修正、という順番で「多階層エージェント運用」のインフラが整えられている。場当たり的な機能追加ではなく、段階的な設計の積み上げと見ている。
7倍のトークン問題：ネストの代償と現実的な対策
なぜ7倍になるのか
ofox.aiとyoucanbuildthings.comの技術記事は、ネストサブエージェントの代表的なコスト見積もりとして「標準セッションの約7倍」を挙げている。算定根拠は概ねこうだ。
| 要素 | 標準セッション | エージェントチーム（プランモード） |
|---|---|---|
| メインスレッドのコンテキスト | 1セット | 1セット |
| サブエージェントのコンテキスト | 必要な分だけ | 全員が独立した約200kトークン枠を保持 |
| プランモードのオーバーヘッド | なし | 各エージェントが計画段階で大量のメタ推論 |
| 中間ツール呼び出し | 主スレッドで実行 | 各サブエージェントが独自に実行 |
ネストするほど、各階層が独立したコンテキストを抱える。5階層フルに使うと、理論上はさらに増える可能性がある。
環境変数による「Haikuルーティング」
実務的な対策として広く紹介されているのが、CLAUDE_CODE_SUBAGENT_MODEL環境変数だ。
export CLAUDE_CODE_SUBAGENT_MODEL=haikuこれをシェルレベルで設定すると、サブエージェント定義で明示的にモデルを指定していない限り、全ての子がClaude Haiku 4.5にフォールバックする。主スレッドと深さ1の子だけをSonnet 4.6やOpus 4.8でブーストし、それ以降の孫・ひ孫はHaikuで処理する設計だ。
Anthropicの公式紹介によれば、Haiku 4.5は前世代のSonnetに近い性能を3分の1程度のコストで提供する位置づけのモデルとされている。深い階層で扱う処理は「ファイル読んでgrepして要約する」程度のことが多く、最上位の推論能力は不要なケースが大半を占める。
階層ごとのコストイメージ
| 階層 | モデル | 1セッションあたり目安 |
|---|---|---|
| L0（主スレッド） | Sonnet 4.6 / Opus 4.8 | 通常通り |
| L1（並列ディスパッチ） | Sonnet 4.6 | 標準的なサブエージェントコスト |
| L2 | Haiku 4.5 | L1の3分の1程度 |
| L3〜L4 | Haiku 4.5 | 同上 |
Claude Code April 2026の500kコンテキスト・MCPアップデートで500kコンテキストが解禁されたこともあり、主スレッドは500kフル活用、子はHaikuで効率化、という棲み分けが現実的になっている。
3つの落とし穴：ネストの誘惑に飛びつく前に
1. 浅くて済む仕事を深くしない
ofox.aiの記事が強調するポイントの一つが、「単一サブエージェントで処理できる仕事をわざわざネストしない」というものだ。深さはコストとレイテンシの両方を増やす。
判断基準はシンプルで、主スレッドの200kトークン枠を汚さずに済むかどうかだ。汚さないなら、サブエージェント1階層で十分。汚すリスクがあるなら、初めてネストを検討する。
2. 暴走防止の許可リスト
サブエージェントが自由に子を起動できる、ということは、設計を誤ると無限に枝分かれする。各サブエージェント定義にtools: Agent(allowed_child_name)を明記し、想定外の子起動を機械的に止める運用が必須だ。
これはClaude CodeのDenyルールバイパス脆弱性の議論とも通じる話で、「使えるツール」を絞り込むホワイトリスト設計が、AIエージェントの安全性の基本になる。
3. リリース直後の挙動を本番に乗せない
v2.1.172はゴーストエージェントのバグを修正したものの、ネスト周辺の挙動はまだリサーチ段階に近い。Anthropic公式のCHANGELOG.mdは2025年から更新が続いており、リリース間隔は数日単位だ。週次でアップデートが入る現状で、本番ワークフローにネスト前提の設計を組み込むのは時期尚早と判断している。
Claude Codeは2025年から2026年にかけてv2.1.xx系のマイナーリリースが週に1〜2回のペースで続いている。ネストサブエージェントの挙動も、v2.1.172時点の仕様と数週間後の仕様が変わる可能性がある。公式のChangelogを定期的に確認することを推奨する。
使いどころ3パターン：深いデバッグ・影響範囲調査・リサーチ
パターン1: 深いデバッグの原因切り分け
主スレッドが「サーバーが時々500を返す」という曖昧な事象を受け取る。debug-investigatorサブエージェントが原因仮説を3つ立て、それぞれに対してlog-analyzer、db-query-checker、network-trace-readerの孫サブエージェントを起動する。孫は大量のログとクエリを読み込むが、親には「タイムアウトはRedisのコネクションプール枯渇に起因する可能性が高い」というサマリだけが戻る。
パターン2: 大規模リファクタの影響範囲調査
impact-analyzerサブエージェントが、変更対象の関数の呼び出し元をgrepし、呼び出し元ごとに孫サブエージェントを起動して個別の影響を評価する。リファクタ対象の関数が30箇所から呼ばれていれば、孫が30セッション動く。主スレッドには「影響箇所のうち5箇所で型不整合の懸念あり、24箇所は安全、1箇所はテストが不足」というサマリだけが戻る。
パターン3: ファクトチェック付きリサーチ
これは記事制作ガイドの4部隊レビューのような構造と相性が良い。research-orchestratorサブエージェントが、調査トピックを5つの観点に分解し、各観点の孫サブエージェントが個別にWeb検索とファクト検証を行う。出典URLと検証済みの主張だけが親に戻る。
Claude Codeのレビュー多エージェント記事で扱った多視点レビューの考え方を、より深い階層で実装する形だ。
電脳狐影としての判断：いつ使い、いつ使わないか
PMとして見ると、ネストサブエージェントは「強力だがコストが見えにくい武器」だ。並列タスクの並列ディスパッチで済む仕事をネストしてしまうと、トークン消費が膨れ上がり、CFOに説明できない請求書が翌月届く。
自分の運用ルールはこうしている。
- 主スレッド+並列1階層: 日常のコーディングタスクはこれで十分。スピードもコストもバランスが取れる
- 2階層ネスト: 影響範囲調査や深いデバッグのときだけ使う。
CLAUDE_CODE_SUBAGENT_MODEL=haikuを設定し、孫はHaikuに固定する - 3階層以上: 原則使わない。使うとしたら、月次の大規模リサーチタスクで、コスト上限を別途設定して走らせる
- Agent View: ネスト運用時は必ずダッシュボードを開いて、樹形図を可視化したまま作業する
正直に言えば、5階層フル活用の実用ユースケースは、現時点ではまだ想像できていない。Anthropicが示すユースケースも「研究用途」「複雑なエージェント設計の実験」に寄っている。製品開発の現場では、2〜3階層で必要十分なケースがほとんどだと考えている。
今後の見通し：Agent SDKとの統合とコスト透明化
Claude Code 6月15日のAgent SDKクレジット分離の記事で扱ったように、Agent SDKは別枠の20ドルクレジットに移行した。多階層エージェントを商用サービスとして組み込む場合、Agent SDK経由のコスト計上が今後の主流になる可能性が高い。
Claude Code側では、v2.1.172で/usageコマンドの粒度が「プラグイン単位」から「プラグイン内のコンポーネント単位」に進化した。ネストの各階層がどれだけトークンを消費したかを後から追跡できるようになり、コストブラックボックス問題は徐々に解消されつつある。
コンテキストエンジニアリング入門で議論したように、「コンテキストをどう構造化するか」がAIエージェント設計の中心課題だ。ネストサブエージェントは、その課題に対するAnthropicからの一つの解答であり、PMとしてはこの設計思想を理解したうえで、自分のワークフローに合わせて取り入れていきたい。
ネストサブエージェントは、サブエージェントの「フラット並列」から「階層分業」へのパラダイム転換だ。並列度を上げるための機能ではなく、コンテキストのノイズを隔離するための機能。この理解を取り違えると、トークン請求書を見て後悔することになる。
電脳狐影としての結論。v2.1.172のネストは「深い調査タスク」のための専用兵器だ。日常のコーディングには重すぎる。だが、月に1〜2回ある「コードベース全体を見渡したい」「複雑な障害の真因を突き止めたい」場面では、これに匹敵する選択肢は現時点では見当たらないと考えている。Agent ViewとHaikuルーティングをセットで覚えてから、慎重に運用するのが正解だ。
Claude Codeを最新版にアップデート
v2.1.172以降でネストサブエージェントが利用できる。アップデートはClaude Code内でnpm install -g @anthropic-ai/claude-code@latestを実行するか、公式ドキュメントの手順に従う。リサーチプレビュー機能のため、本番投入前に必ずChangelogを確認すること。
本記事の情報は2026年6月16日時点のものです。Claude Code v2.1.172のネストサブエージェント機能はリリース直後のため、仕様・制限事項は変更される可能性があります。最新情報はAnthropic公式のChangelogをご確認ください。料金やトークン消費の試算は各種解説記事の数値を参照したものであり、実際の課金額は利用条件により変動します。
Claude、Claude CodeはAnthropic, PBCの商標です。
Sources:
- Claude Code v2.1.171 to v2.1.172 Major Updates - DevelopersIO
- Claude Code Sub-agents Now Support 5 Levels of Nesting - note
- Claude Code Nested Sub-Agents: 5 Levels Deep, Token Math, 3 Pitfalls (2026) - ofox.ai
- Claude Code Nested Subagents: 5 Levels Deep - claudefa.st
- Why Claude Code Subagents Burn So Many Tokens - youcanbuildthings.com
- Agent view in Claude Code - Anthropic
- Manage multiple agents with agent view - Claude Code Docs
- Claude Code Agent View: Manage Every Session in One List - claudefa.st
- Claude Code Subagents documentation - Anthropic
- Claude Code changelog - Claude Code Docs
- Claude Code Guide 2026: 25 Features with Examples + Demo - MarkTechPost
- Claude Code June 2026 Update: Safe Mode, Opus 4.8, and Doubled Rate Limits - jangwook.net
