case_1103

Claude Codeの定期実行|/loopとRoutinesの選び分け

Claude Codeの定期実行|/loopとRoutinesの選び分け

Claude Codeの定期実行は/loop・Routines・Desktopの3系統。最小間隔とマシン起動の要否で選び分け、cron式とジッター、7日期限、/scheduleが出ない原因まで公式情報で確認する。

2026年9月29日時点の結論。Claude Codeの定期実行は3系統あり、選び分けは2つの質問だけで決まる。(1) マシンを落としている間も動いてほしいか、(2) ローカルのファイルとツールに触る必要があるか。両方「はい」は成立しないので、どちらを捨てるかを決めた時点で系統は1つに絞られる。マシンを落としてよいならクラウドで動く Routines、ローカルのファイルに触るなら Desktop のローカル定期タスク、いま開いているセッションの中で数分おきに様子を見せたいだけなら /loop だ。最小間隔もここで分かれる。Routines は1時間、Desktop と /loop は1分が下限になる。

公式ドキュメントはこの3系統を1枚の比較表にしていて、「実行場所」「マシンの起動が必要か」「セッションを開いておく必要があるか」「再起動をまたぐか」「ローカルファイルに触れるか」「MCPの扱い」「権限プロンプト」「スケジュールの自由度」「最小間隔」の9項目で並べている(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。以下はその表を「選び方」と「つまずく場所」に組み替えたものだ。

この記事の要点

  • 選び分けの2問:マシンを落として動かすなら Routines(クラウド)。ローカルのファイルに触るなら Desktop のローカル定期タスク。開いたセッションの中で見張るだけなら /loop。
  • 最小間隔:Routines は1時間が下限で、それより短い cron 式は拒否される。Desktop と /loop は1分(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。
  • /loop は3通りに化ける:間隔とプロンプトの両方を渡せば固定スケジュール、プロンプトだけなら間隔をClaudeが毎回決める、どちらも省略すると組み込みの保守プロンプト(または loop.md)が走る。
  • 黙って消える仕様:/loop などセッション内のタスクは7日で期限切れになり、最後に1回動いてから自分を削除する。新しい会話を始めると全部消える。
  • 時刻がずれる仕様:定時タスクには意図的なジッター(最大30分の後ろずれ)が入る。0 9 * * * ではなく 3 9 * * * のように「:00 と :30 以外の分」を選ぶ。
  • /schedule が出ない:Routines は claude.ai のサブスクリプションログインが前提。ANTHROPIC_API_KEY がシェルに残っていると、それが優先されてコマンドごと消える。
  • 緑は成功ではない:Routines の実行一覧の緑は「セッションがインフラ障害なく終了した」という意味で、プロンプトの仕事が成功したという意味ではない。
  • 対象読者:毎朝のレビューや依存関係チェックを自動化したい開発者、CIやデプロイの状態を見張らせたい運用担当、cron から claude -p を叩く構成を見直したいチームリード。
  • 今日やること:まず /loop 5m で1つ回して挙動を確かめ、7日をまたぐ必要があるものだけ Routines か Desktop に移す。

前提|3系統のどれを使うかは2つの質問で決まる

3系統は名前が似ているが、実行場所が違うので使える範囲が根本的に違う。

Routines(クラウド):Anthropic管理のクラウド基盤で動く。組織の自己ホスト環境に振り向けた場合はそこで動く。マシンを落としていても動く代わりに、ローカルファイルには触れない。リポジトリは毎回クローンし直される。

Desktop のローカル定期タスク:自分のマシンで動く。ローカルのファイルとツールにそのまま触れるが、デスクトップアプリが起動していてマシンが起きている間しか動かない。

/loop(セッション内):いま開いているCLIセッションの中で動く。セッションを閉じれば止まる。

定期実行という入口が、マシンの起動が必要かという関門でRoutinesと手元実行に分かれ、手元実行がさらにセッションを開いておく必要かでDesktopと/loopに分かれる図
2つの質問で3系統に振り分ける

9項目の比較

公式の比較表は次の内容だ。並びは「クラウド/Desktop//loop」の順になっている。

項目 Routines(クラウド) Desktop /loop
実行場所 クラウド(既定はAnthropic管理) 自分のマシン 自分のマシン
マシンの起動が必要 不要 必要 必要
セッションを開いておく必要 不要 不要 必要
再起動をまたぐ またぐ またぐ --resume で復元(例外あり)
ローカルファイルに触れる 触れない(毎回クローン) 触れる 触れる
MCP タスクごとに設定したコネクタ 設定ファイルとコネクタ セッションから継承
権限プロンプト 出ない(自律実行) タスクごとに設定可 セッションから継承
スケジュールの自由度 CLIの /schedule 経由 あり あり
最小間隔 1時間 1分 1分

「セッションを開いておく必要」が /loop だけ「必要」になっている点が、実務では一番効く分かれ目だ。ターミナルを閉じると止まる。ただしセッションをバックグラウンドに送った場合は、/loop のタスクがバックグラウンドセッションに引き継がれ、ターミナルなしで動き続ける。

系統1|/loop|開いたセッションの中で回す

/loop は同梱スキルで、セッションを開いたまま同じプロンプトを繰り返させる最短の手段だ。間隔とプロンプトはどちらも省略でき、何を渡したかで挙動が3通りに変わる(以下の3通りと後述の仕様はいずれもAnthropic「Run prompts on a schedule」(2026年9月29日確認)による)。

プロンプトとScheduleWakeupが円環をなして繰り返し、その戻りの矢印にEscと7日の期限が外から当たって抜ける様子を示した図
/loopの1周と、抜ける2つの条件
渡すもの 例 起きること
間隔とプロンプト /loop 5m check the deploy プロンプトが固定スケジュールで走る
プロンプトだけ /loop check the deploy 間隔をClaudeが毎回決めて走る
間隔だけ、または両方なし /loop 組み込みの保守プロンプト、または loop.md が走る

間隔を渡す場合

間隔を渡すと、Claudeがそれをcron式に変換してジョブを登録し、周期とジョブIDを返す。単位は s(秒)、m(分)、h(時間)、d(日)。cronの粒度は1分なので、秒は分に切り上げられる。7m や 90m のようにcronの刻みに落ちない間隔は、落ちる一番近い間隔に丸められ、どれを選んだかをClaudeが伝える(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。

間隔は 30m のように先頭の裸のトークンでもよく、every 2 hours のように後ろの句でもよい。

間隔を省略する場合

間隔を省略すると、固定のcronスケジュールではなく、Claudeが毎回動的に次の待ち時間を決める。1分から1時間の範囲で、直前の回に何を観測したかに基づいて選ぶ(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。ビルドが終わりかけている時やPRが動いている時は短く、何も起きていない時は長くなる。選んだ待ち時間とその理由が各回の最後に表示される。

Monitor ツールが使えるセッションでは、動的な /loop を頼んだときにClaudeがそちらを直接使うことがある。Monitor はバックグラウンドのスクリプトを走らせて出力行を1行ずつ戻すので、間隔ごとにプロンプトを再実行するより効率がよく反応も速い。

動的スケジュールのループも、他のタスクと同じようにタスク一覧に出るので、同じ手順で一覧・取り消しができる。後述のジッターは適用されないが、7日の期限は適用される。

動的な間隔と組み込みの保守プロンプトは、すべてのプロバイダーで動く。ただし Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry、またはフィーチャーフラグの取得を切っている場合は、どちらも Claude Code v2.1.248 以降が必要になる。それ以前の版では、間隔なしのプロンプトは固定の10分周期で走り、プロンプトなしの /loop は使い方の表示だけを出す(Anthropic「Run prompts on a schedule」(2026年9月29日確認)/GitHub「anthropics/claude-code — Releases」(2026年9月29日確認))。

プロンプトを省略した場合の中身

プロンプトを省略すると、組み込みの保守プロンプトが使われる。各回で次の順に処理する。

  1. 会話に残っている未完了の作業を続ける
  2. いまのブランチのプルリクエストを世話する(レビューコメント、失敗したCI、コンフリクト)
  3. どれも残っていなければ、バグ探しや簡素化などの掃除を走らせる

この範囲の外で新しい取り組みを始めることはしない。push や削除のような取り消せない操作は、会話の記録がすでに承認している作業の続きである場合にだけ進む。

裸の /loop はこのプロンプトを動的な間隔で走らせる。/loop 15m のように間隔を足すと固定スケジュールになる。

loop.md で既定のプロンプトを置き換える

組み込みの保守プロンプトを自分の指示に差し替えるには loop.md を置く。これは裸の /loop に対する既定のプロンプトを1つ定義するファイルで、スケジュールされたタスクの一覧ではない。コマンドラインでプロンプトを渡した場合は無視される。

パス スコープ
.claude/loop.md プロジェクト。両方あるときはこちらが優先
~/.claude/loop.md ユーザー。自前のファイルを持たないプロジェクトに適用

中身は構造を要求されない素のMarkdownで、/loop のプロンプトを直接打つつもりで書く。編集は次の回から効くので、ループを回しながら指示を直せる。25,000バイトを超えた分は切り詰められるので、短く保つ(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。

止め方

自分でペースを決めるモードの /loop を、次の回を待っている間に止めるには Esc を押す。保留中の起床が消えるのでもう発火しない。Claudeに直接頼んで登録したタスクは Esc の影響を受けず、削除するまで残る。

このモードでは、仕事が終わったときにClaudeが自分でループを終えることもある。ScheduleWakeup を stop: true で呼び、保留中の起床を即座に取り消す。ある回が「次を予約する」も「止める」もせずに終わった場合は、約20分後に1回だけ予備の起床が入り、その回も予約しなければループが終わる(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。

固定間隔のループは、他のスケジュール済みタスクと同じように取り消すか、7日が経つまで走り続ける。

一度だけのリマインダー

一発だけのリマインダーは /loop を使わず、自然文でそのまま頼む。Claudeが単発のタスクを登録し、実行後に自分を削除する。発火時刻は cron 式で特定の分と時に固定され、いつ発火するかを返してくる。

一覧と取り消し

一覧や取り消しは自然文で頼めるが、裏で動いているのは3つのツールだ。

ツール 役割
CronCreate 新しいタスクを登録する。5フィールドのcron式、走らせるプロンプト、繰り返しか単発かを受け取る
CronList すべてのスケジュール済みタスクをID・スケジュール・プロンプトつきで並べる
CronDelete IDでタスクを取り消す

各タスクには8文字のIDが付き、CronDelete に渡せる。1セッションで同時に持てるのは50件までだ(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。

系統2|Routines|クラウドで回す

Routines は保存したClaude Codeの設定一式(プロンプト、1つ以上のリポジトリ、コネクタ)に名前を付けて、自動で走らせる仕組みだ。Anthropic管理のクラウド基盤か、組織の自己ホスト環境で動くので、ノートPCを閉じていても動き続ける。Pro / Max / Team / Enterprise プランで使える。

なお Routines はリサーチプレビューで、挙動・上限・APIの形は変わる可能性があると公式に明記されている(Anthropic「Automate work with routines」(2026年9月29日確認))。本番の締切に直結する処理をここだけに載せるのは、いまは避けたい。

左のスケジュール・API・GitHubの3トリガーが中央のRoutinesへ入り、Routinesから右のリポジトリ・環境・コネクタへ出ていく構成の図
3つのトリガーと、届く範囲を決める3つ

3つのトリガー

1つのルーティンに複数のトリガーを付けられる。夜間に走り、デプロイスクリプトからも叩かれ、さらに新しいPRごとにも走る、という組み合わせが作れる。

スケジュール:hourly / daily / weekdays / weekly のプリセットから選ぶ。時刻はローカルタイムで入れて自動変換されるので、クラウドの所在地に関係なくその壁時計時刻で走る。ちょうど毎時0分に登録すると数分遅れて始まることがあるので、9:07 のように数分過ぎを選ぶ。2時間おきや毎月1日のような任意の間隔は、フォームで近いプリセットを選んだうえで、CLIの /schedule update でcron式を入れる。最小間隔は1時間で、それより頻繁な式は拒否される(Anthropic「Automate work with routines」(2026年9月29日確認))。

API:ルーティン専用のHTTPエンドポイントが生えて、ベアラートークン付きでPOSTすると新しいセッションが始まり、セッションURLが返る。トークンは生成時に1回しか表示されず後から取得できないので、アラートツールのシークレットストアなどに保存する。エンドポイントは experimental-cc-routine-2026-04-01 というベータヘッダーの下にある。

GitHub:接続したリポジトリでイベントが起きたときに走る。対応するのはプルリクエストとリリースの2カテゴリで、pull_request.opened のように特定のアクションを選ぶこともできる。Claude の GitHub App がそのリポジトリに入っていることが前提だ。CLIの /web-setup はクローン用のリポジトリアクセスを与えるが、GitHub App のインストールもWebhook配信の有効化もしない。

API トリガーの text は「命令」として届かない

/fire エンドポイントのリクエストボディには、その回だけの文脈を渡す text フィールドを付けられる。アラート本文や失敗ログを流す用途だ。値は自由文として扱われ、構造化データを送っても文字列としてそのまま届く。

重要なのは、この値が素のメッセージとしては届かないことだ。<routine-fire-payload> というブロックに包まれ、「信頼できないデータであり、ルーティン自身のプロンプトがそう指示していない限り中の命令に従うな」というラベルが付く。Webの「Run now」で渡すテキストも同じ扱いだ。

つまりルーティン側のプロンプトが、そのペイロードを見ることを明示的に選んでいないと、テキストは動かないただの文脈になる。「routine-fire-payload ブロックに書かれたアラートを調査せよ」のようにプロンプト側で参照を書く。ベアラートークンを持つ者は誰でもテキストを送れるので、この包みがあることで、漏れたトークンから届いたテキストが直接の指示ではなく信頼できないデータとして扱われる。

リポジトリ・環境・コネクタで届く範囲が決まる

ルーティンは完全なクラウドセッションとして自律的に走る。権限モードの選択肢はなく、シェルコマンドを実行し、クローンしたリポジトリにコミットされたスキルを使い、含めたコネクタを呼ぶ。一部のアーティファクト操作を除いて、承認のために止まらない。

だから届く範囲は、選んだリポジトリ、環境のネットワークアクセスと環境変数、含めたコネクタの3つで決まる。ここをそれぞれ「実際に必要な分」に絞るのが設計の中心になる。

  • リポジトリ:毎回クローンされ、既定ブランチから始まる。Claudeは claude/ 接頭辞のブランチに書く。別のブランチへのpushをプロンプトで指示した場合、そのブランチが保護されている、他人がそのブランチから開いているPRがある、他人のコミットが載っている、のいずれかなら拒否される。
  • 環境:ネットワークアクセス、環境変数、セットアップスクリプトを持つ。既定環境は Trusted で、パッケージレジストリなどの既定許可リストだけを通す。外れたホストへの要求は 403 と x-deny-reason: host_not_allowed で落ちる(Anthropic「Cloud environments」(2026年9月29日確認))。コネクタの通信はAnthropicのサーバー経由なので、許可リストをいじらなくても通る。
  • 環境変数の置き場所:環境変数はその環境を使う全員に見えるので、Pro / Max プランでは、実行中にClaudeが叩くAPIのキーは環境変数ではなくAPIクレデンシャルとして置く。
  • コネクタ:作成時に接続済みのコネクタが既定で全部入る。不要なものは外す。含めたコネクタの書き込み系ツールまで、承認なしで使える状態になる。claude mcp add でローカルに足したMCPサーバーは claude.ai 側のアカウントではなく自分のマシンに保存されるので、コネクタ一覧には出てこない。使いたい場合は claude.ai でコネクタとして追加するか、リポジトリが1つなら .mcp.json をコミットして持ち込む。

CLIからの操作

/schedule をどのセッションで打っても、対話でスケジュール付きルーティンを作れる。/schedule daily PR review at 9am のように説明を直接渡してもよい。別名は /routines。既存のルーティンは /schedule list、/schedule update、/schedule run で扱える。

/schedule why did my nightly review do nothing this morning? のように実行履歴を尋ねると、直近の実行をステータスとWebで開くリンク付きで並べ、ログを読んで何が起きたかを説明する。ツールのエラー、権限の拒否、最終結果まで含む。この履歴の説明は v2.1.227 以降が必要だ(Anthropic「Automate work with routines」(2026年9月29日確認)/GitHub「anthropics/claude-code — Releases」(2026年9月29日確認))。

「/schedule が Unknown command」になる時

/schedule は要件を満たしていないとCLIが隠すので、入力中は候補に出ず、送信すると Unknown command: /schedule が返る。原因はほぼ次のどれかだ。

  • claude.ai のサブスクリプションログインではない。Console の APIキー、Anthropic のプロファイルやフェデレーション資格情報、Bedrock などのクラウドプロバイダー経由でログインしている。シェルに ANTHROPIC_API_KEY か ANTHROPIC_AUTH_TOKEN が設定されていたり、settings.json に apiKeyHelper があると、それが claude.ai のログインより優先されるので、まずそれを外す。
  • 完全にサインアウトしている。フィーチャーフラグの取得が有効なら、送信時に claude.ai のサブスクリプションが必要という案内が出る。/login でサインインする。
  • クラウドセッションの中にいる。その環境では使えないと返る。Webの管理画面から操作する。
  • 組織のポリシーがクラウドセッションを無効にしている。クラウドセッションが組織のポリシーで無効だと返る。
  • Team / Enterprise の Owner が Routines を切っている。この場合はサーバー側の組織設定なので、ローカルの設定では上書きできない。Owner に有効化を頼む。

実行一覧の緑は「成功」ではない

実行一覧の緑は、セッションが起動してインフラ障害なく終了したという意味だ。プロンプトに書いた仕事が成功したという意味ではない。ブロックされたネットワーク要求、足りないコネクタのツール、タスクレベルの失敗は、ステータス表示ではなく実行の記録の側に出る。開いて何をしたかを読む。

GitHubの接続が切れているか期限切れのまま実行時刻が来た場合は、最大72時間まで実行を飛ばす。その間に再接続すれば自動で再開し、72時間を超えるとルーティンが止まるので、再接続してから自分で戻す(Anthropic「Automate work with routines」(2026年9月29日確認))。

系統3|Desktop|自分のマシンで回す

Desktop のローカル定期タスクは、自分のマシンで新しいセッションを自動で始める。ローカルのファイルとツールにそのまま届くのが Routines との違いだ。Code タブの Routines から「New routine」を開き、Cloud ではなく Local を選ぶと作れる(Anthropic「Schedule recurring tasks in Claude Code Desktop」(2026年9月29日確認))。デスクトップアプリが 1.1.5368 より前の版では、ローカル定期タスクは使えない。

上段はマシンが起きていて新しいセッションが始まる流れ、下段はマシンが寝ていて追いつきの実行が1回だけ走る流れを並べた図
起きていた場合と、寝ていた場合の行き先

作成フォームの4項目

設定するのは4項目だ。

項目 中身
Name タスクの識別名。小文字のケバブケースに変換され、ディスク上のフォルダ名になる。重複不可
Description 一覧に出る短い要約
Instructions 走らせる指示。権限モードとモデルの選択、作業フォルダ、隔離したワークツリーで走らせるかの指定がここに付く
Schedule 実行頻度。Manual / Hourly / Daily / Weekdays / Weekly から選ぶ

フォルダの指定は必須で、まだ信頼していないフォルダなら保存前に信頼の確認が出る。Manual は予定なしで、「Run now」を押した時だけ走る。プロンプトを保存しておいて手で叩く用途に使う。15分おきや毎月1日のようにピッカーに無い間隔は、Desktopのどのセッションでも自然文で頼めば設定できる。

既定では、作業ディレクトリの現在の状態、つまりコミットしていない変更も含めた状態に対して走る。 各回に独立したワークツリーを与えたい場合は、作成時にワークツリーのトグルを入れる。

取りこぼしは1回だけ追いつく

Desktopはアプリが開いている間、毎分スケジュールを確認して、期限が来たタスクのために新しいセッションを始める。APIへの集中を散らすため、各タスクには数分の決まった遅れが入る。同じタスクは常に同じオフセットで始まる。

タスクが動くのはアプリが起動していてマシンが起きている間だけだ。予定時刻にマシンが寝ていた回は飛ぶ。アイドルスリープを防ぐには、設定の Desktop app → General で「Keep computer awake」を入れる。ただしノートPCの蓋を閉じればそれでも寝る。

アプリの起動時やマシンの復帰時に、Desktopは各タスクが直近7日間に取りこぼした回があるかを確認する。あった場合は、一番新しく取りこぼした時刻の分だけを1回走らせ、それより古い分は捨てる。6日ぶん取りこぼした日次タスクは、復帰時に1回だけ走る。追いつきの実行が始まると通知が出る(Anthropic「Schedule recurring tasks in Claude Code Desktop」(2026年9月29日確認))。

ここはプロンプトの書き方に跳ね返る。朝9時のつもりのタスクが、マシンが一日寝ていれば夜11時に走ることがある。時刻が意味を持つ処理なら、プロンプト自身に歯止めを書く。「今日のコミットだけをレビューする。17時を過ぎていればレビューを飛ばして、飛ばした分の要約だけを出す」のような形だ。

権限モードと「毎回止まる」を防ぐ

タスクごとに権限モードを持ち、作成・編集時に決める。~/.claude/settings.json の allow ルールも定期タスクのセッションに適用される。Manual モードのタスクが権限を持たないツールを使おうとすると、承認するまで実行が止まったままになる。セッションはサイドバーに残るので後から答えられるが、朝の自動実行が止まっていることに昼まで気付かない、という形になりやすい。

止まりを避ける手順は公式に書かれている。作成直後に「Run now」を押し、権限の確認が出るのを見て、それぞれで「always allow」を選ぶ。以後そのタスクの実行は同じツールを確認なしで通す。保存された承認はタスクの詳細ページで確認・取り消しができる。

ただし requiresUserInteraction が付いたMCPツールは毎回確認が出て、always-allow の選択肢が無い。そのツールを呼ぶ実行は毎回止まる。

管理とディスク上の実体

詳細ページから、Run now、Active / Paused の切り替え、編集、履歴の確認、承認済み権限の確認、削除ができる。履歴では飛んだ回も見え、理由(マシンが寝ていた、前の回がまだ動いていた、他の定期タスクが既に動いていた)にカーソルを当てると出る。

削除の確認ダイアログには「Also delete files on disk」のチェックがあり、入れると ~/.claude/scheduled-tasks/ 以下のそのタスクの SKILL.md と関連データも消える。

プロンプトだけをディスク上で直したい場合は ~/.claude/scheduled-tasks/<task-name>/SKILL.md を開く(CLAUDE_CONFIG_DIR を設定しているならその下)。YAMLフロントマターに name と description、本文がプロンプトだ。変更は次の回から効く。スケジュール、フォルダ、モデル、有効・無効はこのファイルには無いので、編集フォームか自然文の依頼で変える。

走っているタスクが update_scheduled_task というMCPツールで自分のスケジュールやプロンプトを書き換えることもできる。リリースブランチが切られたのを見つけたらレビューを早い時刻に移す、といった作り方ができる。

時刻がずれる・黙って消える3つの仕様

「登録したのに動いていない」「頼んだ時刻と違う」の大半は、次の3つの仕様のどれかだ。バグではないので、探しても設定ミスは見つからない。

ジッター・7日の期限・発火しない条件を上から3段に積み、それぞれの右側に対応する具体的な挙動を添えた図
ずれる・消える・発火しないの3層

ジッター(意図的な後ろずれ)

すべてのセッションが同じ壁時計の瞬間にAPIを叩かないよう、スケジューラーは発火時刻に決まったオフセットを足す(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。

  • 繰り返しのタスクは、予定時刻から最大30分後ろにずれて発火する(1時間より頻繁なタスクは、間隔の半分まで)。:00 に登録した毎時ジョブは :30 までのどこかで発火しうる。
  • 単発のタスクを毎時の0分か30分に登録した場合は、最大90秒早く発火する。

オフセットはタスクIDから導かれるので、同じタスクは常に同じオフセットになる。時刻が厳密に効くなら、0 9 * * * ではなく 3 9 * * * のように :00 と :30 以外の分を選ぶ。単発のジッターはこれで適用されなくなる。

7日の期限

繰り返しのタスクは作成から7日で自動的に期限切れになる。最後に1回発火してから、自分を削除する(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。忘れられたループが走り続ける期間に上限を付ける仕組みだ。7日より長く回す必要があるなら、期限が来る前に取り消して作り直すか、Routines か Desktop の定期タスクに移す。

発火しない条件

セッション内のスケジュールには構造的な制約がある。

  • 動いていて、かつ手が空いている間しか発火しない。 ターミナルを閉じたりセッションが終了すると止まる。セッションをバックグラウンドに送った場合は /loop のタスクが引き継がれ、ターミナルなしで動き続ける。
  • 取りこぼしの追いつきはない。 長い処理の最中に予定時刻が過ぎた場合、手が空いた時に1回だけ発火する。飛んだ回の数だけ走ることはない。
  • 新しい会話を始めるとセッション内のタスクは全部消える。 claude --resume や --continue で再開したときは CronCreate で登録したタスクが復元されるが、期限切れの繰り返しタスクと、予定時刻を過ぎた単発タスクは戻らない。自分でペースを決める /loop は復元されないので、もう一度 /loop を打ち直す。バックグラウンドのBashとMonitorのタスクは再開時に一切復元されない。
  • フィーチャーフラグの取得を切っている場合、セッションをまたいで残すよう頼んだタスクはプロジェクトの .claude/scheduled_tasks.json に保存される。.claude ディレクトリかそのファイルがシンボリックリンクだと、登録の代わりにエラーが返る。保存されたタスクは作ったプロジェクトフォルダでのみ走る。ファイルを別のフォルダ(新しいワークツリーなど)にコピーすると、そこのセッションは一覧に出すが走らせないので、そのフォルダで作り直す。

まるごと止めたい時

CLAUDE_CODE_DISABLE_CRON=1 を環境に設定すると、スケジューラー全体が無効になる。cron関連のツールと /loop が使えなくなり、すでに登録済みのタスクも発火しなくなる(Anthropic「Environment variables」(2026年9月29日確認))。CIや共有マシンで「勝手に動く仕組みを全部落としたい」時の1行だ。

cron 式の書き方|CronCreate が受け取る5フィールド

CronCreate は標準の5フィールドのcron式を受け取る。順番は「分 時 日 月 曜日」。すべてのフィールドがワイルドカード(*)、単一の値(5)、刻み(*/15)、範囲(1-5)、カンマ区切りの列挙(1,15,30)に対応する(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。

式 意味
*/5 * * * * 5分ごと
0 * * * * 毎時0分
7 * * * * 毎時7分
0 9 * * * 毎日9時(ローカル時刻)
0 9 * * 1-5 平日の9時(ローカル時刻)
30 14 15 3 * 3月15日14時30分(ローカル時刻)

曜日と日を同時に指定した場合

曜日は日曜が 0 または 7、土曜が 6。L、W、?、MON や JAN のような名前の別名といった拡張構文には対応していない。

日と曜日の両方に条件を付けた場合、どちらかが一致した日が対象になる(AND ではなく OR)。これは標準的な vixie-cron の意味付けに従ったものだ(man7.org「crontab(5)」(日と曜日の両方が制限されている場合の挙動・2026年9月29日確認))。0 9 1 * 1 は「毎月1日 または 毎週月曜の9時」であって、「1日が月曜のときだけ」ではない。

時刻はすべてローカルタイムゾーンで解釈される。0 9 * * * はUTCの9時ではなく、Claude Codeを動かしている場所の9時だ。

症状から引く早見表

症状 見る場所
ターミナルを閉じたら止まった /loop はセッション内。Routines か Desktop に移す
7日で勝手に消えた セッション内タスクの7日期限。Routines か Desktop に移す
予定時刻より20分遅れて動く ジッター。分を :00 :30 以外にする
単発タスクが1分前に動いた 単発ジッターの最大90秒の前倒し
一晩寝かせたら1回しか動いていない Desktopは取りこぼしを1回だけ追いつく。/loop は追いつきなし
/schedule が Unknown command claude.ai ログインではない。ANTHROPIC_API_KEY を外す
Routines が緑なのに何もしていない 緑はセッションの終了。実行を開いて記録を読む
Routines がある時刻から全く走らない GitHub接続切れ。72時間で自動オフ
定期タスクが毎回止まっている Manual モードで承認待ち。Run now で always allow を入れる
1分おきにしたいのに拒否される Routines の最小間隔は1時間。Desktop か /loop にする
新しいワークツリーでタスクが動かない .claude/scheduled_tasks.json はコピーしても走らない。作り直す

想定の使い分け例(実測値ではありません)

以下は公式仕様から組んだ想定の構成で、特定の企業の実測値ではない。

  • 想定1|朝のレビュー準備:平日9時7分に、前日マージされたPRの要約を作る。ローカルのファイルには触らず、リポジトリのクローンで足りる。マシンを落としていても動いてほしい。→ Routines のスケジュールトリガー。分を :07 にしてジッターの影響を避ける。

  • 想定2|週次の依存関係チェック:社内の非公開パッケージレジストリに届く必要があり、ローカルの .npmrc と認証情報を使う。→ Desktop のローカル定期タスク。作成直後に Run now を押して、npm 系のコマンドに always allow を入れておく。

  • 想定3|デプロイの見張り:いまリリース作業をしていて、あと10分から30分で終わる見込み。→ /loop(間隔を省略してClaudeにペースを決めさせる)。終わったら Esc で止める。7日期限も関係ない。

  • 想定4|アラートからの一次調査:監視ツールが閾値超過を検知したときだけ動かしたい。スケジュールではない。→ Routines の API トリガー。プロンプト側に「routine-fire-payload ブロックのアラートを調査する」と明示的に書く。

今日やる3つ

  1. /loop 5m で1つ登録して、1回だけ発火させる。ジョブIDと、表示される発火時刻が自分の指定とどれだけずれるかを見る。ここでジッターの体感を掴んでおくと、後で「動いていない」と誤診しなくなる。
  2. 登録済みのタスクを自然文で一覧させ、8文字のIDを確認する。7日期限をまたぐ必要があるものを洗い出し、Routines か Desktop のどちらに移すかを決める。
  3. /schedule を打ってみる。Unknown command が返るなら、echo $ANTHROPIC_API_KEY と settings.json の apiKeyHelper を先に確認する。Routines を使う前提なら、ここを片付けるのが最初の一歩になる。

あわせて読みたい

よくある質問

Q. cron から claude -p を叩くのと、Routines はどちらがいいですか

マシンの電源とネットワークを自分で保証できるなら claude -p でも成立します。Routines の利点は、マシンを落としていても動くこと、リポジトリのクローンから毎回やり直すので前回の残骸が効かないこと、GitHubイベントとAPI呼び出しをスケジュールと同じ仕組みに載せられることです。逆に、ローカルのファイルや社内ネットワークに届く必要がある処理は Routines では動きません。

Q. /loop のタスクはセッションを閉じたらどうなりますか

止まります。ただしセッションをバックグラウンドに送った場合は、/loop のタスクがバックグラウンドセッションに引き継がれ、ターミナルなしで動き続けます。claude --resume で再開したときは CronCreate で登録したタスクは復元されますが、自分でペースを決める /loop は復元されないので打ち直してください。

Q. 予定した時刻とずれるのを止められますか

ジッター自体は止められません。ただし単発タスクの90秒の前倒しは、毎時の :00 と :30 を避ければ適用されなくなります。繰り返しタスクの最大30分の後ろずれは残るので、「9時台に走ればよい」処理に使い、「9時00分でなければ困る」処理には使わない、という設計にします(Anthropic「Run prompts on a schedule」(2026年9月29日確認))。

Q. Routines のプロンプトに渡した text が無視されます

ルーティン側のプロンプトが、そのペイロードを参照していないからです。text は <routine-fire-payload> ブロックに包まれ、信頼できないデータとして届きます。プロンプトに「routine-fire-payload ブロックに書かれた内容を調査する」のように明示的に書くと参照されます。

Q. Routines を1分おきに走らせたいです

できません。スケジュールトリガーの最小間隔は1時間で、それより頻繁なcron式は拒否されます。1分単位が必要なら Desktop のローカル定期タスクか /loop を使います。

Q. .claude/scheduled_tasks.json をリポジトリにコミットして配れますか

配っても走りません。保存されたタスクは作成したプロジェクトフォルダでのみ動きます。ファイルを別のフォルダにコピーすると、そこのセッションは一覧に出すだけで実行しないので、そのフォルダで作り直してください。.claude ディレクトリやそのファイルがシンボリックリンクの場合は、登録自体がエラーになります。

Q. Desktop の定期タスクが毎回権限待ちで止まります

タスクの権限モードが Manual で、必要なツールの承認が保存されていない状態です。作成直後に「Run now」を押し、出てくる確認で「always allow」を選んでおくと、以後の実行は同じツールを通します。ただし requiresUserInteraction が付いたMCPツールは always-allow の選択肢が無く、毎回止まります。

Q. Routines は同僚と共有できますか

できません。ルーティンは個人の claude.ai アカウントに属し、チームメンバーとは共有されません。実行中の操作は自分の名義で現れます。コミットとPRは自分のGitHubユーザーになり、コネクタ経由の操作も自分の連携アカウントを使います。

Q. /loop に自作のスラッシュコマンドを渡せますか

/loop 20m /review-pr 1234 のようにスキルを渡せます。ただしスケジュールされた発火で実行されるのは、Claudeが自分から呼べるスキルだけです。/permissions や /model のような組み込みコマンド、disable-model-invocation: true が付いたスキル、skillOverrides や Skill の deny ルールで隠したスキル、/mcp__github__list_prs のようなMCPプロンプトは、実行されずに素のテキストとしてClaudeに届きます。

運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る(無料)

参考・出典

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、AI開発ツール導入の失敗を減らせます。

導入を相談する

チームで学ぶなら: Claude Code 法人研修(2日間ハンズオン) / 1人で習得するなら: 個別指導(週1マンツーマン)