Claude Code Routinesが来た——ラップトップを閉じてもAIが仕事し続ける世界

Home / Blog / Claude Code Routinesが来た——ラップトップを閉じてもAIが仕事し続ける世界

Claude Code Routinesの設定方法・トリガー種類・プラン別制限・実践的なユースケースを解説。スケジュール実行・API駆動・GitHub連携でAI自動化の次のステージへ。

エンジニアのゆとです。

2026年4月14日、Anthropicから地味にデカいアップデートが来た。

Claude Code Routines——ひとことで言えば「AIのcronジョブ」だ。

これまでの話は「Claude Codeがいる間はこれをやってくれ」だった。セッションを閉じたら終わり。ラップトップのフタを閉めたら寝てくれ、と。

Routinesはそこを変える。一度設定しておけば、スケジュールに従って、あるいは外部イベントに反応して、Anthropicのクラウド上でClaudeが自律的に動き続ける。自分がPCの前にいようといまいと関係ない。

「cronジョブにしてはできることが多すぎる」と感じるかもしれないが、それはその通りで、RoutinesはAnthropicのウェブインフラで動くClaudeのフルセッションだ。コードを読む、PRを出す、ドキュメントを検証する——Claudeがインタラクティブにできることは、全部自動実行できる。

リサーチプレビューという位置づけだから、まだ荒削りな部分もある。でも「方向性が正しい」と感じさせる機能だった。全部まとめておく。

Routinesとは何か

Routinesは「Claudeへの定期指示」を永続化する仕組みだ。

毎朝Claude Codeを起動して「バックログのIssueを確認して」とタイプしていたとする。それを毎日繰り返すのが人間の仕事だった。Routinesを設定すれば、その作業をClaudeが自分でスケジュールを見て実行する。

動作場所はAnthropicのウェブインフラ。つまりローカルのMacは一切関係ない。MacBookを閉めて寝ていても、電源を切っていても、Claudeはクラウドの上で淡々と仕事を続けている。

Routineを一つ定義するために必要な要素は3つだけだ。

プロンプト: Claudeに何をさせるか（自然言語で書く）
リポジトリ: どのGitHubリポジトリを対象にするか
コネクター: 結果をどこに通知するか（Slack、Linearなど）

この3点セットを一度設定すれば、あとはトリガーに従って自動実行される。

「3点セットを覚えるのが面倒」と思う必要はない。Claude.aiのRoutines設定画面でインタラクティブに作れる。「毎朝9時にPRレビューしてSlackに投げてほしい」と書けば、プロンプト・スケジュール・コネクターの設定をClaude自身が組み立ててくれる。

3つのトリガー

Routinesが発火するタイミングは3種類ある。トリガーの種類によって向いているユースケースが全然違うので、それぞれ押さえておこう。

スケジュール

毎時・毎晩・毎週など、時刻で発火するタイプ。cronジョブに一番近いイメージだ。

設定できる頻度：

Hourly（毎時）: 最短間隔。1時間おきに発火する
Daily（毎日）: 指定した時刻に1日1回
Weekdays（平日）: 月〜金の指定時刻
Weekly（毎週）: 週1回、指定した曜日と時刻

「毎晩22時にバックログを整理して」「毎週月曜朝9時にスプリントの状況をまとめて」みたいな定型業務に向いている。

一点だけ：最小間隔は1時間なので、「10分おきに監視したい」は現状できない。短いインターバルが必要なら /loop を使うほうがいい。

API

HTTP POSTリクエストで発火するタイプ。RoutineごとにエンドポイントとBearerトークンが発行される。

使い方はシンプルで、発行されたエンドポイントにPOSTを投げるだけだ：

curl -X POST https://api.claude.com/v1/routines/{routine_id}/trigger \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{"context": "deployment completed: v2.3.1"}'

context フィールドに追加情報を渡せるのがポイント。デプロイが完了したCI/CDパイプラインから「バージョン2.3.1がデプロイされた」という情報を乗せて発火させれば、Claudeはその文脈を踏まえて動く。

「外部システムのイベントを受けてClaudeに動いてほしい」という場面はほぼこれで解決できる。PagerDutyのアラートからRoutineを呼ぶ、Zapierのフローに組み込む、など。

