Claude Codeの定期実行・自動化の全パターン｜schedule / loop / cronの使い分け

エンジニアのゆとです。

Claude Codeを使っていて、あるとき気づいた。「毎朝PRレビューして」「ビルド壊れたら教えて」「週1で依存パッケージの脆弱性チェックして」。こういう繰り返し作業、毎回手動でClaude Codeに頼んでいた自分がいた。

でも考えてみてほしい。Claude Codeには「定期実行」の仕組みが3つもある。つまり、AIに「明日からこれ毎朝やっといて」と言えば、本当にやってくれるということだ。cronジョブの感覚で、AIエージェントが自律的にタスクを回してくれる世界。

この記事では、Claude Codeの3つのスケジューリング機能を全部掘り下げる。それぞれの仕組み、設定方法、ユースケース、そして「どれを使えばいいの？」の判断基準まで。cron式の書き方も含めて、これを読めば自動化の選択肢で迷わなくなるはず。

Claude Codeの「定期実行」は3種類ある

まず全体像を掴んでおこう。Claude Codeで定期的にタスクを実行する方法は、以下の3つ。

• Cloud Scheduled Tasks（/schedule） — Anthropicのクラウド上で動く。PCの電源がオフでも実行される。GitHubリポジトリが対象
• Desktop Scheduled Tasks — Claude Code Desktopアプリ上で動く。ローカルファイルに直接アクセスできる。マシンが起動している必要あり
• /loop — セッション内で動くポーリング。「5分おきにビルドチェック」みたいな一時的な監視に使う。セッション終了で消える

イメージとしては、Cloud Scheduled Tasksが「クラウド上のcronジョブ」、Desktop Scheduled Tasksが「ローカルのcronジョブ」、/loopが「シェルでwatchコマンドを叩いている感覚」に近い。

それぞれ得意なシーンが全然違うので、順番に見ていく。

Cloud Scheduled Tasks（/schedule）— クラウドで定期実行

一番パワフルで、一番「放置できる」のがこれ。Anthropicのクラウド環境でClaude Codeが起動し、指定した頻度でタスクを実行してくれる。自分のPCが寝ていても、旅行中でも、深夜3時でも動く。

作成方法は3つ

Cloud Scheduled Tasksの作成方法は複数用意されている。

1. CLIから対話的に作成

/schedule

これを実行すると、Claude Codeが「何をしたい？」「どのリポジトリ？」「頻度は？」と順番に聞いてくれる。自然言語で答えればOK。

2. CLIからワンライナーで作成

/schedule daily PR review at 9am

自然言語で一気に指定することもできる。Claude Codeが意図を解釈して、適切なスケジュールを組んでくれる。「毎朝9時にPRレビューして」と日本語で書いても通る。

3. Webから作成

ブラウザで直接設定画面にアクセスできる。

claude.ai

Claude Code Scheduled Tasks ブラウザからCloud Scheduled Tasksの作成・管理ができる

4. Desktopアプリから作成

Claude Code Desktopアプリの Schedule ページ → 「New task」 → 「New remote task」でもクラウドタスクを作成できる。GUIで設定したい人はこっちのほうが直感的かもしれない。

動作の仕組み

Cloud Scheduled Tasksの裏側で何が起きているかを理解しておくと、トラブルシューティングが圧倒的に楽になる。

実行のたびに、Anthropicのクラウド環境でこういう流れが走る:

1. 指定したGitHubリポジトリがクローンされる
2. セットアップスクリプト（設定していれば）が実行される
3. タスクの指示内容に従ってClaude Codeが動く
4. 結果がconnector経由で通知される（Slack、Linear等）
5. 必要に応じてclaude/プレフィックス付きのブランチが作成される

ここで重要なのが「毎回クローンされる」という点。ローカルのワーキングツリーの状態は関係ない。あくまでGitHubのリモートリポジトリの最新状態がベースになる。

だから、Cloud Scheduled Tasksが使えるのはGitHubリポジトリが対象のタスクに限られる。ローカルにしかないファイルを処理したいなら、後述のDesktop Scheduled Tasksを使う必要がある。

