第14回 ClaudeがClaudeを起動する（サブエージェント・Agent Teams・Dynamic Workflows）

起動するのが、人からClaude自身に変わる場面がある。

前回、仕事は人が起動するものから、仕組みが起動するものへ変わった。今回はもう一段深く進む。

第8回で「2体目を立てる」を学んだとき、あなたはまだ両方のタブを自分で開いていた。ここから先は違う。メインのClaudeが、判断の結果として別のClaudeを呼ぶ。呼ばれた側はさらに別の誰かを呼ぶこともある。

この構造には、性格の違う3つの実装がある。サブエージェント・Agent Teams・Dynamic Workflowsだ。名前だけ覚えても意味がない。誰がプランを持っているかで見分けると、使い分けを間違えなくなる。

業務のたとえで先に地図を描くと、外部専門会社への委託がサブエージェント、合同会議がAgent Teams、標準作業手順書（SOP）がDynamic Workflowsに近い。この対応関係を頭の片隅に置いたまま読み進めてほしい。

3つの仕組みの正体

誰がプランを持つかで、3つの仕組みは分かれる。

サブエージェントは、外部の専門会社への委託に似ている。担当者（メインのClaude）が「この作業は専門会社に頼もう」と判断し、委託先（サブエージェント）は自分の持ち場で仕事をして、レポートだけを返す。委託先同士が直接話すことはない。

Agent Teamsは、合同会議に似ている。3〜5人の専門家が同じ場に集まり、タスクリストを共有しながら直接意見を交わす。誰かが一方的に指示するのではなく、対等な立場で協調する。公式ドキュメントは「単一セッションより大幅にトークンを消費する」と明記しており、推奨される開始規模は3〜5体だ。

Dynamic Workflowsは、標準作業手順書（SOP）に似ている。あらかじめ書かれた手順書（スクリプト）に沿って、担当者がその場その場で判断を下さなくても淡々と実行されていく。判断はすでに手順書を書いた時点で終わっている。

公式が語る「計画をコードに移す」という発想

Dynamic Workflowsの核心は、判断そのものをコードに埋め込むという発想の転換にある。公式ドキュメントはこう説明している。

サブエージェントやAgent Teamsでは、判断そのものはまだその場のClaudeが握っている。何を次にやるか、誰に振るかを、実行の途中で毎回考えている。Dynamic Workflowsでは、その判断はすでにスクリプトを書いた時点で終わっていて、実行時はランタイムが機械的にこなすだけになる。

だからこそ規模が違う。サブエージェントはセッションあたり既定200体、ネストは深さ5階層まで。Agent Teamsは推奨3〜5体。Dynamic Workflowsは1実行あたり最大1,000体、同時16体まで走らせられる。判断をコードに移した分だけ、扱える数が桁で変わる。

この「深さ5階層」という上限には、本人の説明がある。ネストサブエージェントがリリースされた日、Boris Chernyはこう投稿した。

見落としがちなのは、この機能の動機だ。ネストの狙いは並列化ではない。本人の言葉を借りれば「better manage context」、コンテキストをうまく管理する手段としてだ。委託を重ねる理由は、こなす量を増やすことではなく、1つの塊のまま抱えると膨らみすぎる文脈を、階層ごとに小さく切り分けて持たせることにある。

チームのエンジニアであるThariq ShihiparとSid Bidasariaは、この転換をこう表現している。

「ハーネス」という言葉が独特に聞こえるかもしれない。Claude Code自体が、Claudeの周りに用意された実行環境という意味での「ハーネス」だ。Dynamic Workflowsは、そのハーネスの縮小版を、Claudeがタスクごとに自分で組み立てるという話になる。

起動してみる

起動は、ひとことのキーワードで済む。

$ultracode 全記事のリンク切れを検出して修正案をまとめてほしい
Building workflow script: scan -> verify -> fix -> report
Spawning up to 16 concurrent agents...

起動のキーワードは ultracode、またはセッション既定にする /effort ultracode だ。ここは意図的にオプトインにされている。何もかもをDynamic Workflowsで動かすのではなく、規模と反復が必要な仕事だけに絞って呼び出すのが本来の使い方になる。

使い分けの軸

見分ける軸はひとつだけだ。誰がプランを持っているか、それだけを見る。

「N個の対等なセッションが会話する」ならAgent Teams、「司令塔がN個のタスクをコードで統制する」ならDynamic Workflows。プランをターンごとに判断しているのがリードなのか、すでに書かれたスクリプトなのか、その違いだけを見る。

よくある誤解と罠

• 数が多いほど良いと思い込む: 公式は25体超、または見込み150万トークン超で「Large workflow」の警告を出す。数は目的から逆算するもので、目的にすること自体ではない。Anthropicのエンジニアリングブログは、マルチエージェント構成のOpus 4が単一エージェントのOpus 4を社内リサーチ評価で90.2%上回った一方、トークン消費は通常のチャット利用の約15倍に達したと報告している。効果は本物だが、無料ではない。同じ報告が挙げる失敗例は、単純な事実確認のクエリに50体のサブエージェントを投入すること、存在しない情報源を延々と探し続けること、サブエージェント同士が過剰な更新で気を散らし合うことの3つだ
• Agent Teamsを安いサブエージェントの代わりに使う: 対等な通信にはトークンコストがかかる。単に会話を分けたいだけならサブエージェントで十分
• 図解を鵜呑みにする: ネット上には「実装役・検証役・修正役」という3つの役割ラベルで説明する図が出回っているが、これはAnthropicの公式用語としては確認できていない。adversarial verificationという概念の実体は本物だが、その図の細部は非公式の解釈だと知っておく

今日のまとめ

• サブエージェントは外部委託、Agent Teamsは合同会議、Dynamic Workflowsは標準作業手順書（SOP）に近い
• 見分ける軸は「誰がプランを持つか」。ターンごとの判断ならAgent Teams、書かれたスクリプトの実行ならDynamic Workflows
• 判断をコードに移した分だけ扱える数が桁で変わる。ただし数を目的にはしない