GA4がbotで
汚染される仕組み
オウンドメディアやコーポレートサイトに記事を追加した直後、GA4（Googleアナリティクス4）の「アクティブユーザー」や「新規ユーザー数」のグラフが、普段の数倍から数十倍に跳ね上がる ── こうした場面に出会うサイト運営者は少なくありません。流入のほとんどが「Direct」で、地域は海外に偏り、滞在時間はほぼゼロ。明らかに普段の読者層とは違う動きです。
これは、ホスティング環境の不具合でも、GA4側の障害でもありません。記事の公開をきっかけに世界中のbotがアクセスし、そのうちJavaScriptを実行するものがGA4の計測タグを発火させ、ユーザーとして数えられている状態です。本記事では、この現象を見分ける方法、なぜ起きるのかという本質的な原因、そしてアクセスは止めずに計測からだけbotを外す多層の対策を整理します。
- 記事公開後の急増の正体は、JavaScriptを実行するbot（AIクローラーやスクレイパー）が計測タグを発火させていること
- ホスティングは無関係。GA4・GTMをJavaScriptで動かしている限り、どの環境でも同じように起きる
- 対策は「アクセスは許可し、計測からだけ外す」。サーバー・エッジでbotに計測タグを配信しないのが中心になる
01.記事公開後にGA4の数値が急に跳ねる現象
症状はおおむね共通しています。コンテンツを追加したタイミングからユーザー数が階段状に増え、グラフが普段とはかけ離れた高さで推移します。リアルタイムレポートを開くと、見覚えのない国からのアクセスが並び、心当たりのある施策とは無関係に数字だけが膨らんでいきます。
この急増分は、人間の読者ではありません。bot ── 人間ではなくプログラムが自動でWebサイトにアクセスする仕組み ── による流入です。クローラー（Webページを自動で巡回・取得するプログラム）やスクレイパー（Webページの情報を自動で収集するプログラム）が、公開されたばかりのページを取得しに来ています。
厄介なのは、こうしたbotが「サイトには来てほしい」存在と「計測には数えたくない」存在の両方を含むことです。検索エンジンやAIに記事を見つけてもらうにはクローラーのアクセスが欠かせません。一方で、それらをサイトの訪問者として数えてしまうと、コンバージョン率も、チャネル別の評価も、記事ごとの成果も、すべて実態からずれてしまいます。問題は「botが来たこと」ではなく「botを計測してしまっていること」に切り分けられます。
02.汚染されているかを見分ける
自社のGA4がbot流入を含んでいるかどうかは、いくつかの特徴的なサインで判断できます。1つだけなら偶然のこともありますが、複数が同時に当てはまる場合は、bot流入を強く疑います。
| GA4で見られる症状 | bot流入時に起きやすい理由 |
|---|---|
| 「新規ユーザー」が「全ユーザー」とほぼ同数で、リピーターがほとんどいない | botは識別用のID（cookieに保存される）を次の訪問へ持ち越さないため、アクセスのたびに新規ユーザーとして数えられる |
| チャネルが「Direct（参照元なし）」に極端に偏る | botはリファラー（流入元のページ情報）も広告パラメータも持たずにURLへ直接アクセスするため、流入元なしと判定される |
| 地域が自社の想定とずれ、海外（特に米国）に偏る | botの多くはデータセンターから動き、その所在地が米国などに集中している |
| 平均エンゲージメント時間が極端に短い | botはスクロールも回遊もせず、ページを取得してすぐ離れる |
| 公開・更新の直後にユーザー数が跳ね、しばらく高止まりする | コンテンツの追加がクロールのきっかけになり、複数のクローラーが相次いでアクセスする |
GA4の画面では、次の手順で確認します。いずれも標準のレポートだけで確認でき、特別な設定は要りません。
- ✓ 「集客」→「トラフィック獲得」で、Directチャネルの比率が不自然に高くないかを見る
- ✓ 「ユーザー属性」→「地域」で、自社の対象地域と一致しているかを見る
- ✓ 「ユーザー」系の指標で、新規ユーザー数と全ユーザー数の差を見る（差が小さいほどリピーターが少ない）
- ✓ 「平均エンゲージメント時間」が、コンテンツの分量に対して短すぎないかを見る
- ✓ 急増が始まった日付を、自社のコンテンツ公開・更新の履歴と突き合わせる
海外向けのサイトであれば海外比率が高いのは自然ですし、広告流入が多ければDirect以外の比率も変わります。重要なのは、複数のサインが同時に、しかもコンテンツ公開のタイミングと連動して現れているかどうかです。「ほぼ全員が新規」「Directが大半」「海外偏重」「滞在ほぼゼロ」「公開と同期した急増」が重なったとき、bot流入の可能性が高いと判断します。
03.本質的な原因 ── GA4は何を「ユーザー」と数えるか
bot流入がGA4に現れる理由は、突き詰めると1つの仕組みに行き着きます。GA4は「自分の計測用JavaScriptを実行したクライアント」をユーザーとして数える、という点です。
botは、人間ではなくプログラムが自動でWebサイトにアクセスする仕組みの総称です。検索エンジンのクローラー、AIの学習・検索用クローラー、データ収集用のスクレイパー、監視ツールなどが含まれます。本記事では、特にJavaScriptを実行し、GA4の計測対象になってしまうbotを中心に扱います。
GA4は通常、gtag.jsやGTM（Google Tag Manager、タグ管理ツール）を通じてページ内で動くJavaScriptとして計測タグを読み込みます。このタグが実行され、計測データ（ヒット）が送られてくれば、GA4はそのクライアントをユーザー・セッションとして記録します。送信元が人間かどうかを根本的に見分ける仕組みは、GA4には備わっていません。
GA4が用意している唯一の標準的な防御が、「既知のボットによるトラフィックの除外」です。これはGoogleの判定と、IAB（Interactive Advertising Bureau、デジタル広告の業界団体）が管理する既知botのリストにもとづいて、リストに載っているbotを自動的に除外する仕組みです。Webデータストリームでは標準で有効になっています。
ただし、このIAB/ABC International Spiders and Bots Listは、登録されたbotのUser-Agent（ブラウザやbotが名乗る識別文字列）をもとにした既知リストです。リストの更新は新しいbotの登場に追いつかないことが多く、近年急増したタイプの多くは、まだリストに含まれていません。つまり、GA4の標準除外は「昔から知られているbot」には効きますが、「新顔のbot」は素通りさせてしまいます。
そして決定的なのが、現代のbotがJavaScriptを実行するという変化です。かつてのクローラーの多くはHTMLを取得するだけで、JavaScriptは実行しませんでした。JavaScriptを動かさないbotは、そもそもGA4の計測タグを発火させないため、GA4には現れませんでした。いまは事情が変わっています。
| botの種類 | JavaScriptの実行 | GA4への影響 |
|---|---|---|
| 旧来のHTTPクローラー・単純なスクレイパー | 実行しないことが多い | GA4には基本的に現れない（サーバーログには残る） |
| AIの学習・検索インデックス用クローラー | 実行するものが増えている | 実行する場合はユーザーとして計上されうる |
| AIアシスタント経由の取得（利用者の操作を起点としたページ取得） | ブラウザに近い挙動をしやすい | ユーザーとして計上されやすい |
| ヘッドレスブラウザ製のスクレイパー・自動化ツール | 実行する（中身は本物のブラウザ） | ほぼ確実にユーザーとして計上される |
| 監視・プレビュー用のbot | ものによる | 実行すれば計上される |
ヘッドレスブラウザ（画面表示を持たないブラウザ。プログラムから操作できる）を使ったスクレイパーは、中身が本物のブラウザそのものなので、GA4を含むすべてのJavaScriptを実行します。注意したいのは、AIクローラーといっても挙動は一様ではない点です。GPTBotやClaudeBot、Google-Extended、CCBotといった主要な生成AIの学習用クローラーの多くは、いまのところHTMLを取得するだけのHTTP専用で、GA4には直接は現れにくいのが実情です。GA4に実際に現れている自動アクセスの主体は、ヘッドレスブラウザ製のスクレイパーや、AIアシスタントが利用者の操作を起点にページを取りに来るリアルタイム取得です。ここで重要なのは、理屈の上での話ではなく、GA4に現れている時点でそのアクセスはJavaScriptを実行している、という事実です。
まとめると、原因は次の重なりです。GA4は計測タグを実行したクライアントを無条件にユーザーとして数える。標準のbot除外は既知リスト頼みで、新しいbotを取りこぼす。そして、その新しいbotはJavaScriptを実行する。「自分のJavaScriptを実行したクライアント＝人間の訪問者」という前提が、JavaScriptを実行するbotの増加で成り立たなくなった ── これが本質です。ホスティング環境は一切関係しません。
クローラーとは？Googlebot・AIクローラー・robots.txtの関係を解説
クローラーの意味、GooglebotとAIクローラーの違い、robots.txtでできること・できないこと、llms.txtとの関係を実務向けに解説しています。
04.なぜ今、AIクローラーで急増しているのか
bot自体は以前から存在しました。それでも近年になって、コンテンツ公開のたびにGA4が目立って汚れるようになったのは、AI検索やAIアシスタントの広がりに伴って、JavaScriptを実行できるクローラーが大きく増えたためです。生成AIに学習させるため、あるいはAIの回答に最新情報を反映させるための巡回が、ここ1〜2年で急速に増えました。
記事の公開は、こうしたクローラーにとって発見のきっかけになります。サイトマップの更新、llms.txtの記載、被リンク、フィードなど、新しいコンテンツの存在を知らせる経路は複数あります。技術的にきちんと整えられたサイトほど、新しい記事は速やかに見つけられ、そのぶん多くのクローラーが相次いでアクセスします。
LLMO・GEO・AIO（生成AI検索で引用・言及されることを目指す最適化の総称）に取り組むと、llms.txtを設置し、robots.txtでAIクローラーを許可し、サイトを高速化し、構造化データを整えます。これらはすべて、AIクローラーに見つけてもらいやすくする施策です。つまり、AI検索向けの最適化を真面目に進めるほど、AIクローラーの訪問は増え、計測層を分けていなければGA4はそのぶん汚れます。最適化の成果が、そのままデータの汚れとして現れる構図です。
この構図を踏まえると、対策の方向性が定まります。AIクローラーのアクセスは、LLMO・GEOの成果につながる「歓迎すべきもの」です。減らすべきではありません。減らすべきは、そのアクセスがGA4の数値に混ざることだけです。AI検索最適化とSEOの関係、そこでの効果測定の考え方は、別の記事でも整理しています。
GEO・LLMO・AIOの違いとは？AI検索最適化とSEOの関係を整理
GEO・LLMO・AIOはSEOの置き換えではありません。AI検索で引用・言及されるための考え方、SEOとの関係、効果測定の仕方を整理しています。
05.混同しやすい別の問題
GA4の数値が実態とずれる現象には、見た目が似ていても原因の異なるものがいくつかあります。対策を誤らないために、本記事が扱う「JavaScriptを実行するbotの流入」と区別しておきます。
| 問題 | 起きていること | 本記事の対策の対象 |
|---|---|---|
| JavaScriptを実行するbotの流入（本記事の主題） | botがページを開き、計測タグを発火させてユーザーとして計上される | 対象 |
| 測定プロトコルのゴーストスパム | サイトを訪れずに、GA4のデータ受信エンドポイントへ偽のヒットを直接送りつける | 対象外（別の対処が必要） |
| サーバーログ集計の過剰計上 | アクセスログを数える集計では、JavaScriptを実行しないbotまで含めて数えてしまう | 対象外（逆方向の問題） |
測定プロトコル（Measurement Protocol、サーバー間でGA4へ直接データを送る仕組み）を悪用したゴーストスパムは、サイトに一切アクセスせず、GA4の受信先へ偽のデータを送りつける手口です。これはページ上のJavaScriptとは無関係なので、サイト側でタグを出し分けても止まりません。ただしGA4では、測定プロトコルでの送信に専用のキー（APIシークレット）が必要なため、かつてのUniversal Analyticsのような無差別なゴーストスパムは起こりにくくなっています。
逆に、サーバーのアクセスログを数えるタイプの集計は、JavaScriptを実行しないbotまで含めてすべて数えるため、GA4とは反対に過大な数字になりがちです。GA4の数値とサーバーログの数値が大きく食い違うのは、両者が「何を1アクセスと数えるか」が異なるためで、異常ではありません。
本記事が扱うのは、あくまで先に挙げた「JavaScriptを実行するbotがGA4の計測タグを発火させてしまう」問題です。記事公開と連動した急増は、ほとんどがこのタイプに当てはまります。
2026年5月13日、GA4のデフォルトチャネルグループに「AIアシスタント（AI Assistant）」が追加されました。ChatGPT・Gemini・ClaudeといったAIアシスタントのリファラー（流入元情報）を持つ流入を自動で判定し、メディアに「ai-assistant」、キャンペーンに「(ai-assistant)」を割り当てて、専用チャネルにまとめる仕組みです。これまでリファラルやDirectに分散していたAI経由の流入を、Google自身が計測区分として切り出した動きと言えます。
ただし、ここで分類されるのは「AIアシスタントのリンクをたどって訪れた“人間”」であり、本記事が扱うbot流入とは別物です。AIクローラーやスクレイパーはAIアシスタントのリファラーを名乗らないため、この新チャネルには入らず、引き続きDirectなどに計上されます。新チャネルはbot汚染を解決しません。むしろ「AIアシスタント」チャネルの流入は実在の人間なので、bot流入と混同して計測から外さないよう注意します。また、リファラーを持たないAI流入（アプリ内ブラウザやリンクのコピー＆ペーストなど）は従来どおりDirectに入ります。つまりDirectには、依然としてbotとリファラーなしの人間流入が混在します。
06.対策の考え方 ── アクセス層と計測層を分ける
具体的な実装に入る前に、対策全体を貫く考え方を整理します。キーとなるのは、Webサイトには「アクセス層」と「計測層」という別々のレイヤーがあり、botに対する扱いを両者で変えてよい、という発想です。
| レイヤー | 扱う対象 | botに対する望ましい方針 |
|---|---|---|
| アクセス層（robots.txt、CDN・サーバーのアクセス制御、HTMLの配信） | 誰がページのコンテンツを読めるか | 検索エンジンやAIのクローラーには読ませる（SEO・LLMOのため） |
| 計測層（GA4・GTMなどの計測タグ） | 誰を訪問者として数えるか | botは数えない（人間のアクセスだけを計測する） |
「ページを読ませること」と「訪問者として数えること」は、本来まったく別の判断です。これまでGA4が汚れていたのは、計測タグをすべての訪問者へ一律に配信し、この2つを同じ扱いにしていたためです。アクセス層では歓迎し、計測層では除外する ── この切り分けができれば、LLMO・GEOの成果を損なわずにGA4をきれいにできます。
GA4の数値を整えたいからといって、robots.txtやエッジの設定でAIクローラーを締め出すのは避けます。生成AI検索やAIアシスタントに自社コンテンツを参照してもらうには、クローラーがページを読める状態が前提です。クロールを止めれば計測は静かになりますが、同時にLLMO・GEOの成果も失われます。止めるべきは計測であって、アクセスではありません。
robots.txtはアクセス層の道具であり、計測層の問題を解決するものではありません。robots.txtの役割と限界については、別の記事で詳しく整理しています。
llms.txtとは？AIクローラー向けファイルの必要性と実装方法
llms.txtの役割、robots.txtやsitemap.xmlとの違い、AI検索時代に導入するメリットと限界、実装テンプレート、AIクローラーの許可設定までを実務向けに解説しています。
07.多層で考えるbot除外の実装
計測層からbotを外す対策は、1つの設定で完結するものではなく、複数の層を組み合わせて精度を上げます。それぞれの層の役割と限界を整理します。
| 対策の層 | やること | 効果と限界 |
|---|---|---|
| GA4の標準設定 | 「既知のボットによるトラフィックの除外」が有効であることを確認する | 既知リストのbotは除外されるが、新しいbotは取りこぼす |
| サーバー・エッジでの出し分け | リクエストがbotかを判定し、botには計測タグを配信しない | 本記事の中心。自ら名乗るクローラーを広く除外でき、実装も一度で済む |
| エッジのbot対策機能 | CDNやWAFのbot対策で、User-Agentを偽装する不正なbotを抑える | 偽装botに有効。ただしAIクローラーまで止めない設定が前提 |
| レポート側の運用 | セグメントや探索でbotらしい流入を除外し、過去データには注釈を残す | 過去データは消せないが、読み解きの精度を保てる |
第1層：GA4の標準のbot除外を確認する
まず、GA4の「既知のボットによるトラフィックの除外」が有効であることを確認します。Webデータストリームでは標準で有効ですが、前提として押さえておきます。これは必要な土台ですが、先に述べたとおり既知リスト頼みのため、これだけでは新しいAIクローラーやスクレイパーを取りこぼします。次の層が要になります。
第2層：サーバー・エッジで計測タグを出し分ける（中心）
最も効果が大きく、実装も一度で済むのが、サーバー側またはエッジ（CDNなど、利用者に近い場所でリクエストを処理する層）で、リクエストがbotかどうかを判定し、botには計測タグ自体を配信しない、という方法です。記事本文のHTMLは従来どおりすべてのクライアントへ返すので、クロールは妨げません。配信しなくなるのはGA4・GTMの計測タグだけです。
// サーバー / エッジでの擬似コード
const isBot = detectBot(request.headers["user-agent"]);
// 記事本文のHTMLは、botにも人間にも同じものを返す（クロールは妨げない）
const body = renderArticleHtml(request);
// GA4 / GTM の計測タグは、人間のリクエストにだけ挿入する
const html = isBot ? body : body + ANALYTICS_TAG;botの判定は、リクエストのUser-Agentをもとに行うのが基本です。AIクローラーやSEOツール、スクレイパーの多くは自らbotであることを名乗るUser-Agentを送るため、これらは判定で広く捕捉できます。User-Agentによるbot判定は、保守されているオープンソースのライブラリを使うと、新種のbotにも追随しやすくなります。User-Agentをまったく送らないリクエストも、通常のブラウザではないものとして扱います。
この出し分けは、特定のホスティングに固有の手法ではありません。SSR（サーバーサイドレンダリング）フレームワークのミドルウェア、CDNやエッジで動かすスクリプト、WordPressならテーマやプラグイン、リバースプロキシなど、サーバー側でリクエストを受け取って応答を組み立てられる場所であれば、どこでも同じ考え方で実装できます。
GA4をGTM経由で動かしている場合でも、対応は同じです。GTMのタグはコンテナが読み込まれて初めて発火します。サーバー側でbotにGTMスニペットを配信しなければ、コンテナが起動せず、その中のGA4タグも発火しません。GTMの管理画面でトリガーの除外条件を細かく組むより、スニペットの配信段階で出し分けるほうが確実で、保守も簡単です。
なお、GTM側のタグ・トリガー・変数の設定そのものも、管理画面だけでなくAPIでコード管理できます。
GTMをAPIで操作する｜Tag Manager API v2で変数・トリガー・タグを設定する方法
GTMの変数・トリガー・タグをTag Manager API v2でコードから作成・更新する方法をまとめています。サービスアカウントの権限設定から、Claude CodeなどのAIエージェントにGTM設定を頼める構成まで扱います。
ただし、この層には弱点があります。GA4汚染の主因であるヘッドレスブラウザ製のスクレイパーは、先述のとおり、ブラウザのふりをするUser-Agentを名乗ります。User-Agentだけで判定すると、これらは人間として素通りしてしまいます。サーバー側の判定だけを入れても数値が改善しないのは、このためです。そこで、サーバー側の出し分けに加えて、ページ側のJavaScriptで自動化ブラウザかどうかを確かめる判定を重ねます。
スクレイパーや自動化ツールの多くは、WebDriver（Selenium・Puppeteer・Playwrightなど、ブラウザをプログラムから操作する仕組み）でブラウザを動かします。WebDriverで制御されたブラウザは、標準のプロパティnavigator.webdriverがtrueになります。計測タグを起動する前にこの値を確認し、trueならGA4・GTMを発火させなければ、User-Agentを詐称してサーバー側の判定を素通りしたヘッドレスブラウザの多くを、計測から外せます。サーバー側のUser-Agent判定（名乗るbotを広く捕捉）と、クライアント側のWebDriver判定（UAを詐称する自動化ブラウザを捕捉）は、取りこぼす相手が異なるため組み合わせて精度を上げられます。ただしこの値も偽装され得るため、サーバー側の判定を置き換えるものではなく、あくまで補強策として併用します。
第3層：エッジのbot対策で偽装botに備える
User-Agentによる判定の弱点は、ブラウザのふりをするUser-Agentを名乗る偽装botを見抜けないことです。こうした手の込んだbotが無視できない規模で来る場合は、CDNやWAF（Webアプリケーションファイアウォール）が備えるbot対策機能を併用します。多くのサービスは、リクエストの特徴から「自動化されている度合い」を推定する仕組みを持っており、その判定をサーバー側の出し分けに使えます。
ここで注意したいのは、エッジのbot対策はあくまで偽装botへの備えであり、検索エンジンやAIのクローラーまで止める設定にはしないことです。エッジで一律にbotを遮断すると、第6章で触れたとおりLLMO・GEOの成果を損ないます。エッジ機能は「計測から外すための判定材料」として使い、「アクセスを遮断する道具」としては慎重に扱います。
第4層：レポート側で過去データと向き合う
すでに取り込まれてしまったデータは、さかのぼって消すことが基本的にできません。現実的な対応は2つあります。1つは、汚染が始まった時期と、出し分けの対策を適用した時期を、レポートに注釈（アノテーション）として残し、グラフを後から見たときに解釈を誤らないようにすることです。もう1つは、探索レポートやセグメントで、bot流入の特徴に当てはまるデータを除外して見ることです。
より長期の傾向や、検索からの流入の質を正確に追いたい場合は、GA4単体に頼らず、検索パフォーマンスのデータと組み合わせた分析基盤を持つと安定します。データの取り扱いを設計する手順は、別の記事で具体的に整理しています。
Search Console × BigQuery × Looker StudioでSEO分析基盤を作る手順
Search Console UIの制約を超えてロングテール検索クエリと長期トレンドを扱うために、BigQueryへ蓄積しLooker Studioで可視化する構成を、設定からコスト管理まで整理しています。
- ✓ GA4の「既知のボットによるトラフィックの除外」が有効になっている
- ✓ サーバーまたはエッジで、リクエストのbot判定を行っている
- ✓ botと判定したリクエストには、GA4・GTMの計測タグを配信していない
- ✓ 記事本文のHTMLは、botにも従来どおり全文配信している（クロールを妨げていない）
- ✓ robots.txtやエッジ設定で、AIクローラーを誤って遮断していない
- ✓ 汚染期間と対策適用日を、GA4のレポートに注釈として記録した
GA4の数値が信用できない状態を、設計から立て直しませんか？
TANTOUでは、bot流入の診断、サーバー・エッジでの計測の出し分け、レポート設計まで、AI検索時代に合った効果計測の整備を支援します。
08.よくある質問（FAQ）
GA4の「既知のボットを除外」をオンにしていれば大丈夫ですか？
それだけでは不十分です。GA4の標準のbot除外は、IAB（Interactive Advertising Bureau）が管理する既知botのリストとGoogleの判定にもとづきます。AIクローラーやヘッドレスブラウザ製のスクレイパーなど、近年増えたタイプの多くはこのリストに含まれず、除外されずに計上されます。サーバー・エッジで計測タグを出し分ける対策と組み合わせる必要があります。
AIクローラーをブロックすればGA4はきれいになりますか？
ブロックすればGA4の数値は改善しますが、おすすめしません。AIクローラーを締め出すと、生成AI検索やAIアシスタントで自社コンテンツが参照されにくくなり、LLMO・GEOの観点で不利になります。目指すのは「クロールはさせるが、計測はしない」という状態です。アクセスの可否と計測の対象は、別のものとして切り分けて考えます。
過去に汚染されてしまったGA4のデータは元に戻せますか？
取り込み済みのデータをさかのぼって消すことは基本的にできません。現実的な対応は2つあります。1つは、汚染が始まった時期と対策を適用した時期をレポートに注釈として残し、グラフの解釈を誤らないようにすること。もう1つは、探索レポートやセグメントで、bot流入の特徴に当てはまるデータを除外して見ることです。
これはCloudflareなど特定のホスティングで起きる問題ですか？
いいえ。ホスティングは関係ありません。WordPress、Vercel、Netlify、自前サーバーなど、どこにサイトを置いていても、JavaScriptで動くGA4・GTMの計測タグを使っていれば同じことが起きます。原因は計測の仕組みの側にあり、特定の環境に固有の不具合ではありません。
自社サイトがbotで汚染されているか、まず何を見ればよいですか？
GA4の「集客」→「トラフィック獲得」でDirectチャネルの比率、「ユーザー属性」→「地域」で地域の偏り、新規ユーザーと全ユーザーの比、平均エンゲージメント時間を確認します。Directが極端に多く、海外比率が高く、ほぼ全員が新規で、エンゲージメント時間がほぼゼロなら、bot流入の可能性が高いと判断できます。急増の開始日をコンテンツ公開の履歴と突き合わせると、さらに確度が上がります。
2026年5月にGA4へ追加された「AIアシスタント」チャネルで、bot汚染は解決しますか？
解決しません。「AIアシスタント」チャネルは、ChatGPT・Gemini・ClaudeなどのAIアシスタントのリファラーを持つ“人間”の流入を分類する機能で、本記事が扱うbot流入とは別物です。AIクローラーやスクレイパーはAIアシスタントのリファラーを送らないため、このチャネルには分類されず、引き続きDirectなどに計上されます。bot汚染への対策は、サーバー・エッジでの計測タグの出し分けが中心であることに変わりはありません。なお「AIアシスタント」チャネルの流入は実在の訪問者なので、botと混同して計測から除外しないよう注意します。
09.まとめ
記事公開後にGA4の数値が急に跳ねるのは、JavaScriptを実行するbot ── AIクローラーやスクレイパー ── が計測タグを発火させ、ユーザーとして数えられているためです。GA4は計測タグを実行したクライアントを無条件に数え、標準のbot除外は既知リスト頼みで新顔を取りこぼします。原因は計測の仕組みの側にあり、ホスティング環境は関係しません。
対策の軸は、アクセス層と計測層を分けることです。検索エンジンやAIのクローラーにはコンテンツを読ませ、計測からだけ外します。具体的には、GA4の標準除外を土台にしつつ、サーバー・エッジでbotに計測タグを配信しない出し分けを中心に据え、必要に応じてエッジのbot対策とレポート運用を重ねます。AIクローラーのアクセスはLLMO・GEOの成果につながるものなので、止めるべきは計測であって、アクセスではありません。この切り分けができれば、AI検索時代でも信頼できる数値でサイトを評価できます。
