Claude Code /loop × /schedule 実践ガイド — 一時ループ・永続スケジュール・自律ワーカーの使い分けと構築パターン

「毎朝PRの状態を確認して、CIが落ちてたら自動で直してほしい」——開発者なら一度は思ったことがあるだろう。Claude Codeの /loop と /schedule を組み合わせれば、こうした定型タスクをセッション内の一時cron、あるいはクラウド上で動き続ける永続スケジュールとして実現できる。

本記事では両機能の内部動作・制約・実務ユースケースを実装例付きで解説し、既存のcron/launchdとの棲み分け判断フローまで踏み込む。

/loopと/scheduleの全体像 — 何が違い、どう選ぶか

セッションスコープの/loop vs クラウド永続の/schedule

/loop はClaude Codeのセッション内で完結する一時的な定期実行の仕組みだ。内部的には CronCreate / CronList / CronDelete の3ツールで実装されており、セッションを閉じれば消える。

一方 /schedule はCLIからクラウド上のリモートエージェント（トリガー）を作成する機能で、PCをオフにしてもクラウド側で継続実行される。最小単位は hour（時間）だ。なお、Claude Desktopアプリにも独自のスケジュール機能（Desktop scheduled tasks）があるが、こちらはマシンが起動中のときのみ動作する別機能であり、CLIの /schedule とは仕組みが異なる。

判断フローチャート: cron・launchd・/loop・/scheduleの4択

どの自動化レイヤーを選ぶべきか。以下の比較表を基準にしてほしい。

判断の流れはシンプルだ。

1. AI判断が不要で、シェルスクリプトだけで完結する → cron / launchd
2. 分単位の高頻度監視で、ローカルファイルへのアクセスが必要 → /loop
3. 時間〜日単位の定期実行で、PCオフでも動いてほしい → /schedule（クラウドリモートエージェント）
4. 分単位だが恒久的に動かしたい → launchd + Claude Code CLIの組み合わせ

/loop 実践 — セッション内cronの構築パターン

基本構文と時間単位の指定

/loop <間隔> <プロンプトまたはスラッシュコマンド>

対応する時間単位は s（秒）/ m（分）/ h（時間）/ d（日）の4種。ただし、秒指定は最小1分に切り上げられる。30s と書いても実際には1分間隔で動く点に注意してほしい。

cron式（標準5フィールド形式）も利用可能で、タイムゾーンはローカルで解釈される。

/loop '0 9 * * 1-5' 今日のgit logを要約して

重要な内部動作として、発火はユーザーのターン間に挿入される。Claudeが応答中のときは待機し、スキップ分のキャッチアップは行われない。また、周期の最大10%（上限15分）のジッターが自動付加されるため、秒単位の正確性が求められる用途には向かない。

実装例①: PR CIモニタリング & 自動修正

5分ごとにCIステータスを確認し、失敗していたら自動修正してpushする例。

/loop 5m 以下の手順でPRを監視して: \
  1. gh pr checks でCIステータスを確認 \
  2. 全てpassなら「CI green」とだけ報告 \
  3. failがあればgit diffとエラーログを確認し、修正をコミットしてpush

正直、最初にこれが動いたときは少し感動した。手動でCI待ち→修正→pushを繰り返していた時間が丸ごと消える。

実装例②: エラーログ巡回アラート

ログファイルを定期的に確認し、新しいエラーがあれば要約する例。

/loop 10m 以下を実行して: \
  1. tail -100 /var/log/myapp/error.log で直近のログを取得 \
  2. 前回チェック以降の新しいエラーがあれば、パターンごとに分類して報告 \
  3. 新しいエラーがなければ何も出力しない

/schedule 実践 — クラウドリモートエージェントの構築

CLIからのリモートトリガー作成

CLIの /schedule はクラウド上で動作するリモートエージェント（トリガー）を作成・管理する機能だ。対話的にスケジュールの内容・頻度・対象リポジトリなどを設定すると、クラウド側にトリガーが登録される。

たとえば、毎朝の朝会サマリーを生成するトリガーを作りたい場合、CLIで /schedule を実行し、以下のような内容を対話的に設定する。

• 実行内容: 昨日のマージ済みPR一覧、オープン中のPRのレビューステータス、優先度の高い未解決issueを収集し、チーム全員が30秒で把握できる箇条書きサマリーを生成する
• スケジュール: 平日の毎朝8時
• 対象リポジトリ: 指定のGitHubリポジトリ

/schedule の最大の利点はPCをオフにしてもクラウド側で継続実行される点だ。朝会前にPCを開いたら、もうサマリーが出来上がっている。

作成済みトリガーの一覧確認・即時実行・削除などの管理操作も /schedule から対話的に行える。

ハマりポイント & 安全制約

3日自動失効とセッション50件上限

/loop で作成した繰り返しタスクは 3日で自動失効し、さらにセッションを閉じれば即座に消える。週末を挟むと月曜にはもう動いていないし、うっかりターミナルを閉じても消える。長期運用には /schedule か launchd を使うこと。

また、セッションあたりの同時実行上限は 50件。「ファイルごとにlintチェック」のような細粒度タスクを乱立させると、あっという間に上限に達する。

Hooks併用による安全ガードレール

自動化で最も怖いのは暴走だ。/loop や /schedule から git push --force が走ったり、本番DBに書き込みが飛んだりする事故を防ぐには、Hooksによるガードレールが有効になる。

~/.claude/settings.json に以下のように設定する。

{
  "hooks": {
    "pre-tool-use": [
      {
        "matcher": "Bash",
        "command": "bash -c 'echo \"$CLAUDE_TOOL_INPUT\" | jq -r .command | grep -qE \"push\\s+--force|push\\s+-f\" && echo \"BLOCK: force pushは禁止されています\" >&2 && exit 1 || exit 0'"
      },
      {
        "matcher": "Bash",
        "command": "bash -c 'echo \"$CLAUDE_TOOL_INPUT\" | jq -r .command | grep -qiE \"DROP\\s+TABLE|DELETE\\s+FROM.*production\" && echo \"BLOCK: 本番DBへの破壊的操作は禁止されています\" >&2 && exit 1 || exit 0'"
      }
    ]
  }
}

この設定により、/loop タスクからの git push --force や本番DBへの破壊的クエリがブロックされる。自動化の範囲を広げる前に、まずHooksで安全制約を敷いておくことを強く推奨する。

レート制限・コスト暴走の防止策

/loop の高頻度実行はAPI消費が跳ねる。1分間隔で複雑なプロンプトを回すと、1日あたりのトークン消費量は想像以上になる。最低でも 1分以上の間隔を設定し、プロンプトも「変化がなければ何も出力しない」と明示して不要な処理を抑えるのがコツだ。

また、応答中は次のループが待機してスキップされる仕様があるため、重い処理が続くと実際の間隔は設定値より開く。これは個人的にはむしろ安全側に倒れる挙動だと感じている。

まとめ — 自動化レイヤーの選択指針

• セッション内の短期監視 → /loop（3日以内かつセッション維持中、分単位の頻度）
• 恒久バックグラウンド → /schedule（時間〜日単位、クラウド実行でPCオフでも継続）
• 非AI処理 → cron / launchd（シェルスクリプト完結タスク）

3日失効・セッション依存・50件上限・ジッターの制約を意識すれば、/loop と /schedule は実務で十分に使える。Hooksで安全性を担保しつつ、まずはCIモニタリングやログ巡回のような低リスクな監視タスクから自動化を始めてみてほしい。小さく始めて、信頼できると分かったら範囲を広げる——自動化の鉄則はAIエージェントでも変わらない。