Dynamic workflowsはエージェントの計画をcontextから実行可能なcodeへ移す

Anthropicのdynamic workflowsでは、Claudeがsubagentの起動、結果の収集、情報の流れを管理するJavaScriptのorchestration programを書く。公式documentationでは、1回の実行で数十から数百のagentを扱い、scriptを読んで保存し、再実行できるとしている。

Claudeは長い会話ではなくprogramへ調整手順を記録する

lead agentが最初に進め方を設計し、作業を分割するprogramを書く。その後runtimeが個別の課題にagentを起動し、中間結果をscript変数へ保持する。main contextへすべての手順を戻す必要はなく、調整済みの結果だけを渡せる。

AI Engineer New YorkでAnthropicは株式watchlist scannerを実演した。あるphaseがtickerを独立したcontextのagentへ配り、後のphaseが結果を確認した。codebase全体のaudit、大規模migration、情報源を相互確認するresearchも用途として挙げている。

Dynamic workflowsは2026年5月28日に発表され、Anthropicの公式pageでは現在general availabilityとされている。Claude Code CLI、Desktop、VS Code extension、APIに加え、Amazon Bedrock、Google Cloud、Microsoft Foundryで使える。利用には有料planまたはAPI accessが必要だ。

再実行できるscriptはengineering leadの仕事を大きく変える

通常のsubagentでは計画が会話の中に残る。workflowはloop、branch、reviewの順番を読めるcodeへ移す。同じ手順を再実行し、修正し、どのphaseが結果を作ったか確認できる。長いpromptが毎回同じ動作を引き出すと期待するより、運用しやすい。

engineering leadの管理対象も変わる。すべての中間手順を承認する代わりに、課題の境界、budget、受け入れ条件を定義する必要がある。独立したverifier agentも組み込めるため、大量のoutputを最後に読むのではなく、reviewをprogram内へ置ける。

Agentを増やすと費用と誤った目標の両方が増幅する

Anthropicは、workflowが通常のClaude Code sessionより大幅に多くのtokenを使うと明記している。conferenceでは、developerがsession budgetを設定できても、実行中のmodel自身はbudgetを知らないと説明された。誤った目標は並列に広がり、短時間で高くつく可能性がある。

可視性も正しさを保証しない。subagentはfilesystemを共有するが、発表によるとdeveloperはAPIから1つのworkflow subagentへ、別のsubagentに直接messageを送るよう指示できない。品質は作業分割、context isolation、test、verification phaseの独立性に左右される。

Token費用と却下された発見の数が実益を示す

実用的な導入では起動したagent数以外も測る必要がある。完了したmigrationあたりの費用、人間のreviewで却下された発見の割合、再実行で短縮した時間、中断後に作業を失わず再開できるかが重要だ。

強い証拠になるのは、保存したworkflowを繰り返し使い、production codeと同じ規律で保守するteamだ。大きな課題のたびに使い捨ての群れと手作業の後片付けが生まれるなら、待ち行列がGitHubからAPI請求書へ移っただけになる。

Lilithの判定

Anthropicはagentの群れを実行可能な時刻表に変えた。経路が間違っていれば、100人の乗客が誤った駅へ早く着くだけだ。