필사 모드: ブラウザ DevTools 徹底解説 2026 — Chrome / Firefox / Safari / Edge / WebDriver BiDi / CDP / Lighthouse 12 / AI Assistance (Gemini) 深掘りガイド

ブラウザ DevTools はフロントエンド開発者にとって IDE よりも頻繁に開くツールである。2026 年時点でその姿は「Inspect Element」の段階をとうに過ぎている。AI がコンソール エラーを説明し、BiDi プロトコルが CDP に取って代わり、Lighthouse 12 は INP を一級指標として報告し、Recorder はクリックを自動ワークフローへ変える。本記事は 2026 年 5 月時点の Chrome / Firefox / Safari / Edge 四陣営の DevTools 状況と、その周囲を取り巻く CDP・BiDi・Lighthouse・自動化ツールのエコシステムを一枚にまとめたものである。

1. 2026 年のブラウザ DevTools 地図 — Chrome / Firefox / Safari / Edge の四陣営

DevTools を一行で括れない理由は、「どのブラウザでデバッグするか」が「どのプロトコル・どの UI・どの限界を持つか」へ直結するからである。2026 年時点の市場は次の四陣営に分かれる。

- Chrome DevTools — Chromium の本家、CDP (Chrome DevTools Protocol) の事実上の標準

- Firefox DevTools — Quantum 期を継承する Mozilla の独自路線

- Safari Web Inspector — Apple、WebKit 陣営のデバッガ

- Edge DevTools — Chromium フォークに 3D View と Edge 専用パネルを追加

| 陣営 | ベース | プロトコル | 強み | 弱み |

| --- | --- | --- | --- | --- |

| Chrome DevTools | Chromium | CDP + BiDi | 最も豊富、AI Assistance | モバイル Safari のデバッグ不可 |

| Firefox DevTools | Gecko / Quantum | RDP + BiDi | CSS Grid インスペクタが秀逸 | シェアの低下 |

| Safari Web Inspector | WebKit | Inspector Protocol | iOS / iPadOS の実機デバッグ | UI が保守的 |

| Edge DevTools | Chromium | CDP + BiDi | 3D View、アクセシビリティ ツリー | Chrome と 90% 同じ |

標準化軸として WebDriver BiDi (W3C) が加わる。2026 年の Selenium 4.x、Playwright 1.50+、Cypress 14 はいずれも BiDi を第一級バックエンドとして採用済みである。CDP は依然として Chrome 専用スーパーセットとして残り、BiDi はクロス ブラウザ自動化の共通語となる。

2. Chrome DevTools — 最も豊富、CDP 標準の本家

Chrome DevTools は依然として最大陣営である。2026 年 5 月時点の Chrome 137 安定版に同梱される DevTools には、Sources / Elements / Network / Performance / Memory / Application / Lighthouse / Recorder / Security / Privacy Sandbox / AI Assistance まで 14 を超えるメイン パネルが存在する。

CDP は WebSocket ベースの RPC プロトコルである。外部から Chrome をリモート デバッグするには次のように起動する。

google-chrome \

--remote-debugging-port=9222 \

--user-data-dir=/tmp/chrome-debug \

https://example.com

その後 `http://localhost:9222/json` を叩けば、開いているタブの一覧が JSON で得られる。WebSocket をつかんで CDP メソッドを送れば Chrome をコードから操作できる。

const ws = new WebSocket('ws://localhost:9222/devtools/page/ABC123')

ws.on('open', () => {

ws.send(JSON.stringify({ id: 1, method: 'Page.navigate', params: { url: 'https://www.google.com' } }))

})

Puppeteer、Playwright (Chromium モード)、Lighthouse、Chrome Headless Shell はすべて CDP を喋る。Chrome DevTools の UI そのものも、結局のところ自分自身に CDP を喋るウェブ アプリにすぎない。

2025〜2026 年の Chrome DevTools 主要変化:

- Performance パネルが Performance Insights に統合され、LCP / INP / CLS の検出を自動的に提示

