ウェブスクレイピングでバン率を5%に抑える方法：12の実証済み保護手段

マーケットプレイスのパース、競合他社の価格監視、サイトからのデータ収集を行っている場合、次のような問題をご存知でしょう:サイトがIPアドレスをブロックし、キャプチャを要求したり、空白ページを返したりします。Ban rate(ブロックされたリクエストの割合)は70-90%に達することがあり、パースを不可能にします。この記事では、ban rateを5-10%まで削減し、安定的にデータを収集するための具体的な手法を解説します。

技術的ソリューション(プロキシローテーション、HTTPヘッダー、フィンガープリンティング)と行動パターン(遅延、ユーザーアクションの模倣)の両方を検討します。すべての手法は、Wildberries、Ozon、Avito、海外プラットフォームのパースで実証済みです。

サイトがパーサーをブロックする理由:主なトリガー

保護手法を解説する前に、サイトが自動化されたトラフィックをどのように検出するかを理解することが重要です。最新のアンチボットシステム(Cloudflare、Akamai、DataDome、Imperva)は、各リクエストの数十のパラメータを分析します。主なブロックトリガーは以下の通りです:

例えば、Wildberriesのパース時の典型的なエラーは、1つのIPから0.5秒ごとにリクエストを送信することです。Cloudflareのアンチボットシステムはパターンを即座に検出し、IPを24時間ブロックします。実際のユーザーは商品カードの閲覧に5-15秒を費やし、ページをスクロールし、画像をクリックします。

プロキシローテーション:IPアドレスの正しい変更方法

プロキシの使用はban rate削減の基本的な手法です。しかし、単にプロキシを購入するだけでなく、ローテーションを正しく設定することが重要です。実証済みの戦略は以下の通りです:

パース用プロキシタイプの選択

マーケットプレイス(Wildberries、Ozon、Avito)のパースには、レジデンシャルプロキシが推奨されます。これらは実際の家庭ユーザーのIPを持ち、通常のトラフィックと区別するのが困難です。データセンタープロキシは、保護の弱いサイトや大量データで最大速度が必要な場合に適しています。

IPアドレスローテーション戦略

プロキシプールのサイズ

最小プールサイズはパースの強度に依存します:

• 低強度(1日10,000リクエストまで):10-20プロキシ
• 中強度(1日10,000 - 100,000リクエスト):50-100プロキシ
• 高強度(1日100,000リクエスト以上):200以上のプロキシまたは自動ローテーション付きレジデンシャル

各リクエストでローテーションするレジデンシャルプロキシ(rotating proxies)の場合、プロバイダーが数百万のアドレスプールから自動的に新しいIPを割り当てるため、プールサイズは小さくても構いません。

User-AgentとHTTPヘッダー:実際のブラウザの模倣

良好なプロキシを使用していても、HTTPヘッダーが疑わしい場合はブロックされる可能性があります。サイトはUser-Agentだけでなく、ヘッダーの順序、値、相互の一致も分析します。

正しいUser-Agent

すべてのリクエストに同じUser-Agentを使用しないでください。人気のあるブラウザのリストを作成し、ランダムに選択します:

user_agents = [
    # Windows上のChrome
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    # macOS上のChrome
    "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",
    # Windows上のFirefox
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0",
    # macOS上のSafari
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1 Safari/605.1.15",
    # Windows上のEdge
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0"
]

完全なHTTPヘッダーセット

最新のブラウザは15-20のヘッダーを送信します。Chromeを模倣するための最小限必要なセットは以下の通りです:

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
    "Accept-Language": "ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7",
    "Accept-Encoding": "gzip, deflate, br",
    "DNT": "1",
    "Connection": "keep-alive",
    "Upgrade-Insecure-Requests": "1",
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-User": "?1",
    "Cache-Control": "max-age=0",
    "sec-ch-ua": '"Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"',
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": '"Windows"'
}

Sec-Fetch-*とsec-ch-ua-*ヘッダーに注意してください — これらは新しいバージョンのChromeに登場し、その欠如は自動化を露呈する可能性があります。

ヘッダーの順序が重要

