はじめに
2025年8月にリリースされたClaude Opus 4.8には、Dynamic Workflowsという新機能が搭載されています。これは単なるチャットの延長ではなく、JavaScriptスクリプトがAIサブエージェントを大規模にオーケストレーションするという、これまでとは一線を画すアーキテクチャです。
この記事では、Dynamic Workflowsの仕組みと使い方を解説し、大規模コードベースの自動監査タスクに活用した知見を紹介します。
Dynamic Workflowsとは
Dynamic Workflowsは、Claude Codeに搭載されたマルチエージェントオーケストレーション機能です。
従来のサブエージェントとの違い
| 方式 | 仕組み | 結果の取り回し |
|---|---|---|
| 通常のサブエージェント | 単一セッション内で動作、完了後に呼び出し元へ返答 | Claude のコンテキスト経由 |
| Agent Teams | 独立したセッションで動作、セッション間で直接通信 | Claude のコンテキスト経由 |
| Dynamic Workflows | JSスクリプトがオーケストレーターとして動作 | スクリプト変数に中間結果を保持 |
Workflowsの最大の特徴は、中間結果がClaudeのコンテキストを通過しない点です。スクリプト変数として保持されるため、コンテキスト長の制約を受けにくく、大規模なタスクに向いています。
ワークフロートリガーの種類
Dynamic Workflowsは以下の3つの方法で起動できます：
- プロンプトに "workflow" というキーワードを含める
-
/deep-researchコマンドを使う -
/effort ultracodeを使う（xhigh推論 + 自動ワークフロー起動）
前提条件と有効化手順
必要環境
- Claude Code v2.1.154 以上
- プラン: Pro / Max / Team / Enterprise（無料プランは非対応）
-
モデル: Claude Opus 4.8（
/effort ultracodeの場合はxhigh対応モデルが必須）
設定手順
# 1. Dynamic Workflowsを有効化
/config → Dynamic Workflows → ON
# 2. モデルをOpus 4.8に切り替え
/model → claude-opus-4-8
# 3. 最大推論モードで起動（任意）
/effort ultracode
/effort ultracode は「xhigh推論 + Dynamic Workflows自動起動」のショートカットです。両方の設定が揃っていないと以下のエラーが出ます：
Ultracode needs dynamic workflows enabled (see /config) and an xhigh-capable model.
Valid options are: low, medium, high, xhigh, max, auto
ワークフロースクリプトの構造
Dynamic Workflowsが起動すると、Claude Codeは内部的にJavaScriptのオーケストレータースクリプトを生成・実行します。スクリプトは以下の4つの主要プリミティブで構成されます。
// phase: 順序付きフェーズの定義
await phase("discovery", async () => {
// ...
});
// parallel: 複数エージェントの並列実行
const results = await parallel([
agent("audit-area-1", { schema: FindingSchema, label: "Area 1 Audit" }),
agent("audit-area-2", { schema: FindingSchema, label: "Area 2 Audit" }),
agent("audit-area-3", { schema: FindingSchema, label: "Area 3 Audit" }),
]);
// pipeline: 前段の出力を後段に渡す直列実行
await pipeline(
agent("scan"),
agent("verify"),
agent("report")
);
agent() のオプション
| オプション | 説明 |
|---|---|
schema |
サブエージェントの返り値のJSONスキーマ（zodなど） |
model |
エージェントごとにモデルを変えられる（コスト最適化に有効） |
label |
UI上に表示される識別名 |
phase |
エージェントが属するフェーズ名 |
StructuredOutputの重要性
サブエージェントが結果を返すには、StructuredOutput ツールを明示的に呼び出す必要があります。これを呼ばずに完了してしまうと、結果がスクリプトに渡らず「検証失敗」扱いになります。
プロンプトに必ず以下のような指示を含めましょう：
タスク完了後、必ずStructuredOutputツールを呼び出して結果を返してください。
呼び出しなしに終了した場合、結果は破棄されます。
実践：大規模コードベースのセキュリティ監査
タスク概要
数万行規模のTypeScriptコードベースを対象に、インシデント級のセキュリティ問題を自動検出するワークフローを構築しました。
想定する監査ターゲット（例）：
- サーバーミドルウェア群（主な攻撃面）
- プラグイン・SSR処理系
- クライアントサイドコード
- パッケージエントリポイント
ワークフロー設計（改善版）
初回試行（1回目）は以下の問題で完全に失敗しました：
- エージェントが3分×6回スタール（Opus 4.8 + xhigh の組み合わせが重すぎた）
- 調査対象が広すぎた（ディレクトリ単位で指定）
- 「確認済みのみ報告」という制約が厳しすぎた
改善策として採用した設計：
モデル: Sonnet（コスト削減 & 安定性優先）
エリア分割: 12の細粒度エリアにファイルリストで明示
精度方針: 「確信度つきで候補を表面化」（判断は検証フェーズに委ねる）
検証構造: スキャンエージェント → 独立した2つの検証エージェント（両者合意で確認）
実行結果サマリー（参考値）
| 指標 | 数値 |
|---|---|
| 総エージェント数 | 66 |
| ツール呼び出し数 | 781 |
| 所要時間 | 約15分 |
| 消費トークン（サブエージェント） | 約182万 |
| 発見数（生） | 38件 |
| 確認済み問題 | 11件 |
| 要レビュー | 27件 |
| 検証エージェント失敗 | 16件 |
ハマりポイントと対策
1. StructuredOutputを呼ばないエージェントが続出
症状： verification failure: agent completed without calling StructuredOutput
対策： エージェントへのプロンプト末尾に必ず「StructuredOutputを呼ばずに終了するな」と明記する。スキーマも具体的に定義する。
2. Opus 4.8 + xhigh でエージェントがスタール
症状： エージェントが3分以上応答なしでタイムアウト
対策： オーケストレーターはOpus 4.8のままでも、サブエージェントのモデルをSonnetに下げることで安定性が大幅に向上。
3. トークンコストが想定以上に高い
182万サブエージェントトークンは、Maxプランでも一気に消費します。
対策：
- スキャンフェーズはHaiku、検証フェーズはSonnet、要約のみOpusという階層型モデル割り当て
- 対象ファイルを絞り込み、「このファイルだけ見ろ」と明示する
- ワークフロー実行中は
/workflowsダイアログを開かない（中断される）
4. エリアが広すぎると品質が落ちる
「あるディレクトリ全体」という指定だと、エージェントが何を優先すべきか判断できず、浅い結果になりがち。ファイル名を明示したリストで指定すると精度が上がります。
まとめ
Dynamic Workflowsは、単発のコード質問とは異なる大規模コードベース横断タスクで真価を発揮します。特に有効なユースケースは：
- セキュリティ監査（複数ファイルを並列スキャン → 独立検証）
- コードレビューの自動化（PR全体を分割して並列チェック）
- ドキュメント生成（ファイルごとに並列解析 → 統合）
- テストカバレッジ分析（モジュール単位の並列チェック）
一方でトークンコストは相当高いため、/effort ultracode はピンポイントで使い、普段のタスクには通常モードを使うという使い分けが重要です。
まずは小さなスコープで試して、エージェント数・モデル構成・StructuredOutputの呼び出し確認の3点を押さえると、安定した結果が得られるようになります。