知識がなくても始められる、AIと共にある豊かな毎日。
AIコーディング

Claude Code のワークフローは台本を固定する — 数十のサブエージェントを一つのスクリプトで回す

ゲンキ

※本記事にはアフィリエイト広告(PR)が含まれます。

7本の記事を、7つの観点で、独立した目で検査したい。人がやるなら、記事ごとにチェックリストを開き、出典を一つずつ開き直し、疑わしい箇所を書き出し、別の人にもう一度見てもらう。Claude Code にサブエージェントを頼めば数は捌けるが、「次に何をするか」を毎回 Claude が会話の中で決めるので、同じ検査を来週も同じ手順で回せる保証が無い。

Claude Code のワークフロー(文書上の名前は dynamic workflows)は、この「次に何をするか」を会話から取り出して、JavaScript の台本に固定する機能だ。Claude が台本を書き、ランタイムがバックグラウンドで実行し、数十から数百のサブエージェントを回す。中間結果は Claude の文脈窓ではなく台本の変数に残る。

本記事は、公式文書の記述と、当サイトが実際に台本を書いて保存し、本週の記事の検査に使った記録で書く。数値と版番号は 2026年9月17日に取得したもので、当サイトの環境は Claude Code 2.1.273 である。

忍者AdMax

4列目が増えた

4列目が増えた

当サイトは 4月に Agent Teams vs Subagents 完全比較 2026 — 2つのマルチエージェントパターンの使い分け(2026-04-24 公開) で、サブエージェントとエージェントチームの違いを扱った。公式文書の比較表は、そこに Skills とワークフローを加えた4列になっている。前3列の説明は繰り返さず、4列目だけを足す。

観点SubagentsSkillsAgent teamsWorkflows
何かClaude が生む作業者Claude が従う指示対等なセッションを監督するリードランタイムが実行するスクリプト
次の手を決めるのはClaude(手番ごと)Claude(プロンプトに従う)リードエージェント(手番ごと)スクリプト
中間結果の置き場Claude の文脈窓Claude の文脈窓共有タスクリストスクリプトの変数
再現できるもの作業者の定義指示チームの定義オーケストレーションそのもの
規模手番あたり数件同左数体の長期ピア1回で数十〜数百体
中断したとき手番をやり直し手番をやり直しチームメイトは継続同じセッション内で再開できる

4列目の本質は「再現できるもの」の行にある。サブエージェントで再現できるのは作業者の定義で、どの順に誰を呼ぶかは毎回 Claude が決め直す。ワークフローで再現できるのは、その呼ぶ順序そのものである。

誰が次の手を決めるか

誰が次の手を決めるか

文書は、この違いを一文で言い切っている。ワークフローは計画をコードに移す。

サブエージェント、スキル、エージェントチームでは、Claude がオーケストレーターだ。手番ごとに何を生むか、何を割り当てるかを決め、すべての結果が文脈窓に入る。ワークフローでは、台本がループと分岐と中間結果を持ち、Claude の文脈には最終的な答えだけが残る。

これは規模の話であると同時に、品質の話でもある。台本に固定すると、独立したエージェントに互いの所見を反証させてから報告する複数の角度で案を出して比較してから一つに絞る、といった手順を、毎回同じ形で適用できる。人が会話の中で「念のためもう一人に見てもらって」と毎回言わなくても、台本がそう書いてあれば必ずそうなる。

会話で頼んでいたときに起きていたこと

会話で頼んでいたときに起きていたこと

当サイトは、この検査をこれまで会話の中でやっていた。記事ごとに「この観点で見て」とサブエージェントを立て、返ってきた所見を主会話で読み、気になるものをもう一度検索する。動いてはいた。しかし三つの点で毎週同じ不満があった。

