<!-- new-v1 -->

Core Web Vitals 計測ツール比較｜PageSpeed/Lighthouse/GTmetrix/Web Vitals 拡張【2026年版】

この記事の結論: Core Web Vitals (LCP/INP/CLS) の計測は「フィールドデータ = PageSpeed Insights / CrUX / Search Console」「Lab データ = Lighthouse / WebPageTest / GTmetrix」「リアルタイム検証 = Web Vitals Chrome 拡張」の三層構造で使い分けるのが 2026 年の最適解です。フィールドが本番ユーザーの実体験、Lab が再現性のある検証環境、拡張が手元で即時確認の役割を担います。

最終更新日: 2026-05-06

はじめに

Core Web Vitals (CWV) を改善しようと PageSpeed Insights を開いたものの、「Lighthouse スコアと結果が違う」「GTmetrix では Good なのに Search Console では Poor になる」「実機 Chrome の Web Vitals 拡張だと数値が安定しない」といった経験をした担当者は多いはずです。これらは「ツールの優劣」ではなく、計測方式 (フィールド / Lab) と環境 (端末・回線・地域) の違いから生まれる必然です。

本記事では Core Web Vitals を計測する主要 6 ツール (PageSpeed Insights / Lighthouse / GTmetrix / WebPageTest / Web Vitals 拡張 / CrUX) を、機能・料金・データソース・ユースケース・落とし穴まで横断的に比較します。さらに、CMS (WordPress / Next.js) 別の組み込み方、改善ワークフロー、よくある失敗事例まで網羅し、「どのツールでどの場面を計測すべきか」を迷わず判断できる状態を目指します。 → 詳しくはCore Web Vitals入門｜LCP・INP・CLSをやさしく解説で 3 指標の基礎を確認できます。

CWV 計測の基礎｜フィールドデータと Lab データの違い

ツール比較の前に、まず「フィールドデータ (Field Data)」と「Lab データ (Lab Data)」という 2 つのデータ種別を理解する必要があります。これを混同していると、ツール間の数値の食い違いに振り回されることになります。

フィールドデータ (RUM) とは

フィールドデータは Real User Monitoring (RUM) とも呼ばれ、実際のユーザーが Chrome でページを訪問した際に収集された匿名の体験データです。Google は Chrome User Experience Report (CrUX) という公開データセットとして集約し、PageSpeed Insights や Search Console の Core Web Vitals レポートで可視化します。

フィールドデータは「ユーザーが実際に体験した LCP / INP / CLS」を示すため、SEO 評価の基準として最も重要です。一方、トラフィックが少ない URL は CrUX に登録されず、PageSpeed Insights で「データ不足」と表示されます。 → 詳しくはGoogle Search Consoleの使い方｜初心者の最初の30分でフィールドデータの読み方を確認できます。

Lab データ (Synthetic Monitoring) とは

Lab データは、決められた端末・回線条件でツールが「シミュレーション計測」した結果です。Lighthouse / GTmetrix / WebPageTest が代表で、何度実行しても (理論上) 同じ条件で再現できるため、改修前後の比較や CI 組み込みに向きます。

ただし Lab データには弱点があります。最も重要な指標である INP は「ユーザーの操作」が前提のため、Lab では正確に測れず、代替指標として TBT (Total Blocking Time) が使われます。CLS も Lab では「ファーストビューだけ」を測るため、無限スクロールや遅延読み込みで起きる CLS は検出できません。

三層構造で使い分ける

2026 年現在、CWV 計測の最適解は次の 3 層を併用する設計です。

この三層を意識せずに「PageSpeed のスコアだけ」を追っていると、改修したのに Search Console が改善しない、Lab では Good なのに本番ユーザーには Poor のままといった事態に陥ります。 → 詳しくはCore Web Vitals入門｜LCP・INP・CLSをやさしく解説で各指標の構造を再確認できます。

PageSpeed Insights 詳細

PageSpeed Insights (PSI) は Google 公式の無料計測ツールで、CWV 改善の起点になる最重要ツールです。URL を入力するだけでフィールドデータと Lab データの両方を一度に確認できます。

PSI のデータ構成

PSI の結果画面は大きく 4 ブロックに分かれます。

注意すべきは、Core Web Vitals の合否判定は「フィールドデータの 75 パーセンタイル」で決まる点です。Lighthouse スコアが 100 でも、フィールドが Poor なら SEO 評価は改善しません。逆もまた然りで、Lighthouse スコアが 60 でも、フィールドが Good なら問題ありません。

URL レベル / オリジンレベル

PSI では「この URL」と「オリジン全体 (ドメイン全体の集計)」の 2 つの粒度で結果が出ます。アクセスが少ない個別 URL は CrUX にデータがなく「URL データなし」と表示され、その場合はオリジンレベルの数値が代用されます。

ロングテール記事サイトでは多くの URL が「データなし」になるため、PSI はオリジンレベルで傾向を掴み、Lab データで個別ページを検証する併用が現実的です。 → 詳しくはテクニカルSEO完全ガイドでクローラビリティ全体の検証も確認できます。

PSI の API 利用

PSI は無料の REST API (pagespeedonline/v5/runPagespeed) を提供しており、自動計測パイプラインに組み込めます。GitHub Actions の CI でリリース前に実行し、スコアが閾値を割れば PR をブロックする運用が一般的です。

PSI のメリットと弱点

メリットはなんと言っても「Google 公式 = 評価基準そのもの」である点と、無料で誰でも使える手軽さです。一方の弱点は、Lab 計測の環境が固定 (Moto G4 + Slow 4G 相当) で、自社ターゲットユーザーの実機環境とは乖離することです。また、ログイン後ページや認証ページは計測できません。

Lighthouse 詳細

Lighthouse は Google 製のオープンソース監査ツールで、Performance / Accessibility / Best Practices / SEO / PWA の 5 カテゴリを Lab データで評価します。PSI のバックエンドも Lighthouse です。

4 つの実行方法

Lighthouse には複数の実行手段があり、用途で使い分けます。

ローカル DevTools での実行は手元の回線・PC スペックに影響されるため、結果は参考値にとどめます。CI 組み込みなら Lighthouse CI を使い、PR ごとに自動計測する設計が王道です。

Lighthouse のスコアリング

総合スコアは各メトリクスの加重平均で算出されます。2026 年時点 (Lighthouse 12.x) の Performance カテゴリの重み付けは次のとおりです。

INP の Lab 代替が TBT である点に注意が必要です。TBT が低くても、実ユーザーの操作シナリオ次第で INP が悪化することがあります。Lab で TBT を下げつつ、フィールドで INP を確認する両輪が必須です。 → 詳しくはCore Web Vitals入門｜LCP・INP・CLSをやさしく解説で INP と TBT の違いを確認できます。

Lighthouse のメリットと弱点

メリットは無料・OSS・カスタマイズ自由・CI フレンドリーという開発者向けの強みです。Performance 以外に Accessibility や SEO 監査も含まれ、技術 SEO 全般のチェックリストとして機能します。

弱点は「Lab 計測のため INP の真値が出ない」「ログイン後ページは標準では測れない (Puppeteer 連携で解決可)」「結果が実行ごとにブレる (3-5 回平均推奨)」という点です。

GTmetrix 詳細

GTmetrix は カナダ Carbon60 社が運営する商用 Lab 計測ツールで、Lighthouse をベースに独自の UI と履歴機能を加えています。日本でも長年使われており、SEO 担当者から開発者まで広く愛用されています。

GTmetrix の特徴

GTmetrix Grade

GTmetrix 独自の "GTmetrix Grade" は Performance スコア (Lighthouse) と Structure スコア (独自監査) の組み合わせで、A〜F のレターグレードで表示されます。経営層への報告で「グレード A をキープ」のような分かりやすい目標設定がしやすいのが商用ツールの強みです。

料金プラン (2026 年時点)

GTmetrix のメリットと弱点

メリットは「履歴グラフが直感的」「拠点を選べる」「定期監視で劣化アラート」など運用面の強さです。とくに「リリース後 1 週間ぐらいは毎日定点観測したい」というケースで Lighthouse CLI より楽です。

弱点は商用 Lab ツールゆえに「フィールドデータがない」点です。GTmetrix のスコアが A でも、Search Console の CWV が Poor のままという乖離が起きえます。フィールドは PSI / Search Console、定点 Lab は GTmetrix、という棲み分けが現実解です。 → 詳しくはSEOツール比較2026｜有料・無料それぞれのおすすめで他ツールとの組み合わせも確認できます。

WebPageTest 詳細

WebPageTest (webpagetest.org) は Catchpoint 社が運営する Lab 計測ツールの「最深ツール」です。1999 年から続く老舗で、世界 40 拠点以上、実機端末 (実 Android / iPhone) で計測できる唯一のクラスのツールです。

WebPageTest の独自機能

特に Filmstrip と Waterfall は他ツールでも見られますが、WebPageTest の細かさは別格で、「リクエストの何 ms 目に何が起きたか」をミリ秒単位で追えます。LCP が遅い真因を特定する深掘りツールとして機能します。

料金プラン (2026 年時点)

WebPageTest のメリットと弱点

メリットは「実機・多拠点・深掘り可視化」という Lab の到達点です。「東京から計測すると LCP 1.5 秒、シドニーから測ると LCP 5 秒」のような地域別問題は WebPageTest でないと検出できません。グローバル展開サイトでは必須クラスです。

弱点は「学習コストが高い」「無料枠が少ない」「UI が古い」という点です。日々の定点監視より、深刻なボトルネックの原因究明フェーズで活躍します。

Web Vitals Chrome 拡張機能

Web Vitals Chrome 拡張は Google 製の無料拡張で、開いているタブの LCP/INP/CLS をリアルタイム表示します。開発中の即時検証 (三層構造の「即時検証層」) を担う必須ツールです。

主要機能

特に LCP 要素のハイライトは「LCP 改善したい画像はどれか」を即座に教えてくれるため、改善着手のスピードが段違いです。

Console Logging を有効にすると分かる情報

拡張のオプションで "Log Web Vitals" を有効にすると、DevTools Console に以下が出力されます。

// 出力例 (擬似コード)
LCP: { value: 2400, element: <img id="hero">, attribution: { ... } }
INP: { value: 320, target: <button>, eventType: 'click' }
CLS: { value: 0.18, sources: [{ node: <div class="ad">, ... }] }

attribution 情報には LCP の TTFB / Resource Load Delay / Resource Load Time / Element Render Delay の内訳が含まれ、「LCP のどのフェーズが遅いのか」をクリック 1 つで把握できます。 → 詳しくはCore Web Vitals入門｜LCP・INP・CLSをやさしく解説で LCP の 4 フェーズ構造を確認できます。

Web Vitals 拡張の注意点

拡張の数値は「自分の PC・回線・キャッシュ状態」に強く依存します。本番ユーザー全体の代表値ではないため、SEO 評価の最終判断には使えません。あくまで「実装中に数値感を掴む」「LCP/CLS 要素を特定する」用途に限定しましょう。

CrUX (Chrome User Experience Report)

CrUX は PageSpeed Insights や Search Console の裏側にあるフィールドデータの大本です。月次更新の BigQuery データセットとして公開されており、自社・競合・業界全体の CWV 分布を分析できます。

CrUX の 3 つのアクセス方法

CrUX API はリクエスト無料 (Google API キーで 150 req/分) で、自社サイトと競合サイトの CWV 比較ダッシュボードを Looker Studio で構築するのが定番パターンです。 → 詳しくはSEOツール比較2026｜有料・無料それぞれのおすすめでデータ可視化基盤の選び方も確認できます。

CrUX 収集対象

CrUX に記録されるユーザーは「Chrome の同期を有効にし、利用統計レポートを送信し、Web 履歴の保存を有効にしている」人に限られます。Safari / Firefox / Edge ユーザーや、プライバシー保護モードのユーザーは CrUX に含まれません。これは「Chrome ユーザーが多い日本では大きな代表性がある」一方、「iOS Safari 比率が高いインバウンド向けサイトでは過小評価リスクがある」ことを意味します。

このため、グローバル展開サイトや法人向けサイトでは CrUX に加えて自社 RUM (Datadog RUM / Sentry / Vercel Analytics など) を導入する設計が安全です。

ツール機能比較表

ここまでの 6 ツールを横断比較します。

機能比較

料金比較 (2026 年時点)

「無料縛りで構築するなら PSI + Lighthouse CI + Web Vitals 拡張 + CrUX API」、「商用運用なら + GTmetrix or WebPageTest」というのが基本戦略です。 → 詳しくは完全無料で使えるSEOツール厳選2026で無料スタックの組み方を確認できます。

用途別 おすすめツール

改善ワークフロー

ツールを揃えるだけでは CWV は改善しません。次の 6 ステップのワークフローに沿って運用するのが効率的です。

ステップ 1: フィールドで現状診断

最初に Search Console の Core Web Vitals レポートで「どの URL グループが Poor / Needs Improvement か」を把握します。次に PSI でオリジン全体と代表 URL を確認し、3 指標 (LCP/INP/CLS) のうちどれがボトルネックかを特定します。

ステップ 2: Lab で原因深掘り

Lighthouse / WebPageTest で代表 URL を計測し、Diagnostics や Waterfall から原因を特定します。LCP なら「LCP 要素は何か」「TTFB / Load Delay / Load Time / Render Delay のどこが遅いか」を Web Vitals 拡張の attribution 情報も併用して切り分けます。 → 詳しくはCore Web Vitals入門｜LCP・INP・CLSをやさしく解説で各フェーズの改善策を確認できます。

ステップ 3: 仮説と改修

原因に基づいて改修案を立てます。例えば LCP の Resource Load Time が遅いなら「画像 WebP/AVIF 化 + 適切な srcset + fetchpriority="high"」というように、原因とアクションを 1:1 対応させます。

ステップ 4: ローカル検証

開発環境で Web Vitals Chrome 拡張を有効にし、改修前後の数値を即時比較します。HUD で LCP/INP/CLS の変化を見ながら、Console Log で attribution の改善を確認します。

ステップ 5: ステージングで Lab 検証

ステージング環境で Lighthouse CI または GTmetrix を 3-5 回実行し、平均で改善が確認できることを検証します。1 回だけだと外れ値に騙されるため、必ず複数回平均で判断します。

ステップ 6: 本番リリース後 4 週間モニタリング

CrUX は 28 日ローリングのため、本番反映から 4 週間かけて段階的にフィールドデータが改善します。Search Console の Core Web Vitals レポートを週次で確認し、不良 URL 数の減少曲線を追います。

「リリース翌日に Search Console を見て改善していない」と早合点しないことが重要です。

CMS 別 計測ツール活用

CMS や フレームワーク によって、計測ツールの組み込み方法と相性が異なります。

WordPress での活用

WordPress では「テーマ依存で LCP 要素が異なる」「プラグイン累積で TBT/INP 悪化」が定番のボトルネックです。GTmetrix で月次監視、PSI で SEO 評価、Web Vitals 拡張で原因究明という三層が現実解です。 → 詳しくはWordPress テーマ・プラグインの選び方で WordPress 固有の最適化も確認できます。

Next.js / Nuxt での活用

Next.js / Nuxt なら Lighthouse CI を GitHub Actions に組み込み、Performance スコアが閾値を割れば PR をブロックする CI ゲートが鉄板です。Vercel Analytics は RUM データを Web Vitals API ベースで収集し、CrUX より自社サイト固有の値が見えます。

EC サイト (Shopify / BASE / EC-CUBE)

EC サイトは「商品画像が LCP 要素」「カート JS が INP ボトルネック」「レビュー埋め込みが CLS 原因」という三大悪化要因を抱えます。Shopify なら "Online Store 2.0" のテーマ最適化機能、BASE / EC-CUBE なら独自テーマでの画像最適化が必須です。

よくある失敗事例

実プロジェクトで頻発する失敗パターンを事例ベースで整理します。これらを知っておくだけで、無駄な工数を大きく減らせます。

失敗 1: PSI スコアだけで判断する

「Lighthouse スコアが 90 になったので OK」と判断したものの、フィールドデータの LCP は依然 4 秒台で Search Console 上は Poor のまま、というパターンです。Lab スコアと SEO 評価は別物だと理解する必要があります。

失敗 2: 1 回計測で結論を出す

Lighthouse は 5 回実行すれば 5 通りの数値が出ます。1 回だけ見て改善 / 悪化を結論付けると、外れ値に振り回されます。Lab は必ず 3-5 回平均、フィールドは 28 日ローリングで判断します。

失敗 3: 改善後すぐにフィールドを見て落胆

CrUX は 28 日ローリングのため、リリース翌日のフィールド変化はほぼゼロです。「リリースしたのに数値が変わらない」と早合点して追加改修を入れると、原因が混在して効果検証が不可能になります。 → 詳しくはKPI設計と効果測定の基本｜SEOで本当に追うべき指標で計測サイクルの基礎も確認できます。

失敗 4: ログイン後ページを忘れる

PSI / Lighthouse は基本的に認証なしページしか測れません。SaaS のダッシュボードや EC のマイページは「最も触られるページ」なのに計測対象から漏れがちです。Puppeteer 連携の Lighthouse や WebPageTest の Multi-step を使う必要があります。

失敗 5: モバイルとデスクトップを混同

CWV の SEO 評価は「モバイルファーストインデックス前提でモバイル値が主」です。PSI のデフォルトはモバイルですが、GTmetrix のデフォルトはデスクトップで、ツール混用で「モバイル値とデスクトップ値を比較」してしまう事故が起きます。常にどちらの値か明記する運用が必須です。

失敗 6: INP を Lab スコアで代替して安心する

Lighthouse は INP を測れず、代替で TBT を表示します。TBT が低くても、ユーザーの実操作 (フォーム入力、複雑なスクロール) で INP が悪化することは普通にあります。INP は CrUX フィールド値と RUM (Vercel Analytics 等) で監視します。 → 詳しくはCore Web Vitals入門｜LCP・INP・CLSをやさしく解説で INP 改善のアプローチを確認できます。

失敗 7: AdSense / Tag Manager を忘れる

広告タグ・GTM・Hotjar など外部スクリプトは CWV の最大の敵ですが、ローカル開発環境では読み込まれず、ステージングでも軽量化されがちです。本番でしか露呈しないため、本番 PSI と Search Console での確認が不可欠です。

失敗 8: 拡張だけで判断する

Web Vitals Chrome 拡張の値は自分の PC とネット環境に強く依存します。「私の手元では Good」を SEO 評価の根拠にしてはいけません。あくまで「即時検証層」として、フィールド層 (PSI / CrUX) と組み合わせて使います。

ツール選定 早見表

迷ったときの早見表です。

FAQ

Q1. PageSpeed Insights のスコアと Lighthouse のスコアが違うのはなぜですか?

PSI は Google サーバー上で固定環境 (Moto G4 + Slow 4G) で実行され、ローカル Lighthouse はあなたの PC と回線で実行されるため、計測条件が違います。PSI のスコアの方が SEO 評価に近い参考値になります。再現性ある比較には Lighthouse CI を使い、計測環境を固定するのが正解です。

Q2. Search Console の Core Web Vitals レポートと PSI の数値が違います

Search Console は Google が選んだ「URL グループ単位」の集計、PSI は「URL またはオリジン単位」の集計で、グルーピング粒度が違います。また、Search Console は集計期間が異なるため、改修反映のタイミングずれも発生します。原則として「Search Console を最終 SEO 評価」「PSI を改修判断のスナップショット」と使い分けます。 → 詳しくはGoogle Search Consoleの使い方｜初心者の最初の30分で Search Console の見方を確認できます。

Q3. CrUX に自社 URL のデータが出ません

その URL の Chrome 同期ユーザートラフィックが少なすぎる可能性が高いです。オリジンレベルでも出ない場合、サイト全体のトラフィックも不足しています。この場合、PSI の Lab 値と Web Vitals 拡張で改善判断を行い、フィールドデータは Search Console のページグループ集計を待つ運用になります。

Q4. Lighthouse の INP はどう見ればいいですか?

Lighthouse は INP の真値を測れず、代替で TBT (Total Blocking Time) を表示します。INP の本値は CrUX (フィールド) と Web Vitals 拡張 (実操作) で確認します。CI では TBT を品質ガードし、本番監視では INP を見るという二層が標準です。

Q5. GTmetrix と WebPageTest はどっちが良いですか?

定点監視・履歴グラフ・経営層向けレポートなら GTmetrix が UI で勝ります。深掘り原因調査・実機計測・多拠点計測なら WebPageTest が機能で勝ります。月次定点に GTmetrix、深刻問題発生時に WebPageTest という併用が現実的です。 → 詳しくはSEOツール比較2026｜有料・無料それぞれのおすすめで他カテゴリも含めた比較を確認できます。

Q6. ログイン後ページの CWV はどう計測しますか?

PSI では計測できないため、Puppeteer 連携の Lighthouse スクリプト、WebPageTest の Multi-step 機能、または自社 RUM (Vercel Analytics / Datadog RUM / Sentry) を使います。SaaS や EC のマイページは最重要動線のため、必ずどれかで計測します。

Q7. CWV を改善したら本当に SEO 順位が上がりますか?

Google 公式は「CWV はランキングシグナルの 1 つで、コンテンツの関連性や品質を上回るものではない」と明言しています。つまり「コンテンツが拮抗したときの差別化要素」です。コンテンツ品質が劣後している状態で CWV だけ改善しても順位は動きません。コンテンツ × CWV の両輪で取り組むのが原則です。

Q8. モバイルとデスクトップ、どちらを優先すべきですか?

モバイルファーストインデックスの現在、評価の主はモバイルです。BtoB SaaS など PC 利用比率が高いサイトでもモバイル CWV を最優先で改善し、デスクトップは従属的に見ます。GTmetrix のデフォルトはデスクトップなので、明示的にモバイルプロファイルに切り替えます。

Q9. 無料ツールだけでどこまで運用できますか?

PSI + Lighthouse CI + Web Vitals Chrome 拡張 + CrUX API + Search Console の組み合わせで、中規模サイトまでは十分運用できます。商用ツールの価値は「履歴の可視化」「定点監視のアラート」「多拠点・実機計測」に集約されるため、それらが必要になった段階で GTmetrix / WebPageTest を導入する判断で問題ありません。 → 詳しくは完全無料で使えるSEOツール厳選2026で無料スタックの作り方を確認できます。

Q10. AI クローラー (GPTBot / Claude-Web 等) も CWV を見ていますか?

現時点で公開情報に基づく限り、主要 AI クローラーは CWV をランキングシグナルとして使っているとは表明していません。ただし、ページの読み込みが遅すぎてタイムアウトすれば、当然インデックス対象から外れます。LLMO 観点でも CWV の最低限 (LCP 4 秒以下) はクリアしておくのが無難です。

まとめ｜三層計測スタックを組む

Core Web Vitals の計測は「フィールド層 = PSI / CrUX / Search Console」「Lab 層 = Lighthouse / GTmetrix / WebPageTest」「即時検証層 = Web Vitals Chrome 拡張」の三層構造で運用するのが 2026 年の最適解です。

各ツールには得意分野と弱点があり、単独で完結することはありません。「SEO 評価判断はフィールド」「改修前後の比較は Lab」「開発中の即時確認は拡張」という役割分担を徹底すれば、ツール間の数値の食い違いに振り回されず、本当に SEO 評価を改善する施策に集中できます。

まずは無料スタック (PSI + Lighthouse CI + Web Vitals 拡張 + CrUX API + Search Console) で運用を始め、定点監視や深掘り調査の必要性が高まった段階で GTmetrix や WebPageTest を追加する成長路線が現実的です。 → 詳しくはCore Web Vitals入門｜LCP・INP・CLSをやさしく解説で 3 指標の基礎を、完全無料で使えるSEOツール厳選2026で無料ツールスタックを確認できます。

関連用語

• SEO
• LLMO
• LCP
• INP
• CLS
• Core Web Vitals
• GSC
• モバイルファーストインデックス

関連記事

• Core Web Vitals入門｜LCP・INP・CLSをやさしく解説
• Google Search Consoleの使い方｜初心者の最初の30分
• SEOツール比較2026｜有料・無料それぞれのおすすめ
• 完全無料で使えるSEOツール厳選2026