2026年8月28日 金曜日
AI時短ラボ
活用· 約18

Claude Codeの定期実行──/loopのEscは「直接頼んだリマインダー」を止めない

Claude Codeでプロンプトを繰り返し実行する仕組みは、セッション内の/loopと自然言語で頼む単発リマインダー、マシンで動くDesktopのローカルタスク、クラウドで動くRoutines(研究プレビュー)の系統に分かれる。公式ドキュメント(scheduled-tasks/routines/desktop-scheduled-tasks、2026年8月27日取得)を確認すると、停止操作のEscが効く範囲、7日で消える有効期限、承認プロンプトの有無がそれぞれ違うことが明記されていた。

Claude Codeの定期実行──/loopのEscは「直接頼んだリマインダー」を止めない
執筆・編集:
目次

Claude Codeで「一定間隔でプロンプトを実行し続けたい」と思ったとき、選べる仕組みは/loopだけではない。公式ドキュメントを読むと、同じ「スケジュール済みタスク」の枠の中に、/loopで作るものと、自然言語でClaudeに直接頼んで作るものが両方入っていて、この二つは停止のされ方が違う。さらにセッションの外まで見ると、マシンで動くDesktopのローカルタスクと、クラウドで動くRoutines(/schedule)という別の仕組みもある。使い分けの軸は「セッションを開いたままにできるか」「マシンの電源を切っても動かす必要があるか」「承認プロンプトなしで自動実行させてよい作業か」の3つで、以下は公式ドキュメントの記述に沿った整理である。

3行まとめ

  1. /loopと、自然言語で頼む単発リマインダーは同じ「セッション内スケジュール」の仕組み(CronCreate/CronList/CronDelete)を共有するが、待機中にEscを押して止められるのは/loopだけ。直接頼んで作ったタスクはEscの影響を受けず、削除するまで残り続けると公式に明記されている
  2. セッション内スケジュールは新しい会話を始めると全部消え、繰り返しタスクは作成から7日で自動的に期限切れになる。マシンの電源が切れていても動かしたい/会話をまたいで残したい場合は、Desktopのローカルタスクか、クラウドで動くRoutines(/schedule、研究プレビュー)に乗せ換える必要がある
  3. Routinesは承認プロンプトが一切出ない全自動実行で、Desktopのローカルタスクは実行ごとに権限モードを設定できる。「目を離しても安全に自動実行できる作業か」で、この二つのどちらに乗せるかが分かれる

「スケジュール済みタスク」は/loopだけを指す言葉ではない

公式ドキュメントの該当ページのタイトルは「Run prompts on a schedule」で、副題には次のようにある。

Use /loop and the cron scheduling tools to run prompts repeatedly, poll for status, or set one-time reminders within a Claude Code session.

つまり公式が「Scheduled tasks」と呼んでいる範囲には、/loopによる繰り返し実行と、自然言語で頼む単発リマインダーの両方が含まれる。本文でも次のように定義されている。

Tasks are session-scoped: they live in the current conversation and stop when you start a new one.

内部的には、どちらも同じ3つのツールで動いている。

ツール 役割
CronCreate 5フィールドのcron式・実行するプロンプト・繰り返しか単発かを受け取って新しいタスクを作る
CronList ID・スケジュール・プロンプト付きで、今あるスケジュール済みタスクを一覧表示する
CronDelete IDを指定してタスクをキャンセルする

各タスクには8文字のIDが振られ、1セッションで保持できるスケジュール済みタスクは最大50個と明記されている。/loopはこの仕組みの「使い方の一つ」であって、/loopイコール「スケジュール済みタスクの全部」ではない。

/loopが選ぶ3パターン

/loopは間隔とプロンプトの両方が任意で、何を渡すかで挙動が変わる。

渡すもの 挙動
間隔とプロンプト /loop 5m check the deploy 固定スケジュールで実行
プロンプトのみ /loop check the deploy 反復ごとにClaudeが選んだ間隔で実行
間隔のみ、または何もなし /loop 組み込みメンテナンスプロンプト、または存在すればloop.mdを実行

固定間隔を指定すると、Claudeがそれをcron式に変換する。ただしcronは1分単位の粒度しか持たないため、秒指定は繰り上げられ、7m90mのようにきれいなcronステップに変換できない間隔は最も近い値に丸められる。ドキュメントは「Claude tells you what it picked」と述べており、丸めが起きたことを黙って処理はしない設計になっている。

