Chrome DevTools 最近の新機能まとめ - devlog [開発部門ブログ]

はじめに

Google Chrome の Chrome DevTools は毎年多くのアップデートが行われています。特にパフォーマンス最適化、CSS デバッグ、JavaScript 解析、バンドル最適化に関する新機能が充実しており、React や TypeScript、GraphQL といったモダン技術を用いる開発現場でも即役立つ改善が多数リリースされています。

本記事では Chrome DevTools 公式ドキュメントに基づき、これら新機能の中でも実務で即効性が高いものを厳選して解説します。各機能の概要とユースケース、公式ドキュメントへのリンクを示しますので、日々のフロントエンド開発にぜひ取り入れてみてください。

パフォーマンス最適化: 新しい分析と現実的なテスト環境

近年の Chrome DevTools では、ページのパフォーマンスボトルネックを自動検出する Performance Insights 機能が強化されています。例えば「Forced reflow」（強制的な再レイアウト）や「Optimize DOM size」（DOM サイズ最適化）といったインサイトが新たに追加され、どのスクリプトや要素がレイアウト処理をブロックしているかを直接指摘してくれます。これらの Insight は、React などで DOM ノードが大量になるケースや、頻繁なスタイル計算によるパフォーマンス低下をすぐに発見して改善策を検討するのに役立ちます。

また、「Network dependency tree」の Insight では重要リソースのリクエストが直列（チェイン）になっていないか検出可能です。クリティカルなリソースのチェイン読み込みは推奨されないため、この Insight によってバンドル分割やプリロード戦略の見直しが促されます。これら自動分析により、複雑なパフォーマンストレースから重要な改善ポイントを見逃さずに済むでしょう。

パフォーマンス計測のリアルな再現性も向上しました。Chrome 134 では CPU スロットリングの自動較正機能が導入され、開発 PC に合わせてミドルレンジやローエンド端末相当の CPU 速度をより正確にシミュレーションできます。設定画面の「Calibrate」ボタンで計測すると、実機データに基づいた新たなプリセットが追加され、例えば「4× スローダウン」のような推奨値が得られます。

さらに Chrome 133 では、よく使われるスロットル値のおすすめが Performance パネル上に表示されるようになり（CPU は約 4 倍、ネットワークは Chrome UX Report の実測に基づく値）、開発者が適切な条件でテストしやすくなりました。加えて、INP（Interaction to Next Paint）などユーザー体感性能を示す指標も Chrome DevTools 内でサポートされています。たとえばユーザー操作に 200ms 超かかった場合、INP ワーニングが自動表示されるようになり、入力遅延や応答性の問題を素早く検知できます。これらの機能強化により、「自分のサイトがモバイル端末で快適に動くか」「ユーザー操作が重くなっていないか」を開発段階でリアルに把握できるようになりました。

パフォーマンス問題の原因特定も一段と容易になっています。Chrome 134 では Performance サマリーに「ファーストパーティ/サードパーティの処理時間」を集計表示するテーブルが追加されました。これにより、計測結果から自社コードと外部スクリプトのどちらがどれだけ時間を消費しているか一目瞭然です。例えば、分析の結果サードパーティ（第三者提供）のスクリプトがページ遅延の大半を占めているとわかれば、そのライブラリの読み込み見直しや削減が検討できます。

同様に、「最も重いスタック」のハイライト表示も強化されました。Chrome 135 では、Performance 記録の Call tree や Bottom-up ビューで重いコールスタックを選ぶと、そのスタックに対応するメインスレッド上のタスクがタイムライン上で強調表示されるようになりました（入れ子になった長時間処理の可視化）。これらの改善によって、複雑なフレームチャートをにらまなくても「何がボトルネックか」が直観的に把握でき、パフォーマンスチューニングの効率が飛躍的に向上します。

CSS デバッグ: モダン CSS 対応と開発体験の向上

昨今の CSS 仕様追加に伴い、Chrome DevTools も最新の CSS 機能をデバッグできるよう進化しています。例えば 2022 年末に登場した CSS コンテナクエリは、Chrome DevTools でいち早くサポートされました。Elements パネル上でコンテナ要素に「container」バッジが表示されるようになり、クリック一つでコンテナのアウトライン表示と子要素の関連付けを可視化できます。また、子要素に適用された@container ルールも条件成立時に Styles ペインへ表示されます（コンテナが条件を満たすとき、そのルールがいつどのように効いているか確認可能）。これにより、コンポーネント単位のレスポンシブデザインを実装する際にも、従来のメディアクエリ同様に Chrome DevTools で挙動確認が容易になりました。

