0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ennagara128

Claude Code の Routines で定期パフォーマンスチューニング自動化 — 寝てる間にコードが磨かれる運用パターン

0
Posted at

はじめに

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と人間の役割分担を実装に落とすパターン です。

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?