「PageSpeed Insightsのスコアを1点でも上げたい」
「LCP（Largest Contentful Paint）を改善して、検索順位を死守したい」

Webフロントエンドに関わるエンジニアなら誰もが抱くこの切実な願い。その解決策として、ネット上に溢れる「Google AdSenseの遅延読み込み（Lazy Load）」というTipsに手を染めてはいませんか？

Intersection Observer や setTimeout を駆使して adsbygoogle.js のロードを遅らせ、スコア上の「100点」を叩き出す。一見すると、それは「賢い最適化」に見えるでしょう。

しかし、adsbygoogle.jsのロードを技術的に遅らせる実装はお手持ちのAdSenseアカウントにポリシー違反の多大なリスクが孕んでいると言えます。

今回はGoogle AdSenseの遅延読み込みは許可されているのか？「ポリシー違反です」
をよりエンジニアリングな目線で要点解説したいと思います。

レイジーロードってそもそも何か？

レイジーロード（Lazy Load）とは、直訳すると「遅延読み込み」のことです。
通常、ブラウザはHTMLを上から順に読み込み、画像やスクリプトなどのリソースをその都度リクエストしますが、これでは初期表示（First Paint）が遅れてしまいます。

これを回避するために、画像、映像、JavaScriptなどのWebアセットの読み込みタイミングを「DOMの解析完了後」や「ユーザーがその要素までスクロールした瞬間」までずらし込む手法を指します。

エンジニアがレイジーロードを実装する主な目的：
LCP（Largest Contentful Paint）の改善: ページ上部の重要コンテンツを最優先で表示させる。

データ転送量の削減: ユーザーが見ない（画面外の）リソースを読み込まないことで、サーバー負荷と通信量を抑える。

初期実行スレッドの解放: 重いJS（AdSenseなど）の実行を後回しにし、メインスレッドの占有を防ぐ。

しかし、AdSenseにおける「遅延」は意味が異なる
一般的な画像（imgタグ）の loading="lazy" とは異なり、AdSenseのスクリプトを独自JSで制御することは、「広告配信システムそのものの挙動を外部からハックする行為」とみなされる点に、この問題の本質があります。

Googleアドセンスで使われる遅延読み込みの手法

様々なブログやSEO対策ガイド、テックメディアで紹介されている手法は一般的なJavaScriptの読み込み順序の遅延テクニックを応用した比較的シンプルな手法である端的に説明すればadsbygoogle.jsを（headタグ）で読めなくして (adsbygoogle = window.adsbygoogle || []).push({});以下AdSenseライブラリーと呼称するをDOMの解析終了に当たるスクロールイベントの発生か一定時間の経過まで実行不可にしてしまうという手法だ。

まず以下のコードでadsbygoogle.jsを再設置するScript要素を生成する。

(function(window, document) {
  function main() {
    // GoogleAdSense読込み
    var ad = document.createElement('script');
    ad.type = 'text/javascript';
    ad.async = true;
    // 新コードの場合、サイト運営者IDを書き換えてコメントアウトを外す
    //ad.dataset.adClient = 'ca-pub-7180830494628299';
    ad.src = 'https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js';
    var sc = document.getElementsByTagName('script')[0];
    sc.parentNode.insertBefore(ad, sc);
  }

次に以下のコードで各イベントリスナーの削除と再登録並びにmain関数を実行してscript要素の挿入を行う。

 // 遅延読込み
  var lazyLoad = false;
  function onLazyLoad() {
    if (lazyLoad === false) {
      // 複数呼び出し回避 + イベント解除
      lazyLoad = true;
      window.removeEventListener('scroll', onLazyLoad);
      window.removeEventListener('mousemove', onLazyLoad);
      window.removeEventListener('mousedown', onLazyLoad);
      window.removeEventListener('touchstart', onLazyLoad);
      window.removeEventListener('keydown', onLazyLoad);
      main();
    }
  }
  window.addEventListener('scroll', onLazyLoad);
  window.addEventListener('mousemove', onLazyLoad);
  window.addEventListener('mousedown', onLazyLoad);
  window.addEventListener('touchstart', onLazyLoad);
  window.addEventListener('keydown', onLazyLoad);

最後に以下のコードでイベントリスナーが発火しない時に3秒のタイマー処理を行いmain関数を強制実行せる。

  window.addEventListener('load', function() {
    // ドキュメント途中（更新時 or ページ内リンク）
    if (window.pageYOffset) {
      onLazyLoad();
    }
  //何もアクションがないときは指定秒数後に読み込み開始（ミリ秒）
  window.setTimeout(onLazyLoad,3000)
  });
})(window, document);

わかりやすくフローをリストにまとめると

headからadsbygoogle.jsを排除
イベントリスナーの発火によりJavascript要素をbodyの末尾に挿入
広告リクエスト・レンダリング

一言で言えばこの実装はタイマーやイベントり処理を用いてる点を除いてadsbygoogle.jsをbodyエリアに設置していることと何ら変わりがない。←しかし実装方法に問題がある。

実装方法によるレンダリングプロセスの違い

自動広告の動作に悪影響を与える

