ブログ / ウェブデータ
ウェブデータ

ブロックされずにウェブスクレイピングを行う：実証済みの12のテクニック

ブロックされずにウェブサイトをスクレイピングする方法のチュートリアル。ウェブサイトスクレイピングのブロックを回避する12の異なる解決策について学びましょう。
6 分読
Michael Nyamande

ボットが全ウェブトラフィックの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(プロキシ)

def fetch(url):
    プロキシ = next(proxy_pool)
    try:
        response = requests.get(
            url,
            proxies={"http": プロキシ, "https": プロキシ},
            timeout=10
        )
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
    print(f"プロキシ {proxy} が失敗しました: {e}")
    return None

# リクエスト間のランダムな遅延を追加し、レート制限を回避
time.sleep(random.uniform(2, 6))

高負荷な操作には単純なラウンドロビン方式以上のものが必要です。インテリジェントなセッション管理、自動IPリタイアメント、地理的ターゲティングによる選択が求められます。そのため本番環境のスクレイパーは静的リストではなく管理されたプロキシインフラを利用します。

2. レジデンシャルプロキシまたはモバイルプロキシを使用する

プロキシには優劣がある。データセンター・プロキシとレジデンシャルプロキシは、コストと検知リスクの根本的なトレードオフを示す。データセンター・プロキシはクラウドサーバーIP経由でトラフィックをルーティングする：高速・低コストだが、ASNブロックリストを持つボット対策システムには即座に非人間と識別される。

レジデンシャルプロキシは、実際の家庭や企業接続に紐づくISP割り当てIPアドレスを経由してトラフィックをルーティングします。対象サイトには、特定ISPの特定都市にいる実ユーザーからのリクエストのように見えます。モバイルプロキシはさらに進み、実際のモバイルキャリアIP（4G/5G）を経由してトラフィックをルーティングします。キャリアはCGNAT（1つのIPを多数の実ユーザーで共有）を使用するため、ブラックリスト登録される可能性がさらに低くなります。

プロキシの種類 検出可能性 速度 最適用途
データセンター 高 非常に高速 低セキュリティサイト、高トラフィック
ISP/固定住宅 中 高速 一貫したアイデンティティ、アカウントベースのスクラッピング
住宅 低 中 Eコマース、旅行、ソーシャルプラットフォーム
モバイル 非常に低い 中 モバイル専用コンテンツ、攻撃的なサイト

Bright Dataは195カ国以上で1億5000万以上のレジデンシャルIPネットワークを運営しており、倫理的に調達されたプロキシネットワークとしては最大規模です。レジデンシャルIPでさえフラグが立つシナリオでは、700万以上のモバイルIPが可能な限り最高の信頼シグナルを提供します。

3. 現実的なリクエストヘッダーの設定

Pythonのrequestsライブラリはデフォルトで最小限のヘッダーセットのみ送信します。実際のChromeブラウザと比較すると、その差は一目瞭然です：

# requestsがデフォルトで送信するもの:
User-Agent: python-requests/2.31.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

# Chrome 121が実際に送信するもの:
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文字列を送信することは、もう一つの簡単なフラグです。実際のユーザーが全員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)

ユーザーエージェントプールを最新の状態に保ってください。2021年以降のブラウザバージョンは、統計的に2026年の実際のトラフィックを反映する可能性が低いため、それ自体が検出シグナルとなります。

5. TLSフィンガープリント対策

これは最も見落とされがちな手法であり、他の対策を完璧に実施したスクレイパーさえも無力化するものです。

PythonのrequestsライブラリがHTTPS接続を開始すると、基盤となるTLSスタック（OpenSSLなど）は特定の暗号スイートと拡張機能の組み合わせでClientHelloを送信します。この組み合わせはJA3値にハッシュ化され、ブラウザ特有の値とは明らかに異なります。Cloudflare、Akamai、DataDomeはコンテンツ提供前にこのフィンガープリントをチェックするため、ヘッダーが評価される前にブロックされる可能性があります。

解決策：実際のブラウザのTLSスタックを模倣するHTTPクライアントを使用する。Pythonでは現在curl_cffiが標準：

from curl_cffi import requests as curl_requests

# impersonate="chrome121" は curl_cffi に Chrome 121 の正確な
# TLS 暗号スイート、拡張機能、HTTP/2 設定を使用するよう指示
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は、暗号レベルで実際のブラウザのTLSフィンガープリントを模倣するlibcurlのビルドであるcurl-impersonateをラップします。重要な要件：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()

    # navigator.webdriver、Chromeランタイム、iframeコンテンツウィンドウ、
    # メディアコーデック、その他の自動化痕跡をパッチ適用
    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は大幅に進化しており、パッチ適用済みのヘッドレスブラウザを依然として検知可能です。最高の信頼性を得るには、BrightDataのスクレイピングブラウザが最適です。これはプラグイン設定不要で、これらのチェックを最初から通過するよう特別に構築された事前強化済みブラウザ環境です。

