Claude Code

Claude Codeを定期実行するには?自動化を3つの層で使い分けよう

本記事にはプロモーション(広告)が含まる場合があります。

「Claude Codeで定期実行して自動化できるって、どういうこと?」
「毎朝のレポート作成を勝手にやっておいてほしい!」

Claude Codeには、決めた時間にプロンプトを自動で走らせる仕組みが用意されています。
ところが方式が3つあり、しかも動く場所が違うので、最初は選び方でつまずくんですよね。

さらに実行時刻が最大30分ずれたり、7日で勝手に止まったりする仕様もあります。
この記事では3つの方式の使い分けから、思ったとおりに動かないときの理由まで通しで整理しました。

この記事でわかること

  • 定期実行と自動化スクリプトの境目がどこにあるのか
  • 3つの方式をどう使い分けるか
  • 毎朝のレポートを自動で作らせる手順
  • 思ったとおりに動かないときに疑うところ
著者について

🧑‍💻

Web Director|Engineer

ITエンジニア歴15年超。設計・実装・運用まで一気通貫でこなすエンジニア。最近はAIエージェント開発・今後のキャリアを軸に発信中。

AIエージェント開発
フルスタックエンジニア
インフラ構築・運用

Claude Codeの定期実行とは何か|自動化スクリプトとの違い

最初に、この記事でいう定期実行の範囲をはっきりさせておきます。

似た話に「自動化スクリプト」がありますが、実は境目はとても単純でした。

定期実行を始める前に押さえること

  • 自動化スクリプトとの違いがどこにあるのか
  • 定期実行に向いている仕事と向かない仕事
  • 自動で走らせる前に満たしたい条件

違いは「起動を人がやるかどうか」だけ

Claude Codeで作業を自動化する話は、大きく2つに分かれます。

1つは、手順をまとめておいて自分が呼んだときに一気に走らせるやり方です。

自動化スクリプトと定期実行の境目

スラッシュコマンドやスクリプトにまとめておく形が、これにあたります。
使い方はClaude Code自動化スクリプトの記事でまとめました。

もう1つが、この記事で扱う定期実行です。時間が来たらClaude Code側が勝手に走らせる形になります。

2つの自動化の違い

  • 自動化スクリプト:手順は自動、起動は人がやる
  • 定期実行:手順も起動も自動
  • どちらも中身(手順の書き方)は同じ考え方でよい

つまり定期実行は、手順をまとめたものの上に「時計」を乗せただけの関係にあります。
だから、まず手で回せる形を作ってから時計を乗せる、という順番が自然でした。

逆にいうと、手で回して安定しないものは時計を乗せても安定しません。
「自動化がうまくいかない」と感じるときは、たいてい時計より下の手順のほうに原因がありました。

この記事で扱うのは、あくまで上に乗せる時計のほうです。
手順そのものの作り方は別の話になるので、まだ手で回す形ができていない方は、スキルとして切り出すところから整えてください。書き方はClaude Code Skillsの使い方で扱っている考え方がそのまま使えました。

定期実行に向いている仕事と向かない仕事

何でも自動で走らせればいい、というものでもありません。

私の感覚では、結果を人が見て判断する余地がある仕事ほど向いています
集めるところまでを自動にして、決めるところは人に残す。この形なら、間違いがあっても手前で気づけます。

定期実行に向いている仕事

  • 毎朝の数字を集めて要約する(読むのは人)
  • 変化があったものだけを知らせる(監視)
  • 放っておくと溜まる整理作業(ログ・リンク切れ)
  • 長い処理の終わりを待って報告する

逆に、外に出ていくものや取り消せないものは向きません。
相手に届いてしまうものは、どれだけ精度が上がっても人の手を最後に残しておくのが安全でした。

メールの送信、公開、決済。この3つは自動で走らせないと決めています。
下書きまで作らせて、送るかどうかは自分で押す形にしておくと事故が起きません。

判断が分かれるのは、外部サービスへ書き込む作業です。
あとから消せるものなら任せてよく、相手に通知が飛ぶものは手元で止める、という線引きにしています。

自動で走らせる前に満たしたい3つの条件

ここが、私がいちばん失敗したところです。

思いついた作業をいきなり定期実行に載せると、間違いだけが自動で量産されます

