Claude Code Dynamic Workflowsとは？6パターンを実務タスクに落とし込む

この記事でわかること

• Claude Code Dynamic Workflowsの基本的な仕組み
• 通常のClaude Code、サブエージェント、Skills、Agent Teamsとの違い
• 実務に落とし込みやすい6つのワークフローパターン
• 14ステップで小さく始める導入手順
• 失敗しやすいタスク分割と運用上の注意点
• AnchorSpec的な「役割・入力・出力・承認」の設計との接続
• FAQと公開前に確認すべき公式情報

先に結論：Dynamic Workflowsは「大きな仕事を小さく分け、検証しながら進める」ための仕組み

Claude Code Dynamic Workflowsとは、Claude Codeがタスクに応じてワークフロースクリプトを生成し、そのスクリプトが複数のサブエージェントを並列に動かして、調査・実装・検証・統合を進める機能です。Anthropic公式ブログでは、Dynamic Workflowsが数十から数百の並列サブエージェントを1つのセッション内で実行し、結果を確認してからユーザーに返すと説明されています。([Claude][2])

読者が最初に確認すべき判断軸は、「そのタスクは1人のClaudeとの対話で十分か、それとも分割・並列化・検証が必要か」です。単純なバグ修正、1ファイルのリファクタリング、短い調査であれば通常のClaude Codeやサブエージェントで十分です。一方、数十〜数百ファイルにまたがる調査、全体監査、移行、複数観点のレビュー、広範囲のリサーチではDynamic Workflowsを検討する価値があります。

導入・調査に進むべきケースは、次のような場合です。

ただし、Dynamic Workflowsは万能ではありません。Anthropic公式ドキュメントは、ワークフローが多くのエージェントを生成するため通常の会話より大きなトークンを消費し得ること、まず小さな範囲で試すべきことを明記しています。([Claude][1])

Dynamic Workflowsの概要

Claude Code Dynamic Workflowsを一言でいうと、「Claudeが作る一時的なオーケストレーションスクリプト」です。

通常のClaude Codeでは、ユーザーが依頼し、Claudeが次に何をするかを会話の流れの中で判断します。サブエージェントを使う場合も、基本的にはClaudeが必要に応じて別の作業者を呼び出します。一方、Dynamic Workflowsでは、計画、分岐、ループ、並列実行、検証の段取りをスクリプトに移します。Anthropic公式ドキュメントでは、この違いを「Subagents、Skills、Agent teams、Workflowsの違い」として整理し、Workflowsは「スクリプトが実行するもの」「次に何をするかはスクリプトが決めるもの」と説明しています。([Claude][1])

### 通常のClaude Codeとの違い

### サブエージェントとの違い

Claude Codeのサブエージェントは、特定のタスクを別のコンテキストで処理する専門作業者です。公式ドキュメントでは、サブエージェントは探索・実装をメイン会話から分離し、コンテキスト節約、制約の強制、再利用、専門化、より安価なモデルへのルーティングに役立つと説明されています。([Claude Platform Docs][3])

Dynamic Workflowsは、そのサブエージェントを大量に、段取り付きで動かす仕組みです。つまり、サブエージェントは「作業者」、Dynamic Workflowは「作業者を束ねる進行台本」と考えるとわかりやすいです。

### ultracodeとは

Dynamic Workflowsは、ユーザーが「workflowを使って」「ultracodeで」などと明示して起動する方法と、`/effort ultracode`を設定してClaudeに判断させる方法があります。公式ドキュメントでは、ultracodeは`xhigh`の推論努力と自動ワークフローオーケストレーションを組み合わせる設定だと説明されています。([Claude][1])

ただし、ultracodeを常時オンにすると、通常作業まで大きなワークフロー化され、トークン消費と実行時間が増える可能性があります。日常的な軽い修正では、必要なときだけ明示的に使う方が現実的です。

6つのワークフローパターン

ここでは、実務で使いやすい形に6パターンへ整理します。

### パターン1：コードベース全体監査ワークフロー

対象は、認証漏れ、入力検証不足、未使用コード、危険なAPI利用、古い依存関係、エラーハンドリング漏れなどです。Anthropic公式ブログでも、コードベース全体のバグ探索、プロファイラに基づく最適化監査、セキュリティ監査がDynamic Workflowsのユースケースとして挙げられています。([Claude][2])

実務タスク例:

向いている業務:

注意点は、いきなり修正させないことです。まず「調査のみ」「ファイル変更禁止」「影響度分類」「根拠ファイル明示」に絞ると、レビューしやすくなります。