現代のAdSenseにおいて主流となっている「自動広告」は、AIがページ全体のドキュメント構造（DOM）を解析し、最適な位置に広告を自動挿入する仕組みです。独自JSによる遅延読み込みは、この 「AIによる解析プロセス」をも破壊 してしまいます。

一般的にAdSenseの自動広告にはアンカーやインタースティシャルなどページレベルフォーマットと呼ばれる広告フォーマットの実装・配信機能が備わっています。これらを管理するのもadsbygoogle.jsが担っている。

ここでadsbygoogle.jsが本来の実装方法とは異なる手法で実行されるとアンカーやインタースティシャルの挙動に不具合が生じることとなります。実際この本投稿をしている私はGoogleのアンカーのプレースホルダーが極端に小さくなり広告案件が歪なほどに小さくなっているサイトを目撃しました。

CLS（Cumulative Layout Shift）の悪化

「LCPを改善するために遅延させた結果、CLSが悪化する」という本末転倒な状況が発生します。
ユーザーがスクロールした瞬間に突然スクリプトが走り、自動広告がDOMに割り込んでくるため、コンテンツがガタッと大きく動いてしまいます。これはCore Web Vitalsのスコアを押し下げるだけでなく、Googleから「ユーザーに誤クリックを誘発させる意図的なレイアウト変更」とみなされるリスクを孕んでいます。

無効なトラフィックによるアカウント無効化のリスク

ここまで技術的な挙動上の問題を見てきました。ここからはよりポリシーに関するリスクを技術的に深堀していきましょう。

Google AdSenseを含むDoubleclickの仕組みをより細かく分析するために、ブラウザのネットワークタブからリクエストチェーンを精査してみると、adsbygoogle.js のロードと並行して、あるいはその直後に、いくつかの重要なスクリプトやビーコンが読み込まれ、実行されていることがわかります。

これらは単なる補助的なツールではなく、広告エコシステムの信頼性を担保するための「心臓部」です。

