GA4で海外都市が急増すると不安になります
結論：Lanzhou急増＝即「侵入」ではない
GA4だけでは“正体”に辿り着けない（限界を理解する）
サーバーログ突合：何を見るべきか（再現できる手順）
GA4に出てもサーバー到達とは限らない理由
再発時に役立つ「調査フロー」テンプレ
実運用のおすすめ対応（最小で効果が高い）
1. ① GA4分析の精度を守る（重要）
2. ② 防御は「必要最小限の確認」でOK

GA4で海外都市が急増すると不安になります

GA4で「Lanzhou（中国　兰州）からのアクセスが急増」と表示されると、「不正アクセスでは？」「サイトが狙われている？」と不安になります。

しかも、平均エンゲージメント時間が0秒、エンゲージメント率が極端に低い、ページがほとんど読まれていない――こうした数値が並ぶと、なおさら心配になるはずです。

ただ、ここで慌てて結論を出すのは危険です。
GA4の地域（市区町村）は、IPの登録情報や経由サーバーの影響で“代表地点”として表示されることがあり、実際のアクセス元とはズレるケースが少なくありません。

本記事では、この状態を判別するために、GA4の指標でBotらしさを整理 → サーバーログで「実際に到達しているか」を裏取り → 必要最小限の対策に絞るまでの流れを解説しています。

結論：Lanzhou急増＝即「侵入」ではない

まずGA4で「Botっぽさ」を見抜くチェックポイント

地域名よりも、GA4にある以下の“行動指標”が重要です。
ここが揃うほどBot疑いが濃くなります。

Bot疑いが強いサイン

平均エンゲージメント時間が0秒〜数秒
エンゲージメント率が極端に低い
1セッションあたりの表示回数（PV）が不自然に低い
イベントが偏る（page_view だけ、または機械的に同じイベントだけ）
時間帯が24時間均一（人間の生活時間帯と一致しない）

逆に「人間っぽい」サイン

scroll / click などが自然に発生
モバイル（iPhone/Android）比率が一定ある
参照元が検索・SNS・他サイトなど多様
複数ページを遷移している

GA4の「地域レポートが見つからない時」：GA4のUI変更に注意

最近のGA4では、以前あった「地域」レポートが見つけにくくなっています。
その場合は次の場所で確認します。

レポート → ユーザー → ユーザー属性 → ユーザー属性の詳細
そこでディメンションを 国 / 地域 / 市区町村 に切り替え

GA4だけでは“正体”に辿り着けない（限界を理解する）

GA4は便利ですが、セキュリティ調査のために作られたツールではありません。
原則として次は追えません。

IPアドレス
通信事業者（ASN）
同一IPの連続攻撃の正確な把握
“誰がやっているか”の特定

そのため、GA4は 「異常の兆候」 を掴むには強い一方、
「誰が・どのIPで」 という“実体の特定”には向きません。

ここから先は「サーバーログ（オリジン）」で裏取り（突合）が必要です。
サーバーログ突合：何を見るべきか（再現できる手順）

サーバーログでは「実際に到達したHTTPリクエスト」が残ります。
つまり、攻撃が本当に届いていれば痕跡が出ます。

サーバーログで「実際に到達しているか」を確認する

目的は、GA4で目立った海外都市のアクセスが、サーバーに実際に届いているかです。

ログで見るポイント

1か月のログ行数（総リクエスト数）
アクセス元IPの偏り（特定IPが連続していないか）
アクセス上位のIP（同一IPが異常に多くないか）
User-Agent（クローラ／Botの名乗り、空UA、機械的UA）
リクエストURLの傾向（管理画面・存在しないURL・脆弱性探索など）
ステータスコードの傾向（404/403の多発、200のみの連打など）
短時間に大量アクセス（レート）

サーバーログの取得方法（一般的な手順）

今回の検証のように「GA4で見えている挙動が、実際にサーバーへ到達しているのか」を確かめるには、サーバーログの取得が欠かせません。

ログは、レンタルサーバーやVPSなどのコントロールパネル（管理画面）からダウンロードできる場合が多く、まずはそこを確認するのが最も簡単です。

一般的には、レンタルサーバーの管理画面にログインし、「アクセス解析」「ログ」「Web/HTTPログ」「アクセスログ」などのメニューから対象ドメインを選び、期間（例：直近1か月、特定日）を指定して取得します。

形式はテキスト（.log）や圧縮ファイル（.gz / .zip）で提供されることが多く、必要に応じて解凍して利用します。

