この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。

「5分おきにビルドが通ったか確認して」とClaude Codeに頼んだら、実際に監視してくれるのか。/loopというコマンドを使えば、セッションの中で決まった間隔で同じ処理を繰り返せる。Windows環境で実際に試しながら、/loopに定期チェックや繰り返し作業をどこまで任せられるかを見る。

この記事で確かめること

Claude Codeの /loop に「定期チェック」と「繰り返し作業」を頼んで、どこまで自動で進めてくれるかを確かめる。

検証条件は次の通り。

• OS: Windows 11
• 利用形態: ターミナルからClaude Codeを起動
• 入力方法: 自然文で依頼
• 検証範囲: /loopの起動〜結果確認〜修正指示〜制限事項の確認

/loopの基本的な使い方から「どこまで任せられて、どこから人が確認すべきか」までを一気に見る。/loop以外の定期実行手段（Desktop scheduled tasks、Routines、GitHub Actions、OS標準のcronなど）の詳しい設定手順は扱わない。

前提：/loopとは何か

/loop は、Claude Codeのセッション内で定期的にプロンプトを実行する仕組みだ。「5分おきに確認して」「毎時ステータスを報告して」と自然文で頼むと、指定した間隔で同じ処理を繰り返してくれる。

cronと違って式を書く必要がない。たとえば「5分おき」と言えば5分ごとに動くし、「状況が変わったら間隔を調整して」と言えば間隔を変えることもある。この「自然文で間隔を指定できる」点が、初心者にとって一番の利点だ。

対応する時間単位は s（秒）、m（分）、h（時）、d（日）。

他の定期実行手段とどう違うのか、ざっくり整理しておく。

要するに /loop は「セッションを開いている間だけ動く、手軽な定期実行」だ。セッションを閉じたら止まるし、最大でも7日で自動的に終了する。本格的な継続運用には向かないが、今の作業中に「ここだけ見張ってほしい」という場面では手軽に使える。

Step 1: 最初の依頼——定期チェックを頼んでみる

まずは最もとっつきやすいユースケースとして、ビルドの完了確認を頼んでみる。

/loop 5m ビルドが通ったか確認して報告して

この依頼文には、/loop、5mという間隔、そして「ビルドが通ったか確認して」という目的が入っている。間隔も目的も1文で伝わるので、/loopの最初の1歩としては扱いやすい頼み方だ。

ここで固定間隔と動的間隔の違いも触れておく。上の依頼文のように「5分おき」と指定すると、5分ごとに毎回実行される（固定間隔）。一方で、間隔をあえて指定せずに /loop ビルドが通ったか確認して のように頼むと、Claude Codeが状況に応じて次の実行間隔を選ぶ動きになる。固定間隔と動的間隔は、最初は分けて試す方が結果を読みやすい。

この依頼を投げると、Claude Codeは内部的にスケジュールを作成し、指定した間隔でプロンプトを自動実行する。ターミナル上では /loop が起動した旨のメッセージが表示され、その後は指定間隔で実行結果が順次出力されていく。

Step 2: 最初の結果——どこまで自動で追ってくれたか

依頼を投げた後、5分ごとにビルドの状態が報告された。初回の報告はこんな内容だった。

ビルドはまだ進行中です。現在のステータスを確認しましたが、完了していません。次のチェックまで待機します。

この出力を見ると、「ビルドが終わっていない」という事実は正しく伝わっている。ただし、「何のコマンドで確認したのか」「どの段階で止まっているのか」までは出力されていなかった。

良かった点は、指定した間隔を目安に継続して確認してくれたこと。多少のズレはあるものの、手動で何度も確認する手間は減らせた。

足りなかった点は、報告の詳細さ。ビルドの進捗段階や、最後に実行されたステップなどの情報があると、状況をより正確に把握できる。この情報は、別途ビルドログを確認すれば人の手で補える。

この段階で確認できたのは、/loopが内部で使うスケジュール管理（CronCreate、CronDelete）が正しく動いていること。登録したスケジュールは一覧で確認できるし、不要になったタイミングで削除もできる。

