Core Web Vitals の監視を自動化する｜LCP・INP・CLSを28日の遅れも含めて見る4層の仕組み（2026年）

表示速度の改善は、一度やると「終わった仕事」になりがちです。ところが数か月後に数字を見ると、元に戻っていることが少なくありません。新しいバナー、計測タグ、キャンペーン用の画像、Cookie バナーの設定変更が、少しずつ積み重なるからです。誰も速度を落とそうとしたわけではないので、いつ悪くなったのかも分かりません。

この記事では、Core Web Vitals（Google が示す表示体験の3指標）を継続して監視する仕組みを整理します。改善の方法そのものよりも、「悪くなったことに、何日で、誰が気づくか」を設計の中心に置きます。検索とアクセスの数字の監視は「Search Console と GA4 の定点観測を自動化する」、サーバーの死活監視や更新は「ホームページ保守の自動化」で扱いました。ここでは表示速度だけに絞ります。

この記事が主に根拠にした情報：web.dev の Core Web Vitals の各指標の解説、Chrome for Developers の CrUX（Chrome UX Report）の方法論と API のドキュメント、Google 検索セントラルと Search Console ヘルプ、Lighthouse と Lighthouse CI の公式ドキュメント、HTTP Archive の Web Almanac 2025。いずれも2026年10月27日に確認しました。

1. いま何が起きているか：指標と道具が入れ替わった2年

Core Web Vitals は、指標も道具も2024年から2026年にかけて入れ替わりました。数年前に組んだ監視がそのまま動いている場合、もう存在しない指標や、終わった道具を見ている可能性があります。

INP が FID に代わり、FID は道具から消えた

操作への反応を測る指標は、2024年3月12日に FID（最初の入力の遅延）から INP（Interaction to Next Paint）に代わりました。FID は最初の1回の操作の待ち時間しか見ていませんでした。INP はページを開いている間のすべての操作を見て、ほぼ最も遅いものを値にします。Search Console は切り替えの日に FID の表示をやめ、PageSpeed Insights と CrUX は6か月の移行期間のあとに FID を外しました。

CrUX Dashboard が終わり、CrUX Vis に移った

Looker Studio で CrUX の月次データを見られた CrUX Dashboard は、2025年11月末で提供を終えると告知され、後継は CrUX Vis になりました。報告書に組み込んでいた場合は、空のグラフが残っていないか確かめてください。

PageSpeed Insights API から、利用者のデータが外れる予定

PageSpeed Insights API（PSI API）の入門ページには、結果に利用者のデータ（フィールドデータ）を含めるのをやめる予定だと書かれ、CrUX API と CrUX History API を使うよう勧めています。利用者のデータは CrUX API から取る形に、先に移しておくのが安全です。

世の中のサイトの合格率は、モバイルで約半分

HTTP Archive の Web Almanac 2025（2025年7月の CrUX データ）では、3指標すべてが良好だったサイトはモバイルで48%、パソコンで56%でした。2023年のモバイルは36%、2024年は44%で、少しずつ上がっています。指標別に見ると、モバイルで最も落ちやすいのは LCP（良好62%）です。

INP はパソコンでは97%が良好で、問題になるのはほぼモバイルです。監視の初期設定は、モバイルを主にするのが合理的です。

2. 3つの指標の定義としきい値

監視を組む前に、何を測っているのかをそろえます。3つとも「速さ」と呼ばれますが、測っているものは別です。

3つとも利用者の75パーセンタイル（遅いほうから4分の1の利用者の体験）で判定し、スマホとパソコンは別々に見ます。

LCP：4つの区間に分けて見る

LCP（Largest Contentful Paint）は、画面に入っている最も大きな画像か文字の塊が描かれるまでの時間です。web.dev は LCP を4つの区間に分け、サーバーの最初の応答（TTFB）がおよそ40%、画像の読み込み開始までの遅れが10%未満、画像の読み込みがおよそ40%、描画の遅れが10%未満を目安にしています。どの区間が伸びたかで、サーバーの問題か画像の問題かを切り分けられます。

