Claude Codeの/loop — セッションを開いたまま繰り返しタスクを回す

こんな場面で使う

デプロイの完了待ち、CIの通過待ち、レビューコメントへの対応、長時間ビルドの監視など、「終わるまで席を外したいが、終わったらすぐ気づきたい」作業が対象です。人が画面を覗きに戻る代わりに、Claude自身が状況をポーリングして結果を報告します。

1回限りのリマインダーなら/loopは要りません。「45分後にテストが通ったか確認して」と自然言語で頼めば、単発で発火するタスクとして登録されます。書き方は一回きりのリマインダーの記事にあります。

Claude Codeの/loopは何をするコマンドか

/loop(エイリアス/proactive)は、セッションを開いたまま同じプロンプトを繰り返し実行するバンドル済みSkillです。待機と再開はClaudeが受け持つので、人が毎回指示を打ち直す必要はありません。間隔とプロンプトはどちらも省略でき、何を渡すかで挙動が変わります。

タスクは実行中のセッションに紐づき、セッションが終わると発火が止まります。/loopはスラッシュコマンドとして使うSkillで、v2.1.287のclaude --helpのオプション一覧にはloopもcronもscheduleも出てきません。

/loop 5m デプロイが終わったか確認して結果を教えて

/loopに渡す間隔とプロンプトで挙動がどう変わるか

渡す情報の組み合わせは3パターンです。

/loop 20m /review-pr 1234のようにスキルを渡すこともできます。ただし自動実行されるのは、Claudeが自分の判断で呼び出せるスキルだけです。次のものは実行されず、ただのテキストとしてClaudeに渡ります。

• /permissions、/model、/clearのような組み込みコマンド
• disable-model-invocation: trueが付いたSkill(バンドル済みの/verifyを含む)
• skillOverridesで隠されたSkillや、Skillのdenyルールで拒否されたSkill
• /mcp__github__list_prsのようなMCPプロンプト

固定間隔で回すとき

間隔を渡すと、Claudeはそれをcron式に変換してジョブを登録し、実行間隔とジョブIDを返します。間隔は30mのように先頭に置いても、every 2 hoursのように文中に置いても構いません。単位は秒s・分m・時h・日dです。

cronの最小粒度は1分なので、秒指定は切り上げられます。7mや90mのようにcronのステップにきれいに乗らない間隔は、最も近い有効な間隔に丸められ、Claudeがどれを選んだか伝えます。cron式そのものの書き方はcron式リファレンスにまとめています。

間隔を省略したとき — 自己ペース実行

間隔を省略すると、Claudeは固定cronではなく、毎回の結果を見て次の待ち時間を1分から1時間の範囲で自分で決めます。ビルドの終盤やPRが動いている間は短く、何も進んでいなければ長く、という具合です。選んだ待ち時間と理由は、各実行の最後に表示されます。

CIの通過とレビューコメントへの対応を見張る例です。

/loop CIが通ったか確認してレビューコメントがあれば対応して

Monitorツールが使えるセッションで自己ペースの/loopを頼むと、Claudeがこのツールを直接使うことがあります。バックグラウンドスクリプトの出力を1行ずつ受け取るので、ポーリング自体が要らなくなり、間隔実行より省トークンで応答も速くなりやすい方式です。

組み込みのメンテナンスプロンプトは何をするか

プロンプトを省略した/loopは、毎回の実行で次の順に作業を進めます。

1. 会話に残っている未完了の作業を続ける
2. 現在のブランチのプルリクエストの世話をする(レビューコメントへの対応・失敗したCIの調査・マージコンフリクトの解消)
3. どちらも片付いていれば、バグ探しや簡略化のようなクリーンアップに着手する

この範囲を超える新しい取り組みは始めません。pushや削除のような取り消しづらい操作は、トランスクリプトがすでに許可した内容の延長でしか実行されません。

loop.mdで既定プロンプトを差し替える

.claude/loop.md(プロジェクト単位)か~/.claude/loop.md(ユーザー単位)を置くと、引数なしの/loopが実行する組み込みプロンプトを自分の指示に差し替えられます。両方あるときは、プロジェクト単位が優先です。どちらも無ければ、組み込みのメンテナンスプロンプトに戻ります。

ファイルは構造の決まりがない通常のMarkdownで、/loopに直接打ち込むつもりの指示文をそのまま書きます。公式の例は、リリースブランチのPRを見張る内容です。

Check the `release/next` PR. If CI is red, pull the failing job log,
diagnose, and push a minimal fix. If new review comments have arrived,
address each one and resolve the thread. If everything is green and
quiet, say so in one line.

編集内容は次の周回から反映されるので、動かしながら指示を直せます。25,000バイトを超えた分は切り詰められます。

loop.mdが定義するのは「引数なしの/loopの既定プロンプト1つ」で、別々のスケジュールを並べる一覧ではありません。コマンドラインでプロンプトを渡した場合も無視されます。別のプロンプトを並行して動かすなら、/loop <プロンプト>を使うか、Claudeに直接頼んで登録します。

/loopを止める・管理する

自己ペースの/loopは、待機中にEscを押すと保留中の予約が消え、それ以降は発火しません。一方、固定間隔のループや、Claudeに直接頼んで登録したタスクはEscの影響を受けず、削除するまで残ります。

一覧の確認とキャンセルは自然言語で頼めます。

どんなスケジュールタスクが動いていますか

デプロイ確認のジョブをキャンセルして

裏ではCronCreate(登録)・CronList(一覧)・CronDelete(ID指定で削除)の3つのツールが動いています。