7. リクエストのタイミングと動作をランダム化

固定間隔（たとえ余裕を持たせた間隔でも）でリクエストを送信するスクレイパーは、タイミング分析によって検知可能です。実際のユーザーは2.0秒ごとにページを訪問しません。彼らは読み、スクロールし、クリックし、一時停止し、非線形に移動します。

遅延にはガウス（正規）分布を使用します。これにより、ほとんどの遅延が平均値に集まる一方で、時折長くなるという人間らしい変動が生じます：

import numpy as np
import time
import random

def human_delay(mean=4.0, std=1.5, min_delay=1.0):
    """正規分布を用いて人間らしい遅延を生成"""
    delay = np.random.normal(mean, std)
    # 最小値を下回らないようにする
    delay = max(delay, min_delay)
    time.sleep(delay)

# ページリクエスト間
human_delay(mean=4.0, std=1.5)

# 同一ページ内アクション間（高速）
human_delay(mean=1.2, std=0.4)

タイミング以外にも、Playwrightで現実的なセッション動作をシミュレートしましょう：データ抽出前にページを段階的にスクロール、クリック前に要素へマウスを移動、常にターゲットURLへ直接移動せずクロール開始点を変化させるなど。

# コンテンツ抽出前に人間のスクロール動作をシミュレート
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には組み込みのCAPTCHAソルバーが搭載されており、reCAPTCHA、hCaptcha、Cloudflare Turnstileを透過的に処理します。統合は不要です。
import requests

# Bright Data Web Unlockerを使用すると、CAPTCHAは自動的に解決されます
# レスポンスが返される前に処理されます。ソルバーの統合は不要です。
response = requests.get(
    "https://target-site.com/product-page",
    proxies={
        "https": "https://username:[email protected]:33335"
    },
    verify=False  # Web Unlockerは独自のSSL証明書を使用
)

print(response.status_code)  # 200を返し、コンテンツは完全にレンダリングされる

9. ハニーポットトラップの回避

ハニーポットリンクは実際のユーザーには見えないが、生のHTMLでは見える。それらを追跡することは即座にボットのサインとなる。

リンクを辿る前にCSSの可視性をチェックして検出する:

from bs4 import BeautifulSoup

def is_visible(tag):
    """要素がCSSで非表示の場合Falseを返す"""
    style = tag.get("style", "")
    if "display:none" in style.replace(" ", "") or 
       "visibility:hidden" in style.replace(" ", ""):
        return False
    # 一般的なハニーポットクラス名もチェック
    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):
    """レート制限レスポンスに対して指数バックオフで再試行"""
    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:
            # Retry-Afterヘッダーが存在する場合、それを尊重する
            retry_after = int(response.headers.get("Retry-After", 2 ** attempt))
            print(f"レート制限中。 {retry_after}秒待機中 (試行回数 {attempt + 1})")
            time.sleep(retry_after)
        elif response.status_code in (403, 503):
            # ブロックされた可能性あり、IPをローテーションしてバックオフ
            print(f"ブロックされました (HTTP {response.status_code})。 バックオフ中...")
            time.sleep(2 ** attempt + random.uniform(0, 1))
        else:
            response.raise_for_status()

    raise Exception(f"{url} の最大再試行回数を超過しました")

11. 地理的コンテキストの適合

多くのサイトは、リクエストの地理的起源に基づいて異なるコンテンツを提供したり、より厳格なボット検出を実施したりします。米国のECサイトをターゲットとする製品価格スクレイパーは、ドイツやシンガポールのIPではなく、米国のレジデンシャルIPを経由してリクエストをルーティングすべきです。地理の不一致は、リクエストの起源とAccept-Languageやlocaleヘッダーとの間に不整合を生み、行動分析システムがフラグを立てる可能性があります。

Bright Dataのプロキシネットワークは、国・州・都市・通信事業者単位のターゲティングをサポートし、対象サイトが想定する正確な地理的コンテキストからリクエストを送信可能にします。地理的ターゲティング戦略を構築する前に、利用可能な全プロキシIPロケーションを調査できます。

12. 基盤となるAPIを活用する

複雑なスクレイパーを構築する前に、ターゲットサイトがフロントエンドで利用する内部APIを公開していないか確認しましょう。ブラウザの開発者ツールを開き、[ネットワーク]タブでサイト閲覧中のXHR/Fetchリクエストを監視します。大規模ECプラットフォームを含む多くのサイトは、HTMLパースよりも直接呼び出しがはるかに容易なJSONエンドポイントからデータをロードしています。

