Claude Code動的ワークフロー解説｜最大1,000並列の衝撃【2026】

「Claude Codeに大きな調査を頼んだら、途中で文脈が溢れて答えが薄くなった」——こういう経験、ありませんか。

2026年5月28日、AnthropicがClaude Opus 4.8と同時に投入してきたのが「Dynamic Workflows（動的ワークフロー）」です。ひとことで言うと、「1回のパスでは単一エージェントには大きすぎる問題」をClaude自身がオーケストレーションスクリプトに落とし込み、数十から数百のサブエージェントを並列で走らせて解く仕組みです。しかもユーザーに結果が届く前に、エージェント同士がお互いの結論を検証し合う。正直、これは「並列実行を速くした」程度の話ではなく、AIへの仕事の任せ方そのものが一段変わる更新だと感じています。

とはいえ、研究プレビュー段階で派手な数字（「最大1,000体」「11日間で75万行」）が独り歩きしている面もあります。実際には「同時に1,000体が動く」わけではないし、トークン消費という現実的なコストの壁もある。100社以上のAI研修・導入支援をやってきた立場から見ると、ここで冷静に「どこに効いて、どこで詰まるのか」を整理しておく価値は高いです。

この記事では、動的ワークフローのファクトを一次情報で確認しつつ、賛否両論・日本企業への影響・中小企業がとるべきアクション・コピペで試せる起動例まで、まるごと解説します。AIエージェントの基本概念や全体像についてはAIエージェント導入完全ガイドで体系的にまとめているので、あわせてどうぞ。

何が起きたのか — ファクトの全体像

まず、確認できた事実を時系列と仕様で整理します。数字には割れがあるので、後述の「賛否両論」で扱い方も書きます。

核心は「計画をコードに移す」という発想です。これまでのサブエージェントやスキルでは、次に何を動かすかをClaudeが「会話のターンごとに」決めていて、すべての中間結果がClaudeの文脈ウィンドウに乗っていました。動的ワークフローでは、ループや分岐、中間結果をスクリプト変数の側が持つため、Claudeの文脈には最終的な答えだけが残ります。大規模タスクで文脈が溢れて品質が落ちる問題への、構造的な解になっているわけです。

実務目線で一番効くのはここです。「500ファイルの移行」「全エンドポイントの認証チェック漏れ監査」のように、1会話の文脈には収まらないが、分割すれば並列で潰せるタスク。こういう作業はこれまで人間が手で分割していました。その分割と統合を、再実行可能なスクリプトとして残せるのが大きい。

なぜ今このタイミングなのか — 技術的・業界的な意味

「並列でサブエージェントを動かす」だけなら、Claude Codeには以前から仕組みがありました。では、なぜ2026年5月末にあらためて「動的ワークフロー」という形で打ち出してきたのか。背景を読み解くと、3つの流れが合流しています。

1. モデルが賢くなり、扱える問題が大きくなった：Opus 4.8のような高性能モデルは、数十万行規模の移行といった「コードベース規模」のタスクを、キックオフからマージまで通しでこなせるようになってきた。すると今度は、1つの会話の文脈ウィンドウが律速になる。文脈の限界をどう超えるか、が次の課題になったわけです
2. 「文脈に乗せない」という発想の転換：従来は中間結果をすべてClaudeの文脈に積み上げていました。動的ワークフローは中間結果をスクリプト変数に逃がし、文脈には最終答えだけを残す。文脈ウィンドウをスケールの天井にしないという、アーキテクチャ上の素直な解です
3. 品質を「数」ではなく「仕組み」で担保する：エージェントを増やすだけでは品質は上がりません。むしろノイズが増える。そこに反証検証・クロスチェックという品質パターンをスクリプトとして組み込むことで、「多数のエージェント＝より信頼できる結果」を成立させようとしている