- AI Assistance (Gemini) が正式 GA、Console / Network / Performance に埋め込み

- Recorder がステップを Workflow 単位にまとめ、JSON / Puppeteer / Cypress / Playwright コードへエクスポート

- Privacy Sandbox タブが Application 配下に新設、Topics / Protected Audience / Storage Access API のデバッグに対応

- CSS Overview が Elements の隣へ昇格し、使用頻度が大幅増加

3. Firefox DevTools — Quantum 期を継ぐ第二陣営

Firefox DevTools はシェアとは無関係に「これは Firefox の方がいい」という領域を守り抜いてきた陣営である。代表例が CSS Grid インスペクタだ。Chrome も 2020 年以降追いついたが、Firefox の line-number トグル、area-names オーバーレイ、transform オーバーレイは今も一段上という評価が多い。

Firefox は Quantum エンジン (2017〜) 以降、DevTools 全体を React + Redux 上に書き直した。コードベースは現在も mozilla-central の `devtools/client/` 配下で維持されている。2024〜2025 年に Mozilla が推し進めた二大トラック:

- WebDriver BiDi の第一級実装 — Marionette を BiDi で段階的に置き換え

- Firefox Profiler の統合 — 単体プロファイラ (profiler.firefox.com) を DevTools の Performance タブから直接起動

Firefox の弱点はシェアそのものというよりも、サイトが Chrome 限定 API に依存して Firefox ではそもそもデバッグできないというケースである。そのため 2026 年における Firefox DevTools は「Chrome 以外環境の互換性検証ツール」というポジションに収束する。

Firefox 固有の強みが残る領域:

- Storage Inspector — IndexedDB / Cookies / Cache を一画面で

- Network Monitor の HAR エクスポートが最もクリーン

- Accessibility Inspector のカラー コントラスト シミュレーション

- `about:debugging` という一貫したリモート デバッグ UI

4. Safari Web Inspector — Apple、WebKit 陣営のデバッガ

Safari Web Inspector は macOS Safari、iOS Safari、iPadOS Safari、visionOS Safari、WKWebView までを実機でデバッグできる唯一のツールである。2024 年に EU の DMA が施行されて iOS でも別エンジン (Blink、Gecko) が解禁されたが、市場の 95% 以上は依然として WebKit なので、モバイル Safari のデバッグとは即ち Web Inspector のデバッグである。

接続方法:

1. iPhone / iPad の Settings - Safari - Advanced - Web Inspector を有効化

2. ケーブルで macOS に接続

3. macOS Safari - Develop メニュー - デバイス名 - 開いているタブを選択

接続するとデスクトップ Safari と同じ UI で Web Inspector が立ち上がる。デバイスのメモリ・CPU・ネットワークがリアルタイムで見える。

Web Inspector の強み:

- iOS Safari の実機デバッグ — Chrome では代替不能

- Audit タブ — Lighthouse ではないが独自ルールによる監査

- Timelines / Memory / Canvas / Layers パネル — WebKit 内部に近い指標

- Responsive Design Mode はデスクトップ Safari と同一

弱点は Inspector の UX が保守的なことである。Chrome の AI Assistance、Recorder、Workflows に相当する新機能がなく、キーボード ショートカットも異なる。そのため「iOS Safari だけ壊れている」場面にのみ起動するチームも多い。

5. Edge DevTools — Chromium フォークに 3D View と Accessibility ツリー

Edge DevTools は Chromium ベースなので Chrome DevTools と 90% 同じである。ただし Microsoft が独自に追加した差別化パネルがある。

- 3D View — DOM ツリーを 3D 可視化、z-index と Composited Layer のデバッグに強い

- Issues パネルの Microsoft-specific チェック — Edge for Business ポリシー、エンタープライズ互換

- Microsoft Edge Tools for VS Code — VS Code の中に DevTools フル セット

- Application Insights 連携 — Azure テレメトリ

