フィールドデータとラボデータ：違いと使い分け

TL;DR — フィールドデータは、ページを訪れた実ユーザーの体験を集計した数値です。 ラボデータは、通常Lighthouseなどのツールが、固定条件の端末で1回だけ実行するテストです。Googleの評価に関わるのは実ユーザーのフィールドデータであり、ラボのスコアではありません。だからラボで良い結果でも、実際の訪問者には問題が残ることがあります。これは故障ではありません。

ページの速度を測る2つの方法

ページの速さを知る方法は、大きく2つです。

• ツールに1回読み込ませる。 固定した端末、通信速度、場所でページを読み込みます。これがラボデータです。LighthouseやPageSpeed Insightsの診断セクションはこの方式です。
• 実ユーザーに起きたことを見る。 各自の端末と接続でページを訪れた人の体験を観測します。これがフィールドデータです。SEOでは、オプトインしたChromeユーザーの体験から作られるGoogleのChrome User Experience Report（CrUX）を使います。

Googleのweb.devはフィールドデータを明確に定義しています。field data “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (翻訳)「ページを訪れるすべてのユーザーを監視し、それぞれの体験について所定のパフォーマンス指標を測定して決まる」という意味です。対してラボデータは、“is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” (翻訳)「ネットワークと端末の条件をあらかじめ定めた管理環境でウェブページを読み込んで決まる」と説明されます。

覚えておきたい一つの原則

Googleの評価に使われるのはフィールドデータです。 LighthouseやPageSpeedのスコアはラボの数値で、Googleがランキングに使う数値そのものではありません。John MuellerもGoogleは100点満点のラボスコアを検索の評価に使わず、 CWVを別途扱うと説明しています。評価対象は実ユーザーの測定です。

PageSpeed Insightsが緑でも、Search ConsoleのCore Web Vitalsレポートが「Poor」と示すことがあります。壊れているのではなく、別のデータセットを見ているためです。

• ラボ＝低速な端末を想定した、1回のシミュレーション。
• フィールド＝実際の端末とネットワークから集めた訪問体験の集計。

2つの結果は頻繁に食い違います。SEOで重視するのは、そのときのフィールドデータです。

どちらを使えばよいか

• 「ランキング上の状態を知りたい」 → フィールドデータ。 Google Search ConsoleのCore Web VitalsレポートまたはPageSpeed Insights上部で確認します。
• “What’s making my page slow / what do I fix?” (翻訳)「ページが遅い理由と、どこを直すべきか」 → ラボデータ。Lighthouseを実行すると問題点が出ます。
• 「変更の効果を確かめたい」 → まずラボで即時確認し、その後、実ユーザーデータが追いつくのを待ちます。フィールドデータは移動する28-dayウィンドウで更新されるため、反映には遅れがあります。

2つの数値がなぜ分かれるのか、75th percentileと28-dayの集計、各ツールが示すデータ、よくある誤解まで知りたい場合は、Advancedタブに進んでください。

TL;DR — フィールドデータは実ユーザー測定（RUM）の分布で、SEOではChrome UX Report（CrUX）を75th percentileでrolling 28-day集計したものです。ラボデータは、Lighthouseなどが固定した端末・ネットワーク・場所で取得する単一の観測で、ランキング入力ではなく診断用です。どちらが常に「正確」なのではなく、目的で使い分けます。キャッシュ、地域、端末、ネットワーク、スロットリング、操作タイミング（INPを含む）が差を生みます。ラボは素早い検証とデバッグに、フィールドは実ユーザーへの影響とランキングに使います。CrUXはオプトインのChrome限定で、ページ／オリジン集計にはURL正規化、iframe帰属、SPAルートなどの注意点があります。BingにCrUX相当の公開データセットはなく、これはGoogle／Chrome圏の枠組みです。

定義を正確に見る

Googleのweb.devにあるラボデータとフィールドデータが異なる理由が、2つの定義を簡潔に示しています。

• フィールドデータ “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (翻訳)「ページを訪れるすべてのユーザーを監視し、各ユーザーの体験について所定のパフォーマンス指標を測定して決まる」。
• ラボデータ “is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” (翻訳)「ネットワークと端末の条件をあらかじめ定めた管理環境でページを読み込んで決まる」。具体的には、“a single device… connected to a single network… run from a single geographic location.” (翻訳)「1台の端末、1つのネットワーク、1つの地理的な場所で実行する」テストです。

