CrUXの2026年8月分でもINPの悪化が続き、原因は公式にも分かっていない ── 自社の悪化を全体の傾向と切り分けて確認する13項目（2026年10月時点）

目次

1. 01 何が起きたか — 2026年8月分のCrUXでもINPの悪化が続き、公式は「明確な理由は分かっていない」と書いた
   1. 公式のリリースノートに書かれたこと
   2. この一文が言っていることと、言っていないこと
   3. 悪化の大きさを、月ごとの数字で見る
2. 02 なぜ・背景 — 全体の傾向が動く月に、自社の悪化の原因探しから始めると遠回りになる
   1. CrUXの数字は、サイトごとの結果の集まり
   2. 全体が動くと、自社の悪化の説明が二通りに割れる
   3. 公式が過去に書いた「悪化の説明」には、型がある
   4. だから、先に「切り分けの順番」を決めておく
3. 03 この記事に出てくる用語
   1. INPは「操作してから、次の画面更新まで」の時間
   2. フィールドデータとラボデータは、別のものを測っている
   3. CrUXが数える利用者と、数えない利用者
4. 04 型別 — 適用範囲・この発表が測っていないこと・切り分けの手順
   1. 🅰 適用範囲 — 自社の数字が見られるサイトと、見られないサイト
   2. 🅱 この発表が測っていないこと
   3. 🅲 手順 — 自社の悪化を、全体の傾向と切り分ける5段
   4. 手順1 — 自社の実ユーザーの数字で、悪化した時期を決める
   5. 手順2 — Search Consoleで、悪化の範囲を絞る
   6. 手順3 — 直近2か月の変更を、日付つきで並べる
   7. 手順4 — 比べるサイトを2〜3つ決めて、同じ期間を見る
   8. 手順5 — 動いたページを実際に操作して、遅い操作を記録する
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — INPの数字を見る道具の使い分け
   1. 道具ごとに、数字の期間と細かさが違う
   2. 自社で実際のユーザーの数字を集めるときの注意
7. 07 当サイトの例 — 点検ツールの報告は「大げさ」と思っていたが、測り直すと本当に遅かった
   1. 2026年9月30日に、記事ページの表示を速くした
   2. この例から、切り分けに持ち込める考え方
8. 08 このテーマの、これまで
   1. 2024年3月12日、INPがFIDに代わった
   2. 2025年、Androidのデータ品質の問題が修正された
   3. 2026年4月から8月、5か月連続で下がった
   4. この記事の数字は、2026年10月4日に確認した時点のもの
9. 09 この記事のまとめ

01 何が起きたか — 2026年8月分のCrUXでもINPの悪化が続き、公式は「明確な理由は分かっていない」と書いた

公式のリリースノートに書かれたこと

Chrome UX Report（略称CrUX）は、Chromeを使う実際の利用者のページの体験を集めた公開データである。Chromeの公式サイトには、このデータの更新内容を月ごとに書いた「リリースノート」がある。2026年9月8日に公開された「August 2026」の項目に、次の一文が書かれている。

"The continued regression of INP in particular is a cause for concern, but we don't have a definitive reason for this."

（訳: 特にINPの悪化が続いていることは懸念すべき点だが、その明確な理由は分かっていない。）

同じ項目には、追跡しているオリジン（サイトのドメイン単位のまとまり）が18,294,881件、INPが「良好」のオリジンが85.3%で、原文では「18,294,881 origins (↑ 1.3%)」「85.3% of origins (↓ 0.5%)」と表記されている。

この一文が言っていることと、言っていないこと

この一文が言っているのは、INPの悪化が続いていること、公式が懸念していること、明確な理由は分かっていないことの3点である。一方で、公式のページには次のことは書かれていない。

• 原因が何か（ブラウザの側か、サイトの側か、データの集め方か）
• どの種類のサイトで悪化が大きいか
• パソコンとモバイルのどちらで悪化が大きいか
• 日本のサイトで同じことが起きているか

