Claude Code Routines完全解説｜Claudeが自分でClaude Codeを起動する非同期自動化

Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。

2026年4月に研究プレビューとしてリリースされ、5月6日のCode with Claude SFでBoris Cherny自身がデモした Routines（ルーチン） は、Claude Codeの使われ方そのものを書き換える機能だ。Borisはステージでこう宣言している。

“The default isn’t ‘I’m going to prompt Claude Code’. The default is now ‘I will have Claude prompt Claude Code’.”

訳すと「これからのデフォルトは『自分がClaude Codeにプロンプトを打つ』ではなく『Claudeに自分のClaude Codeを動かしてもらう』に変わる」。Routinesはこの「Claudeが自分自身に対するプロンプトを書く」というhigher-order prompt（高階プロンプト）を実装したプリミティブだ。本記事では公式ドキュメント（code.claude.com/docs/en/routines）と公式ブログ（claude.com/blog/introducing-routines-in-claude-code）を一次ソースに、仕組み・設定・運用上の制約までを2026年5月時点の最新仕様で解説する。

Routinesとは：Claudeが自分でClaude Codeを起動する「保存済み構成」

公式ドキュメントの定義はシンプルだ。

“A routine is a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically.”

つまりRoutineは「プロンプト + 1つ以上のリポジトリ + 連携先（connectors）の集合」を1セットにして保存し、トリガー条件で自動的に走らせる仕組みだ。実行はAnthropicが管理するクラウドインフラ上で行われる。公式ブログによれば「Routines run on Claude Code’s web infrastructure, so nothing depends on your laptop being open」——ローカルマシンを閉じても止まらない。

higher-order promptという比喩

Boris Chernyが何度も使った比喩が「higher-order prompt（高階プロンプト）」だ。プログラミングでhigher-order functionといえば「関数を引数に取る・関数を返す関数」を指す。これに倣えば、Routineは「プロンプトを引数に取り、Claude Codeの起動という結果を返す、メタなプロンプト」だと言える。

実用的な含意は、開発者の作業対象が変わるという点だ。Bristolが「最近の自分のコードのほとんどはRoutineが書いている。プロンプトを打つのは自分じゃない、プロンプトを打つRoutineを自分が作っている」と語った通り、エンジニアがClaude Codeを直接動かす機会は確実に減っていく。Claude Codeのプロンプトテンプレートそのものをエンジニアリングの対象にする時代が来た、ということだ。

研究プレビュー段階という重要な前置き

公式ドキュメントには明確な注意書きがある。

“Routines are in research preview. Behavior, limits, and the API surface may change.”

この注意書きはAPIヘッダーにも反映されている。後述する /fire エンドポイントは anthropic-beta: experimental-cc-routine-2026-04-01 というデートスタンプ付きベータヘッダーで配信され、破壊的変更があった場合は新しい日付のヘッダーが追加される（直近2バージョン分の互換性は維持）。本番ワークフローに組み込む際は、この点を踏まえてヘッダー値を変数化しておくのが安全だ。

3つのトリガータイプ：schedule・API・GitHub event

Routinesの中核は3種類のトリガーだ。公式ドキュメントの記述をそのまま引用する。

“Scheduled: run on a recurring cadence like hourly, nightly, or weekly, or once at a specific future time” “API: trigger on demand by sending an HTTP POST to a per-routine endpoint with a bearer token” “GitHub: run automatically in response to repository events such as pull requests or releases”

そして「A single routine can combine triggers」と明記されている。例えば「毎晩動く + デプロイスクリプトから叩ける + 新規PRすべてに反応する」——3つのトリガーを1つのRoutineに同居させ、同じプロンプトと同じ環境を共有させられる。

各トリガーの違いを表で整理

最小実行間隔は1時間で、それ以下のcron式は拒否される。1時間より短い間隔で動かしたい用途（5分ごとのヘルスチェック等）はGitHub Actions側で組むか、APIトリガーを外部cronから叩くのが定石だ。

Schedule triggerの自然言語入力

CLIから作成する場合は /schedule コマンドに自然言語で時刻を渡せる。

