Claude Code を定期的に動かしたいと思ったら、まず何から手をつければよいのでしょうか。/loop、Desktop の scheduled task、OS のスケジューラ、routine、GitHub Actions――候補を並べただけでは、どれも「スケジュール実行」に見えてしまい、違いがつかみにくいものです。

違いを分けるコツは、機能の名前を覚えることではなく、たった一つの問いから始めることです。「いま開いている会話が終わったあとも、走り続けてほしいか」。答えが「いいえ」なら選択肢は/loopの一択で、これは会話の中だけで回るスケジューラです。答えが「はい」なら、次に「どこで走らせるか」という問いが続きます。値は自分のマシン・Anthropic のクラウド・他社の CI の3つしかなく、自分のマシンを選んだときだけ、時刻を持つのが Claude Code か OS かという、もう一段の分かれ目が出てきます。

この2段の問いをそのまま表にすると、次のようになります。

方法	会話が終わっても走るか	どこで走るか	時刻を持つのは	マシンが要るか	ローカルファイル	承認	最小間隔
/loop	走らない（7日で失効）	自分のマシン	Claude Code	要る	見える	セッションの設定を継続	1分
Desktop scheduled task	走る	自分のマシン	Claude Code	要る（起きている必要あり）	見える	タスクごとに permission mode	1分
OS スケジューラ + claude -p	走る	自分のマシン	OS	要る	見える	事前に許可を渡す	OS 次第
routine	走る	Anthropic のクラウド（または組織の self-hosted 環境）	Anthropic	要らない	見えない（毎回 fresh clone）	承認プロンプトなし	1時間
GitHub Actions	走る	GitHub の runner	GitHub の schedule	要らない	見えない（毎回チェックアウト）	ワークフロー側	5分未満は不可

上4行（/loop・Desktop scheduled task・OS スケジューラ・routine）は、公式の比較表が示す「自分のマシンか、クラウドか」という区別をそのまま列にしたものです。ところが/loopと Desktop scheduled task は、この列で見るとどちらも「自分のマシン」に並びます。この2行を分けているのは場所ではなく、隣の列「会話が終わっても走るか」のほうです。「どこで走るか」を最初に決めれば全部が芋づる式に決まる、という単純な話ではありません。

GitHub Actions の行は、この記事で無理に当てはめた追加行ではありません。公式ドキュメントは「会話から独立して生き続けるスケジュール実行」の受け皿として、routine・Desktop scheduled task・GitHub Actions の3つを名指ししています。反対に、この記事が独自に足しているのは OS スケジューラの行のほうです。Claude Code の機能一覧には出てこず、OS が時刻を管理してclaude -pを外から呼ぶ層だからです。

ここから、この2段の問いをそのままたどりながら、それぞれの選択肢を見ていきます。

会話の中だけで回す: /loop

/loopは、いま開いている Claude Code の会話の中で、同じ指示を繰り返し実行させる仕組みです。少し様子を見たい確認作業や、短い間隔でのポーリング（定期チェック）にはうってつけです。

/loopは「スケジュール実行っぽいけど本物ではない」機能ではありません。時刻や間隔を指定すると、Claude はそれを内部で cron 式に変換して登録します。最小間隔は1分で、発火時刻がずれるジッターや7日で自動的に切れる期限も、後で見る他の方法とまったく同じ仕組みで適用されます。他の方法と違うのは、寿命の長さだけです。

似た名前の機能と混同しないよう、先に線を引いておきます。/goalは間隔ではなく「前のターンが終わったら次を始める」という条件で回すので、/loopとは軸が違います。Channels は外から起きたことをセッションへ push する仕組みで、こちらもポーリングの対極にあります。

Monitor は後で出てきますが、バックグラウンドで動くスクリプトの出力を監視するツールで、スケジュールとは別物です。どれも/loopの近くにありますが、時間で回す仕組みではありません。

間隔を自分で決めるか、Claude に任せるか

/loopには、間隔の決め方が2通りあります。/loop 5m check the deployのように間隔とプロンプトを両方書くと、指定した間隔での固定スケジュールになります。一方、/loop check whether CI passed and address any review commentsのように間隔を省いてプロンプトだけを書くと、Claude が毎回の実行のあとに「次はどれくらい待つか」を自分で判断します。