公式が分からないと書いている以上、「原因はこれだ」という記事や投稿は、公式の情報では裏づけられていない。WEBディレクターが確認できるのは、自社のサイトの数字が、この全体の動きの中でどう動いたかだけである。この記事は、その切り分けの手順を整理したものである。

悪化の大きさを、月ごとの数字で見る

リリースノートの各月の項目から、INPが「良好」のオリジンの割合を並べると、2026年4月から8月にかけて下がり続けている。

02 なぜ・背景 — 全体の傾向が動く月に、自社の悪化の原因探しから始めると遠回りになる

CrUXの数字は、サイトごとの結果の集まり

リリースノートの「85.3%」は、利用者全員の平均ではない。CrUXはサイト（オリジン）ごとに、実際の訪問での操作の遅さを集め、そのサイトのINPが「良好」「改善が必要」「不良」のどれに当たるかを判定する。リリースノートの数字は、「良好」と判定されたサイトが、追跡しているサイト全体の何%かを表している。自社のサイトが悪化したかどうかは、この数字とは別に、自社のオリジンの数字を見ないと分からない。

全体が動くと、自社の悪化の説明が二通りに割れる

自社のINPが悪くなったとき、考えられる説明は大きく二つある。ひとつは、サイトの改修・タグの追加・広告の入れ替えなど、自社が変えたものが原因という説明。もうひとつは、ブラウザや利用者の端末、データの集め方など、自社の外で起きていることが原因という説明である。画面に表示される数字は、どちらの場合も同じ「悪化」である。

公式が過去に書いた「悪化の説明」には、型がある

リリースノートを2025年から2026年まで読むと、INPが動いた月の説明が、毎回同じではないことが分かる。次の2つは、いずれも公式のノートに書かれた文である。

"Previously, we mentioned that we fixed a data quality issue affecting Android devices and we are pleased to see a reversion of the last few month's regressions in most metrics (and even more so when looking at mobile only)."

（訳: 以前、Android端末に影響するデータ品質の問題を修正したと述べたが、ほとんどの指標で、ここ数か月の悪化が元に戻ったことを喜ばしく思う（モバイルだけで見ると、その傾向はさらに強い）。）

これは2025年7月分（2025年8月12日公開）の項目である。続く8月分（9月9日公開）には、次のようにある。

"A return to form with the numbers trending up again with the completion of the Android data fix mentioned last month."

（訳: 先月触れたAndroidのデータ修正が完了し、数字が再び上向いて、本来の調子に戻った。）

この2つは、データの集め方に問題があったという種類の説明である。2026年5月分にはAndroidに偏った悪化、6月分には季節的な動き、8月分には理由が分からないという説明が書かれている。つまり、全体の数字が動いたときの説明は、データの問題・端末の偏り・季節・不明と、月によって違う。

だから、先に「切り分けの順番」を決めておく

説明が月によって違う以上、全体の数字を見ただけでは、自社の悪化の原因は決まらない。必要なのは、自社とほかのサイトの数字を同じ期間で並べ、自社だけが動いたのか、全体と一緒に動いたのかを先に確かめる順番である。順番を決めずに調べ始めると、最近入れた変更だけが疑われ、全体の傾向が見落とされる。順位が動いた週の切り分けは、「順位が落ちた」と騒がれた週、Googleの公式は何も言っていなかった ── 変動と、自分に起きたことを切り分けるに整理されている。

03 この記事に出てくる用語

INPは「操作してから、次の画面更新まで」の時間

web.devの公式ガイドは、INPを次のように定義している。

"INP is a metric that assesses a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page."

（訳: INPは、利用者がページを訪れている間に起きたクリック・タップ・キー入力のすべての遅延を観察して、ページ全体の反応の良さを評価する指標である。）

