Tech BlogAWSツール & 技術ブログ

Claude Code の /schedule と claude -p、どう使い分ける?——クラウド実行とローカル実行の違い・料金・定期処理の実例

皆さんは「定期処理」を回していますか?

Claude Code を対話的に使うのには慣れてきても、「毎朝決まった時刻に勝手に動いてくれる仕組み」まで組んでいる人は、まだ少ない印象です。

私は最新の Claude 関連アップデートや各種セキュリティニュースを、Claude Code の定期処理で半自動的に拾うようにしています。手動で X やニュースサイトを巡回していた頃と比べると、見落としが減り、しかも「自分が使っているツールに関係する話題だけ」に絞り込めるようになりました。

その運用を進めるなかで、一度しっかり整理しておきたかったのが「/scheduleclaude -p を launchd で回すのは、そもそも別物では?」という疑問です。どちらも「定期的に Claude を動かす」点は同じですが、実行場所・料金・セキュリティの性質がまったく違います。ここを混同すると、思わぬ課金やセキュリティリスクにつながります。

この記事では、両者の違いと使い分けの判断軸を、実際に運用している立場から整理します。

この記事で学べること

  • 学習の軸: 「定期処理をどの実行環境で動かすか」を、料金・セキュリティ・信頼性の観点から自分で判断できるようになること
  • 対象読者: /scheduleclaude -p の両方を一度は触ったことがあり、これから定期処理を組もうとしている人
  • 読む価値: 意図しない課金を避ける料金構造の理解、外部情報を扱うときのセキュリティの考え方、そして実際に /schedule を毎朝回している著者の運用例から、自分の用途での選択基準を持ち帰れること

なお、この記事は「判断軸の整理」に重心を置いています。具体的な /schedule の組み方(実装パターン)は、末尾で紹介する関連記事に役割を分けています。

関連記事: 脆弱性ニュース、追いきれていますか?——Claude Code の /schedule で情報収集を半自動化する話 では、/schedule を使ったセキュリティニュース収集の具体的な組み方を紹介しています。この記事は「そもそも /scheduleclaude -p をどう使い分けるか」という一段手前のテーマを扱います。

/schedule と claude -p は何が違うのか

まず、2つの方式の正体を押さえます。

  • /schedule(routines): Anthropic のクラウド側で、cron のスケジュールに従って自律的に Claude Code を動かす仕組み。Claude Code on the web をベースにしたリモート実行です。
  • claude -p + launchd: 自分のマシン(私の場合は Mac)で claude を非対話モード(headless)で起動し、それを macOS の launchd(Linux なら cron や systemd timer)から定期的にキックする方式です。

仕組みの違いを表にまとめます。

観点 claude -p + launchd /schedule(routines)
実行場所 ローカルマシン(自分の PC) Anthropic のクラウド(リモート)
マシンの起動 必須(スリープ・電源オフだと動かない) 不要(クラウドで常時動作)
ローカルファイル フルアクセス可能 不可(毎回リポジトリを新規クローン)
権限プロンプト ローカル設定に従う なし(自律実行)
出力先の相性 ローカルファイル・git commit 向き Slack・メール等のクラウド出力向き

ざっくり言うと、claude -p は自分のマシンの中で完結する作業、/schedule は外部情報を取りに行って通知する作業 が得意、という性格の違いがあります。

料金体系の違い(2026年6月15日から変わる点)

定期処理を組むうえで見落としやすいのが料金です。ここは 2026年6月15日から仕組みが変わる ので、特に注意が必要です。

claude -p(非対話モード)と Claude Agent SDK、GitHub Actions 連携は、2026年6月15日から 通常のプラン使用量とは別枠の月次クレジット で動くようになります。プラン別の月次クレジット額はおおむね次の通りです(Pro が $20、Max 20x が $200 を上限とする刻み)。

プラン 月次クレジット
Pro $20
Max 5x $100
Max 20x $200

