Claude Code の Dynamic Workflows で数十〜数百のサブエージェントを一度に動かそう

Claude にサービス全体のバグ調査や、数百ファイルにまたがる移行作業を頼んだとき、「1つの会話の中だけでは手が回りきらないな」と感じたことはないでしょうか。Claude が1人で順番にこなしていくやり方には、どうしても「一度に見られる範囲」の上限があります。コンテキストウィンドウには限りがありますし、調べた中身が増えるほど、最初に見たことが押し出されていきます。

そこへ新しく加わったのが、今回ご紹介する Dynamic Workflows（ダイナミックワークフロー） です。Claude がタスクに合わせてオーケストレーション用のスクリプトをその場で書き起こし、そのスクリプトに従って数十から数百のサブエージェントを並列で走らせて、大きな仕事を分担して片づけてくれます。しかも実行中もセッションは止まらず、僕たちは別の作業を続けられます。

現時点では research preview（研究プレビュー）という位置づけで、Claude Code v2.1.154 以降で利用できます。まだ発展途上の機能ですが、考え方そのものがこれまでのサブエージェントとは少し違っていて面白いので、仕組みから丁寧に見ていきましょう。

Dynamic Workflows とは

ひとことで言うと、Dynamic Workflows は 「サブエージェントを大規模に束ねるための JavaScript」 です。

これまでも Claude Code には、作業を別の Claude（サブエージェント）に切り出して任せる仕組みがありました。Dynamic Workflows が新しいのは、その「どのエージェントを、どんな順番で、何個動かすか」という段取りそのものを、Claude がコードとして書き出す点にあります。

流れはこうです。

1. やりたいことを言葉で伝える
2. Claude がそのタスク用のオーケストレーションスクリプトを書く
3. 専用の実行役（ランタイム）がそのスクリプトをバックグラウンドで実行し、サブエージェントを並列で動かす
4. 途中の結果を突き合わせ、検証したうえで、最終的な答えだけが僕たちの手元に返ってくる

ポイントは、段取りが Claude の頭の中（コンテキスト）ではなく、スクリプトという目に見える形に落ちていることです。スクリプトは読めますし、気に入れば保存して何度でも同じ手順を回せます。途中経過はスクリプトの変数の中に溜まっていくので、Claude のコンテキストには最後の結論しか戻ってきません。だからこそ、1つの会話では抱えきれない規模の作業に踏み込めるわけですね。

向いているのは、たとえばこんな場面です。

• コードベース全体にまたがるバグ調査
• 数百ファイルに及ぶ移行（フレームワークの乗り換え、API の廃止対応、言語ポートなど）
• 複数の情報源を互いに突き合わせて裏取りしたいリサーチ
• 一発で決めるには重すぎる設計を、いくつかの角度から下書きして見比べたいとき

サブエージェント・Skills との違い

Claude Code には、複数ステップの作業をこなす手段がすでにいくつかあります。サブエージェント、Skills、そして今回の Workflows です。混乱しやすいので、「段取り（プラン）を誰が握っているか」という軸で整理してみましょう。

サブエージェントや Skills では、オーケストレーターは Claude 自身です。ターンごとに「次は何を動かそうか」と判断し、結果はすべて Claude のコンテキストに戻ってきます。これに対して Workflows は、ループや分岐、途中結果の保持までをスクリプト側が引き受けます。段取りをコードに移したことで、ただエージェントの数を増やすだけでなく、繰り返し使える品質パターンを組み込めるのが利点です。

たとえば、独立した複数のエージェントに互いの発見を批判的にレビューさせてから報告させる、あるいは1つの設計を複数の角度から下書きさせて天秤にかける、といったやり方ができます。1回きりの単発処理より、結果を信頼しやすくなるわけですね。

Agent Teams との違い

ここまではサブエージェントと Skills を比べてきましたが、「複数のエージェントを並列で束ねる」という意味で、ワークフローに最も近い仕組みがもう1つあります。Agent Teams（エージェントチーム）です。普段から「Agent Team を組織して、この観点ごとに調べさせて」といった頼み方をしている方ほど、ワークフローとどう違うのかが気になるところだと思います。

Agent Teams は、リード役の Claude セッションが複数の「チームメイト」を立ち上げ、共有のタスクリストとメッセージのやり取りで協調させる仕組みです。チームメイトはそれぞれ独立したコンテキストを持つ本物の Claude Code セッションで、メールボックスを通じて互いに直接メッセージを送り合えます。さらに、僕たち自身がリードを介さずに個々のチームメイトへ話しかけ、途中で方針を修正することもできます。なお Agent Teams は実験的機能で、デフォルトでは無効です。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を有効にすると使えるようになります（Claude Code v2.1.32 以降）。

