Claude Code Routines 実践ガイド：インディーメーカーがクラウド AI Agent で cron job を置き換える方法

毎朝 30 分かけて「昨晩の散らかり」を片付けている——CI ログの確認、PR の整理、Sentry エラーのトリアージ、Linear チケットの更新。これらのタスクには判断力が必要で、単なるデータ転送ではないため、Zapier では処理できません。以前は自分でパソコンの前に座って作業するか、複雑な GitHub Actions ワークフローを構築するしかなく、何か壊れるたびに手動介入が必要でした。

2026 年 4 月 14 日、Anthropic は Claude Code Routines をリリースしました。Anthropic のクラウドインフラ上で Claude Code セッションを継続実行し、ノートパソコンは閉じたままで構いません。「AI Agent そのものをスケジュールタスクにする」初の製品で、サーバーも DevOps の知識も不要です。

この記事では、最初の Routine をゼロから構築し、よくある 3 つの誤解を解消し、インディーメーカーがすぐに使える 3 つのテンプレートを提供します。

TL;DR

• **Routines は「スケジュールされた Claude Code セッション」**で、Anthropic クラウド上で実行——問題に遭遇すると固定スクリプトの cron job のように停止せず、推論で回避します
• 3 層構成：Cloud Routines（クラウド、ローカルアクセス不可）/ Desktop tasks（ローカル）/ /loop（現在のセッション）——90% のケースでは /loop から始めれば十分です
• Pro プランの 5 回/日で足りる：高頻度イベント（PR オープン）は Webhook trigger を使用し、日次上限にカウントされません。固定スケジュールのみ Schedule trigger を使用
• 最適な組み合わせ：Routines は「AI の判断が必要な繰り返し作業」を担当し、Zapier/Make は引き続き「機械的なデータ転送」を担当
• Routine を作成する前に、Claude Code の CLAUDE.md と Skills アーキテクチャが設定済みであることを確認してください——Routine プロンプトが効果的に機能するための基盤です

Routines とは何か？スマート cron job ではなく、AI Agent スケジューラー

「自動スケジュール実行」と聞くと cron job を想像する人が多いですが、Routines は従来の cron job とは根本的に異なります。

従来の cron job の限界：固定のシェルスクリプトを実行し、予期しないエラーが発生すると停止して手動介入を待ちます。「毎日午前 8 時にこのスクリプトを実行」と指定できますが、スクリプトが想定外の状況（リポジトリ構造の変更、API レスポンス形式の変更）に遭遇すると失敗し、修正通知が届きます。

Routines の違い：各トリガーは実際に完全な Claude Code セッションを Anthropic のクラウドインフラ上で起動します。Claude は完全な推論能力を持っており、エラーに遭遇すると代替アプローチを試み、問題を回避するか、続行できない場合は明確な説明を残します。The Register はこれを「動的 cron job」と呼んでおり、その表現は的確です——実行するのは「固定ステップ」ではなく「目標」です。

設計の核心：従来の cron job には「実行するステップ」を与えますが、Routine には「達成すべき目標」を与え、Claude に経路を判断させます。

# NG：ステップ指向（cron job 思考）
Review each PR by:
1. Run git diff on the PR
2. Check for lint errors
3. Post a comment with format X

# OK：目標指向（Routine 思考）
Review all open PRs in this repo.
For each PR, assess code quality and potential issues.
Post a concise review comment. Do NOT approve or merge. Keep comments under 150 words.

前者は Claude を固定ステップに依存させ、あるステップが失敗すると止まります。後者は Claude に自律的に経路を判断させるため、想定外の事態にも対応できます。

3 層スケジューリング判断フレームワーク：本当に Cloud Routines が必要ですか？

Anthropic の公式ドキュメントは 3 つのスケジューリングオプションを提供していますが、メディア報道は Cloud Routines にほぼ集中しており、多くの人が「唯一の選択肢」だと誤解しています。実際には、90% のインディーメーカーはもっとシンプルな方法から始めれば十分です。

