【Google検索セントラル解説】Core Web Vitalsとは｜LCP・INP・CLSの基準値と、日本語版の更新遅れ・測り方を整理

2026年11月5日

「Core Web Vitals」という言葉は、制作会社の提案書や、Search Consoleの警告メールで目にする機会が増えました。では、Googleは自分のドキュメントの中で、この指標をどう説明しているのでしょうか。

この記事は、Google検索セントラルの「Core Web Vitals と Google 検索の検索結果について」を、英語版の原文から読みます。3つの指標の中身、良し悪しの基準、測り方のどこまでが公式の説明で、どこからが周辺資料の話かを分けて整理します。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。このページは、その「測る道具」の入口にあたるため、先に中身を押さえておきます。

結論：3行で言うと

Core Web Vitalsは、読み込み（LCP）、反応の速さ（INP）、表示のずれ（CLS）の3つで、実際の利用者の体験を測る指標です
目安はLCPが2.5秒以内、INPが200ミリ秒未満、CLSが0.1未満です。公式ページは「目指す」という書き方で、合格ラインを断定してはいません
最初に見る場所はSearch Consoleの「ウェブに関する主な指標」レポートです。実際の利用者のデータで、サイトのどこが遅いかを見られます

日本語版には、冒頭に英語版より強く読める言い回しが2か所あります。出典として引くときは、英語版が安全です。

このページの基本情報

項目	内容
原題（英語）	Understanding Core Web Vitals and Google search results
日本語版の題名	Core Web Vitals と Google 検索の検索結果について
英語版の最終更新日	2025年12月10日
日本語版の最終更新日	2025年12月18日
Google検索セントラルの中の位置（章）	左の目次の「Ranking and search appearance」の中にある「Page experience」の組です。ページエクスペリエンスの解説ページと、インタースティシャルのページが並びます
直近の主な更新	変更履歴の2024年3月12日の項目に、INPがCore Web Vitalsになったことを反映した、とあります（ただし項目が名指ししているのは別の3ページで、このページの名はありません）。それ以降、このページに触れた項目は見当たりませんでした

原文はこちらで読めます。英語版／日本語版。

このページ自体は短く、本文は3つの指標と、測り方の案内先だけです。順位との関係や、広告・HTTPSなど「ページエクスペリエンス」全体の話は、ページエクスペリエンスの解説記事で扱っています。

この記事は、指標の中身と測り方に絞ります。

Googleがこのページで言っていること

導入：実際の利用者の体験を測る指標

冒頭は、Core Web Vitalsの定義です。ページの読み込み、操作への反応、見た目の安定という3つについて、実際の利用者の体験を測る一連の指標だと説明しています。

続けて、Googleは次のように勧めています。

“We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.”（検索での成功と、全般的に良い利用者体験のために、サイト所有者がCore Web Vitalsを良好にすることを強くおすすめします）

そして、これはほかのページエクスペリエンスの要素とともに、コアランキングシステムが報いようとするものに沿っている、と書かれています。この「沿っている」の読み方は、日本語版との差の節で触れます。

3つの指標と、目安の数値

指標	測るもの	公式ページの目安
LCP（Largest Contentful Paint）	読み込みの速さ。ページの中でいちばん大きな要素が表示されるまで	読み込み開始から2.5秒以内
INP（Interaction To Next Paint）	反応の速さ。クリックやタップなどの操作から、画面が更新されるまで	200ミリ秒未満
CLS（Cumulative Layout Shift）	見た目の安定。表示中に画面がどれだけずれるか	0.1未満

3つとも、原文は「strive」、つまり「そうなるよう努める」という動詞で目安を書いています。合格と不合格を分ける線ではなく、目指す水準の示し方です。

指標の定義は、各指標の名前に付いたGoogleのウェブ開発者向けサイト（web.dev）のリンク先で読む作りです。

最適化のための3つの案内先

後半の「Optimizing your Core Web Vitals」は、測定・監視・改善に使える資料を3つ挙げています。

Search ConsoleのCore Web Vitalsレポート：自分のページの成績を見る
web.devのCore Web Vitalsの学習ガイド：測定、原因の調査、改善、ベストプラクティスを扱う
web.devの計測ツールの一覧：LCP、INP、CLSを測れるツールを紹介する

ページの末尾には、Googleのブログで発表したCore Web Vitals関連の記事の一覧があります。

リンク先を開いて確かめたこと

公式ページは案内先を挙げるだけなので、私が実際に開いた資料から、判断に使える範囲を補います。ここからは、このページ本体ではなく、リンク先の内容です。

基準値は「75パーセンタイル」で見る