/schedule daily PR review at 9am
/schedule clean up feature flag in one week
/schedule tomorrow at 9am, summarize yesterday's merged PRs
/schedule in 2 weeks, open a cleanup PR that removes the feature flag

時刻はローカルタイムゾーンで入力し、内部でUTCに変換される。「いつ・何を・どの粒度で」が自然言語1行で確定するUXは、cronとは別物のシンプルさだ。なお、One-off（一度だけ）の実行は日次上限のカウント対象外（subscription usageは普通に消費）という重要な例外がある。

Custom cronはCLIで上書き

Webフォームには「hourly / daily / weekdays / weekly」のプリセットしかないが、/schedule update をCLIで叩けば任意のcron式を設定できる。「毎月1日」「平日の9時と17時」のような複合パターンはここで指定する。

CI AutoFix：「PRオーナーがもう赤いXを見ない」仕組み

Code with Claude SFでBorisが見せたデモのハイライトがCI AutoFixだ。彼の発言を引用する。

“CI flaked on the network timeout. The routine woke up, it diagnosed it as a known infra issue. It retried the job and now it’s green.”

「CIがネットワークタイムアウトでflakeした。Routineが起き上がって既知のインフラ問題と診断し、ジョブをリトライした。これでgreenだ」。さらにAnthropic社内のCloud Codeリポジトリでは、単なるリトライではなく「root cause毎回直す」設定になっており、PRオーナーは「もう赤いX（CI失敗）を見ることがない」とのことだ。

CI AutoFixを構成する4要素

「CI AutoFix」は単独の機能名ではなく、Routinesの構成要素を組み合わせて実現される。

graph TD
    A[PR opened/synced] -->|GitHub trigger| B[Routine fires]
    B --> C{CI status check}
    C -->|失敗| D[ログ取得・診断]
    D --> E[修正コミット to claude/branch]
    E -->|push| F[CI再実行]
    F -->|green| G[mergeable]
    C -->|review comment| H[コメント解析]
    H --> I[該当箇所を修正]
    I --> E

要素は4つだ。

1. GitHubトリガー — pull_request.opened や pull_request.synchronize でRoutineを発火させる
2. Connectors — GitHub PR API、CI（GitHub Actions等）、必要ならSlack通知のためのconnector接続
3. claude/プレフィックスブランチ — 修正コミットを安全にpushする受け皿
4. 自動承認の前提 — Routineは「permission-mode picker」も「approval prompt」もないクラウドセッションで走る（=ユーザーの手介入は走行中ゼロ）

公式ドキュメントの記述

公式が述べる安全性の前提は明確だ。

“Routines run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run.”

つまりRoutineが走り出したら、Claudeはshell・skills・connectorsを止めずに使い切る。これを安全に成立させているのが次節のブランチ制限だ。

作成方法：Web・CLI・Desktopの3経路 + curl実例

Routineは3つの経路で作成でき、いずれも同一のクラウドアカウントに保存される。1箇所で作成すれば他の経路でも即座に出てくる。

経路別の特徴

CLIだけで完結したい場合は、まず /schedule でscheduleトリガー付きRoutineを作り、その後Webで開いてAPI/GitHubトリガーを追加するのが現実的なフローだ。

CLIから1行で作成

# 毎朝9時にPRレビュー
/schedule daily PR review at 9am

# 一覧
/schedule list

# 編集（cron式上書き等）
/schedule update

# 即時実行
/schedule run

APIトリガーをcurlで叩く

公式ドキュメントの完全な例をそのまま引用する。

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を返す。

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

text フィールドは自由記述のテキストで、JSONを渡しても構造化はされず文字列としてプロンプトに連結される。アラート本文・スタックトレース・直近ログ等を素のまま貼ればよい。

Pythonクライアントの最小実装

import os
import requests

ROUTINE_TRIGGER_ID = "trig_01ABCDEFGHJKLMNOPQRSTUVW"
TOKEN = os.environ["CLAUDE_ROUTINE_TOKEN"]

