DataDomeとは？ボット検知の仕組みとスクレイパーのブロック方法

スクレイパーはテスト環境では完璧に動作します。

しかし、実際のWebサイトをターゲットにすると、次のような結果になります：

403 Forbidden。

あるいは、CAPTCHAが表示されます。

あるいは、Chromeではページが読み込まれるものの、スクリプトとは全く異なる結果が返されてしまいます。

IPアドレスを変更しても、数回のリクエストは通るものの、またブロックされてしまいます。

DataDomeは、こうした問題を自動トラフィックに対して引き起こすように設計されています。

理解しておくべき重要な点は、DataDomeが単に次のように問うわけではないということです：

「このIPは不審か？」

現代のボット検出は、むしろ次のようなものです：

「このIP、ネットワーク接続、ブラウザ、デバイス、リクエストパターン、セッションが、すべて整合性を持っているか？」

この違いこそが、プロキシを切り替えることが時に有効である理由、多くの場合無効である理由、そしてHTTPレベルでは完全に正常に見えるスクレイパーがそれでも失敗する理由を説明しています。

このガイドでは、DataDomeの仕組み、DataDomeが利用可能なシグナル、DataDomeによるブロックの具体的な様子、ブラウザとスクリプトの挙動が異なる理由、そしてプロキシ、ブラウザの自動化、スクレイピングAPIが全体像の中でどのような役割を果たすかについて解説します。

DataDomeとは？

DataDomeは、ウェブサイト、モバイルアプリ、APIが、正当なユーザーと自動化されたトラフィックや悪意のあるトラフィックを区別するために利用する、ボットおよびオンライン不正防止プラットフォームです。

ウェブサイト運営者は、DataDomeのようなシステムを活用して、次のような活動を抑制しています：

不正なスクレイピング
クレデンシャルスタッフィング
アカウント乗っ取りの試み
偽アカウントの作成
在庫の不正利用
決済詐欺
自動化された脆弱性スキャン
攻撃的なボット
望ましくないAIエージェント

公開されているウェブデータを収集する者にとって、DataDomeは方程式の反対側に位置する存在です。

リクエストが保護されたウェブサイトに到達すると、アプリケーションがどのコンテンツを返すかを決定する前に、DataDomeがそのリクエストを評価し、それが正当なものか、不審なものか、あるいは自動化されたものかを判断します。

その結果として、以下のいずれかが発生します：

許可

リクエストは通常通り処理されます。

デバイスチェック

ブラウザやデバイスに対する追加の検証が行われます。

CAPTCHA

クライアントにインタラクティブな課題が提示されます。

ブロック

リクエストは拒否されます。

これが、まったく同じURLに対する2つのリクエストが、全く異なる応答を返すことがある理由です。

URLは変わっていません。

変わったのはクライアントです。

DataDomeの仕組み

これを簡略化したモデルは、次のようなものです：

クライアント → 保護対象のウェブサイト／DataDome → 検知判定 → ウェブサイト

検知の段階こそが、スクレイパーによる問題のほとんどが発生する場所です。

DataDomeは、単一の単純な指標に頼るのではなく、接続の複数のレイヤーからのシグナルを評価することができます。

これらのレイヤーには、次のようなものがあります：

レイヤー	シグナルの例
ネットワーク	IPアドレス、ASN、ネットワークのレピュテーション
TLS	TLSフィンガープリントおよび接続特性
HTTP	ヘッダー、ヘッダーの一貫性、リクエストのプロパティ
ブラウザ	ブラウザフィンガープリントおよび環境
デバイス	OS、ハードウェア、および実行シグナル
JavaScript	クライアント側チェックの結果
セッション	クッキーおよびリクエスト間の連続性
行動	タイミングおよびインタラクションのパターン
レピュテーション	インフラストラクチャに関連付けられた過去の活動

1つの項目だけでは、そのリクエストが自動化されていることを必ずしも証明できるわけではありません。

真価は、これらを総合的に比較することから生まれます。

あり得ないブラウザフィンガープリントを持つ住宅用IPアドレスであっても、不審に見える可能性があります。

一貫性のないTLSクライアントから送信された、一見完璧に見えるUser-Agentであっても、不審に見える可能性があります。

実際のブラウザが、非常に反復性の高いリクエストを何百件も生成している場合でも、不審に見える可能性があります。

これこそが、最新のアンチボットシステムと、従来のIPブロックシステムとの根本的な違いです。

DataDomeの検知：主なレイヤー

1. IPレピュテーション

IPレピュテーションは依然として重要です。

IPアドレスには履歴がある場合があります。

例えば、インフラストラクチャから大量の不正なトラフィックや明らかに自動化されたトラフィックが発生すると、そのインフラストラクチャのレピュテーションが低下する可能性があります。

DataDome は、トラフィックが以下のいずれから発信されているかを判断できます：

