Claude Code Routines 実践 — スケジュール・API・GitHubイベント自動化

先週、チームメンバーが「昨夜PRが自動でレビューされた」と言ったとき、一瞬止まった。誰もレビューを依頼していないのに、Claudeが夜の間にPRを開き、チームのコーディング規約に沿ってインラインコメントを残し、サマリーまで添えていた。それがClaude Code Routinesとの初対面だった。

Anthropicが2026年4月14日にリサーチプレビューとして公開したRoutinesは、まだベータ段階だが、日常的な繰り返し作業を自動化する方法をかなり変えてしまう。この記事では、Routinesが実際にどう動くのか、どう設定するのか、そして正直どこで限界に当たるかを、実際に使ってみた経験をもとに整理する。

Claude Code Routinesとは? — Prompt + Repository + Connector の3要素

公式ドキュメントにはこう書かれている。「ルーティンは保存されたClaude Code設定だ: プロンプト、1つ以上のリポジトリ、そしてコネクタセットが一度パッケージ化されて自動的に実行される。」

シンプルに言えば、3つのピースがある。

プロンプト(Prompt): Claudeが毎回の実行時に従う指示。重要なのは、このプロンプトが会話ではなく完全に独立した(self-contained)指示である必要があるということだ。「前回と同じように」は通用しない。実行のたびに最初から始まると考えると理解しやすい。

リポジトリ(Repository): Claudeがクローンして作業するGitHubリポジトリ。デフォルトブランチから始まり、複数リポジトリを指定することもできる。重要な制約が一つある。デフォルトでは、Routinesはclaude/で始まるブランチにのみプッシュできる。誤ってmainを変更してしまうのを防ぐ安全装置だ。

コネクタ(Connector): MCP(Model Context Protocol)ベースの外部サービス連携。Slack、Linear、Google Drive、GitHubなどが現在サポートされている。コネクタを通じて、ルーティンが単純にコードを見るだけでなく、外部システムへの読み書きができる。

この3要素が組み合わさると、「Anthropicのサーバーで自律的に実行されるAIエージェント」になる。自分のノートPCやサーバーなしで。

始める前の準備

Routinesを使うには以下が必要だ。

Claude Codeがウェブで有効になっているPro、Max、Team、またはEnterpriseプラン
GitHubアカウント（リポジトリ連携用）
使用するMCPコネクタ（Slack、Linearなど）を事前に接続しておくこと

プランごとの1日の実行上限:

プラン	1日のルーティン実行回数
Pro	5回
Max	15回
Team	25回
Enterprise	25回

正直、Proプランの5回は少し窮屈に感じた。1日にPRが10件を超えるチームなら、すぐに上限に達してしまう。Routinesを本格的に活用するなら、Teamプラン以上が現実的だ。

Step 1 — 初めてのRoutineを作る

3つの方法でルーティンを作成できる。

ウェブUI方式（最も直感的）

claude.ai/code/routinesにアクセス
「New routine」をクリック
ルーティン名の入力とプロンプトの作成
GitHubリポジトリの選択
クラウド環境の選択（ネットワークアクセス、環境変数、セットアップスクリプトを制御）
トリガーの選択: スケジュール / API / GitHubイベント
コネクタ設定の確認
作成

最も重要な部分はプロンプトの作成だ。次のように具体的で自己完結的に書く必要がある。

あなたはこのリポジトリのコードレビュワーです。

今日新しく開かれたPRを見つけて、以下の作業を行ってください:
1. PRのタイトルと説明が[リポジトリ名]の規約に従っているか確認
2. 変更されたファイルで明らかなバグやセキュリティ問題を確認
3. テストカバレッジが十分か確認（新しい関数ごとにテスト1件以上）
4. 発見した内容をインラインコメントで残し、PRにサマリーコメントを追加

レビューが完了したら、Slack #code-review チャンネルに「レビュー完了: [PRタイトル]」を送信

曖昧な表現（「適切にレビューして」「チームスタイルで」）は避けるべきだ。ルーティンは質問を聞き返さない。

