Claude Code の /loop を試したいが、何をどこまで任せてよいのか分からない。PR レビューコメントの追従や CI 監視を自動化したいが、長時間放置して事故るのは避けたい。そんな人向けの記事です。
/loop は「Claude を cron のようにずっと働かせる機能」ではありません。いま開いているセッションの文脈を保ったまま、数分おきに同じ仕事を見直させるための軽量な反復実行です。ここを誤解すると、Cloud の定期実行や GitHub Actions 向きの仕事まで持ち込んで破綻します。Claude Code 全体の導入順を先に整理したいなら Claude Code の使い方 実践ガイド、強制ルールの設計を詰めたいなら Claude Code Hooks の使い方 実践ガイド、セッション外の定期実行まで含めて考えたいなら Codex Automations 実践ガイド を先に読むとつながりやすいです。
先に結論: /loop は「その場の監視と追従」にだけ使う
2026年5月時点の公式 docs では、/loop は Claude Code の scheduled tasks 機能の一部で、セッションが開いている間だけ動きます。しかも recurring task は 7日で自動失効 します。つまり、恒久ジョブではなく、いま進めている作業をしばらく見張らせるための仕組みです。
私なら、/loop を使うのは次の3条件を満たす仕事だけに絞ります。
- すでに人間が目的と終了条件を決めている
- 数分から数時間の間に状態が変わる
- 失敗しても、次の iteration か人間のレビューで止められる
逆に向いていないのは、次のような仕事です。
- 端末を閉じても動き続けてほしい定期ジョブ
- 本番デプロイや課金変更のような不可逆操作
- 要件がまだ固まっていない大きな実装
- MCP や secrets を広く開けないと成立しない unattended job
この線引きを守るだけで、/loop はかなり使いやすくなります。
/loop で何ができるのか
Anthropic の scheduled tasks docs では、/loop は prompt を繰り返し再実行する最短ルートとして説明されています。使い方は大きく3つです。
1. 固定間隔で回す
/loop 5m check whether CI passed and tell me what changedこの形は最も分かりやすいです。5m 30m 2h のように間隔を先に与えると、Claude が cron 式へ変換して、その cadence で繰り返します。
向いている用途:
- CI 完了待ち
- デプロイ完了待ち
- PR に新規 review comment が付いたかの確認
2. 間隔を Claude に決めさせる
/loop check whether the release PR is still blockedinterval を省略すると、Claude が iteration ごとに待ち時間を決めます。ビルド中は短く、静かな時間帯は長くする使い方です。docs では 1 分から 1 時間の範囲で次回実行を選ぶとされています。
これは「いつ次に見るべきか」を自分で決めたくないときに便利ですが、何分おきに必ず見てほしい仕事には向きません。予測可能性が落ちるからです。
3. bare /loop を既定のメンテナンス prompt として使う
/loopprompt まで省略すると、Claude Code の built-in maintenance prompt が走ります。公式 docs では、未完了作業の継続、現在ブランチの PR の review comment / CI / merge conflict の確認、最後に cleanup pass までを順に処理するとされています。
ただし私は、この bare /loop をそのまま長く回すより、後述の loop.md で対象を絞る方が安全だと考えています。
まず覚えるべき制約
/loop を便利に使う前に、制約を先に理解した方が失敗しません。
セッション依存
公式 docs では task は current conversation に属し、新しい会話を始めると消えると明記されています。claude --resume や --continue で未失効 task は戻せますが、端末やセッションをまたいで永続する scheduler ではありません。
つまり「ノート PC を閉じても毎日動いてほしい」は /loop ではなく Cloud task や GitHub Actions の領域です。
7日で失効する
recurring task は 7 日後に最後の 1 回を走らせて自動削除されます。忘れた loop が何週間も回り続けないための安全装置ですが、長期運用の本命には向きません。
Claude が忙しい間は後ろにずれる
scheduled tasks docs では、due time に Claude が別の長い response を返しているとき、missed interval 分を全部取り返すのではなく、idle になったあと 1 回だけ走ると説明されています。
ここは重要です。/loop は厳密な監視基盤ではなく、Claude の空き時間に差し込まれる追跡タスクです。SLO 監視や強いリアルタイム性が必要な仕事には使わない方がよいです。
loop.md を使うと実務でかなり安定する
最近の公式 docs では、bare /loop の既定 prompt を loop.md で差し替えられます。置き場所は次の2つです。
.claude/loop.md~/.claude/loop.md
プロジェクトごとに違う監視をしたいなら前者、どこでも共通の個人用 default を持ちたいなら後者です。
私なら、PR babysit 用の loop.md を次のように短く書きます。
Check the current branch PR.
If CI is red, inspect the failing job and propose the smallest safe fix.
If new review comments arrived, address them one by one.
If everything is green and quiet, report that in one line.
Do not start unrelated refactors.ポイントは3つです。
- 対象を
current branch PRのように狭くする - 「何をしてよいか」より先に「何をしてはいけないか」を書く
- unrelated refactor を禁止する
公式 docs でも loop.md は 25,000 bytes を超えると切り詰められるため、長文の運用哲学を書く場所ではありません。ここでは判断の枠だけを固定すべきです。詳細な強制ルールは Claude Code Hooks の使い方 実践ガイド の Hook 側へ逃がした方が安定します。
PR レビュー自動化での現実的な使い方
検索意図として最も強そうなのは、やはり「PR レビューを自動で追いかけたい」です。ここでの実務上のコツは、PR を直させる前に review loop を作ることです。
使い始めのおすすめ prompt
/loop 15m check the current PR for failed CI, merge conflicts, and new review comments.
If there is a clear, minimal fix, make it and run the project verification command.
If the issue needs product judgment, summarize the blocker instead of guessing.この prompt でやらせたいのは、あくまで次の範囲です。
- 新規 review comment の確認
- failed CI の確認
- 明確な小修正
- 判断不能なら blocker の要約
やらせない方がよいのは、次です。
- review scope を超える設計変更
- 新しい依存追加
- 勝手な rebase や force push
- product 判断を含む仕様変更
Anthropic の power user tips でも、verification を与えることが最重要とされています。私は /loop を回す前に、必ず「修正後に何を実行して green を確認するか」を prompt に入れます。ここがない loop は、進んでいるように見えて、ただ差分だけを増やします。
Hooks と /loop は競合しない
/loop を触り始めると、Hooks と何が違うのかで混乱しやすいです。私は役割を次のように分けます。
| 仕組み | 役割 |
|---|---|
| Hooks | ツール実行前後の強制ルール |
/loop | 状態変化を数分おきに見直す追跡タスク |
たとえば、
pnpm run buildを編集後に必ず走らせたい → Hooks- build が終わったか 10 分おきに見たい →
/loop .envを触らせたくない → Hooks- PR に新しいコメントが来たら追従したい →
/loop
この切り分けにすると、/loop 側の prompt を短く保てます。強制事項まで全部 /loop に書く必要はありません。
Codex Automations や Cloud task とどう違うか
このテーマは既存の Codex Automations 実践ガイド と近そうに見えますが、実際の論点はかなり違います。
/loop を選ぶケース
- いま開いている会話の文脈を保ちたい
- ローカルファイルや現在の branch 状態をそのまま使いたい
- 数時間だけ babysit したい
- 人間が横で随時止められる方がよい
Automations / Cloud task を選ぶケース
- 端末を閉じても走らせたい
- 毎日や毎週の定期実行にしたい
- fresh clone 前提でも成立する
- inbox に review 単位で戻したい
公式 docs でも /loop は open session が前提で、Cloud task は machine が落ちても動く前提です。つまり /loop は automation の下位互換ではなく、会話に寄り添う短期の追跡 worker と見た方が正確です。
安全に使うための判断基準
ここが一番大事です。私は /loop を回す前に、最低限これを確認します。
- 終了条件を 1 文で言えるか
- 変更してよい範囲を限定できるか
- 検証コマンドを固定できるか
- 判断不能時は止まれと書いてあるか
たとえば「CI が通るまで見張る」は良い task です。「リポジトリを見て必要そうな改善を続ける」は悪い task です。後者は終わりがなく、safe boundary も曖昧だからです。
組織で配るなら、managed settings や MCP allowlist まで含めて統制しておく方がよいです。そこまで必要なら Claude Code managed settings 設計ガイド の領域です。
結論
Claude Code の /loop は、PR babysit、CI 監視、デプロイ完了待ちのような短期で状態が変わる作業にかなり向いています。逆に、永続ジョブや広い権限を必要とする unattended automation を背負わせるべきではありません。
私の結論はシンプルです。
- その場の文脈を保ったまま追いかけたい →
/loop - 端末を閉じても定期実行したい → Automations / Cloud task
- 強制ルールを敷きたい → Hooks
この3つを混ぜなければ、/loop は「なんとなく便利そうな新機能」ではなく、日常のレビュー待ちや CI 待ちを削る実用機能になります。