version: "1.0.0" name: performance-optimization description: アプリケーションの性能問題を計測ファーストで特定・改善するスキル。「遅い」「重い」「タイムアウトが多発する」など性能要件を満たせていないときや、リリース前の負荷試験を実施するときに使う。

パフォーマンス最適化

目的

計測に基づいて真のボトルネックを特定し、最小限の変更で性能目標を達成する。 推測による場当たり的な改修を排除し、施策の効果を定量的に検証する。

使うタイミング

• レスポンスタイム・スループット・エラーレートが[[non-functional-requirements]]で定めた目標値を下回るとき
• 本番でスロークエリ・タイムアウト・OOMが頻発しているとき
• リリース前に想定ピーク負荷への耐性を確認したいとき
• コードレビューや[[refactoring]]の際に性能リグレッションの懸念が生じたとき

鉄則

1. 推測するな、計測せよ — 「たぶんここが遅い」で改修しない。必ずプロファイラ・APMのデータを根拠にする
2. 目標なき最適化はしない — [[non-functional-requirements]]で合意した数値目標(例: p95 < 200ms)が起点。目標達成後は止める
3. 早すぎる最適化は諸悪の根源 — まず動くものを作り、遅い場所だけ直す
4. 1施策ずつ適用して前後比較 — 複数施策を同時に当てると効果の切り分けができなくなる
5. 本番相当の環境・データ量で計測 — 開発環境の少量データでは性能問題は再現しない
6. 平均でなくパーセンタイルで見る — p50だけでなくp95/p99を必ず確認する

進め方

1. 目標の確認 — [[non-functional-requirements]]から計測対象のKPI(レイテンシ/スループット/エラーレート)と目標値を確認する
2. 計測環境の整備 — 本番相当のデータ量・負荷を再現できる環境を用意する
3. ベースライン計測 — プロファイラ・APM・負荷テストツールで現状を数値化する(p50/p95/p99を記録)
4. ボトルネック特定 — フレームグラフ・スロークエリログ・EXPLAINの結果から最大のボトルネックを1つ特定する
5. 施策の立案と優先順位付け — 改善インパクト・実装コスト・リスクで施策を並べる
6. 1施策を実装 — 最優先の施策を実装する([[implementation]]参照)
7. 再計測・前後比較 — 同条件で再計測し、ベースラインと比較する
8. 目標達成の判定 — 達成なら終了。未達なら次のボトルネックへ戻る
9. 負荷テスト(リリース前) — 想定ピークの2〜3倍で限界スループットと限界レイテンシを把握する
10. 改善レポートの作成 — 下記テンプレートで成果を記録する

定番ボトルネックと定石

キャッシュ設計の注意点

キャッシュは「最後の手段」ではなく「副作用が最大の手段」として扱う。

• 階層を整理してから導入: ブラウザ → CDN → アプリ(インメモリ/Redis) → DB(クエリキャッシュ)
• 無効化戦略を先に決める("キャッシュの無効化は計算機科学の二大難問")。更新時パージ・TTL・バージョニングのどれを使うか明示する
• TTLの根拠を記録する(「なんとなく5分」は不可)
• キャッシュヒット率・ミス率を[[monitoring-operations]]で観測する

成果物テンプレート

# 性能改善レポート
 
## 目標
-対象: [エンドポイント / 機能名]
-KPI: p95 レスポンスタイム < Xms、スループット > Y rps、エラーレート < Z%
 
## 計測条件
-環境: [本番 / ステージング / ローカル]
-データ量: [件数・サイズ]
-負荷条件: [同時ユーザー数・RPS・テストツール(k6等)]
 
## ボトルネック一覧
 
| # | 内容 | 根拠 | 推定インパクト |
|---|------|------|----------------|
| 1 | N+1クエリ (UserController#index) | スロークエリログ: 1リクエストあたり51クエリ | 大 |
| 2 | ... | ... | ... |
 
## 実施した施策
 
| # | 施策 | 変更箇所 |
|---|------|---------|
| 1 | User.includes(:posts) に変更 | app/controllers/users_controller.rb |
 
## 前後比較
 
| 指標 | 改善前 | 改善後 | 変化率 |
|------|--------|--------|--------|
| p50  | 320ms  | 45ms   | -86%   |
| p95  | 980ms  | 120ms  | -88%   |
| p99  | 2100ms | 310ms  | -85%   |
| エラーレート | 2.1% | 0.0% | - |
 
## 目標達成判定
-[x] p95 < 200ms → 120ms で達成
 
## 残課題
-キャッシュ導入(優先度: 低、次スプリントで検討)

チェックリスト

• [ ] 性能目標(p95/p99の数値)が[[non-functional-requirements]]に記載されている
• [ ] 本番相当のデータ量・環境でベースラインを計測した
• [ ] p50だけでなくp95・p99を記録した
• [ ] 最大のボトルネックを1つ特定し、根拠(ログ・プロファイル)を残した
• [ ] 施策は1つずつ適用し、前後の数値を比較した
• [ ] キャッシュを導入する場合、無効化戦略とTTLの根拠を記録した
• [ ] 想定ピーク負荷での負荷テストを実施した
• [ ] 目標達成後に最適化を停止した
• [ ] 改善レポートをレビュー可能な状態で残した

アンチパターン

• 推測ドリブンの改修: 計測せず「たぶんここが遅い」でコードを変更する
• 複数施策の同時適用: 効果の切り分けができなくなり、悪化した施策を特定できない
• 無効化戦略なしのキャッシュ: 古いデータが表示され続けるバグの温床になる
• 開発環境での計測: 少量データでは本番のN+1やフルスキャンが再現しない
• 平均値のみ監視: 外れ値に苦しむユーザーを見落とす
• 目標達成後も最適化を続ける: 可読性・保守性のコストが増大する
• ミクロ最適化への執着: ループ1つのマイクロ秒短縮より、N+1の解消やインデックス追加の方が桁違いに効く

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

関連スキル

• [[non-functional-requirements]] — 性能目標の定義元。目標値なき最適化はしない
• [[database-design]] — インデックス設計・クエリ最適化の詳細
• [[monitoring-operations]] — 本番の継続的な性能監視・アラート設定
• [[refactoring]] — 可読性と性能のトレードオフを判断する際の参考
• [[testing]] — 負荷テストのシナリオ設計・CI組み込み
• [[architecture-design]] — キャッシュ階層・非同期化など構造的改善の設計
• [[code-review]] — 性能リグレッションの早期検出
• [[cicd-deployment]] — 性能テストのパイプライン組み込み