ブランチの扱い

Claude Codeがコード変更を伴うタスク（例: 依存パッケージの更新）を実行すると、claude/プレフィックスのブランチを自動で作成し、そこにコミットしてPRを出してくれる。mainブランチに直接プッシュされることはないので安心していい。

claude/update-dependencies-2026-03-28
claude/fix-type-errors-2026-03-28

こんな感じのブランチ名になる。

Connectors（通知連携）

実行結果を受け取る先として、複数のconnectorが用意されている。

• Slack — チャンネルに結果を投稿
• Linear — Issueを自動作成
• Google Drive — レポートをドキュメントに書き出し
• その他、今後も追加予定

connectorを設定しておけば、「毎朝9時にPRレビューして、結果をSlackの#dev-reviewチャンネルに投げて」みたいなワークフローが組める。GitHub Actionsのレポーティングに近いが、AIがレビューの中身まで書いてくれるのが違う。

クラウド環境の設定

Cloud環境ではネットワークアクセスが可能で、環境変数やセットアップスクリプトも設定できる。

• 環境変数: APIキーやシークレットをセキュアに設定可能。タスクの実行環境にのみ注入される
• セットアップスクリプト: タスク実行前に走るシェルスクリプト。npm installやpip installなど、依存関係のインストールに使う
• ネットワークアクセス: 外部APIの呼び出しやパッケージのインストールが可能

たとえば、CI失敗の分析タスクなら、GitHub APIのトークンを環境変数に設定しておいて、セットアップスクリプトで必要なCLIツールをインストールする、という構成になる。

頻度設定

実行頻度は以下から選べる:

• Hourly（毎時） — 1時間おき。最小間隔がこれ。5分おきにはできない
• Daily（毎日） — 指定した時刻に1日1回
• Weekdays（平日） — 月〜金の指定時刻
• Weekly（毎週） — 週1回、指定した曜日と時刻

最小間隔が1時間という制約は覚えておこう。もっと短い間隔でポーリングしたいなら、/loopを使う。

管理コマンド

作成済みのタスクを管理するコマンドも揃っている。

# タスク一覧
/schedule list

# タスクの設定変更
/schedule update

# 今すぐ手動実行（デバッグ用）
/schedule run

/schedule runは地味に便利。「設定したタスクがちゃんと動くか、まず手動で試したい」というときに使う。スケジュールを待たずにすぐ実行できる。

Cloud Scheduled Tasksの実践ユースケース

毎朝のPRレビュー

/schedule daily at 9am review all open PRs,
summarize changes, flag potential issues,
and post results to Slack #dev-review

朝出社したらSlackにレビューサマリーが届いている。全PRに目を通す前に、AIの所見を確認できる。もちろんAIレビューだけで済ませるわけじゃないが、「どのPRを優先的に見るべきか」のトリアージには十分使える。

CI失敗の自動分析

/schedule hourly check for failed CI runs,
analyze the failure logs, identify root cause,
and create a Linear issue with suggested fix

ビルドが壊れたら、原因分析とIssue作成まで自動でやってくれる。「誰かがmainを壊した」を1時間以内に検知してチケット化できる。

依存パッケージの脆弱性監査

/schedule weekly on monday at 10am
run npm audit, analyze vulnerabilities,
and create a PR to update affected packages

週次のセキュリティチェック。npm auditの結果をAIが読んで、重要度の高い脆弱性があればアップデートPRまで作ってくれる。dependabotと似ているが、AIがCHANGELOGを読んで破壊的変更の有無まで判断してくれるのが強い。

ドキュメント同期

/schedule daily at 6pm
check if code changes have corresponding doc updates,
create a PR to update outdated documentation

コードを変更したのにドキュメントを更新し忘れている箇所を検出して、ドキュメントの更新PRを自動作成。ドキュメントの陳腐化は地味に痛いので、これは助かる。

Desktop Scheduled Tasks — ローカルで定期実行