判定は、実際の訪問で記録されたページ読み込みの75パーセンタイルで行われ、モバイルとデスクトップに分けて見る。「200ミリ秒以下が良好、200ミリ秒を超えて500ミリ秒以下が改善が必要、500ミリ秒を超えると不良」という3段階の区切りは、同じガイドに書かれている。3つの指標（LCP・INP・CLS）全体の基準の整理は、Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目（2026年9月時点）にまとめてある。

フィールドデータとラボデータは、別のものを測っている

この2つは、同じページでも数字が違って当然である。web.devのガイド（2022年7月更新）は、ラボのテストでは、利用者がいつページを操作するかを正確に予測できないと説明している。この文面はFIDについてのものだが、操作への反応を測るINPでも、同じ食い違いが起きやすいと考えられる。

PageSpeed Insightsの上の欄（実際のユーザー）と下の欄（Lighthouse）を並べて「数字が合わない」と悩むのは、よくある遠回りである。切り分けでは、まず実際のユーザーの数字で悪化を確かめ、あとからラボで原因を探す順番にする。

CrUXが数える利用者と、数えない利用者

CrUXの公式の説明によると、データを提供するのは、使用状況の統計の送信を有効にし、閲覧履歴を同期していて、同期のパスフレーズを設定しておらず、対応する環境（Windows・macOS・ChromeOS・Linuxのデスクトップ版Chrome、またはAndroid版Chrome）で使っている利用者である。iOSのChromeやAndroid WebView、ほかのChromium系ブラウザは対象に含まれない。データが出るのは「公開されていて、十分に訪問者のいるオリジン」で、人数の基準は公開されていない。

04 型別 — 適用範囲・この発表が測っていないこと・切り分けの手順

🅰 適用範囲 — 自社の数字が見られるサイトと、見られないサイト

CrUXの数字は、すべてのサイトで見られるわけではない。訪問者が少ないサイトや、公開されていないページは、データが出ない。PageSpeed Insightsの公式の説明は、数字の出し方を次のように書いている。

"Sometimes the origin may also have insufficient data, in which case PSI will be unable to show any real-user experience data."

（訳: オリジンのデータも足りないことがあり、その場合、PageSpeed Insightsは実際のユーザーの体験のデータを表示できない。）

PageSpeed Insightsは、特定のURLに十分なサンプルがないとき、自動的にオリジン全体（サイト全ページ）の数字に切り替える。実際のユーザーの欄で、「このURLのデータ」と「オリジン全体のデータ」のどちらが表示されているかを、必ず確認する。数字が出ないサイトは、自社で測る方法（06章）に切り替える。

🅱 この発表が測っていないこと

リリースノートの数字から、自社のことは分からない。理由は4つある。

• 自社の数字ではない。約1,830万のオリジン全体の割合である。自社が良好のグループに入っているかどうかは別に確かめる。
• 原因が書かれていない。公式が分かっていないと書いているため、原因を探す手がかりにはならない。
• 端末の内訳が書かれていない。2026年5月分にはAndroidへの言及があるが、8月分には端末の説明がない。
• 日本のサイトの内訳が書かれていない。国や地域別の数字は、リリースノートの項目には見当たらない。

他人の数字の扱い方は、「+28%」と「+9%」は、同じ調査の、同じプラットフォームの数字だった ── 他人が測った数字を自分のサイトに当てはめる前に確かめる3点にある。

🅲 手順 — 自社の悪化を、全体の傾向と切り分ける5段

手順は5段ある。図の順番に、1段ずつ確かめる。各段で、「自社だけの動きか、全体も同じか」を1行ずつ記録しておくと、最後に判定できる。

手順1 — 自社の実ユーザーの数字で、悪化した時期を決める

