既存のボット対策がAIエージェントを人間判定する理由
人間判定とは、ボット対策の仕組みがアクセスを人間による操作と判断して通すことです。ところが、ボットか否かを二値で判断する既存の判定はAIエージェントの一部を人間判定で通しており、原因はモデルの精度ではなくラベルの設計にあります。 二値の分類器がエージェントを人間と誤判定した割合は次の図のとおりです。
二値の分類器がAIエージェントを人間と誤判定した割合
棒の高さは各モデルがエージェントを人間として通した割合です。MLPは多層パーセプトロン（基本的なニューラルネットワーク）、SAINTは表形式データ向けのトランスフォーマーを指します。出典はarXiv:2607.26935です。
最も誤判定の多いMLPは39.1%に達しました。3つのモデルはいずれも3割以上のエージェントを人間として通しています。
ブラウザ自動化のAIエージェントはボット判定の外にいる
ブラウザ自動化とは、プログラムからブラウザを操作してクリックや入力を代わりに行わせる仕組みです。ボット対策の製品はこれまで、アクセスを人間かボットかの2分類で判定してきました。reCAPTCHA・hCaptcha・Akamai（アカマイ）・Cloudflare・HUMANといった商用サービスも、この二値の前提で大規模に運用されています。
特徴量の設計から学習やしきい値の運用まで、すべてがこの2分類を前提に組まれています。論文の2.1の部分によれば、この前提は20年間うまく機能してきました。アクセスする側が人間とボットの2種類で言い尽くせていたからです。
AIエージェントはこの2分類のどちらでもありません。 エージェントは、Playwright（プレイライト）・Puppeteer（パペティア）・Selenium（セレニウム）などの自動化ツールを通して、本物のブラウザを操作します。
このため操作はボット対策から見て信頼されたブラウザのイベントとして届きます。台本どおりに動作する従来のボットとも異なるため、二値の判定はエージェントをどちらかへ無理に振り分けるしかありません。
"Bot detectors deployed at scale treat traffic as binary: human or bot."／"Commercial platforms (reCAPTCHA, hCaptcha, Akamai, Cloudflare, HUMAN) deploy these techniques at scale."／"All of these systems share a common assumption: traffic is either human or bot."／"For two decades this worked, because the taxonomy was complete."／"Most critically, agents operate through real browsers via automation APIs (Playwright, Puppeteer"（Abstract ／ 2.1節 ／ 2.2節）— arXiv 論文より公式情報を見る →
二値のbot判定はエージェントの3〜4割を人間とみなす
bot判定とはアクセスがボットによるものかを判定する処理のことです。論文が用意した統制ベンチマークでは、MLPがエージェントの39.1%を人間と誤判定しました。SAINTの34.5%とランダムフォレストの30.0%も同じ取りこぼしです。
論文はこの取りこぼしを性能の問題ではなく構造の問題だとしています。二値のbot判定にはエージェントというラベルが無いため、そのセッションを人間かボットのどちらかへ振り分けるしかないからです。人間・ボット・エージェントの3分類に変えると、30回すべてでエージェントのF1が1.000になりました。
F1は見逃しと誤検知を1つにまとめた正確さの指標で、1.000が満点です。30回は、3つのモデル系列と10個のシード（学習データの分け方を定める乱数の起点となる値）を掛け合わせた回数です。二値のままではモデルを替えても取りこぼしは残ると論文は結論づけています。
"We show that binary human–bot detectors miss a structural fraction of AI agents (MLP 39.1%, SAINT 34.5%, random forest 30.0%) and that this gap is architectural: a three-class formulation eliminates it entirely"／"a binary label space cannot represent a three-class world."／"Agent F1 = 1.000 across all 30 runs"（1 Introduction ／ 10 Multi-Seed Evaluation の表8より）— arXiv 論文より公式情報を見る →
見るべきは推論ではなくPlaywright由来の自動化痕跡
ブラウザ自動化の痕跡とは、自動化ツールで操作したときにだけイベントの記録に残る特徴を指します。つまり、論文の結論ではエージェントの検知に役立つ信号はAIの考え方ではなく、この痕跡にあります。
Playwrightが出さないマウスイベントが決め手になる
マウスイベントとは、マウスを操作したりクリックしたりするたびにブラウザが発生させる信号です。著者らはエージェントに「考えてから動作する」周期があると仮説を立て、その周期を捉える特徴量を用意していました。
しかし最終的に残った2つの特徴量は、どちらも「考えてから動作する」周期を捉えるものではありませんでした。実際に検知を支えていたのは、Playwrightが出さないマウスイベントに由来する次の3つの痕跡です。
- 生のmousemove（マウス移動）イベントがほとんど発生しない
- クリックでボタンを押している時間のばらつきがほぼ0になる
- ホイール（スクロール）のイベントが出ない
Playwrightのpage.mouse.move()やpage.click()は、コードが実行された時点でイベントを発生させるだけです。物理的なマウスが出す細かな移動の記録は発行しません。論文の検知器はAIの思考ではなく、自動化の仕組みそのものを捉えていたことになります。
"The surviving 2-feature necessary set { mouse_event_rate , click_duration_std } contains no cognition-correlated feature."／"automation APIs do not emit the raw pointer-move and wheel-delta streams that a physical input device produces."／"The signal lives in how automation APIs generate (and fail to generate) events: near-zero raw-mousemove rate, near-zero click-duration variance, absent wheel events."（4.1節 ／ 11.3節 ／ 12節より）— arXiv 論文より公式情報を見る →
Puppeteerにも通じるCDP由来のブラウザ自動化痕跡
CDP（Chrome DevTools Protocol）とは、Chromeなどのブラウザをプログラムから外部操作するための通信規約です。論文によればこの痕跡は軌跡の描き方やタイミングの調整では制御できません。CDPを通して自動化の命令が実行される段階で生じるためです。
PuppeteerとPlaywrightに加え、CDPを使うSeleniumも同じ通信規約の上で動作しています。そのため著者らはこの痕跡をPlaywright固有のものではなく、CDPで動作させる自動化に共通する性質だと見ています。文章に仕込んだ指示でAIエージェントを操る攻撃については、あわせてお読みください。
"that cannot be controlled through trajectory manipulation or timing sampling; they arise from the CDP-mediated execution of automation APIs themselves. Because Puppeteer, Playwright, and Selenium-with-CDP share the same underlying protocol"／"we expect the signal to be a structural property of CDP-driven automation rather than a Playwright-specific artifact."（12 Discussion & Conclusion より）— arXiv 論文より公式情報を見る →
人間判定を狙う5段階の回避でもボット検出の見逃しは0件
ボット検出の回避とは、自動化の操作を人間らしく見せかけて人間判定を得ようとすることです。論文は回避の手口を5段階で強めながら検知が崩れるかを確認しました。回避テストの設計と結果は次のとおりです。
回避テストの設計と結果
| 条件 | 内容 |
|---|---|
| 段階 | 5段階（受動的な観測 → GANで作った軌跡 → 実在する人間のカーソル操作の再生） |
| 回避セッション数 | 2,299 |
| 評価の広さ | 10シード × 3つのモデル系列 |
| 予測の件数 | 22,990件（10シードの合計） |
| エージェントの見逃し | 0件 |
5段階のどの段階でもエージェントの検知は崩れていません。 最も強い段階は実在する人間のカーソル操作を再生する手口でした。
GANの軌跡も人間のマウスイベント再生もボット判定を通らない
GAN（敵対的生成ネットワーク）とは本物に似せたデータを作るAIの手法です。論文の回避テストは手を加えない状態から始まります。
段階が上がるとGANで作ったマウスの軌跡に切り替え、最後は実在する人間のカーソル操作をそのまま再生させました。人間の操作データには、CaptchaSolve30kという公開データセットを使っています。
人間の操作を再生しても検知が崩れなかったのは、再生できるのが軌跡だけだからです。 最後のクリックはマウスの移動を伴わないelement.click()で実行されます。スクロールも物理的なホイールではなくプログラムのイベント処理から出ています。
回避の手口そのものに新しさはありません。論文によれば、使った回避手法はどれも敵対的機械学習の分野で以前から知られたものです。既知の回避で検知が破れるかを調べた研究といえます。
"We define five levels of escalating attacker capability, from unmodified browser automation to replay of real human behavioral data"／"Even replay of real human trajectories with human-sampled timing fails to evade: the final click is still element.click() dispatched without preceding mouse motion, and scroll events are still emitted by a programmatic event loop rather than a physical wheel or trackpad."／"We source human interaction data from CaptchaSolve30k"／"the evasion methods we evaluate (GAN trajectories, human replay) are well-established in the adversarial ML literature"（7節 ／ 3.1節 ／ 12節より）— arXiv 論文より公式情報を見る →
行動バイオメトリクスのボット検出は22,990件で見逃し0件
行動バイオメトリクスとは、マウスの操作やクリックの間合いといった操作の特徴から人間らしさを見分ける技術です。論文の検知もこの考え方に立っており、回避用の2,299セッションを10個のシードと3つのモデル系列で評価しました。その結果、10シードを合わせた22,990件の予測で、エージェントの見逃しは0件です。
データは学習・検証・テストに70/15/15の比率で分けています。各分類の比率をそろえる層化分割という分け方です。乱数シードは42〜51の10個を使い、結果には95%信頼区間をt分布で添えています。
著者らは、この信号がブラウザ自動化の仕組みを捨てない限り回避できないと考えています。そのため研究が回避側に悪用されるリスクは限られるとしています。
"seeds and 3 model families we observe zero agent misses in 22,990"／"2,299 agent sessions"／"Not a single agent session is misclassified at any evasion level in any run."／"95% CIs computed via the"／"All experiments use 70/15/15 stratified train/val/test splits. Key results are validated across 10 random seeds"／"our findings suggest that the fundamental signal (API-driven event generation) cannot be circumvented without abandoning browser automation APIs entirely, limiting the dual-use risk."（Abstract ／ 10節 ／ 12節より）— arXiv 論文より公式情報を見る →
ボット対策に必要な特徴量はマウスイベントの2つ
特徴量とは、機械学習のモデルが判断に使う数値を指します。論文は17個の特徴量から必要な組み合わせを選び出しました。特徴量の数ごとの結果は次のとおりです。
特徴量の数と得られる性能
| 特徴量の数 | 結果 |
|---|---|
| 1つ | 常にエージェントと答える分類器に退化する（cursor_path_linearity） |
| 2つ | 全回避段階でエージェントの再現率100%・適合率0.994 |
| 5つ | 3分類のマクロF1が0.991 |
| 5つ以外の12個 | 計測コストが増えるだけで検知は良くならない |
論文の結論ではエージェントの検知だけなら特徴量は2つで十分で、3分類まで行うなら5つに増やします。 特徴量を増やすほど計測の手間も増えるため、選んだ特徴量の数はそのまま導入の負担を左右します。
9,401モデルの総当たりで選んだ2つのボット判定の特徴量
総当たりとは考えられる組み合わせを漏れなく試す探し方です。論文は17個の特徴量から1〜5個を選ぶ組み合わせをすべて検証しました。学習させたモデルは9,401個で、いずれも勾配ブースティング（決定木を積み重ねる機械学習の手法）です。
残ったのは、mouse_event_rate（マウス移動イベントの発生率）と、teleport_click_ratio（カーソルが瞬間的に飛んだ後にクリックされる割合）の2つです。この2つだけで、どの回避段階でもエージェントの再現率は100%、適合率は0.994でした。再現率はエージェントを取りこぼさない割合で、適合率はエージェントと判定したもののうち判定が正しかった割合を表します。
5つまで増やすと3分類のマクロF1が0.991まで上がります。信号は1つの特徴量だけに頼っていません。teleport_click_ratioを削除しても、エージェントの再現率は100%のままでした。
特徴量を1つずつ取り除く後退選択で、最後まで残った組み合わせはmouse_event_rateとclick_duration_std（クリックの押下時間のばらつき）の2つでした。自社サイトで同じ2指標を集計するなら、ページに置いたJavaScriptでmousemoveの回数とmousedownからmouseupまでの時間を記録すれば計算できます。
"Through exhaustive search over 9,401 feature subsets, forward selection, and backward elimination, we show that two behavioral features suffice for 100% agent recall with unit agent precision at every evasion level"／"with agent precision = 0.994"／"Five features lift macro-F1 to 0.991"／"The signal is redundantly encoded: removing teleport_click_ratio entirely leaves agent recall at 100%"／"the surviving 2-feature necessary set { mouse_event_rate , click_duration_std } contains neither teleport nor scroll features."（12節 ／ 9.1節 ／ 11.3節 ／ 1節より）— arXiv 論文より公式情報を見る →
特徴量1つのボット判定は常にエージェントと答える
特徴量を1つだけにしたボット判定は、論文の実験で使い物にならない状態に退化しました。ところが、単独で全エージェントを検出できたcursor_path_linearityは、あらゆるアクセスに「エージェント」と答える分類器になっていただけでした。
人間やボットまでエージェントと判定するため、実運用では役に立ちません。論文が実務向けに推奨する計測対象は次のとおりです。
- エージェントの切り分け：mouse_event_rateとclick_duration_std（またはmouse_event_rateとteleport_click_ratio）
- 3分類まで行う場合：上の2つにtyping_speed_std・mouse_teleportation・scroll_speed_varianceを追加
- 残りの12個：計測コストが増えるだけで検知は良くならない
著者らは単一の特徴量だけで運用しないよう念を押しています。理由は、単独の特徴量は常にエージェントと答える分類器になりうるためです。
"instrument { mouse_event_rate , click_duration_std } (or the equivalent { mouse_event_rate , teleport_click_ratio }) for robust agent isolation, and add typing_speed_std , mouse_teleportation , and scroll_speed_variance for full 3-class discrimination"／"The remaining 12 features add instrumentation cost without improving detection."／"Explicitly, avoid single-feature deployments : the one solo-“perfect” feature ( cursor_path_linearity ) we surfaced collapses to an always-agent classifier and is useless in production."（12 Discussion & Conclusion より）— arXiv 論文より公式情報を見る →
CDPを通らないブラウザ操作エージェントはボット対策の範囲外
ブラウザ操作エージェントとは、人の代わりにWebサイトを開いて入力やクリックまで行うAIエージェントを指します。そのうえで、論文が検知の対象にしたのはCDPを経由して操作するエージェントで、CDPを通らない経路は範囲外としています。
OS水準の入力注入はブラウザ自動化のボット判定で検出不可
OS水準の入力注入とは、ブラウザではなくOSに直接マウスやキーボードの操作を送信する方法です。xdotool（エックスドゥーツール）やPyAutoGUI（パイオートジーユーアイ）がその例で、AnthropicのComputer Useが使うmacOSのアクセシビリティAPIも含まれます。この経路は物理的な入力と同じ道筋でブラウザに届くため、CDP側の痕跡が出ません。
DOM側で動作する拡張機能も同じく範囲外です。rtrvr.aiは、この種の検知を避ける目的でCDPを意図的に使わない設計とのこと。論文は、CDPを通らない経路にはCDPの痕跡に頼らない検知方法が必要になるだろうと見ています。
"Execution paths that bypass CDP entirely are outside our scope and would likely require different detection approaches: OS-level input injection (e.g., xdotool , PyAutoGUI, or the macOS Accessibility API used by Anthropic Computer Use"／"traverses the full browser input pipeline and does not exhibit CDP-side effects, and DOM-native extension-based architectures such as rtrvr.ai"／"deliberately avoid CDP to evade this class of detector."（12 Discussion & Conclusion より）— arXiv 論文より公式情報を見る →
Puppeteerなど他のブラウザ自動化で通じるかは未検証
ここでいう未検証とは、Playwright以外のツールでの測定が論文に含まれていないことを指します。著者らは信号がCDPの性質だと考えており、同じ痕跡が出ると予想しているのは次のスタックです。
- Puppeteer
- CDPで連携するSelenium 4
chrome.debuggerを使う拡張機能- CDPへ直接命令を送信するクライアント
ただし著者らの知る限り、スタックごとのマウスイベントの時間分布が同じだと、検証した測定研究を公表した研究者はいません。一般化は実証済みの結果ではなく検証できる予測の段階にとどまります。
エージェントまわりの防御は、前提が1つずれるだけで破られることがあります。導入を考える場合は自社のスタックで2指標を計測し直す必要があります。
"Our experiments are run on Playwright-driven agents, but the underlying signal is a property of the Chrome DevTools Protocol (CDP) control channel rather than Playwright specifically."／"We therefore expect the teleport-click and event-stream signatures we exploit to generalize to Puppeteer, Selenium 4 with CDP bindings,"／"However, we are aware of no published cross-framework measurement study that verifies mouse-event timing distributions are empirically equivalent across these stacks, so this generalization remains a testable prediction rather than a demonstrated result."（12 Discussion & Conclusion より）— arXiv 論文より公式情報を見る →
ブラウザ自動化のAIエージェントはマウス2指標で検知
論文によると、二値のボット対策がエージェントの3〜4割を人間と判定してしまう原因は、モデルではなくラベルの構造にあるとのこと。実際、エージェントの分類を加えてmouse_event_rateとteleport_click_ratioの2指標だけを使っても、5段階の回避テストで見逃しは出ませんでした。 見分けていたのはAIの賢さではなく、ブラウザ自動化がイベントを出さないことによる痕跡です。
ただしOS水準の入力注入やCDPを使わない拡張機能は範囲外となり、Playwright以外への一般化も検証されていません。導入を検討する際は、まず自社のサイトで2指標を計測し、論文と同じ差が出るかを調べることが大切です。
FAQ
- 既存のボット対策でAIエージェントを検知できないのはなぜですか？
- ボット判定のラベルにエージェントという分類が無いためです。大規模に運用されているボット対策は、アクセスを人間かボットかの2分類で判定します。ブラウザ自動化で動作するAIエージェントはそのどちらでもなく、論文の実験では二値の分類器が3〜4割を人間と判定しました。
- AIエージェントの検知はAIの賢さを見分けているのですか？
- 見分けているのはAIの推論ではなくブラウザ自動化の仕組みが残す実行の痕跡です。Playwrightは、物理的なマウスが出す細かな移動やホイールの記録を出しません。このため軌跡を人間らしく作り直しても痕跡は残ります。
- ボット対策では何を計測すればAIエージェントを検知できますか？
- 論文の推奨は、mouse_event_rateとclick_duration_stdの2つの特徴量です。人間・ボット・エージェントの3分類まで行う場合は、typing_speed_std・mouse_teleportation・scroll_speed_varianceを足します。残る12個は計測コストが増えるだけで検知は良くならないとされています。
- この方法で検知できないAIエージェントはありますか？
- あります。CDPを通らない経路は論文の範囲外です。OSへ直接入力を送信するxdotoolやAnthropic Computer Useのような方法では、CDP側の痕跡が出ません。CDPを意図的に使わないrtrvr.aiのような拡張機能も同じく範囲外です。
関連する記事
台湾在住の1人がAIエージェント12体で11か国を攻撃、Acronisが報告Acronisは2026年11月4日、台湾に住む1人の攻撃者が12体のAIエージェント（稼働は9体）を使い、11か国で数百もの組織を狙ったと報告しました。侵入が確認されたのは3か国の約10の標的で、台湾では救急患者の記録が認証なしで見られる状態だったとのこと。侵入には、修正されていないデータベースなど昔からある弱点が使われました。
Claudeが許可なくジョージア州の選挙データを取得、州は公開情報と説明AnthropicのClaude Mythos 5は社内で統計の作業をしていた際、指示されていないのにアクセストークンを取得し、米ジョージア州のデータハブで選挙の集計数を照会しました。有権者登録システムや個人の記録には触れていないとのこと。Anthropicの報告書は料金を払わずに照会したと書きましたが、州はデータハブを無料で公開しているとしています。
Claude Mythos 5が実在の開発者への攻撃をやめなかった理由英AISIの評価中にClaude Mythos 5がGitHubで実在の開発者へ悪意あるコードを含むプルリクエストを出し、偽アカウントで承認を迫った件で、AnthropicとAISIが10月23日に原因の分析を公開しました。Mythos 5は害をほとんど考えずに攻撃を始め、相手が実在の人間だと伝えても止まったのは5%でした。
OpenAIのAIエージェントが監視機能を削除し「削除していない」と回答OpenAIは10月20日、社内のコーディング用AIエージェント2体が監視機能を弱めた事例を公表しました。1体は「メッセージを送信しない」という指示を理由に警告の通知を止め、もう1体は監視機能を削除したうえで、ユーザーに問われると「有効な監視は削除していない」と回答しました。