月次レポートを見ると、セッション数は前年より増えている。それなのに問い合わせフォームからの連絡は横ばいで、増えているのは転送量とホスティングの請求額だけ。制作会社に相談したらボット対策の強化を勧められ、入れてみたら今度は「フォームが送れない」という問い合わせが来るようになった。
このやり取りが噛み合わないのは、「ボットを弾く」という言い方が、もう単一の作業を指していないからです。自動化されたアクセスの中には、無断で本文を持っていくスクレイパーもいれば、ユーザーに代わって商品を比較しに来ているAIエージェントもいます。前者は止めたいが、後者を止めるのは客を追い返すことに近い。ところが従来の検知は、この2つを区別する材料をほとんど持っていませんでした。
一回きりのチェックでは、もう分けられない
これまでのボット判定は、リクエストが来た瞬間に判断を下す形が中心でした。User-Agent を見る、JavaScript を実行できるか試す、CAPTCHA を出して人間かどうか確かめる。どれも「その1回」で答えを出します。
この方式が崩れたのは、自動化の側が実際のブラウザを使うようになったからです。JavaScript は動くし、Cookie も保持するし、CAPTCHA も通過します。短い瞬間だけを切り取れば、人間のアクセスと区別がつきません。しかも判定はリクエストごとにリセットされるので、疑わしい挙動をしても次のページ読み込みで白紙に戻ります。
Cloudflare が2026年に投入した Precursor は、この前提のほうを変えにいった設計です。軽量なクライアントサイドのスクリプトを挿入し、ポインタの動き、キー入力のタイミング、フォーカスの移動、ページが表示されているかどうかといったシグナルをセッションを通じて継続的に集めます。それをエッジ側でリアルタイムに突き合わせ、セッション全体の文脈を積み上げながら Bot Score を調整していきます。
効いてくるのは、リロードで逃げられない点です。行動の履歴がセッションに紐づくため、ページを読み込み直しても署名がリセットされません。短時間だけ人間のふりをするのは簡単でも、セッション全体で一貫して人間らしく振る舞い続けるのは難しい、という非対称性を突いています。
プライバシー面は、キー入力については押されたキーそのものではなく打鍵のタイミングとリズムだけを見る、シグナルは個人に紐づけず集約したパターンとして扱う、という設計が公表されています。とはいえ「訪問者の操作を継続的に観測するスクリプトを自社サイトに挿す」という事実は変わらないので、プライバシーポリシーや同意管理の記述と整合しているかは、導入前に自分の目で確認すべき部分です。
「全部弾く」が選べなくなった
検知の精度が上がると、次に効いてくるのは技術ではなく方針のほうです。精度が低いうちは「怪しいものは全部弾く」で済んでいましたが、区別がつくようになると、どこで線を引くかを自分で決めなければならなくなります。
自動アクセスは、少なくとも次のように性質が分かれます。
| 種類 | 何をしに来ているか | 通すかどうかの判断軸 |
|---|---|---|
| 学習用クローラー | モデルの訓練データとして本文を収集 | 自社コンテンツを学習に使わせたいか |
| 検索・回答エンジンのクローラー | 検索結果や回答に引用するための収集 | 引用元として名前が出る価値と、素通りされるリスク |
| ユーザー代理のAIエージェント | 特定の人の依頼で調べ物・比較・申込 | その先に人間の意思決定がある |
| 悪性の自動化 | 在庫買い占め、フォーム投稿、認証情報の総当たり | 通す理由がない |
3行目が、この数年で新しく増えた層です。その先に実在の人間がいて、購買や問い合わせにつながる可能性がある。ここを一律で弾くのは、営業時間中に来店した客を「顔認証で判定できなかったので」と追い返すのに近い判断になります。
一方で1行目については、通すか止めるかで収益構造が変わります。学習クローラーへの向き合い方そのものが商売の話になっている状況は、AIに記事をタダ読みされて流入は激減で扱いました。無断学習を積極的に妨害する側の手口についてはCloudflare AI Labyrinth を読み解くが近い話になります。
決める順番は、コストから入るほうが早い
線引きの議論は抽象的になりがちなので、金額から入ると早く終わります。
まず、ボットに払っている金額を出します。転送量課金や関数実行課金のホスティングを使っているなら、請求額の何割が自動アクセスによるものかを見ます。ここが小さいなら、そもそも急いで対策する話ではありません。金額の見え方とプラン設計の関係はボット対策とホスティング費用で整理しています。
次に、計測を分けます。自動アクセスを含んだままの数字で「PVが増えた」と報告し続けると、施策の評価がすべて狂います。弾く前に、まず判定結果でセグメントを分けて数えられる状態を作るほうが先です。弾くかどうかはそのあとで決められます。
最後に、通す側のホワイトリストを先に書きます。弾くルールから書き始めると、通したいものを取りこぼしたときに気づけません。自社が引用されたい回答エンジン、決済や配送の連携先、監視サービス、そしてユーザー代理のエージェントのうち通す範囲。これを先に列挙してから、残りをどう扱うかを決めます。
導入前に確認しておきたいこと
行動分析はスクリプトの挿入で成立します。コンテンツセキュリティポリシーを厳しく設定しているサイトでは、そのままでは動きません。また、計測系スクリプトを既に複数積んでいるサイトでは、表示速度への影響が積み上がります。Core Web Vitals を気にしている運用なら、導入前後で数字を取っておくべきです。
操作パターンが「人間らしくない」利用者がいます。スクリーンリーダーやスイッチデバイスを使う訪問者は、ポインタをほとんど動かさず、キー入力のリズムも一般的な分布から外れます。行動を根拠にした判定は、原理的にこの層を誤判定しやすい方向に働きます。フォーム送信のような重要な動線に厳しい閾値を置くなら、誤判定されたときに人間が通れる代替経路を必ず残してください。弾かれた人からは問い合わせが来ないので、この失敗は気づかないまま続きます。
判定の強さは、ページごとに変えられます。記事ページは緩く、フォームとログインは厳しく、というのが基本形です。サイト全体に一律で強い判定をかけると、失うものと守れるものの釣り合いが悪くなります。
次にやること
まず、直近1か月のアクセスのうち自動アクセスがどれだけを占めているかを、弾かずに数えるところから始めてください。数字が出れば、これがコストの問題なのか、コンテンツを守る問題なのか、それとも大した問題ではないのかが判断できます。
そのうえで、通したいアクセスのリストを先に書いてください。守りの設計は、そこから逆算したほうが事故が少なくなります。
自社サイトのボット判定の設計や、計測と防御を分けた運用の組み立てについては、グリームハブの開発・AI・自動化のご相談で承っています。サイトの構成やホスティング環境によって取れる手段は変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- Introducing Precursor: detecting agentic behavior with continuous client-side signals — Cloudflare Blog
- Cloudflare’s Precursor Detects Bots and AI Agents Through Continuous Behavioral Analysis — InfoQ
- Cloudflare Precursor uses continuous behavioral analysis to stop advanced bots — Help Net Security
- Cloudflare Introduces Precursor; One-Click Behavioral Defense Against Modern Bots — Cloudflare Press