どちらも「エージェントを並列で動かす」点では同じですが、性格はかなり違います。

ひとことで言えば、Agent Teams は「その場で組む、会話できるチーム」、Dynamic Workflows は「コードに固めた、回しっぱなしのパイプライン」 です。

チームメイト同士に仮説をぶつけ合わせたり、僕たちが横から「そっちじゃなくてこっちを見て」と口を挟んだりしたいなら、Agent Teams が向いています。公式でも、PR レビューを観点ごとに分担する、競合する仮説を立てて互いに反証させながらバグの真因に迫る、といった協調的・探索的な作業が得意分野として挙げられています。推奨されるチームの規模も3〜5体ほどです。

一方、分担すべき作業が多すぎて一つひとつ見ていられないとき、毎回まったく同じ段取りで回したいとき、結果を機械的にクロスチェックしたいときは、ワークフローの出番です。スクリプトが制御を握るので、実行中に話しかけて軌道修正することはできませんが、その代わり数十から数百のエージェントを破綻なく回し、気に入った段取りは /コマンド として保存して何度でも同じように再現できます。

普段スキルやプロンプトに「Agent Team を組織して〜」と書き込んでいる作業を、いちど思い浮かべてみてください。そのうち、毎回同じ手順で回したいものや、規模が大きくて付きっきりになれないものは、ワークフローに移してスクリプトとして保存しておくと、再現性とスケールの面で扱いやすくなります。逆に、相手と相談しながら詰めていきたい段階の作業は、これまでどおり Agent Teams のほうが心地よいはずです。両者は置き換え合うものというより、手元の作業の性質で選び分ける関係だと捉えるとよいと思います。

まずは /deep-research で触ってみる

理屈はこのくらいにして、実際に動かしてみるのが一番です。手早く雰囲気をつかむなら、Claude Code に最初から組み込まれているワークフロー /deep-research を使うのがおすすめです。

これは1つの問いを、複数の角度から Web 検索で調べ、見つけた情報源を互いに突き合わせて裏取りし、出典つきのレポートにまとめてくれるワークフローです。

/deep-research Node.js のパーミッションモデルは v20 から v22 で何が変わったのか

実行すると、Claude Code が「このワークフローを実行してよいか」を確認してきます。Yes を選ぶと、調査がバックグラウンドで始まります。手元のセッションは空いたままなので、その間に別の作業を進められます。

途中経過を見たくなったら、/workflows を実行してください。

/workflows

実行中・完了済みのワークフローが一覧で出てくるので、矢印キーで選んで Enter を押すと、進捗ビューが開きます。各フェーズごとに、動いているエージェントの数、消費トークン量、経過時間が表示され、フェーズの中に潜っていけば、個々のエージェントが何を調べているのかまで確認できます。

調査が終わると、レポートがセッションに戻ってきます。それぞれの主張がどの情報源から来たのかが明記され、突き合わせで裏が取れなかった主張はあらかじめ除かれた状態で届きます。なお /deep-research は Web 検索（WebSearch ツール）が使える環境であることが前提です。

自分のタスクをワークフローにする

組み込みのワークフローを試して感触がつかめたら、いよいよ自分のタスクで動かしてみましょう。方法は大きく2つあります。

プロンプトに「workflow」と書く

一番手軽なのは、プロンプトのどこかに workflow という単語を入れることです。セッション全体の設定を変えずに、その1回だけをワークフローとして動かせます。

src/routes/ 配下のすべての API エンドポイントに認証チェックの漏れがないか、workflow で監査して

このように書くと、Claude Code が入力中の workflow という単語をハイライトし、ターンごとに自分で処理する代わりに、タスク用のワークフロースクリプトを書き起こします。

ちなみに、そんなつもりはないのに workflow が反応してしまったときは、alt+w を押せばそのプロンプトでは無視できます。たとえば「ワークフローを整理する話」のように、単語として書いただけのときに便利ですね。

/effort ultracode で Claude に任せる

もう1つは、ultracode という新しい effort（思考の強度）レベルを使う方法です。

/effort ultracode

ultracode は、xhigh の推論強度と、ワークフローの自動オーケストレーションを組み合わせた設定です。これを有効にすると、こちらから頼まなくても、Claude が「このタスクはワークフローにする価値があるか」を自分で判断してくれます。1つの依頼が複数のワークフローに分かれることもあります。たとえば、コードを理解するためのワークフロー、変更を加えるためのワークフロー、それを検証するためのワークフロー、といった具合です。

その分、セッション内のすべてのタスクで使うトークンが増え、時間もかかります。ultracode はそのセッションの間だけ有効で、新しいセッションを始めるとリセットされます。通常の作業に戻るときは、/effort で普段のレベルに戻しておきましょう。既定は多くのモデルで high ですが、より深い推論を求めるなら xhigh を常用してもかまいません（Opus 4.7 ではそもそも xhigh が既定です）。なお ultracode は xhigh に対応したモデルでのみ選べる設定で、対応していないモデルでは /effort のメニューに出てきません。

