Webボットとボット検知技術の短い歴史

• Webボットは、単純なHTTPクライアントのリクエストから実際のブラウザ自動化まで発展してきており、それに対抗してボット検知手法も継続的に高度化している
• IPレピュテーション、TCP/TLS/ブラウザ環境フィンガープリント、JavaScriptベースの行動分析など、さまざまな技術がボット検知に活用されている
• Headlessブラウザ、プロキシ、User-Agent改ざんなどのボット回避手法は進化しているが、検知アルゴリズムも同時に進化し、両者の「いたちごっこ」が続いている
• 最近では、行動データベースのAIモデルを活用した高度な行動分析まで組み合わさり、ボット検知はさらに複雑化している
• CAPTCHA、プロキシ検知、Proof-of-Work、行動ベース認証などの多層防御体制が一般化しつつある

---

導入: Webボットと検知技術の進化

• Webボットには、単純なクローラー・自動化スクリプトから、実際のユーザーのように振る舞う高度なプログラムまで、さまざまな種類が存在する
• 検索エンジンやアーカイブボットのような有益なボットもある一方、スパムや違法スクレイピングなど問題のある利用も多い
• サイト運営者は初期のころからボットとの戦いを続けており、検知・回避手法は同時に高度化してきた

最も単純なボット: HTTPクライアント

• curl、wget などの単純なHTTPクライアントでサイトにリクエストを送る方式が、最も基本的なボットである
• すべてのHTTPクライアントは User-Agent ヘッダーに自身を露出するため、サイト側は容易に検知・遮断できる
• User-Agentをブラウザに偽装しても、ブラウザは追加のヘッダー（言語、エンコーディングなど）を含むため、完全な擬装でなければ依然として検知される

IPレピュテーションとプロキシ

• サーバーはIPアドレスを活用してボットを検知する。特にクラウド・データセンターのIP帯域は、ボット/自動化トラフィックと見なされ、信頼度が低い
• プロキシなしで運用するとすぐに遮断されるため、住宅系/モバイルプロキシでIPを迂回する必要があり、そのためのコストがかかる
• サイトはIPレピュテーション、プロキシポート（1080など）の開放有無、IP帯域、接続パターンなどを積極的に点検する
• IPブロックを回避するために、**ローテーティングプロキシ（rotating proxy）**やモバイルプロキシなどが利用される

TCPフィンガープリント（TCP Fingerprinting）

• HTTPリクエストの前にTCP接続を確立する際、OSごとにTCPパケットの構成方法が異なるため、これを分析してOSを識別できる
• User-Agentと実際のOS（TCPフィンガープリント）が一致しない場合、ボット/偽装トラフィックと判断される
• プロキシサーバーもTCPフィンガープリントに影響を与えることがあるため、プロキシ選定時にはOS一致の有無を考慮する必要がある

TLSフィンガープリント（TLS Fingerprinting）

• TLSハンドシェイクの過程では、対応する暗号方式、バージョン、拡張などがブラウザ/OSごとに異なる
• TLSフィンガープリントを通じてブラウザ、OS、ライブラリ種別を推定し、User-Agentと相互検証できる

JavaScript検知

• サーバーはレスポンス前、またはページ読み込み後にJavaScriptでクライアント環境・行動情報を追加収集する
• ボットがJavaScriptを実行しなければ即座に検知され、ボット側もSelenium、Puppeteer、Playwrightなどのブラウザ自動化ツールを使って対応する
• 単純なHTTPリクエスト水準からブラウザ自動化へと進化している

Headlessブラウザと検知

• Headlessモード（ウィンドウのないChromeなど）はボット開発に不可欠だが、navigator.webdriver などの固有プロパティ、空のプラグインリストなど、さまざまな相違点により検知が可能である
• 各種プロパティをパッチして偽装できるものの、数十個のヒントをすべて処理する必要があり、新たな検知ポイントも継続的に登場する
• 2023年から導入されたNew Headlessモードは実際のChromeと同じエンジンを使用するため、検知がさらに難しくなっている

オーケストレーションフレームワーク検知とIPC

• Selenium、Playwrightなどの自動化フレームワークは、固有フラグ・オプション、ブラウザバージョン、環境構成において特徴を露出する
• 例: --disable-ipc-flooding-protection などのフラグは、ボット環境を識別する手がかりになる
• 一部のJS関数（例: window.history.pushState）を過度に呼び出し、IPC flood状態を誘発して検知することも可能

プロキシ検知: JSベースの高度化

• Latency（遅延計測）: WebSocketなどで測定した全体遅延とTCP遅延の差を比較し、プロキシの存在有無を確認する
• WebRTC Leak: ブラウザのWebRTCを利用して実際のクライアントIPを取得し、HTTPリクエストのIPと比較して不一致ならプロキシ/ボットを疑う
• DNS Leak: JavaScriptで任意のサブドメインへリクエスト → DNSサーバーの位置/IPを通じて異常なパターン（国の不一致など）を検知する
• Timezones: ブラウザのタイムゾーンとIP位置を比較して、プロキシ利用・偽装を検知する

CAPTCHAと認証

• CAPTCHAはボット検知/遮断を目的とした別個の認証であり、人間が解ける問題（文字認識、クリックなど）で構成される
• 最近では、Proof-of-WorkベースのCAPTCHA（計算作業を課す）、行動ベースCAPTCHA（単純クリックと行動分析の組み合わせ）が導入されている
• 大半のボットは低価格の外部CAPTCHAソルバーサービスを活用してCAPTCHAを回避する

単純/高度な行動分析

• 行動分析は、マウスの動き、キー入力パターン、クリック位置・速度など、人間の行動特有の非効率性と多様性を分析する
  • 例: マウスの曲線移動、クリック遅延、キー入力間の時間差、モバイル機器の orientation/motion イベントなど
  • ボットは直線移動、一定/高速タイピング、非現実的な反応速度などから容易に露見する
• 高度な行動分析は、大規模な人間・ボット行動データを収集・学習し、AI/機械学習で微細なパターンまで識別する
  • 例: マウス移動軌跡、キーストローク間の微妙な時間差、ページ探索パターンなど、複合データに基づく分類

結論と示唆

• Webボット vs. 検知技術は絶え間ない進化と対抗の戦いであり、静的フィンガープリント・行動分析・AIベース検知まで、さまざまな手法が組み合わせて使われている
• 各種の回避・偽装手法があるにもかかわらず、サービス運営者は多層的な検知体制、リアルタイム行動分析、AIモデルなどで対応しており、継続的なアップグレードが必要である
• ボット開発者は完璧な偽装環境を構築するうえで限界があり、最新の検知トレンドと対応方法への理解が不可欠である