2026/04/17Claude Code

Skills活用AI活用

Claude Code定期実行の完全比較｜/loop・cron・routinesの使い分け

Claude Codeで定期実行を実装しようとすると、似た名前の機能が複数出てきて混乱しがちです。/loop、CronCreate、ScheduleWakeup、Monitor、routines、Desktop scheduled tasksと、公式が用意しているだけでも6つあります。

さらにOS層のlaunchd/cronまで含めると選択肢はもっと広がります。

用途を間違えると「PCを開きっぱなしにしないと動かない」「思ったよりトークンを食う」「7日後に勝手に止まる」といった事態が起きます。私自身、Google Search Consoleのデイリー取得を/loopで約1週間運用してみて、それぞれの仕組みの違いと向き不向きが見えてきました。

この記事では、Claude Codeの定期実行に関する全機能を仕組みベースで整理し、用途別の使い分け基準と、Fyveでの実運用例を紹介します。

結論：定期実行6機能の早見表

まず全体像から。次の早見表で「自分が必要なのはどれか」を絞り込めます。

セッション内で完結する4機能（CLI起動中のみ動作）

/loop：固定間隔または自己ペースでプロンプトを繰り返す。最も使いやすい入口
CronCreate / CronList / CronDelete：/loopの裏側にあるツール。自然言語で「9時にpushして」と言うとClaudeがこれを叩く
ScheduleWakeup：/loopの自己ペースモード内部で使われる遅延タイマー。ユーザーが直接叩くことはほぼない
Monitor：ポーリングではなく、ログやファイル変更などのイベント駆動でClaudeを起こす

セッション外でも動く2機能

Desktop scheduled tasks：Mac/Windowsアプリ内のスケジューラ。PCが起動していれば動く
routines：Anthropicのクラウドで動くためPCがオフでも動く。Schedule・API・GitHubの3トリガーに対応

シンプルな判断基準は次の通りです。

セッションを開いている間だけでいい → /loop
ログやイベントに即反応させたい → Monitor
毎朝9時に必ず動かしたいがPCは起動している → Desktop scheduled tasks
PCを閉じている時間も含めて動かしたい → routines
GitHubのPRイベントに反応させたい → routines（GitHubトリガー）
外部システムからHTTPで叩きたい → routines（APIトリガー）

Claude Codeの定期実行は3つのレイヤーに分かれる

個別機能の前に、まず構造を理解すると混乱しません。Claude Codeの定期実行は実行場所で3層に分かれます。

レイヤー1：セッション内（in-session）

Claude Code CLIを起動している間だけ動作します。/loop・CronCreate・ScheduleWakeup・Monitorはここに属します。最大の特徴はセッションを閉じると全タスクが消滅すること。一時的なポーリングや「今夜のビルドを見守っておきたい」といった用途に適しています。

レイヤー2：マシン内（Desktop app）

Claude Code DesktopアプリのSchedule機能で設定します。Desktopアプリが起動していて、PCがスリープしていなければ動きます。CLIを終了してもタスクは生き続けるため、毎朝の定期処理などに使えます。

レイヤー3：クラウド（routines）

Anthropic管理のクラウドインフラで動くため、PCを完全にオフにしていても動きます。ローカルファイルにはアクセスできず、リポジトリは毎回フレッシュにcloneされる前提です。

もう1つ、忘れがちな選択肢としてOS層のlaunchd（Mac）やcron（Linux）があります。claude --printを直接叩くシェルスクリプトをこれらでスケジュールすれば、Claudeの機能を借りずに完全外部から定期実行できます。Claude側の制約（7日expiryや1時間最低間隔）を回避したい場合の最終手段です。

/loop：セッション内ポーリングの最速ルート

定期実行を試すなら/loopから入るのが最速です。引数の与え方で挙動が変わる3パターンがあります。

パターン1：間隔とプロンプトを両方指定（固定間隔モード）

/loop 5m check if the deployment finished and tell me what happened

5分ごとにプロンプトが実行されます。内部ではcron式*/5 * * * *に変換されてCronCreateで登録されます。

面白いのは「every 2 hours」のような末尾「every」表現にも対応している点。「/loop check the deploy every 20m」のように書いても認識されます。

注意点として、cronは1分単位なので秒指定は切り上げられます。また「7m」や「90m」のように1時間を綺麗に分けられない数値は、最も近いcron表現に丸められます（その場合Claudeが何分に丸めたか教えてくれます）。

パターン2：プロンプトのみ指定（自己ペースモード）

/loop check whether CI passed and address any review comments

間隔を指定しないと、Claude自身が毎回「次は何分後に動くべきか」を判断します。CIが動いている間は短く、PRが静かになったら長く、といった具合に動的に変化します。