オプション	実行環境	ローカルアクセス	PC 起動必須	適したシーン
Cloud Routines	Anthropic クラウド	不可	不要	PC がオフでも実行が必要なタスク
Desktop scheduled tasks	ローカルマシン	可能	必要	ローカルファイルやデータベースが必要なタスク
/loop	現在のセッション	可能	必要	セッション内で完結する実験的タスク

判断ツリー：

1. このタスクは寝ている間、PC を閉じた状態で実行する必要がありますか？

   • はい → Cloud Routines
   • いいえ → 次へ

2. このタスクはローカルファイルやローカル環境へのアクセスが必要ですか？

   • はい → Desktop scheduled tasks
   • いいえ → /loop で十分です

ペルソナシナリオ：

• Leo（SaaS 創業者）の朝の PR ダイジェスト：寝ている間に実行され、起きたら結果が見られる必要あり → Cloud Routines
• Leo の Sentry アラート分析：ローカルの .env.local を読んでプライベート Sentry エンドポイントに接続する必要あり → Desktop scheduled tasks
• Mei（テック系 YouTuber）が新しい週次整理フローをテスト：まず /loop で一度実行し、ロジックを確認してから Cloud Routines にアップグレード → まず /loop から

重要：Cloud Routines は毎回 fresh clone を実行します——Anthropic クラウドのクリーンな環境であり、ローカルの .env.local やローカルデータベースは読み取れません。ローカル状態が必要なタスクは Desktop scheduled tasks を使用してください。

前提条件と最初の Routine：ゼロから初回実行まで

公式では Cloud Routines を「メンテナンスゼロ、DevOps ゼロ」と謳っており、それは事実です——ただし、初回のセットアップコスト（約 15〜30 分）は発生します。この「一度の投資」という本質を理解することが、「ゼロ運用」という謳い文句に惑わされないために重要です。

前提条件チェックリスト

1. Claude Code on the web の有効化：claude.ai/code にアクセスし、Claude Code の Web アクセス権限があることを確認（Pro プラン以上）
2. GitHub リポジトリの接続：Claude Code on the web の設定で、Anthropic に GitHub リポジトリの読み取りを許可
3. Environment Variables の設定：Routine が外部 API（Slack、Linear、Sentry）に接続する場合、Routine 設定の Environment Variables セクションに対応する API キーを入力——これが Cloud Routines で実行間の情報を「記憶」する唯一の方法です

最初の Routine を作成する（朝の PR ダイジェストの例）

ステップ 1：claude.ai/code/routines にアクセス → New Routine をクリック

ステップ 2：トリガータイプを選択

• Schedule：cron スケジュールを設定（例：毎日 08:00 台湾時間 → 0 0 * * * UTC）
• Webhook：GitHub の PR/Issue イベントでトリガー
• API：外部システムの呼び出しでトリガー

ステップ 3：リポジトリを選択し、Routine に必要な権限を設定（読み取り、PR コメントの書き込みなど）

ステップ 4：Routine プロンプトを記述（以下のテンプレートを参照）

ステップ 5：保存してテスト（Run now をクリックして手動で一度実行し、出力が期待通りであることを確認）

自分がトリガーしていないのに Routine の実行ログが表示されるのを初めて見ると、不思議な感覚があります——それは本当に Claude Code セッションが動いているのです。ただし、あなたがその場にいる必要はありません。

/schedule CLI vs Web UI：2 つの作成方法の実際の違い

Routines は機能的に同一ですが、体験が異なる 2 つの作成方法をサポートしています。

Web UI（claude.ai/code/routines）：CLI に慣れていない Mei のようなユーザーや、設定の視覚的確認が必要なシーンに最適。ポイント＆クリックのインターフェースで直感的に使えます。

/schedule CLI：既に Claude Code ターミナルワークフローを持つ開発者や、複数のクライアントリポジトリの Routine をバッチ管理する必要がある Chris（フリーランサー）のようなユーザーに最適。