ブラウザは特定の順序でヘッダーを送信します。例えば、Chromeは常にHostを最初に、次にConnection、User-Agentなどの順に配置します。Pythonのrequestsライブラリを使用している場合、順序がアルファベット順になる可能性があり、自動化を露呈します。

解決策:ヘッダーを正しく形成するライブラリ(Pythonのcurl_cffi、Node.jsのgot)を使用するか、実際のブラウザのようにヘッダーを生成するヘッドレスブラウザ(Puppeteer、Playwright、Selenium)を使用します。

リクエスト間の遅延:最適な間隔

ban rate削減の最もシンプルで効果的な手法の1つは、リクエスト間の適切な遅延です。実際のユーザーは1秒間に10ページを開くことはできないため、速すぎるリクエストは即座にブロックを引き起こします。

固定遅延の代わりにランダム遅延

固定遅延(例:リクエスト間正確に2秒)を使用しないでください。アンチボットシステムはそのようなパターンを簡単に検出します。ランダムな間隔を使用します:

import random
import time

# 固定遅延の代わりに
time.sleep(2)  # ❌ 悪い

# ランダムな間隔を使用
delay = random.uniform(2.5, 5.5)  # ✅ 良い
time.sleep(delay)

異なるサイトの推奨間隔

サーバー応答に基づく適応的遅延

高度なアプローチ — サーバー応答に応じて遅延を動的に変更します:

base_delay = 3.0  # 基本遅延
delay_multiplier = 1.0

response = requests.get(url, headers=headers, proxies=proxies)

# キャプチャまたは429を受け取った場合 — 遅延を増やす
if response.status_code == 429 or 'captcha' in response.text.lower():
    delay_multiplier *= 1.5
    print(f"保護を検出、遅延を{base_delay * delay_multiplier}秒に増加")

# すべて正常な場合 — 少し速くできる
elif response.status_code == 200:
    delay_multiplier = max(1.0, delay_multiplier * 0.95)

time.sleep(random.uniform(base_delay * delay_multiplier, base_delay * delay_multiplier * 1.5))

このアプローチにより、保護検出時に自動的に減速し、サイトが攻撃的でない場合は加速できます。

フィンガープリンティング対策:Canvas、WebGL、フォント

サイトがJavaScriptを使用して検証する場合、単純なHTTPヘッダーでは不十分です。最新のアンチボットシステムは、Canvas、WebGL、インストールされたフォント、タイムゾーン、画面解像度などの数十のパラメータに基づいてブラウザの「指紋」(fingerprint)を作成します。

フィンガープリンティングの主なパラメータ

フィンガープリンティング回避ツール

フィンガープリンティングを回避するには、専用ツールを使用します:

• Undetected ChromeDriver(Python) — 自動化の兆候を隠す改良版Selenium
• Puppeteer Stealth(Node.js) — fingerprintパラメータを置き換えるPuppeteerプラグイン
• Playwright with stealth — Puppeteerと同様ですが、異なるブラウザのサポートが優れている
• アンチ検出ブラウザ(Dolphin Anty、AdsPower、Multilogin) — コードを書きたくない人向け、これらのブラウザは自動的にfingerprintを置き換えます

Pythonでundetected-chromedriverを使用する例:

import undetected_chromedriver as uc

# 検出保護付きブラウザを作成
options = uc.ChromeOptions()
options.add_argument('--disable-blink-features=AutomationControlled')

driver = uc.Chrome(options=options)
driver.get('https://example.com')

# navigator.webdriver === undefinedを確認
webdriver_status = driver.execute_script("return navigator.webdriver")
print(f"navigator.webdriver: {webdriver_status}")  # None/undefinedであるべき

Cookieとセッションの管理

多くのサイトはユーザーの行動を追跡するためにCookieを使用します。Cookieの適切な管理は、ブロックを回避し、実際のユーザーのように見えるのに役立ちます。

Cookieの保存と再利用

各リクエストで新しいセッションを作成する代わりに、Cookieを保存して再利用します。これは、サイトに戻る実際のユーザーの行動を模倣します:

import requests
import pickle

session = requests.Session()

# 初回訪問 — Cookieを取得
response = session.get('https://example.com')

# Cookieをファイルに保存
with open('cookies.pkl', 'wb') as f:
    pickle.dump(session.cookies, f)

