User-Agentは自己申告に近い情報
User-Agentはブラウザやクローラーの種類を推測する手掛かりですが、変更や偽装が可能です。文字列が空、古い、見慣れないというだけで、悪意や本人性を確定できません。単独の遮断根拠にすると誤停止が起こります。
悪質な自動処理が一般的なChrome文字列を名乗る一方、正規の監視ツールが独自名を使うこともあります。『MozillaではないからBot』『Botという文字を含むから攻撃』といった規則は簡単ですが、回避も誤判定も容易です。識別文字列は調査の入口にし、制御の最終条件には挙動と経路を加えます。
正当な通信も変わった識別情報を持つ
プライバシー保護ブラウザ、読み上げなどの支援技術、企業内プロキシ、監視サービス、検索クローラーは、一般的なブラウザと異なる情報を示すことがあります。Unknownは『危険』ではなく、判定に十分な材料がない状態です。
誤判定例として、社内ネットワークの出口でUser-Agentが短縮され、複数の顧客操作が同じUnknownに見える場合があります。アクセシビリティ支援アプリの内蔵ブラウザが古い形式を送ることもあります。こうした利用者を一括拒否すると、プライバシーや障害の事情がある人ほどサービスへ到達しにくくなります。
経路・速度・結果を組み合わせる
識別情報に加え、何を呼び出したか、どの速度で繰り返したか、失敗後も続けたか、購入や問い合わせへ進んだかを見ます。ProのSmart Protectionで示されるHuman・Bot・Unknownも補助分類であり、完全な判定ではありません。
例えば見慣れないUser-Agentが商品質問を10分に2回行い、カートへ進んでいるなら通常顧客に近い挙動です。同じ文字列が存在しない商品IDを1分200回呼び、すべて失敗しているなら制御根拠が強まります。分類名が同じでも対応が変わるよう、複数条件をANDで組み合わせます。
- 同じ入力・経路の反復速度
- AI費用が高い機能への集中
- 失敗後の再試行パターン
- ページ遷移や顧客成果の有無
- 正規クローラーとして検証できる情報
遮断より狭い制御から始める
見慣れないUser-Agent全体を拒否せず、高コスト経路の短時間反復だけを制限する、追加確認を求める、監視頻度を上げるといった段階的対応を選びます。アクセシビリティやプライバシーを理由に正当な利用者を排除しない確認も必要です。
実行順は、ログの確認、正当なテスト、対象経路の通知、短時間制限、追加確認、最後に一時遮断です。各段階で通常ブラウザと支援環境からテストし、問い合わせ完了率が通常比10％以上落ちたら戻します。AI機能が制限された場合にも、電話を強制せずオンラインフォームなど同等の代替手段を残します。
ルールには反証条件を付ける
『このUser-Agentは悪質』ではなく、『この経路をこの速度で反復し、顧客成果がない場合に一時制御する』と書き換えます。正当なテスト操作が止まったらルールを戻す、という反証条件まで決めると、思い込みではなく証拠で運用できます。
成果物は、思い込み、反例、追加証拠、制御条件、解除条件を並べた誤判定チェック表です。『Unknown＝攻撃』にはプライバシーブラウザという反例を、『Human＝安全』には偽装自動化という反例を置きます。週次レビューで誤停止事例を一つ追加し、ルールが人物属性ではなく観測可能な挙動に基づいているかを確かめます。表にはテスト日、ブラウザ条件、対象経路、結果も残し、User-Agent仕様やCDN設定が変わった後に同じ反例を再現できるようにします。解除テストに失敗したルールは本番へ残しません。
「見慣れないUser-Agentだけで悪質Botと決めてはいけない」から一律停止が正当な需要まで拒むと分かったなら、さらに粗いルールで解決しないでください。まず無料版をダウンロードして基準値を作り、Human・Bot・Unknownと売上シグナルが必要になった段階でProのSmart Protectionへ移れます。