### パターン2：大規模マイグレーションワークフロー

フレームワーク移行、API廃止対応、言語移植、ディレクトリ構成変更、型定義更新などに使います。Anthropic公式ブログでは、Dynamic Workflowsがフレームワーク変更、API非推奨対応、数千ファイルにまたがる言語移植のような大規模モダナイズに使えると紹介しています。([Claude][2])

実務タスク例:

向いている業務:

重要なのは、移行対象を一括ではなく段階に分けることです。Dynamic Workflowsは大きな作業に向いていますが、承認ポイントなしで全自動修正させると差分が大きくなり、レビュー不能になります。

### パターン3：複数観点レビュー・反証ワークフロー

Dynamic Workflowsの強みは、複数のエージェントに独立した観点から検証させられることです。公式ドキュメントでも、ワークフローは独立したエージェントに互いの発見を敵対的にレビューさせるなど、単なる並列処理以上の品質パターンを適用できると説明しています。([Claude][1])

実務タスク例:

向いている業務:

これは開発だけでなく、EC運用にも応用できます。たとえば商品登録ルール、広告文、FAQ、返品ポリシーを「法務表現」「SEO」「CS対応」「ブランドトーン」「運用負荷」の観点で別々にレビューさせる形です。

### パターン4：Deep Research・調査統合ワークフロー

Claude Codeには `/deep-research` という組み込みワークフローがあります。公式ドキュメントでは、複数の角度からWeb検索を展開し、情報源を取得・クロスチェックし、根拠付きレポートを統合すると説明されています。([Claude][1])

実務タスク例:

向いている業務:

注意点は、調査結果をそのまま最終記事や意思決定に使わないことです。Dynamic Workflowsはクロスチェックを助けますが、料金・規約・法律・医療・金融などの変動情報は、最終的に公式ページを人間が確認する必要があります。

### パターン5：テスト・ビルド・修正ループワークフロー

大規模変更では、実装後のテスト失敗を修正するループが重要です。Dynamic Workflowsでは、調査、実装、テスト、失敗原因の特定、再修正を段階化できます。

実務タスク例:

向いている業務:

ただし、失敗ログを読ませるだけでなく、「どのコマンドを実行してよいか」「どのファイルは触らないか」「修正は最小差分にするか」を明示する必要があります。

### パターン6：運用・ドキュメント整備ワークフロー

Dynamic Workflowsはコード変更だけでなく、ドキュメント整備、仕様書更新、運用手順書、README改善にも使えます。Claude Codeの一般的なワークフローには、コードベース探索、バグ修正、リファクタリング、テスト、PR作成、ドキュメント作業などが含まれます。([Claude][4])

実務タスク例:

向いている業務:

これはWeb/EC運用者にも相性が良いパターンです。コードだけでなく、CSVテンプレート、運用ルール、記事作成ルール、問い合わせ対応テンプレートなどを「実装や現場ルールとズレていないか」確認できます。

ultracode: src/routes 配下のAPIエンドポイントをすべて確認し、認証チェック漏れ、入力検証不足、エラーハンドリング不足を洗い出してください。変更はまだ加えず、影響度・根拠ファイル・修正方針だけを表で返してください。

ultracode: pages ディレクトリ配下の旧API呼び出しを調査し、新しい client 関数へ移行する計画を作ってください。まず影響範囲、変更順序、テスト方針を出し、実装は承認後に進めてください。

ultracode: このPRを、セキュリティ、パフォーマンス、保守性、テスト不足、仕様逸脱の5観点で独立レビューしてください。各観点の指摘を別エージェントで出し、最後に重複を統合して、修正優先度順にまとめてください。

/deep-research Claude Code Dynamic Workflows の公式仕様、制約、料金面の注意点、国内実践記事を調べ、実務導入判断に必要な論点を整理してください。

ultracode: feature/account-settings の変更について、関連テストを洗い出し、失敗しているテストを原因別に分類し、最小差分で修正してください。各修正後に該当テストを再実行し、変更理由を記録してください。

ultracode: docs と README、src 配下の実装を照合し、古くなっている手順、存在しない環境変数、実装とズレた説明を洗い出してください。修正案を出し、承認後にドキュメントだけ更新してください。

14ステップを実務に置き換える

ここでは、Dynamic Workflowsをいきなり本番導入せず、小さく始めるための14ステップに落とし込みます。

### Step 1. 対象タスクを1つに絞る

最初から「全部見て」「全部直して」は避けます。たとえば、`src/routes`だけ、`components/forms`だけ、`docs`だけ、特定PRだけに絞ります。