自己ペースのモードでは、Claude は1分から1時間のあいだで待ち時間を選び、選んだ理由もあわせて表示します。ビルドが進行中なら短く待ち、何も動いていなければ長く待つ、といった具合です。このとき Claude は Monitor（バックグラウンドで動くスクリプトの出力を監視するツール）を直接使うこともあり、そちらのほうがポーリングを繰り返すより効率的な場面もあります。

自己ペースのモードにはジッターの規則が適用されませんが、7日の期限切れは同じようにかかります。「間隔を指定しない＝何のスケジュールも持たない」わけではない、ということです。

なお、Amazon Bedrock や Google Cloud、Microsoft Foundry 経由で Claude Code を使っている場合は挙動が変わります。間隔を省いたときの待ち時間は Claude が選ぶのではなく、固定10分になります。プロバイダによって同じコマンドの挙動が変わる、という点は覚えておくとよさそうです。

一回きりのリマインダーは、/loopの出番ではありません。「remind me at 3pm to push the release branch」のように自然文で頼むと、Claude は一度だけ発火して自動的に消えるタスクを裏で登録します。使っている仕組み自体は/loopの繰り返しタスクと同じ cron の仕組みですが、繰り返すかどうかが最初から違うので、コマンドの入口も分かれています。

会話を閉じると何が起きるか

「ターミナルを閉じたら/loopは止まる」というのは、半分だけ正しい説明です。実際に効いてくるのはターミナルの有無ではなく、会話（セッション）が続いているかどうかです。会話をバックグラウンドへ回す（ターミナルを閉じてもその会話自体は動き続ける状態にする）と、/loopのタスクはそのまま引き継がれ、ターミナルなしで動き続けます。

とはいえ、繰り返しタスクには別の寿命があります。作成から7日で自動的に期限切れになる決まりで、Claude Code 2.1.237（Windows 11）で実際に登録すると、応答には「Auto-expires after 7 days」という一文が毎回添えられました。継続して回したい処理は、後述する routine か Desktop の scheduled task に任せたほうが安心です。

登録されたタスクには5cb3974fのような8文字の ID が振られ、一覧表示では cron 式を人が読める形(「Every day at 4:07 AM」など)に直したものが並びます。ただし次にいつ発火するかまでは表示されないので、当面の予定を確認したいだけなら少し物足りません。

/loopを裏で支えているのは、5フィールドの cron 式です。ここでつまずきやすいのが、フィールドの数は合っているのにエラーになるケースです。試しに0 9 * * MONのように曜日を英語名で書くと、Invalid cron expression '0 9 * * MON'. Expected 5 fields: M H DoM Mon DoW.というエラーが返ってきます。

フィールドはちょうど5つなのに「5フィールドを期待している」というメッセージが出るので、エラー文だけを読むと桁数を疑って時間を溶かしがちです。実際の原因は曜日の名前(MONのようなエイリアス)に対応していないことで、数字(0 9 * * 1)で書き直せば通ります。

なお/loopに限らず、Claude Code の定期実行は指定した時刻ぴったりには発火せず、多少ずらして動きます。世界中の利用者が同じ時刻に一斉に処理を投げないようにするための工夫(ジッター)です。ずれ方は、一回きりのタスクと繰り返しのタスクで扱いが違います。

どちらが実際の挙動なのかは、発火を待つ検証ができておらず未確認です。ただ、少なくとも「一回きりの規則は一致していて、繰り返しの規則だけが食い違っている」というところまでは特定できています。

一回きりのタスクがきりのよい時刻(:00や:30)に指定されていた場合、公式ドキュメントとツール側の実装のどちらも「最大90秒前倒しで発火する」と揃って説明しています。ところが繰り返しのタスクになると、公式ドキュメントは「最大30分後ろ倒し(1時間より短い間隔なら間隔の半分まで)」としているのに対し、実装側は「周期の10%まで、最大15分」と別の値を示しており、食い違ったままです。