Edge DevTools が真に光るのは VS Code 上でのデバッグである。`Microsoft Edge Tools for VS Code` 拡張を入れると、次のすべてが 1 ウィンドウで完結する。

- VS Code デバッガでブレークポイント

- Edge DevTools パネルが VS Code サイドバーに埋め込み

- CSS Mirror Editing — インスペクタでの変更が SCSS / CSS ソース ファイルへ直接反映

Windows + VS Code + Edge のエンタープライズ環境であれば、Chrome DevTools をブラウザ単体で開くより統合度が高い。難点は、Chrome 本家の新機能が Edge へ降りるまでメジャー バージョン 1 つ分ほど遅れることである。

6. WebDriver BiDi (W3C) — CDP の後継、クロス ブラウザ自動化の共通語

CDP は 2009 年頃から Chrome の内部プロトコルとして始まり、Puppeteer / Playwright が事実上の標準として使い続けてきた。問題は Chrome 専用である点だ。Firefox と Safari はそれぞれ別プロトコル (Marionette、Inspector Protocol) を持つので、クロス ブラウザ自動化ライブラリは内部で分岐するしかなかった。

これを解くため、W3C が WebDriver BiDi (Bidirectional) の標準化を始めた。従来の WebDriver Classic (Selenium のあれ) は片方向の HTTP リクエスト/レスポンス モデルだったので、リアルタイム イベント (ネットワーク、コンソール、DOM mutation) を拾うのが難しかった。BiDi は WebSocket ベースで双方向、CDP がやっていた仕事を標準形でこなす。

2026 年 5 月時点の進捗:

- Chrome / Edge — BiDi は GA、一部ドメインは依然として CDP に優位性

- Firefox — BiDi 第一級実装、Marionette を段階的に deprecate

- Safari — BiDi の一部ドメイン (browser、browsingContext、log) を実装、network / script は作業中

- Selenium 4.20+ — BiDi コマンド API が正式採用

- Playwright 1.50+ — `--use-bidi` フラグで BiDi バックエンドを選択可能

- Puppeteer 23+ — Firefox サポートが BiDi へ全面移行

BiDi の意味は、自動化ツールがついに「Chrome も Firefox も Safari も同じコードで」という約束を実現できる点である。ただし 2026 年時点でも全機能 (特に CDP-only な Performance trace の一部) が BiDi へ移行したわけではないので、Chrome の深部を扱うツールはしばらく CDP を併用することになる。

7. Chrome AI Assistance (Gemini, 2024.4) — DevTools 内蔵 AI

Chrome 124 (2024 年 4 月) で「Console Insights」という名前で初投入され、その後 AI Assistance という傘の下で Console / Network / Performance / Styles / Sources まで拡張された。2026 年には Gemini 1.5 / 2.0 がバックエンドに入り、次のことを行う。

- コンソール エラー メッセージ 1 行を受けて原因 / 修正案を提示

- ネットワーク リクエスト 1 件を受けて応答コード / ヘッダ / payload の意味を解説

- Performance トレース上の Long Task の原因関数コール チェーンを自然言語で説明

- Styles パネルで「なぜこの要素は中央寄せにならないのか」のような自然言語質問に CSS 観点で回答

- Sources パネルでデバッガ停止時の変数コンテキストから状況を解説

有効化は DevTools 右上の歯車 - Preferences - Experiments - AI Assistance。Google アカウントでのログインが必要で、データはデバウンスのあと匿名化されて Google サーバへ送られる (組織ポリシーで無効化可能)。

AI Assistance が真価を発揮するのは、見覚えのないエラーに遭遇した瞬間である。例えばコンソールの `Uncaught (in promise) DOMException: Failed to execute 'transaction' on 'IDBDatabase'` が、1 クリックで「IndexedDB のトランザクションが閉じた状態で呼ばれています。原因は ...」と読み解かれる。検索 → Stack Overflow → 30 分のループが 30 秒に縮む。