CLI方式

Claude Codeセッション内で /schedule コマンドでルーティンを作成できる。

/schedule daily PR review at 9am

Claudeが対話式で必要な情報を聞いてくれる。作成後の管理コマンド:

/schedule list          # すべてのルーティン一覧
/schedule update        # 既存ルーティンの変更
/schedule run           # 即時実行（テスト用）

CLI方式は、すでにClaude Codeセッション内にいるときに素早くルーティンを追加するのに便利だ。

デスクトップアプリ方式

メニューからSchedule → New task → New remote taskを選択するとウェブUIに接続される。

Step 2 — トリガーを設定する

Routinesは3種類のトリガーをサポートしており、1つのルーティンに複数のトリガーを同時に設定できる。

スケジュールトリガー

繰り返し周期を設定する。オプション:

毎時 / 毎日 / 平日 / 毎週
カスタムcron式

# 毎日午前9時実行（ローカルタイムゾーンを自動変換）
cron: 0 9 * * *

# 毎週月曜日午前10時
cron: 0 10 * * 1

最小間隔は1時間だ。5分ごとの実行のようなポーリングはサポートされていない。

ドキュメントドリフト検出ルーティンに週次スケジュールを使ってみたが、毎週月曜日の朝に先週マージされたPRをスキャンし、古いAPIドキュメントを自動更新するPRを開く方式がかなりうまく動いた。ただし、APIエンドポイントの変更がコードコメントにのみ反映されてドキュメントに漏れている場合を、Claudeが常に見つけてくれるわけではなかった。より精緻なプロンプトが必要だ。

APIトリガー

各ルーティンは専用のHTTPエンドポイントを持つ。

# ルーティン実行例
curl -X POST \
  https://api.anthropic.com/v1/claude_code/routines/{routine_id}/fire \
  -H "Authorization: Bearer {routine_token}" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "今回のデプロイでapi/usersエンドポイントが変更された。関連ドキュメントの確認が必要。"}'

textフィールドに実行ごとに異なるコンテキストを渡すことができる。モニタリングシステムが異常を検知したときにアラートとともにルーティンをトリガーするパターンに特に有用だ。

例えば、Sentryアラートを受け取ったらスタックトレースを分析して最近のコミットと関連付け、修正案のドラフトPRを開くルーティンを作ることができる。

MCP サーバーを直接構築したことがあるなら、このコネクタエコシステムがどのように拡張されるかすでに体感しているはずだ。Routinesはそのコネクタを自動化された実行環境でそのまま活用する。

GitHubイベントトリガー

このトリガーが最も強力だ。PRやリリースイベントが発生すると、自動的にルーティンが実行される。

サポートされているイベント:

PR: opened, closed, assigned, labeled, synchronized, updated
Release: created, published, edited, deleted

フィルターオプションが細かい。PR作成者名、タイトル/本文のテキスト、ブランチ名、ラベル、ドラフト状態、マージ状態、正規表現パターンでフィルタリングできる。

# PRレビュールーティングのGitHubイベント設定例
trigger:
  type: github_event
  event: pull_request.opened
  filters:
    - author_not_in: ["dependabot[bot]", "renovate[bot]"]  # ボットPRを除外
    - base_branch: "main"
    - labels_not_contains: ["skip-review"]

Step 3 — MCPコネクタ連携で外部サービスを統合

コネクタはルーティンが外部システムと通信するための通路だ。現在サポートされている主なコネクタ:

Slack: チャンネルメッセージの読み書き
Linear: イシューの作成/更新
Google Drive: ドキュメントの読み書き
GitHub: PRコメント、イシュー管理（デフォルト含む）

ルーティン作成時、すでに接続されているMCPコネクタはデフォルトで含まれる。不要なコネクタを削除してルーティンのアクセス範囲を最小化することが重要だ。セキュリティ面で大切な習慣だ。

実際の連携例:

[Slack + Linear連携イシュートリアージルーティング]

