9月ごろから大手サービスでの大規模な情報漏洩ニュースが相次いでおり、世間ではセキュリティへの関心が高まっています。ワイドショーの報道でも流出件数が「数百万件〜数千万件」という桁違いの規模になってきている背景を見て、一般ユーザーの視点では「またおわびメールか」「企業の管理はどうなっているんだ」と思われるかもしれません。
しかし、その裏側にあるサーバー保守の現場で、実際にどのような攻撃が仕掛けられ、インフラエンジニアやシステム管理者がどう戦っているのかは、あまり表に出てきません。
実際、情報漏洩があった現場では、システムエンジニアたちがメチャクチャ責められ、すぐなんとかしろと幹部からの叱責で大変な状況になってるはずです。考えただけでもおそろしい。。
実は、私が保守を担当しているサーバーでも、今年（2026年）の9月末から10月にかけて、例のA2B攻撃を喰らっていた痕跡があとから見つかりました。
特に、アラートらしき兆候もなく、いつもの日常的なDoS攻撃がたまにあるだけだったのですが、関係会社のアラートをきっかけにログの詳細調査をすると、生成AIの影がチラつくステルス攻撃を特定し、幹部へレポートするまで、てんやわんやでした。
予兆は「いつものDoS」に隠された、本当の脅威
それは9月末のある日、インフラの監視アラートが鳴ったことから始まりました。特定のエンドポイントに対して、短時間に大量のリクエストが集中する「DoSアタック」の検知です。
しかし、サーバー保守の現場において、この手のDoS検知は日常茶飯事であり、連続で攻撃されない限り、スルーしています。うちの場合、インフラ側で自動的に検知して一時的にブロックをかけてくれるため、サーバーの負荷もほとんどなく、実害が出ることもありません。
そのため、その時点では「またBotか何かかな」程度にしか思わず、詳細なログチェックまでは行っていませんでした。
流れが大きく変わったのは、それからしばらく経った後のことです。関係会社から「不審なIPアドレスによるアクセスがあった。念のため、ログを調べてみてほしい」という緊急の連絡が入ったのです。
「ただの自動ブロックされたDoSじゃなかったのか？」と思ったのですが、小さな違和感を覚えながら、通常業務の手を止め、該当する時間帯のアクセスログ（Access Log）を本格的に掘り下げてみることにしました。
ログ解析で見つかった「古典的な攻撃」と、素人コーディングへの警鐘
敵は「生成AI」？レートリミットを回避するステルス手口
しかし、アタック自体の中身（SQL文など）は初歩的だったものの、その攻撃を裏でコントロールしている「システム」の挙動は、今までにないほど不気味で洗練されていました。
ログのタイムスタンプとIPアドレスの相関関係を時系列で細かく解析していくと、ある驚くべき変化のパターンが浮かび上がってきたのです。
第一階段：最初の突撃（機械的な力押し）
最初は、私たちが「いつものDoS」としてスルーしていた段階です。この時は、自動化されたボットがかなりの秒間リクエスト数で、手当たり次第にインジェクション攻撃を仕掛けていました。当然、これはサーバー前段にある「DoSレートリミット（一定時間内のアクセス回数制限）」に引っかかり、自動的に遮断（BAN）されていました。
第二段階：学習と適応（AIの影）
不気味だったのはここからです。
制限に引っかかり、一度アクセスが遮断されると、攻撃側は「あ、このアタックスピードだと弾かれるんだな」と瞬時に理解したかのように、ピタッとアタックスピード（攻撃の頻度）を落としてきたのです。
第三段階：ステルス化（監視の網をすり抜ける）
そして次に仕掛けてきたのは、IP制限の網に引っかからない「絶妙に遅いスピード（例えば数秒に１回とか）」にリクエスト間隔を調整した攻撃でした。
しかも、単一のIPからではなく、複数個を使い分けバラバラのプロキシやボットネット（踏み台IP）を経由していました。
この、「一度拒絶されたら、そのルール（閾値）を学習し、人間の手を介さずに即座に攻撃パラメータを最適化して再アプローチしてくる」という一連の挙動は、明らかに生成AI、あるいはAIを組み込んだ次世代の自動攻撃ボットツールを使った手口だと確信しました。
従来の固定スクリプトであれば、弾かれたら弾かれっぱなしでエラーログを量産し続けるか、あるいは人間が手動で設定を書き換えて翌日に再アタックしてくるのが関の山です。しかし、今回の敵はリアルタイムにこちらの防壁の厚さを「学習」していました。
今後のサーバー保守は、こうした「AIによって最適化されたステルスボット」と24時間体制で知恵比べをしなければならないのかと、ぞっとする思いでした。
敵が残した「間抜けな足跡」から関連アクセスを全件特定
世界中の多様なIPアドレスから、AIによって計算し尽くされたスピードで静かに仕掛けられるインジェクション攻撃。一見すると完璧な隠蔽工作であり、生のログからそれらを1つずつ見つけ出してブロックするのは不可能に近い思えました。
しかし、どれだけAIが賢く立ち回ろうとも、それを使っている「攻撃者（人間）」の詰めが甘かったのか、ログには致命的なミス（仕様の穴）が残されていました。
それは、リクエストヘッダーに含まれる「User-Agent（ユーザーエージェント）」が、すべて『一定の、明らかに不自然で変な文字列』で固定されていたことです。
通常、ブラウザからのアクセスであれば Mozilla/5.0... といった標準的な文字列が入ります。攻撃側もカモフラージュのためにこれを偽装することが多いのですが、今回の攻撃者は、IPアドレスの分散やアタックスピードの調整（AIの得意分野）にリソースを全振りした反面、User-Agentのバリエーションを増やすコードを書くのをケチった（あるいは忘れた）ようでした。
特定の怪しいツール固有の識別子なのか、あるいは開発者がテスト用に埋め込んだまま消し忘れたような「おかしな文字列」が、すべてのリクエストに共通して刻まれていたのです。
この「唯一の足跡」を見つけてからは、簡単に今回のアタックの痕跡を調査することができました。
それによると、実際のアタック以外にも通常アクセスを装った様子見のようなアクセスもアタックの数日前からあるなど、用意周到に数日間に渡って計画してそうな感じでした。
今回はアタックされたことがわかったのが数日後だったため、アタックしてきたIPアドレスをブロックすることまではしていないです。すでに手遅れでした。
その代わり、単純なインジェクションアタックを検知するスクリプトをクーロンで仕込み、警告する対応を入れました。まずは、アタックされていることがわかることが大事だと考えたからです。
将来的にはアタックの検知から即ブロックまで自動でできればと考えてます。
まとめ：これからのサーバー保守に求められる「3つの防衛思想」
今回、10月の上旬にアタックが発覚してから、まさに「てんやわんや」という言葉がふさわしい激動のログ解析とセキュリティ対応でした。
これだけ世間で騒がれていると、さすがに会社としても放置はできず、会社の上層部からもレポートを出せとか、関連部署への情報共有をしろだとか、今までセキュリティのことなど見向きもしなかった人たちまで騒ぎ出し、大変でした。しかも、素人同然なので、説明もたいへん。。
この経験を通して得た、これからのWebサイト運営・サーバー保守に必要な教訓は、以下の3つに集約されます。
「日常のDoS」の裏に潜む本命を疑え
単なる嫌がらせや、負荷をかけるだけのDoSアタックだと思っても、それが本命の脆弱性スキャン（SQLiなど）を隠すための煙幕である可能性があります。自動ブロックされたからと安心せず、関係会社や外部からの「不審な動きがあった」という小さなフラグ（報告）を見逃さず、ログを掘るフットワークの軽さが重要です。
素人コーディングを徹底的に撲滅せよ
攻撃側が生成AIを手に入れ、どれだけスマートに、どれだけ検出困難なスピードでアクセスを仕掛けてこようとも、受け止めるWebアプリケーション側がSQLiやOSコマンドインジェクション対策（プレースホルダの徹底、入力値のバリデーション）を「正しく」行っていれば、このような攻撃程度で実害は100%ゼロです。「基本に忠実なセキュアコーディング」こそが、AI時代における最強の防壁です。
ログの生データにある「微細な違和感」を見逃すな
IPアドレスがどれだけ分散されようとも、リクエストヘッダー（User-Agent、Accept-Languageなど）のどこかに、攻撃ツール固有の「癖」や「バグ」が出ることがあります。機械的なアラートだけに頼らず、時には生のログファイルを自分の目で観察し、違和感に気づく「エンジニアの勘」を養っておくことが、システムを守る最後の砦になります。