# 後でCookieを読み込む
with open('cookies.pkl', 'rb') as f:
    session.cookies.update(pickle.load(f))

# リクエストが戻ってきたユーザーからのように見える
response = session.get('https://example.com/catalog')

パース前のセッションウォームアップ

ターゲットページからすぐにパースを開始しないでください。実際のユーザーの行動を模倣します:

1. サイトのメインページを開く
2. 2-5秒待つ
3. カテゴリまたはセクションページを開く
4. 3-7秒待つ
5. その後初めてターゲットページのパースを開始

これにより、Cookie内にアクティビティ履歴が作成され、ブロックの可能性が低下します。

セッションCookieとトークンの処理

一部のサイトは初回訪問時にユニークなトークンを生成し、後続のリクエストでそれを検証します。例えば、Wildberriesはx-requested-withヘッダーでトークンを使用します。常に最初の応答からそのようなトークンを保存し、後続のリクエストで送信してください。

JavaScriptレンダリング:必要な場合

多くの最新サイトはJavaScriptを介してコンテンツを読み込みます。単純なHTTPクライアント(PythonのrequestsやNode.jsのaxios)を使用している場合、空白ページやプレースホルダーを受け取ります。そのような場合、JavaScriptレンダリングが必要です。

JavaScriptレンダリングが必要な場合

• サイトがReact、Vue、Angularを使用 — コンテンツは初期ページ読み込み後に読み込まれる
• データがAJAX/Fetchリクエストを介して読み込まれる
• サイトがトークンまたはCookieの生成にJavaScript実行を要求
• JS-コードの実行を要求するボット対策が存在(例:Cloudflare Challenge)

JavaScriptレンダリングツール

ほとんどのタスクにはPlaywrightが推奨されます — Seleniumより高速で、保護回避が優れており、より便利なAPIを持っています。

代替案:APIリクエストのインターセプト

サイトがデータ読み込みに使用するAPIリクエストを見つければ、JavaScriptレンダリングを回避できることがよくあります。DevTools(F12)を開く → Networkタブ → XHR/Fetchフィルターで、サイトが送信するリクエストを確認します。その後、HTTPクライアントを介してこれらのリクエストを直接再現します。

例:WildberriesはAPI https://catalog.wb.ru/catalog/...を介して商品データを読み込みます。ページ全体をレンダリングする代わりに、このAPIを直接リクエストできます。これは10-20倍高速です。

キャプチャ回避:自動ソリューション

適切なプロキシとヘッダーを使用していても、キャプチャに遭遇する可能性があります。解決にはいくつかのアプローチがあります:

キャプチャのタイプと解決方法

キャプチャ認識サービスの統合

Pythonで2Captchaを統合する例:

from twocaptcha import TwoCaptcha

solver = TwoCaptcha('YOUR_API_KEY')

try:
    # reCAPTCHA v2を解決
    result = solver.recaptcha(
        sitekey='6Le-wvkSAAAAAPBMRTvw0Q4Muexq9bi0DJwx_mJ-',
        url='https://example.com'
    )
    
    # 解決トークンを取得
    captcha_token = result['code']
    
    # トークン付きフォームを送信
    response = requests.post('https://example.com/submit', data={
        'g-recaptcha-response': captcha_token
    })
    
except Exception as e:
    print(f"キャプチャ解決エラー: {e}")

レート制限:サイトの制限を超えない方法

多くのサイトにはリクエスト数に明示的または暗黙的な制限があります。これらの制限を超えると、IPの一時的または永続的なブロックにつながります。

サイトの制限の判定

サーバー応答のHTTPヘッダーに注意してください:

• X-RateLimit-Limit — 期間内の最大リクエスト数
• X-RateLimit-Remaining — 残りのリクエスト数
• X-RateLimit-Reset — 制限がリセットされる時刻(Unixタイムスタンプ)
• Retry-After — リクエストを再試行できるまでの秒数

ステータスコード429(Too Many Requests)を受け取った場合、制限超過を意味します。Retry-Afterヘッダーを読み、次のリクエスト前に指定された時間待ってください。

レートリミッターの実装

リクエスト速度制御メカニズムを作成します:

import time
from collections import deque