INP：最も遅い操作を、外れ値を除いて取る

INP は、クリック・タップ・キー入力から、画面に次の変化が描かれるまでの時間です。スクロールやホバーは数えません。50回ごとに最も遅い1回を外れ値として除き、残りの最も遅いものを値にするので、操作の少ないページでは実質は最も遅い1回です。実際の操作がないと測れないため、Lighthouse では TBT（メインスレッドが塞がれた合計時間）を目安にします。

CLS：ずれの「かたまり」の最大値

CLS（Cumulative Layout Shift）は、要素が予期せず動いた量です。ずれの間隔が1秒未満で、全体が5秒以内のものを1つのかたまりとし、最大のかたまりの値を取ります。操作から500ミリ秒以内のずれは数えません。ラボは読み込み中しか見ないので、スクロールした先のずれは利用者のデータにしか出ません。

3. フィールドデータとラボデータの違い

表示速度の数字には、実際の利用者から集めたフィールドデータと、決まった条件で機械が測ったラボデータの2種類があります。監視で最も多い混乱は、この2つを同じものとして比べることです。

どちらか一方では監視は成り立ちません。フィールドデータは正しいが遅く、ラボデータは速いが利用者と一致しません。

数字が食い違う主な理由

web.dev によると、ラボはキャッシュのない初回訪問を測りますが、実際の利用者には再訪問者が多く、キャッシュや bfcache（戻る・進むのキャッシュ）で速く表示されます。逆に、ログイン後の画面や A/B テストでは、LCP の対象の要素そのものが変わることがあります。

スコアは合否ではない

Lighthouse の性能スコア（0〜100）は、Lighthouse 10 以降、TBT 30%、LCP 25%、CLS 25%、FCP 10%、Speed Index 10% の重みで合成した数字です。90〜100が緑、50〜89が橙、0〜49が赤です。Core Web Vitals の合否とは別物で、INP は含まれません。

4. フィールドデータの出どころ：CrUX・Search Console・自前の RUM

利用者のデータを取る経路は、大きく3つあります。どれも実際の利用者の体験ですが、集める人と粒度と遅れが違います。

CrUX（Chrome UX Report）

CrUX は、Chrome の利用者のうち、利用状況の統計の送信と閲覧履歴の同期をオンにしている人から集めたデータです。対象はパソコンと Android の Chrome で、iPhone の Chrome や Safari、Edge などは含みません。公開されていて、一定以上の訪問者がいるページだけが対象で、必要な訪問者数は公開されていません。

CrUX の取り出し口は複数あります。

自動化で主に使うのは CrUX API と CrUX History API です。どちらも Google Cloud の API キーが要り、上限を有料で増やすことはできませんが、主要ページを数十件見る程度なら困りません。

Search Console の Core Web Vitals レポート

Search Console の Core Web Vitals レポートも、元は CrUX です。特徴は、似た体験のページをまとめた「URL グループ」で表示することと、グループの状態を最も悪い指標に合わせることです。データが足りないグループは、サイト全体の値に寄せて表示されます。修正したあとに「修正を検証」を押すと、28日間かけて問題が消えたかを確かめます。

気づく道具としては遅く粗いので、担当者どうしの共通の画面として使い、細かい判断は API の数字で行います。

自前の RUM（web-vitals ライブラリ）

RUM（Real User Monitoring）は、計測用のスクリプトで利用者の体験を自分で集める方法です。Google の web-vitals ライブラリは圧縮後およそ3KB で、onLCP・onINP・onCLS で値を受け取れます。約1.5KB 大きいattribution 版なら、どの要素が LCP だったか、どの操作が遅かったかも取れます。

送信は、ページが隠れたとき（visibilitychange）に navigator.sendBeacon() でまとめて送ります。LCP・INP は Chromium・Firefox・Safari で測れ、CLS は Chromium だけです。CrUX に出ない Safari の体験を補えるのが利点です。

5. 28日移動の性質：改善も悪化も遅れて見える

