個人開発の合間に、深夜のプルリクエストのレビューやエラーログの見張りを、できれば自分が寝ている間に済ませたいと思っていました。かといって、そのためだけにサーバーへ cron を仕込んで運用まで面倒を見るのは、正直重い。そんな折に Claude Code へ追加された /loop コマンドを、まさにこの「ちょっとした常駐作業」に充てて数週間まわしてみました。
結論から言うと、手軽さは期待どおりでしたが、素の cron のつもりで任せると足をすくわれる癖がいくつかありました。ここでは基本の使い方に加えて、実際に使って初めて分かった落とし穴と、どこまでを任せてどこからは別の仕組みに寄せるべきかの線引きを共有します。
/loop の基本 — 一行で繰り返しを仕込む
/loop は、指定したプロンプトやスラッシュコマンドを一定間隔で繰り返し実行するコマンドです。書き方はいたってシンプルで、間隔と実行内容を並べるだけです。
/loop [間隔] [実行するコマンドやプロンプト]
たとえば、特定のプルリクエストを2時間ごとにレビューさせたいなら、こう書きます。
/loop 2h /review-pr 1234
これでセッションが開いている間、2時間ごとに PR #1234 のレビューが自動で走ります。間隔は次の単位で指定できます。cron 構文に不慣れでも、自然言語でおおよその間隔を伝えれば解釈してくれます。
| 単位 | 表記 | 例 |
|---|---|---|
| 秒 | s | 30s |
| 分 | m | 15m |
| 時間 | h | 2h |
| 日 | d | 1d |
私が最初に組んだのは、ログ監視とテストの二つでした。
/loop 15m logs/error.log を確認して、重大なエラーがあれば要点だけ報告してください
/loop 30m テストを実行して、失敗があれば原因を調べて直してください
15分ごとにログの異常を拾い、30分ごとにテストを回す。個人開発では自分がレビュアーも運用担当も兼ねているので、こうした下ごしらえを機械に任せられるだけでも助かります。人が張り付かなくても、朝には「何が起きて何を直したか」が会話に積み上がっている——この体験自体は、想像していたとおり快適でした。
使って初めて分かった三つの癖
問題は、素の cron と同じ気持ちで任せたときに現れました。次の三点は、ドキュメントを読んで頭で理解していたつもりでも、実際に取りこぼしてから体で覚えたものです。
セッションを閉じると全部消える
/loop のタスクが動くのは、Claude Code が起動していて、かつアイドル状態のときだけです。ターミナルを閉じたり、セッションが終わったりすると、登録していたタスクはまとめてキャンセルされます。私は一度、ノートPCを閉じて出かけたつもりが、帰宅後に「何も動いていない」ことに気づきました。サーバー上で回る cron のように、マシンを離れても走り続けてくれるわけではありません。常駐させたいなら、端末を開いたまま・スリープさせない前提で組む必要があります。
3日で自動的に消える
タスクには作成から3日という有効期限があります。最後に一度実行されたあと、静かに削除されます。「一度組めばずっと動く」と思い込んでいると、週明けにタスクが消えていて戸惑うことになります。恒久的に回したい処理には向きません。あくまで、いまこの数日の作業を軽くするための道具、と割り切るのが正解でした。
アイドル時しか発火しない
Claude Code が別の作業で忙しいと、スケジュールされたタスクはその隙間を待ちます。込み入った実装を対話でお願いしている最中は、15分間隔のログ監視がきっちり15分ごとには来ません。厳密な時刻保証が要る処理——たとえば「毎時0分に必ず集計する」といった約束——には使わないほうが安全です。
本物の cron・サーバー側の定期実行と使い分ける
これらの癖を踏まえると、/loop の得意分野がはっきりしてきます。私は次の基準で振り分けるようにしました。
- 数日で終わる・手元にいる間だけでいい作業 →
/loopに任せる（PRの下見、ログの拾い読み、書きかけコードの軽い点検） - 端末を閉じても動き続けてほしい → サーバーの cron / CI に寄せる
- 実行時刻を厳密に守りたい →
/loopは避ける（アイドル待ちでずれる） - 失敗を確実に人へ通知したい → 監視は別系統に持たせる（
/loopはセッションが死ぬと通知ごと消える）
言い換えると、/loop は CI/CD の置き換えではなく、対話セッションのかたわらで雑用をこなしてくれる相棒です。この線引きさえ間違えなければ、日々の細かな繰り返しはずいぶん軽くなります。
なお、スケジュールしたタスクが「止まっているのか、ただ順番を待っているだけなのか」を見分けたい場面もよくあります。応答が返らないときの切り分けについては、Claude が応答しない・止まるときの見分け方 に別途まとめていますので、あわせて役立てていただければ幸いです。
次の一歩
もし試すなら、いきなり本番の作業を預けず、まずは害のない読み取り系——logs/error.log の監視のような、失敗しても壊れない一つのタスクから始めてみてください。数日回してみると、アイドル待ちのずれや3日での消滅といった癖が、身をもって分かります。そのうえで「端末を閉じても続けたいもの」だけをサーバー側へ引き上げていくと、/loop とサーバー cron の役割分担が自然と決まっていきます。
私自身、最初はこれ一つで夜間運用を全部まかなえると期待して、見事に取りこぼしました。同じ回り道をせずに済む方が一人でも増えればと思い、つまずいた順に書き残しておきます。