Claude Code スケジュール — 4 方式と落とし穴

Claude Code のスケジュール実行 — 4 方式の使い分け早見表

Claude Code のスケジュール実行は「セッション内で動かす」「クラウドで動かす」「自分の PC で動かす」「外部 cron から起動する」の 4 系統に分かれます。Anthropic 公式は前 3 系統を比較する表を Scheduled tasks ページに掲載しており、外部 cron は Claude Code Action(GitHub) や CLI 直接起動による事実上の選択肢として広く使われています(出典: Run prompts on a schedule)。

3 つのネイティブ方式は Pro / Max / Team / Enterprise プランで利用可能で、Free プランからはアクセスできません(出典: Installation)。読者のニーズは「PC を閉じても動かしたい」「cron 式で柔軟に設定したい」「/schedule の使い方が知りたい」の 3 つに分かれるため、目的別に下記章を読み分けてください。

/schedule と /loop の関係

/schedule コマンドは内部的に /loop バンドルスキルを呼び出すエイリアスとして実装されています。CLI 上で /schedule daily PR review at 9am と自然言語で指定すると、対応する cron 式に変換されてセッション内に登録されます。サブコマンドの /schedule update で cron 式を直接書き換えることもでき、既存の /loop API と完全互換です(出典: Run prompts on a schedule)。

ただし /schedule は セッションスコープ(現在の会話に紐づく)で、Routines や Desktop Schedule のようにセッション横断で永続しません。長期運用には別方式に乗り換えるのが正解です。

クラウド Routines — PC を閉じても 1 時間ごとに動く定期実行

クラウド Routines は、Anthropic マネージドのクラウドインフラで Claude Code セッションを自動的に走らせる仕組みです。プロンプト・対象リポジトリ・コネクタ・トリガーを 1 つの単位にまとめ、設定後は PC が閉じていても電源が切れていても稼働を続けます(出典: Routines)。研究プレビュー段階のため、API 形式や制限値は今後変更される可能性があります。

毎晩のバックログ整理・PR レビュー自動化・アラート発火時のトリアージなど、人間の介在なしで完結させたい繰り返し作業に最適です。Routines の設定手順と 3 種類のトリガーを把握しておくと、初期構築で迷う時間が減ります。

利用条件と GitHub App のインストール

Routines は Pro / Max / Team / Enterprise プランで、claude.ai/code の Claude Code on the Web が有効になっている必要があります。Free プランからは利用できません。GitHub トリガーを使う場合、Claude GitHub App をリポジトリにインストールする必要があり、CLI の /web-setup ではアプリインストールまでは行われない点に注意してください(出典: Routines)。

GitHub アカウント連携経由で実行されるため、ルーティンが作成するコミット・PR は実行ユーザー本人として記録されます。Slack や Linear など接続済みの MCP コネクタもユーザーアカウント権限で動きます。アクセス範囲は対象リポジトリ・環境設定・コネクタ選択で絞り込みます。

スケジュールトリガー(最小 1 時間)

スケジュールトリガーはプリセット(Hourly / Daily / Weekdays / Weekly)か、/schedule update で cron 式を直接指定します。最小間隔は 1 時間で、それより短い式は拒否されます。5 分ごとや 15 分ごとの実行が必要なら、後述の Desktop Schedule か /schedule(セッション内)を使ってください(出典: Routines)。

cron 式には jitter(最大 10% または 15 分の遅延)が必ず加算されるため、0 9 * * * のように 0 分や 30 分ちょうどを指定すると揺れ幅が大きく出ます。3 9 * * * のように奇数分を指定すると jitter が相対的に小さくなる運用知見が公式ドキュメントに記載されています(出典: Run prompts on a schedule)。

API トリガーと curl サンプル

Routines は専用 HTTP エンドポイント /fire に POST すると即座に起動できます。Authorization: Bearer ヘッダーに加え、anthropic-beta: experimental-cc-routine-2026-04-01 ベータヘッダーが必須です。研究プレビュー期間中はリクエスト形式が変わる可能性があり、最新 2 世代のベータヘッダーまでは受理される設計になっています(出典: Routines)。

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_xxx/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod."}'

text フィールドにアラート本文や任意の文字列を渡せるため、Sentry / Datadog / PagerDuty などからの Webhook をそのまま流し込んでトリアージさせる構成が定石です。