def fire_routine(alert_body: str) -> dict:
    url = f"https://api.anthropic.com/v1/claude_code/routines/{ROUTINE_TRIGGER_ID}/fire"
    r = requests.post(
        url,
        headers={
            "Authorization": f"Bearer {TOKEN}",
            "anthropic-beta": "experimental-cc-routine-2026-04-01",
            "anthropic-version": "2023-06-01",
            "Content-Type": "application/json",
        },
        json={"text": alert_body},
        timeout=10,
    )
    r.raise_for_status()
    return r.json()

# 例: PagerDutyのwebhook受信時に呼ぶ
result = fire_routine("PD incident #4521: latency p99 > 2s on /checkout")
print(result["claude_code_session_url"])

トークンはRoutine作成時に1度だけ表示される（Webの「Generate token」モーダルで Regenerate / Revoke 可能）。Vault・GitHub Actions Secrets・各種monitoring tool secret store等に保管しよう。

GitHub eventトリガーとフィルタ設計

GitHubトリガーが受け付けるイベントは2カテゴリだ。

各イベント発火ごとに新規セッションが作られる。同一PRに2回push（synchronize）が来れば、独立した2セッションが起動する。

PRフィルタの全フィールド

PRトリガーには以下のフィルタフィールドが用意されている。各フィールドは equals / contains / starts with / is one of / is not one of / matches regex のいずれかの演算子と組み合わせる。

公式が示す典型例3つを訳出する。

• Auth module review: base = main かつ head contains auth-provider → 認証関連PRだけ専用レビュアーRoutineに送る
• Ready-for-review only: is draft = false → ドラフトの間はRoutineを動かさない
• Label-gated backport: labels contains needs-backport → メンテナがラベルを付けた瞬間だけポートRoutineが走る

GitHub App必須

GitHubトリガーを設定するには Claude GitHub App をリポジトリにインストールする必要がある。CLIの /web-setup はクローン用のリポジトリアクセスを付与するだけで、webhookは流れてこない。トリガー設定画面が「アプリ未インストール」を検知すると案内が出る。

安全性・ブランチ制限・connector権限スコープ

Routineは「permission-mode picker無し・approval prompt無し」で走るため、スコープ設計が安全性のすべてと言ってよい。公式が用意した3つのレバーがある。

1. claude/プレフィックスブランチ強制

公式ドキュメントから直接引用する。

“By default, Claude can only push to branches prefixed with claude/. This prevents routines from accidentally modifying protected or long-lived branches.”

つまりデフォルトでは、Routineがmain や release 等の保護ブランチに直接pushすることは不可能だ。修正は必ず claude/fix-ci-flake-20260507 のような名前空間に閉じ込められる。

例外を許可したい場合は 「Allow unrestricted branch pushes」 をリポジトリ単位で有効化する必要がある。CI AutoFixで「PRブランチ自体をfast-forwardしたい」場合などはこの解除が必要になるが、解除する範囲は最小化すべきだ。

2. Connectorsの個別除外

Routineは作成時、ユーザーが接続済みの全MCP connectorsをデフォルトで含める。Slack・Linear・Google Drive・Jira等を全部繋いでいる人は要注意だ。

“Claude can use every tool from an included connector, including writes, without asking for permission during a run.”

Routineが必要としないconnectorは作成フォームで明示的に外しておく。例えば「PRレビューRoutine」がLinearやSlackを書き込む必要がないなら、それらは外してGitHubのみに絞る。

3. Environmentのネットワーク・環境変数スコープ

Cloud environmentでは、ネットワークアクセスの許可レベル・環境変数（APIキー）・セットアップスクリプトを制御できる。本番DBの認証情報をdefault environmentに入れるのではなく、Routine用に最小権限のenvironmentを別建てする運用が望ましい。

個人アカウントに紐付くという事実

公式ドキュメントの一節は強調しておく価値がある。

“Routines belong to your individual claude.ai account. They are not shared with teammates… commits and pull requests carry your GitHub user, and Slack messages, Linear tickets, or other connector actions use your linked accounts for those services.”