一つ目は順序と密度が毎回違うこと。7本のうち最初の2本は丁寧に、残りは駆け足になる。人が会話で指示している以上、手番の疲れがそのまま検査の粗さに出る。二つ目は中間結果が主会話の文脈を食うこと。7本分の所見が全部会話に流れ込むと、それだけで文脈窓が埋まり、執筆の続きに支障が出る。三つ目は反証の段が抜けること。「もう一人に見てもらう」は、忙しい週ほど省かれる。

台本にすると、この三つが構造として消える。順序と密度は台本に書いたとおりになり、中間結果は台本の変数に残って主会話には最終の集計だけが届き、反証の段は書いてある以上必ず走る。会話で頼む方式の欠点は、Claude の能力ではなく、人が毎回オーケストレーターを務めることに由来していた。

台本の中身

台本の中身

台本は平文の JavaScript で、先頭に名前と説明を持つ meta を置き、本文で3つの関数を使う。

export const meta = {
  name: 'audit-routes',
  description: 'Audit every route handler for missing auth checks',
}

const found = await agent('List every .ts file under src/routes/.', {
  schema: { type: 'object', required: ['files'], properties: { files: { type: 'array', items: { type: 'string' } } } },
})

const audits = await pipeline(found.files, file =>
  agent(`Audit ${file} for missing authentication checks.`, { label: file }),
)

return audits.filter(Boolean)

agent() は1体のサブエージェントを生む。pipeline() はリストの各項目に1体ずつを、項目ごとに独立して流す。parallel() は一群を同時に走らせ、全部が終わるまで待つ。phase() で進捗表示の見出しをつけ、log() で一行の報告を出し、args で外から入力を受ける。

schema を渡すと、そのエージェントは散文ではなく指定した形の JSON を返す。検証に失敗すると再試行され、試行5回(初回と再試行4回)で失敗すると呼び出しがエラーになる。矛盾したスキーマは開始前に拒否される。この構造化出力が、台本の後半で「所見の一覧」を機械的に扱える理由になる。

agent()null を返すことがある。途中で止めた場合、回復できない API エラーの場合、そして auto mode の分類器が開始前に止めた場合だ。台本の末尾に filter(Boolean) が付いているのは、その null を落とすためである。

台本の中で Date.now()Math.random()、引数なしの new Date() は使えない。呼ぶと例外になる。再実行したときに同じ agent() 呼び出しが同じ順で再現される必要があるからで、日時は args で外から渡す。

起動の入口

起動の入口

ワークフローが走り出す経路は一つではない。

プロンプトに ultracode という語を含めるか、「use a workflow」のように自然文で頼むと、Claude はその作業を手番ごとの対話ではなく台本として書く。/effort ultracode を設定すると、以後のすべての実質的な作業に対して Claude が自分でワークフローを計画する。これは xhigh の effort と自動オーケストレーションを組み合わせた設定で、起動時に claude --effort ultracode として付けるには v2.1.203 以降が要る。同梱の /deep-research は、質問を複数の角度で検索し、出典を突き合わせ、投票で残った主張だけを引用つきで返すワークフローで、WebSearch が使えることが前提になる。そして保存済みの台本は /<名前> で呼べる。

キーワードには境界がある。ultracode が発火するのは人が打った入力だけで、-p で渡したプロンプト、SDK の非人間入力、定期タスクのプロンプト、webhook の本文では発火しない(v2.1.210 以降)。ワークフロー自体は -p や SDK でも許可規則を通せば起動できるので、これはキーワードの扱いの話であって、機能の制限ではない。

利用条件は、全有料プラン、API、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry。Pro プランでは /config の Dynamic workflows の行で有効にする。

上限と警告

上限と警告

ランタイムには文書に明記された上限がある。

制約理由
同時に走るエージェント既定で16体(CPU が少ない環境では減る)手元の資源を抑える
1回の parallel()pipeline() の項目数4,096件黙って切り捨てず、超えたら明示的にエラーにする
1回の実行の総エージェント数1,000体暴走したループの歯止め
途中の人の入力受けない段階ごとに承認したいなら、段階ごとに別のワークフローにする
台本からのファイル・シェル操作不可。エージェントが行う台本は調整役