なお、ログの保存期間はサーバー会社やプランによって異なり、数日～数か月で自動削除されることもあるため、異常に気づいたら早めに取得しておくと安心です。

また、サーバーによってはコントロールパネルからの取得に加え、FTP/SFTPでサーバーに接続してログディレクトリから直接ダウンロードできる場合もあります。

VPSや自前サーバーの場合は、SSHでログファイル（例：Webサーバーのアクセスログ）を確認し、必要な期間分を抽出して保存する方法が一般的です。

⚠️いずれの方法でも、取得したログは個人情報を含む可能性があるため、取り扱いには注意し、分析に使う範囲で適切に保管しましょう。

今回の作業では、契約レンタルサーバーのコントロールパネルより2026年に入ってからのサーバーログを取得しサーバーログ突合を行いました。

突合結果：GA4の海外都市アクセスは「サーバーログに存在しなかった」

今回のログでは、上位には通常ユーザー由来と思われるアクセスに加え、検索エンジンやSEO系クローラなど“正規の巡回”と判断できるUAも見られました。

調査の結論は明確でした。

GA4上では海外の特定都市が大量
しかしサーバーログでは、その海外由来の実体がほぼ確認できない

つまり、今回見えていた現象は次のどちらか（または複合）です。

パターンA：上流（WAF/CDN/防御層）で遮断され、サーバー（オリジン）に届いていない

防御層が機能していれば、攻撃はサーバーに届かないため、ログには残りません。
それでもGA4側には、何らかの形で“痕跡”が見えることがあります。

パターンB：計測系への疑似ヒット（計測イベントの偽送信）

閲覧を伴わず、計測に似た信号だけを送る手口や、計測上のノイズが混ざる場合があります。
この場合も、実アクセスがないためサーバーログには出ません。

今回の最終判断：実害はなく、GA4側のノイズとして扱うのが正解

今回の突合で分かったのは、「海外都市からの攻撃が激増している」ではなく、

“到達前に遮断されたBot（もしくは計測ノイズ）が、GA4上の地域表示に集約されて見えていた”

という構図です。

実務的な結論

サーバー侵入や実害を示す証拠は見当たらない
防御層が機能している可能性が高い
GA4分析では海外ノイズを除外して、国内ユーザーを主対象にするのが合理的

GA4に出てもサーバー到達とは限らない理由

GA4で「Lanzhou（海外都市）からのアクセスが急増」と出ると、不正アクセスがサーバーに届いているように見えます。

しかし、GA4に表示された＝サーバーに到達したとは限りません。
GA4は「アクセスの記録（通信ログ）」ではなく、あくまで「計測データ（イベント）」を集計する仕組みだからです。

**GA4は『ユーザーの行動』を測るもので、『通信の正しさ』を保証するものではない**

上図の流れで言うと、
まず海外の攻撃/ボットがサイトへアクセスします（①）。
ここで、途中にある防御（WAFやフィルター）が働くと、アクセスはチャレンジ/ブロックされ（②）、オリジンサーバーまで届きません。
この場合、サーバー側はそもそも通信を受け取っていないため、サーバーログに残らない（またはごくわずかしか残らない）ことがあります。

一方で、CDNを使っていない場合でもGA4に“アクセスがあったように”見えることがあります。
ただし理由は「上流で遮断されたから」ではなく、計測スパム（計測だけを直接送る）／疑似ヒット（見たふり）／即時拒否（接続直後に切られてログが残りにくい）などです。
つまり、図の③のように「ページ閲覧は成立していないのに、計測の痕跡だけがGA4に残る」ことが起こります。

だからこそ、本当にサーバーへ届いているかどうかの最終判断はサーバーログで行います。

GA4は“異常に気づくための警報”、サーバーログは“実際に届いたか確認する証拠”と考えると、迷わず判断できます。

再発時に役立つ「調査フロー」テンプレ

最後に、同じ現象が出たときのための、再現可能な調査フローは以下の手順になります。

[1] GA4で異常発見（地域・都市が突出）
   ↓
[2] 指標でBot判定（0秒/低PV/低Eng/時間帯均一）
   ↓
[3] GA4の限界を理解（IP・ASNは追えない）
   ↓
[4] サーバーログで裏取り（到達しているか確認）
   ↓
[5] 結論分岐
   ├─ ログに大量 → 実攻撃。遮断ルール強化へ
   └─ ログに無い → 上流遮断/計測ノイズ。GA4除外で対応