Step 3: 修正指示——もっと賢く監視させるには

Step 2の報告では「進捗の詳細」が足りなかった。そこで、報告内容を改善する修正指示を出す。

ビルドの進捗段階と、最後に実行されたステップも含めて報告して。
状況が変わったら間隔を調整しても構いません。

この修正には2つの狙いがあった。1つは報告に「進捗段階」と「最後のステップ」を含めることで、状況をより詳しく把握できるようにすること。もう1つは「状況が変わったら間隔を調整して」と動的間隔を許可し、ビルドが終盤に差し掛かったら確認頻度を上げるような柔軟な動きを期待したこと。

動的間隔を使うと、Claude Codeが状況を見て次の確認タイミングを選ぶことがある。ビルドが終わりに近いと判断した場合は短めに、しばらく変化がなさそうな場合は長めに待つ、といった動きになる。

修正の狙いを整理すると、「情報の詳細さ」と「間隔の柔軟さ」の両方を改善したい、という意図だった。

Step 4: 修正後の結果——監視と修正案はどこまで出せるか

修正指示後の報告は、内容が明らかに変わった。

修正前の報告は「ビルドはまだ進行中です」という一行だけだったのに対し、修正後は「現在フェーズ3のテスト実行中。最後に完了したステップはユニットテストのtest_auth.py」のように、進捗の詳細が含まれるようになった。これで手動でログを確認する頻度を減らせる。

間隔の調整も観察できた。ビルドの前半は5分ごと、テストフェーズに入ってからは3分ごとに切り替わった。状況に応じて間隔を変える動き自体は機能している。

次に、PRのビルドエラー監視も試した。ビルドが失敗した場合にエラー内容を報告させ、さらに修正案を出すところまで任せられるかを確認した。

PRのビルドエラーを監視して、エラーがあったら原因と修正案を報告して

結果として、エラーの報告はできたが、修正案の品質は一長一短だった。単純なインポートミスやタイプミス程度なら的確な指摘が出た一方で、依存関係の複雑なエラーになると「ログ全体を確認してください」といった一般的な回答になった。外部サービス（Linear等）との連携は、該当するツールが使える環境設定が済んでいれば報告の自動化ができそうだったが、今回の環境では確認していない。

修正後に別の問題が出たかというと、致命的なものはなかった。ただし、長時間動かしているとセッションのコンテキストが増えていき、後半の報告で前半と同じ簡潔さを保てなくなる場面があった。

Step 5: どこまで頼むだけでできた？

ここまでの検証結果を3段階で整理する。

比較的任せやすい
– 定間隔でのステータス報告（「5分おきに確認して」レベルの依頼）
– ビルドの完了・未完了の判定
– 指定したフォーマットでの報告

これらは依頼文がシンプルで、期待する出力も明確。特別な修正指示なしでも安定して動く。

条件付きで使える
– 進捗の詳細報告（修正指示で改善できるが、最初から詳細なフォーマットを指定した方が確実）
– 動的間隔の調整（状況によっては期待通りに動くが、判断基準がClaude Codeに委ねられる）
– 単純なエラー原因の特定（タイプミスやインポートミス程度なら正確）

「条件付き」の共通点は、依頼文の書き方で結果の質が変わること。具体的に書くほど結果が安定する。

必ず人が確認すべき
– 修正案の妥当性（特に依存関係の複雑なエラー）
– 長時間運用時のコンテキスト肥大化による報告の変化
– 外部サービスとの連携設定
– セッションをまたぐ継続的な監視

やり取りの回数は、起動から修正指示、結果確認までで計3往復程度だった。

制限事項と注意点——7日の壁とセッションの範囲

/loopにはいくつか押さえておくべき制約がある。

最大7日の有効期限
登録したスケジュールは、最長で7日間で自動的に終了する。7日を超える監視が必要な場合は、セッションを開き直して再度依頼するか、別の手段を検討する必要がある。

セッション限定スコープ
/loopは現在のセッション内でのみ動く。ターミナルを閉じたり、Claude Codeを終了したりすると、実行中のスケジュールも消える。長期的な監視には向かない。