開発運用の文脈では、同じ区別を別の名前で知っているかもしれません。MDNの整理では、フィールドデータはReal User Monitoring（RUM）です。“the performance of a page from real users’ machines,” (翻訳)「実ユーザーの端末から見たページのパフォーマンス」であり、“the browsers of real users report back performance metrics experienced” (翻訳)「実ユーザーのブラウザーが体験した指標を報告する」仕組みです。ラボデータはsynthetic monitoringで、“monitoring the performance of a page in a ‘laboratory’ environment” (翻訳)「実験室環境でページのパフォーマンスを監視」し、“deploying scripts to simulate the path an end user might take.” (翻訳)「エンドユーザーが取りそうな経路をスクリプトで再現」します。つまりフィールド＝RUM、ラボ＝syntheticです。

用語の違いだけではありません。フィールドデータは、数百から数百万の実ユーザーセッションを母集団にまとめ、percentileで読む分布です。ラボデータは、選んだ端末・ネットワーク・場所で1回（または数回）実行する、再現可能な単一観測です。どちらが「正確」かは、知りたい問い、代表させたい母集団、集計方法で変わります。フィールドは「実ユーザーはどう使っているか」、ラボは「ページが機械的に遅い理由」を答えます。両方が有効なパフォーマンス測定の一部であり、それぞれ長所と限界があるとGoogleも説明しています。

フィールドデータを詳しく見る

SEOでいう「フィールドデータ」は、具体的にはCrUX、つまりChrome User Experience Reportです。CrUXは、数百万サイトのGoogle Chromeユーザーの一部から集めた公開データセットで、個々の体験をページ単位とオリジン単位の分布に集計します。

重要な仕組みを押さえましょう。

• オプトインかつChrome限定。 CrUXは利用統計の共有を有効にし、ブラウザー履歴を同期し、同期パスフレーズを設定していないユーザーから、対応プラットフォーム上でデータを集めます。iOS版Chrome、Android WebView、Microsoft EdgeなどのChromiumブラウザーは対象外です。SafariやEdgeが多い利用者層では、実ユーザーの一部しか捕捉できません。
• 平均ではなくpercentile。 フィールド測定のベストプラクティスは、“Whenever possible, rely on percentiles instead of averages,” (翻訳)「可能な限り平均ではなくpercentileを使う」よう勧めています。分布全体を表すにはpercentileが適しており、推奨Core Web Vitalsの判定では**75th percentile（p75）**を確認します。
• 28-dayウィンドウ。 ランキングの基礎となるCore Web Vitalsは移動する28-day集計です。Ahrefsのガイドにも、“the CWV data is on a 28 day rolling average. Any changes you make won’t be seen in the CWV data for a while but will be reflected in lab test data after the changes are made.” (翻訳)「CWVデータは28日間の移動平均で、変更はしばらくフィールドに現れないがラボには反映される」とあります。

数値を信頼する前に知っておきたい母集団・集計の例外:

• ページ単位とオリジン単位は別の分布。 適格性の閾値も異なります。URL単体ではトラフィック不足でも、オリジン全体なら十分なことがあります。CrUXの方法論は両者を分けて定義しているため、オリジンの数値をそのページの数値として扱わないでください。
• URL正規化。 CrUXは集計前にクエリ文字列とフラグメントを識別子から外すため、アプリでは別ページと考えるパラメーター付きURLが1レコードにまとめられることがあります。
• 埋め込みiframe。 遅い第三者iframeの体験は独立したページではなく、最上位ページの数値に帰属します。
• SPAのルート変更。 JavaScriptでの遷移が独立したCrUXページレコードにならず、初回ロードに含まれることがあります。
• データなしは「利用不可」。 「0」でも「良好」でもありません。人気度や適格性の基準に届かなければ、フィールドデータがないと正直に扱い、ラボ推定で埋めないでください。