7日を超えて動かすなら、期限前に作り直すか、RoutinesやDesktopスケジュールに移します。スケジューラそのものを止めたいときは、環境変数CLAUDE_CODE_DISABLE_CRON=1を使います。/loopもcronツールも使えなくなり、登録済みのタスクも発火しなくなります。詳しくはCLAUDE_CODE_DISABLE_CRONの記事で扱っています。

指定した時刻にぴったり動くのか

動きません。全セッションが同じ時刻にAPIへ集中しないよう、スケジューラは発火時刻にタスクIDから決まる固定のずれ(ジッター)を足します。

• 繰り返しタスクは、予定時刻から最大30分後まで遅れて発火します。1時間未満の間隔なら、遅れるのは間隔の半分までです
• 毎時00分・30分に予定した単発タスクは、最大90秒早く発火します
• 時刻を厳密にしたいときは、0 9 * * *でなく3 9 * * *のように00分・30分以外を指定すると、単発タスクのジッターは付きません
• 自己ペースの/loopは、待ち時間をClaudeが毎回決める性質上、ジッターの規則自体が対象外です

時刻はすべてローカルのタイムゾーンで解釈されます。0 9 * * *はUTCではなく、Claude Codeを動かしている場所の9時です。

再開したとき何が残り、何が消えるか

「--resumeで復元される」は、すべてのタスクに当てはまるわけではありません。v2.1.287のclaude --helpは、-c, --continueを「現在のディレクトリで直近の会話を続ける」、-r, --resume [value]を「セッションIDを指定して再開する、または絞り込み語つきでピッカーを開く」と説明しています。このときタスクの種類で扱いが分かれます。

もう1つ、見落としやすい点があります。最初のプロンプトが/loopだったセッションは、--continueの復帰先から外れ、セッションピッカーにも出てきません。/loopで始めたセッションを後から探すときに効く挙動です。会話の途中で/loopを打った場合は隠れません(v2.1.211より前は、途中で打っても隠れ続けました)。claude -p --continueなら、/loopで始まったセッションも対象に含まれます。

/loop・Routines・Desktopスケジュールはどう違うか

Claude Codeには繰り返し・定期実行の手段が3つあります。動く場所と持続性が異なります。

マシンを閉じても確実に動かしたいならRoutines、ローカルファイルが要るならDesktopスケジュール、開いているセッションでその場の様子を見たいなら/loopです。Claude Code Routinesはクラウドで動き、Desktop側の設定手順はDesktopスケジュールの記事にあります。

Desktopスケジュールにも癖があります。アプリが起動していてPCが起きている間だけ動き、スリープ中に過ぎた時刻の実行はスキップされます。スキップは履歴に残るので、理由(PCがスリープしていた、前の実行がまだ続いていた、など)を後から確かめられます。

アプリの起動時やPCの復帰時には、直近7日の取りこぼしのうち最新の1回だけが補完実行され、それより古い分は破棄されます。/loopは見逃した回を補完しないので、ここが違いになります。設定のDesktop app → Generalにある「Keep computer awake」を有効にすると、アイドル時のスリープを防げます。ノートPCのふたを閉じた場合はスリープします。

/loopの制約

セッション単位の仕組みであるがゆえの制約が4つあります。

1. アイドル状態でしか発火しない: Claudeが応答中に時刻が来ても、その場では実行されず、今のターンが終わってから発火します。スケジューラは1秒ごとに期限を確認し、低い優先度でキューに積みます
2. 見逃した回の埋め合わせはしない: 長い応答でスケジュール時刻を何度も過ぎても、アイドルに戻った時点で1回だけ実行されます
3. ターミナルを閉じると止まる: セッションが終われば、タスクの発火も止まります。継続したいなら、再開の節のとおり--resumeか--continueで再開します。セッションをバックグラウンド化した場合は、/loopのタスクがバックグラウンドセッションへ引き継がれ、ターミナルなしで動き続けます
4. 機能フラグの取得を切ると、保存先の癖が出る: feature-flag fetchingがオフのとき、「セッションをまたいで残して」と頼んだタスクはプロジェクトの.claude/scheduled_tasks.jsonに保存されます。.claudeディレクトリやこのファイルがシンボリックリンクだと、スケジュールがエラーになります。保存されたタスクは、作成したプロジェクトのフォルダでしか動かず、新しいworktreeなど別のフォルダへファイルをコピーしても、一覧に出るだけで実行されません

フラグ取得を止める環境変数には、DISABLE_TELEMETRYやCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICなどがあります。DISABLE_GROWTHBOOKやDO_NOT_TRACKを設定した場合も同じです。Amazon Bedrockなどサードパーティプロバイダーのセッションも取得を止めるので、テレメトリを切っている環境やそうしたプロバイダーでは、ここで挙げた保存の挙動が当てはまります。

もう1つ、クラウド系のプロバイダーでの違いがあります。Amazon Bedrock、Claude Platform on AWS、Google CloudのAgent Platform、Microsoft Foundryでも、間隔なしの自己ペース実行と組み込みのメンテナンスプロンプトは動きます。フラグ取得をオフにしている場合を含め、どちらもv2.1.248以降が条件です。

恒久的な自動化には、GitHub Actionsのscheduledトリガーも選択肢です。

/loopと/goalは何が違うか

/loopは時間の間隔でプロンプトを繰り返します。ターンをまたいで、条件を満たすまで自走させたいなら、間隔ではなく完了条件で動く/goalが合います。CIの失敗のように「起きたら知りたい」出来事なら、ポーリングの代わりにCIから通知をセッションへ直接流し込むChannelsという仕組みもあります。