Claude Codeで同じ作業を一定間隔で繰り返したい初心者向け
Hugoの本番ビルドや大きなテストの完了を5分おきに確認したい時、PRのCI状況とレビューコメントを自己ペーシングで見張りたい時、プロジェクト固有のチェック項目を.claude/loop.mdに書いて毎日巡回させたい時に、開いているセッション内で叩く。クラウド永続実行が必要な場合は/loopではなくRoutinesかDesktop scheduled tasksに切り替える。
/loopは、開いているClaude Codeのセッション内で、同じ指示を一定間隔で繰り返し叩き続けるための組み込みskillです。長時間ビルドの完了を待つ、PRのCIを見張る、レシピ記事の品質チェックを定期巡回させる、そういう「合間に何度も確認したい作業」を手放すための仕組みです。
公式上のもう1つの呼び名は/proactiveで、機能はまったく同じです。他人の記事やドキュメントで/proactiveを見かけても、別物ではなく/loopの別名だと覚えておけば混乱しません。
大事なのは、これがセッション内ローカル限定という点。ターミナルを閉じればその瞬間に止まります。永続スケジューラではありません。
噛み砕くと
会議室で誰かに「5分おきにビルド画面のぞいて、終わったら教えて」と頼むイメージです。頼んだ相手はその会議室にいる間だけ動いてくれます。あなたが会議室を出れば、相手も仕事をやめます。/loopはまさにこれ。
クラウド上で勝手に動き続ける常駐ロボットではない。
この距離感を最初に掴むかどうかで、使いこなせるか/裏切られるかが決まります。
大事な前提：開いているセッションの中だけで動く
動くのはClaude Code v2.1.72以上で、なおかつセッションが開いていて、Claudeが手すきの間だけです。CIに頼んで放置しておくものとは性格が違います。--resumeや--continueで同じ会話を呼び戻せば、作成から7日以内のループは復元されます。ここは結構ありがたい挙動。逆に新しい会話を始めた瞬間、ループは全部消えます。
「料理ブログをHugoでビルド中」を例に、実際の手順を見る
私はcooking-blogというフォルダで、Hugoという静的サイトジェネレータを使って料理ブログを組んでいる、という設定で進めます。レシピ記事を数百本まとめて本番ビルドすると、終わるまで時間がかかる。その間、5分おきに状況を見てもらいます。
ステップ1: 別ターミナルで本番ビルドを走らせる
まず1つ目のターミナルでビルドを走らせる。
$ cd ~/projects/cooking-blog
$ hugo --minify > build.log 2>&1 &これでHugoは裏で動き続け、画面の制御は私の手元に戻ってきます。出力はbuild.logに流れていく。
ステップ2: 別ターミナルでClaude Codeを起動して/loopを叩く
同じcooking-blogフォルダでclaudeを起動して、こう入力します。
/loop 5m build.log の最後の30行を tail で見て、ビルドが終わったかどうか報告して。エラーがあれば該当行と修正案も出して。Claudeは「5mを*/5 * * * *のcron式に変換した。8文字のジョブIDで登録した」と返してきます。これで5分ごとにこの指示が走り続けます。
ステップ3: ループが回っている間、私は他の作業をやる
同じClaudeセッションの中で、別のタスクを話しかけても大丈夫です。/loopの発火は「Claudeのターン間」に挟まる設計なので、私が会話している最中に割り込んで返事が壊れる、ということは起きません。
ただし、私の長いリクエストを処理中に発火タイミングが来ると、Claudeが手すきになるまで待たされます。1回の遅れは1回ぶんで、たまった回数まとめて発火することはありません。
ステップ4: ビルドが終わったらEscでループを止める
Claudeが「ビルド完了、エラー0件、生成ファイル247本」と報告してきたら、次の発火を待っている間にEscを1回押します。ペンディング中のwakeupがクリアされて、それ以上発火しなくなります。
これは「会話越しにキャンセル指示を出す」のとは別の経路です。Escは/loop専用のショートカット。自然言語で「あのジョブやめて」と頼んだ場合は別のフローになります。
ステップ5: 席を立つ場合の挙動を理解しておく
ここで初心者がやりがちな勘違いがあります。/loopを仕掛けたまま安心してターミナルを閉じると、ループも一緒に消える。クラウド上で勝手に動き続ける、と思い込まないこと。
翌朝までずっと監視してほしい用途なら、/loopではなく後述のRoutines（クラウド側）かDesktop scheduled tasksに切り替える、というのが公式の推奨ルートです。
ステップ6: 私のペースで動かしたい時はintervalを省く
間隔を私が決めずに、Claudeに「状況見ながら自前で間隔を選んで」とお願いすることもできます。
/loop hugo build.log を見て、進捗が止まっていたら原因を調べてこのとき、Claudeは1分〜1時間の範囲で次回までの待ち時間を毎回選び直します。ビルドが活発に流れている時は短く、何も起きてない時は長く、という具合に。各イテレーションの末尾に「次は◯分後、理由は◯◯」と表示されます。
つまり /loop は何をしてくれるのか
- やってくれる: 開いているセッション内で、同じ指示を1分単位の間隔で繰り返し実行。intervalを省略すれば自己ペース調整、promptを省略すればプロジェクト固有の巡回（後述の
.claude/loop.md）か組み込みのメンテナンスチェックを回す - やってくれない: セッションを閉じても動き続けること、別マシン/クラウドで永続的に走ること、見逃した発火を後からまとめて取り戻すこと
- 意味が薄い場面: 「明日の朝9時に1回だけリマインドして」程度の単発用途。これは
/loopでなく自然言語で「明日9時にプッシュをリマインドして」と頼む方が公式推奨ルート
.claude/loop.mdを置いておくと挙動が変わる
プロンプトを省略して/loopだけを叩いた時、プロジェクト直下に.claude/loop.mdがあれば、その中身がプロンプト代わりに使われます。無ければユーザーホームの~/.claude/loop.mdが次に参照され、それも無ければ組み込みのメンテナンスチェック（未完了の作業の継続/現在ブランチのPR世話/簡単な掃除作業）が走ります。
料理ブログ題材だとこういう内容を置いておくと便利です。
記事フォルダ content/recipes 配下の .md ファイルを巡回し、
frontmatter に title / date / thumbnail のいずれかが欠けている記事を一覧化。
画像参照のうち alt 属性が空のものも検出して、ファイル名と該当行を報告。
全部問題なければ「異常なし」と1行で返す。こうしておくと、料理ブログを開くたびに/loop1発で雑チェックが回り続けます。25,000バイトを超えた分は切られるので、長くなりすぎないこと。
使いどころ3シナリオ（具体題材で再現）
シナリオ1: 長時間ビルドの完了監視
料理ブログのレシピ記事を500本まとめてhugo --minifyするとき、完了まで10〜20分かかります。/loop 5m build.log の最後を見て進捗報告で、その間に私は別のhost記事の校正に取り掛かれます。終わったらClaudeが報告してくれるので、私はEscでループを切ってデプロイ作業に移る。これが一番出番の多い形です。
シナリオ2: 自己ペーシングでPRをbabysitする
レシピ画像をWebPに一括変換するPRを出した直後、CIの結果と他メンバーのレビューコメントが気になります。/loop CIの状況とPR #42の新規コメントをまとめてで、Claudeが状況に応じて1分〜1時間で次の確認タイミングを選びます。動きがある時は短く、静かなら長く、という調整を勝手にやってくれる。これは私がintervalを決めるより楽です。
シナリオ3: プロジェクト固有チェックを.claude/loop.mdで常設
料理ブログのように記事数が多くなる案件では、frontmatter漏れ・画像alt欠落・公開予約日逆行などの「ありがち事故」を.claude/loop.mdに巡回項目として書いておきます。毎朝claudeを立ち上げて/loop 30mとだけ打てば、その日の作業中ずっとバックグラウンドで品質チェックが回り続ける。私はチェック内容を覚えていなくていい、というのが大きい。
初心者が踏みやすい落とし穴
- ターミナルを閉じても動き続けると勘違いする。これが一番多い誤解です。
/loopはセッション内ローカル限定。クラウドではない。閉じれば止まる。終わってないと困る用途なら、AnthropicがホストするRoutines、私のマシンで永続化するDesktop scheduled tasks、CI連動のGitHub Actionsのいずれかに切り替える - permanentなcronだと思い込む。仮にセッションを開き続けても、登録から7日経つと自動的に消えます。最後の1回が発火してから自己削除される設計。長期運用は別ツールに任せる
- promptを省略すると何も起きないと誤解する。実際は
.claude/loop.mdがあればそれが走り、無ければ組み込みのメンテナンスチェックが走ります。「無反応」ではなく「別のものが回ってる」 - intervalを極端に短くしてレートに当たる。1分が最小ですが、毎分Claudeにフル思考させると、コンテキストもAPIコストもあっという間に膨らみます。ビルド監視なら5〜15分、PRウォッチなら自己ペーシング推奨
- 破壊的な指示を入れたまま放置する。
/loop 10m 不要そうなファイルを削除しておいてのような頼み方は事故のもと。組み込みメンテナンスプロンプトは「会話の流れで既に許可された範囲の不可逆操作だけ」に限定する設計ですが、私が書いたプロンプトはこの安全弁の外。書き込み・削除を任せるなら、最低でも「事前に確認してから」と1行入れる - 新しい会話を始めて全部消す。
/clearや新規セッションは登録されたタスクをまるごと消します。継続したいなら--resumeで同じ会話を呼び戻す。これを知らずに/clearで「コンテキスト軽くしよう」と思ったら、走らせてたループまで全部消える事故になります - Bedrock/Vertex/Foundry環境での挙動差を見落とす。これらのプラットフォームでは、promptなし
/loopはメンテナンス起動ではなくusageメッセージ表示に切り替わります。intervalなしのpromptありも10分固定。Anthropic直結APIと前提が違うので、職場で違うバックエンドを使っているなら必ず確認 /proactiveは/loopの別名。公式コマンド表にAlias: /proactiveと明記されています。他人の手順書やブログで/proactive 5m ...と書かれていても別の新コマンドではなく、/loopとまったく同じ動作。どちらで叩いても結果は同じです
書き方
/loop [間隔] [指示文]（エイリアス: /proactive）やってみるとこうなる
入力
/loop 5m build.log の最後の30行をtailで見て、ビルドが終わったかどうか報告して出力例
Created scheduled task (ID: a3f9c2b1)
Schedule: */5 * * * * (every 5 minutes)
Prompt: build.log の最後の30行をtailで見て、ビルドが終わったかどうか報告して
[5分後の最初のイテレーション]
build.log末尾を確認しました。
現在 page 312/500 を生成中。エラー行なし。
次回は5分後に再確認します。このページに出てきた言葉
- セッション
- Claude Codeを起動してから抜けるまでの、ひとつの会話の固まり。<code>claude</code>と打って入って<code>/exit</code>で抜けるまでが1セッション
- cron式
- 「いつ動かすか」を5つの数字（分・時・日・月・曜日）で書く定型書式。<code>*/5 * * * *</code>なら「5分おきに毎回」
- イテレーション
- ループの1周。<code>/loop</code>がプロンプトを1回実行するたびに1イテレーション
- frontmatter
- Markdownファイルの先頭に書く記事の属性メモ。タイトル・日付・サムネ画像などをYAMLで並べる
- Hugo
- Markdown記事をHTMLサイトに変換する、軽量の静的サイトジェネレータ
- CI
- コードを変更するたびに自動でテストやビルドを走らせる仕組み。GitHub上の緑/赤チェックがこれ
- wakeup
- 次の発火予定。Escで止められるのはこの「次回ぶん」だけで、既に実行中のターンは止まらない
- Routines
- Anthropic側のクラウドインフラで永続的にプロンプトを定期実行する仕組み。<code>/loop</code>と違いマシンを閉じても動き続ける
- /proactive
- <code>/loop</code>の別名（エイリアス）。公式コマンド表に <code>Alias: /proactive</code> と明記されている、同じ機能の呼び出し方