サムネイル

Claude Code Routinesとは?自動化する3つのトリガーを解説

  • 0

コードを書かないAIエンジニア@もるふぉです。10年以上ソフトウェア開発をしてきたシニアエンジニアで、今はClaude Codeを活用して「コードを書かない開発」を実践しています。

「朝起きたら、バグ修正のPRが届いていた」。

これ、Claude Code Routinesを使うと本当に起きるんですよ。

2026年4月14日、AnthropicがClaude Codeの新機能「Routines」をリサーチプレビューとして発表しました。

AnthropicのNoah Zwebenさんの投稿にあるとおり、スケジュール実行だけでなく、GitHubイベントやAPIからテンプレート化されたエージェントをトリガーできるようになりました。

自分はこれまで /loop コマンドや Desktop のスケジュールタスクで定期実行を組んでいたんですが、正直「PCの電源落としたら止まる」という制約がずっと気になっていました。

Routinesはその制約を根本から解消してくれます。

この記事では、Claude Code Routinesの3つのトリガー(スケジュール・GitHub・API)の仕組みから、セットアップ手順、実践的なユースケース、プラン別の制限まで、一通り整理して解説します。

Claude Code Routinesとは何か

毎回手動でPRレビューするの、地味にしんどいですよね。

「週末に走らせたいドキュメントチェック、PCを起動し続けておくのもな」「/loop を仕込んでも、CLIのセッションが切れたら終わり」——そういうモヤモヤ、自分もずっと感じていました。

Claude Code Routinesは、プロンプト・リポジトリ・コネクターをひとまとめにして、自動で繰り返し実行する仕組みです。

ポイントは、Anthropicのクラウドインフラで実行されること。

ローカルマシンに依存しないので、PCがスリープしていても、電源を切っていても、設定したトリガーに応じてClaude Codeが動き続けてくれます。

つまり、あなたの代わりに動くAIが、クラウドの中に常駐している——そういう感覚です。

これまでの自動化(/schedule, /loop)との違い

Claude Codeにはこれまでも自動化の手段がありました。

  • /loop コマンド: CLIセッション内で一定間隔のタスクを繰り返す
  • Desktop スケジュールタスク: Desktopアプリからローカルマシン上で定期実行

どちらも便利なんですが、共通の制約としてPCが起動している必要があるんですよ。

/loop はCLIセッションを維持しないと止まりますし、Desktopタスクもマシンがスリープすれば当然止まります。

夜中に「PRレビューしといて」とか、週末に「ドキュメントの整合性チェック走らせて」みたいなことを安定して回すには、どうしても限界がありました。

PCオフでも動き続けるクラウド実行モデル

Routinesはこの問題をクラウド実行で解決しています。

実行のたびにリポジトリがクローンされ、設定したコネクター(Slack、Linear、Google Driveなど)にアクセスしながらタスクを処理します。

各ランは独立したClaude Codeセッションとして実行されるので、途中経過や結果をブラウザからリアルタイムで確認できます。

「寝ている間にClaude Codeが仕事してくれて、朝起きたらセッションのログとPRが残っている」——これが現実になるわけです。

正直、初めてこのコンセプトを見たとき、鳥肌が立ちました。

次のセクションでは、そのRoutinesを動かす3種類のトリガーを詳しく見ていきます。

Claude Code Routinesの3つのトリガーを理解する

記事の画像

Routinesのトリガーは3種類あります。

ここが面白いところなんですが、1つのRoutineに複数のトリガーを組み合わせることもできるので、「毎晩のスケジュール実行 + PRが来たら即レビュー」みたいな設定も可能です。

スケジュールトリガー:毎日・毎週の定期実行

一番シンプルなトリガーです。

プリセットとして hourly(毎時)、daily(毎日)、weekdays(平日)、weekly(毎週) が用意されています。

タイムゾーンはローカル時刻で入力すれば自動変換してくれるので、「日本時間の朝9時」と設定すればその通りに動きます。

カスタムのcron式も使えますが、最小間隔は1時間です。

5分間隔で回したいようなケースにはRoutinesは向いていません。そこはGitHub Actionsなど他のツールの出番ですね。

GitHubイベントトリガー:PR・Push・Issueに自動反応

個人的に一番テンションが上がった機能です。

GitHubリポジトリで発生するイベントに反応して、自動的にClaude Codeセッションを起動してくれます。

対応しているイベントが、これが本当に幅広いんですよ。以下の18カテゴリがサポートされています。