### Step 2. 成果物を決める

「調査レポート」「修正PR」「差分一覧」「リスク表」「テスト結果」など、出力を明確にします。

### Step 3. 変更可否を分ける

最初は「変更禁止・調査のみ」が安全です。変更する場合も、承認後に進める設計にします。

### Step 4. 対象外を明記する

触ってはいけないディレクトリ、生成ファイル、環境ファイル、認証情報、マイグレーションファイルを指定します。

### Step 5. 判断軸を3〜5個に絞る

セキュリティ、保守性、テスト、パフォーマンス、仕様整合など、観点を絞ります。多すぎると出力がぼやけます。

### Step 6. ワークフロー化すべきか判断する

1ファイル修正なら通常のClaude Codeで十分です。多数ファイル、並列調査、クロスチェック、再実行性がある場合にDynamic Workflowsを使います。

### Step 7. 小さな範囲で試す

Anthropic公式ドキュメントも、大きなタスクに入る前に、1ディレクトリや狭い質問から始めて使用量を確認することを推奨しています。([Claude][1])

### Step 8. 実行前に計画を確認する

Claude Codeでは、ワークフロー実行前に計画フェーズやスクリプト確認の選択肢が表示されます。公式ドキュメントでは、CLI上で「実行」「今後同じワークフローを確認なしで実行」「生スクリプトを見る」「キャンセル」といった選択肢があると説明されています。([Claude][1])

### Step 9. `/workflows`で進捗を見る

Dynamic Workflowsはバックグラウンドで動作し、`/workflows`からフェーズ、エージェント数、トークン数、経過時間を確認できます。公式ドキュメントでは、各フェーズやエージェントの詳細、最近のツール呼び出し、結果を掘り下げられると説明されています。([Claude][1])

### Step 10. 途中停止できる前提で見る

大きなワークフローは、途中で止める判断も必要です。進捗画面では停止・再開・エージェント再起動などの操作が可能です。([Claude][1])

### Step 11. 結果を人間がレビューする

Dynamic Workflowsは複数エージェントで検証できますが、最終判断は人間が行うべきです。特にセキュリティ、顧客情報、請求、注文、法務表現、医療・金融関連は自動適用を避けます。

### Step 12. 成功したら保存する

繰り返す価値があるワークフローは、`.claude/workflows/`または`~/.claude/workflows/`に保存できます。公式ドキュメントでは、保存したワークフローは将来のセッションで`/<name>`として実行できると説明されています。([Claude][1])

### Step 13. 引数化する

保存したワークフローは`args`で入力を受け取れます。対象パス、Issue番号、調査テーマなどを実行時に渡せるようにすると、再利用性が上がります。([Claude][1])

### Step 14. チームルールに落とし込む

どのタスクで使うか、どの権限で使うか、費用上限、レビュー必須範囲、保存場所、ログの扱いを決めます。組織ではDynamic Workflowsを無効化する管理設定も用意されています。([Claude][1])

失敗しやすいタスク分割

Dynamic Workflowsで失敗しやすいのは、機能の問題というより「タスクの渡し方」の問題です。

### 失敗1. 目的が広すぎる

悪い例:

改善例:

### 失敗2. 調査と修正を同時に頼む

最初から調査・修正・テスト・PRまで一気に任せると、差分が大きくなりすぎます。まず調査、次に小さな修正、最後にテストの順に分けます。

### 失敗3. 承認ポイントがない

大規模修正では、調査後、設計後、実装前、PR前に承認ポイントを作るべきです。公式ドキュメントでも、ワークフロー実行前に計画確認やスクリプト確認ができることが説明されています。([Claude][1])

### 失敗4. 触ってはいけない範囲を指定しない

環境変数、シークレット、マイグレーション、生成ファイル、ロックファイル、課金処理、顧客情報関連は、必要に応じて明示的に対象外にします。

### 失敗5. 検証条件が曖昧

「ちゃんと確認して」ではなく、実行してよいコマンド、成功条件、テスト対象、出力形式を指定します。

### 失敗6. トークン使用量を見ない

Dynamic Workflowsは通常会話より多くのトークンを使う可能性があります。`/workflows`の進捗ビューでトークン数を見ながら、小さな範囲から始めるべきです。([Claude][1])

このリポジトリを全部改善して

ultracode: src/routes 配下のAPIについて、認証チェック漏れだけを調査してください。変更はせず、ファイル、関数、リスク、修正方針を表で返してください。

AnchorSpecとの接続

