Claude Code Routinesとは？AIエージェントの定期実行と自動化を理解する

Name

Soren Atelier

更新日 2026/4/15

Claude Code Routines の重要性は、AI エージェントを「人間のプロンプトを待つ存在」から、「世界の変化や時計に合わせて自動で動く存在」へ変えることにあります。ここが本質です。cron は単なるスケジューリング機能ではありません。エージェントを運用システムに変える仕組みです。

2026年4月15日現在、Anthropic は Claude Code on the web 向けの research preview 機能として Claude Code routines を案内しています。routines は、プロンプト、repositories、environment、connectors に加えて、実行を自動開始する trigger を持てるクラウド上の保存済み agent configuration と考えると分かりやすいです。UI の手順や最新の制限を正確に知りたい場合は、先に公式の Claude Code routines docs (opens in a new tab) を確認してください。このガイドはその上で、routines の実態、重要性、そして Codex app Automations や OpenClaw cron jobs との違いを整理します。

AI coding 全体の流れから見たいなら、先に AI Coding トピックハブ、Parallel Code Agents の解説、Codex の使い方 を読むと全体像をつかみやすいです。

まず結論: Claude Code Routinesとは何か

Claude Code routines は、クラウド上で動く Claude Code セッションを自動開始する仕組みです。

手で Claude を開いて「open PR を review して」「本番アラートを確認して」と毎回頼む代わりに、次のような trigger を 1 回設定しておきます。

• schedule
• API call
• GitHub event

つまり routines は、単なるタイマーではありません。実際の coding agent session を起動するための trigger layer です。

ここで大事なのはブランド名ではなく、chat-first agent から time-triggered / event-triggered agent への移行です。

Routinesが解決する問題

多くの AI エージェントはいまも reactive なループにいます。

1. 人間が問題に気づく
2. 人間が agent を開く
3. 人間が問題を説明する
4. 人間が output を待つ

単発作業ならこれで十分です。ただ、繰り返し作業には向きません。

繰り返し作業はたいてい次の特徴を持ちます。

• 地味
• 忘れやすい
• 実行し忘れると困る
• 毎回ゼロから説明するより、policy として書いたほうが明確

だからこそ、agent に cron job 的な考え方が必要になります。価値は「毎朝タスクが走ること」そのものではなく、次の点にあります。

• work が 信頼できる
• trigger が 明示的
• 人間が思い出すのを待たずに agent が動ける
• 実行前に手で始めるのではなく、実行後に review できる

AI エージェントにとって、これはかなり大きいアップグレードです。assistant mode から operations mode へ移すからです。

Claude Code Routinesの仕組み

Anthropic の現行 docs では、routine は次の要素でできた保存済み Claude Code セットアップとして説明されています。

• prompt
• 1 つ以上の repositories
• environment
• optional connectors
• 1 つ以上の triggers

実行そのものは、単なる小さな task runner ではなく、完全な Claude Code cloud session です。

そのため routines では、たとえば次のことができます。

• repository を clone する
• shell command を実行する
• repo にコミットされた skills を使う
• Slack や Linear のような connected service を connector 経由で呼ぶ
• 後から inspection できる session を開く

実務上のイメージはこうです。

routine は、trigger を付けた reusable agent runbook です

実際の作り方

Anthropic は、web から作った routine も CLI から作った routine も同じ cloud account に書き込まれると案内しています。つまり、どの surface から作っても最終的には同じ場所に集約されます。

作成方法は次の 3 つです。

• web UI
• Desktop app の remote task
• CLI の /schedule

CLI での最短例は次の形です。

/schedule daily PR review at 9am

この方法は、最も一般的な「定期実行」の setup をかなり始めやすくしてくれます。

ただし、現行 docs には重要な制限があります。

• CLI が作れるのは scheduled routines まで
• API と GitHub trigger の追加は web UI から行う必要がある

Anthropic はまた、routine は team 共有ではなく individual account に属すると説明しています。

3つのトリガー

1. Scheduleトリガー

多くの人がまず思い浮かべるのが、定義した周期で繰り返し走る trigger です。

公式 docs では、routines は次のような preset schedule をサポートします。

• hourly
• daily
• weekdays
• weekly

独自の interval が必要な場合は、CLI の /schedule update で cron expression を設定できます。現時点の最小 interval は 1 hour なので、毎分ポーリングするような用途は想定されていません。

運用上、重要なのは次の 2 点です。

• time は local timezone で入力する
• Anthropic が consistent stagger を適用するため、実行開始が数分遅れることがある

つまり、cron に近い自動化ですが、agent 向けの scheduling rules が上に載っている形です。

2. APIトリガー

ここで routines は、単なる定期ジョブではなくなります。

Anthropic は、routine ごとに認証済みの専用 HTTP endpoint を持たせることもできます。外部システムがその endpoint に POST すると、Claude は新しい run を開始し、text field で追加の自由形式 context も受け取れます。

これによって、routine は次のようなものとつながります。

• deployment pipeline
• error alerting
• internal tools
• 別システムに置いた manual button

重要なのは、agent が時間だけでなく 外部 state change にも反応できることです。

3. GitHubトリガー

Anthropic の docs では、GitHub event から routine を起動することもできます。現行 docs では、サポートされている event category は pull request と release で、author、title、base branch、labels、draft state、merge state、fork 由来かどうかなどで filter できます。

これで Claude は repository-native な automation layer になります。

• PR が open される
• Claude が review する
• release が publish される
• Claude が verification や backport の logic を走らせる