既知のホスティングインフラストラクチャ
データセンターの IP 範囲
共有プロキシ
住宅用プロキシ
無料のパブリックプロキシネットワーク
過去に不審とされたアドレス

しかし、IP レピュテーションは単なる一つの指標に過ぎません。

そのため、次のような主張は

「住宅用プロキシを使えば、DataDomeには検出されない」

といった主張は誤解を招くものです。

住宅用IPアドレスを使用することで、ネットワークリクエストを一般的な消費者トラフィックのように見せかけることは可能です。

しかし、それだけでリクエストの他の部分が自動的に整合性を持つようになるわけではありません。

2. HTTPヘッダー

ブラウザは、識別可能な一連のヘッダーを送信します。

自動化ツールも同様にヘッダーを送信します。

重要なのは、単にリクエストに ``User-Agent`

` が含まれているかどうかだけではありません。

リクエスト全体として理にかなっているかどうかが問題なのです。

例えば、最新のChromeバージョンを装いながら、通常はそのブラウザには見られないようなヘッダーの組み合わせを送信するクライアントを想像してみてください。

個々の値は、それぞれ妥当に見えるかもしれません。

しかし、それらを総合すると、そうではない可能性があります。

最新のボット検出技術は、こうした不整合を探し出すことができます。

単に `

User-Agent: Mozilla/5.0...

` を変更しただけでは、単純なHTTPライブラリをChromeに変えることはできません。

3. TLS フィンガープリント

HTTPS 経由で HTTP データが交換される前に、クライアントは TLS 接続を確立します。

クライアントによって、TLS の特性は異なります。

ブラウザ、Python HTTP ライブラリ、コマンドラインクライアント、その他のランタイム環境では、暗号化された接続の確立方法が異なる場合があります。

これらのパターンはフィンガープリントとしてまとめられます。

DataDomeのドキュメントでは、トラフィックの評価に使用できるデータの一部として、JA3やJA4情報を含むTLSフィンガープリントについて具体的に言及しています。

これは、単純なスクレイピング環境にとって重大な問題となります。

HTTPヘッダーには次のように記載されているかもしれません：

Windows上のChrome

しかし、その背後にあるネットワーク接続は、使用していると主張しているChromeのバージョンとは全く異なる場合があります。

HTTPヘッダーを変更しても、その背後にあるTLSスタックが自動的に変更されるわけではありません。

これが、HTTPのみのスプーフィングが最終的に限界に達する理由の一つです。

4. ブラウザフィンガープリント

JavaScriptが実行可能になると、ボット対策システムはより豊富な環境情報を活用できるようになります。

実際のブラウザは、自身やそれを動作させているデバイスに関する大量の情報を公開しています。

潜在的なシグナルには、以下のような特性が含まれます：

ブラウザのバージョン；
オペレーティングシステム；
ハードウェア；
CPU；
メモリ；
グラフィックス環境；
サポートされているブラウザAPI；
レンダリング動作；
機能のサポート状況；
自動化の痕跡。

自動化において難しいのは、1つの「信憑性のある」値を生成することではありません。

数百もの相互に整合性のある値を生成することにあります。

ある自動化されたブラウザが、あるオペレーティングシステム上で動作していると主張しているにもかかわらず、その環境の他の部分が別のOSのように振る舞うとします。

あるいは、報告されたハードウェアの特性が、主張されているデバイスと一致しない場合もあります。

あるいは、自動化が一般的なフィンガープリントの特性を変更しても、二次的なシグナルは変更しない場合もあります。

5つの明らかなプロパティを検査しただけでは、そのブラウザは説得力があるように見えるかもしれません。

しかし、検出システムは5つだけで判断を終わらせる必要はありません。

5. ヘッドレスおよび自動化されたブラウザの検出

Playwright、Puppeteer、Seleniumは極めて有用です。

また、それらは目に見えないものでもありません。

Chromiumを起動することで、スクレイパーに本物のブラウザエンジンが提供され、基本的なHTTPクライアントでは解決できない多くの問題が解決されます：

JavaScriptの実行；
レンダリング；
クッキー；
ブラウザAPI；
動的コンテンツ；
ナビゲーション状態。

しかし、「本物のブラウザエンジン」だからといって、「通常のユーザーと見分けがつかない」という意味ではありません。

自動化フレームワークは、目に見える違いをもたらす可能性があります。

DataDome自身の検出に関するドキュメントには、Puppeteer、Selenium、Playwrightによって駆動されるブラウザを含む、自動化ブラウザおよびヘッドレスブラウザの検出カテゴリが明示的に記載されています。

つまり、次のようなシンプルなアーキテクチャ：

Playwright + プロキシ

は、万能なアンチボットソリューションとして扱われるべきではありません。

あるウェブサイトでは完璧に機能しても、別のウェブサイトではすぐに失敗する可能性があります。

6. JavaScript とデバイスチェック

DataDomeは、クライアントに対して追加の検証を要求することもできます。

その仕組みの一つがデバイスチェックです。