もう一つ、覚えておくとよい挙動があります。/loopで繰り返しタスクを登録しても、タスクの中身(cron 式やプロンプト)自体はディスクに書かれません。ですが、プロジェクトの.claude/フォルダにはscheduled_tasks.lockというファイルが作られ、そこにはいまの会話を識別する値が記録されます。「ディスクに書かない」は、プロジェクトに何も残らないという意味なのでしょうか。

実測してみると、そうではありませんでした。ジョブの中身こそ残りませんが、「このプロジェクトのスケジューラは、いまこの会話が持っている」という印だけは静かに残ります。ジョブを登録しても削除しても、この印そのものは更新されず、ジョブが0件になっても消えずに残り続けました。同じフォルダで複数の会話を開いて/loopを使うときは、この印の存在を頭の片隅に置いておくとよいでしょう。

ここで、公式ドキュメントの記述とは食い違う点が一つ見つかりました。公式の Limitations には「Claude Code stores the scheduled task list in the project’s .claude directory」とあり、タスクの一覧そのものが.claudeに保存されるとしています。ところが Claude Code 2.1.237 で実際に登録・削除を繰り返しても、一覧ファイルらしきものは増えず、更新されるのは無関係なファイルだけでした。

この食い違いを説明する手がかりが、ツール自体の中にありました。タスクを登録するCronCreateにはdurableというパラメータがあり、その説明には「Has no effect — durable persistence is not available. All jobs are session-only (in-memory, gone when this Claude session ends).」と明記されています。

永続化する口自体は用意されているものの、このビルドでは無効化されている、ということです。バージョンが上がれば挙動が変わる可能性もあるので、ここは「2.1.237 で確かめた範囲では」という限定つきで読んでください。

/loopにはもう一つ、地味だが効いてくる制約があります。予定時刻を過ぎても Claude が別の作業で手一杯だった場合、取りこぼした回数ぶんをまとめて実行してはくれません。Claude が手すきになったタイミングで一度だけ動き、それで終わりです。

会話が終わっても走らせる: どこで走らせるか

Remote Control という機能名を見て、「ローカル／クラウド／リモート」という3つ目の実行場所があると思ってしまうかもしれません。ですが Remote Control は実行場所の話ではなく、操作面の話です。公式ドキュメントも「Remote Control sessions run directly on your machine … The web and mobile interfaces are a window into that local session.」と説明しており、スマホやブラウザから操作していても、実際に動いているのはいつもの自分のマシンです。

会話が終わっても走ってほしいと決まったら、次の問いは「どこで走らせるか」です。値は自分のマシン・Anthropic のクラウド・他社の CI の3つで、自分のマシンを選んだ場合だけ、時刻を持つのが Claude Code か OS かというタイブレーカーが加わります。

なお Desktop アプリには、この3系統とは別に Cowork というタブがあり、そちらにも定期実行のセッションが存在します。ここでは深入りせず、そういう別系統があるという紹介にとどめます。

手元で走らせる(1)Desktop の scheduled task

Claude Code Desktop の Routines 画面で Local を選ぶと、ローカル実行の Desktop scheduled task が作られます。同じ画面で Cloud を選ぶと、後述する routine が Anthropic 管理のクラウドで実行される形になります。

Desktop の scheduled task は、ローカルの作業環境をそのまま使いたいときに向いています。ローカルファイルに触りながら処理したい、あるいは自分のマシンの状態を前提にしたいという場合に扱いやすいです。一方で、動かすには Desktop アプリが開いていて、マシンも起きている必要があります。「自分の PC 上で回す」ことの強さと引き換えに、そこは前提条件になります。

もうひとつ、Desktop ならではの特徴として、タスク作成時に permission mode(承認フローの設定)をタスクごとに選べる点があります。Plan mode もその一種で、「まず計画を見せてから実行する」フローを有効にできます。クラウド側のタスクには同様の設定がないので、承認ありで慎重に動かしたいなら Desktop が向いています。

コンピュータが眠っていて予定時刻を逃した場合はどうなるのでしょうか。その瞬間の実行は素直にスキップされますが、Desktop アプリの起動時やマシンが目を覚ましたタイミングで、直近7日分の取りこぼしがないか確認され、あれば最新の1回だけを catch-up run(取りこぼしの追い掛け実行)として動かします。

