DataDome vs Akamai vs Cloudflare ボット対策の比較（2026年版）

私たちは hellworld.io のフルラインナップを再販しています。14 の住宅用ブランド（ローテーション式、GB 単位で販売）、3 つの 4G モバイルプール（FP-Mobile / ET-Mobile / HD-Mobile）、Static ISP（IP 単位・月額）、そして 2 つの無制限プラン（Unlimited ISP / Unlimited Residential）。そのすべてでマージンを得ています。ですから、どのプロキシがどのボット対策ベンダーに通用するかを書くとき、正直に言える立場はこうです。私たちはどれか一つに肩入れする理由がありません。Lumi を私たちから買うお客様も直接買うのと同じ小売価格を払いますし、F-Oxylab を買う方も FP-Mobile を使う方も同様です。私たちの動機はただ一つ、あなたが正しいツールを素早く見つけ、乗り換えをやめ、契約を続けてくれること。これだけです。読み進める際は、このバイアスを念頭に置いてください。

これは 2026年シリーズの第 2 弾です。第 1 弾は 14 ブランド実測テスト で、プロキシネットワークそのものを比較しました。今回は反対側、つまりそれらのプロキシが突破しようとしているボット対策スタックを見ていきます。今後の記事では各ベンダーを 1 つずつ掘り下げます。本稿はその全体地図だと考えてください。

2026年に「WAF」より「ボット対策」という枠組みが役立つ理由

多くの購入者向けガイドは今なお WAF の話をしています。WAF とは Web アプリケーションファイアウォールのことです。HTTP ペイロードを見て「これは SQL インジェクションか? XSS 文字列か? パストラバーサルか?」と問う層です。有用ではありますが、プロキシのお客様が実際に抱える問題とは、ほとんど別軸の話です。

ボット対策は別の層です。リクエストボディが無害かどうかには関心がありません。関心があるのは「あなたが誰か」です。具体的には 3 つ。あなたが来た IP のレピュテーション、使っているブラウザやクライアントのフィンガープリント、そしてリクエスト間の行動シグナルです。WAF はボット経済より前から存在していました。ボット対策スタックが生まれたのは、WAF ではスクレイパーと購入者を見分けられなかったからです。

2026年のプロキシのお客様にとって、WAF が問題になることはまれです。私たちが目にする「プロキシが動かない」というサポートチケットのほぼすべては、WAF ではなくボット対策が原因です。HTTP リクエスト自体は問題ありません。IP のスコアが低く付けられたか、TLS フィンガープリントが user-agent と一致しなかったか、Cookie チェーンにサイトが期待するチャレンジトークンが含まれていなかったか、です。そのどれも、従来の意味でのファイアウォールの挙動ではありません。

ですからプロキシを選ぶとき、対象サイトの WAF はほとんどノイズです。その前段に立つボット対策ベンダーこそが、効いてくる変数です。本ガイドはそこを扱います。

押さえるべき 6 つのベンダー

世の中にはボット対策製品が数十種類あります。そのうち 6 つが、私たちのお客様が実際に直面する高防御トラフィックの圧倒的大部分をカバーしています。ラインナップはこちらです。

ベンダー	遭遇する場面	検知スタイル	プロキシ戦略（おおまか）
Cloudflare Bot Management + Turnstile	あらゆる場所 — 最大の CDN フットプリント	IP レピュテーション + JS チャレンジ + TLS	住宅用が望ましい。データセンターはしばしば失敗
DataDome	EC・メディア・クラシファイド	多層スコア：IP + フィンガープリント + 行動	モバイルが最も安定。格安プールはしばしば失敗
Akamai Bot Manager (BMP)	スニーカー・航空会社・銀行・大手小売	センサーデータのペイロード + Cookie チェーン	スニーカーはモバイル / ISP。住宅用は当たり外れ
PerimeterX (HUMAN)	Supreme・StubHub・チケッティング	_px Cookie ファミリー + JS + 行動	モバイルが強い。住宅用ローテーションはしばしば弱い
Queue-it	Ticketmaster・ドロップ・行政サービス	仮想待合室（ボット対策ではない）	スティッキー ISP / スティッキーモバイル。ローテーションは逆効果
Kasada	ANZ 系銀行・Twitch・行政	WASM クライアントサイドチャレンジ	IP への依存度は低い。ソルバーがより重要

