Chromeが広告の量を測り始めた｜CrUXの広告指標4つと使い道

自社のサイトに広告を出しすぎていないか。出稿を検討している媒体の面は、広告で埋まっていないか。この2つの問いには、これまで担当者が実際にページを開いて目で確かめるか、媒体資料の言い分を受け取るかのどちらかでしか答えられませんでした。

Chromeは2026年9月15日、実際の利用者の環境で測った広告の量を、Chrome User Experience Report（以下、CrUX）から公開すると発表しました。CrUXは、LCPやINPといった表示速度の実測値を一般に公開してきた仕組みです。そこへ、広告の数、広告の密度、広告が使ったネットワーク資源、広告が使ったCPU時間という4つの指標が加わりました。公式ブログは、これらの指標がWebの広告主と、広告の配信に使われるサービスにとってとくに有用だろうと書いています。

先に、誤解されやすい点を2つ置いておきます。1つ目は、これらがCore Web Vitalsではないことです。公式ブログは、CrUXの広告指標はCore Web Vitalsの一部ではなく、推奨される目標値や閾値も持たない、と明記しています。合格か不合格かを判定する物差しではありません。2つ目は、4つとも「実験的」という位置づけだということです。コミュニティからの意見を受けて変わりうる、と書かれています。

それでも、これまで数字にできなかったものが公開値になった意味は小さくありません。この記事では、Chromeの公式ドキュメントに書かれている範囲だけを使って、4つの指標が何を測っているのか、そもそも何を広告と判定しているのか、どのサイトが集計に載るのか、そして日本の実務者が何に使えるのかを順に見ていきます。確認日は2026年9月16日です。

4つの指標が何を測っているか

公式ドキュメントの説明を、まず原文のまま並べます。

指標	公式ドキュメントの説明（原文）
Ad Count	how many ads a typical user is seeing at once on the site
Ad Density	a typical user’s balance of content and advertising visibility
Ad Weight: CPU	the CPU consumption by ads, which can impact performance
Ad Weight: Network	the network resources consumption by ads, which can impact performance

出典は Chrome for Developers「Ad measurements」（確認日 2026-09-16）です。意味を変えないよう、説明は英語の表記のまま記録しています。

Ad Count は、ある時点でビューポート（画面に映っている領域）の中にある広告の数です。方法論のページによれば、標本を取った時点で1ピクセルでもビューポートに入っていれば1つとして数えます。広告どうしが重なっていても、部分的にしか見えていなくても、それぞれ別に数えられます。

Ad Density は、ビューポートの面積のうち広告が占めている割合です。こちらは重なりの扱いが逆で、重なっている部分は和集合として一度だけ数えます。画面の外へはみ出している部分も対象から外れ、ビューポートの内側に実際に入っている面積だけが数えられます。

Ad Weight の2つは、見え方ではなく消費された資源の量です。CPUはミリ秒、ネットワークはバイトで測られます。ここに、実務で効いてくる非対称があります。display: none のように描画されない広告は、数と密度には入りません。一方で、CPUとネットワークの消費は測られ続けます。読者にはまったく見えていないのに端末の資源だけを食っている広告は、Ad Weight の側にしか現れない、ということです。

何を「広告」と判定しているのか

数字の意味を決めているのは、Chromeが何を広告と見なしているかです。広告検出のドキュメントには、判定の道筋が3つ挙げられています。

1つ目はフィルターリストとの照合です。リクエストが送られる前に、ブラウザがそれをリストと突き合わせます。このリストは、望まない広告を自動で検出して取り除くために広く使われている公開のルール集、EasyListを圧縮した版だと説明されています。元になっているリストは chromium-ads-detection として公開されています。

2つ目はJavaScriptの実行スタックです。サブリソースやフレームが要求された時点で、スタックに広告のスクリプトが載っていれば、新しく読み込まれるリソースも広告として分類されます。

3つ目は引き継ぎです。いちど広告と判定されたiframeの中で発生したリクエストは、以後すべて広告の分類を受け継ぎます。なお、メインフレーム自体が広告に分類されることはありません。ただしメインフレームの中で使われるスクリプトやメディアといったサブリソースは、分類されることがあります。

この作りから、実務上の含意が2つ出てきます。1つは、自社が出している告知バナーやレコメンドのウィジェットが、フィルターリストの規則に当たれば広告として数えられうることです。もう1つは逆に、リストに載っていない配信のしかたをしていれば数え漏れることです。この数字は「広告の実態」ではなく「Chromeが広告と判定したものの量」です。ここを取り違えると、他社との比較がそのまま不公平になります。

確かめる手段は用意されています。DevToolsのApplicationパネルにあるAdsタブで、フレームごとのAd Statusと、そう判定された理由を見られます。Networkパネルには「Is ad-related」の列があり、リクエスト単位で分類を確認できます。テストのために、リクエストのURLへ ?ad_filterlist_demo_param=1 を付け、実際のルールに当たっていなくても広告として分類させることもできます。自社サイトの検証は、この3つで足ります。

計測はいつ始まり、いつ終わるのか

計測は1回の閲覧ごとに区切られます。開始はメインのHTML文書のTTFB、つまり最初の1バイトが返ってきた時点です。そこから、ページを離れる、タブを閉じる、ブラウザを終了する、のいずれかまで収集が続きます。Androidでは、タブがバックグラウンドへ移った時点も終了として扱われます。タブが背面にある間は収集そのものが止まり、前面へ戻ると再開します。

