CrUX広告指標を媒体社はどう読むか：Chromeの広告検出と3つの落とし穴

By /

2026年9月15日、GoogleはChromeの実ユーザーデータ集「Chrome User Experience Report（CrUX）」に、広告に関する4つの実験的な指標を追加しました。画面に同時に出ている広告の数、広告が画面を占める割合、広告が使うCPU時間と通信量です。

この数字は媒体社だけのものではありません。広告主も代理店も、同じ値を無料で調べられます。2026年10月15日には、Assertive YieldのLeela Fallah氏が英DecisionMarketingに寄稿し、広告の数が同じでも読者にかかる負担はページによって大きく違うと指摘しました。

筆者の結論を先に書きます。媒体社は、買い手に見られる前に自社の数字と「Chromeが何を広告と見なしているか」を確かめるべきです。そのうえで、この数字を既存の基準の合否判定に流用しないこと。計算の方法が違うからです。

関連記事
・Chromeが2026年9月に広告体験の新指標を追加、CrUXの4メトリクスとパブリッシャーへの影響
・パブリッシャーがAI用いた広告運用で主導権を握り、収益性を高める方法（Webinarレポート）
・AI検索で読者が消える時代のパブリッシャー戦略：Reach編集220人削減とNYTのAIライセンス3原則

CrUXの広告指標とは？

CrUXの広告指標は、実際のChromeユーザーの訪問から測った広告の量と重さを、サイトごとに公開する4つの数字です。過去28日の値を集計し、75パーセンタイル（p75、訪問の4分の3がその値以下）で示します。

発表の経緯と支持企業の顔ぶれは、2026年9月17日の記事「Chromeが2026年9月に広告体験の新指標を追加、CrUXの4メトリクスとパブリッシャーへの影響」で紹介しました。今回は、発表と同じ日に公開された計測方法の技術文書を読み込み、媒体社が数字をどう読むかに絞ります。

指標 APIのキー 単位 測り方
Ad Count experimental_ad_count 個 1秒ごとに画面内の広告の数を数えて平均
Ad Density experimental_ad_density % 1秒ごとに画面の面積に占める広告の割合を出して平均
Ad Weight: CPU experimental_ad_cpu ミリ秒 広告フレームのJavaScript実行時間の合計
Ad Weight: Network experimental_ad_kilobytes KB 広告関連リソースの転送量（圧縮後）の合計

Chromeはこの4指標をCore Web Vitalsに含めていません。「良い」「要改善」といった区分も、推奨値も設けていない。見られる場所はCrUX Vis、CrUX API、CrUX History API、DevToolsの広告パネルで、BigQueryへの追加は準備中です。

検索順位との関係も気になるところでしょう。2026年9月22日、Googleは検索のページエクスペリエンス文書の参考資料欄にこの指標を1行加えました。Search Engine Landによると、GoogleのJohn Mueller氏はBlueskyで同誌の記者に対し、サイトの状態を評価する指標として載せたもので、すべてが検索の直接のランキング要因ではないと答えています。現時点で順位に効くという根拠はありません。

広告の数が同じでも、読者の負担は違う

Fallah氏の寄稿の出発点は、広告の量を「枠の数」で語る習慣への疑問です。

two pages with the same number of ads can impose very different costs
（同じ数の広告でも、ページによって読者に強いるコストは大きく違う）
（Leela Fallah氏、DecisionMarketing）

寄稿によると、Assertive Yieldの媒体社向け資料で、媒体社3,743ドメインと、プログラマティック供給シェア上位1,000ドメインを比べました。測った広告数は同じでも、媒体社側は広告密度が2ポイント低く、広告の通信量は25%、CPU時間は21%少なかったといいます。筆者はこの資料の原本を確認できていません。Fallah氏自身も、集団どうしの比較であって因果の証明ではないと断っています。

それでも、数と重さが別物だという主張は、Chromeの計算方法を読むと裏づけられます。

Chromeはどうやって広告を見分けているのか