adsbygoogle.js (メインAPI/司令塔)
すべての広告配信プロセスの起点となるエントリポイントです。ページ内の広告ユニットを検知し、後続の各専用スクリプトをロード・制御する司令塔の役割を果たします。
show_ads_impl_fy2021.js (案件選択・描画)
広告主の入札状況に基づいた**広告案件の選択（シンジケーション）と実際の描画（レンダリング）**を管理します。さらに「インプレッションが発生した」事実をサーバーに確定・記録する、収益発生のトリガーとなる最重要コアです。
lidar.js (ビューアビリティ計測)
広告が実際にユーザーの視界に入っているかを精密に測定する専用ライブラリです。
sodar2.js (トラフィック品質検査)
サイト全体のトラフィック品質を包括的に解析します。ブラウザ環境やデバイスの整合性を検証し、人間による正当なアクセスであるかを多角的に判定するための高度なスキャンを行います。
abg_lite_fy2021.js アドベリフィケーションの軽量ライブラリー
Google の Anti‑Bot / Anti‑Abuse Guard（BotGuard）の軽量版で、広告クリックや広告リクエストが bot かどうかを高速に判定するための前処理スクリプト。ATQ や BotGuard 本体と連携し、不正トラフィックを早期に検出する。
bg/*.js (BotGuard/不正検知)
不正なクリックや自動化された操作（BOT）をリアルタイムで検知・遮断するための防壁です。広告主の予算を保護し、エコシステムの健全性を維持する極めて重要なセキュリティ層です。
ext.js (SafeFrame ライブラリ)
IAB 標準の SafeFrame 規格を実装し、広告をセキュアなサンドボックス環境に隔離します。ページ本体のセキュリティを保ちつつ、広告との安全な通信 API を提供します。
window_focus_fy2021.js (アクティブビュー計測)
ウィンドウのフォーカス状態を監視し、ユーザーが実際にページを注視しているかを計測します。高単価な広告配信に欠かせない「アクティブビュー」指標の核となるスクリプトです。
f.txt / integrations (統合シグナル交換エンドポイント)
広告主、パブリッシャー、および計測システム間でシグナルを双方向に交換するための統合ハブです。リアルタイムオークション（RTB）の最適化だけでなく、トラフィック品質、ビューアビリティ、さらには不正検知に関するデータの同期を一手に担います。

⚠️ 遅延読み込みすると何が壊れるのか

■ 1. ビューアビリティ計測が破壊される
Active View は以下の条件を満たさないと成立しない

広告が画面に入った瞬間に lidar.js が動いている
window_focus がフォーカス状態を追跡している
SafeFrame が初期化されている

遅延読み込みすると・・・
広告が画面に入った後に lidar が読み込まれる

ビューアビリティが 0% と判定される
高単価広告が配信されなくなる
収益が落ちるだけでなく、ポリシー違反扱いになる可能性もある

Google は「ビューアビリティを意図的に下げる行為」を
広告品質の低下＝ポリシー違反として扱う。

■ 2. ATQ（不正トラフィック検知）が正常に動かない
sodar / abg_lite / bg は広告リクエストの前に動く必要がある。

遅延読み込みすると・・・

クリック保護（qs_click_protection）が間に合わない
BotGuard が初期化される前に広告がクリックされる
ATQ が「不自然なクリック」と誤判定する

つまり！
無効トラフィック（IVT）扱い→最悪アカウント制限の対象

Google は「不正クリックを防ぐための仕組みを意図的に無効化する行為」を
重大なポリシー違反として扱う。

■ 3. 広告オークション（RTB）の品質が低下する
show_ads_impl はページの状態を見て広告案件を選ぶ。

遅延読み込みすると・・・

ページの初期状態が取得できない
コンテキスト解析が不完全
ユーザーの滞在時間が短いと広告が間に合わない

低単価広告しか入札されない

これは収益低下だけでなく、
Google 側から見ると「広告枠の品質が低い」と判断される。

■ 4. SafeFrame が正しく初期化されない
ext.js（SafeFrame）は広告のサンドボックス化を担う。

遅延読み込みすると・・・

SafeFrame が初期化される前に広告が表示される
広告がページ DOM に直接触れる可能性
セキュリティリスク扱い
ポリシー違反の対象

つまり：遅延読み込みは“広告を遅らせる”のではなく、

AdSense の安全・品質チェックを破壊する行為になる
これまでスクリプト構造を見ると遅延読み込みは次のように見えます。

Active View → 壊れる
ATQ → 壊れる
BotGuard → 壊れる
SafeFrame → 壊れる
RTB → 最適化不能
インプレッション確定 → 不正確
クリック保護 → 無効化される可能性

Google から見れば：

「広告の品質を意図的に下げる行為」
「不正トラフィック検知を回避する行為」
「ビューアビリティを偽装する行為」

無効なアクティビティと解釈されてもおかしくない。

Google の無効トラフィック判定は“意図”ではなく“挙動”で判断されるため、遅延読み込みによって安全機構が正常に動作しない状態が発生すると、それだけで IVT と誤判定されるリスクがある。

なぜ黙認されているか？

Google の公式スタンスはこう：

遅延読み込みという手法そのものはポリシー違反ではない

ただし広告の計測・安全機構に影響が出たら、それはあなたの責任

その結果 IVT（無効トラフィック）扱いになっても、それもあなたの責任

つまり Google は：

「遅延読み込みを禁止する」とは言っていない
「遅延読み込みで壊れたら知らないよ」と言っているだけ

これが“黙認されているように見える”正体。

「明確に許可されていない」
「明確に禁止もされていない」

という状態は、実は最も危険な状態である。

なぜなら、アカウント停止になったとき“復活できない理由”として使われるから。

意義の申立てを却下する要因

GoogleAdSenseコードの改変を禁止ておきながらそれを理由に直接のポリシー制裁を下さずほんとどが以下の理由でアカウントを無効化したり配信を一時停止することが多い。

無効なアクティビティ（Invalid Activity）
無効なトラフィック（Invalid Traffic）
無効なクリック（Invalid Clicks）

しかし、Googleのポリシーチームは意義の申立てだけではパブリッシャーの意図は読み取らず構成公平に判断される。これを覆すにはGoogle社内のパブリッシャー担当者であるアカウントマネージャーと呼ばれる。営業担当者が付いていない限り一切意思は反映されない。

故に、第三者による故意や過失でない無効なトラフィックであることを立証したとしても遅延読み込みしている時点でアピールは却下されかねない。

Googleが開発者向けドキュメントで説明していることは？

グーグルの開発者向けサイト（Google Developers）でも遅延読み込みのためのコードサンプルを提供してますがこちらはより本格的で、広告が画面領域内に入ったら表示する、というもの。

enableLazyLoad（遅延読み込みの有効化）（英語）

Googleパブリッシャータグ（GPT）というのを利用するものですが難しいので割愛 ^-^;）
勝手に割愛されているブログもあるが...

広告製品が異なりプログラム自体、別のロジックで構成されている。

これが指し示しているのはあくまでもGoogle Publisher Tag(GPT)つまりGoogleアドマネージャーの話しでAdSense単体における話ではないためこれをAdsenseのに当てはめて考えると本解説で挙げているポリシー上のリスクを伴うことになる。

まとめAdSenseの遅延読み込みは自己責任を超えてポリシー違反である

Google Developers が提供している遅延読み込みコードは、Google Publisher Tag（GPT）＝Google アドマネージャー専用のものであり、AdSense とは別の広告配信ロジックで動いている。

GPT はパブリッシャーが広告リクエストのタイミングやビューアビリティ計測を制御する前提で設計されているため、遅延読み込みが公式にサポートされている。

一方、AdSense は安全機構（Active View・ATQ・BotGuard・SafeFrame）が自動で動く前提のため、GPT の遅延読み込み手法を流用すると計測が破壊され、結果として無効なトラフィック（IVT）扱いになるリスクがある。

つまり、Google の開発者ドキュメントは AdSense の遅延読み込みを許可しているわけではなく、誤解して適用すると重大なポリシーリスクを招く。

AdSenseの遅延読み込みはポリシー違反であると私は認識する。