すぐに目に見えるCAPTCHAを表示する代わりに、ブラウザ内でJavaScriptが実行され、環境が評価されます。

DataDomeによると、同社のデバイスチェックは数百ものシグナルを収集し、自動化フレームワーク、偽装された環境、およびプログラムによるアクセスを検出することを目的とした複数のチェックを実行します。

実際の訪問者にとっては、この処理は目立った中断を伴わずに実行される場合があります。

一方、スクレイパーにとっては、以下の2つの間に重要な違いが生じます：

HTTPクライアント

と：

期待されるクライアントサイドのロジックを実行できるブラウザ

スクレイパーが初期のHTMLのみをダウンロードし、ブラウザ内で発生するすべての処理を無視している場合、保護されたサイトが期待する完全なインタラクションを再現できない可能性があります。

7. 行動の検知

技術的に説得力のあるブラウザであっても、奇妙な動作をする場合があります。

2つのセッションを考えてみましょう。

セッションA

ユーザー：

商品ページを開く；
14秒間、ページを読む；
別のページを開く；
スクロールする；
元のページに戻る；
検索を行う；
検索結果を開く。

セッション B

クローラー：

商品 1 をリクエストする；
300 ミリ秒後に商品 2 をリクエストする；
300 ミリ秒後に商品 3 をリクエストする；
この動作を数百回繰り返す。

どちらのセッションも Chrome を使用している可能性があります。

どちらも一般家庭のIPアドレスを使用可能です。

両者の挙動は明らかに異なります。

挙動検出により、アンチボットシステムは個々のリクエストではなく、パターン全体を考慮できるようになります。

これは特に大規模な環境において重要です。

一度成功したスクレイパーが、必ずしも10万件のリクエストを継続して行えるとは限りません。

8. セッションの一貫性

現代のウェブサイトはステートフルです。

Cookie、ブラウザの状態、IPアドレス、リクエスト履歴はすべてセッションの一部を構成します。

これらの要素が互いに矛盾している場合、自動化の検出は容易になります。

例えば：

同じセッションクッキーが残っているにもかかわらず、IPアドレスが絶えず変化する場合；
セッションの途中でブラウザの識別子が変化する場合；
ナビゲーションが突然、関連性のないリソース間を飛び回る場合；
前のステップで期待されていたクッキーが一切現れない場合；
すべてのリクエストが、まるで全く新しい訪問者であるかのように振る舞う場合。

そのため、リクエストごとに無闇にIPをローテーションさせると、スクレイパーの信憑性が高まるどころか、かえって低くなる場合があるのです。

ローテーションは有用です。

継続性も有用です。

どちらが正しい選択かは、処理負荷によって異なります。

DataDomeによるブロックはどのようなものか？

DataDomeは、不審なリクエストすべてに対して同じように応答するわけではありません。

いくつかの結果が考えられます。

403レスポンス

最も明確な兆候は、HTTPの「403 Forbidden」レスポンスです。

ただし、インターネット上のすべての 403 レスポンスが DataDome によるものだと決めつけないでください。

常に実際のレスポンスを精査してください。

CAPTCHA ページ

ターゲットページではなく、レスポンスに DataDome の認証課題が含まれる場合があります。

デバイスチェック

アクセスを継続する前に、ブラウザが非表示の検証を行う場合があります。

これはデバッグ中に特に混乱を招きやすい現象です。なぜなら、CAPTCHAが表示されることなく、通常のブラウザでは最終的にページが正常に動作する場合があるからです。

ブロックページ

十分に不審とみなされたトラフィックに対しては、直接ブロックされる場合があります。

Chromeとスクレイパーでの挙動の違い

これは、問題がURL自体にあるのではないことを示す最も有力な手がかりの一つです。

もし：

Chrome → コンテンツ

であるのに対し、

リクエスト/cURL/カスタムスクリプト → チャレンジ

となる場合、その違いはクライアント、ネットワークの識別情報、ブラウザの実行環境、またはセッションのどこかに原因がある可能性が高いです。

IPアドレスを変更するだけでは不十分な理由

プロキシは、リクエストの重要な部分を変更します。

トラフィックの発信元として認識される場所

これは有益です。

しかし、以下は自動的に変更されません：

HTTPの実装；
TLSフィンガープリント；
ブラウザ環境；
JavaScriptの実行；
ブラウザのフィンガープリント；
クッキー；
リクエストのタイミング；
ナビゲーションの挙動；
セッションロジック。

フルスタック全体を考えてみてください：

**IP

TLS
HTTP
ブラウザ
デバイス
セッション
挙動**

プロキシは主に最初のレイヤーを変更します。

リクエストが失敗する原因がIPレピュテーションである場合は、それで十分かもしれません。

しかし、複数のレイヤーで不一致が生じている場合には、それだけでは不十分です。

DataDome におけるデータセンタープロキシと住宅用プロキシ

万能な「DataDome プロキシ」というものは存在しません。