業界的には、これは「エージェントを1体ずつ賢くする」競争から「多数のエージェントをどう束ねるか」というオーケストレーション競争へのシフトを象徴しています。OpenAIのAgents SDKなど、各社が似た方向を模索していますが、品質パターンをデフォルトで内蔵してきたのは現時点でのClaude Codeの特徴です。

反証検証とは何か — 「論破を生き延びた主張」だけが届く

動的ワークフローを単なる「並列の数を増やしただけ」と区別しているのが、この反証検証（adversarial verification）です。公式ドキュメントの記述を要約すると、こうなります。

• あるサブエージェントが「この関数に競合状態（race condition）がある」と主張する
• 別のサブエージェントが、その主張を論破しにかかる役を担う
• 論破を生き延びた主張だけが、ユーザーに報告される
• 同梱の /deep-research では、ソース同士をクロスチェックし、各主張に投票して、クロスチェックを生き延びなかった主張はフィルタで落とされる

「1回のパスより信頼できる結果が得られる」とAnthropicが言っているのは、この品質パターンをスクリプトとして繰り返し適用できるからです。研修現場でAIの出力を扱うとき、私がいつも言うのは「AIの一発回答を鵜呑みにするな」。動的ワークフローは、その「鵜呑み防止」を機械側で内蔵してきた、という見方ができます。

ただし注意。反証検証は「絶対に正しい答えが出る装置」ではありません。収束した＝正解、ではない。複数エージェントが同じ前提で間違える可能性は残ります。最終確認は人間が必要、という原則は変わらない、ということは強調しておきます。

「サブエージェント」「スキル」との違い — どれを使うべきか

Claude Codeにはマルチステップ作業を回す手段が3つあります。動的ワークフローはその「上位概念」というより、用途が違う第3の選択肢と捉えるのが正確です。公式の比較表を実務向けに整理しました。

使い分けの目安はシンプルです。「1つの会話で調整しきれる量」を超えたとき、あるいはオーケストレーションをコードとして残して読み返し・再実行したいときに動的ワークフローを選びます。それ未満なら従来のサブエージェントで十分。Claude CodeのSubagentそのものの基礎はClaude Code法人導入ガイドでも触れているので、社内展開を考えている方は先にそちらを押さえると理解が早いです。

コピペで試せる起動例 — 3パターン

「で、結局どうやって動かすの？」という声に応えて、実際に使える起動例を3つ。いずれもClaude Code v2.1.154以降が前提です。CLIにそのまま貼って試せます。

例1：標準ワークフロー /deep-research でクロスチェック調査

一番手軽なのは同梱の /deep-research。複数の角度からWeb検索を広げ、見つけたソースを突き合わせ、引用付きレポートを返します。WebSearchツールが有効である必要があります。

/deep-research 競合3社（A社・B社・C社）の生成AI関連プレスリリースを2026年に絞って洗い出し、
発表ごとに「自社サービスへの影響度（高・中・低）」を付けて、根拠URL付きでレポートしてください。
不足している情報があれば、最初に質問してから作業を開始してください。
数字と固有名詞は、根拠（出典URL）を必ず添えてください。

例2：プロンプトに workflow を入れて単発タスクをワークフロー化

セッション全体の設定を変えずに、その1タスクだけワークフローとして走らせたいときは、プロンプトのどこかに workflow という単語を入れます。Claude Codeがその語をハイライトし、スクリプトを書いてくれます。

Run a workflow to audit every API endpoint under src/routes/ for missing auth checks.
（src/routes/ 配下の全APIエンドポイントを対象に、認証チェック漏れを監査するワークフローを実行してください）

各エンドポイントについて「認証あり／なし／要確認」を判定し、要確認のものはファイルパスと行番号を提示してください。
仮定した点は必ず「仮定」と明記してください。

例3：/effort ultracode で自動オーケストレーション