6日間止まっていた日次タスクでも、目を覚ましたときに1回だけ動く、という具合です。9時に動くはずのタスクが夜11時に動くこともあるので、時刻に依存する処理を書くなら、プロンプト側にもガードを入れておくと安全です。

/loopはこれとは対照的です。取りこぼしをまとめて追いかけることはせず、Claude が次に手すきになったタイミングで一度だけ動いて終わります。

手元で走らせる(2)OS のスケジューラから呼ぶ

自分のマシンで走らせる方法には、もう一つの道があります。Claude Code 自身にスケジュールを持たせるのではなく、OS 側のスケジューラに「いつ実行するか」を任せてしまう方法です。Windows なら タスク スケジューラー、Mac なら launchd(macOS 標準のジョブ管理の仕組み)から、非対話実行のclaude -pを呼び出します。Mac では timed job の第一候補として launchd が使われ、cron は推奨されていません。

この道は Claude Code の機能一覧には出てきません。Claude Code が時刻を管理しているわけではないからです。ですが「自分のマシンで動かす」という枝の中では、Desktop の scheduled task と並ぶ現実的な選択肢です。

OS が起動したタスクは、いったい誰の許可を得て動くのでしょうか。ここで承認の扱いが、他の方法と大きく違ってきます。-pは対話プロンプトを出せません。既定の permission mode はどのプランでも Manual なので、事前に--allowedToolsや--permission-modeで許可を渡しておかないと、OS が起動したタスクはそこで止まってしまいます。

課金のされ方も、フラグ一つで変わります。ふつうにclaude -pを呼べば、ログイン済みの契約プランがそのまま使われます。ところが--bareを付けると OAuth の認証情報を一切読まなくなるので、代わりにANTHROPIC_API_KEYが必要になり、課金は API トークンに切り替わります。

もう一つ、拾っておきたい落とし穴があります。--bareを付けずに OS スケジューラから呼び出すと、信頼していないフォルダでも.claude/settings.jsonのフックがそのまま動いてしまいます。-pのセッションには workspace trust のダイアログが出ないためです。

--bareを付ければこれは避けられますが、代わりにスキルやプラグイン、MCP(外部サービスとつなぐための接続の仕組み)、CLAUDE.mdも読まなくなるので、どちらを取るかはトレードオフです。

クラウドで走らせる: routine

routine は、Anthropic 管理のクラウド上で実行される仕組みです。PC を閉じても継続できるのが大きな利点で、夜間の定期処理や放置しておきたい作業には相性がいいです。CLI からは/scheduleというコマンドで作成でき、実行そのものはクラウド側に任せる形になります。組織によっては、Anthropic 管理のクラウドではなく自社の self-hosted 環境(組織が自前で用意した実行基盤)へルーティングされることもあります。

ただし、クラウドで動くぶん、ローカルの作業環境をそのまま見るというよりは、実行のたびに真新しいクラウド環境(cloud environment)を用意して、リポジトリを fresh clone した状態で考えるほうが自然です。手元の状態を細かく使いたいというより、安定して回したいというときに向いています。タスク作成時には model selector(どのモデルで実行するか)を選べますが、これは Plan mode の ON/OFF ではありません。routine は承認なしで自律実行するのが前提で、Plan mode という選択肢自体がありません。

実行回数にも上限があります。アカウント単位で1日に開始できる routine の回数には上限が設けられていますが、具体的な数は公式ドキュメントに書かれておらず、アカウントの画面で確認する仕組みになっています。単発の実行(one-off run)はこの上限には数えられません。

そしてもう一つ、旧来のイメージを更新しておきたい点があります。routine はいまや定期実行専用の道具ではありません。

起動のきっかけとなるトリガーには、時刻で起動する schedule のほかに、API 呼び出しや GitHub 上のイベントでも起動できる仕組みが用意されています。GitHub 側のイベントは「プルリクエストが開かれたとき」や「リリースを作成したとき」のような、プルリクエストとリリースの2カテゴリに限られます。この記事では、そのうち schedule トリガー、つまり時刻で起動する使い方を中心に扱います。