この表について 2 つ注意があります。第一に、「プロキシ戦略」はサポートチケットで見られるおおまかな傾向であって、保証ではありません。各ベンダーは顧客ごとに設定をチューニングします。Nike の Akamai と Delta の Akamai は別物です。第二に、ベンダー間の境界はぼやけています。サイトが 2 つのシステムを重ねることは日常茶飯事です。前段に Cloudflare・後段に DataDome、あるいは店頭は Akamai・チェックアウトは PerimeterX、といった具合です。「どのプロキシを使うべきか」の正解は、実際にどの層がブロックしているかに依存し、それはサイトごとに変わります。

次のセクションから、各ベンダーを順に見ていきます。

Cloudflare Bot Management と Turnstile

Cloudflare は巨象です。現代の Web の巨大な一角の前段に陣取っており、その Bot Management 製品は、ほとんどのプロキシのお客様が最初に出くわす相手です。

まずは公開されている仕組みから。Cloudflare はすべてのリクエストに 0〜99 の BotScore を割り当てます。Cloudflare 自身のドキュメントでは、1 は確実にボット、99 は確実に人間、中間帯は判断が不確実、と説明されています。サイト運営者はこのスコアの上にルールを書きます。30 未満はブロック、60 未満はチャレンジ、80 超は許可、といった具合です。スコアを消費するのはサイト側の WAF とレートリミッターであり、何をブロックするかを決めるのは Cloudflare 自身ではなく顧客です。

このスコアは複数のシグナルの積み重ねで構築されます。IP の ASN レピュテーションが入力の一つ。JA3 / JA4 の TLS フィンガープリントもその一つ。HTTP/2 のフレーム順序。結果を返すブラウザ側の JS チャレンジ。セッションをまたいだ行動パターン。これらのどれ一つとして単独では決定的ではありません。Cloudflare はそれらを組み合わせます。

Turnstile は目に見えるチャレンジ面です。多くのサイトで reCAPTCHA を置き換えたウィジェットで、2022年に v1 としてローンチされ、2025年に v2 へ更新されました。Turnstile を通過すると、ブラウザはそのセッションを保証する cf_clearance Cookie を受け取ります。この Cookie は短命でフィンガープリントに紐づくため、別のブラウザの cf_clearance を使い回すと、まず失敗に終わります。

さてプロキシの観点です。Cloudflare はデータセンターの ASN がデフォルトで高いボットリスクを帯びると公言しています。これは彼ら自身のマーケティング資料にある話で、私たちの作り話ではありません。ですから既知のデータセンター IP からのリクエストは、他のシグナルが届く前から、スコア上のハンデを背負ってスタートします。住宅用とモバイルの IP はより高い位置からスタートします。ISP プロキシは技術的にはデータセンターでホストされていながら住宅用 ASN 上にあるため、その中間に位置し、プロバイダーごとに挙動が異なります。

私たちのサポートチケットでは、Cloudflare で保護された対象こそ、「なぜプロキシが動かないのか」という最も頻出する質問です。パターンは繰り返されます。お客様が Cloudflare を前段に置くサイトをスクレイプしようと格安住宅用プールを買い、チャレンジに遭遇し、プレミアムプールに切り替えて通過する。あるいは、すでにプレミアム住宅用を使っていて、実は問題が IP ではなく TLS フィンガープリントだった、という場合もあります。Cloudflare はその両方を罰します。

私たちのいつものサポートの流れはこうです。お客様が Cloudflare で失敗している場合、まず HTTP クライアントが本物のブラウザの TLS フィンガープリントを出しているかを尋ねます。デフォルトの urllib3 を使った Python の requests スクリプトは、IP がどれだけクリーンでも自動化として識別されます。フィンガープリント側が対処済みなら、次に IP 層が効いてきます。その場合は Lumi または F-Oxylab の住宅用プールに寄せがちです。リトライで通過したという報告がそうでない場合より多いからです。どちらもプロキシ比較ページからリンクしています。

