Claude Code Dynamic Workflowとは｜サブエージェントとの違いと使い分け

「Dynamic Workflow」「ultracode」「1,000 エージェント」——リリース告知や技術系のタイムラインでこうした言葉を見かけ、自分の作業に使えそうだと感じている方は多いのではないでしょうか。大規模なリファクタリング、コードベース全体の監査、多角的な調査。これまで「Claude Code に任せきるには大きすぎる」と感じていたタスクが、一気に自動化できそうな予感があります。

一方で、すでにサブエージェント（Agent ツール）を使っている方ほど、ある疑問にぶつかります。「結局、サブエージェントと何が違うのか？」「自分のこのタスクは、通常の対話で済むのか、サブエージェントで足りるのか、それとも Dynamic Workflow を使うべきなのか？」——選択肢が増えたぶん、どれを選べばよいのか判断できないという迷いです。

公式ドキュメントを読んでも、比較表は「誰が計画を持つか（who holds the plan）」という1つの軸で整理されているだけで、「なぜそれが効くのか」「自分のケースならどう選ぶのか」までは、なかなか腹落ちしません。とくに重要なのは、Dynamic Workflow が本質的に何を改善したのか——なぜ中間結果をコンテキストウィンドウではなくスクリプト変数に持つことが効くのか、という点です。ここが理解できると、使い分けの判断は驚くほどシンプルになります。

本記事では、まず Dynamic Workflow とは何かを定義し、通常の Claude Code・サブエージェント・Agent Teams からの「段階的な進化」として技術的な因果を説明します。そのうえで、スクリプトの仕組み・起動方法・使い分けの判断軸・research preview ゆえの制約まで、「自分のタスクにどれを選ぶか」を即断できるところまで一気に解説します。

なお、Dynamic Workflow は 2026 年 5 月 28 日に research preview（試験公開）として提供が始まった機能です。research preview のため、バージョンによって挙動や制約が変わる可能性があります。本記事は執筆時点（2026 年 6 月）の公式ドキュメントに基づいていますので、実際に使う際は最新の公式ドキュメントも併せて確認してください。

Claude Code の Dynamic Workflow とは

Claude Code の Dynamic Workflow（ダイナミックワークフロー）を一言で定義すると、Claude がタスクに応じて JavaScript のオーケストレーションスクリプトを自動生成し、そのスクリプトをランタイムがバックグラウンドで実行する仕組みです。

これまでのように Claude が対話のターンごとに「次に何をするか」を判断するのではなく、ループ・分岐・並列実行といった段取りを記述したスクリプトを Claude 自身が書き、それを実行エンジン（ランタイム）が回します。実体は Workflow というツールで、スクリプトはセッションとは隔離された環境でバックグラウンド実行されるため、スクリプトが動いている間もユーザーはそのまま対話を続けられます。

スケール感も従来とは桁が違います。1 回の実行で最大 16 エージェントを同時並行、総数で最大 1,000 エージェントまで動かせます。「数千ファイル規模のマイグレーション」や「コードベース全体のバグスイープ」といった、これまで 1 つの会話では調整しきれなかった規模のタスクを、1 セッションで回しきることを狙った設計です。

research preview の位置づけ・提供プラン・必要バージョン

Dynamic Workflow は 2026 年 5 月 28 日に research preview として公開されました（公式ブログ）。利用には以下の条件があります。

• 必要バージョン: Claude Code v2.1.154 以降
• 対応プラン: すべての有料プラン（Pro / Max / Team / Enterprise）。Anthropic API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry でも利用可能
• 提供サーフェス: CLI / デスクトップアプリ / IDE 拡張機能

ただし Pro プランの場合は、初期状態でオフになっていることがあります。/config の「Dynamic workflows」の行からオンにして使います。research preview という位置づけのため、提供範囲・バージョン要件・制約は今後変わる可能性があります。

「スクリプトがオーケストレーションを担う」という発想の転換

ここで押さえておきたいのは、Dynamic Workflow の核心が「たくさんのエージェントを並列で動かせること」そのものではない、という点です。本質はオーケストレーション（複数エージェントの段取り・調整）をスクリプトという形に書き起こすことにあります。