ただし限界も明快である。社内モノレポのコードベースのような文脈は知らないので、「我々のコードでなぜこのエラーが出るのか」までは行き着けない。そこは IDE 側 AI (Cursor、Claude Code、GitHub Copilot Chat) の仕事である。

8. Performance Insights + Trace + LCP / INP / CLS — 新しいワークフロー

従来の Performance パネルはトレースをまるごと並べ、LCP / FID / CLS がどこで発生したかをユーザに探させた。2024 年に投入された Performance Insights はこれを反転させる。

ワークフロー:

1. DevTools - Performance - Record - シナリオ実行 - Stop

2. トレース上に LCP / INP / CLS の位置がカラー マーカーで表示

3. サイド パネル「Insights」に検出した問題がカードとして整列

4. カードをクリックすると原因関数 / ネットワーク リクエスト / レイアウト シフトがハイライト

代表的な Insight:

- Render-blocking request — LCP の前にブロックする CSS / JS

- Long Task — メイン スレッドを 50ms 以上掴んだ関数

- Forced Synchronous Layout — JS が layout を強制的にトリガ

- LCP image not eagerly loaded — `loading="lazy"` が誤って LCP 画像に付与

- Document request latency — TTFB が大きすぎるケース

INP (Interaction to Next Paint) は 2024 年 3 月に FID を置き換えた Core Web Vital である。Performance Insights は INP をインタラクション単位で可視化する。例えばボタン クリック 1 回が 250ms の INP を生んだなら、そのインタラクションの input delay / processing time / presentation delay がバーに分割される。どこを削れば INP を下げられるかが一目瞭然となる。

9. Recorder + Workflows — ノーコード E2E 自動化

Recorder パネルはユーザ操作を録画して再生可能なワークフローとして保存する。Chrome 97 でベータが始まり、2026 年では GA に至っている。

基本フロー:

1. DevTools - Recorder - "Create a new recording"

2. 開始 URL を入力 - 録画開始

3. ページ上でクリック / 入力 / スクロール

4. Stop - ワークフロー保存

保存したワークフローの活用先:

- 同一シナリオの再生 (Replay) — リグレッション確認

- Performance トレースと結合 — シナリオごとのパフォーマンス計測

- コードへのエクスポート — Puppeteer、Playwright、JSON、Cypress、WebPageTest スクリプト

例として Recorder ワークフローを Puppeteer にエクスポートした結果。

;(async () => {

const browser = await puppeteer.launch({ headless: false })

const page = await browser.newPage()

await page.setViewport({ width: 1280, height: 800 })

await page.goto('https://shop.example.com/')

await page.locator('input[name="search"]').fill('headphones')

await page.keyboard.press('Enter')

await page.locator('a.product-card >> nth=0').click()

await page.locator('button.add-to-cart').click()

await browser.close()

})()

QA がシナリオを録画し、開発者がコードとして受け取り、CI の E2E スイートに組み込む。Cypress / Playwright の record 機能との比較で言えば、Recorder の強みは「DevTools の中で完結する」点、弱みはセレクタ安定性が低い点である。

10. Workspace — DevTools 内でファイル編集、ディスクへ保存

Workspace は Sources パネルのフォルダ マッピング機能である。ローカル ディレクトリを DevTools に紐付けると、インスペクタで変更した CSS / JS がそのままディスク上のファイルへ保存される。リロード不要、ライブのままで。

設定:

1. Sources - Filesystem - "Add folder to workspace"

2. ローカル プロジェクト フォルダを選択 - パーミッション許可

3. ネットワーク経由のファイルとディスク ファイルが対応付け (URL ドメイン → フォルダ)

2024 年末以降、Workspace はさらに進化した。一部の環境では自動マッピング (DevTools Project) が可能で、`.devtools` フォルダ 1 つを置いておくと DevTools が次の情報を読み取る。

- ワークスペースのルート パス

- ソース マップのマッピング ルール

- 推奨デバイス / ネットワーク プロファイル

- AI Assistance のコンテキスト (コードベース構造)

