サイト共通のBot比率には意味がない
公開記事には検索エンジンなど正当な自動アクセスが多く含まれます。一方、1回ごとにAI費用が発生する購入支援では、少数の反復でも損失が大きくなります。Bot比率だけをサイト全体で決めると、守るべき場所と許容できる場所が混ざります。
記事閲覧10万件のうちBotが30％でも、キャッシュ配信だけならAI費用はほぼ動かないかもしれません。購入支援1,000件のうちBotが3％でも、1回0.20ドルの処理を各100回反復すれば600ドルになります。割合ではなく、どの経路で何回の有料処理が起きるかを計算単位にします。
経路ごとに1回の費用を見積もる
対象経路について、通常の1リクエストあたり入力・出力トークンと推定費用を出します。そこへ短時間の反復回数を掛け、30分または1時間で起こり得る費用を見積もります。推定値は、最終的にAI事業者の請求明細で補正します。
計算例は『0.08ドル／回×最大120回／分×30分＝288ドル』です。ただし全呼び出し回数が同じ長さとは限らないため、中央値と上位10％の単価で幅を出します。推定288〜430ドルのように範囲で持ち、許容損失100ドルを超えるなら外部通知を待つだけでなく担当者が制御判断へ進む、と境界を付けます。
- 1回あたりの推定AI費用
- 通常利用者の反復回数
- 観測された最大速度
- その経路が生む注文・問い合わせ
- 誤停止した場合の損失
分類の確信度を計算へ入れすぎない
ProのSmart Protectionで示されるHuman・Bot・Unknownは運用上の判断材料であり、完全な身元判定ではありません。『Botと表示されたから全件無価値』として損失をゼロ計算すると、検索クローラーや支援技術、誤分類された顧客を見落とします。反復、経路、成果の有無も合わせます。
誤判定例として、企業のセキュリティプロキシ経由の購入者がUnknownになったり、一般ブラウザを装う自動処理がHuman寄りに見えたりします。そこで分類別の単純遮断率ではなく、『高コスト経路』『通常の10倍を超える反復』『成果なし』が重なった場合に制御を強めます。どれか一つだけなら監視へ留めます。
しきい値は二段階にする
最初の段階では外部監視による通知やアプリケーション側の緩やかな回数制限、次の段階では対象経路の一時停止というように、いきなり全遮断しない設計が実務的です。高単価かつ売上に直結しない処理は早めに、購入途中の支援は顧客成果を確認しながら慎重に制御します。
たとえば30分の推定費用が許容額の50％なら外部通知、80％かつ反復が通常の10倍なら担当者が対象経路を確認、月間上限へ達したら基本のハードストップ保護、という役割分担を考えられます。本製品が50％・80％の短時間ルールを自動提供するという意味ではありません。購入完了率が通常比15％以上落ちたら制御を戻す条件も対で置き、数値はサイト実績から決めます。
毎週、誤停止と超過費用の両方を見直す
基準が適切だったかは、止めた件数ではなく、回避できた推定費用と、止めてしまった正当な利用の両面で評価します。まず最も高コストな一経路から基準を作り、1週間の実績で調整してください。
成果物は経路別しきい値計算シートです。1回単価、通常速度、異常速度、30分の推定損失、誤停止時の注文損失、外部通知・アプリケーション側の制限・停止判断の各条件を埋めます。週次で実請求との差、制御された呼び出し回数、制御後の購入率を追記し、費用だけ下がって顧客成果も落ちた基準は修正します。モデル変更、価格改定、繁忙期の開始時には再計算日を更新し、古い単価のしきい値を使い続けません。最大値だけでなく通常日の95パーセンタイルを残すと、一度の外れ値に基準を引きずられません。計算者と承認者も記録します。
「Botは何％なら危険か──割合ではなく費用と誤停止損失で決める」から一律停止が正当な需要まで拒むと分かったなら、さらに粗いルールで解決しないでください。まず無料版をダウンロードして基準値を作り、Human・Bot・Unknownと売上シグナルが必要になった段階でProのSmart Protectionへ移れます。