従来は Claude が頭の中（コンテキストウィンドウ）で段取りを管理していました。Dynamic Workflow では、その段取りがコードとして外部化されます。この「計画をコードに移す」という発想の転換こそが、サブエージェントとの本質的な違いを生んでいます。次の章で、従来手法と並べながら何が改善されたのかを掘り下げます。

通常の Claude Code・サブエージェントとの違い

Dynamic Workflow を理解する一番の近道は、これまでのマルチステップ実行の手段と並べて見ることです。Claude Code には現在、複数ステップのタスクをこなす方法が大きく 4 つあります。通常の対話 → サブエージェント（Agent ツール）→ Agent Teams → Dynamic Workflow という流れで、段階的に「計画を誰が・どこで持つか」が変わっていきます。

4 つの手段を 5 観点で比較する

公式ドキュメントは、これらの違いを「誰が計画を持つか（who holds the plan）」という軸で整理しています（公式ドキュメント）。その視点を踏まえて、5 つの観点で整理すると次のようになります。

通常の対話・サブエージェント・Agent Teams のいずれも、オーケストレーター（指揮役）は Claude です。Claude が毎ターン「次に何を spawn（生成）するか／誰に何を割り当てるか」を判断し、その結果はすべてコンテキストウィンドウや共有タスクリストに積み上がっていきます。これに対して Dynamic Workflow だけが、計画そのものをスクリプトに移しています。

最重要の差異「計画をコードに移す」がもたらすもの

この記事で最も理解してほしいのが、この「計画をコードに移す（move the plan into code）」という一点です。なぜこれが効くのか、技術的な因果で説明します。

従来の方式では、Claude が毎ターン次の手を決め、すべての中間結果がコンテキストウィンドウに蓄積されていきます。サブエージェントを 10 個動かせば、10 個ぶんの出力がコンテキストに戻ってきます。これには 3 つの代償があります。

• ノイズ: 本当に必要な最終結論に対して、途中経過の大量のテキストがコンテキストを埋め、後続の判断精度を下げる
• コスト: 蓄積されたコンテキストは毎ターン読み直されるため、トークン消費が膨らむ
• 非決定性: 「次に何をするか」を毎回 Claude が判断するため、同じタスクでも実行ごとに段取りがブレる

Dynamic Workflow では、スクリプトがループ・分岐・中間結果を保持します。100 個のエージェントを回しても、その途中結果はスクリプト変数の中に留まり、Claude のコンテキストには最終的な答えだけが届きます。

これにより、上記 3 つの問題が同時に解消されます。ノイズが減るのは中間結果がコンテキストに流れ込まないから、コストの増大が抑えられるのは大量の途中経過を読み直さないから、そして再現性が得られるのは段取りがスクリプトという固定された形になるからです。「数十〜数百エージェント」というスケールが現実的になるのも、この設計があってこそです。コンテキストウィンドウに全結果を積む方式では、エージェントを増やすほどコンテキストが破綻するため、そもそも数百規模は成立しません。

品質担保の仕組み——「より多く回す」以上の価値

計画をコードに移すことには、もう 1 つ見逃せない利点があります。繰り返し適用できる品質パターンを組み込めることです。これは単に「より多くのエージェントを回す」のとは違う価値を持ちます。

公式ドキュメントが挙げる代表的なパターンは 2 つです。

1. 敵対的レビュー（adversarial review）: あるエージェントが出した主張を、別の独立したエージェントが反証しにいく。両者の突き合わせを経て、検証に耐えた主張だけを残す
2. 収束ループ: 同じ問いを複数の独立したアプローチで解かせ、答えが収束するまで突き合わせる

組み込みワークフローの /deep-research はこの考え方を体現しています。複数の角度から Web 検索を展開し、見つけたソースを互いに照合し、各主張について内部で「投票」を行い、相互検証を生き残った主張だけを引用付きのレポートにまとめます。「1 回で出した答え」より「複数の独立した視点が反証し合った末に残った答え」のほうが信頼できる——この品質の作り込みは、計画がコードとして固定されているからこそ毎回確実に適用できるのです。

