「User-Agentをブラウザっぽくしたのに403」「ヘッドレスをやめても弾かれる」——そんな経験、ありますよね。Akamai・Cloudflare・ImpervaのBot対策が強い理由は、HTTPヘッダだけでなく通信層（TLS/HTTP2）・実行環境（JS/端末指紋）・行動（セッションの流れ）を重ねてスコア化し、さらにグローバル規模の観測データで更新し続けているからです。本記事では、検知の“中身”を分解して説明します。 Akamai・Cloudflare・Impervaがスクレイピングを検知できるのは、単発リクエストの特徴だけでなく、「そのクライアントは本当にブラウザか」と「そのセッションは人間の操作フローか」を、複数レイヤーの信号で突き合わせるからです。代表的には次の3レイヤーです。 重要：対策ベンダーは「1つの強い検知」で勝つというより、弱めの検知を多数重ねて誤検知を抑えつつ、回避コストを上げる設計を取ります。Cloudflareは機械学習・挙動分析・フィンガープリンティングを組み合わせる方針を明記しています。 スクレイピング実装が「HTTP的に正しそう」に見えても、TLSハンドシェイクやHTTP/2の振る舞いはライブラリ差が露骨に出ます。ここが最初の分水嶺です。 CloudflareはBot Managementの機能としてJA3/JA4フィンガープリントを扱えることをドキュメント化しています。 なぜAkamai・Cloudflare・Impervaはスクレイピングを検知できるのか？Bot対策の仕組みを技術的に解説
この記事でわかること
まず結論
検知の3レイヤー
ネットワーク層の指紋
クライアント層の信号
次に効くのが、JavaScriptで取得できる実行環境の整合性です。いわゆる「端末指紋」や「ヘッドレスの兆候」がここに入ります。
- JSチャレンジ/JS検知：HTMLを1回返してJSを実行させ、実行結果を検知に利用
- 指紋の整合性：UA・画面サイズ・WebGL/Canvas・フォント・タイムゾーンなどの整合
- 自動化の兆候：navigator系の不自然さ、イベント発火の偏り、実行時間のパターン
注意：「JSを実行しないHTTPクライアント」は、この層の信号が空になるため不利です。対策側はそれ自体を“リスク”として扱えます（もちろんAPIなど例外もあります）。
Cloudflareのドキュメントでは、JavaScript Detectionsは最初のリクエストではデータが無く、HTMLリクエスト後に挿入・クッキー発行が行われる流れが説明されています。また、cf_clearanceはJavaScript detectionsに必要とされています。
行動層のスコアリング
最終的に効いてくるのが、セッションを通した行動の違和感です。スクレイピングは「人間の導線」から外れやすい。ここが肝心なところです。
- リクエストレート：一定周期・同一間隔・過度な並列
- 遷移の不自然さ：参照元の欠落、ページ→画像→JSの読み込み順が人間と違う
- 状態の不整合：Cookie/ローカルストレージ/キャッシュの扱いが“ブラウザらしくない”
- 同一性の破綻：IPは同じなのに指紋が変わる、逆に指紋は同じなのに分散しすぎる
Cloudflareは「機械学習・行動分析・フィンガープリンティング」を組み合わせて分類すると説明しています。AkamaiもBot ManagerでAI/MLによる挙動分析やブラウザ/デバイスのフィンガープリンティング、HTTP異常検知、ユーザー操作信号などの多層検知を掲げています。
Cloudflareの仕組み
CloudflareのBot対策は、エッジでの評価（ML/ヒューリスティクス/挙動）に加え、必要に応じてJavaScript由来の信号を重ねます。技術要素として押さえるポイントは次の通りです。
検知エンジンの分業
Cloudflareのドキュメントでは、Bot検知エンジンの概念が整理されています。特にJSD（JavaScript Detections）エンジンは、ヘッドレスブラウザ等の悪性フィンガープリントを識別する、と説明されています。また__cf_bmクッキーがボットスコア算出を平滑化する用途で触れられています。
クッキーで継続評価
__cf_bmは、Bot ManagementやBot Fight Modeで配置され、ボットスコア計算に関連する情報を含む、とCloudflareは説明しています。さらにAnomaly Detectionが有効な場合はセッション識別子も含まれる旨が記載されています。つまりCloudflareは「単発」よりも「継続」を強く見ます。
JS検知の前提条件
JavaScript Detectionsは、最初のリクエストでは情報が揃わないことが多く、HTMLが一度必要とされています。ここで「APIだけ叩く」実装は不利になりやすい、という構造が見えてきます。
Akamaiの仕組み
Akamai Bot Managerは、挙動分析や指紋、HTTP異常などの多層検知を明示しています。Akamaiは「軽量スクリプトの挿入」によってクライアント側テレメトリを有効化できる、と説明しており、行動層の信号取りにも力点があります。
多層検知の組み合わせ
Akamaiの公開情報では、AI/MLによる挙動分析、ブラウザ/デバイスのフィンガープリント、HTTP異常検知、自動ブラウザ/ヘッドレス検知、ユーザー操作信号などを挙げています。製品ブリーフでも「ユーザー行動分析、ブラウザ指紋、自動化ブラウザ検知、HTTP異常、高リクエストレート」などが並びます。
クライアント信号の収集
Akamaiは、クライアント側の行動テレメトリを「軽量スクリプトを挿入して有効化」できる旨を記載しています。これにより「リクエストの並び」「画面操作に伴うイベント」など、スクレイピングが苦手な領域の差分を取れます。
検知メソッドの体系
Akamaiのドキュメント（TechDocs）では、Bot Managerが様々な検知メソッドを提供することが説明されています。実運用では「カテゴリ」「スコア」「アクション（許可/監視/チャレンジ/遮断）」に落として制御します。
Impervaの仕組み
ImpervaはAdvanced Bot Protectionで、行動分析・デバイスフィンガープリント等の「高度な手法」を使い、700以上の次元（dimensions）で指紋を作る、と説明しています。ポイントは、指紋が単一パラメータではなく、多変量であることです。
700+次元の指紋
Impervaの製品ページでは、700以上の次元で人間・良性ボット・悪性ボットを分離し、回避に強いユニークフィンガープリントを作る旨が述べられています。これは「ヘッダを整える」程度では追いつかない設計だ、と読み解けます。
行動分析と指紋の併用
同ページでは、行動分析・デバイスフィンガープリントなどの手法で、ユーザーを邪魔しにくい形でボットを識別・遮断する方向性が示されています。つまり「怪しいものは全部CAPTCHA」ではなく、裏側で静かに分類する比重が高いタイプです。
3社の比較
実際の実装はブラックボックスですが、公開情報から整理できる範囲で「何を軸にしているか」を比較します。
| 観点 | Cloudflare | Akamai | Imperva |
|---|---|---|---|
| 基本方針 | ML・挙動分析・指紋を併用 | 多層検知＋ポリシー応答 | 多次元指紋＋行動分析 |
| JS由来の信号 | JavaScript Detections、cf_clearance等 | 軽量スクリプト挿入でテレメトリ | （詳細は非公開だが）指紋/行動の併用を明記 |
| ネットワーク指紋 | JA3/JA4の提供を明記 | HTTP異常検知を明記 | 次元数の多さを明記 |
| スコア/分類 | ボットスコア関連のクッキー運用を明記 | Bot Score（0-100）を提示 | 人/良性/悪性の分離を強調 |
検知される典型例
API直叩きでJS無し
HTMLを踏まずにJSON/APIだけを叩くと、JS由来の信号が得られず、セッションとしての整合も作りにくい。結果としてスコアが上がらず、チャレンジやブロックにつながることがあります。
TLSがブラウザと違う
curl系・requests系・一部の自動化ランタイムは、TLS/HTTP2の指紋が実ブラウザと一致しません。ヘッダだけ似せても、ネットワーク層で「違う」と判断されます。
遷移が人間っぽくない
人間は、検索→一覧→詳細→戻る、のような導線を持ちます。一方、スクレイパーは詳細を総当たりしがちで、参照元や静的リソース取得が薄い。行動層で差が出ます。
同一性が壊れる
セッション中にIPだけ変える、指紋だけ変える、Cookieを捨てる、といった“整合性の破綻”は、むしろボットらしさを強めます。Bot対策は「矛盾」を好みます。
対策の考え方
ここでは回避手法の提供ではなく、設計・運用としての現実的な対応を整理します（法令・利用規約・robots.txt等の確認も前提です）。
正規経路を探す
最優先は、公式API、データ提供、提携、エクスポート機能の利用です。Bot対策が厚いサイトほど、非公式スクレイピングはコストが跳ねます。
負荷と頻度を下げる
必要データを絞り、差分取得、キャッシュ、更新頻度の最適化を行いましょう。「高頻度・大量」は検知にも運用コストにも直結します。
失敗を前提に設計
チャレンジ/403/429は起きます。リトライ戦略、回復、観測（どの段で落ちたかのログ化）を作ることが、実務では効きます。
import time
import random
def backoff(attempt: int, base: float = 1.0, cap: float = 60.0) -> float:
"""指数バックオフ + ジッター（検知回避目的ではなく、失敗時の再試行制御のため）"""
exp = min(cap, base * (2 ** attempt))
return exp * (0.5 + random.random())
for attempt in range(6):
try:
# request() など
pass
except Exception:
time.sleep(backoff(attempt))守りたい側の視点
もし自社サイトを守る立場なら、Bot対策ベンダーが見ている3レイヤーを意識して、次を整えるのが近道です。
- 重要画面（ログイン/検索/カート等）に対し、ボットスコアで段階的に制御
- 良性ボット（検索/監視/提携）と悪性ボットを分けて扱う
- 誤検知を恐れて「全部許可」より、観測→限定適用→拡大の順で運用
公式情報の引用
Cloudflare Bot Management uses machine learning, behavioral analysis, and fingerprinting to accurately classify bots.
収集設計を相談しませんか？
Bot対策が強いサイトは、技術だけでなく要件・頻度・導線設計で難易度が大きく変わります。目的に合うデータ取得設計を一緒に整理できます。
まとめ
- Akamai・Cloudflare・Impervaは「ネットワーク層」「クライアント層」「行動層」の信号を重ねてスコア化するため、スクレイピングを検知しやすい
- CloudflareはJA3/JA4やJavaScript Detections、
__cf_bm/cf_clearanceなど継続評価の仕組みが整理されている - Akamaiは多層検知（挙動分析・指紋・HTTP異常など）と、クライアント側テレメトリ（スクリプト挿入）を明記している
- Impervaは700+次元の指紋など、多変量での分類を前面に出している