Turnstile は特に、BotScore 単体よりも手強い相手です。ブラウザ内で JS を実行し、エントロピーを収集し、トークンを送出します。このチャレンジをスキップするには、本物のブラウザでレンダリングするか、サードパーティのソルバーを使うか、すでに有効な cf_clearance Cookie を持つセッション経由でルーティングするか、のいずれかです。これらは厳密にはプロキシの問題ではなく、クライアント側の問題です。プロキシは IP レピュテーションを与え、クライアントはチャレンジトークンを与えます。お客様がこの 2 つを混同し、問題が自分のヘッドレス構成にあるのにプロキシを責める、というのをよく見ます。

Cloudflare バイパス戦略の詳しい掘り下げは、本シリーズの後の記事で独立して扱います。

DataDome

DataDome は、サポートチケットで 2 番目によく見るベンダーです。特に EC、クラシファイド、メディアをスクレイプするお客様からよく上がってきます。

彼らの公開ドキュメントは多層スコアリングのアプローチを説明しています。DataDome が自社資料で説明する層は、IP レピュテーション、ブラウザフィンガープリント、行動シグナル、そしてその上に乗る機械学習です。各層がスコアに寄与します。サイトには内部を見せずに、許可・チャレンジ・ブロックという判定だけが見えます。

目に見える Cookie は datadome です。これは通過に成功すると設定され、スコアが下がるまで保持されます。クリーンなシグナルと汚れたシグナルが混在するセッションは、途中で Cookie を失いやすく、それが「さっきまで動いていたのに今は動かない」という形で表面化します。

DataDome のチャレンジは JS のインタースティシャルです。実行され、収集し、Cookie を付与するか CAPTCHA を表示するかします。CAPTCHA 自体は下流の症状です。それを目にした時点で、スコアはすでにあなたを許可しきい値より下に落としているのです。

プロキシ側について、おおまかな業界の共通認識はこうです。DataDome に対しては、モバイルキャリアが住宅用よりスコアが良くなりやすく、住宅用がデータセンターよりスコアが良くなりやすい、というもの。これは DataDome がキャリアを明示的にホワイトリスト化しているからではありません。キャリア IP が何百万もの正規ユーザーと共有されており、共有スコアリングが彼らに有利に傾くからです。これに数値を付けるつもりはありません。このパターンはベンダーのブログ、スクレイピングフォーラム、そして私たち自身の顧客層を横断して現れます。

格安住宅用プールは、私たちが見る一貫した失敗パターンです。お客様が安いプールに登録し、DataDome の対象に向け、リクエストはほぼ即座に失敗します。安いプールの IP は素早く再利用され、しばしば攻撃的なスクレイパーを走らせる多数の顧客間で共有されており、IP レピュテーション層がそれをフラグします。同じお客様がプレミアム層に移ると、成功率が跳ね上がります。その跳ね上がりが価格差に見合うかどうかは、ボリューム次第です。一度きりのスクレイプなら、安いプール + リトライで十分なこともあります。本番のデータパイプラインなら、安いプールは失敗リクエストでプレミアム以上のコストを焼くことになります。

長期運用の DataDome 案件では、モバイルプールかプレミアム住宅用にお客様を案内する傾向があります。どちらも住宅用とモバイルの製品ページに掲載しています。両者の選択は、ほぼリクエストボリュームとコスト上限の問題です。

Akamai Bot Manager (BMP)

Akamai は大手小売、航空会社、銀行におけるヘビー級です。Nike、Adidas、Footlocker、Delta、United、あるいはほとんどの大手銀行でスクレイプや購入をするなら、相手は Akamai です。

技術的な表層は、公開されているリバースエンジニアリングの解説記事でよく文書化されています。Akamai BMP は JS を介して大量のブラウザフィンガープリントデータを収集します。マウスの動き、画面サイズ、プラグインの列挙、タイミング、ポインターイベント、その他もろもろ。その塊はシリアライズされ、base64 エンコードされ、「センサーデータ」としてサーバーに POST されます。サーバーはそれをスコアリングし、_abck Cookie を設定します。

_abck Cookie の構造は、スニーカーコミュニティが何年もかけて解析してきました。Cookie 値の中の sec~ フィールドが、目に見える判定です。sec~-1~ はセンサーが検証に失敗したことを意味します。sec~7~（およびその範囲の他の正の整数）はセンサーが通過したことを意味します。他にもフィールドはあり、Akamai はその意味をローテーションさせますが、-1 か正の数かという区別は、ソルバー開発者がそこを基準にできる程度には安定しています。