CSS Mirror Editing は Edge DevTools が先行し、Chrome が追従した機能である。Styles パネルでの色調整がそのまま SCSS / CSS ソース ファイルへ書き戻される。バンドラを通さなくてよい。

11. Lighthouse 12 + Lighthouse CI + PageSpeed Insights — スコアの政治学

Lighthouse は 2018 年頃から Chrome に同梱されている監査ツールである。Chrome 122 (2024 年 2 月) の Lighthouse 11 で INP が正式指標となり、Lighthouse 12 (2025 年後半) では Bento (メイン カード UI) が刷新され、Performance / Accessibility / Best Practices / SEO / PWA の 5 カテゴリが一行に整列する。

ローカル Lighthouse の利用面は 2 つ。

- DevTools 内の Lighthouse タブ (最も簡単)

- CLI の `lighthouse` パッケージ (CI 統合向け)

npm i -g lighthouse

lighthouse https://example.com --output html --output-path ./report.html

Lighthouse CI は GitHub Actions のような CI でスコア後退を阻止するツールである。設定例:

name: lighthouse-ci

on: pull_request

jobs:

lhci:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: 22

- run: npm ci && npm run build

- run: npx @lhci/cli@latest autorun

`.lighthouserc.json` に閾値を書いておけば、スコアが落ちた PR をブロックできる。

{

"ci": {

"collect": { "url": ["http://localhost:3000/"], "numberOfRuns": 3 },

"assert": {

"assertions": {

"categories:performance": ["error", { "minScore": 0.85 }],

"categories:accessibility": ["error", { "minScore": 0.95 }]

}

}

}

}

PageSpeed Insights は同じ Lighthouse エンジンを Google サーバ側で回した結果と、実ユーザ (CrUX、Chrome User Experience Report) の 28 日間平均を同時に表示する。ローカル Lighthouse が「ラボ データ」、CrUX が「フィールド データ」という分担で、PSI は両方を 1 ページに並べる。

12. Privacy Sandbox デバッガ — クッキーなし世界のデバッグ

サードパーティ クッキーは Chrome で段階的に廃止されつつある。Privacy Sandbox はその穴を埋める API 群 — Topics API (関心信号)、Protected Audience API (旧 FLEDGE、リターゲティング)、Storage Access API、Attribution Reporting API、CHIPS (Cookies Having Independent Partitioned State)、Federated Credential Management (FedCM) などである。

これらの API はデバッグが難しい。データは匿名化され、遅延発火するものもあり、結果を直接確認する手段が少ない。そこで Chrome DevTools の Application タブに Privacy Sandbox セクションが追加された。

確認できる項目:

- Topics — 現在ユーザに推論されている関心トピック

- Protected Audience — 登録済み interest group、進行中 / 終了済みの auction

- Storage Access — iframe ごとのストレージ アクセス状態

- Attribution Reporting — pending な source / trigger イベントと report キュー

- CHIPS — Partitioned cookie の状態

- FedCM — Identity Provider と Relying Party の設定

テスト環境では Chrome フラグ (`chrome://flags`) で各 API を強制的に有効化 / 無効化できる。

google-chrome \

--enable-features=BrowsingTopics,InterestGroupStorage,FledgeBiddingAndAuctionServer

広告 / マーケティング バックエンドを触るなら、2026 年時点で最も開く頻度が高いパネルが Privacy Sandbox デバッガである。

13. Animation Inspector + Memory + JS profiler — 深掘り 3 種

Animation Inspector はページで発生する CSS と Web Animations API のアニメーションを 1 つのタイムラインに並べる。使い所:

- transition がカクついて見える原因 — easing カーブと duration の競合

- transform が paint ではなく composite で扱われているか

- requestAnimationFrame ループと CSS animation の同期

Memory パネルには大きな道具が 2 つある。

- Heap snapshot — 特定時点のオブジェクト ツリーを丸ごと取得

- Allocation timeline — 時間軸での割り当て量変化