自動実行に載せる前のチェック

  • 手で3回動かして、毎回同じ結果になっている
  • 成果物の出力先(ファイル名とフォルダ)が決まっている
  • 間違えても、あとから取り返せる作業になっている

2つ目が意外と抜けます。出力先を決めていないと、結果が会話のなかに消えていくんですよね。
ファイルに書き出させておけば、あとから見返せますし差分も追えます。

1つ目の「3回」という数字にも意味があります。
1回だけの成功は運のことがあり、3回続けて同じ結果になって初めて手順が固まったと判断できるからです。

3回試すあいだに、指示の穴もだいたい見つかります。
「この場合はどうする?」と聞かれた内容を書き足していけば、自動で走らせても迷わない指示になりました。
逆に3回やっても結果がぶれる作業は、そもそも手順が定まっていないサインです。

Claude Codeの定期実行を3つの層で使い分ける

ここが選び方の話です。定期実行の方式は、動く場所によって3つに分かれます。

どれが優れているという話ではなく、条件で決まると考えてください。

Claude Codeの定期実行を動かす3つの場所

  • いま開いているセッションの中で回す
  • 自分のマシンの上で回す
  • クラウドで回す

セッションの中で回す(/loop)

いちばん手軽なのが /loop です。

いま話している会話のなかで、同じプロンプトを決まった間隔で繰り返してくれます

> /loop 5m デプロイが終わったか確認して、結果を教えて

セッションが開いている間だけ動くので、ターミナルを閉じると止まります。

Claude Code公式ドキュメントのスケジュールタスクのページ

出典:Claude Code Docs「スケジュールに従ってプロンプトを実行する」

/loopが向いている場面

  • ビルドやデプロイの終わりを待つ
  • プルリクエストのCIやコメントを見張る
  • 作業中にちょっと様子を見ておいてほしい

最短で1分間隔から指定できるので、待ち時間を潰すのに向いています。
逆に、明日の朝まで動かしておくような使い方には向きません。

実行されるのは、Claude Codeがアイドル状態のときだけです。
長い処理の途中で時間が来た場合は、そのターンが終わってから走る形になります。

飛ばした回をまとめて取り返す動きもありません。
3回ぶん遅れたとしても、実行されるのは次の1回だけなので、そこは期待しないでおくのが安全です。

自分のマシンの上で回す(デスクトップのスケジュールタスク)

2つ目が、デスクトップアプリのスケジュールタスクです。

セッションを開いていなくても動くのが大きな違いで、手元のファイルやツールにそのまま触れます

「毎朝7時に前日の売上をまとめて」のように、日本語で登録するだけで設定できました。

デスクトップのスケジュールタスクが向く場面

  • ローカルのファイルやデータベースを読む必要がある
  • 手元に入れているMCPサーバーを使いたい
  • 1分単位の細かい間隔で回したい

条件は、マシンが起動していてスリープしていないことです。
ここさえ満たしていれば、セッションを開いていなくても決まった時刻に動いてくれます。

ノートPCを閉じて出かけると、その間の実行は飛んでしまいます。
常時起動のマシンがあるなら、ここに寄せるのがいちばん扱いやすいと感じました。

タスクごとに権限の設定を変えられるのも、この方式の便利なところです。
読むだけの仕事は確認なしで通し、書き換えを伴うものだけ止める、といった調整ができました。

クラウドで回す(Routines)

3つ目が、Anthropic側のクラウドで動くRoutinesです。

自分のPCの電源を落としていても動くのが最大の強みでした。

項目 /loop デスクトップ クラウド
動く場所 自分のマシン 自分のマシン クラウド
マシンの起動 必要 必要 不要
セッションを開く 必要 不要 不要
ローカルのファイル 使える 使える 使えない
最短の間隔 1分 1分 1時間

クラウドではローカルのファイルを直接は見られず、リポジトリを新しく取得して動く形になります。
手元にしか置いていないデータを読ませたい場合は、この方式では成立しないと考えてください。

つまり手元の環境に依存する作業はデスクトップ、依存しない作業はクラウドという切り分けでした。
迷ったらデスクトップで育ててから、安定したものだけクラウドへ移すと失敗しません。

クラウドで回すときに押さえること

  • 最短の間隔は1時間(細かい監視には向かない)
  • ローカルのファイルは見えない(リポジトリを取得して動く)
  • 確認を挟まず最後まで自律的に走る