CI で走らせる: GitHub Actions

GitHub Actions は、Claude Code をリポジトリ中心で動かしたいときの選択肢です。PR や CI の流れに組み込みやすいのが特徴で、開発フローの中で自動化したいときの受け皿になります。公式ドキュメントも、会話から独立して生き続けるスケジュール実行の受け皿として routine・Desktop の scheduled task と並べて GitHub Actions を名指ししており、この記事で無理やり当てはめた選択肢ではありません。

ここで注意したいのが、GitHub 側のスケジュールトリガーの仕様です。scheduleで定期実行するワークフローは既定ブランチからしか動かず、公開リポジトリでは60日間なんの活動もないと自動的に無効化されます。せっかく組んだ定期実行が、しばらく放置していたら止まっていた、ということが起こり得るので、動いているかどうかをたまに確認しておくとよさそうです。

スキルをスケジュール実行と組み合わせるには

Claude Code には、スキル(.claude/skills/のSKILL.mdに手順をまとめておく再利用可能な仕組み)という機能があります。これをスケジュール実行と組み合わせたくなる場面は多いのですが、そのまま試すと思ったように動かないことがあります。

最初につまずきやすいのが置き場所です。ホームディレクトリの~/.claude/skills/に置いた personal skill は、routine からは見えません。公式ドキュメントも「cloud sessions, including routines, don’t read ~/.claude/skills/ on your machine」とはっきり書いています。

routine は毎回リポジトリを fresh clone して動くので、手元だけの設定は届かないわけです。回避策は3つあり、①リポジトリ内の.claude/skills/にコミットする、②claude.ai のアカウント側でスキルを有効化して同期する、③リポジトリで宣言したプラグイン経由で配る、のいずれかを選びます。

次に気になるのが呼び出し方です。タスクの prompt に/skill-nameと書けば呼べそうに見えますが、これは推測ではなく公式に明記されています。スキル側のdisable-model-invocationという設定の説明に「As of v2.1.196, also prevents the skill from running when a scheduled task fires with the skill as its prompt」とあり、裏を返せば既定(false、または未指定)のスキルは scheduled task の prompt から/skill-nameで呼び出せる、ということです。

もう一つの呼び方は、スキルの description に沿った自然文を prompt に書いて、Claude に自律的に見つけさせる方法です。たとえばスキルの description が「Review recent repository changes and produce a daily engineering summary」なら、タスクの prompt を「昨日からの変更を確認して、エンジニア向けのデイリーサマリーを作ってください」のように書くと、Claude がそのスキルを自分で選んで動いてくれます。

この自動発見はdisable-model-invocationをtrueにすると止まります。ふだんの対話セッションでは、trueにしたスキルは/skill-nameで明示的に呼ばない限り動きません。ところが scheduled task の文脈では、もう一段厳しい扱いになります。

/loopの公式ドキュメントは、/loopで仕込んだ発火について「A scheduled fire only runs skills that Claude is allowed to invoke on its own」と書いており、disable-model-invocation: trueのスキルは実行されずにただの文字列として Claude に届く、としています。同じ扱いは、/permissionsや/modelのような組み込みコマンド、MCP prompt にも及び、これらもスキルと同様に実行されず文字列として渡されるだけです。

scheduled task 全般に及ぶ話だと言い切っているのはこちらではなく、スキルのドキュメントのdisable-model-invocationの説明のほうです。そこには「also prevents the skill from running when a scheduled task fires with the skill as its prompt」とあり、trueにしたスキルはタスクの prompt に/skill-nameと明示的に書いても scheduled task からは起動しない、と読めます。「明示指定すれば確実に動く」と思い込んで設計すると、静かに空振りする落とし穴です。

Desktop の scheduled task なら、/skill-nameの明示呼び出しに加えて personal skill もそのまま使えます。ローカルの設定を丸ごと引き継ぐので、「このスキルを確実に動かしたい」という場面では Desktop のほうが挙動を読みやすいです。

自分ならどう選ぶか