Routineが行うすべての行動は作成者本人として記録される。退職・異動・アカウント停止時のオフボーディング手順に必ず「Routinesの停止/移管」を入れる必要がある。

プラン別日次上限と /loop ・ Desktop scheduled tasks との違い

Routinesはsubscriptionの通常使用量に加えて、独自の日次実行回数上限を持つ。

上限到達後は新規実行が拒否されるが、Settings > Billing で extra usage を有効化していれば metered overage で継続可能。One-off scheduleはこの日次上限のカウント対象外で、subscription usageだけ消費する点はもう一度強調しておきたい。

似た仕組みとの違い

Anthropicは「定期実行」「自動化」を冠する仕組みをいくつか持っている。混同を避けるために整理しておく。

/loop は同じセッションのコンテキストを持ち越せる代わりに、Claude Codeを開いている間しか動かない。Desktop scheduled tasksはローカルファイルに触れる代わりに、ローカルマシンが起きている必要がある。Routinesは「リポジトリ・connectors中心の長期自動化」専用であり、3つを使い分けるのが正解だ。

実用ユースケース8選

公式ドキュメントが挙げる例＋現実的に効きそうな組合せを8つ整理した。すべて「unattended（人介在なし）・repeatable（繰り返し）・tied to a clear outcome（明確な完了条件あり）」という公式の推奨基準を満たす。

1. バックログ整理（Schedule） — 平日夜次にissue trackerを連携。前回実行以降のissueにラベル付け・担当者割当・Slackサマリ投稿。チームは朝、整理済みのキューから始められる。
2. アラートトリアージ（API） — Sentry/Datadog/PagerDutyのwebhookから /fire を叩く。Routineはスタックトレースと直近コミットを突き合わせ、修正案PRを下書きで開く。On-callはブランクターミナルから始めずに済む。
3. PR独自レビュー（GitHub event） — pull_request.opened で発火。チーム独自のレビューチェックリスト（セキュリティ・パフォーマンス・スタイル）を適用してインラインコメント。人間レビュアーは設計判断に集中できる。
4. デプロイ検証（API） — CDパイプラインがデプロイ完了後に /fire 叩く。スモークテスト・エラーログ検査・goサイン投稿をリリース時間内に終わらせる。
5. ドキュメントドリフト検知（Schedule） — 週1で前週のマージ済みPRをスキャン。変更APIを参照しているドキュメントを検出し、ドキュメントリポジトリにPRを開く。
6. SDK間ポート（GitHub event） — pull_request.closed かつ is merged = true で発火。一方のSDKのマージ済み変更をもう一方のSDKに自動移植して並行PRを開く。
7. CI AutoFix（GitHub event + Schedule） — pull_request.synchronize 発火 + 1時間ごとのpolling schedule。CI失敗・レビューコメント・merge conflictを順次修復。
8. Feature flag掃除（One-off） — /schedule in 2 weeks, open a cleanup PR that removes the feature flag のように、ロールアウト完了予定日に1回だけ走るRoutineを作る。日次上限を消費しないのが利点。

利用条件・対応プラン（2026年5月時点）

「Routinesは結局どのプランで使えるのか」「Pro契約だけで自動化できるのか、Enterpriseが必要なのか」は読者から最もよく聞かれる質問だ。Routinesと、それと混同されがちな関連機能（Code Review・GitHub Actions・Security Review）の対応プランを公式ドキュメントベースで一表に整理した。

Routinesの利用条件詳細

公式ドキュメントの一節をそのまま訳すと「Routines are available on Pro, Max, Team, and Enterprise plans with Claude Code on the web enabled」——Pro以上のサブスクリプションで使える。Free/無料アカウントは対象外だ。

• Pro（月額$20）: 5回/日。個人開発者の試用に十分
• Max（月額$100/$200）: 15回/日。本格的に複数Routineを回すならここから
• Team / Enterprise: 25回/日 + 管理者向けの組織管理機能

One-off scheduleはこのカウントから除外される点は前述の通り。日次上限到達後は Settings > Billing で「extra usage」を有効化すれば metered overage で継続できる。