クラウド側は最短でも1時間おきという制限があります。
細かい間隔で回したい監視系はここに載せられないので、そこも選ぶときの判断材料になりました。

外部サービスとつなぐ場合は、タスクごとに接続を設定する形になります。
手元に入れてあるMCPの設定がそのまま持ち込まれるわけではないので、そこは移すときに確認してください。

Claude Codeでloopを使って定期実行する手順

ここからは実際の操作です。まずは /loop から始めるのがおすすめでした。

設定ファイルもいらず、その場で試せます。

/loopで定期実行を始める流れ

  • 間隔とプロンプトを決めて打つ
  • 間隔をClaudeに任せる書き方を覚える
  • 動いているタスクを一覧して止める

【ステップ1】間隔とプロンプトを決めて打つ

いちばん基本の形が、間隔とやってほしいことを続けて書くやり方です。

# 5分ごとにデプロイの状況を確認する
> /loop 5m デプロイが終わったか確認して、結果を1行で教えて



# 「every 2 hours」のように後ろに置いてもよい
> /loop 未対応の問い合わせを確認して every 2 hours

使える単位は秒・分・時間・日で、smhd と書きます。

秒を指定しても最短の刻みは1分なので、そこは切り上げられました。

間隔の指定で気をつけること

  • 7m90m のような半端な間隔は、近い値に丸められる
  • 丸めた結果はClaudeが教えてくれるので、そこで確認する
  • 細かすぎる間隔は、そのぶん消費も増える

私は待ち時間の確認なら5分、様子見なら30分くらいを目安にしています。
短くすればするほど早く気づけますが、そのぶん毎回の消費が積み上がっていくので、必要な粗さで十分です。

スキルをそのまま繰り返させることもできます。
たとえば /loop 20m のあとに自作のスキルを続けて書けば、毎回それを走らせてくれました。

ただし、繰り返しの中で走るのは自動で呼び出せるスキルだけです。
設定を変えるような組み込みのコマンドは、そのままの文字として届くだけで実行されません。

【ステップ2】Claudeに間隔を任せる書き方を覚える

間隔を書かずにプロンプトだけを渡すと、動きが変わります。

この場合、Claudeが状況を見て次までの待ち時間を自分で決めます

> /loop CIが通ったか確認して、レビューコメントがあれば対応して

動きがあるうちは短く、静かになったら長く。1分から1時間の範囲で調整してくれました。

間隔を任せると便利な場面

  • いつ終わるか読めない処理を待つとき
  • 反応がないときに無駄な確認を減らしたいとき
  • やることがなくなったら自分で止まってほしいとき

3つ目がなかなか賢くて、片付いたと判断すると自分からループを終えてくれます。
固定間隔だと止めるまで走り続けるので、待ち系はこちらのほうが楽でした。

状況によっては、繰り返し確認する代わりに変化を見張る仕組みへ切り替えてくれることもあります。
同じ質問を何度も投げ直すより効率がよく、反応も速くなります。

どちらで動いているかは、毎回の終わりに理由つきで示されました。
「次は15分後に見ます、まだビルド中のため」といった具合で、待ち方の意図まで見えるのが助かります。

【ステップ3】動いているタスクを一覧して止める

動かしたら、止め方も一緒に覚えておいてください。
いちばん簡単なのは、次の実行を待っている間に Esc を押すことです。

# いま動いているものを確認する
> いま登録されている定期タスクを教えて



# 名前を指定して止める
> デプロイ確認のタスクをキャンセルして

一覧やキャンセルは、日本語でそのまま頼めば通ります。
裏側ではタスクごとに8文字のIDが振られていて、それを使って消してくれる仕組みでした。

登録が増えてくると、自分でも何を動かしていたか忘れます。
週に一度は一覧を出して、もう要らないものを片付ける時間を取っておくと安心でした。

止め方でつまずきやすいところ

  • Esc で止まるのは /loop で作ったループだけ
  • 会話で頼んで作ったタスクは、消すまで残り続ける
  • 1つのセッションで持てるのは50件まで

「3時に○○して」のような1回だけの依頼も、同じ仕組みで登録されます。
こちらは実行が終わると自分で消えるので、消し忘れの心配はいりません。