Dynamic Workflow の仕組みとスクリプトの中身

ここからは、Claude が実際に書くスクリプトの中身を見ていきます。コードを 1 行ずつ解説するというより、スクリプトを構成する「部品（プリミティブ）」の役割を押さえることで、なぜ再現性や中断耐性が生まれるのかを腹落ちさせるのが目的です。

スクリプトを構成する 4 つのプリミティブ

Claude が生成するスクリプトは、おおむね次の 4 つのプリミティブを組み合わせて書かれます。

• agent(prompt, opts): サブエージェントを 1 つ実行する。最も基本の部品。schema オプションを渡すと、結果を構造化データ（JSON）として受け取れる
• parallel(thunks): 複数のエージェントを並列実行し、全員の完了を待つ（バリア付き）。全エージェントの結果が揃ってから次に進みたいときに使う
• pipeline(items, stage1, stage2, ...): 各アイテムを段から段へ流す。バリアなしで、先に終わったものから次の段に進める。スループットが出るためデフォルトで推奨される方式
• phase(title): 処理をフェーズに区切る。区切りは /workflows の進捗ビューに表示され、どこまで進んだかが見やすくなる

イメージをつかむために、ごく簡単な擬似コードで示します（実際のスクリプトは Claude が自動生成するため、書き方の雰囲気をつかむためのものです）。

// フェーズ1: 対象ファイルを並列で監査する
phase("Audit API routes");
const routes = ["routes/users.js", "routes/orders.js", "routes/admin.js"];

// 各ルートを独立したエージェントが調査（全完了を待つ）
const findings = await parallel(
  routes.map((path) => () =>
    agent(`${path} の認可チェック漏れを洗い出して`, {
      schema: { missingAuth: "string[]" },
    })
  )
);

// フェーズ2: パイプラインで「検出 → 反証 → 集約」を流す
phase("Cross-check findings");
const verified = await pipeline(
  findings,
  // 段1: 別エージェントが各検出結果を反証（敵対的レビュー）
  (f) => agent(`次の指摘を反証してみて: ${JSON.stringify(f)}`),
  // 段2: 検証を生き残った指摘だけを集約
  (reviewed) => agent(`検証済みの指摘をレポートにまとめて: ${reviewed}`)
);

parallel で全完了を待ってから次へ進み、pipeline で「検出 → 反証 → 集約」を順に流す——この組み合わせが、前章で触れた敵対的レビューのような品質パターンの実装です。

中間結果はスクリプト変数に、スクリプトはファイルとして残る

上の擬似コードで、findings や verified といった変数に途中結果が入っている点に注目してください。これらはスクリプト変数であって、Claude のコンテキストウィンドウではありません。100 ルートを監査しても、その 100 件ぶんの詳細はスクリプトの中で完結し、Claude には最終レポートだけが返ります。これが前章で説明した「コンテキスト蓄積からの解放」の実装上の正体です。

そして、ランタイムは隔離された環境でこのスクリプトを実行し、実行ごとにスクリプトを ~/.claude/projects/ 配下のセッションディレクトリにファイルとして書き出します。実行開始時に Claude はそのパスを受け取るので、「今のワークフローのスクリプトを見せて」と尋ねれば中身を読めますし、前回の実行スクリプトと差分を取ったり、手で編集して「この編集版で再実行して」と頼んだりもできます。

気に入った段取りが出来上がったら、/workflows ビューでその実行を選んで s キーを押すと、スクリプトを自分のコマンドとして保存できます。保存先はプロジェクト共有の .claude/workflows/ か、自分専用の ~/.claude/workflows/ のどちらかを選べます。保存後は /<名前> で呼び出せる独自コマンドになり、「毎ブランチで回すレビュー」のような繰り返し作業を、毎回まったく同じオーケストレーションで実行できます。再現性が「ワーカー定義」止まりだったサブエージェントと違い、オーケストレーション自体が再利用可能な資産になるわけです。