最初にやるのは、「いつから悪くなったか」を日付で決めることである。PageSpeed Insightsの実際のユーザーの欄は、直近28日間の数字である。公式の説明は、PageSpeed Insightsの実際のユーザーのデータと、BigQuery上のCrUXのデータセットについて「Both data sources represent trailing 28-day periods.」（訳: どちらのデータ源も、直近28日間の期間を表す。）と書いている。28日間の移動する期間の数字なので、悪化が始まった週を、この欄だけで特定するのは難しい作りである。

週ごとの履歴が必要なときは、CrUXの履歴APIを使う。公式の説明では、このAPIは最大40週分（約10か月分）のデータを週ごとの期間で返し、各期間は直近28日間のデータを集めたもので、隣り合う期間は3週間ぶんが重なる。既定では25期間が返り、1〜40の範囲で変更できる。

"The History API is updated each Monday around 04:00 UTC and contains data up until the previous Saturday (as per the standard 2-day lag)."

（訳: 履歴APIは毎週月曜のUTC 04:00ごろに更新され、直前の土曜日までのデータを含む（通常の2日の遅れによる）。）

APIの取得は開発担当に頼んでも構わない。「自社のオリジンのINPを、モバイルとデスクトップに分けて、25期間ぶん」と範囲を指定して頼み、取得できたら、悪化が始まった週を1つ決めて日付で書き留める。この日付が、手順3で変更の一覧と照らす基準日になる。

ラボデータで確かめたいときは、当サイトの🔧 Lighthouse監査・チェックツール（利用には無料の会員登録が必要である）が使えるが、実際のユーザーの数字の代わりにはならない。

手順2 — Search Consoleで、悪化の範囲を絞る

Search Consoleの「ウェブに関する主な指標」レポートは、公式ヘルプによると、CrUXのデータを元にしている。ここでは、モバイルとパソコンを分けて、INPに問題があるURLグループがいくつあるかを見る。悪化が特定のテンプレートに集中しているのか、サイト全体なのかが分かれば、手順3で調べる範囲が狭まる。

注意したいのは、このレポートの「修正を検証」である。公式ヘルプは、検証が始まった時点の動作を、次のように書いている。

"Start tracking does not trigger re-indexing or any other active behavior from Google. It just (re)starts the clock on a 4-week monitoring period of CrUX data for your site by Search Console."

（訳: 追跡の開始は、再インデックスやGoogleのほかの能動的な動作を引き起こさない。Search Consoleがあなたのサイトの CrUX のデータを4週間監視する期間の時計を、（再）開始するだけである。）

つまり、「修正を検証」を押すと、4週間の監視期間が始まる。切り分けが済む前に押すと、4週間の監視だけが始まり、原因の切り分けは進まない。押すのは、原因が自社にあると判定して、直したあとにする。Search Consoleの通知の扱いについて、当サイトで毎週の点検にした経緯は、Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日にある。Search Consoleの画面の読み方に迷うときは、当サイトの🔧 Search Consoleの見方に迷ったときの解説ツールが使える。

手順3 — 直近2か月の変更を、日付つきで並べる

手順1で決めた基準日の前後2か月に、自社が入れた変更を、日付つきで一覧にする。更新履歴・タグ管理の変更履歴・広告やCMSの管理画面の履歴から拾う。一覧に入れるものは、次のとおりである。

• サイトの改修（テンプレート・スクリプトの追加や変更）
• タグの追加・変更（計測・広告・チャット・A/Bテストなど）
• 広告の入れ替えや、広告の提供元の設定変更
• CMSのプラグインやテーマの更新
• 外部の部品（埋め込み動画・地図・フォーム・口コミ部品）の提供元の更新

最後の項目は、自社で何も変えていなくても、提供元の更新で自社のページのINPが動く場合があるため入れる。一覧には、変更した日だけでなく、「自社で入れた」か「提供元が変えた」かも書く。

手順4 — 比べるサイトを2〜3つ決めて、同じ期間を見る

