/workflowsで数十〜数百エージェントの実行を管理する

/workflowsを開いてpキーを押すだけで、走っている実行を一時停止できます。再開したとき何が生き延びるかは、フェーズの中で何番目に起動したエージェントだったかで決まります。この仕様を知らずに大きな実行を止めると、完了していたはずの作業まで再計算され、トークンを二重に払うことになります。

ダイナミックワークフロー自体の仕組みと起動方法は別記事で扱いました。本稿は、実行が始まったあとの操作面である/workflowsビューに絞ります。キーバインド・サイズ指針・中断再開の正確な挙動・保存したワークフローの再利用を、公式ドキュメントの現行仕様に沿って掘り下げます。

背景

ダイナミックワークフローは2026年5月28日に研究プレビューとして公開された当初、起動と結果確認だけができるシンプルな機能でした。そこからのバージョンアップで、/workflowsビュー側の制御機能が段階的に積み上がっています。

この積み上げの結果、/workflowsは「実行を眺める画面」から「規模とコストを操作する管理面」に変わっています。大量のエージェントを日常的に走らせるなら、ここで扱う仕様を知っているかどうかがコストの差になります。

/workflowsビューの操作とキーバインド

/workflowsは実行中と完了済みのワークフローを一覧し、選んだ1件の進捗ビューを開くコマンドです。フェーズごとのエージェント数・消費トークン・経過時間が表示され、エージェント単位まで掘り下げてプロンプトとツール呼び出しを確認できます。

/workflows

進捗ビューのフッターにキー操作が並びます。

Escまたは←で1階層戻ります。v2.1.203〜v2.1.205の3バージョンだけは←がフェーズ・エージェントから戻らない不具合があり、その期間はEscを使う必要があります。

起動前に承認する流れは権限モードで変わる

ワークフローを起動する前の承認ダイアログは、セッションの権限モードによって出るタイミングが変わります。

承認ダイアログではCtrl+Gでスクリプトをエディタで開いて中身を確認でき、Tabで依頼文をその場で調整できます。ultracodeがオンのセッションでは、この承認自体がスキップされます。

実行規模とコストをどう制御するか

workflowSizeGuidelineは、Claudeがワークフローを書くときに目安にするエージェント数の指針です。強制的な上限ではなく助言なので、依頼内容がその規模を超えると判断すれば、指針より大きいスクリプトが書かれることもあります。

これはClaudeが書くスクリプトの目安であり、実際にランタイムが同時に走らせられる数はさらに絞られます。同時実行は最大16体まで(CPUが少ない環境ではさらに少なくなります)、1回の実行全体で合計1,000体までという上限があります。largeの50体未満という指針は、この同時実行数の上限とは別の話です。

/config workflowSizeGuideline=small

25体を超えるエージェントが予定されるか、消費トークンの見込みが150万を超えると、入力欄下のタスクパネルにLarge workflowという警告が出ます。これは実行を止めも制限もしない助言的な表示で、/workflowsを開いて手動で止める判断材料になります。自分でサイズ指針を選んでいる場合は、その値の上限がこの25という閾値に置き換わります。ultracodeがオンのセッションでは、そもそも大規模実行に同意済みという扱いで、この警告自体が出ません。

モデルのコストも見落とせません。各エージェントは既定でセッションと同じモデルを使うため、普段は軽いモデルに切り替えている場合は/modelを大きい実行の前に確認します。組織のavailableModels許可リストが台本の要求するモデルを止めるときは、置き換えられたモデルで実行が続き、進捗ビューには要求モデルと置換後モデルの両方を示す警告が出ます。

中断と再開で何が生き延びるか

同一セッション内なら、止めた実行を再開できます。ただし生き残る結果は単純な「完了 / 未完了」では決まりません。

再開のルールは2つです。1つ目、止めたときにまだ走っていたエージェントは保存されず最初からやり直しになります。2つ目、再現は起動順に従うため、キャッシュされた結果は最初に完了しなかったエージェントの手前で止まり、その後に起動した全エージェントはすでに完了していても再実行されます。

具体例で考えると分かりやすくなります。スクリプトがA・B・C・Dの順に4体を起動し、Bがまだ走っている間に止めたとします。再開するとAはキャッシュから返りますが、Bは未完了だったのでやり直し。CとDはBより後に起動したという理由だけで、止めた時点で完了済みだったにもかかわらず再実行されます。

この仕様が意味するのは、小さく分割したワークフローほど中断時の取りこぼしが少ないということです。1本の長いエージェントに処理を詰め込む書き方は、中断時の再実行コストで不利になります。

保存したワークフローを再利用する

気に入った実行のスクリプトは、/workflowsで選んでsを押し、保存ダイアログのTabで保存先を選ぶとコマンド化できます。

