Claude CodeのRoutinesとは？スケジュール・API・GitHubイベントで定型作業を自動化する方法【2026年4月版】
Claude Code を使っていると、毎朝の PR review、deploy 後の smoke check、alert 発生時の一次切り分けのように、「だいたい同じ条件で何度も回したい作業」が増えてきます。毎回 interactive session を開いても進みますが、回数が増えると prompt の揺れと起動忘れが先に問題になります。
その定型作業を saved configuration と trigger で回すのが Claude Code の Routines です。2026年4月15日時点の公式 docs では research preview ですが、schedule、API、GitHub event の3種類の trigger に対応し、Anthropic 管理の cloud 上で動き続けます。
先に結論を言うと、Routines は prompt、repositories、connectors、environment、triggers をまとめて保存する cloud 実行版の Claude Code です。完了条件が明確で unattended に回したい仕事ほど、通常の interactive session より設計しやすくなります。
本記事のポイント
- Claude CodeのRoutinesは、prompt、repositories、connectors、environment、triggers を保存して cloud 上で自動実行する saved configuration である。
- trigger は schedule、API、GitHub event の3種類で、同じ routine に複数組み合わせられるため、定時実行とイベント駆動を一つの運用へ寄せやすい。
- Routine には approval prompt が出ず、actions は自分の GitHub や connector の権限で実行されるため、prompt より先に scope と権限境界を狭く設計する必要がある。
この記事で扱うテーマ
関連キーワード
- Claude Code Routines
- Claude Code routine 使い方
- Claude Code schedule api github trigger
- Claude Code remote task
- Claude Code local scheduled task 違い
このページで答える質問
- Claude CodeのRoutinesとは何ですか？
- schedule・API・GitHub trigger はどう違いますか？
- Claude CodeのRoutinesはどう作りますか？
- Routinesとlocal scheduled taskの違いは何ですか？
Routines が刺さりやすいケース
- 毎朝同じ review checklist で pull request を見たい
- 本番 deploy 後に smoke test と log 確認をまとめて走らせたい
- alert 発生時に、stack trace と recent commits を突き合わせる初動を自動化したい
- docs drift や backlog maintenance のような unattended な定期業務を cloud 側へ逃がしたい
「毎回人が起動して説明しなくてもよい仕事」を Claude Code の設定として固定したい場合に、Routines は強く効きます。
Claude Code の Routines とは何か
Routines は、Claude Code をその都度起動する代わりに、「この prompt を、この repository と connector と environment で、この条件で走らせる」という設定を一つの unit として保存する機能です。routine 自体は local の cron ではなく、Anthropic 管理の cloud infrastructure で動きます。そのため、laptop を閉じていても schedule trigger は継続します。
| 固定する要素 | Routines で持つ内容 | 実務上の意味 |
|---|---|---|
| prompt | 毎回 Claude が読む指示文 | done の定義を毎回ぶらさない |
| repositories | run ごとに clone する GitHub repository | 対象 codebase と branch 起点を固定する |
| connectors | Slack、Linear、Google Drive などの接続先 | 外部ツール連携を routine 単位で絞る |
| environment | network access、env vars、setup script | 外部 API と install 条件を cloud 側に閉じる |
| triggers | schedule、API、GitHub event | 手動起動ではなく event で回す |
2026年4月15日時点の docs では、Routines は Pro、Max、Team、Enterprise で Claude Code on the web が有効な環境を前提に提供されています。routine の run は通常の session と同じように履歴へ残るため、後から session URL を開いて何をしたか確認できます。
3つの trigger はどう使い分けるか
Routines を理解するうえで重要なのは、「何を自動化するか」より先に「何で起動するか」を分けることです。same prompt でも、schedule で回すべきか、API で叩くべきか、GitHub event にぶら下げるべきかで設計が変わります。
| trigger | 起動条件 | 向いている仕事 | 押さえるべき注意点 |
|---|---|---|---|
| Schedule | hourly / daily / weekdays / weekly の定期実行 | nightly review、docs drift、backlog maintenance | 時刻は local timezone 基準。custom cron も使えるが最短は1時間間隔 |
| API | routine 専用の endpoint へ HTTP POST | alert triage、deploy verification、社内ツールからの起動 | token は一度しか表示されず、CLI では token 管理ができない |
| GitHub event | PR、push、issues、workflow run などの repository event | PR review、backport、workflow 連動 | Claude GitHub App の install が必要で、各 event は毎回独立 session になる |
公式 docs でも、一つの routine に複数 trigger を付けられる前提になっています。たとえば deploy verification を nightly の health check と API 起動の両方に寄せる、という設計ができます。
API trigger は routine ごとの /fire endpoint を持ち、request body の text に one-shot の文脈を足せます。alert 本文や failing log の要約をここに入れると、同じ routine を複数の incident へ流用しやすくなります。
作成手順と設定で外しやすいポイント
作成 surface は web、CLI、Desktop app の3つありますが、役割は同じではありません。ここを曖昧にすると、「作れたはずなのに token が出ない」「GitHub trigger が反応しない」といった詰まり方をします。
| surface | できること | 外しやすい点 |
|---|---|---|
| Web | routine の新規作成、trigger 追加、token 管理、connector 見直し | API と GitHub trigger の設定は実質ここが正本 |
| CLI | /schedule で schedule routine 作成、/schedule list、/schedule update、/schedule run | CLI だけで API trigger や GitHub trigger は作れない |
| Desktop app | New remote task から routine 作成 | New local task は routine ではなく、自マシンで動く scheduled task |
prompt は interactive session より厳密に書く必要があります。routine には approval prompt がなく、曖昧な指示を run 中に人が補う前提が置きにくいからです。成功条件、禁止条件、どこまで push してよいか、失敗時にどこへ記録するかまで self-contained に書いた方が安定します。
repository は run ごとに default branch から clone され、既定では claude/ prefix の branch へしか push できません。保護 branch に近い repository ほど、この制約を外す前に 権限設計 と 監査ログ を先に固めた方が安全です。
外部ファイルや SaaS へ広げるなら、routine 自体より connector と MCP の設計が本丸です。Office や Drive まで含めて動かしたい場合は、Claude Code × MCP の接続設計 を先に見ておくと scope の切り方が整理しやすくなります。
見落としやすい制約と誤解
Routines は便利ですが、interactive Claude Code をそのまま unattended にしただけ、と捉えると危険です。公式 docs 上でも research preview であり、limits と API surface は変わり得る前提です。
| 誤解 | 実際 | 実務上の扱い |
|---|---|---|
| approval prompt が最後に止めてくれる | Routine run には permission picker も approval prompt もない | prompt、branch 権限、connector を先に絞る |
/web-setup だけで GitHub trigger も動く | clone 権限とは別に Claude GitHub App の install が必要 | GitHub event の反応有無は App install まで確認する |
| 各 GitHub event は前の run を引き継ぐ | matching event ごとに新しい独立 session が始まる | state は repository か外部系へ明示的に残す |
| connector action は system user 名義で動く | GitHub commit や Slack 投稿などは自分の接続 identity として実行される | 個人権限のまま広くつなぎすぎない |
加えて、routine run には account 単位の日次 cap があり、通常の subscription usage と同じ系統で消費されます。失敗しにくいのは、one-off の曖昧な仕事より、「入力」「完了条件」「出力先」が固定できる routine です。運用文書まで含めて整えるなら、AIエージェント Runbook の型 も一緒に作る方が安定します。
よくある質問
Routines と Desktop の local scheduled task は何が違いますか？
Routine は Anthropic 管理の cloud で動く remote task です。Desktop の local scheduled task は自分の machine 上で動き、routine とは別物です。Desktop app では New remote task が routine、New local task は machine local と分けて理解するのが正確です。
CLI だけで API trigger や GitHub trigger まで作れますか？
できません。CLI の /schedule は scheduled routine の作成と管理には使えますが、API trigger と GitHub trigger の追加や token 管理は web 側の edit 画面が必要です。
GitHub trigger は pull request 以外にも使えますか？
使えます。docs 上では push、issues、issue comment、discussion、workflow run、workflow job など幅広い event category が対象です。ただし、event を増やすほど run 数も増えるため、最初は label や branch 条件で絞った方が運用しやすくなります。
どんな仕事を Routine 化すると失敗しにくいですか？
「毎回ほぼ同じ入力を受け、終わり方が明確で、失敗時の戻し先が決まっている仕事」です。逆に、関係者への調整や曖昧な判断が多い one-off の仕事は、interactive session の方がまだ向いています。