見え方の2つ、つまり Ad Count と Ad Density は、ビューポートを1秒に1回だけ標本化して計算されます。連続で追いかけているわけではないので、1秒より短い時間しか見えなかった広告は、標本の取り方次第で入ったり入らなかったりします。

ここから、日本のメディアに直接効いてくる話が2つ出てきます。無限スクロールのページでは標本化が続くため、読み込みの合間に手が止まる時間が長いと、その間の画面の状態がセッション全体の値を引っ張ります。もう1つはSPAです。ソフトナビゲーションでは収集がリセットされないため、ルーティングで表示したすべての画面ぶんが1回のセッションに積み上がります。記事を何本も続けて読ませる設計のサイトほど、1回の値が大きく出る方向に働く、ということです。

平均ではなく p75 で出る

報告される値は平均ではありません。Chromeは75パーセンタイル（p75）で出します。方法論のページの説明では、そのページでの全セッションのうち75%が、その値かそれよりも良い状態だったことを意味します。外れ値に引っ張られないようにするための選び方で、Core Web Vitalsの読み方と同じです。

注意したいのは、良し悪しの向きを決める基準が示されていないことです。密度は低いほうが読者にとって快適だろう、という推測は成り立ちますが、公式には推奨値も閾値も置かれていません。したがってこの数字の使い道は、「基準を満たしたかどうか」ではなく比べることに絞られます。自社の月ごとの推移を追うか、同じジャンルの他のオリジンと並べるか、改修の前と後で見るか。当面はこの3つです。

載るサイトと、載らないサイト

数字が公開されるかどうかには、広告の量とはまったく別の条件がかかります。方法論のページには、ads.txt に正規の販売者（authorized seller）が少なくとも1件記載されているサイトだけがCrUXのレポートの対象になる、と書かれています。ads.txt が無いオリジンや、仮の記載しか入っていないオリジンは、集計レポートから外されます。ただしその場合でも、DevToolsでのローカルな計測は見られます。

さらに、CrUX全体の条件も重ねてかかります。公開されていて、検索エンジンと同じ基準で発見できること。そして十分な数の訪問者がいることです。訪問者数の具体的な下限は公表されていません。利用者の側にも条件があり、使用統計の送信を有効にし、閲覧履歴を同期していて、同期のパスフレーズを使っていないChromeだけがデータに寄与します。対象の環境はWindows、macOS、ChromeOS、Linux、Androidで、iOSのChrome、WebViewのアプリ、他のChromium系ブラウザは含まれません。

ここは読み違えやすいところです。自社のオリジンの数字が出てこなかったとき、それは「広告が少ないから」ではありません。条件のどれかを満たしていないだけ、という可能性のほうが高いはずです。

日本の実務者は、これを何に使えるか

立場によって使いどころが変わります。

立場	見るもの	気をつけること
媒体・オウンドメディア	自社オリジンの密度と数の推移	改修の前後で比べる。他社との横並びだけを判定材料にしない
広告主・代理店	出稿を検討している面の混み具合	媒体資料ではなく公開値で見る。ただし合否の閾値は無い
制作・開発	Ad Weight のCPUとネットワーク	表示速度の話に直結するが、LCPやINPの代わりにはならない

進め方には順番があります。最初にやることは、CrUXを開くことではなくDevToolsのAdsタブで自社の主要なページを自分で見ることです。集計レポートに載っていなくてもローカルには測れますし、どのフレームがなぜ広告と判定されているかまで分かります。自社の告知枠が広告として数えられているかどうかも、ここで先に分かります。

次に ads.txt の状態を確認します。広告を配信していないサイトであれば、そもそも集計の対象外です。自社で広告枠を売っている媒体であれば、記載が正しく入っているかを見ておきます。そのうえで、CrUXから自社と比較対象のオリジンの値を取り、月ごとに並べます。

最後に、これを社内のKPIに固定しないことを勧めます。実験的な扱いの指標であり、定義が変わる可能性が明示されています。定義が変わったときに目標値だけが残ると、意味の分からない管理が始まります。当面は、改修の効果を確かめるための観測値として扱うのが無理のない位置づけです。

公式ドキュメントで確認できなかったこと

参照した範囲で分からなかったことを残します。

まず、4つとも実験的な扱いで、推奨値や閾値は示されていません。次に、広告の密度と収益や離脱の関係を示す数値、日本国内のサイトでの分布、業種ごとの目安といったものは、参照したページには記載がありませんでした。BigQueryのどのテーブルやAPIのどのキーで取り出せるかも、今回参照した範囲には書かれていません。データの拡充については、今後1か月のうちに増える見込みだ、という記述だけがあります。

つまり現時点で確実に言えるのは、測れるようになったことと、その測り方までです。どの水準が適切かは、まだ誰も示していません。だからこそ、先に自社の値を把握しておく意味があります。基準が後から示されたときに、自分たちがどこにいたかを遡って言えるのは、いま記録を取り始めた側だけです。

広告の計測まわりの変更は、当サイトで続けて扱っています。表示回数の数え方そのものが変わる話はGoogleの表示回数が描画基準へ移る記事に、測定の設計から入りたい場合はWeb広告の効果測定の記事にまとめています。サイト側の見やすさを整える話は使いやすさの改善、指標の選び方はアクセス解析の指標が近い内容です。海外の動きは海外マーケティングにまとめています。