Chromeは、広告ブロッカーで広く使われるフィルタリスト「EasyList」の縮約版と照らし合わせ、通信や iframe が広告かどうかを決める。広告と判定したスクリプトが呼び出したリソースも広告扱いです。いったん広告と判定された iframe は、あとで別のページに移っても広告のまま。ページ本体（メインフレーム）は広告と判定されません。

この判定の仕組みは、2026年に新しくできたものではありません。Chromiumの技術文書によると、この「Ad Tagging」は同じフィルタリストを、Better Ads Standards違反サイトの広告ブロックにも使っています。2020年5月に発表された重い広告の強制削除（Heavy Ad Intervention）も、この判定に基づきます。

筆者は、ここに今回の発表の意味があると考える。広告を止めるために使ってきた判定の結果が、誰でも見られる数字になったのです。

1つの広告判定が3つの用途で使われている
Ad Tagging（EasyListの縮約版によるフィルタ判定）
↓
Better Ads Standards違反の広告ブロック
Heavy Ad Intervention

2020年5月発表・重い広告を強制削除
CrUX 広告指標

2026年9月15日〜・数値を公開
出典: Chromium Docs「Ad Tagging in Chromium」／Chrome for Developers「Ad detection in Chrome」（2026-09-15）／Chromium Blog「Protecting against resource-heavy ads in Chrome」（2020-05-14）

媒体社にとっての含意は2つあります。1つ目は、何が広告かを決めるのがChromeのフィルタだという点。媒体社が広告として売った枠かどうかとは関係がありません。フィルタに当たらない配信は数えられず、逆に当たれば自社の部品でも広告として数えられる可能性がある。DevToolsのApplicationパネルにあるAdsタブで「Highlight Ads」をオンにすると、Chromeが広告と判定した枠が赤く表示されます。通信ごとの判定は、Networkパネルの「Is ad-related」列で確かめられる。

2つ目は、判定から外れるように配信を変えれば数字は下がる、という点です。ただしそれは、Fallah氏が警告する「表面的な遵守」そのもの。読者の負担は何も変わりません。

既存の基準と混同しやすい3つの落とし穴

落とし穴1：広告密度の30%は計算方法が違う

Better Ads Standardsは、モバイルで広告密度が30%を超えるページを受け入れられない体験としています。ただしこの密度は、本文部分の縦の長さに対する広告の高さの合計で、ビューポート（画面）を基準にしないと明記されています。CrUXのAd Densityは、1秒ごとの画面の面積に占める広告の割合の平均です。

CrUXで22%と出ても、Better Ads Standardsで合格とは言えません。逆もまた同じです。

広告密度「30%」はどちらの定義か
項目 Better Ads Standards CrUX Ad Density
分母 本文部分の縦の長さ 画面の面積
測り方 広告の高さの合計 1秒ごとに測って平均
画面（ビューポート）基準 基準にしない（本文基準） 画面の面積を基準にする
基準値 モバイルで30%超は不合格 推奨値なし
集計 記載なし 過去28日のp75
出典: Coalition for Better Ads「Ad Experience: Ad Density Higher Than 30% [Mobile]」（2018-02-16改訂）／Chrome for Developers「CrUX ad metrics measurement methodology」（2026-09-15）

落とし穴2：CPU時間に入らない広告スクリプトがある

Chromeの文書には、CPU時間は広告フレームだけを測り、メインフレームで動く広告スクリプトのCPU時間は除くと書かれています。業界メディアppc.landは、ヘッダービディングのラッパーや広告サーバーのライブラリはメインフレームで動くことが多く、この数字に入らないと指摘しました。CPU時間が小さくても、収益化にかかる処理が軽いとは限りません。

落とし穴3：測っている範囲が限られる

