ある日GA4を開いたら、セッション数がいきなり跳ね上がっている。新しい記事を出したわけでもないし、SNSでバズった気配もない。「え、もしかして攻撃されてる？」と一瞬ヒヤッとするあの感じ、Webサイトを運営している人なら一度は経験があるのではないでしょうか。
結論から言うと、Googleアナリティクス（GA4）で「怪しいアクセス」を判別することはある程度できます。ただし、GA4は攻撃検知ツールではないので、見えるものと見えないものがハッキリ分かれます。今回はその線引きと、実際にどこを見れば判別できるのかを整理していきます。
そもそもGA4に「攻撃」は記録されるのか
まず最初に押さえておきたいのが、GA4に記録されるのは「計測タグ（gtag.jsやGoogleタグマネージャー）が実行されたアクセス」か「Measurement Protocolで直接送り込まれたデータ」のどちらかだけ、という点です。つまり通常のWebタグによる計測では、JavaScriptを実行しないアクセスはGA4のレポートに出てきません（サーバー側からMeasurement Protocolでイベントを送っている場合は別です）。
ここが勘違いされやすいポイントで、たとえばログイン画面への総当たり攻撃や、サーバーに大量のリクエストを送りつけるDDoS攻撃、脆弱性を探すスキャンなどは、多くの場合HTMLを取得するだけでJavaScriptを実行しません。なのでGA4上では「何も起きていない」ように見えてしまいます。逆に言えば、GA4が平穏でもサーバーが攻撃を受けている可能性はゼロではないということです。
GA4で見えるのは「ボット」と「スパム」
では、GA4で何が見えるのかというと、主に次の2種類です。ひとつはヘッドレスブラウザなどでJavaScriptまで実行してくるボット。もうひとつはMeasurement Protocolを使い、サイトを訪問せずに計測データだけを直接送りつけてくる、いわゆるゴーストスパムです。
前者は実際にサーバーへアクセスしていますが、後者はサーバーには一切来ていません。GA4の数字だけが汚されるタイプで、サイトそのものへの実害はほぼありません。この2つを見分けるだけでも、「サーバー側の対策が必要なのか」「レポートの掃除だけで済むのか」の判断がかなりラクになります。
GA4が自動でやってくれていること
GA4には、既知のボットやスパイダーのトラフィックを自動で除外する仕組みが最初から入っています。Googleの公式ヘルプによると、この判定はGoogle独自の調査と、IAB（Interactive Advertising Bureau）が管理する「International Spiders and Bots List」を組み合わせて行われているそうです。
ただ、この機能には注意点がふたつあります。ひとつは、オフにすることも、除外された量を確認することもできないこと。もうひとつは、あくまで「既知の」ボットが対象だということです。自分は普通のブラウザですよと名乗ってくるボットや、新しく出てきたボットはすり抜けてきます。なので「GA4が自動で除外しているから安心」とは言い切れず、レポートに残ってしまった分は自分で見つけるしかありません。
怪しいアクセスを見分けるチェックポイント
ここからが本題です。レポートに残ってしまったボットやスパムには、人間のアクセスとは明らかに違う「クセ」があります。ただし、どれも「疑うきっかけ」であって、ひとつの指標だけでボットと断定はできません。複数の特徴が重なっているかどうかを見て、怪しさの度合いを判断していくのがコツです。
エンゲージメント率と平均エンゲージメント時間
一番わかりやすいのがここです。ボットやスパムは、ページを読んだりスクロールしたりしないことが多いので、エンゲージメント率が限りなく0%に近く、平均エンゲージメント時間も0秒付近に偏りがちです。普段のサイト平均と比べて極端に低い参照元や国があれば、まずそこを調べてみてください。
レポートの「集客」→「トラフィック獲得」で、セッションの参照元/メディアごとにエンゲージメント率を並べてみるのが手っ取り早いです。ただし、すぐに離脱した正規のユーザーや、計測タグがうまく動いていないアクセスでも同じような数字になります。逆に、滞在しているように見せかけるボットもいるので、エンゲージメントの数字は参照元やランディングページ、ホスト名と組み合わせて判断しましょう。
ホスト名が自分のドメインではない
ゴーストスパムを疑うときに役立つのがホスト名のチェックです。正規のアクセスであれば、ホスト名は基本的に自分のサイトのドメインになります。一方でMeasurement Protocolで外部から送り込まれたデータは、ホスト名が空になっていたり、まったく関係ないドメインになっていたりすることがあります。
探索（データ探索）の自由形式で、ディメンションに「ホスト名」を追加して一覧にしてみてください。自分のサイトと無関係なドメインや「(not set)」が目立つ場合は、ゴーストスパムか計測設定の問題を疑うサインです。ただ、ステージング環境やローカル環境、計測設定のミスでも同じように見えるので、ホスト名だけで原因は確定できません。まず自分のサイトで使っている正規のホスト名を洗い出し、ほかのディメンションやアクセスログと照らし合わせてみましょう。
地域・ブラウザ・画面解像度の偏り
日本語のサイトなのに、特定の国や都市からのアクセスだけが急増している。しかも全部同じブラウザのバージョンで、画面解像度も同じ。こういう不自然な「揃いすぎ」もボットによくあるサインです。人間のアクセスは普通もっとバラバラになりますからね。とはいえ、海外のユーザーや特定の端末からの正規アクセスということもあるので、これも調べるきっかけのひとつとして扱いましょう。
ほかにも、参照元が「direct」なのにランディングページがトップではなく深い階層ばかり、特定の時間帯だけ毎日きっちり増える、といったパターンも怪しいです。単体では判断しにくくても、エンゲージメントの低さと組み合わせると一気に輪郭が見えてきます。
探索レポートでまとめて確認する
これらを毎回レポートを行き来して見るのは面倒なので、探索の自由形式でひとつの表にまとめておくのがおすすめです。ディメンションに「ホスト名」「国」「市区町村」「ブラウザ」「画面の解像度」「セッションの参照元/メディア」、指標に「セッション」「エンゲージメント率」「平均エンゲージメント時間」を入れておけば、異常値が出たときにすぐ絞り込めます。
一度作っておけば使い回せるので、アクセスが跳ねたときの「とりあえずこれを見る」用の探索として保存しておくと安心です。
見つけた怪しいアクセスへの対処法
判別できたら、次は対処です。ただしGA4の機能でできるのは「レポートからどう扱うか」まで。アクセスそのものを止める機能ではないので、そこは割り切って考える必要があります。
「除外する参照のリスト」はブロック機能ではない
よく誤解されているのが、データストリームの設定にある「除外する参照のリスト」です。名前からするとスパムをブロックしてくれそうですが、実際は条件に一致したイベントにignore_referrer=trueを付与して、参照元として扱わないようにするだけの機能です。
本来は決済代行サービスなど、外部ドメインを経由して戻ってくるユーザーの流入元が上書きされないようにするためのもの。データストリームごとに最大50個まで設定できますが、スパムのデータ自体は記録され続け、参照元から消えた分がほかの扱いになるだけです。スパム対策としての効果は限定的だと覚えておきましょう。
データフィルタで今後のデータから除外する
GA4の「データフィルタ」では、内部トラフィックやデベロッパートラフィックに加えて、ウェブホスト名を条件にしたトラフィックの除外も設定できるようになっています。不要なホスト名を指定して受信データから除外できるので、ゴーストスパム対策として有効な手段です。
ただし、条件の組み方には注意が必要です。「自分のドメイン以外は全部いらない」という考え方だけで作ると、正規のサブドメインや決済後の戻り先、計測に使っている別のホストまで巻き込んでしまうおそれがあります。まずは実際に使っているホスト名をすべて洗い出し、除外する対象をはっきりさせてから設定しましょう。
もうひとつの注意点は、フィルタが適用されるのは設定した後に入ってくるデータだけで、過去のデータは変わらないこと。そして「有効」にすると、除外されたデータは後から戻せないことです。なので、まずは「テスト」状態で作成し、24〜36時間ほど様子を見て、正規のアクセスが巻き込まれていないことを確認してから有効にする流れが安全です。
Measurement ProtocolのAPIシークレットを確認する
GA4のMeasurement Protocolでは、Webデータストリームの測定IDに加えて、データストリームごとに発行される「APIシークレット」などを使ってイベントを送信します。APIシークレットは不正な送信を防ぐための大事な認証情報ですが、漏れてしまえば第三者でも不正なデータを送れてしまいます。また、送ってきた相手が本当にサイトの訪問者かどうかまで保証してくれるものではありません。
なお、測定IDはサイトのソースコードに書かれているので、隠すことはできません。大事なのはAPIシークレットの管理のほうです。GitHubの公開リポジトリやフロントエンドのコードにうっかり書いてしまっていないか確認し、使っていないシークレットは削除しましょう。漏洩が疑われる場合は、新しいシークレットを発行するだけでなく、古いシークレットを必ず削除して無効にしておくことが重要です。
過去のデータは「比較」と「セグメント」で切り分ける
すでに混ざってしまった過去のデータは、フィルタでは消せません。なので、レポートの「比較」機能や探索のセグメントを使って、怪しい条件（特定の国、ホスト名、エンゲージメント0秒など）を除いた数字を別に出して確認するのが現実的です。毎月のレポートを作る立場の方は、補正した数字と補正条件をメモしておくと後から困りません。
本当に攻撃が疑わしいならサーバー側を見る
GA4はあくまでマーケティングのための分析ツールです。「GA4上で怪しいアクセスが見つかった」は「攻撃を受けているかもしれない」というヒントにはなりますが、攻撃の有無や中身を確定させるものではありません。
本気で攻撃を疑うなら、サーバーのアクセスログを確認するのが一番確実です。IPアドレスやユーザーエージェント、アクセスされたURL、レスポンスのステータスコードなどが記録されるので、GA4では見えないJavaScriptを実行しないアクセスも確認できます。ただし、CDNやWAFの段階で処理されたリクエストはサーバーのログに残らないなど、見える範囲はログの設定や構成次第です。レンタルサーバーやCDNの管理画面にWAFやボット対策の機能があれば、そちらのログも合わせて確認しましょう。
切り分けの目安としては、GA4の数字が急に増えているのにサーバーログやCDNのリクエスト数に変化が無ければゴーストスパムの可能性、サーバーログでも特定のURLへのアクセスが増えていれば実際のリクエストを伴うボットアクセスの可能性、と考えられます。ただし、ゴーストスパムとボットアクセスが同時に起きていることもあるので、ログの取得範囲も確認しつつ、複数の情報を照らし合わせて判断しましょう。
まとめ
GA4で第三者攻撃を判別できるか、という問いに対する答えは「ボットやスパムっぽいアクセスの判別はできるけど、攻撃そのものの検知はできない」になります。通常のタグ計測ではJavaScriptを実行しないアクセスは記録されないので、GA4だけを見て「攻撃は無かった」と判断するのは危険です。
判別のコツは、エンゲージメント率と平均エンゲージメント時間、ホスト名、地域やブラウザの偏りといった複数のサインを重ねて見ることです。どれかひとつで断定はできませんが、探索で一覧を作っておくだけでも、異変に気づいたときの調べやすさがまったく違います。
対処としては、正規のホスト名を洗い出したうえでデータフィルタのウェブホスト名除外をテストしてから有効にする、Measurement ProtocolのAPIシークレットを整理して漏洩が疑われるものは無効にする、過去分は比較やセグメントで切り分ける、の3つを押さえておけば十分だと思います。「除外する参照のリスト」はブロック機能ではない点だけはお忘れなく。
そして本当に攻撃が疑わしいときは、迷わずサーバーのアクセスログとWAFを確認しましょう。GA4は「異変に気づくためのセンサー」、サーバーログは「何が起きたかを確定させるための証拠」。この役割分担を意識しておくと、アクセスが急に跳ねても慌てずに済みますよ。
【参考文献】
- 既知の bot トラフィックの除外 – アナリティクス ヘルプ https://support.google.com/analytics/answer/9888366?hl=ja
- 除外する参照を指定する – アナリティクス ヘルプ https://support.google.com/analytics/answer/10327750?hl=ja
- Google アナリティクスでウェブホスト名のトラフィックを除外する – アナリティクス ヘルプ https://support.google.com/analytics/answer/16608575?hl=ja
- Measurement Protocol（Google アナリティクス 4） | Google for Developers https://developers.google.com/analytics/devguides/collection/protocol/ga4?hl=ja
- Measurement Protocol でイベントを送信する | Google for Developers https://developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events?hl=ja
- Spam traffic in GA4: How to detect, filter & prevent it – Search Engine Land https://searchengineland.com/guide/spam-traffic