フィールドデータは抽象的なものではなく、常に更新される大規模データセットです。CrUXのリリースノートによると、2026年5月のリリース（2026年6月9日公開）は18,445,974 originsを対象とし、全体で**55,9%**が良好なCore Web Vitalsでした（LCP 68,6%、CLS 81,3%、INP 86,6%）。約半数のオリジンが不合格であること自体、フィールドとラボが大規模にも食い違う証拠です。

ラボデータを詳しく見る

SEOでいう「ラボデータ」は、Lighthouseと、それを使うPageSpeed Insightsのラボ欄、WebPageTest、Chrome DevToolsのPerformanceパネルです。Lighthouseはスロットリングした接続の管理環境でページを1回読み込み、起きたことを報告します。

制約がそのまま強みです。端末、ネットワーク、場所を固定するため、再現可能で速く、必要なときに実行できます。トラフィックがゼロのページにも結果を出せます。遅いネットワークや低性能端末のユーザーにサイトを広げ、アクセシビリティを高める機会を見つける用途にも役立ちます。

ただしGoogleは限界も明確にしています。Lighthouseはフィールドデータの代替ではありません。“Lighthouse is primarily a diagnostic tool listing potential issues,” (翻訳)「Lighthouseは主に潜在的な問題を列挙する診断ツール」であり、“always concentrate on field Core Web Vitals over Lighthouse metrics and scores.” (翻訳)「Lighthouseの指標やスコアより、常にフィールドのCore Web Vitalsを重視する」べきです。

AhrefsのPageSpeed Insightsガイドも、“you can have a good score but still have a slow page that doesn’t pass CWV,” (翻訳)「良いスコアでも遅く、CWVに合格しないページがあり得る」と説明し、“other factors, such as network conditions, server load, caching, and the user device, also affect page load time.” (翻訳)「ネットワーク条件、サーバー負荷、キャッシュ、利用端末も読み込み時間に影響する」と補足します。

2つのデータが分かれる仕組み

「ネットワークが違う」だけでは説明不足です。Googleは、フィールドデータには多様なネットワーク、端末、ユーザー行動が含まれる一方、ラボデータは “intentionally limits the number of variables involved.” (翻訳)「意図的に変数の数を制限する」と説明しています。主な差は次のとおりです。

• キャッシュ。 Lighthouseは毎回コールドロードします。実ユーザーには再訪者もいて、ウォームキャッシュでラボより速いこともあれば、コールドロードでは見えない遅さもあります。
• 地域とネットワークのばらつき。 ラボは1地点・1プロファイルですが、実ユーザーは国、通信事業者、接続方式に分散します。AhrefsのCWVガイドにある “field data looks at real users, network conditions, devices, caching, etc. But lab data is consistently tested based on the same conditions to make the test results repeatable.” (翻訳)「フィールドは実ユーザー、ネットワーク、端末、キャッシュなどを見、ラボは再現性のため同じ条件で測る」という整理が参考になります。
• 端末。 ラボの中級端末1台に対し、実際には最新機種から古い低価格Androidまで幅があります。
• スロットリングと現実。 Lighthouseのモバイル初期プロファイルは、おおむねslow 4G、約1,6 Mbps、約150 msの往復遅延、約4×のCPU低速化をシミュレートします。DebugBearの分析を個々の利用者の条件と照合してください。
• 操作タイミング。 ラボは受動的なロードを測りますが、実ユーザーはスクロール、タップ、遷移を行います。Chrome DevToolsのPerformanceパネルは手動再現した操作のローカルINPを記録できます。ただし1人1回の操作は母集団ではなく、フィールドCWVの75th percentileにはなりません。

これは欠陥ではありません。Googleも、ラボとフィールドは有効なパフォーマンス測定の一部で、双方に長所と限界があるため、差が出るのは当然だとしています。

どのツールがどのデータを示すか

GoogleのPageSpeed Insightsの説明は、“PSI provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics.” (翻訳)「PSIはページのラボデータとフィールドデータを提供する。ラボは管理環境で集めるためデバッグに有用だが、現実のボトルネックを捉えない場合がある。フィールドは実際の体験を捉える一方、指標の種類は限られる」と要約しています。

