Claude Codeを少し使い慣れてきて、一度の指示でもっと大きな作業を任せたい人向け
料理ブログ全120本のリンク切れ点検、500ファイルの一括書き換え、コードベース全体のバグ一掃、複数ソースを突き合わせる調査など、会話1往復ではとても捌けない量の作業を一気に任せたいときに、プロンプトへ「workflow」の語を入れて頼む。まずは1カテゴリ10本など小さなひと切れで試してから本番に広げる。
Dynamic Workflows（動的ワークフロー）は、Claude Codeが「タスクの段取りを書いたJavaScriptの台本」を自分で書き起こし、その台本が裏で大量の作業役を一斉に動かす仕組みです。料理ブログの全記事120本を一気に点検する、500個のファイルをまとめて書き換える、といった「会話1往復ではとても捌けない量」を任せたいときに使います。
ふつうに会話でお願いすると、Claudeは1回ごとに「次は何をやろうか」と考えながら進めます。Dynamic Workflowsはその段取りを台本の中に閉じ込めてしまう。だから走っている間も会話画面は止まらず、別の話を続けられます。
噛み砕くと
大きなイベントの当日を思い浮かべてください。会場には数十人のスタッフがいて、それぞれ受付・誘導・撤収を担当しています。全員に逐一あなたが指示を出していたら、口がいくつあっても足りません。
そこで「進行台本」を1枚用意します。何時に誰が何をやるか、その結果を受けて次に誰が動くか、が全部書いてある紙です。スタッフはその台本どおりに動き、あなたは終わったあとの完成報告だけ受け取ればいい。
Dynamic Workflowsの台本がこの進行台本にあたります。台本を書くのはClaudeで、あなたは日本語で「〜のワークフローを動かして」と頼むだけ。自分でプログラムを書く必要はありません。ここ、いちばん勘違いされる点です。
大事な前提：研究プレビューで、有料プランとバージョンが要る
これは公式が「research preview」と明記している新しい機能です。動かすには Claude Code v2.1.154 以降が必要。
使えるのは Pro / Max / Team / Enterprise の有料プランだけ。ほかに Anthropic API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry 経由でも動きます。無料プランでは動きません。
さらにProの人は、ひと手間あります。/config（設定画面）を開いて「Dynamic workflows」の行をオンにしないと使えない。ここは見落としやすいので先に書いておきます。
「料理ブログ全記事120本の点検」を例に、実際の手順を見る
仮に、自分が運営する料理ブログに記事が120本あるとします。古いリンクが切れていないか、レシピ内の価格表記が今と合っているか、全部まとめて点検したい。1本ずつ会話で頼んでいたら日が暮れます。こういうときがDynamic Workflowsの出番です。
ステップ1: まず小さく試す（1カテゴリ10本だけ）
いきなり120本に突っ込んではいけません。公式も「小さなひと切れで先に試せ」と書いています。理由は後半の落とし穴で詳しく触れますが、要はトークンを食うからです。トークンの意味はこのパート末でまとめます。
まず和食カテゴリの10本だけで雰囲気を掴みます。プロンプトに「workflow」という単語を入れて、こう頼みます。
和食カテゴリの10記事を対象に、リンク切れと古い価格表記をまとめて点検する workflow を動かして「workflow」の語が入っていると、Claude Codeがその単語を光らせて、台本を書くモードに切り替わります。
ステップ2: Claudeが台本を書く
頼むと、Claudeはその場で台本を書き起こします。「まず10記事のURLを集める→各記事を作業役に割り振ってリンクを確認→価格表記を確認→結果を集計」といった段取りが、JavaScriptの台本として組まれます。
ここで自分がコードを読む必要はありません。読みたければ後で開けますが、ふつうは中身を見ずに進めて大丈夫。
ステップ3: 「動かしていい?」に答える
台本ができると、Claude Codeが「この段取りで動かしていいか」を確認してきます。予定されたフェーズ（作業の段階）の一覧が出るので、内容を見て Yes, run it を選びます。
Plan:
Phase 1: 対象10記事のURL収集
Phase 2: 各記事のリンク切れ確認
Phase 3: 価格表記の確認
Phase 4: レポート集計
> Yes, run it台本そのものを読んでから決めたいときは View raw script も選べます。
ステップ4: 裏で走る間、会話は止まらない
動き出すと、点検は裏で進みます。ここがふつうの会話と決定的に違うところで、走っている間も会話画面は応答可能なまま。別の質問を投げても待たされません。
ステップ5: /workflows で進み具合を見る
途中経過は /workflows コマンドで見られます。実行中・完了済みのワークフローが一覧で出るので、矢印キーで選んでEnterを押すと進捗画面が開きます。
/workflows画面には各フェーズごとに「作業役が何体動いているか」「トークンをどれだけ使ったか」「経過時間」が並びます。pキーで一時停止と再開、sキーで台本の保存、xキーで停止。ここで「思ったより重そうだ」と感じたら、完了済みの分を残したまま途中で止められます。
ステップ6: 最後に1本のレポートが返る
終わると、会話画面に1本のまとまったレポートが届きます。途中の細かいやり取りは全部台本の中で処理されていて、あなたの画面には「リンク切れが7件、価格が古い記事が3件」のような最終結果だけが乗る。会話が中間報告で膨らまないのが利点です。
10本で感触を掴んだら、同じ要領で120本に広げます。
つまり Dynamic Workflows は何をしてくれるのか
- やってくれる: 数十〜数百の作業役を1つの台本で統制し、コードベース全体のバグ一掃や500ファイルの移行、複数の角度からの調査をまとめて回す
- やってくれない: 台本自体がファイルやコマンドを直接いじることはない。読み書き・実行は作業役の担当で、台本はあくまで段取り役に徹する
- 意味が薄い場面: 1〜2個の小さなタスク。作業役を大量に生む分トークンを食うので、軽い用事はふつうの会話で頼むほうが安く速い
使いどころ3シナリオ（具体題材で再現）
シナリオ1: 個人ブログのリンク切れ・情報古い一斉点検のとき
記事が100本を超えてくると、1本ずつ確認は現実的じゃありません。リンク切れと古い価格表記をまとめて点検するワークフローを1回流せば、作業役が記事を手分けして調べ、最後に「直すべき記事リスト」が1本のレポートで返ってきます。手作業で半日かかる棚卸しが、流して待つだけの作業に変わります。
シナリオ2: GitHubから落としてきた他人のプロジェクトのバグ一掃のとき
GitHubから他人のOSSを自分のパソコンにコピーしてきた直後、コードのあちこちに同じ種類のバグが散らばっていることがあります。「src以下の全エンドポイントで、認証チェックの抜けをまとめて洗い出すワークフローを動かして」と頼めば、作業役がファイルを分担して点検し、抜けの一覧を返します。会話で1ファイルずつ見ていくのとは速度が桁違いです。
シナリオ3: 調べ物を複数ソースで裏取りしたいとき（/deep-research）
「この情報、1つのサイトだけだと不安だな」というときは、同梱の /deep-research を使うのが手軽です。これは最初から用意されているワークフローで、1つの質問に対してWeb検索を複数の角度から展開し、見つけたソース同士を突き合わせ、各主張に「投票」して、裏取りに残った主張だけを引用付きのレポートにまとめてくれます。使うにはWeb検索の道具が有効になっている必要があります。
初心者が踏みやすい落とし穴
- 自分でJavaScriptを書く機能だと思い込む。書くのはClaudeです。人は日本語で「〜のワークフローを動かして」と頼むだけで、コードの知識は要りません。
- サブエージェントと同じものだと混同する。違いは「誰が段取りを持つか」です。会話で数タスク投げるのがサブエージェント、数十〜数百を1つの台本で統制するのがワークフロー。中間結果が台本の中に溜まるので、あなたの会話には最終結果だけが乗ります。
- 全部のタスクをワークフローにしようとする。作業役を大量に生む＝トークンを大量に消費する、という構造です。軽い用事まで回すと料金だけかさみます。大規模・並列・相互チェックが要るタスク限定で。
- 無料プランで使おうとする。使えません。Pro / Max / Team / Enterprise の有料プラン＋API利用が前提で、Proは
/configでオンにする操作も要ります。 - いきなり本番フルサイズで回す。まず1ディレクトリ、狭い質問など小さなひと切れで試して、トークンの食い具合を確かめてから本番へ。
/workflows画面で使用量を見ながら、重ければ途中停止できます。 - 走行中に途中で口を挟めると期待する。ラン中はユーザー入力を受け付けません。段階ごとに自分の承認を挟みたいなら、各段階を別々のワークフローに分けて回すのが公式の案内です。
- 「Yes, run it」を押せばもう止まらず最後まで走ると思い込む。これは逆向きの落とし穴です。外部のコマンド実行・Web取得・MCP連携ツールのうち、最初に許可していないものを作業役が使おうとすると、走行の途中でも「これ使っていい?」の確認が出て、そこで止まってしまいます。長く流したいときは、走らせる前に作業役が使う道具を
/configの権限設定であらかじめ許可しておくと、途中で止まらず最後まで進みます。 - 同時にいくらでも作業役が増えると思う。同時に動く作業役は最大16体で、CPUコアが少ない機械ではもっと少なくなります。1回の実行で合計1,000体までという上限があります。暴走ループを防ぐための制限です。
- 編集が勝手に進むのを見落とす。作業役は常に acceptEdits（編集自動承認）モードで走り、ファイルの書き換えはいちいち確認されず自動で通ります。許可設定はあくまで「最初に動かしていいか聞くか」だけを制御します。
書き方
プロンプトに「workflow」の語を入れて頼む ／ /effort ultracode で毎タスク自動ワークフロー化 ／ /deep-research や保存済みワークフローを実行やってみるとこうなる
入力
和食カテゴリの10記事を対象に、リンク切れと古い価格表記をまとめて点検する workflow を動かして出力例
Claudeが段取りの台本を書き、「Yes, run it」で承認すると裏で作業役が分担して点検。/workflows 画面で各フェーズの作業役数・トークン・経過時間を見ながら待つと、最後に「リンク切れ7件・価格が古い記事3件」のような最終レポートが1本だけ会話に返る。このページに出てきた言葉
- サブエージェント（作業役）
- Claudeが裏で生み出す分身。ファイルの読み書きやコマンドの実行を分担して担当する
- スクリプト（台本）
- 段取りを書いた命令の並び。ここではClaudeが書くJavaScriptの段取り台本を指す
- ランタイム
- 台本を実際に動かす裏方のプログラム。台本を読み込んで作業役を呼び出す係
- research preview
- 正式版になる前の「お試し公開」段階。仕様が今後変わる可能性がある
- /config
- Claude Codeの設定画面を開くコマンド。Proの人はここで「Dynamic workflows」をオンにする
- /workflows
- 実行中・完了済みのワークフローを一覧表示し、進み具合を見たり一時停止・停止・保存したりする画面を開くコマンド
- /deep-research
- 最初から同梱されているワークフロー。1つの質問をWeb検索で複数角度に展開し、ソースを突き合わせ、裏取りに残った主張だけを引用付きレポートで返す
- acceptEdits（編集自動承認）
- 作業役が走るときのモード。ファイルの書き換えがいちいち確認されず自動で通る
- トークン
- AIが文章を処理するときの単位。多く処理するほど料金や利用枠を食う