🔀 技術調査 - Claude Code 動的ワークフロー：並列実行の責任境界と検証設計

調査日: 2026-05-30 / 対象: Claude Code dynamic workflows（Claude Opus 4.8 と同時提供、2026-05-28、research preview）
視座: 「便利機能ではなく、並列実行時の責任境界と検証設計の問題として読む」

概要

2026-05-28、Anthropic は Claude Opus 4.8（claude-opus-4-8）と同時に、Claude Code へ dynamic workflows（動的ワークフロー） を research preview として追加しました。

公式は次のように定義します（一次: code.claude.com/docs/en/workflows）。

"A dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive."

この機能が解決する課題を整理します。 従来の subagents や skills では、Claude がオーケストレーターとしてターンごとに次の手を判断します。その結果、中間結果がすべて Claude の context window に蓄積し、大規模タスクでは context 枯渇がボトルネックになります。dynamic workflows はこの構造を根本から変えます。

"A workflow moves the plan into code. ... A workflow script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer."

本質は「Claude が書く JavaScript のオーケストレーションスクリプトを、ランタイムが background で実行する」仕組みです。ループ・分岐・中間結果はスクリプト変数に外出しされ、Claude の会話 context には最終回答だけが戻ります。これにより context 枯渇を回避し、桁違いのスケールに到達します。

Claude Opus 4.8 との関係を確認します。 dynamic workflows は Opus 4.8 と同日リリースですが、モデルへの依存は技術的制約というより機能的要件に近いものです。Opus 4.8 が実現した次の改善が、数百エージェント・数千ファイル規模の長時間ワークフローを「現実的に完走できる」前提になります（一次: anthropic.com/news/claude-opus-4-8）。

• longer agentic runs の持続力
• tool calling の効率化（同じ知能で fewer steps）
• コードの flaw 見逃し確率が前世代比 約 1/4
• xhigh effort による ultracode（xhigh reasoning と自動 workflow orchestration の組み合わせ）のサポート

利用要件をまとめます。

• CLI バージョン: Claude Code v2.1.154 以降が必須（research preview）
• 対応プラン: Claude Code docs では 全有料プラン（Pro / Max / Team / Enterprise） に加え、Anthropic API・Amazon Bedrock・Google Cloud Vertex AI・Microsoft Foundry。ローンチブログは Max / Team / Enterprise のみ言及し Pro に触れていないため、docs とブログで粒度が異なります。Pro は /config から手動 ON が必要です。

特徴

並列上限: 同時 16 / 累計 1,000

• 同時実行: 最大 16 concurrent agents。CPU コアが少ないマシンでは動的に減少します。
• 1 ラン累計上限: 1,000 agents total per run。runaway loop（暴走ループ）を防ぐ backstop です。

マーケティング文言「hundreds of parallel subagents」の実体は「同時 16 並列 × 累計最大 1,000」というランタイム制約であり、現実的なスケールは「数十〜数百 / ラン」です。

対応プラン

制御プリミティブ

self-verification = 敵対的クロスチェック

公式は次のように述べます。

"Moving the plan into code also lets a workflow apply a repeatable quality pattern: it can have independent agents adversarially review each other's findings before they're reported, or draft a plan from several angles and weigh them against each other."

/deep-research の具体動作は次のとおりです。

"Fans out web searches on a question across several angles, fetches and cross-checks the sources it finds, votes on each claim, and returns a cited report with claims that didn't survive cross-checking filtered out."

実体は次の 3 つです。

1. 独立エージェント同士の敵対的相互レビュー
2. claim 単位の投票とクロスチェック落ちのフィルタ
3. 複数アングルからのプラン起案と相互比較

「出力を検証してから報告する」の正体がこれです。ただし同系統モデルによるクロスチェックは同じ盲点を共有するリスクが残ります。品質保証と読み替えてはいけません（詳細は「トラブルシューティング」）。

起動 3 ルート

構造

公式一次ソース（code.claude.com/docs/en/workflows）を C4 model の 3 段階で整理します。

システムコンテキスト図

コンテナ図

コンポーネント図

データ

概念モデル

情報モデル

構築方法

前提条件

• CLI バージョン: Claude Code v2.1.154 以降が必須（research preview）
• プラン: 全有料プラン対応（Pro / Max / Team / Enterprise）。Anthropic API・Bedrock・Vertex AI・Foundry でも利用可能
• Pro の注意: デフォルト無効。/config を開き「Dynamic workflows」行から ON にします
• 推奨モデル: Opus 4.8（claude-opus-4-8）。ultracode（effort xhigh）はこのモデルで利用可能