オリジン単位へのフォールバックにも注意してください。特定URLのCrUXサンプルが足りないと、PSIはオリジン全体のデータを表示します。オリジンにも十分なデータがなければ、実ユーザーの体験データは表示できません。新規または低トラフィックのページでは正常であり、Googleがラボ推定で補っているわけではありません。

Googleが実際に評価するもの

ランキングの問いで見るのは、28日間のp75に集計されたCrUXのフィールドデータで、ラボの数値ではありません。Search ConsoleのCore Web Vitalsレポートはフィールドデータだけを示し、“shows how your pages perform, based on real world usage data (sometimes called field data),” (翻訳)「実世界の利用データ（フィールドデータとも呼ばれる）に基づきページの状態を示し」、“the data… comes from the CrUX report.” (翻訳)「データはCrUXレポートから来る」と説明します。Googleが内部で公開CrUX値をURLごとのランキング入力へどう変換するかは公開していないため、そこまで断定しません。Search Consoleは似た体験のURLをグループ化するので、1つのURLの状態確認にはPageSpeed Insightsが向いています。

Google関係者はこの区別を一貫して説明しています。Martin Splittの2020年の発言は、“field data comes from real users, whereas lab data comes from a strong machine with good internet — so you might not see the same results” (翻訳)「フィールドは実ユーザー、ラボは良好な通信環境の強いマシンから来るため、同じ結果にならないことがある」と述べています。出典：Search Engine Journal John Muellerは、ラボ結果を*“essentially an approximation of what Google’s systems think might happen in the field”* (翻訳)「Googleのシステムがフィールドで起きそうだと考えることの近似」と説明しました。出典：Search Engine Journal また、“Google doesn’t use the X/100 Lighthouse score for search — it uses the Core Web Vitals separately, as users see them” (翻訳)「GoogleはX/100のLighthouseスコアを検索に使わず、ユーザーに見えるCore Web Vitalsを別に使う」としています。出典：Search Engine Journal

ランキングについて過剰に単純化しないための注意点が2つあります。

• Core Web Vitalsは多数あるシグナルの1つ。 ページエクスペリエンスの文書は、“There is no single signal,” (翻訳)「単一のシグナルはない」とし、“getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results.” (翻訳)「レポートや第三者ツールで良い結果でも、Google検索上位は保証されない」と明記します。
• CrUXだけがフィールドデータではない。 Cloudflare Web Analytics、SpeedCurve、DebugBear、TreoなどのRUMもフィールドデータを作りますが、Googleのランキングシステムが参照するのはCrUXです。ブラウザー、同意、端末、サンプリング、セッション、測定タイミングの違いで、民間RUMとCrUXが食い違うこともあります。
• ラボスコアはランキング予測ではない。 Lighthouseの数値が改善したことは機構を直した証拠であって、ランキングが動く証拠ではありません。

指標そのもの（LCP、INP、CLS、閾値）と関連ツールの詳しい説明は、兄弟ページのCore Web Vitalsハブと、この記事が属するWebパフォーマンスツールハブを参照してください。

Bingではどうか

BingにはCrUXに相当する公開データセットがありません。照会できるBingの実ユーザーフィールドデータも、GoogleやChrome、web.devのような「フィールド対ラボ」の公開ランキング枠組みもありません。Bing Webmaster ToolsのSite Scanは合成的なクロール・監査ツールで、RUM製品ではありません。Bingはページ速度が一般的なユーザー体験に関わるとは述べますが、CrUX型のデータセットは示していません。この枠組みはGoogle／Chromeの概念として扱ってください。

実務で2つを使い分ける

2つのデータセットは競合ではなく、1つのワークフローです。

1. フィールドデータで問題のあるページを見つける。 Search ConsoleのCore Web Vitalsレポート（サイト全体）またはPageSpeed Insights上部（1URL）から始めます。ランキング上の現在地が分かります。
2. ラボデータで診断する。 Lighthouse、PSI下部、DevToolsで、レンダリングをブロックするリソース、過大な画像、レイアウトシフトなどの原因を特定します。
3. ラボで素早く反復する。 即時かつ再現可能な結果を変更のフィードバックにします。
4. フィールドが追いつくのを待つ。 28-dayの移動窓があるため、修正はCWV／CrUXにすぐ完全反映されません。
5. フィールドで実ユーザーへの効果を確認する。 Search ConsoleやPSIのフィールド欄で改善を確かめます。