保存前にシンボリックリンクの検査が入ります。プロジェクト保存では.claude・.claude/workflows・保存先ファイルのいずれかがシンボリックリンクだと拒否され、個人保存では保存先ファイル自体がリンクの場合のみ拒否されます。v2.1.216より前はリンクをそのまま辿ってしまい、選んだはずの場所の外にファイルが書かれる余地がありました。

モノレポで.claude/ディレクトリが複数階層にあるケースでは、保存先の解決ルールが変わります。作業ディレクトリからリポジトリルートまでの間で、最も近い既存の.claude/workflows/に保存されます(v2.1.178以降)。同名のワークフローが複数階層にあるときは、作業ディレクトリに近い方が実行されます。

保存したワークフローにはargs引数で入力を渡せます。スクリプト側はargsというグローバル変数としてそれを読むので、対象パスや設定値を実行のたびに書き換える必要がありません。

Run /triage-issues on issues 1024, 1025, and 1030

チーム・複数リポジトリへの配布にはClaude Codeプラグインが使えます。プラグインルートのworkflows/ディレクトリにスクリプトを置くだけです。名前空間はプラグイン名で切られ、acme-toolsというプラグインにmeta.name: 'release-audit'のスクリプトを置くと/acme-tools:release-auditとして実行されます。

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)

/workflowsの拡張は大規模運用の何を変えたか

サイズ指針・ラージワークフロー警告・保存の再利用性という3つの追加が指しているのは、同じ方向です。ダイナミックワークフローは「Claudeに丸投げして結果を待つ」機能から、規模とコストを事前に絞り繰り返す作業をコマンド化して配る運用の道具に寄っています。

象徴的なのがサイズ指針の既定変更です。v2.1.202では選択式のオプションとして追加され、v2.1.219で「何も選ばなければmedium(15体未満)」という既定に変わりました。指針なしで際限なく広がる実行を標準にしないという判断です。この変更は、想定より大きく広がった実行がコスト面で問題になった運用が一定数あったことをうかがわせます。

もう一つの手がかりは、args引数とプラグイン配布の組み合わせです。単発の依頼で終わらせず、保存してチームに配る前提の機能追加が続いている点は、ダイナミックワークフローが研究プレビューの実験機能から、繰り返し使う運用資産へ位置を移していることを示しています。

運用でつまずきやすい点

サイズ指針を上限だと思って安心する

workflowSizeGuidelineはあくまで助言です。依頼内容が明らかに大規模な処理を要求すると、指針を超えるスクリプトが書かれることがあります。指針だけに頼らず、大きな実行の前には/modelとスコープを自分でも確認します。

大きなフェーズの途中で止めてしまう

中断と再開のルールにより、フェーズの途中で止めると、止めた時点で完了していたエージェントまで再実行される場合があります。止めるなら、フェーズの区切りが分かるタイミングを狙います。

プロジェクト保存がシンボリックリンクで拒否される

dotfilesツールで.claudeをシンボリックリンク管理している場合、プロジェクト保存はリンクを検出して拒否されます。個人保存(~/.claude/workflows/)ならリンク先ファイル自体がリンクでない限り書き込めるため、回避策になります。

モノレポで意図しないワークフローが実行される

作業ディレクトリに近い.claude/workflows/が優先されるため、階層の異なる同名ワークフローを作業ディレクトリ次第で意図せず切り替えてしまうことがあります。同名を複数階層に置く運用は避けるのが無難です。

よくある質問

workflowSizeGuidelineは/configと設定ファイルのどちらが優先されますか?

v2.1.219以降、設定ファイルでworkflowSizeGuidelineを指定するとその値が優先され、/configの行自体が非表示になります。設定ファイルが値を提供していない間だけ/configから選べます。

Large workflow警告が出たら実行は止まりますか?

止まりません。あくまで助言的な表示で、/workflowsから手動で止めるかどうかを判断する材料です。

保存したワークフローの実行順序をチームで揃えるには?

.claude/workflows/をプロジェクトへ保存すればリポジトリをcloneした全員に配られます。モノレポでは、共有したい階層の.claude/workflows/に保存先を揃えることで、階層違いによる意図しない切り替えを避けられます。

組織のモデル許可リストでブロックされるとどうなりますか?

台本が要求したモデルの代わりに、サブエージェントと同じ置換ルールでモデルが差し替えられます。進捗ビューには要求モデルと実際に使われたモデルの両方が警告として表示されます。

まとめ

/workflowsビューは、v2.1.154の研究プレビュー公開以降、サイズ指針・保存時の安全性チェック・args引数・プラグイン配布と、運用に必要な制御を積み重ねてきました。中でも中断・再開の仕様は見落とされがちで、フェーズの途中で止めると完了済みのエージェントまで再実行される点を踏まえておくと、大規模な実行での無駄なコストを避けられます。日常的に数十体規模のワークフローを回すなら、workflowSizeGuidelineの既定値とLarge workflow警告の閾値を自分の運用に合わせて調整しておく価値があります。