項目 CrUXの広告指標 注意点
対象サイト ads.txtに認定販売者が1社以上あるサイト ads.txtがないと集計されない
対象ブラウザ Windows、macOS、Android、ChromeOS、LinuxのChrome iOSのChromeとアプリ内WebViewは除外
集計の単位 サイト全体（オリジン）か URL ごとの p75 記事・トップ・ライブブログの差が隠れる
平均の偏り 1秒ごとの画面サンプル 広告のない場所を長く読むと数が下がる。無限スクロールの下端で止まると同じ画面が続いて偏る

Ad Countの例で言えば、広告2つが見える画面を5秒、広告のない画面を5秒読むと、値は1.00です。冒頭に広告を詰め込んだページでも、下まで読まれれば数は小さく出ます。

Heavy Ad Interventionとの違いも押さえておきたい点です。こちらは1つの広告について、通信量4MB超、30秒のうち15秒超のCPU使用、合計60秒超のCPU使用のいずれかで、Chromeがその広告を消す仕組みです。Chromiumブログによると、2020年時点で超えた広告は全体の0.3%でしたが、広告の通信量の27%、CPU使用の28%を占めていました。CrUXの指標は広告を消しませんが、このような極端な広告が混じればp75の値に表れます。

重い広告は長い時間をかけて読者を減らす

広告の重さが問題になるのは、読者が離れる影響がすぐには見えないからです。研究はこの点で一致しています。

GoogleのHohnhold氏らは2015年の論文で、短期の実験結果は長期の影響を予測しないと示しました。利用者が広告を見なくなるかどうかは、過去に見た広告の質で決まります。Googleはこの結果をもとに、モバイル検索の広告量を50%減らしました。

音楽配信Pandoraの実験は、約3,500万人を広告の量が異なる9つの群に分け、その割り当てを21か月続けました。最も多い群の広告は、最も少ない群の2倍を超えます。長期で測った広告量への反応は、1か月の実験で測った場合の3倍でした。観察データだけで推定すると、偏ったり向きが逆になったりすることも示されています。

迷惑な広告の値段を測った研究もあります。Microsoft ResearchのGoldstein氏らの実験では、迷惑な広告を出したまま同じ表示回数を得るには、1,000表示あたり1ドル以上多く払う必要がありました（Microsoft Researchのブログによる）。

これまで媒体社の手元には、収益の数字はあっても読者が払うコストの数字がほとんどありませんでした。CrUXは、そのコスト側をサイトをまたいで比べられる公開データとしてそろえました。収益側の数字は、自社のデータで補うしかありません。

媒体社がいまやるべきこと

  1. CrUX VisでデバイスごとにURL単位とサイト単位の値を確認する。ads.txtに認定販売者があることもあわせて確かめる
  2. DevToolsのAdsタブとNetworkパネルで、Chromeが何を広告と判定しているかを見る
  3. 記事、トップ、ライブブログなどページの種類ごとに分け、訪問あたり収益、ビューアビリティ、滞在時間と並べる
  4. 広告のリフレッシュ規則、動画枠、遅延読み込み、需要パートナーごとの重さを1つずつテストする
  5. Heavy Ad Interventionの通知を受け取る設定をする。Reporting APIの通知が埋め込み元のページにも届くようになり、自社ページで広告が消された事実を把握できる

3と4はFallah氏の寄稿の提案に沿っています。1、2、5はChromeの文書に書かれた手段で、今日から試せます。

まとめ

  • 2026年9月15日から、Chromeは広告の数・画面占有率・CPU時間・通信量をサイトごとに公開している。推奨値はなく、検索順位との関係も示されていない
  • 判定はEasyList系のフィルタで行われ、Better Ads Standards違反の広告ブロックやHeavy Ad Interventionと同じ仕組みに基づく
  • 広告密度の定義はBetter Ads Standardsの30%と違い、CPU時間はメインフレームの広告スクリプトを含まない。合否判定に流用しない

買い手は、この数字を掲載先を比べる材料の1つとして使い始めるでしょう。その前に、自社の値と内訳を説明できるようにしておくことが、媒体社の最初の一手になります。

関連記事

参考記事

主要ソース

関連資料

コメントを残す

上部へスクロール