間隔を省略する「自分のペースモード」では、Claudeが1分〜1時間の範囲で毎回待機時間を選び直す。この選び直しはtools-referenceによればScheduleWakeupツールが担っており、Claudeが各反復の最後に呼び出して次回までの間隔を決める。さらにこのモードでは、ポーリングの代わりにMonitorツール(バックグラウンドスクリプトを実行し出力行をストリーミングで受け取る仕組み)を使うことがあり、公式は「often more token-efficient and responsive than re-running a prompt on an interval」としている。

プロンプトを省略した裸の/loopは、①未完了作業の継続 ②現在のブランチのPRの世話(レビューコメント・CI失敗・マージコンフリクト) ③何もなければバグハントや簡素化、の順で進む組み込みメンテナンスプロンプトを実行する。これを独自の内容に置き換えたい場合は.claude/loop.md(プロジェクト単位、優先)か~/.claude/loop.md(ユーザー単位)を置く。ファイルは25,000バイトを超えると切り詰められる。

止め方の非対称──Escが効くもの・効かないもの

ここが/loopと「直接頼んだスケジュール済みタスク」の一番はっきりした違いだ。ドキュメントの「Stop a loop」節にはこう書かれている。

To stop a /loop while it is waiting for the next iteration, press Esc. This clears the pending wakeup so the loop does not fire again. Tasks you scheduled by asking Claude directly are not affected by Esc and stay in place until you delete them.

つまり「/loop 30m ...で回しているタスク」は次回発火待ちの間にEsc一発で止められるが、「remind me at 3pm to push the release branchのように自然言語で頼んで作ったタスク」はEscを押しても何も起きない。止めるには、Claudeに「何のタスクがあるか教えて」「そのジョブをキャンセルして」と頼む(内部的にはCronListCronDeleteが呼ばれる)必要がある。

自分のペースモードの/loopには、Claude自身が終了を判断する経路もある。ScheduleWakeupstop: trueで呼ぶと即座に終了し、逆に1回の反復がスケジュール変更も終了もせずに終わった場合は、Claude Codeが約20分後のフォールバックの目覚ましを設定し、その次の反復でも何も決めなければそこでループを終了する。固定間隔の/loopは、止めるか7日が経過するまで動き続ける。

セッションが消えれば全部消える、ただし7日以内なら戻る

セッション内スケジュールは会話に紐づく。新しい会話を始めると/loopも直接頼んだリマインダーも全部消える。--resumeまたは--continueで再開した場合は、期限切れになっていないタスク(作成から7日以内の繰り返しタスク、まだ発火時刻が来ていない単発タスク)だけが復元される。バックグラウンドのBashタスクやMonitorタスクは、再開時には復元されないと明記されている。

繰り返しタスクは作成から7日で自動的に失効する。最後にもう1回だけ発火してから自身を削除する仕組みで、公式は「This bounds how long a forgotten loop can run」と、忘れたループが無限に走り続けない安全弁として位置づけている。

発火時刻には決定論的なジッターも入る。時間ごとより頻繁でない繰り返しタスクは、予定時刻から最大30分後(1時間より高頻度なタスクは間隔の最大半分)までのどこかで発火する。正時・30分ちょうどに単発タスクを置くと最大90秒早く発火することもある。オフセットはタスクIDから決まるため同じタスクなら毎回同じズレになるが、厳密な時刻がほしいなら0 9 * * *ではなく3 9 * * *のように:00/:30を避けるとよい、と明記されている。

環境変数CLAUDE_CODE_DISABLE_CRON=1を設定すると、/loopを含むスケジューラ全体が無効になり、cronツール自体が使えなくなる。すでに登録済みのタスクも発火を止める。

セッションの外へ出す2つの経路──DesktopとRoutines

セッションが閉じている間も動かしたい場合、公式は3つの比較軸を並べている。

Cloud(Routines) Desktop /loop
実行場所 クラウド(既定はAnthropic管理) 自分のマシン 自分のマシン
マシンの電源が必要か 不要 必要 必要
セッションを開いておく必要があるか 不要 不要 必要
再起動をまたいで残るか 残る 残る --resumeで未失効なら復元
ローカルファイルへのアクセス なし(毎回クローンし直し) あり あり
承認プロンプト なし(自動実行) タスクごとに設定可能 セッションの設定を引き継ぐ
最小間隔 1時間 1分 1分

公式の推奨も一言でまとまっている。マシンなしで確実に動かしたいならCloud、ローカルファイルやツールへのアクセスが要るならDesktop、セッション中の手早いポーリングなら/loop、という切り分けだ。