無効化方法

# 方法1: 対話コマンド（永続）
/config            # → "Dynamic workflows" トグルを OFF

# 方法2: 設定ファイル（~/.claude/settings.json、永続）
#   { "disableWorkflows": true }

# 方法3: 環境変数（起動時に読まれる）
export CLAUDE_CODE_DISABLE_WORKFLOWS=1

組織単位では managed settings の { "disableWorkflows": true }、または admin settings ページのトグルで無効化します。無効化すると、バンドルワークフローコマンドが使用不可になり、workflow キーワードが非トリガーになり、/effort から ultracode が消えます。

設定パス

.claude/workflows/          # プロジェクト配下 → クローンした全員と共有
~/.claude/workflows/        # ホーム → 全プロジェクトで自分のみ利用可

同名が両方に存在する場合は プロジェクト側が優先 されます。保存したワークフローは /<name> として / autocomplete に表示されます。

保存・再利用手順

1. ワークフローを実行する
2. /workflows でラン一覧を開く
3. 保存したいランを選択し s を押す
4. Tab で保存先を切り替える（.claude/workflows/ ↔ ~/.claude/workflows/）
5. Enter で保存し、以降 /<name> として呼び出す

利用方法

3 つの起動方法

# 方法1: プロンプトに workflow の語を含める（その1タスクだけ workflow 化）
Run a workflow to audit every API endpoint under src/routes/ for missing auth checks
#   → 誤検知時は alt+w で無視

# 方法2: /effort ultracode（セッション全体で自動 workflow 計画）
/effort ultracode
#   → 通常作業に戻すなら /effort high

# 方法3: 保存済み bundled コマンドを直接実行
/deep-research What changed in the Node.js permission model between v20 and v22?

bundled ワークフロー /deep-research

現時点で公式 docs に掲載されているバンドルワークフローは /deep-research のみです（WebSearch tool が必要）。動作フローは次のとおりです。

1. 質問を複数角度に展開して Web 検索を fan-out
2. 各ソースを fetch しクロスチェック
3. 各 claim に投票
4. 生き残らなかった claim をフィルタ
5. 引用付きレポートを返す

オーケストレーションスクリプトの構造例

ワークフローの実体は Claude が生成する JavaScript スクリプトです。公式 docs に完全なコード例の掲載はないため、以下は公式の説明・制約から導出した構造例です。 agent() 等の関数名は説明用の仮称であり、実際の記法は Claude が生成するため変動します。

// 【例: fan-out パターン】src/routes/ 配下の全 API を並列監査
const routes = await agent("List all API endpoint files under src/routes/");
// → スクリプト変数に格納。Claude の context には入らない
const auditResults = await Promise.all(
  routes.files.map(file =>
    agent(`Audit ${file} for missing auth checks. Return { file, issues: [] }`)
  )
);
// 同時実行は最大 16 並列（CPU コアが少ない場合はより少ない）

// 【例: pipeline パターン】段階連鎖（前段出力をスクリプト変数経由で次段へ）
const lifetimeMap = await agent("Map correct Rust lifetimes for all Zig struct fields in src/");
const portResults = await Promise.all(
  lifetimeMap.structs.map(struct =>
    agent(`Port ${struct.file} from Zig to behavior-identical Rust. Lifetime map: ${JSON.stringify(struct.lifetimes)}`)
  )
);
const buildResult = await agent(`Run build and tests. Fix failures in: ${portResults.map(r => r.file).join(", ")}`);

// 【例: adversarial cross-check パターン】各 claim を別エージェントが反証
const findings = await Promise.all(
  angles.map(angle => agent(`Research: "${question}" from angle: ${angle}`))
);
const crossChecks = await Promise.all(
  findings.map(f => agent(`Try to refute this finding with counter-evidence: ${f.claim}`))
);
const survivedClaims = findings.filter((_, i) => !crossChecks[i].refuted);
const report = await agent(`Synthesize a cited report from these verified claims: ${JSON.stringify(survivedClaims)}`);

// 【例: worktree isolation】並列ファイル編集の衝突を回避
const results = await Promise.all(
  files.map(file => agent(`Refactor ${file}`, { isolation: "worktree" }))
  // → 各 subagent が個別の git checkout を持つ
);

公式が示すランタイムの limits は次のとおりです。

実行中の操作

/workflows    # ラン一覧 → 矢印キーで選択 → Enter で進捗ビュー

resume の挙動と制約

