Claude Code Routines で定期的にパフォーマンスチューニングさせる（1回1改善・数値で判定）

どんな場面で使う？

• ベンチマークとテストが揃っていて、デグレを機械的に検出できるリポジトリ
• 「思いついても面倒でやらない」-2〜3%の地味な改善を積み上げたいとき
• 同じ発想で、ライブラリ更新・OpenTelemetry を見た API の性能改善・スキルの改善・ベストプラクティスの適用なども定期実行に回せる（@suthio_）

プロンプトの骨組み（@yamadashy の例を要約）

冒頭に設定を置き、手順をチェックリストにする。

• 設定: 作業ブランチ（例 perf/auto-perf-tuning）、ベースブランチ、対象フォルダ、PRタイトル、改善指標（例「実行全体の2%以上」）、調査サブエージェント数（5）とモデル（sonnet）
• 方針: 振る舞いは変えず、性能かメモリだけを改善する
• 手順:
  1. 作業ブランチを用意し、ベースが進んでいればマージ
  2. 既存PRの説明とレビューコメントを読む
  3. 構造を把握 → 重ならない調査範囲を自分で決めて5並列のサブエージェントに調べさせる（クリティカルパス、I/O、データ構造、並列化、依存の初期化コストなど）
  4. 改善は1つだけに絞る。指標を満たす案がなければ報告して終了
  5. 実装 → ベンチマーク → lint・test。指標未達なら revert して終了
  6. perf プレフィックスでコミット、本文にベンチ結果
  7. ローカルでサブエージェントにレビューさせ、amend で1コミットに保つ
  8. 1つの Draft PR に積み上げる

取り込み方

• 自動PRはそのままマージしない（ときどきデグレや、改善のわりに大きな変更が混ざる）
• PR上のベンチ履歴で効果の大きいコミットを選び、「main からこの変更を再実装して PR にして」と別に頼む
• CI でも PR と main を別々にビルドして3 OS で計測し、PR にコメントさせる。main は github-action-benchmark で gh-pages に時系列を残す

注意点

• ベンチマーク基盤づくりが先。測れないものは任せない
• 伸びしろが減ると空振りが増える。費用と相談して頻度を下げる
• 関連: Claude Code Routines で「エラーログ監視→修正PR→別Claudeがレビュー→デプロイ」を自動で回す、skill は定期リファクタとテストで「確率的な挙動」を抑える、会話履歴からスキルの改善点を Issue 化し、Routines で毎日直させる

出典

• @yamadashy 2026-04-28（記事「Claude Codeのルーチン機能で定期的にパフォーマンスチューニングをさせている」）: @yamadashy · 2026-04-28
• 記事: zenn.dev
• @suthio_ 2026-04-05（定期実行させているタスクの例）: @suthio_ · 2026-04-05