Cloud版が「クラウドのcronジョブ」なら、Desktop Scheduled Tasksは「ローカルのcronジョブ」だ。Claude Code Desktopアプリ上で動き、ローカルのファイルシステムに直接アクセスできる。

Cloud版との最大の違い

Desktop Scheduled Tasksの最大の特徴は、ローカルファイルにアクセスできること。GitHubにプッシュしていないファイル、ローカルのデータベース、設定ファイルなど、マシン上にあるものすべてが対象になる。

その代わり、マシンが起動していて、Claude Code Desktopアプリが開いている必要がある。PCを閉じたら動かない。

設定方法

Claude Code Desktopアプリの Scheduleページ → 「New task」から作成する。設定項目は以下の通り:

• タスク名: 識別用の名前
• 指示内容: Claude Codeに実行させたい内容を自然言語で記述
• プロジェクトパス: 対象のディレクトリ
• 実行頻度: manual / hourly / daily / weekdays / weekly
• Worktree isolation: 有効にすると、git worktreeで隔離された環境でタスクが実行される。本番のワーキングツリーを汚さない
• Permission mode: タスクごとに権限モードを設定できる（例えば危険な操作は禁止する等）

実行頻度

Cloud版と同じ選択肢に加えて、manual（手動） がある。

• Manual — 手動トリガーのみ。定期実行はしないが、ワンクリックで呼び出せるショートカット的な使い方
• Hourly — 1時間おき
• Daily — 1日1回
• Weekdays — 平日のみ
• Weekly — 週1回

Worktree隔離

これは地味に重要な機能。有効にすると、タスクの実行がgit worktreeで隔離される。つまり、タスクがファイルを変更しても、自分が作業中のワーキングツリーには影響しない。

たとえば「毎時テストを全部走らせて、失敗したら修正コミットを作って」というタスクを設定する場合、worktree隔離を有効にしておけば、自分のブランチでコーディング中に突然ファイルが書き換わる、みたいな事故が防げる。

見逃し実行のキャッチアップ

PCがスリープしていたり、アプリが閉じていたりしてタスクの実行タイミングを逃した場合、直近7日以内の見逃し分は、次にアプリが起動したときに1回だけキャッチアップ実行される。

朝のデイリータスクを設定していて、週末ずっとPCを閉じていた場合:

• 月曜の朝にPCを開くと、直近の見逃し分が1回だけ実行される
• 金曜・土曜・日曜の分が3回走るわけではない。あくまで「最後にやり損ねた1回」だけ

これは賢い設計だと思う。3日分まとめて実行されたらリソースの無駄だし、結果も混乱する。

「コンピュータを起動したままにする」設定

Desktop Scheduled Tasksには「Keep computer awake」的な設定もある。タスクの実行中にMacがスリープに入らないようにする設定で、長時間実行されるタスクがスリープで中断されるのを防いでくれる。

タスクファイルの保存場所

Desktop Scheduled Tasksの定義ファイルは、以下のパスに保存される。

~/.claude/scheduled-tasks/<タスク名>/SKILL.md

中身はMarkdown形式で、タスクの指示内容がそのまま書かれている。手動でこのファイルを編集してもいいし、バージョン管理に含めることもできる。

Desktop Scheduled Tasksの実践ユースケース

ローカルのログ監視

Hourly: Check ~/logs/app.log for errors in the last hour.
If critical errors found, summarize them and
save a report to ~/reports/

本番サーバーのログをマシンに転送している環境なら、ローカルのログファイルを定期的に解析させるのに使える。

ローカルDBのヘルスチェック

Daily at 8am: Connect to the local PostgreSQL database,
check table sizes, index usage stats,
slow queries from pg_stat_statements,
and save a health report

開発環境のDBの状態チェック。テーブルサイズの肥大化やインデックスの未使用をAIが検出してくれる。

作業ディレクトリの整理

Weekly on Friday at 5pm: Scan ~/Projects for repos
with uncommitted changes older than 3 days,
list them, and remind me which branches
need to be pushed or cleaned up

金曜の夕方に「コミットし忘れてるブランチないですか？」と教えてくれる秘書的な使い方。地味だけど、週末に入る前にこれがあると安心感が違う。