GitHub トリガー

Pull request または Release イベントに反応して走らせるトリガーです。フィルタで作者・タイトル・ラベル・ベースブランチ・ドラフト状態を絞り込めるため、「外部コントリビューターからの PR だけ Auto レビュー」「リリース時に CHANGELOG を再生成」のような運用が可能です。is draft = false でドラフトを除外する運用が定石です(出典: Routines)。

1 つの Routine は 複数トリガーを同時に持てる ため、「毎朝 9 時 + デプロイ後の API 呼び出し + 新規 PR」を 1 ルーティンに束ねる構成も組めます。

デスクトップ Schedule — ローカルファイルを毎朝触らせる予約

Desktop Schedule(ローカルスケジュールタスク)は、Claude Code Desktop が自分のマシン上で新しいセッションを自動起動する仕組みです。ローカルファイルへの直接アクセス・MCP 設定ファイルの利用・最小 1 分間隔という、クラウド Routines にはできない要件をカバーします(出典: Schedule recurring tasks)。

毎朝出社前にローカルリポジトリの依存関係を監査させる、夜間にローカルログを集計させる、社内 MCP サーバー経由で内部データを更新するといった用途に向きます。クラウド側にコードを置きたくない事情・置けない事情(機密ソース・社内 LAN 限定 API)と相性が良い構成です。

Routines と Desktop タスクの違い

両方ともデスクトップアプリの Routines ページから作成しますが、New routine 選択時に Local(ローカル)を選ぶと Desktop タスク、Remote(クラウド)を選ぶと Routines になります。両者は実行場所と前提が以下のように分かれます(出典: Schedule recurring tasks)。

• Desktop タスク: マシン起動が必須・ローカルファイル可・MCP 設定ファイルから読み込む・権限プロンプトをタスク単位で設定
• クラウド Routines: マシン起動不要・ローカルファイル不可(リポジトリのクローンのみ)・コネクタはタスク単位で設定・権限プロンプトなし(自律実行)

ローカルファイルや、自社 MCP 設定ファイル、社内固有のツールチェインに触れさせたいなら Desktop タスク一択です。

設定手順

サイドバーの Routines から New routine を押し、Local を選択。Name(タスク識別子・ファイル名にも使われる)・Description・Instructions(プロンプト本体・権限モードとモデルもここで指定)・Schedule・Folder(対象フォルダ、未信頼なら信頼ダイアログ)を埋めます。Schedule プリセットは Manual / Hourly / Daily / Weekdays / Weekly の 5 種、それ以外の間隔(15 分ごとなど)はセッション内で「15 分ごとにテストを走らせて」と自然言語指示すれば設定できます(出典: Schedule recurring tasks)。

権限モードはタスク単位で設定できます。Ask モードでツール権限不足が出ると、セッションは保留のままサイドバーに残ります。これを避けるには作成直後に Run now で 1 度実行し、各ツールに「always allow」を選んでおくと次回以降の同種ツールは自動承認されます。

Catch-up 仕様(missed runs)

PC をスリープさせて 9 時のタスクを逃した場合、起動 / 復帰時に 直近 7 日以内で missed した最後の 1 回だけ が catch-up として再実行されます。6 日寝かせた毎日タスクは合計 1 回しか走らない仕様です(出典: Schedule recurring tasks)。

「9 時のレビュー」を 23 時に走らせて困る場面では、プロンプト側に「17 時を過ぎていれば本日分はスキップして missed のサマリーだけ投稿」のようなガード条件を書き込んでおくと事故を防げます。タスクのプロンプト本体は ~/.claude/scheduled-tasks/<task-name>/SKILL.md に YAML フロントマター + 本文で保存され、ファイル直接編集も次回実行から反映されます。

/schedule と /loop — セッション内で繰り返し走らせる

/schedule コマンド(/loop バンドルスキルのエイリアス)は セッションスコープのスケジューリングで、現在の会話に紐づきます。Routines や Desktop タスクのようにセッション横断で永続せず、7 日で自動失効 する点が大きな特徴です(出典: Run prompts on a schedule)。

「デプロイが終わったか 5 分ごとにチェック」「PR にコメントが来たら拾い続ける」のような、開いたセッションに張り付けて使う短期ポーリングに最適です。長期監視用途には向きません。

3 つの呼び出しパターン