プロキシの種類によって、解決できるネットワーク上の課題は異なります。

データセンタープロキシ

データセンターのIPアドレスは高速で安価であり、多くの自動化ワークロードにおいて極めて有用です。

しかし、厳重に保護された一般消費者向けウェブサイトにおいては、そのネットワークの起源がホスティングインフラとして分類されやすくなってしまうという欠点があります。

これは、すべてのデータセンターからのリクエストがブロックされるという意味ではありません。

つまり、IPアドレスそのものが、クライアントが一般的な一般ユーザーであるという証拠として、あまり役立たない可能性があるということです。

レジデンシャルプロキシ

レジデンシャルプロキシは、一般ユーザーのインターネット接続に関連付けられたIPアドレスを経由してリクエストをルーティングします。

これにより、一般消費者向けの公開ウェブサイトを対象とするワークロードにおいて、より適切なネットワークプロファイルを提供できます。

しかし、レジデンシャルIPが必ずしも「人間」を意味するわけではありません。

DataDomeは、レジデンシャルプロキシを経由してルーティングされた自動化されたトラフィックを識別できるモデルについて、明確に文書化しています。

したがって、レジデンシャルプロキシについて考える上で有用な視点は以下の通りです：

より優れたネットワークアイデンティティ

であり、

ボット対策の自動回避

ではありません。

ISPプロキシ

ISPプロキシは、一般消費者のISPに関連付けられたIPアドレス空間を使用しながら、安定したセッションを提供できます。

長時間のセッションにわたって一貫したアイデンティティを必要とするワークフローにおいて、その安定性は価値あるものとなります。

繰り返しになりますが、クライアント側のその他の要素も依然として重要です。

プロキシの頻繁なローテーションが逆効果になる理由

「より頻繁にローテーションする」というのは、一見当然のアドバイスのように思えます。

しかし、それが常に正しいとは限りません。

5分間続くウェブサイトのセッションを想像してみてください。

実際のユーザーであれば、通常、そのセッションの大部分において同じネットワークIDを維持します。

もし、自動化システムが同じクッキーやアカウントセッションを維持したまま、3回のリクエストごとに国やネットワークを変更すると、その組み合わせは不自然なものになりかねません。

ワークロードによっては、セッションのローテーションが適切です。

一方で、スティッキーセッションの方が一貫性のある動作を生み出す場合もあります。

プロキシ戦略は、アクセスするアプリケーションの構造に合わせて設定すべきです。

CAPTCHA ソルバーについてはどうでしょうか？

CAPTCHA は、必ずしも DataDome の判定プロセスの最初の段階というわけではありません。

他の検出機能によってセッションがすでに不審と判定された後の、さらなる対応の一つとして機能する場合もあります。

この区別は重要です。

CAPTCHA を解いたからといって、以下の問題が自動的に解消されるわけではありません：

不審なブラウザフィンガープリント；
一貫性のないTLSスタック；
低いIPレピュテーション；
不自然なセッションの挙動。

DataDomeは、チャレンジが解決された後であっても、CAPTCHAファームや自動化された環境を検出することについて公に議論しています。

したがって、CAPTCHAの解決を問題のすべてと見なすことは、その周囲にあるより大きなシステムを見落としていることになります。

スクレイパーが今日は機能しても、明日は失敗する理由

これもよくある誤解の原因です。

コードには何の変更もありません。

突然、成功率が低下します。

それは必ずしも、ターゲットがウェブサイトを再設計したことを意味するわけではありません。

ボット管理システムは、検出ロジックを絶えず変更しています。

他にも変化する要因があります：

IPのレピュテーションが変化する；
ブラウザのバージョンが更新される；
ウェブサイトのポリシーが変更される；
トラフィック量が増加する；
リクエストパターンが変化する；
ターゲットが特定のエンドポイントに対してより厳格な保護を有効にする。

したがって、最新のアンチボットシステムに対するスクレイピングは、一度きりの設定問題ではなく、運用上の問題なのです。

DataDome と Playwright

Playwright は、Web サイトで実際のブラウザ実行が必要な場合に役立ちます。

JavaScript を読み込み、ページとやり取りし、ブラウザの状態を維持することができます。

そのため、現代の Web サイトにおいて、単純な HTTP リクエストライブラリよりもはるかに高い機能性を発揮します。

しかし、Playwright だけではトラフィックを自動的に「人間らしい」ものにはできません。

保護されたサイトでは、依然として以下の要素が評価される可能性があります：

ブラウザの特性
自動化の痕跡
ネットワークの識別情報
セッション
リクエストの頻度
動作

これが、Playwright を使ったスクレイパーが開発段階では成功しても、大規模運用では信頼性を失う理由です。

ブラウザの自動化は、ブラウザ上での実行という課題を解決します。

しかし、ブラウザを取り巻くあらゆるアンチボット対策層を解決するわけではありません。

DataDome と Puppeteer

