Claude Codeスケジュール実行の3大トラブル、症状別デバッグガイド

Claude Codeのスケジュール実行機能、いざ動かそうとしたら「なぜか動かない」「タスクが消えた」「時間がずれてる」。スケジュール実行は使い始めにつまずきやすい機能です。

/loop コマンドは確かに便利なのですが、仕組みをきちんと理解していないと「設定したはずなのに実行されない」という状況が何度でも起きます。この記事ではスケジュール実行でありがちな3つのトラブルを、症状・原因・解決策の順で整理しました。

対象読者: Claude Code v2.1.72 以降を使っていて、/loop やスケジュール機能を使い始めた方。バージョン確認は claude --version で。

トラブル1: タスクを設定したのに実行されない

症状

/loop 30m check if the build passed

と打ったら「スケジュールしました」と返ってきた。でも30分待っても、1時間待っても何も起きない。

原因

Claude が「忙しい状態」だとタスクは待機に入ります。

スケジューラーは毎秒タスクの実行タイミングをチェックしていますが、Claude が別の処理を実行中の場合はキューに入れて待機します。ドキュメントには次のように書かれています。

A scheduled prompt fires between your turns, not while Claude is mid-response.

長い処理を走らせている最中にタイミングが来ても、その処理が終わるまでは実行されません。「30分おきのはずが実質1時間おきになっている」という事態もここから起きます。

また、catch-up（追いかけ実行）がない点も要注意です。長い処理中に2回分のタイミングを跨いだとしても、終わった後に実行されるのは1回だけです。

解決策

状況	対処
Claude がコード生成など長い処理中にタスクが来た	正常動作。処理終了後に1回実行される
定刻実行が絶対に必要	/loop ではなく Cloud/Desktop スケジュールタスクを使う
セッション内でのポーリングで十分	インターバルを長めに設定して許容範囲を広げる

セッション内ポーリングとして /loop を使う分には問題ありませんが、「この時刻に必ず動く」ことを前提にした処理には向いていません。

見落としやすいのが「セッションを閉じるとタスクも消える」という仕様です。ターミナルを閉じたり exit した時点で全タスクがリセットされます。永続化が必要なら Cloud スケジュールタスクか Desktop スケジュールタスクへ移行を。

トラブル2: 指定した時刻と実際の実行時刻がずれる

症状

remind me at 9:00 to review the PR

と設定したのに、9時ちょうどには何も起きず、数分後にリマインドが来た。あるいは逆に少し早く来た。

原因

スケジューラーには意図的なジッター（ゆらぎ）が入っています。

これはセッションが増えたときに全員が同じ瞬間にAPIを叩かないようにする分散処理の仕組みです。具体的には以下のルールがあります。

• 繰り返しタスク: 設定した周期の最大10%、上限15分まで遅延する可能性がある。例えば1時間ごとのタスクは :00 ではなく :06 などに来ることがある
• 一回限りのタスク: :00 や :30 の分単位に設定した場合、最大90秒のジッターが入る

同じタスクIDには同じオフセットが付くので、毎回バラバラにずれるわけではありません。「今日は9:03に来た」なら明日も9:03前後に来ます。

解決策

公式ドキュメントに明快な対処法が書かれています。

If exact timing matters, pick a minute that is not :00 or :30, for example 3 9 * * * instead of 0 9 * * *, and the one-shot jitter will not apply.

キリの良い分数を避けるだけでジッターが外れます。

# ジッターが入りやすい設定
0 9 * * *   # 9:00ぴったり → 最大90秒のジッターあり

# ジッターを避けた設定
3 9 * * *   # 9:03 → ジッターなし

CronCreate ツールを直接使うか、Claude に「9時3分に実行して」と自然言語で伝えることで対処できます。

タイムゾーンについては心配不要です。cron式はすべてローカルタイムとして解釈されます。0 9 * * * は「UTCの9時」ではなく「あなたのマシンのタイムゾーンでの9時」です。

トラブル3: 7日後にタスクが勝手に消える

症状

デプロイ監視のために設定した /loop タスクが、1週間後に突然動かなくなった。what scheduled tasks do I have? で確認すると何も残っていない。

原因

セッションスコープのタスクには7日間の自動有効期限があります。

これは「作ったことを忘れたループがいつまでも走り続ける」のを防ぐための設計です。7日経つとタスクは最後に1回だけ実行され、その後自動削除されます。

# タスクの状態確認
what scheduled tasks do I have?

# 期限前に作り直す場合
cancel the deploy check job
/loop 30m check if the deployment finished

ただし根本的な問題として、セッションを閉じるとリセットされるため、実際に7日間同じセッションを開き続けることは少ないはずです。「7日後に消えた」という状況が起きているなら、セッションを再起動しても自動で復元する仕組みが必要だということを示しています。

解決策

長期間の継続実行が必要なケースでは、/loop はそもそも適切な選択肢ではありません。用途に応じて以下を検討してください。

要件	推奨手段
マシンをオフにしても動き続けてほしい	Cloud スケジュールタスク（最小間隔1時間）
ローカルファイルへのアクセスが必要、でも永続化したい	Desktop スケジュールタスク（最小間隔1分）
CI/CD パイプラインに組み込みたい	GitHub Actions の schedule トリガー
セッション中のちょっとした確認	/loop（本来の用途）

Cloud スケジュールタスクは最小間隔が1時間と /loop より粗くなります。「5分おきにビルドを監視したい」というセッション中のユースケースには向きません。

3つのトラブルを1枚で整理すると

症状	原因	解決策
タスクが実行されない	Claude が処理中で待機状態	処理が終わるまで待つ。厳密な定刻実行が必要なら別手段を使う
時刻がずれる	:00 や :30 へのジッター	3 9 * * * のようにキリの悪い分数を指定する
タスクが勝手に消える	7日間の自動有効期限 / セッション終了	長期継続はCloud/Desktopスケジュールへ移行する

まとめ

/loop は「セッション中の簡易ポーリングツール」であって、「cronの代替」ではありません。この認識のズレが3つのトラブルすべての根っこにあります。

タイミングのずれが気になるなら、:00 や :30 を避けて 3 9 * * * のような分数を指定すれば即解決します。セッションをまたいで使いたいなら Cloud か Desktop のスケジュールタスクを検討してください。