Claude Code のサブエージェントを多段で動かす — TeamCreate 廃止と『暗黙チーム』への移行(v2.1.178)

Claude Code のマルチエージェント周りが 6 月中旬の 2 リリースで大きく作り替わりました。v2.1.172(2026-06-10)で サブエージェントが最大 5 段までネストできるようになり、続く v2.1.178(2026-06-15)で TeamCreate / TeamDelete ツールが廃止され、代わりに 「暗黙チーム(implicit team)」 モデルに移行しました。これまで「チームを作ってから人を入れる」という 2 段階だったものが、Agent ツールの name パラメータを渡すだけで済むようになっています。本記事では、この設計変更が何を狙ったものかと、実務でサブエージェントを多段に回すときの考え方・権限制御を整理します。

到達点

暗黙チームへの移行で何が消え、何が増えたかを正確に把握する
旧 TeamCreate → 新 Agent(name) のメンタルモデルの違いを理解する
サブエージェントを 5 段ネストで組むときの設計上の勘所
Agent(model:opus) 形式の Tool(param:value) 権限ルールでモデル・コストを縛る
ネストした .claude/ の解決順(closest wins)を運用に織り込む

まず変更点を 1 枚に

項目	〜v2.1.177	v2.1.178 以降
チーム生成	`TeamCreate` ツールで明示的に作成	セッションごとに暗黙チームが 1 つ(作成不要)
チーム削除	`TeamDelete` ツールで明示的に削除	ツール廃止(ライフサイクルはセッションに従属)
チームメイト追加	チーム作成後に投入	`Agent` ツールの `name` を渡すだけ
`team_name` パラメータ	意味を持つ	受け付けるが無視される(後方互換のため残置)
有効化	—	`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`(実験フラグ)

ポイントは、「チームという入れ物を先に用意する」概念が消えたことです。セッション = チームの器、という前提に統一され、開発者が意識すべきは「誰を(name)立てるか」だけになりました。

旧モデルと新モデルのメンタルの違い

旧来の TeamCreate 方式は、オーケストレーションの状態を明示的に組み立てる設計でした。

1. TeamCreate でチーム(器)を作る
2. そこにエージェントを所属させる
3. 仕事を割り振る
4. 終わったら TeamDelete で片付ける

この方式は柔軟ですが、「器の作成・破棄」というボイラープレートが常に付いて回ります。短いタスクでも器のライフサイクル管理が必要で、作りっぱなし(TeamDelete 忘れ)の温床にもなっていました。

新しい暗黙チーム方式は、この器を セッションそのものに畳み込みました。

1. (セッション開始時点でチームは既に存在)
2. Agent ツールに name を付けて呼ぶ → その瞬間にチームメイトが生える
3. 仕事は呼び出しと同時に渡る
4. セッション終了でまとめて片付く(個別の後始末ツール不要)

要するに:オーケストレーションの単位が 「チーム」から「呼び出し」へ降りてきた、ということです。Agent(name: "reviewer") のように名前付きで呼ぶと、その名前のチームメイトが立ち上がり、以後 SendMessage 等でその名前宛てにやり取りできます。状態管理の起点が「器」ではなく「個々のエージェント」になりました。

名前を付けることの意味

name は単なるラベルではなく、そのエージェントを後から指名するためのアドレスです。名前を付けて立てたチームメイトは、同一セッションの中で再度メッセージを送って続きを依頼できます。逆に名前を付けずに新規の Agent 呼び出しをすれば、それは毎回まっさらな文脈で始まる使い捨てになります。

立て方	文脈	再利用	向くケース
`name` あり	立てたエージェントの文脈が継続	名前宛てに追撃依頼が可能	レビュアー・専門担当を常駐させて何度も相談する
`name` なし(新規呼び出し)	毎回ゼロから	不可(都度新規)	独立した一発タスクを並列にばらまく

この区別は、「同じ相手に文脈を保ったまま相談を重ねたいか」「独立タスクを撒いて結果だけ集めたいか」 の選択に対応します。多段オーケストレーションを設計するときは、まずこの 2 系統を意識すると役割分担が崩れません。

サブエージェントの 5 段ネスト(v2.1.172)

暗黙チームと対になるのが、v2.1.172 で入った 「サブエージェントが自分のサブエージェントを生成できる(最大 5 段)」 という変更です。これにより、親が子に丸ごと一塊の仕事を委譲し、子がさらに孫に分解するという再帰的な分担が可能になりました。

あなた(main)
└─ orchestrator(1 段目)
   ├─ explorer(2 段目)
   │  └─ file-reader ×N(3 段目:並列)
   └─ implementer(2 段目)
      └─ verifier(3 段目)

段を深くするときの勘所

多段は強力ですが、深さは「コストと文脈の希薄化」と表裏です。実務では次を目安にします。

深さより幅を優先する:1 段目で十分に分解できるなら、無理に 3 段・4 段にしない。段が増えるほど中間の要約で情報が落ちる。
末端は「結論だけ返す」契約にする:孫エージェントには「ファイルの中身ではなく、判明した事実だけを返せ」と指示する。これがネストの価値の本質(文脈を親に持ち込まない)。
5 段はあくまで上限:再帰の暴走を止めるための天井であって、目標値ではない。2〜3 段で収まる設計がほとんど。
並列は末端で効かせる:ファン-アウトは葉ノード(独立タスク群)で効く。中間ノードを無闇に並列化しても待ち合わせのコストが勝ちやすい。