同セッション内でのレジューム（中断耐性）

ランタイムは実行が進むにつれて各エージェントの結果を追跡しているため、同じセッション内であれば中断したワークフローをレジューム（再開）できます。一度止めて再開すると、すでに完了したエージェントはキャッシュ済みの結果を返し、残りだけがライブで実行されます。/workflows ビューで対象を選んで p キーを押すか、Claude に「同じスクリプトで再開して」と頼めば再開できます。

ただし、この再開はあくまで同一セッション内に限られます。ワークフロー実行中に Claude Code を終了してしまうと、次のセッションでは最初からのやり直しになります。とはいえ、ターンを丸ごと再スタートするしかなかったサブエージェントと比べれば、途中まで進んだ大規模ジョブを無駄にせず再開できるのは大きな利点です。

ultracode で始める 4 つの起動方法

仕組みが分かったところで、実際にどう起動するかを見ていきます。Dynamic Workflow の起動には大きく 4 つの経路があります。手を動かすときに迷わないよう、それぞれの使いどころを整理します。

4 つの起動経路

1. プロンプトに ultracode キーワードを含める

セッション全体の挙動を変えずに、単発のタスクだけをワークフローとして実行したいときの基本形です。プロンプトに ultracode を含めると、Claude はそのタスクを（ターンごとに進めるのではなく）ワークフロースクリプトとして書き起こします。

ultracode: src/routes/ 以下の全 API エンドポイントを認可チェック漏れの観点で監査して

入力中、Claude Code はこのキーワードをハイライト表示します。意図せず起動しそうになったら、macOS は Option+W、Windows / Linux は Alt+W でそのプロンプトのハイライトを解除できます。なお、v2.1.160 以前ではトリガーキーワードが workflow でしたが、現在は ultracode です（自然言語でのリクエストはどちらのバージョンでも有効）。

2. 自然言語で「workflow を使って」と頼む

「use a workflow」「ワークフローで実行して」のように自分の言葉で頼んでも、Claude は同じオプトイン（明示的な許可）として扱い、ワークフローを書きます。キーワードを覚えていなくても起動できます。

3. /effort ultracode でセッション全体に自動適用

ultracode は、xhigh の推論努力（reasoning effort）と自動ワークフロー化を組み合わせた設定です。

/effort ultracode

これをオンにすると、Claude はセッション中のすべての本格的なタスクについて「ワークフローにすべきか」を自分で判断します。1 つの依頼が複数のワークフローに分かれることもあります（コードを理解する用・変更する用・検証する用、というように）。そのぶん各リクエストはトークン消費が増え、時間もかかります。ultracode は現在のセッションの間だけ有効で、新しいセッションを始めるとリセットされます。通常作業に戻るときは /effort high などで下げます。

4. 組み込みワークフロー /deep-research

最も手早く動きを体感できるのが、組み込みの /deep-research コマンドです。多数のソースを横断して問いを調査し、複数の角度から検索を展開・相互照合し、引用付きのレポートを 1 つ返します。

/deep-research Node.js の permission model は v20 から v22 で何が変わった？

承認カードと /workflows での進捗確認・保存

ワークフローを起動しようとすると、Claude Code は実行前に承認を求めます。CLI では予定されているフェーズの一覧が示され、「Yes, run it（実行）」「Yes, and don't ask again（このワークフローは今後確認しない）」「View raw script（スクリプトを確認）」「No（キャンセル）」が選べます。デスクトップアプリでは、ワークフロー名・フェーズ一覧・トークン使用量の注意書きを載せた承認カードが表示されます。大量のトークンを消費しうる機能なので、実行前に規模を把握できるようになっているわけです。

実行が始まると処理はバックグラウンドで進みます。/workflows を実行すると、進行中・完了済みのワークフローが一覧され、選択すると進捗ビューが開きます。ビューには各フェーズのエージェント数・累計トークン・経過時間が表示され、フェーズを掘り下げれば個々のエージェントが何を見つけたかまで確認できます。前章で触れたとおり、この進捗ビューから s キーでスクリプトをコマンドとして保存できます。

