サーバー移設後のアクセス急増をAIに分析させたらボットだった話
ギターの練習もそこそこに、最近はサーバーの面倒ばかり見ている気がします。
サーバー移設したらアクセスが急増した！……？
先日、長年使ってきた老朽化サーバー（CentOS）を、新しいVPS（AlmaLinux 8.10 / ConoHa）へ移設しました。その経緯はこちらの記事にまとめています。
移設が無事に完了し、数日経った頃のこと。Google Analyticsの管理画面をなにげなく開いたら、アクセス数がドカンと跳ね上がっているではありませんか。
一日のPV（表示回数）が 4,000〜8,000 を超えている日がズラリと並んでいます。
「おお、サーバーが速くなったからSEO的にも評価が上がったのか……？」と一瞬だけ喜びました。ほんの一瞬だけです。
長年ブログを運営していると、こういうときの”嫌な予感”というのはだいたい当たります。
Google Analyticsで確認する
まずはGoogle Analytics（GA4）のダッシュボードで状況を確認してみます。しかし、GA4の管理画面って正直見づらいんですよね。日別の推移やページごとの内訳を細かく追いかけようとすると、ぽちぽちフィルタをいじるのが面倒になってきます。
とはいえ、ざっと眺めただけでも気になる点がありました。
- PV数とセッション数とアクティブユーザー数が、ほぼ同じ数値
- アクセスの大半が特定のページに集中している
人間がブログを読むなら、1回の訪問で何ページか回遊するのが普通です。PV/AU比率が 1.0 ということは、1ユーザーが1ページだけ見て即離脱していることを意味します。……うん、人間じゃないですね、これは。
面倒なのでGASにデータを集約する
GA4の管理画面でちまちま確認し続けるのは苦行なので、Google Apps Script（GAS）を使ってデータをスプレッドシートに自動で流し込む仕組みを作りました。
GA4の Analytics Data API をGASから叩いて、以下の3つのシートに日次で自動蓄積するスクリプトです。
- 全体アクセス：日別のアクティブユーザー数(AU)、セッション数、表示回数(PV)
- 流入元内訳：日別の参照元（sessionSource）とメディア別のセッション数
- ページ別PV：日別のページパスごとの表示回数
これで手元のスプレッドシートに生データが溜まるので、あとは好きなように分析できます。
AIに分析させてみた
スプレッドシートのデータをExcelにエクスポートして、AIエージェント（Antigravity）に渡して分析してもらいます。
Pythonのpandasでデータを読み込み、ボットアクセスの典型的な特徴をスキャンした結果が、これです。
全体アクセスの異常パターン
| 日付 | 表示回数(PV) | AU | セッション数 | PV/AU比率 |
|---|---|---|---|---|
| 2026-07-16 | 4,310 | 4,283 | 4,347 | 1.0 |
| 2026-07-15 | 8,590 | 8,526 | 8,421 | 1.0 |
| 2026-07-12 | 5,547 | 5,530 | 5,522 | 1.0 |
| 2026-07-11 | 7,194 | 7,159 | 7,140 | 1.0 |
| 2026-07-13 | 332 | 310 | 314 | 1.1 |
PV:AU:セッション が見事に 1:1:1 で揃っています。「1つのURLに1回だけ機械的にアクセスし、他のページを一切回遊せずに即離脱」——典型的なボットの挙動です。
アクセス先パスの集中
ページ別PVの内訳を集計すると、さらに決定的でした。
- 全体PV数：39,113
- 一般ページPV：865（2.2%）
- 特定のシステムパス：38,248（97.8%）
そして、そのシステムパスの内訳のほぼ全量（96%）が、WikiのトップページURL /tips_/index.php への集中アクセスでした。
GA4では「ボットトラフィック」として検出されていなかったのですが、これはアクセス元がユーザーエージェントを通常のブラウザ（Chromeなど）に偽装しているためです。GA4のフィルタをすり抜けて、一般ユーザーとしてカウントされてしまっていたわけです。
やっぱりね。
サーバーのアクセスログで裏を取る
GA4のデータだけだと「状況証拠」止まりなので、WebサーバーのApacheアクセスログを直接見に行きます。AIにSSH接続情報を渡して、サーバーに入ってもらいました。
アクセスログから /tips_/index.php を叩いているIPアドレスを集計した結果がこちらです。
$ grep '/tips_/index.php' /var/log/httpd/typea.info-access_log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 5
59428 74.7.227.141
56645 74.7.227.63
4055 209.85.238.4
3006 144.76.32.242
2671 216.244.66.235
2つのIPだけで累計116,000回以上。3位以下が4,000回台なので、文字通り桁が違います。
生ログを見ると、手口もはっきり分かります。
74.7.227.141 - - [17/Jul/2026:16:35:14 +0900] "GET /tips_/index.php?limit=20&offset=20200619090326&printable=yes&title=特別:ログ&type=&user= HTTP/1.1" 200 81783 74.7.227.63 - - [17/Jul/2026:16:35:14 +0900] "GET /tips_/index.php?limit=500&offset=20200624125627&printable=yes&title=特別:ログ&type=&user= HTTP/1.1" 200 1030179
printable=yes（印刷用の重いページ生成を強制）と limit=500（一度に500件分のログを取得）を組み合わせて、1秒間に3〜5リクエストのペースでWikiの操作ログを根こそぎスクレイピングしていました。1リクエストあたり最大1MBもの応答を返させているので、サーバーへの負荷も相当なものです。
逆引き（WHOIS）を確認すると、この2つのIPはRIPEレジストリに属する米国のクラウドホスティング上のアドレスでした。正体不明の自動巡回ボットです。
対策もAIにお願いした
原因がはっきりしたので、対策もAIにそのままお願いしました。
「対策Bの実行をお願いします」の一言で、AIがSSH経由でサーバーにログインし、OSのファイアウォール（firewalld）にブロックルールを登録・反映してくれました。
# AIが実行したコマンド firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='74.7.227.141' reject" firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='74.7.227.63' reject" firewall-cmd --reload
実行結果の確認も自動でやってくれます。
$ firewall-cmd --list-all
(省略)
rich rules:
rule family="ipv4" source address="74.7.227.141" reject
rule family="ipv4" source address="74.7.227.63" reject
これで該当IPからのアクセスは、Apacheに到達する前にOSカーネルレベルで即座に破棄されます。
まとめ
今回の一連の流れを振り返ると、こうなります。
- サーバー移設完了 → アクセスが急増 → 「速くなったからか？」と一瞬喜ぶ
- Google Analytics確認 → PV/AU/セッションが全部同じ値 → 嫌な予感
- GASでデータ集約 → スプレッドシートに日次データを自動蓄積する仕組みを構築
- AIで分析 → 全体の97.8%がWikiへの自動スクレイピングと判明
- サーバーログで裏取り → 特定2IPが計116,000回以上アクセスしていた
- 対策もAIに依頼 → ファイアウォールでブロック完了
「GA4のデータ収集 → 分析 → サーバーログの調査 → ファイアウォールの設定変更」まで、ほぼ全行程をAIエージェントに委任できたのは、なかなか面白い体験でした。人間がやったのは「GASのデプロイ（clasp push）」と「GASエディタの実行ボタンを押す」くらいで、あとは「分析して」「対策して」と言っただけです。
サーバー移設後にアクセスが急増したら、まずは喜ぶ前にログを確認しましょう。だいたいボットです。
めでたし。