カテゴリ
トリガーされるタイミング
Pull request
PRのオープン、クローズ、ラベル付与、同期など
PR review
レビューの送信、編集、却下
PR review comment
PRの差分コメントの作成、編集、削除
Push
ブランチへのコミットプッシュ
Release
リリースの作成、公開、編集
Issues
Issueのオープン、編集、クローズ、ラベル付与
Issue comment
Issue/PRコメントの作成、編集、削除
Sub issues
サブIssueや親Issueの追加・削除
Commit comment
コミットや差分へのコメント
Discussion
ディスカッションの作成、編集、回答
Discussion comment
ディスカッションコメントの作成、編集、削除
Workflow run
GitHub Actionsワークフローの開始、完了
Workflow job
GitHub Actionsジョブのキュー追加、完了
Workflow dispatch
ワークフローの手動トリガー
Repository dispatch
カスタムrepository_dispatchイベント
Check run / Check suite
チェックの作成、完了
Merge queue entry
PRのマージキュー出入り

つまり、「PRが来た瞬間にレビューが走る」「Issueが作られた瞬間にトリアージが始まる」——開発フローのほぼあらゆるタイミングをClaude Codeへのトリガーにできるわけです。

利用にはClaude GitHub Appのインストールが必要です。

/web-setup でリポジトリアクセスを許可しただけではWebhookの配信が有効にならないので、トリガー設定時にアプリのインストールを求められたら素直に従ってください。

APIトリガー:外部システムからオンデマンド起動

APIトリガーは、HTTPのPOSTリクエストでRoutineを起動する仕組みです。

既存のツールチェーンにClaude Codeを組み込めるのが最大の強みです。

Sentryのアラートが発火したらfix PRを自動生成する、CDパイプラインのデプロイ後に検証を走らせる、社内ツールのボタンからClaude Codeセッションを起動する。

こういったシナリオがすべてAPIの1リクエストで実現します。

「Claude Codeを呼び出すHTTPエンドポイント」が手に入る——そう考えると、使い道がどんどん浮かんでくるはずです。

3つのトリガーがどんな仕組みで動いているかわかったところで、次は実際のセットアップ手順を見ていきましょう。

Claude Code Routinesのセットアップ手順

「で、実際どうやって作るの?」という話ですね。

思ったよりずっと簡単なので、安心してください。

対応プランと前提条件

Routinesを利用するには、以下の条件を満たす必要があります。

  • 対応プラン: Pro、Max、Team、Enterprise
  • Claude Code on the Web が有効であること
  • GitHubトリガーを使う場合は Claude GitHub App のインストールが必要

Freeプランでは利用できません。

Webから作成する手順

最も直感的なのはWebからの作成です。

  1. claude.ai/code/routines にアクセスし、New routine をクリック
  2. Routineの名前とプロンプトを入力(使用するモデルも選択可能)
  3. 対象のGitHubリポジトリを追加
  4. クラウド環境を選択(ネットワークアクセス、環境変数、セットアップスクリプト)
  5. トリガーを選択(スケジュール / GitHub / API、複数設定可)
  6. コネクターを確認(Slack、Linear等。不要なものは外す)
  7. Create をクリックして完成

作成後、Run now ボタンですぐに手動実行もできます。

ここで一番大事なのはプロンプトです。

Routinesは自律実行される前提なので、「何をして、成功とは何か」を明確に書いておく必要があります。人間の承認プロンプトは表示されません。プロンプトの設計がRoutineの品質を直接決める、と思っておいてください。

CLIの/scheduleコマンドから作成する方法

CLIからは /schedule コマンドで対話的に作成できます。

/schedule daily PR review at 9am

このようにワンライナーで指定することも可能です。

ただし、CLIから作成できるのはスケジュールトリガーのみです。

APIトリガーやGitHubトリガーを追加したい場合は、claude.ai/code/routines のWeb UIから編集する必要があります。

既存のRoutine管理も可能で、/schedule list で一覧表示、/schedule update で更新、/schedule run で即時実行ができます。

セットアップはこれだけです。次は「実際にどう使うか」のトリガー設定の詳細と、コピーして使えるコード例を紹介します。

Claude Code Routines:トリガー別の設定詳細とコード例

ここからが実践的な話です。

GitHubトリガーのフィルター設定

GitHubトリガーの中でも特に便利なのが、Pull requestのフィルター機能です。

すべてのPRに反応させるのではなく、条件を絞って特定のPRだけにRoutineを走らせることができます。

これを見てもらうと分かるんですが、絞り込みの粒度が細かいんですよ。

フィルター
マッチ対象
Author
PRの作成者(GitHubユーザー名)
Title
PRのタイトルテキスト
Body
PRの説明文
Base branch
PRのマージ先ブランチ
Head branch
PRの元ブランチ
Labels
PRに付与されたラベル
Is draft
ドラフト状態かどうか
Is merged
マージ済みかどうか
From fork
フォークからのPRかどうか