同時16体は既定値で、v2.1.269 以降は環境変数で最大256まで上げられる。

上限とは別に助言がある。既定のサイズ指針のままなら、ワークフローが25体を超えてエージェントを予定するか、推定トークン合計が150万を超えると、進捗行に「Large workflow」の警告が出る。止まりはしない。サイズ指針を自分で選ぶと閾値はその体数に置き換わり、ultracode をオンにしたセッションでは警告自体が出ない。

サイズ指針は、Claude が台本を書くときに目安にするエージェント数で、2026年9月17日時点の文書では small(5体未満)、medium(10体未満)、large(50体未満)、unrestricted。既定は medium で、Pro プランでは v2.1.271 以降 small になる。あくまで助言で、作業の性質が要求すれば超える。

止まったときの規則

止まったときの規則

台本を固定する利点は、途中で止まっても続きから再開できることにある。ただし規則がある。

再開すると、ランタイムはエージェントが始まった順に再生する。完了していたエージェントは保存された結果を返す。台本を編集するか前のエージェントの結果が変わって、プロンプトが変わった最初の1体からは、それ以降を全部やり直す。そして失敗した1体があると、その後に始まった完了済みのものも含めて、全部やり直す。文書の例では、A・B・C・D の順で始めて B が失敗すると、A はキャッシュから返り、B・C・D が再実行になる。

使用量の上限に当たった場合は、失敗ではなく一時停止になる(v2.1.271 以降)。上限に当たったエージェントはリセットを待ち、新しいエージェントは始まらず、リセット後に自動で再開する。ただし条件が四つある。対話セッションであること、claude.ai のサブスクリプションでログインしていること、autoContinueAtUsageLimit の設定がオンであること、リセットが24時間以内であること。-p・SDK・バックグラウンドセッション・Remote Control・エージェントチームのチームメイトでは一時停止せず、該当エージェントは失敗する。待つのは2回までで、3回目は失敗になる。

費用の構造

費用の構造

ワークフローは多数のエージェントを生むので、同じ仕事を会話でやるより明らかに多くのトークンを使う。実行はプランの使用量と rate limit に数えられる。

その中で費用を下げる仕組みが一つ組み込まれている。同じモデル・同じ effort・同じ種類・同じツール・同じ出力スキーマ・同じ作業ディレクトリで走るエージェントは、同じシステムプロンプトとツール定義の前置きを持つ。fan-out で同型のエージェントを一斉に始めるとき、ランタイムは最初の1体の応答が始まるまで残りを最大5秒待たせ、最初の1体がキャッシュに載せた前置きを、残りが読むようにする。前置きを全員が別々に処理するより安い。

ただし、ワークフローのエージェントは主会話のキャッシュ寿命の外にいる。主会話がサブスクリプションの枠内で1時間の寿命を得ていても、ワークフローのエージェントは既定で5分だ。subagentPromptCacheTtl1h にすれば延ばせる(文書は v2.1.242 以降と記す。changelog 上の掲載は 2.1.243)が、1時間の書込は単価が高い。短時間で終わる fan-out なら5分のままでよい。

費用を見積もる実務的な方法は、文書が勧めるとおり、まず小さな範囲で走らせることだ。ディレクトリ一つ、質問一つ。/workflows の画面でエージェントごとのトークンが見えるので、そこから全体を外挿する。

当サイトで組んだ台本

当サイトで組んだ台本

当サイトの制作工程には、公開前に記事を7つの観点(製品オプションの完全性、OS・ベース技術、修飾語の根拠、URL と型番の表記、世代差、既定値、公式呼称。台本ではこれに8項目目として同じ週の記事間の整合性を足している)と5つのデータ種別で独立検証する段階がある。これまでは記事ごとにサブエージェントを手で立てていた。今回、これを台本にした。

