Claude Code をどうスケジュール実行する？
まずはこの4択と番外編を押さえよう

公開日: 2026.04.24　更新日: 2026.04.24

Claude Code を定期的に動かしたいと思ったとき、まず迷うのは「どの方法が自分に合うのか」ではないでしょうか。細かい設定まで追いかける前に、どこで動かすのかで分けて考えると、かなりすっきりします。

結論から言うと、Claude Code のスケジュール実行は大きく4つに整理できます。`/loop`、Desktop の scheduled task、routines、GitHub Actionsです。そこに加えて、Windows のタスクスケジューラーや macOS の launchd を使う番外編もあります。

ただし、番外編は Claude Code の機能そのものではありません。OS 側で「いつ起動するか」を管理して、Claude Code を外から呼び出す考え方です。まずは本編の4択を押さえて、必要なら番外編を足す、という順番がわかりやすいと思います。

まずはこの4択を押さえる

それぞれの違いは、ざっくり言えば「どこで動くか」「何にアクセスできるか」「どこまで自動で回るか」です。ここを見れば、かなり判断しやすくなります。

`/loop` は、いま開いている Claude Code のセッション内で繰り返し実行する方法です。
Desktop の scheduled task は、自分のマシン上で定期実行する方法です。
routines は、Anthropic 管理のクラウド上で回る方法です。
GitHub Actions は、CI の中で定期実行したいときの選択肢です。

公式ドキュメントでも、用途に応じてこのあたりを使い分ける考え方が示されています。なので、最初から「これが唯一の正解」と決めるより、用途ごとに素直に分けるほうが自然です。

`/loop` は、まず試すのにちょうどいい

`/loop` は、Claude Code のセッションを開いたまま、同じプロンプトを繰り返し実行したいときに便利です。たとえば、しばらく様子を見たい確認作業や、短い間隔でのポーリング（定期チェック）には向いています。

かみ砕いて言うと、会話の中でそのまま「もう一回」を回すイメージです。手早く試せる反面、セッションが閉じると止まるので、常時運用の土台としては少し弱いですね。

Desktop の scheduled task は、手元のファイルと相性がいい

Desktop の scheduled task は、ローカルの作業環境をそのまま使いたいときに向いています。ローカルファイルに触りながら処理したい、あるいは自分のマシンの状態を前提にしたい、という場合に扱いやすいです。

一方で、動かすにはデスクトップアプリが開いていて、マシンも起きている必要があります。「自分のPC上で回す」ことの強さと引き換えに、そこは前提条件になります。

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

routines は、PC を閉じても動かしたいときの候補

routines は、Anthropic 管理のクラウド上で実行される仕組みです。なので、PC を閉じても継続できるのが大きな利点です。夜間の定期処理や、放置しておきたい作業にはかなり相性がいいです。

ただし、クラウドで動くぶん、ローカルの作業環境をそのまま見るというよりは、fresh clone（毎回新しく取り直した状態）で考えるほうが自然です。手元の状態を細かく使いたいより、安定して回したい、というときに向いています。

タスク作成時にはmodel selector（どのモデルで実行するか）を選べます。Sonnet か Opus かで精度と処理の重さが変わります。ただしこれはあくまで「どの Claude に頼むか」の設定であって、Plan mode の ON/OFF ではありません。routines は承認なしで自律実行するのが前提で、Plan mode は使えない仕様です。

GitHub Actions は、CI に寄せたいときの補助線

GitHub Actions は、Claude Code をリポジトリ中心で回したいときの選択肢です。定期実行の入口としても使えますし、PR や CI の流れの中に組み込みやすいのが特徴です。

言い換えると、開発フローの中で自動化したいときの受け皿です。Claude Code 単体のスケジュールというより、GitHub を軸にした運用に寄せたいときの方法、と考えるとわかりやすいでしょう。

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

Claude Code にはスキル（`.claude/skills/` に置く再利用可能な手順書）という仕組みがあり、これをスケジュール実行と組み合わせたくなる場面があります。ただ、そのまま試すと思ったように動かないことがあります。

