Engineering · アーキテクチャ
AIが書くオーケストレーション — ダイナミック・ワークフローと“数百のサブエージェント”の設計
AIがオーケストレーションのプログラムを自分で書き、数百のサブエージェントをバックグラウンドで並行に動かす——Claude Opus 4.8が示した『ダイナミック・ワークフロー』、その設計を解説します。
要点
- ✓ダイナミック・ワークフロー（Anthropic、2026-05-28）は、Claudeがオーケストレーションのスクリプトを生成し、バックグラウンドランタイムが数百のサブエージェントを並行・非同期に実行する仕組み（現在 research preview）。
- ✓1セッションで数百のサブエージェントが並行で動く一方、セッション自体はレスポンシブなまま保たれる（Anthropic は具体的なエージェント数の上限値を公表していない）。
- ✓従来の『静的な並列割り当て』と異なり、問題の形に応じてオーケストレーションを動的に組み立てる——渡すのは『手順』でなく『目標』。
- ✓収束型反復：一部のエージェントが仮説を立て、別のエージェントが反論・検証。答えが収束するまで繰り返すことで信頼性が上がる。
- ✓Anthropic Engineering（2026-03-24）の知見：Planner/Generator/Evaluatorの役割分離、評価者はプロセスを見ない（サンクコストバイアスの排除）、Opus 4.6 でコンテキストリセットが不要化（SDK の自動 compaction が吸収）。
手順を指定するから、目標を渡すへ
並列エージェントの典型的な形は、人が事前にタスクをA・B・Cに分割して、それぞれのエージェントに固定で割り振る「静的な並列」です。誰が何をするかは、実行前に人が設計します。問題が明確で、分割の仕方が決まっている場合はこれで十分です。
ダイナミック・ワークフローは違います。Claudeに「目標」と「合格の定義（どこで完了とみなすか）」を渡すと、Claudeがオーケストレーションのプログラム（スクリプト）を自ら書きます。そのプログラムがバックグラウンドランタイムで実行され、問題の形に応じてサブエージェントを動的に展開します。
手順を事前に完璧に設計しなくてよくなる——それがダイナミック・ワークフローの根本的な変化です。代わりに明確にすべきは「何を達成するか」という目標と「合格の条件は何か」という収束の定義です。
目標を渡すと、手順はAIが組み立てる
Claude Opus 4.8 のダイナミック・ワークフロー（Anthropic、2026-05-28）
Anthropicは2026年5月28日、Claude Opus 4.8の発表とともに「ダイナミック・ワークフロー（dynamic workflows）」を研究プレビュー（research preview）として公開しました。Enterprise/Team/Max プランの Claude Code が対象です。
仕組みはこうです。タスクを説明するとClaudeがオーケストレーション・スクリプトを生成し、バックグラウンドランタイムがそのスクリプトを実行します。セッション自体はその間もレスポンシブな状態を保ちます——タスクが裏で動いている間も、別の指示を出したり進捗を確認したりできます。
Anthropic は「1セッションで数百のサブエージェントを並行に走らせ」、「コードベース規模の移行（数十万行規模）を、開始からマージまで、既存のテストスイートを基準にこなせる」と報告しています（2026-05-28。具体的なエージェント数の上限値は公表されていません）。一部のエージェントが仮説を立て、別のエージェントがそれを反論・検証する——答えが収束するまで繰り返すことで、信頼性の高い成果を生み出します。
AIがプログラムを書き、数百のサブエージェントが動く
長時間自律実行を成立させる3つの要（Anthropic Engineering、2026-03-24）
Anthropicは2026年3月24日、「Harness design for long-running application development」（anthropic.com/engineering/harness-design-long-running-apps）として社内の設計知見を公開しています。以下は、この記事をもとにした一般論・設計原則の整理です（(B) 設計・一般論モード）。
第一の要は役割の分離です。Planner（1〜4文のプロンプトを詳細な仕様に展開）・Generator（実装）・Evaluator（評価）の3役割を分けます。重要なのは、評価者がプロセスを見ないことです。生成プロセスを知っている評価者は「せっかくここまで作ったから合格にしよう」というサンクコストバイアスに引っ張られます。評価者は成果物だけを見て、事前に定めた採点基準（デザイン品質・独自性・クラフト・機能性）で判定します（→ 生成役と評価役を分ける）。
第二の要は反復の設計です。Anthropic は（フロントエンド生成で）1生成あたり5〜15回のイテレーションを回す設計を報告しています。第三の要はコンテキスト管理の進化です。初期設計にあったコンテキストリセット（作業中に文脈を再初期化する仕組み）は、Opus 4.6 でほぼ自動的に不要になり、SDKの自動 compaction がコンテキストの膨張を吸収するようになりました（→ コンテキスト管理・メモリ設計）。
反論させるほど、答えが信頼できる
一次資料と注記
本記事の事実はすべて Anthropic の公開情報に基づきます：「Introducing Claude Opus 4.8」（Anthropic、2026-05-28）、「Harness design for long-running application development」（Anthropic Engineering、2026-03-24）。『数百の並行サブエージェント』や実行業務規模はいずれも Anthropic の報告であり、agens の機能・実績ではありません（Anthropic は具体的なエージェント数の上限値を公表していません）。ダイナミック・ワークフローは現在 research preview（Enterprise/Team/Max プランの Claude Code）。一般提供の時期は未公表です。
収束の設計——目標・制約・合格の定義
ダイナミック・ワークフローが示す設計の変化は、3つの問いで整理できます（(B) 設計の一般論）。
最初の問いは「何を目標として渡すか」です。Claudeにオーケストレーションを動的に生成させるには、「手順」ではなく「目標・制約・収束の定義（done の基準）」を渡す必要があります。「合格の条件」が曖昧なままだと、エージェントはループし続けます。採点基準を具体的に定める——「いいデザインとは？」を「視覚的統一性・独自性・タイポグラフィ・機能性」のように採点可能な指標に落とし込む——のが出発点です。
次の問いは「どう収束させるか」です。一部のエージェントが仮説を立て、別のエージェントが独立した視点で反論・検証する。答えが揃うまで繰り返す——これが品質の核心です。自分で採点すると甘くなるという傾向は、スケールが数百のサブエージェントになっても変わりません。
最後の問いは「統制をどこに置くか」です。スケールが上がるほど「何をやったか」の追跡が難しくなります。監査ログと巻き戻し——誰が何をAIにやらせ、どう完了したかを記録して戻せる仕組み——の価値は、スケールに比例して大きくなります。
🛡 agens との関係
（A）agens は、大規模・長時間の自律実行を「統制の枠内で動かす」製品です。タスクごとのサンドボックス隔離（エージェントが何をしても隔離環境内に閉じる）・全操作の監査とタスク単位の巻き戻し・RBAC による権限分離・スキル・ワークフローによる繰り返し業務の自動化・サブエージェントによる役割分担——これらをすぐに使えます。スケールが上がるほど、この統制レイヤーの価値は増します。（C）ダイナミック・ワークフローのような動的オーケストレーション規模への直接サポートは、設計上の拡張方向として位置づけています。
よくある質問
ダイナミック・ワークフローと静的な並列実行はどう違うのですか？
数百のサブエージェントが一斉に動くのですか？
長時間動かしてもコンテキストが壊れませんか？
評価者がプロセスを見ないのはなぜですか？
agens でこうした大規模並列実行を安全に運用できますか？
最終更新: 2026-06