同じ原理が Puppeteer にも当てはまります。

Chromium を使用することで、クローラーは生の HTTP よりもはるかに充実したクライアント環境を得ることができます。

これは次のような場合に役立ちます：

クライアント側でレンダリングされるアプリケーション；
動的なページ；
JavaScriptによるナビゲーション；
初期HTMLの後に読み込まれるコンテンツ；
クッキーやブラウザの状態を必要とするアプリケーション。

しかし、ブラウザ、IP、および動作は、依然として一貫性のあるセッションを形成する必要があります。

Puppeteerはブラウザ自動化フレームワークです。

それは「不可視化レイヤー」ではありません。

本当に重要なスクレイピング・スタック

次のように問うよりも：

「どのプロキシならDataDomeをバイパスできるか？」

レイヤーごとに考えるほうがより有益です。

問題	関連するレイヤー
IPレピュテーションの低下	プロキシ／ネットワーク
ロケーションの不一致	地域ターゲティング型プロキシ
JavaScriptが必要	ブラウザ／レンダリング
動的コンテンツ	ブラウザ／レンダリング
TLSの不整合	HTTP／ブラウザスタック
ブラウザフィンガープリントの不一致	ブラウザ環境
セッションの不安定さ	クッキー／セッション管理
過度なリクエストパターン	クロールアーキテクチャ
CAPTCHA／チャレンジ	チャレンジ処理
継続的なボット対策のメンテナンス	管理型スクレイピングインフラ

これにより、トラブルシューティングが大幅にスピードアップします。

プロキシを置き換えることであらゆる問題を解決しようとする必要がなくなります。

DataDomeで保護されたサイトからデータを収集する3つの方法

対象サイトへのアクセスが許可されている正当なデータ収集の場合、大きく分けて3つのアーキテクチャがあります。

1. スクラッパーを自作する

すべてを自分で制御します：

HTTPクライアント；
ブラウザ；
プロキシ；
セッション；
リトライロジック；
パーシング；
レンダリング；
モニタリング。

メリット：

最大限の制御が可能。

デメリット：

最大限のメンテナンスが必要。

ワークフローが特殊で、スタック全体を自社で管理する価値がある場合に有効です。

2. 独自のブラウザやスクレイパーでプロキシを使用する

アーキテクチャ：

独自のスクレイパー → プロキシネットワーク → ターゲット

これにより、ネットワークインフラを外部委託しつつ、アプリケーションの制御を維持できます。

次のような問題が主な課題である場合に有用です：

IPのレピュテーション；
地域ターゲティング；
同時実行数；
ネットワークローテーション；
安定したセッション。

例えば、Geonode Residential Proxiesは、地域ターゲティングに加え、ローテーションセッションとスティッキーセッションの両方の設定に対応しています。

ただし、プロキシ層より上流の処理については、引き続きアプリケーション側が責任を負うことになります。

3. スクレイピングAPIの利用

アーキテクチャ：

アプリケーション → スクレイピングAPI → ターゲット

ブラウザやプロキシの選択、データ抽出インフラを自ら管理する代わりに、Webデータ収集用に設計されたサービスにURLを送信します。

これは、実際の要件が次のような場合に適しています：

「ページのコンテンツをください。」

という場合、

「アンチボット／ブラウザインフラチームを維持したい」

という要件よりも適しています。

例えば、GeonodeのScraper APIは、レンダリングされたページコンテンツをHTMLやMarkdown形式で返すことができ、JavaScriptレンダリング、管理されたプロキシインフラ、ジオターゲティング、バッチ処理、クロール機能を提供します。

重要な違いは、複雑さの所有権にあります。

プロキシの場合：

スタックを制御するのはあなたです。

スクレイピングAPIの場合：

スタックの大部分をスクレイピングプラットフォームが管理します。

どちらのモデルも、一概に優れているわけではありません。

これらは、それぞれ異なる技術的課題を解決するものです。

プロキシ vs ブラウザ vs スクレイピングAPI

ソリューション	IPの変更	JSの実行	ブラウザの管理	データ抽出の処理	メンテナンス
プロキシのみ	はい	いいえ	いいえ	いいえ	高い
Playwright + プロキシ	はい	はい	あなた	あなた	高い
Puppeteer + プロキシ	はい	はい	あなた	あなた	高い
スクレイピングAPI	管理済み	サポートされている場合ははい	管理済み	管理済み	低い

だからこそ、「単に住宅用プロキシを使えばいい」と言うのは不十分なアドバイスなのです。

場合によっては、それがまさに必要なことでもあります。

また、プロキシがはるかに大きな問題の一部に過ぎない場合もあります。

DataDome ブロックのトラブルシューティング方法

リクエストが失敗し始めた場合、10項目を同時に変更しないでください。

該当するレイヤーを診断してください。

問題：ブラウザでは動作するが、スクリプトでは失敗する

調査すべき可能性のある領域：