ネストの本当の効用は「親の文脈を汚さずに大量の探索を肩代わりさせる」点にあります。子が 50 ファイル読んでも、親に返るのは要約 1 つ。これが段を切る最大の理由で、逆に「結論を要約せず生データを返す」設計だとネストの意味が薄れます。

新しい権限制御:`Tool(param:value)` 構文

v2.1.178 では、権限ルールに ツールの入力パラメータでマッチする Tool(param:value) 構文が追加されました(* ワイルドカード対応)。公式に挙げられている例が Agent(model:opus) で、これは 「Opus を使うサブエージェントをブロックする」 ルールになります。

{
  "permissions": {
    "deny": [
      "Agent(model:opus)"        // Opus 指定のサブエージェント生成を拒否
    ]
  }
}

これがマルチエージェントと噛み合うと、コスト・モデルのガバナンスが現実的になります。サブエージェントは黙っていると親と同じ上位モデルを引き継ぎがちで、多段・並列で一気に走るとトークン消費が跳ねます。Agent(model:opus) を deny に置けば、「探索や定型作業の末端は上位モデルを使わせない」 という線を機械的に引けます。

やりたいこと	ルール例	効果
末端で上位モデルを禁止	`"Agent(model:opus)"` を `deny`	Opus サブエージェントを止める
特定モデル系のみ許可	`allow` 側で許可モデルを列挙	想定外モデルの混入を防ぐ
ワイルドカード指定	`Tool(param:*)` 形式	パラメータ値を緩くマッチ

autoMode の自然言語ルール(hard_deny など)が**「意図ベースの方針」を担うのに対し、この Tool(param:value) は「パラメータ値での機械的なマッチ」**を担います。両者は補完関係なので、「方針は autoMode、確実に止めたい値は permissions の Tool(param:value)」と住み分けるのが実務的です。

ネストした `.claude/` の解決順

地味ですが多段運用に効くのが、v2.1.178 の ネスト .claude/ の解決ルールです。

エージェント定義・ワークフロー・output-style:作業中ディレクトリに最も近い .claude/ が勝つ(closest wins)
スキル:ネストした .claude/skills も読み込まれ、名前衝突時は <dir>:<name> の形で両方が併存(どちらも使える)

モノレポで パッケージごとに振る舞いを変えたいときに効きます。たとえば packages/api/.claude/ に API 用のレビュー観点を持つエージェントを置き、packages/web/.claude/ には別物を置けば、作業中のディレクトリに応じて自動的に近い方が選ばれる。サブエージェントを多段で走らせるとき、各エージェントが「自分のいる場所のローカル流儀」を拾えるのは運用上かなり楽です。

スキルだけは「衝突したら近い方が勝つ」ではなく <dir>:<name> で両立する点に注意してください。同名スキルを意図的に上書きしたいなら、名前自体を分ける必要があります。

実務での組み立て方(最小レシピ)

暗黙チーム + 多段サブエージェントを使う場合の、現実的な進め方です。

まず実験フラグを通す:CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を環境変数に設定。実験段階なので、まず使い捨てのリポジトリで挙動を確認する。
常駐させたい役割は name で立てる:reviewer / researcher など、何度も相談する相手は名前付きで起動し、SendMessage で文脈を保ったまま追撃する。
独立タスクは名前なしで撒く:互いに依存しない調査・変換は、名前を付けずに並列の Agent 呼び出しでファン-アウトし、結果だけ集約する。
末端のモデルを縛る:permissions.deny に Agent(model:opus) を入れ、葉ノードが上位モデルを浪費しないようにする。
ディレクトリ流儀を用意する:モノレポなら各パッケージに .claude/ を置き、近い方が勝つ解決を前提にエージェント定義を分ける。

注意点

まだ実験フラグ下:暗黙チームは CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 前提です。フラグ無しの通常セッションでは従来どおり単発の Agent 呼び出しが基本で、チームメイトの常駐は前提にできません。仕様は今後変わり得ます。
team_name は無視される:過去のスクリプトやワークフローで team_name を渡していてもエラーにはならず黙って無視されます。意図したチーム分離が効かなくなっている可能性があるので、移行時は確認を。
コストは段数 × 並列で効く:5 段ネストと並列は掛け算でトークンを食います。「上限まで使える」ことと「使うべき」ことは別物で、まず 2〜3 段で設計するのが安全です。
深いほどデバッグしづらい:多段の途中で結論がねじれると追跡が難しくなります。各段に「何を返す契約か」を明示し、末端は構造化した結論だけ返させると切り分けが楽になります。

まとめ

6 月中旬の 2 リリースで、Claude Code のマルチエージェントは 「器を作る」発想から「呼び出しで人を生やす」発想へ移りました。v2.1.172 のサブエージェント 5 段ネストで再帰的な分担が可能になり、v2.1.178 の暗黙チームでチーム生成のボイラープレートが消滅。さらに Agent(model:opus) 形式の権限ルールで末端モデルのガバナンスが、ネスト .claude/ の closest-wins で場所ごとの流儀が扱えるようになりました。

実務の勘所は一貫しています — 段は深さより幅、末端は結論だけ返す契約にして親の文脈を汚さない、上位モデルは権限で縛る。実験フラグ下の機能ではありますが、マルチエージェントを「なんとなく並列」から「設計して回す」段階に進めるための土台が、この 2 リリースで揃いました。

到達点