/schedule(/loop)は引数の与え方によって 3 種類の挙動になります(出典: Run prompts on a schedule)。

• インターバル + プロンプト: /loop 5m check the deploy で 5 分ごとに固定実行。s m h d 単位、cron に丸めできない値は近似に丸められます。
• プロンプトのみ: /loop check whether CI passed でインターバルを Claude が動的に選択。1 分〜1 時間の範囲で観測内容に応じて短く / 長く調整します。
• 何も指定しない: /loop 単独でビルトインのメンテナンスプロンプト(未完了作業 + PR ケア + クリーンアップ)が動的間隔で走ります。.claude/loop.md か ~/.claude/loop.md で上書き可能。

停止は待機中に Esc キー。1 セッションあたり最大 50 タスクまで持てます。--resume / --continue で再開する場合、有効期限内(7 日)のタスクのみ復元され、新規セッションを始めると消失します。

Auto モードとの組み合わせ

/schedule は権限モードとして Auto モード と組み合わせると「夜中に確認なしで走り続ける」運用が可能になります。Max + Opus 4.7 で --enable-auto-mode フラグなしで Auto モードが有効化されるため、夜間の長時間タスクをセッション内 /loop に張り付けて翌朝結果だけ確認する構成が組めます(出典: Use Claude Code Desktop)。

ただし Auto モードは Bypass permissions(サンドボックス専用・全許可)とは別物で、本番リポジトリでは安全チェックが効く Auto モードを使うのが正解です。

GitHub Actions cron / OS crontab との使い分け

ネイティブ 3 方式に加え、Claude Code は CLI として外部 cron から呼び出す運用も可能です。既存の GitHub Actions ワークフローや OS の crontab に Claude Code を組み込みたい ケースでは、ネイティブ方式と外部 cron のどちらを選ぶかが論点になります。

選択基準は「既存 CI 資産との統合」「複数リポジトリ横断」「インフラ管理範囲」の 3 点です。GitHub Actions に既に多数のワークフローがある組織は、Claude Code Action を cron トリガーで呼ぶ方が一貫性が出ます。OS crontab は個人の自宅サーバーや常時起動のワークステーションで動かす場合に有効です。

GitHub Actions cron + Claude Code Action

GitHub Actions の schedule トリガーは cron 式で記述でき、Claude Code Action(anthropics/claude-code-action)を呼び出して定期実行できます。最小間隔は 5 分ですが、GitHub のドキュメント上は 1 分指定も可能(実用上は 5 分が下限)です(出典: GitHub - Schedule events)。

クラウド Routines との比較で言うと、GitHub Actions cron は 既存の CI 資産・Secrets 管理・Artifacts と統合できる メリットがあります。一方で実行環境はランナー単位の使い捨てで、長期コンテキストを保持したいケースには Routines が向きます。1 ジョブごとに API トークン消費が発生するため、頻度の高い実行は Routines のサブスクリプション枠で吸収する方がコスト的に有利です。

OS crontab + Claude Code CLI

Linux / macOS の crontab に Claude Code CLI を直接登録する運用も可能で、crontab -e で 0 9 * * * /usr/local/bin/claude --print "毎朝のメール要約をして" のように書けます。最小間隔は OS の cron 仕様(1 分)に従います。

OS cron は 常時起動のワークステーションや自宅サーバーで動かす 場合に向きますが、Desktop Schedule と比較すると権限モード(Auto / Ask)を細かく制御しにくく、SKILL.md 形式のテンプレ管理もできません。本格運用では Desktop Schedule に移行する方が運用しやすいでしょう。

スケジュール実行の落とし穴 — Free 不可・1 時間下限・7 日失効

公式ドキュメントを読まずに導入すると引っかかる典型的な制約と、回避策を整理します。一次情報の確認は必ず実機検証とセットで行ってください。本章で扱うのは、初期構築時に最も問い合わせの多い 6 項目です。

Free プラン誤解・Routines 1 時間下限・/schedule 7 日失効・Desktop タスクの PC スリープ問題・cron 式の jitter・API トリガーのベータヘッダー必須要件の順に、なぜそうなるのかと回避策をセットで示します。

Free プランは Claude Code 自体が使えない