web.devのLCP、INP、CLSの各ページには、目標を満たしているかを見る位置が書かれています。モバイルとパソコンに分けて、ページ読み込みの75パーセンタイルで見る、という考え方です。

速い順に並べて、4分の3の位置にある訪問の値で判定する、という意味です。ごく一部の遅い訪問があっても、判定は変わりにくくなります。

「良好」「改善が必要」「低速」の境目

Search Consoleのヘルプには、3段階の境目が載っています（日本語版のヘルプの呼び名は「良好」「改善が必要」「低速」）。公式ページの目安は、このうち「良好」の線にあたります。

LCP：2.5秒以内が良好、4秒以内が改善が必要、4秒超が低速
INP：200ミリ秒以内が良好、500ミリ秒以内が改善が必要、500ミリ秒超が低速
CLS：0.1以内が良好、0.25以内が改善が必要、0.25超が低速

INPの200は、公式ページが「未満」、ヘルプとweb.devが「以内」と書いています。資料ごとの表記の揺れで、実務の判断は変わりません。

Search Consoleのレポートの読み方

Search Consoleのヘルプによると、このレポートは実際の利用者のデータ（フィールドデータ）で作られています。データの元は、Chromeの利用者から集めた公開データセットのCrUX（Chrome User Experience Report）です。

URLは、似た体験のページどうしで「URLグループ」にまとめて評価されます
グループの状態は、3つの指標のうち最も悪いもので決まります
表示される値は、過去28日間の75%の訪問が満たした値です
レポートに出るのは、インデックスされたURLだけです
データが少ないと「データがありません」と表示されます。新しいプロパティか、CrUXのデータ不足のどちらかです

ヘルプには、このレポートは特定の1URLの状態を調べる道具ではなく、サイト全体の傾向と、複数ページに共通する問題を見つける道具だ、とも書かれています。

実測データと実験室のデータは別物

web.devの計測ツールの解説は、Core Web Vitalsは現場（実際の利用者）で測るのが基本だと述べています。Lighthouseのような実験室のツールは、問題の診断用です。

実験室のツールは、決まった条件で、初めて訪れた人の読み込みを再現します。実際の訪問者の端末や回線、キャッシュの状態とは違いが出ます。

もうひとつ重要な点があります。Lighthouseは操作する利用者がいない環境のため、INPの代わりにTBT（Total Blocking Time）という指標を使います。

web.devの表では、LighthouseのINPの欄は「TBTを使う」になっています。

英語版と日本語版の違い

確認した日付は2026年11月5日です。英語版の更新日は2025年12月10日、日本語版は同年12月18日です。

日本語版のほうが8日新しく、英語版だけにある文や、事実と数値の食い違いは、すべて見当たりませんでした。

ただし、冒頭の2文で、訳し方に差があります。

箇所	英語版	日本語版
勧める理由	for success with Search（検索での成功のために）	検索結果でのランキングを上げ（略）改善することを強くおすすめします
ランキングとの関係	aligns with what our core ranking systems seek to reward（コアランキングシステムが報いようとするものに沿っている）	コアランキングシステムがランキングを決定する際に考慮する要素です

英語版が書くのは「検索での成功」で、順位を上げるとまでは言っていません。「報いようとするものに沿う」も、仕組みの方向性の説明です。

日本語版は、「ランキングを上げ」「考慮する要素」と訳しています。英語版より、順位に直結するという印象が強くなります。

どちらの版でも、3つの指標の名前と基準値は同じです。違うのは、順位との関係を述べた冒頭の言い回しだけです。

順位との関係そのものは、ページエクスペリエンスの解説記事で、そのページの原文に当たって整理しています。

更新の経緯：日本語版のINP反映は遅れました

Internet Archiveの保存記録と、変更履歴を突き合わせると、次の流れでした。

2023年4月19日：変更履歴に、ページエクスペリエンスの解説を改訂し、一部を新しいCore Web Vitalsのページへ移した、とあります。このページの始まりです
2023年5月10日：変更履歴に、INPが2024年3月にFIDに代わる予告のバナーを、Core Web Vitalsのページ群に付けた、とあります
2024年3月12日：変更履歴に、INPがCore Web Vitalsになったことを反映した、とあります。ただし、この項目が名指ししているのはページエクスペリエンス、署名付きExchange、ECのページ送りの3ページで、このページの名はありません。FIDからINPへの切り替え自体は、項目の「理由」欄にあるweb.devの記事が説明しています

英語版の保存記録では、2024年3月4日はFID（100ミリ秒未満）、同年4月2日はINP（200ミリ秒未満）の表でした。

切り替わりは、この2つの記録の間です。変更履歴の3月12日と矛盾しませんが、このページ自身の切替日までは絞れません。

