Performance Optimization

パフォーマンス最適化スキル

スタック全体にわたってアプリケーションのパフォーマンスを分析・最適化するための包括的なフレームワークです。

概要

• アプリケーションの動作が遅い、または応答しない
• データベースクエリに時間がかかる
• フロントエンドのバンドルサイズが大きすぎる
• API の応答時間が目標を超えている
• Core Web Vitals の改善が必要
• スケールアップや高トラフィックへの対応準備

パフォーマンス目標

Core Web Vitals（フロントエンド）

指標	良好	改善が必要
LCP（Largest Contentful Paint）	< 2.5s	< 4s
INP（Interaction to Next Paint）	< 200ms	< 500ms
CLS（Cumulative Layout Shift）	< 0.1	< 0.25
TTFB（Time to First Byte）	< 200ms	< 600ms

バックエンドの目標

操作	目標
単純な読み取り	< 100ms
複雑なクエリ	< 500ms
書き込み操作	< 200ms
インデックス検索	< 10ms

ボトルネックのカテゴリ

カテゴリ	症状	ツール
ネットワーク	TTFB が高い、読み込みが遅い	Network タブ、WebPageTest
データベース	クエリが遅い、コネクションプールの枯渇	EXPLAIN ANALYZE、pg_stat_statements
CPU	使用率が高い、計算が遅い	プロファイラー、フレームグラフ
メモリ	リーク、GC の一時停止	ヒープスナップショット
レンダリング	レイアウトの頻繁な再計算	React DevTools、Performance タブ

---

プロトコルリファレンス

データベースの最適化

参照先：references/database-optimization.md

主なトピック：

• SQLAlchemy の selectinload を使った N+1 クエリの検出と修正
• インデックス選択戦略（B-tree、GIN、HNSW、Hash）
• EXPLAIN ANALYZE の解釈
• コネクションプーリングの設定
• カーソル方式とオフセット方式のページネーション

キャッシュ戦略

参照先：references/caching-strategies.md

主なトピック：

• マルチレベルキャッシュ階層（L1-L4）
• キャッシュ・アサイドとライトスルーのパターン
• キャッシュ無効化戦略（TTL、イベントベース、タグベース）
• Redis のパターン（文字列、ハッシュ、リスト、セット）
• キャッシュスタンピードの防止
• HTTP キャッシュヘッダーと ETag

Core Web Vitals

参照先：references/core-web-vitals.md

主なトピック：

• LCP の最適化（画像、SSR、クリティカル CSS）
• INP の最適化（デバウンス、Web Workers、タスク分割）
• CLS の最適化（画像の寸法、フォント読み込み）
• web-vitals ライブラリを使った測定
• Lighthouse による監査

フロントエンドのパフォーマンス

参照先：references/frontend-performance.md

主なトピック：

• React.lazy() を使ったコード分割
• ツリーシェイキングとインポートの最適化
• 画像の最適化（WebP、AVIF、遅延読み込み）
• メモ化（memo、useMemo、useCallback）
• @tanstack/react-virtual によるリストの仮想化
• バンドル分析ツール

プロファイリングツール

参照先：references/profiling.md

主なトピック：

• Python のプロファイリング（cProfile、py-spy、memory_profiler）
• Chrome DevTools の Performance タブと Memory タブ
• React DevTools Profiler
• PostgreSQL クエリのプロファイリング（pg_stat_statements）
• フレームグラフの解釈
• k6 と Locust による負荷テスト

---

クイック診断

データベース

-- Find slow queries (PostgreSQL)
SELECT query, calls, mean_time / 1000 as mean_seconds
FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;

-- Verify index usage
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 123;

フロントエンド

# Lighthouse audit
lighthouse http://localhost:3000 --output=json

# Bundle analysis
npx vite-bundle-visualizer  # Vite
ANALYZE=true npm run build  # Next.js

バックエンド

# Profile running FastAPI server
py-spy record --pid $(pgrep -f uvicorn) --output profile.svg

---

モニタリングチェックリスト

リリース前

• Lighthouse スコア > 90
• Core Web Vitals に合格
• バンドルサイズが予算内
• データベースクエリのプロファイリングを実施
• 圧縮を有効化
• CDN を設定

継続的な確認

• パフォーマンスモニタリングが有効
• パフォーマンス低下のアラートを設定
• パイプラインに Lighthouse CI を導入
• 毎週クエリを分析
• リアルユーザーモニタリング（RUM）

---

実例

ハイブリッド検索の最適化

問題： 検索結果の合格率は 87.2％で、90％超が必要でした

解決策： RRF の取得倍率を 2x から 3x に引き上げ、メタデータのブースティングを追加しました

結果：

• 合格率：87.2% -> 91.6% (+5.1%)
• MRR：0.723 -> 0.777 (+7.4%)
• クエリ時間：85ms -> 5ms（HNSW インデックス）

LLM レスポンスのキャッシュ

問題： LLM のコストが年間 35k ドルに達すると予測されていました。

解決策： マルチレベルのキャッシュ階層（Claude のプロンプトキャッシュ + Redis セマンティックキャッシュ）