この流れを正直に保つガードレールは2つです。

• 同じ条件同士で比較する。 フィールドの数値が「動いた」と判断する前に、母集団、フォームファクター、ウィンドウが基準と同じか確認します。オリジン単位からページ単位へ変わった、端末構成が変わった、percentileが変わっただけなら、修正の成否ではなく測定条件の差です。
• ラボ1回だけで機構を断定しない。 管理環境でもネットワーク、端末、バックグラウンド処理で結果は揺れます。原因を特定する前にラボを繰り返します。

原則は、ラボデータでテストとデバッグを行い、フィールドデータで確認とランキング判断を行うことです。Googleの言葉でも、両方があるなら取り組みの優先順位にはフィールドデータを使うとされています。 (翻訳)「フィールドデータを優先する」。

なくしたい誤解

• 「Lighthouseが100/100ならCWVに合格し、ランキングも上がる」 → いいえ。Lighthouseは1回のコールドロード、CWVは実ユーザーの28-day・p75フィールドデータです。結果は食い違い得て、ランキングに関わるのはフィールド側です。
• 「フィールドとラボが一致しないなら壊れている」 → いいえ。目的と測定条件が違うため、差は通常です。
• 「LighthouseのPerformanceスコアがランキング要因だ」 → いいえ。Muellerの説明どおり、Googleは0–100スコアではなくフィールドのCore Web Vitals値を使います。
• 「CrUXは即時更新されるので28日間何も試せない」 → 即時の検証にはラボを使い、フィールドは遅れて届く実世界の確認と考えます。業界で異なる見解もありますが、Googleの公式表現と混同しないでください。
• 「トラフィックがないページのCWVをGoogleが類似ページやラボから推定する」 → いいえ。PSIはまずオリジンのフィールドデータへフォールバックし、それも不足すれば実ユーザーデータを表示しません。
• 「Bingにも知られていないCrUX相当がある」 → いいえ。公開された同種のBingデータセットはありません。

よくある質問

Googleはランキングにラボデータ（Lighthouse）を使いますか？ いいえ。Googleの文書とMuellerの説明では、Lighthouseスコアはランキング入力ではなく、CrUXのフィールドCore Web Vitalsが使われます。

PageSpeed／Lighthouseは良いのにSearch Consoleが「Poor」なのはなぜですか？ 測定対象が違います。固定条件の1回のコールドロード（ラボ）と、28-day・p75で集計した実ユーザーの分布（フィールド）を比較しているからです。「なぜ分かれるか」の節を参照してください。

フィールドデータがない場合は？ PSIはオリジン単位へフォールバックします。オリジンもCrUXサンプル不足なら実ユーザーデータは表示されません。新規または低トラフィックのページでは正常です。

CrUXだけがフィールドデータの源ですか？ いいえ。一般的な意味では、RUMツールならフィールドデータを作れます。ただしGoogleのランキングシステムが使うフィールドデータセットはCrUXです。

BingにもCrUXの独自版がありますか？ この原稿時点で、同等の公開データセットはありません。

ラボとフィールドのどちらを最適化すべきですか？ 変更中の高速で再現可能なテストにはラボを使い、実ユーザーへの影響とランキングに関わる判断はフィールドで確認します。Googleが測るのは後者です。

AI要約

Advanced版の要点をまとめます。

• 競合する2つのスコアではなく、2種類の証拠。 フィールドデータはRUMの分布で、SEOではCrUXを75th percentile・rolling 28-dayで集計します。ラボデータはLighthouseによる単一の合成観測で、診断用でありランキング入力ではありません。
• RUMとsynthetic。 開発運用の用語では、フィールド＝RUM、ラボ＝synthetic monitoringです。
• 分かれる理由。 コールド／ウォームキャッシュ、地域、端末とネットワーク、スロットリング、操作タイミングが関係します。INPは手動のローカル観測はできますが、母集団ではありません。Googleは差を通常のものとして扱います。
• 母集団と集計の例外。 ページ単位とオリジン単位、URL正規化、iframe帰属、SPAルート、データなし＝unavailableを区別します。
• Googleが評価するもの。 28-day・p75のフィールドCore Web Vitalsであり、0–100のLighthouseスコアではありません。CWVは多数のシグナルの1つです。
• オリジンフォールバック。 URLのCrUXサンプルが不足すればオリジンを見て、それも不足すればフィールドデータはありません。ラボで代用しません。
• Bing。 公開CrUX相当はありません。
• ワークフロー。 Search Consoleで発見し、Lighthouse／PSIのラボで診断し、ラボで反復し、約28日待って、同じ条件のフィールドで確認します。ラボはテスト、フィールドはランキング判断です。