ここまでの分岐をたどりなおすと、迷ったときの目安が5つ見えてきます。

• まず試したいだけなら/loop
• ローカルファイルを見ながら、承認フローも自分で選んで回したいならDesktop の scheduled task
• 手元で動かしたいが、時刻の管理そのものは OS に一任したいならOS のスケジューラ + claude -p
• PC を閉じても回したいならroutine
• PR や CI に寄せたいならGitHub Actions

数字は数えれば5つになりますが、大事なのはその数ではなく、たどってきた3つの問いのほうです。私なら、最初は/loopか Desktop から入ります。理由は単純で、いきなりクラウド常駐や CI 連携に寄せるより、いまの作業の延長線上で試せるからです。そこで足りないものが見えてきたら、OS のスケジューラや routine、GitHub Actions へ広げていく、という順番のほうが無理がありません。

月額プランとAPIトークン、どちらで消費されるか

スケジュール実行を検討していると、これは契約している月額プランの枠で動くのか、それとも別に API 料金がかかるのか、という疑問が出てきます。答えは、選ぶ方法と認証の仕方によって変わります。

routine は、Claude Code on the web が有効な Pro/Max/Team/Enterprise プランに含まれる機能です。Desktop scheduled task はローカルで完結するアプリの機能なので「web 上の機能」という括りには入りませんが、こちらも同じ契約プランの範囲で動きます。どちらも、使った分が別建てで API 料金として請求されるわけではありません。OS のスケジューラからclaude -pを呼ぶ場合も基本は同じで、ログイン済みの契約プランがそのまま使われますが、--bareを付けて OAuth を読ませない設定にすると、そこだけは API トークン課金に切り替わります。

一方 GitHub Actions は、認証方法によって課金のされ方が変わります。ANTHROPIC_API_KEYを指定すれば通常どおり API トークン課金になりますが、OAuth トークン(CLAUDE_CODE_OAUTH_TOKEN。Pro/Max/Team/Enterprise で使える、契約プランで認証するためのトークン)で認証すると、実行は契約プランの利用枠から差し引かれます。公式ドキュメントも「If you authenticate with an OAuth token, runs use your Claude subscription instead of API billing」と明言しているので、GitHub Actions だから必ず API 課金になる、という思い込みは正しくありません。ただし公式ドキュメントは「Each run consumes two kinds of resources: GitHub Actions minutes … API tokens …」とも書いており、OAuth トークンで認証しても GitHub Actions 自体の実行時間(GitHub Actions minutes)は別枠で消費します。

利用量を確認したいときは/usageコマンドを使います。以前は/costという名前でしたが、公式のコマンド一覧には「Alias for /usage」とあり、いまは/usageの別名として動くだけの存在です。公式ドキュメントによれば、Pro/Max/Team/Enterprise の契約者でも/usageを打てば、そのプランの利用枠に対する消費内訳がそのまま CLI 内に表示されます。「利用量の確認はダッシュボード側で行うもの」と思い込む必要はありません。

まとめると、routine・Desktop scheduled task・OS のスケジューラは契約プランの枠内で動き(OS のスケジューラは--bareを付けたときだけ例外)、GitHub Actions は認証方法しだいで契約プランにも API トークンにも寄せられる、という整理になります。どちらで消費したいかが決まっているなら、認証方法を選ぶところから逆算すると迷いません。

まとめ

Claude Code のスケジュール実行を選ぶ出発点は、たった一つの問いです。「いま開いている会話が終わったあとも、走り続けてほしいか」。ここで「いいえ」なら/loop、「はい」なら、どこで走らせるか(自分のマシン・Anthropic のクラウド・他社の CI)を決め、自分のマシンを選んだ場合だけ、時刻を持つのが Claude Code か OS かをさらに決めます。

出発点は1つでも、たどる問いは3つ、たどり着く先は5つです。/loop・Desktop の scheduled task・OS のスケジューラ・routine・GitHub Actions。名前を丸暗記するより、この3つの問いを覚えておくほうが、次に選択肢が増えたときにも迷いません。

どこで動かしたいか、誰の承認を挟みたいか。そこから逆算すれば、自分に合う一つが自然と見えてきます。