CrUX の値は、直近28日間の利用者の体験をまとめた集計です。この性質を知らないと、「直したのに数字が変わらない」「悪化に気づいたのが3週間後」ということが起きます。

修正を出して7日後でも、窓の4分の3は修正前の体験です。75パーセンタイルは集計全体で決まるので、大きく改善しても、しきい値をまたぐのは2〜3週間後になることがよくあります。悪化も同じです。

この表のとおり、28日集計は「確かめる」道具で、「気づく」道具ではありません。気づく役目はラボデータと RUM に持たせます。

週ごとの重なりを、変化と読み違えない

CrUX History API は、毎週、直近28日の集計を1つの期間として返すので、隣り合う期間は3週間分が重なっています。前週差で兆しを拾い、窓がまるごと入れ替わった4週前との差で確かめる2段で見ると、読み違えが減ります。

6. 自動化の構成：4層で組む

ここまでの性質を踏まえると、監視は時間の速さが違う4つの層で組むのが合理的です。速い層で気づき、遅い層で確かめます。

小さなサイトでは、1〜3層だけで十分なことが多いです。4層目は、改善を続ける意思と担当者がいる場合に加えます。

層1：デプロイ時の回帰チェック

最も費用対効果が高い層です。Lighthouse CI（Lighthouse の自動実行の仕組み）を GitHub Actions などのデプロイの流れに組み込み、検証環境を5回測って中央値が予算を超えたら公開を止めます。

層2：毎日のラボ値の記録

PSI API で主要ページを毎日決まった時刻に測り、結果を表計算かデータベースに貯めます。PSI API は strategy を指定しないとパソコンとして測るので、strategy=MOBILE を必ず付けます。タグマネージャーで足したタグや CMS で差し替えた画像のように、デプロイを通らない変更はこの層でしか拾えません。

層3：毎週の利用者データの確認

CrUX History API で、主要ページ群とサイト全体のスマホとパソコンの75パーセンタイルを毎週取ります。更新は月曜の04:00 UTC ごろなので、月曜の昼以降に実行します。最大40期間（約9か月）さかのぼれます。

7. Lighthouse CI の予算とアサーションの決め方

Lighthouse CI は、設定次第で毎回落ちて誰も見なくなるか、何も止めないかになりがちです。

何回測って、どの値で判定するか

Lighthouse CI の既定の実行回数は3回ですが、Lighthouse の公式ドキュメントは5回の中央値は1回よりおよそ2倍安定するとしています。判定には中央値（median）を使います。実行する機械は2コア以上の専用のCPUが勧められ、共有コアや関数実行型のサービスは避けるよう書かれています。

設定の例

次は、モバイルの条件で5回測り、中央値で判定する設定の例です。数値は DevNJ の初期値の例で、サイトの現状に合わせて調整します。

{
  "ci": {
    "collect": { "numberOfRuns": 5, "url": ["https://staging.example.com/"] },
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", { "maxNumericValue": 3000, "aggregationMethod": "median" }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1, "aggregationMethod": "median" }],
        "total-blocking-time": ["warn", { "maxNumericValue": 300, "aggregationMethod": "median" }]
      }
    },
    "upload": { "target": "filesystem" }
  }
}

容量の予算は resource-summary:script:size のような形で同じ欄に書けます（単位はバイト）。ラボの条件は実際の利用者より厳しいことが多いので、最初は「いまより悪くしない」予算で始め、改善に合わせて下げます。

error と warn の使い分け

判定は off（見ない）、warn（止めない）、error（止める）の3段階です。止めるのは LCP と CLS 程度に絞ります。すべて error にすると急ぎの修正まで止まり、やがて判定ごと外されます。結果の保存先のうち、数日で消える一時的な公開保管は誰でも見られる場所なので、公開前のページはファイル出力か自前の LHCI サーバーに保存します。

8. アラートのしきい値：知らせる条件を先に決める

監視が続かない最大の理由は、通知が多すぎることです。ラボの値は毎回ぶれるので、知らせる条件を層ごとに先に決めます。

