Core Web Vitalsスコアは存在しません（そして、それが重要な理由）

「Core Web Vitalsのスコアが下がっています。助けてもらえますか？」

私はこの質問を1日に数回受けます。最初に確認すべきことは「そのCore Web Vitalsスコアとは何のことですか？」です。私に連絡してくる人は、ページ速度に問題があり、自分では解決できないと気づいたばかりです。通常、これはlab data（Lighthouse）かfield data（CrUXとRUM）のいずれかが不合格であることを意味します。

最終確認: 2026年3月 Arjen Karel

したがって、Core Web Vitalsが不合格だと言われた場合、最初に把握すべきは、lab dataとfield dataのどちらの話をしているかです。lab data（Lighthouse）の話をしているという明確なサインは、この「Core Web Vitalsスコア」という言葉を使っていることです。

あぁ、Lighthouseのスコアですね

この魔法の「Core Web Vitalsスコア」について掘り下げて聞くと、連絡してきた人の多くは不合格のLighthouseスコアを見せてきます。ここからが厄介です。不合格のLighthouseスコアは、Core Web Vitalsが不合格であることを意味するわけではありません。「緑色」のLighthouseスコアがCore Web Vitalsの合格を意味しないのと同じです。単に、その特定のテストに不合格、または合格していることを意味するだけです。

数字がこれを証明しています。HTTP Archiveの調査によると、Lighthouseで90以上のスコアを出したページの43%が、field dataでは少なくとも1つのCore Web Vitalsで不合格になっています。99というほぼ完璧なLighthouseスコアであっても、約4ページに1ページが不合格でした。2024年3月にFIDがINPに置き換わり、LighthouseはINPを全く測定できないため、現在このギャップはさらに広がっているはずです。

field dataについて伝える

次に私がすることは、field dataについて伝えることです。この場合はCrUXデータです。CrUXはChrome User Experience Reportの略です。CrUXは、実際のChromeユーザーがウェブ上の人気サイトをどのように体験しているかを反映したデータセットです。

CrUXはWeb Vitalsプログラムの公式データセットです。つまり、3つの指標（LCP、INP、CLS）でCore Web Vitalsに合格（または不合格）するためには、訪問者の少なくとも75%が良い体験を得る必要があります。Googleはこれを75パーセンタイルで測定します。つまり、最悪の25%の訪問がスコアを決定します。トラフィックのピーク時にサーバーの応答が一度遅れただけで、オリジン全体の足を引っ張る可能性があります。

Google Search AdvocateのJohn Mueller氏はこの点について明確に述べています。「ChromeのLighthouseツールもスコアを生成します。Googleは検索にこれらのスコアを使用しません。」Googleが使用しているのはCrUXのfield dataです。Core Web Vitalsがランキングに与える影響の詳しい解説については、Core Web VitalsとSEOをご覧ください。

これで、Core Web Vitalsの合否を決める単一の「Core Web Vitalsスコア」など存在しないことがお分かりいただけたでしょう。

field dataを見せる

クライアントがfield dataについて知ったところで、実際にそれを見せます。先ほどお見せした「不合格」のLighthouseスコアを覚えていますか？ これが対応するCrUXデータです。ご覧の通り合格しており、このクライアントについてはCore Web Vitalsを心配する必要は全くありません。

手順は簡単です。ブラウザでpagespeed.web.devにアクセスし、URLを入力します。次に「Origin」（「This URL」のすぐ横にあります）を選択して、トップページだけでなくサイト全体のCore Web Vitalsを表示します。また、CrUX History reportを使用して、指標の経時的な変化を追跡することもできます。なお、CrUXデータは28日ごとに更新されるわけではありません。

では、Lighthouseはどうなのでしょうか？

この時点で、説得力のある説明を行い、今述べたことを証明したとしても、99%のクライアントはLighthouseスコアを手放す気にはなりません。気持ちはわかります。スコアには魅力があります。誰にでも解釈できる緑、オレンジ、赤の数字が全く重要ではないとは、想像しにくいものです。

忘れないでほしいのは、Lighthouseはテストであるということです。非常に優れたテストです。私はその機能の多くを高く評価しており、コードの書かれ方も、Core Web Vitalsの問題修正に役立つ点も気に入っています。しかし、Lighthouseにはできないことが4つあります。

1. ページを操作する。これだけでテストとしては実質的に使えません。訪問者はページを操作します。コンバージョンはその操作から生まれるのです。

2. リピーターとして振る舞う。Lighthouseは（デフォルト設定では。この設定は変更可能です）、初めて訪れたかのようにページを訪問します。ページのレンダリングやタイミングにおいて、これは往々にして決定的な違いを生みます。つまり、Lighthouseは訪問者の大部分を代表していません。

3. ページについて理解する。最も良い例はTotal Blocking Timeの監査です。ほとんどの専門家でさえ、Total Blocking Timeが大きいのは悪いことだと同意しますが、それが全てではありません。ページが応答性を必要とするタイミングで「ブロッキング」が発生せず（これを強制することは可能です！）、初期のレンダリング中にもブロッキングが発生しない限り、Lighthouseスコアが悪くてもおそらく全く問題ありません！

4. Interaction to Next Paint を測定する。INPは3つのCore Web Vitalsの1つですが、実際のユーザーの操作を必要とするため、Lighthouseはこれに0%の重みを割り当てています。LighthouseはTotal Blocking Timeを代替として使用し、これに最高である30%の重みを与えていますが、TBTとINPは逆の動きをする可能性があります。2025年には、lab dataのTBTは58%増加しましたが、field dataのINPは実際に改善しました。これだけでも、単一のLighthouseの数字をどれだけ信用すべきかがわかるはずです。

2025 Web Almanacによると、3つのCore Web Vitalsすべてに合格しているモバイルのオリジンはわずか48%です。デスクトップではその数字は56%になります。クライアントが合格しているなら、ウェブの半分以上をリードしていることになります。その状態を維持するために、Real User Monitoringを設定して、クライアントが気づく前にリグレッションを検知できるようにしましょう。CoreDashで追跡されているサイトを見ると、アクティブな監視を行っているオリジンは、CWVのリグレッションを平均して48時間以内に検知していますが、定期的なLighthouseのチェックに頼っているサイトでは数週間かかっています。

Core Web Vitalsに合格するためのステップバイステップの計画が必要な場合は、Core Web Vitalsの合格方法をご覧ください。