• 再開すると完了済みエージェントはキャッシュ結果を返し、残りだけライブ実行されます。完了済み作業は保持されます。
• 重要な制約: resume は 同一 Claude Code セッション内のみ 有効です。Claude Code を終了すると次セッションでは最初からやり直しになります。

運用

コスト管理: token budget で自分から止める設計

• 公式 docs は「dynamic workflows は通常セッションより meaningfully more usage を消費し、コストが急速に climb する」と認めています。
• 公式の 1,000 エージェント上限は runaway 防止の backstop であり運用上限ではありません。コスト管理はスクリプト内に組み込む必要があります。
  • maxTurns で各 subagent の最大 agentic turns を制限します。
  • phase ごとにスクリプトを分割し、各段階の完了を確認してから次を走らせます。
  • 大規模ラン前に /model を確認し、一部 stage を小さいモデルにルートして節約します。
• claude -p や Agent SDK は bypassPermissions 相当で承認ダイアログが出ません。unattended 実行ではコスト爆発への歯止めがなく、「このタスクをオーケストレーションするな」と止めるガバナンス層が欠けます。

2026-06-15 の Agent SDK 課金分離

• Anthropic ヘルプセンターによると、2026-06-15 から Agent SDK / claude -p / GitHub Actions 経由の使用量は 月次の Agent SDK クレジットから先に消費 されます。
• クレジット超過分は usage credits（標準 API レート）が適用されます（事前に usage credits の有効化が必要）。未使用クレジットの繰り越しは不可です。
• 課金倍率の試算（12x〜）は二次情報で正確な値はワークロード次第ですが、「独立コンテキストごとにフルにトークンを焼く」構造的コスト増は公式が認めています。

# コスト管理の最小チェックリスト
1. 小規模スコープ（単一ディレクトリ / 機能単位）から試す
2. ultracode はセッション全体に適用されるため選択的に使う
3. 長時間ランの前に tool allowlist を完備する（prompt 待ちでランが滞留し再開不能や無駄な再実行につながる）
4. unattended 実行は 2026-06-15 以降 Agent SDK クレジット消費に切り替わる

並列度設計: 16 / 1,000 上限の意味

• 16 並列を前提にした負荷設計が必要 です。fan-out 幅を 16 より広くしてもキューに詰まり、速度は変わらず token 消費だけ増えます。
• subagents 単体（workflow でない場合）には 16 / 1,000 の明示的上限は適用されません（workflow 固有の制約）。

acceptEdits を本番直結しない

• ワークフローが spawn する subagent は 常に acceptEdits モードで走り、ファイル編集を auto-approve します（session の permission mode に関わらず適用）。
• 推奨隔離パターンは、isolation: "worktree" で subagent ごとに個別 git worktree を割り当て、本番 main への直接適用ではなく feature / review ブランチへの PR として出す方法です。
• 非 git プロジェクトは worktree 分離が効きません。worktree 内 agent は main checkout の未コミット変更を参照できず環境認識を失うリスクがあります。

再開制約: 同一セッション内のみ

公式 docs は次のように述べます。

"Resume works within the same Claude Code session. If you exit Claude Code while a workflow is running, the next session starts the workflow fresh."

• 中断・再開は同一セッション内に限ります。background subagent が allowlist 外のコマンドや MCP ツールを使おうとすると、permission prompt でランが一時停止 します（auto-deny ではなく pause）。夜間の unattended ランが permission 待ちで止まり、セッションが途切れると再開不能になります。
• 対策は、ランの前に必要な全コマンドを allowlist に追加することです（/config や settings.json）。

責任境界の 4 層

ベストプラクティス

依頼文より「分割単位・レビュー観点・失敗時巻き戻し条件」を先に設計する

• 誤解: 自然言語で依頼すれば Claude が勝手に分割して並列化してくれる。
• 反証: 「dispatch problem（どこで分割し、何を parallel に、何を sequential に保つか）は未解決で、あなたの頭の中にある。アーキテクチャがその穴を埋めてくれない」（rundatarun.io）。worktree 分離があっても、各 subagent の schema と責務境界を事前に決めないと fabricated result を返します（Issue #29181）。
• 推奨: ランを承認する前に次を確認します。

ワークフロー設計チェックリスト
[ ] 分割単位: 各 subagent が担当する範囲は排他的か
[ ] schema: 各 subagent が返すべき structured output を定義したか
[ ] 依存関係: 段階間バリアが必要な箇所はどこか
[ ] レビュー観点: cross-check エージェントへの refute すべき軸を明示したか
[ ] 巻き戻し条件: どの段階で失敗したら全体を止めるか
[ ] allowlist: ランに必要な全ツール コマンドは事前追加済みか
[ ] worktree: git プロジェクトで isolation worktree を使うか確認

