| name | performance |
| description | This skill should be used when the user asks to "optimize performance", "reduce bundle size", "fix slow rendering", or mentions "パフォーマンス", "最適化", "バンドルサイズ", "メモリリーク", "再レンダリング". Measurement-first approach. Covers bundle optimization, rendering, state management, memory/storage management. Takes optional argument: /performance <target-component or instruction>
|
| argument-hint | <対象コンポーネント or 指示> |
| allowed-tools | Read, Glob, Grep, Edit, Write, Bash(git *), WebSearch, WebFetch, Agent, mcp__context7__resolve-library-id, mcp__context7__query-docs |
| context | main |
Performance Optimization
計測ファーストのアプローチでパフォーマンス最適化を実施する。
CLAUDE.md の方針を厳守すること。プロジェクト固有のコードパターンは docs/development-patterns.md を参照。
前提条件
| 参照ファイル | 用途 | スタブ時のフォールバック |
|---|
docs/project.md | コマンド | project-config.md §3 を直接参照 |
docs/development-patterns.md | パフォーマンスパターン | project-config.md §2, §11 を直接参照 |
基本姿勢
- 計測なき最適化は行わない — 推測ではなくデータに基づく
- 最適化前後の数値を必ず比較する（Before/After）
- 可読性を犠牲にする最適化は最終手段
- 過剰な最適化を避ける（体感可能な改善がない場合は見送る）
- 既存テストを壊さない
使い方
/performance <対象コンポーネント or 最適化指示>
引数は省略可能。省略した場合はユーザーに対話的に確認する。
ファイルパスを指定した場合はそのファイル周辺のパフォーマンスを分析する。
例
/performance ダッシュボードの初期表示が遅い
/performance src/features/assignment/components/AssignmentTreeGrid.tsx
/performance バンドルサイズを最適化する
出力先
- 最適化コード:
src/ 配下（プロジェクトのディレクトリ構成に従う）
- レポート: 会話内で提示（計測ツールの生データは
testreport/perf/ に保存）
他スキルとの連携
| 前工程 | 本スキル | 後工程 |
|---|
/implementing-features | /performance | /code-review |
最適化カテゴリ
1. バンドル最適化
- バンドル分析ツールでバンドル構成を可視化
- 動的インポートによるコード分割
- tree-shaking の確認（副作用のある import を排除）
- ビルドサイズを計測
2. レンダリング最適化
- プロファイラーでボトルネックを特定
- メモ化（フレームワーク提供のメモ化API）の適切な使用
- 不要な再レンダリングの検出と排除
- コンポーネント分割による再レンダリング範囲の最小化
注意: メモ化は実測でボトルネックが確認された場合のみ追加する。予防的なメモ化は行わない。
3. 状態管理最適化
docs/development-patterns.md に記載された状態管理のアンチパターンを回避する- 個別フィールドの購読（オブジェクト全体ではなく必要なフィールドのみ）
- 状態更新の最小化
4. メモリ・ストレージ管理
- ストレージクォータ監視
- 大規模データの分割保存戦略
- 不要データのクリーンアップ
最適化ワークフロー
- ボトルネック特定 — ユーザー報告または計測ツールで問題箇所を特定
- ベースライン計測 — 最適化前の数値を記録
- 原因分析 — プロファイリング結果から根本原因を特定
- 🚏 分析ゲート — ボトルネックと最適化方針を提示し、確認を待つ
- 最適化実装 — 影響範囲を最小限に抑えた変更を行う
- 効果検証 — 最適化後の数値を計測し、Before/After を比較
- テスト確認 — プロジェクトの検証コマンド（
docs/project.md 参照）を実行
- 🚏 完了ゲート — 効果レポートを提示
出力契約
🚏 分析ゲート出力
| フィールド | 型 | 必須 | 制約 |
|---|
| ボトルネック箇所 | ファイルパス:行番号 | ✅ | 計測データに基づく特定 |
| 計測値 | 数値+単位 | ✅ | 推測値は不可。計測方法を明記 |
| 原因分析 | テキスト | ✅ | 根本原因を1〜3文で説明 |
| 最適化方針 | 箇条書き | ✅ | 実施する最適化を優先順に列挙 |
| 予想改善効果 | テキスト | 条件付き | 定量的に見積もれる場合 |
🚏 完了ゲート出力
| フィールド | 型 | 必須 | 制約 |
|---|
| Before/After比較 | テーブル | ✅ | 指標名, Before値, After値, 改善率 |
| テスト結果 | X pass / Y fail | ✅ | |
| カバレッジ | 行: X% / 分岐: Y% | ✅ | ベースラインとの差分 |
| 静的解析 | エラー: X件 | ✅ | |
語彙制約
| 用語 | 定義 |
|---|
| ベースライン | 最適化前の計測値。比較の基準 |
| ボトルネック | 計測によって特定された性能劣化の主因 |
| 改善率 | (Before - After) / Before × 100（%表記） |
| 体感改善 | ユーザーが知覚可能な応答速度の変化 |
構造制約
- Before/Afterテーブルの指標は同一条件で計測すること
- 計測値には必ず単位を付記する（KB, ms, 回, 件）
- 「推測」「おそらく」による最適化判断は記載禁止
PASS条件: Before/After 全指標が改善(悪化した指標がある場合は理由を明記)/ テスト・静的解析がベースラインと同数以上パス / 計測値なしの最適化提案が0件。
レポートフォーマット
# パフォーマンス最適化レポート: [対象の概要]
## 概要
- 対象: [最適化した機能/コンポーネント]
- カテゴリ: バンドル / レンダリング / 状態管理 / メモリ
- 変更ファイル数: X
## ボトルネック分析
- 箇所: `ファイルパス:行番号`
- 計測値: [数値+単位]（計測方法: [方法]）
- 原因: [根本原因の説明]
## Before / After
| 指標 | Before | After | 改善率 |
| ---- | ------ | ----- | ------ |
| [指標名] | [値+単位] | [値+単位] | [X%] |
## 実施した最適化
1. [変更内容と理由]
## テスト結果
- テスト: X pass / Y fail
- カバレッジ: 行: X% / 分岐: Y%
- 静的解析: エラー 0件
## 注意事項
- [副作用やトレードオフがあれば記載]
ドキュメント同期
最適化による変更後、影響を受ける docs/ ファイルを必ず更新する。
| 変更内容 | 更新対象 |
|---|
| コードパターン・最適化パターンの発見 | docs/development-patterns.md |
| feature構成の変更（lazy load等） | docs/architecture.md |
| ストアの分割・統合 | docs/project.md |
| 依存パッケージの追加 | docs/project.md |
Git操作
--no-verify は使用禁止（pre-commit / pre-pushフックを迂回しない）- フック失敗時はエラーの原因を修正する
--force は原則禁止
禁止事項
- 計測なしでの最適化（「たぶん遅い」での着手禁止）
docs/development-patterns.md に記載されたアンチパターンの使用- 可読性を著しく損なうマイクロ最適化
- 既存テストを壊す変更
--no-verify によるフック迂回
関連参照(必要に応じて Claude が load)
@.claude/quality-gates.md
@.claude/pitfalls.md