クレジットの細かい挙動は、判断軸として効く3点だけ押さえれば十分です。

  • 使い切ったクレジットは翌サイクルに繰り越せない(個人アカウントに帰属し、組織でのプール・共有は不可)
  • 枠を使い切った後は、Usage Credits が 有効 なら従量課金へ移行、無効 なら次サイクルまでリクエストが停止する
  • 正確なプラン別の金額や claim 手順は更新されることがあるため、最新の数字は Anthropic 公式ヘルプセンター で確認するのが確実

判断軸として重要なのは金額の細部ではなく、claude -p 系だけが別枠の月次クレジットに切り出される一方、/schedule は通常のプラン使用量のまま、という違いです。意図しない課金を避けたいなら、Usage Credits を無効のままにしておけば、枠を使い切った時点で止まります。

一方の /schedule(routines)は、この月次クレジットの対象外 です。routines はクラウドで動き、通常のサブスクリプション使用量を消費します。なお、定期実行(recurring)は日次の使用量上限のカウント対象になる点は押さえておきましょう。

整理すると、課金の観点では次のように分かれます。

方式 2026年6月15日以降の課金
claude -p / Agent SDK / GitHub Actions 別枠の月次クレジット(枠超過+Usage Credits 有効時のみ従量課金)
/schedule(routines) 通常のプラン使用量を消費
対話型 Claude Code・Web/アプリの会話 従来どおり通常のプラン使用量

「対話型の Claude Code はこれまで通り」「claude -p だけ別枠クレジットに切り出される」という点が、6月15日からの一番の変化です。

claude -p が向いているケース

claude -p + launchd が活きるのは、ローカル環境そのものが処理の主役 になるケースです。具体例を挙げます。

  • 毎晩、ローカルにあるリポジトリで npm audit / composer audit を走らせ、結果をローカルのレポートファイルに出力する
  • ローカルに溜まったログファイルを定期集計し、サマリを作って蓄積していく
  • 管理下の .env やローカルの MCP サーバーを使ったバッチ処理
  • 処理結果を git commit する作業(ローカルの保護ブランチ判定・フック・CLAUDE.md の指示が効く)

特に ローカルに情報を溜め込んでいく用途claude -p の独壇場です。クラウド実行の /schedule は毎回リポジトリを新規クローンするため、前回の処理結果をローカルに積み上げていくような使い方はできません。手元のファイルシステムを読み書きしながら状態を育てていく処理は、ローカル実行でしか実現できません。

/schedule が向いているケース

逆に /schedule(routines)が向くのは、外部情報を取りに行って通知する タイプの定期処理です。

  • セキュリティニュース・脆弱性フィードの定期監視
  • 最新の Claude / Claude Code アップデート情報の収集
  • 業界ニュースの朝のダイジェストを Slack に投稿
  • マシンの電源状態に関係なく、毎朝決まった時刻に確実に走らせたい監視タスク

claude -p + launchd には「マシンが起動・スリープ解除していないと動かない」という弱点があります。朝の速報のような定時タスクでは、PC を閉じて寝ていると launchd は発火しません。/schedule はクラウドで動くので、電源状態に依存せず確実に走ります。定時の情報収集では、この信頼性の差が効いてきます。

セキュリティの観点:外部情報の収集はクラウド実行が安全

もう一つ、見落とされがちですが重要なのがセキュリティです。

ニュースやフィードの収集は、未検証の外部コンテンツを取り込んで処理する タスクです。外部コンテンツには、プロンプトインジェクション(コンテンツ内に紛れ込ませた指示で AI に意図しない操作をさせる攻撃)のリスクが常につきまといます。

この観点では、両者の安全性に差があります。

  • /schedule(クラウド): ローカルの認証情報・ファイルシステムにそもそもアクセスできない隔離環境で動く。仮に外部コンテンツに悪意ある指示が混入していても、奪われる資格情報がローカルに存在しない → 隔離されているぶん安全
  • claude -p(ローカル): 自律実行(権限プロンプトなし)に加え、ローカルの .env・ファイル・MCP サーバーにアクセスできる。未検証コンテンツの処理中にプロンプトインジェクションが起きると、ローカルの資格情報やファイルが標的になりうる

