MF Blogs Tools
クラウド中央のスケジューラから3方向にトリガーが伸びるRoutinesの抽象図

Article

Claude CodeのRoutinesでcron/GitHubイベント/APIから自動化を組む

Claude CodeのRoutinesを整理します。スケジュール/API/GitHubイベントの3トリガー、対応プラン(Pro/Max/Team/Enterprise)、`/schedule`コマンド、claude.aiでのWebセットアップ、PR Auto-fixとの違い、`claude/`ブランチ制約、connectors権限、レート制限と日次キャップまで、定期実行や自動応答をAIに任せたい上級者向けに公式仕様を踏まえて解説します。

0:00 0:00

This article is not published in this language yet, so the Japanese version is shown instead.

Claude CodeのRoutinesは、プロンプト・リポジトリ・接続するMCPコネクタを1つの「保存済みセッション」にまとめ、cron/API/GitHubイベントで自動起動する仕組みです。Anthropic管理のクラウドVMで動作するため、PCを閉じたままタスクを進められます。本記事は、Routinesの3トリガー、対応プラン、/scheduleコマンド、connectors権限、レート制限と日次キャップ、運用上の注意点までを整理します。

結論:「保存済みのプロンプト」を自動起動する装置

Routinesを使うべきかどうかは、次の3点で決められます。

  1. 同じ作業を繰り返している:毎日/毎週/毎リリースで実行するプロンプトがある
  2. PCを開きっぱなしにできない:手元から離れても進めたい長尺タスクがある
  3. イベント起点で動かしたい:PR・アラート・デプロイ完了などをトリガーにしたい

このいずれかが当てはまるなら、Routinesは強力な選択肢になります。Routinesは2026年5月時点でリサーチプレビューとして、Pro/Max/Team、およびEnterprise(Claude Code on the webが有効な席)に提供されています。動作環境やセッションの仕組みは「Claude Code on the webの使い方とローカルCLIとの違い」が前提になります。

Routinesに付けられる3つのトリガー

Routinesには、Schedule・API・GitHubの3種類のトリガーを組み合わせて付けられます。同じRoutineに複数トリガーを付けるのも可能で、例えば「毎晩走らせつつ、新規PRが来たら追加で走る」という運用ができます。

トリガー起動契機
Schedule毎時/毎日/平日/毎週などの定期、または特定時刻の1回実行
API専用エンドポイントへのHTTP POST(Bearer Token認証)
GitHubリポジトリイベント(Pull Request/Release)に対する反応

Routineの作り方:Web/CLI/Desktopから

Routineはclaude.ai/code/routines・CLI・Desktopアプリの3経路から作成・管理できます。同じクラウドアカウントを参照するため、どこで作っても全サーフェスに反映されます。

CLIから作る場合は次のコマンドです。

/schedule

引数を直接渡すこともできます。

/schedule daily PR review at 9am
/schedule clean up feature flag in one week

CLIから作れるのはScheduleトリガーのみで、APIとGitHubトリガーはWeb UIで追加します。一覧・更新・即時実行はそれぞれ次のコマンドです。

/schedule list
/schedule update
/schedule run

Desktopアプリでは、サイドバーの「Routines」から「New routine」→「Remote」で作成します。「Local」を選ぶとDesktop scheduled tasks(手元のマシンで動くスケジュールタスク)になり、Routinesとは別物です。

Routineの設定項目

作成フォームでは次の5要素を組み合わせます。

要素内容
プロンプト起動時に走る指示文。自己完結で、成功条件まで明示する
リポジトリ各実行でdefault branchから新規クローン。1つ以上選ぶ
環境クラウド環境(ネットワークアクセス・環境変数・setup script)
Connectors利用するMCPコネクタ。実行中は承認なしで全ツールが使える
トリガーSchedule/API/GitHubの組み合わせ

公式が強調している通り、プロンプトは最も重要なパートです。Routinesは「permission-modeなし・実行中の承認なし」で動くため、依頼文の曖昧さがそのまま事故につながります。依頼文の作法は「Claude Codeに伝わるプロンプトの基本構造:目的・制約・完了条件の書き方」、完了条件は「Claude Codeの成功率を上げる制約条件と受け入れ条件の作り方」が土台になります。

Scheduleトリガー:時間ベース