実行前の承認とパーミッション

ワークフローはたくさんのエージェントを動かすため、いきなり走り出すのではなく、実行前に承認を求められます。CLI では、計画されたフェーズの一覧とともに、次のような選択肢が表示されます。

• Yes, run it — そのまま実行する
• Yes, and don't ask again for <name> in <path> — 実行し、このプロジェクトのこのワークフローについては以後確認しない
• View raw script — スクリプトの中身を読んでから決める
• No — キャンセルする

Ctrl+G でスクリプトをエディタで開けますし、Tab を押せば実行前にプロンプトを調整できます。中身が気になるときは、遠慮なく覗いてから判断しましょう。

確認ダイアログが出るかどうかは、パーミッションモードによって変わります。

ここで1つ押さえておきたいのは、このダイアログが制御しているのは 「起動時の確認」だけ だという点です。ワークフローが生み出すサブエージェントは、手元のセッションのモードに関わらず常に acceptEdits モードで動き、設定済みのツール許可リストを引き継ぎます。ファイルの編集は自動承認されます。

一方で、許可リストに入っていないシェルコマンドや Web フェッチ、MCP ツールは、実行の途中で確認を求めてくることがあります。長く走らせるワークフローでこれに邪魔されたくないときは、エージェントが必要とするコマンドをあらかじめ許可リストに加えておくとスムーズです。

/workflows ビューで進捗を見る

先ほども少し触れましたが、/workflows ビューはワークフローの司令塔です。バックグラウンドで進む作業の様子を、ここから細かく見守れます。進捗ビューでよく使うキーをまとめておきます。

入力欄の下に出るタスクパネルからも、一行の進捗サマリーを確認できます。下矢印でそこにフォーカスを移し、Enter で展開すると詳しく見られます。

ワークフローを保存して使い回す

ある実行が思いどおりに動いたら、そのスクリプトをコマンドとして保存できます。たとえば「ブランチを切るたびに回すレビュー」のような定型作業なら、毎回同じオーケストレーションを呼び出せるわけです。

/workflows で残しておきたい実行を選び、s を押します。保存ダイアログでは Tab で2つの保存先を切り替えられます。

• .claude/workflows/（プロジェクト内） — リポジトリをクローンした全員と共有される
• ~/.claude/workflows/（ホームディレクトリ） — すべてのプロジェクトで使えるが、自分だけに見える

Enter で保存すれば、以後のセッションで /<name> として呼び出せるようになり、/ の入力補完にも組み込みワークフローと並んで出てきます。チームで揃えたい手順はプロジェクトに、自分用の道具はホームに、と使い分けると整理しやすいですね。なお、プロジェクトのワークフローと個人のワークフローが同じ名前になった場合は、プロジェクト側が優先されます。

この「保存して共有できる」という性質は、Skills や Hooks と同じく、Claude Code を自分たちの開発フローに馴染ませていくうえで効いてくるところだと思います。

仕組みと制約

少しだけ内部の話に踏み込んでおきます。スクリプトを実際に動かしているのは「ランタイム」と呼ばれる実行役です。普段やり取りしている Claude 本体とは別に、裏でスクリプトを進める仕組みだと考えてください。このランタイムは、僕たちの会話とは切り離された隔離環境でスクリプトを実行します。途中結果は Claude のコンテキストではなくスクリプトの変数に保持され、ランタイムは各エージェントの結果を逐一記録していきます。この記録があるおかげで、止めても同じセッション内なら再開できるわけです。

そのうえで、ランタイムにはいくつかの制約があります。

止めたワークフローを再開すると、すでに完了したエージェントはキャッシュされた結果を返し、残りはその場で動き直します。ただし再開が効くのは同じ Claude Code セッションの中だけです。ワークフローの実行中に Claude Code を終了すると、次のセッションでは最初からやり直しになる点は覚えておきましょう。

コストとモデルの話

ワークフローは多数のエージェントを動かすため、同じ作業を会話の中でこなす場合より、1回の実行で目に見えて多くのトークンを消費することがあります。 公式の案内でも「強力だが高くつくこともある。トークンを速く消費するので、まずはスコープを絞ったタスクから感触をつかんでほしい」と明言されています。

実行はほかのセッションと同じく、プランの利用量やレート制限にカウントされます。とはいえ、/workflows からはいつでもワークフローを停止でき、その時点で完了している作業は失われません。「思ったより回りすぎているな」と感じたら、途中で止めればよいと思います。