Slack #bug-reportsチャンネルで過去24時間以内の新しいメッセージを読み:
1. 再現可能なバグレポートかどうかを判断
2. バグであればLinearにイシューを作成（深刻度: 本文から判断）
3. LinearイシューのリンクをSlackスレッドに返信
4. 不明瞭な場合はSlackで追加情報を求めるメッセージを送信

Claude Codeのエージェンティックワークフローの5つのパターンを知っているなら、Routinesはその中の「自律エージェント(Autonomous Agent)」パターンをクラウドで予約実行する方式と理解すれば正確だ。

実践ユースケース4選

実際によく動くRoutinesのタイプをまとめた。

ケース1: PR自動レビュー

最も即効性があるケースだ。pull_request.openedイベントにトリガーを設定し、チームのコーディング規約をプロンプトに入れると、PRが開かれるたびにClaudeが自動でレビューを始める。

[PRレビュールーティングのプロンプト核心部分]

リポジトリのCONTRIBUTING.mdに書かれたスタイルガイドを参照して:
- 変数名がcamelCaseまたはsnake_caseの規約に従っているか確認
- 公開APIの変更時にCHANGELOG.mdが更新されているか確認
- 新しいエンドポイントにOpenAPIスペックが追加されているか確認

発見された問題はGitHubインラインコメントで、全体サマリーはPRコメントで残すこと
「LGTM」または「変更リクエスト」の判定はしないこと（それは人間が決める）

最後の行が重要だ。Claudeに最終判定の権限を与えるとチームメンバーが不快に感じることがある。「発見+説明」までにとどめ、決定は人間に委ねるのが現実的だ。

ケース2: 夜間バックログトリアージ

毎晩新しく開かれたイシューを分類するルーティングだ。

毎日深夜実行:
1. 今日開かれたGitHubイシューをすべて取得
2. イシューのタイプタグを追加 (bug, feature-request, question, documentation)
3. コードエリアごとの担当者を自動アサイン (CODEOWNERSファイル参照)
4. 分類結果をLinearイシューとして作成 (Slack #triageチャンネルにもサマリーを送信)

これを直接使ってみてわかったことがある。CODEOWNERSファイルが最新の状態でないと、ルーティングが的外れな人にアサインしてしまう。Routinesが良い自動化を作ってくれるのではなく、良いベースデータがあるときにそれを活用するツールだ。

ケース3: デプロイ後スモークテスト

CD パイプラインの最後にAPIルーティングをトリガーする。

# CI/CDでデプロイ完了後に実行
curl -X POST \
  https://api.anthropic.com/v1/claude_code/routines/{smoke_test_routine_id}/fire \
  -H "Authorization: Bearer {token}" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -d '{
    "text": "v2.3.4デプロイ完了。環境: production。デプロイ時刻: 2026-04-22T14:30:00Z"
  }'

ルーティングはデプロイされたバージョンの主要APIエンドポイントを呼び出し、エラーログをスキャンし、#releasesチャンネルにgo/no-go判定を送信する。

MCP サーバーをKubernetes にプロダクションデプロイする方法をすでに扱ったが、このスモークテストルーティングをそのパイプラインの最後のステップとして組み込むと自然につながる。

ケース4: 週次ドキュメントドリフト検出

毎週月曜日の朝、先週マージされたPRをスキャンして、APIドキュメントがコードと不一致な箇所を見つけて更新PRを開くルーティングだ。

正直、これが最も印象的だった。コード変更とドキュメント更新の間のギャップを人間が毎週手動でチェックするのは、現実的に難しい。ルーティングがこの役割を担ってくれれば、ドキュメント品質を維持するのに大いに役立つ。ただし、Claudeが生成した更新PRを無条件にマージせず、必ず人間がレビューするステップを維持する必要がある。

正直な評価 — 限界と注意点

Routinesが印象的なのは事実だが、まだリサーチプレビュー段階だという点を過小評価してはならない。

プロダクション運用にすぐ使うのは早い。 APIがexperimental-cc-routine-2026-04-01ヘッダーを要求していること自体がこの機能の成熟度を示している。APIサーフェスが変わる可能性があり、過去2つのバージョンのみ互換性を維持すると明示されている。クリティカルパスの自動化にはまだ検証が必要だ。