数値は DevNJ の初期値の例です。最初の3週間は記録だけ取り、ぶれの幅を見てから決めると誤報が減ります。

「割合」と「絶対値」の両方を条件にする

LCP の1.0秒から1.2秒は20%の悪化でも体験はほぼ同じで、2.4秒から2.7秒は12%でもしきい値をまたぎます。割合と絶対値の両方か、区分をまたいだときに知らせます。通知には、デプロイとタグマネージャーの公開履歴へのリンクを入れておくと原因が絞りやすくなります。

9. 毎週見る数字と、放置してよい数字

自動化の目的は、人が見る数字を減らすことです。

ページはトップ、一覧、詳細、記事、問い合わせのような5つ前後のページ群に分けて見ます。Web Almanac 2025 では、トップページの合格率（モバイル45%）は下層ページ（56%）より低い一方、INP は下層ページのほうが低く（モバイル69%）、トップだけでは全体を読み違えます。

10. 典型的な劣化原因：画像・タグ・フォント・Cookie バナー

表示速度が悪くなる経路は、意外なほど決まっています。

右端の列が手がかりです。デプロイがないのに悪化したならタグマネージャーか広告、全ページが一様に悪化したならフォントか共通の部品を疑います。

画像：サイズ指定と、LCP 画像の遅延読み込み

Web Almanac 2025 では、モバイルのページの62%にサイズ（幅と高さ）の指定がない画像があり、CLS の原因になります。また約16%が LCP 画像を遅延読み込み（loading="lazy"）にしていました。CMS のテーマが、すべての画像に一律で遅延読み込みを付けている例がよくあります。

広告タグと計測タグ

Web Almanac 2025 では、9割以上のページが外部サービスを読み込み、外部へのリクエストの中央値はモバイルで79件でした。広告や計測のスクリプトは操作と同じメインスレッドを使うので、INP を直接悪くします。

タグマネージャー：デプロイを通らない変更

タグマネージャーで足したタグは、層1のデプロイ時チェックを素通りします。公開日を層2の毎日の計測と同じ表に記録しておくと、悪化した日と突き合わせられます。

Webフォント：和文は特に重い

フォントを待つ間は文字の表示が遅れて LCP が伸び、差し替わるときに CLS が出ます。web.dev は、本文に font-display: optional、見出しに swap、size-adjust で代わりのフォントの大きさを合わせる方法を示しています。和文フォントは1書体で数MBになることもあるので、サブセット化か端末のフォントの利用が効きます。日英のサイトでは、英語ページに和文フォントを読み込ませないだけで改善することがあります。

Cookie バナー：同意のあとが重い

web.dev は、Cookie バナーをレイアウトのずれのよくある原因としています。画面の上に差し込むと本文を押し下げ、モバイルではバナーそのものが LCP の対象になることもあります。そして「同意する」の直後に外部スクリプトが一斉に読み込まれ、INP が悪化します。対策は、スクリプトを非同期で HTML に直接置くこと、下部固定かモーダルで表示することです。

11. 費用の幅：無料の組み合わせから有料 RUM まで

費用は、どの層まで自動にするかで変わります。次は DevNJ の目安で、統計ではありません。円は1ユーロ＝175円、外注の時間単価は80ユーロで換算しています。

段階1と2の月額がほぼ0なのは、使う道具が無料だからです。CrUX API と CrUX History API は無料で、GitHub Actions は公開リポジトリなら標準の実行環境が無料、非公開でも無料プランに月2,000分が含まれます。Cloudflare Web Analytics のように、Core Web Vitals を無料で集計し、Cookie を使わないと説明しているサービスもあります。

段階3の有料 RUM は、ページビュー数とラボ測定の回数で料金が決まるものが多く、例として SpeedCurve は2026年10月27日時点で月90ドルからと表示しています。比べるときは同じページビュー数で見積もり、データの保管場所も確かめます。

12. 日本と欧州で比べる：同じ指標、違う前提

