GA4 vs サーバーログとは、Webアクセスを測る2つの方式を比較し、それぞれが何を捉え何を捉えられないかを明確にする対比の枠組みです。AI検索時代には「人間の訪問」と「AIボットの巡回」という性質のまったく違う2種類のアクセスを別々に把握する必要があり、この2方式は片方だけでは全体像を描けません。両者は競合ではなく、担当領域が異なる補完関係にあると理解することが出発点になります。本稿では、両者が「どこで・いつ・何を記録するか」の違いを起点に、AIボットが片方にしか映らない理由と、2方式をどう重ね合わせて使うかを具体的に整理します。この理解が、AI検索対策のレポートで数字を読み違えないための前提になり、どちらの道具をどの問いに向けるべきかの判断軸になります。両者の役割を取り違えると、収集も成果も正しく測れないまま施策を回すことになりかねません。
GA4は、Webページに計測用のJavaScript(=ブラウザ上で動く小さなプログラム)を埋め込み、訪問者がページを開いたときにブラウザからGoogleのサーバーへ計測データ(=イベント)を送る方式です。GA4はセッション(=一連の訪問)単位ではなくイベント(=クリックやスクロールなど個々の出来事)単位でデータを集める設計に変わり、Cookie(=ブラウザに保存する識別情報)に依存しない計測(クッキーレス計測)の選択肢も持ちます。人間がページ上で何を見て・どう動いたかを詳細に測るのに向きます。
サーバーログは、Webサーバーがリクエストを受け取った瞬間に、アクセス元IPアドレス・日時・要求URL・HTTPステータスコード・User-Agentを1行ずつ書き残す記録です。ブラウザの協力もJavaScriptの実行も要らず、サーバーに届いたものはすべて残ります。このため、計測タグを実行しないAIボットや、ページを描画せずファイルだけ取りに来るクローラーも漏れなく捉えられます。
AI検索対策では「AIに収集されているか(=入口)」と「人間がAI経由で訪れて何をしたか(=出口の一部)」を両方見ておきましょう。前者はサーバーログでしか安定して捉えられず、後者はGA4が得意とします。片方だけで判断すると、AIボットの巡回を丸ごと見落とすか、逆に人間の行動の質を測れないまま「巡回数が多い=成果」と誤読する事故が起きます。2方式の守備範囲を知ることが、正しいレポート設計の前提になります。
GA4はブラウザ発火・人間中心、サーバーログはサーバー発火・全リクエスト網羅。
観点 GA4 サーバーログ 記録の場所 ブラウザ→Googleのサーバー 自社Webサーバー 発火条件 JavaScriptが実行されたとき リクエストが届いた時点 AIボット 多くが映らない 映る(User-Agentで判別) 得意分野 人間の行動・体験の質 全リクエストの事実記録 Cookie/同意 影響を受ける 影響を受けない 画像・静的ファイル取得 基本的に測らない すべて残る
横にスクロールできます
この表の核心は「発火条件」の行にあります。GA4はJavaScriptの実行が起点なので、ブラウザを持たず素のHTTPリクエストでファイルを取得するAIクローラーは、そもそも計測の引き金を引きません。サーバーログはリクエスト到達が起点なので、実行環境に関係なく記録されます。ここがAIボットの可視性を分ける決定的な分岐点です。
なぜAIクローラーの多くはJavaScriptを実行しないのでしょうか。学習用・検索インデックス用のクローラーは、大量のページを効率よく集めることが目的で、1ページごとにブラウザを起動してJavaScriptを描画させると計算コストが跳ね上がります。そのため多くは素のHTTPリクエストでHTML本文だけを取得し、JavaScriptによる後追いの描画は行わないか、行っても計測タグまでは実行しない設計が一般的です。GA4の計測タグはこの描画・実行の先で発火するので、クローラーの取得は計測の網に掛かりません。逆に言えば、GA4に「映らないアクセス」こそがAIボットの巡回であり、その死角をサーバーログが埋める、という関係になります。
加えて、GA4側にはボットを意図的に除外する仕組みもあります。既知のボットやスパイダーからのアクセスを計測から自動的に取り除く配慮が働くため、仮に一部のボットが計測タグを実行したとしても、人間の行動データを汚さないよう弾かれることがあります。この設計はGA4を「人間の行動を測るツール」として正しく機能させるためのものですが、裏を返せば「GA4でAIボットの巡回を数えよう」とすること自体が、道具の目的から外れた使い方だと分かります。ボットを測りたいならサーバーログ、というのは思想レベルでの役割分担でもあります。
GPTBotがトップページを取得:GA4には映らない/サーバーログには「GPTBotが/を200で取得」と残ります。 人間がAI Overviewsのリンクから記事を開いてスクロール:GA4がイベント(閲覧・スクロール)を記録/サーバーログにはHTMLと画像の取得が並ぶが、スクロール等の行動は測れません。 Cookie同意を拒否した人間の訪問:GA4では計測が制限される場合がある/サーバーログにはリクエストが残ります。 なりすましボットが人間のUser-Agentを名乗って巡回:GA4には映りにくい/サーバーログにはIPと挙動が残り、公開IP一覧照合で見破れる余地があります。 「GA4の数字とサーバーログの数字が一致しない」のは異常ではなく仕様です。両者は測っている対象も発火条件も違うので、数値は原理的にずれます。GA4のセッション数とサーバーログのリクエスト数を単純比較して「どちらかが壊れている」と結論づけるのは誤りです。ずれる前提で、それぞれの得意領域の問いに使い分けます。
AI検索対策では、この2方式を「足し算」ではなく「重ね合わせ」で使います。サーバーログで「どのAIボットが・どのページを・どれだけ収集したか(入口)」を押さえ、GA4で「人間がAI経由も含めてどう流入し、サイト内でどう行動し、目標を達成したか(体験と成果)」を押さえます。この2つのレイヤーを重ねると、たとえば「学習用クローラーの巡回は増えているのに、人間の流入は伸びていない」「AI Overviewsに露出しても、来訪後の直帰(=1ページで離脱すること)が多い」といった、片方だけでは見えない構図が浮かび上がります。収集が増えることと成果が出ることは別なので、両レイヤーを突き合わせて初めて施策の良し悪しを判断できます。片方の数字だけで結論を出すと、収集は伸びているのに成果が出ていない状態を「順調」と誤認したり、逆に成果の停滞を収集不足のせいにできず打ち手を誤ったりします。
実務上のコツは、2方式のデータを1つの表に混ぜて平均や比率を計算しないことです。単位も母数も違うため、混ぜた瞬間に意味のない数字が生まれます。代わりに、レポートを「収集の観測(サーバーログ由来)」と「行動の観測(GA4由来)」の2セクションに分け、それぞれの結論を並べて示します。両者を橋渡ししたいときは、同じ期間・同じ対象ページに絞って「収集は起きていたか」「その後に人間の流入・成果があったか」を時系列で並べる、という見せ方が読み手に伝わりやすいです。
まず問いを分類する:「AIに収集されているか」はサーバーログ、「人間がどう行動したか」はGA4、と担当を決めます。 AIボット巡回の観測はサーバーログで行い、User-Agent別・URL別に集計します。 人間の流入と体験の質(滞在・遷移・コンバージョン=目標達成)はGA4で測ります。 2つを1枚のレポートに並べず、「収集の観測(ログ由来)」と「行動の観測(GA4由来)」でセクションを分けます。 数値のずれを説明できるよう、各方式が何を測っているかを注記しておきます。 AI経由の人間流入はリファラー(=流入元を示すヘッダー)が付かない・独自表記になる問題があるため、GA4の参照元だけで判断せず、両面から裏を取ります。 2方式を対比するとき、「両方で測れること」より「片方でしか測れないこと」に注目すると使い分けが腑に落ちます。GA4だけが捉えるのは、ページ内でのユーザーの振る舞いです。どこまでスクロールしたか、どのボタンを押したか、フォームを送信したか、購入や問い合わせといった目標(コンバージョン)に到達したか――これらはブラウザ上のイベントとして初めて記録されるもので、サーバーログには残りません。人間の体験の質を評価する情報は、原理的にGA4側にしかありません。
逆にサーバーログだけが捉えるのは、ブラウザを介さないアクセスのすべてです。AIクローラーの巡回はもちろん、画像・CSS・JavaScriptファイル単体への直接リクエスト、APIへのアクセス、存在しないURLへの404、攻撃的なスキャンなど、GA4の計測タグが発火しない領域が丸ごと残ります。AI検索対策で言えば、「どのAIボットが・いつ・どのページを・成功(200)で取得したか」という収集の事実は、サーバーログにしか刻まれません。この非対称性を理解すれば、「両方入れるのは冗長では」という疑問は消えます。両者は重複ではなく、互いの死角を埋め合う関係にあります。
データの保持と粒度にも違いがあります。GA4は集計済みのレポートとして扱いやすい反面、生のイベントを長期に細かく持ち続けるには制約があり、過去に遡って別の切り口で数え直すのが難しいことがあります。一方サーバーログは、保存さえしておけば1リクエスト単位の生データが手元に残るため、後から「あのAIボットは半年前どう動いていたか」を遡って集計し直せます。AI検索は事業者もボットの振る舞いも短期間で変わるため、後から過去を検証できるサーバーログの生データ性は、変化の速い領域を追ううえで大きな強みになります。ただし生ログは個人情報(IPアドレス等)を含みうるため、保存期間や取り扱いは自社のプライバシー方針に沿って管理する必要があります。
まとめると、GA4は「加工済みで人間の行動を読みやすいが、ボットと生データには弱い」、サーバーログは「生で網羅的だが、そのままでは人間の行動の質を語れない」。この長所と短所が正反対だからこそ、2つを併用する意味があります。AI検索対策のレポートでは、サーバーログで収集の土台を固め、GA4で人間の流入と成果を評価し、両者の結論を並べて意思決定に使う――この分担が、どちらか一方に偏るより確実に精度の高い判断につながります。どちらを先に整えるべきか迷うなら、まずサーバーログでAIボットの収集が起きているかを確認し、収集の土台があると分かってからGA4で人間側の成果を追う、という順序が実務では扱いやすいです。
「片方でしか測れないこと」を並べると、2方式が補完関係だと一目で分かります。
測れること GA4のみ サーバーログのみ 両方 スクロール・クリック等の行動 ○ コンバージョン到達 ○ AIクローラーの巡回 ○ 静的ファイル単体の取得 ○ ページの被アクセス(人間) ○ 404などのエラー応答 ○(全件)
横にスクロールできます
GA4でAIボットの巡回は見られますか。 基本的に見られません。GA4はブラウザのJavaScript実行で発火するため、JavaScriptを動かさないAIクローラーの多くが計測に載りません。ボット巡回はサーバーログで観測してください。
どちらか一方だけ運用するならどちらですか。 目的次第です。人間の行動と体験を改善したいならGA4、AIに収集されているかを確認したいならサーバーログが要ります。AI検索対策では両方を担当分けして併用するのが基本です。
GA4とサーバーログで数字が合いません。壊れていますか。 壊れていません。測定対象も発火条件も異なるため、数値がずれるのは正常です。一致させようとせず、それぞれの得意な問いに使い分けてください。
AI検索からの人間流入はGA4で正確に測れますか。 完全には測れません。AI検索経由の流入はリファラーが付かない、または独自の表記になることがあり、参照元が「不明」に落ちがちです。GA4の参照元だけに頼らず、複数の手がかりで裏取りしてください。