ブラウザ 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 専用パネルを追加

標準化軸として 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 をコードから操作できる。

import WebSocket from 'ws'

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 にエクスポートした結果。

import puppeteer from '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 をバックエンドで使う。

比較:

リモート デバッグの 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. 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
• Chrome DevTools Protocol — https://chromedevtools.github.io/devtools-protocol/
• WebDriver BiDi (W3C ドラフト) — https://w3c.github.io/webdriver-bidi/
• Firefox DevTools — https://firefox-source-docs.mozilla.org/devtools-user/
• Safari Web Inspector — https://webkit.org/web-inspector/
• Edge DevTools — https://learn.microsoft.com/microsoft-edge/devtools-guide-chromium/
• Lighthouse — https://developer.chrome.com/docs/lighthouse
• Lighthouse CI — https://github.com/GoogleChrome/lighthouse-ci
• PageSpeed Insights — https://pagespeed.web.dev/
• Core Web Vitals — https://web.dev/articles/vitals
• INP ガイド — https://web.dev/articles/inp
• Privacy Sandbox — https://privacysandbox.com/
• Chrome AI Assistance — https://developer.chrome.com/docs/devtools/ai-assistance
• Recorder — https://developer.chrome.com/docs/devtools/recorder
• Workspace — https://developer.chrome.com/docs/devtools/workspaces
• Puppeteer — https://pptr.dev/
• Playwright — https://playwright.dev/
• Cypress — https://www.cypress.io/
• トス Frontend — https://toss.tech/tech/categories/frontend
• NAVER D2 — https://d2.naver.com/
• メルカリ engineering — https://engineering.mercari.com/
• Cybozu Frontend — https://blog.cybozu.io/
• web.dev — https://web.dev/