サブエージェント(Claudeが裏で呼び出す作業役のClaude)を、私はよく「下請けの分身」と説明してきました。2026年6月の更新で、その下請けがさらに下請けを持てるようになりました。組織図が一段深くなったイメージです。

サブエージェントの基本は別記事に書いています。

何が変わったのか

2026年6月10日のClaude Code更新(v2.1.172)で、サブエージェントが自分自身のサブエージェントを起動できるようになりました。階層は最大5レベルまでです。

これまでは、親のClaudeが下請け(サブエージェント)に仕事を振る、までの1段でした。今回の更新で、その下請けがさらに孫請けに振れる。会社でいえば、部長→課長→担当、のように指揮系統が深くなった、という変化です。

入れ子が効く場面

深い入れ子が効くのは、大きな仕事が「分けたら、その一部がまた大きい」ような構造のときです。

たとえば、大規模なシステムの作り替えを頼むとします。親が「画面まわり」「データまわり」「テスト」と3つに分ける。そのうち「画面まわり」自体が大きければ、担当のサブエージェントがさらに「一覧画面」「詳細画面」と分けて、それぞれに孫請けを割り当てる。大きな塊を、無理なく小さくしていけます。

長時間の自律作業を支える土台にもなります。新しいAIモデルFable 5で大仕事を任せる話は、別記事に。

深ければいいわけではない

ただし、階層を深くすればするほど良い、という話ではありません。

入れ子が深くなると、指揮系統が長くなり、途中で意図がずれたときに原因を追いにくくなります。人間の組織でも、階層が深い会社ほど現場の状況が上に伝わりにくいのと同じです。

私の感覚では、ふだんの作業なら1〜2階層で十分。5階層まで使うのは、本当に大規模で、分割の構造がはっきりしている作業に限られます。「使えるから深くする」ではなく、「作業の構造が深いから、それに合わせる」が正しい順番です。

コストと所要時間にも効く

階層が増えると、動くサブエージェントの数も増えます。

サブエージェントはそれぞれがトークン(AIが処理する文章量の単位で、料金に響く)を消費します。深い入れ子で大量の分身が動けば、その分コストもかさむ。重い作業を任せる前に、本当にその深さが要るかを一度考えるクセが、コスト管理では効きます。

チームで動かす機能との関係

サブエージェントの入れ子と混同しやすいのが、複数のエージェントをチームのように動かす機能です。役割が少し違います。

入れ子は「1つの大きな仕事を、上から下へ分解していく」縦の広がり。一方でチーム的な動かし方は、役割の違うエージェントを横に並べる発想です。縦に深くするのか、横に並べるのか。作業の形に合わせて選びます。

実際には、横で分けた担当の中で、さらに縦の入れ子が起きる、という組み合わせもあります。どちらか一方ではなく、両方が噛み合って大きな仕事が回ります。

非エンジニアはどう捉えるか

正直に言うと、非エンジニアが「5階層の入れ子」を自分で細かく設計する場面は、まずありません。

大事なのは、Claudeに大きな仕事を任せたとき、裏側でこういう「分けて、さらに分けて」が自動で起きうる、と知っておくことです。仕組みを知っていれば、「なぜこの大仕事を最後までやり切れたのか」が腹落ちするし、結果がずれたときに「分割のどこかで意図が伝わらなかったかも」と当たりを付けられます。

裏側の動きを知ることは、任せ方の上達につながります。

まとめ

  • 2026年6月10日の更新(v2.1.172)でサブエージェントの入れ子(最大5階層)に対応
  • 下請けがさらに孫請けに仕事を振れる、指揮系統が深くなる変化
  • 大きな塊が「分けても一部がまた大きい」構造の作業で効く
  • 深ければ良いわけではなく、深いと原因追跡が難しくなる
  • 階層が増えると動く分身が増え、トークン消費とコストもかさむ
  • 非エンジニアは設計より「裏でこう動く」と知っておくと任せ方が上達する