フィルターはAND条件で動作します。

実用的な組み合わせ例を挙げると、こんな感じです。

  • 認証モジュール専用レビュー: Base branch = main、Head branch に auth を含む
  • 外部コントリビューター対応: From fork = true でフォークからのPRだけセキュリティレビュー
  • レビュー準備完了のみ: Is draft = false でドラフトをスキップ
  • ラベルベースの起動: Labels に needs-review が含まれるPRだけ対象

「全PRにRoutineが走ってしまうのが心配」という方は、まず Is draft = false と Labels のフィルターだけかけて始めるのがおすすめです。

APIトリガーのcurl実行例

APIトリガーのエンドポイントは、Routine作成後にWeb UIからURLとBearerトークンを取得します。

トークンは一度しか表示されないので、必ずその場でコピーして安全な場所に保管してください。

実際のリクエスト例はこのようになります。

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

text パラメータは任意で、Routineのプロンプトに追加コンテキストとして渡されます。

アラートの本文やエラーログをそのまま渡すのに使えます。

成功すると、以下のようなレスポンスが返ります。

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

claude_code_session_url をブラウザで開けば、実行状況をリアルタイムで確認できます。

APIは experimental-cc-routine-2026-04-01 というベータヘッダーが必要です。

リサーチプレビュー中はリクエスト/レスポンスの形式が変更される可能性があるので、プロダクション環境に組み込む際はその前提で設計しておくのが安全です。

仕組みが分かったところで、次はこれを使って実際に何ができるかを具体的に見ていきましょう。ここからが一番面白いところです。

Claude Code Routinesの実践ユースケース5選

記事の画像

「で、実際のところ何に使えるの?」という部分です。

公式ドキュメントの例をベースに、実務で使うならどうセットアップするかという視点で整理しています。

毎朝バックログを自動トリアージ(schedule)

トリガー: スケジュール(毎日、平日のみ)

Linearコネクターを使って、前日にオープンされたIssueを読み取り、コードの変更箇所と照らし合わせてラベル付けとオーナーのアサインを自動で行います。

結果はSlackにサマリーを投稿。

朝会が始まる前に、バックログの整理が終わっている状態を作れます。毎回手動でトリアージする時間がなくなるだけで、朝のスタートが全然変わりますよ。

PRオープン時にチーム独自ルールで自動レビュー(GitHub)