もう一つのシグナルは sec-cpt ヘッダーチェーンです。特定のチャレンジポイントの後、Akamai は後続のリクエストが計算量のプルーフ・オブ・ワークを完了したことを証明するヘッダーを携えることを期待します。cpt チェーンをスキップすると、たとえ最初のセンサーが通過していても、後のチェックポイントで失敗します。

Akamai に対するプロキシ戦略は、対象への依存度が非常に高いです。スニーカーコミュニティは、Akamai で保護されたドロップに対するデフォルトとして、モバイルと ISP プロキシに落ち着いています。そこでの共通認識は何年もの厚みがあり、私たちが異を唱えることはありません。私たちのスニーカープロキシページもそれを反映しており、モバイルと ISP ブランドを最初に取り上げています。

スニーカー以外の Akamai 対象（航空会社、銀行、一般小売）については、絵がよりぼやけます。モバイルは依然として効きます。住宅用は対象によって効いたり効かなかったり。データセンターはほぼどこでも失敗します。ISP は中間で、Akamai の IP 層が適度に重み付けされているが支配的ではないサイトでよく効きます。

念頭に置くべきこと。Akamai BMP の IP 層は、多数ある入力の一つにすぎません。完璧な IP でもセンサーペイロードが壊れていれば失敗します。プレミアム ISP に投資したのに、ヘッドレスブラウザが有効なセンサーデータを生成していないせいでブロックされ続けるお客様を見ます。プロキシは必要条件ですが、十分条件ではありません。

本シリーズには、より深い Akamai の記事が控えています。センサー構造、cpt チェーン、そして典型的なソルバーのツールチェーンがどのようなものかを掘り下げます。

PerimeterX (HUMAN)

PerimeterX は数年前に HUMAN Security と合併しました。製品は多くの文脈で今も PerimeterX として出荷され、Cookie も今なお _px* ですが、親会社のブランディングは変わりました。内部の詳細もそれに伴って変化しており、合併後の製品サイクルがまだ進行中であるため、このセクションは控えめに記します。

公開されている仕組み。Cookie ファミリーは _px、_pxhd、_pxvid で、_px が短命のセッショントークン、_pxhd がより長命のヘッダー値、_pxvid が訪問者 ID です。チャレンジは JS ベースで、DataDome のパターンに似ています。行動シグナルが他の一部ベンダーよりも重く効きます。マウスの動きやタイミングのパターンが、モデルの一部として明示的に組み込まれています。

PerimeterX に遭遇する場面：Supreme、StubHub、チケッティングプラットフォーム、そして EC のロングテール。スニーカーのドロップも歴史的には PerimeterX を使っていましたが、一部は移行しました。

私たちのチケット履歴から見たプロキシ戦略。モバイルプールは PerimeterX に対してよく持ちこたえる傾向があります。住宅用ローテーション、つまりリクエストごとに IP を変える攻撃的なスタイルのスクレイピングは、スコアを素早く落とす傾向があります。PerimeterX の行動層が、セッションの連続性の欠如をフラグするからです。IP を数分間保持するスティッキー住宅用やスティッキーモバイルのセッションは、スコアが良くなります。これは「ローテーションを減らし、より人間のセッションらしく振る舞う」という、行動を重視するベンダーに対する業界全般のパターンと一致します。

PerimeterX の内部に関する具体的な踏み込んだ見解、つまり正確な Cookie フィールドの意味や、正確なチャレンジバイパスの詳細については、意図的に曖昧にしておきます。HUMAN との合併後、内部が十分に変わったため、具体的な主張はどれも賞味期限が短いのです。安定したアドバイスはこうです。モバイルはスティッキー、住宅用もスティッキー、ローテーションを遅くし、セッションの連続性を大切にすること。

Queue-it

Queue-it はこのリストの中で異色です。他とは同じ意味でのボット対策ではないからです。これは仮想待合室です。この区別は重要で、多くのお客様がここを取り違えます。