メモリ リーク調査の定石は「3 回スナップショット」テクニックである。(1) ベースライン スナップショット → (2) 疑わしいシナリオ実行 → (3) 2 回目のスナップショット → (4) もう一度実行 → (5) 3 回目のスナップショット。1 → 2 → 3 にかけて単調増加するオブジェクトがリーク候補である。Detached DOM Tree が最も典型的なシグナルになる。

JS Profiler (Performance パネルのメイン スレッド トレース) は関数別の self time / total time を表示する。2024 年以降の V8 サンプリング プロファイラは精度が上がっており、200ms を超える関数はほぼ確実に捕捉される。フレーム チャートの横幅がそのまま時間である。

14. Coverage タブ — 使われていないコードを見つける

Coverage タブはページ ロードやインタラクション中に実際に実行された JS / CSS の割合を表示する。使い方:

1. DevTools - Coverage タブを有効化 (Cmd/Ctrl+Shift+P → "Show Coverage")

2. Reload - シナリオ実行

3. ファイル別に used / unused バイト数が表で整列

unused 比率が高いファイルはツリー シェイキングやコード スプリッティングの第一候補である。大規模 SaaS のベンダ バンドルでは unused が 60〜80% は珍しくなく、これを見ながら dynamic import で切り分けていく。

注意 — Coverage は「このページ / このシナリオで使われていない」を意味するのであって、「絶対に使われない」ではない。ルートごとに unused を集めて横断的に合算し、デッド コード候補を絞り込むのが定石である。

15. Network スロットリング + デバイス エミュレーション + CSS Overview — 環境シミュレーション三種

Network スロットリングは Network パネル上部のドロップダウンで No throttling / Slow 4G / Fast 4G / Offline などを選ぶ。2026 年では Custom profile に RTT / ダウンロード / アップロード / パケット ロスまで指定できる。

デバイス エミュレーションは Toggle Device Toolbar (Cmd/Ctrl+Shift+M) で起動する。iPhone 15 Pro、Galaxy S24、iPad mini などのプリセットがあり、カスタム ビューポートも定義可能。CSS メディア クエリ、viewport meta、タッチ イベント シミュレーション、位置情報の上書きが一画面で動く。

CSS Overview はページの CSS 統計を 1 ページに集約する。

- 使用中のフォント、font-size、line-height の分布

- 実際に使われているカラー パレット

- メディア クエリ一覧

- 未使用候補のセレクタ

- コントラスト比が低いテキスト (アクセシビリティ ヒント)

デザイン システムの一貫性を取り戻す際に最も速い道具である。カラー パレットが 100 色に発散しているなら即座に分かる。

16. Source maps + Long task analyzer — バンドル デバッグと INP

Source maps はバンドル / 圧縮 / トランスパイル後のコードを元 (`.ts`、`.tsx`、`.jsx`、`.vue` など) へ戻すマッピングである。2026 年のすべてのビルド ツール (Vite、Webpack、Rspack、Turbopack、esbuild、swc) はデフォルトで source map を出力する。

DevTools での source maps Tips:

- Sources パネルで右クリック - "Add source map" によって外部 source map を手動指定可能

- Settings - Preferences - "Enable JavaScript source maps" がオンであること

- Network パネルの Initiator 列で source map で解決されたパスを確認

- 本番エラー レポート (Sentry など) も source map をアップロードしておけばスタック トレースが原本へ戻る

Long task analyzer は Performance パネルの "Long Tasks" トラックである。50ms 以上メイン スレッドを掴んだ作業が横バーで表示される。INP デバッグの一次ツールである。

INP が悪いときのチェック順:

1. Performance 録画 - 問題のインタラクションを再現

2. 該当インタラクションの Long Task がどこで発火したかを確認

3. フレーム チャートで横幅が最も広い関数 / 最も深いコール チェーンを追跡

4. 強制 reflow があるか確認 (紫の警告マーカー)

5. requestIdleCallback / scheduler.yield で譲渡できるか検討