さらに Chrome 125 では、新しい CSS アンカーポジショニング（スクロールアニメーション用の position: anchor）にも Chrome DevTools が追随し、Elements パネルで@position-try 規則を正しく解釈・表示できるようになりました。各 position-try オプションがどの位置にフォールバックしたかを Styles ペインで確認できるため、スクロール連動アニメーションのデバッグがスムーズになります。その他、Chrome 115 では CSS Subgrid レイアウトを示すバッジが導入されるなど、Grid/Flexbox を含む最新 CSS 仕様の可視化サポートが着実に拡充されています。

基本的なスタイルデバッグ体験もさらに改善されました。Chrome 112 以降、Chrome DevTools の Styles ペインは CSS ネスティング構文（入れ子セレクタ）を正しく認識するようになり、ネストされたセレクタのルールでも対応する要素に適用済みであることが視覚的にわかります。加えて Chrome 113 では、無効な CSS プロパティ名や値が一目で判別できる表記になりました。もしスペルミス等で CSS プロパティ自体が無効な場合は宣言全体（プロパティ名と値）が、プロパティ名は正しいが値が不適切な場合はその値だけが、それぞれ取り消し線で示されます。これにより、「なぜこのスタイルが効かないのか？」と悩んだ際にソースを見返すだけで原因を発見しやすくなります。

また、アニメーションのデバッグにも配慮がなされています。CSS アニメーションの animation ショートハンドプロパティに対し、Chrome DevTools は対応する@keyframes ルールへのリンクを自動付与するようになりました。これにより、適用中のキーフレーム定義に即座にジャンプでき、スタイル調整の手間が減ります。さらに Chrome 123 では、Elements パネル上からページ全体をフォーカス状態にする機能（:focus-visible エミュレーション）が追加されました。キーボードフォーカス時のスタイルを擬似的に適用できるため、フォーカスリングやアクセシビリティ対応の UI 検証が簡単に行えます。こうした Chrome DevTools の細かな改良が、CSS バグ修正やデザイン調整の生産性を着実に高めてくれるでしょう。

加えて、CSS カスケードや変数の理解を助けるヒント機能も充実しています。Chrome 115 では、Styles ペイン上でセレクタにホバーするとその詳細な Specificity 値（優先度）がツールチップ表示されるようになりました。具体的には、各セレクタが持つ(a,b,c)の重み（ID・クラス・要素数の組）が表示されるので、どのルールが競合に勝つか直感的に把握できます。同じく Chrome 115 からカスタムプロパティ（CSS 変数）の値もツールチップでプレビュー可能になりました。`–color: #ff0000`のような変数定義箇所に触れると現在の値が表示され、複雑なテーマカラー管理などで変数が正しく伝播しているかを即確認できます。

さらに Chrome 115 以前からの機能ですが、CSS Overview パネルも活用すると良いでしょう。CSS Overview はドキュメント全体のカラーやフォント、未使用のスタイルなどを集計するツールで、Chrome 113 では無効な CSS や非推奨プロパティも報告対象に加わるなど改善が続けられています。これらの機能により、CSS の適用順序や継承関係、未定義変数といった問題をツールのサポートを得ながら素早く突き止めることが可能です。

JavaScript 解析: デバッグ効率の飛躍的向上

フロントエンド開発では、フレームワークやビルドツール由来のコードが混在するため、自分が書いたコードに集中してデバッグしたいというニーズが高まっています。Chrome DevTools はこの点で大きな進歩を遂げました。

まず、不要なスタックフレームのフィルタリングが高度化しています。Nuxt や Vite、Rollup といったモダンフレームワークが出力するバンドルコードについて、Chrome DevTools 側であらかじめ「無視リスト」に登録する協調が進み、スタックトレース上でそれらフレームをデフォルトで非表示にするようになりました。例えば、コンソール上のエラートレースやデバッガの Call Stack で「(フレーム数 N 個を非表示)」とまとめて折りたたまれ、必要ならクリックで展開できる形です。React/TypeScript の開発では、node_modules 配下のライブラリやフレームワーク内部の呼び出しが山ほどスタックに積まれますが、この「Ignore-listed frames」機能により、自作コード部分だけをすぐ特定できるようになりました。

Chrome 120 ではこの考えを推し進め、デフォルトで node_modules をパターンマッチして無視リストに追加する設定も有効化されています（設定から手動調整可能）。さらに Chrome 127 では、特定のスクリプトファイルやディレクトリを対象に”Never Pause Here”（ここではデバッガ停止しない）オプションを強化し、ブレークポイントや例外捕捉の対象外に簡単に指定できる UI 改善も行われました。これらの機能により、巨大な依存ライブラリを含む SPA アプリでも本当に追いたい処理だけにフォーカスしてデバッグでき、調査効率が飛躍的に向上します。