これは「チャットを開いて review を頼む」とはまったく違う operating model です。

普通のcron jobより面白い理由

普通の cron job は、ひとつのことに強いです。決まった時刻に code を起動することです。

agent routine は、そこからもう一段先に進みます。次の要素をまとめて扱えるからです。

• schedule または event
• repository context
• tools と connectors
• 成功条件を定義する prompt
• 後で inspection できる output surface

つまり cron expression は stack の一部にすぎません。

このカテゴリが注目される深い理由は、次のような work を任せられるからです。

• 朝の PR review を誰も思い出さなくても回す
• nightly docs drift check を merged code の後に走らせる
• release 完了後に自動で deployment follow-up をする
• weekly backlog triage で labels、summary、ownership suggestion を出す

これらは shell script でも昔から可能でした。ただ、agent routine になると、scheduled run の中で扱える unstructured reasoning の量が一気に増えます。

Claude Code RoutinesとCodex app Automationsの違い

ここから比較が面白くなります。

OpenAI の 2026年2月2日 の Codex app announcement では、app は Automations をサポートしており、instructions に optional skills を組み合わせて schedule で実行できると説明されています。OpenAI は、完了した work は review queue に流れる background work として位置づけており、将来的な version に向けて cloud-based triggers も構築中だとしています。

そのため Codex app Automations は Claude routines に近い存在ですが、完全に同じではありません。

現時点の public positioning を素直に並べると、次のようになります。

• scheduled background work
• review-oriented handoff
• desktop-app-centered orchestration

一方で Claude routines は、すでに次のように整理されています。

• cloud sessions
• multi-trigger automations
• API-callable runs
• GitHub-event-aware runs

なので、比較を一言でまとめるとこうです。

Codex をよく使う人にとって重要なのは、Claude が「勝った」かどうかではありません。市場が agents must be schedulable という同じ必要性に向かって収束していることです。

OpenClawユーザーがcron jobsを気にする理由

OpenClaw は、スケジューリングを UI の裏に隠れた機能ではなく、第一級の systems surface として扱っている点で良い比較対象です。

公式 docs では、より広い automation stack として次を案内しています。

• cron: 正確な scheduling と one-shot reminder
• heartbeat: おおよその periodic check と、完全な session context
• hooks: event-driven scripts
• standing orders: 継続的な operating authority

この設計が、OpenClaw が autonomy 重視の人たちに注目される大きな理由です。

OpenClaw の docs で特に明確なのは、次の区別です。

• timing が厳密である必要がある、または work を isolation で走らせたいなら cron
• おおよその timing でよく、main-session context を使いたいなら heartbeat

これは単なる implementation detail ではありません。かなり強い automation design pattern です。

なぜそれが重要なのか

「agent cron jobs が欲しい」と言う人の多くは、実は 2 種類のものを欲しがっています。

1. 正確な scheduled execution
2. 空気のように続く periodic awareness

OpenClaw はそれをきれいに分けています。

Claude routines は、現時点では主に 1 のカテゴリをカバーしています。つまり、クラウド上で explicit な schedule または event-triggered run を起こす仕組みです。

Codex app Automations も、今のところは主に scheduled work 側です。

OpenClaw は automation logic をより細かい層に分けて露出しているので、autonomy を重視するユーザーに好まれやすいのです。

AIエージェントにcron jobsが重要な理由

agent が人間の依頼後にしか動けないなら、それは reactive tool のままです。

しかし agent が次のように動けるならどうでしょうか。

• 毎朝
• PR が開いたとき
• deploy が終わったとき
• alert が鳴ったとき
• weekly maintenance window が始まったとき

その瞬間、agent は system の operating rhythm の一部になります。

これが routines や automation framework の本質です。次の 4 つを定義できるようになります。

• agent がいつ起きるか
• どんな context を受け取るか
• どんな authority を持つか
• 結果をどこへ送るか

この 4 つが安定すると、繰り返し作業で agent を信頼しやすくなります。

よくある落とし穴

1. Scheduling と autonomy を同じものだと思う

cron trigger が解決するのは「いつ」です。正しさ、permission scope、review quality は別問題です。

2. Prompt が曖昧すぎる

「repo を見ていい感じにして」は automation prompt ではありません。drift を招くだけです。

3. Runtime boundary を無視する

cloud routines、desktop tasks、self-hosted scheduler は互換ではありません。正しい選択は、次のどれが必要かで決まります。

• local files
• cloud availability
• event integrations
• strict auditability

4. Failure handling を忘れる

良い automations には、報告すべきものがない場合、処理が多すぎる場合、外部 system が落ちている場合の扱いまで含めます。

このカテゴリをどう考えるか

シンプルな枠組みが欲しいなら、次のように考えると整理しやすいです。

• Claude Code routines を選ぶのは、schedule、API call、対応済み GitHub event で起きる cloud agent が欲しいとき
• Codex app Automations を選ぶのは、coding app 内で review-driven workflow を伴う recurring work が欲しいとき
• OpenClaw を選ぶのは、cron、heartbeat、hooks、persistent authority を別の building block として明確に扱いたいとき

だからこそ、この機能カテゴリは重要です。本質は cron syntax ではありません。AI エージェントが chat window に閉じ込められたままか、それとも信頼できる background worker になるか、そこが問題です。

Related Guides

• AI Coding トピックハブ
• Codex の使い方
• Parallel Code Agents の解説
• Claude Agent SDK で Claude Code 風 AI エージェントを作る
• OpenClaw / ZeroClaw / Pi Agent / Nanobot 比較