監査証跡(Audit Trail)が不十分だ。 ルーティングがなぜ特定の決定を下したかを把握するのが難しい。Claudeがプルリクエストにコメントしたりイシューを自動作成したりするとき、その判断根拠をログから完全に再現するのは現状ほぼ不可能だ。

承認チェックポイントがない。 ルーティングは完全に自律的に実行される。ミスがリポジトリに反映された後でのみ発見できる可能性があることを意味する。

GitHubイベント処理量の制限がある。 リサーチプレビュー期間中、GitHubイベントはルーティングごと、アカウントごとに時間当たりの上限がある。PRが多いモノレポにイベントトリガーを設定すると、上限に達してイベントがドロップされる可能性がある。

セッションの再利用ができない。 GitHubイベントが2回発生すると、2つの独立したセッションが開始される。前回実行のコンテキストを次の実行に引き継ぐ方法がない。

Claude Codeを並列セッションで運用する方法をすでに習得しているなら、Routinesはその並列性を時間軸に拡張する概念として捉えることができる。今この瞬間自分が別の作業をしている間、ルーティングが別のリポジトリで別の作業を処理している。

結論 — どのチームに適しているか

正直な立場を言えば、Routinesは現段階でAI自動化に慣れたチームの実験的ツールとして最も適している。

3種類の作業に絞って始めることをお勧めする。

第一、人間が毎回やる必要があるが規則が明確な繰り返し作業（バックログトリアージ、タグ分類）。第二、失敗しても次の実行で自動補完される作業（ドキュメントドリフト検出）。第三、結果物が人間の最終レビューを経る作業（レビュー草稿、更新PRの草稿）。

Routinesに積極的に投資を続けているAnthropicの動きは明確だ。ログの強化、GitHubイベント処理量の拡大、セッション継続性のサポートは近い将来実現する可能性が高い。今から軽く試しながらチームに合ったパターンを見つけておく方が賢明だ。

参考リンク:

Claude Code Routines 実践 — スケジュール・API・GitHubイベント自動化

Claude Code Routinesとは? — Prompt + Repository + Connector の3要素

始める前の準備

Step 1 — 初めてのRoutineを作る

ウェブUI方式（最も直感的）

CLI方式

デスクトップアプリ方式

Step 2 — トリガーを設定する

スケジュールトリガー

APIトリガー

GitHubイベントトリガー

Step 3 — MCPコネクタ連携で外部サービスを統合

実践ユースケース4選

ケース1: PR自動レビュー

ケース2: 夜間バックログトリアージ

ケース3: デプロイ後スモークテスト

ケース4: 週次ドキュメントドリフト検出

正直な評価 — 限界と注意点

結論 — どのチームに適しているか

他の言語で読む

この記事は役に立ちましたか？

著者について

Kim Jangwook

Claude Code Routinesとは? — Prompt + Repository + Connector の3要素

始める前の準備

Step 1 — 初めてのRoutineを作る

ウェブUI方式（最も直感的）

CLI方式

デスクトップアプリ方式

Step 2 — トリガーを設定する

スケジュールトリガー

APIトリガー

GitHubイベントトリガー

Step 3 — MCPコネクタ連携で外部サービスを統合

実践ユースケース4選

ケース1: PR自動レビュー

ケース2: 夜間バックログトリアージ

ケース3: デプロイ後スモークテスト

ケース4: 週次ドキュメントドリフト検出

正直な評価 — 限界と注意点

結論 — どのチームに適しているか

他の言語で読む

この記事は役に立ちましたか？

著者について

Kim Jangwook

関連記事

Claude Codeのエージェントワークフローパターン5選 — 自分の作業に合うパターンは?

MCPサーバーを自分で作る — Streamable HTTPトランスポートで実際のAIツールを実装する

Claude Code 並列セッション運用ガイド — Git Worktreeで複数タスクを同時処理する実践的アプローチ