Code Reviewは「Team / Enterprise限定」が要注意

PR本文・差分を多エージェントで分析しインラインコメントを残すCode Review（managed GitHub App service）は、Pro/Maxプランでは利用不可だ。公式ドキュメントの注記を引用する。

“Code Review is in research preview, available for Team and Enterprise subscriptions. It is not available for organizations with Zero Data Retention enabled.”

つまり個人のPro/Max契約では、Code Reviewのmanagedサービスは使えない。Pro/Max利用者がPRレビュー自動化をしたい場合は次の3つの代替手段がある。

1. Routines + GitHub event trigger — pull_request.opened で発火するRoutineを作り、レビュー指示をプロンプトに書く
2. anthropics/claude-code-action@v1 — GitHub Actionsで自前のCI上で動かす（ANTHROPIC_API_KEY をリポジトリシークレットに設定）
3. @claude review コメントトリガー（Code Review導入後） — Team/Enterpriseに上げるのが最短だが組織契約が必要

CI AutoFixは独立プロダクトではない

「CI AutoFix」という名のスタンドアローン製品は存在しない。Code with Claude SFのデモで見せた「PRが赤いXを見ない」状態は、次のいずれかの組合せで実現される。

• Routines（GitHub trigger） + claude/プレフィックスブランチ + connector — Pro/Max以上で実装可能
• GitHub Actions（claude-code-action） — API課金で全プラン対応
• Code Review（managed） — Team/Enterpriseのみ、CI AutoFixというよりPRレビューに特化

つまり「Pro契約でもCI失敗自動修正は実装できる（=Routinesで作れる）」というのが正解だ。Anthropic社内のCloud Codeリポでの運用は、この「Routines + GitHub trigger + connector」の組合せだと推測される。

Security Reviewは2系統あるので混同注意

「Security Review」と呼ばれる機能は実は2つ別物ある。

どちらもCode Reviewのmanaged GitHub Appサービスとは別物で、Pro/Maxユーザーでも使える。CLI内で /security-review を叩けばその場でセッションが立ち上がるし、GitHub Actions版はリポジトリにworkflow YAMLを置けば動く。「セキュリティレビューだけはmanagedサービス必須？」と誤解しがちだが、実際はどちらもPro/Maxで運用可能だ。

結論：プランごとの推奨運用

• Pro（個人開発）: Routines 5回/日 + /security-reviewスラッシュコマンドで十分。CI AutoFixはGitHub Actions版で代替
• Max（個人ヘビー）: Routines 15回/日でPRレビュー・バックログ整理を全自動化。Code Reviewは使えないのでGitHub Actions併用
• Team: Routines 25回/日 + Code Reviewが両方使える。CI AutoFixはRoutines、PRレビューはCode Reviewと役割分担
• Enterprise: 上記に加え組織管理・spend cap・analyticsダッシュボード。ZDRを有効化するとCode Reviewが使えなくなる点だけ注意

まとめ

Code with Claude SFでBoris Chernyが宣言した 「The default is now I will have Claude prompt Claude Code」 という未来は、Routinesという形で2026年4月にすでに研究プレビュー出荷済みだった。5月の基調講演はそれを「これがNew Default だ」と再定義したイベントだったといえる。Anthropic社内のCloud Codeリポジトリで「PRオーナーがもう赤いXを見ない」状態が現実だとすれば、それを再現する手順はこの記事ですべて公開された。あとは1つ目のRoutineを作るだけだ。

最初のRoutineには「毎朝9時、昨日マージされたPRをサマリしてSlackに投稿」あたりが最適——失敗してもダメージがなく、connector・schedule・cloud environmentすべてを一度に試せる。

参照ソース

• Anthropic公式ドキュメント — Automate work with routines
• Anthropic公式ブログ — Introducing routines in Claude Code
• Anthropic公式ブログ — Preview, review, and merge with Claude Code
• Simon Willison ライブブログ — Live blog: Code w/ Claude 2026
• Code with Claude San Francisco — claude.com/code-with-claude/san-francisco
• Claude Code GitHub — github.com/anthropics/claude-code