🎯 はじめに
「Claude Code に指示を出す → 終わる → また指示を出す」の往復に疲れていませんか。
v2.1.55（2026-02-25）から v2.1.251（2026-08-28）までの半年で、Claude Code を人間の入力なしに動かし続けるための道具が4つ揃いました。
/goal すべてのテストがグリーンになるまで
/loop 5m check if the deploy finished
/goal は「完了条件」を渡してターンを跨いで自走させるもの。/loop は「一定間隔で繰り返す」もの。似ているようで用途がまったく違います。
本記事では /goal / /loop / Cron / Workflow の4つを、それぞれ何のための道具なのか整理して使い分けを示します。
📌 3行まとめ
-
/goal（v2.1.139）は完了条件を渡してターンを跨いで自走させる。/goal clearで解除 -
/loop（v2.1.71）は一定間隔での繰り返し。間隔を省略すると Claude が自分でペースを決める - Workflow は複数エージェントを決定論的にオーケストレーションする仕組み。既定は「15エージェント未満」の medium ガイドライン（v2.1.219）
1️⃣ /goal — 完了条件を渡して自走させる
v2.1.139（2026-05-11）で追加されました。CHANGELOG の説明はこうです。
Added
/goalcommand: set a completion condition and Claude keeps working across turns until it's met.
構文
/goal [condition|clear]
| 指定 | 挙動 |
|---|---|
/goal <条件> |
その条件が満たされるまでターンを跨いで作業を継続 |
/goal |
現在の（または直近達成した）ゴールを表示 |
/goal clear |
ゴールを解除 |
解除は clear のほか stop / off / reset / none / cancel でも通ります。
使いどころ
/goal npm test がすべてグリーンになり、lint エラーがゼロになるまで
重要なのは「条件」を書くことです。 タスクの手順ではなく、何をもって完了とみなすかを渡します。Claude はターンが終わるたびにその条件を評価し、満たされていなければ次のターンを自分で始めます。
実行中は経過時間・ターン数・トークン数がオーバーレイパネルにライブ表示されるので、暴走に気づけます。
対話セッションのほか -p（print モード）と Remote Control でも動作します。
v2.1.246 で挙動が調整されました。アイドル状態のセッションが長時間バックグラウンド作業をチェックしに行く回数が、1つのゴールあたり最大3回までに制限されています。あなたが次のメッセージを送ると、さらに3回分が許可されます。無限に確認し続けてトークンを溶かす事故への対策です。
2️⃣ /loop — 一定間隔で繰り返す
v2.1.71 で追加。エイリアスは /proactive です。
構文
/loop [interval] [prompt]
| 指定 | 挙動 |
|---|---|
/loop 5m check if the deploy finished |
5分おきに指定プロンプトを実行 |
/loop check the CI |
間隔を省略 → Claude が自分でペースを決める（dynamic mode） |
/loop |
組み込みのメンテナンスプロンプト、または loop.md を実行 |
停止は /exit または /quit でセッションを終了します。
/goal との違い
/goal |
/loop |
|
|---|---|---|
| 駆動するもの | 完了条件 | 時間間隔 |
| 終わり方 | 条件が満たされたら終了 | セッションを閉じるまで続く |
| 向いている用途 | 「直しきる」作業 | 「監視し続ける」作業 |
「テストを直しきってほしい」は /goal、「デプロイが終わったか見張ってほしい」は /loop です。
半年での改善
| バージョン | 内容 |
|---|---|
| v2.1.85 |
/loop や CronCreate が発火した際、トランスクリプトにタイムスタンプマーカーが入るように |
| v2.1.113 | Esc で保留中の wakeup をキャンセルできるように。wakeup が "Claude resuming /loop wakeup" と表示されて分かりやすく |
| v2.1.243 |
/usage に Loops ブレークダウンを追加。ループごとの実行回数・総トークン・1回あたりトークン・最終実行を表示 |
| v2.1.243 | やることが無い連続 wakeup が、1行にまとめて表示されるように |
| v2.1.248 | self-paced dynamic mode と no-prompt autonomous default が、Bedrock / Vertex / Foundry でも常時利用可能に |
/loop は放っておくとトークンを食い続けます。v2.1.243 で追加された /usage の Loops ブレークダウンで、「1回あたり何トークン使っているか」を必ず確認してください。CHANGELOG も "runaway or chatty /loop tasks are easy to spot" と、暴走検知が目的であることを明記しています。
3️⃣ Cron — セッション内のスケジューリング
v2.1.71 で /loop と同時に「セッション内で繰り返しプロンプトを実行する cron スケジューリングツール」が入りました。/loop がシンプルな間隔指定なのに対し、cron はより細かいスケジュール表現ができます。
緊急停止
CLAUDE_CODE_DISABLE_CRON=1
v2.1.72 で追加された環境変数です。セッションの途中でもスケジュール済みジョブを即座に止められます。設定を書き換えて再起動、という手順を踏まずに済むので、暴走時のキルスイッチとして覚えておく価値があります。
4️⃣ Workflow — 複数エージェントの決定論的オーケストレーション
/goal や /loop が「1つのセッションを回し続ける」道具なのに対し、Workflow は複数のサブエージェントを並列・段階的に動かす仕組みです。
サイズガイドライン
ここが実運用で一番効く部分です。
| バージョン | 内容 |
|---|---|
| v2.1.202 |
/config に 「Dynamic workflow size」 設定を追加（small / medium / large）。強制上限ではなく助言的なガイドライン
|
| v2.1.219 |
既定を medium（15エージェント未満を目安）に変更。/config から別のサイズや無制限を選択可能 |
| v2.1.219 |
workflowSizeGuideline 設定キーを追加し、任意の settings ファイルから指定可能に。指定されている間は /config の行が隠れる |
| v2.1.219 | 実行中の workflow のステータスラインに現在の既定サイズを表示 |
{
"workflowSizeGuideline": "medium"
}
数十エージェントが一斉に走るとトークン消費が跳ね上がるため、既定で歯止めがかかっているという理解が重要です。
意図しない起動を防ぐ
「workflow」という単語がプロンプトに入っているだけで dynamic workflow が起動してしまう、という問題がありました。
-
v2.1.157：
/configに「Workflow keyword trigger」設定を追加し、無効化できるように - v2.1.178：トリガーを明示的な言い回し（"run a workflow"、"workflow:" など）のみに限定。単語の言及だけでは起動しなくなった。あわせて紫のシマー表示に
パフォーマンスと可視化
| バージョン | 内容 |
|---|---|
| v2.1.186 |
/workflows のエージェント詳細ビューで f キーによるステータスフィルタが使えるように |
| v2.1.196 |
/code-review workflow の5つのクリーンアップ検出器を1つに統合し、トークン使用量を約25%削減
|
| v2.1.202 |
workflow.run_id と workflow.name を OpenTelemetry 属性として出力。OTel データから workflow 実行を再構成できる
|
| v2.1.202 |
/workflows のエージェント一覧レイアウト改善（タイトル幅拡大、時刻列の分離） |
| v2.1.229 | fan-out 時に同一プレフィックスの兄弟エージェントをずらして起動し、後続がプロンプトプレフィックスのキャッシュを読めるように（CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS=0 で無効化） |
| v2.1.248 | Workflow ツールのプロンプトフットプリントを 5.7k → 約 1k トークンに削減。スクリプト作成リファレンスは workflow-authoring スキルに分離 |
v2.1.229 の stagger は地味ですが効果が大きい変更です。同じプレフィックスを持つエージェントを同時起動すると全員がキャッシュミスして満額のトークンを払いますが、ずらして起動すれば2体目以降はキャッシュヒットします。
🔭 補助ツール：Monitor
v2.1.98 で Monitor ツールが追加されました。バックグラウンドスクリプトからイベントをストリーミングするためのものです。
/loop で定期的にポーリングする代わりに、Monitor で「条件が満たされたら通知」という待ち方ができます。ポーリング回数＝トークン消費なので、待ち合わせは Monitor に寄せたほうが安上がりです。
v2.1.236 で auto mode との関係が変わりました。auto mode が有効な間は Monitor の allow ルールが脇に置かれ、Monitor コマンドは Bash コマンドと同じように分類器でレビューされます。
🧭 使い分けの指針
| やりたいこと | 使う道具 |
|---|---|
| テストを直しきってほしい | /goal |
| デプロイの完了を見張ってほしい |
/loop（または Monitor） |
| 細かいスケジュールで定期実行したい | Cron スケジューリングツール |
| 大きなリファクタを並列で分担させたい | Workflow |
| 外部プロセスの完了を待ちたい | Monitor |
組み合わせも有効です。たとえば /goal で完了条件を設定しつつ、その中で Workflow を回して並列に調査させる、といった構成が取れます。
⚠️ 自走させる前のチェックリスト
-
/usageで現在のトークン消費を把握したか（v2.1.243 の Loops ブレークダウンを確認） -
/goalの条件は手順ではなく完了条件になっているか - Workflow のサイズガイドラインは適切か（既定は medium = 15エージェント未満）
-
CLAUDE_CODE_DISABLE_CRON=1というキルスイッチの存在を知っているか - パーミッションモードは適切か（自走中は権限プロンプトに人間が答えられない）
最後の項目が特に重要です。自走させるということは権限プロンプトに誰も答えないということなので、auto mode の設定や settings.json の allow / deny ルールを事前に整えておく必要があります。
✅ まとめ
-
/goalは条件駆動、/loopは時間駆動。ここを取り違えると期待した動きになりません - Workflow は v2.1.219 で 既定 medium（15エージェント未満） のガイドラインが入り、暴走しにくくなった
- v2.1.243 の
/usageLoops ブレークダウンは、自走機能を使うなら必ず見るべきダッシュボード -
CLAUDE_CODE_DISABLE_CRON=1はセッション途中でも効くキルスイッチ
「Claude に任せて席を立つ」ための道具は揃いました。あとは止められる状態を作ってから任せるのがコツです。