JavaScriptの実行；
HTTP/TLSクライアントの違い；
ブラウザフィンガープリント；
Cookie；
セッション状態。

失敗の原因がクライアント側にある場合、IPを変更しても効果がない可能性があります。

問題：最初は動作するが、その後ブロックされる

確認すべき点：

リクエストレート；
繰り返されるナビゲーションパターン；
IP/セッションのローテーション；
深刻化するIPレピュテーションの問題；
セッションの一貫性。

最初のリクエストと1000回目のリクエストは同等ではありません。

問題：データセンターのIPでは失敗するが、一般家庭のIPでは動作する

ネットワークのレピュテーションが、判断の重要な要素となっている可能性が高い。

とはいえ、他のシグナルが無視されていることを証明するものではない。

問題：一般家庭向けプロキシでも失敗する

すぐに一般家庭向けプロキシが不良であると結論づけてはならない。

以下の点を調査してください：

ブラウザ／クライアントのフィンガープリント；
TLSの特性；
JavaScriptの要件；
クッキー；
リクエストパターン；
セッションの設計。

問題：CAPTCHAが繰り返し表示される

CAPTCHAのループは、セッション全体が引き続き不審であると見なされていることを示している可能性があります。

この問題を、必ずしも根本原因ではなく、あくまで症状として捉えてください。

問題：国によって結果が異なる

以下の点を確認してください：

サイト自体が地域によって異なる動作をしていないか；
コンテンツの可用性に変化がないか；
クッキーの状態が一貫しているか；
IPの地理的位置情報が、意図したセッションと一致しているか。

DataDomeは住宅用プロキシを検出しますか？

検出可能です。

これは、DataDomeの検出に関するドキュメントにも明示的に記載されています。

ただし、すべての住宅用プロキシからのリクエストがブロックされるわけではありません。

もしそうであれば、共有の家庭用ネットワークを利用している正当なユーザーに対して、膨大な数の誤検知が発生することになります。

より正確な表現は次の通りです：

住宅用IPアドレスは一つの指標に過ぎず、人間によるアクセスであることの証拠ではありません。

最新の検出技術では、これを他の証拠と組み合わせて判断します。

DataDomeはPlaywrightを検出しますか？

DataDomeのドキュメントには、Playwright、Puppeteer、Seleniumなどの自動化フレームワークを通じて制御されるブラウザを対象とした検出モデルが記載されています。

しかし、だからといってすべてのPlaywrightセッションが自動的にブロックされるわけではありません。

つまり、次のような仮定は

「Playwrightは実際のブラウザを使用しているため、検出できない」

という考えは誤りです。

DataDomeはブラウザフィンガープリントを使用していますか？

はい。

ブラウザおよびデバイスのフィンガープリントは、DataDomeの検知アーキテクチャの一部を構成しています。

これにより、システムはUser-Agentヘッダーなどの単純な識別子を鵜呑みにするのではなく、ブラウザや実行環境から公開される情報を比較することができます。

DataDomeはTLSフィンガープリントを使用していますか？

DataDomeのドキュメントではTLSフィンガープリントについて言及しており、保護API統合で利用可能なシグナルとしてJA3およびJA4フィンガープリントを推奨しています。

これは、通常のWebアプリケーションロジックがリクエストを認識する前にTLS接続が確立されるため、重要な点です。

したがって、スクレイパーはHTTPヘッダーを完璧に改ざんしていても、低レベルのネットワークフィンガープリントが異なるまま露呈してしまう可能性があります。

DataDomeは機械学習を利用していますか？

DataDomeは、自社の脅威検知モデルを機械学習ベースであり、継続的に更新されていると説明しています。

機械学習は魔法ではありません。

ここでの実用的な価値は、次のような単一の静的なルールに依存するのではなく、多くのシグナルやパターンを組み合わせることができる点にあります：

100回のリクエスト後にIPをブロックする。

DataDomeはAIエージェントをブロックできますか？

はい。

ボット管理市場は、従来のスクレイパーからAIエージェントやLLMクローラーへと、ますます拡大しています。

DataDomeは現在、商用ボットやAIエージェントの識別および認証を明示的にサポートしており、認証されていない自動トラフィックに対しては、脅威検知ポリシーを適用することができます。

AIシステムがウェブサイトを直接閲覧し、やり取りを行うケースが増えるにつれ、この機能の重要性はますます高まるでしょう。

DataDomeを回避することはできるか？

これは通常、技術的な観点からは誤った問いです。

最新の検知システムを無効化できる、恒久的なヘッダーやプロキシの種類、ブラウザのフラグなどはありません。

あるエンドポイントで、あるトラフィック量において機能する設定でも、次のような場合には失敗する可能性があります：

別のエンドポイントでは；
より大規模な場合は；
別のブラウザバージョンでは；
検出モデルが変更された後は。

正当なWebデータ処理ワークロードにおいて、より持続可能な問いは次の通りです：