公式ドキュメント

フィールドデータとラボデータに関する一次資料です。

Google

• ラボとフィールドデータが異なる理由（対処法を含む） — 定義、差が出る理由、取り組みの優先順位。
• Core Web Vitals：フィールドとラボのツール — CrUXをフィールドの出典とし、Lighthouseは代替ではないと説明。
• フィールドでWeb Vitalsを測るベストプラクティス — 平均ではなくpercentileと75th percentile。
• PageSpeed Insights v5について — PSIのラボ／フィールド欄とオリジンフォールバック。
• Google検索のページエクスペリエンス — 単一のシグナルではなく、良いスコアだけでは上位を保証しないこと。
• Core Web Vitalsレポート — CrUX由来のフィールド専用レポート。
• Chrome UX Report：方法論 — CrUXの定義、オプトイン条件、対応プラットフォーム。
• Chrome UX Report：リリースノート — 日付付きの最新統計。

MDN（エコシステム共通の用語）

• RUMとSynthetic monitoring — フィールド（RUM）とラボ（synthetic）の開発運用上の呼び方。

Bing／Microsoft

• BingにはCrUX相当や「フィールド対ラボ」のランキング枠組みがありません。ページ速度を一般的なユーザー体験の一部として扱いますが、引用できる公開実ユーザーデータセットはありません。Bing Webmaster Toolsのガイドを参照してください。

出典からの引用

Google（およびGoogle関係者）が公に述べた内容です。各リンクは、出典ページの引用箇所へ移動します。

Google — 定義

• “Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (翻訳)「フィールドデータは、ページを訪れるすべてのユーザーを監視し、各ユーザーの体験について所定のパフォーマンス指標を測定して決まります。」 — web.dev。 引用箇所へ移動
• “Lab data is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” (翻訳)「ラボデータは、ネットワークと端末の条件をあらかじめ定めた管理環境でページを読み込んで決まります。」 引用箇所へ移動

Google — 何を優先し、なぜ差が出るか

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (翻訳)「ページに両方のデータがあるなら、取り組みの優先順位にはフィールドデータを使うべきです。」 引用箇所へ移動
• “PSI provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics.” (翻訳)「PSIはページのラボとフィールドの両方を提供します。ラボは管理環境で集めるためデバッグに有用ですが、現実のボトルネックを捉えないことがあります。フィールドは実際の体験に有用ですが、指標は限られます。」 — PageSpeed Insightsの説明。 引用箇所へ移動

Google — フィールドデータとSearch Console（およびランキング）

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” (翻訳)「Core Web Vitalsレポートは、実世界の利用データ（フィールドデータとも呼ばれる）に基づいてページの状態を示します。」 — Search Consoleヘルプ。 引用箇所へ移動
• “There is no single signal.” (翻訳)「単一のシグナルはありません。」 — Googleのページエクスペリエンス文書。 引用箇所へ移動

Google — 75th percentileでフィールドを測る

• “Whenever possible, rely on percentiles instead of averages. Percentiles across a distribution for a given performance metric better describe the full range of user experiences.” (翻訳)「可能な限り平均ではなくpercentileを使う。分布上のpercentileは、指標ごとのユーザー体験の幅をよりよく表す。」 — web.dev。 引用箇所へ移動

Martin Splitt（Google）（Search Engine Journal、2020年6月経由）

• “Field data is coming from real users, whereas lab data comes from a quite strong machine with probably good internet from somewhere around the world. So you might not see the same results.” (翻訳)「フィールドデータは実ユーザーから、ラボデータはおそらく良好な通信環境の強力なマシンから来るため、同じ結果にならないことがあります。」 引用記事