まずハマりやすいのがスキルの置き場所です。ホームディレクトリ（`~/.claude/skills/`）に置いた personal skill は、routines（クラウドタスク）からは見えません。routines は毎回リポジトリを fresh clone して実行するので、手元のローカル設定は参照されないからです。routines でスキルを使いたい場合は、リポジトリ内の `.claude/skills/` に入れるのが前提になります。

次に気をつけたいのがスキルの呼び出し方です。タスクの prompt に `/skill-name` と書けば呼べそうに見えますが、少なくとも公式ドキュメント上で routines 側から明示的に保証されているわけではありません。より安定するのは、スキルの description に合う自然文で prompt を書いて、Claude に自動でそのスキルを発見・使用させる設計です。

たとえばスキルの description が「Review recent repository changes and produce a daily engineering summary」なら、タスクの prompt を「昨日からの変更を確認して、エンジニア向けのデイリーサマリーを作ってください」のように書くと、Claude がスキルの内容を自律的に読んで動いてくれます。

この設計では、スキル側の`disable-model-invocation` の設定が重要です。`false`（または省略）にしておくと、Claude が関連すると判断したときに自動でそのスキルを使います。routines 向けには基本これで大丈夫です。逆に `true` にすると、`/skill-name` で明示的に呼ばない限り動かないので、scheduled task の prompt から自動発火させる設計とは噛み合いません。

Desktop の scheduled task なら `/skill-name` の明示呼び出しが通りやすいです。ローカル環境で動くぶん、personal skill も含めて手元の設定をそのまま使えます。「確実にこのスキルを動かしたい」なら、Desktop のほうが動作の予測がつきやすいです。

自分ならどう選ぶか

迷ったら、次の順番で考えると整理しやすいです。

まず試したいだけなら `/loop`
ローカルファイルを見ながら回したいなら Desktop
PC を閉じても回したいなら routines
PR や CI に寄せたいなら GitHub Actions

私なら、最初は `/loop` か Desktop から入ります。理由はシンプルで、いきなりクラウド常駐や CI 連携に寄せるより、いまの作業の延長線上で試せるからです。そこで足りないものが見えてきたら、routines や GitHub Actions に広げる、という順番のほうが無理がありません。

番外編: Windows と Mac の外部スケジューラ

ここで、番外編として Windows と Mac のやり方も入れておくと、実運用のイメージがつきやすくなります。これは Claude Code の機能ではなく、OS 側のスケジューラで Claude Code を起動する考え方です。

Windows なら タスクスケジューラー、Mac なら launchd です。どちらも「いつ実行するか」をOSが面倒を見るので、Claude Code の内蔵スケジュールとは別の層になります。

この番外編は、特に「自分のPCで決まった時刻に起動したい」というときに役立ちます。Claude Code をどう動かすかではなく、どう起動するかをOSに任せる、という整理ですね。

Mac では timed job の第一候補として launchd が使われ、cron は推奨されていません。Windows でもタスクスケジューラーは定番の手段です。なので、番外編として触れておく価値は十分あります。

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

スケジュール実行を検討するとき、「これはプロプランの月額枠で動くのか、それとも別途APIトークンが引かれるのか」という疑問が出てきます。これは方法によって答えが変わります。

routinesやDesktop Scheduled Taskは、Claude Code on the web 上の機能として Pro/Max プランに含まれています。なので、月額プランの利用枠の中で動くと考えるのが自然です。使用量は API トークンベースではなく、プランの利用枠として扱われます。

一方でGitHub Actions や Agent SDKを使う場合は、`anthropic_api_key` を指定して動かす形になります。こちらは API トークン課金です。1回の実行で消費したトークン数や費用を把握しやすい反面、月額枠の外の話になります。

ちなみに Claude Code には `/cost` というコマンドがありますが、これは API トークンを使っているユーザー向けの確認コマンドです。Pro/Max 加入者の場合、利用量の確認はアカウントのダッシュボード側で行います。

まとめると、「月額プランで回したい」なら routines か Scheduled Task、「トークン単位で課金を把握・制御したい」なら GitHub Actions や SDK、という選び方になります。両方を同時にとる設計は現状難しいので、どちらを優先するかで方法が変わってきます。