ボットは現在、全ウェブトラフィックの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でプロキシをローテーションする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は400M+のレジデンシャルIPを195カ国以上にわたって運営しており、倫理的に調達された最大のプロキシネットワークです。レジデンシャル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は模倣しているブラウザプロファイルと一致する必要があります。Chrome 121のTLSフィンガープリントをFirefoxのUser-Agentと一緒に送信すると、高度なシステムが検出できる不一致が生じます。
本番規模での使用には、Bright DataのWeb Unlockerがライブラリ管理なしでTLSフィンガープリントマッチングを自動的に処理します。
6. ステルスプラグインを使用したヘッドレスブラウザを使う
ターゲットサイトがJavaScriptチャレンジを実行する場合、実際のブラウザが必要です。ヘッドレスブラウザとは何かとその仕組みを理解することが、このテクニックの基礎となります。PlaywrightとPuppeteerはChromiumを自動化し、完全なJavaScript実行、クッキー処理、動的コンテンツのレンダリングを可能にします。
問題:デフォルトのヘッドレス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(リクエスト過多)レスポンスに対して即座に再試行することは逆効果です。ブロックを加速させます。より厳しいBANを引き起こさずにスクレイピングを再開するために、指数バックオフを実装して優雅にバックオフします:
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ポーリング、または直接ダウンロードで配信できます。まだカバーされていないドメインには、スクレイパースタジオがインフラ作業なしで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クッキーは、実際のブラウザでチャレンジを通過することで取得でき、TTL内で再利用できます。検出は主にnavigator.webdriverの露出、一貫性のないヘッダーセット、非ブラウザのJA4ハッシュに依存しています。有効な方法の完全な技術的解説については、Cloudflareをバイパスする方法のガイドをご覧ください。
Akamai Bot Manager
Akamaiは注入されたJavaScriptを通じてクライアントサイドのセンサーデータ(キャンバス、フォント、タイムゾーン、WebGL)を収集し、abckクッキートークンに対してサーバーサイドで検証します。TLS/JA3フィンガープリントとセッショントークンを同時に相互参照するため、一つの層だけを修正しても不十分です。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に属しており、ネットワーク層で実際のユーザートラフィックと区別がつきません。パフォーマンスの違いの完全な内訳については、データセンター対レジデンシャルプロキシの比較をご覧ください。