John Mueller（Google）（Search Engine Journal経由）

• “One of the things that generally happens with the lab versus field data is that with the lab data it’s basically an assumption. It’s an approximation of what our systems think might happen in the field.” (翻訳)「ラボデータは基本的に仮定であり、システムがフィールドで起きると考えることの近似です。」 引用記事
• “Google doesn’t use the X/100 lighthouse score for search, we use the core web vitals separately (lcp, cls, fid)… Google uses the values as users see them, which requires a certain amount of traffic first.” (翻訳)「Googleは検索にX/100のLighthouseスコアを使わず、Core Web Vitalsを別に使います。ユーザーに見える値を使うため、まず一定量のトラフィックが必要です。」 （Muellerの大文字・小文字と古いFID表記は原文のままです。） 引用記事

どのデータセットを見るべきか

「どの道を選ぶか」で迷いやすい問いに対する簡易フローです。

開始：何を知りたいですか？

• 「ランキング／SEOで合格しているか」 → フィールドデータ。 サイト全体はSearch ConsoleのCore Web Vitalsレポート、1URLはPageSpeed Insights上部で確認します。フィールドデータが表示されないなら、ページまたはオリジンのトラフィックが不足しています。ラボスコアでランキングシグナルは判定できません。

• 「ページが遅い理由と修正箇所」 → ラボデータ。 Lighthouse、PSI下部、DevTools Performanceで具体的な問題を確認します。

• 「変更の効果」 → まずラボ、次にフィールド。 ラボは即時で再現可能ですが、rolling 28-dayのためフィールドは約28日遅れます。

• 「ログイン後や公開前のページ」 → ラボだけ。 Chrome DevToolsでLighthouseを実行します。公開されていないURLはCrUX／公開PSIから見えません。

• 「競合の実ユーザーパフォーマンス」 → PageSpeed Insightsのフィールドデータ。 十分なCrUXデータがある公開URLで使えます。

• 「ページがなぜ遅いか、何を直すか」 → ラボデータ。 Lighthouse（またはPSI下部、DevTools Performance）で具体的な問題を確認します。

• 「変更したが効果があったか」 → まずラボデータで即時の再現可能なフィードバックを得て、次にフィールドデータで確認します。移動窓のためフィールドの反映は約28日遅れます。

• 「ログイン後・公開前のページをテストしたい」 → ラボだけです。Chrome DevToolsでLighthouseを実行します。CrUXや公開PSIは非公開URLを見られません。

• 「競合の実ユーザーパフォーマンスを確認したい」 → PageSpeed Insightsのフィールドデータ。 十分なCrUXデータがある公開URLなら確認できます。

全体を貫くルール： 評価とランキングにはフィールド、診断と高速な反復にはラボです。2つの数値が食い違っても、SEOで重視するのはフィールドデータです。

フィールド対ラボ — チートシート

中心となる違い

ツールの対応

• フィールド： CrUX・PageSpeed Insights（上部）・Search ConsoleのCWVレポート・DevToolsのCrUXパネル
• ラボ： Lighthouse・PageSpeed Insights（下部）・WebPageTest・DevToolsのPerformanceパネル

早見表

• Googleはフィールドデータで評価する。 CrUXのp75／28-dayであり、0–100のラボスコアではありません。
• ラボで緑でもフィールドで不合格になり得ます。異常ではありません。
• フィールドデータがない場合： PSIはオリジン単位へフォールバックし、それも薄ければ実ユーザーデータは表示しません。
• CrUXはChrome限定かつオプトイン。 iOS Chrome、WebView、Edge、Safari、Firefoxは含みません。
• BingにCrUX相当はありません。 フィールド対ラボはGoogle／Chromeの概念です。
• 原則： ラボでテストとデバッグ、フィールドで確認とランキング判断。

フィールドは不合格だがラボは合格するとき