Scheduleトリガーは、毎時/毎日/平日/毎週のプリセットから選びます。時刻はあなたのローカル時間で入力し、自動でUTC変換されるため、クラウドインフラの場所に関係なく狙った時刻で走ります。

実行はstaggerにより数分ずれて始まりますが、同じRoutineについてはオフセットが一定とされています。最小間隔は1時間で、より短いcron式は拒否されます。

「2時間ごと」「毎月1日」のようなプリセットにない間隔は、近いプリセットで作ってから/schedule updateでcron式に書き換える運用です。

一回限りの予約実行もできます。「来週金曜の朝に昨日マージしたPRをまとめる」「2週間後にフィーチャーフラグ削除PRを開く」のような使い方で、1回発火後にRoutineは自動で無効化され「Ran」と表示されます。重要な点として、一回限りの実行は日次Routine実行キャップに加算されません(通常のサブスクリプション利用は消費)。

APIトリガー:HTTP POSTで起動

APIトリガーは、Routineごとに専用のHTTPエンドポイントとBearer Tokenを発行する仕組みです。アラート・デプロイ完了・社内ツールなど、認証付きHTTPリクエストを送れる場所からRoutineを起動できます。

設定はWeb UIからのみ可能で、トークンは生成時の1度しか表示されません。アラートツールのシークレットストアに保管する前提です。

呼び出しは次のような形になります(公式サンプル)。

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

成功レスポンスにはセッションIDとURLが含まれ、ブラウザでリアルタイム監視できます。

textフィールドは「Routine実行ごとに変わるコンテキスト」を渡す箇所で、フリーテキストとして扱われます。JSONを文字列として送ると、それは保存済みプロンプトと一緒に文字列として渡る、という点に注意してください(構造化パースは行われません)。

/fireエンドポイントはexperimental-cc-routine-2026-04-01ベータヘッダのもとで動作し、リクエスト・レスポンス形状やレート制限・トークン仕様は変更され得ます。破壊的変更は新しい日付付きヘッダで提供され、直近2バージョンの旧ヘッダも当面動くため、移行の猶予があります。

GitHubトリガー:PRとReleaseに反応

GitHubトリガーは、Pull RequestとReleaseの2イベントカテゴリに対応します。pull_request.openedのような特定アクション、またはカテゴリ全体に反応する設定が選べます。

GitHub triggerを使うには、Claude GitHub Appを対象リポジトリにインストールしている必要があります。公式が明示している通り、/web-setupはクローン用のアクセス権を渡すだけで、Webhook配信は有効化しません

フィルタも豊富で、Author/Title/Body/Base branch/Head branch/Labels/Is draft/Is mergedの組み合わせを、equals/contains/starts with/is one of/is not one of/matches regexの演算子で書けます。matches regexは完全一致である点に注意(部分一致なら.*hotfix.*)。

公式が挙げている例:

  • Auth module reviewbase branch = main AND head branch contains "auth-provider"で、認証まわりに触るPRだけ専用レビュアーへ
  • Ready-for-review onlyis draft = falseでドラフトはスキップ
  • Label-gated backportlabels includes "needs-backport"でラベル付きだけバックポート

リサーチプレビュー期間中、GitHub WebhookイベントにはRoutineごとおよびアカウントごとに毎時上限があり、超過分はドロップされます(リセットまで保留はされません)。

Connectorsと権限:何にアクセスできるか

Routineは「permission-modeなし/実行中の承認なし」で動くため、何にアクセスできるかは事前設定で決まります。

  • Connectors:claude.aiに接続したMCPコネクタが既定で全て含まれる。書き込みを含む全ツールを承認なしで使えるため、不要なものは外す
  • リポジトリ:選んだリポジトリだけが見える。pushは既定でclaude/プレフィックスのブランチに限定(Allow unrestricted branch pushesで解除可)
  • 環境:Network access(None/Trusted/Full/Custom)、環境変数、setup scriptで決まる

claude mcp addで個人マシンに入れたMCPサーバー」はRoutineからは見えません。Routinesで使うなら、claude.ai側でConnectorとして追加するか、リポジトリにコミットした.mcp.jsonで宣言します。

PR Auto-fixとの違い

Routinesと混同しやすいのが、「Claude Code on the webの使い方とローカルCLIとの違い」で扱ったPR Auto-fixです。両者は別機能で、補完関係にあります。