これらの内部APIは、構造化されたJSONレスポンス（HTMLパース不要）、メインレンダリングページより低いボット対策、自動化が容易なページネーションパラメータを備えていることが多い。

トレードオフ：内部APIは非公開で予告なく変更される可能性があり、メインサイト経由で取得が必要な認証トークンを要求する場合があります。しかし利用可能で安定している場合、これが最も効率的なスクレイピング経路となります。

最速の方法：ウェブスクレイピングAPIの利用

上記の12の手法はすべて、個別の実装、メンテナンス、そしてボット対策システムの進化に伴う継続的な適応を必要とします。規模が大きくなると、このスタックの管理自体が仕事になってしまいます。

代替案：スタック全体を単一のAPI呼び出しに統合する。

Bright Data Web Unlocker

Web UnlockerはAI搭載プロキシゲートウェイであり、対象サイトの要件に基づきIPローテーション、TLSフィンガープリント照合、CAPTCHAの解決、ブラウザレンダリングを自動処理します。標準的な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,)


# 完全にレンダリングされたブロック解除済みコンテンツを返す
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 Scraper API

特定のプラットフォームから構造化データを取得する必要があるチーム向けに、スクレイピングインフラの構築や保守が不要なBrightDataのScraper APIを提供。Amazon、LinkedIn、Instagram、Zillow、Indeed、TikTok、Walmart、Booking.com、Glassdoorなど主要ドメイン向けに120以上の既製スクレイパーをライブラリ化。

各スクレイパーはURLまたはキーワード入力を受け付け、内部でブロック解除とレンダリングを処理し、クリーンな構造化データをJSONまたはCSV形式で返します。プロキシ管理、パーサーのメンテナンス、フィンガープリント調整は不要です。成功して配信されたレコードに対してのみ課金されます。

# 例: スクレイパーAPI経由でAmazon商品スクレイピングを実行
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カ国以上で1億5000万以上のIPをカバーし、都市レベルや通信事業者レベルまで詳細な地域ターゲティングが可能です。モバイル通信事業者トラフィック向けの700万以上のモバイルIPと、信頼スコアの高いスタティックIP向けISPプロキシを含みます。

アンチボットシステム：直面する課題

Cloudflare

Cloudflare Bot Managementは最も広く導入されているアンチボットシステムであり、主要なECサイトやメディアサイトを含む数百万のサイトを保護しています。その動作は多層構造：JavaScriptチャレンジ（Turnstileを含む）、IPレピュテーションスコアリング、TLS/JA4フィンガープリンティング、行動分析で構成されます。Cloudflareのcf_clearanceクッキーは、実際のブラウザでチャレンジに合格すると取得でき、そのTTL内で再利用可能です。検出はnavigator.webdriverの露出、不一致なヘッダーセット、非ブラウザのJA4ハッシュに大きく依存しています。有効な手法の完全な技術的解説については、Cloudflareの回避方法に関するガイドを参照してください。

Akamai Bot Manager

Akamaiはクライアントサイドセンサーデータ（キャンバス、フォント、タイムゾーン、WebGL）を注入されたJavaScript経由で収集し、サーバーサイドでabckクッキートークンと照合します。TLS/JA3フィンガープリントとセッショントークンを同時に照合するため、単一レイヤーの修正では不十分です。Akamaiは企業向け小売、航空、金融サイトで広く採用されています。暗号スイートの不一致だけでソフトブロックや403エラーが発生する可能性があります。

DataDome

DataDomeはリアルタイムの機械学習ベースのスコアリングにより、スクレイピングブラウザとAPIの両方から保護します。IP ASN、リクエスト頻度、ヘッダーエントロピー、クライアントサイドJavaScriptシグナルを総合的に検証します。検証に失敗すると「アクセス拒否。DataDome提供」という特徴的なページが返されます。モバイルレジデンシャルIPと永続セッションを用いた完全なブラウザ自動化は、生のHTTPクライアントよりもDataDomeに対して大幅に優れた性能を発揮します。

PerimeterX / HUMAN

PerimeterX（現HUMAN Security）は行動分析を専門とし、マウス操作、キーストローク、スクロール深度、フォーカス/ブラーイベント、セッション全体のタイミングを追跡して行動フィンガープリントを構築します。人間の行動基準値とセッションを比較し、ボットスコアを割り当てます。特に注目すべきは遅延適用戦略を採用しており、疑わしいボットがブロックされる前に自由な閲覧を許容しつつ行動証拠を蓄積します。つまり、ブロックがトリガーされる前に最初のリクエストが成功する可能性があります。

比較：ブロックメカニズムと対策

ブロック方式 推奨手法 Bright Dataソリューション
IP禁止／レート制限 プロキシによるIPローテーション レジデンシャルプロキシ（1億5000万以上の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とplaywright-stealthから始める。