Claude Code は Pro($20/月)以上が必要で、Free プランからは /schedule・Routines・Desktop Schedule のいずれもアクセス不能です。「Claude を無料でスケジュール実行したい」というご要望に対しては、まず Pro 加入が前提になる旨を最初にお伝えしておきます(出典: Installation)。料金詳細は Claude 料金完全ガイド を参照してください。

Routines の最小間隔は 1 時間 — 5 分ごとには走らせられない

Routines は最小実行間隔 1 時間で、*/5 * * * * のような短間隔 cron 式は拒否されます。5 分ごとや 15 分ごとの実行が必要なら、ローカル Desktop タスク(最小 1 分)か /schedule(最小 1 分)を使い分けてください(出典: Routines)。

また Routines にはアカウント単位の 1 日あたりルーティン実行回数キャップ が別途設定されており、サブスクリプション通常使用量とは独立して効きます。1 回限りの実行(one-off run)はこの日次キャップを消費しません。

/schedule は 7 日で自動失効 — 長期監視には使わない

セッション再開しないまま 7 日経過した /schedule タスクは最後に 1 回だけ発火して自動削除されます。リリース後 1 ヶ月の監視のような用途では失効してしまうため、Routines か Desktop タスクで永続化するのが正解です(出典: Run prompts on a schedule)。

短期ポーリングが目的なら /schedule で十分ですが、長期運用 = 別方式という判断軸を最初に持っておくと、後から方式変更で構成を組み直す手間を避けられます。

Desktop Schedule は PC スリープで missed — keep awake で防止

ノート PC のフタを閉じるとスリープに入り、その時間帯の Desktop タスクは catch-up が 1 回しか走りません。Settings → Desktop app → General → Keep computer awake を有効にしておくとアイドルスリープを防げます。フタを閉じるとそれでもスリープするため、毎晩走らせたい場合は電源接続 + 蓋開放が前提です(出典: Schedule recurring tasks)。

外出先で動かしたい場合は、最初からクラウド Routines を選ぶ方が運用負荷が低くなります。

cron 式には jitter が加わる(最大 10% / 15 分)

0 9 * * * のように 0 分指定の cron 式には jitter(最大 10% または 15 分の遅延)が必ず加算されます。厳密に 9 時きっかりに走らせたい用途では、3 9 * * * のように奇数分を指定すると jitter が相対的に小さくなる運用知見が公式に記載されています(出典: Run prompts on a schedule)。

毎時実行で 0 * * * * を多用する場合、1 つのアカウントから同時刻に多数のジョブが発火しない設計 にしておくとリトライ集中によるレート制限を避けられます。

Routines API トリガーはベータヘッダー必須

/fire エンドポイントは anthropic-beta: experimental-cc-routine-2026-04-01 ヘッダーが必須で、ヘッダーなしでは弾かれます。研究プレビュー期間中はリクエスト / レスポンス形式が変わる可能性があり、最新 2 世代のベータヘッダーまでは受理される設計です(出典: Routines)。

本番運用では当該ヘッダーをシークレット管理側に明示しておくと、ローテーション時の事故を防げます。Webhook 受け側のコードで「ベータヘッダーを忘れて 400 エラー」は導入初週に必ず 1 度は遭遇する事案です。

出典(一次情報)

公式ドキュメントを最新版で確認したい場合は、以下を参照してください。研究プレビュー段階の機能(Routines / Auto モード)は今後仕様変更が入る可能性があります。

• Run prompts on a schedule — /schedule / /loop / cron 式の jitter ルールの一次情報
• Automate work with routines — Routines のトリガー・作成・API リファレンス
• Schedule recurring tasks in Claude Code Desktop — Desktop Schedule の比較表・catch-up 仕様
• Use Claude Code Desktop — Auto モードと Bypass permissions の権限モード解説
• Claude Code Changelog — v2.1.111(2026-04-16)以降の Auto モード仕様変更履歴
• GitHub - Events that trigger workflows: schedule — GitHub Actions cron 仕様

関連記事

スケジュール実行を組み込む前に、Claude Code 自体の使い方や料金を確認しておくと事故が減ります。

• Claude Code 自動化ガイド — Routines・Headless・4 方式 — Routines トリガー種別・Headless モード・CI 統合の詳細解説
• Claude Code 4 月大型更新まとめ — Auto モード・Routines・xhigh の速報
• Claude Code 完全ガイド — インストール・基本操作の入門
• Claude 料金完全ガイド — Pro / Max / Team の料金とプラン別機能