台本の形は単純だ。記事ディレクトリのリストを pipeline() に流し、各ディレクトリに対してレビュー担当を1体生む。レビュー担当は対象ファイルの事実主張を全件列挙し、出典を開いて照合し、問題のある主張だけを構造化出力で返す。所見が一つでもあれば、同じディレクトリに対して反証担当を1体生む。反証担当は所見の出典を自分で再取得し、所見が正しければ CONFIRMED、所見のほうが誤りなら REFUTED、判断できなければ UNVERIFIABLE を返す。迷ったら REFUTED ではなく UNVERIFIABLE を選ぶよう指示した。

args で三つを受ける。検査の対象が執筆前の fc_log なのか執筆後の記事本文なのかを示す mode、ディレクトリの一覧、そして検査日。日付を args で渡すのは、台本の中で日時を取れないからだ。

保存先は .claude/workflows/phase95_fc.js。リポジトリに含まれるので、同じリポジトリを使う人は誰でも同じ検査を回せる。

走らせた結果

走らせた結果

9月17日、執筆前の fc_log 7本を対象に、mode=fc_log で走らせた。

項目
エージェント14体(レビュー7、反証7)
所要約10分15秒。バックグラウンドで走り、その間セッションは執筆を続けた
トークンサブエージェント合計 約208万(/workflows が表示する値で、キャッシュ読み取り分の約1,830万は含まない)。ツール呼び出し 237回
照合した主張315
所見54(反証担当の判定は確認 53、反証 1。当サイトの台本の集計は文字列の完全一致で突き合わせていたため 2 件を「不一致」として数えていた。台本はその後、装飾を除いた文字列と位置で対応づけるよう直した)
重さの内訳54件のうち MUST 2、SHOULD 20、CONSIDER 32。反証で覆った1件は MUST

14体は medium の指針(10体未満)を超えているが、指針は助言であり、警告の閾値(25体)には届いていないので何も表示されなかった。

所見の中身は、記事にそのまま効く種類だった。たとえば MUST の1件は、ある版番号の要件が「セッション内のコマンド」ではなく「起動時のフラグ」に係るものだという指摘で、当サイトの fc_log は誤って帰属していた。SHOULD の多くは「その条件が抜けている」という指摘で、プラン別の差、既定値の版番号、警告が出ない条件、といったものだ。人が7本分を読み直して同じ密度で拾えたとは思えない。

反証の1体が誤所見を落とした

反証の1体が誤所見を落とした

54件のうち1件は、反証担当がレビュー担当の所見を覆した

レビュー担当は、当サイトが記録していたある原文引用について「この文字列は出典の本文に存在しない」と所見を出した。fc_log に原文と称して要約を書いてしまう事故は当サイトにも過去にあり、もっともらしい指摘だった。しかし反証担当が出典を自分で取得したところ、その文字列は冒頭の要約段落に一字一句そのまま存在した。レビュー担当は本文の中盤にある別の似た文を見て、冒頭を見落としていた。

もしレビュー1体だけの台本にしていたら、当サイトは正しい引用を「誤り」として書き換えていた。独立した2段目は飾りではない。しかも2段目を人が毎回言わなくても実行されるのは、台本に書いてあるからだ。

保存して、名前で呼ぶ

保存して、名前で呼ぶ

一度走らせた台本は、/workflows の画面で選んで s を押すと保存できる。保存先はプロジェクトの .claude/workflows/(リポジトリを clone した全員に共有)か、ホームの ~/.claude/workflows/(自分だけ、全プロジェクトで有効)。以後は /<名前> で呼べ、args に入力を渡せる。当サイトはファイルを直接置いたが、同じ場所に入れば同じ扱いになる。

