Anthropicが先月公開した Claude Code Routines を3週間ローテーションに組み込んだ結果、「夜中もMacを開けっぱなしにしないと回らないジョブ」の運用負荷が明確に下がった。本稿では Routines の実体、トリガ3種類の使い分け、ローカル拘束の解消効果、そして実際に効いた運用パターンを実機ベースで整理する。
Routinesは「Claude Codeの設定を冷凍保存する仕組み」だった
機能名だけ聞くと「cron + AI」に近い印象を受けるが、触ってみるとやや毛色が違う。Routines の実体は、プロンプト、対象リポジトリ、コネクタ、環境変数、セットアップスクリプトをまとめてパッケージ化し、クラウド側に保存しておくものだ。トリガが発火するとその冷凍されたワーキングセットを解凍してClaude Code相当の環境で走らせる、というイメージが一番近い。
トリガは3種類用意されている。スケジュール（毎日・毎週・指定時刻）、API（per-routine のHTTPエンドポイントと Bearer トークンを発行）、GitHubイベント（PR、リリース、issue 等）の3つだ。これらは同じRoutineに併走させられる。筆者は「毎晩2時のスケジュール + main 向けPR時のGitHubトリガ」を1本に束ねている。
最初の3週間で組んだ3本のRoutineと、それぞれの粒度
1本目は社内ドキュメントの「リンク切れ巡回 + 自動PR起こし」で、週1で十分なので毎週日曜23:00 のスケジュールに置いた。Routine が対象 docs リポジトリを取りに行き、セットアップスクリプトでリンクチェッカーを入れ、修正案を別ブランチでPRに上げる。レビューは月曜の朝に回す前提だ。
2本目は、過去24時間分のissueに対する「初動レスポンス草案」を毎朝7:15に走らせるもの。Claude側で内容を読み、ラベル候補と担当候補を提案するコメントを下書きする。トリアージにかかっていた朝の25〜30分が、6〜8分に縮んだ実感がある。完璧ではないが、初動の壁を下げる効果は十分にある。
3本目は API トリガで「営業からの問い合わせを Slack から叩く」用途。Slack のスラッシュコマンドから Routine の per-endpoint を POST する形にした。非エンジニアが触る前提なので、Bearer トークンの取り扱いをかなり慎重に作り込んでいる。
ローカル拘束時間が週あたり9.5時間減った
数字で言うと、Mac をスリープにしておけない時間が週あたり9.5時間ほど減った。夜にスケジュール起動していた既存ジョブをすべて Routines に寄せたためだ。Anthropic 管理のクラウド上で動くため、ローカルが落ちていても淡々と走る。週1のドキュメント巡回が、筆者不在の週末でも普通に動き、月曜朝にPRが4件積まれていたとき、ようやく「これは本当にクラウドで動いている」と腑に落ちた。
副作用として大きかったのは、手元の Claude Code セッションの体感が静かになったことだ。これまでは「夜間に走るやつ用のターミナル」を1枚常時開いていた。これが要らなくなった結果、デスク上の認知負荷が想像以上に下がった。
効いた使い方は「PRトリガ + 短時間プロンプト」の組み合わせ
GitHub トリガで一番手応えがあったのは、PRに area:db ラベルが付いた瞬間にだけ走る、超短い Routine だ。プロンプトは40字程度しかない。中身は「対象PRの SQL を読み、migration up/down が対称になっているかだけ、3点以内で指摘して」というもので、これ以上のことはやらせない設計にしている。
ポイントは「広い権限を持った Routine を1本太く作る」より「やることを絞った短い Routine を複数並べる」ほうが、デバッグもアクセス権限のレビューも楽だということだ。一つで何でもやる構造はメンテで詰みやすく、Routines は分割運用と相性が良い。
トークン取り扱いとセットアップスクリプトの設計
API トリガで発行される Bearer トークンは初回しか表示されない仕様なので、シークレットマネージャに即座に格納するフローを最初から組んでおく必要がある。筆者は1本作るたびに「トークン即退避」のチェックリストを横に貼って運用している。
セットアップスクリプトの作り込みも地味に効く。Routine はトリガごとに毎回まっさらな環境で動くため、依存のインストールに30秒余計にかかると、その分待ち時間が積み上がっていく。筆者の3本は、平均で17秒のセットアップ時間に収まるよう、不要なパッケージを削り込んだ。毎時間走るRoutineではここの差が顕著に出る。「クラウドだから何でも入れていい」と最初は思っていたが、実運用では真逆に振れた格好だ。
まとめ — 「型が決まっている作業」を外出しする道具として最初の選択肢に
Routines は派手な機能ではない。むしろ「PCを閉じても回る」「設定が1ファイルとして冷凍される」「権限がトリガ単位で切れる」という3点が刺さるタイプの機能だ。逆に、対話的に試行錯誤するタイプの作業には向かない。あくまで「型が決まっている作業」を Claude Code から外出しする道具と捉えるのが現実的だろう。
これまで n8n や GitHub Actions の中に押し込んでいた「AIに任せる気味の悪い部分」を、Routines 側に引き上げる流れは今後数ヶ月で広がる可能性が高い。ワークフロー全体を覆うのではなく、Actions の1ステップを Routine の API endpoint に置き換えていくほうが、移行コストも低く済む。
