この記事の目次
Claude Codeの定期実行には何があり、何を基準に選べばよい？
方式は3つあります。セッション内で動く /loop、Anthropic管理のクラウドで動くRoutines、自分のPC上で動くDesktopスケジュールです。選ぶ基準は、動かす場所、PCの電源とセッション、ローカルファイルへの到達、確認間隔の4点に整理できます。
この記事は「どの仕組みで定期実行するか」を選ぶ話に限ります。そもそも何を自動化すべきかという業務の選定は、Claude Codeで自動化できる業務の考え方に譲ります。
先に決める4つの問い
表を見る前に、次の4つに答えておくと候補が絞れます。
- 動かす場所は、クラウドか自分のPCか
- PCの電源とClaude Codeのセッションを開いたままにできるか
- ローカルのファイルに触れる必要があるか
- 確認間隔は何分か
3方式を1枚の表で比べる
比較軸は、公式ドキュメントの比較表にある「実行場所」「マシンの電源」「セッションを開く必要」「ローカルファイル」「最短間隔」です。許可確認の扱いは後半の節で触れます。
| 項目 | /loop |
Desktopスケジュール | クラウド(Routines) |
|---|---|---|---|
| 実行場所 | 自分のPC | 自分のPC | 既定ではAnthropic管理のクラウド |
| マシンの電源が必要か | 必要 | 必要 | 不要 |
| セッションを開いておく必要 | あり | なし | なし |
| ローカルファイルへの到達 | できる | できる | できない(新規クローン) |
| 最短間隔 | 1分 | 1分 | 1時間 |
公式はこの表の直後で用途を一言で示しています。“Use /loop for quick polling during a session.” つまり、セッション中の手軽な確認(ポーリング)には /loop が向く、という位置づけです。ポーリングとは、一定間隔で状態を見に行くことを指します。
/loopはどう書けば動き、動いたことをどう確認する？
/loop は先頭に間隔、続けてプロンプトを書けば動きます。作成時にClaudeが周期とジョブIDを返すので、それが成功状態です。一覧表示と削除も、自然な言葉で頼めます。
/loop 5m check if the deployment finished and tell me what happened間隔を付けると、Claudeがcron式(定期実行の時刻指定の書式)に変換してジョブを登録し、周期とジョブIDを知らせます。画面の見た目はこの記事では扱わず、「周期とジョブIDが返る」ことだけを成功の目安とします。
間隔を付ける、付けない、何も付けない
公式の整理は3パターンです。
- 間隔とプロンプトの両方:
/loop 5m check the deployのように固定周期で動きます。 - プロンプトだけ: Claudeが反復ごとに1分から1時間の間で待ち時間を選びます。ビルド終盤は短く、動きがなければ長くなります。
- 間隔だけ、または何も付けない: 組み込みの保守プロンプトが動きます。
.claude/loop.mdか~/.claude/loop.mdがあれば、そちらの内容が優先されます(プロジェクト側が先)。25,000バイトを超える部分は切り詰められます。
間隔は先頭の 30m のような形でも、末尾の every 2 hours のような形でも書けます。単位は s、m、h、d です。cronは1分刻みのため、秒指定は分に切り上げられます。7m や 90m のようにきれいな刻みにならない値は、近い刻みに丸められ、Claudeが採用した値を知らせます。
動いたかの確認、一覧、削除
確認の流れは次のとおりです。
- 作成直後に返る周期とジョブIDを見る
- 「いまのスケジュールタスクは？」のように聞いて一覧を出す
- 「deploy checkのジョブを消して」のように頼んで削除する
内部では CronCreate(作成)、CronList(一覧)、CronDelete(ID指定の削除)が使われ、IDは8文字です。1セッションに持てるタスクは50件までです。
1回だけの通知
繰り返しではなく1回だけ動かすなら、/loop を使わず「15時にリリースブランチのpushを思い出させて」のように頼みます。実行後に自動で消える単発タスクになります。
バージョン条件の注意
動的な間隔と保守プロンプトは、Amazon Bedrock、Claude Platform on AWS、Google Cloudの Agent Platform、Microsoft Foundryのいずれかを使う場合、またはfeature-flag取得をオフにしている場合に限り、Claude Code v2.1.248以降が必要です。該当する環境の方は、Claude Codeのアップデートと版の確認で現在の版を確かめてください。
/loopが止まる・動かない条件
止まる条件は6つに分かれます。端末を閉じる、長い処理で見逃す、7日が経つ、再開時に復元されない、Esc で待機を消す、環境変数で無効化する、です。設定したのに動かないときは、この一覧と照らしてください。
| 条件 | 何が起きるか | 対処 |
|---|---|---|
| 端末を閉じる、セッションを終了する | 発火しない。公式は “Tasks only fire while Claude Code is running and idle.” と説明 | セッションを開いたままにする。続けたいなら他方式へ |
| Claudeが長い処理中に予定時刻を過ぎた | アイドルになった時点で1回だけ発火。見逃した回数分は追いつかない | 追いつかないので、毎回の実行が必須の用途には向かない |
| 繰り返しタスクの作成から7日 | 最後に1回発火して自動削除される | 作り直すか、RoutinesやDesktopへ移す |
--resume / --continue で再開 |
CronCreate のタスクは復元。ただし失効済みの繰り返しと、時刻を過ぎた単発は復元されない。自己ペースの /loop も復元されない |
自己ペースの /loop は再実行する |
自己ペースの /loop 待機中に Esc |
待機中の次回予約が消え、再発火しない | 続けたいなら /loop を再度入力する |
CLAUDE_CODE_DISABLE_CRON=1 を設定 |
スケジューラ全体が無効になる。/loop も使えず、登録済みタスクも動かない |
環境変数を外す |
補足がいくつかあります。Esc が消すのは自己ペースの /loop の待機で、Claudeに直接頼んで登録したタスクには影響しません。後者は削除するまで残ります。固定間隔の /loop は、自分でキャンセルするか7日が経つまで動き続けます。
バックグラウンドのBashやモニタータスクは、再開時に復元されません。さらに公式は、セッションをバックグラウンド化すると /loop のタスクが端末なしで動くバックグラウンドセッションに引き継がれる、とも書いています。その手順はこの記事では扱いません。セッション操作の基本はClaude Code CLIの使い方にまとめています。
実行時刻のずれ
時刻はずれます。5分周期だけは前回の4分45秒後で15秒早く動き、10分以上の繰り返しは周期に応じて最大30分遅れます。
ずれの理由は公式によれば、全セッションが同時にAPIを呼ばないよう、Claude Codeが各タスクの実行時刻をずらしているためです。繰り返しタスクの遅れは、次の実行までの間隔の半分以内で、かつ最大30分です。
| 周期 | 実行開始の目安 | 向き |
|---|---|---|
5分ごと(*/5 * * * *。/loop 5m が作る形) |
前回の実行から4分45秒後 | 15秒早い |
| 10分ごと | 0〜5分 | 遅れる |
| 30分ごと | 0〜15分 | 遅れる |
| 1時間ごと、またはそれより長い周期(日次など) | 0〜30分 | 遅れる |
5分周期だけ向きが逆です。ちょうど5分後だと5分間のプロンプトキャッシュが切れた後になるため、15秒早めて開始する設計だと公式は説明しています。
等間隔の周期(毎時、毎日、10分ごとなど)は、毎回同じ分数だけ遅れます。:00 と :15 のような不均等な周期は、回ごとに遅れ幅が変わりえます。公式の例では、7,37 * * * * は30分間隔なので遅れは0〜15分で、仮に14分遅れなら :21 と :51 に動きます。
単発タスクは逆向きで、毎時0分と30分の指定では最大90秒早く動きます。時刻が重要なら、0 9 * * * ではなく 3 9 * * * のように切りのよい時刻を避けるのが公式の案内です。動的間隔の /loop にはこのjitter(ずらし)のルールは適用されませんが、7日失効は適用されます。
cron式を自分で書く場合の例を1つ挙げます。時刻は協定世界時ではなく、実行している環境のローカルタイムゾーンで解釈されます。
0 9 * * 1-5これは平日の午前9時です。L、W、? や MON のような名前の別名など、拡張記法には対応していません。
/loopで足りないときの移行先
PCを閉じても続けたいなら、間隔が1時間以上の場合に限りクラウド(Routines)が候補です。ローカルファイルが要るならDesktopスケジュールになります。状況別に当てはめると、次のとおりです。
- PCを閉じても続けたい。確認間隔は1時間以上でよい: クラウド(Routines)。ただしローカルファイルには触れず、毎回新規クローンで動きます。
- ローカルのファイルを触らせたい。セッションは開かなくてよい: Desktopスケジュール。マシンの電源は入れておく必要があります。
- 数分おきの確認を、PCを閉じても続けたい: 公式の比較表にある3方式の範囲では、該当する方式はありません。クラウドの最短は1時間で、Desktopと
/loopはマシンが必要なためです。間隔を1時間に緩めてRoutinesにする、常時起動できるPCでDesktopスケジュールにする、といった組み替えが考えられます。 - CIの中で回したい: GitHub Actionsの
scheduleトリガーがあります。設定はGitHub Actionsとの連携ガイドに任せます。
Routinesのスケジュールは、CLIの /schedule から設定できると公式の比較表にあります。RoutinesとDesktopスケジュールの画面操作や設定手順はこの記事では扱わず、選ぶ軸の提示までとします。Desktopアプリ自体の使い方はClaude Code Desktopアプリの解説を参照してください。
似た用途の機能も1行だけ挙げておきます。イベントが起きた時点で反応させたいなら公式はChannelsを、条件が満たされるまでターンを続けさせたいなら /goal を案内しています。どちらも間隔で動かす仕組みとは別物です。
無人で動かす前に決めておくこと
決めておくのは、許可の扱い、触らせる範囲、止め方の3点です。方式によって許可確認の挙動が違うため、/loop から移すときは前提が変わります。
公式の比較表では、許可確認(Permission prompts)は次のように分かれています。
/loop: セッションの設定を引き継ぎます。- Desktopスケジュール: タスクごとに設定できます。
- クラウド: 確認なしで自律的に実行されます(“No (runs autonomously)”)。
同じ内容をクラウドに移すと、/loop では確認が入っていた操作も確認なしで進みうる、という違いが生じます。MCPサーバーの扱いも異なり、/loop はセッションから継承し、Desktopは設定ファイルとコネクタ、クラウドはタスクごとのコネクタです。MCPの設定はMCPの接続ガイド、許可の仕組みは権限モードの解説で確認できます。
組み込みの保守プロンプトにも手がかりがあります。公式によれば、pushや削除のような不可逆な操作は、会話履歴で既に許可された作業の続きである場合に限って進みます。自分で書く定期実行のプロンプトでも、触る範囲、してはいけない操作、止める条件を明記しておけば、同じ考え方を踏襲できます。運用上の推奨値は公式に書かれていないため、ここでは示しません。
まとめ
判定は一文で足ります。手元で1分間隔から確認するなら /loop、PCを閉じても続けたいならクラウド(1時間以上)、ローカルファイルが要るならDesktopです。/loop を選んだ場合は、作成直後のジョブIDと7日失効を忘れないでください。
方式が決まった先には、無人で動かすときの権限設計と、失敗したときの扱いという課題が残ります。ここは読んだだけでは身につきにくい部分で、実際に手を動かして試すことで固まります。自分の手でClaude Codeを使えるようになるために学ぶ場として、月額1,980円からの学習コミュニティ「AI駆動ラボ」があります。具体的な学習内容は、サイトで確認してから判断してください。
出典は公式ドキュメント「Run prompts on a schedule」(https://code.claude.com/docs/en/scheduled-tasks)です。このページには日付や版の表記がないため、設定前に現行の記載を公式ページで確かめてください。料金、プラン別の可否、地域差、提供段階は同ページに記載がなく、この記事では未確認として扱っています。