class RateLimiter:
    def __init__(self, max_requests, time_window):
        self.max_requests = max_requests  # 最大リクエスト数
        self.time_window = time_window    # 時間枠(秒)
        self.requests = deque()
    
    def wait_if_needed(self):
        now = time.time()
        
        # 時間枠外の古いリクエストを削除
        while self.requests and self.requests[0] < now - self.time_window:
            self.requests.popleft()
        
        # 制限に達した場合 — 待機
        if len(self.requests) >= self.max_requests:
            sleep_time = self.time_window - (now - self.requests[0])
            if sleep_time > 0:
                print(f"レート制限に達しました。{sleep_time:.2f}秒待機中...")
                time.sleep(sleep_time)
                self.requests.popleft()
        
        # 現在のリクエストを記録
        self.requests.append(time.time())

# 使用例:1分間に最大30リクエスト
limiter = RateLimiter(max_requests=30, time_window=60)

for url in urls:
    limiter.wait_if_needed()
    response = requests.get(url)

メトリクス監視:ban rateの追跡

パースの効果を評価し、問題を早期に検出するには、主要メトリクスを監視する必要があります:

追跡すべき主要メトリクス

監視システムの実装

シンプルなメトリクス収集システムの例:

class ScraperMetrics:
    def __init__(self):
        self.total_requests = 0
        self.successful_requests = 0
        self.blocked_requests = 0
        self.captcha_requests = 0
        self.response_times = []
    
    def record_request(self, success, blocked=False, captcha=False, response_time=0):
        self.total_requests += 1
        if success:
            self.successful_requests += 1
        if blocked:
            self.blocked_requests += 1
        if captcha:
            self.captcha_requests += 1
        if response_time > 0:
            self.response_times.append(response_time)
    
    def get_stats(self):
        if self.total_requests == 0:
            return "リクエストなし"
        
        ban_rate = (self.blocked_requests / self.total_requests) * 100
        success_rate = (self.successful_requests / self.total_requests) * 100
        captcha_rate = (self.captcha_requests / self.total_requests) * 100
        avg_response_time = sum(self.response_times) / len(self.response_times) if self.response_times else 0
        
        return f"""
        総リクエスト数: {self.total_requests}
        成功率: {success_rate:.2f}%
        Ban rate: {ban_rate:.2f}%
        キャプチャ率: {captcha_rate:.2f}%
        平均応答時間: {avg_response_time:.2f}秒
        """

# 使用
metrics = ScraperMetrics()

for url in urls:
    start_time = time.time()
    try:
        response = requests.get(url, headers=headers, proxies=proxies, timeout=10)
        response_time = time.time() - start_time
        
        if response.status_code == 200:
            metrics.record_request(success=True, response_time=response_time)
        elif response.status_code == 403 or response.status_code == 429:
            metrics.record_request(success=False, blocked=True, response_time=response_time)
        elif 'captcha' in response.text.lower():
            metrics.record_request(success=False, captcha=True, response_time=response_time)
    except Exception as e:
        metrics.record_request(success=False)

print(metrics.get_stats())

パースツールの比較

適切なツールの選択はban rateに大きく影響します。主要ソリューションの比較:

まとめ

Ban rateの削減は、複数の保護レベルを組み合わせた包括的なアプローチです。主な推奨事項:

1. 適切なプロキシを使用:マーケットプレイスにはレジデンシャル、シンプルなサイトにはデータセンター
2. IPを定期的にローテーション:5-10分ごとまたは50-150リクエストごと
3. 実際のブラウザを模倣:正しいUser-Agent、完全なヘッダーセット、適切な順序
4. ランダムな遅延を追加:リクエスト間2-10秒、サイトの保護レベルに応じて
5. Fingerprintを保護:undetected-chromedriver、Playwright、またはアンチ検出ブラウザを使用
6. Cookieを管理:保存、再利用、パース前のセッションウォームアップ
7. メトリクスを監視:ban rate、成功率、応答時間を追跡
8. レート制限を尊重:サイトの制限を超えず、429エラーに対応

これらの推奨事項に従うことで、ban rateを5-10%まで削減し、安定したデータ収集を確保できます。各サイトには独自の保護の特徴があることを忘れないでください — 最適な設定を見つけるために実験してください。