コーディング

React の不要な再レンダリングを検出するプロンプト

いつ使うか

React アプリが画面遷移時に妙に重い、入力欄が一文字ごとにラグる——その時に Component ツリーと state 構造を AI に渡して、再レンダリング地獄の発生源を特定させる。React DevTools の Profiler 結果と組み合わせると精度が一段上がる。

プロンプト本文 (コピペして使う)

あなたは React パフォーマンスの専門家です。以下のコードから不要な再レンダリングを検出し、改善案を出してください。

## 対象コンポーネント
```tsx
<該当の親+子コンポーネントを貼る>
```

## 観察事項
- 重いと感じる操作: <例: 入力欄の onChange、リストの hover>
- DevTools Profiler の結果: <render 回数や時間>
- 状態管理: <useState / useReducer / Zustand / Redux>

## 検査観点
1. **参照同一性の崩壊** (props で渡される object/array/function が毎回新規)
2. **過剰な useEffect 依存配列** (state を effect で別 state にコピー)
3. **Context の粒度** (1つの Context に多くの値を詰め込んで全 subscriber が再描画)
4. **memo 化忘れ** (重い計算が render ごと実行)
5. **key の不安定さ** (index を key にしてリスト全体が remount)
6. **state の場所** (深い親で持つべきでない state が高い位置にある)

## 出力
1. 検出した問題点とそのコード行 (3つまで)
2. 各問題の修正コード (before/after)
3. useMemo / useCallback / React.memo の使い分け判断
4. Context を分割すべきか、Zustand 等に逃がすかの判断
5. 確認方法 (React DevTools で何を見れば改善を確認できるか)

## 禁止
- 全部 useMemo で囲うような雑な提案
- 計測なしの「これで速くなる」断定

効くポイント

  1. 6つの観点を渡すと、useMemo を雑に追加するだけの回答にならない
  2. memo化系API の使い分け判断まで要求すると、過剰最適化を防げる
  3. 確認方法を聞くと、改善効果を実測できる流れに繋がる

関連プロンプト

よくある質問

React DevTools Profiler の結果は必須ですか?
必須ではありませんが、貼ると AI の仮説精度が一段上がります。Profiler が使えない環境では、代わりに「重いと感じる操作」と「state の更新箇所」を箇条書きで渡すと代替になります。
useMemo / useCallback を全部に付けたほうがいい?
いいえ、過剰最適化は読みづらさを増やすだけです。このプロンプトは「memo 化系 API の使い分け判断まで要求する」設計なので、AI が「ここは不要」と判定したものは付けない方が保守性が上がります。
Server Components (Next.js App Router) でも使えますか?
Client Components 部分には適用できます。Server Components は再レンダリングの概念自体が異なるため、Next.js App Router 用の別プロンプトと併用するのが現実的です。
改善後の効果を測る具体的な方法は?
React DevTools Profiler の record で「修正前のフレーム数」と「修正後のフレーム数」を比較するのが最も簡単です。本番では Web Vitals (INP) の改善で間接的に効果を確認できます。

このプロンプトを実戦で使った所感や改善案があればぜひフィードバックを。姉妹サイト ai-pick.tech では AI x SNS集客の運用ノウハウを公開しています。