どんなタスクで使うべきか（ユースケースと使い分けの判断軸）

ここまでで「何が違い、何が改善されたか」は押さえられました。いよいよ本記事の核心、「自分のこのタスクに、結局どれを使えばよいのか」に答えます。

公式が挙げる 4 つのユースケース

公式は Dynamic Workflow が効くタスクとして、次の 4 つを挙げています。

1. コードベース監査: セキュリティレビューやバグハント。リポジトリ全体にわたって認可チェック漏れや脆弱性を横断的に洗い出す
2. 大規模マイグレーション: 数百〜数千ファイル規模の移行。1 会話では到底さばききれない量のファイルを、多数のエージェントで並列処理する
3. クリティカルな検証作業: 失敗が許されない判断について、複数の独立したアプローチで検証し突き合わせる
4. 複数角度からの調査: ある問いを複数視点で調べ、ソースを相互検証したうえでレポートに統合する（/deep-research がこの典型）

これらに共通するのは、「単独のエージェントを 1 回走らせる」のでも「数個のサブエージェントを並行させる」のでもなく、多数のエージェントを段取りよく協調させ、かつ結果の質を担保したいという性格です。

使い分けの判断軸——サブエージェントで十分か、Dynamic Workflow が適するか

実務では、次の問いに当てはめると判断しやすくなります。

サブエージェントで十分なケース

• 1 つの会話で調整しきれる、少数（数個程度）の並行委任で済む
• 段取りを毎回作り直しても問題ない（再現性をそこまで求めない）
• 中間結果がコンテキストに乗っても許容できる量に収まる

「テストファイルを 3 つ並行で直して」「この機能とこの機能を別々のエージェントで調べて」といった、少数並行の委任はサブエージェントの土俵です。Dynamic Workflow を持ち出すと、承認やトークン消費のオーバーヘッドのほうが大きくなります。

Dynamic Workflow が適するケース

• 1 会話では調整しきれない数のエージェントが必要（数十〜数百規模）
• オーケストレーション自体を再利用したい（毎ブランチで回すレビュー、定期的な監査など）
• 高い再現性や品質担保が要る（敵対的レビューや収束ループで結論の信頼性を上げたい）
• 中間結果をコンテキストから逃がしたい（大量の途中経過でノイズ・コストが膨らむのを避けたい）

ざっくり言えば、「規模・再現性・品質担保」のいずれかが本気で必要になった瞬間が、サブエージェントから Dynamic Workflow へ乗り換える分岐点です。逆に言えば、その必要がないなら無理に使わず、サブエージェントや通常の対話で十分です。選択肢が増えたからといって、すべてを Dynamic Workflow で回すのは（後述するトークン消費の観点からも）得策ではありません。

発展機能：待機時間を自分で決める ScheduleWakeup と /loop dynamic mode

Dynamic Workflow は単発の機能というより、「Claude が動的に段取りを判断する」という方向性の一部として捉えると理解が深まります。その広がりを示すのが、ScheduleWakeup と /loop の dynamic mode です。判断軸を押さえたうえで、発展的な関連機能として軽く触れておきます。

dynamic mode の挙動——AI が待機時間を決める

/loop コマンドは、タスクを繰り返し実行する仕組みです。/loop 5m のように間隔を指定すると 5 分ごとに固定実行されますが、間隔を省略して /loop だけにすると dynamic modeになります。

dynamic mode では、Claude が ScheduleWakeup を呼び出して次回の待機時間（1 分〜1 時間）を自分で決めます。「今は変化が激しいから 1 分後に」「落ち着いているから 30 分後に」といったように、観察結果に応じて間隔を動的に調整するわけです。固定間隔の /loop 5m との決定的な違いは、この「待機時間を AI が判断する」点にあります。タスクが完了したと自分で判断すれば、次回を予約せずにループを終了することもできます（公式ドキュメント）。

使う前に知っておきたい注意点

便利な反面、いくつか落とし穴もあります。

