GA4に存在しないURLが記録された。サーバーログから見えたWebサイトの裏側

2026年10月18日、markeTransの自社サイトで、少し奇妙なアクセスがGA4（Google Analytics 4）に記録されていました。アクセス先は https://marketrans.jp//checkout/。しかし、私のサイトに「checkout」という決済ページは存在しません。参照元として記録されていた https://www.google.com//checkout/ も、見慣れないURLでした。

普段からChatGPTと一緒に日次レポートを確認し、GA4やGoogle Search Consoleのデータを見ながらWebサイトの状態を把握しています。今回も、その日常的な確認から始まった調査でした。最初は内部参照や計測上の問題かもしれないと考えましたが、GA4の情報だけでは原因がわからず、サーバーのアクセスログを取得して調べることにしました。

すると、異常値が記録されたのと同じ時間帯に、セキュリティ検査ツールを名乗るアクセスが見つかりました。さらに、別の時間帯にはWordPressの設定ファイルや管理画面などを探す大量のアクセスも記録されていたのです。

今回の調査で、Webサイトへの侵入成功や情報漏洩を裏付ける証拠は確認されていません。それでも、普段GA4で見ている数字の裏側で何が起きているのかを知ると、Webサイトの保守やセキュリティに対する見方も少し変わります。その調査過程を、確認できた事実と未解決の疑問を分けながら紹介します。

GA4に記録された、存在しないページへのアクセス

まず、問題のアクセスについてGA4で確認できた情報を整理します。

このURLには、ページ閲覧を示す page_view、セッション開始の session_start、初回訪問の first_visit に加え、scroll_depth と user_engagement も記録されていました。5種類のイベントがそれぞれ1件ずつです。

GA4の記録だけを見ると、英国からMacintoshのChromeを使って訪問したユーザーが、ページを閲覧したようにも見えます。しかし、実際には存在しないページが記録されているうえ、参照元とアクセス先の両方に //checkout/ という不自然なパスが含まれています。通常のアクセスとして扱うには、気になる点がいくつもありました。

もっとも、存在しないURLがGA4に記録されること自体は珍しい仕組みではありません。例えば、存在しないページへアクセスして404エラーページが表示された場合でも、そのページにGA4の計測タグが設置されていればページビューは記録されます。また、Googleの公式資料によると、計測時に送信する page_location（ページURL）や page_referrer（参照元URL）は、任意の値を設定することもできます。GA4にURLが表示されたからといって、そのURLへのHTTPリクエストが実際にサーバーへ届いていたとは限らないわけです。

同様に、page_view や user_engagement が記録されていても、それだけで人間がページを読んだとは判断できません。ブラウザの操作を自動化するプログラムなどでも、計測イベントが発生する可能性があります。

それなら、実際にWebサーバーにはどのようなアクセスが届いていたのか。GA4に記録された12:35という時刻を手がかりに、サーバーログを確認しました。

サーバーログを調べると、セキュリティ検査を名乗るアクセスが見つかった

サーバーログとは、Webサーバーに届いたリクエストと、その応答などを記録したものです。サーバーの設定によって内容は異なりますが、アクセス日時、要求されたURL、ログに記録されたIPアドレス、HTTPステータスコードなどを確認できます。

今回取得したログには、2026年10月18日3:34頃から翌19日3:16頃までのアクセスが、計1,422行記録されていました。18日のすべてのアクセスを網羅しているとは限りませんが、GA4に異常が記録された時間帯も含まれています。ChatGPTを使って該当する時刻のリクエストを抽出し、アクセス先や応答コードを確認すると、12:35:24から12:35:35までの約10秒間に、ログ上で同じIPアドレスから32件のリクエストが記録されていました。

主な内容は次のとおりです。

※実際のログを要約したものです。200はリクエストが正常に処理されたこと、403はサーバーがアクセスを拒否したことを表します。

特徴的だったのは、アクセスに使用したプログラムが自ら名乗る「User-Agent」という情報です。今回の記録にはセキュリティ検査ツールを名乗る文字列が含まれており、同じIPアドレスからの別のリクエストには、Chrome 155とMacintoshを示す情報も残っていました。後者はGA4に記録されていた環境情報とも一致します。

また、トップページだけでなくCSSやJavaScript、画像まで取得していたことから、通常のブラウザに近い動作でWebページを読み込んでいた可能性があります。ただし、User-Agentは偽装できる情報です。セキュリティ検査ツールを名乗っているからといって、そのツールや提供企業が実際にアクセスしたとは断定できません。

なお、WordPressの管理画面である /wp-admin/ へのリクエストには403が返されていました。このリクエストについては、サーバーがアクセスを拒否したことが確認できます。

ところが、肝心の「//checkout/」へのアクセスがない