ボット対策は自動化トラフィックを識別してブロックしようとします。Queue-it はあなたがボットかどうかを実のところ気にしません。気にするのはスループットです。その仕事は、ピーク負荷をさばけないサイトの前段に立つこと。大型ドロップ時の Ticketmaster、登録シーズン中の行政サービスポータル、限定商品のローンチなどです。そして人間もボットも全員を待合室に並べます。あなたは待ちます。トークンを受け取ります。そのトークンが一定時間、本物のサイトへの通過を許します。やがて期限が切れます。

公開されている仕組み。Queue-it は入場時に、位置トークンを含む Cookie チェーンを設定します。キュー内のあなたの位置は、そのトークンとあなたの IP に紐づきます。サイトはタイマーで Queue-it の API をポーリングし、あなたの順番が来たかを確認します。来たら、あなたが待ったことを証明するリダイレクトトークンを受け取り、上流のサイトがあなたを受け入れます。

キューの位置が IP に紐づくため、ここでのプロキシ戦略は、ほとんどのボット対策ベンダーに有効なものとは正反対です。攻撃的なローテーション、つまり住宅用スクレイピングのデフォルトモードは、むしろ逆効果です。新しい IP のたびに新しいキュー位置が始まります。あなたは列の最後尾に回されます。Cloudflare や DataDome の発想で来て、高ローテーションで Queue-it を力ずくで突破しようとするお客様は、人間のように並んだ場合よりも悪い位置に終わります。

効くパターンはスティッキーセッションです。ISP やモバイルでの長いスティッキーセッション、つまりキューの全期間にわたって同じ IP を保持すること。これがチケッティングやドロップでお客様が落ち着く形です。モバイルが良いのはキャリア IP が強く罰せられないから。ISP が良いのは IP が安定して静かだからです。モバイルのスティッキーセッションは、チケッティングのお客様のサポートチケットで、他のどのプールタイプよりも頻繁に登場します。

層を重ねるパターンもあります。一部のサイトは Queue-it を Akamai や Cloudflare の前段に重ねます。まずキューに並ばされ、キューを抜けると、今度はボット対策層が始動します。そのスタックは、両方を生き延びるプロキシを必要とします。キュー位置を保持できるだけスティッキーで、その後のボットスコアリングを通過できるだけクリーンなもの。モバイルが答えになりがちなのは、両軸とも強いからです。

Queue-it の詳細掘り下げ記事では、トークンチェーン、ポーリングの頻度、そしてキューをスキップしようとするお客様がよくやる間違いを扱います。

Kasada

Kasada は、デプロイ数ではこのリストで最小のベンダーですが、成長中であり、他とは意味のある違いがあります。

製品の中核はクライアントサイドの WebAssembly チャレンジです。Kasada で保護されたサイトにアクセスすると、レスポンスにはブラウザ内で実行される小さな WASM ペイロードが含まれます。WASM は計算タスク、つまりプルーフ・オブ・ワーク、フィンガープリンティング、環境チェックを行い、トークンを生成します。トークンは送り返され、サーバー側で検証され、リクエストが受け入れられます。

大きなアーキテクチャ上の違い。Kasada は IP レピュテーションよりもクライアントサイドのプルーフを重く見ます。彼らの公開資料はこの点を明言してきました。計算ベースのチャレンジは、フィンガープリントベースのものより大規模に偽装しにくいという賭けです。フィンガープリントの偽装は安上がりですが、計算の偽装は WASM を実際に正しく実行することを意味するからです。

Kasada に遭遇する場面：ANZ 系銀行（Westpac、ANZ など複数が利用してきました）、Twitch、一部の行政サービス。フットプリントはオーストラリアで厚く、米国エンタープライズ領域で成長しています。

ここでのプロキシ戦略は変わっています。Kasada は Cloudflare や DataDome ほど IP に敏感ではないため、IP 重視のベンダーに対しては手痛く失敗する格安住宅用プールでも、WASM チャレンジが正しく解かれていれば、Kasada の対象には実際に通用しうるのです。ボトルネックがプロキシからソルバーへ移ります。

難しいのはソルバー側です。WASM は動的に難読化され、ローテーションします。Kasada のトークンを扱う商用ソルバーサービスがあり、Kasada が難読化を更新するまでの一定期間だけ機能するオープンソースの試みもあります。私たちはソルバーを売っていません。プロキシを売っています。それでもこの点に触れるのは、Kasada に対して失敗するお客様はたいてい誤ったメンタルモデルを持っているからです。Cloudflare 流の結果を期待してプレミアム住宅用に投資する。しかし本来お金が向かうべきだったのはソルバーの能力でした。