コンソールでのエラー解析支援も注目すべき新機能です。Chrome 125 では Chrome DevTools にジェネレーティブ AI を活用した「エラー内容の理解」ボタン（ライトバルブアイコン）が試験導入されました。コンソール上のエラーや警告メッセージの横にこのボタンが表示されていれば、クリックすることでそのエラーの意味や考えられる原因、一般的な解決策を AI が解説してくれます。たとえば典型的な CORS エラーに対し「サーバー側で Access-Control-Allow-Origin ヘッダーを設定する必要がある」旨の具体的な対処例（コード付き）が示されます。これは GraphQL のクエリ失敗や Fetch エラーなど、メッセージだけでは分かりにくい問題に直面した際に大いに助けとなるでしょう。現在この機能は段階的ロールアウト中で、利用にはオンライン接続やログイン等の条件がありますが、対象ユーザーには Chrome DevTools 内で StackOverflow 的な知見を得られる心強いアシスタントとなります。

またコンソール関連では、Chrome 125 で Error オブジェクトの cause プロパティ（エラーの原因チェーン）も表示サポートされました。`throw new Error(‘外側’, { cause: 内側のError });`のようにネストした例外を扱っている場合、コンソールのスタックトレース上に「Caused by: 内側の Error…」という形で原因エラーまで遡って表示されます。Promise の例外扱いも改良されており、`.catch()`でハンドリング済みの拒否（Rejected Promise）については「Pause on uncaught exceptions（捕捉されなかった例外で停止）」オプション有効時でもデバッガが停止しなくなりました。これらの改善によって、エラー原因の突き止めや非同期処理のデバッグが格段にスムーズになり、フレームワーク内部のエラー伝搬や GraphQL エラーハンドリングの追跡も容易になります。

開発者のコーディング体験を高める工夫も随所に見られます。コードフォーマット面では、ソースコードの自動 Pretty-Print が一層使いやすくなりました。Chrome 110 ～ 125 のアップデートで、ミニファイされた JS や CSS を Chrome DevTools 上で読みやすく整形する「Pretty print（整形表示）」機能を自動適用するオプションが実装・強化され、設定で有効化すればファイルを開いた際に自動で美しくインデントされた状態にしてくれます。また括弧やタグの自動閉じ補完も任意でオンオフ切り替えられるようになり、Chrome DevTools 内での簡単なコード編集やスニペット作成がより快適になりました。

ソースマップ対応の強化も特筆すべき点です。Chrome 121 では実験機能だった「コンソール評価やウォッチ式で元の変数名を解決する」オプションが正式に標準オンになりました。これにより、TypeScript や Babel で変換されたコードでも、Chrome DevTools は元のソースに基づいた変数名でコンソール評価やオートコンプリートを行います。デバッガのウォッチ式や条件付きブレークポイントでも同様で、開発者は自分が書いたコードそのままの感覚でデバッグ可能です。

たとえば、transpile 後に\_\_awaiter や\_this といった難読化された名前になっていても、Chrome DevTools 上ではオリジナルの await 構文や this として扱われます。これは React+TypeScript や Webpack などでビルドされたプロジェクトでは非常に恩恵が大きく、「ビルド前の素のコードでそのままデバッグしているような体験」を味わえます。

さらに Chrome 115 では、Vue や Angular の SFC、SCSS/LESS といったプリプロセッサ対応のシンタックスハイライトも Sources パネルで改善され、フレームワーク特有の構文も見やすく色分けされるようになりました。その他、条件付きブレークポイントをワンクリックで設定するショートカット（行番号を Ctrl/⌘ ＋クリック）や、ログポイント/ブレークポイントから発生したコンソールメッセージにマークを付ける（オレンジの「?」やピンクの「…」アイコンを表示）など、細かな UX 改善も盛り込まれています。

総じて、Chrome DevTools の JavaScript デバッグ機能はここ 2 年で飛躍的に開発者フレンドリーになっており、複雑なアプリのデバッグに費やす時間を大幅に削減できるでしょう。

バンドル最適化: 無駄なコードの可視化とサードパーティ分析

Web アプリのパフォーマンスとファイルサイズを最適化するには、自分のアプリがどのくらい不要なコードを抱えているかを知ることが重要です。Chrome DevTools の Coverage（カバレッジ）機能は、ページで実際に実行・使用されたコードと未使用コードの量を測定できますが、Chrome 124 ではこのカバレッジパネルにいくつか改良が加えられました。