セッション中の重めのタスクを、Claudeの判断で都度ワークフロー化させたいときは ultracode を有効化します。xhigh の推論努力と自動ワークフロー化を組み合わせた設定で、1リクエストが「理解→変更→検証」の複数ワークフローに分かれることもあります。当然、トークンと時間は増えます。

/effort ultracode

レガシーな日付処理ユーティリティ（src/utils/date/ 配下）を、
タイムゾーン安全な実装に移行してください。既存テストを壊さないことを成功基準とし、
移行後にテストスイートを再実行して結果を報告してください。

# ルーチン作業に戻すときは /effort high で元に戻す

運用の注意：動的ワークフローが生成したサブエージェントは、セッションのモードに関わらず常に acceptEdits モードで動き、ファイル編集は自動承認されます。長時間ランで途中の許可プロンプトを避けたいなら、エージェントが必要とするコマンドを事前に許可リスト（allowlist）へ入れておくこと。これを知らずに走らせると、深夜バッチが許可待ちで止まっていた、という事故が起きます（事例区分：想定シナリオ）。

ランの「見える化」と保存・再利用 — ここが運用の肝

動的ワークフローが「黒箱で勝手に走る怖い機能」にならない理由は、ランの進行を細かく観察でき、うまくいった段取りをそのまま資産化できるからです。ここは導入の意思決定に直結するので、少し丁寧に説明します。

進行をリアルタイムで覗く

ワークフローはバックグラウンドで走るので、セッションは応答可能なまま。/workflows を実行すると、実行中・完了済みのワークフロー一覧が出て、選ぶと進行ビューが開きます。

/workflows

# 進行ビューの操作（フッターに表示される）
#   ↑ / ↓     フェーズ or エージェントを選択
#   Enter / → 選択したフェーズに入り、さらにエージェントの
#             プロンプト・直近のツール呼び出し・結果を読む
#   p         ランの一時停止 / 再開
#   x         選択エージェントを停止（ランにフォーカス時は全体停止）
#   r         停止中のエージェントを再起動
#   s         このランのスクリプトをコマンドとして保存

進行ビューには各フェーズのエージェント数・トークン総量・経過時間が出ます。これが地味に効く。「いま何体動いていて、トークンをいくら食っているか」が見えるので、暴走の兆候を早期に掴めます。研修で「AIに任せると何が起きているか分からなくて怖い」という声をよく聞きますが、この可視化はその不安にかなり効きます。

うまくいったランを「自社コマンド」として保存する

動的ワークフローの真価は、一度成功した段取りをコマンドとして保存し、毎回同じオーケストレーションを走らせられる点にあります。/workflows で対象ランを選び、s を押すと保存ダイアログが出ます。

保存すると、以後 /<名前> でコマンドとして呼び出せ、/ のオートコンプリートにも標準ワークフローと並んで出てきます。プロジェクト版と個人版が同名なら、プロジェクト版が優先されます。属人化していたレビュー手順を、チーム共有のコマンドに昇華できる——これは中小の開発チームにとって地味に大きい価値です。

顧問先（事例区分：想定シナリオ）でよくあるのが「ベテランしかできない監査手順」の属人化。動的ワークフローでその手順を一度スクリプト化して保存すれば、ジュニアでも /<名前> 一発で同じ品質の監査が回せる。ナレッジの形式知化として、かなり筋がいい使い方だと思います。

動的ワークフローが向くタスク・向かないタスク

「とりあえず全部ワークフローで」は確実に失敗します（しかもトークンを浪費します）。向き不向きを整理しておきましょう。

ポイントは「広く・突き合わせて精度を上げる」性質のタスクに効くということ。逆に、対話しながら方向を探る作業や、途中で人間が判断を挟む作業は、従来のサブエージェントや通常の会話のほうが向いています。ランの途中ではユーザー入力を差し込めない（許可プロンプトでの一時停止のみ）という制約も、この向き不向きを決めています。

【要注意】導入でつまずく失敗パターン

研究プレビューの新機能だからこそ、初手で踏みやすい地雷があります。代表的な3つを挙げます。

