ClaudeがClaude Codeに追加した「dynamic workflows」は、ひと言でいうと、ひとつのAIに全部やらせるのではなく、たくさんの小さなAI作業を同時並行で走らせて、最後にまとめて点検する仕組みです。Anthropicはこれを、特に大きくてややこしい仕事向けに出してきました。
個人的にかなり面白いと思ったのは、単なる「速くなる機能」ではなく、AIの使い方そのものを変えようとしているところです。雑に答えを出すのではなく、途中で反証させたり、別の角度から検証させたりして、最終的に人の前に出す前にチェックを重ねる。ここがいちばん“らしい”進化だと感じます。
/config から有効化できるAnthropicの説明を読むと、dynamic workflowsは「Claudeが自分でオーケストレーションスクリプトを書く」ことが肝です。オーケストレーション、つまり作業全体の指揮をする仕組みですね。

普通のAIアシスタントは、1回の会話で順番に考えて、順番に答えることが多いです。でもこの機能では、まずClaudeが仕事を見て、どこをどう分けるかを動的に決めます。そして、その分けた作業を大量のsubagentに並列で投げる。さらに、出てきた結果を別のagentに検証させる。要するに、「考える」「分ける」「試す」「疑う」「まとめる」を自動で回すわけです。
これ、地味にすごいです。AIの強さは「一発回答」よりも「見落としを減らす能力」にあると思っていて、dynamic workflowsはその方向にかなり寄っています。人間のチームでも、難しい案件は一人で抱えず、役割を分けてレビューしますよね。あれをかなり強引にAI側へ寄せた感じです。
記事で挙げられている用途はかなり現実的です。たとえば、コードベース全体をまたぐバグ探し。古いコードが混ざった大規模なサービスだと、「この不具合、どこに潜んでるの?」という話になります。そういうときに一箇所を読むだけでは足りません。複数の場所を同時に見て、さらに別のagentが検証する。これは相性がいい。
それから、大規模なmigration。フレームワークの入れ替え、APIの廃止対応、言語の移植みたいに、何百ファイルにもまたがる作業です。こういうのは、途中で人間が疲れるし、見落としも出ます。dynamic workflowsは、その「広くて長い作業」を得意にしているようです。
もうひとつ印象的だったのは、critical work you need checked twice という考え方です。答えを出すだけならまだしも、間違いのコストが高い仕事では、答えそのものより「ちゃんと反対意見で殴ったか」が大事になります。セキュリティ監査なんてまさにそうで、見つかった問題が本当に問題かを独立に確かめる必要がある。Anthropicはそこをかなり意識しているように見えます。
記事の中でも目を引くのが、Bunのrewriteの話です。Jarred Sumnerが、BunをZigからRustへ移植するのにdynamic workflowsを使ったという例で、約75万行のRust、最初のcommitからmergeまで11日、そして既存テストの99.8%が通ったとされています。
これだけでも十分インパクトがありますが、やり方がまた面白いです。
まず、あるworkflowがZigコードベースの各struct fieldに対して、Rustでどのlifetimeを使うべきかを洗い出した。次に、別のworkflowが.zigに対応する.rsファイルを、振る舞いが同等になるように書いた。しかも何百ものagentが並列で作業し、各ファイルに2人のreviewerが付くような形。最後に、buildとtestが通るまで修正ループを回したそうです。
まだproductionではないと記事は書いていますが、それでもかなり攻めた使い方です。個人的には、ここは「AIがコードを書く」というより、巨大な変換作業を、人間が手を動かしすぎずに回す仕組みとして捉えるとしっくりきます。人力でやると気が遠くなる仕事を、分担と検証で押し切る。かなり実務っぽい。
workflowが始まると、Claudeは与えられた指示をもとに計画を立て、タスクを分解し、並列に走らせます。結果はそのまま採用されるのではなく、入れる前にチェックされます。さらに、別のagentが反証を試みる。つまり、ひとつの結論をそのまま信じず、違う方向から何度も当てにいくわけです。
ここが重要で、dynamic workflowsは「速く一回で終わる」ための機能というより、長く続く複雑な仕事を、途中で壊れにくくするための機能です。しかも進捗が保存されるので、途中で止まっても最初からやり直しになりません。大きな仕事ほど、やり直しのコストが痛いので、この仕様はかなり現場向きだと思います。
ただし、いい話ばかりではありません。Anthropic自身が、通常のClaude Codeセッションよりかなりtokenを使うと注意しています。つまり、気軽な雑談や軽い修正に向いた機能ではない。まずはスコープを絞った仕事で試すのがよさそうです。ここはかなり現実的な注意書きで、むしろ好感が持てます。万能感を盛りすぎていない。
始め方は2通りあります。ひとつは、Claudeにそのまま「workflowを作って」と頼む方法。もうひとつは、Claude Code専用の設定である ultracode をオンにする方法です。これは effort level を xhigh にしつつ、どのタイミングでworkflowを使うかをClaudeに任せる設定です。
利用できる環境も広く、Claude Code CLI、Desktop、VS Code拡張、そしてAPI経由でも使えます。さらに Bedrock、Vertex AI、Microsoft Foundry にも対応しています。Max、Team、Enterpriseでは基本オン、Proは /config から有効化する形です。管理者は設定で無効化もできます。
このあたりを見ると、Anthropicは「先端のデモ機能」としてではなく、ちゃんと業務に入れる機能として出してきた印象があります。大げさな実験ではなく、実際の開発フローに入り込ませるつもりなのでしょう。
dynamic workflowsの面白さは、モデル単体の性能向上ではなく、作業の組み立て方の変更にあります。AIを一人の天才として扱うのではなく、分業するチームとして扱う。しかも、そのチームにレビュー役まで持たせる。
私は、こういう方向性のほうが実用で強いと思っています。なぜなら、現実の仕事は「ひらめき」より「検証」と「修正」の繰り返しだからです。大きなコードベース、長い移行作業、セキュリティ確認。どれも一発で終わる世界じゃない。dynamic workflowsは、その現実にかなり正面から向き合っている機能です。
もちろん、token消費は重いし、万能でもありません。でも、大きな仕事を丸ごと任せるための土台としてはかなり筋がいい。AIエージェントの話は派手になりがちですが、こういう「地味に正しい」設計のほうが、あとから効いてくるのではないかと思います。