Claude Code には、いま四つの自動化 surface があります。最初に考えるべきことは trigger syntax ではなく、runtime を誰に持たせるかです。Routines は cloud 側の枝です。ノート PC を閉じたあとも、Anthropic-managed clone の中で workflow を動かし続けられます。Desktop scheduled tasks はローカルのマシンに残り、/loop は現在の session に残り、GitHub Actions は CI に残ります。
この topic は launch の勢いで見るより、ownership で見るほうがずっと整理しやすくなります。ノート PC を閉じたあとも動き続けてほしくて、cloud clone で成立する workflow なら Routines。ローカル files、ローカル apps、ローカル browser profile が必要なら Desktop scheduled tasks。いま開いている Claude Code session の中で短い反復を回したいなら /loop。repo policy、build、audit logs を含む CI-native automation なら GitHub Actions。仕事がローカル環境か live session か CI に属しているなら、たとえ繰り返し仕事でも Routines は正しい owner ではありません。
Anthropic は 2026年4月14日に Routines を research preview として公開しました。大事なのは「新しい」という事実より、今の contract がまだかなり限定的だという点です。Routines はすでに schedule、API、GitHub triggers をサポートしますが、CLI の /schedule は scheduled routine だけを作ります。さらに API trigger は通常の Anthropic API key ではなく、per-routine bearer token で認証されます。
“証拠メモ：この記事は Anthropic の現行 routines docs、scheduled tasks docs、
/firedocs を 2026年4月16日時点で確認した内容に基づいています。daily caps、beta header、preview status は日付つきの事実として読んでください。
いちばん早い判断方法
prompt や cron を考える前に、まずこの workflow をどの runtime owner に持たせるべきかを決めます。
| workflow に必要なのが… | いちばん自然な owner | その route が勝つ理由 | なぜ Routines ではないのか |
|---|---|---|---|
| ノート PC を閉じたあとも続く仕事 | Routines | Anthropic が cloud clone で起動し、schedule、API、GitHub event で wake-up できる | ローカル依存がある仕事には cloud clone が向かない |
| ローカル files、ローカル apps、ローカル browser へのアクセス | Desktop scheduled tasks | 依存が machine にあるなら task も machine に置くべき | cloud runtime は同じ local state を見られない |
| いま開いている coding session の中での短い polling や watch-work | /loop | 軽く、分単位で回せて、open session の owner をそのまま使える | session-scoped なので recurring loop は7日で切れる |
| repo-owned CI automation、policy checks、build logs | GitHub Actions | workflow 自体が repo と CI history に属している | Routines は「新しい GitHub Actions」ではない |
この表がまず最初の答えです。残りの本文は setup を増やすためではなく、その選択が本当に安全かを確認するためにあります。
Routines が本当に持っているもの
automation という言葉だけを見ると、四つの surface は trigger の違いに見えがちです。実際には、もっと手前で違います。違うのは execution location と ownership です。Anthropic の current docs での routine は、prompt、ひとつ以上の repository、connectors、環境設定を保存し、それを Anthropic-managed cloud infrastructure 上で自動的に起動する Claude Code workflow です。
ここからいくつかの practical consequences が出ます。まず、routine は「今この Mac で開いている Claude Code session の遠隔版」ではありません。Anthropic の current docs は、run ごとに repository が clone され、通常は default branch から始まり、外部システムへの actions は紐づいた claude.ai account の user として見えると説明しています。つまり Routines は remote control ではなく、別の cloud execution surface です。
次に、Routines は多くの local Claude Code workflows より広い execution environment を持ちつつ、同時に明確な境界も持ちます。Anthropic は cloud environments を使って network access、environment variables、setup scripts を扱います。だからこそ「席を離れた後も続く仕事」に向いています。逆に言えば、local browser profile、desktop software、mounted drive、machine-specific credential path に依存する仕事には向きません。
最後に、Routines は何でもできる unattended shell ではありません。Anthropic は現在、repository で unrestricted pushes を有効にしない限り、push を claude/ prefix の branch に制限しています。これは小さな detail ではなく、Routines が bounded cloud automation surface として設計されていることを示す重要な boundary です。
どんなときに Routines が向いているか
Routines が急に魅力的になるのは、「ノート PC を開きっぱなしにしておく」が acceptable でなくなった瞬間です。たとえば、毎朝ひとつの repository を見て stale issues を確認し、新しい PR を眺めて next action をまとめる workflow。あるいは docs drift の定期チェック、backlog triage、GitHub event で起きる cloud-side repo work。こうした仕事の共通点は prompt の複雑さではなく、cloud persistence そのものに価値があることです。
Anthropic の launch materials に出てくる examples もその方向です。issue triage、research、recurring repo work。Routines を選ぶ理由は、「いちばん柔軟な automation surface だから」ではありません。open session でも local machine でもなく、bounded cloud session に owner を移したほうが workflow がきれいに成立するからです。
別の fit として、外部システムから remote に wake-up したいケースがあります。ここで useful な mental model は、「コードから Claude を呼ぶ」ではなく、「既に決まっている cloud workflow を小さな payload で起こす」です。この見方にすると、API trigger は狭いようでいて、安定した workflow にはむしろ合います。
同時に、negative case も同じくらい重要です。Routines は every recurring job の default answer ではありません。workflow が live Claude Code session の中にあること自体に意味があるなら、あるいは machine-bound なら、cloud surface を増やしても constraint は解決しません。
Desktop scheduled tasks、/loop、GitHub Actions のほうがいい場面
Routines を選ばない判断は、かなりの頻度で正解です。だからこそ、残りの三つも同じだけ明確に扱う必要があります。
Desktop scheduled tasks: machine-bound な仕事は machine に残す
workflow が local files、local applications、local browser profile に依存しているなら、trigger を考える前に route choice はほぼ終わっています。job は machine に残すべきです。Desktop scheduled tasks の価値は、routine の cloud clone が見られない local state をそのまま扱えることにあります。
ここにはもうひとつ boundary があります。sub-hour の local cadence です。ローカル依存があり、しかも一時間より細かい local scheduling がほしいなら、Desktop scheduled tasks のほうがずっと自然です。
/loop: live session のための surface であって、cloud persistence のためではない
/loop が Routines より軽いのは、守備範囲が小さいからです。Anthropic の current scheduled tasks docs は、これを session-scoped scheduling として扱っています。分単位で回せますが、recurring loops は七日で切れます。だから open session の中での watch-work や polling には非常に向いています。
よくある誤解は、「/loop と Routines は同じものの新旧バージョンだ」と考えることです。そうではありません。/loop は open session が owner のままでよい仕事のための surface です。Routines は open session が owner では困るからこそ意味があります。
本当の悩みが unattended automation ではなく、長い local coding session の中での approvals や friction なら、より近い sibling は Claude Code Auto Mode です。Auto Mode は local workflow の approval behavior を変えます。Routines は workflow の実行場所を変えます。
GitHub Actions: CI-owned automation は CI に残す
GitHub Actions は「古い route」ではなく、今でも非常に強い sibling route です。workflow が repository policy、build、test gates、scheduled CI maintenance、audit-friendly logs に属しているなら、GitHub Actions の contract は依然としてきれいです。logs も permissions も repo-native な場所に残ります。
Routines も GitHub event で wake-up できますが、それは「GitHub Actions の上位互換」という意味ではありません。正しい問いは、repo event が trigger でしかないのか、それとも workflow 自体が CI-owned なのかです。後者なら GitHub Actions を残したほうが自然です。
逆に cloud branch へ行かず local route に残すと決めたなら、次の課題は schedule より tool access であることが多いです。その場合は Claude Code のおすすめ MCP Servers のほうが、より実務的な次の一歩になります。
現在の境界: preview、auth、実行頻度
Routines はすでに使える surface ですが、current contract は route choice をまだ動かします。Anthropic の launch materials によると、2026年4月16日時点で included routine runs は Pro が 5/day、Max が 15/day、Team または Enterprise が 25/day です。さらに routine runs は interactive Claude Code sessions と同じ subscription usage pool を使います。headline にする必要はありませんが、どの workload を先に routines に渡すかは確実に変わります。
auth model も同じくらい重要です。Anthropic の current /fire docs は、API trigger が per-routine bearer token と anthropic-beta: experimental-cc-routine-2026-04-01 header を使うと明記しています。つまり、これは普通の Anthropic API key integration の別名ではなく、Claude Code Routines product surface の一部です。
trigger configuration にも境界があります。Routines は schedule、API、GitHub triggers を扱え、ひとつの routine で複数 trigger を組み合わせられます。ただし CLI は surface 全体より狭く、claude --schedule は scheduled routine だけを作ります。API と GitHub triggers は web editor から設定します。こうした facts は route choice のあとに知るべきことであって、first screen の主語にするべきではありません。
もうひとつ大きい boundary は、cloud routines の最小間隔が一時間だということです。minute-level polling が必要なら、Routines はその時点で route として負けます。そこは /loop か local path か CI の territory です。
plan や usage の全体像が必要なら、Claude Code 料金ガイド に進むほうがいいです。このページで大事なのは、preview caps や shared usage pool が owner choice をどう動かすかです。
最初の routine は何から始めるのが安全か
最初の routine は、少し退屈なくらいでちょうどいいです。価値をすぐ測れるくらいに narrow でありつつ、外しても cleanup が大きくならないくらいに bounded であるべきです。
安全な最初の形としては、朝の single-repo triage がわかりやすいです。
- まずは repository を一つだけにする。
- 初日は schedule trigger だけにして、API と GitHub trigger を同時に載せない。
- stale issues、open PR、failing checks を見て、短い summary か branch-scoped draft action list を返させる。
- push はデフォルトの branch boundaries に残し、最初から write-power を広げすぎない。
この形がいいのは、Routines が本当に証明すべきことだけを証明できるからです。つまり、cloud persistence が不在時にも有用な repo work を進められるかどうかです。local machine に依存せず、CI まで置き換えるふりもしません。
逆に、最初の routine でやりがちな悪手はだいたい決まっています。repository が多すぎる。trigger が多すぎる。write power が大きすぎる。そして「automation だから全部一つの surface にまとめるべきだ」と考えすぎることです。まずは一つの bounded workflow で surface に自分を証明させるほうが安全です。
FAQ
Routines は /schedule や scheduled tasks と同じですか？
同じではありません。Routines は現在のより広い surface 名で、schedule、API、GitHub triggers を含みます。CLI の --schedule はそのうち scheduled routine だけを作ります。
Desktop scheduled tasks を選ぶべきなのはどんなときですか？
local files、local apps、local browser、あるいは machine-bound state が必要なときです。sub-hour の local cadence が必要なときもこちらです。依存が machine にあるなら owner も machine のほうが自然です。
/loop で十分なのはどんなときですか？
いま開いている Claude Code session が owner のままでよく、短い反復だけが必要なときです。/loop は分単位で回せますが、session-scoped で recurring loops は七日で切れます。
Routines は GitHub Actions を置き換えますか？
置き換えません。workflow が CI、repo policy、build automation、pipeline logs に属しているなら GitHub Actions のほうが自然です。Routines は sibling route です。
routine API trigger はどう認証されますか？
Anthropic の current docs では、routine API trigger は per-routine bearer token と anthropic-beta: experimental-cc-routine-2026-04-01 header を使います。通常の Anthropic API key flow と同じではありません。
現在の daily routine-run limits はいくつですか？
2026年4月16日時点の launch materials では、Pro が 5/day、Max が 15/day、Team または Enterprise が 25/day です。preview facts として日付つきで読んでください。
結局のところ、問うべきなのは runtime を誰に持たせるか
Routines が重要なのは、Claude Code に「もっとすごい scheduler」が増えたからではありません。Anthropic が cloud-persistent automation という一本の route を切り出したからです。workflow を cloud clone に残して進めたいなら、それははっきり意味のある新しい選択肢です。
ただし、それが every recurring workflow の答えになるわけではありません。仕事が local machine に属するなら local route、open session に属するなら /loop、CI に属するなら GitHub Actions のほうが自然です。この見方ができると、Routines は万能 scheduler ではなく、Claude Code の automation stack の中で境界がはっきりした一本の枝として見えてきます。