/loop — セッション内ポーリング

/loopは他の2つとは毛色が違う。「セッション内で繰り返し実行」するためのコマンドで、セッションを閉じると消える。言い換えれば、使い捨てのcronジョブ。

基本構文

/loop 5m check the build status

これで「5分おきにビルドステータスをチェック」が始まる。

インターバルの指定方法

インターバルは3つの指定パターンがある。

先頭に書く（leading）

/loop 5m check the build

一番よく使う形式。5mが先頭にあるので、5分間隔で実行される。

末尾に書く（trailing）

/loop check the build every 2 hours

自然言語的に「every 2 hours」と末尾に書いてもOK。

省略（デフォルト10分）

/loop check the build

間隔を省略すると、デフォルトの10分間隔になる。

時間単位

使える時間単位は以下の通り:

• s — 秒（例: 30s）
• m — 分（例: 5m）
• h — 時間（例: 2h）
• d — 日（例: 1d）

他のコマンドと組み合わせる

/loopの面白いところは、他のスラッシュコマンドを中に入れられること。

/loop 20m /review-pr 1234

これで「20分おきにPR #1234をレビュー」が回る。PRに新しいコミットが追加されるたびに、最新の状態でレビューしてくれるイメージ。コードレビューのラウンドトリップが多いPRで特に便利。

ワンタイムリマインダー

実は/loopは繰り返しだけでなく、ワンタイムのリマインダーとしても使える。

remind me at 3pm to push the branch

これで3時になったら「ブランチをプッシュしてください」とリマインドしてくれる。/loopコマンドとして明示的に書かなくても、「remind me」という自然言語で認識してくれる。

内部の仕組み: CronCreate / CronList / CronDelete

/loopの裏側では、以下のツールが動いている。

• CronCreate — ループを作成する
• CronList — 実行中のループ一覧を確認する
• CronDelete — ループを削除する

通常は/loopコマンドから間接的に使うが、Claude Codeに直接「CronListで今動いてるループ見せて」と頼むこともできる。

自動有効期限

/loopで作成したループには、3日間の自動有効期限がある。セッションを閉じなくても、3日経ったら自動で消える。

これは安全弁として良い設計。「うっかり止め忘れたループがずっと回り続けている」という事態を防いでくれる。

ジッター（実行タイミングのゆらぎ）

繰り返し実行には最大10%のジッター（遅延のゆらぎ）がかかる。ただし上限は15分。

つまり「5分おき」と設定しても、実際には5分〜5分30秒の間のどこかで実行される。「1時間おき」なら1時間〜1時間6分の間。この揺らぎはサーバー側の負荷分散のためなので、秒単位の精度が必要な用途には向かない。

ワンタイムリマインダーの場合、ジッターは発生しない。「3時にリマインドして」と言えば、きっちり3時に通知される。

/loopの実践ユースケース

デプロイ後の監視

/loop 5m check the production logs for errors since the last deploy

デプロイ直後の数時間、エラーログを監視させる。問題が見つかったら即座に報告してくれるので、安心してデプロイできる。

長時間ビルドの完了待ち

/loop 2m check if the CI build for PR #456 has completed

ビルドが終わったら教えてくれる。ブラウザのGitHub Actionsタブをリロードし続ける必要がなくなる。

テストの連続実行

/loop 10m run the integration tests and report any new failures

リファクタリング中にテストを定期的に回して、壊した瞬間を早期に検出する。

3つの方式の使い分け

ここまで3種類のスケジューリング機能を見てきた。「結局どれを使えばいいの？」をまとめておく。

Cloud Scheduled Tasks が向いているケース

• PCの電源状態に関係なく確実に実行したい
• GitHubリポジトリに対する操作（PRレビュー、CI分析、依存更新など）
• チーム向けの定期レポートを生成したい
• 結果をSlackやLinearに自動で送りたい
• 「設定したら完全に放置したい」ワークフロー

Desktop Scheduled Tasks が向いているケース