# 以下は例示的な構文です。実際のフラグ名は公式ドキュメントで確認してください
# 毎日 08:00 に実行される PR ダイジェスト Routine を作成
/schedule create \
  --name "morning-pr-digest" \
  --cron "0 0 * * *" \
  --repo "your-org/your-repo" \
  --prompt "Review all open PRs opened in the last 24 hours..."

# 既存の Routine を一覧表示
/schedule list

# 手動で一度実行（テスト用）
/schedule run morning-pr-digest

注意：CLI /schedule のドキュメントは現在 Web UI での作成フローに重点を置いています。上記のフラグ構文は例示的なものです。作成前にセッション内で /schedule をトリガーして最新の CLI ドキュメントを確認するか、Web UI（claude.ai/code/routines）で現在の構文を確認してください。

手動セットアップと比較した CLI の利点は、スクリプト化されたバッチ操作です。Chris のシナリオ：5 つのクライアントリポジトリそれぞれに nightly PR review Routine が必要——CLI なら一度のスクリプトで完了し、Web UI を 5 回クリックする必要がありません。

cron 式の構文については、OpenAI Codex CLI のスケジューリング設計を参考にしてみてください。ツールは異なりますが、cron 構文自体は共通で、2 つの AI コーディングエージェントのスケジューリング設計における哲学の違いも見えてきます。

インディーメーカー必須の 3 つの Routine テンプレート（完全なプロンプト例付き）

Routine プロンプト設計の核心原則：目標 ＋ 出力フォーマット ＋「やってはいけない」境界を与える。どれか 1 つでも欠けると、Claude が過度に積極的（main にプッシュしてしまう）か、過度に保守的（長い分析をするだけで行動しない）になる可能性があります。

Shareuhack の agent fleet でこれらのプロンプトロジックをテストしました。レビューア agent（Eno）が毎日コンテンツドラフトを自動レビューしており、以下の PR レビューテンプレートと類似のロジックを使っています。VentureBeat のエンタープライズ向け Routines テストでも、構造化された Routine プロンプトが PR レビューサイクルを平均 2.3 ラウンドから 1.4 ラウンドに短縮したと報告しています（注：エンタープライズ規模のリポジトリでの結果であり、インディーメーカーのシナリオでは差異が大きい可能性があります）。

---

テンプレート 1：朝の PR ダイジェスト（Schedule trigger、毎日 08:00）

トリガータイプ：Schedule
Cron：0 0 * * *（UTC、台湾時間の 08:00 に相当）
リポジトリ：{your-repo}

プロンプト：
Review all open pull requests in this repository that were updated in the last 24 hours.

For each PR, provide:
- PR title and number
- One-line summary of what it does
- Key concerns or blockers (if any)
- Suggested action: Ready to merge / Needs revision / Needs more info

Format the output as a markdown summary. Post it as a new comment on each relevant PR.

Do NOT:
- Approve or merge any PR
- Leave more than one comment per PR
- Comment on PRs older than 24 hours

---

テンプレート 2：週次ドキュメントスキャン（Schedule trigger、週 1 回）

トリガータイプ：Schedule
Cron：0 1 * * 1（毎週月曜 UTC 01:00、台湾時間の月曜 09:00 に相当）
リポジトリ：{your-repo}

プロンプト：
Scan the /docs directory for documentation that may be outdated.

Check for:
- References to deprecated APIs or features
- Version numbers that don't match the current package.json
- Broken internal links
- TODO or FIXME comments older than 30 days

Create a GitHub Issue titled "Weekly Docs Audit - {date}" with a checklist of findings.
If no issues found, create a brief issue noting the audit was clean.

Do NOT:
- Edit any files directly
- Delete any content
- Create more than one issue per run

---

テンプレート 3：PR オープン Webhook trigger（PR ごとの自動レビュー）

トリガータイプ：Webhook（GitHub PR opened/synchronize イベント）
リポジトリ：{your-repo}