スクレイピングスタックのどの部分がリクエストを「自動化」と分類させているのか、そしてそのレイヤーを自ら管理し続けたいのか？

答えがネットワークインフラである場合もあります。

適切なプロキシ設定を使用してください。

答えがレンダリングである場合もあります。

ブラウザを使用してください。

答えが運用スタック全体である場合もあります。

マネージドスクレイピングAPIを使用してください。

また、正しい答えは、代わりに公式APIやその他の認可されたデータソースを使用することである場合もあります。

DataDome 対 Cloudflare

DataDome と Cloudflare は、ボット管理市場の一部で機能が重複していますが、同一の製品として扱うべきではありません。

Cloudflare は、CDN、DNS、WAF、DDoS 対策、ボット管理機能などを含む広範なインフラストラクチャ・プラットフォームを提供しています。

一方、DataDomeは、ウェブサイト、モバイルアプリ、APIにわたるボットおよびオンライン不正行為の検知に特化しています。

しかし、スクレイパー開発者の観点から見れば、得られる教訓は同様です。

現代のボット対策は、複数のレイヤーにまたがって機能します。

効果的な対策は、単一のHTTPヘッダーを変更することだけに頼ることはできません。

DataDome 対 CAPTCHA

DataDomeはCAPTCHAサービスではありません。

CAPTCHAは、検知後の対応策の一つに過ぎません。

クライアントが不審であるかどうかを判断する実際のシステムは、その前段に位置しています。

この区別が重要なのは、開発者が「CAPTCHAを解く」ことに多大な労力を費やす一方で、そのチャレンジが表示される原因となったシグナルを無視しがちだからです。

より適切な問いは次の通りです：

そもそも、なぜこのセッションにチャレンジが表示されたのか？

レジデンシャルプロキシが有効な場合

レジデンシャルプロキシは、ネットワーク層が重要な場合に役立ちます。

例としては、以下のような正当なワークロードが挙げられます：

地域限定の公開コンテンツ；
地域別の検索結果；
地域ごとの価格設定；
商品の在庫状況；
市場調査；
分散型ウェブ収集。

これらは、自身のスクレイパーを完全に制御したい場合に特に有用です。

Geonodeのレジデンシャルプロキシは、地理的ターゲティングと設定可能なセッション動作を備えたレジデンシャルIPルーティングを提供します。

しかし、プロキシは本来あるべき姿、つまり：

ネットワークインフラストラクチャであるべきです。

ブラウザではありません。

CAPTCHAシステムでもありません。

スクレイピングエンジンでもありません。

そして、破損したフィンガープリントを自動的に修復するものでもありません。

Scraper APIがより理にかなう場合

Scraper APIが魅力的になるのは、アンチボット対策の維持管理が開発作業の大部分を占め始めたときです。

チームが以下の作業に、データそのものの利用よりも多くの時間を費やしている場合は、少なくともマネージドAPIの導入を検討すべきです：

ブラウザのアップグレード；
リトライロジック；
プロキシのオーケストレーション；
レンダリング；
データ抽出；
セッション処理；
リクエストの失敗対応；

Geonode Scraper API を利用すれば、アプリケーションは URL を送信するだけで、抽出された HTML や Markdown を受け取ることができ、リクエストの背後にあるレンダリングやプロキシインフラの管理はサービス側が担当します。

トレードオフは単純明快です：

自社で構築すれば、より細かく制御できます。

API を利用すれば、インフラ関連の作業が不要になります。

製品が実際に何を必要としているかに基づいて選択してください。

よくある質問

DataDomeとは何ですか？

DataDomeは、ウェブサイト、モバイルアプリ、APIにおける自動化されたトラフィックや悪意のあるトラフィックを特定するために設計された、ボットおよびオンライン不正防止プラットフォームです。

DataDomeはどのようにボットを検知するのですか？

IPレピュテーション、HTTPおよびブラウザのフィンガープリント、TLSの特性、デバイス情報、行動パターン、機械学習による検知モデルなど、複数のシグナルを組み合わせています。

なぜDataDomeは私のスクレイパーをブロックするのですか？

単一の普遍的な理由があることはめったにありません。 IPアドレス、HTTP/TLSクライアント、ブラウザ環境、JavaScriptのサポート状況、セッションの一貫性、リクエストの挙動などが、すべて要因となり得ます。

DataDomeはCAPTCHAを使用しますか？

はい、CAPTCHAは不審なトラフィックに対する対応策の一つとなり得ます。DataDomeは、目に見えない「Device Check」を実行したり、リクエストを直接ブロックしたりすることも可能です。

DataDomeの「デバイスチェック」とは何ですか？

デバイスチェックは、必ずしもユーザーによる目に見える操作を必要とせずに、クライアント側でチェックを実行する追加の検証メカニズムです。デバイスや実行のシグナルを評価し、その結果に応じてクライアントを許可、検証、またはブロックします。

User-Agentを変更すれば、DataDomeを回避できますか？