GitHub

PRの作成・マージ・pushのイベント、Issueのオープン・クローズ、GitHub Actionsのworkflow完了など、GitHubのイベントで発火するタイプ。

Routinesのダッシュボードで対象リポジトリをGitHub連携しておけば、そのリポジトリ上の指定イベントが発火条件になる。

「PRが作成されたら自動でコードレビューしてほしい」「IssueがオープンされたらバックログのPriorityを確認してほしい」——こういうワークフローがスクリプトなしで組める。

GitHub Actionsの on: トリガーに近い感覚で、でもアクションの中身がシェルスクリプトじゃなくてClaudeのフルセッションになる。

プラン別の制限と選び方

Routinesはプランによって1日に実行できる回数の上限が決まっている。

プラン	1日の実行上限
Pro	5回
Max	15回
Team / Enterprise	25回

Proの5回というのは、正直ちょっと少ない。毎時発火のRoutineを設定したら1日24回になるわけで、Proでは物理的に追いつかない。

現実的な使い方で考えると：

Pro: 「毎朝1回のまとめ処理」「週1の監査」くらいが現実的。5回をすべてスケジュール系に使うなら朝・昼・夕・夜・翌朝みたいな運用が上限
Max: 15回あれば、朝のPRスキャン・毎時のCI監視・夜のドキュメントチェックを全部回せる。個人開発で本格活用するなら最低これが欲しい
Team / Enterprise: 25回。チームのリポジトリ複数を横断してRoutineを回すような使い方に対応できる

フリーランスで副業レベルの自動化ならMaxで十分だと思う。Proだと「使いたいRoutineが5本あるけど1日の上限に引っかかる」という状況が普通に発生する。

なお、現時点でのリサーチプレビュー期間中は制限が変わる可能性もある。最新の上限は公式ドキュメントで確認してほしい。

実践ユースケース3選

公式ドキュメントには6つのユースケースが挙げられている。その中から「エンジニア個人が今すぐ使えそう」な3つを選んで、実際の設定イメージとともに解説する。

ユースケース1: バックログ管理の自動化

想定場面: 週1でIssueのバックログを整理したい。古いIssueのラベルを更新したり、重複を見つけたり、Milestoneへのアサインをやったり——地味だけど溜まると痛い作業。

設定例:

トリガー: Weekly（毎週月曜9:00）
プロンプト: 「GitHubのIssue一覧を確認して、以下を実行してください。7日以上更新のないオープンIssueにはStalコメントを付けてStaleラベルをつける。タイトルと内容が重複しているIssueをリストアップしてコメントを残す。Milestoneがアサインされていない高優先度IssueにMilestoneを提案する。結果のサマリーをSlackの#dev-backlogチャンネルに投稿する。」
コネクター: Slack（#dev-backlogチャンネル）

週次でバックログが自動整理される。人間がやれば1時間かかる作業が、月曜の朝に終わっている状態で始められる。

ユースケース2: ドキュメント整合性チェック

想定場面: APIのコードを変更したのにREADMEや型定義のドキュメントが追いついていないことが多い。毎日確認するのは面倒だし、見落としが発生する。

設定例:

トリガー: Daily（毎日22:00）
プロンプト: 「過去24時間にmainブランチにマージされたPRの変更内容を確認してください。APIのインターフェース変更（関数のシグネチャ、エンドポイント、型定義）が含まれる場合、対応するドキュメント（README.md、/docs/配下、JSDoc/TSDocコメント）が更新されているか確認してください。更新されていない箇所があればGitHub Issueを作成して、コードとドキュメントの差分を記述してください。」
コネクター: GitHub Issues（自動作成）

毎晩22時に「今日マージされた変更でドキュメントと齟齬が出ていないか」が自動でチェックされる。翌朝Issueが増えていれば対応する、という流れが作れる。

コードとドキュメントのズレは「気づいたときにはもう遅い」系の問題なので、毎日監視できると安心感が全然違う。

ユースケース3: デプロイ後の検証

想定場面: デプロイが完了したらCI/CDパイプラインから通知を飛ばして、Claudeに簡単な動作確認をさせたい。