• 重複コストに注意: スラッシュコマンドが再実行されることで、意図せずコストが重複して発生するケースが報告されています
• 外部からのキャンセル手段が限られる: 走り出したループを外部から止める手段が乏しいため、開始前にスコープを絞っておくのが安全です
• 7 日で自動失効: スケジュールは 7 日経つと自動的に失効します。永続的なジョブのつもりで放置すると止まっていることがあります
• 一部環境では利用不可: ScheduleWakeup は Amazon Bedrock / Google Cloud Vertex AI / Microsoft Foundry では利用できません（これらの環境でも Dynamic Workflow 自体は使えますが、この待機予約機能のみ制限されます）

使う前に知っておきたい制約と注意点

最後に、research preview ゆえの「ハマりどころ」をまとめます。これを先に知っておくと、最初の一歩でトークンを浪費したり、想定外の制約に詰まったりせずに済みます。

機能面の制約

公式ドキュメントが明示している制約は次のとおりです。

• ミッドラン（実行中）のユーザー入力は不可: 走り出したワークフローに途中で口を挟むことはできません（エージェントの権限プロンプトだけは実行を一時停止できます）。段階ごとに人間の承認を挟みたいなら、各段を別々のワークフローに分けるのが公式の推奨です
• スクリプト自体からのファイル・シェルアクセスは不可: ファイルの読み書きやコマンド実行を行うのはエージェントであり、スクリプトはあくまで調整役（オーケストレーター）です。スクリプトに直接 fs 操作などを書かせることはできません
• 同時実行は最大 16 エージェント: CPU コアが少ないマシンではさらに少なくなります（ローカルリソースの保護のため）
• 総数は 1 実行あたり最大 1,000 エージェント: 暴走ループを防ぐための上限です

コストと環境の注意点

• トークン消費が通常セッションより大幅に多い: 1 回の実行で多数のエージェントを生成するため、同じタスクを対話でこなすより遥かに多くのトークンを消費します。プランの使用量・レート制限にも通常のセッションと同様にカウントされます
• まずは狭いスコープで試す: 公式が強く推奨しているのがこれです。いきなりリポジトリ全体ではなく 1 ディレクトリだけ、広い問いではなく狭い問いから始めて、/workflows ビューでトークン消費を見ながら規模感を掴むのが安全です。途中で止めても完了済みの作業は失われません
• モデルコストの制御: ワークフロー内の各エージェントはセッションのモデルを使います。大きな実行の前に /model を確認し、軽い作業用に小さいモデルへ切り替えている場合は注意してください。段によっては「弱いモデルでよい」と指定してコストを抑えることもできます
• 無効化する方法: research preview ゆえの不安定さが気になる場合や組織として止めたい場合は、/config の「Dynamic workflows」をオフにする、~/.claude/settings.json に "disableWorkflows": true を設定する、環境変数 CLAUDE_CODE_DISABLE_WORKFLOWS=1 を設定する、のいずれかで無効化できます

まとめ

Claude Code の Dynamic Workflow は、計画（オーケストレーション）をコードに移すことで、コンテキストウィンドウへの中間結果の蓄積から解放され、再現性・中断耐性・品質担保を獲得した手法です。Claude が JavaScript のスクリプトを自動生成し、ランタイムが数十〜数百のサブエージェントをバックグラウンドで並列実行します。中間結果はスクリプト変数に留まり、Claude のコンテキストには最終結果だけが届く——この設計が、サブエージェントとの本質的な違いを生んでいます。

使い分けの結論はシンプルです。

• 少数の並行委任で済むなら、サブエージェントや通常の対話で十分
• 規模（数十〜数百エージェント）・再現性（オーケストレーションの再利用）・品質担保（敵対的レビューや収束ループ）のいずれかが本気で必要になったら、Dynamic Workflow

そして、Dynamic Workflow はまだ research preview の段階です。トークン消費も通常セッションより大幅に多いため、最初はリポジトリ全体ではなく 1 ディレクトリ、広い問いではなく狭い問いから——狭いスコープで試して規模感を掴むところから始めるのが、失敗しないための堅実な一歩です。自分のタスクがどの土俵にあるかを見極めたうえで、適した道具を選んでください。