ここまでの記録を見ると、GA4の異常値とセキュリティ検査を名乗るアクセスには、何らかの関連がありそうです。発生時刻が一致し、ブラウザやOSを示す情報にも共通点があります。

しかし、取得したサーバーログを確認しても、12:35の時間帯に GET //checkout/ というリクエストは見つかりませんでした。

これが今回の調査で、最も気になった部分です。

例えば、何らかのプログラムが実際に表示したページとは異なるURLをGA4へ送信した可能性は考えられます。また、取得したサーバーログには記録されない経路で、GA4へイベントが送信された可能性もあります。ただし、いずれも今回の記録だけでは検証できておらず、原因を特定するには至っていません。

つまり、同じ時間帯に関連が疑われるアクセスがあったことは事実ですが、それがGA4の異常値を直接発生させたとまでは言えません。時刻や環境情報の一致は調査の手がかりになりますが、因果関係を証明するものではないのです。

別の時間帯には、WordPressのファイルを探す大量のアクセスも

当初の目的は、GA4に存在しないURLが記録された原因を調べることでした。ところが、取得したログを広く確認してみると、同じ日の別の時間帯にも、通常のサイト閲覧とは考えにくいアクセスが多数残っていました。

例えば、朝9:15:30から9:16:07までの約40秒間には、ログ上で同じIPアドレスから245件のリクエストが発生しています。アクセス先は通常のコンテンツページではなく、さまざまなPHPファイルやWordPressのプラグイン関連ファイルなどです。ほかにも、特定のファイルを機械的に探しているようなアクセスが確認できました。

それぞれ異なるIPアドレスがログに記録されており、12:35に確認したセキュリティ検査を名乗るアクセスと一連のものだと判断する根拠はありません。

13:02頃に発生した36件のアクセスでは、WordPressの外部連携に使用される xmlrpc.php を、複数のディレクトリで探していました。36件すべてに403が返されており、該当リクエストは拒否されています。夜21:32頃のアクセスには、.env、.git、wp-config.php といった設定情報に関連するファイルの探索も含まれていました。これらは環境によっては認証情報やソースコードなどの機密情報につながるものです。さらに別の時間帯には、.sql や .zip といったデータベース・バックアップファイルを想定したリクエストも記録されていました。

もちろん、リクエストが送られたことと、対象のファイルが実際に存在したことは別です。記録されたHTTP応答には403（アクセス拒否）や404（対象が見つからない）、301（URLの転送）などが多く、一部には200もありました。しかし、200はリクエストが正常に処理されたことを示すだけで、不正なファイル取得や管理権限の獲得を意味するわけではありません。301についても、転送先の応答を確認しなければ、その後の結果は判断できません。

興味深かったのは、こうした探索のUser-Agentに「Googlebot」や「ChatGPT-User」という文字列まで含まれていたことです。ただし、これも自己申告の情報であり、GoogleやOpenAIが実際に探索した証拠にはなりません。アクセス元を特定するには、IPアドレスの帰属などを含めた別の確認が必要です。

また、21:32頃のログには /checkout へのアクセスもありましたが、GA4で異常が記録された12:35の //checkout/ とは時刻もURLの形式も異なります。名称が似ているからといって、同じ事象として結びつけることはできません。

探索されたことと、侵入されたことは違う

今回のようなアクセスには、WordPressの脆弱性や設定ミス、公開されているファイルなどを探す目的があった可能性があります。ただし、探索の試行と侵害の成功は区別しなければなりません。取得したログの範囲では、侵入成功や情報漏洩を裏付ける証拠は確認できませんでした。

一方で、サーバーのアクセスログだけで「被害は一切なかった」と証明できるわけでもありません。さらに詳しく調査する場合は、ファイルの変更履歴や認証ログ、管理者アカウントの状態なども確認する必要があります。今回の記録から言えるのは、markeTransのような小規模な事業者のWebサイトにも、自動的な探索のリクエストが届いていたということです。

GA4とサーバーログでは、見えているものが違う

Webマーケティングの仕事では、GA4を使って流入元やページ閲覧、ユーザーの行動を分析します。しかし、GA4はWebサーバーに届くすべてのリクエストを記録するためのツールではありません。Googleの公式資料によれば、GA4では既知のボットやスパイダーによるトラフィックが自動的に除外されています。また、GA4の計測イベントが送信されないアクセスは、通常のアクセス解析レポートには記録されません。

一方、サーバーログには、GA4の計測タグを実行しないプログラムからのリクエストも記録される場合があります。例えば、存在するかどうかもわからないPHPファイルを大量に探すようなアクセスです。こうした通信は、通常のWebマーケティングの分析対象とは性質が異なります。

