はじめに

Claude Code の Routines 機能を使うと、人間が指示しなくても、AIが定期的に決まったタスクを回す 運用が組めます。

実務で一番効くのは、夜中や週末に "コードベース改善" を Claude Code に走らせておく 運用です。

朝起きると、

「重複コードがあったので統合PRを作りました」
「未使用の依存パッケージを 3 個削除する PR を出しました」
「テストカバレッジが低い領域に対してテストを追加する PR を作成しました」

という通知が並ぶ。寝てる間にコードベースが磨かれる 状態です。

本記事では、Routines を使って「定期パフォーマンスチューニング自動化」を組む実践パターンを共有します。

なぜ Routines か

普段 Claude Code を使っていると、こんな問題が出てきます：

リファクタリングや依存パッケージのアップデートは「やらなきゃ」と思いつつ、後回しになる
パフォーマンスチューニングは、計測 → 仮説 → 実装 → 検証のサイクルで時間がかかる
ローカルの未使用ファイル・dead code は気づかないまま蓄積していく

これらは 「重要だけど緊急じゃない」タスク群 で、人間がトリガーを引かないと永遠に放置される。

Routines に組み込んで Claude Code に 定期的に回してもらう ことで、この層のタスクを潰せます。

設計パターン1: 週次「重複コード検出 → 統合PR」

// .claude/routines.json
{
  "routines": [
    {
      "name": "weekly-deduplication",
      "schedule": "0 3 * * 1",  // 毎週月曜日 03:00 (UTC)
      "trigger": "scheduled",
      "task": [
        "1. apps/web/components/ 配下の React コンポーネントを全部読み込み、",
        "   構造的に類似している（80%以上のコードが同じ）ペアを検出してリストアップ",
        "2. 検出したペアごとに、共通化できる props 設計を提案",
        "3. もっとも統合効果が大きいペアについて統合PRを作成",
        "4. PRの本文に、Before/After のコード例と、削減できた行数を記載",
        "5. PRのラベルに refactor/auto を付与"
      ],
      "permissions": {
        "allow": ["Bash(git checkout:*)", "Bash(git add:*)", "Bash(git commit:*)", "Bash(gh pr create:*)"]
      }
    }
  ]
}

ポイントは：

週1回 に絞る（毎日だとPRが氾濫する）
1回1PR に制限（複数同時提案は人間がレビューできなくなる）
ラベル refactor/auto で自動生成PRと識別できるようにする

設計パターン2: 日次「未使用依存パッケージの削除提案」

{
  "name": "daily-unused-deps-check",
  "schedule": "0 4 * * *",  // 毎日 04:00 (UTC)
  "trigger": "scheduled",
  "task": [
    "1. package.json の dependencies / devDependencies をすべてリストアップ",
    "2. 各パッケージについて、リポジトリ内で実際に import されているかを grep で検索",
    "3. 30日以上 import がない依存があれば、削除候補としてリストアップ",
    "4. 候補が3個以上あれば、まとめて削除PRを作成",
    "5. PRの本文に、各パッケージが「いつから使われていないか」を記載"
  ],
  "permissions": {
    "allow": ["Bash(npm uninstall:*)", "Bash(git:*)", "Bash(gh pr:*)"],
    "deny": ["Bash(npm install --save:*)"]
  }
}

注意点：

npm uninstall だけ allow、npm install --save を deny にして「削除専用ジョブ」と明確にする
30日の閾値は実務感覚。短すぎると振動的（増えたり減ったり）になる

設計パターン3: 月次「テストカバレッジ低い領域へのテスト追加」

{
  "name": "monthly-test-coverage-boost",
  "schedule": "0 5 1 * *",  // 毎月1日 05:00 (UTC)
  "trigger": "scheduled",
  "task": [
    "1. npm run test:coverage を実行してカバレッジレポートを生成",
    "2. カバレッジが 50% を下回っているファイルを抽出（最大5ファイル）",
    "3. 各ファイルについて、ビジネスロジックの中核となる関数を特定",
    "4. その関数に対してユニットテストを追加するPRを作成",
    "5. PRの本文に、追加前後のカバレッジ差分を記載"
  ]
}

これは「テスト書くの後回し問題」の特効薬。月1回 Claude Code がテストを書き溜めてくれる構成。

運用上の注意：「Routines を信頼しすぎない」

Routines は便利ですが、過信すると痛い目に遭います。

ガードレール1: PRは必ず人間レビュー

Routines が作るPRに対しては、自動マージは絶対にしない。

人間レビューを必須化することで：

AIの暴走を1段階で止められる
何が変わったかを把握する機会が残る
コードベースの理解が薄まらない

ガードレール2: schedule は深夜帯に固定

UTC基準で 03:00〜05:00 あたりに固定します。理由は：

開発者がオフラインの時間帯
API レート制限のピークを避けられる
もし暴走しても、朝のスタンドアップで気づける

ガードレール3: PR数の上限を設定

{
  "global": {
    "max_open_routine_prs": 5
  }
}

これを超えたら新規PRは作らない、というポリシー。レビュー渋滞を防ぎます。

効果測定：何が変わったか

私のチームで Routines を 2ヶ月運用して感じた変化：

指標	導入前	導入後
未使用依存の数	平均 12 個	平均 3 個
重複コンポーネント	平均 8 ペア	平均 2 ペア
テストカバレッジ	52%	71%
「リファクタしたいけど時間がない」のストレス	高	ほぼゼロ

時間を取られない代わりに、コードベースが勝手に磨かれていく感覚。人間レビューの工数だけ少し増える トレードオフですが、十分ペイします。

まとめ

Claude Code の Routines は「重要だけど緊急じゃない」タスクの自動化に最適
週次の重複検出、日次の未使用依存削除、月次のテスト追加を仕込む
ガードレール: PR は必ず人間レビュー / 深夜帯にスケジュール / PR数上限を設ける
AIに任せる範囲・人間が握る範囲の線引きを意識的に設計するのがコツ

これは単なる「自動化テクニック」ではなく、AIと人間の役割分担を実装に落とすパターン です。

関連: 教材で手を動かして学ぶ

まず無料で試したい方: 教材の体験版を GitHub で配布中（git clone してすぐ動かせます） → https://github.com/ayies128/next-ai-camp-trial
全20セッション完全版＋メンタリング → https://menta.work/plan/20251
YouTubeチャンネル → https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/