routines は、Claude Codeに「決まった仕事」を自動でやらせる仕組みAnthropic の Claude Code Docs に追加された routines は、ひとことで言うと Claude Codeを自動実行する仕組み です。
これまでもAIに「このPR見て」「このログ調べて」と頼むことはできました。でも routines は一歩進んでいて、
あらかじめ役割・対象リポジトリ・接続先・実行条件を決めておき、必要なタイミングで勝手に動く のがポイントです。
しかも実行場所は Anthropic 管理の cloud infrastructure。
つまり、ノートPCを閉じても、Claudeが裏で働き続ける わけです。これ、地味にすごいです。というか、かなり“AIエージェントが業務システムに入り込んでくる未来”っぽさがあります。
ただし、まだ research preview。
ここは大事で、便利そうだから即本番全面導入 というよりは、まずは限定的な用途で試すのが現実的だと思います。
routines は何を保存しているのかroutine は、単なる「定期実行ジョブ」ではありません。
ドキュメントでは、次の要素をひとまとまりにしたものとして説明されています。
つまり、「何をするか」だけでなく、「どこで」「何とつながって」「いつ動くか」まで含めた保存済みClaude Code設定 です。
個人的には、この設計がかなりうまいと思いました。
普通の自動化ツールは「起動条件」は作れても、実際の思考や判断を入れ込むのが難しい。でも Claude Code の routines は、AIに渡す指示文そのものが中核なので、人がやっていた判断作業をかなり自然に置き換えやすい んですよね。
routines には、3種類の trigger を付けられます。
定期実行です。たとえば:
定期的に「昨日のPRをまとめてレビュー」「今朝のissueを整理」みたいな仕事に向いています。
HTTP POST を送ると動くタイプです。
つまり、外部システムが「今すぐこのルーチンを走らせて」と呼び出せるわけです。
たとえば監視ツールがエラーを検知したら、その内容を渡して Claude を起動し、原因調査や修正案のPR作成までやらせる、という使い方が想定されています。
GitHub のイベントに反応して動きます。
PR が開かれた、閉じられた、release が出た、みたいなイベントに連動できます。
これはかなり実用的です。
人が毎回チェックしなくても、「PRが来たらレビュー」「マージされたら別SDKに移植」 のような仕事を自動で回せます。
しかも、1つの routine に複数の trigger を組み合わせられます。
たとえば「毎晩回る」し「新しいPRでも動く」し「デプロイスクリプトからも呼べる」みたいな構成が可能です。
この柔軟さは、かなり本気の運用設計向けだと思います。
ドキュメントには、かなり現実的な use case が載っています。ここが面白いです。単なるデモではなく、**“人間が毎回やるには少し面倒だけど、毎回必要な仕事”** を狙っているのがよくわかります。
毎晩 issue tracker を見に行って、新しい issue に label を付け、担当者を割り当て、Slack に要約を投げる。
こういう仕事、やってみるとわかりますが、別に難しくないのに毎回だるい。
だからこそ自動化のうまみが大きいです。
監視ツールがエラーしきい値超えを検知したら routine を呼び出し、stack trace と最近の commit を照合して、修正案の draft PR を作る。
これはかなり“未来感”があります。
オンコール担当がゼロから考えるのではなく、最初のたたき台をAIが作る。
人間はそれを見て判断するだけ。これなら精神的な負担はかなり下がりそうです。
GitHub trigger で PR open に反応し、セキュリティ・性能・style などの観点でコメントを付ける。
これは特に良さそうです。
レビューの中には、毎回同じ観点で確認する作業があります。そこを AI に任せて、人間は設計や最終判断に集中する。理にかなっています。
本番デプロイ後に API trigger で routine を呼び、smoke test(最低限の動作確認)や error log のチェックを行い、release channel に go / no-go を返す。
ここも実務っぽい。
個人的には、こういう 「リリースのたびに毎回発生する確認作業」 はAI自動化との相性がかなり良いと思います。
マージされた PR を見て、変更された API に触れている docs を探し、更新PRを出す。
これも地味に重要です。
ドキュメントって放っておくとすぐ古くなるので、**“古くなったこと自体を検知して直す”** のはかなり価値があります。
ある SDK の PR が merged されたら、別言語の parallel SDK に同じ変更を移植して PR を作る。
これはかなり攻めた使い方です。
二重実装のメンテって本当に面倒なので、ここを自動化できるなら開発体験はかなり変わるのではないかと思います。
作成方法は3つあります。
しかも、同じ Claude account に紐づくので、web で作った routine が Desktop にもすぐ出る そうです。
この統合感はうれしいですね。ツールが分断されると一気に面倒になりますから。
作成フォームでは、次の項目を設定します。
中でもいちばん重要なのは prompt です。
ドキュメントでもかなり強調されています。
なぜかというと、routine は自律的に動くので、「何をどうやって、成功とは何か」まで、指示文の中で完結していないと危ない からです。
ここ、AI運用の本質だと思います。
雑な指示だと、雑な結果が返ってくる。人間相手よりも、むしろ丁寧に書く必要があるわけです。
Claude に作業させる GitHub repository を選びます。
各 repository は実行開始時に clone され、default branch から始まります。
変更は claude/ プレフィックスの branch に作られます。
これは分かりやすいですね。AIが触った変更だと識別しやすい。
cloud session が何にアクセスできるかを決めます。
たとえば API key や token を environment variables に入れたり、依存関係を setup script で入れたりします。
setup script の結果は cached されるので、毎回やり直しではないようです。
ここはセキュリティ的にも重要です。
AIに何でも見せるのではなく、必要なものだけを渡す。
自動化が進むほど、この設計が雑だと危険だと思います。
Slack や Linear など、MCP connectors を含められます。
しかも、含めた connector の tool は、実行中に毎回 permission を求めずに使える と書かれています。
これは便利な反面、かなり強い権限でもあります。
だからこそ、「routine が本当に必要な connector だけを入れる」という考え方が大事です。
branch push の権限も設定できます。
通常は claude/ プレフィックスの branch にしか push しないですが、必要なら既存 branch への unrestricted push を許可できます。
これは強力ですが、慎重に扱うべき設定だと思います。
自動化は便利ですが、権限を広げるほど事故の可能性も増えるので、最小権限の原則はやはり大事です。
CLI では /schedule コマンドを使います。
たとえば:
/schedule daily PR review at 9am/schedule clean up feature flag in one weekみたいに、自然文で指定できます。
ただし、CLI で作れるのは scheduled routine のみ。
API trigger や GitHub trigger を追加したい場合は web で編集する必要があります。
また、既存 routine の管理も CLI からできます。
/schedule list/schedule update/schedule runこの辺りは、日常的に Claude Code を触る人にはかなり便利そうです。
「思いついたときにその場で登録できる」のは、運用のハードルをかなり下げます。
定期実行は local zone で入力され、cloud 側では自動で UTC に変換されます。
つまり、「朝9時に動かしたい」なら、その地域の朝9時として扱われる ということです。
また、実行時刻は数分ずれることがあります。
これは stagger のためで、各 routine ごとに一定のずれがつくようです。
こういう設計は、同時刻に大量実行が集中するのを避けるためでしょう。実運用ではむしろありがたいです。
カスタムな cron expression も使えますが、CLI で更新する必要があります。
最低実行間隔は1時間で、それより短い cron は拒否されます。
1回だけ未来の特定時刻に動かす設定もあります。
たとえば:
1回実行したら自動で disable され、UI 上では Ran と表示されます。
しかも、one-off は daily routine run cap にはカウントされず、通常の subscription usage を消費する扱いです。
この仕様はちょっとややこしいですが、要するに
「定期枠とは別に、単発実行は通常セッションと同じ扱い」 と覚えるとよさそうです。
ここはかなり重要です。
チーム共有ではありません。
作成者の個人 claude.ai account に属します。
つまり、チーム運用するには、誰がどの routine を持つのかを考える必要があります。
「みんなで見える共有自動化」ではなく、まずは個人起点の機能です。
routine はアカウントの daily run allowance にカウントされます。
使いすぎると枠を圧迫するので、むやみに高頻度で回すものではないでしょう。
GitHub identity や connector 経由の動作は、あなたのアカウントとして記録されます。
これは便利でもあり、少し怖くもあります。
Slack 投稿や PR 作成が「AIがやりました」ではなく、あなた名義で実行される わけです。
運用ルールを決めておかないと、後から「これ誰がやったの?」になりかねません。
個人的には、routines は「おもしろいデモ」よりも かなり実務に寄った機能 だと感じました。
特に良いのは、単なる cron 的な自動実行ではなく、
AIに“判断を伴う仕事”を持たせている ところです。
こういう作業は、ルールベースの自動化だけではしんどい。でもAIなら、文章・コード・ログをまたいで処理できる。
ここに routines の強さがあります。
一方で、危うさもあります。
自律的に動くほど、prompt の質、権限設計、connector の選択が重要になる。
つまり、「賢いAIを入れれば勝手にうまくいく」わけではない です。むしろ運用設計の巧拙が、そのまま成果に出そうです。
なので、いきなり本番の最重要フローを全部任せるより、
みたいに、失敗しても被害が小さい仕事から試す のがよさそうだと思います。
Claude Code の routines は、Claude を「その場で答えるAI」から「継続的に動く作業担当」へ進化させる機能です。
schedule、API、GitHub event を使って、定型的で繰り返し発生する仕事をかなり自然に自動化できます。
特に、PRレビューや障害対応、ドキュメント更新のような、
“人間が毎回やるには面倒だけど、価値は高い仕事” と相性が良さそうです。
まだ preview なので慎重さは必要ですが、方向性としてはかなり面白いです。
AIが「質問に答える存在」から「業務を回す存在」に変わっていく、その入口にある機能だと思います。