定期実行とスケジュール

なぜ定期実行が必要か

開発業務には「繰り返し実行すべきだが、つい忘れてしまう」タスクが大量にあります。 PRのレビューコメントへの対応、デプロイ後のヘルスチェック、依存パッケージの更新確認。 これらを毎回手動で思い出して実行するのは、現実的ではありません。

Claude Codeには、こうした定期タスクを自動化する仕組みが2つあります。/loop（ローカル定期実行）と/schedule（クラウド定期実行）です。 それぞれ用途が異なるため、使い分けを理解することが重要です。

/loop — ローカル定期実行

/loopは、任意のプロンプトやSkillを指定した間隔で繰り返し実行するコマンドです。 ターミナルを開いている間、バックグラウンドで定期的にタスクを走らせます。

基本構文

# Skillを5分ごとに実行
/loop 5m /babysit

# プロンプトを30分ごとに実行
/loop 30m "デプロイステータスを確認して、問題があれば報告して"

# 間隔を省略すると10分がデフォルト
/loop /post-merge-sweeper

間隔の指定は1m（1分）、5m（5分）、30m（30分）、1h（1時間）などが使えます。 最大で1週間の連続実行が可能です。

内部の仕組み

/loopは内部的にcronツール（CronCreate、CronList、CronDelete）を使用して動作します。 ターミナルセッションに紐づいているため、ターミナルを閉じると停止します。 つまり「自分がPCの前にいる間だけ動かしたい」タスクに最適です。

Anthropicエンジニアの実践例

Boris（Anthropicエンジニア）が実際に業務で使用しているパターンを紹介します。

• /loop 5m /babysit —— PRを5分おきに監視し、レビューコメントへの自動対応・リベース・マージまでを自動化。 「PRのお守り役」として機能します
• /loop 30m /slack-feedback —— Slackのフィードバックチャンネルを30分ごとにチェックし、対応が必要なものをPRとして自動作成
• /loop /post-merge-sweeper —— マージ後に見落とされたレビューコメントを検出し、フォローアップの修正を自動実行
• /loop 1h /pr-pruner —— 1時間ごとにstale（放置された）PRを検出し、自動でクローズ

/schedule — クラウド定期実行

/scheduleは、Anthropicのクラウドインフラ上でタスクをスケジュール実行するコマンドです。 /loopとの最大の違いは、ターミナルを閉じても、PCの電源を切っても、スケジュールされたタスクが実行され続ける点です。

基本的な使い方

# スケジュールを作成
/schedule

# 既存のスケジュールを一覧表示・管理
/schedule list

スケジュールの定義にはcron構文を使用します。 「毎朝9時」「毎週月曜日」「1時間ごと」など、柔軟なタイミング指定が可能です。

活用シーン

• 夜間コード分析 —— 深夜にコードベース全体の品質分析を実行し、朝には結果レポートが届いている
• 日次レポート生成 —— 毎朝9時に前日のコミットをまとめたスタンダップレポートを自動生成
• 週次依存チェック —— 週1回、outdatedな依存パッケージを検出してアップデートPRを作成
• 長期的な品質監視 —— テストカバレッジの推移、コード複雑度の変化を継続的にトラッキング

/loop と /schedule の使い分け

2つの仕組みは補完関係にあります。目的に応じて適切な方を選んでください。

比較表

• 実行環境 —— /loop: ローカル（ターミナル内） / /schedule: クラウド（Anthropicインフラ）
• 持続性 —— /loop: ターミナルを閉じると停止 / /schedule: マシンオフでも動き続ける
• 適した用途 —— /loop: 開発中のリアルタイム監視 / /schedule: 定期レポート・長期監視
• 間隔指定 —— /loop: 分・時間単位のシンプル指定 / /schedule: cron構文でフル制御
• 最大期間 —— /loop: 最大1週間 / /schedule: 無制限

定期実行に適したSkill設計

定期実行されるSkillには、通常のSkillとは異なる設計上の配慮が必要です。 以下の3つの原則を押さえてください。

冪等性（べきとうせい）

何度実行しても安全な設計にすることが最重要です。 たとえば「PRにコメントする」Skillが、実行のたびに同じコメントを重複投稿してしまっては困ります。 「前回コメント済みなら何もしない」というチェックを組み込んでください。

差分ベースのログ

Thariq（Anthropic共同創業者）が推奨するパターンです。 前回の実行結果をログファイルに保存し、今回との差分だけを報告する設計にします。 これにより「変化があったときだけ通知が来る」状態を作れます。

# Skill内でのログ活用例
# 前回の状態をログから読み込み
# 現在の状態を取得
# 差分がある場合のみレポートを生成
# 今回の状態をログに保存

エラー耐性

定期実行では、ネットワークエラーやAPI制限など一時的な障害が発生しやすくなります。 1回の失敗が次回の実行に影響しないよう、各実行を独立させる設計にしてください。 前回の実行が途中で失敗しても、次回は正常にゼロから動く必要があります。

実践パターン

パターン1: PR babysitter

最も実用的なパターンです。/loop 5mでPRの状態を監視し、 レビューコメントへの対応・リベース・コンフリクト解消を自動で行います。

# .claude/skills/babysit.md の概要
---
name: babysit
description: PRを監視してレビュー対応を自動化
---

# PR Babysitter
1. 自分のオープンPRを一覧取得
2. 新しいレビューコメントがあれば対応
3. コンフリクトがあればリベース
4. CIが失敗していれば修正を試みる
5. 全てクリアならマージ

# 使い方
/loop 5m /babysit

Borisはこのパターンで、PRを開いたら/loop 5m /babysitを実行し、 あとはPRがマージされるまで放置しています。 レビュアーがコメントを付けると、5分以内にClaude Codeが自動で修正コミットを作成します。

パターン2: デプロイ監視

ステージング環境にデプロイした後、/loop 10mでヘルスチェックを定期実行します。 エンドポイントの応答確認、エラーログの監視、パフォーマンスメトリクスの収集を自動化できます。

# 使い方
/loop 10m "ステージング環境のヘルスチェックを実行して。
https://staging.example.com/api/health を確認し、
レスポンスタイムが1秒を超えていたら報告して"

パターン3: 日次スタンダップ

/scheduleで毎朝9時にスケジュールし、 昨日のコミットログ・マージされたPR・オープンなissueをまとめたレポートを自動生成します。 Slack連携と組み合わせれば、チーム全員の朝会準備が不要になります。

パターン4: 依存パッケージチェック

/scheduleで週1回（たとえば毎週月曜朝）実行し、 outdatedなnpmパッケージを検出してアップデートPRを自動作成します。 セキュリティパッチの見落としを防ぐ効果もあります。

# scheduleで週次実行するSkillの概要
---
name: dependency-check
description: 依存パッケージの更新チェック
---

# 依存パッケージチェッカー
1. npm outdated を実行
2. セキュリティアドバイザリを確認（npm audit）
3. メジャーバージョンアップ・マイナー・パッチを分類
4. パッチとマイナーは自動でアップデートPRを作成
5. メジャーバージョンアップはレポートのみ

まとめ

/loopと/scheduleは、Claude Codeを「指示を待つアシスタント」から「自律的に働くエージェント」へと変える仕組みです。 まずは/loop 5m /babysitのようなシンプルなパターンから始めてみてください。 定期実行の威力を実感したら、自分のワークフローに合ったSkillを設計し、 /loopや/scheduleで自動化する範囲を広げていきましょう。 重要なのは、冪等性・差分ログ・エラー耐性の3つの設計原則を守ることです。