失敗1：本番リポジトリにいきなり走らせる

❌ いきなり本番のメインブランチで「全ファイルをリファクタするワークフロー」を実行する
⭕ 検証用ブランチ or サンドボックスで試し、差分を人間がレビューしてからマージする

なぜ重要か：ワークフローのサブエージェントは acceptEdits モードで動き、ファイル編集が自動承認されます。意図しない大量変更が一気に入るリスクがあるため、最初の数回は必ず隔離環境で。

失敗2：トークンコストを試算せずに ultracode を常用する

❌ 「賢くなるらしいから」と /effort ultracode を常時オンにする
⭕ まず /deep-research の限定タスクで消費感を掴み、重い用途にだけ段階的に広げる

なぜ重要か：ultracode はセッション中の各タスクを都度ワークフロー化するため、1リクエストが複数ワークフローに分かれ、トークンと時間が大きく増えます。ルーチン作業に戻すときは /effort high で必ず戻すこと。

失敗3：許可リストを設計せずに長時間ランを始める

❌ シェルコマンドやMCPツールを許可リストに入れないまま、夜間に大規模ランを仕掛ける
⭕ エージェントが必要とするコマンドを事前に許可リスト（allowlist）へ登録してから走らせる

なぜ重要か：許可リストにないシェルコマンド・Web取得・MCPツールはラン中に許可を求めてくることがあります。これを放置すると、ランが許可待ちで止まったまま朝を迎える、という事故になります。

賛否両論 — 楽観論と慎重論

新機能はだいたい「神機能だ」と「過大評価だ」の間で揺れます。動的ワークフローもそう。両論をフェアに並べます。

楽観論：大規模作業の「壁」が下がる

• 文脈溢れ問題の構造的解決：中間結果をスクリプト側に持たせるので、500ファイル移行のような「会話に収まらない作業」が現実的に回せる
• 品質パターンの内蔵：反証検証・クロスチェックがデフォルトで入る。人間が後追いでレビューする工数を減らせる可能性
• 再現性：うまくいったオーケストレーションをコマンドとして保存（.claude/workflows/ または ~/.claude/workflows/）でき、毎ブランチのレビューなどに使い回せる
• 象徴的事例：あるBun（JavaScriptランタイム）の書き換えで、Rust 75万行を「最初のコミットからマージまで11日」、既存テストスイートの99.8%をパスし続けたと報告されている

慎重論：コスト・誇張・適用範囲

• トークン消費が大幅増：公式自身が「典型的なセッションよりかなり多くのトークンを消費しうる」と明記。プランの利用上限・レート制限にもカウントされる
• 数字の独り歩き：「最大1,000並列」という報道があるが、正確には同時実行は最大16体・1ランの総数が最大1,000体。公式ブログの表現も「数十〜数百（tens to hundreds）」。1,000は暴走防止の上限値であって、常時1,000体が動くわけではない
• 研究プレビュー：仕様・挙動は今後変わりうる。本番クリティカルな移行を全面依存するのは時期尚早
• 「収束＝正解」ではない：反証検証を生き延びても、最終確認は人間が必要。特に金額・固有名詞・最新情報は要注意

正直に言うと、私は「楽観7・慎重3」くらいで見ています。大規模調査やコード監査のように「広く浅く・突き合わせて精度を上げる」タスクには本当に効く。一方で、トークンコストは無視できないので、中小企業がいきなり ultracode を常用するのはおすすめしません。まずは /deep-research で限定的に試すのが現実的です。

日本企業・中小企業への影響

では、これが日本の現場、とくに中小企業にどう効くのか。研修・導入支援の肌感覚で3点に絞ります。

1. 「人手が足りない大規模作業」が外注せずに回る可能性