このモードの裏側で動いているのがScheduleWakeupです。Claudeは1回の実行ごとにdelaySecondsを決めてScheduleWakeupを呼び、次の起床時刻を予約します。プロンプトキャッシュの5分TTLを意識し、60〜270秒（キャッシュ温存）か、1200〜1800秒（キャッシュミスを覚悟して長めに待つ）の範囲で選ばれることが多い設計です。

パターン3：何も指定しない（メンテナンスモード）

/loop

引数なしで打つと、組み込みの「メンテナンスプロンプト」が動きます。未完了タスクの継続→現在ブランチのPR対応→静かなときは簡素化のクリーンアップ、という順で動きます。.claude/loop.mdまたは~/.claude/loop.mdを置けば独自プロンプトに差し替え可能です。

/loopの落とし穴3つ

7日で自動失効：再帰タスクは作成から7日後に最後の1回を発火して消えます。長期運用したいならcronから再作成するか、routinesに移行する必要があります
jitter（揺らぎ）：再帰タスクは周期の最大10%（上限15分）遅れる仕様です。複数セッションがAPIを同時に叩かないための設計ですが、「9時きっかり」を期待すると外れます。3 9 * * *のように:00や:30を避けると緩和できます
セッション終了で全消滅：CLIを閉じた瞬間に全タスクが消えます。ノートPCの電源切れに弱い

CronCreate / CronList / CronDelete：自然言語で操作する裏方ツール

/loopが「便利なフロントエンド」なら、CronCreateは「内部API」です。とはいえ自然言語で「9時にpushして」「全スケジュール見せて」「deploy-checkを止めて」と言えば、ClaudeがこれらのToolを叩いてくれます。

知っておくべき仕様は以下の通りです。

標準5フィールドcron式（分時日月曜日）に対応
1セッションあたり最大50タスク
Day-of-monthとDay-of-weekを両方指定するとOR動作（vixie-cron仕様）
L、W、?、MON、JANなど拡張構文は非対応
scheduler は1秒ごとに発火チェック。Claudeが応答中なら、現在のターン終了後に低優先度で実行

環境変数CLAUDE_CODE_DISABLE_CRON=1を設定すれば、cronツールと/loopを完全に無効化できます。チームでcron系を使わせたくない場合に便利です。

Monitor：ポーリングではなくイベント駆動で動かす

/loopとCronCreateは「N分ごとに見に行く」というポーリング型です。一方Monitorは「何かが起きたら教えてくれ」というイベント駆動型。これが知られておらず、もったいない使われ方をされている機能の筆頭です。

Monitorの仕組み

Monitorはバックグラウンドでシェルスクリプトを起動し、標準出力に1行出るたびに、それをClaudeへの通知として届けます。脱出条件はスクリプトの終了。シンプルですが応用範囲が広い設計です。

使い方の典型パターン

パターン1：ログファイルの監視

tail -f /var/log/app.log | grep --line-buffered "ERROR"

app.logにERRORを含む行が出るたびにClaudeが通知を受け取り、その行をコンテキストとして次のアクションを決められます。--line-bufferedを必ず付けるのが鉄則。これがないとパイプのバッファリングで通知が分単位で遅れます。

パターン2：ファイル変更の監視

fswatch -0 /watched/dir | xargs -0 -I {} echo "changed: {}"

指定ディレクトリに変更があるたびに通知されます。デザインカンプを更新したら自動でCSSに反映、といった用途に使えます。

パターン3：外部APIのポーリング

last=$(date -u +%Y-%m-%dT%H:%M:%SZ)
while true; do
  now=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  gh api "repos/owner/repo/issues/123/comments?since=$last" \
    --jq '.[] | "\(.user.login): \(.body)"' || true
  last=$now
  sleep 30
done

30秒ごとにGitHubのPRコメントをチェックし、新しいコメントだけを通知します。/loopで同じことをやるとプロンプト全体が毎回トークンを消費しますが、Monitorならスクリプト実行のみで、Claudeは「新しいコメントが来たとき」だけ起動します。トークン効率がまるで違うのが最大のメリットです。

Monitor使用時の3つの鉄則

Anthropic公式が「silence is not success（沈黙は成功ではない）」と強調しているのが象徴的です。ハマりやすいポイントを3つ挙げます。

失敗パターンも必ずgrepする：成功シグナルだけ拾うMonitorは、プロセスがクラッシュしても沈黙し続けます。grep -E "elapsed_steps=|Traceback|Error|FAILED|Killed|OOM"のように失敗系も含めて拾うこと
常に--line-bufferedを付ける：パイプのバッファリングで通知が遅延する事故が多発します
出力量を絞る：rawログを垂れ流すとClaudeが通知を捌ききれず、Monitor自体が自動停止されます。grep/awk/wrapperで「実際にアクションを取る行」だけに絞る

Monitorと/loopの使い分け