本番環境規模のスクラッピングの場合：フィンガープリントのローテーション、ステルスプラグインの更新、プロキシプールの管理、CAPTCHAの解決、ブラウザレンダリングを単一のAPI呼び出しに統合します。これにより、インフラではなくデータに集中できます。

よくある質問

ウェブサイトはスクレイピングを検知できますか？

はい。ウェブサイトはIPレピュテーション、HTTPヘッダー解析、TLSフィンガープリンティング、ブラウザフィンガープリンティング、CAPTCHAチャレンジ、行動分析を用いてスクレイパーを検出します。大半の検知はページコンテンツが配信される前の数ミリ秒で行われます。

ウェブスクレイパーがブロックされる理由は？

スクレイパーは、1つのIPから過剰なリクエストを送信した場合、非人間的なHTTPヘッダーを送信した場合、TLSまたはブラウザフィンガープリントチェックに失敗した場合、またはCAPTCHAチャレンジをトリガーした場合にブロックされます。レジデンシャルプロキシとステルスブラウザは、これらのリスクをすべて軽減します。

ブロックされずにスクレイピングする最善策は？

最も信頼性の高いアプローチは、ローテーションするレジデンシャルプロキシ、現実的なリクエストヘッダー、ランダムなタイミング遅延、ステルスプラグインを備えたヘッドレスブラウザを組み合わせることです。本番環境規模のウェブスクレイピングには、Bright DataのWeb Unlockerのようなマネージドソリューションがこれら全てを自動的に処理し、IPローテーション、TLSフィンガープリント管理、CAPTCHAの解決、ブラウザレンダリングを単一のAPI呼び出しに統合します。

ウェブスクレイピングは、特に個人情報や著作権保護対象外のデータについては、ほとんどの法域で一般的に合法です。対象サイトのrobots.txtと利用規約を必ず確認してください。個人データのウェブスクレイピングはGDPR、CCPAなどの法令で制限される場合があります。米国では、hiQ対LinkedIn判決により、公開データのウェブスクレイピングがコンピュータ詐欺・濫用防止法（CFAA）に違反しないことが確認されています。

TLSフィンガープリンティングとは何ですか？

TLSフィンガープリンティングは、HTTPSハンドシェイク時に使用される暗号スイート、TLSバージョン、拡張機能の固有の組み合わせを分析することで、クライアントの種類（ブラウザ、ボット、スクリプト）を識別します。アンチボットシステムはJA3およびJA4ハッシュを使用して、Pythonのrequestsライブラリなどの既知のスクラッピングツールをブロックします。重要な点：TLSスタックがChromeではなくOpenSSLのように見える場合、完全に現実的なHTTPヘッダーであっても効果はありません。

レジデンシャルプロキシがデータセンター・プロキシより優れている理由

レジデンシャルプロキシは、実際のISP割り当てIPアドレスを経由してトラフィックをルーティングします。アンチボットシステムは、すべての受信IPのASN（自律システム番号）をチェックします。 データセンターIPは既知のASN（AWS、GCPなど）に属し、高セキュリティサイトではデフォルトでブロックされます。レジデンシャルIPはComcastやBTなどのISPに属するため、ネットワーク層では実際のユーザートラフィックと区別がつきません。性能差の詳細な比較については、データセンター・プロキシとレジデンシャルプロキシの比較レポートをご覧ください。

目次

    あなたは下記にもご興味がおありかもしれません

    Nanobot with Bright Data blog image
    AI
    Satyam Tripathi
    Satyam Tripathi
    Technical Writer

    NanobotとBright DataでAIウェブスクレイピングエージェントを構築する

    このチュートリアルでは、NanobotとBright Data MCPサーバーを連携させ、AIエージェントに約15分でライブウェブアクセスを付与する方法を説明します。
    11-Mar-2026
    3 分読
    AWS Glue ETL jobs with Bright Data integration
    ウェブデータ
    Antonello Zanini
    Antonello Zanini
    Technical Writer

    Bright DataをAWS Glue ETLジョブに統合する：ステップバイステップガイド

    Bright DataのウェブスクレイピングAPIを活用したAWS Glue ETLパイプラインの構築方法を学びましょう。株価データの抽出から、S3に保存されたフィルタリング済み結果までをカバーします。
    10-Mar-2026
    2 分読
    AWS Step Functions for orchestrating complex scraping workflows
    ウェブデータ
    Antonello Zanini
    Antonello Zanini
    Technical Writer

    AWS Step Functionsを使用したウェブスクレイピングワークフローのオーケストレーション

    このガイドでは、Bright DataをAWS Step Functionsに統合し、HTTP API呼び出しまたはLambda関数を使用して信頼性が高くスケーラブルなウェブスクレイピングパイプラインを構築する方法を示します。
    10-Mar-2026
    2 分読