Claude Code Routines 実運用ガイド 2026 — フリーランス一人運用で失敗した3事例と安全な設計パターン
Claude Code Routinesをフリーランスが一人で実運用して失敗した3つの実例を公開。コネクター過多によるブランチ汚染、日次上限オーバー、サイレント失敗——それぞれの原因と再発防止設計パターンを解説。GitHub Actionsとの使い分けフレームも整理。
エンジニアのゆとです。
Claude Code Routines が登場してから2ヶ月ほど経つ。フリーランスとして一人でいくつかのRoutineを本番運用してみた結果、思ったより「ハマりどころ」があった。
Routinesの「何ができるか」は他の記事でも書いたし、公式ドキュメントも充実している。この記事ではあえて「どこで失敗したか」に絞って書く。失敗事例3つと、そこから導いた「一人運用での安全設計パターン」を整理した。
既存の Routines 入門記事との差別化を最初に明言しておく。
上の記事が「Routinesとは何か・使い方の基本」なら、この記事は「実運用で何が起きるか・どう設計すれば安全か」だ。
Routinesの動作を理解するための前提
失敗事例の説明の前に、Routinesの重要な仕様を押さえておく。
Routinesは Anthropicのクラウドインフラ上で動く完全なClaudeセッションだ。ラップトップが閉じていても動くし、電源を切っていても動く。Claudeはシェルコマンドを実行でき、接続したコネクタ（MCP）のツールを使え、GitHubリポジトリにコードを書ける。
「自律的に動くAgentをクラウドで走らせっぱなしにする」のだから、設計を間違えると意図しない副作用が発生する。
特に重要な仕様を3点。
1. コネクタはデフォルトで全部有効
Routineを作成するとき、自分のclaude.aiアカウントに登録されているMCPコネクタが全部デフォルトで有効になる。「使わないコネクタは明示的に外す」設計が必要で、外し忘れると不要なサービスへのアクセスが発生する。
2. Routineは自分のアカウントとして動く
Routineが実行したGitHub操作はすべて自分のGitHubアカウント名で記録される。Routineが間違えてコミットしても、そのコミットは自分のアカウント名になる。PRも同様。
3. 「緑のステータス = タスク成功」ではない
実行リストの緑は「インフラエラーなしでセッションが終了した」ことを意味する。プロンプトで指示したタスクが実際に成功したかどうかは、ログを読まないとわからない。
失敗事例1: コネクタを絞らずにRoutineを走らせた結果
状況: バックログ管理Routineを設定した。毎週月曜9時にGitHub IssueをスキャンしてラベルをつけてSlackに投稿するシンプルなRoutineだ。
何が起きたか: Routine作成時にコネクタを確認しなかった。当時、claude.aiにはGitHub、Slack、Linear、Notionの4つのコネクタが登録されていた。全部デフォルトで有効になっていたため、ClaudeはLinearにもアクセスして独自判断でIssueをトリアージし始めた。
さらに悪いことに、Notionにも「参考情報として」Pageを作り始めた。頼んでもいないのに。
なぜ起きたか: プロンプトには「GitHub Issueをスキャンして」と書いたが、「Linearは触らないで」とは書いていなかった。Claudeは「役立ちそうなことをやってくれる」方向に判断した結果、コネクタが許可している範囲でアクション範囲を広げた。
根本原因: 最小権限の原則をRoutineに適用していなかった。
改善後の設計:
Routineを作成するとき、コネクタをデフォルトから「このRoutineが必要とするもの以外は全部外す」。
バックログ管理Routineに必要なのはGitHubとSlackだけだ。Linear、Notionは外す。
Routineのコネクタ設定（正しい例）:
バックログ管理 → GitHub のみ、Slack のみ
ドキュメント整合性チェック → GitHub のみ
アラートトリアージ → GitHub + Slack + PagerDuty
週次レポート → GitHub + Slack + Google Driveプロンプトにも「このRoutineがアクセスしていいサービスと操作範囲」を明示するようにした。
良いプロンプトの例:
「このRoutineはGitHubのIssueのみ操作します。
他のサービス（Linear、Notion等）には一切触らないでください。
実行内容:
1. mainリポジトリのオープンIssueを取得
2. 7日以上更新のないIssueにStaleラベルをつける
3. 結果をSlackの#dev-backlogに投稿する
Slack以外のMCPツールは使わないこと。」Routineごとに「このRoutineに必要なコネクタはどれか」を明示的に決める。デフォルトの「全部有効」から「必要なものだけ残す」に変える。
プロンプトにもアクセス範囲を書く。「〇〇は触らないで」という明示的な制約は、Claudeが範囲を広げる判断を抑制する。
失敗事例2: 日次上限を意識せずに複数Routineを設定した
状況: Proプランで以下の4つのRoutineを設定していた。
- 毎朝9時: バックログ管理（Daily）
- 毎晩22時: ドキュメント整合性チェック（Daily）
- 毎週月曜: 週次レポート（Weekly）
- デプロイ後: スモークテスト実行（APIトリガー）
問題はデプロイだ。その週は本番デプロイが5回あった。
何が起きたか: 月曜にDailyの2本とWeeklyの1本が走り、追加でデプロイが2回あった。合計5回の実行でProプランの日次上限に達した。その日の夜のドキュメント整合性チェックが動かなかった。
静かに失敗した。Slackに何の通知も来なかったし、Routinesのダッシュボードを見るまで気づかなかった。
なぜ起きたか: Proプランの日次上限は5回だ。1日の実行数を意識せず設計した。しかもサイレント失敗の検知機構を作っていなかった。
改善後の設計:
2つの対策を取った。
対策1: Routineを「1実行で複数タスクをこなす」構造に統合する
毎朝のバックログ管理と毎晩のドキュメント整合性チェックを1つのRoutineに統合した。
統合Routine（毎日22時）:
1. バックログのStaleチェック
2. 今日マージされたPRのドキュメント差分チェック
3. 結果を一つのSlackメッセージにまとめて投稿1回の実行で両方できるなら、2回使う必要はない。
対策2: プロンプトに必ずSlack通知を入れる
すべてのRoutineのプロンプト末尾に必ず以下を入れるようにした。
「実行が完了したら、以下をSlackの#routine-logチャンネルに投稿してください:
- 実行した内容の要約
- 成功/失敗のステータス
- 次回実行への引き継ぎ事項があれば
なんらかのエラーが発生した場合も、Slackに投稿してください。
Slackへの投稿が失敗した場合のみ、GitHubに#routine-failureラベルのIssueを作成してください。」これで「Slackに何も来ない = Routineが動いていないか失敗している」という状態になった。サイレント失敗が検知できる。
Proプランの日次5回をどう配分するか（参考）:
毎日の定型 → 最大2回（朝・夜の統合Routine）
APIトリガー用 → 最大2回（デプロイ等）
バッファ → 1回（突発的な手動Run Now用）
予測デプロイ本数が多い週は手動Routineを減らすか、
デプロイRoutineを「1日1回まで」の制限付きで設計する週に5回以上のデプロイがあり、かつ毎日のバックログ管理も必要なら、Maxプラン（15回/日）を検討したほうがいい。
フリーランスでの個人開発なら、「統合Routine」で5回に収める設計が先で、それでも足りない時にプランを上げる判断でいい。
失敗事例3: ブランチへの書き込み権限を広くしすぎた
状況: デプロイ後の自動スモークテストRoutineを設定した。テストが落ちた場合、Claudeに「バグを修正してPRを出す」ところまでやってもらいたかった。
設定時に Allow unrestricted branch pushes を有効にした。「PRを出すためにブランチが必要だから」という判断だった。
何が起きたか: あるデプロイ後にスモークテストが落ちた。ClaudeはTypeErrorを修正しようとしたが、修正方法を誤り、さらに別のTypeErrorを引き起こすコードをmainブランチに直接プッシュした。
Allow unrestricted branch pushes を有効にしていたため、mainへの直接プッシュが可能だった。CIが落ちて、本番のデプロイパイプラインが止まった。
なぜ起きたか: Allow unrestricted branch pushes は「mainを含む任意のブランチへのプッシュを許可する」設定だ。これはPR経由ではなく直接プッシュを意味する。「PRを出す」だけならデフォルト設定（claude/ プレフィックスブランチのみ）で十分だった。
改善後の設計:
原則を1つ決めた。「RoutineはPRを作るまでで止まる。マージは人間が判断する」。
Routineの書き込み権限の原則:
NG: Allow unrestricted branch pushes を有効にする
→ main・develop等へ直接プッシュ可能になる
OK: デフォルト設定（claude/ プレフィックスのみ）のまま
→ claude/fix-smoke-test-20260605 のようなブランチにプッシュ
→ PRを作成してレビューを要求
→ マージは人間が判断
例外としてAllow unrestricted が必要なケース:
→ ドキュメント専用リポジトリで、誤りが少なく影響範囲が小さい
→ ブランチ保護ルールでCI必須マージを設定しているプロンプトも変えた。
「スモークテストが失敗した場合:
1. エラー内容をSlackの#alertsに投稿する
2. 修正候補のコードをclaude/smoke-test-fix-{日付}ブランチに作成する
3. PRを作成してレビューを依頼する
4. mainへの直接プッシュは絶対に行わない」安全設計の3原則
3つの失敗から抽出した、一人運用での安全設計パターンをまとめる。
原則1: 最小コネクタ・明示プロンプト
Routineごとに必要なコネクタだけを有効にする。プロンプトに「このRoutineがアクセスしていいサービスと操作範囲」を明記する。
チェックリスト（Routine作成時）:
□ コネクタを全部確認した
□ このRoutineに不要なコネクタを削除した
□ プロンプトにアクセス範囲を明記した
□ 「〇〇には触らないで」という制約を書いた原則2: 必ずSlack通知を仕込む
「プロンプト末尾に必ずSlack通知を入れる」ルールを徹底する。これが最低コストのサイレント失敗検知だ。
Slack通知が来なくなったら即座に気づける。
# 監視Routineとして設定するSlack通知の確認
# （Weekly、毎週月曜朝に先週のRoutine実行ログをチェック）
# Routineが全部正常に動いているか確認する:
# - 先週の月〜日に#routine-logへの投稿があったか
# - 欠落している投稿（失敗 or 実行されなかった）があれば#alertsに報告する原則3: Routineはclaude/ブランチ止まり
Allow unrestricted branch pushes は原則使わない。mainへの書き込みは人間が判断する。
「Routineは提案するまで、判断は人間がする」という役割分担を守ることで、意図しない本番影響を防げる。
Routines vs GitHub Actions: 使い分けフレーム
RoutinesをどこまでやるべきかはGitHub Actionsとの比較で考えると整理しやすい。
根本的な違い
| 項目 | Routines | GitHub Actions |
|---|---|---|
| 動作場所 | Anthropicクラウド | GitHubのランナー（ubuntu等） |
| ローカルファイルアクセス | 不可 | 可（checkoutしたリポジトリ） |
| トリガー | Schedule / API / GitHub Events | GitHub Events / cron / workflow_dispatch |
| コスト | プランの使用量に含まれる | GitHub Actionsのminutes + API料金 |
| 設定難易度 | 低（自然言語プロンプト） | 中（YAML設定） |
| 認証管理 | claude.aiに統一 | Secretsで別途管理 |
| ログ確認 | claude.ai/code/routines | GitHub Actions UI |
判断フロー
判断1: ローカルファイルやDocker環境が必要か？
YES → GitHub Actions しかない
NO → 次へ
判断2: 既存のCI/CDパイプラインに組み込む必要があるか？
YES → GitHub Actions の方が自然（既存ワークフローとの連携）
NO → 次へ
判断3: 自然言語で指示したい・プロンプトで制御したい？
YES → Routines
NO → GitHub Actions（シェルスクリプトの方が確実な場合）
判断4: APIコストを直接制御したい？
YES → GitHub Actions（claude-code-actionでAPIを直接叩く）
NO → Routines（プランの使用量内で自動管理）使い分けの実例
Routinesが適している:
- GitHubのIssue/PRをスキャンして整理する定期処理
- ドキュメントとコードの整合性チェック（週次）
- バックログの自動ラベリング・担当者割り当て
- 外部APIからのイベントを受けてPRを自動作成（APIトリガー）
GitHub Actionsが適している:
- テストの実行・CI（ローカルでのビルド・テストが必要）
- セキュリティスキャン（Snyk、OWASP等との連携）
- デプロイパイプライン（環境変数・Secretsの複雑な管理）
@claudementionでPR上のコードレビューを依頼する
両方使う構成:
# GitHub Actionsでデプロイ → APIトリガーでRoutineを呼ぶ
steps:
- name: Deploy
run: ./deploy.sh
- name: Trigger smoke test Routine
run: |
curl -X POST https://api.anthropic.com/v1/claude_code/routines/${{ secrets.ROUTINE_ID }}/fire \
-H "Authorization: Bearer ${{ secrets.ROUTINE_TOKEN }}" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d "{\"text\": \"deploy completed: ${{ github.sha }}\"}"GitHub ActionsでデプロイしてからRoutineのAPIトリガーを叩く構成は、「CIはActionsで管理、AIによる検証はRoutinesで」と役割を分けられる。
まとめ: 失敗から学んだ安全Routinesの設計
Routinesは「設定した瞬間から自律的に動く」ことが強みであり、ミスが起きたときに「設定した瞬間から意図しない動作が続く」リスクでもある。
一人運用でRoutinesを安全に使うための核心は3つ。
コネクタを絞る: デフォルトの全有効から、「このRoutineが必要とするコネクタのみ」に削る。最小権限はコードだけでなくAIエージェントにも適用すべき原則だ。
Slack通知を絶対入れる: サイレント失敗が一番怖い。全RoutineのプロンプトにSlack通知を入れることで、「通知が来なかったら何かおかしい」という検知ができる。
Routineはclaude/ブランチ止まり: main等への直接プッシュを許可しない。「AIが提案、人間が判断」の分業ラインを守ることで、意図しない本番影響を防ぐ。
Routinesは「使い始め」よりも「継続運用」の設計が難しい。最初は1本だけシンプルなRoutineを設定して、失敗パターンを自分の環境で確かめてから本数を増やすのが安全だ。
新しいRoutineを作る前に確認する:
□ 必要なコネクタだけ有効にした？不要なものを削除した？
□ プロンプトにアクセス範囲と「触ってはいけないもの」を明記した？
□ プロンプト末尾にSlack通知が入っている？
□ Allow unrestricted branch pushes は本当に必要か？デフォルトで足りるはず
□ Proの日次5回上限を超えないか？超えるなら統合か、Maxプランか
関連記事
よくある質問
Q. Routinesのリサーチプレビューが終わったら仕様が変わるか？
変わる可能性があります。現在（2026年6月）はリサーチプレビュー段階で、日次実行上限・API形式・ベータヘッダーはすべて変更される可能性があります。特にAPIトリガーの experimental-cc-routine-2026-04-01 ベータヘッダーは、正式版では変わります。公式ドキュメント（code.claude.com）を定期的に確認してください。
Q. Routineが実行途中でクラッシュしたらどうなるか？
Anthropicのインフラエラーの場合、実行リストにエラーステータスが記録されます。Routineのプロンプトで指示したタスクが途中で失敗した場合（GitHubの権限エラー等）は、インフラとしては「正常終了」扱いになります。ログを読まないとわからないため、Slack通知でタスク完了確認を入れることが重要です。
Q. 1つのRoutineに複数のGitHubリポジトリを設定できるか？
はい、できます。Routine作成時に複数リポジトリを追加できます。各リポジトリは実行開始時にクローンされます。ただし、リポジトリが増えるほど1回の実行時間が長くなるため、プランの使用量消費が増えます。