• ローカルファイルへのアクセスが必要
• GitHubに上がっていないプロジェクトが対象
• ローカルのデータベースやサービスを使う
• Worktree隔離で安全にタスクを実行したい
• 「マシンが起動している間は自動で回したい」ワークフロー

/loop が向いているケース

• 一時的な監視（デプロイ後のエラー監視など）
• 「今日だけ」のポーリング
• 1時間未満の短いインターバルが必要
• セッション内で完結するタスク
• リマインダー的な用途

判断フローチャート

迷ったらこの順番で考えるといい:

1. ローカルファイルへのアクセスが必要？ → Yes: Desktop Scheduled Tasks
2. PCが閉じていても動いてほしい？ → Yes: Cloud Scheduled Tasks
3. 今日だけ、今のセッションだけでいい？ → Yes: /loop
4. GitHubリポジトリ対象で定期的に回したい？ → Cloud Scheduled Tasks
5. ローカルで定期的に回したい？ → Desktop Scheduled Tasks

cron式クイックリファレンス

Cloud Scheduled TasksもDesktop Scheduled Tasksも、内部的にはcron式でスケジュールが管理されている。GUIから設定する場合は意識しなくていいが、CLIから細かく指定したいときに知っておくと便利。

5フィールド形式

┌───────── 分 (0-59)
│ ┌─────── 時 (0-23)
│ │ ┌───── 日 (1-31)
│ │ │ ┌─── 月 (1-12)
│ │ │ │ ┌─ 曜日 (0-6, 0=日曜)
│ │ │ │ │
* * * * *

よく使うパターン

• 0 9 * * * — 毎日9:00
• 0 9 * * 1-5 — 平日9:00
• 0 */2 * * * — 2時間おき
• 30 8 * * 1 — 毎週月曜8:30
• 0 0 1 * * — 毎月1日の0:00
• 0 9,18 * * * — 毎日9:00と18:00の2回

特殊文字

• * — すべての値にマッチ
• , — 複数の値を列挙（例: 1,3,5）
• - — 範囲指定（例: 1-5 = 月〜金）
• / — ステップ指定（例: */2 = 2つおき）

cron式を手動で書くのが面倒なら、Claude Codeに自然言語で伝えればいい。「平日の朝9時と夕方6時」と言えば、正しいcron式に変換してくれる。

実践レシピ集

ここからは、実際に使えるレシピをいくつか紹介する。コピペしてそのまま使ってもいいし、自分の環境に合わせてアレンジしてもいい。

レシピ1: 毎朝のコードベースヘルスチェック

/schedule daily at 8am
Analyze the codebase health:
1. Check for TODO/FIXME comments added in the last 7 days
2. Find functions longer than 50 lines
3. Identify unused imports
4. Check test coverage trends
Post a summary to Slack #engineering

毎朝のスタンドアップ前に、コードベースの健康診断レポートが届く。「TODOが増えてるぞ」「この関数デカくなりすぎ」みたいなシグナルを早期にキャッチできる。

レシピ2: PR自動ラベリング

/schedule hourly
Check for new PRs without labels.
Analyze the changed files and add appropriate labels:
- "frontend" if UI/component changes
- "backend" if API/database changes
- "docs" if documentation changes
- "deps" if dependency updates
- "breaking" if public API changes detected

PRのラベリングを手動でやるのは面倒だし忘れがち。AIが変更内容を読んで自動でラベルを付けてくれる。

レシピ3: デプロイ後の5分監視

/loop 1m for the next 30 minutes, check the error rate
in production logs. If error rate exceeds 1%,
alert me immediately with the error details

デプロイ直後に1分間隔でエラーレートを監視。閾値を超えたら即座に報告。カナリアデプロイ的な使い方ができる。

レシピ4: 週次の技術負債レポート

/schedule weekly on friday at 4pm
Generate a technical debt report:
1. List all TODO/HACK/FIXME with file locations
2. Dependencies with known vulnerabilities (npm audit)
3. Files with the most changes in the past week (churn analysis)
4. Outdated dependencies (major version behind)
Create a GitHub issue titled "Weekly Tech Debt Report - [date]"