ジッター（実行タイミングのズレ）
指定した間隔ぴったりに実行されるとは限らない。発火時刻が :00 や :30 などの丸められた時刻に近い場合、数秒〜数十秒程度のズレが生じることがある。ミリ秒単位の正確さが求められる用途には不向きだ。

タスク数の上限
1つのセッションで同時に動かせるスケジュールには上限がある。多数の監視を並行させる場合は、公式ドキュメントで最新の上限を確認すること。

--resumeでの復元
セッションを再開する --resume または --continue を使うと、期限切れになっていないスケジュールは復元される場合がある。ただし、7日を過ぎた定期タスクや、すでに実行時刻を過ぎた単発タスクは対象外になる。また、Background BashやMonitor系のタスクは復元されない。

loop.mdによるカスタマイズの可能性
.claude/loop.md を置くと、プロジェクト内で裸の /loop を実行したときの標準プロンプトを変えられる。毎回同じ監視内容を頼みたい場合には便利だが、個別の依頼文を指定して /loop 5m ... のように実行する場合は、その依頼文が優先される。

この検証の振り返り

依頼→結果→修正→限界の流れを整理する。

最初の依頼（「5分おきにビルドが通ったか確認して」）で、定期実行自体は問題なく動いた。報告の詳細さに課題があったため、修正指示で「進捗段階」と「最後のステップ」を含めるよう調整したところ、改善された。動的間隔も試し、終盤で間隔が短くなる動きを確認できた。一方で、修正案の品質や長時間運用時のコンテキスト肥大化には、人の目が届いている必要がある。

やり取りは起動→初回結果確認→修正指示→修正後結果確認の3往復。/loop自体は依頼文1回で起動するので、やり取りの大部分は「結果をどう評価するか」に使われている。

依頼文を書くときのコツ
– 間隔と目的を1文にまとめる（「5分おきに〇〇を確認して」）
– 報告に含めてほしい項目を先に書いておくと、修正指示が減る
– 「状況が変わったら間隔を調整して」と添えると、動的間隔が有効になる

/loopが向いている人
– 今の作業セッション内で「ここだけ見張ってほしい」場面がある人
– cron式を書かずに定期実行を試してみたい人
– 数時間〜数日程度の一時的な監視で十分な人

向かない人
– 週・月単位で継続的に監視したい人
– 複数のプロジェクトをまたいで定期実行したい人
– ミリ秒単位の正確な実行間隔が求められる人

Windows環境でつまずきそうなポイント
– ターミナルを閉じるとスケジュールが消えるため、長時間動かすならターミナルを開きっぱなしにする必要がある
– パス区切り文字の違いは、/loop自体の動作には影響しないが、監視対象のパスを指定する場面では注意が必要

次に試すなら

初心者がまず試すなら、次のあたりが取り組みやすい。

• デプロイの完了確認: 「3分おきにデプロイが完了したか確認して」
• テストの結果チェック: 「ビルドが終わったらテスト結果を報告して」
• ログの監視: 「1時間おきにエラーログに新しい行がないか確認して」
• ファイルの変更検知: 「10分おきに特定のファイルが更新されていないか確認して」

いずれも依頼文がシンプルで、期待する結果が明確。/loopの感覚を掴むにはちょうどいい。

関連する機能として、Claude Desktop Appの /schedule や Routines がある。/loopで「セッション内の定期実行」の感覚を掴んだ後は、セッションをまたいで定期実行したい場合にこれらを試すと良い。

環境やバージョンによっては、今後さらに進められる可能性がある。

骨組みは1回の依頼で動き、修正指示で細かい調整もできる。まずは「5分おきに〇〇を確認して」から始めて、結果を見ながら依頼文を工夫していくのが近道だ。

まとめ

/loopは、セッション内での定期チェックであれば頼むだけで十分に機能する。間隔と目的を1文で伝えれば起動し、固定間隔でも動的間隔でも動く。ただし最大7日の有効期限とセッションスコープという制約があるため、本格的な継続運用には人の管理が必要だ。制約の境界線を押さえておけば、手動確認の繰り返しを減らせる。

今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。