Amazonのアンチボットを回避する方法：プロキシとスクレイピングの手法

```html

Amazonは世界で最も保護されたマーケットプレイスの1つです。そのアンチボットシステムは、価格、在庫、商品ポジションに関する自動データ収集の90％をブロックします。セラーやマーケティング担当者にとって、これは重大な問題です。競合他社の最新データがなければ、価格戦略を適切に調整し、利益を上げ続けることはできません。

このガイドでは、Amazonの保護の技術的メカニズムを解説し、アンチボットを回避するための実績のある手法を示し、ブロックなしで数ヶ月間安定して動作する価格監視システムを設定します。

なぜAmazonはパーシングをブロックするのか：保護メカニズム

Amazonはパーシングによって数百万ドルを失っています。競合他社は商品データ、価格、レビューをコピーし、不正な販売者は自動化を利用してポジションを操作します。したがって、同社は複数のレベルで同時に機能するアンチボットシステムに多額の資金を投資しています。

Amazonの保護の主要コンポーネント：

AWS WAF (Web Application Firewall) — 入ってくるトラフィックを分析し、ネットワークレベルで疑わしいIPアドレスをブロックします。リクエストの頻度、地理、IPの評判を追跡します。
Cloudfront CDN — ボットフィルタリングの独自のアルゴリズムを持つ分散型コンテンツ配信ネットワークです。リクエストのヘッダー、クッキー、TLSフィンガープリンティングを確認します。
Bot Managementシステム — ユーザーの行動を分析するために機械学習を使用します。マウスの動き、スクロール速度、クリックパターンを追跡します。
CAPTCHAとチャレンジページ — 疑わしい活動がある場合に表示されます。続行するためにパズルを解いたり、CAPTCHAを入力する必要があります。
Rate limiting — 1つのIPからのリクエスト数に厳しい制限があります：通常、ログインしていないユーザーには1分あたり10-20リクエストが許可されます。

これらのシステムはすべて連携して動作し、データを交換します。いずれかのシステムがボットを疑うと、IPは24-48時間のブラックリストに載せられ、時には永久にブロックされます。

重要： Amazonは地域やユーザータイプによって異なる価格を表示します。ブロックは単にアクセスを失うだけでなく、最新のデータを取得できないことも意味します。これは競合の監視にとって致命的です。

Amazonはどのようにボットを特定するのか：7つの主要な信号

Amazonのアンチボットシステムは、各リクエストの数十のパラメータを分析します。以下は、自動化を認識するための主要な信号です：

1. IPアドレスの評判

Amazonはデータセンター、VPNサービス、パブリックプロキシのIPアドレスのデータベースを維持しています。このようなアドレスからのリクエストは、特別な注意を受けるか、すぐにブロックされます。システムはまた、活動の履歴を追跡します：IPから商品ページへのリクエストが多すぎると、疑わしいと見なされます。

チェックされる内容： 有名なデータセンター（AWS、Google Cloud、DigitalOcean）への所属、パブリックプロキシのデータベースへの存在、過去1時間のリクエスト数、地理（予期しない国からのリクエスト）。

2. User-AgentとHTTPヘッダー

多くのパーサーは標準的なUser-Agentライブラリを使用します：python-requests/2.28.0や、まったくこのヘッダーを送信しないものもあります。Amazonはこのようなリクエストを瞬時に認識します。

疑わしい兆候： Accept-Language、Accept-Encodingヘッダーの欠如；User-Agentと他のヘッダーの不一致（例えば、ChromeのUser-Agentだが、Firefoxのヘッダー）；ページ間の遷移時にRefererが欠如；古いバージョンのブラウザ。

3. TLS/SSLフィンガープリンティング

HTTPS接続を確立する際、ブラウザは暗号化パラメータのセット（暗号スイート、拡張機能、TLSバージョン）を送信します。このセットは各ブラウザに固有です。requestsやcurlのようなライブラリは、実際のブラウザとは異なるフィンガープリンティングを持っています — Amazonはこれを認識します。

4. JavaScriptとCanvasフィンガープリンティング

AmazonはJavaScriptコードを読み込み、ブラウザに関する情報を収集します：画面解像度、インストールされたフォント、サポートされているWebGL機能、Canvasパラメータ。簡単なHTTPクライアントはJavaScriptを実行せず、すぐに自らを暴露します。

5. クッキーとセッション

Amazonは初回訪問時に多くのクッキーを設定します：session-id、ubid-main、x-mainなど。これらのクッキーが欠如しているか、無効な値であることはボットの兆候です。また、システムはセッションの寿命を追跡します：実際のユーザーは30秒で100リクエストを行うことはありません。

6. 行動パターン

実際の人間はホームページを開き、商品を探し、カテゴリを移動し、説明を読み、戻ります。ボットはすぐに特定の商品のURLを完璧な順序で遅延なしにリクエストします。

疑わしいパターン： ホームページを訪れずに商品ページのみへのリクエスト；完璧なURLの順序（product1、product2、product3...）；静的ファイルへのリクエストがない（画像、CSS、JS）；リクエスト間の同じ間隔。

7. リクエストの頻度

完璧なブラウザのエミュレーションを行っても、リクエストの頻度が高すぎるとボットが露見します。AmazonはIPからのリクエスト数を1分、1時間、1日単位で追跡します。制限を超えると（通常、ゲストの場合は1分あたり10-20リクエスト）、ブロックされます。

アンチボット回避のためのプロキシの選択：レジデンシャル vs データセンター

プロキシのタイプを正しく選択することは、Amazonの保護を回避するための成功の70％を占めます。3つの主要なタイプとマーケットプレイスのパーシングにおける適用性を解説します。

プロキシのタイプ	Amazonの信頼レベル	速度	用途
レジデンシャル	非常に高い（実際の家庭ユーザーのIP）	中程度（50-150ミリ秒）	主なパーシング、高ボリューム
モバイル	最大（モバイルキャリアのIP）	低い（200-500ミリ秒）	厳しいブロックの回避、アカウント
データセンター	低い（AmazonはこれらのIPを知っている）	非常に高い（10-30ミリ秒）	テスト、一時的なタスク

レジデンシャルプロキシ — 最適な選択

Amazonの安定したパーシングには、レジデンシャルプロキシが推奨されます。これらは、Amazonが大量にブロックすることができない実際の家庭ユーザーのIPアドレスを使用しています。

Amazonのためのレジデンシャルプロキシの利点：

IPはインターネットサービスプロバイダー（アメリカのComcast、AT&T、Verizon）に属し、データセンターには属さない
ブロック率が低い：適切なローテーション設定で2％未満
地理の選択が可能：アメリカ、イギリス、ドイツなど、ローカル価格を取得するための国
スティッキーセッションのサポート：1つのIPを10-30分間使用して実際のユーザーを模倣できる

レジデンシャルプロキシを選択する際の重要なパラメータ：

IPプールのサイズ： 効率的なローテーションのために最低1百万のアドレス
地理： Amazonが機能する国を選択（アメリカ、イギリス、ドイツ、日本など）
ローテーションのタイプ： 10-30分の寿命を持つスティッキーセッションのサポート
プロトコル： HTTP/HTTPSおよびSOCKS5、さまざまなツールとの互換性

モバイルプロキシを使用するタイミング

モバイルプロキシは、モバイルキャリアのIP（4G/5G）を使用します。Amazonはこのようなアドレスをほとんどブロックしません。なぜなら、CGNAT技術により1つのIPの背後に数千の実際のユーザーがいる可能性があるからです。

モバイルプロキシを選択するタイミング：

Amazonセラーアカウント（Seller Central）との作業 — IPの安定性が重要
レジデンシャルIPの禁止後の厳しいブロックの回避
認証付きのパーシング（例えば、Prime会員向けの価格）
データ量が少ない（1日あたり1000商品まで） — モバイルプロキシは高価

モバイルプロキシの欠点は、高コストとモバイルネットワークの特性による低速です。数千の商品を大量にパーシングするには効果的ではありません。

データセンターが適さない理由

データセンターのプロキシは、AWS、Google Cloud、DigitalOceanのサーバーのIPを使用します。Amazonはこれらのアドレスを瞬時に認識します — それらはデータセンターのASN（自律システム）データベースに存在します。

データセンター使用時の問題： 5-10リクエスト後のブロック；常にCAPTCHA；古い価格や空のページの表示；数回の試行後のIPの永久禁止。

データセンターを使用できる唯一のケースは、レジデンシャルプロキシでの実行前に少数の商品（10-20個）でパーサーをテストすることです。

IPアドレスのローテーション戦略：頻度と地理

レジデンシャルプロキシを使用しても、IPのローテーションが不適切であればブロックされます。Amazonは各アドレスの行動を追跡し、リクエストが多すぎるか、疑わしい行動をするものを禁止します。

最適なローテーション頻度

ローテーションには2つのアプローチがあります：各リクエスト後（ローテーティングプロキシ）と固定の寿命を持つもの（スティッキーセッション）。Amazonには後者の方が効果的です。

推奨されるスティッキーセッション戦略：

IPの寿命： 10-15分 — 実際のユーザーを模倣するための最適なバランスとブロックのリスク
IPあたりのリクエスト数： セッションの寿命中に15-20リクエストを超えない
リクエスト間の遅延： 3-7秒（ランダムで固定しない！）
行動の模倣： 最初のリクエストはホームページまたはカテゴリ、次に商品ページ

1つのIPのシナリオの例：Amazon.comを開く → 5秒待つ → Electronicsカテゴリを開く → 4秒待つ → 商品1を開く → 6秒待つ → 商品2を開く → ... → 15リクエスト後にIPを変更。

高負荷のためのアドバイス：

もし1時間に数千の商品をパーシングする必要があるなら、異なるIPを持つ50-100の同時セッションのプールを使用してください。各セッションは10-15リクエストを遅延を持って行い、その後IPを変更します。これにより、ブロックなしで1時間に500-1500リクエストを実現できます。

地理的分布

Amazonは、ユーザーの位置に応じて異なる価格、品揃え、配達条件を表示します。正確な監視を行うには、ターゲットマーケットプレイスと同じ国のプロキシを使用する必要があります。

マーケットプレイスとプロキシの地理的対応：

Amazon.com（アメリカ）： アメリカのプロキシを使用し、できれば異なる州からのものを選択
Amazon.co.uk（イギリス）： イギリスのプロキシ
Amazon.de（ドイツ）： ドイツのプロキシ
Amazon.co.jp（日本）： 日本のプロキシ

重要：特定のマーケットプレイスをパーシングするために他の国のプロキシを使用しないでください。例えば、インドやロシアのIPからのAmazon.comへのリクエストは疑わしく見え、しばしばCAPTCHAを受けます。

IPの再利用を避ける

IPがブロックされていなくても、2-3時間の間は再利用しないでください。Amazonは各アドレスの活動履歴を記憶します。同じIPが1日に15分ごとに出現する場合、これは自動化の明らかな兆候です。

ローテーションのルール： 安定した運用のためには、500-1000のユニークIPのプールが必要です。これにより、各アドレスが1日に1-2回以上使用されないように十分な多様性が確保されます。

実際のブラウザのエミュレーション：ヘッダーとフィンガープリンティング

レジデンシャルプロキシと適切なローテーションを行っても、パーサーが本物のブラウザをエミュレートしなければブロックされます。AmazonはHTTPリクエストとJavaScript環境の数十のパラメータを確認します。

正しいHTTPヘッダー

簡単なHTTPクライアント（requests、curl、wget）は、ボットを瞬時に露呈させる最小限のヘッダーセットを送信します。実際のブラウザのヘッダーをコピーする必要があります。

Amazonに必要なヘッダー：

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.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
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

重要なポイント：

User-Agent： 最新のChromeまたはFirefoxのバージョンを使用してください（2-3ヶ月ごとに確認）。古いバージョンのブラウザは疑わしいです。
Accept-Language： プロキシの地理に一致する必要があります（アメリカの場合はen-US、イギリスの場合はen-GB、ドイツの場合はde-DE）
Sec-Fetch-* ヘッダー： 現代のブラウザで登場したもので、これらが欠如していると古いクライアントの兆候です
Referer： ページ間の遷移時には、前のページのRefererを必ず送信してください

TLSフィンガープリンティングと回避

AmazonはTLS接続のパラメータを分析します：プロトコルのバージョン、暗号スイート、拡張機能。標準ライブラリ（Python requestsのOpenSSLなど）は、ブラウザとは異なるフィンガープリンティングを持っています。

解決策： ブラウザのTLSをエミュレートするツールを使用してください：

curl-impersonate： ChromeとFirefoxのTLSフィンガープリンティングをコピーするcurlのバージョン
tls-client（Python）： ブラウザフィンガープリンティングをサポートするライブラリ
Playwright/Puppeteer： ヘッドレスモードの実際のブラウザ — 完璧なエミュレーションですが、遅くなります

JavaScriptとクッキー

Amazonはページの読み込み時にJavaScriptコードを実行し、クッキーを設定し、ブラウザに関する情報を収集します。このコードを実行しないと、完全なデータを取得できず、すぐにブロックされます。

必須のアクション：

JavaScriptをサポートするツールを使用：Selenium、Playwright、Puppeteer
セッション内のリクエスト間で全てのクッキーを保存する
データを抽出する前にページが完全に読み込まれるのを待つ（DOMContentLoadedイベント）
ユーザーの行動を模倣する：スクロール、ランダムな休止

Amazonは重要なクッキーを設定します：session-id、ubid-main、x-main。これらがないと、CAPTCHAや空のページが表示されます。

リクエストの制限とその間の遅延

完璧なブラウザのエミュレーションでも、リクエストが多すぎると禁止されます。Amazonは1つのIPからのアクセス頻度を厳しく制限しています。

Amazonの文書化された制限

公式の制限データはありませんが、コミュニティのテストに基づいておおよその値が知られています：

ユーザータイプ	リクエスト制限/分	リクエスト制限/時間
ログインしていないユーザー	10-15	200-300
ログインした購入者	20-30	500-800
Amazon API（公式）	制限なし	プランによる

制限を超えると、CAPTCHA、時間制限（1-24時間）、またはシステマティックな違反によるIPの永久禁止が発生します。

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

固定の間隔（例えば、ちょうど5秒）はボットを露呈させます。実際の人間は異なる長さの休止を取ります：商品説明を読み、価格を比較し、気を散らします。

推奨される遅延戦略：

基本遅延： 3-7秒（範囲からのランダム値）
セッション内の最初のリクエスト： 5-10秒（ホームページの読み込みを模倣）
エラーやCAPTCHAの後： 再試行前に30-60秒待つ
IP変更間： "再接続"のために2-3秒待つ

ランダムな遅延の実装例：sleep(random.uniform(3, 7)) — 各休止がユニークになります。

時間による負荷分散

00:00に数千の商品を同時にパーシングしないでください。Amazonは活動の急増を追跡します。タスクを数時間または1日中に分散させてください。

例： 5000商品をパーシングする必要があります。500商品の10パッケージに分け、各パッケージを1-2時間の間隔で実行します。これは、異なるユーザーの有機的な活動のように見えます。

Amazonパーシングのための既製ツール

ゼロからパーサーを書くのは難しく、時間がかかります。アンチボットの回避、プロキシのローテーション、ブラウザのエミュレーションを実現する既製のソリューションがあります。

1. Bright Data Web Scraper IDE

Amazon用のテンプレートが用意されたクラウドツールです。プログラミングは不要で、視覚的インターフェースを通じてデータセレクターを設定します。組み込みのプロキシとCAPTCHA回避機能があります。

利点： すぐに使用可能、自動IPローテーション、JavaScriptサポート。 欠点： 高価（$500以上/月）、外部サービスへの依存。

2. Octoparse

視覚的なパーサー構築ツールを備えたWindows用のデスクトップアプリケーションです。24/7でタスクを実行するためのクラウド版もあります。プロキシとの統合をサポートしています。

Octoparseでのプロキシ設定： 設定 → プロキシ設定 → IP:PORT:USER:PASS形式のプロキシリストを追加 → ローテーションを有効にします。

利点： コード不要、使いやすいインターフェース、無料プランあり。 欠点： 無料版でのページ数制限、CAPTCHAとの問題。

3. ScrapingBee API

自動的に保護を回避するためのパーシング用APIサービスです。URLを送信すると、HTMLを取得します。組み込みのプロキシローテーションとJavaScriptの実行があります。

使用例：

curl "https://app.scrapingbee.com/api/v1/?api_key=YOUR_KEY&url=https://www.amazon.com/dp/B08N5WRWNW&render_js=true&premium_proxy=true&country_code=us"

利点： 簡単な統合、独自のプロキシは不要。 欠点： 有料（$49/月から）、リクエスト数の制限。

4. Playwright + 自前のプロキシ（開発者向け）

プログラミングができるなら、最良の選択肢はレジデンシャルプロキシを使用したPlaywright（またはPuppeteer）です。プロセスを完全に制御でき、コストも最小限に抑えられます。

Playwrightでのプロキシ設定の例（Python）：

from playwright.sync_api import sync_playwright
import random
import time

proxy_list = [
    {"server": "http://proxy1.example.com:8080", "username": "user", "password": "pass"},
    {"server": "http://proxy2.example.com:8080", "username": "user", "password": "pass"},
]

with sync_playwright() as p:
    proxy = random.choice(proxy_list)
    browser = p.chromium.launch(proxy=proxy, headless=True)
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
        locale="en-US",
        timezone_id="America/New_York"
    )
    page = context.new_page()
    
    # 最初のリクエスト - ホームページ
    page.goto("https://www.amazon.com")
    time.sleep(random.uniform(3, 5))
    
    # 商品リクエスト
    page.goto("https://www.amazon.com/dp/B08N5WRWNW")
    page.wait_for_load_state("networkidle")
    
    # データ抽出
    title = page.locator("#productTitle").inner_text()
    price = page.locator(".a-price-whole").first.inner_text()
    
    print(f"タイトル: {title}, 価格: ${price}")
    
    browser.close()

利点： 完全な制御、クラウドサービスより安価、スケーラブル。 欠点： プログラミングスキルが必要、CAPTCHAの処理が必要。

ツール選択の推奨

あなたの状況	推奨ツール
プログラミングができない、1日あたり100-500商品が必要	Octoparse + レジデンシャルプロキシ
アイデアを迅速にテストしたい、予算がある	ScrapingBee API
プログラミングができる、数千の商品が必要	Playwright/Puppeteer + レジデンシャルプロキシ
大きな予算、最大の信頼性が必要	Bright Data Web Scraper

ブロックされた場合の対処法：診断と解決策

すべてのルールを守っていても、時々ブロックが発生します。原因を理解し、迅速に問題を修正することが重要です。

ブロックの種類とその兆候

1. CAPTCHA（ステータスコード503または/errors/validateCaptchaへのリダイレクト）：

原因： IPからの疑わしい活動、しかし完全なブロックではない
解決策： IPを変更し、リクエスト間の遅延を増やし、ユーザー行動の模倣を追加する
自動化： CAPTCHA解決サービス（2Captcha、Anti-Captcha）を使用する — しかし、これによりパーシングが遅くなります

2. IPのブロック（コード403または空のページ）：

原因： IPが制限を超えたか、データセンターを使用したためにブラックリストに載った
解決策： すぐにIPを変更し、プロキシのタイプを確認する（データセンターではなくレジデンシャルを使用している可能性があります）
持続時間： 通常24-48時間、時には永久に

3. "Amazonデータへの自動アクセスについては、api-services-support@amazon.comにお問い合わせください"：

原因： Amazonが自動化を明確に特定し、公式APIの使用を提案している
解決策： ブラウザのエミュレーションを改善し、TLSフィンガープリンティングを確認し、リクエストの頻度を2倍に減らす

問題診断のチェックリスト

ブロックされている場合、順番に確認してください：

プロキシのタイプ： レジデンシャルを使用していることを確認し、データセンターではないことを確認します。whoer.netで確認できます。
地理： IPはマーケットプレイスと同じ国からのものである必要があります（.comの場合はアメリカ、.co.ukの場合はイギリス）
User-Agent： 最新のChrome/Firefoxのバージョン（3-4ヶ月以内）
クッキー： セッション内のリクエスト間で保存されているか
JavaScript： 実行されているか（Playwright/Puppeteerを使用している場合は実行される必要があります）
リクエストの頻度： 1つのIPからのリクエストは10-15を超えない
遅延： ランダムで固定しない
IPのローテーション： 各アドレスは2-3時間に1回以上使用されない

大規模なブロック時の緊急対策

もし多数のリクエストがブロックされている場合（30％以上）：

パーシングを2-3時間停止する — Amazonにあなたの活動を「忘れさせる
プロキシプロバイダーを変更する — おそらくIPプールがすでに危険にさらされています
負荷を3-5倍減らす — 1時間あたり100リクエストの代わりに20-30リクエストを行う
モバイルプロキシに切り替える — ほとんどブロックされず、ただし高価です
人間の模倣を追加する： カテゴリ間のランダムな移動、直接URLではなく検索バーを通じて商品を探す

注意： あなたのIPが永久に禁止されている場合（ブロックが72時間以上続いている場合）、再度使用しようとしないでください。Amazonは永久禁止を解除することは稀です。新しいプロキシプールに切り替えてください。

結論

Amazonのアンチボットを回避することは、適切なプロキシ、正確なブラウザのエミュレーション、合理的なリクエスト制限の組み合わせを必要とする複雑なタスクです。成功するための重要なポイント：ターゲットマーケットプレイスと同じ国のレジデンシャルプロキシを使用すること；10-15分ごとにIPをローテーションし、セッションあたり15-20リクエストの制限を設けること；正しいヘッダーとJavaScriptの実行を伴う現代のブラウザの完全なエミュレーション；リクエスト間の3-7秒のランダムな遅延。

これらのルールを守ることで、成功したリクエストの割合は95-98％に達し、ブロックは稀になります。重要なのは急がず、実際のユーザーの行動を模倣することです。数分で数千の商品をパーシングしようとしないでください。

Amazonとの安定した作業には、レジデンシャルプロキシの使用をお勧めします。

```

アマゾンのアンチボットを回避して競合の実際の価格を取得する方法：完全ガイド