2025 年に追加された `scheduler.yield()` は INP デバッグ最大の変化である。長い作業を明示的に譲渡すれば INP は即時に下がる。その効果はトレースの再録画で DevTools 上で検証できる。

17. Puppeteer + Playwright + Cypress + chrome://inspect — DevTools と自動化の橋渡し

Puppeteer、Playwright、Cypress はいずれも DevTools の弟・いとこである。3 つすべて CDP もしくは BiDi をバックエンドで使う。

比較:

| ツール | バックエンド | 強み | 弱み |

| --- | --- | --- | --- |

| Puppeteer | CDP (Chrome) / BiDi (Firefox) | 最軽量、Chrome 深部に強い | クロス ブラウザに弱い |

| Playwright | CDP + Patchright + BiDi | クロス ブラウザ、並列性 | 学習曲線が急 |

| Cypress | in-browser ランナー | 開発者フレンドリーな UX | iframe / マルチ タブ制約 |

リモート デバッグの 2 シナリオ:

(1) 同一マシン — `--remote-debugging-port=9222` で Chrome を起動し、`http://localhost:9222` に接続

(2) 別マシン / モバイル — `chrome://inspect` を使用

Android 実機デバッグ:

1. PC の Chrome で `chrome://inspect/#devices` を開く

2. Android 端末の開発者オプションで USB デバッグを有効化

3. USB ケーブルで接続

4. 端末の Chrome でページを開くと PC の chrome://inspect にタブが現れる

5. "inspect" をクリックすると PC の DevTools が端末のページに接続

iOS Safari は chrome://inspect が使えない。macOS Safari + USB ケーブル + Web Inspector の組み合わせのみが唯一の手段である。

18. 韓国 / 日本 — トス perf、NAVER D2、メルカリ、Cybozu DevTools ブログ

DevTools の活用度合いは「組織がどれだけ深く性能を見ているか」と直結する。日韓の事例を見ると、グローバルな潮流とほぼ同期している。

韓国:

- トス — toss.tech の Frontend カテゴリに Lighthouse CI、INP デバッグ、Long task 分析の事例が多数。特に「INP を 100ms 未満に押し下げた過程」系の記事は検索 1 位に並ぶ。

- NAVER D2 — d2.naver.com のフロントエンド記事。Chrome DevTools Performance / Memory snapshot の韓国語解説では D2 が事実上の標準リファレンスである。

- Kakao if(kakao) カンファレンス — 毎年 DevTools 性能事例セッションが 1 〜 2 本。動画は YouTube に公開される。

- Woowa Brothers (出前ミン) — woowahan.com/tech のフロントエンド性能事例。CrUX と RUM を並行して扱う。

日本:

- メルカリ engineering — engineering.mercari.com の Web Performance シリーズ。Lighthouse、INP、Core Web Vitals の取り組みを扱う。

- Cybozu Frontend — blog.cybozu.io に Chrome DevTools と Playwright 統合の記事が定期的に掲載される。

- LINE Yahoo techblog — techblog.lycorp.co.jp。日本ドメインの RUM データを基にしたデバッグ事例が多い。

- DeNA testblog — testblog.dena.com。自動化 / E2E 面で Cypress / Playwright の BiDi 移行事例を共有。

英語圏の web.dev とは色合いが違う。モバイル環境 (韓国の三大キャリア、日本の docomo / au / softbank) の実 4G / 5G RTT データを持ち込み、Network スロットリング プロファイルを作るという書き口が多い。

19. 誰が何を深く学ぶべきか — フルスタック / フロントエンド / モバイル ウェブ

DevTools は幅広い。役割ごとの優先順位を整理する。

| 役割 | 第 1 優先 | 第 2 優先 | 知っていると有利 |

| --- | --- | --- | --- |

| フルスタック エンジニア | Network、Console、Sources | Performance Insights、Lighthouse | AI Assistance、Recorder |

| フロントエンド (UI) | Elements、Styles、Animation Inspector、CSS Overview | Workspace、Coverage | Memory、JS Profiler |

