2026年5月28日、AnthropicはClaude CodeにDynamic Workflows（動的ワークフロー）を研究プレビューとして追加した。同日には新モデルClaude Opus 4.8と、Fast Modeの大幅値下げも発表されている。
Dynamic Workflowsの核心は「計画をコードに移す」という発想だ。これまでサブエージェントやスキルでは、Claudeがターンごとに次の一手を判断し、すべての中間結果がClaudeのコンテキストに積み上がっていた。Dynamic Workflowsは、ループ・分岐・中間結果の保持をClaudeが書いたJavaScriptスクリプトに任せる。
その結果、数個ではなく数十から数百のサブエージェントを1回の実行で並列オーケストレーションできる。実際にBunの開発者Jarred Sumnerは、この仕組みでBunをZigからRustへ移植し、11日間で75万行・テストスイート99.8%通過を達成した。
Claude Code全体のアーキテクチャと本番運用の全体像は Claude Code完全ガイド2026：インストールから本番運用まで を参照されたい。
- ・Dynamic WorkflowsはClaudeが書くJavaScriptスクリプトでサブエージェントを大規模オーケストレーションする仕組み。計画をコードに移すのが本質。
- ・同時16並列・1回あたり合計1,000エージェントが上限。実行はバックグラウンドで進み、セッションは応答可能なまま。
- ・敵対的レビュー（互いの結論を反証し合い収束させる）で、単発実行より信頼できる結果を得る。
- ・起動方法は3つ。プロンプトに
workflowと書く・/effort ultracode・組み込みの/deep-research。 - ・同時発表のClaude Opus 4.8はFast Modeが従来比3分の1の価格に。
1. Dynamic Workflowsとは何か——「計画をコードに移す」発想
Dynamic Workflowsは、サブエージェントを大規模に束ねるJavaScriptスクリプトだ。あなたが記述したタスクに対してClaudeがそのスクリプトを書き、専用のランタイムがバックグラウンドで実行する。スクリプトが走っている間も、あなたのセッションは応答可能なまま保たれる。
公式ドキュメントは、ワークフローを使うべき場面を明確に挙げている。1つの会話では調整しきれないほど多くのエージェントが必要なとき、あるいはオーケストレーション自体を「読めて再実行できるスクリプト」として残したいときだ。
具体例としては、コードベース全体のバグ掃討、500ファイル規模のマイグレーション、複数のソースを相互検証する必要があるリサーチ、コミット前に複数の独立した角度から下書きしたい難しい設計判断などが挙げられている。いずれも共通するのは、1つの会話のコンテキストに収まりきらない量の探索・検証を伴う点だ。
従来のサブエージェントでこうしたタスクに挑むと、すべての中間結果がオーケストレーターであるClaudeのコンテキストに積み上がり、やがてコンテキストが飽和して判断の質が落ちる。Dynamic Workflowsはこの「コンテキストの天井」を、計画と中間結果をスクリプト側へ追い出すことで突破する。Claudeに戻ってくるのは収束した最終回答だけなので、数百エージェント分の探索を行ってもコンテキストはクリーンに保たれる。
ツール・スキル・サブエージェントの使い分けは、Anthropicのワークショップ実録 ツール・スキル・サブエージェント——肥大化したエージェントを解剖するAnthropicワークショップ実録 で実例とともに解説している。Dynamic Workflowsはこの「サブエージェント」を大規模に束ねる上位レイヤーにあたる。
ポイントは、ワークフローが「単にエージェントを増やす」だけの機能ではないことだ。計画をコードに移すことで、繰り返し適用できる品質パターンを組み込める。たとえば独立したエージェントに互いの結論を敵対的にレビューさせてから報告させたり、1つの計画を複数の角度から下書きして互いに重み付けしたりできる。これが単発実行より信頼できる結果につながる。
研究プレビューであるため、利用には次の条件がある。
Proプランでは/configの「Dynamic workflows」行から有効化する。組織管理者はマネージド設定でワークフローを無効化できる。
2. サブエージェント・スキル・ワークフローの使い分け
Dynamic Workflowsを理解する最短ルートは、サブエージェント・スキルとの違いを「誰が計画を持つか」で整理することだ。3者はいずれも複数ステップのタスクを実行できるが、計画の所在が決定的に異なる。
| 観点 | サブエージェント | スキル | ワークフロー |
|---|---|---|---|
| 正体 | Claudeが起動するワーカー | Claudeが従う手順書 | ランタイムが実行するスクリプト |
| 次に何を走らせるか決めるのは | Claude（ターンごと） | Claude（プロンプトに従う） | スクリプト |
| 中間結果の置き場所 | Claudeのコンテキスト | Claudeのコンテキスト | スクリプト変数 |
| 再利用できるもの | ワーカー定義 | 手順書 | オーケストレーション自体 |
| スケール | 1ターンに数個 | サブエージェントと同等 | 1実行に数十〜数百 |
| 中断時 | ターンをやり直す | ターンをやり直す | 同一セッション内で再開可能 |
サブエージェントとスキルでは、Claude自身がオーケストレーターだ。ターンごとに次に何を起動するか判断し、すべての結果がClaudeのコンテキストに着地する。一方ワークフローでは、ループ・分岐・中間結果をスクリプトが保持するため、Claudeのコンテキストには最終回答だけが残る。
1ターンに数個のサブエージェントで足りる、結果を会話の中で見たい——そんなときはサブエージェントやスキルで十分だ。1つの会話では調整しきれないほどエージェントが必要、あるいはオーケストレーション自体を再実行可能なスクリプトとして残したい——そのときに初めてワークフローへ移行する。
つまり「とにかくワークフロー」ではなく、コンテキストを汚さず大規模に並列したい・手順そのものを資産化したいという要件が立ったときの選択肢だ。サブエージェントが「ワーカーというプリミティブ」、ワークフローが「それを束ねるオーケストレーション」という階層関係になっている。
3. ワークフローの実行モデルと並列上限（最大1,000エージェント）
ワークフローのランタイムは、あなたの会話とは分離された隔離環境でスクリプトを実行する。中間結果はClaudeのコンテキストに着地せず、スクリプト変数に留まる。ランタイムは各エージェントの結果を実行の進行に合わせて追跡し、この追跡が同一セッション内での再開（resume）を可能にしている。
実行フローを図にすると次のようになる。
(あなたの入力)"] --> B["Claudeがスクリプトを生成"] B --> C{"実行を承認？"} C -->|"No"| X["キャンセル"] C -->|"Yes"| D["ランタイムが隔離環境で実行"] D --> E["フェーズ1: 並列サブエージェント
最大16同時"] E --> F["フェーズ2: 敵対的レビュー
互いの結論を反証"] F --> G{"収束した？"} G -->|"No"| E G -->|"Yes"| H["最終回答のみ
Claudeのコンテキストへ"] D -.->|"中断時"| I["完了済みはキャッシュ
残りをresume"] I -.-> D
ランタイムには明確な制約がある。これは安全とリソース保護のための設計だ。
| 制約 | 内容 | 理由 |
|---|---|---|
| 実行中のユーザー入力 | 不可（エージェントの権限プロンプトのみ一時停止できる） | 段階間の承認が要るならステージごとに別ワークフローにする |
| スクリプトからのファイル/シェルアクセス | 不可 | 読み書き・コマンド実行はエージェントが行う。スクリプトは調整役に徹する |
| 同時実行エージェント数 | 最大16（CPUコアが少ないと減る） | ローカルリソースの使用量を抑える |
| 1実行あたりの合計エージェント数 | 1,000 | 暴走ループを防ぐ |
実行はバックグラウンドで進む。/workflowsを実行すれば、走行中・完了済みのワークフロー一覧が表示され、選択すると進捗ビューが開く。各フェーズのエージェント数・トークン総量・経過時間が表示され、フェーズを掘り下げれば個々のエージェントが何を見つけたかまで確認できる。
/workflows
進捗ビューではpで一時停止/再開、xでエージェントやワークフロー全体の停止、rで実行中エージェントの再起動、sでそのスクリプトをコマンドとして保存できる。
再開（resume）の挙動はシンプルだ。実行を停止して再開すると、すでに完了したエージェントはキャッシュ済みの結果を返し、残りがライブで走る。/workflowsから対象を選びpを押すか、同じスクリプトでワークフローを再起動するようClaudeに頼めばよい。ただし再開は同一セッション内に限られる。ワークフロー走行中にClaude Codeを終了すると、次のセッションではワークフローは最初から実行される点に注意したい。
コスト面では、ワークフローが多数のエージェントを起動するため、1回の実行が同じタスクを会話で進める場合よりも明確に多くのトークンを消費する。実行はプランの使用量・レート制限に通常のセッションと同様にカウントされる。ワークフロー内の各エージェントは、スクリプトが特定のステージを別モデルにルーティングしない限り、セッションのモデルを使う。大きな実行の前には/modelを確認し、最強のモデルが不要なステージには小さいモデルを使うようタスク記述の段階でClaudeに伝えておくとコストを抑えられる。
4. 3つの起動方法——workflowキーワード・ultracode・/deep-research
ワークフローの起動方法は3つある。手軽さと自動化の度合いが異なる。
(1) プロンプトにworkflowと書く。 セッションのeffortレベルを変えずに、単発のタスクをワークフローとして走らせたいときの最短手だ。プロンプトのどこかにworkflowという語を入れると、Claude Codeがその語をハイライトし、ターンごとに処理する代わりにワークフロースクリプトを書く。
Run a workflow to audit every API endpoint under src/routes/ for missing auth checks
意図せずハイライトされた場合はalt+wでそのプロンプトに限り無視できる。
(2) /effort ultracodeでClaudeに任せる。 ultracodeはxhighの推論effortと自動ワークフローオーケストレーションを組み合わせた設定だ。オンにすると、Claudeはあなたが頼まなくても実質的なタスクごとにワークフローを計画する。
/effort ultracode
1つのリクエストが複数のワークフローに分かれることもある——コードを理解するもの、変更を加えるもの、検証するもの、といった具合だ。セッション中だけ有効で、新しいセッションを始めるとリセットされる。日常的な作業に戻るときは/effort highで下げる。effortレベルそのものの考え方は Claudeの思考レバー：effortレベル完全ガイド で整理している。
(3) 組み込みの/deep-researchを使う。 ワークフローを最も手早く体験できるのが、Claude Codeに同梱された組み込みワークフロー/deep-researchだ。複数の角度からWeb検索をファンアウトし、見つけたソースを取得して相互検証し、引用付きのレポートを返す。
/deep-research What changed in the Node.js permission model between v20 and v22?
実行を許可すると、バックグラウンドでエージェント群がフェーズを進める間もセッションは自由に使える。相互検証を生き残らなかった主張はあらかじめフィルタされ、各主張に出典が付いた1本のレポートが最後に届く。
/workflowsで実行を選びsを押すと、そのスクリプトをコマンドとして保存できる。保存先は.claude/workflows/（リポジトリ共有）か~/.claude/workflows/（自分専用・全プロジェクトで利用可）。以後/<name>で同じオーケストレーションを再実行でき、ブランチごとに走らせるレビューなどを資産化できる。
ワークフロー全体を無効化したい場合は、/configでトグルをオフにするか、設定ファイルに記述する。
{
"disableWorkflows": true
}
環境変数CLAUDE_CODE_DISABLE_WORKFLOWS=1でも無効化でき、組織全体ではマネージド設定でdisableWorkflowsを有効にする。無効化すると組み込みワークフローコマンドが使えなくなり、workflowキーワードもトリガーされず、/effortメニューからultracodeが消える。
5. 敵対的レビューと収束——なぜ単発実行より信頼できるか
Dynamic Workflowsの品質を支えるのが敵対的レビュー（adversarial review）だ。Claudeはあなたのプロンプトから計画を動的に立て、サブタスクに分解する。サブエージェントが並列に走り、独立した角度から問題に取り組む。
ここからが核心だ。別のエージェント群が、それらの結論を反証しようと試みる。実行は答えが収束するまで反復される。単一パスの実行では到達できない結果を、この反復が可能にする。
この仕組みは権限モデルにも一貫している。あなたのセッションの権限モードが何であれ、ワークフローが起動するサブエージェントは常にacceptEditsモードで走り、あなたのツール許可リストを継承する。ファイル編集は自動承認される。
許可リストにないシェルコマンド・Webフェッチ・MCPツールは、実行の途中であなたにプロンプトを出すことがある。長い実行で中断されたくなければ、エージェントが必要とするコマンドを開始前に許可リストへ追加しておくのが安全だ。
claude -pやAgent SDKでは確認する相手がいないため、設定済みの権限ルールに従い対話的確認なしで進む。承認フローは権限モードによって変わる。整理すると次の通りだ。
| 権限モード | プロンプトが出るタイミング |
|---|---|
| デフォルト / accept edits | 毎回（そのワークフローについて「今後聞かない」を選んでいれば除く） |
| auto | 初回のみ。「Yes」がユーザー設定に同意を記録し以後は無確認。ultracode時は完全にスキップ |
bypass permissions / claude -p / Agent SDK |
出ない。実行は即座に開始 |
CLIの承認プロンプトでは計画されたフェーズが表示され、「View raw script」で実行前にスクリプトを読める。Ctrl+Gでエディタにスクリプトを開き、Tabで開始前にプロンプトを調整することもできる。Desktopアプリでは、ワークフロー名・フェーズリスト・トークン使用量の注意書きを載せた承認カードが表示され、「Once」「Always」「Deny」で操作する。進捗ビューはBackground tasksサイドペインに現れる。
重要なのは、あなたの権限モードが制御するのは「起動プロンプト」だけだという点だ。ワークフローが生成するサブエージェントは、セッションのモードに関わらず常にacceptEditsモードで走る。この設計のおかげで、数百エージェントの実行が途中でファイル編集の確認待ちに陥らずに済む。
つまりワークフローは「ブラックボックスで大量のエージェントが走る」のではなく、実行前にスクリプトを読み、承認し、必要なら編集できる設計になっている。計画がコードとして可視化されていることの実利がここに表れる。
6. Bunの実例——11日で75万行のRust移植 + Claude Opus 4.8 / Fast Mode
Dynamic Workflowsの実力を示す最も象徴的な事例が、Bunの開発者Jarred Sumnerによる移植プロジェクトだ。彼はDynamic Workflowsを使ってBunをZigからRustへ移植した。
その内訳が興味深い。あるワークフローはRustのライフタイムをマッピングし、別のワークフローは並列で.rsファイルを生成した。各ファイルには2人のレビュアーが付き、フィックスループがクリーンビルドに至るまで継続的にテストを回した。数百のエージェントが2人ずつのレビュアーとともに並列稼働した格好だ。
ただし注意点として、この結果はまだ本番環境には投入されていない。研究プレビューでの実証という位置づけである。
この事例は、第5章で述べた敵対的レビューと収束の仕組みが、現実の大規模移植でどう機能するかを示している。「並列に生成し、複数のレビュアーで検証し、テストが通るまで収束させる」——このパターンを1,000エージェントの予算内でスクリプト化したものがBun移植だった。
注目すべきは、移植が単一の巨大なワークフローではなく、役割の異なる複数のワークフローの連携で進んだ点だ。ライフタイムのマッピング、ファイル生成、フィックスループはそれぞれ独立したオーケストレーションとして設計されている。これは「段階間で人間の承認が要るならステージごとに別ワークフローにする」という公式の推奨とも整合する。実行中はユーザー入力を受け付けない制約があるため、人間が介在するチェックポイントは自然とワークフローの境界に置かれることになる。
裏を返せば、Dynamic Workflowsを使いこなす鍵は「1つのタスクをどう複数のワークフローに切り分けるか」という設計判断にある。理解フェーズ・変更フェーズ・検証フェーズを分け、それぞれの出力を次の入力にする——この分割は、ultracodeがClaudeに自動で行わせる分割（理解→変更→検証）とも本質的に同じ構造だ。
同時発表：Claude Opus 4.8とFast Modeの値下げ
Dynamic Workflowsと同じ2026年5月28日、AnthropicはClaude Opus 4.8を公開した。Dynamic Workflowsとともに研究プレビューとして提供される。
最も実務に効くのはFast Modeの値下げだ。Fast Modeは別モデルではなく、Claude Opusの高速構成で、出力トークン速度を2.5倍にしつつ品質は同一を謳う。/fastコマンドでトグルでき、↯アイコンで示される。
| 項目 | Opus 4.7 / 4.6 | Opus 4.8 |
|---|---|---|
| Fast Mode価格 | 基準 | 従来比 約3分の1 |
| Fast Modeの性質 | Opusの高速構成（別モデルではない） | 同左 |
| 出力速度 | 2.5倍（Fast Mode時） | 2.5倍（Fast Mode時） |
| 提供形態 | 一般提供 | 研究プレビュー |
Dynamic WorkflowsもFast Modeも、典型的なセッションより「はるかに多くのトークンを消費しうる」と公式が明言している。1回の実行で最大1,000エージェントが起動するため、コストは急速に膨らみうる。大きな実行の前には
/modelを確認し、強いモデルが不要なステージには小さいモデルを使うようClaudeに依頼するとよい。実行は/workflowsからいつでも停止でき、完了済みの作業は失われない。Opus 4.8でFast Modeが3分の1の価格になったことは、Dynamic Workflowsの大量エージェント実行と相性が良い。数百エージェントを並列に走らせるコストモデルにおいて、出力速度2.5倍かつ低価格の構成は、ワークフローの実用性を一段引き上げる組み合わせと言える。
まとめ
- ・Dynamic Workflowsは「計画をコードに移す」仕組み。ループ・分岐・中間結果をClaudeが書くJavaScriptスクリプトが保持し、Claudeのコンテキストには最終回答だけが残る。
- ・サブエージェント（数個・コンテキストに結果が戻る）に対し、ワークフローは数十〜数百のエージェントを束ね、オーケストレーション自体を再利用可能なスクリプトとして資産化する。
- ・同時16並列・1実行あたり合計1,000エージェントが上限。実行はバックグラウンドで進み、同一セッション内ならresume可能。
- ・敵対的レビューで結論を反証し合い収束させることで、単発実行より信頼できる結果を得る。Bun移植は11日で75万行・テスト99.8%通過を実証した。
- ・起動は
workflowキーワード・/effort ultracode・/deep-researchの3通り。v2.1.154以降が必要。 - ・同時発表のClaude Opus 4.8はFast Mode価格が従来比3分の1。大量エージェント実行のコストモデルと噛み合う。
Dynamic Workflowsは、サブエージェントという既存のプリミティブを「読めて再実行できるオーケストレーション」へと引き上げる研究プレビューだ。まずは/deep-researchで挙動を体感し、繰り返すタスクが見つかったらスクリプトを保存してコマンド化する——この順序が実務への入り口になる。コストが急増しうる点だけは常に意識し、/workflowsから実行を監視・制御する習慣をつけておきたい。
