7.6 DevTools とデバッグ
「とりあえず動いたけど、何が起きているのかよく分からない」という状態から、「今この瞬間、どのコンポーネントがなぜ再レンダーされたのか」を追えるようになると、React の理解が一段階上がります。そのための道具が React DevTools と Chrome DevTools です。
この 2 つは役割が異なり、併用する のが定跡です。最初はどちらをいつ開けばいいかで迷うと思いますが、この章で整理していきます。
React DevTools の概要
React DevTools は React 公式のデバッグツールで、ブラウザ拡張として配布されています (react.dev/learn/react-developer-tools)。Chrome / Firefox / Edge 向けに用意されています。
- Chrome 版:
chromewebstore.google.com/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi - Firefox / Edge も同名の拡張があります（公式ページから各ストアにリンク）。
- Safari や、拡張を入れられない環境向けには、npm でスタンドアロン版 (
npm install -g react-devtools) もあります。
拡張をインストールして React アプリを開くと、ブラウザ DevTools に Components タブと Profiler タブが追加されます。
図 7.6.1 React DevTools が追加する 2 つのタブ
Components タブ
Components タブでは、実行中のアプリのコンポーネントツリーを React 視点で 見ることができます。
見えるもの:
- 各コンポーネントの名前（関数名がそのまま出ます）。
- そのコンポーネントに渡っている props。
- そのコンポーネントが保持している state / hooks の値。
- ツリー内の親子関係。
できること:
- props / state を その場で編集 して UI への影響を見る（公式ページの「Edit props and state」）。
- 特定のコンポーネントを選択し、DOM 要素を対応付けてハイライトする。
- コンポーネント名でツリーを検索する。
使い所:
- 「この子コンポーネントに props が届いていないのでは?」を、DOM を漁ることなく React 側から即確認できます。
- Context の値が期待どおり供給されているかを、Context を受け取るコンポーネント側で確認できます。
Profiler タブ
Profiler タブは、レンダリングのコストを可視化するツールです（公式: 「Identify performance problems」）。
操作フロー:
- Record ボタンを押して計測を開始します。
- アプリを操作します（クリック、入力など）。
- Stop を押して計測を終えます。
- 結果が炎グラフ (flame graph) とランキング表示で出ます。
分かるもの:
- どのコンポーネントが再レンダーされたか。
- 各コンポーネントのレンダーにかかった時間。
- そのレンダーが起きた理由（props が変わった、state が変わった、親が再レンダーされた）。
Part 4 の 4.6 パフォーマンス で扱った memo / useMemo / useCallback の効果を測るときに、Profiler が 定量的な根拠 になってくれます。
Chrome DevTools との連携
Chrome DevTools (developer.chrome.com/docs/devtools) は React に限らず Web 一般の開発ツールで、次の主要パネルがあります。
- Elements — DOM と CSS の確認・編集。
- Console — JS の実行と
console.logの出力。 - Sources — JS のステップ実行・ブレークポイント。
- Network — HTTP リクエストの確認。
- Performance — ランタイムパフォーマンス（Core Web Vitals: LCP / CLS / INP の分析）。
React で詰まったときの Chrome DevTools 側の主な使い途は、こんな感じです。
- Network: API レスポンスを見ます。ステータスコードが期待どおりか、ペイロードが正しいか、遅いリクエストがないか。
- Sources: コードにブレークポイントを置いてステップ実行します。
console.logを大量に撒くより、特定行で止めて変数を見る方が速いです。 - Elements: 最終的に DOM に何が出力されたか、CSS がどう適用されたかを見ます。
- Performance: 長いタスク (Long Task) が発生していないか、スクリプト実行時間が長すぎないか。
React DevTools と Chrome DevTools は 情報の粒度が違います。「React のツリー・props・state」は React DevTools、「ネットワーク・実 DOM・JS ステップ実行」は Chrome DevTools が担います。
図 7.6.2 デバッグツールの役割分担
よくあるデバッグパターン
現場で頻出する症状と、最初に開くべきタブの対応表です。
| 症状 | 最初に見るもの | 典型的な原因 |
|---|---|---|
useEffect が無限に走る | React DevTools (Components) で依存配列に入っている値を確認 | 依存配列にオブジェクト・配列リテラルを直接置いて毎レンダーで新規作成されている |
| 子コンポーネントに props が届かない | React DevTools (Components) で親側の props を確認 | 親がそもそも渡していない / 条件分岐で undefined になっている |
| 描画が重い / 遅い | React DevTools (Profiler) で再レンダー範囲と時間を計測 | 上位の Context が頻繁に変わり広範囲が再レンダーされている / 重いコンポーネントが memo されていない |
| データが取れない | Chrome DevTools (Network) | ステータス 401 / 404 / CORS エラー / 認証ヘッダ未送信 |
undefined が表示される | Chrome DevTools (Sources) でブレークポイント | データ取得前に描画していて、ローディング分岐が抜けている |
| クリックしても何も起きない | Chrome DevTools (Console) と React DevTools (Components) | イベントハンドラが undefined / 上の要素が pointer-events: none でクリックを奪っている |
図 7.6.3 症状から開くタブへの早見
図 7.6.4 デバッグの出発点
console.log とブレークポイントの使い分け
初学者は console.log を大量に撒くことが多く、それ自体は悪くありません。ただし、次の条件に当てはまるようなら、ブレークポイント（Chrome DevTools の Sources タブ）に切り替えた方が速く解決します。
- ログを入れては消して、ということを 3 回以上繰り返している。
- どの条件分岐に入ったのか、複雑で分からない。
- オブジェクトの中身を入れ子まで追いたい（log だと toString されて見づらい）。
ブレークポイントを置くと、その行で実行が止まり、スコープ内のすべての変数を Watch パネルで見られます。慣れるまでは console.log でもよいのですが、中級以上の案件では「最初から Sources でブレークポイント」が標準です。
React 開発時によく使う追加の観点
- React 19 の警告 —
use clientの付け忘れ、Server Components での非対応フックの使用などは、Next.js 側のエラーメッセージが詳しく出ます。ブラウザコンソールと ターミナル (dev server) 両方を見る癖をつけておきましょう。 - React DevTools の "Highlight updates when components render" — 拡張内 Settings（歯車アイコン）→ General タブにある正式オプション名です。有効にすると、再レンダーされたコンポーネントの枠が一瞬ハイライトされ、「今の操作でどこが再レンダーされたか」を目視できます。更新頻度が高いほど枠の色が濃く変化します。