金曜の夕方に技術負債レポートが自動生成される。スプリントのふりかえりに使えるし、「来週はここの負債を返そう」の判断材料になる。

レシピ5: Desktop版でローカル開発環境の整理

Desktop Schedule (Weekly, Friday 5pm):
Scan all projects in ~/Projects:
1. List repos with uncommitted changes
2. Find branches that are behind remote/main by more than 10 commits
3. Check disk usage of node_modules directories
4. Identify .env files that differ from .env.example
Save report to ~/weekly-dev-cleanup.md

開発環境の掃除レポート。「このリポジトリ、3週間前のブランチに取り残されてますよ」みたいな情報が週次で届く。

知っておくべきTips

cron実行を完全に無効化する

何らかの理由で、Claude Codeのcron関連機能を全部止めたい場合は、環境変数を設定する。

export CLAUDE_CODE_DISABLE_CRON=1

これでCronCreate / CronList / CronDeleteのツールが無効化され、/loopも使えなくなる。CI環境でClaude Codeを実行するときに、意図しないループが起動するのを防ぎたい場面で使える。

Cloud版の実行ログを確認する

Cloud Scheduled Tasksの実行結果は、claude.ai/code/scheduled のダッシュボードから確認できる。各実行の入出力ログ、成功/失敗ステータス、実行時間などが記録されている。タスクがうまく動かないときはここを見るのが最初のステップ。

Desktop版のSKILL.mdを直接編集する

Desktop Scheduled Tasksの定義は ~/.claude/scheduled-tasks/<タスク名>/SKILL.md に保存されている。GUIから編集してもいいが、Markdownファイルを直接いじるほうが効率的な場面もある。特に、複雑な指示を書くときはエディタで編集してから保存するのがおすすめ。

/loopのキャンセル

/loopで走り始めたポーリングを止めたいときは、Claude Codeに「ループを止めて」と伝えればいい。内部的にはCronDeleteツールが呼ばれて、ループが削除される。

# ループ一覧を確認
> 今動いてるループを見せて

# 特定のループを止める
> ビルド監視のループを止めて

実行タイミングのずれを許容する

/loopのジッターの話でも触れたが、スケジューリング機能全般に言えることとして、「秒単位の精度」は期待しないほうがいい。これはcronジョブ全般に言えることで、システム負荷やネットワーク状況で数秒〜数十秒のずれは普通に発生する。

「9:00:00ちょうどに動かないとダメ」みたいな用途には向かない。そういう場合は素直にcronやGitHub Actionsのスケジュールトリガーを使おう。

まとめ

Claude Codeの3つのスケジューリング機能を整理すると:

• Cloud Scheduled Tasks は「放置してOK」の定期ジョブ。GitHub連携が前提で、PCの電源状態に左右されない。PRレビュー、CI分析、依存チェックなどチーム開発のルーティンに最適
• Desktop Scheduled Tasks は「ローカルファイルに触れる」定期ジョブ。マシンが起動していれば確実に動く。開発環境の整理やローカルDBの監視に便利
• /loop は「今だけ使い捨て」のポーリング。デプロイ後の監視やビルド完了待ちなど、一時的な繰り返しに最適。3日で自動消滅

個人的には、Cloud Scheduled Tasksの「PRレビュー」と「依存パッケージ監査」の2つを設定するだけで、かなり開発ライフが変わると思っている。朝イチで「AIがレビューしてくれたPR一覧」がSlackに届いているのは、なんというか、優秀なジュニアエンジニアがチームに加わった感覚に近い。

AIにタスクを任せるとき、「1回だけの指示」と「定期的な自動実行」では、得られる価値がまるで違う。1回だけなら便利なツール。定期実行なら、チームの一員。Claude Codeのスケジューリング機能は、AIを「たまに使うツール」から「常に動いている仲間」に変えてくれる仕組みだと思う。

docs.anthropic.com

Claude Code 公式ドキュメント Claude Codeの公式ドキュメント。スケジューリング機能の最新仕様はこちらで確認できる。