全体の傾向かどうかは、ほかのサイトの数字を同じ期間で見ないと分からない。比べるサイトは、同じ業界で、作りが近いサイトを2〜3つ選ぶ。それぞれのPageSpeed Insightsの実際のユーザーの欄を、同じ日に確認し、可能なら同じ期間のCrUXの履歴も見る。

比べるときは、条件をそろえる。別の期間、別の端末の数字を並べると、違いが条件の違いなのか、サイトの違いなのか、区別できなくなる。当サイトが、サイトごとに測る条件がそろっていなかった例は、同じ条件で測っていなかった ── robots.txtは「24時間キャッシュ」のはずが、測ったら1日13.9件と152.3件。3サイトの数字を並べる前に確認すべきだったことにある。

並べた結果は、次の4通りに分かれる。4通りのうち、自社だけが動いている場合にだけ、自社に原因がある可能性が高くなる。

手順5 — 動いたページを実際に操作して、遅い操作を記録する

自社だけが悪化していると判定したら、最後に、悪化したURLグループのページを1つ選び、実際に操作して記録する。Chrome DevToolsのPerformanceパネルは、操作の記録に加えて、CrUXの数字を横に並べて見られる。公式のドキュメントでは、「Next steps」の「Field data」で設定すると、手元の数字と実際の利用者の数字の比較が表示されると書かれている。

遅い操作が見つかったら、どこで時間がかかっているかを分ける。web.devのガイドは、操作から画面更新までを3つの区間に分けている。

"The input delay, which starts when the user initiates an interaction with the page, and ends when the event callbacks for the interaction begin to run."

（訳: 入力の遅延は、利用者がページに対して操作を始めた時点から始まり、その操作に対するイベントの処理が動き始めた時点で終わる。）

残りの2つは、イベントの処理が動いている時間（処理時間）と、操作の結果を表した次の画面が出るまでの時間（描画の遅延）である。どの区間が長いかで、直す方向が変わる。

自社の利用者の操作を継続して記録したいときは、公式のweb-vitalsライブラリで、操作の対象の要素と、3つの区間の時間を記録できる。

05 明日、自社のサイトで確認できることチェックリスト

以下は、自社のINPが悪化したと感じたときに、PageSpeed Insights・Search Console・Chrome DevToolsで確認できる項目である。1〜3番目は時期の特定、4〜5番目は範囲の絞り込み、6〜7番目は変更の一覧、8〜10番目は比べるサイトとの照合、11〜13番目は操作の記録と再確認である。チェックの状態はブラウザに保存され、サーバーには送られない。

• PageSpeed Insightsに自社トップページのURLを入れ、モバイルとデスクトップの両方で「実際のユーザー」の欄が出るか確認する
• その欄の表示が「このURL」と「オリジン全体」のどちらか書き留め、INPの値を200ミリ秒・500ミリ秒の区切りと照らして判定する
• CrUXの履歴APIで自社オリジンのINPを25期間ぶん取り（開発担当に頼んでよい）、悪化が始まった週を1つ書き出す
• Search Consoleの「ウェブに関する主な指標」を開き、モバイルとパソコンで、INPに問題があるURLグループの数を書き出す
• 問題があるURLグループの代表のURLを3つ開き、共通のテンプレートや部品があるか確認する
• 悪化が始まった週の前後2か月に入れた改修・タグ・広告・CMSの更新を、日付つきで10件まで書き出す
• 書き出した変更のうち、悪化が始まった週の2週間前から当日までに入ったものに印を付ける
• 同じ業界で作りが近いサイトを2〜3つ決め、PageSpeed Insightsの「実際のユーザー」のINPを同じ日に書き留める
• 比べるサイトのCrUXの履歴でも、同じ週にINPが上がっていないか確認する
• 自社と比べたサイトの動きを、手順4の4通りのどれに当たるか判定し、1行で書く
• 自社だけが悪化している場合は、悪化したURLグループのページを1つ選び、Chrome DevToolsのPerformanceパネルでクリックを3回記録する
• 記録した操作のうち最も遅いものについて、入力の遅延・処理時間・描画の遅延のどれが最大かを書き留める
• 判定・基準日・変更の一覧を1枚にまとめ、4週間後の同じ日にPageSpeed InsightsのINPを測り直す予定をカレンダーに入れる

