Claude Code の /loop 機能を触ってみた

TL;DR

Claude Code の /loop を使うと、自然言語で定期実行ジョブを作れる
API の定期チェックや issue 監視など、開発フローの軽量な自動化に便利
自動コンパクト中は定期実行が止まるため、コンテキスト消費量を意識した間隔設計が大事

はじめに

Claude Code の /loop 機能は段階的にロールアウト中で、自分のアカウントでも使えるようになっていたので触ってみました。

1. /loop の基本

構文

/loop [間隔] <プロンプト>

間隔を省略すると デフォルト10分 で実行されます。

間隔の指定パターン（3通り）

# パターン1: 先頭に間隔を記述
/loop 5m git status を確認して

# パターン2: 末尾に "every" で記述
/loop デプロイ状況を確認して every 20m

# パターン3: 間隔なし（デフォルト10分）
/loop テスト結果を確認して

指定できる単位は s（秒）、m（分）、h（時間）、d（日）です。ただし cron の最小粒度は1分なので、秒指定は繰り上げられます。

内部の仕組み

ユーザーが /loop を実行すると、裏側では以下の3つのツールが動いています。

ツール	役割
`CronCreate`	ジョブの作成
`CronList`	ジョブの一覧表示
`CronDelete`	ジョブの削除

とはいえ、これらのツール名を直接知っている必要はありません。自然言語で十分操作できます。

「今動いてるジョブある？」 → CronList が呼ばれる
「ループ止めて」           → CronDelete が呼ばれる

このあたりの体験は正直かなり良くて、「ジョブ管理を自然言語でできる」という点だけでも触ってみる価値があると感じました。

2. 実用ユースケース

ユースケース1: API エンドポイントの定期チェック

外部 API のレスポンスを定期的にチェックして、変化があれば報告してもらうパターンです。

/loop 5m https://api.example.com/v1/status を確認して、前回と変化があれば報告して

ステータス監視やレスポンス内容の変化検知など、シンプルな API チェックに向いています。

ユースケース2: GitHub issue 監視

/loop 5m gh issue list --label "bug" で新しいissueがないか確認して、
あれば内容を分析して対応方針を提案して

issue をトリガーにした開発フローとの相性が良さそうです。たとえば、新しい issue が立ったら自動で内容を分析して対応ブランチを作る、といった使い方もできるかもしれません。

3. 自動コンパクトと間隔設計

認識しておくべきこと

/loop で情報取得系の処理を回すと、ループのたびに取得結果がコンテキストに蓄積されていきます。Claude Code では、会話履歴が長くなると古い内容を要約して圧縮する自動コンパクトが走ります（/compact で手動実行もできます）。

この自動コンパクト自体は通常の Claude Code 利用でも発生するものですが、/loop と組み合わせると少し気になる点があります。

自動コンパクト中は処理がブロックされるため、その間のloop間隔がずれる
自動コンパクト中に溜まった cron イベントが、完了後にまとめて発火することがある

特に情報取得系の処理はコンテキスト消費が大きいため、短い間隔で回すとすぐに自動コンパクトが発生しやすいようです。/loop にそこまで正確なタイミングを求めるものではないと思いますが、認識しておくと間隔設計の参考になりそうです。

間隔設計の目安

ユースケース	推奨間隔	理由
軽量チェック（`git fetch` 等）	3〜5分	コンテキスト消費が少ない
API レスポンス監視	5〜10分	レスポンスサイズによる
テスト実行	10〜30分	実行時間自体が長く、結果も大きい

間隔の設定は「どれくらいの頻度で確認したいか」だけでなく、「1回のチェックでどれくらいコンテキストを消費するか」 も意識しておくと良さそうです。

また、プロンプトに「変化がなければ『変化なし』とだけ報告して」と明記すると、無駄なコンテキスト消費を抑えられます。

/loop 5m サイトを確認して、変化がなければ「変化なし」とだけ報告して

4. Hooks との連携

問題: cron トリガーと手動入力を区別できない

Hooks と組み合わせて「cron 発火時だけ特定の処理を走らせたい」と考えるのは自然な発想です。しかし現状、UserPromptSubmit イベントのペイロードにはトリガーソースを示すフィールドがありません。

{
  "session_id": "abc123",
  "hook_event_name": "UserPromptSubmit",
  "prompt": "送信されたテキスト"
  // trigger_source のようなフィールドはない
}

cron が自動で発火したのか、ユーザーが手動入力したのか、Hook 側では判別できません。

回避策: プレフィックス方式

プロンプトにプレフィックスを付ける ことで区別できるかもしれません。

/loop 5m [CRON] git fetch して新しいissueがあれば分析して

Hook 側では [CRON] の有無で分岐します。

# check_cron.py
import json, sys

data = json.load(sys.stdin)
prompt = data.get("prompt", "")

if "[CRON]" in prompt:
    # cron トリガーの場合の処理
    print("Cron-triggered prompt detected", file=sys.stderr)
else:
    # 手動入力の場合の処理
    pass

正式にトリガーソースフィールドが追加されるまでは、こういった方法で対処することになりそうです。

5. 制約と棲み分け

/loop の制約

制約	詳細
セッション依存	セッション（ターミナル）を閉じると全ジョブが停止する
3日間の期限切れ	ジョブは作成から3日後に自動削除される
承認プロンプト	`git push` 等の破壊的操作は確認ダイアログが出る
間隔精度	cron ベースのため最小粒度は1分。実行時間分の遅延もある
同時実行上限	1セッションあたり最大50ジョブ

GitHub Actions 等との棲み分け

この制約を踏まえると、/loop は 「軽量・一時的な自動化」 向きだと感じました。

用途	/loop	GitHub Actions / 従来 cron
数時間だけ状況を見守りたい	向いている	オーバーキル
PR のマージまで監視したい	向いている	セットアップが面倒
本番環境の継続的な監視	向いていない	こちらが適切
チーム全体で共有する自動化	向いていない	こちらが適切