【要約】AIクローラーのUAは名乗るだけ — 検証済みだけ数えたら本物468件・偽装991件だった [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
Webサイト運営者がUAのみに依存して集計を行うと、実態を見誤る問題がある。UAはヘッダ情報であり、誰でも任意の文字列を名乗れるためだ。具体的には以下の課題が存在する。
- ・AI学習を目的としたクローラーと、脆弱性を探るスキャナーが同じUAを偽装して混在する。
- ・UAベースの集計では、攻撃的なスキャンリクエストをAIの関心として誤認してしまう。
- ・Google-Extendedのように、そもそもUAを持たない制御用トークンを偽装するケースがある。
// Approach
筆者は、UAの「主張」と「実体」を切り分けるため、Cloudflareの検証機能とサイトマップを用いた二軸の検証手法を採用した。これにより、リクエストの正当性を多角的に判定する。
- ・Cloudflareの
verifiedBotCategoryを用い、IPアドレスから検証されたボットか否かを判定する。 - ・リクエストされたパスがサイトマップに存在するかを確認し、コンテンツ消費か否かを判別する。
- ・パスのパターン（
.env,.git等）に基づき、スキャン、運用、アセット、コンテンツの4種に分類する。 - ・CloudflareのAPI制限（1日単位の取得）に対応するため、期間を分割して取得する実装を行う。
// Result
8日間の検証により、UAの信頼性が極めて低いことが定量的に示された。これにより、正確なボットトラフィックの把握が可能となる。
- ・GPTBotを名乗るリクエストのうち、OpenAIと検証できたのはわずか13%であった。
- ・コンテンツ取得（content）が468件に対し、認証情報スキャン（scan）は991件に達した。
- ・Google-Extendedを名乗るリクエストは、定義上存在しないUAであり、全て偽装であった。
Senior Engineer Insight
> UAベースのメトリクスは、セキュリティ監視において「ノイズ」でしかない。実態を把握するには、インフラ層の検証データと、アプリケーション層のサイトマップ情報を組み合わせる多層的なアプローチが不可欠である。特に、スキャンリクエストがAIクローラーを装う傾向は強く、WAFの閾値設計においてこの「偽装」を考慮する必要がある。ログ解析の際は、単なるUA集計ではなく、パスの妥当性と検証済みフラグをセットで見るべきだ。