中小企業の情シスは慢性的な人手不足です。社内全システムのセキュリティ監査、古いコードベースの移行、規約改定に伴う全社ドキュメントの横断チェック——こういう「重いが定型的な調査」は、これまで外注かペンディングの二択でした。動的ワークフローは、この層を社内のClaude Codeで巻き取れる余地を作ります。

2. コスト構造が「人月」から「トークン」に変わる

ここが日本企業にとって一番のパラダイム転換かもしれません。大規模作業のコストが、人月見積もりからトークン消費量に置き換わる。これは予算化の考え方を変える必要があり、情シスと経理の両方を巻き込んだルール作りが要ります。プラン選定とコスト試算についてはClaude Code 月額コスト最適化完全ガイドで、7プランの年間試算と規模別の最適解を出しているので、導入前に必ず目を通してください。

3. Opus 4.8との同時進化として捉える

動的ワークフローはOpus 4.8と同時リリースされました。Opus 4.8は「自分の作業の不確実性を申告しやすく、根拠のない主張をしにくい」方向に調整されたとされ、反証検証を回すモデルとして相性が良い。「賢いモデル」と「賢い使い方」がセットで来たのが、今回の更新の本質です。Opus 4.8自体の料金・1M文脈・新機能はClaude Opus 4.8完全ガイドで詳しく扱っています。

企業がとるべきアクション — 5つ

「で、明日から何をすればいいの？」に答えます。研究プレビューだからこそ、いきなり全面導入ではなく、段階を踏むのが正解です。

1. まず /deep-research を限定タスクで試す：競合調査・社内ナレッジの突き合わせなど、失敗してもダメージの小さい調査系から。トークン消費の体感を掴む
2. 許可リスト（allowlist）を先に設計する：ワークフローのサブエージェントはファイル編集を自動承認する。本番リポジトリに対していきなり走らせない。サンドボックス or 検証用ブランチで
3. コスト上限と監視を決める：誰が・どの規模のワークフローを・月いくらまで回せるか。/model で大規模ラン前にモデルを確認するルールも合わせて
4. プラン別の有効化ポリシーを決める：Max・Teamではデフォルト有効、Enterpriseは管理者が有効化、Proは /config から手動。組織全体でオフにするなら "disableWorkflows": true を管理設定に。野放しにしない
5. 「人間の最終確認」を業務フローに残す：反証検証があっても、金額・契約・固有名詞・最新情報のチェックは人間の責任範囲として明文化する

事例区分：想定シナリオ。100社以上の導入支援から言えるのは、新機能の事故は「機能そのもの」より「権限とコストのルールを決めずに走らせた」ときに起きる、ということ。動的ワークフローは特にその傾向が強い機能です。技術より先に運用ルールを作ってください。

料金・有効化まわりの整理

導入判断に直結する「どこで使えて、いくらかかるのか」を表にまとめます。

金額の細かい試算はプランとモデルの組み合わせで大きく変わるため、ここで断定はしません。重要なのは「動的ワークフローは安く済む機能ではなく、人月を浮かせる代わりにトークンを使う機能」という性質を、稟議の段階で正しく伝えることです。AI導入全体の戦略設計についてはAI導入戦略ガイドで、優先順位の付け方からまとめています。

コスト管理の実務的なコツも3つ置いておきます。いずれも公式が推奨している節約ポイントです。

• 大規模ラン前に /model を確認する：ふだんルーチン用に小さいモデルへ切り替えている人は、ワークフロー起動前にモデルを確認する習慣を。ワークフロー内の各エージェントは、スクリプトが別モデルへ振り分けない限りセッションのモデルを使います
• 強いモデルが不要な段階は小さいモデルへ：タスクを説明するときに「この段階は軽いモデルでいい」とClaudeに指示すれば、段階ごとにモデルコストを最適化できます
• 止めても完了分は無駄にならない：/workflows からいつでもランを停止でき、すでに完了したエージェントの作業は失われません。「想定より食っている」と思ったら早めに止める判断ができます

よくある質問（FAQ）