まるごと止めたい場合は、環境変数 CLAUDE_CODE_DISABLE_CRON=1 でスケジューラ自体を無効にできます。
これを設定している間は /loop も使えなくなるため、緊急停止用と考えておくとよいです。

Claude Codeの定期実行を毎日の業務に組み込む

使い方がわかったところで、実際に何を任せているかを紹介します。

どれも「読むのは人、集めるのは自動」という形に揃えています。

定期実行に載せている業務

  • 毎朝のレポートづくり
  • 毎週のリンク切れチェック
  • 既定の指示をファイルで固定する運用

毎朝のレポートを自動で作らせる

いちばん効果が出たのがこれでした。
前日の数字を集めて要約させ、決まったファイルに書き出させるだけの単純な仕事です。

毎朝7時に、前日のアクセス数と問い合わせ件数をまとめて、
reports/YYYY-MM-DD.md に書き出してください。
前日比で20%以上動いた項目があれば、先頭に理由の仮説を3つ書いてください。

ポイントは、ただの集計で終わらせずに「気になる点」を出させるところです。
数字だけ並べても結局は読み流してしまうんですよね。

仮説は当たっていなくてもかまいません。
「なぜだろう」と考えるきっかけさえあれば、朝いちばんの5分が確認の時間に変わります。

レポートを読ませるための工夫

  • 変化が小さい日は「変化なし」の一行で終わらせる
  • 事実と仮説を必ず分けて書かせる
  • 先頭に結論、詳細は下に置かせる

置き場所は日付つきのファイルにしておくのがおすすめです。
先月と比べたくなったときに、そのまま並べて読ませられるようになります。

毎日届くものほど、短くする工夫が効いてきます。
読むのに1分かかるレポートは、3日で開かなくなるというのが正直な実感でした。

毎週のリンク切れチェックを任せる

もうひとつが、放っておくと溜まる整理系の仕事です。
私はブログの内部リンクが切れていないかを、週に一度まとめて見てもらっています。

毎週月曜の朝、公開済み記事の内部リンクをすべて確認して、
404になっているものだけを一覧にしてください。
問題がなければ「異常なし」とだけ報告してください。

最後の1行がないと、毎週長い正常報告が届いて読まなくなります。
異常があるときだけ詳しく知らせる形にしておくのが、続けるコツでした。

この考え方は、ほかの監視にもそのまま使えます。
「問題がなければ黙っている」を守るだけで、通知が生きた情報として届くようになりました。
毎回同じ長さの報告が来る状態は、そもそも設計を見直す合図だと考えています。

監視系で任せやすい仕事

  • リンク切れ・画像の欠落チェック
  • 使っていない依存パッケージの洗い出し
  • 期限が近いタスクや未対応の問い合わせの確認

逆に、異常が出たときは詳しく書かせてください。
どこが・いつから・どれくらい、まで揃っていれば、そのまま直しに入れます。

どれも人がやると忘れるものばかりで、まさに時計に任せたい領域です。
気づいたときには手遅れになりがちな作業ほど、定期実行の価値が出てきます。

loop.mdで既定の指示を固定する

毎回同じことを頼むなら、指示自体をファイルにしてしまう手があります。
プロジェクトの .claude/loop.md に書いておくと、/loop とだけ打ったときの中身がそれに置き換わります

release/next のプルリクエストを確認する。
CIが落ちていれば、失敗したジョブのログを取って原因を調べ、最小限の修正を入れる。
新しいレビューコメントが来ていれば、1つずつ対応する。
すべて問題なければ、その旨を1行で報告する。

個人用にしたい場合は ~/.claude/loop.md に置いておきましょう。
両方ある場合はプロジェクト側が優先されるので、案件ごとの事情はそちらに書いておくとよいです。

編集した内容は次の回から反映されるので、走らせながら指示を育てられました。
ただしファイルが長すぎると途中で切られてしまうため、要点だけを短く書くのがコツです。

loop.mdの置き場所と優先順位

  • .claude/loop.md:そのプロジェクト用(両方あるとこちらが優先)
  • ~/.claude/loop.md:自分用(どのプロジェクトでも効く)
  • どちらもなければ、組み込みの指示にそのまま戻る

なお、このファイルが効くのは /loop を引数なしで打ったときだけです。
その場でプロンプトを書いた場合は、そちらが優先されて中身は読まれません。