保存先にシンボリックリンクがあると拒否される(v2.1.216 以降)。ただし範囲が違う。プロジェクト側は .claude.claude/workflows・対象ファイルのいずれかがリンクなら拒否、個人側は対象ファイル自体がリンクのときだけ拒否で、dotfiles で管理した ~/.claude はそのまま動く。

承認の出方は権限モードで変わる。auto mode では初回だけ確認され、以後は記録された同意で始まる。manual と accept edits では毎回確認されるが、名前で呼ぶ同梱・保存済み・プラグインのワークフローに限り「このプロジェクトではもう聞かない」を選べる。その場で Claude が書いた台本にはこの選択肢は出ない。bypass permissions では確認なしに始まる。ワークフローが生むエージェントは通常の許可規則に従うので、長い実行で止められたくなければ、必要なツールを先に許可リストに入れておく。

台本を編集したいときは、/workflow-authoring という同梱のスキル(v2.1.248 以降)で書き方の参照を読み込んでから、ファイルを直すか Claude に頼む。meta は先頭の純粋なオブジェクトリテラルでなければならず、変数や関数呼び出しを混ぜると / の補完から消える。

3Dプリントの作業台で何を台本にするか

3Dプリントの作業台で何を台本にするか

ワークフローが向く仕事の形は、「同じ手順を多数の対象に当てる」か「独立した目で互いを検証させる」かのどちらかだ。

前者なら、STL や 3MF のファイル群に対して、寸法の範囲・マニフォールドの有無・サポートの要否を一括で検査する仕事がそれに当たる。3Dプリント 修理 実践 2026 — 廃番部品を採寸とAI CADで蘇らせる(2026-07-25 公開) のように採寸から設計を起こした部品が数十個あるなら、寸法の検算を1体ずつに任せ、外れ値だけを人が見る。後者なら、設計をコードで書かせて、確認まで機械に回させる(2026-09-17 公開) で扱ったコード CAD の生成に対して、寸法検証を別の1体に反証させる台本が組める。

どちらも、1回きりなら会話で済む。台本にする価値が出るのは、来週も、来月も、同じ検査を同じ形で回すときだ。もう一つ、台本にしておくと検査の基準が文書として残る。「寸法の外れ値とは公称値から何ミリ以上か」「マニフォールドでない面が一つでもあれば不合格か」といった判断が台本のプロンプトに書かれるので、後から基準を変えたときに差分が追える。会話で頼んでいると、基準はその日の言い方に埋もれる。当サイトの検査台本は、次に記事本文が出来上がったとき、mode=article に変えて同じ7本に対してもう一度走る。

まとめ

まとめ

ワークフローを使うとき、確かめる順序は次のとおりだ。

  1. 再現したいのは作業者か、手順か。手順なら台本にする。1回きりなら会話でよい
  2. 既定の上限は同時16体、1回1,000体、4,096項目。25体か150万トークンで助言の警告(指針を選ぶと変わる)
  3. 失敗した1体の後ろは全部やり直しになる。長い fan-out ほど、失敗の位置で費用が変わる
  4. 同型のエージェントは最初の1体のキャッシュを読む。ただし寿命は既定5分
  5. 反証の段を台本に書く。当サイトでは54件中1件が反証で覆り、正しい引用を誤って直すところだった
  6. 保存して名前で呼ぶ。manual と accept edits の「もう聞かない」はプロジェクト単位で名前で呼ぶものにだけ効く。auto mode の同意はユーザー設定に記録され、以後の起動に効く

当サイトの台本は、14体・約10分・約208万トークンで315の主張を検査した。週1回の検査として払える額で、記事1本の推敲ごとに回す規模ではない。この見積りは当サイトの環境と台本の書き方に依存する。自分の台本で小さく走らせて、/workflows の数字から外挿してほしい。

Claude Code を体系的に押さえたい場合の入門書の例。本シリーズは公式ドキュメントを一次情報にしているので、書籍は補助線として。

出典・参考

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】
ABOUT ME
swiftwand
swiftwand
AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.
記事URLをコピーしました