11日で75万行、テスト通過率99.8% — Claude Codeの「Dynamic Workflows」が開いた並列開発の扉

Bunの開発者Jarred Sumnerが、11日間で約75万行のコードを生成し、既存テストスイートの通過率を99.8%に維持した。手でペアプロしたわけではない。Claude Codeに「Dynamic Workflows」という新機能を使わせた結果だ。

5月28日、AnthropicはClaude Opus 4.8のリリースと同時に、Claude Codeの新たなオーケストレーション機能Dynamic Workflowsをリサーチプレビューとして公開した。一言でいうと、Claude Codeが自分でJavaScriptのオーケストレーションスクリプトを書き、最大1,000のサブエージェントを並列で走らせる仕組みだ。

これまでのClaude Codeは「1つのセッションで1つの問題を順番にこなす優秀な個人」だった。Dynamic Workflowsは、それを「チームを束ねるリーダー」に変える。

仕組み — Claudeが脚本を書き、ランタイムが実行する

Dynamic Workflowsの中核は、従来のサブエージェントとの役割分担の変更にある。

通常のサブエージェント実行では、Claudeがターンごとに「次に何を実行するか」を判断する。中間結果はすべてClaudeのコンテキストウィンドウに溜まる。タスクが大きくなると、コンテキストが埋まり、判断精度が落ちる。

Dynamic Workflowsでは、計画をコードに移す。Claudeがタスクの構造を分析し、ループ、分岐、中間変数を持つJavaScriptスクリプトを生成する。ランタイムがそのスクリプトを分離環境で実行し、各サブエージェントの結果はスクリプト変数に格納される。Claudeのコンテキストには最終結果だけが返る。

つまり、プランの保持と実行がClaudeの「頭の中」からコードに移った。これにより、数十〜数百のエージェントを並列に走らせても、コンテキスト溢れを起こさない。

制約もはっきりしている。

制約	値
同時並列エージェント数	最大16（CPUコア数が少ない環境では自動調整）
1ランあたりの総エージェント数	最大1,000
ユーザーからの途中入力	不可（パーミッション確認のみ）
ファイルシステム・シェルへの直接アクセス	スクリプト自体からは不可。エージェントが代行

1,000という上限は暴走防止のためだ。途中で止めても完了済みのエージェント結果はキャッシュされ、再開すれば途中から走り直す。

3つのトリガー

Dynamic Workflowsを起動する方法は3つある。

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

Run a workflow to audit every API endpoint under src/routes/ for missing auth checks

「workflow」という単語をClaudeが検知し、通常のターンバイターン処理ではなくワークフロー生成に切り替わる。意図せずトリガーしてしまった場合は alt+w でキャンセルできる。

2. /deep-research コマンド

ビルトインのワークフローコマンド。質問を渡すと、複数の角度からWeb検索を展開し、ソースをクロスチェックし、根拠付きのレポートを返す。

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

3. /effort ultracode

最も大胆なモード。セッション全体でClaudeが「このタスクにワークフローが必要か」を自律的に判断する。1つのリクエストが「コードを理解するワークフロー → 変更するワークフロー → 検証するワークフロー」と連鎖することもある。トークン消費は跳ね上がるが、大規模な作業にはこれが一番手っ取り早い。

何に使えるのか

公式ドキュメントが挙げるユースケースは4つ。

• コードベース全体のバグ監査: 数百のファイルを独立したエージェントが並列で走査し、互いの発見を敵対的にレビューする
• 大規模マイグレーション: フレームワークやAPIのバージョン移行を、ファイル単位で分割して並列実行
• クロスチェック型リサーチ: 複数のソースを独立に調査し、矛盾する主張をフィルタリングしてから統合
• 多角度プランニング: 設計方針を複数の独立したエージェントに起案させ、比較検討してから1つに決める

ここで重要なのは、単に「並列に走らせる」だけではない点だ。ワークフロースクリプトには、独立したエージェントが互いの成果物を敵対的にレビューするフェーズを組み込める。1つのエージェントが書いたコードを別のエージェントがテストし、不合格ならフィードバックを返して修正させる——といったループが、人間の介入なしに回る。

この「エージェント間のピアレビュー」こそが、Jarred Sumnerの99.8%テスト通過率の裏にある仕組みだろう。

実行できる環境

プラン	利用可否
Pro	/config で有効化が必要
Max, Team, Enterprise	デフォルトで利用可能
API（Bedrock, Vertex AI, Foundry）	利用可能

CLI、デスクトップアプリ、VS Code拡張のすべてで動作する。Claude Code v2.1.154以上が必要。

気をつけたいのはコストだ。ワークフロー1回で数百のサブエージェントが動くため、通常の会話型利用と比べてトークン消費が桁違いに増える。各プランの使用量制限・レート制限がそのまま適用されるので、大きなワークフローを回す前に /model でモデルを確認しておくことを勧める。ルーティン作業のステージには軽量モデルを使うよう指示すれば、コストを抑えられる。

保存して再実行できる

うまく動いたワークフローは /workflows からコマンドとして保存できる。プロジェクト内の .claude/workflows/ に置けばチーム全員で共有でき、~/.claude/workflows/ に置けば個人用のどのプロジェクトからでも呼び出せる。

つまり「うちのCI/CDで毎回走らせるセキュリティ監査ワークフロー」のようなものを、一度書けば繰り返し使える。ここがDynamic Workflowsの地味に大きいポイントで、単発の便利機能ではなく、チームのプロセスに組み込めるインフラになり得る。

正直な懸念

リサーチプレビューであることは忘れてはいけない。

まず、スクリプトの途中でユーザーが介入できない設計は、タスクの方向性が間違っていた場合にトークンを大量に無駄にするリスクがある。止めることはできるが、軌道修正はできない。

次に、1,000エージェントという数は理論上の上限であって、ProプランのRate Limitを考えると現実的に走らせられるのはもっと少ないはずだ。Maxプラン以上でないと本領は発揮しにくいだろう。

そして、ワークフロースクリプトの品質がClaudeの生成能力に依存する。スクリプト自体にバグがあればワークフロー全体が壊れる。Ctrl+G でスクリプトをエディタで確認してから実行する癖をつけたほうがいい。

それでも方向は正しい

Dynamic Workflowsが示しているのは、AIコーディングツールの次のフェーズだ。

これまでのClaude Codeは「1人の優秀なエンジニアをペアプロ相手にする」ツールだった。Dynamic Workflowsは「10人のエンジニアチームに指示を出す」ツールに変えようとしている。しかもそのチームは互いのコードをレビューし、テストを回し、結果を統合して1つの成果物にまとめる。

この方向が実用レベルに到達すれば、「レビュー待ち」という開発チーム最大のボトルネックが構造的に変わる可能性がある。人間がレビューする前に、エージェント同士で事前フィルタリングが終わっている状態だ。

いまはリサーチプレビューの段階で、本番投入には早い。だが /deep-research を一度試せば、ワークフローが返すレポートの質に「これが数百のエージェントが並列で動いた結果か」と驚くだろう。Claude Codeを日常的に使っている人は、今のうちに /effort ultracode を小さなタスクで試して感触を掴んでおくことを勧める。本番投入できるレベルに達したとき、真っ先に恩恵を受けるのは、この仕組みに慣れている人だ。