Claude Codeの新機能「Dynamic Workflows」を試す
こんにちは。開発二部の箕浦です。
2026年5月28日、Anthropicが Claude Opus 4.8 と同時に、Claude Codeの新機能 「Dynamic Workflows(ダイナミックワークフロー)」 を発表しました(公式ブログ)。
ひとことで言うと、 「Claude自身がオーケストレーションスクリプトを書いて、多数のサブエージェントを走らせ、結果を自己検証してから1つの答えにまとめてくれる」 という機能です。
これまでこのブログでは、Claude Code導入ガイドや仕様駆動開発(SDD)入門、Skillsでエージェントを強化するといったテーマを扱ってきましたが、Dynamic WorkflowsはまさにそれらのAIエージェント路線の最新形です。発表されたばかりで日本語の情報もまだ少ないので、現時点(2026年6月)で分かっていることを整理してみます。
なぜ「ワークフロー」が必要なのか
Claude Codeは賢くなりましたが、それでも 「1人のエージェントが1パスで処理する」には大きすぎるタスク があります。
- サービス全体・リポジトリ全体にまたがる バグ探索 や セキュリティ監査
- 数百〜数千ファイルに触れる 大規模なマイグレーション(フレームワーク移行、API廃止対応、言語ポート)
- コミット前に あらゆる角度からストレステストしておきたい 設計や変更
こうした作業は、人間がやれば「四半期単位」の計画になることもあります。
従来のサブエージェント機能でも並列化はできましたが、 「どう分割し、どう検証し、どう統合するか」を毎回人間が組み立てる 必要がありました。Dynamic Workflowsは、その オーケストレーション(指揮)そのものをClaudeに任せてしまおう という発想です。
Dynamic Workflowsとは何か
公式の「How it works」を要約すると、こういう流れです。
- プロンプトを受け取ると、Claudeが 動的に計画を立て、タスクをサブタスクに分解する
- サブタスクを 並列で動くサブエージェント群 にファンアウト(分散)する
- 各エージェントが 独立した角度から問題に取り組み、別のエージェントがその結果を 反証(refute) しようとする
- 答えが 収束(converge)するまで反復 する
- 結果は統合前に検証され、利用者には 1つの整理された答え だけが返る
ポイントは、Claudeが裏側で JavaScriptのオーケストレーションスクリプトを生成 し、ランタイムがそれを実行するという仕組みです。
調整(コーディネーション)が会話の外側で行われるため、タスクがどれだけ大きくなっても 計画が脱線しにくい という特徴があります。
なお、エージェントの規模には公式ドキュメントで上限が決められています。
同時に走るのは最大16エージェント(CPUコアが少ないマシンではさらに少なくなります)で、 1回の実行で生成できるエージェントは累計最大1,000 までです。後者は暴走ループを防ぐためのストッパーという位置づけです。
さらに、 途中経過が保存される ので、停止しても完了済みのエージェントはキャッシュ結果を返し、残りだけを実行する レジューム(再開) が可能です。
ただし再開できるのは 同一のClaude Codeセッション内に限られ、Claude Codeを一度終了するとワークフローは次回最初からやり直しになる点には注意が必要です。数時間〜数日に及ぶ長時間タスクを想定した設計です。
従来の「サブエージェント」や「Skills」との違い
過去記事を読んでくださった方向けに、立ち位置を整理します。
| 機能 | ざっくりした役割 |
|---|---|
| サブエージェント | 1つのタスクを別コンテキストに切り出して並列実行する |
Skills(SKILL.md) | 「ブレストする」「仕様を書く」等の手順を再利用可能に固定化する |
| Dynamic Workflows | 分割・並列実行・相互検証・収束までを丸ごとClaudeが指揮する |
CyberAgentのエンジニアの方も公式ブログで 「単一サブエージェントを撃つことと、本格的なエージェントチームを組むことの“あいだ”を埋めてくれる」 とコメントしていて、この表現が立ち位置をうまく言い当てていると思います。
使い方
対象プランと提供形態
現時点では リサーチプレビュー として、Claude Code CLI・デスクトップアプリ・IDE拡張・非対話モード(claude -p)・Agent SDKで利用できます。
利用には Claude Code v2.1.154 以降 が必要です。
- 全有料プランで利用可能。ただし Proプランはデフォルト無効 で、
/configの「Dynamic workflows」行から自分でオンにします - 組織(Enterprise等) では管理者がマネージド設定で組織全体のオン/オフを制御できます
- Claude API / Amazon Bedrock / Google Cloud Vertex AI / Microsoft Foundry でも利用可能
起動方法
公式は auto modeをオンにした状態での利用を推奨 しています。その上で、起動方法は2通りです。
- Claudeに直接ワークフローを作るよう頼む(例: 「Create a workflow」「ワークフローを作って」)
ultracodeという新設定をオンにする ─ effort(努力度)メニューからアクセスでき、effortレベルをxhighに設定しつつ、 ワークフローを使うかどうかはClaudeが自動判断 してくれます
初めてワークフローがトリガーされるときは、Claudeが 「これから何を実行するか」を提示して確認を求めてくれます。いきなり大量のエージェントが暴走することはありません。
ワークフローが起動中は、/workflows コマンドを実行すると
以下のように起動中のエージェントがいくつ立ち上がって、それぞれのエージェントが何をしているかが確認可能です。
ユースケース
公式やアーリーアクセスのユーザーが挙げている使いどころです。
- コードベース全体のバグ探索 / 最適化監査 / セキュリティ監査
並列で探索した上で、 個々の発見を独立に再検証 するため、レポートに上がるのは“本物の問題”だけになります。認証チェック・入力バリデーション・危険なパターンの洗い出しといったハードニング作業にも同じ形が使えます。 - 大規模なマイグレーション / モダナイゼーション
フレームワーク移行、API廃止対応、言語ポートなど、数千ファイルにまたがる作業をエンドツーエンドで。 - 二重チェックが必要なクリティカルな作業
間違いのコストが高い場面で、Claudeに 独立した複数の試行 をさせ、 敵対的(adversarial)なエージェント に結果を壊しにかからせてから人間が確認できます。
実際、Klarnaのエンジニアリングマネージャーは 「デッドコードの特定や、静的解析では見つからなかったクリーンアップ箇所の洗い出しに効いた」 とコメントしています。
圧巻の実例: Bunを Zig → Rust に移植
インパクトが大きい事例として、ランタイム Bun の言語移植が紹介されています。
Jarred Sumner氏がDynamic Workflowsを使って、BunをZigからRustへ移植したというものです。
- 既存テストスイートの 99.8% がパス
- 約75万行のRustコード
- 最初のコミットからマージまで わずか11日
流れもエージェント的で、
- あるワークフローがZigコードの全構造体フィールドに対して 正しいRustのライフタイムをマッピング
- 次のワークフローが各
.zigを 挙動が同一な.rsに移植(数百のエージェントが並列で動き、各ファイルにレビュアーが2人) - ビルドとテストが通るまで回し続ける fixループ
- 移植後、 夜間のワークフロー が不要なデータコピーを直し、それぞれPRを起票
…という、まさに「四半期仕事が数日で終わる」を体現した事例になっています(※本番投入はこれからとのこと)。
試すときの注意点
実際に使ってみる前に、押さえておきたい点です。
- トークン消費が桁違いに増える
公式が繰り返し警告しているとおり、Dynamic Workflowsは 通常のClaude Codeセッションよりも大幅にトークンを消費 します。いきなり巨大タスクで回すのではなく、 スコープを絞った小さなタスク で使用感を確かめるのが推奨です。 - リサーチプレビュー段階である
仕様や挙動は今後変わる可能性があります。社内の標準フローに組み込むのは、もう少し成熟を待ってからが安全でしょう。 - Enterpriseはデフォルト無効
組織で使う場合は管理者による有効化が必要です。逆に、管理設定でワークフローを 明示的に無効化 することもできます。
まとめ
Dynamic Workflowsは、AIコーディングの主役を 「AIにコードを書いてもらう」から「AIエージェント群の指揮系統ごとAIに任せる」 へと一段押し進める機能だと感じます。
前回のSDDの記事で引用したKarpathyの "The programmer is increasingly not just a code writer, but an orchestrator of agents." という言葉が、いよいよ製品機能として降りてきた、という印象です。
とはいえ現状はリサーチプレビューで、トークンコストも相応にかかります。
まずは ultracode をオンにして、コードベースのちょっとしたバグ探索や監査 あたりの“小さく試せるタスク”から触ってみるのが良さそうです。
弊社でも実案件で回してみて、また知見がたまったら続報をお届けしようと思います。