詳細掘り下げ記事では、Kasada のチャレンジ構造、典型的なソルバーの状況、そしてレスポンスコードから失敗が IP・フィンガープリント・トークンのどれによるものかを見分ける方法を扱います。

これがあなたのプロキシ選択にとって意味すること

人がやりがちな間違いは、一対一の対応を探すことです。「Cloudflare には住宅用。Kasada にはデータセンター。Akamai にはモバイル」。そんなふうにはいきません。

より役立つ枠組みは 2 つの軸です。そのベンダーは IP レピュテーションをどれだけ重視するか、そしてクライアントのフィンガープリントとチャレンジ解決をどれだけ重視するか。

IP 重視のベンダー：Cloudflare Bot Management、DataDome、Akamai BMP（おおむね）、PerimeterX。これらに対しては、あなたが買うプロキシのブランドが本当に効いてきます。他をすべて同条件にしたとき、格安プールが失敗する場所でプレミアムプールが成功します。IP レピュテーションの差は本物です。ここで私たちの比較ページが真価を発揮します。14 ブランドの品質あたり価格の比率は、IP 重視のベンダーに対する勝率を実際に動かします。

フィンガープリント重視のベンダー：Kasada、Akamai の計算プルーフ層の一部、Cloudflare の Turnstile の一部。これらに対してはプロキシのブランドの重要度は下がり、クライアント側、つまり TLS フィンガープリント、ブラウザのステルス性、チャレンジソルバーの重要度が上がります。ここで高価な住宅用を買うお客様は、間違った層にお金を払っています。

Queue-it はそれ自体が独自のカテゴリーです。ボット対策ではまったくありません。正解はスティッキーセッションで、ブランドは問いません。スティッキーモバイルもスティッキー ISP もどちらでも結構です。ここではプレミアム価格を払っても大して得るものはありません。

ジオの観点、つまり対象サイトがボット検知に加えて IP がどの国のものかを気にする場合については、14 ブランドの記事が、ブランドごとの実用的なジオロックの限界をカバーしました。ジオも気にする IP 重視のボット対策ベンダー（地域ロックコンテンツについては、ほぼすべてがそうです）に対しては、両方の層が複合します。その記事こそ出発点として正解です。

AI エージェントのトラフィックやヘッドレスブラウザ駆動のフローにも、同じロジックが当てはまります。エージェントの TLS フィンガープリントと行動は、IP と同じくらい重要です。自動化として識別されるエージェントにプレミアムプロキシをぶつけても、それを救うことはできません。

ISP 製品ラインについては、ユースケースはスティッキーな中間地点です。ローテーション住宅用よりクリーンで、モバイルよりスティッキー、プレミアム住宅用より GB あたり安価。IP 品質を軽くは気にするが、安定したセッションを罰しないベンダーに対して有効です。

本シリーズの次回

このピラー記事は、プロキシを選ぶのに必要なレベルで 6 つのベンダーをカバーしました。各ベンダーは今後数週間で、それぞれ独立した掘り下げ記事を持ちます。現在の予定は、順に以下の通りです。

• C1: Cloudflare バイパス — BotScore の仕組み、Turnstile の内部、cf_clearance が実際に何をチェックするか
• C2: DataDome — 多層スコア、行動シグナル、JS チャレンジを引き起こすもの
• C3: Akamai BMP — センサーデータの構造、_abck Cookie の内部、sec-cpt チェーン
• C4: PerimeterX (HUMAN) — 現行の Cookie チェーン、行動フィンガープリンティング、合併後の変更
• C5: Queue-it — トークンの仕組み、ポーリングの頻度、スティッキーセッション戦略
• C6: Kasada — WASM チャレンジの構造、ソルバーの状況、プロキシ選択が重要でなくなるとき

おおよそこの順で公開していきますが、読者の要望に応じて優先順位を入れ替えます。先に見たいベンダーがあれば、私たちの Discord に来て教えてください。すべてのチャンネルに目を通していますし、順番は固定ではありません。