一行でいうと
Claudeがその場で工程表（スクリプト）を書き、ランタイムがそれを実行して数十〜数百体のエージェントを動かす仕組みです。合言葉は ultracode。
工程をコードにすると、大量の反復と検証を同じ型で回せます。
何が新しいのか
新しいのは、Claudeが仕事のやり方そのものをコードとして書き出すようになったことです。
前のレッスンまでは、判断はすべてその場のClaudeが下していました。ターンごとに「次はこれ」と考える。人数が5人なら回りますが、100件のタスクではもう無理です。
Anthropicの公式記事は、この変化をこう表現しています。
Claude can now write its own harness on the fly, custom-built for the task at hand. （Claudeは今や、目の前の仕事のために特注の"馬具"をその場で自分で書けるようになった）
ループも分岐も、そのコードの中にあります。公式ドキュメントはこう言い切っています。「ワークフローとは、計画をコードに移すことだ」。
新しいと言っても、この発想そのものに元ネタがあります。Anthropicが2024年12月に公開した設計指針「Building Effective Agents」です。
そこでAnthropicは、workflowとagentという2つの言葉を分けて定義しました。workflowは、あらかじめ決めたコードの経路に沿ってLLMとツールを動かす仕組み、agentは、LLM自身がその場で自分の進め方とツールの使い方を決めていく仕組み、と整理しているとされます。前のレッスンまでのClaudeは、判断をターンごとに自分で下すagent型でした。Dynamic Workflowsは、そのagentが自分の手でworkflowを書き、実行はコードに委ねるという、両者をつなぐ形だといえます。
仕組み: 計画がコードになる
ultracodeと打つと、4段階を経て結果だけが返ってきます。
大事なのは最後です。ループの途中経過はスクリプト側が持ち、Claudeの会話には最終結果だけが残ります。だから100件処理しても、会話は汚れません。
この4段階の骨格は、Building Effective Agentsが挙げた5つの型のうち、Orchestrator-workersパターンをそのまま受け継いだものです。原典が挙げる5つの型は、順に処理を渡すPrompt chaining、内容で振り分けるRouting、並列に走らせるParallelization、中央のLLMがタスクを動的に分解して割り振るOrchestrator-workers、生成と評価を往復させるEvaluator-optimizerです。このうちOrchestrator-workersが、Dynamic Workflowsの直接の祖先だといえます。中央のLLMがタスクを分解し、ワーカーに配り、結果をまとめるという骨格が、設計・展開・実行・回収の4段階とそのまま重なるからです。
$ultracode このフォルダの記事120本すべてを事実関係の誤りがないか監査して。見つけた指摘は別のエージェントに反証させて、生き残ったものだけ報告して
/effort ultracode と打てばセッション全体の既定にもできますが、そうすると全タスクでワークフローが検討されてトークン消費が跳ね上がります。普段はプロンプトに合言葉を混ぜる方式で十分です。
Agent Teamsとの違いは「誰がプランを持つか」
違いは一点だけです。誰がプランを持つか。ここが最も混乱しやすいポイントです。
チームはその場で相談して決める。工場は先に決めた工程表のとおりに流れる。どちらが優れているかではなく、仕事の形で選びます。
規模と限界
数十〜数百体という規模には、明確な上限があります。
- 1回の実行で数十〜数百体
- 同時に走るのは16体まで、1回の合計は1,000体まで
- 25体を超えるか、見込み150万トークンを超えると警告が出る
ただし警告は出るだけで、止まりません。読むのは人間の仕事です。
数を質に変える「疑う役」
定石は、独立したエージェントに互いの発見を敵対的にレビューさせてから報告させることです。数百体を走らせると量は稼げますが、もっともらしい間違いも同じだけ増えるからです。
働く人にはおなじみの構造です。ダブルチェックと査読。作った本人に確認させるのではなく、疑うことだけが仕事の別人を立てる。規模が大きくなるほど、この分離が効いてきます。
よくある誤解と罠
罠1: 何でもワークフロー化する
いちばん高くつく誤用です。1つの依頼が複数のワークフローに化け、トークンが最重量になります。大型の横断改修・徹底監査・多面リサーチのときだけ、と決めておくのが安全です。
罠2: 警告を無視する
25体超・150万トークン超の警告は、止まらないぶん自分で判断する必要があります。「この仕事に、人を雇っていたらいくらかかったか」を基準にすると判断しやすくなります。
罠3: 検証を付けずに数だけ増やす
これが最悪の組み合わせです。間違いも同じ倍率で増えます。数を増やすなら、必ず疑う役をセットにする。
使いどころ
向いているのは、量と横断性がものを言う仕事です。
- 過去に書いた記事・スライド全部を横断して、記述の矛盾を洗い出す
- 大量の資料を一定の観点で仕分けし、独立に検証させてから結論を受け取る
- 自分の教材全体を通しで監査する（1本ずつのチェックでは見つからない矛盾が出る）
- 四半期がかりの大規模なコード移行やリファクタリングを、後回しにせず片づける
3つ目が特に価値があります。1本ずつのファクトチェックでは、記事どうしの矛盾は原理的に見つかりません。横断で見て初めて分かります。
4つ目は、規模がものを言う効果を最も端的に示す例です。Claude Code作者のBoris Chernyは、この変化をこう述べています。
“Big migrations and refactors are some of a team's most important work, and the easiest to push off to a “better time” since they'd tie up engineers for a quarter. With dynamic workflows, Claude can now land that kind of work in days or weeks.”
筆者訳大規模なマイグレーションやリファクタリングは、チームにとって最も重要な仕事の一つでありながら、エンジニアを1四半期拘束してしまうために「もっと良いタイミングで」と先送りされがちな仕事でもある。Dynamic workflowsを使えば、その種の仕事をClaudeが今や数日から数週間で仕上げられる。
エンジニアを1四半期拘束していた仕事が、数日から数週間に縮む。数を扱えることの実際の価値は、ここに表れています。
今日のまとめ
- Dynamic Workflowsは、Claudeが工程表を書き、ランタイムが数百体を動かす仕組み
- Agent Teamsとの違いは「誰がプランを持つか」。会話で協調か、コードで統制か
- 数を増やすなら疑う役を必ず付ける。検証なしの規模拡大は間違いも増やす
ultracodeの起動、規模の上限、Agent Teams・Subagentsとの公式比較表。
ここまでが「誰に判断を持たせるか」の4階層。次からは、その外側で支える仕組みを見ていきます。