Claude Code Routines の使い方——スケジュール / API / GitHub の 3 トリガー実例、Pro 5 回・Max 15 回・従量課金の実費
毎朝、自分が PC を開く前に Claude Code が「昨日の差分要約」を仕上げてくれていたら、業務時間は何分買い戻せるでしょうか。Claude Code Routines は、その買い戻しを Pro / Max プランの追加機能として実現する仕組みです。スケジュール起動・API 起動・GitHub イベント起動の 3 トリガーを軸に、本記事では「最初の 1 件を 10 分で動かす」から「1 日 5 〜 15 回の上限と従量課金をどう設計するか」まで、実運用に必要な勘所を一気に整理します。
Claude Code Routines は、クラウド側で Claude Code を起動する機能で、スケジュール・API・GitHub イベントの 3 トリガーを持ちます。
Pro は 1 日 5 回、Max は 1 日 15 回までが無料枠で、それを超えると従量課金が走るため、毎日同時刻に走る軽量タスクから順に Routines へ寄せ、突発の重い処理は手元の対話式に残すのが基本設計です。
OS 側の定期起動やマネージドな常駐プロセスとの使い分けは「回数 × 重さ × 失敗時コスト」の 3 軸で判断します。
目次 (18)
- Claude Code Routines とは——3 つの起動トリガーと「クラウド側で動く Claude Code」という位置付け
- 対話セッション内のスケジュール指示とは別物——検索者の取り違えを最初に防ぐ
- 始め方——Web / desktop からの有効化・最初の 1 件を 10 分で動かす最短手順
- Step 1-3: タブを開いて新規 routine を作成、トリガーを選ぶ
- Step 4-5: プロンプトを書いて初回テスト実行で動作確認
- 3 トリガー別の実例——スケジュール起動 / API 起動 / GitHub イベント起動を、業務シナリオで使い分ける
- スケジュール起動: 毎朝 7 時の「公開ドキュメント差分要約」
- API 起動: 社内 Slack / 受信メールの特定タグから一次返信案を作る
- GitHub イベント起動: PR open / push 時に「軽い変更点要約とリスクメモ」を先出し
- Pro 1 日 5 回 / Max 1 日 15 回——実行上限・従量課金の実費感・予算超過しないための運用設計
- 「5 回」「15 回」をどう割り当てるか——朝・昼・夕の 3 ブロックで考える
- Opus 4.7 Fast Mode が既定化——重い処理は Fast Mode 側のコストも見る
- 既存手段との使い分け——スクリプト常駐・サードパーティ製定期起動と比較した判断軸(回数 × 重さ × 失敗時コスト)
- 判断軸 1: 回数——1 日 5 〜 15 回の上限内に収まるか
- 判断軸 2: 重さ——単発で長時間の処理は Routines と相性が悪い
- 判断軸 3: 失敗時コスト——人が即介入すべきタスクは Routines 単独で完結させない
- チェックリスト: 今日 Routines に乗せる「最初の 1 件」を決める
- 出典
Claude Code Routines とは——3 つの起動トリガーと「クラウド側で動く Claude Code」という位置付け
Claude Code Routines は、Pro / Max プランの追加機能としてクラウド上で Claude Code を起動する仕組みです。手元のターミナルで対話する Claude Code と違い、自分が PC を開いていなくても処理が走る点が本質的な違いです。トリガーは(1)スケジュール起動(指定した時刻に発火)(2)API 起動(外部から HTTP で呼び出して発火)(3)GitHub イベント起動(PR / push などのイベントを受けて発火)の 3 種類。出力結果は Web / desktop アプリの Routines タブで時系列に閲覧できます出典。
対話セッション内のスケジュール指示とは別物——検索者の取り違えを最初に防ぐ
検索で取り違えやすいのが、対話セッション中に Claude Code 自身が次回の処理時刻を提案する「セッション内のスケジューリング」機能です。こちらは Claude Code が「次は◯◯時に再開してください」と提案して対話を終了する仕組みで、Routines のように「自分が PC を開いていなくても処理を継続する」性質はありません出典。Routines はクラウド側に常駐する別レイヤーであることをまず押さえます。
始め方——Web / desktop からの有効化・最初の 1 件を 10 分で動かす最短手順
Routines の最初の 1 件は、できるだけ短時間で「動いた」状態まで持ち込み、後から内容を磨き込むのが定石です。最短 10 分で 1 件を動かすには、次の 5 ステップで進めます。手順そのものはシンプルですが、最初のトリガー選択とプロンプトの粒度の 2 点だけは慎重に決めると、その後の運用が楽になります。最初の 1 件が動いた後の改善のほうが、初回設定よりも 10 倍時間を掛ける価値があります出典。
Step 1-3: タブを開いて新規 routine を作成、トリガーを選ぶ
(a)Web もしくは desktop アプリの Routines タブを開きます。(b)新規 routine を作成し、後から自分で識別できる名前を付けます(例: daily-doc-diff のように内容と頻度が伝わる命名が後で楽です)。(c)起動トリガーをスケジュール / API / GitHub のいずれかから選択します。最初の 1 件は失敗時の影響が小さい「スケジュール起動・1 日 1 回」を選ぶと検証が楽です出典。
Step 4-5: プロンプトを書いて初回テスト実行で動作確認
(d)Claude Code に投げるプロンプトを書きます。最初は「対象ファイルのパス」「読み取って欲しい内容」「出力フォーマット」の 3 つを明示するだけで十分です。(e)初回テスト実行で動作を確認します。失敗した場合は履歴タブからログを開き、どの段階で止まったかを確認できます出典。本番投入前に必ず 1 回テスト実行する習慣を付けると、本番運用での驚きが減ります。
3 トリガー別の実例——スケジュール起動 / API 起動 / GitHub イベント起動を、業務シナリオで使い分ける
3 トリガーは「いつ発火させるか」の違いです。スケジュール起動は時刻、API 起動は外部イベント、GitHub イベント起動はリポジトリ上のイベント。実務では「業務シナリオに合うトリガーを選ぶ」のではなく「Routines に寄せたいタスクの発火条件を整理してから、それに合うトリガーを 1 つだけ選ぶ」順序が正解です。各シナリオで Routines が向く理由と向かない理由を 1 行ずつ添えて整理します出典。
スケジュール起動: 毎朝 7 時の「公開ドキュメント差分要約」
自社プロダクトの公開ドキュメントが日次で更新される現場では、前日比の差分要約を毎朝 7 時に Routines が生成しておく運用が便利です。読み手は出社直後に Routines タブを開けば、その日のリリース情報を 30 秒で把握できます出典。向く理由は「決まった時刻に決まった対象を要約する」型のタスクであること。向かない理由は「対話途中で人間の判断が要る案件」には使えない点で、その場合は手元の対話式に残します。
API 起動: 社内 Slack / 受信メールの特定タグから一次返信案を作る
問い合わせ管理を Slack や共有メールで運用しているチームでは、特定のタグやキーワードが付いた瞬間に API で Routines を呼び出し、「問い合わせ要約と一次返信案」を生成させると初動が速くなります。向く理由はトリガーが外部イベント駆動であること。向かない理由は応答そのものを送信まで完結させようとすると失敗時の説明責任が重くなる点で、Routines の出力は人間の確認を挟んでから送信する設計が安全です出典。
GitHub イベント起動: PR open / push 時に「軽い変更点要約とリスクメモ」を先出し
GitHub イベント起動は PR が open された瞬間や push が走った瞬間に Routines を発火させ、変更点の要約と懸念点のメモを PR コメントとして残す使い方が定番です。本格レビュー前に頭を作る「下準備」として相性が良く、Routines が向く理由は「事象駆動」「短時間で終わる」の 2 点が揃うこと。向かない理由は本格レビューそのものを置き換えようとすると見落としが出る点で、Routines は要約・整理・タグ付けまでに留めます出典。
Pro 1 日 5 回 / Max 1 日 15 回——実行上限・従量課金の実費感・予算超過しないための運用設計
Routines の実行回数は、Pro が 1 日 5 回、Max が 1 日 15 回までが当日の無料枠です。これを超えると従量課金が走る設計のため、毎日同時刻に走る軽量タスクを優先的に Routines に寄せ、突発の重い処理は手元の対話式に残す——という配分が、最もコストを抑える設計指針になります出典。料金体系の具体的な数字は契約プランと地域で変動しうるため、Anthropic 公式ドキュメントとサードパーティの実運用記事の双方を必ず一次情報として参照してください。
「5 回」「15 回」をどう割り当てるか——朝・昼・夕の 3 ブロックで考える
Pro の 5 回なら「朝 2 / 昼 1 / 夕 2」、Max の 15 回なら「朝 5 / 昼 5 / 夕 5」と分けると、上限を使い切る運用にも、突発タスクのために 1 〜 2 枠を予備に残す運用にも、どちらにも対応できます。Pro で実行回数が頻繁に上限に届くようであれば、Max への切り替え or 一部タスクを OS 側に移すのが次の判断です出典。
Opus 4.7 Fast Mode が既定化——重い処理は Fast Mode 側のコストも見る
2026 年 5 月 12 日付のリリースで、Opus 4.7 の Fast Mode が既定モデルとして提供されています出典。Routines に重い処理を寄せる場合は、Fast Mode 側のレートや実費を併せて確認しておき、無料枠 + 従量課金の合計予算を月次で見積もるのが安全な進め方です。月初に予算上限を決めて、月末にズレを確認するサイクルが回せば、突発の重い処理で予算を超えそうな日は手元の対話式に戻す判断ができます。
既存手段との使い分け——スクリプト常駐・サードパーティ製定期起動と比較した判断軸(回数 × 重さ × 失敗時コスト)
Routines はクラウド側で軽量タスクを回す道具として優秀ですが、すべての定期処理を寄せるのが正解ではありません。OS 側の定期起動・マネージドな常駐プロセス・サードパーティ製のスケジューラと比較したうえで、Routines に寄せる範囲を絞り込むのが運用設計の本筋です。判断は次の 3 軸で行います。回数・重さ・失敗時コスト。3 軸をすべて満たすタスクから順に Routines へ移していくと、無理のない移行になります出典。
判断軸 1: 回数——1 日 5 〜 15 回の上限内に収まるか
1 日 5 〜 15 回以内に収まるタスクは Routines が第一候補です。それを超えるもの(例: 1 時間ごとの監視・5 分ごとのヘルスチェック)は OS 側の定期起動やマネージドな常駐プロセスに分散させる設計が無難で、これにより Routines の無料枠を「人間が読む価値のある出力」に集中させられます出典。
判断軸 2: 重さ——単発で長時間の処理は Routines と相性が悪い
単発で長時間掛かる重処理は、Routines の上限・タイムアウト・コストのいずれとも相性が悪くなりがちです。短い指示で済むもの、出力が要約・差分・整形に収まるものを Routines に寄せ、重処理は手元のマシンやマネージド環境に残す——という線引きが、運用コストを最も低く抑えます出典。
判断軸 3: 失敗時コスト——人が即介入すべきタスクは Routines 単独で完結させない
失敗時に人が即介入すべきタスク(本番障害対応・顧客通知の最終発射・支払処理など)は、Routines 単独で完結させないのが原則です。Routines は通知・要約・下準備・ドラフト生成までに留め、最終決断は人が握る設計にします。失敗時のリカバリ手順を事前に書いておく習慣も、運用上は重要な保険になります出典。
チェックリスト: 今日 Routines に乗せる「最初の 1 件」を決める
- 毎日同じ時刻にやっている軽作業を 1 件挙げる(目安: 5 分以内 / 失敗しても困らない)。
- その 1 件を Routines のスケジュール起動で書き換え、初回テスト実行を通す。
- 1 週間運用して、買い戻せた時間と従量課金の実費を確認する。
最初の 1 件が動けば、2 件目以降は同じ型を増やすだけです。本記事の続きは、自分の業務カレンダーを開いて 1 件選ぶことから始まります。