User-Agentの変更は、HTTPヘッダーの1つの値を変更するだけです。それによって、TLS接続、ブラウザ環境、デバイスフィンガープリント、Cookie、または動作が自動的に変更されることはありません。

DataDomeはヘッドレスChromeを検出できますか？

DataDomeでは、ヘッドレスブラウザや自動化されたブラウザ（Puppeteer、Selenium、Playwrightを通じて制御されるブラウザを含む）の検出カテゴリについて具体的に記載しています。

DataDomeはPlaywrightを検出できますか？

Playwrightによる環境を含め、ブラウザの自動化に関連する特徴を識別することができます。 Playwrightを使用しているからといって、セッションが自動的にブロックされるわけではありませんが、本質的に検出不能であるとは見なすべきではありません。

DataDomeはPuppeteerを検出できますか？

はい、DataDomeには、Puppeteerベースの自動化およびPuppeteer Extra Stealthを網羅する検出モデルが記載されています。

DataDomeはレジデンシャルプロキシを検知できますか？

DataDomeには、レジデンシャルプロキシを経由するトラフィックに関連する検知モデルがあります。レジデンシャルIPはネットワークの身元を変えるため有用な場合もありますが、それだけで自動化されたトラフィックが自動的に正当化されるわけではありません。

DataDomeで保護されたサイトにおいて、住宅用プロキシはデータセンター用プロキシよりも優れていますか？

住宅用プロキシは、一般の消費者トラフィックに近いネットワークアイデンティティを提供できるため、消費者向けサイトでは有用な場合があります。適切な選択は、依然としてターゲット、ワークロード、およびその他の検知レイヤーによって異なります。

DataDomeで保護されたサイトをスクレイピングするには、ブラウザが必要ですか？

保護されたページすべてにブラウザが必要なわけではありません。ただし、クライアントサイドレンダリングやDevice Checkに依存するウェブサイトでは、基本的なHTTPクライアントでは提供できない、本物のJavaScriptの実行やブラウザの状態が必要になる場合があります。

DataDomeから403エラーが返ってくるのはなぜですか？

403エラーは、リクエストが不審または自動化されたものと分類されたことを示している可能性があります。アンチボットシステムが原因であると決めつける前に、レスポンスが実際にDataDomeから返されていることを確認してください。

手動ではページが正常に動作するのに、Pythonでは動作しないのはなぜですか？

通常のブラウザとPythonのHTTPライブラリでは、ネットワーク、TLS、HTTP、JavaScript、およびブラウザ環境が大きく異なります。ボット対策システムは、これらの違いの一部を検知できる場合があります。

スクレイパーが数回のリクエストまでは動作するのに、その後停止してしまうのはなぜですか？

考えられる原因としては、行動検知、リクエスト頻度のパターン、IPレピュテーションの変化、またはセッションの不整合などが挙げられます。ボット対策システムは、各リクエストを個別に判断するのではなく、複数のリクエストにわたる活動を総合的に評価することがあります。

プロキシのローテーションでDataDomeの問題は解決しますか？

それだけでは解決しません。

ローテーションはネットワーク上の身元を変更しますが、ブラウザのフィンガープリント、TLSクライアント、JavaScript環境、またはリクエストの挙動を自動的に変更するわけではありません。

スクレイピングAPIはプロキシよりも優れていますか？

これらは異なる問題を解決するものです。

スクレイパーを自分で制御したい場合や、主にネットワークインフラが必要な場合は、プロキシを使用してください。

ブラウザ、プロキシ、レンダリング、データ抽出のインフラをより多く管理してもらいたい場合は、スクレイピングAPIを使用してください。

結論

DataDomeについて理解しておくべき最も重要な点は、「ボットの兆候」という単一の指標は存在しないということです。

現代のボット検知技術は、複数のレイヤーを横断して分析を行います。

リクエストとは、単なるIPアドレスではありません。

それは、

IPアドレス
がTLS接続を確立し
HTTPヘッダーを送信し
ブラウザやアプリケーションから
セッション内で
履歴を持ち
特定の行動パターンを示すもの

これらの要素が互いに整合しているほど、クライアントは一貫性があるように見えます。

だからこそ、IPアドレスを切り替えても、1つの問題は解決できても、他の5つの問題はそのまま残ってしまうのです。

これが、Playwrightがすべての検出問題を解決することなく、JavaScriptの実行問題を解決できる理由です。

そして、そもそもマネージドスクレイピングAPIが存在する理由でもあります。

完全な制御が必要な場合は、スタックを自作し、ネットワークインフラとしてプロキシを使用してください。

ブラウザやプロキシのオーケストレーションを管理することなく、主に信頼性の高いウェブコンテンツが必要な場合は、スクレイピングAPIを使用してください。

重要なのは、実際にどのレイヤーを修正しようとしているのかを理解することです。

DataDomeとは？ ボット検出の仕組みと、スクレイパーがブロックされる理由