Anthropic / Claude Code発表 2026-05-28 ・レビュー 2026-06-16

Claude CodeのDynamic workflowsはAIを小チームに変える

Claude CodeのDynamic workflowsは、単なるClaude Opus 4.8の付属機能ではありません。AIがひとつの依頼に答える存在から、作業を分解し、複数のサブエージェントで並列に進め、最後に検証して返す運用単位へ変わるサインです。

3行で捉える

エージェントの常駐化: 単発のチャットではなく、仕事の文脈を持ち続けるAgentが各社の主戦場になっている。Dynamic workflowsは、その文脈を一つのAgentが抱えるだけでなく、作業単位へ分けて実行する方向を示している。

AnthropicのClaude Opus 4.8発表では、モデルの性能、誠実さ、effort controlと並んで、Claude CodeのDynamic workflowsが紹介されています。ここで重要なのは、モデルが少し賢くなったというより、AIに仕事を渡す単位が変わることです。

これまでのAI利用は、ひとつのプロンプトにひとつの回答、または一つのAgentが順番に作業する形が中心でした。Dynamic workflowsは、Claudeが作業を計画し、複数のサブエージェントを並列に動かし、最後に出力を検証して返す方向です。これは「回答生成」ではなく「作業運用」に近い。

人間の仕事でも、大きな移行や調査は一人で全部やりません。調査する人、実装する人、テストする人、レビューする人に分けます。Dynamic workflowsが示しているのは、この分担をAI側で組み立てる流れです。

もちろん、実際には人間のチームと同じではありません。サブエージェントは責任を持ちませんし、勝手に正しい判断を保証するわけでもありません。それでも、作業を分けて並列に進め、結果をまとめて検証する構造は、AIを一人の作業者として見る発想から離れています。

Anthropicは例として、数十万行規模のコードベース移行を挙げています。こうした作業は、単にコードを書ければ終わりではありません。影響範囲を探し、変更方針を決め、複数箇所を直し、テストを回し、失敗したら戻す必要があります。

この手の作業で難しいのは、作業量だけではなく、全体の整合性です。ひとつのファイルだけ直しても、周辺の型、テスト、設定、ドキュメントが崩れる。Dynamic workflowsは、こうした「分けて進めるが、最後は一つの基準で検証する」仕事に向いています。

最初に効きやすいのは開発です。依存ライブラリの移行、古いAPIの置き換え、テスト追加、リファクタリング、セキュリティ修正。どれも、影響範囲の調査と変更と検証がセットになります。

ただし、開発だけの話ではありません。契約書群の差分確認、社内規程の横断更新、複数資料からの調査、顧客問い合わせログの分類、ナレッジベース整理にも似た構造があります。大きな仕事を小さな仕事へ分け、並列に進め、最後に人間が確認する。この型が広がる。

並列化すると、速くなるように見えます。しかし実務で一番重要なのは速さではありません。何をもって完了とするかです。テストが通ることなのか、差分が小さいことなのか、レビューコメントがゼロになることなのか、ユーザー影響がないことなのか。

AIが複数のサブタスクを動かすほど、最後の統合と検証が重くなります。人間が見るべきなのは、AIがどれだけたくさん作業したかではなく、どの条件で止まり、どの証拠を出し、どの不確実性を残したかです。

サブエージェントが増えるほど、権限管理は難しくなります。どのファイルを触ってよいか。どのコマンドを実行してよいか。外部サービスにアクセスしてよいか。秘密情報を読ませてよいか。ログはどこに残すか。

Dynamic workflowsの価値は、AIに任せられる仕事を増やすことです。同時に、任せてはいけない範囲を明確にしないと危険です。大規模な自動変更ほど、承認者、停止条件、ロールバック、監査ログが必要になります。

Dynamic workflowsは、Claude Codeの便利機能としてだけ見ると小さく見えます。しかし、実務の見方では大きい。AIが「答える道具」から「作業を分解して進める運用単位」へ移るサインだからです。

これから問うべきことは、どのモデルが一番賢いかだけではありません。どの仕事を分解できるか。どこまで並列に動かせるか。何を検証基準にするか。最後に誰が承認するか。AI活用は、プロンプトの上手さから、仕事の設計へ移っています。