Unknownは『悪質』ではなく『証拠不足』
ProのSmart Protectionで変更直後にUnknownだけが増えたなら、訪問者の性質が突然変わったとは限りません。CDNでヘッダーが書き換わった、キャッシュ経由で情報が欠けた、信頼するプロキシの設定が合っていない、といった観測側の変化が有力です。
変更前はUnknownが4％、切り替え5分後から38％になり、注文数と総セッションがほぼ同じなら、攻撃急増より計測断絶の可能性を先に考えます。反対に設定時刻と無関係に特定APIの反復だけが増えたなら別原因です。分類割合の変化とインフラ変更の時刻を1分単位で合わせ、同時に変わったものを探します。
変更前後の通信経路を描く
ブラウザからCDN、ロードバランサー、Webサーバー、WordPressまでの順番を一枚にします。各区間で、元の接続情報やUser-Agentなど、判定に使う情報がどう引き継がれるかを確認します。ヘッダーは外部から偽装できるため、信頼境界も明記してください。
図では各矢印に『誰がこの値を書けるか』を添えます。外部クライアントが自由に付けられるヘッダーと、管理下のCDNが上書きする値を混同すると、判定材料を偽装されます。変更前の設定を書き戻せるようエクスポートを保存し、DNSやキャッシュの反映遅延も考慮してテスト時刻を記録します。
- CDN導入・設定変更の正確な時刻
- 変更前後のヘッダー差分
- キャッシュヒットとMissでの分類差
- 特定経路だけUnknownになるか
- 注文・ログイン成功数は変化したか
実在する操作で再現する
社内端末、モバイル回線、プライバシー保護ブラウザなど複数条件で、商品閲覧や問い合わせを実行します。自分で行った正当な操作がUnknownになるなら、遮断ルールを強める前に観測経路を直すべきです。テストでは個人情報を含まない入力を使います。
最低でも、通常ブラウザ、Cookie制限あり、スマートフォン回線、キャッシュヒット、キャッシュミスの5条件を試します。各テストに時刻とランダムな識別語を付け、ログ上の1件を探します。通常ブラウザだけHumanで、キャッシュヒットだけUnknownなら、訪問者ではなくキャッシュ層で情報が失われているという切り分けができます。
修正は信頼境界を限定して行う
転送ヘッダーを無条件に信用する設定は避け、管理下のCDNやプロキシから届いた場合だけ参照します。変更後はHumanが増えたことだけで合格とせず、正当なテストが期待どおり分類され、不審な反復を見落としていないか確認します。
合格条件は、5条件の正当テストが期待する分類または説明可能なUnknownになり、既知の自動テストが一律Humanへ移らないことです。設定変更は一項目ずつ行い、15分の観察後に次へ進みます。分類率だけを元へ戻すために信頼範囲を広げると、見た目は直っても検出品質を落とす可能性があります。
Unknownを制限する前に、別の証拠で裏付ける
Unknownは分類に必要な証拠が足りない状態であり、自動アクセスという判定ではありません。プロキシやCDNの変更で以前使えていたシグナルが欠けることがあり、外部の分析機能も技術的な制約からUnknownを返す場合があります。ラベルだけで意図を推測したり、顧客導線を停止したりしてはいけません。
同じ時間帯から200セッションを固定抽出し、判断に必要な運用項目だけを記録します。項目はリクエスト経路、反復回数の区分、速度の区分、注文・問い合わせの完了、必要な場合の同意状態、既知のプロキシやアクセシビリティ試験条件です。この検証のために生のプロンプトや直接識別子を集める必要はありません。
Unknownだけを対象にした制御は、少なくとも二つの独立した観測が同じ狭いパターンを示す場合に限定します。例えば、一つの商品経路で高速な反復があり、顧客成果もない場合です。Unknownのセッションが注文や問い合わせを完了している場合や、経路変更と同時に増えた場合は、導線を開けたまま欠けた証拠を直します。
| 200セッションでの観測 | 支持する仮説 | 証明できないこと | 対応 |
|---|---|---|---|
| CDN・プロキシ変更直後にUnknownが増加 | 識別シグナルが欠けた可能性 | 不正利用 | シグナルを確認し、ラベルでは止めない |
| 同じ経路・正規化済み要求が高速反復 | 限定的な反復パターン | すべてのUnknownがBotであること | 経路と反復に絞ったルールを試す |
| Unknownが注文・有効問い合わせを完了 | 顧客価値を持つUnknownがいること | すべてがHumanであること | 成果を生む導線を残す |
| 顧客成果がなく、反復と費用が同時に増加 | 限定制御の候補 | 悪意 | 終了時刻付きルールを適用し誤停止を確認 |
ポリシー変更より先に、観測を復旧する
次に確かめるのはUnknownの量ではなく、どの経路で判定材料が失われたかです。原因が分かるまでUnknownをBotと同じ扱いにせず、一時的な監視対象として残す方が、正当な顧客を誤って止めにくくなります。
成果物は、変更前後の通信経路図と再現テスト表です。図に信頼境界、表にテスト条件・期待結果・実結果・復旧可否を残します。これをCDN設定変更の受け入れ条件へ組み込み、Unknown比率が通常の2倍を超えたら遮断強化ではなく観測確認を先に行う、という運用順を明文化します。CDN事業者の設定変更履歴と図の版を結び付け、半年後の担当者でも差分をたどれるようにします。
「CDN変更後にUnknownが急増したとき、Bot扱いする前に確認すること」から一律停止が正当な需要まで拒むと分かったなら、さらに粗いルールで解決しないでください。まず無料版をダウンロードして基準値を作り、Human・Bot・Unknownと売上シグナルが必要になった段階でProのSmart Protectionへ移れます。