ボットは現在、全ウェブトラフィックの51%を占めています。ウェブサイト側もこれを把握しており、対策を強化しています。Cloudflare、Akamai、DataDomeのアンチボットシステムは、IPレピュテーション、TLSフィンガープリンティング、ブラウザフィンガープリンティング、行動分析を組み合わせて、HTMLが1行も返される前にスクレイパーをブロックします。スクレイパーがブロックされ続けている場合、このガイドでその理由を詳しく説明し、解決するための12の具体的なテクニックを紹介します。
クイックサマリー:ブロックされずにスクレイピングする方法
- レジデンシャルプロキシを使用してIPアドレスをローテーションする。データセンターIPは簡単にフラグが立てられます。
User-AgentやRefererを含む、ブラウザに似た完全なHTTPヘッダーを設定する。- 2秒から10秒の間で可変遅延を使用してリクエストのタイミングをランダム化する。
- ステルスプラグインを使用したヘッドレスブラウザでフィンガープリントチェックを通過する。
- 手動での解決はスケールしないため、CAPTCHAを自動的に処理する。
- プロキシのジオロケーションをターゲットサイトの想定ユーザーベースに合わせる。
- 管理されたスクレイピングAPI(Bright DataのWeb Unlockerなど)を使用して上記のすべてを自動化する。
ウェブサイトがウェブスクレイパーをブロックする理由
ブロックされる理由を理解することが、ブロックされないための第一歩です。検出はページをダウンロードした後に起こるのではありません。多くの場合、HTMLが提供される前の、接続の最初の数ミリ秒で起こります。最も一般的なアンチスクレイピング技術は階層的な組み合わせで機能するため、それらを回避するにはすべての層を同時に一致させる必要があります。
IPベースの検出
すべてのリクエストにはソースIPアドレスが含まれます。アンチボットシステムは、既知のデータセンターIP範囲(AWS、GCP、Azure、DigitalOcean)、以前にフラグが立てられたIP、高いリクエスト量を示すIPのレピュテーションデータベースを維持しています。1分間に500リクエストを送信する単一のIPは簡単に特定されます。実際のレジデンシャルユーザーはAWSデータセンターからアクセスしないため、データセンターIPは多くの高セキュリティサイトでデフォルトでフラグが立てられます。
ブラウザとTLSフィンガープリンティング
すべてのHTTPS接続はTLSハンドシェイクで始まります。ClientHelloフェーズ中、クライアントはコンテンツが交換される前に、サポートされている暗号スイート、TLSバージョン、拡張機能、楕円曲線の設定をすべてプレーンテキストでブロードキャストします。アンチボットシステムはこのデータをフィンガープリント(JA3またはJA4標準)にハッシュ化し、既知のボットシグネチャと比較します。Pythonのrequestsライブラリは、実際のブラウザとは異なる独特のTLSフィンガープリントを持っており、CloudflareとAkamaiによって簡単に検出されます。
TLSを超えて、ウェブサイトは数十のJavaScriptシグナルを通じてブラウザタイプを検出します:navigator.webdriver、キャンバスレンダリング出力、WebGL GPU文字列、インストールされたフォント、画面解像度、オーディオコンテキストの動作、プラグインリストなどです。ヘッドレスChromeはUser-Agent文字列にHeadlessChromeを公開し、navigator.webdriver = trueを設定したままにします。これはほとんどの主要なアンチボットプラットフォームで即座に検出されるシグナルです。
行動分析
ウェブサイトは個々のリクエストだけを見ているわけではありません。セッション全体のパターンを監視しています。PerimeterX/HUMANなどのシステムは、リクエスト間のタイミング、スクロールパターン、マウス移動の軌跡、クリック行動、ナビゲーションの深さ、セッション時間を測定します。ちょうど1.0秒間隔でリクエストを送信し、スクロールもマウス移動もせず、ホームページを訪問せずに深い商品ページに直接ジャンプするスクレイパーは、人間とは即座に区別できます。
CAPTCHAとJavaScriptチャレンジ
サイトが自動化を疑っているが確信がない場合、チャレンジを発行します。Cloudflare Turnstile、reCAPTCHA v3、hCaptchaは自動化のアーティファクトをチェックするJavaScriptプローブを実行します。これらのチャレンジに失敗するか、JavaScriptの実行が全くない場合、ブロックまたは無限リダイレクトループが発生します。
ハニーポットトラップ
一部のサイトはHTMLに隠しリンクを埋め込んでいます。CSS(display: none)によって実際のユーザーには見えませんが、生のHTMLを解析するスクレイパーには完全にアクセス可能です。これらのリンクをたどると即座にボットとしてフラグが立てられます。ドキュメント内のすべての<a href>タグを盲目的にたどるスクレイパーは、最終的にその罠にはまります。
ブロックされずにウェブサイトをスクレイピングするための主要テクニック
1. プロキシでIPアドレスをローテーションする
IPローテーションは最も基本的なアンチ検出テクニックです。単一のIPアドレスからすべてのリクエストを送信する代わりに、プロキシプールは何百または何千ものIPにトラフィックを分散させ、単一のIPが疑わしいリクエスト量を蓄積しないようにします。Pythonでプロキシをローテーションする方法を学ぶことは、本格的なスクレイパーを構築するすべての人にとって不可欠なスキルです。
基本的なパターン:各リクエストを異なるプロキシエンドポイントを通じてルーティングし、IPがブロックされた場合に自動リトライロジックを実装します。
import requests
from itertools import cycle
import random
import time
proxies = [
"http://proxy1.example.com:8080",
"http://proxy2.example.com:8080",
"http://proxy3.example.com:8080",
]
proxy_pool = cycle(proxies)
def fetch(url):
proxy = next(proxy_pool)
try:
response = requests.get(
url,
proxies={"http": proxy, "https": proxy},
timeout=10
)
response.raise_for_status()
return response.text
except requests.exceptions.RequestException as e:
print(f"Proxy {proxy} failed: {e}")
return None
# Add a random delay between requests to avoid rate limiting
time.sleep(random.uniform(2, 6))
大量の操作には、単純なラウンドロビンローテーション以上のものが必要です。インテリジェントなセッション管理、自動IP廃棄、ジオターゲット選択が必要です。そのため、本番スクレイパーは静的リストではなく管理されたプロキシインフラを使用します。
2. レジデンシャルまたはモバイルプロキシを使用する
すべてのプロキシが同等ではありません。データセンタープロキシとレジデンシャルプロキシは、コストと検出リスクの間の基本的なトレードオフを表しています。データセンター・プロキシはクラウドサーバーIPを通じてトラフィックをルーティングします:高速で安価ですが、ASNブロックリストを持つアンチボットシステムによって即座に非人間として識別されます。
レジデンシャルプロキシは、実際の家庭や企業の接続に紐付けられた実際のISP割り当てIPアドレスを通じてトラフィックをルーティングします。ターゲットサイトからは、リクエストが特定の都市の特定のISP上の実際のユーザーから来ているように見えます。モバイルプロキシは、実際のモバイルキャリアIP(4G/5G)を通じてトラフィックをルーティングすることでさらに進んでおり、キャリアがCGNAT(多くの実際のユーザーが共有する1つのIP)を使用するため、ブラックリストに載る可能性がさらに低くなります。
| プロキシタイプ | 検出可能性 | 速度 | 最適な用途 |
|---|---|---|---|
| データセンター | 高 | 非常に高速 | 低セキュリティサイト、大量処理 |
| ISP/スタティックレジデンシャル | 中 | 高速 | 一貫したID、アカウントベースのスクレイピング |
| レジデンシャル | 低 | 中程度 | Eコマース、旅行、ソーシャルプラットフォーム |
| モバイル | 非常に低 | 中程度 | モバイル専用コンテンツ、アグレッシブなサイト |
Bright Dataは195カ国以上に400M+のレジデンシャルIPのネットワークを運営しており、倫理的に調達された最大のプロキシネットワークです。レジデンシャルIPでさえフラグが立てられるシナリオでは、700万以上のモバイルIPが可能な限り最高の信頼シグナルを提供します。
3. リアルなリクエストヘッダーを設定する
Pythonのrequestsライブラリはデフォルトで最小限のヘッダーセットを送信します。実際のChromeブラウザと比較すると、その違いは一目瞭然です:
# What requests sends by default:
User-Agent: python-requests/2.31.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
# What Chrome 121 actually sends:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
サイトはAccept、Accept-Language、Accept-Encoding、Sec-Fetch-*ヘッダー、ヘッダーの順序をチェックして、実際のブラウザとスクリプトを区別します。同じドメインのページ間をナビゲートする際のRefererヘッダーを含め、主張しているブラウザに一致するヘッダーを設定してください。詳細については、ウェブスクレイピング用HTTPヘッダーのガイドをご覧ください。
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.9",
"Accept-Encoding": "gzip, deflate, br",
"Referer": "https://www.google.com/",
"Sec-Fetch-Dest": "document",
"Sec-Fetch-Mode": "navigate",
"Sec-Fetch-Site": "cross-site",
"Upgrade-Insecure-Requests": "1",
}
response = requests.get(url, headers=headers)
4. User-Agentをローテーションする
すべてのリクエストで同じUser-Agent文字列を送信することも簡単に検出されます。実際のユーザーが全員Windows 10上でChrome 121を使用しているわけではありません。現実的で最近アクティブなUser-Agent文字列のプールを構築してローテーションしてください。重要なルール:ローテーションするUser-Agentは内部的に一貫している必要があります。macOS上のChromeと主張する場合、Accept-LanguageとSec-CH-UAヘッダーもそれを反映する必要があります。
import random
user_agents = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
"Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0",
"Mozilla/5.0 (iPhone; CPU iPhone OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1",
]
headers["User-Agent"] = random.choice(user_agents)
User-Agentプールを最新の状態に保ってください。2021年のブラウザバージョンはそれ自体が検出シグナルです。2026年の実際のトラフィックを統計的に表す可能性が低いためです。
5. TLSフィンガープリンティングを管理する
これは最も見落とされがちなテクニックであり、他のすべてを正しく行ったスクレイパーを敗北させるものです。
PythonのrequestsライブラリがHTTPS接続を開始すると、基礎となるTLSスタック(OpenSSLなど)は特定の暗号スイートと拡張機能の組み合わせを持つClientHelloを送信します。この組み合わせは、明らかに非ブラウザであるJA3値にハッシュ化されます。Cloudflare、Akamai、DataDomeはコンテンツを提供する前にこのフィンガープリントをチェックするため、ヘッダーが評価される前にブロックされる可能性があります。
解決策:実際のブラウザのTLSスタックを模倣するHTTPクライアントを使用することです。curl_cffiがPythonの現在の標準です:
from curl_cffi import requests as curl_requests
# impersonate="chrome121" tells curl_cffi to use Chrome 121's exact
# TLS cipher suites, extensions, and HTTP/2 settings
response = curl_requests.get(
"https://example.com",
impersonate="chrome121",
headers={
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...",
}
)
print(response.status_code)
curl_cffiはcurl-impersonateをラップしており、暗号レベルで実際のブラウザTLSフィンガープリントを模倣するlibcurlのビルドです。重要な要件:User-Agentは模倣しているブラウザプロファイルと一致する必要があります。Firefox User-AgentとともにChrome 121 TLSフィンガープリントを送信すると、高度なシステムが検出する矛盾が生じます。
本番規模の使用には、Bright DataのWeb Unlockerがライブラリ管理不要でTLSフィンガープリントマッチングを自動的に処理します。
6. ステルスプラグインを使用したヘッドレスブラウザを使う
ターゲットサイトがJavaScriptチャレンジを実行する場合、実際のブラウザが必要です。ヘッドレスブラウザとは何かとその仕組みを理解することで、このテクニックの基盤が得られます。PlaywrightとPuppeteerはChromiumを自動化し、完全なJavaScript実行、Cookieの処理、動的コンテンツのレンダリングを可能にします。
問題点:デフォルトのヘッドレスChromeは簡単に検出されます。navigator.webdriver = true、HeadlessChrome User-Agent文字列、欠落しているブラウザプラグイン、異常な画面サイズを露出します。CloudflareのTurnstileと同様のシステムは200以上のJavaScriptチェックを実行し、デフォルトのPlaywrightセッションをミリ秒で捕捉します。
解決策はplaywright-stealthで、これらの検出ベクターにパッチを当てるプラグインです:
from playwright.sync_api import sync_playwright
from playwright_stealth import stealth_sync
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
# Patches navigator.webdriver, chrome runtime, iframe content windows,
# media codecs, and other automation artifacts
stealth_sync(page)
page.goto("https://example.com")
print(page.title())
browser.close()
playwright-stealthは最も一般的な検出ベクターを処理します:navigator.webdriver、window.chrome、navigator.plugins、navigator.languages、パーミッションAPIの不整合。Seleniumユーザーには、バイナリレベルでChromeDriverにパッチを当てるundetected-chromedriverが同等のツールです。
重要な制限:ステルスプラグインは検出リスクを軽減しますが、排除はしません。Cloudflare TurnstileとAkamai Bot Managerは大幅に進化しており、パッチを当てたヘッドレスブラウザを依然として捕捉できます。最大の信頼性のために、Bright Dataのスクレイピングブラウザは、プラグイン設定なしでこれらのチェックを通過するよう特別に構築された事前強化されたブラウザ環境です。
7. リクエストのタイミングと動作をランダム化する
固定間隔でリクエストを送信するスクレイパーは、余裕のある間隔であっても、タイミング分析によって検出可能です。実際のユーザーは2.0秒ごとにページを訪問しません。読んだり、スクロールしたり、クリックしたり、一時停止したり、非線形にナビゲートしたりします。
遅延にはガウス(正規)分布を使用してください。これにより、ほとんどの遅延が平均を中心にクラスター化されるが、時々長くなる人間に似たバリエーションが生成されます:
import numpy as np
import time
import random
def human_delay(mean=4.0, std=1.5, min_delay=1.0):
"""Generate a human-like delay using normal distribution."""
delay = np.random.normal(mean, std)
# Ensure we don't go below minimum
delay = max(delay, min_delay)
time.sleep(delay)
# Between page requests
human_delay(mean=4.0, std=1.5)
# Between actions on the same page (faster)
human_delay(mean=1.2, std=0.4)
タイミング以外にも、Playwrightでリアルなセッション動作をシミュレートしてください:データを抽出する前にページを段階的にスクロールし、クリックする前に要素にマウスを移動し、ターゲットURLに直接ナビゲートするのではなく、クロールのエントリポイントを変えてください。
# Simulate human scroll behavior before extracting content
page.evaluate("window.scrollTo(0, document.body.scrollHeight * 0.3)")
time.sleep(random.uniform(0.8, 2.0))
page.evaluate("window.scrollTo(0, document.body.scrollHeight * 0.7)")
time.sleep(random.uniform(0.5, 1.5))
8. CAPTCHAを自動的に処理する
CAPTCHAは壁であり、行き止まりではありませんが、手動での解決はスケールしません。本番スクレイピングには、自動化されたCAPTCHA処理が必要です。ウェブスクレイピングに最適なCAPTCHAソルバーを確認して、ユースケースに適したツールを選択してください。
主なアプローチ:
- サードパーティのソルバーサービス(2captcha、Anti-Captcha):CAPTCHAの画像またはサイトキーを人間のソルバーまたはAIモデルに送信し、トークンを受け取り、フォームに注入します。
- reCAPTCHA v3スコア管理:reCAPTCHA v3はサイレントに実行され、リスクスコアを割り当てます。スコアが高いほどチャレンジが表示される可能性が低くなるため、良好なセッション衛生(リアルなヘッダー、タイミング、閲覧履歴)によってスコアを高く保ちます。
- 管理されたソリューション:Bright DataのWeb Unlockerには、統合不要でreCAPTCHA、hCaptcha、Cloudflare Turnstileを透過的に処理する組み込みのCAPTCHAソルバーが含まれています。
import requests
# With Bright Data Web Unlocker, CAPTCHAs are solved automatically
# before the response is returned. No solver integration needed.
response = requests.get(
"https://target-site.com/product-page",
proxies={
"https": "https://username:[email protected]:33335"
},
verify=False # Web Unlocker uses its own SSL certificate
)
print(response.status_code) # Returns 200 with fully rendered content
9. ハニーポットトラップを避ける
ハニーポットリンクは実際のユーザーには見えませんが、生のHTMLには表示されます。それらをたどることは即座にボットシグナルになります。
リンクをたどる前にCSSの可視性をチェックして検出してください:
from bs4 import BeautifulSoup
def is_visible(tag):
"""Return False if the element is hidden via CSS."""
style = tag.get("style", "")
if "display:none" in style.replace(" ", "") or
"visibility:hidden" in style.replace(" ", ""):
return False
# Also check for common honeypot class names
classes = tag.get("class", [])
honeypot_classes = {"hidden", "invisible", "honeypot", "trap"}
if honeypot_classes.intersection(set(classes)):
return False
return True
soup = BeautifulSoup(html_content, "html.parser")
safe_links = [
a["href"] for a in soup.find_all("a", href=True)
if is_visible(a)
]
これですべてのハニーポットを捕捉できるわけではありません。インラインスタイルではなく外部CSSクラスで隠されているものもあるためです。Playwrightのpage.is_visible()メソッドは、インライン属性だけでなく計算されたCSSスタイルを評価するため、より信頼性が高いです。
10. 指数バックオフでレート制限を処理する
HTTP 429(Too Many Requests)レスポンスに対して、即座にリトライすることは逆効果です。ブロックを加速させます。指数バックオフを実装して、より厳しいバンをトリガーせずに優雅にバックオフしてスクレイピングを再開してください:
import time
import random
import requests
def fetch_with_backoff(url, headers, proxies, max_retries=5):
"""Retry with exponential backoff on rate limit responses."""
for attempt in range(max_retries):
response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
if response.status_code == 200:
return response
elif response.status_code == 429:
# Respect Retry-After header if present
retry_after = int(response.headers.get("Retry-After", 2 ** attempt))
print(f"Rate limited. Waiting {retry_after}s (attempt {attempt + 1})")
time.sleep(retry_after)
elif response.status_code in (403, 503):
# Likely blocked, rotate IP and back off
print(f"Blocked (HTTP {response.status_code}). Backing off...")
time.sleep(2 ** attempt + random.uniform(0, 1))
else:
response.raise_for_status()
raise Exception(f"Max retries exceeded for {url}")
11. 地理的コンテキストを一致させる
多くのサイトは、リクエストの地理的起源に基づいて異なるコンテンツを提供したり、より厳格なボット検出を実施したりします。米国のEコマースサイトをターゲットにした商品価格スクレイパーは、ドイツやシンガポールのIPではなく、米国のレジデンシャルIPを通じてリクエストをルーティングする必要があります。地理的な不一致は、リクエストの起源とAccept-Languageまたはロケールヘッダーの間に矛盾を生み出し、行動分析システムがフラグを立てる可能性があります。
Bright Dataのプロキシネットワークは国、州、都市、キャリアによるターゲティングをサポートしており、ターゲットサイトが期待する正確な地理的コンテキストからリクエストを発信できます。ジオターゲティング戦略を構築する前に、利用可能なすべてのプロキシIPロケーションを確認できます。
12. 基盤となるAPIを活用する
複雑なスクレイパーを構築する前に、ターゲットサイトがフロントエンドが使用する内部APIを公開しているかどうかを確認してください。ブラウザの開発者ツールを開き、ネットワークタブに移動し、サイトをナビゲートしながらXHR/Fetchリクエストを監視してください。大規模なEコマースプラットフォームを含む多くのサイトは、HTMLを解析するよりも直接呼び出す方がはるかに簡単なJSONエンドポイントからデータを読み込みます。
これらの内部APIは多くの場合、構造化されたJSONレスポンス(HTMLパースが不要)、メインのレンダリングページよりも低いアンチボット監視、自動化が簡単なページネーションパラメータを持っています。
トレードオフ:内部APIはドキュメント化されておらず、予告なしに変更される可能性があり、メインサイトを通じて取得する必要がある認証トークンが必要な場合があります。しかし、利用可能で安定している場合、それらは最も効率的なスクレイピングパスです。
最速の方法:ウェブスクレイピングAPIを使用する
上記の12のテクニックはすべて、個別の実装、メンテナンス、アンチボットシステムの進化に伴う継続的な適応が必要です。規模が大きくなると、このスタックの管理自体が仕事になります。
代替手段:スタック全体を単一のAPI呼び出しに統合することです。
Bright Data Web Unlocker
Web Unlockerは、ターゲットサイトの要件に基づいてIPローテーション、TLSフィンガープリントマッチング、CAPTCHAの解決、ブラウザレンダリングを自動的に処理するAI搭載のプロキシゲートウェイです。標準的なHTTPリクエストを行うと、Web Unlockerが使用するプロキシタイプ、提示するフィンガープリント、CAPTCHAを解決するかどうか、JavaScriptをレンダリングするかどうかを決定し、サイトのアンチボットの複雑さに関係なくクリーンなコンテンツを返します。
import requests
response = requests.get(
"https://any-protected-site.com/data",
proxies={"https": "https://user:[email protected]:33335"},
verify=False,
)
# Returns fully rendered, unblocked content
print(response.text)
Web UnlockerはCloudflare、Akamai、DataDome、PerimeterXに対してテストされ、継続的に更新されています。1回のAPI呼び出しで10の手動テクニックを置き換えます。
Bright Data スクレイピングブラウザ
マルチステップフロー、ログインシーケンス、JavaScriptが多いSPAを含む完全なブラウザインタラクションが必要なサイトには、スクレイピングブラウザがCDP経由でアクセス可能な事前強化されたChromiumインスタンスを提供します。PlaywrightとPuppeteerと直接統合し、プラグイン設定なしでCloudflare TurnstileとAkamai Bot Managerのフィンガープリンティングチェックを通過します。
from playwright.sync_api import sync_playwright
SBR_WS_CDP = "wss://brd-customer-XXXX:[email protected]:9222"
with sync_playwright() as pw:
browser = pw.chromium.connect_over_cdp(SBR_WS_CDP)
page = browser.new_page()
page.goto("https://cloudflare-protected-site.com")
print(page.inner_text("body"))
browser.close()
Bright Data スクレイパーAPI
スクレイピングインフラを作成または維持することなく特定のプラットフォームから構造化データが必要なチームには、Bright DataのスクレイパーAPIが最も人気のあるドメイン向けの120以上の既製スクレイパーライブラリを提供しています:Amazon、LinkedIn、Instagram、Zillow、Indeed、TikTok、Walmart、Booking.com、Glassdoorなど。
各スクレイパーはURLまたはキーワード入力を受け付け、すべてのアンブロッキングとレンダリングを内部で処理し、JSONまたはCSVでクリーンな構造化データを返します。プロキシ管理、パーサーのメンテナンス、フィンガープリントの調整は不要です。正常に配信されたレコードのみに対して支払います。
# Example: trigger an Amazon product scrape via the Scraper APIs
curl -H "Authorization: Bearer API_TOKEN"
-H "Content-Type: application/json"
-d '[{"url":"https://www.amazon.com/dp/B0CRMZHDG8","asin":"B0CRMZHDG8","zipcode":"94107"}]'
"https://api.brightdata.com/datasets/v3/trigger?dataset_id=gd_l7q7dkf244hwjntr0&format=json"
専用スクレイパーはEコマースプラットフォーム、LinkedIn、ソーシャルメディアチャンネル向けに利用可能で、Webhook、APIポーリング、または直接ダウンロードで結果を配信できます。まだカバーされていないドメインには、Scraper Studioを使用してAIでカスタムスクレイパーをインフラ作業なしで構築できます。
Bright Data レジデンシャルプロキシ
独自のスクレイピングインフラを管理しているが、信頼性の高い大規模なIPプールが必要なシナリオには:Bright Dataのレジデンシャルプロキシネットワークは195カ国以上に400M+のIPをカバーし、都市およびキャリアレベルまでの細かいジオターゲティングが可能です。モバイルキャリアトラフィック用の700万以上のモバイルIPと、高い信頼スコアを持つスタティックレジデンシャルIPのためのISPプロキシが含まれています。
アンチボットシステム:対峙している相手
Cloudflare
Cloudflare Bot Managementは最も広く展開されているアンチボットシステムで、ほとんどの主要なEコマースおよびメディアプロパティを含む何百万ものサイトを保護しています。層で動作します:JavaScriptチャレンジ(Turnstileを含む)、IPレピュテーションスコアリング、TLS/JA4フィンガープリンティング、行動分析。Cloudflareのcf_clearance Cookieは、実際のブラウザでチャレンジを通過することで取得され、TTL内で再利用できます。検出は主にnavigator.webdriverの露出、不整合なヘッダーセット、非ブラウザJA4ハッシュに依存しています。機能するメソッドの完全な技術的解説については、Cloudflareをバイパスする方法のガイドをご覧ください。
Akamai Bot Manager
Akamaiは注入されたJavaScriptを介してクライアント側のセンサーデータ(キャンバス、フォント、タイムゾーン、WebGL)を収集し、abck Cookieトークンに対してサーバー側で検証します。TLS/JA3フィンガープリントとセッショントークンを同時に相互参照するため、1つの層だけを修正するだけでは不十分です。Akamaiはエンタープライズ小売、航空会社、金融サイトで一般的です。不一致な暗号スイートだけでもソフトブロックまたは403をトリガーする可能性があります。
DataDome
DataDomeはリアルタイムのMLベースのスコアリングでブラウザスクレイピングとAPIスクレイピングの両方から保護します。IP ASN、リクエストのケイデンス、ヘッダーエントロピー、クライアント側のJavaScriptシグナルを一緒に検証します。検証に失敗すると、特徴的な「Access denied. Powered by DataDome.」ページが返されます。モバイルレジデンシャルIPと永続的なセッションを使用した完全なブラウザ自動化は、生のHTTPクライアントよりもDataDomeに対して大幅に優れたパフォーマンスを発揮します。
PerimeterX / HUMAN
PerimeterX(現在はHUMAN Security)は行動分析を専門とし、マウスの動き、キーストローク、スクロールの深さ、フォーカス/ブラーイベント、セッション全体のタイミングを追跡して行動フィンガープリントを構築します。セッションを人間のベースラインと比較し、ボットスコアを割り当てます。注目すべきは、遅延実施戦略を使用しており、ブロックする前に行動証拠を蓄積しながら疑わしいボットが自由にブラウズできるようにします。これはブロックがトリガーされる前に最初のいくつかのリクエストが成功する可能性があることを意味します。
比較:ブロッキングメカニズムと対策
| ブロッキングメカニズム | 推奨テクニック | Bright Dataソリューション |
|---|---|---|
| IPバン / レート制限 | プロキシでIPをローテーション | レジデンシャルプロキシ(400M+ IP) |
| データセンターIP検出 | レジデンシャルまたはモバイルプロキシを使用 | ISPプロキシ、モバイルプロキシ |
| TLSフィンガープリンティング | ブラウザ模倣によるcurl_cffi |
Web Unlocker(自動TLSマッチング) |
| ブラウザフィンガープリンティング | ヘッドレスブラウザ + ステルスプラグイン | スクレイピングブラウザ(ステルス内蔵) |
| CAPTCHAチャレンジ | 自動化されたCAPTCHAソルバー | Web Unlocker(内蔵ソルバー) |
| 行動分析 | タイミングのランダム化 + 人間の行動をシミュレート | スクレイピングブラウザ(人間に似た動作) |
| ハニーポットトラップ | 隠しリンクをスキップ | スクレイピングブラウザ(インテリジェントナビゲーション) |
| JavaScriptチャレンジ | 完全なブラウザレンダリング | スクレイピングブラウザ、Web Unlocker |
| ジオブロッキング | ジオターゲットプロキシ | 195カ国以上のターゲティング |
| レート制限 | 指数バックオフ | Web Unlocker(管理されたレート制限) |
まとめ
すべてのアンチボットシステムを打ち負かす単一のテクニックはありません。現代の検出はIPレピュテーション、TLSフィンガープリンティング、ブラウザフィンガープリンティング、行動分析にわたって階層化されており、それを回避するにはすべての層を同時に一致させる必要があります。
開発および低量スクレイピングには:レジデンシャルプロキシ、リアルなヘッダー、TLSフィンガープリント管理のためのcurl_cffi、JavaScriptが多いサイト向けのplaywright-stealthを使用したPlaywrightから始めてください。
本番規模のスクレイピングには:ローテーションフィンガープリント、ステルスプラグインの更新、プロキシプールの管理、CAPTCHAソルバーの統合を含む、これらすべての層を手動で維持する複雑さは相当なものです。Bright DataのソリューションはIPローテーション、TLSフィンガープリント管理、CAPTCHAの解決、ブラウザレンダリングを単一のAPI呼び出しに統合します。これにより、インフラではなくデータに集中できます。
よくある質問
ウェブサイトはスクレイピングしているかどうかわかりますか?
はい。ウェブサイトはIPレピュテーション、HTTPヘッダー分析、TLSフィンガープリンティング、ブラウザフィンガープリンティング、CAPTCHAチャレンジ、行動分析を使用してスクレイパーを検出します。ほとんどの検出はページコンテンツが提供される前のミリ秒単位で起こります。
ウェブスクレイパーがブロックされるのはなぜですか?
スクレイパーは、1つのIPから多すぎるリクエストを行ったり、非人間的なHTTPヘッダーを送信したり、TLSまたはブラウザフィンガープリントチェックに失敗したり、CAPTCHAチャレンジをトリガーしたりするとブロックされます。レジデンシャルプロキシとステルスブラウザはこれらのリスクをすべて軽減します。
ブロックされずにスクレイピングする最善の方法は何ですか?
最も信頼性の高いアプローチは、ローテーションするレジデンシャルプロキシ、リアルなリクエストヘッダー、ランダムなタイミング遅延、ステルスプラグインを使用したヘッドレスブラウザを組み合わせることです。本番規模のスクレイピングには、Bright DataのWeb Unlockerのような管理されたソリューションがIPローテーション、TLSフィンガープリント管理、CAPTCHAの解決、ブラウザレンダリングを単一のAPI呼び出しに統合して、これらすべてを自動的に処理します。
ウェブスクレイピングは合法ですか?
公開されているデータのウェブスクレイピングは、特に非個人・非著作権データについては、ほとんどの法域で一般的に合法です。常にターゲットサイトのrobots.txtと利用規約を確認してください。個人データのスクレイピングはGDPR、CCPA、および類似の法律の下で制限される場合があります。米国では、hiQ v. LinkedInの判決が公開データのスクレイピングはコンピュータ詐欺・不正使用法に違反しないと確認しました。
TLSフィンガープリンティングとは何ですか?
TLSフィンガープリンティングは、HTTPSハンドシェイク中に使用される暗号スイート、TLSバージョン、拡張機能のユニークな組み合わせを分析することで、クライアントのタイプ(ブラウザ、ボット、スクリプト)を識別します。アンチボットシステムはJA3およびJA4ハッシュを使用して、Pythonのrequestsライブラリなどの既知のスクレイピングツールをブロックします。重要な意味:TLSスタックがChromeではなくOpenSSLのように見える場合、完全にリアルなHTTPヘッダーでも役立ちません。
レジデンシャルプロキシがデータセンタープロキシよりも優れているのはなぜですか?
レジデンシャルプロキシは実際のISP割り当てIPアドレスを通じてトラフィックをルーティングします。アンチボットシステムはすべての受信IPのASN(自律システム番号)をチェックします。データセンターIPは、高セキュリティサイトでデフォルトでブロックされている既知のASN(AWS、GCPなど)に属しています。レジデンシャルIPはComcastやBTなどのISPに属しており、ネットワーク層で実際のユーザートラフィックと区別できません。パフォーマンスの違いの完全な詳細については、データセンター対レジデンシャルプロキシの比較をご覧ください。