モデルについても一点。ワークフロー内の各エージェントは、スクリプトが特定の段階を別のモデルに振り分けないかぎり、手元のセッションのモデルをそのまま使います。 ですから、

• 普段ルーティン作業で小さいモデルに切り替えている人は、大きな実行の前に /model を確認しておく
• タスクを伝えるときに「最も強いモデルが要らない段階は小さいモデルを使って」と添えておく

といった一手間で、コストをある程度コントロールできます。

最初は小さく、たとえば1つのディレクトリ配下の監査あたりから試して、自分のプロジェクトでどのくらいトークンを使うのかを体感しておくのが安心です。

ワークフローをオフにする

僕自身はこの機能をオフにして使う場面がまだないので、ここは公式ドキュメントの記載をもとにまとめておきます。不要なときは、次の方法でオフにできるとされています。

自分の環境だけでオフにするなら、次のいずれかです。

• /config の Dynamic workflows をオフにする（セッションをまたいで持続）
• ~/.claude/settings.json に "disableWorkflows": true を設定する（同じく持続）
• 環境変数 CLAUDE_CODE_DISABLE_WORKFLOWS=1 を設定する（起動時に読まれる）

組織全体で無効にしたい場合は、マネージド設定で "disableWorkflows": true を指定するか、Claude Code の管理者設定ページのトグルを使う、と案内されています。無効化すると、組み込みワークフローのコマンドは使えなくなり、workflow というキーワードも反応しなくなり、/effort のメニューから ultracode も消える、とのことです。

早期ユーザーの事例

最後に、すでに Dynamic Workflows を使った人たちの事例を、公式ブログなどで見かけた範囲で紹介しておきます。僕自身が試した結果ではなく聞いた話ですが、規模感は伝わってくると思います。

なかでも目を引くのが、Bun の作者である Jarred Sumner 氏のケースです。Dynamic Workflows を使って Bun を Zig から Rust へ移植し、約750,000行の Rust を生み出したうえで、既存テストスイートの 99.8% がパスする状態を、11日間で作り上げたと報告されています。数千ファイルにまたがる言語ポートのような作業でも、端から端まで通しきれる、というのがこの事例から伝わってきます。

ほかにも、従来の静的解析では見つけきれなかったデッドコードやクリーンアップの余地を洗い出し、保守作業を前進させた、という使い方も共有されています。フレームワークの乗り換えや API の廃止対応など、「1人のエージェントには大きすぎるが、人手でやるには骨が折れる」タスクと相性がよさそうです。

利用できるプランについても触れておきましょう。Dynamic Workflows はすべての有料プランで使えます。Max と Team プランではデフォルトで有効、Pro では /config の Dynamic workflows の行からオンにできます。Enterprise では管理者がマネージド設定から有効化する形です。加えて、Anthropic API 経由や、Amazon Bedrock・Google Cloud Vertex AI・Microsoft Foundry でも利用できます。

まとめ

Claude Code の Dynamic Workflows について、仕組みから使い方、コストの考え方まで見てきました。要点を振り返っておきましょう。

• Dynamic Workflows は Claude がその場で書くオーケストレーションスクリプトで、ランタイムが数十〜数百のサブエージェントを並列で束ねます。research preview として、v2.1.154 以降で使えます
• サブエージェントや Skills が「Claude が段取りを握る」のに対し、Workflows は 段取りをコードに移すのが本質です。途中結果はスクリプトの変数に溜まり、Claude のコンテキストには結論だけが返ります
• 同じ「並列でエージェントを動かす」仲間でも、会話しながら進める Agent Teams と 段取りをコードに固めて回す Workflows は性格が異なります。相談・探索なら前者、規模と再現性なら後者が向いています
• まずは組み込みの /deep-research で感触をつかみ、自分のタスクは プロンプトに workflow と書くか、/effort ultracode で Claude に判断を任せる、という2通りで始められます
• /workflows ビューから進捗の確認・一時停止・停止・保存ができ、気に入った実行は /<name> のコマンドとして保存して使い回せます
• 多数のエージェントを動かすぶん トークン消費は増えがちです。小さなスコープから試し、必要に応じてモデルを使い分けるのが安心です

「1つの会話では抱えきれない大きさ」の仕事をどう任せるか、というのは、エージェントを実務に組み込むうえで避けて通れないテーマです。Dynamic Workflows は、そこに「段取りそのものをコードにして、読めて・再実行できて・並列で回せる形にする」という答えを示してくれました。まだ research preview ではありますが、まずはスコープを絞った監査やリサーチあたりから、気軽に触ってみてはいかがでしょうか。

参考リンク

• Orchestrate subagents at scale with dynamic workflows - Claude Code 公式ドキュメント
• Introducing dynamic workflows in Claude Code - Anthropic 公式ブログ