Claude Codeの定期実行が思ったとおりに動かない理由

ここは導入前に読んでおいてほしい部分です。

私は仕様を知らずに「壊れた」と勘違いして、ずいぶん時間を使いました。

先に知っておきたい仕様

  • 実行時刻が意図的にずらされること
  • 7日で自動的に止まること
  • セッションを閉じると動かないこと

実行時刻はわざとずらされる

「9時ちょうどに設定したのに、9時20分に動いた」。これは不具合ではありません。

世界中のセッションが同じ瞬間に動くのを避けるため、実行時刻に少しだけずれが加えられています

定期実行が思ったとおりに動かない3つの仕様

繰り返しのタスクなら、設定時刻から最大30分あとまでの間に走ります。

1時間より短い間隔の場合は、その間隔の半分までがずれの上限でした。

時刻のずれを小さくするコツ

  • 1回限りのタスクは :00:30 を避けて指定する
  • たとえば9時ちょうどではなく9時3分に設定する
  • 分単位の正確さが要るなら、そもそも定期実行に向かない

ずれの量はタスクごとに固定なので、毎回バラバラになるわけではありません。
「うちの朝のタスクはいつも15分遅れ」というふうに、慣れれば予測できる範囲に収まります。

1回限りのリマインダーは、逆に少しだけ早く走ることがあります。
ちょうどの時刻に設定したときだけの動きなので、分をずらして指定すればほぼ狙いどおりになりました。

繰り返しのタスクは7日で止まる

2つ目がこれで、知らないと「いつの間にか動かなくなった」と感じます。

セッションの中で作った繰り返しタスクは、作成から7日で自動的に期限切れになります

最後に1回だけ走って、そのあと自分で消えるという動きです。

7日で止まる仕様への対処

  • 短期の監視ならそのままでよい(むしろ消し忘れを防げる)
  • ずっと続けたいなら、期限前に作り直す
  • 本当に長く回すなら、デスクトップかクラウドへ移す

この仕様は、忘れられたループが延々と動き続けるのを防ぐためのものです。
「ずっと動いてほしいものは /loop で作らない」と覚えておけば十分でした。

7日という区切りは、試している期間とちょうど同じくらいの長さです。
1週間回してみて価値があると感じたものだけを、常設の仕組みへ引っ越すという使い方が合っていました。

期限が来ると、最後に1回だけ走ってから消えます。
いきなり無言で止まるわけではないので、その最終回を見たら引っ越しのタイミングだと考えてください。
期限が近いものは、切れる前に作り直しておくと途切れません。

セッションを閉じると動かない

3つ目は当たり前に思えて、意外と忘れがちなところです。

/loop で作ったタスクは、Claude Codeが起動していて、かつ手が空いているときにだけ走ります

ターミナルを閉じれば止まりますし、長い処理の最中は実行が後ろにずれます。

見落としがちな挙動

  • 飛ばした回はまとめて実行されない(次の1回だけ走る)
  • 新しい会話を始めると、セッション内のタスクは消える
  • --resume で再開すると、期限内のタスクは戻ってくる

マシンを閉じても動かしたいなら、最初からデスクトップかクラウドを選んでください。
セッションを背後で動かし続ける方法もありますが、そこまでするなら常設の仕組みに寄せるほうが素直です。

時刻の解釈は、いつも手元のタイムゾーンが基準になります。
海外のサーバーを触っているときも、指定した9時は自分のいる場所の9時だと考えて大丈夫でした。

Claude Codeの定期実行を安全に運用するコツ

最後に、事故を起こさないための運用面をまとめます。

自動で動くものほど、止める側の設計が大事でした。

安全に回すために決めておくこと

  • 権限と出力先を先に決める
  • 失敗に気づける形にする
  • 止めるスイッチを持っておく

権限と出力先を先に決める

人がいないときに走るので、確認ダイアログは意味を持ちません。

だからこそ、触ってよい範囲を設定ファイルで先に区切っておくのが大事でした。

自動実行の前に区切っておくこと

  • 書き込みを許すフォルダを限定する
  • 削除系のコマンドは禁止しておく
  • 外部への送信を伴う操作は許可しない

出力先も同じで、成果物の置き場を決めておくと結果を追いやすくなります。
日付をファイル名に入れておけば、いつの結果なのかを探す手間も消えました。