AnchorSpecは、AIと人間、または複数AIの協調において、役割、入力、出力、制約、承認、検証を明確にする発想と相性が良いテーマです。Dynamic Workflowsも、まさに「AIが複数作業者に分かれて動く」ため、曖昧な依頼ではなく、作業のアンカーを置くことが重要になります。

Dynamic Workflows向けにAnchorSpec的に整理するなら、次のような項目を事前に決めます。

たとえば、コードベース監査では次のように書けます。

このように書くと、Dynamic Workflowsは単なる「強いAI」ではなく、実務プロセスの一部として扱いやすくなります。AnchorSpec関連記事 `/ainews/article/anchorspec-ai-collaboration-protocol/` では、AI協調プロトコルとしての考え方を別角度から整理しています。

ultracode: 以下の条件でDynamic Workflowを作成してください。

目的:
- src/routes 配下の認証チェック漏れを調査する

対象:
- src/routes/**/*.ts
- src/middleware/**/*.ts

対象外:
- DBマイグレーション
- .env
- package-lock.json
- 本番設定ファイル

役割:
- 調査エージェント
- 反証エージェント
- 影響度分類エージェント
- 最終統合エージェント

出力:
- ファイル
- 関数名
- 問題内容
- 根拠
- 影響度
- 修正方針

制約:
- ファイル変更は禁止
- 実行してよいコマンドは grep、rg、npm test のみ
- 推測は推測として明記

導入チェックリスト

### 技術面

### セキュリティ・運用面

### 費用・品質面

• [ ] Claude Codeのバージョン要件を確認した
• [ ] Dynamic Workflowsが有効なプラン・環境か確認した
• [ ] `/config`で有効化状況を確認した
• [ ] 使うモデルと使用量制限を確認した
• [ ] `/workflows`で進捗・トークン数を確認できる
• [ ] 保存先 `.claude/workflows/` と `~/.claude/workflows/` の使い分けを決めた
• [ ] チーム共有するワークフローと個人用ワークフローを分けた
• [ ] 触ってよいディレクトリを限定した
• [ ] 触ってはいけないファイルを明記した
• [ ] 実行してよいコマンドを決めた
• [ ] MCPツールや外部接続の許可範囲を確認した
• [ ] シークレットや個人情報を入力しないルールを決めた
• [ ] 自動編集・自動実行の範囲を制限した
• [ ] 人間レビュー必須のタスクを決めた
• [ ] 最初は小さなディレクトリで試した
• [ ] トークン使用量を記録した
• [ ] 実行時間を記録した
• [ ] 指摘の正確性を人間が評価した
• [ ] 誤検出・見逃しを記録した
• [ ] 再利用できるワークフローだけ保存した
• [ ] 高コストになりやすいタスクを明確にした

FAQ

### Q1. Claude Code Dynamic Workflowsとは何ですか？

Claude Codeがタスクに応じてJavaScriptのワークフロースクリプトを作り、そのスクリプトが複数のサブエージェントを動かして大きな作業を進める仕組みです。コードベース監査、大規模移行、クロスチェック付き調査など、1つの会話だけでは扱いにくいタスクに向いています。([Claude][1])

### Q2. 通常のClaude Codeと何が違いますか？

通常のClaude Codeは会話のターンごとにClaudeが次の作業を判断します。Dynamic Workflowsでは、計画、分岐、ループ、並列実行をスクリプト側に移し、中間結果もスクリプト側で扱います。そのため、大規模・並列・再実行可能な作業に向いています。([Claude][1])

### Q3. どんなタスクで使うべきですか？

コードベース全体の監査、大規模マイグレーション、セキュリティレビュー、複数観点のPRレビュー、Deep Research、テスト修正ループ、ドキュメント整備などです。逆に、1ファイルの軽い修正や短い質問では通常のClaude Codeで十分です。

### Q4. 6つのパターンは公式分類ですか？

この記事の6パターンは、Anthropic公式の固定分類ではありません。公式ブログ・公式ドキュメント・国内実践記事をもとに、実務で判断しやすいように「監査」「移行」「複数観点レビュー」「Deep Research」「テスト修正ループ」「運用ドキュメント整備」に再整理したものです。

### Q5. ultracodeは常にオンにすべきですか？

常にオンにする必要はありません。ultracodeは高い推論努力と自動ワークフロー判断を組み合わせる設定で、通常作業よりトークンと時間を使いやすくなります。大きなタスクだけ明示的に使う方が、費用と制御の面で安全です。([Claude][1])

### Q6. Dynamic Workflowsは費用が高くなりますか？