まず、ファイルパスでフィルタした場合の使用率集計が正確に計算されるようになりました。従来はサブフォルダでフィルタしても親フォルダ全体の数字が出てしまうバグがありましたが、修正により選択範囲のファイル群のみを合算した使用バイト数・未使用バイト数が正しく表示されます。例えば/src/components 以下に絞ってカバレッジを確認し、そのフォルダ内で未使用のコードが多ければ、コンポーネントの分割や削減を検討するといった分析が正確な数値に基づいて行えます。同時に、未使用コードのハイライト色も従来の緑からグレーに変更されました（色覚多様性への配慮）。地味な変更ですが、これにより大きなファイルを確認するときにも未使用部分が一目で判別しやすくなっています。

また、実行時の負荷を生む要因を探るための情報も増えました。Chrome 125 では、Performance パネルに「CSS セレクタ統計の取得」オプションが追加され、長時間かかったスタイル再計算イベント内でどの CSS セレクタがどれだけ非効率だったかを分析できるようになりました。計測を有効化しておくと、再計算イベントを選択した際に「Selector Stats」タブが現れ、各セレクタごとの処理時間やマッチ試行回数、失敗率（slow-path に入った割合）などが表示されます。大量の DOM 要素に対して無駄にコストの高いセレクタを適用していないか診断できるため、CSS 設計の見直しや不要なスタイルシートの除去に役立ちます。例えば、後から不要になった CSS が残ってページ全体のスタイル計算を遅くしていた場合でも、この統計情報から問題のセレクタを特定しやすくなるでしょう。

リソースロードの最適化という観点では、前述の Network dependency tree Insight が有用です。Chrome DevTools が「重要なリソースがチェイン（直列）読み込みされている」と判断すれば、Performance パネル内に注意喚起が表示されます。これは例えば、バンドル分割したチャンク A のロード完了後にチャンク B を読み込むようなケースでパフォーマンス問題となり得ますが、そうした不適切なロード順をすぐ察知できるわけです。

同様に、Chrome 117 ではネットワークリクエストのプライオリティ変更がタイムライン上で視認できるようになり（優先度が切り替わった箇所にマーカー表示）、重要度の低いスクリプトや画像がメインスレッドをブロックしていないか分析しやすくなりました。これらは直接バンドルサイズを減らす機能ではありませんが、「どのリソースを圧縮・遅延読み込みすべきか」といった戦略を練る材料を提供してくれます。

さらに、サードパーティコードの影響把握もバンドル最適化の重要ポイントです。Chrome 134 で導入された Performance サマリーの First-party vs Third-party テーブルは、ページ負荷におけるサードパーティスクリプトの占有率を数値化します。例えばトータル実行時間のうち何割が広告タグや解析ツールに費やされているかが一目で分かるため、もし外部スクリプトのコストが大きければ軽量な代替への置き換えや削除を検討する判断材料になります。

同じ観点で、Lighthouse（Chrome DevTools 内蔵の監査ツール）も定期的にアップデートされており、2023 年には Large JavaScript Libraries（大きな JS ライブラリへの警告）やチェインリクエスト検出など、バンドル最適化に関わる監査項目が充実しています。Chrome DevTools 上の Lighthouse タブから最新バージョンで監査を実行すれば、パフォーマンスやベストプラクティスの観点で改善すべき点（例えば「未使用の Polyfill が含まれている」「サードパーティスクリプトによるメインスレッドブロックが長い」等）を総合的に洗い出すことができます。

これらのツール群を組み合わせて活用することで、コードの無駄や非効率を発見し、ユーザー体験を損なうことなくファイルサイズを削減するための具体的な指針が得られるでしょう。

おわりに

上記のような機能は、いずれも即戦力となる実践的な改善ばかりです。パフォーマンス面では自動解析によるボトルネックの可視化と現実的な環境再現、CSS デバッグ面では最新仕様への追従と開発効率アップ、JavaScript 解析面ではフレームワーク対応やエラー理解支援、そしてバンドル最適化面では未使用コード検出の精度向上や外部スクリプト分析など、幅広い分野で開発者体験が向上しました。

これらの機能は公式ドキュメントやブログでも詳細が紹介されています。ぜひ Chrome DevTools を最新バージョンにアップデートし、日々の開発に取り入れてみてください。それにより、React/TypeScript や GraphQL を駆使するモダンな開発においても、問題の発見から解決までのスピードが飛躍的に向上するはずです。新機能を積極的に活用し、快適で効率的なフロントエンド開発を実現しましょう。