Claude Code Scheduled Tasks実践ガイド — /loop・CronCreate・Desktop定期実行で実現するAIオートパイロット開発
Claude Codeに「時間の概念」が加わった。/loopで5分ごとにデプロイを監視し、CronCreateで毎朝9時にコードレビューを走らせ、Desktopで永続的なレポート生成を仕掛ける——2026年春、Claude Codeは対話ツールから自律バックグラウンドワーカーへと進化した。
本記事では、3階層のスケジューリング機能を体系的に整理し、すぐに使える実践レシピとハマりポイントを解説する。
Claude Code スケジューリングの3階層を理解する
Claude Codeのスケジューリングは、用途と寿命が異なる3つのレイヤーで構成されている。まずは全体像を掴もう。
/loop — セッション内のシンプルなインターバル実行
最も手軽なのが/loopコマンドだ。スラッシュコマンドやプロンプトを指定間隔で繰り返し実行する。
/loop 5m デプロイのヘルスチェックを実行して結果を報告して
デフォルト間隔は10分。/loop 5m /fooのように間隔とコマンドを指定する。セッションを閉じれば当然止まる。「ちょっと監視しておきたい」程度の用途にはこれで十分だ。
CronCreate — cron式による柔軟なセッションスコープスケジューリング
より柔軟な制御が必要ならCronCreateツールを使う。標準5フィールドcron式(分 時 日 月 曜日)をローカルタイムゾーンで指定できる。
CronCreate cron='57 8 * * 1-5' prompt='srcディレクトリの変更差分をレビューして'
recurring: true(デフォルト)で定期実行、recurring: falseでワンショット(リマインダー用途)の2モードがある。
管理はCronListで一覧確認、CronDelete id='xxx'で削除というシンプルな操作体系だ。
ただし、CronCreateには理解しておくべき重要な制約がある(後述のハマりポイントで詳しく解説する)。
Desktop Scheduled Tasks — 永続的なバックグラウンドタスク
Desktop版Claude Codeでは、永続タスクとしてディスクに保存されるスケジュールタスクを作成できる。セッション終了後も存続する上位レイヤーだ。CLIのCronCreateがセッションスコープで消えてしまうのに対し、Desktop版は明示的に削除するまで残り続ける。
3階層の使い分け早見表
| 特性 | /loop | CronCreate | Desktop永続タスク |
|---|---|---|---|
| 手軽さ | 最も手軽 | 中程度 | 設定が必要 |
| スケジュール柔軟性 | 固定間隔のみ | cron式で自在 | プリセット選択式(Hourly/Daily/Weekdays/Weekly等) |
| 永続性 | セッション中のみ | セッション中(最大3日) | 永続 |
| 主な用途 | アドホック監視 | 開発中の定期タスク | 長期運用の自動化 |
実践レシピ集 — 今日から使える4つの自動化パターン
ここからは、コピペで使える具体的なレシピを紹介する。
レシピ1: デプロイ監視 — /loopで本番URLを5分間隔ヘルスチェック
デプロイ直後の安定性確認に最適なパターン。
/loop 5m 以下のURLにcurlでアクセスし、ステータスコードとレスポンスタイムを確認して。
200以外またはレスポンスが3秒を超えた場合は「ALERT」と明示して詳細を報告して。
正常時は1行で結果だけ報告して。
URL: https://myapp.vercel.app/api/health
ポイントは「正常時は簡潔に」という指示だ。毎回長々と報告されると邪魔になるので、異常時のみ詳細を出すようプロンプトを設計する。
レシピ2: 定期コードレビュー — CronCreateで毎朝git diffを自動レビュー
平日朝にチームの変更差分を自動レビューする設定。
CronCreate
cron='57 8 * * 1-5'
recurring=true
prompt='以下の手順でコードレビューを実行して:
1. git fetch origin && git diff origin/main...HEAD を取得
2. 差分がなければ「差分なし」と報告して終了
3. 差分がある場合、以下の観点でレビュー:
- セキュリティ上の問題(SQLインジェクション、XSS等)
- パフォーマンス懸念
- 明らかなバグ
4. 結果をCODE_REVIEW.mdに出力'
レシピ3: 依存関係チェック — 週次でnpm audit + outdatedを実行
CronCreate
cron='23 9 * * 1'
recurring=true
prompt='プロジェクトの依存関係を監査して:
1. npm audit --json を実行し、Critical/Highの脆弱性のみ報告
2. npm outdated を実行し、メジャーバージョンの更新があるものを報告
3. 結果をDEPS_REPORT.mdに出力
4. Critical脆弱性がある場合は冒頭に警告を記載'
毎週月曜9:23に実行。正直、依存関係の脆弱性チェックは後回しにしがちなので、こうして自動化しておくと精神衛生上もよい。
レシピ4: 日次レポート生成 — テスト結果・カバレッジをSlack通知
CronCreate
cron='47 17 * * 1-5'
recurring=true
prompt='日次開発レポートを生成して:
1. npm test を実行してテスト結果とカバレッジを取得
2. git log --oneline --since="8 hours ago" で本日のコミットを取得
3. 以下のMarkdownテンプレートで DAILY_REPORT.md を生成:
- テスト: 合計/成功/失敗
- カバレッジ: ライン/ブランチ
- 本日のコミット一覧
- 未解決の問題(テスト失敗がある場合)'
ハマりポイントと運用のベストプラクティス
ここからが本記事の肝だ。公式ドキュメントを読んだだけでは気づきにくい制約を先回りで解説する。
3日間自動期限切れへの対処法
CronCreateで作成したrecurringタスクは、3日間で自動的に期限切れになる。最後に1回発火してから削除される仕様だ。
つまり、金曜に設定した週次タスクが翌週月曜にはもう消えている、ということが起こりうる。長期運用が必要なタスクには、Desktop永続タスクかOS-levelスケジューラ(launchd、crontab)を選択すべきだ。
REPL非アイドル時のジョブ未発火問題
CronCreateのジョブはREPLがアイドル状態のときのみ発火する。Claude Codeが別のクエリを処理している最中にはスケジュールされたジョブは実行されない。
これは設計上の制約だが、実運用で影響が大きい。対策として:
- プロンプトは軽量に設計する(重い処理はバックグラウンドエージェントに委譲)
- 長時間タスクの合間に監視ジョブを挟みたい場合は
/loopを別セッションで走らせる - 確実な実行保証が必要ならOS-levelスケジューラを使う
ジッターの仕組みと時刻精度の期待値調整
Claude Codeのスケジューラには意図的なジッター(時刻のゆらぎ)が組み込まれている。
- recurringタスク: 周期の最大10%(上限15分)の遅延が入る
- ワンショットの
:00/:30指定: 最大90秒の前倒し発火がある
これはフリート全体の負荷分散のための設計だ。全ユーザーのリクエストが毎時ちょうどに集中するのを避けている。
ワンショットタスクでは:00や:30を避けて中途半端な時刻を指定すると、前倒し発火のジッターを回避できる。一方、recurringタスクでは周期ベースのジッターが指定分に関係なく常に適用されるため、分の指定を工夫しても効果はない。厳密なタイミング制御が必要な場合は、OS-levelスケジューラを使おう。
不要になったジョブは放置せず、定期的にCronListで棚卸ししてCronDeleteで掃除する習慣をつけておきたい。
CronList # 登録済みジョブの一覧を確認
CronDelete id='abc123' # 不要なジョブを削除
OS-levelスケジューラとの使い分け — launchd/node-cronとの共存パターン
いつClaude Code Scheduled Tasksを選び、いつlaunchd/cronを選ぶか
判断軸は3つある。
| 判断軸 | Claude Code向き | OS-level向き |
|---|---|---|
| セッション寿命 | 数時間〜3日の短期 | 24/365の永続稼働 |
| AI判断の要否 | コード理解・生成が必要 | 定型処理の繰り返し |
| 実行保証 | ベストエフォート | 確実な実行が必須 |
Claude Code向き: アドホックな監視、開発中の反復タスク、AIの判断・生成が不可欠な処理。
OS-level向き: 24/365の永続稼働、確実な実行保証が必要な処理、AI不要の定型バッチ。
ハイブリッド構成: node-cronデーモン + Claude Code定期タスクの実践例
最も堅牢な構成は、OS-levelスケジューラをベースにしつつ、AI判断が必要な部分だけClaude CLIを呼び出すハイブリッドパターンだ。
import cron from 'node-cron';
import { spawn } from 'child_process';
// 定型のヘルスチェックはnode-cronで確実に実行
cron.schedule('*/5 * * * *', async () => {
const res = await fetch('https://myapp.vercel.app/api/health');
if (!res.ok) {
// 異常検知時のみClaude CLIでAI診断を呼び出す
const claude = spawn('claude', ['-p', '--dangerously-skip-permissions']);
claude.stdin.write(
'https://myapp.vercel.app/api/health が異常応答を返しています。' +
'プロジェクトの最新の変更を確認し、原因を診断して修正案を提示してください。'
);
claude.stdin.end();
}
});
このパターンなら、ヘルスチェック自体はnode-cronが確実に5分間隔で実行し、異常時のみAIの分析力を活用できる。Claude Codeのセッション寿命やジッターの影響を受けない。
筆者が運用しているlaunchd + node-cronの自律デーモンでも、まさにこのパターンを採用している。launchdのKeepAlive: trueでプロセス永続化を保証し、AI判断が必要な局面だけClaude CLIを呼び出す構成だ。Desktop永続タスクが成熟するまでは、この組み合わせが現時点で最も信頼性が高いと感じている。
Claude Code Scheduled Tasksは、AIエージェントに「時間軸での自律性」を与える重要な進化だ。/loopで手軽に始め、CronCreateで柔軟に制御し、長期運用にはDesktop永続タスクやOS-levelスケジューラと組み合わせる——この3階層の使い分けを押さえれば、開発ワークフローの自動化レベルが一段上がる。
まずは/loop 10mで自分のプロジェクトのヘルスチェックを仕掛けてみるところから始めよう。