したがって、外部の未検証コンテンツを取り込む情報収集系は、隔離されたクラウド実行の /schedule の方がセキュリティ的にも理にかなっています。「ローカルで何でもやれる方が便利」という直感とは逆に、扱う対象が外部情報のときはアクセス範囲が狭いクラウド側が安全側に倒れる、という点は意識しておきたいところです。

私の使い方:最新 Claude 情報とセキュリティニュースの定期収集

私自身は、最新の Claude 関連情報と各種セキュリティニュースの収集を /schedule で回しています

理由は、これまで述べた判断軸そのものです。

  1. 対象が外部の未検証コンテンツ だから、隔離されたクラウド実行の方が安全
  2. 毎朝確実に走らせたい から、マシンの電源状態に依存しないクラウド実行が向く
  3. ローカルに溜め込む必要のない「読んで通知するだけ」のタスク だから、ローカルファイルへのアクセスが不要

実際に運用してみると、「自分が使っているフレームワーク・プラグインに関係するニュースだけ」を毎朝の決まったタイミングで受け取れるようになり、情報の取りこぼしが目に見えて減りました。具体的な /schedule の組み方はこちらの記事にまとめています。

逆に、ローカルのリポジトリを監査して結果を蓄積するような処理を組むなら、私は claude -p + launchd を選びます。要は「外部を見にいくなら /schedule、手元を触るなら claude -p」という単純な基準で振り分けています。

まとめ

/scheduleclaude -p は「定期的に Claude を動かす」点こそ同じですが、別物です。判断軸を最後にまとめます。

  • 実行場所: クラウド(/schedule)か、ローカル(claude -p)か
  • 対象: 外部情報の収集・通知なら /schedule、ローカルファイル・git 操作・情報の蓄積なら claude -p
  • 信頼性: 電源状態に依存せず確実に動かしたいなら /schedule
  • セキュリティ: 未検証の外部コンテンツを扱うなら、隔離されたクラウド実行の /schedule
  • 料金(2026年6月15日以降): claude -p は別枠の月次クレジット、/schedule は通常のプラン使用量

そして個人的に強く感じているのは、AI 時代において定期的な情報収集を仕組み化しておく価値はかなり大きい ということです。技術の更新速度が上がり続けるなかで、人手の巡回だけで追いきるのは現実的ではなくなってきました。自動で集めて、自分に関係するものだけに絞り込んでくれる仕組みがあると、可処分時間の使い方がはっきり変わります。

トークン(使用枠)に余裕があるなら、まずは小さな定期処理を一つ組んでみることをおすすめします。「毎朝、自分の使っているツールの最新情報を 1 通だけ通知する」くらいの軽いものでも、続けてみると手放せなくなります。

次のステップ:判断軸から実装へ

この記事で「自分の用途ならどちらを選ぶか」の判断軸が整理できたら、次は実際に手を動かす番です。

  • 外部情報の収集・通知を /schedule で組むと決めたなら: 脆弱性ニュース、追いきれていますか?——Claude Code の /schedule で情報収集を半自動化する話 に、著者が毎朝回しているセキュリティニュース収集の具体的な組み方(出力先の選び方・自分のスタックに関係する話題への絞り込み・ラベル付け)をまとめています。本記事が「理論(判断軸)」、関連記事が「実装パターン」という役割分担です。
  • ローカルの監査・蓄積を claude -p で組むなら: まずは npm audit などの軽いコマンドを 1 つ、launchd(または cron)から動かすところから始めると、権限プロンプトや出力先の挙動を小さく確認できます。

「理論を読んだら、最小構成で一度動かしてみる」——この順番で進めると、判断軸が自分の中で腹落ちします。