| フロントエンド (性能) | Performance、Long Task、Memory | Lighthouse CI、INP デバッグ | Privacy Sandbox |

| モバイル ウェブ | デバイス エミュレーション、Network スロットリング、Safari Web Inspector | chrome://inspect (Android)、Web Inspector (iOS) | BiDi ベースのモバイル自動化 |

| QA / 自動化 | Recorder、HAR エクスポート | Playwright + BiDi、Lighthouse CI | CDP メッセージ デバッグ |

| セキュリティ | Security パネル、Application/Cookies、Privacy Sandbox | CSP デバッグ、Mixed Content | CORS シミュレーション |

| 専業デバッガ | AI Assistance、Sources デバッガ | Issues パネル、Lighthouse | 3 回スナップショット Memory |

フロントエンド新人向けの推奨学習順:

1. Elements + Styles + Network + Console — 1 週間

2. Sources (ブレークポイント、conditional、logpoint) — 1 週間

3. Performance + Performance Insights — 2 週間

4. Memory + Coverage — 1 週間

5. ローカル Lighthouse + Lighthouse CI — 1 週間

6. Recorder + Workspace — 1 週間

7. AI Assistance — ここから先は全段階で補助に組み込む

7 〜 8 週間で DevTools の 80% を使う人になれる。残り 20% はケースに応じて取りに行けばよい。

20. 参考 / References

- Chrome DevTools 公式 — [https://developer.chrome.com/docs/devtools](https://developer.chrome.com/docs/devtools)

- Chrome DevTools Protocol — [https://chromedevtools.github.io/devtools-protocol/](https://chromedevtools.github.io/devtools-protocol/)

- WebDriver BiDi (W3C ドラフト) — [https://w3c.github.io/webdriver-bidi/](https://w3c.github.io/webdriver-bidi/)

- Firefox DevTools — [https://firefox-source-docs.mozilla.org/devtools-user/](https://firefox-source-docs.mozilla.org/devtools-user/)

- Safari Web Inspector — [https://webkit.org/web-inspector/](https://webkit.org/web-inspector/)

- Edge DevTools — [https://learn.microsoft.com/microsoft-edge/devtools-guide-chromium/](https://learn.microsoft.com/microsoft-edge/devtools-guide-chromium/)

- Lighthouse — [https://developer.chrome.com/docs/lighthouse](https://developer.chrome.com/docs/lighthouse)

- Lighthouse CI — [https://github.com/GoogleChrome/lighthouse-ci](https://github.com/GoogleChrome/lighthouse-ci)

- PageSpeed Insights — [https://pagespeed.web.dev/](https://pagespeed.web.dev/)

- Core Web Vitals — [https://web.dev/articles/vitals](https://web.dev/articles/vitals)

- INP ガイド — [https://web.dev/articles/inp](https://web.dev/articles/inp)

- Privacy Sandbox — [https://privacysandbox.com/](https://privacysandbox.com/)

- Chrome AI Assistance — [https://developer.chrome.com/docs/devtools/ai-assistance](https://developer.chrome.com/docs/devtools/ai-assistance)

- Recorder — [https://developer.chrome.com/docs/devtools/recorder](https://developer.chrome.com/docs/devtools/recorder)

- Workspace — [https://developer.chrome.com/docs/devtools/workspaces](https://developer.chrome.com/docs/devtools/workspaces)

- Puppeteer — [https://pptr.dev/](https://pptr.dev/)

- Playwright — [https://playwright.dev/](https://playwright.dev/)

- Cypress — [https://www.cypress.io/](https://www.cypress.io/)

- トス Frontend — [https://toss.tech/tech/categories/frontend](https://toss.tech/tech/categories/frontend)

- NAVER D2 — [https://d2.naver.com/](https://d2.naver.com/)

- メルカリ engineering — [https://engineering.mercari.com/](https://engineering.mercari.com/)

- Cybozu Frontend — [https://blog.cybozu.io/](https://blog.cybozu.io/)

- web.dev — [https://web.dev/](https://web.dev/)