設定例:

トリガー: API（CI/CDパイプラインから呼び出す）
プロンプト: 「デプロイが完了しました。以下を確認してください。1）ヘルスチェックエンドポイント（/health）が200を返しているか。2）ステージング環境のスモークテスト（/tests/smoke/配下）を実行して全パスするか。3）前回デプロイ時のエラーログと比較して、新規のエラーパターンが増えていないか。問題が見つかればSlackの#alertsチャンネルに詳細を投稿する。正常であれば確認完了のメッセージだけ投稿する。」
コネクター: Slack（#alertsチャンネル）

GitHub Actions の on: deployment イベントでAPIトリガーを叩く設定を追加するだけで、デプロイのたびにClaudeが動作確認してくれるワークフローができる。

- name: Trigger Routines check
  run: |
    curl -X POST https://api.claude.com/v1/routines/${{ secrets.ROUTINE_ID }}/trigger \
      -H "Authorization: Bearer ${{ secrets.ROUTINE_TOKEN }}" \
      -H "Content-Type: application/json" \
      -d "{\"context\": \"deployment completed: ${{ github.sha }}\"}"

GitHub Actionsのシークレットにルーティン用のIDとトークンを設定しておけば、デプロイパイプラインへの組み込みは数行で終わる。

既存の自動化（cron＋CLI）との比較

「LaunchAgentでcronを設定して claude -p "..." --headless を叩けばよくない？」という疑問は当然出てくる。

実際、僕もそういう構成を使っていたし、今も使っている部分がある。Routinesとどう違うのかをまとめておく。

項目	Routines	cron + CLI
ラップトップの電源	不要（クラウド実行）	必要（ローカル実行）
GitHubトリガー	ネイティブ対応	自前で実装が必要
APIトリガー	エンドポイント自動生成	自前でHTTPサーバーが必要
実行ログ	ダッシュボードで確認	自前でログ管理
コネクター（Slack等）	設定画面から選べる	自前でAPI連携を実装
ローカルファイルへのアクセス	不可（GitHub経由のみ）	可（ローカル全体）
コスト感	プランの上限内	APIコスト別途発生

端的に言うと：

ローカルファイルに触れないといけない: cron + CLIしかない
GitHubリポジトリが対象で、PCの電源に依存したくない: Routinesが圧倒的に楽

「LaunchAgentの設定ミスってRoutineが動いてなかった」「Mac miniを再起動したら設定が飛んだ」みたいなローカル運用の面倒さからは、Routinesを使えば解放される。その代わり、ローカルの .env ファイルや開発中のDBには触れない。トレードオフを理解した上で使い分けるのが正解だ。

リサーチプレビューで知っておくべき注意点

Routinesは2026年4月時点でリサーチプレビューだ。本番運用に使う前に押さえておきたいことをまとめておく。

仕様が変わる可能性がある: プレビュー期間中はプラン別の上限、料金、機能の範囲が変わる可能性がある。「これが正式版の仕様」と決めつけずに、公式ドキュメントを定期的に確認したほうがいい。

実行失敗時の挙動を把握しておく: Routineが失敗した場合（GitHubの権限エラー、コネクターの設定ミス等）、再試行の有無とアラートの設定を確認しておくこと。ダッシュボードで実行ログを見れば成功・失敗・エラー内容を確認できる。

GitHubへの書き込み権限は慎重に: Routinesに渡すGitHub連携のスコープは最小限にするのが安全だ。「読み取りとコメントだけ許可」「PRの作成は許可するがmainへの直接プッシュは禁止」みたいな権限設計を意識してほしい。設定を間違えると、意図しないコミットやIssue操作がクラウド上で走り続ける。

コスト管理: Routinesの実行はプランの利用量に含まれる。長時間実行されるRoutineを高頻度で走らせると、プランの月間上限に予想外のペースで引っかかることがある。最初は低頻度（毎日1回）のRoutineから始めて、実行時間と消費量を確認してから頻度を上げるのが無難だ。

公式ドキュメントはこちらにある： https://code.claude.com/docs/en/routines

機能のロードマップや既知の制限も記載されているので、本格導入前に一読しておくといい。