Claude Code Routines を見て、「これで毎朝の棚卸しや PR レビューを放っておけるのでは」と考えた人は多いはずです。ただ、Routines は便利な反面、/loop や Auto-Fix よりも事故時の半径が広いです。実行中に承認プロンプトを挟まない cloud session として動くため、どの repository、connector、network、branch push を許すかを先に決めないと、無人実行のつもりが無人変更になります。
この記事では、Claude Code Routines を cloud 側の unattended run として扱い、どの仕事を載せるべきか、何を載せるべきではないかを整理します。Claude Code の導入順を先に押さえたい場合は Claude Code の使い方 実践ガイド、セッション内の短期追跡は Claude Code /loop 完全ガイド、PR 単位の CI 修正は Claude Code Auto-Fix 実践ガイド、review queue を GitHub 側でどう受けるかは Codex code review in GitHub 実践ガイド、組織ルールの土台は AIコーディングツールの社内ガイドライン、承認境界と監査証跡は AIエージェント承認フロー設計ガイド と AIエージェント監査ログ設計ガイド に分けています。今回はその次に来る「定義しておけば勝手に走る仕事」の設計に絞ります。
先に結論: Routines は「独立して終われる反復作業」だけに使う
Routines に向いているのは、次の 4 条件を満たす仕事です。
- 入力が毎回ほぼ同じ
- 成功条件を prompt に書ける
- 出力を PR、コメント、レポートのようにレビューできる
- 失敗しても本番状態を直接壊さない
逆に、次の仕事は最初から載せない方がいいです。
- 本番データを直接変更する作業
- deploy の go / no-go を人間確認なしで決める作業
- 広い connector 権限がないと成立しない作業
- 仕様判断、設計判断、組織判断が毎回変わる作業
- 失敗時に差し戻し先が分からない作業
この線引きは地味ですが重要です。Routines は研究 preview の機能であり、公式 docs でも behavior、limits、API surface が変わる可能性があるとされています。つまり、今は「便利だから全面移行」ではなく、レビュー可能な反復作業を小さく切り出す段階です。
Routines は何を保存して、どこで動くのか
Routines は、prompt、1 つ以上の repository、connector、environment、trigger をまとめた Claude Code の実行設定です。保存した routine は Anthropic 管理の cloud infrastructure 上で実行されます。つまり、ノート PC を閉じても動き続けます。
ここが /loop との一番大きな違いです。
| 仕組み | 主な用途 | 実行場所 | 安全境界 |
|---|---|---|---|
/loop | 今の session の短期追跡 | 開いている session | 会話文脈と短い間隔 |
| Auto-Fix | PR の CI 失敗やコメント対応 | Claude Code の PR 運用 | PR 単位の差分レビュー |
| Routines | schedule / API / GitHub event での無人実行 | cloud session | repository / connector / environment / branch push |
| GitHub Actions | CI/CD 内の自動処理 | GitHub runner | workflow permissions と secrets |
私はこの 4 つを混ぜません。CI が落ちた PR を直すなら Auto-Fix。今のレビュー待ちを 10 分おきに追うなら /loop。毎朝 backlog を棚卸しするなら Routines。CI/CD の一部として deterministic に走らせるなら GitHub Actions。この分け方にすると、権限設計も prompt も短くなります。
3 種類の trigger をどう使い分けるか
Routines には大きく 3 種類の trigger があります。
1. Schedule trigger
毎時、毎日、平日、毎週のような cadence で routine を走らせる trigger です。1 回だけ未来の時刻に実行する one-off schedule もあります。
向いている用途:
- 毎朝の issue / PR 棚卸し
- 週次の docs drift 確認
- 毎週の dependency update 候補の洗い出し
- 月次の unused flag / stale branch 調査
このタイプは「最後の実行以降に増えたものを見る」仕事と相性がいいです。逆に、1 時間未満の細かい監視やリアルタイム性が必要な alert handling には向きません。公式 docs でも schedule の最小間隔は 1 時間で、実行開始は数分ずれる可能性があります。
2. API trigger
routine 専用の endpoint に bearer token 付きで HTTP POST すると、新しい session が起動します。request body には自由形式の text を渡せます。monitoring tool、deploy pipeline、社内 tool から呼び出す用途です。
向いている用途:
- Sentry や Datadog の alert から調査 PR を下書きする
- deploy 後に smoke check の結果を読ませる
- 社内 dashboard から「この顧客の失敗ログを要約して」と投げる
ここで気をつけるべきなのは、API trigger token を「万能な Claude 起動 token」として扱わないことです。token は routine ごとに分け、呼び出し元も絞ります。alert 本文に含まれる外部入力をそのまま実行指示として扱わない、という前提も必要です。
3. GitHub trigger
pull request や release などの GitHub event に反応して routine を起動します。PR title、base branch、draft 状態、label などで filter できます。
向いている用途:
pull_request.openedでチーム固有の review checklist を適用するrelease.publishedで docs / changelog drift を確認するpull_request.closedかつ merged のときに別 repository へ変更を port する
GitHub trigger は便利ですが、PR update ごとに独立した session が起きる点に注意します。前回 session の文脈を引き継ぐ前提で prompt を書くと失敗します。毎回、対象 PR、見る範囲、コメント方針、差分を作る条件まで prompt 側に閉じ込めるべきです。
実務で最初に作るなら「review queue routine」がよい
私が最初に作るなら、いきなり修正 PR を出す routine ではなく、review queue を整える routine から始めます。このサイト運用でも、記事作成や SEO 改善は毎回 branch / worktree / build / PR まで進めますが、完全な自動 merge はしていません。最後に見るべき差分を小さくすることが目的です。
たとえば、毎朝 9 時に走る routine の prompt はこのくらいで十分です。
Review open pull requests in the repository.
Goal:
- Identify PRs that are ready for human review.
- Identify PRs blocked by merge conflicts, failing build, or duplicate content intent.
- Do not push changes unless explicitly requested by the routine owner.
Steps:
1. List open PRs.
2. For blog article PRs, check title, changed files, build status, and overlap with existing articles.
3. Leave a short summary comment only when there is a concrete blocker.
4. Produce a final queue with: ready, blocked, stale, duplicate-risk.
Success:
- No direct merge.
- No production deploy.
- No broad rewrite.
- Every blocker includes a specific file, PR, or command result.この設計なら、routine が間違えても被害は小さいです。PR を勝手に書き換えず、review queue を整えるだけだからです。ここで安定してから、label 付与、docs drift PR、軽微な修正 PR へ広げます。
権限設計は prompt より先に決める
Routines で一番危ないのは、prompt を丁寧に書けば安全だと思うことです。prompt は必要ですが、最終的な境界は repository、branch push、connector、environment で決まります。
Repository は最小にする
routine には 1 つ以上の repository を紐づけられます。最初は 1 repository だけにします。複数 repository をまたぐ routine は便利ですが、失敗時にどこで何が起きたか追いにくくなります。
Branch push は claude/ prefix から始める
公式 docs では、routine は初期状態では claude/ prefix の branch にだけ push できます。既存 branch へ直接 push したい場合は unrestricted branch push を許可できますが、最初は使わない方がいいです。
既存 branch へ push できる routine は、実質的に unattended committer です。main への直接 push を許さないのは当然として、feature branch でも人間が作業中の branch を壊す可能性があります。
Connector は「全部入り」を消す
routine 作成時、接続済み connector が既定で含まれる場合があります。ここは必ず削ります。Slack、Linear、GitHub、Notion、Sentry などを全部渡すと、routine は読めるだけでなく書ける tool も持ちます。
私なら、最初の routine は次のようにします。
| 用途 | connector |
|---|---|
| PR review queue | GitHub read + comment まで |
| alert triage | monitoring read + GitHub draft PR まで |
| docs drift | GitHub read/write は docs repository の branch だけ |
| backlog grooming | issue tracker read/write は label と owner 付与まで |
「便利そうだから Slack も足す」は後回しです。通知先を増やすほど、失敗時の後始末が増えます。
Network access は default のまま始める
routine は cloud environment の network policy を継承します。Default environment は trusted network access で、一般的な package registry や cloud provider API などは許可されますが、任意 domain は許可されません。
独自 API や社内 service へ出たい場合だけ custom allowed domains を足します。Full access は、最初の選択肢にしない方がいいです。特に alert 本文、issue 本文、PR 本文のような未信頼入力を読む routine では、外部送信先を狭くしておく価値があります。
失敗しやすい routine の特徴
Routines は「無人で動く」こと自体が価値ですが、失敗する routine には共通点があります。
成功条件が曖昧
「いい感じに PR をレビューして」では広すぎます。次のように、出力形式と終了条件を固定します。
ready / blocked / stale / duplicate-riskに分類する- 変更を加える場合は draft PR だけ作る
- merge、deploy、release publish はしない
- 失敗した command と exit code を final summary に残す
書き込み権限が広すぎる
読める connector と書ける connector を分けない routine は危険です。たとえば、外部 issue を読み、GitHub に write し、Slack に投稿し、deploy API に触れる routine は、prompt injection を受けたときの被害が広すぎます。
人間レビューに戻らない
routine の run status が green でも、task が成功したとは限りません。公式 docs でも、green は infrastructure error なしで session が開始・終了したという意味であり、prompt の目的達成を保証しないと説明されています。run transcript、差分、コメント、PR を人間が確認する前提を残すべきです。
小さく始める導入手順
私なら、次の順で導入します。
1. Report-only routine を作る
最初はコメントも PR 作成もさせません。open PR、stale issue、docs drift 候補を調べ、final summary だけ返す routine にします。
2. Comment-only に広げる
summary の精度が安定したら、具体的な blocker がある場合だけ PR コメントを残します。ここでも code push は許しません。
3. Draft PR だけ許す
docs drift、typo、release note のように rollback しやすい作業だけ draft PR 作成を許します。branch は claude/ prefix のままにします。
4. Connector と network を 1 つずつ足す
必要になった connector だけ追加します。network も domain allowlist を 1 つずつ足します。追加するたびに、routine prompt ではなく権限表を更新します。
5. Audit trail を残す
routine ごとに次の情報を残します。
- routine name
- owner
- trigger
- repositories
- connectors
- network policy
- branch push policy
- できること / してはいけないこと
- last review date
組織で使うなら、これは社内ガイドラインの例外申請や棚卸しと同じ扱いにした方がいいです。
まとめ: Routines は automation ではなく「権限付きの作業者」として扱う
Claude Code Routines は、schedule、API、GitHub event をきっかけに cloud 側で Claude Code を走らせる強力な仕組みです。ただし、強力だからこそ、prompt より先に権限境界を決める必要があります。
私なら、次の順で使います。
/loopは短期追跡- Auto-Fix は PR 単位の CI / comment 修正
- Routines は cloud 側の反復作業
- GitHub Actions は CI/CD 内の deterministic な処理
最初の routine は、report-only か comment-only にしてください。repository は 1 つ、branch push は claude/ prefix、connector は最小、network は default。ここから外れるほど、無人化ではなく権限委譲になります。Routines を安全に使うコツは、何を自動化するかより、何を絶対にさせないかを先に決めることです。