状況	選ぶべき機能	理由
5分以内に状態が変わる作業を見守る	/loop（固定間隔）	CLIから一発で書ける
イベント発生まで時間が読めない	Monitor	無駄なポーリングが消える
判断や応答が毎回必要	/loop（自己ペース）	Claudeが状況に応じて間隔を変える
ログを延々と監視したい	Monitor（persistent: true）	セッション中ずっと動かせる

Desktop scheduled tasks：CLIを閉じても動く中間解

Claude Code Desktopアプリには独自のScheduleページがあります。/loopとは別物で、CLIセッションを閉じてもDesktopアプリが起動している限り動き続けます。

主な特徴は以下の通りです。

Desktopアプリ内で「New task」→「New local task」から作成
頻度プリセット：Manual / Hourly / Daily / Weekdays / Weekly
カスタム間隔も自然言語で「6時間ごとにテスト走らせて」と言えば設定可能
最小間隔は1分（routinesは1時間）
各タスクごとにpermission modeを個別設定できる
設定で「Keep computer awake」を有効化すればアイドルスリープを防げる

Desktop tasksのキラー機能：missed runs catch-up

PCがスリープしていてタスクをスキップした場合、起動時に直近1件だけ自動で追従実行する仕様があります。6日間PCを落としていた毎日タスクは、起動時に1回だけ実行され、それ以前の分は破棄されます。「9時に動くはずのタスクが23時に動く」可能性があるので、プロンプトに「今日のコミットだけレビューして。17時以降ならスキップして要約だけ投稿して」のようなガードを書いておくと安全です。

routines：PCがオフでも動くクラウド型スケジューラ

2026年4月時点でリサーチプレビュー中のroutinesは、Anthropicクラウドで動く本格派です。Pro/Max/Team/Enterpriseプランで利用可能で、設定はclaude.ai/code/routinesまたはCLIの/scheduleから行います。

3種類のトリガー

routinesの強みは、1つのroutineに複数のトリガーを組み合わせられる点です。

Schedule：hourly / daily / weekdays / weeklyのプリセット、または1時間以上のカスタムcron。最小間隔は1時間（/loopの1分よりかなり大きい）
API：routine専用エンドポイントにbearer tokenでPOSTすると起動。Sentryアラートやデプロイ完了通知から叩ける
GitHub：Pull request / Releaseイベントで起動。filterでauthor、title、base branch、labelsなどを絞れる

routinesでできること・できないこと

できること：

PCをオフにしていても動く（クラウド実行）
connectorsを通じてSlack、Linear、Google Driveなどを操作
routine実行時のセッションは事後にWebで確認・継続可能
/schedule runコマンドで即時実行

できないこと：

ローカルファイルへのアクセス（毎回フレッシュにrepoがcloneされる）
5分間隔のような短サイクル実行（最小1時間）
permission modeの細かい制御（autonomous実行のみ）
チームメンバーとの共有（個人アカウントに紐づく）

料金と制限

routinesはサブスクリプションの利用枠を消費します。それに加えて1日のrun回数に上限があり、超えると次のリセットまで実行が拒否されます。Settings > Billingで「extra usage」を有効化すれば従量課金で続行可能です。

OS層のlaunchd / cron：最後のフォールバック

「Claudeの仕様に縛られず純粋に定期実行したい」という場合は、Mac標準のlaunchdやLinuxのcronからclaude --print "プロンプト"を叩く方法もあります。

例えばMacのlaunchdで毎朝9時にClaudeを呼ぶ場合：

<dict>
  <key>Label</key>
  <string>com.fyve.daily-gsc</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/claude</string>
    <string>--print</string>
    <string>/fyve-gsc-report</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Hour</key>
    <integer>9</integer>
    <key>Minute</key>
    <integer>0</integer>
  </dict>
</dict>

メリットはClaudeの7日expiry制約から解放されることと、セッション管理が不要なこと。デメリットは、結果をすぐに目視で確認できない点と、API利用枠に直接ヒットする点です。

使い分けフローチャート

ここまでの整理を1つのフローに落とすと次のようになります。

「PCをオフにできる必要があるか？」 → Yes → routines
「ローカルファイル・ローカル環境が必要か？」 → Yes → 次の質問へ／No → routines検討
「CLIセッションを開きっぱなしにできるか？」 → No → Desktop scheduled tasks／Yes → 次の質問へ
「ポーリング型でよいか、イベント駆動が必要か？」 → イベント → Monitor／ポーリング → /loop
「間隔は固定でよいか、状況で変えたいか？」 → 固定 → /loop（間隔指定）／可変 → /loop（プロンプトのみ）

Fyveでの実運用例：GSCデイリー分析を/loopで回す

私のFyveでは、Google Search Consoleのデイリーデータ取得に/loopを採用しています。2026年4月時点で約1週間運用中です。