プロンプト：
A pull request has been opened or updated. Review it for:

1. Code quality: Are there obvious bugs, anti-patterns, or style issues?
2. Test coverage: Does the PR include tests for new functionality?
3. Documentation: Are new functions/APIs documented?

Post a constructive review comment summarizing your findings.
Use this format:
- What looks good
- Concerns to address
- Suggestions (optional)

Do NOT:
- Approve or request changes (leave that to human reviewers)
- Post more than one comment per PR update
- Comment on draft PRs

重要ポイント：テンプレート 3 の Webhook trigger は Pro プランの 5 回/日のスケジュール上限にカウントされません。PR オープンごとに独立したトリガーとなるため、高頻度のシナリオに最適です。

外部ツールとの連携：MCP コネクタで Slack と Linear に通知

Routines は MCP コネクタを通じて外部ツール（Slack、Linear、Google Drive など）と連携し、Routine の出力を GitHub だけでなく、作業環境に届けることができます。

ただし、まず重要な認識を持つ必要があります：Routines は「AI 判断レイヤー」であり、「統合プラットフォーム」ではありません。

• Routines が得意なこと：コンテキストの理解、判断、サマリー生成、ドキュメント品質の分析
• Routines が不得意なこと：機械的なデータ転送（サービス A のデータをサービス B にコピー）
• 最適な組み合わせ：Routines で判断、Zapier/Make でデータ転送

Routines に単純なデータ転送（例：「新しい GitHub Issue を Notion に同期」）をさせるのは、トークンの無駄であり、Zapier の確定的ワークフローより信頼性も劣ります。

インディーメーカーのワークフローに最適な MCP サーバーの選定がまだの方は、MCP サーバー完全ガイドを参考にしてみてください。

Slack コネクタの設定（通知の例）

1. Claude Code on the web の設定 → Connectors → Slack を追加
2. Anthropic に指定の Slack ワークスペースとチャンネルの読み書きを許可
3. Routine プロンプトに Slack 出力指示を追加

# Routine プロンプトの末尾に追加：
After completing the review, send a summary to Slack channel #dev-digest using this format:
"Morning PR Digest ({date}): {X} PRs reviewed, {Y} need attention"
Include links to PRs that need revision.

実践的アドバイス：MCP コネクタの設定自体は比較的シンプルですが、Routine プロンプト内の Slack 出力フォーマットはテストが必要です。最初の実行後に Slack 通知のフォーマットが期待通りかを確認してから、プロンプトの調整が必要かどうかを判断してください。

Pro の 5 回/日を最大限に活用するスケジュール配分戦略

Pro プランの日次 5 回の Schedule trigger は少なく見えますが、課金の仕組みを理解すれば、ほとんどのインディーメーカーにとって 5 回で十分です。

重要な区別：Schedule trigger vs Webhook/API trigger

• Schedule trigger：日次上限にカウント（Pro：5 回/日、Team：25 回/日、公式価格ページに基づく）
• Webhook/API trigger：イベント駆動、日次上限にカウントされない（ただし、課金メカニズムは変更される可能性があるため、最新の公式ドキュメントでご確認ください）

推奨される Pro プランの配分戦略：

Routine	トリガータイプ	上限にカウント？	頻度
朝の PR ダイジェスト	Schedule	はい	毎日（1/5 を消費）
週次ドキュメントスキャン	Schedule	はい	毎週月曜（1 日あたり 1/35 を消費）
PR オープン自動レビュー	Webhook	いいえ	PR オープンごと
Issue 作成トリアージ	Webhook	いいえ	Issue 作成ごと
緊急アラート（Sentry）	API trigger	いいえ	オンデマンド

結論：Schedule trigger は「固定時間帯のアクティブスキャン」に予約し、即座に反応すべきイベント（PR、Issue、アラート）はすべて Webhook/API trigger を使用してください。こうすれば 5 回/日の上限を使い切ることはほぼありません。