Core Web Vitals の基準は世界共通ですが、監視を組む前提は日本と欧州で違います。両方の利用者がいるサイトでは、次の違いを踏まえます。

日本では、RUM で利用者の情報を外部のサービスに送る場合、外部送信規律に沿った通知・公表が必要になる場合があります。欧州では、RUM が Cookie や端末の識別子を使うかで同意の要否が変わり、オランダの個人データ保護庁（AP）は影響の小さい限定的な分析には同意が要らない場合があるとしています。有料 RUM は、Cookie の有無とデータの保管場所を必ず確かめてください。

CrUX はiPhone の利用者を含まないので、iPhone の利用者が多いページこそ、RUM で Safari の値を補う意味があります。

13. ケースで考える（架空の2社）

ここからは、架空の会社で監視の組み方を考えます。実在の会社ではありません。

A社：オランダで日本食材を売る通販サイト

月の訪問は約3万で、スマホが7割です。商品の入れ替えは CMS で毎日あり、開発会社のリリースは月1回です。Cookie バナーとレビューのウィジェット、広告の計測タグを使っています。この規模なら段階2が合います。リリースが少ないので、効くのは層1より層2の毎日の計測と、層4の RUM です。商品一覧の絞り込みの INP と、Cookie 同意後の INP を RUM で分けて見ます。

B社：日本の製造業の欧州向け英語サイト

月の訪問は約2,000で、CrUX にはサイト全体の値しか出ません。更新は年に数回です。段階1で十分で、PSI API で主要5ページのモバイルのラボ値を毎日記録し、CrUX History API でサイト全体を毎週見ます。日本のサーバーから欧州に配信しているため、TTFB が LCP の半分以上を占めていれば、監視より先に CDN の導入が効きます。

2社とも、最初に見る数字を1〜2個に絞っています。

14. よくある失敗と、やってはいけないこと

役に立たなかった監視には、共通する型があります。

最も多いのは最初の2つです。報告の数字には、どの端末で、ラボか利用者かを必ず添えます。

もう1つは、見つけても直す人と期限が決まっていないことです。通知を受けた人が何日以内に誰に頼むかを、監視と同時に決めておきます。リリース前の確認の考え方は「記事更新の自動化は品質ゲートで決まる」でも扱いました。

15. 導入の手順（4週間で始める）

いきなり4層を組まず、記録から始めて、通知は後から足す順番が失敗しにくい方法です。

1. 1週目：見る対象を決める。ページ群を5つ前後に分け、各群の代表URLを1〜3件選ぶ。スマホの3指標の75パーセンタイルの現状を表に書き出す
2. 1週目：API キーを用意する。Google Cloud で PageSpeed Insights API と Chrome UX Report API を有効にし、使える API を制限したキーを発行する
3. 2週目：毎日と毎週の記録を始める。GitHub Actions などの定時実行で、PSI API（strategy=MOBILE）を毎日、CrUX History API を毎週月曜に実行し、結果を表計算に追記する。この段階では通知を出さない
4. 3週目：デプロイ時の回帰チェックを入れる。Lighthouse CI を検証環境に向けて5回実行し、中央値で判定する。最初は LCP と CLS を warn にして、ぶれの幅を見る
5. 4週目：しきい値と通知を決める。3週間分の記録からぶれの幅を確かめ、第8章の条件を調整して通知を有効にする。LCP と CLS を error に上げる
6. 4週目以降：必要なら RUM を足す。改善を続けるページ群があれば、web-vitals の attribution 版を入れ、送信先と保管期間、同意の扱いを決める
7. 四半期ごと：監視そのものを点検する。指標や道具の変更（第1章）がないか、通知が役に立ったか、放置している通知がないかを見る

16. チェックリスト

導入時と四半期ごとの点検に使えるように、項目を並べます。