Q1. 動的ワークフローは無料プランでも使えますか？

いいえ。動的ワークフローは有料プラン（Pro / Max / Team / Enterprise）向けの機能です。Claude Code v2.1.154 以降が必要で、研究プレビューとして提供されています。

Q2. 「最大1,000体」が同時に動くのですか？

いいえ、ここは誤解が多いところです。同時実行は最大16体（CPUコアが少ないマシンではさらに少なく）で、1ランあたりの総数の上限が1,000体です。1,000は暴走ループを防ぐためのキャップであり、公式ブログ自身は規模感を「数十〜数百」と表現しています。

Q3. 従来のサブエージェントと何が違うのですか？

サブエージェントは「次に何を動かすか」をClaudeがターンごとに決め、中間結果がClaudeの文脈に乗ります。動的ワークフローはその計画・分岐・中間結果をスクリプト側が持つため、文脈が溢れにくく、オーケストレーション自体を保存・再実行できます。1会話で調整しきれない規模のときに使い分けます。

Q4. 途中で止めたり、人間が介入できますか？

ランの途中でユーザー入力を差し込むことはできません（許可プロンプトでの一時停止のみ）。段階ごとに人間の承認を挟みたい場合は、各段階を独立したワークフローとして実行する設計にします。停止は /workflows ビューからいつでも可能で、完了済みの作業は失われません。

Q5. セキュリティ面で気をつけることは？

ワークフローが生成するサブエージェントは、セッションのモードに関わらず常に acceptEdits モードで動き、ファイル編集が自動承認されます。本番リポジトリにいきなり走らせず、検証用ブランチやサンドボックスで試すこと、必要なコマンドを事前に許可リストへ入れておくことが重要です。組織全体でオフにする設定も用意されています。

Q6. 中小企業が最初に試すなら何がおすすめですか？

同梱の /deep-research を、失敗してもダメージの小さい調査系タスク（競合調査・社内ナレッジの突き合わせなど）で試すのがおすすめです。トークン消費の体感を掴んでから、コードベース監査や移行のような重い用途に広げてください。いきなり /effort ultracode を常用するのはコスト面で非推奨です。

まとめ

動的ワークフローは、「1回のパスでは大きすぎる問題」を、Claudeが書いたスクリプトで多数のサブエージェントに分解し、反証検証で精度を上げながら、答えが収束するまで回す機能です。大規模な調査・移行・監査という、中小企業が外注かペンディングで凌いできた領域を、社内のClaude Codeで巻き取れる可能性を開きました。

一方で、トークン消費の増加・研究プレビューという段階・「収束＝正解ではない」という限界も明確にあります。だからこそ、技術の前に権限とコストの運用ルールを作ること。そして /deep-research の限定試行から始めること。この2点を守れば、今回の更新は中小企業にとっても十分に味方になります。

Opus 4.8という「賢いモデル」と、動的ワークフローという「賢い使い方」がセットで来たのが、2026年5月末の本質です。AIへの仕事の任せ方が、また一段アップデートされました。

あわせて読みたい：

• Claude Opus 4.8完全ガイド — 料金・1M文脈・新機能を体系的に
• Claude Code 月額コスト最適化完全ガイド — 7プラン年間試算・規模別の最適解

参考・出典

• Introducing dynamic workflows in Claude Code — Anthropic（参照日: 2026-05-29）
• Orchestrate subagents at scale with dynamic workflows — Claude Code Docs（参照日: 2026-05-29）
• Anthropic releases Opus 4.8 with new ‘dynamic workflow’ tool — TechCrunch（参照日: 2026-05-29）
• Anthropic Ships Claude Opus 4.8 Alongside Dynamic Workflows and Cheaper Fast Mode, With Workflows Capped at 1,000 Subagents — MarkTechPost（参照日: 2026-05-29）
• Introducing Claude Opus 4.8 — Anthropic（参照日: 2026-05-29）

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。