こんにちは、株式会社TIMEWELLの濱本です。
2026年5月28日、AnthropicがClaude Opus 4.8と同時に「Dynamic Workflows（ダイナミック・ワークフロー）」を公開しました。当初はリサーチプレビューでの提供でしたが、今では公式ブログ「Introducing dynamic workflows in Claude Code」もドキュメントも、はっきり「一般提供（generally available）」と書いています。ここが、この記事の一番の書き換えポイントです。「様子見していい新機能」から「有料プランなら誰でも使える標準機能」へと、位置づけが半年で変わりました。
この記事では、Anthropicの公式ブログとClaude Code公式ドキュメントを一次情報として、一般提供になったDynamic Workflowsを実務でどう使うかを整理します。起動キーワードが workflow から ultracode に変わったこと、agent() や pipeline() といったスクリプトの実体、コストとガバナンスの新しい統制手段、そしてどの入力経路ならワークフローが起動するのかというセキュリティの論点まで。Claudeを業務に組み込んでいる経営層、DX推進担当者、エンジニアリングマネージャーが、社内の意思決定会議にそのまま持ち込める密度を目指します。
なお、ベンチマークの具体スコアなど、現時点で一次情報の本文だけでは裏取りしきれない数値は本稿では断定していません。確認できた範囲に留め、未確認のものは未確認と明記します。
Dynamic Workflowsとは何か、そして一般提供までの経緯
まず定義を一次情報でそのまま押さえます。Anthropicの公式ドキュメントは、Dynamic Workflowsをこう説明しています。サブエージェントを大規模に協調動作させるためのJavaScriptスクリプトであり、ユーザーが説明したタスクに対してClaudeがそのスクリプトを書き、ランタイムがバックグラウンドで実行する。その間もユーザーのセッションは応答可能なまま、というものです。
用語を初心者向けに補っておきます。サブエージェントとは、Claudeが特定の仕事を任せるために生成する「分身」のことで、コンテキストや権限を分けて並列に動かせます。オーケストレーションは、複数のエージェントの実行順序や分岐や並列度を制御する作業を指します。ランタイムは、そのスクリプトを走らせる独立した実行環境です。会話とは別の場所で動くと考えてください。
半年前と今で何が変わったのか。ここを最初に表で押さえておきます。
| 項目 | 当時（2026年5月） | 現在（一般提供後） |
|---|---|---|
| ステータス | リサーチプレビュー | 一般提供（generally available） |
| 利用可能プラン | Pro、Max、Team、Enterprise（一部は管理者有効化） | すべての有料プランで利用可。Proは /config の「Dynamic workflows」をオン |
| 起動キーワード | workflow（リテラル） |
ultracode（workflowはv2.1.160より前の仕様） |
| 最低バージョン | Claude Code v2.1.154以降 | 同上。機能ごとに追加要件あり |
| プロバイダ表記 | Google Cloud Vertex AI | Google CloudのAgent Platform（ブログや料金ページにはVertex AI表記も残る） |
一般提供になったことで、導入の意思決定は「使うか、使わないか」から「どこから、どのリスクラインで使うか」へと移りました。リサーチプレビュー段階では「仕様が固まっていないから本番投入は保留」という判断にも一定の理があったのですが、その前提はもう外れています。
Claude Opus 4.8との関係
同日発表のClaude Opus 4.8は、大量のエージェントを走らせるDynamic Workflowsの性質を意識した価格設計になっています。標準料金は入力100万トークンあたり$5、出力$25で、Opus 4.7と同じ水準に据え置かれました。Fast Modeは$10／$50です。ここが大きい。Opus 4.7のFast Modeは$30／$150でしたから、実質3分の1の値段になりました。しかもそのOpus 4.7のFast Modeは2026年7月24日に廃止予定です。Fast Mode自体はまだリサーチプレビュー扱いで、Batch APIとは併用できず、Claude Platform on AWSでは使えないという制約が残っている点は覚えておいてください。
なお、エージェント的なコーディングタスクでの性能改善はアナウンスされていますが、SWE-bench VerifiedなどのベンチマークスコアはSystem Cardに委ねられており、今回取得できた一次情報の本文には表示されていません。数値の断定は避けます。導入検討にあたって具体的なスコアが必要なら、Opus 4.8のSystem Cardを直接あたるのが確実です。
起動方法が変わった。ultracodeと/effort ultracode
旧版のこの記事で最も大きな技術的な誤りは、起動キーワードの説明でした。以前は「プロンプトに workflow という単語を含める」「Claude Codeは workflow という単語をハイライトする」と書いていましたが、これは古い仕様です。公式ドキュメントは「v2.1.160より前は起動キーワードが workflow だった」と明記しており、現在の明示的なキーワードは ultracode です。
使い方は素直です。プロンプトのどこかに ultracode を含めると、単発のタスクがワークフローとして編成されます。もちろん、「use a workflow」「run a workflow」のような自然文での依頼も引き続き有効です。リテラルなキーワードを覚えていなくても、やりたいことを普通に書けば起動できるようになっています。
ultracode src/routes/ 配下のAPIエンドポイントを全数調査して、認証チェック漏れを洗い出して
もう一段上の使い方が /effort ultracode です。これはxhighの推論エフォートと自動ワークフロー編成を組み合わせる設定で、v2.1.203以降で利用できます。起動時に claude --effort ultracode として立ち上げるか、セッション内で /effort ultracode を指定します。オンにすると、Claudeが実質的にタスクごとに自動でワークフローを計画するようになります。1つのリクエストが「理解、変更、検証」の複数ワークフローに分岐しうる、というイメージです。この設定はセッション限定で、セッションを抜けるとリセットされます。
バンドル済みコマンドも健在です。/deep-research は複数の角度からWeb検索を並列に走らせ、ソースを相互照合して引用付きのレポートを返します。この検証挙動はv2.1.196で改善されており、レート制限やAPIエラーで検証エージェントが主張を確認できない場合、以前のように「反証された」とするのではなく「unverified（未検証）」として報告に列挙するようになりました。事実確認を任せる用途では、この違いは地味に効いてきます。
4つのプリミティブ。サブエージェント、Skills、Agent teams、ワークフロー
ここが多くの方が混乱する論点です。旧版では「サブエージェント、Skills、ワークフロー」の3つで比較していましたが、現行ドキュメントはここに Agent teams を加えた4つの整理に拡張されています。Agent teamsの説明が旧版には一切なかったので、ここは丸ごと入れ替えます。
Agent teamsは、リードとなる1体のエージェントが、自分と同格のセッションを監督する仕組みです。共有のタスクリストを持ち、あなたが途中で割り込んで指示を変えても、チームメイトは走り続けます。対話しながら分業を進めたいときに向いています。これに対してDynamic Workflowsは、いったんスクリプトに落として一気に走らせる。この違いを踏まえて、4つを並べます。
| 観点 | サブエージェント | Skills | Agent teams | ワークフロー |
|---|---|---|---|---|
| 実体 | Claudeが起動するワーカー | Claudeが従う指示書 | リードが監督する同格セッション群 | ランタイムが実行するスクリプト |
| 次の一手を決めるのは | Claude（ターンごと） | Claude（プロンプトに従う） | リードとチームメイト | スクリプト |
| 中間結果の保存先 | Claudeのコンテキスト | Claudeのコンテキスト | 共有タスクリスト | スクリプト変数 |
| 中断時の挙動 | ターンが最初から | ターンが最初から | チームメイトは走り続ける | 同セッション内で再開可能 |
| 向くスケール | ターンあたり数個 | サブエージェント同等 | 対話しながらの並行作業 | ランあたり数十から数百 |
公式ドキュメントの核心は「プランがコードに移る」という一文です。サブエージェントやSkillsでは、Claudeが対話のターンごとに次に何を生成するかを決め、すべての結果がコンテキストに積まれます。コンテキスト窓には上限があるので、エージェントが10個を超えると会話履歴が膨らみ、後半で前半の結果を見失いはじめる。Dynamic Workflowsは、この設計上のボトルネックをスクリプト変数で回避します。中間結果は変数として保持され、会話コンテキストには最終回答だけが返る。だから数百のエージェントを走らせても会話側はクリーンなままです。
Agent SDK・Managed Agentsとの棲み分け
似た名前の仕組みがもう2つあるので、別表でも整理します。
| 種別 | 主体 | 課金 | 典型ユースケース |
|---|---|---|---|
| Tool Use（Messages API） | 開発者がループを書く | トークン課金 | カスタムツール呼び出しの基本形 |
| Agent SDK | SDKがエージェントループを抽象化 | トークン課金 | Claude Code相当を自社アプリに組み込む |
| Managed Agents | Anthropicがランタイムを管理 | トークン＋稼働時間$0.08／session-hour | 数時間以上の本番運用エージェント |
| Dynamic Workflows | Claudeが書いたスクリプトをランタイムが実行 | 通常のトークン課金 | 1ラン内で数十から数百エージェントの協調 |
Managed Agentsは、トークンに加えてセッション稼働時間で課金される独立したレイヤーで、こちらは今も提供が続いています。長時間動かし続けたいならManaged Agents、複雑な1ショットのタスクを一気に片づけたいならDynamic Workflows、という棲み分けです。ひとつ運用上の注意点があります。Dynamic Workflowsのランには、BatchやFast Mode、データレジデンシーといった通常のAPIモディファイアが効きません。コスト最適化のつもりでBatchを当てにしていると当てが外れるので、後述のコスト統制はワークフロー固有の手段で組み立てる必要があります。
AI駆動開発を、実務で使えるところまで
トレンドを追うだけで終わらせないための実践プログラムがWARPです。元大手DX・データ戦略の専門家が、現場で動かすところまで伴走します。
動作原理とスクリプトの実体
旧版が手薄だったのが、スクリプトそのものの中身です。開発者は概念ではなく具体的なコードを見たいはずなので、ここを厚くします。
Dynamic Workflowsのスクリプトは、トップレベルawaitが使える素のJavaScriptです。中心になる関数は2つ。agent() は1つのサブエージェントを起動します。pipeline() はリストの各要素に対して1つずつエージェントを実行します。そして export const meta にname（名前）とdescription（説明）を書いておきます。概念を伝えるための簡略コードを載せます。
export const meta = {
name: "auth-audit",
description: "src/routes 配下の認証チェック漏れを監査する",
};
// トップレベル await がそのまま書ける素の JavaScript
const paths = await agent("src/routes 配下のエンドポイント一覧を出す");
// リストの各要素に 1 エージェントを割り当てて並列実行
const findings = await pipeline(paths, (path) =>
agent(`${path} の認証チェック漏れを検証する`)
);
// 結果はスクリプト変数に溜まる。会話に返すのは最終レポートだけ
const report = await agent(
`次の検証結果を統合してレポートにする: ${JSON.stringify(findings)}`
);
面白いのは、このスクリプトがランごとにファイルとして書き出される点です。出力先は ~/.claude/projects/ のセッションディレクトリ配下で、そのパスがClaudeに渡されます。だからあなたは、Claudeが書いたオーケストレーションを読んで、差分を確認して、必要なら手で直してから再起動できます。ブラックボックスではなく、レビュー可能な成果物としてスクリプトが手元に残る。この設計は、ガバナンスを気にするエンタープライズにとってかなり重要な性質だと感じています。
制限値と再開の正確な仕様
制限値は据え置きが確認できています。同時に走らせられるのは最大16エージェントで、CPUコア数の少ないマシンではさらに絞られます。1ランあたりの合計は最大1,000エージェント。これは暴走ループを止めるための上限で、日常的な用途は数十から数百に収まります。
再開（resume）の仕様は、正確に理解しておく価値があります。完了済みのエージェントはキャッシュ結果を返し、未完了の分だけが実際に走り直します。ただし落とし穴があって、停止した瞬間に実行途中だったエージェントは保存されず、やり直しになります。だから、1体に重い仕事を丸ごと持たせるより、小さなエージェントに分散させておいたほうが、中断しても進捗が残りやすい。もうひとつ、再開できるのは同一セッション内だけです。Claude Codeを終了すると、次回起動時はゼロからのスタートになります。
コストとガバナンスの新装備
一般提供にあたって、コスト統制の手段が具体的に増えました。旧版では「トークン予算管理」「ネスト実行」といった抽象的な書き方をしていましたが、現行ドキュメントには実際の機能名で書かれています。ここを正しい名前に置き換えます。
1つ目が、/config の「Dynamic workflow size」設定です（v2.1.202以降）。既定はunrestricted（無制限）ですが、small（5エージェント未満）、medium（15未満）、large（50未満）を選ぶと、Claudeに規模のおおよその目安を助言できます。強制ではなく助言です。2つ目が「Large workflow」警告（v2.1.203以降）。スケジュールされたエージェントが25体を超える、あるいは予測トークン総量が150万を超えると警告が表示されます。これも助言のみで、実行を止めはしません。暴走する前に人間が気づけるようにする、というブレーキです。
コストそのものの割引手段も整理しておきます。プロンプトキャッシュの読み取りは標準入力の0.1倍で、最大90％の削減になります。共通のシステムプロンプトを使い回すワークフローほど効きます。Batch APIは入出力とも50％削減で、Opus 4.8ならバッチ料金は$2.50／$12.50です。ただし先に触れたとおり、Batchはワークフローのランには効かないので、これは通常のAPI呼び出し側での話として使い分けてください。
見落とされがちな新事実がひとつあります。Opus 4.7以降のOpus、そしてFable 5、Mythos 5、Sonnet 5は新しいトークナイザを採用しており、同じテキストでも約30％多くトークンを生成します。大量のエージェントを走らせるコスト試算では、この30％増を最初から織り込んでおかないと、見積もりが甘くなります。モデル階層と料金を一覧にしておきます。
| モデル | 標準料金（入力／出力・100万トークン） | 備考 |
|---|---|---|
| Claude Fable 5 | $10／$50 | 一般提供の最上位級。1Mコンテキストを標準料金に含む |
| Claude Mythos 5 | 限定提供 | Project Glasswing限定 |
| Claude Opus 4.8／4.7／4.6／4.5 | $5／$25 | 4.7以降は1Mコンテキストを標準料金に含む |
| Claude Sonnet 5 | 導入価格$2／$10（2026-08-31まで、以後$3／$15） | 1Mコンテキストを標準料金に含む |
| Claude Haiku 4.5 | $1／$5 | 検証や要約など軽い処理の受け皿に |
ワークフローの中で「重い計画はOpus 4.8、軽い検証や要約はHaiku 4.5」と段階分けする運用は、今も有効な定石です。
保存と再利用、そしてargs
気に入ったランは資産にできます。/workflows の画面で s キーを押すと、そのランのスクリプトをコマンドとして保存できます（保存パスの表示はv2.1.208以降）。保存先は2か所。リポジトリで共有したいなら .claude/workflows/、自分だけで使うなら ~/.claude/workflows/ です。保存後は /<名前> で何度でも同じオーケストレーションを呼び出せます。
再利用がさらに実用的になったのが args です。保存したワークフローは、実行時に構造化された入力を受け取れます。Issue番号のリスト、対象パス、設定オブジェクトなどをargsとして渡し、スクリプト内ではグローバルな args として参照します。つまり「毎回ちょっとだけ引数が違う定型作業」を、ひとつのワークフローで回せるようになりました。社内の点検作業やレポート生成をライブラリ化していく上で、ここは効いてきます。
組織レベルの無効化
エンタープライズ管理者がDynamic Workflowsを丸ごと止めたい場合の選択肢も、公式に明記されています。/config のトグルをオフにする、settings.json に "disableWorkflows": true を入れる、環境変数 CLAUDE_CODE_DISABLE_WORKFLOWS=1 を設定する、の3つが個別手段です。組織全体に効かせたいなら、Managed Settings側に同じフラグを入れるか、Adminの設定ページから切ります。情シスにとっては、集中管理の口が用意されている点が安心材料になるはずです。
セキュリティ。どの入力がワークフローを起動するのか
旧版の記述で、今となっては危ういのがヘッドレスとAgent SDKまわりの説明でした。以前は「claude -p とAgent SDK経由でもワークフローを実行できる」と書いていましたが、v2.1.210以降、ここは大きく変わっています。
現在、起動キーワードによるワークフロー化は「人間が自分でタイプした入力」限定のオプトインになりました。具体的には、-p で渡したプロンプト、humanスタンプのないAgent SDK送信、スケジュールタスク、WebhookやPRコメント経由の入力では、ワークフローが起動しなくなっています。これはセキュリティ強化が目的です。外部から流れ込んだ指示が、勝手に数百のエージェントを起動して環境を書き換える、という事故を防ぐための設計だと読めます。
自動化やCI／CDでワークフローを回すことを検討していた方は、この前提で組み直す必要があります。「キーワードを含めれば自動で走る」わけではなくなったので、パイプラインに組み込むなら、起動条件を満たす入力経路を明示的に設計し直してください。旧版のCI／CD自動実行を前提にした説明は、この点で誤りになっています。
もうひとつ、ワークフローが起動するサブエージェントは基本的に自動編集モードで動く点も要注意です。プロダクションのリポジトリに直接走らせるなら、ツール許可リストの整備と専用ブランチでの実行が前提になります。事前の許可設計を怠ると、想定外の編集が走るか、逆に都度プロンプトが出てバックグラウンド実行のメリットが消えるかの二択になります。
エンタープライズ導入の論点。GA後の運用統制へ
ここからは、公式情報を前提に、国内の経営層やDX推進担当者が議論すべき論点を4軸で整理します。旧版では4つ目を「リサーチプレビューであることのリスク」としていましたが、一般提供になった今、論点は「様子見のリスク管理」から「本番運用の統制設計」へと移りました。
セキュリティとガバナンス。サブエージェントが自動編集モードで動く前提を、まず社内標準に落とし込むこと。専用ブランチでの実行、ツール許可リストのホワイトリスト管理、そして先に述べた入力経路の限定（人間のタイプ入力のみ起動）を、運用ルールとして明文化します。組織レベルのオンオフはManaged SettingsとAdminダッシュボードで集中管理できるので、まずは限定した部署で有効化し、統制が整ってから広げる進め方が現実的です。
データ主権。Anthropic API直接利用は原則として米国リージョン経由です。Google CloudのAgent Platform（旧称のVertex AI表記も残ります）やAmazon Bedrock、Microsoft Foundryでは国内リージョンを選べる場合があります。ただしモデルの可用性は個別確認が要ります。機密データを扱う業務にDynamic Workflowsを差し込むなら、どのエンドポイントを通すかがそのままデータ所在地の決定になります。経営会議では「どこを通すか」の決定権限が明確になっているかを確認してください。
運用負荷とコスト。公式ドキュメントが正直に書いているとおり、Dynamic Workflowsは通常のセッションよりかなり多くのトークンを消費する可能性があります。まずは限定したタスクから始めて感触を掴むのが安全です。ここに、先ほどのsize設定とLarge workflow警告、そして新トークナイザによる約30％増を組み合わせて、予算の初期前提を作ります。エージェント数が会話の何倍にもなる性質を考えると、最初の予算は通常運用の5倍から10倍を見ておくと外しにくい、というのが私の肌感覚です。
一般提供後の運用統制。リサーチプレビューが終わったことで、「仕様が変わるかもしれないから保留」という言い訳は使えなくなりました。とはいえ、いきなり業務クリティカルパスに載せるのも別のリスクです。ドキュメント生成、コードレビュー、競合調査といった補助業務でパイロットを回し、KPIを測りながら適用範囲を広げていく。この順序は一般提供後も変わりません。
資料ダウンロード：エンタープライズAI導入意思決定フレーム
Dynamic Workflowsを含む2026年のAIエージェント基盤を、自社で評価する際の意思決定フレーム（セキュリティ、コスト、運用負荷、データ主権の4軸）をまとめた資料を配布しています。
Anthropic公式が提示するユースケース
推測を避け、公式ブログとドキュメントに書かれている事例を並べます。代表格が、コードベース全体のバグ調査です。リポジトリを並列で探索し、見つかった発見ごとに独立した検証エージェントを走らせて、Issueとパッチ案を一括で出します。セキュリティ監査も同じ発想で、1人のレビュアーより複数の独立した視点でクロスチェックしたほうが確度が上がるという考え方です。プロファイリング駆動の最適化監査、そしてバンドル済みの /deep-research によるディープリサーチも公式のユースケースに含まれます。
大規模マイグレーションの実例として、公式ブログが挙げているのがBun（高速JavaScriptランタイム）のZigからRustへの移植です。開発者のJarred Sumner氏はDynamic Workflowsを使い、約75万行のRustコードを生成して、既存テストスイートの99.8％が通る状態にまで持っていきました。初コミットからマージまで11日です。特筆すべきは中身で、1つのワークフローが構造体フィールドをまたぐRustのライフタイムを処理し、後続のエージェントがファイル1つあたり2名のレビュアーを付けて、挙動が同一の移植を並列で実行したと公表されています。数千ファイルにまたがる作業を、レビューの網をかけながら1ラン内で完結させる。これがDynamic Workflowsの一番わかりやすい見せ場だと思います。
国内企業の選択肢。ZEROCKとDynamic Workflowsの組み合わせ
国内でClaudeを業務利用するとき、Dynamic Workflowsをそのまま米国のAnthropic APIに流すか、Bedrockや各社の国内リージョンを噛ませるか、社内データを扱う部分は別途国内基盤に逃がすか、という3択になります。
TIMEWELLが提供する ZEROCK は、3つ目を取りたい企業向けのエンタープライズAI基盤です。AWS国内サーバー上でGraphRAGによるナレッジコントロールを行い、プロンプトライブラリで業務横断の指示書を統制します。機密度の高い情報を国内に留めつつ、Dynamic Workflowsの並列処理能力をリサーチや大量文書処理に使い分ける、というハイブリッド構成が組めます。具体的には、社内ナレッジはZEROCK経由でGraphRAG検索、外部Webリサーチや大量コードベース監査はDynamic Workflowsで実行、といった役割分担です。あるいはワークフロー内で、機密データに触れるサブエージェントは国内基盤に、Web検索や一般的な検証はAnthropic API直接に振り分ける段階分けも考えられます。
最適解は業界と業務の機密度合いで変わります。国内基盤に寄せるのが一律で正解というわけではありません。まず補助業務で試し、ガバナンス整備が追いついた段階で本業務にも広げる、という段階的な移行が現実的です。
WARP NEXTでサポートする「Dynamic Workflows導入評価」
新機能を「自社で使うか」「使うならどの業務から」「ガバナンスをどう設計するか」を判断するのは、現場のエンジニアリングマネージャーや情シスだけでは荷が重い領域です。予算配分、業務プロセスの再設計、リスク評価まで含めた議論が要ります。
TIMEWELLの WARP NEXT は、元大手DX・データ戦略専門家が月次で伴走するAIコンサルティングサービスです。自社のどの業務が並列処理に向くかの仕分け、リスクアセスメントと社内承認プロセスの設計、パイロット業務の選定とKPI設計、ZEROCKやManaged Agents、各クラウド経由との組み合わせ、そして経営会議向けの意思決定資料への落とし込みまでをお手伝いしています。
一般提供になった今、「様子見だから」で止まっている理由はほとんどなくなりました。半年後に競合が業務効率で先行している、というのが2025年以降のAI領域の現実です。様子見と試験導入はトレードオフではなく、どちらも同時に走らせる体制設計が要ります。
当時→現在：Claude機能進化の流れ
参考までに、Anthropicが過去1年半でリリースしてきたエージェント関連機能の変遷を整理します。
| 時期 | 機能 | 位置づけ |
|---|---|---|
| 2024年初頭 | Tool Use（Messages API） | カスタムツール呼び出しの基本形 |
| 2024年中盤以降 | Computer Use | 画面操作系の自動化 |
| 2025年前半 | Claude Code発表 | エージェント型コーディングCLI |
| 2025年中盤 | Agent SDK公開 | Claude Code相当の能力をライブラリ化 |
| 2025年後半 | Skills、Subagents、Managed Agents | エージェントの構造化と運用基盤 |
| 2026年5月28日 | Dynamic Workflows + Opus 4.8 | スクリプト駆動の大規模並列オーケストレーション（リサーチプレビュー） |
| 2026年（現在） | Dynamic Workflows一般提供、Agent teams、ultracode | 全有料プランへ。起動はultracode、Agent teamsも追加 |
「Tool Useでツール呼び出しを定義」から始まり、「Agent SDKでループを抽象化」「SkillsとSubagentsで分業」「Managed Agentsで運用基盤を肩代わり」と積み上がり、「Dynamic Workflowsでオーケストレーション自体をスクリプト化」した。そして今、それが一般提供になり、Agent teamsという対話型の並行作業モードも加わりました。Dynamic Workflowsはこれらを置き換えるものではなく、最上位レイヤーに乗る抽象だと捉えると、社内の技術選定がしやすくなります。最新の機能状況はClaude Code公式ドキュメントとClaude Platform公式ドキュメントで確認してください。
まとめ
ポイントを整理します。
- Dynamic Workflowsは一般提供（generally available）になり、すべての有料プランで使える。Proは
/configの「Dynamic workflows」をオンにするだけ - 起動キーワードは
ultracode。workflowはv2.1.160より前の仕様。自然文での依頼も有効で、/effort ultracodeはxhigh推論と自動編成を組み合わせる（v2.1.203以降） - 現行の比較はサブエージェント、Skills、Agent teams、ワークフローの4つ。プランがコードに移り、中間結果はスクリプト変数に残る
- スクリプトの実体はトップレベルawaitの素のJavaScript。
agent()とpipeline()、export const meta。ランごとに~/.claude/projects/へ書き出され、読んで直して再起動できる - 同時最大16、1ラン合計1,000エージェント。再開は同セッション内のみで、停止時に実行途中だったエージェントはやり直しになる
- コスト統制はsize設定、Large workflow警告（25エージェント超か150万トークン超）、キャッシュ90％減とBatch 50％減。新トークナイザで同一テキスト約30％増を織り込む
- v2.1.210以降、起動は人間のタイプ入力限定のオプトイン。
-p、humanスタンプなしのAgent SDK、スケジュール、Webhook／PRコメントでは起動しない - 国内企業はZEROCKのような国内基盤との組み合わせ、または各クラウド経由の構成が現実解。WARP NEXTで意思決定プロセスごと支援
一般提供という一言で、Dynamic Workflowsは「試せる人が試す実験機能」から「有料プランの標準装備」に変わりました。経営会議で議論すべきは「使うか、使わないか」ではなく、「どの業務から、どのリスクラインで導入するか」です。半年前の様子見トーンは、もう手放していい時期に来ています。
自社のAI戦略を整理したい方へ
Dynamic Workflowsのような最新エンタープライズAI機能を、自社のどの業務に、どのタイミングで導入すべきか。その意思決定を、元大手DX・データ戦略専門家が月次伴走する形でご支援するのが WARP NEXT です。Claudeを国内サーバーで安全に使いたい場合は ZEROCK が候補になります。
WARP NEXTの内容を見る ZEROCKの内容を見る 30分の無料相談を予約する
参考文献
- Anthropic. "Introducing dynamic workflows in Claude Code."（一般提供の明記・Bun事例） https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
- Anthropic. "Orchestrate subagents at scale with dynamic workflows." Claude Code Documentation. https://code.claude.com/docs/en/workflows
- Anthropic. "Introducing Claude Opus 4.8." 2026年5月28日. https://www.anthropic.com/news/claude-opus-4-8
- Anthropic. "Pricing." Claude Platform Documentation.（Opus 4.8／Fast Mode／Batch／キャッシュ／新トークナイザ） https://platform.claude.com/docs/en/about-claude/pricing
- Anthropic. "Fast mode." Claude Platform Documentation.（対応モデル・Opus 4.7 Fast Mode廃止日） https://platform.claude.com/docs/en/build-with-claude/fast-mode
- Anthropic. "Create custom subagents." Claude Code Documentation. https://code.claude.com/docs/en/sub-agents