日本語版は違いました。保存記録では、2025年2月6日まで指標の表がFIDのままで、「2024年3月以降にINPがFIDに代わる」と予告する文が残っていました。

INPの表になっていたのは、2025年3月7日の記録からです。

保存記録は不定期のため、日本語版が切り替わった日は、2025年2月7日〜3月7日のどこかとしか絞れません。それでも、英語版が遅くとも2024年4月2日にINPの表で、日本語版は早くとも2025年2月7日までFIDの表だったので、少なくとも約10か月、最大で約12か月の遅れがあったことは、記録から確かめられます。

日本語版の2024年3月14日、4月2日、12月17日の記録も、FIDのままでした。

日本語の資料に「FID」の記述が残りやすいのは、この遅れも一因かもしれません。これは私の推測です。

このページから、言えること・言えないこと

言えること	言えないこと
Core Web Vitalsは、LCP、INP、CLSの3つで、実際の利用者の体験を測る指標である	FIDは、現在もCore Web Vitalsの1つである。（2024年3月にINPへ置き換わりました）
Googleは、良好な状態にすることを、検索での成功と利用者体験のために強くおすすめしている	良好にすれば、順位が上がると約束している。（公式ページに、順位の保証はありません）
目安は、LCPが2.5秒以内、INPが200ミリ秒未満、CLSが0.1未満である	目安を1つでも超えると、検索結果から外れる。（そうした記述はありません）
Search Consoleのレポートで、サイトの傾向を見られる	レポートの数字が、検索順位を決める値そのものである。（公式ページは、順位との関係をそこまで書いていません）

中小企業の視点で、どう受け取るか

ここからは、Googleの説明とは別の、私の読み取りです。

1. まず、自社に「実際の利用者のデータ」があるかを確かめる

Search Consoleの左メニューで、「ウェブに関する主な指標」のレポートを開きます（ヘルプの日本語版では「Core Web Vitals レポート」とも書かれています）。メニューの階層は画面の更新で変わることがあるため、名前で探してください。

モバイルとパソコンのグラフが出れば、CrUXのデータがあります。

訪問が少ない小さなサイトでは、「データがありません」と表示されることがあります。これは不具合ではなく、公式ヘルプに書かれた仕様です。

その場合は、次の項目の道具で補います。

2. 「低速」「改善が必要」が出たら、URLグループの代表ページを開く

レポートにある、良好と見なされなかった理由の表から、問題の行を開きます。出てくるURLは、似たページのグループの代表です。

WordPressなら、同じテーマ、同じテンプレートの投稿が1つのグループになりやすいと考えられます。1ページを直すより、テンプレートや共通の部品を直すほうが、グループ全体に効きます。

3. 実験室の測定は「診断用」と割り切る

PageSpeed Insightsを使うと、Search Consoleのヘルプによれば、実際の利用者のデータと、その場で測った実験室のデータの両方が表示されます。

判断の軸は実際の利用者のデータに置き、実験室のデータは原因の候補を探すために使います。1回の実験室の数字に一喜一憂しないことが、web.devの説明に沿った使い方です。

4. 古い資料のFIDは、読み替える

制作会社の資料に「FIDを100ミリ秒未満に」とあれば、2024年3月以前の内容です。いまは、反応の速さをINPで見ます。

速度の改善がAI検索に関係するかは、別の記事で整理しています。実務の手順は、表示速度はAI検索に関係ある？Googleの公式説明と応答速度の測り方をご覧ください。この記事は公式ページの解説、あちらは測り方の手順という役割分担です。

弊社のサイトで確かめたこと

2026年11月5日に、kenkyo.aiのトップページに対して、次の確認を行いました。これはCore Web Vitalsの値とは別の確認です。

利用者のデータ（フィールドデータ）は、私の側から見られる範囲の外にあります。

確認	方法	結果
PageSpeed InsightsのAPIで、モバイルの測定を依頼	PageSpeed InsightsのAPIを呼ぶコマンド（curl）	1日あたりの利用上限を超えた、という応答（HTTP 429）で、測定できませんでした
トップページの取得	curl -sL https://kenkyo.ai/	HTTP 200、転送0回。最初の1バイトまで0.07秒、取得完了まで0.12秒（1回目の計測）。同じ日に測り直すと、最初の1バイトまでが約0.1〜0.65秒と、測るたびに変わりました
HTMLの大きさと圧縮	同上と、Accept-Encodingを付けた取得	非圧縮で約33万バイト。gzipで約8.8万バイト。Brotliでの圧縮も返しました
HTMLの画像（img）タグ64個の確認	取得したHTMLを集計	幅と高さの指定は64個すべてにありました。遅延読み込み（loading=”lazy”）の指定は62個です