権限を絞ると、できることは当然減ってしまいます。
ただ、無人で動くものに広い権限を渡す怖さと比べれば、少し不便なくらいがちょうどよいと感じています。

フックを組み合わせると、実行後の後処理まで自動にできました。仕組みはClaude Code hooksの使い方にまとめています。

失敗に気づける形にする

自動化でいちばん怖いのは、止まっていることに気づかない状態です。

私は正常なときも1行だけ記録を残させるようにしています。

そうすると、記録が途切れた時点で異常だとわかります。

気づける仕組みの作り方

  • 結果を日付つきのファイルに追記させる
  • 異常時だけ通知を飛ばす(正常時は静かに)
  • 週に一度、記録の抜けがないか自分で見る

スマホに通知を飛ばしたい場合は、リモート接続を有効にしておく手もあります。
外出中でも異常だけ受け取れる形にしておくと、帰ってから慌てることがなくなりました。

記録は、成功も失敗も同じ場所に残すのがコツです。
失敗だけを別に集めると、そもそも動いていなかった日が見えなくなってしまいます。

止めるスイッチを持っておく

最後に、いつでも止められる状態を作っておいてください。

おかしな動きに気づいたとき、まず全部止めてから原因を探すほうが安全です。

止め方の選択肢

  • 次の実行を待っている間に Esc を押す
  • 「〇〇のタスクをキャンセルして」と会話で頼む
  • CLAUDE_CODE_DISABLE_CRON=1 でスケジューラ自体を止める

3つ目は強力なので、いざというときの緊急停止として覚えておくと安心です。
設定している間はスケジューラそのものが止まるため、原因を調べ終えたら戻すのを忘れないでください。
止め方を知らないまま増やすのがいちばん危ないので、ここは最初に確認しておきたいところです。

止めることを前提にしておくと、新しい自動化を試すハードルも下がります。
「まずいと思ったらすぐ切れる」と分かっていれば、思い切って任せてみられるようになりました。

自動化を増やすときほど、この止める側を先に用意しておくと落ち着いて進められました。
効率化の全体像はClaude Codeによる業務効率化の実例もあわせて読んでみてください。

Claude Codeの定期実行と自動化に関するよくある質問

Q:Claude Codeの定期実行は無料プランでも使えますか?

A:使えません。Claude Code自体がProプラン以上の有料プランで提供されているためです。
月20ドルのProから利用でき、使用量が足りない場合はMaxを検討することになります。

Q:PCの電源を切っていても定期実行できますか?

A:クラウドで動くRoutinesを使えば、マシンの電源が入っていなくても動きます。
ただしローカルのファイルは参照できないため、手元の環境に依存する作業はデスクトップ側で回してください。

Q:cron式を覚える必要はありますか?

A:基本的には不要です。「毎朝7時に」のように日本語で伝えれば、Claudeがcron式に変換してくれます。
細かく制御したい場合だけ、0 9 * * 1-5(平日9時)のような書き方を覚えておくと便利です。

Q:設定した時刻ぴったりに実行されないのはなぜですか?

A:負荷が集中しないように、実行時刻へ意図的なずれが加えられているためです。
繰り返しのタスクなら最大30分後まで、1回限りのタスクなら最大90秒前にずれることがあります。

まとめ

Claude Codeの定期実行は、自動化スクリプトに時計を足したものでした。

だから順番としては、まず手で回せる形を作ってから、時計を乗せるのが確実です。

場所は3つあり、手元のファイルが要るかどうかとマシンを開けておけるかで決まります。

今日から試せること

  • 待ち時間のある作業で /loop 5m を一度使ってみる
  • 毎朝やっている確認作業を1つ書き出す
  • その作業を手で3回動かして、結果が安定するか確かめる

自動化は、増やすほど楽になるわけではありません。

あなたが毎朝いちばん最初に開くファイルは、どれでしょうか。
そこに載る情報を1つだけ自動で用意させるところから始めてみてください。

ここまでの内容を一人で回せるようになったら、次は同じやり方をチームや社内に広げる段階に入ります。体系立てて学び直したい方や、研修という形で社内に展開したい方は、社会人におすすめの生成AI研修スクール|スクール6校を比較を参考にしてみてください。