運用構成

自宅のMac miniをスリープせずに常時稼働
Claude Code CLIを開きっぱなし
/loop 24h /fyve-gsc-reportを登録
毎日決まった時刻にGSC APIを叩き、検索順位・キーワード・CTRを取得→Markdown形式で蓄積
外出時はremote-controlでスマホから状況確認

なぜ/loopを選んだか

routinesでなく/loopを選んだ理由は3つあります。

ローカルにデータを蓄積したい：取得したデータをdata/フォルダのMarkdownファイルに直接書き込み、後続の記事戦略スキルから即参照できる構成にしたい。クラウド実行のroutinesではローカル書き込みができない
セッションのコンテキストを引き継ぎたい：取得直後に「インプレッション多×CTR低のページ」を見つけて表示内容を改善する作業まで、同一セッション内で連続実行したい
1日1回で十分：1時間最低の制約があるroutinesでも事足りるが、それ以上の頻度（例えばdeploy後のチェックなど）にも同じ仕組みを使い回したい

運用してわかった効果

/loop+GSCの組み合わせで、以下の改善が回るようになりました。

インプレッション多×CTR低のページ発見→表示内容改善：検索意図から逆算してタイトルとディスクリプションを変更。実際にCTRが改善した記事が複数本
重複記事の統合：類似テーマの記事を合体させ、伸びている方にコンテンツを集約。回遊率が上昇
キーワード周辺の補強記事：伸びているキーワード周辺で不足する記事を生成し、内部リンクで繋げる

「資産の状態確認」を継続的に回す用途は、/loopが最も使いやすいと実感しています。Webサイトやサービスの状態を毎日チェックし、変化があったら手を打つ、というサイクルがClaudeとの相性が良いのです。

定期実行で踏みやすい落とし穴

最後に、6機能を試してわかった「事前に知っておきたい注意点」を共有します。

1. /loopの7日expiryを忘れる

「ずっと動くと思っていたのに止まっていた」事故が起きやすいポイント。長期運用するなら、Desktop scheduled tasksかroutinesに移行するか、loop.mdとシェル側の再起動スクリプトを組み合わせる必要があります。

2. アメリカのピーク時間帯で実行されるとトークン消費が増える

日本時間の深夜（=アメリカのピーク帯）に重い/loopが走ると、レート制限に到達しやすくなります。重要な定期実行は日本時間の朝〜夕方に寄せるのが安全です。

3. jitterで「9時きっかり」が崩れる

/loopもDesktop tasksも、API集中を避けるためのstaggerが入っています。0 9 * * *は最大15分後まで遅れる可能性があるため、外部システムと連動させるなら3 9 * * *のように:00と:30を避けるのが定石です。

4. /loopの自己ペースモードでcache windowを意識しない

プロンプトキャッシュは5分TTLです。ScheduleWakeupのdelaySecondsが300秒前後だと「キャッシュも切れているのに、長く待った効果もない」最悪のパターンになります。短く回すなら270秒以内、長く待つなら1200秒以上、と二択で考えるのが安全です。

5. Monitorの沈黙バグ

Monitorのgrepが成功シグナルだけを拾う設定になっていると、プロセスクラッシュ時に何の通知も来ません。Traceback|Error|FAILED|OOMなど失敗系も必ず含めること。

定期実行と組み合わせることで効果が増す関連トピックは以下の記事で詳しく解説しています。

Claude CodeClaude Codeリモートエージェント活用法｜/remote・/schedule・/loopの実践

Claude CodeClaude Codeで定常業務を自動化する方法｜実践ガイド

AI業務効率化AIタスク管理・スケジュール管理の実践法｜1人経営で回す業務自動化

まとめ：6機能の最終推奨マップ

Claude Codeの定期実行機能は、似た顔をしていながら設計思想が大きく違います。最後にもう一度、用途別の推奨を整理します。

「とりあえず試したい」 → /loop（CLI一発）
「イベントに即反応させたい」 → Monitor（ポーリング不要）
「毎朝の定常タスク」 → Desktop scheduled tasks（PC起動時のみ）
「PCを閉じても動かしたい」 → routines（クラウド実行）
「外部システムから叩きたい」 → routines（API trigger）
「PRイベントに反応させたい」 → routines（GitHub trigger）
「Claudeの制約から完全に独立したい」 → launchd / cron + claude --print

Fyveでは、まず手元の業務を/loopで試し、本格運用に移行するときにroutinesかDesktop scheduled tasksへ昇格させる、というステップで進めています。最初から完璧な構成を狙わず、用途が固まってから機能を選び直すのが結果的に一番早い、というのがこの1週間の運用で得た実感です。

← 記事一覧に戻る

Service

御社の業務に合わせたClaude Code導入支援

「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。

無料AI活用診断を受けるサービス詳細を見る →