もちろん、サーバーログも万能ではありません。CDNやプロキシ、WAF（Webアプリケーションへの通信を検査・制御する仕組み）などを利用している場合、アクセスがどの段階で記録されるかは構成によって異なります。保存期間が短ければ、異変に気づいた頃には必要な記録が残っていない可能性もあります。

今回、GA4とサーバーログの情報を照合することで関連が疑われるアクセスを見つけることはできましたが、異常値が生じた直接の原因は特定できませんでした。この結果は、どちらかのツールが間違っていることを意味するものではありません。それぞれが異なる仕組みで情報を記録している以上、数字やURLが一致しない場合にも、その違いを踏まえて判断する必要があります。

Webサイトの運用には、集客・SEO以外の視点も必要だった

私の普段の仕事では、GA4やGoogle Search Consoleを使い、アクセス数や検索流入、問い合わせにつながるユーザーの行動などを分析しています。そのデータから改善施策を考え、優先順位を判断するのがWebマーケティングの仕事です。

しかし、Webサイトの運用には、数字として見えやすい成果を追うこととは別に、サイトを正常かつ安全な状態で維持するための保守管理があります。WordPress本体やプラグインの更新、バックアップ、管理画面のアクセス制御、障害への対応などです。集客施策はアクセス数や問い合わせ数の変化によって効果を確認できますが、保守管理は問題が起きなければ、その必要性を意識する機会も少ないでしょう。

今回、自社サイトのログを調べたことで、普段のアクセス解析では目にしない自動探索の存在を確認できました。これは、知名度の高い大企業だけがセキュリティについて考えればよいわけではない、という気づきにつながりました。サイトの規模が小さいからといって、自動的な探索の対象にならないとは限りません。

だからといって、すべての中小企業が高価なセキュリティ製品を導入したり、専門の技術者を雇ったりする必要があるとは考えていません。まずは、自社サイトの管理状況を把握することが先です。

例えば、確認したいのは次のようなことです。

• 更新管理： WordPress本体やテーマ、プラグインを誰が更新し、作業後の動作をどう確認しているか。
• バックアップ： 保存場所や取得頻度が決まっているか。必要なときに復元できるか。
• ログ管理： サーバーログを誰が取得でき、どのくらいの期間保存されているか。
• 対応体制： 不審なアクセスや障害があった際、誰が調査し、必要に応じてどこへ相談するか。

こうした基本的な管理は、社内のWeb担当者がすべて行う必要はありません。サイト制作会社や保守会社に任せる方法もあります。ただし、どこまで対応してもらえるのかは、契約内容や運用体制によって異なります。「保守をお願いしているから大丈夫」と考える前に、具体的な作業範囲を確認しておくことが大切です。

WordPress公式のセキュリティガイドや、IPA（情報処理推進機構）の「安全なウェブサイトの作り方」なども、必要な管理項目を整理する際の参考になります。

情報漏洩は他人事。でも、自社サイトのログを見てみると

不正アクセスや情報漏洩のニュースを見ると、被害を受けた企業の規模や業種から、自分の事業とは少し距離のある話に感じてしまうことがあります。私自身、普段からWebサイトのアクセス解析を行っていながら、今回のようにサーバーログを詳しく確認する機会は多くありませんでした。

ところが、実際に自社サイトのログを開いてみると、わずか数十秒間に数百件のリクエストが届き、WordPressのさまざまなファイルが機械的に探索されていました。今回のログに侵入成功や情報漏洩を示す証拠はありませんでしたが、小規模なサイトもこうしたアクセスと無縁ではないことは確かです。

調査ではChatGPTも活用しました。1,422行のログから特定の時刻やアクセスパターンを抽出し、GA4の情報と照らし合わせる作業では役立ちましたが、AIが提示した推測をそのまま結論にはしていません。関連しそうな情報が見つかっても、因果関係を証明できなければ未確認として残す。その判断は、元の記録を確認しながら行う必要があります。

今回、GA4に存在しないURLが記録された直接の原因は、結局特定できませんでした。それでも、日常的なアクセス解析をきっかけに、普段は見えていなかったWebサイトへのアクセスを確認できたことには意味があったと思います。

Webサイトを育てるための集客・SEOと、その土台を維持するための保守管理。どちらもWebサイトを運用するうえで欠かせない仕事です。もし、自社サイトのサーバーログを誰が確認できるのか、どのような保守体制になっているのかを把握していなければ、一度確認してみてもよいかもしれません。

参考資料

• Google アナリティクス ヘルプ｜既知のbotトラフィックの除外
• Google for Developers｜Google Analytics Configuration
• Google for Developers｜Googleのクローラーからのリクエストを確認する方法
• WordPress公式｜Hardening WordPress
• IPA｜安全なウェブサイトの作り方