トリガー: GitHub(pull_request.opened

チームのレビューチェックリスト(セキュリティ、パフォーマンス、コーディングスタイル)をプロンプトに組み込んでおけば、PRがオープンされた瞬間にインラインコメントが付きます。

人間のレビュアーは機械的なチェックをスキップして、設計判断に集中できるようになります。

これが一番すぐに効果を実感できるユースケースだと思います。「毎回同じようなコメントを書いていたな」という部分が、そのままRoutineのプロンプトになります。

アラート発火で自動fixPR作成(API + Sentry)

トリガー: API

SentryなどのモニタリングツールからWebhookでRoutineのAPIエンドポイントを叩きます。

text パラメータにスタックトレースを渡せば、Routineが最近のコミットと照合して原因箇所を特定し、修正案をドラフトPRとして作成してくれます。

オンコール担当は白紙からデバッグを始めるのではなく、PRのレビューから始められるわけです。

「深夜のアラート対応でゼロからデバッグする」あの地獄が、起き上がったらPRが来ている体験に変わります。

毎週ドキュメントのAPI drift検出(schedule)

トリガー: スケジュール(毎週)

マージされたPRをスキャンして、変更されたAPIを参照しているドキュメントを検出します。

ドキュメントの更新が必要な箇所に対して、自動でPRを作成してくれます。

「APIは更新したけどドキュメントは放置」という状況、どのチームでもあると思いますが、これを仕組みで防げるのは地味に大きいです。

マルチ言語SDKのポーティング同期(GitHub)

トリガー: GitHub(pull_request.closed、マージ済みフィルター)

あるSDKリポジトリでPRがマージされたら、別言語のSDKリポジトリに同等の変更を自動でポートして、対応するPRを作成します。

Python SDKの変更をTypeScript SDKに自動反映する、みたいな運用が人手なしで回ります。

5つのユースケースを見ていただきましたが、共通しているのは「人間が毎回やるには単調すぎて、でも放置するには大事すぎる仕事」を自動化しているという点です。

次はこのRoutinesを既存の自動化手段と比較して、どこで使い分けるべきかを整理します。

/loop・Desktop tasks・Routinesの3方式を徹底比較

記事の画像

「で、今まで使ってた /loop とどう違うの?」という疑問、当然わきますよね。

Claude Codeの自動実行には3つの方式があります。それぞれの特性を理解して使い分けるのが重要です。

比較表

項目
/loop
Desktop tasks
Routines
実行場所
ローカルCLIセッション内
ローカルマシン
Anthropicクラウド
PC起動が必要
はい(セッション維持)
はい(マシン起動中)
いいえ
永続性
セッション中のみ
マシン起動中
常時
トリガー
時間間隔のみ
スケジュール
スケジュール + GitHub + API
作成方法
/loop コマンド
Desktop app
Web / Desktop / CLI
ローカルファイルアクセス
あり
あり
なし(リポジトリクローン)
MCP / コネクター
ローカルMCPのみ
ローカルMCPのみ
クラウドコネクター
最小間隔
1分
制限なし
1時間

この表を見るとわかるんですが、Routinesはあらゆる面でスーパーセット——というわけではないんですよ。

ローカルファイルへのアクセスや、1分以下の短い間隔で動かしたいケースでは、/loop や Desktop tasks の方が適しています。

どれを使うべき?判断フロー

まず聞くべきは「PCが閉じていても動く必要があるか?」です。

  • No/loop か Desktop tasks を使う。ローカルファイルにアクセスしたいなら /loop、GUIで管理したいなら Desktop tasks
  • Yes → Routines 一択

次に 「何をトリガーにしたいか?」 です。

  • 時間間隔(5分、10分など短いサイクル)/loop(Routinesの最小間隔は1時間)
  • GitHubイベント → Routines のGitHubトリガー
  • 外部システムからのHTTPリクエスト → Routines のAPIトリガー
  • 毎日/毎週の定期実行で、PCを常時起動しておけない → Routines

迷ったら、まず Desktop tasks で小さく試して、安定したらRoutinesに昇格させるという段階的なアプローチもおすすめです。

自分がどの方式を選ぶべきかイメージできたところで、最後にプラン別の制限と運用上の注意点を確認しておきましょう。

Claude Code Routinesのプラン別制限と運用上の注意点

「無制限に動かせるの?」——残念ながら、制限はあります。

ただ、仕組みを理解しておけば引っかかる心配はありません。

Pro: 5回/日、Max: 15回/日の実行上限

Routinesにはプランごとの1日あたりの実行回数上限があります。

プラン
日次上限
Pro
5回/日
Max
15回/日
Team / Enterprise
25回/日

現在の消費量は claude.ai/code/routines または claude.ai/settings/usage から確認できます。

上限を超えた場合、Extra Usage が有効なら従量課金で継続実行されます。

Extra Usageが無効だと、ウィンドウがリセットされるまで追加の実行は拒否されます。

GitHubトリガーも同様に、1時間あたりのイベント上限があります。上限を超えたイベントはドロップされるので、アクティブなリポジトリでGitHubトリガーを使う場合はフィルターで絞り込むのがベストプラクティスです。

ブランチ制約とセキュリティ設定

もう一つ、最初に知っておくべき仕様があります。

デフォルトでは、Routinesが作成できるブランチは claude/ プレフィックスが付いたものだけです。

これは maindevelop を直接変更してしまう事故を防ぐためのガードレールです。

制約を解除したい場合は、Routine編集画面でリポジトリごとに Allow unrestricted branch pushes を有効にできます。

ただし、本番ブランチへの直接プッシュを許可する場合はブランチ保護ルールと合わせて運用を設計してください。

もう一つ意識しておくべきなのは、Routineの操作はすべてあなたのGitHub IDで行われるという点です。

コミット、PR、Slackメッセージ、Linearのチケット作成、すべてがあなたのアカウントとして実行されます。チームで運用する場合は、bot用のアカウントを用意するかどうかの検討が必要になるでしょう。

まとめ:Claude Code Routinesで変わる開発体験

Claude Code Routinesは、これまで「PCを閉じたら止まる」という制約があった自動化を、クラウド常時稼働に昇格させた機能です。

3つのトリガー(スケジュール・GitHub・API)を組み合わせることで、定期的なメンテナンスタスク、イベント駆動のコードレビュー、外部アラートからの自動修正まで、幅広いユースケースをカバーできます。

まだリサーチプレビューなので、実行回数の制限やAPIの仕様変更の可能性はあります。

でも、この機能の方向性は明確で、「エンジニアが寝ている間もAIエージェントが開発を進める」という未来が現実のものになりつつあるのを感じます。

まずは1つ、自分のリポジトリで毎日のPRレビューRoutineを作ってみてください。

5分でセットアップできて、翌朝にはレビューコメントが付いたセッションが残っているはずです。

会員登録して機能を使おう

この機能を利用するには、無料の会員登録が必要です。
お気に入りの記事を保存して、あとで読み返しましょう!