コスト上限・停止条件をワークフローに組み込む

• 誤解: 公式の 1,000 上限があるからコスト爆発は起きない。
• 反証: Anthropic 自身が「1,000 は runaway loop の backstop」であり運用上限ではないと認めています。claude -p や SDK ではユーザー確認なしで即実行されます。2026-06-15 以降は Agent SDK クレジットの先消費になり超過分は標準 API レートで請求されます。
• 推奨: スクリプト段階を分割し、各段階の完了を人間が確認してから次を走らせます。No mid-run user input 制約があるため、段階を別ワークフローとして逐次起動するのが公式推奨パターンです。unattended 実行では最大 agent 数をスクリプト変数で自前管理し、閾値超えで early exit します。

自己検証出力を「検証済み」と読まない

• 誤解: dynamic workflows は自己検証してから報告するので品質が担保されている。
• 反証: arXiv 2603.18740v2（査読前）は、コードを「bug-free」と framing するとバグ検出率が 16.2〜93.5pt 低下し false-negative bias が支配的になることを示します（Claude Opus 4.5 は非有意 -4.9pt）。adversarial 第 2 パスが同系統モデルなら同じ盲点を共有し同時に見逃します。「50 個の plausible bug を fan-out すると単一の慎重なパスより悪い。人間がノイズを triage させられる」（rundatarun.io）。
• 推奨: CI（外部テスト）を最終ゲートに必ず置きます。異なるモデル（Codex / Gemini 等）に並行レビューさせる adversarial review を CI に加えます。schema 定義から逸脱した出力は必ず reject する仕組みを入れます。

トラブルシューティング

GitHub Issue 実在事例

anthropics/claude-code リポジトリで存在を確認した 4 件です。

self-verification の限界

• 論文: "Measuring and Exploiting Contextual Bias in LLM-Assisted Security Code Review"（arXiv:2603.18740v2, submitted 2026-03-19 / revised 2026-04-23、査読前）
• 主な知見: コードを「バグフリー」と framing すると対象モデルのバグ検出率が 16.2〜93.5pt 低下します（false-negative bias 支配）。Claude Opus 4.5 は耐性があり低下は非有意（-4.9pt）でしたが、Opus 4.8 での結果は本論文の対象外で未確認です。
• 実務的含意: dynamic workflows の「findings を refute する adversarial 第 2 パス」が同一モデル群で構成される場合、構造的に同じ blind spot を持つリスクがあります。自己検証を通過した出力でも CI と人間レビューを省略できない根拠になります。

allowlist 漏れで夜間ラン停止

// 事前設定: ~/.claude/settings.json（または .claude/settings.json）
{
  "permissions": {
    "allow": [
      "Bash(git:*)",
      "Bash(npm:*)",
      "Bash(pytest:*)"
      // ... ランに必要な全コマンドを事前列挙
    ]
  }
}

発生後は /workflows で状態を確認し、停止中ランを x で終了し、allowlist 追加後に再実行します。権限不足で失敗した subagent は foreground で同タスクを再起動して interactive prompt で権限を付与します。

worktree 隔離の落とし穴

• 非 git プロジェクトでは worktree 分離が機能せず working-dir 衝突リスクが残ります。
• worktree 内 agent は main checkout の未コミット変更（.env・ローカル設定）を参照できません。必要な状態は事前に git commit し、worktree が参照するブランチに含めます。

まとめ

Claude Code の動的ワークフローは、プランを JavaScript スクリプトへ外出しして並列 subagent を background 実行し、中間結果を context から切り離すことで大規模作業のスケールを実現します。一方で、同時 16 / 累計 1,000 の上限・acceptEdits の自動編集・同一セッション内のみの resume・自己検証の構造的限界があり、便利機能ではなく「並列実行時の責任境界と検証設計」の問題として読むと、依頼文より先に分割単位・レビュー観点・コスト上限・失敗時巻き戻し条件を設計すべきだと分かります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント
  • Orchestrate subagents at scale with dynamic workflows
  • Run agents in parallel
  • Create custom subagents
  • Manage costs
  • Introducing Claude Opus 4.8
  • Introducing dynamic workflows in Claude Code
  • Models overview
  • Model deprecations
  • Use the Claude Agent SDK with your Claude plan
• GitHub
  • anthropics/claude-code Issues
• 記事
  • Measuring and Exploiting Contextual Bias in LLM-Assisted Security Code Review (arXiv:2603.18740)
  • rundatarun.io