• ページ群を5つ前後に分け、代表URLを決めた
• 合否はフィールドデータ（CrUX の75パーセンタイル）で見ると決めた
• PSI API に strategy=MOBILE を付けている
• 利用者のデータは CrUX API / CrUX History API から取っている
• Lighthouse CI は5回実行・中央値で判定している
• error で止めるのは LCP と CLS 程度に絞った
• 通知の条件に、割合と絶対値の両方を入れた
• タグマネージャーの公開履歴を記録している
• LCP 画像に遅延読み込みが付いていないことを確かめた
• 英語ページで和文フォントを読み込んでいない
• Cookie バナーが本文を押し下げていない
• RUM の送信先・保管場所・同意の扱いを決めた
• 通知を受けた人が、何日以内に誰に頼むかを決めた

17. まとめ

• Core Web Vitals の合否は、利用者の75パーセンタイルで、LCP 2.5秒・INP 200ミリ秒・CLS 0.1 以下。スマホとパソコンは別に判定する
• PSI のスコアは合否ではない。ラボデータは原因探しと回帰の検知に、フィールドデータは合否に使う
• CrUX は28日の移動集計なので、改善も悪化も1〜3週間遅れて見える。気づく役目はラボと RUM に持たせる
• 監視はデプロイ時・毎日・毎週・常時の4層で組み、小さなサイトは1〜3層で足りる
• 道具は入れ替わる。INP への移行、CrUX Dashboard の終了、PSI API のフィールドデータの扱いを確かめる
• 悪化の原因は、画像・広告タグ・タグマネージャー・Webフォント・Cookie バナーにほぼ集まる
• 毎週見るのはスマホの3指標と前週差・4週前差だけ。通知は記録を3週間取ってから決める

参考にした情報源

指標の定義（web.dev・W3C）

• Web Vitals — web.dev：しきい値と75パーセンタイル
• Interaction to Next Paint (INP) — web.dev：INP の定義
• INP becomes a Core Web Vital on March 12 — web.dev：INP への切り替え日
• Largest Contentful Paint (LCP) — web.dev：LCP の定義
• Optimize Largest Contentful Paint — web.dev：LCP の4区間
• Cumulative Layout Shift (CLS) — web.dev：CLS の定義
• Why lab and field data can be different — web.dev：ラボとフィールドの違い
• Best practices for cookie notices — web.dev：Cookie バナーの影響
• Best practices for fonts — web.dev：フォントの対策
• Event Timing API — W3C：INP の元の仕様

CrUX（Chrome for Developers）

• CrUX methodology — Chrome for Developers：対象の条件
• CrUX API — Chrome for Developers：更新と上限
• CrUX History API — Chrome for Developers：週次の28日集計
• CrUX on BigQuery — Chrome for Developers：月次データ
• CrUX Dashboard deprecation — Chrome for Developers：提供終了

Google 検索・PageSpeed Insights・Lighthouse

• Understanding Core Web Vitals and Google search results — Google Search Central：検索との関係
• Core Web Vitals report — Search Console ヘルプ：URL グループと検証
• About PageSpeed Insights — Google for Developers：ラボの条件
• Get started with the PageSpeed Insights API — Google for Developers：フィールドデータの予定
• runPagespeed — PageSpeed Insights API Reference：strategy の既定
• Lighthouse performance scoring — Chrome for Developers：スコアの重み
• Lighthouse variability — GoogleChrome/lighthouse：5回の中央値
• Lighthouse CI configuration — GoogleChrome/lighthouse-ci：アサーションと保存先
• web-vitals — GoogleChrome：容量と送信方法

統計（HTTP Archive）

• Performance — Web Almanac 2025：合格率と画像
• Third Parties — Web Almanac 2025：外部サービス

費用・制度

• GitHub Actions billing — GitHub Docs：無料の実行時間
• Cloudflare Web Analytics：無料の集計
• SpeedCurve Pricing：有料 RUM の料金
• 外部送信規律 — 総務省：通知・公表の内容

いずれも2026年10月27日に確認したものです。指標・道具・料金は変わるため、導入の前に公式サイトで最新の情報を確認してください。費用と工数、しきい値の初期値は DevNJ の実務上の目安で、サイトの規模と構成によって変わります。