Claude Codeルーチンでcron・ローカル実行を卒業する定期実行の始め方
Claude Codeを使った自動化を、いまだにcronジョブとローカルスクリプトで回していないだろうか。Anthropicが2026年4月14日に research preview として公開した「ルーチン(Routines)」は、プロンプト・リポジトリ・コネクタを一度保存すれば、Anthropicのクラウド上で繰り返し実行される仕組みだ。ノートPCを閉じても指定した条件でタスクが動き続けるため、cronサーバーの死活監視やローカル常駐から解放される。本記事は、3種類のトリガー設定、1日あたりの実行回数上限とトークン消費、claude/ブランチなどの制約まで、導入判断に必要な点を research preview 時点の公式仕様で整理する。
まとめ:Claude Codeルーチンの要点
- クラウド実行でローカル不要。実行基盤はAnthropic側にあり、cronサーバーやPCの常駐がいらない。
- トリガーは3種類:スケジュール・API・GitHub。1つのルーチンに複数併用できる。
- 1日の実行回数はプラン別(公開時点でPro5回・Max15回・Team/Enterprise25回、変動あり)。トークンは通常のインタラクティブセッションと同じ枠から消費される。
- 安全側の既定:プッシュ先は
claude/接頭辞のブランチのみ。ドラフトPR+人間レビューが前提運用。 - 2026年7月時点も research preview。上限値やAPIは変更されうるため、ミッションクリティカルな処理を単独で任せない。
Claude Codeルーチンとは — cronとローカル常駐を不要にするクラウド実行
保存型構成でローカルマシンを使わずクラウド上に完結する仕組み
ルーチンは、実行時の指示となるプロンプト、対象リポジトリ、Slack・Linear・Google Driveなどのコネクタをひとまとめに保存した「保存型」の自動化単位だ。保存後はトリガーを設定するだけで同じ構成が繰り返し走る。実行環境はAnthropicのクラウドに完結するため、従来のCLIのようにターミナルを開いたローカルマシンへ依存しない。夜間や週末でも設定どおりに動き、PCのスリープやネットワーク切断で処理が止まることがない。
管理はスマホやクラウドでClaude Codeを操作する構成と同じくブラウザのclaude.ai/code/routinesから行い、作成・編集・実行ログ確認まで完結する。各ルーチンは個人のclaude.aiアカウントに帰属し、GitHubやコネクタ経由の操作は作成者名義で実行される。
cron・MCP自前管理を置き換える設計と/scheduleコマンドからの移行
ルーチン以前は、cronの設定・障害対応、SlackやGitHubをつなぐMCPサーバーの構築と維持、そしてローカル依存の稼働時間制限をすべて自前で抱える必要があった。ルーチンはこの3点をまとめて解消する。すでにCLIの/simplifyや/batchなどのスラッシュコマンドを使っているなら、/scheduleコマンドがそのままクラウドルーチンの作成に対応する。プロンプトやリポジトリ設定を書き直さずに移行でき、/schedule updateでcron式のカスタムスケジュールもCLIから指定できる。なお利用にはclaude.aiのサブスクリプションログインが必要で、Console APIキーやBedrock・Vertex経由のAPIアカウントでは使えない。
スケジュール・API・GitHub Webhookで異なる3トリガーの設定方法
2026年4月時点で提供されるトリガーはスケジュール・API・GitHubの3種類だ。自動化するタスクの性質に合わせて選び、1つのルーチンに複数併用もできる。各トリガーは独立してセッションを生成し、その分だけ1日の実行回数を消費する。
スケジュールトリガー:プリセットとcron式で決まった時刻に起動
設定画面でhourly(毎時)・daily(毎日)・weekdays(平日)・weekly(毎週)のプリセットを選ぶと、指定時刻にルーチンが自動起動する。タイムゾーンはユーザーのローカル設定が自動反映される。プリセットで足りない頻度は、CLIの/schedule updateでcron式を直接指定する。たとえば2時間ごとなら0 */2 * * *、月初の月曜のみなら0 9 1-7 * 1と書く。ただし最小実行間隔は1時間で、それより高頻度のcron式は拒否される。定期的なバグトリアージ、週次のドキュメント点検、日次のデプロイレポートなど、決まったタイミングで繰り返す作業に向く。単発(特定時刻に1回だけ)の実行も可能で、これは1日の実行回数上限には数えられない。
APIトリガー:/fireエンドポイントとトークンで外部システムから起動
APIトリガーは、ルーチンごとに発行される/fireエンドポイントへHTTP POSTを送って実行を開始する。固有のエンドポイントURLと認証トークン(表示は一度きり)が発行され、beta header experimental-cc-routine-2026-04-01を付けて呼び出す。レスポンスにはclaude_code_session_urlが返る。DatadogやPagerDuty、Sentryなどの監視ツールのWebhook送信先にこのエンドポイントを登録すれば、アラート発生時に自動でルーチンが起動し、トレース解析や関連デプロイの相関分析、Slack投稿までを人手なしで実行できる。プログラムから制御したい場合はClaude Agent SDK(旧Claude Code SDK)と組み合わせる選択肢もある。
GitHub Webhookトリガー:PR・Releaseイベントをフィルタして実行
GitHubトリガーは、指定リポジトリのイベントに連動してルーチンを起動する。対応イベントはPull Request(opened・closed・assigned・labeled・synchronized など)とRelease(created・published・edited・deleted)で、特定アクションに絞り込める。設定にはClaude GitHub Appのインストールが必要で、フィルタ条件はWeb UIから指定する。たとえば認証モジュール(/auth-provider)を変更するPRだけを対象にセキュリティレビューを自動化できる。GitHubトリガーにはルーチン単位・アカウント単位の時間あたり上限があり、コミット頻度が高いリポジトリではフィルタで対象を絞らないと、上限超過分のイベントはドロップされ再送されない。
プラン別の1日の実行回数上限とトークン消費の仕組み
ルーチンは無制限ではなく、プランごとに1日の実行回数上限が設けられている。公開時点の上限は次のとおりだが、research preview 期間中は変更されうるため、実際の残り回数はclaude.ai/code/routinesの表示で確認するのが確実だ。
| プラン | 月額(年払い) | 1日の実行回数上限 |
|---|---|---|
| Pro | 20ドル(年17ドル) | 5回 |
| Max | 100 or 200ドル | 15回 |
| Team(Standard席) | 25ドル/席(年20ドル) | 25回 |
| Enterprise | 要問い合わせ | 25回 |
この上限は「作成できるルーチン数」ではなく「1日に実行される回数」を指す。Proでも20個以上のルーチンを保存し曜日で切り替える運用は可能だが、実行できるのは1日5回分だけだ。
もう1つの制約がトークンで、ルーチンの実行は通常のインタラクティブセッションと同じサブスクリプション枠から消費される。大きなリポジトリを対象にした詳細なレビューは1回で多くのトークンを使い、日中の手動セッションが早く上限に達することもある(Claude Codeの利用上限の考え方と共通だ)。上限に達した後も、usage credits(メータードオーバージ)を有効にしていれば従量課金で継続実行できる。有効化はSettings>Billingから行うが、フィルタが甘いGitHubトリガーが想定外に多数実行されるとコストが膨らむため、上限アラートと併用したい。
GitHub ActionsやZapierと使い分けるルーチン導入の判断基準
ルーチンは既存のCI/CDやiPaaSと機能が一部重なる。使い分けの軸は明快で、「自動化対象がコードの意味を読むかどうか」だ。Claude Code ActionやGitHub ActionsはYAMLで定義したステップを順に実行するオーケストレーターで、コード内容に基づく判断や自然言語での分析はしない。一方ルーチンは、PRの差分を読んで認証・認可の変更を検出し、影響範囲を要約してSlackへ通知する、といった処理を1つのプロンプトで書ける。テスト実行やビルドのような決定論的処理はGitHub Actionsが適し、両者は競合ではなく補完関係にある。ZapierやMakeが得意とするCRM・決済・メール連携などの非開発系ワークフローも引き続きiPaaSの領分だ。ただしルーチンは状態管理・自動リトライ・複数ルーチンの連鎖といった汎用オーケストレーターの機能を持たない。実行が途中で失敗しても自動再実行はされないため、「繰り返し実行可能なClaude Codeセッション」であって、複雑な依存関係を組むツールではないと割り切るのが実務的だ。
安全に始めるための制約と最初のルーチン
ルーチンには安全のための意図的な制約がある。既定ではプッシュ先がclaude/接頭辞のブランチに限定され、mainやdevelopへ直接プッシュできない。生成コードはclaude/fix-auth-bugのような専用ブランチのドラフトPRとして提出され、人間がレビューしてからマージする流れが標準だ。この制限はリポジトリ単位で「Allow unrestricted branch pushes」から無効化もできるが、堅牢なレビュー体制がある場合に限るのが公式の推奨で、research preview 中は有効のままが安全側だ。自律的なマージは避け、まず小さなタスクで実績を積んでから権限を広げたい。最初の1本には毎日のバグトリアージが向く。成果はSlackに投稿されたサマリーで即座に確認でき、コード変更やマージを伴わないためリポジトリへの影響がなく、リードエンジニアの手動トリアージ時間を削減できてチーム全体で効果を実感しやすいからだ。Team/Enterpriseでは組織のOwnerがclaude.ai/admin-settings/claude-codeからルーチン機能自体を無効化できる点も、導入前に押さえておくとよい。
よくある質問
Claude Codeでタスクを定期実行できますか
できる。ルーチンのスケジュールトリガーで、hourly/daily/weekdays/weeklyのプリセット、またはCLIの/scheduleコマンドとcron式で定期実行を設定する。最小実行間隔は1時間だ。
ルーチンの実行にローカルマシンは必要ですか
不要だ。実行基盤はAnthropicのクラウド上にあり、PCを閉じても設定どおりに動く。作成・管理はclaude.ai/code/routinesから行い、Claude Code on the web の有効化が前提となる。
1日に実行できるルーチンの回数はいくつですか
公開時点でPro5回・Max15回・Team/Enterprise25回だが、research preview 中は変わりうる。これは作成数ではなく実行数の上限で、残り回数はclaude.ai/code/routinesで確認できる。上限超過分はusage creditsを有効化すれば従量課金で継続できる。
cronやcrontabから移行できますか
できる。CLIの/scheduleコマンドがクラウドルーチンの作成に対応し、cron式は/schedule updateで指定する。cronサーバーの死活監視やローカル常駐を手放せる点が移行の主な利点だ。
実行回数の制限にすぐ達してしまうのはなぜですか
複数トリガーを持つルーチンは、トリガーごとに実行回数を消費するためだ。スケジュールで1日1回、GitHubで3回起動されるルーチンは合計4回と数える。加えてトークンが通常セッションと共通枠のため、大きなリポジトリを対象にすると消費が早い。フィルタで対象を絞り、重要ルーチンを早い時間帯に配置すると安定する。