結果：

• ベースライン：年間 35k ドル -> キャッシュ導入後：年間 2～5k ドル
• コスト削減：85～95%
• レイテンシ：2000ms -> 5～10ms（セマンティックキャッシュのヒット時）

ベクトルインデックスの選択

問題： ベクトル検索に 85ms かかっており、<10ms が必要でした。

解決策： IVFFlat から HNSW インデックスに切り替えました。

結果：

• クエリ時間：85ms -> 5ms（17 倍高速）
• トレードオフ：クエリを高速化する代わりに、インデックス作成が遅くなります（8s 対 2s）

---

テンプレートのリファレンス

テンプレート	目的
database-optimization.ts	N+1 の修正、ページネーション、プーリング
caching-patterns.ts	Redis のキャッシュアサイド、メモ化
frontend-optimization.tsx	React のメモ化、仮想化、コード分割
api-optimization.ts	圧縮、ETag、フィールド選択
performance-metrics.ts	Prometheus メトリクス、パフォーマンスバジェット

---

拡張思考のトリガー

次の場合は Opus 4.5 の拡張思考を使用します。

• 複雑なデバッグ - 原因が複数考えられる場合
• アーキテクチャの決定 - キャッシュ戦略の選択
• トレードオフの分析 - メモリ、CPU、レイテンシの比較
• 根本原因の分析 - パフォーマンス低下の調査

---

関連スキル

• caching-strategies - Redis の詳細なキャッシュパターンとキャッシュ無効化
• database-schema-designer - インデックス戦略とクエリ最適化の基本
• observability-monitoring - パフォーマンス監視とアラートの統合
• devops-deployment - CDN の設定とインフラストラクチャの最適化

主要な決定事項

決定事項	選択	理由
ページネーション戦略	大規模なデータセットにはカーソルベース	オフセットに左右されない安定したパフォーマンスを実現し、同時挿入にも対応
ベクトルインデックスの種類	IVFFlat より HNSW	クエリが 17 倍高速。読み取り中心のワークロードでは、インデックス作成が遅くても価値があります
キャッシュ階層	マルチレベル（L1～L4）	ヒット率を最適化し、コストの高い処理への負荷を軽減
バンドル分割	ルートベースのコード分割	初期読み込みを減らし、並列ダウンロードを可能にします

---

スキルのバージョン: 1.2.0 最終更新日: 2026-01-15 メンテナンス担当: AI Agent Hub Team

変更履歴

v1.2.0 (2026-01-15)

• リファレンスベースの構成にリファクタリング
• 詳細な内容を references/ ディレクトリに移動
• SKILL.md を 1079 行から約 290 行に削減

v1.1.0 (2025-12-25)

• 包括的なフロントエンドバンドル分析のセクションを追加
• React 19 のパフォーマンスパターンを追加
• TanStack Virtual によるリスト仮想化を追加

v1.0.0 (2025-12-14)

• データベース最適化、キャッシュ、プロファイリングを含む初期スキル

---

機能の詳細

database-optimization

キーワード： 遅いクエリ、n+1、クエリ最適化、explain analyze、インデックス、postgres のパフォーマンス 解決できること：

• 遅いデータベースクエリを最適化するには？
• Eager Loading で N+1 クエリの問題を修正する
• EXPLAIN ANALYZE を使ってクエリを診断する
• パフォーマンス向上のために不足しているインデックスを追加する

caching-strategies

キーワード： キャッシュ、redis、cdn、キャッシュアサイド、ライトスルー、セマンティックキャッシュ 解決できること：

• マルチレベルキャッシュを実装するには？
• キャッシュアサイドとライトスルーパターン
• LLM レスポンス向けのセマンティックキャッシュ
• キャッシュ無効化戦略

frontend-performance

キーワード： バンドルサイズ、遅延読み込み、コード分割、ツリーシェイキング、lighthouse、web vitals 解決できること：

• フロントエンドのバンドルサイズを小さくするには？
• React.lazy() でコード分割を実装する
• Lighthouse のスコアを最適化する
• Core Web Vitals の問題を修正する

core-web-vitals

キーワード： lcp、inp、cls、core web vitals、ttfb、fid 解決できること：

• Core Web Vitals を改善するには？
• LCP（Largest Contentful Paint）を最適化する
• CLS（Cumulative Layout Shift）を修正する
• INP（Interaction to Next Paint）を改善する

プロファイリング

キーワード： profile、flame graph、py-spy、chrome devtools、memory leak、cpu bottleneck 解決できること：

• Python のバックエンドをプロファイリングするには？
• py-spy でフレームグラフを生成する
• DevTools で React コンポーネントをプロファイリングする
• フロントエンドのメモリーリークを見つける

バンドル分析

キーワード： bundle analyzer、vite visualizer、webpack bundle、tree shaking 解決できること：

• バンドルサイズを分析するには？
• Vite のバンドルビジュアライザーを使用する
• サイズの大きい依存関係を特定する
• ツリーシェイキングでバンドルを最適化する