ログインフォームや会員登録フォームにボット対策を入れているサービスを運用しているなら、見過ごせない検証結果が公開されました。
ボット検出システムを開発するProof of Humanが、自社製品を含む5種類の検出システムに対して、AIエージェント（画面を読み取り自分で操作を判断して進めるAI）3種類と、決まった手順だけで動く従来型ボット2種類をぶつけて検出率を比較しています。結果は、WAF（Webアプリケーションファイアウォール）やCAPTCHA（ユーザーが人間かどうかを判定する認証の仕組み）の選定を見直す材料になる内容でした。
検証では、Claude Opusを使った「Browser Use」、Perplexityの「Comet」、xAIの「Grok」というAIエージェント3種と、自動操作の痕跡を隠さない「Chromium」、痕跡を偽装する「CloakBrowser」の計5種を使い、各検出システムに20回ずつアンケート回答タスクを実行させています。
なぜ今この判断が必要になるのか
ここ数年、hCaptchaやCloudflare Turnstileのような画像認証や行動解析型の仕組みを「導入しておけば安心」と考えて選定したチームは少なくないはずです。
しかし今回の検証で、hCaptchaのAIエージェントに対する検出率はBrowser Useで16％、Cometで0％、Grokで6％という結果が出ました。Cloudflare Turnstileに至っては3種類のAIエージェントすべてで検出率0％です。
一方で決まった手順のボットに対しては、hCaptchaとTurnstileはどちらも95〜100％という高い検出率を維持していました。つまり「古いタイプのボット対策」としては機能しているものの、「画面を見て判断するAIエージェント」には素通りされているということになります。
これは会員登録フォームの不正作成、価格情報のスクレイピング、ポイントサイトの不正利用といった障害・インシデント対応の現場にとって、検出ロジックの前提が崩れつつあるサインです。監視設計やアラート閾値を見直すタイミングとして、まず押さえておきたい判断材料です。
判断軸を整理する
ボット対策サービスを選び直す、あるいは今の構成を継続するかを決めるうえで、確認しておきたい軸は4つあります。
検出方式の種類です。画像選択のようなチャレンジ型（利用者に問題を解かせる方式）か、スコア型（行動ログから人間らしさを数値化する方式）か、ブラウザ環境の整合性検査型かで、AIエージェントへの耐性が大きく異なります。
偽装耐性も重要です。IPアドレスやブラウザのフィンガープリント（端末・ブラウザ固有の識別情報）を偽装するボットに対して、検出ロジックがどこまで耐えられるかを確認する軸です。
運用コストと誤検知率も見逃せません。精度を上げようとすると、人間の利用者まで弾いてしまうリスクが高まります。カスタマーサポートへの問い合わせ増加という形で運用コストに跳ね返ってきます。
ログの可観測性も判断材料になります。検出ロジックが「なぜブロックしたか」「なぜ通過させたか」を運用チームが後から追えるかどうかです。障害対応の根本原因分析（RCA）の速度に直結します。
検出システムの比較
今回の検証で示された検出率をもとに、5種類の特性を整理します。
| 検出システム | AIエージェント検出率の傾向 | 従来型ボット検出率 | 特徴 |
|---|---|---|---|
| Proof of Human | 総合99％と最高水準 | 高い | 自社製品のため比較対象のベースラインとして提示 |
| reCAPTCHA v3 | Browser Use 95％ Comet 100％ Grok 72％ | 高い | スコア型でチャレンジ画面を出さない方式 |
| hCaptcha | 16％ 0％ 6％と低い | 95〜100％ | 画像認証はAIに解読されやすい |
| Cloudflare Turnstile | 3種とも0％ | 95〜100％ | ブラウザ状態検査型だがAIに素通りされる |
| Cloudflare Bot Management | 検証対象だが個別数値は概要で非公開 | - | 総合スコアでの運用が前提 |
注目すべきは、AIエージェントの検出で優位だったreCAPTCHA v3でも、ブラウザ情報とIPアドレスを偽装したCloakBrowserに対する検出率は0％だった点です。研究チームは、ブラウザ偽装とIPアドレス偽装のどちらが効いたのか、あるいは両方かは今回の検証だけでは切り分けられないとしています。つまりスコア型であっても万能ではなく、偽装技術の組み合わせ次第で突破される余地が残っています。
ケース別の推奨
決まった手順の古いボットによるクレデンシャルスタッフィング（流出したID・パスワードの総当たり）対策が主目的なら、hCaptchaやTurnstileのような軽量な検出方式で十分なケースが多いはずです。導入コストも低く、ユーザー体験への影響も小さい選択肢です。
生成AIを使った自動入力や自動購入、チケット転売のような「画面を読んで判断するエージェント」への対策を主眼に置くなら、reCAPTCHA v3のようなスコア型、またはProof of Humanのような複合的な検出方式の採用を検討する価値があります。
すでにTurnstileやhCaptchaを導入済みで、AIエージェントによる不正利用の兆候（短時間での大量フォーム送信、不自然に一定間隔の操作ログなど）が監視ログに見られる場合は、検出方式の併用を検討するタイミングです。WAFのログとボット検出システムのログを突き合わせ、通過率の変化を定点観測する運用に切り替えることをおすすめします。
あえて見送るべき条件
一方で、今すぐ全面的な切り替えを急ぐべきではないケースもあります。
対象サービスが低トラフィックで、不正アクセスの実被害がログ上に確認できていない場合は、検出方式の変更よりも先に監視体制の整備が優先です。検出率の数字だけを見て過剰投資するのは避けたいところです。
また、今回の検証は人間の利用者を誤ってボットと判定する「誤検知率」を評価対象に含んでいません。研究チーム自身も今後の課題として言及しています。誤検知が増えればコンバージョン率やサポートコストに悪影響が出るため、検出率の高さだけで即断するのは早計です。本番導入前には必ず自社のトラフィックでA/Bテストを行い、誤検知の発生状況を確認してください。
まとめ
ボット対策の選定は「検出率が高いサービスを選ぶ」という単純な話では済まなくなっています。
まず自社の脅威モデルが「従来型ボット」なのか「AIエージェント」なのかを、アクセスログの操作パターンから切り分けることが出発点です。そのうえで、検出方式・偽装耐性・運用コスト・ログの可観測性という4つの軸で現行システムを棚卸ししてみてください。
次の一歩としては、Cloudflareやhcaptcha.comの管理画面でチャレンジ通過率の推移を確認し、不自然に高い通過率が続いていないかをまず見ることをおすすめします。その数字が、今の検出方式を見直すべきかどうかの一番わかりやすい手がかりになります。