Claude Code Docs の新しい機能「routines」は、ひと言でいうとClaude Code をスケジュール実行・API起動・GitHubイベント連動で自動運転させる仕組みです。
しかも、ただの「定期実行」ではありません。Anthropic 管理のクラウド上で動くので、手元のPCを閉じても止まりません。ここがかなり大きい。ローカルで動く自動化は、結局「PCをつけっぱなしにする人が勝つ」世界になりがちですが、routines はその弱点をかなりきれいに消しています。
この機能の面白いところは、単なる cron 的な定期実行に見えて、実態はもっと広いことです。
routine に入れるのは、ただの命令文ではなく、prompt、対象リポジトリ、environment、connectors、trigger をひとまとめにした“作業パッケージ”です。
つまり、「毎週これを見て、こう判断して、必要ならPRを作って、Slackに報告して」という一連の流れを、Claude に最初から覚えさせておける。
この発想はかなり実務向きだと思います。人間が毎回やると面倒だけど、毎回やるからこそ価値がある仕事って、現場には山ほどありますから。
元記事では、例えばこんな用途が挙げられています。
この中で特に「お、そこまでやるのか」と思ったのは docs drift と library port です。
前者は地味だけど痛い問題、後者は地味だけどずっと面倒な問題。つまり、放っておくと品質がじわじわ下がる領域に強い。こういうところに自動化を当てるのは、かなり賢い設計だと思います。
routines の起動条件は3つあります。
毎時、毎晩、毎週のように繰り返し実行したり、未来の特定時刻に1回だけ動かしたりできます。
定期点検、夜間バッチ、週次レビューみたいな仕事向けです。
HTTP POST で外部から呼び出せます。
たとえば監視ツールがエラー閾値を超えたら routine を叩く、CI/CD パイプラインがデプロイ後に起動する、みたいな使い方です。
「何か起きたらすぐ動いてほしい」という用途に向いています。
PR の作成、リリース、クローズなど、リポジトリイベントに反応できます。
コードレビューや移植作業のように、GitHub を中心に回る仕事と相性がいい。
しかもこれ、1つの routine に複数トリガーを付けられるのがポイントです。
たとえば、PRレビュー用の routine を「毎晩走らせる」「deploy script から呼ぶ」「新しいPRが来たら自動反応する」の3本立てにする、という使い方ができます。
同じルールを、定期監視にも、イベント駆動にも使い回せるわけで、これはかなり便利です。
元記事を読んでいて一番印象に残ったのは、prompt が最重要だとかなり強く書かれていることです。
routine は自律的に動くので、曖昧な指示だと困る。Claude は「何をすべきか」「何を成功とみなすか」まで、最初から自分で判断できるくらい具体的な prompt を求められます。
ここは人間の感覚だと少し怖いかもしれません。
でも逆に言うと、雑なお願いをそのまま放り込むと事故るという当たり前の話でもあります。
「いい感じにやって」では足りない。
「この issue tracker を見て、前回の実行以降に追加された issue だけを拾い、A系はXラベル、B系はYラベル、担当者がいなければコード所有者ルールで決め、最後に Slack に要約を送る」くらいまで書く必要がある。
これ、面倒に見えて、実は人間の仕事でも同じです。雑な指示は雑な成果しか生みません。
routine はクラウド上で full Claude Code session として動きます。
つまり shell command を実行できるし、リポジトリに入っている skills も使えるし、connector でつないだ外部ツールにも触れます。
ただし、何でも無制限に見えるわけではありません。
アクセス範囲は次の要素で決まります。
この制御は地味ですが重要です。
自動化は便利な反面、広く権限を持たせると怖い。特に APIキーや社内サービスに触れるなら、「必要なものだけ渡す」のが鉄則です。
元記事も、routine が本当に必要な範囲に絞るよう勧めています。これはかなりまっとうです。
routines はチーム全体で共有する仕組みではなく、個人の claude.ai アカウントに属すると書かれています。
そして、実行結果は GitHub や connector 経由で自分として残ります。コミットやPRは自分のGitHubユーザー名で出るし、Slack や Linear などの操作も連携済みアカウントで行われます。
これは便利でもあり、少し生々しくもあります。
つまり、AIが勝手にやった感じではなく、あくまで本人の作業として世界に記録される。
実務ではこのほうが扱いやすいです。責任の所在が曖昧になりにくいからです。
一方で、「このPR、本当に人間が書いたの？」という境界はますます曖昧になる。ここは今後、チーム運用のルールが必要になるだろうと思います。
作成方法は3つあります。
Web では claude.ai/code/routines から作成します。
Desktop app からも作れます。
CLI では /schedule を使って会話形式で作成できます。
Web の作成画面では、ざっくりこんなことを設定します。
ここで少し気になるのが、Desktop app には Local と Remote がある点です。
Local はデスクトップ上で動く scheduled task で、クラウドではなく自分のマシンで動く。
一方、Remote は今回の routines に近い、クラウド実行のほうです。
この切り分けがあるのは親切ですが、最初は少し混乱するかもしれません。
CLI の /schedule は scheduled routine の作成が中心で、API や GitHub trigger を付けたい場合は web 側で編集する、という役割分担になっています。
このあたりは「全部CLIで完結」とは言い切っていないので、運用の本番はWeb中心、作成の入り口としてCLIもある、という理解がよさそうです。
まず、routines はresearch previewです。
つまり正式版ではなく、挙動やAPI surface が変わる可能性があります。仕事の根幹を全部預けるなら、そこは意識したほうがいい。
個人的には、最初は「壊れても困りにくいけど面倒な仕事」から入れるのが正解だと思います。
また、Team / Enterprise では Owner が管理画面で routines を全体無効化できます。
無効にすると、既存の routine も止まり、新規作成もできません。
組織として見ると、これは安心材料でもあります。勝手に自動化が広がりすぎるのを防げるからです。
さらに、ネットワークアクセスにも default の考え方があり、Trusted network access では一般的なパッケージレジストリやクラウドAPIなどは許可される一方、それ以外はブロックされます。
社内サービスや独自ドメインに触れるなら、環境設定を見直す必要があります。
この制限は地味ですが、ちゃんと安全側に倒している感じがして好印象です。
この機能の本質は、単に「Claude にタスクを投げられる」ことではないと思います。
本当に大きいのは、一度型を作れば、あとは決まった条件で勝手に回ることです。
人間は最初の設計と例外処理に集中して、反復作業は Claude に寄せる。
この分業がちゃんと機能し始めると、チームの時間の使い方がかなり変わるはずです。
ただし、万能ではありません。
定型の運用、単純なレビュー、繰り返しの確認作業には強いけれど、曖昧な判断や政治的な調整はまだ人間のほうが向いています。
なので、routines は「AIに仕事を奪わせる」機能というより、人間がやるべき仕事を、AIが退屈な部分ごと引き受ける仕組みとして見るのが自然だと思います。
