Agentic Bot が SaaS の漏斗に入る: 本物の利用者を傷つけずに abuse を抑える方法
signup、trial credit、checkout、API access を段階別に守り、未知の自動化をすべて攻撃者として扱わない SaaS チーム向けの実務ガイド。
更新日
従来の SaaS 防御は「人が来て、bot が endpoint を速く叩く」という前提でした。今の automation は browser を使い、JavaScript を実行し、form を埋め、間を置き、後で戻れます。悪意あるものもあれば、 ユーザーの代わりに作業する Agent、accessibility tool、許可した integration もあります。
答えは bot を全部 block することではありません。費用や不可逆な risk を生む action を守り、control が 本物の conversion をどれだけ傷つけるかを測ることです。
Cloudflare が 2026 年 7 月に発表した Precursor は、この変化を示す一例です。公開説明では、単発の challenge ではなく、client-side の session-level behavior を追加信号として扱います。特定 vendor の 製品を採用するかは別として、漏斗で起きる abuse は一つの event だけでは見えない、という原則は有用です。
高くつくのは landing page ではない
多くの損失は後段にあります。新規 account が free credit を取り高額 job を実行する。disposable email で trial を量産する。checkout が card testing に使われる。token が作られ shared quota を使い切る。 未確認の workflow が customer data を変更する。landing page の automation と 5 ドルの compute credit を同じ rule で扱うのは、摩擦の置き場所として不適切です。
まず、first request から最も高い action までを書き出します。各段階で「利用者は何を得るか」「千回 繰り返されると何を失うか」「必要最小限で何を確認できるか」「最も軽い control は何か」を問います。
| 段階 | 主な risk | 最初の control | escalation |
|---|---|---|---|
| landing/docs | scan、noise | cache、rate limit、観測 | 明確な abuse だけ challenge |
| signup | account farm | velocity、email、権限の遅延付与 | risk-based verification |
| trial credit | compute abuse | 小さい初期枠、action cap | 支払い/強い確認 |
| checkout | fraud、card testing | provider signal、attempt limit | step-up と review |
| API/state change | quota、data access | server auth、scope、idempotency | hold、human approval |
CAPTCHA は一層にすぎない
Turnstile のような managed challenge は form を守り、単純な automation の費用を上げるのに役立ちます。 しかし一回の event の signal です。Precursor の公開説明は、高度な automation が real browser や JavaScript で孤立したチェックを通れるため、focus、visibility、timing、interaction の連続を見る必要を 示します。発表時点では rolling out 中で GA 前の製品なので、能力を一般論として約束してはいけません。
実装では、money を消費する action ごとに rate limit を置く、trial を小さく始める、retry を idempotent にする、sensitive route を server-side で認可する、最小限の audit trail を残す、false positive の回復 導線を置く、という組み合わせが必要です。
shadow mode から始める
すぐ厳しい challenge を出す前に、一、二週間観測します。最も高い三 action について account age、 velocity、credit consumption、payment attempt、task failure、support outcome を記録します。収集できる からといって raw interaction content を保存せず、privacy と目的に必要な最小限にします。
小さな sample を人が分類します。明確な abuse、本物だが珍しい customer、許可された automation、 不明なケースです。これが false positive の baseline になります。trial account が多くの compute を使い activation しないなら、CAPTCHA より free tier の設計が問題かもしれません。email verification が遅く 顧客が離脱するなら、先に delivery reliability を直します。
各 control には owner と退出条件が必要です。どの abuse を減らすか、どの action に効くか、損失低減、 conversion/accessibility risk、いつ緩めるかを記録します。AI Agent Security Checklist と同じく、security は怖い言葉の一覧ではなく、permission と failure mode の設計です。
Bot detection は authorization の代わりにもなりません。人の account も侵害され、trusted integration も越権します。credential を scope し、costly route に quota を置き、state change を確認し、audit trail を残します。Agent が signup や比較をすることは許しても、無制限の free compute や未確認の変更まで 許す必要はありません。