1. データセットを確認する。 CrUXの範囲、フォームファクター、28-dayウィンドウ、指標をラボの端末・ネットワーク条件と並べて記録します。オリジンフォールバックや別指標なら、まず比較を正します。
2. 影響を受けたフィールドの区分を探す。 モバイルとデスクトップ、URLまたはテンプレート群を分けます。オリジン単位だけの問題なら、合格したページを調整する前に遅いテンプレートを調べます。
3. 現実的な条件で再現する。 遅い端末／ネットワーク、コールド／ウォームキャッシュ、実ユーザーと同じページ状態でラボを再実行します。再現できたらトレースからボトルネックを特定します。
4. 利用できればファーストパーティRUMを使う。 地域、端末、ブラウザー、テンプレート、ナビゲーション種別で分け、Chrome以外の差はCrUXの誤りではなく母集団の差として記録します。
5. 原因を追跡できる修正を1つ出す。 ラボで機構を即時確認し、RUMの初期変化を観測します。隣接するCWVが悪化したら戻すか修正します。
6. フィールドの判定を待つ。 CrUXはrolling 28-day集計なので、同等のウィンドウ同士で比較します。1日目に失敗と決めません。

してはいけないこと

2つのデータセットを混同すると、同じ誤りを繰り返します。

• Lighthouseの100/100を達成して終わりにする。 ラボスコアはランキングシグナルではなく、ラボが完璧でもフィールドで不合格になり得ます。Googleのページエクスペリエンス文書も、SEOだけを理由に完璧なスコアを追うことが最善とは限らないと示します。
• ラボとフィールドの差をバグとして直そうとする。 意図的に異なる測定であり、差は通常です。
• フィールドデータのないページでランキングを判断する。 PSI／Search ConsoleにCrUXがなければ、ラボスコアからCWVランキングの状態は分かりません。
• 修正がすぐフィールドに出ると期待する。 まずラボで即時確認し、実ユーザーデータの遅れを待ちます。
• 任意のRUMがGoogleのランキングデータだと思う。 Cloudflare、SpeedCurve、DebugBear、Treoもフィールドデータを作りますが、Googleのランキングシステムへ供給するのはCrUXです。
• BingもGoogleと同じだと思う。 BingにはCrUX相当がありません。
• 1つのスロットリング条件だけを最適化する。 実ユーザーは端末、ネットワーク、場所が多様なので、1回のslow-4Gシミュレーションに合わせても現実の利用者には失敗することがあります。

テスト：フィールドデータとラボデータ

2つのデータセットと、Googleがどちらをランキングに使うかを問う5問です。各問に答えてから確認してください。

役立つリソース

関連する記事

• Core Web Vitalsとは何か、改善方法 — フィールドとラボの違い、rolling 28-day、CrUXの位置づけ。
• SEO担当者と開発者のためのGoogle PageSpeed Insights — CrUXのフィールド欄とLighthouseのラボ欄、良いスコアでも遅いページになり得る理由。
• テクニカルSEO入門 — パフォーマンス測定を大きな文脈で見るための記事。

登壇・講演

• How Search Works（SlideShare）— クロール、レンダリング、インデックス登録、ランキングとページエクスペリエンスの関係を説明します。（定型の注意書き：“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳)「これはシステムについての私の理解であり、100%完全または正確とは限りません。」）

公式資料

• ラボとフィールドデータが異なる理由とCore Web Vitals：フィールドとラボのツール（web.dev）。
• PageSpeed InsightsについてとCore Web Vitalsレポート（Google）。
• Chrome UX Report：方法論とリリースノート（Chrome for Developers）。

業界の資料

• Googleがフィールドデータをラボデータより信頼できると説明（Search Engine Journal、Southern、2020年6月）— Martin Splittの実ユーザーと強力なマシンの違い。
• 遅いインターネットがCore Web Vitalsに与える影響（Search Engine Journal、Montti、2021年4月）— John Muellerの近似という説明。
• Google LighthouseのスコアはSEOに影響するか（Search Engine Journal、Southern、2021年）— X/100スコアを検索に使わないという説明。
• Lighthouseのラボとフィールドが一致しない理由（DebugBear）— スロットリングの数値と差が出る仕組み。
• ラボデータとフィールドデータの違いと使い分け（Onely）— 比較表による整理。
• RUMとSynthetic monitoring（MDN）— フィールド対ラボの用語。
• r/TechSEO — Core Web Vitalsのコミュニティ。

変更履歴