Desktopのローカルタスクは、Desktopアプリの「Routines」サイドバーから「New routine」→「Local」で作る。毎分チェックが走り、アプリが開いていてマシンがスリープしていない間だけ発火する。ここで効くのが「Missed runs」の仕様で、アプリ起動時やマシン復帰時に過去7日分の未発火を確認し、直近1回分だけキャッチアップ実行して、それより古いものは切り捨てる。「9時に毎日走るはずのタスクが、マシンをずっと閉じていたせいで夜11時に1回だけ走る」という挙動になりうるため、公式はタイミングをプロンプト側のガードで縛ることを勧めている。権限モードはタスクごとに設定でき、~/.claude/settings.jsonのallowルールもDesktopタスクのセッションに適用される。

クラウドのRoutines(CLIでは/schedule)は現時点で「研究プレビュー」扱いで、挙動・制限・APIの形は今後変わりうると注記されている。利用にはPro/Max/Team/Enterpriseプランに加えて「Claude Code on the web」が有効になっている必要があり、Console APIキーやBedrock/GCP/Microsoft Foundry経由のログインでは/schedule自体が使えない。トリガーはスケジュール・API呼び出し・GitHubイベントの3種類を組み合わせられ、承認プロンプトは一切出ない。公式は「権限モードの選択肢も実行中の承認プロンプトもない、フルセッションとして自律的に動く」と明記しており、含めたコネクタのツールは書き込みも含めて無条件に使える。

実務で引っかかる点

GitHub連携は/web-setupだけでは動かない。 Routinesの GitHub トリガーには Claude GitHub App のインストールが別途必要だと公式は念を押している。/web-setupが付与するのはクローン用のリポジトリアクセスだけで、GitHub Appのインストールもwebhook配信の有効化もしない。クローン権限があるからPRイベントで発火すると思い込むと、いつまで経っても起動しない。

スキル呼び出しは/loopで素通りすることがある。 /loop 20m /review-pr 1234のようにスキルをプロンプトとして渡しても、そのスキルがClaudeによる自律呼び出しを許可されていない場合(disable-model-invocation: true付き、skillOverridesで隠されている等)は、発火時にプレーンテキストとして届くだけで実行されない。/permissionsのような組み込みコマンドやMCPプロンプトも同様に素通りする対象として明記されている。

取りこぼしたら1回分しか実行されない。 公式の制限事項に「見落とされた実行のキャッチアップはない」と明記されている。タスクの発火時刻が過ぎてもClaudeが長時間の処理でビジーなら、アイドルになった瞬間に1回だけ発火し、見落とした回数分は発火しない。5分間隔で40分かかるビルドを監視させていた場合、その間の7回分は消えて最後に1回だけ動く。

Bedrock・AWS・GCP・Microsoft Foundry経由では挙動が変わる。 これらのプラットフォームでは、間隔なしの/loopは「Claudeが選ぶ間隔」ではなく固定10分スケジュールで動き、プロンプトなしの/loopは組み込みメンテナンスプロンプトの代わりに使用方法メッセージを表示するだけになる。DISABLE_TELEMETRY等でfeature-flag fetchingを無効化した場合も同じ挙動になり、加えて/schedule自体が使えなくなる。

.claudeディレクトリのシンボリックリンクはエラーになる。 セッション内スケジュールのタスクリストはプロジェクトの.claudeディレクトリに保存されており、このディレクトリ自体、あるいは中のタスクファイルがシンボリックリンクだと、タスク登録がエラーで失敗すると明記されている。

Routinesの/fireペイロードは指示として実行されない。 APIトリガーで送るtextは保存済みプロンプトに直接混ざるのではなく、<routine-fire-payload>ブロックに包まれて「信頼できないデータ」として届く。プロンプト側で明示的に参照させないと、送ったテキストはただの不活性なコンテキストとして無視される。

公式ドキュメントに記載を見つけられなかったこと

  • Routinesの「1日あたりの実行回数の上限」は具体的な数値が本文中になく、「claude.ai/code/routinesで確認せよ」という案内があるだけだった。数値そのものは記載を見つけられなかった。
  • /loopの自分のペースモードがDesktopのローカルタスクでも使えるかは、Desktop側のページに記載がなく確認できなかった(説明は固定間隔のプリセット中心)。
  • CLIからのRoutines単発実行は「段階的にロールアウト中」とあるが、対象バージョンや地域など具体的な範囲は記載を見つけられなかった。

参照した4つの公式ドキュメント

いずれも2026年8月27日にMarkdown版(URL末尾.md)を取得して確認した。

シェア: ポスト はてブ

出典・参照資料

AIニュースの解説を動画でも

YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。

コメント

まだコメントはありません。最初のコメントを書いてみませんか?

AIについて聞きたいことはありますか?

質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。

質問箱を見る →

新しい記事をメールで受け取る

AIの新しい発表を、出典付きで整理して届けます。

関連記事