このレッスンで終わる頃には
- Claude Codeの拡張機能を「誰が制御を持つか」で説明できる
- Agent TeamsとDynamic Workflowsの違いと使い分けが言える
- 大規模に走らせるときの、コストと検証の守り方が分かる
このレッスンで作るもの
前のレッスンの続き: 「並列」の先にある世界
前のレッスンで、ターミナルのタブを2枚開いてClaudeを2人走らせました。あれがマルチエージェントの入り口です。
で、その先がどうなっているか。
Claude Codeを作ったAnthropicのBoris Chernyさんは、2026年6月の講演で「もう8ヶ月、コードを1行も手で書いていない」と話しています。ターミナルで5人のClaudeを並列で走らせ、さらにクラウド側でも5〜10人動かす。1人のマネージャーが現場対応・会議・書類仕事を並行で回すように、AIの側が「組織」になってきたわけです。
ただ、機能の名前が一気に増えたせいで、ここで迷子になる人が多い。サブエージェント、Agent Teams、Dynamic Workflows、ultracode。
大丈夫です。「誰が制御を持つか」という1本の軸で並べると、全部きれいに整理できます。
まず地図: 「誰が制御を持つか」で選ぶ
手順書
人が用意した型に沿う
再現したい作業
リードClaude
分けて任せ、結果を受け取る
独立した分担
チーム
互いに話し、その場で調整する
議論が必要な仕事
コード
決めた工程を反復して実行する
大量の反復
会社の仕事に置き換えると、こうなります。
この4つに、強さの順はありません。マニュアルで済む仕事に部署横断の作戦会議は開かないですよね。それと同じで、仕事の形に合わせて仕組みを選ぶのがこの地図の使い方です。
SkillsとSubagentsは前のレッスンまでに登場済み。今日は残りの2つ、Agent TeamsとDynamic Workflowsを見ていきます。
Agent Teams: Claude同士が相談する（実験的機能）
Agent Teamsは、複数のClaude Codeセッションが「チームメイト」として直接やり取りする機能です。
サブエージェントとの違いはここ。サブエージェントは、上司（メインの会話）に結果を報告するだけでした。Agent Teamsでは、1人のリード＋複数のチームメイトが共有のタスクリストを持ち、チームメイト同士が直接メッセージを送り合えます。
「Aの調査結果を見たBが、自分の担当範囲の仮説を修正する」みたいな、会話しながらの協調ができるわけです。
まだ実験的機能なので、環境変数で自分でONにする方式です。
$export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1$claude$3人のチームを作って、この提案書ドラフトを「構成」「エビデンス」「表現」の3視点で並列レビューして。互いの指摘が矛盾したら相談して統一見解にして
向いているのは、視点の違うメンバーが議論すると質が上がる仕事。並列レビュー、対立する仮説を1つずつ持たせるデバッグ、新機能の分担実装などです。
注意
トークン消費は覚悟する
公式ドキュメントに「単一セッションよりかなり多くのトークンを使う」と明記されています。推奨は3〜5人から。前のレッスンの「2並行で十分」の感覚のまま、必要なときだけ開くのが正解です。
サブエージェントとの違い、向くタスク、設定方法。実験的機能なので仕様は変わりうる。
Dynamic Workflows: Claudeが工場のラインを設計する
もう1つの、そしてもっと大規模な方式がDynamic Workflowsです。
仕組みが面白い。あなたが大きな仕事を頼むと、Claudeがまず「作業手順のスクリプト」を書きます。どのタスクを何体のエージェントに配るか、結果をどう集めるかをコードにする。そしてそのスクリプトをClaude Codeのランタイムが裏で実行します。
Agent Teamsとの違いは「誰がプランを持つか」。Teamsではリードが会話しながらその都度判断しますが、Workflowsではスクリプト自体が工程表。ループも分岐も途中結果もスクリプト側が持つので、メインの会話には最終結果だけが戻ってきます。
規模も桁が違います。公式ドキュメントいわく、1回の実行で数十〜数百のエージェント。同時に動くのは16体まで、合計1,000体が上限です。
起動はあっけないほど簡単で、プロンプトに「ultracode」という言葉を入れるだけ。
$ultracode このリポジトリの記事120本すべてについて、事実関係の誤りがないか徹底監査して。見つけた指摘は別のエージェントに反証させて、生き残ったものだけ報告して
この例文の後半に、大規模運用のいちばん大事な工夫が入っています。
数を増やすなら、疑う役を入れる
エージェントを数百体走らせると、量は稼げますが、もっともらしい間違いも混ざります。
そこで公式ドキュメントが挙げているのが、独立したエージェント同士に互いの発見を敵対的にレビューさせてから報告するというパターンです。たとえばこんな流れです（役割名は説明用です。公式の固有名詞ではありません）。
- 作る役が実装や調査をする
- 疑う役が2体、独立に「この結果は間違っていないか」だけを考えて検証する
- 直す役が指摘を反映して、最後に報告が上がってくる
これ、働く人にはおなじみの発想のはずです。ダブルチェックや相互レビューと同じ構造。作った本人に確認させるのではなく、疑うことだけが仕事の別人を立てる。AIの世界でも、これが「数を質に変える」定石になっています。
使い分けチートシート
判断に迷ったら、「会話で協調させたいのか、コードで統制したいのか」を自問してください。前者がTeams、後者がWorkflowsです。
もう1枚の地図: エージェント数で見る「自分の現在地」
道具の地図が頭に入ったら、もう1枚。今度は使う側の人間がどう成長していくかの地図です。
Claude Codeを作ったBoris Chernyさんは、AI活用の成熟度を「同時に動くエージェントの数」で段階分けしています（2026年7月の整理）。数字がそのまま自分の現在地になる、シンプルで強い物差しです。
この地図で見ると、今日のレッスンの位置づけがはっきりします。前のレッスンのタブ2枚はStep 2の入り口。今日のAgent TeamsとDynamic Workflowsは、Step 3に上がるための道具です。100体の世界は、工場（Workflows）なしには回りません。
そして大事なのは、段階を上げる鍵が毎回同じだということ。Step 1から2へ上がる条件は「信頼できる自己検証ループ（テスト・ビルド・lint）を持つこと」。Step 2から3へは「仕事をループとルーティンに分解すること」。つまり、エージェントを増やす前に、検証を増やす。この順番が崩れると、どの段階でも事故ります。
作った人たちが繰り返し言うこと
最後に、道具の使い方より大事な話。Claude Codeを作っている2人が、インタビューやポッドキャストで繰り返し強調している原則が2つあります。
1つ目はBoris Chernyさん。「Claudeに自分の仕事を検証する手段を与えることが、良い結果を得るためのおそらく最も重要なこと」。テストでも、実行結果でも、チェックリストでもいい。検証手段があるだけで結果が2〜3倍良くなると言っています。数百体の工場を回すときほど、この原則が効きます。
2つ目はプロダクト責任者のCat Wuさん。自動化は「まず1件でテストして、挙動を確かめてから10件に広げる」。いきなり全量に流さない。
新しい施策をいきなり全社員に展開しないのと同じです。小さく検証してから、スケールする。マルチエージェントの世界でも、この慎重さがそのまま通用します。
ultracodeの起動方法、スケールの上限、Agent Teams・Subagentsとの公式比較表。
Boris ChernyとCat Wuが設計思想を語る回。検証ループと「小さく始める」原則の原典。
コストの話（今回も正直に）
並列数が増え、エージェント同士の協調が増えるほど、トークン消費は跳ね上がります。
Dynamic Workflowsには一応ガードレールがあって、25体を超えるか、見込み150万トークンを超えると警告が出ます。ただし警告は出るだけで、止まりはしません。
守り方は今日出てきた原則そのままです。
- まず小さく。Teamsは3〜5人、Workflowsも小さな範囲で1回試す
- 検証手段をセットで渡す。数が増えるほど、疑う役の価値が上がる
- 日常業務はSkillsかSubagentsで十分。Agent TeamsとDynamic Workflowsは「ここぞ」の仕事だけ
増やす前に、留保をひとつ
ここまで、増やす方向の話を続けてきました。ここで一度、逆側の声にも耳を傾けます。
Boris ChernyもCat Wuも、無条件に増やせと言っていたわけではありません。検証手段を持つこと、まず小さく試すこと。ここまでの原則は、どちらも増やす前提に条件をつけていました。
その条件そのものを疑う声もあります。TDDの考案者として知られるKent Beckは、マルチエージェントの礼賛に真正面から異を唱えています。
“Nobody wants agents. Nobody wants agent swarms. I have a system and I want it to change.”
筆者訳誰もエージェントなど求めていない。誰もエージェントの群れなど求めていない。私にはシステムがあり、それを変えたいだけだ。
Beckの指摘は、道具そのものへの否定ではありません。目的と手段を取り違えるな、という指摘です。
“Multi-agent is a feature. Outcome-orientation is the thing the feature is supposed to deliver. We keep getting those confused.”
筆者訳マルチエージェントは機能の一つに過ぎない。成果志向こそがその機能が届けるべきものだ。私たちはそこを混同し続けている。
賛否は割れています。増やす側は「検証さえ整えれば、数は速さと網羅性に変わる」と主張します。Beckの側は「欲しいのはシステムの変化であって、エージェントの数ではない」と切り返します。どちらの側も、検証手段を先に用意し、小さく試してから広げるという同じ原則を、別の角度から支えている点は変わりません。
問うべきは、増える体制そのものではなく、それが成果に向いているかどうかです。数を選ぶ前に、まず何のための数かを言葉にしておく。それだけで、ここまでの原則がそのまま効きます。
まとめ
- 地図は「誰が制御を持つか」で選ぶ。Skills、Subagents、Agent Teams、Dynamic Workflows
- Agent Teamsは会話で協調するチーム。視点の違う並列レビューに向く（実験的機能・3〜5人から）
- Dynamic Workflowsはコードで統制する工場。ultracodeで起動し、数百体まで展開できる
- 数を増やすなら「疑う役」を立てる。ダブルチェックと同じ構造
- 自分の現在地は「同時に動くエージェント数」で測れる。1体、10体、100体
- 原則は2つ。検証手段を与える、1件で試してから広げる。エージェントを増やす前に、検証を増やす
- 数がそのまま成果になるわけではない、という留保もある。増やす前に、何のための数かを言葉にする
次はパイプライン。この並列の仕組みをスケジュールと組み合わせて、寝てる間に仕事が終わってる話です。
明日のアクション
今日はAgent TeamsやDynamic Workflowsをいきなり触る必要はありません。まず地図を体に入れましょう。
- 手元のプロジェクトで「サブエージェントを3体使って、このフォルダを3つの視点（構造・内容・改善点）で調べて。最後に3つの報告の食い違いを指摘して」と頼んでみる
- 報告の「食い違い」がどう出るかを観察する。これが「疑う役」の感覚です
チームと工場は、この感覚をつかんでから。それで十分間に合います。