高くなる可能性があります。Dynamic Workflowsは多数のエージェントを生成するため、通常のClaude Code会話より多くのトークンを使う場合があります。公式ドキュメントでも、小さな範囲で試してから大きなタスクに広げることが推奨されています。([Claude][1])

### Q7. ワークフローは保存できますか？

保存できます。公式ドキュメントでは、繰り返し使うワークフローをプロジェクトの `.claude/workflows/` または個人用の `~/.claude/workflows/` に保存でき、将来のセッションでコマンドとして実行できると説明されています。([Claude][1])

### Q8. 途中で止められますか？

`/workflows`から進捗を確認し、停止・再開・エージェントの再起動などができます。ただし、セッションを終了した場合の再開挙動には制約があるため、長時間実行では公式ドキュメントの制限を確認してください。([Claude][1])

### Q9. Web/EC運用者にも関係ありますか？

関係あります。コード開発だけでなく、商品CSVテンプレート、FAQ、運用マニュアル、サイト構成、記事群、内部リンク、広告文、問い合わせテンプレートなどを広く点検する用途に応用できます。ただし、顧客情報や注文情報を扱う場合は、入力データのマスキングと組織内ルールが必要です。

### Q10. 導入前に何を確認すべきですか？

公式ドキュメントでバージョン要件、対応プラン、利用可能な環境、制約、使用量、管理設定を確認してください。また、実務では「対象範囲」「変更可否」「実行コマンド」「承認ポイント」「費用上限」「レビュー担当」を決めてから使うべきです。

まとめ：Dynamic Workflowsは「大きな仕事を任せる前の設計」が重要

Claude Code Dynamic Workflowsは、単にClaude Codeを強くする機能ではありません。大きなタスクを分割し、複数のサブエージェントで並列に進め、検証して統合するための実務機能です。

ただし、効果を出すには、次の設計が必要です。

1. 対象範囲を絞る

2. 成果物を決める

3. 変更可否を分ける

4. 触ってはいけない範囲を明記する

5. 判断軸を絞る

6. 小さな範囲で試す

7. `/workflows`で使用量と進捗を見る

8. 人間レビューを残す

9. 成功したワークフローだけ保存する

10. チームルールに落とし込む

Dynamic Workflowsは、複雑な開発・調査・レビューを加速する可能性があります。一方で、タスク設計が曖昧なまま使うと、差分が大きくなりすぎたり、費用が増えたり、レビューできない結果になったりします。

まずは、1ディレクトリ、1観点、調査のみから始めるのが現実的です。そのうえで、監査、移行、複数観点レビュー、Deep Research、テスト修正ループ、ドキュメント整備へ広げていくと、Claude Code Dynamic Workflowsを「実務で使えるワークフロー」として育てやすくなります。

関連するAIサービスの比較や、AI協調設計に関する記事も、必要に応じて参照してください。

参考リンク一覧

[https://code.claude.com/docs/en/workflows](https://code.claude.com/docs/en/workflows)

[https://claude.com/blog/introducing-dynamic-workflows-in-claude-code](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)

[https://code.claude.com/docs/en/common-workflows](https://code.claude.com/docs/en/common-workflows)

[https://code.claude.com/docs/en/sub-agents](https://code.claude.com/docs/en/sub-agents)

[https://code.claude.com/docs/en/hooks-guide](https://code.claude.com/docs/en/hooks-guide)

[https://www.anthropic.com/engineering/building-effective-agents](https://www.anthropic.com/engineering/building-effective-agents)

[https://zenn.dev/aria3/articles/claude-code-dynamic-workflows-6-patterns](https://zenn.dev/aria3/articles/claude-code-dynamic-workflows-6-patterns)

[https://zenn.dev/yamk/articles/claude-code-dynamic-workflows-prompt](https://zenn.dev/yamk/articles/claude-code-dynamic-workflows-prompt)

[https://qiita.com/kai_kou/items/fe9b0e65e2252af773c9](https://qiita.com/kai_kou/items/fe9b0e65e2252af773c9)

• Anthropic: Orchestrate subagents at scale with dynamic workflows
• Anthropic: Introducing dynamic workflows in Claude Code
• Anthropic: Common workflows
• Anthropic: Create custom subagents
• Anthropic: Automate actions with hooks
• Anthropic: Building effective agents
• Zenn: Claude Code「Dynamic Workflows」完全ガイド：6つのパターンと14ステップ
• Zenn: Claude CodeのDynamic Workflowsからエージェントの作業を覗いてみる
• Qiita: Claude Code Dynamic Workflows入門