06 代替・他の選択肢 — INPの数字を見る道具の使い分け

道具ごとに、数字の期間と細かさが違う

INPの数字を見られる道具は複数あり、それぞれ期間と細かさが違う。

CrUX APIの公式の説明では、数字は「a 28-day rolling average of aggregated metrics」（訳: 集計した指標の28日間の移動平均）で、更新は毎日UTC 04:00ごろに行われ、1つのGoogle Cloudプロジェクトあたり1分に150回まで、無料で使える。

自社で実際のユーザーの数字を集めるときの注意

訪問者が少なくてCrUXに数字が出ないサイトでは、web-vitalsのようなライブラリを自社のページに入れて、利用者の操作を自分で集める方法がある。この場合は、次の点を決めてから入れる。

Core Web Vitalsが検索順位に与える影響についての公式の言い方は、Core Web Vitalsは、クロールやリンク評価に影響するのか ── 公式ドキュメントを確認する（2026年8月時点）にまとめてある。

07 当サイトの例 — 点検ツールの報告は「大げさ」と思っていたが、測り直すと本当に遅かった

2026年9月30日に、記事ページの表示を速くした

当サイトでは、毎朝の点検ツールが「遅いページ」を大量に報告していた。大げさだと考えていたが、1本ずつ測り直すと、記事ページだけが1〜4秒かかっていた。原因は、記事の中の用語に説明を付ける処理だった。この処理を速くしたところ、記事ページの表示は0.1〜0.27秒になった。経緯は、警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かったと、毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかったに書いている。

この例から、切り分けに持ち込める考え方

効いたのは、報告された数字を、そのまま信じも疑いもせず、自社の側で1件ずつ測り直すことだった。INPでも、全体の報告と自社の数字は別々に確かめる。

08 このテーマの、これまで

2024年3月12日、INPがFIDに代わった

INPは、2024年3月12日に、それまでのFID（First Input Delay）に代わるCore Web Vitalsの指標になった。web.devは2024年1月31日の発表で、次のように予告していた。

"INP will officially become a Core Web Vital and replace FID on March 12 of this year"

（訳: INPは今年の3月12日に、正式にCore Web Vitalとなり、FIDに代わる。）

発表には、Search ConsoleではINPがCore Web Vitalになると同時にFIDが削除されること、PageSpeed InsightsやCrUXなどのほかのツールでは6か月の移行期間が設けられることも書かれている。INPとFIDの違いの整理は、Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目（2026年9月時点）にある。

2025年、Androidのデータ品質の問題が修正された

2025年7月分と8月分のリリースノートには、Android端末のデータ品質の問題の修正が書かれている（02章の引用）。データの集め方の問題が数字に現れた例で、全体の数字が動いたときにデータの側の事情も疑う理由になる。

2026年4月から8月、5か月連続で下がった

2026年は、4月分の87.1%から、8月分の85.3%まで、毎月数字が下がっている。5月分は「Androidに偏った悪化」、6月分は「季節的」、8月分は「明確な理由が分からない」と、ノートの説明が変わっている。説明が変わったことは、原因が1つではない可能性を示す。ただし、公式のノートに書かれているのは説明の文面だけで、原因の裏づけは書かれていない。

この記事の数字は、2026年10月4日に確認した時点のもの

この記事に書いた数字は、2026年10月4日に、CrUXのリリースノートとweb.devなどの公式の資料を開いて確認した。9月分のリリースノートが公開されたら、まず同じ表に数字を足し、悪化が続いたか、戻ったかを確かめる。公式の文面と食い違ったときは、公式の最新のページが優先である。