Team プランへのアップグレードを検討すべき時：複数のクライアントリポジトリを管理している場合（Chris のシナリオ）、各リポジトリに毎朝の Schedule Routine を設定すると、5 クライアントを超えた時点で上限に達します。Team プランの 25 回/日はフリーランサーに適しています。

エッジケースとリスク管理——Routine が予期しない動作をした時

Routines は強力なツールですが、トークン消費と予期しない動作は現実のリスクです。The Register の批判的な視点はやや偏っていますが、核心的な懸念は妥当です：監視なしの Claude は過度に積極的になる可能性があります。

Leo の実体験が参考になります。以前 GitHub Actions bot で PR に自動コメントを設定したところ、bot がすべてのマイナーな typo に 500 語の詳細分析を残し、PR スレッド全体が混乱して、コラボレーターからクレームが来ました。

リスク管理チェックリスト：

• [ ] 明確な「やってはいけない」境界：すべての Routine プロンプトに Do NOT: セクションを含め、Claude が実行してはいけない操作を列挙（main にプッシュしない、X 個以上のファイルを変更しない、1 つ以上のコメントを残さない）
• [ ] まず /loop または Run now でテスト：スケジュールを設定する前に、手動で一度トリガーし、出力を注意深く確認。出力が期待通りであることを確認してから自動スケジュールを有効化
• [ ] レビュー可能な出力フォーマットの設定：Claude の出力に固定フォーマット（マークダウンチェックリスト、箇条書き）を要求し、全文を読み返すのではなく素早くスキャンできるように
• [ ] ローカル状態 → Desktop tasks：ローカルの .env、ローカルデータベース、ローカルツールが必要なタスクは Cloud Routines に入れないでください。代わりに Desktop scheduled tasks を使用
• [ ] トークン消費の監視：複雑な Routine プロンプト（大規模リポジトリのスキャンを要求）は大量のトークンを消費する可能性があります。最初の 1 週間は Claude Code の usage を注意深く監視し、想定内の消費であることを確認
• [ ] 失敗通知メカニズムの確認：Routine の実行が失敗した場合、どうやって知りますか？実行履歴は現在 claude.ai/code/routines で閲覧可能です。プロアクティブな通知が必要な場合は、Routine プロンプトに Slack 失敗通知の指示を明示的に追加する必要があります（例：「エラーが発生した場合、#dev-alerts に失敗サマリーを送信」）——これは自動的な動作ではありません

よくある落とし穴：Routine プロンプトを複雑にしすぎること（「すべてのファイルをスキャン、すべての PR を分析、すべてのドキュメントを更新、全員に通知」）で、毎回の実行が大量のトークンを消費し、出力品質が低下します。最良の Routine は 1 つのことをうまくやります。

この原則はすべての自動化ツールに当てはまります。自動化の最大の落とし穴は「1 つのワークフローに詰め込みすぎる」ことで、手動よりかえってメンテナンスが困難になります。

まとめ

Claude Code Routines の最大の価値は「より多くのことを自動化できる」ことではなく、AI の判断が必要な繰り返し作業にあなたの在席が不要になることです。「Zapier には複雑すぎる」と「自分でやるには些細すぎる」の間にあるタスク——Routines はまさにそのギャップを埋めます。

ここから始めましょう：

1. まず Claude Code の CLAUDE.md と Skills セットアップが整っていることを確認してください。Routine のプロンプトは日常の Claude Code 設定と同じ動作規範基盤を共有しています
2. 最初の最小限の Routine を作成：朝の PR ダイジェスト（GitHub リポジトリがある場合）、または週次ドキュメントスキャン
3. Run now で手動トリガーし、出力品質を確認
4. 出力が期待通りであることを確認したら、自動スケジュールを有効にし、1 週間観察
5. 1 週間後もまだ満足していたら、2 つ目の Routine の追加を検討

最初から 10 個の Routine を作成しないでください。うまく機能する 1 つの Routine は、常に修正が必要な 10 個の Routine よりも価値があります。