RoutinesAuto-fix PR
起点Schedule/API/GitHubイベント特定PRに対する継続監視
設定単位Routine(プロンプト+環境)として保存PRごとのトグル
プロンプト自分で書く「CI失敗とレビュー指摘に反応」のテンプレート
終了条件各実行で完結PR監視をOFFにするまで継続

「PR作成時に常にレビューさせたい」ならRoutineのpull_request.openedトリガー、「特定の進行中PRをClaudeに見させたい」ならAuto-fix、というのが分かりやすい棲み分けです。

帰属:Routineは「あなたとして」動く

Routinesは個人claude.aiアカウントに紐づき、チームには共有されません。実行で発生する操作は、すべてあなた経由で記録されます。

  • GitHubコミット・PRはあなたのGitHubユーザー名義
  • SlackメッセージやLinear起票などのConnector操作はあなたの連携アカウント

公式の警告は明確で、Routinesがあなたとして動くという前提で、リポジトリ・Connector・環境変数のスコープを絞ることが運用設計の出発点です。

レート制限と日次キャップ

Routinesは通常のサブスクリプション利用の枠を消費します。それに加えて、アカウントごとに1日のRoutine実行回数キャップがあります。日次キャップはclaude.ai/code/routinesまたはclaude.ai/settings/usageで確認できます。

キャップに達した後の挙動は、組織のUsage credits設定により分岐します。

  • Usage credits ON:メーター超過で継続実行(追加課金)
  • Usage credits OFF:以降の実行は拒否され、ウィンドウのリセットを待つ

並列実行が増えるほどレート消費も比例して増えるため、--remoteでの並列実行と組み合わせる場合は、コスト構造を把握してから動かすのが安全です。

組織管理者向け:無効化トグル

TeamとEnterprise管理者は、claude.ai/admin-settings/claude-codeの「Routines」トグルでRoutines機能を全メンバーに対して無効化できます。無効化すると既存Routinesは停止し、新規作成も拒否されます。/scheduleはクライアント側設定では上書きできないサーバー側設定です。

CLIで/scheduleが「Unknown command」になるときの公式トラブルシュート:

  • Console API keyやBedrock/Vertex/Foundry経由認証になっている(claude.aiサブスクリプションログイン必要)
  • ANTHROPIC_API_KEYANTHROPIC_AUTH_TOKENapiKeyHelperが設定されている(claude.aiログインより優先される)
  • DISABLE_TELEMETRYDO_NOT_TRACKCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICDISABLE_GROWTHBOOKが設定されている(フィーチャーフラグ取得を止める)
  • Claude Code on the webセッション内(WebからRoutinesを管理する)
  • CLIがv2.1.81未満(claude updateで更新)

やってはいけないこと

Routinesでハマりやすいパターンを挙げます。

  1. 本番リソースに無制限ブランチプッシュを許可するclaude/プレフィックス制限を切ると、Routineが本番ブランチへ直接pushできる
  2. 不要なConnectorsを残したまま走らせる:書き込み権限が広いConnectorほど事故の影響が大きい
  3. textにJSONを期待する:APIトリガーのtextは文字列扱い。構造化パースは行われない
  4. GitHubトリガーでpull_request全アクションを購読する:synchronizeを含めると、push毎にRoutineが走り、レート制限を消費する
  5. 本番秘密を環境変数として渡す:環境を編集できる全員が見える前提で扱う(専用シークレットストアは未提供)

Routines運用前チェックリスト

  • 対応プラン(Pro/Max/Team/Enterprise)にいるか確認した
  • Claude Code on the webが有効か、ZDR組織でないか確認した
  • プロンプトを自己完結で書き、成功条件を明示した
  • リポジトリは必要なものだけ選び、claude/プレフィックス制限を維持した
  • Connectorsから不要なものを外した
  • 環境のネットワークアクセス/環境変数/setup scriptを点検した
  • GitHubトリガーは特定アクション+フィルタに絞った
  • APIトークンはシークレットストアに保管し、誰でも見られる場所に置かない
  • 日次Routine実行キャップを把握し、並列起動時のレート消費を見積もった
  • 組織管理者向けのRoutines無効化トグルの方針を決めた

次に読むおすすめ記事: