Core Web Vitalsレポート（Google Search Console）

TL;DR — Google Search ConsoleのCore Web Vitalsレポートは、実際の訪問者にとってのGoogleの3つの速度・安定性指標（LCP、INP、CLS）について、ページがどう動作するかを示します。Chromeユーザーの実世界データを似たページのグループにまとめ、モバイルとデスクトップを分けて表示します。サイト全体の問題を見つけるためのツールであり、ページごとの速度チェッカーではありません。小規模サイトや新しいサイトでは、データがまったく表示されないことがあります。

Core Web Vitalsレポートとは

Google Search Consoleのエクスペリエンスセクションにあります。Googleの説明は次のとおりです。“shows how your pages perform, based on real world usage data (sometimes called field data).” (翻訳)「実世界の利用データ（フィールドデータと呼ばれることもあります）に基づいて、ページがどのように動作するかを示します。」

まず明確にしておきたいのは、これは指標そのものではなく、レポートだということです。 Core Web VitalsのLCP、INP、CLSは、実際の訪問者にとってページがどう感じられるかを測る3つの指標です。主なコンテンツの読み込み速度、タップへの応答速度、読み込み中のレイアウトのずれを扱います。指標の詳細な定義はこのサイトの別記事で説明しています。この記事の対象は、Search Consoleで数値を表示し整理するレポートというツールです。

データはどこから来るか

このレポートは速度テストを実行しません。Chrome User Experience Report（CrUX）から、ページを訪れた実際のChromeユーザーの匿名化された計測値であるフィールドデータを取得します。管理された環境でページを一度読み込むPageSpeed Insightsのラボテストとは異なります。フィールドデータは実際の人々に起きたことを、直近28日間で平均したものです。

レポートの整理方法

URLのグループ化について、押さえるべき点は3つあります。

• モバイルとデスクトップは別タブです。 同じページがモバイルでは「Good」、デスクトップでは「Poor」になることがあります。両者を平均することはありません。
• ステータスは3種類です。 Poor、Need improvement、Goodです。URLのステータスは最も悪い指標で決まり、1つの悪い数値がページ全体を引き下げます。
• URLは1件ずつ採点されず、グループ化されます。 Googleは似たページ（通常は同じページテンプレート）をまとめるため、1つの問題が多数のURLに一度に影響しているように見えます。

多くの人が誤解する点

このレポートだけでは、特定の1ページが遅いかどうかを確実には判断できません。 Googleは明確に、“not designed [to] find the status of a specific URL, but rather to see your site’s performance as a whole.” (翻訳)「特定のURLのステータスを見つけるためではなく、サイト全体のパフォーマンスを見るために設計されています」と説明しています。用途はサイト全体やテンプレート単位の問題を見つけることです。1ページを確認する場合は、PageSpeed InsightsまたはURL検査ツールを使います。

早い段階で知っておきたいことが、もう2つあります。

• 「No data available」はよく表示され、通常はページの問題を意味しません。 Search Consoleのプロパティが新しいか、表示中の端末（モバイルまたはデスクトップ）について、Googleのレポートしきい値を満たすだけのChromeトラフィックがないかのどちらかです。
• 反映には約1か月かかります。 28日間の平均なので、今日公開した修正がこのレポートに完全に現れるまで数週間かかります。早いフィードバックにはPageSpeed Insightsを使います。

URLグループが実際にどう機能するか、PageSpeed Insightsと一致しない理由、検証フロー、FIDに起きたことまで確認するには、Advancedタブへ切り替えてください。

TL;DR — Core Web Vitalsレポートは、インデックス登録済みURLのCrUXフィールドデータを、移動28日間・75パーセンタイルで表示します。新しい測定値を計算するものではありません。端末（独立したモバイル／デスクトップタブ）、ステータス（Poor／Need improvement／Good、最も悪い指標が勝つ）、URLグループ（似たテンプレートのページをまとめ、1つのステータスを共有）で整理します。表示対象はインデックス登録済みURLのサンプルで、すべてのURLではありません。URLグループがプライバシー上の報告規模に届かなければ、上位のオリジングループへフォールバックし、それでもしきい値を満たせなければ「No data available」となります。グループ単位と単一URL単位の違い、GSCはURLパラメータを区別しPSIは削除する違いがあるため、PageSpeed Insightsとは一致しません。用途はサイト全体のトリアージで、単一URLの照会ではありません。FIDは2024年3月12日に削除されました。 INPがCore Web Vitalになった日にGSCから即時に消え、PSI／CrUXの6か月の移行期間とは異なります。「Poor」を先に直し、Start Trackingで検証し、フィールドデータの反映を約1か月待ちます。

これは指標の再定義ではなく、レポートです

この記事で最も重要な見方は、Core Web Vitalsレポートがすでに存在するデータの表示であり、新しい測定ではないということです。Googleは次のように明記しています。“the data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (翻訳)「Core Web VitalsレポートのデータはCrUXレポートから取得されます。CrUXレポートはURLを訪れた実際のユーザーのパフォーマンス時間に関する匿名化された指標（フィールドデータ）を集めます。CrUXデータベースは、そのURLがSearch Consoleプロパティに含まれるかどうかにかかわらず、URLの情報を収集します。」

したがって、このレポートにはラボデータが一切ありません。Lighthouseのスコアも合成テストもなく、100%フィールドデータ、つまり実際のChromeユーザーによる移動28日間のデータを端末別に75パーセンタイルで示します。指標の定義、しきい値、ランキングシグナルの重みはCore Web Vitalsの用語集とweb-vitalsトピックで扱うため、ここでは再説明しません。この記事の対象はツールです。

インデックス登録済みURLだけ、しかもサンプルです

見落とされがちな範囲のルールは3つあります。第一に最も基本的な点として、URLグループはLCPとCLSの両方についてデータしきい値を満たして初めて表示されます。両方の報告データが不足しているグループは、合格扱いにせずレポートから完全に除外されます。第二に、“Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (翻訳)「このレポートに表示されるのはインデックス登録済みURLだけです。すべての登録済みURLの完全な一覧ではなく、Core Web Vitalsに基づくサイトのパフォーマンス評価に役立つページのサンプルを表示します。」したがって、網羅的な監査と解釈しないでください。第三に、他のGSCレポートと違う細かな点として、“Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (翻訳)「ほとんどの他のレポートのようにcanonical URLではなく、実際のURLにデータが割り当てられます。」多くのSearch Consoleレポートはcanonicalへ集約しますが、このレポートはそうしません。

モバイルとデスクトップは別々のデータセット

このレポートは端末ごとに分解され、2つのタブは完全に独立しており、平均されません。同じURLグループがモバイルではGood、デスクトップではNeed improvementになることがあります。端末、ネットワーク、CPUクラスが異なるCrUXデータセットを反映するためです。必ず両方のタブを確認してください。一方の「Good」要約が、もう一方の「Poor」グループを隠すことがあります。

最も悪い指標がステータスを決める

各URLグループはPoor、Need improvement、Goodの3つのいずれかになり、グループのステータスは最も悪い指標のものになります。LCPとINPがGoodでもCLSがPoorなら、グループはPoorです。この「最も悪い指標が勝つ」ルールのため、1つの不安定なレイアウト要素が、他は高速なテンプレート全体を悪化させることがあります。

基礎となるしきい値は、「Good」に対するLCP ≤2,5s／INP ≤200ms／CLS ≤0,1（いずれもp75）で、Core Web Vitals用語集にある指標定義です。調査時点でも、公開中のSearch Central文書はこの元の数値を掲載しています。Googleが「Good」のLCPしきい値をひそかに2,0秒へ下げた、または2025年後半のコアアップデートでCore Web Vitalsのランキング要因が大幅に強くなったという主張を見かけても、Google所有の資料では確認できず、文書とも矛盾します。噂として扱ってください。

URLグループ — 中核となる仕組み

これはレポートの特徴であり、PageSpeed Insightsの単一URLの習慣から来た人にとって最大の考え方の転換です。Googleは次のように説明しています。“URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (翻訳)「レポート内のURLは、似たユーザー体験を持つページにグループ化されます。LCP、INP、CLSのステータスはグループ全体に適用されます。一部の外れ値URLは訪問によって良い値や悪い値になることがありますが、グループ内の全URLへの訪問の75%が表示されたグループステータスを経験しました。」

John Muellerは2021年にこの仕組みを説明しました。“We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (翻訳)「Chrome User Experience Reportのデータ、つまり実世界のフィールドデータを使い、十分に似ているページを認識してグループ化しようとしています。」さらに重要なのは、グループのデータが固有データのないURLの代わりになることです。“If we find a new URL that is also a part of this group, we don’t have to have data for that new URL. We can rely on the data for the group overall.” (翻訳)「このグループに属する新しいURLを見つけた場合、その新しいURL自体のデータがなくても、グループ全体のデータを利用できます。」

だから、実際には1つのバグでもレポートが警告だらけに見えることがあります。Muellerはさらに、“We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (翻訳)「サイトに本質的には1つのグループしかなくても、そこに数千のURLが含まれることがあります。そのためSearch Consoleのレポートでは、数千のURLにこの問題があると表示するでしょう」と述べています。テンプレートの1つの欠陥が、数千URLのフラグになります。

だからこそ、グループ化は煩わしいのではなく有用です。私のAhrefs Core Web Vitalsガイド で述べたように、“This grouping of pages makes a lot of sense. This is because most of the changes to improve Core Web Vitals are done for a particular page template that impacts many pages.” (翻訳)「このページのグループ化は理にかなっています。Core Web Vitalsを改善する変更の多くは、多数のページに影響する特定のページテンプレートに対して行われるからです。」また、PageSpeed Insightsガイド では、“The benefit of GSC is that it buckets similar URLs. For the bucketed pages, you will likely be working in one system or template.” (翻訳)「GSCの利点は似たURLをまとめることです。まとめられたページでは、1つのシステムまたはテンプレートを扱うことになるでしょう」と説明しています。テンプレートを1度直せば、グループ全体を直せます。さらにOutside Communicationsのインタビュー で、“Basically, here are groups with issues that probably share the exact same theme. You fix it once, you fix that issue for all those pages.” (翻訳)「基本的には、同じテーマを共有している可能性が高い問題グループです。一度直せば、その問題をすべてのページで直せます」と表現しました。

プライバシーしきい値とオリジングループへのフォールバック

グループ化は便利なだけでなく、プライバシー要件でもあります。Googleは、“In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (翻訳)「ユーザーのプライバシーを守るため、URLグループをレポートに表示するには最低限のデータが必要です。URLグループに表示に足る情報がなければ、Search Consoleはレポートに表示できるだけのURLとデータを含む上位のオリジングループを作成します。」この連鎖は、URLグループ → オリジングループ → 何もなし、です。オリジンでもしきい値を満たせない場合は「No data available」となります。これが、トラフィックの少ないサイトで大まかなグループ化やデータなしが生じる仕組みです。

なぜPoorグループにも高速なページが含まれるのか

ステータスはグループ全体の75パーセンタイルに適用されるため、個別には高速なURLが遅いグループに含まれることがあります。Poorグループに入ったからといって、そのURLが遅いとは限りません。クラスター全体に問題があるという意味であり、全メンバーを有罪と決めつけず、分析単位をグループとして扱います。

レポートを読む：チャートと表

第三者ガイドの多くが省く、混乱しやすい点です。ランディングチャートと問題表では数え方が異なります。“The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (翻訳)「チャートは各URLに影響する最も遅い問題について、URLを1回だけ数えます。一方、表はURLに関連するすべての問題を数えます。」そのため、Poorの問題とNeed improvementの問題が1つずつあるURLは、チャートではPoorとして1回、表では両方の行に表示されます。合計が一致しないのはバグではなく仕様です。問題をクリックすると、“gives you a breakdown of page groups that are impacted” (翻訳)「影響を受けたページグループの内訳」が表示され、例URLはインプレッション順に並びます。

修正を検証する：Start Trackingのワークフロー

このレポートには見落としやすい検証ループがあります。Googleは、“When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (翻訳)「特定の問題を修正したと思ったら、Search ConsoleのCore Web Vitalsレポートの問題詳細ページでStart Trackingをクリックしてください」と説明しています。これにより問題について28日間の監視セッションが始まり、その間Googleは即時に再チェックするのではなくグループのフィールドデータを蓄積します。監視中に影響を受けたURLが1つでも失敗し続ければ、問題全体が合格しないことがあります。問題レベルのステータスはNot started／Started／Looking good／Passed／N/A／Failed、URLごとのステータスはPending／Passed／Failedです。Start Trackingをクリックしても再インデックスや能動的なクロールは開始されません。Googleがすでに収集しているデータを監視するフラグにすぎません。集計チャートを眺めて期待するのではなく、フィールドで修正を確認する正式な方法です。

Core Web VitalsレポートとPageSpeed Insights

この2つのツールは同じCrUXというデータ源から取得しますが、表示方法が異なるため、URLについて定期的に食い違います。文書化されている理由は2つあります。

• グループと個別URLの違い。 Googleは、“Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (翻訳)「Core Web VitalsはデータとステータスをURLグループにまとめ、PageSpeed Insightsは通常、個別URLのデータを表示します」と説明しています。1つのURLがグループ内の外れ値なら、そのグループのステータスとURL単体のPSI数値は一致しません。
• URLパラメータの扱い。 “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (翻訳)「Core Web Vitalsはページを区別する際にURLパラメータを含めますが、PageSpeed InsightsはURLからすべてのパラメータを削除し、結果をパラメータなしのURLに割り当てます。」これだけでも、2つのツールが一致しない理由の多くを説明できます。

「フィールドデータ」と「ラボデータ」は曖昧に使われるため、データの範囲も整理しておきます。GSCレポートはグループ化されたCrUXフィールドデータだけで、他のデータはありません。PageSpeed Insightsは3つを組み合わせます。URLレベルのCrUXフィールドデータ、URLに十分なデータがない場合のオリジンレベルCrUXへのフォールバック、そしてライブのLighthouseラボ実行です。PSIガイド で説明したとおり、“PageSpeed Insights also pulls in the page level data, as well as origin data and lab test data which comes from Lighthouse.” (翻訳)「PageSpeed Insightsはページレベルデータだけでなく、オリジンデータとLighthouseから得られるラボテストデータも取り込みます。」GSCレポートにはこのラボ層がなく、完全にフィールドデータだけです。

私の実際のワークフローと、多くの競合記事が見落とす実務上のコツは、PSIのラボデータで素早く診断・検証し、GSCで遅いが実際の問題を確認することです。PSIガイド には、“The CWV data will take longer to show the impact of any changes because it is a 28-day average, so use PSI or the PSI data in Ahrefs to check if the changes you made improved the lab test metrics.” (翻訳)「CWVデータは28日間の平均なので、変更の影響が表示されるまで時間がかかります。PSIまたはAhrefsのPSIデータを使い、変更によってラボテスト指標が改善したか確認してください」とあります。変更が効いたかはラボで即時に確認し、その後数週間、GSCのフィールドデータが追いつくのを待ちます。

「No data available」とトラフィックの少ないサイト

Google自身の説明は次のとおりです。“If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (翻訳)「『No data available』画面が表示される場合、Search Consoleのプロパティが新しいか、選択した端末タイプ（デスクトップまたはモバイル）について意味のある情報を提供するだけのCrUXデータがないかのどちらかです。」CrUXには適格性しきい値があり、フィールドデータが表示されるにはURLまたはオリジンに十分なChromeトラフィックが必要です。

どの程度よく起きるのでしょうか。非常によく起きます。私の2022年1月の調査では、43,66M件の一意なSite Audit ページとCrUXを照合しました。“We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (翻訳)「Core Web Vitals指標が1つ以上あったのはわずか5,21M（約11,9%）で、その93%（合計約4,85M）が3指標すべてを持っていました。」これはGSCそのものではなく、GSCレポートが参照するのと同じCrUXの生データセットを調べた結果で、2022年1月の数値です。現在の割合ではなく規模感を示すものとして扱ってください。ウェブ上の多くのページはフィールドデータを生成するほどChromeトラフィックがなく、そのためレポートはオリジンレベルのグループ化に頼り、多くのサイトで何も表示されません。該当する場合も健全性の証明ではなく、PageSpeed InsightsまたはLighthouseで個別URLをテストしてください。

FIDはなくなった — 2024年3月の変更

ここは正確に理解してください。古いチュートリアルではまだ誤って説明されています。Interaction to Next Paint（INP）は、2024年3月12日にFirst Input Delay（FID）をCore Web Vitalとして置き換えました。ほとんど説明されないSearch Console固有の点として、Chromeチームのweb.dev発表 には、“FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (翻訳)「INPが3月12日にCore Web Vitalになると同時に、FIDはGoogle Search Consoleから削除されます。PageSpeed InsightsやCrUXなど他のツールには、開発者がコードを更新できるよう6か月の非推奨期間があります」とあります。つまりGSCは猶予なくFIDを即時削除し、PSIとCrUXはさらに6か月表示しました。Search ConsoleのスクリーンショットにFIDがあれば、2024年3月より前のものです。

Page Experienceレポートはどうなったか

今も検索される混乱ポイントです。Googleは、Core Web VitalsとHTTPSなどのUXシグナルをまとめていた旧ダッシュボード、独立したPage Experienceレポートを2023年4月19日にSearch Consoleから削除しました。残ったのはCore Web VitalsレポートとHTTPSレポートで、現在もそれぞれ独立したレポートとして存在します。統合サマリーだけがなくなったのです。「Page Experience」ダッシュボードが見つからない理由はこれです。その下にあった2つのレポートは残っています。PerformanceレポートやPage Indexingレポートなどの関連レポートは、Search Consoleの他の範囲を扱います。

レポートが見つけた問題の優先順位付けと修正

Googleの案内は非技術者向けと開発者向けに分かれており、このレポートが異なる読者に使われることが分かります。全員に共通する優先順位は、「Poor」を先に直し、次に「Need improvement」を直すことです。開発者向けには、グループ内のURLがインプレッションの多い順に並ぶため、上位のURLほどグループのステータスに大きく影響します。

Googleが挙げるページ単位の修正は単純ですが、実際的です。“Reduce your page size: best practice is less than 500KB for a page and all its resources.” (翻訳)「ページとそのすべてのリソースを合わせて、ページサイズを500KB未満にするのがベストプラクティスです。」それ以外のLCP、INP、CLSの改善方法は個別指標の記事に任せ、ここでは重複させません。このレポートの仕事は直すべきテンプレートを知らせることであり、修正そのものではありません。

何も変更していないのにステータスが変わった理由

非常によく起きることで、通常はバグではありません。Googleのトラブルシューティングには、“If you didn’t make any changes in your site, but you see a big change in status for a lot of pages, it’s possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge.” (翻訳)「サイトを変更していないのに多数のページのステータスが大きく変わった場合、多くのページが境界付近のステータスで、サイト全体の何らかの出来事によってしきい値を越えた可能性があります」とあります。トラフィック構成の変化、CDNや画像ホストの遅延、広く適用されたブラウザー更新などは、28日間のp75集計で境界付近のURL群を一度にしきい値の反対側へ動かすことがあります。

適格なURLの件数だけが変動することもあります。2025年7月、適格データを表示するURL数が特にモバイルで減った際、John Muellerはこの動きを問題ではなく通常のサンプルサイズの変動と説明しました。これらのレポートはGoogleがサイトについて把握している内容のサンプルに基づき、サンプルサイズは変わるため、問題を示すものではないという説明です。Core Web VitalsプロジェクトのBarry Pollardも減少を認め、修正を展開中だと述べました。重要なのは、適格URL数と基礎となる指標品質は別だということです。サンプルが変わったからといって、ページが遅くなったとは限りません。

このレポートはランキングに影響するか

このレポートは、Googleのランキングシステムが利用し得るものと同じフィールドデータを示しますが、Googleの担当者は一貫して、Core Web Vitalsをコンテンツの関連性に並ぶ小さな、タイブレーカー程度のシグナルとして説明してきました。ランキングの重みの詳しい議論はCore Web Vitals用語集に譲り、ここでは一行に留めます。私の率直な見方では、現在これらのしきい値を満たしても順位は大きく動かないと思います。ただし、GoogleがモバイルフレンドリーやHTTPSで行ったように、将来このシグナルを強く使う可能性はあります。見落とされがちなランキング以外の理由もあります。ページが速いほど、読み込み完了前に離脱するユーザーが減り、CrUXや自社分析に記録されるデータが増えます。これらの指標を改善する主な価値は、本当に良い体験の代理指標になることです。

Bingについての短い注記

Bing Webmaster Toolsには、URLグループ化を備えたCrUX型の専用Core Web Vitalsレポートという、Googleに直接相当するものはありません。Bingは、フィールドデータのCore Web Vitals内訳ではなく、クリック数・インプレッション数のPerformance Reportと、技術監査のSite Scanを中心にレポートします。Bingの案内にはCore Web Vitals型の指標が登場しますが、Googleのようなグループ化されたフィールドデータレポートは提供していません。Bingのツールは比較的頻繁に変わるため、重要な場合は最新のBing Webmaster Tools文書で確認してください。

この記事の位置付け

このレポートはGoogle Search Consoleにある複数のレポートの1つです。Performanceレポートは検索で実際にどうだったか（クリック、インプレッション、順位）を扱い、Page Indexingレポートはカバレッジとインデックス登録を扱います。このレポートが表示するCore Web Vitals、CrUX、ラボデータの補助役であるPageSpeed Insightsの指標は、web performanceクラスターの別個の深掘り記事で説明しています。

AI要約

Advanced版の要点を短くまとめます。

• これは指標ではなくレポートです。 Core Web Vitalsレポート（GSC → Experience）は、インデックス登録済みURLのCrUXフィールドデータ（移動28日間、75パーセンタイル）を表示します。新しい計算はせず、ラボデータは含みません。
• 3つのグループ化。 端末（独立したMobile／Desktopタブ、平均しない）、ステータス（Poor／Need improvement／Good、最も悪い指標が勝つ）、URLグループ（似たテンプレートのページをまとめ、1つのステータスを共有）です。
• URLグループが原子単位です。 個別URLではありません。1つのテンプレートを直すと、Muellerが述べたように数千のフラグ付きURLが解消することがあります。Poorグループにも高速なページは含まれます。
• プライバシーの連鎖。 URLグループ → オリジングループ → **「No data available」**です。新しいサイトやトラフィックの少ないサイトでは何も表示されないことがあり、Patrickの2022年調査ではCrUXデータがあったページは約12%でした。
• PageSpeed Insightsとは一致しません。 グループと単一URLの違いに加え、GSCはURLパラメータを区別し、PSIはパラメータなしのURLへまとめます。
• 適格性ゲート。 URLグループはLCPとCLSの両方のしきい値データが揃って初めて表示されます。どちらかが不足すれば、合格扱いではなく除外です。対象はインデックス登録済みURLのサンプルで、データはcanonicalではなく実際のURLに割り当てられます。
• チャートと表の数え方は異なります。 チャートは最も悪い問題ごとにURLを1回、表はすべての問題を数えるため、合計は一致しません。
• FIDは2024年3月12日に削除されました。 INPがCore Web Vitalになった日にGSCから即時に消え、PSI／CrUXの6か月の移行期間とは異なります。
• Page Experienceレポートは2023年4月に削除されました。 残っているのはCore Web VitalsレポートとHTTPSレポートです。
• ワークフロー。 Poorを先に直し、Start Trackingで検証します。28日間の監視セッションで失敗URLが1つでも残れば合格を妨げ、再インデックスは行われません。PSIで素早く診断し、フィールドデータの反映を約1か月待ちます。サイトを変更していないのにステータスが変わるのは、境界付近のURLがしきい値を越えたか、サンプルサイズが変動したことが多いです。

公式ドキュメント

Googleの一次資料です。

Google

• Core Web Vitalsレポート — この記事の正典となるヘルプページです。データ源（CrUX）、端末／ステータス／URLグループの整理、「No data available」、オリジングループへのフォールバック、チャートと表の数え方、PageSpeed Insightsとの差、Start Trackingによる検証フローを扱います。
• 3月12日にInteraction to Next PaintがCore Web Vitalになる — Chromeチームの発表で、FIDがGSCから即時に削除されたこと（PSI／CrUXでは6か月の移行期間）を含みます。
• Core Web VitalsへのINP導入 — FIDからINPへの移行に関するGoogle Search Centralの2023年5月の発表です。
• Core Web VitalsとGoogle検索結果を理解する — 調査時点でもLCP 2,5s／INP 200ms／CLS 0,1だった、Search Centralの概要です。

出典からの引用

Googleによる記録に残る発言です。各リンクは出典ページの引用箇所へ移動します。

Google — レポートの内容とデータの出所

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” (翻訳)「Core Web Vitalsレポートは、実世界の利用データ（フィールドデータと呼ばれることもあります）に基づいてページがどう動作するかを示します。」 — Search Console Help。 Jump to quote
• “The data for the Core Web Vitals report comes from the CrUX report… The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (翻訳)「Core Web VitalsレポートのデータはCrUXレポートから取得され、CrUXデータベースはURLがSearch Consoleプロパティに含まれるかどうかにかかわらず情報を収集します。」 Jump to quote
• “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (翻訳)「このレポートに表示されるのはインデックス登録済みURLのサンプルで、すべてのURLの完全な一覧ではありません。」 Jump to quote
• “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (翻訳)「他の多くのレポートのようにcanonical URLではなく、実際のURLにデータが割り当てられます。」 Jump to quote

Google — URLグループとプライバシーによるフォールバック

• “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (翻訳)「レポート内のURLは似たユーザー体験を持つページにグループ化され、LCP、INP、CLSのステータスはグループ全体に適用されます。外れ値URLは訪問によって値が変わることがありますが、グループ内の全URLへの訪問の75%が表示されたグループステータスを経験しました。」 Jump to quote
• “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (翻訳)「ユーザーのプライバシー保護のため、URLグループを表示するには最低限のデータが必要です。不足する場合、Search Consoleは十分なURLとデータを含む上位のオリジングループを作成します。」 Jump to quote

Google — レポートの読み方と修正の検証

• “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (翻訳)「チャートはURLを、影響する最も遅い問題について1回だけ数い、表はURLに関連するすべての問題を数えます。」 Jump to quote
• “The report is not designed find the status of a specific URL, but rather to see your site’s performance as a whole, and troubleshoot issues affecting multiple pages on your site.” (翻訳)「このレポートは特定URLのステータスを見つけるためではなく、サイト全体のパフォーマンスを確認し、複数ページに影響する問題を診断するためのものです。」 Jump to quote
• “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (翻訳)「特定の問題を修正したと思ったら、Search ConsoleのCore Web Vitalsレポートの問題詳細ページでStart Trackingをクリックします。」 Jump to quote

Google — PageSpeed Insightsとの違いと「No data available」

• “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (翻訳)「Core Web VitalsはデータとステータスをURLグループにまとめ、PageSpeed Insightsは通常、個別URLのデータを表示します。」 Jump to quote
• “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (翻訳)「Core Web Vitalsはページを区別する際にURLパラメータを含めますが、PageSpeed Insightsはすべてのパラメータを削除し、結果をパラメータなしのURLに割り当てます。」 Jump to quote
• “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (翻訳)「『No data available』は、Search Consoleのプロパティが新しいか、選択した端末に十分なCrUXデータがないことを意味します。」 Jump to quote

Google — Search ConsoleでのFID → INP（Chromeチーム、web.dev）

• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (翻訳)「INPが3月12日にCore Web Vitalになると同時に、FIDはGoogle Search Consoleから削除されます。PageSpeed InsightsやCrUXなど他のツールには、コードを更新するための6か月の非推奨期間があります。」 Jump to quote

John Mueller（Google）— URLをグループ化する理由（2021年）

• “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (翻訳)「Chrome User Experience Reportの実世界フィールドデータを使い、十分に似たページを認識してグループ化しようとしています。」
• “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (翻訳)「サイトには本質的に1つのグループがあり得ますが、そこに数千のURLが含まれることがあります。その場合、Search Consoleでは数千URLに問題があると表示するでしょう。」 記事の全文を読む

Search Engine Journalのページには文字起こしとGoogle Office Hours動画が埋め込まれています。Muellerの回答は約10:34から始まります。

どのツール（または手順）を選ぶべきか

「特定の1ページのCore Web Vitalsを確認したい」 → このレポートではありません。 そのURLのフィールドデータとラボデータを確認できるPageSpeed Insights、またはURL検査ツールを使います。Core Web Vitalsレポートは「特定URLのステータスを見つけるために設計されたものではありません」。

「レポートに『No data available』と表示される」 → プロパティが新しいか確認します。新しい場合は、CrUXがデータを蓄積するまで数日待ちます。 → それ以外は、オリジングループでさえプライバシーしきい値を満たせないほどトラフィックが不足している可能性が高いです。個別URLをPageSpeed Insights／Lighthouseでテストしてください。「データなし」は健全性の証明ではありません。

「グループがPoorになっている。最初に何を直すべきか」 → 「Need improvement」より先に、Poorと表示された問題をすべて直します。 → グループ内ではURLがインプレッションの多い順に並ぶため、上位のURLほどグループのステータスに影響します。 → ステータスはグループの最も悪い指標で決まります。LCP／INP／CLSのどれが失敗しているかを確認し、その指標を直します。

「同じURLでGSCのステータスとPageSpeed Insightsが一致しない」 → 想定される動作です。GSCはグループを報告し、PSIは個別URL（グループの外れ値かもしれません）を報告します。GSCはURLパラメータを区別し、PSIはパラメータなしのURLにまとめます。どちらが間違いなのではなく、異なる単位を測っています。

「修正を公開した。効いたことをどう確認するか」 → まずPageSpeed Insightsのラボ結果で、すぐに得られるフィードバックを確認します。 → GSCの問題でStart Trackingをクリックし、フィールドで検証します。 → その後は待ちます。移動28日間のウィンドウなので、変更がレポートに完全に反映されるまで約1か月かかります。

「サイトに触っていないのにステータスが変わった」 → トラフィック構成、CDN／画像遅延、ブラウザー更新など外部変化で、境界付近のURLがしきい値を越えた可能性があります。単なるサンプルサイズの変動の場合もあります。動いたのが適格URL数なのか、基礎となる指標品質なのかを確認してください。両者は別です。

Core Web Vitalsレポートを読む — 正常性チェックリスト

結論を出したり、開発者に作業リストを渡したりする前に、次を確認します。

• モバイルとデスクトップの両方のタブを確認した。両者は独立しており、食い違うことがある。
• 個別URLではなくURLグループを単位として扱っている。1つの修正でグループ全体が改善する可能性がある。
• Poorグループにも高速なページが含まれることを理解している。グループのステータスはクラスター全体のp75で決まる。
• チャートと表の合計は一致しないことを知っている。チャートは最も悪い問題ごとにURLを1回、表はすべての問題を数える。
• PoorをNeed improvementより先に直し、インプレッションの多いURLを優先している。
• コードに触れる前に、各グループのステータスを決めている指標（LCP／INP／CLS）を特定した。
• 単一URLの確認では、このレポートではなくPageSpeed Insights／URL検査へ切り替えた。
• GSCがPageSpeed Insightsと一致するとは期待していない。グループ対URL、パラメータ保持対削除の違いがある。
• 「No data available」が出たら、ページが良いと決めつけず、トラフィックと適格性を確認した。
• 修正後にStart Trackingをクリックし、フィールドデータの反映に約1か月を見込んでいる。
• 境界しきい値やサンプルサイズの変動によるステータス変更を過剰に追っていない。

Core Web Vitalsレポートのメンタルモデル

1. レポートであり、メーターではない。 すべての数値は、実際のChromeユーザーによるCrUXフィールドデータです。移動28日間の75パーセンタイルであり、レポートはそのデータを表示するだけで、新しい計算をせず、ラボ層もありません。したがって常に直近の過去を表し、「今この瞬間」を表すものではありません。

2. URLグループが原子単位である。 単一URLで考えるのをやめます。Googleは似たテンプレートのページをまとめ、クラスター全体に1つのステータスを付けます。1つのテンプレートの欠陥から数千URLにフラグが立つことがあります。テンプレートを1度直せばグループを直せます。高速なURLがPoorグループに含まれることもあります。

3. 最も悪い指標が勝つ。 グループのステータスはLCP／INP／CLSのうち最も弱いものが決めます。最適化を始める前に、どの指標が失敗しているかを確認してください。「グループ」を直すのではなく、ステータスを下げている指標を直します。

4. プライバシーの連鎖が空白を説明する。 URLグループ → オリジングループ → 「No data available」です。プライバシー保護のために報告できるトラフィックが不足すると、粗いグループ化になるか、何も表示されません。「データなし」はCrUXデータ不足を意味し、サイトが健全だという意味ではありません。

5. 2つのツール、2つの役割 — 速く診断し、遅く確認する。 PageSpeed Insightsは単一URLのフィールド＋ラボを扱い、すぐにフィードバックを返します。GSCレポートはグループ化されたフィールドデータだけで、反映に約1か月かかります。PSIのラボで修正を診断・検証し、GSCのフィールドデータが実世界で確認するまで待ちます。

Core Web Vitalsレポート — チートシート

整理方法

GSCレポートとPageSpeed Insights

早わかり

• データ源はCrUXフィールドデータ。移動28日間、端末ごとのp75。
• インデックス登録済みURLだけが対象で、すべてではなくサンプル。canonicalではなく実際のURLに割り当てられる。
• 「No data available」は、新しいプロパティまたはCrUXトラフィック不足（URLグループ → オリジングループ → 何もなし）。
• チャートは最も悪い問題ごとにURLを1回、表はすべての問題を数えるため、合計は一致しない。
• FIDは2024年3月12日にGSCから削除（即時。PSI／CrUXではさらに6か月表示）。
• Page Experienceレポートは2023年4月19日に削除。残るのはCore Web VitalsとHTTPSのレポート。
• Poorを先に修正し、Start Trackingで検証する。レポートの反映には約28日を見込む。
• Googleのページサイズの目安は、ページと全リソースを合わせて500KB未満。

Core Web Vitalsレポートでよくある誤り

PoorグループのすべてのURLを個別に遅いと扱う。 ステータスはクラスター全体の75パーセンタイルで決まるため、個別メンバーは速いことも遅いこともあります。代表的なURLを診断し、共有テンプレートまたはコンポーネントを修正します。

モバイルだけ、またはデスクトップだけを確認する。 データセットは別々で、食い違うことがあります。平均して1つの話にせず、両タブを独立してトリアージします。

「No data available」を合格と呼ぶ。 通常はURLまたはオリジンに、報告に必要な適格CrUXトラフィックがないことを意味します。ラボテストや他のフィールドデータ源を使い、ページがGoodだとは主張しません。

1つのURLについてGSCがPageSpeed Insightsと一致すると期待する。 GSCはグループを報告し、URLパラメータを保持します。PSIは通常、パラメータなしの単一URLを報告します。差をバグと扱う前に、単位とURLの扱いを理解します。

すでにGoodの指標を最適化する。 グループの最も弱い指標がステータスを決めます。開発者に作業を渡す前に、LCP、INP、CLSのどれが原因かを特定します。

ラボだけの修正直後にStart Trackingを開始する。 まず影響を受けるすべてのテンプレートに変更がデプロイされていることを確認します。その後にフィールド検証を1回開始し、移動CrUXウィンドウが実ユーザーの証拠を集める時間を確保します。

チャートと表の合計を照合チェックに使う。 チャートは最も悪い問題ごとにURLを1回、表はURLに付いたすべての問題を数えます。異なる合計は想定どおりです。

Core Web Vitalsの修正を検証する

3層の証拠を使います。どれか1つだけでは十分ではありません。

1. デプロイの証拠

• 代表的な影響URLで、遅いインタラクション、不安定な要素、または遅れて読み込まれる最大要素を再現する。
• 変更したコードがプレビューだけでなく本番に存在し、URLグループに含まれるすべてのテンプレートに適用されていることを確認する。
• 同じテスト条件で、変更前後にLighthouseまたは別のラボトレースを実行する。対象指標は改善し、別のCore Web Vitalは悪化していないこと。

2. レポートワークフローの証拠

• 正確な問題行を開き、端末、ステータス、指標、URLグループ、例URLを記録する。
• 個別URLはGSCグループと異なることがあるため、例URLをPageSpeed Insightsでスポットチェックする。
• 本番展開が完了してからStart Trackingをクリックする。何度も再起動せず、問題の検証ステータスを観察する。

3. フィールド結果の証拠

• 移動28日間のCrUXウィンドウが、リリース後の訪問を取り込むまで待つ。
• もともと失敗したのと同じ端末・指標で、対象グループが改善したことを確認する。
• モバイルとデスクトップの両方を確認し、本当の指標改善と、適格になるURLが変わっただけの変化を区別する。
• GSCが変わらない場合は、デプロイが失敗したと判断する前に、グループの例URLをURLレベル／オリジンレベルのPSIデータと比較する。

合格条件は「Lighthouseが一度緑になったこと」ではありません。本番の修正がグループ全体に存在し、管理されたラボの証拠が改善し、十分な実ユーザーデータが届いた後に該当するGSCフィールド問題が解消することです。

パフォーマンススコアを捏造せず進捗を測る

次の値を、端末、指標、URLグループ、リリース日ごとに分けて追跡します。

Googleが公開しているGoodのしきい値、つまり75パーセンタイルで測定したLCP ≤2,5秒、INP ≤200 ms、CLS ≤0,1を品質基準にします。全体共通の期限や改善率目標を作ってはいけません。有用な傾向は、失敗グループの適格URLが減ること、問題の検証が完了すること、指標同士で犠牲を出さず連続する28日間のウィンドウで改善が安定することです。

時間をかける価値のある資料

関連する私の執筆

• Core Web Vitals（CWV）とは何か、改善方法 — 指標そのものと、GSCレポートがテンプレート別に影響ページをグループ化する方法を説明するガイドです。
• SEO担当者・開発者向けGoogle PageSpeed Insights — ラボデータの補助記事で、“diagnose in PSI, monitor in GSC” (翻訳)「PSIで診断し、GSCで監視する」ワークフローと28日遅延の説明があります。
• Core Web Vitalsデータ調査：520万ページ — CrUXデータを持つページがどれほど少ないか（約12%）を大規模に調べた記事で、「No data available」が多い理由を説明します。

講演・インタビュー

• 中小企業向けGoogleのCore Web Vitals：Patrick Stoxとの対話 （Outside Communications）— レポートの用途を技術者以外にも説明する短い記事です。「一度直せば、その問題をすべてのページで直せる」という考え方を扱います。

公式資料

• Core Web Vitalsレポート — Search Consoleヘルプ — この記事全体の正典となる参考資料です。
• INPが3月12日にCore Web Vitalになる — web.dev — GSCからFIDが即時削除されたことを説明します。

業界資料

• GoogleがCore Web Vitalsスコア用にURLをグループ化する理由 （Search Engine Journal）— 1つのグループが数千URLにフラグを付ける理由を説明するJohn MuellerのOffice Hours文字起こしです。
• Google Search ConsoleのCore Web Vitalsレポートの使い方 （DebugBear）— 設定から修正までの実務手順と、高速なページが遅いグループに入る理由を説明します。
• Google Search ConsoleのCore Web Vitals：修正と最適化 （Quattr）— 並べ替え→優先順位付け→テスト→解決→検証のワークフローです。
• Google Search ConsoleのPage Experienceレポート廃止 （Search Engine Land）— 2023年4月のPage Experience統合レポート削除を扱います。
• Google Search ConsoleのCore Web Vitalsレポートを更新 （Search Engine Land）— 2023年3月にオリジングループへのフォールバック層が追加されたことを扱います。
• Google Core Web Vitals Search Console更新 （Search Engine Roundtable）— MuellerとPollardによる、2025年7月の適格URL減少とサンプルサイズ変動の説明です。

引用する価値のある統計

• 2022年1月のサンプルでは、Site Auditの一意な43,66Mページのうち約12%だけがCrUX指標を持っていました。 私の調査 では、“We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (翻訳)「Core Web Vitals指標が1つ以上あったのはわずか5,21M（約11,9%）で、その93%（合計約4,85M）が3指標すべてを持っていました」と報告しています。これはレポートが参照する基礎CrUXデータセットであり、「No data available」が多い理由の規模感を示します。
• FIDは2024年3月12日にGSCから削除されました。 猶予はなく、PSIとCrUXには6か月の非推奨期間がありました。出典
• ページサイズの目安は500KB未満です。 ページと全リソースについて、レポートの「Fix issues」セクションにあるGoogleの案内です。出典
• Page Experienceレポートは2023年4月19日に削除されました。 残っているのはCore Web VitalsとHTTPSのレポートです。報道

Core Web Vitalsレポートをテストする

Search ConsoleのCore Web Vitalsレポートの仕組みについて、5つの簡単な質問です。各問に答えてから確認してください。

変更履歴