フィールドデータとは、PageSpeed Insights（PSI）が表示する実際のユーザーの計測値のことです。Mobilisticaが2026年9月2日に16サイトのトップページを測ったところ、この欄は96回の観測すべてで空でした。埋まらなかったのはURL単位だけではありません。サイト全体をまとめたオリジン単位も同じく0件でした。
この記事でわかることは次の3点です。
- 16サイト×モバイル/デスクトップ×3回＝96回の実測値と、その生の内訳
- フィールドデータが空のとき、ラボ値のどこを見て良否を決めるか
- 1回のスコアを信じてよい場面と、信じてはいけない場面の切り分け
Mobilisticaは、運営または関与している16サイトを同一条件で並べて測れる立場にあります。1サイトだけを何度も測っても「このスコアは普通なのか」は判断できません。16本を横に並べたときに初めて、スコアの散らばり方と、スコアが同じでも中身が違うことが見えてきます。以下の数値はすべて2026年9月2日の実測で、集計方法も併記しました。
測定条件を先に書く（再現できない数値は載せない）
数値より先に、どう測ったかを示します。同じ手順を踏めば、誰でも自分のサイトで同じ形の表を作れます。
| 項目 | 内容 |
|---|---|
| 測定日 | 2026年9月2日（日本時間 18:51:37〜18:58:45） |
| ツール | PageSpeed Insights API v5（runPagespeed） |
| カテゴリ | category=performance のみ |
| strategy | mobile と desktop の両方 |
| 対象URL | 各サイトのトップページ1本 |
| 回数 | 同一URLを3回。16サイト×2×3＝96回 |
| Lighthouse | 96回すべて 13.4.1 |
| 採用値 | 3回の中央値。欠測は0点に丸めず「取れなかった」として別扱い |
16サイトのうち5サイトは第三者が運営しているため、名称・URL・業種を伏せて「サイトA」〜「サイトE」と表記します。残りはMobilisticaの運営元が自ら手がけるメディアで、サイト名をそのまま出しました。数字の高低を並べる目的ではなく、内訳を開くための材料として読んでください。
結果1：実ユーザーデータは96回すべて空だった
PSIの応答には、実ユーザー由来の loadingExperience（URL単位）と originLoadingExperience（オリジン単位）という2つの枠があります。96回の応答を機械的に数えたところ、値が入っていたのはURL単位で0件、オリジン単位でも0件でした。16サイト全滅です。
これは不具合ではなく、仕様どおりの結果です。Googleは条件をこう書いています。
「特定のページのユーザー エクスペリエンス データを表示するには、CrUX データセットに含めるのに十分なデータが必要です。ページが最近公開された場合や、実際のユーザーのサンプル数が少ない場合は、十分なデータがない場合もあります。（中略）オリジンのデータが不十分な場合、PSI は 実際のユーザー エクスペリエンス データを表示できません。」（Google「PageSpeed Insights について」より）
さらに、CrUX側の収録条件にも同じ趣旨の一文がありました。
「ページは、訪問者数が最小数に達している場合に、十分に人気があると判断されます。（中略）正確な数は公開されていませんが、含まれるページの統計分布に自信を持てるだけの十分なサンプル数を確保できるように選択されています。最小数は、ページとオリジンで同じです。人気度のしきい値を満たしていないページとオリジンは、CrUX データセットに含まれません。」（Google「CrUX の方法論」より）
つまり空欄は「まだ集計中」ではなく「母数の条件を満たしていない」という状態を指します。しきい値は非公開なので、あと何人訪問すれば埋まるのかを逆算する方法はありません。待っていれば埋まると思って計測を先送りするより、ラボ値だけで判断する型を先に持っておくほうが実務は回ります。
結果2：同じURLでも、スコアは動く
同じURLを3回測って、モバイルスコアの最大と最小の差を出しました。差の中央値は3点、最大は29点です。3回とも1点も動かなかったのは15サイト中1サイト（サイトA：56／56／56）だけでした。
| サイト | モバイル3回 | 幅 | デスクトップ3回 | 幅 |
|---|---|---|---|---|
| Apron Days | 99 / 100 / 100 | 1 | 99 / 99 / 100 | 1 |
| Mobilistica | 100 / 100 / 97 | 3 | 99 / 100 / 99 | 1 |
| 都市伝説ラボ | 100 / 98 / 98 | 2 | 100 / 100 / 99 | 1 |
| みんぱくマップ | 96 / 95 / 96 | 1 | 100 / 100 / 100 | 0 |
| マネースタディ埼玉 | 80 / 87 / 66 | 21 | 72 / 98 / 88 | 26 |
| 旅の手続き | 74 / 72 / 83 | 11 | 97 / 95 / 98 | 3 |
| 男の増大塾 | 66 / 83 / 74 | 17 | 99 / 99 / 96 | 3 |
| アイレストヴィレッジ | 67 / 69 / 69 | 2 | 92 / 85 / 85 | 7 |
| サイトD | 66 / 67 / 64 | 3 | 94 / 92 / 88 | 6 |
| EL ORIGEN | 36 / 63 / 65 | 29 | 89 / 89 / 88 | 1 |
| サイトA | 56 / 56 / 56 | 0 | 79 / 79 / 79 | 0 |
| サイトB | 43 / 55 / 55 | 12 | 71 / 73 / 64 | 9 |
| サイトC | 56 / 55 / 55 | 1 | 66 / 66 / 69 | 3 |
| Erii 和装小物店 | 44 / 52 / 58 | 14 | 93 / 89 / 83 | 10 |
| サイトE | 30 / 30 / 37 | 7 | 34 / 38 / 39 | 5 |
| MASUTO Biz | 6回ともスコアが出なかった（後述） | |||
EL ORIGENは36点と65点の間を行き来しました。この2つの数字は、片方だけ見れば「改善の緊急案件」、もう片方だけ見れば「あと少しで合格圏」と、正反対の判断を導きます。同じ日の同じURLで、サイト側は何も触っていません。
Googleもこの現象をFAQで明記していました。
「パフォーマンス測定の ばらつき は、影響のレベルが異なる複数のチャネルを通じて発生します。指標のばらつきの一般的な原因として、ローカル ネットワークの可用性、クライアント ハードウェアの可用性、クライアント リソースの競合などがあります。」（Google「PageSpeed Insights について」FAQより）
ただし「全部が動く」わけでもありません。サイトAはモバイルもデスクトップも3回まったく同じ値で、みんぱくマップのデスクトップも100点で固定でした。動くサイトと動かないサイトが混在するので、幅そのものを毎回測るしかありません。施策の前後で3点動いた程度なら、それは改善ではなく測定のゆらぎの範囲だと考えるほうが安全です。
結果3：スコアが近くても、遅い原因は同じではない
モバイル中央値が52〜56点に固まった4サイトを取り出すと、LCPは10.7秒・11.0秒・21.9秒・26.2秒とばらばらでした。点数の近さは、原因の近さをまったく意味しません。
| サイト | モバイル中央値 | FCP | LCP | TBT | 読み取れる型 |
|---|---|---|---|---|---|
| マネースタディ埼玉 | 80 | 1.1秒 | 1.7秒 | 614ms | 描画は速いがメインスレッドが詰まる |
| サイトA | 56 | 9.8秒 | 11.0秒 | 0ms | 最初の1文字が出るまでが遅い |
| サイトB | 55 | 12.8秒 | 21.9秒 | 0ms | 描画開始も主要要素も遅い |
| サイトC | 55 | 17.4秒 | 26.2秒 | 0ms | 描画開始も主要要素も遅い |
| Erii 和装小物店 | 52 | 7.1秒 | 10.7秒 | 279ms | 描画の遅さとJS実行の両方 |
マネースタディ埼玉のモバイルスコア80点は、スコアが出た15サイトの中で5番目の高さでした。それでもTBTは614ミリ秒、操作可能になるまでの時間は16.1秒で、遅い順に数えると4番目です。点数だけを見ていると、この「触れるまで待たされる」性質は視界に入りません。逆にサイトA〜Cは、TBTが0ミリ秒なのでJavaScriptを削っても事態は動かず、手を入れるべきは描画が始まるまでの経路です。
切り分けにはFCPとLCPの差が使えます。差が小さいときの容疑者は、サーバー応答やレンダリングを止めている読み込みなど、描画の入口です。差が大きいときは主要な画像やフォントの取得を疑います。LCPが速いのにTBTだけ大きい場合は、JavaScriptの実行時間が本命です。個別の直し方はLCP改善の手順とINP改善の手順に分けて書いています。
結果4：CLSでは差がつかず、モバイルとデスクトップは別の話だった
16サイトを横に並べて意外だったのは、CLSがほとんど判断材料にならなかったことです。スコアが出た15サイトのうち11サイトはCLSが0で、残り4サイトも最大0.049。Googleの目安である0.1未満に、15サイトすべてが収まりました。CLS改善の手順は必要になった時点で読めば足りる、という順序が実測から見えます。
一方でモバイルとデスクトップの差は無視できませんでした。モバイル中央値の中央値は69点、デスクトップは89点。差は中央値で16点、最大でErii 和装小物店の37点（52点→89点）に達しました。デスクトップだけを見て安心すると、実際の読者が触っている側の状態を見落とします。
その差が生まれる理由も、Googleが説明していました。
「Lighthouse では現在、ミッドティア デバイス（Moto G4）デバイスでのページ読み込み状況をシミュレートしています。」（Google「PageSpeed Insights について」FAQより）
ただし「モバイルは必ず低い」と決めつけるのも早計でした。Apron DaysとMobilistica自身は、モバイル100点に対してデスクトップ99点と、わずかに逆転しています。例外が2件ある以上、法則ではなく傾向として扱うのが正確です。
結果5：スコアそのものが出ないことがある
16サイトのうち1サイト（MASUTO Biz）は、モバイル3回・デスクトップ3回の計6回すべてでパフォーマンススコアが null になりました。原因はエラー内容に書いてあり、LCPを含む9つの監査項目が NO_LCP、つまり「LCPの対象となる要素を観測できなかった」で失敗していました。
興味深いのは、同じ応答でもFCP（3回の中央値2.1秒）、CLS（0）、Speed Index（同4.5秒）といった他の指標はきちんと取れていた点です。別途1回だけ応答の中身を開いて確かめたところ、82件のリクエストはすべて成功していました（200が81件、204が1件）。総合スコアはLCPを含む加重平均なので、LCPが1つ欠けるだけで欄ごと消えます。
ここで大事なのは、空欄を0点と読み替えないことです。今回は2種類の「取れない」を観測しました。1つはMASUTO Bizのように6回とも同じ理由で落ちる、再現するタイプ。もう1つは一時的な障害です。18時46分時点で保存した1回目のバッチでは、3サイトのデスクトップ計測がLighthouse側の500・400エラーで落ちていました。ところが同じURLを対象にした18時51分以降の3ラウンド96回では、HTTPエラーが0件です。再現するものと消えるものでは対処がまったく違うため、1回落ちただけで原因調査を始める前に、まず測り直す価値があります。
フィールドデータが無いサイトの判断手順
ここまでの実測を、自分のサイトに当てはめられる順番に並べ直します。
-
ステップ1：フィールドデータ欄が空か、まず確認する
PSIの画面上部に実ユーザーの数値が出ていなければ、そのサイトはCrUXの収録条件に達していません。Mobilisticaの16サイトはURL単位もオリジン単位も全滅でした。ここで「計測が壊れている」と考える必要はなく、以降の判断をラボ値だけで組み立てる合図だと受け取ってください。
-
ステップ2：1回で判断せず、3回測って中央値を採る
今回の実測では、モバイルスコアの3回の幅が中央値で3点、最大29点でした。幅が10点を超えたサイトはスコアそのものを判断材料から外し、LCPとTBTの実数で見たほうが安定します。逆に3回ともほぼ同じ値なら、そのスコアは信用してよい数字です。
-
ステップ3：総合点ではなく、LCPとTBTを別々に読む
同じ55点前後でも、TBTが0ミリ秒のサイトと279ミリ秒のサイトでは打ち手が違います。Core Web Vitalsの3指標のうち、どれが合格ラインから外れているかを先に確定させます。
-
ステップ4：FCPとLCPの差で原因の型を絞る
FCPとLCPがほぼ同時なら描画の入口が遅く、FCPが速いのにLCPが遅ければ主要要素の取得が遅い。今回の16サイトでは、LCPが4秒を超えたのは15サイト中10サイト、2.5秒以内に収まったのは4サイトだけでした。着手順の考え方は表示速度改善の進め方にまとめています。
-
ステップ5：改善後は同条件で3回測り、幅ごと記録する
測定日・strategy・カテゴリ・回数を毎回そろえ、平均ではなく中央値と幅の両方を残します。幅を残しておけば、次の計測で3点動いたときに「効いた」のか「ゆらいだ」のかを後から判定できます。
注意点・よくある失敗
最も多い失敗は、改善作業の前後で1回ずつしか測らず、その差を効果として記録してしまうことです。今回の実測では、何も触っていないサイトが最大29点動きました。前後1回ずつの比較では、この幅と施策の効果を区別できません。
もう一つは、日本語ドキュメントの機械翻訳をそのまま根拠にすることです。PSIの日本語ページには「ラボデータが良好な状態では実際のユーザーエクスペリエンスも良いことを意味します」という一文があります。ところが英語の原文は “does not necessarily mean” と否定形でした。日本語版ではこの否定が落ち、意味が逆になっています。日本語ページ自身も冒頭で機械翻訳である旨を断っているため、判断の根拠に使う一文は原文で確かめるほうが安全です。
最後に、スコアは順位を保証する数字ではありません。Google 検索セントラルは、Core Web Vitalsと検索結果の関係をこう説明しています。
「Core Web Vitals は、その他のページ エクスペリエンス要素とともに、Google のコア ランキング システムがランキングを決定する際に考慮する要素です。」（Google 検索セントラル「Core Web Vitals と Google 検索の検索結果について」より）
考慮される要素の一つであって、中身の代わりにはなりません。
よくある質問（フィールドデータが出ないサイト FAQ）
フィールドデータが出ないのは、サイトの設定ミスですか？
多くの場合は違います。CrUXは訪問者数の最小数と一般公開での検索可能性を収録条件にしており、この基準を満たさないページとオリジンはデータセットに含まれません。Mobilisticaが2026年9月2日に測った16サイトは、96回の観測すべてで空でした。
どれくらいアクセスが増えればフィールドデータが出ますか？
Googleは正確な数を公開していません。CrUXの方法論には「正確な数は公開されていません」と明記されているため、必要な訪問者数を逆算する方法はありません。埋まるのを待つより、ラボ値で判断する手順を先に用意するほうが現実的です。
スコアが測るたびに変わりますが、どれを採用すればよいですか？
3回測って中央値を採ってください。今回の実測ではモバイルスコアの3回の幅が中央値3点・最大29点でした。幅が10点を超える場合はスコアではなく、LCPとTBTの実数を判断材料にします。
モバイルの点数が低いのは仕方がないのでしょうか？
差が出るのは自然ですが、放置してよい理由にはなりません。Lighthouseのモバイル計測はミッドティア端末（Moto G4）を模したうえで実行されるため、デスクトップより厳しい値が出ます。今回はモバイル中央値69点に対しデスクトップ89点で、差の中央値は16点でした。
スコアが空欄（null）になったときはどうすればよいですか？
0点と読み替えず、失敗した監査項目の理由を確認してください。今回の1サイトは6回ともLCP要素を観測できず、総合スコアだけが出ませんでした。同じ日に別の3サイトでは一時的な500・400エラーも発生し、こちらは測り直しで解消しています。
まとめ
要するに、フィールドデータが出ないサイトでは、総合スコアを1回測って終わりにする読み方が最も危険です。今回の16サイト実測から言えることは次の3点です。
- 実ユーザーデータの空欄は不具合ではなく収録条件の問題で、96回の観測すべてで空だった
- 同じURLでもスコアは動く（幅の中央値3点・最大29点）ため、3回の中央値と幅をセットで残す
- 点数が同じでも原因は違う。LCPとTBTを分けて読み、FCPとの差で型を絞る
Mobilisticaでは、運営・関与するサイト群の実測値を同一条件で並べて公開していきます。この記事の数値は測定条件を明記しているので、自分のサイトを同じ手順で3回測り、表に1行足す形で使ってください。
※本記事の数値は2026年9月2日にPageSpeed Insights API v5（category=performance）で取得した実測値です。ラボ計測は環境によって変動するため、再現時に同じ値になるとは限りません。
※サイトA〜Eは第三者が運営するサイトのため、名称・URL・業種を伏せています。
最終更新: 2026年9月2日
Mobilisticaの運営者情報はこちらをご覧ください。