先週末、AmazonのBest Sellersページを4つの方法でスクレイピングしようとして、コーヒーを丸一杯分消費してしまいました。うまくいったのは2つ、IP停止寸前までいったのが1つ、そしてたった2クリックで完了したものが1つ。そこで学んだことをすべてまとめます。
Amazonは巨大なマーケットプレイスです。、、そして1時間ごとに更新されるBest Sellers Rank(BSR)があります。FBA向けの商品リサーチ、競合価格の分析、あるいはライバルより先にトレンドを掴みたい場合、Best Sellerのデータはまさに宝の山です。
でも、そのデータをAmazonから取り出してスプレッドシートに落とし込むのは簡単ではありません。そこで今回は、requests + BeautifulSoup、Selenium、スクレイピングAPI、そして私たちのノーコードAIウェブスクレイパーであるを比較し、どの方法が本当に使えるのか、どれがCAPTCHA画面を前に途方に暮れることになるのかを検証しました。
Amazonのベストセラーとは?なぜ気にするべきなのか?
Amazon Best Sellers Rank(BSR)は、各カテゴリー内での売上数量をもとにしたAmazonのリアルタイムランキングです。最近の売上と過去の売上の両方を反映し、1時間ごとに更新される人気投票のようなものだと考えると分かりやすいでしょう。Amazon自身は次のように説明しています。
「Amazon Best Sellersの算出はAmazonの売上に基づいており、Amazonで販売された各商品の最近および過去の売上を反映するために1時間ごとに更新されます。」 —
Best Sellersページでは、各カテゴリーの上位100商品が表示され、50件ずつ2ページに分かれています。1ページ目が#1〜#50、2ページ目が#51〜#100です。Amazonは、ページ閲覧数やカスタマーレビューはBSRに影響しないと明言しており、純粋に売上ベースで決まります。
このデータを必要とするのは誰でしょうか?FBA向けに商品を探すEコマース販売者、競合分析を行う営業チーム、価格動向を追うオペレーション担当、市場成長を調べるリサーチャーなどです。私の経験では、Amazonで販売している人、あるいはAmazonと競合している人は、最終的にこのデータをスプレッドシートで管理したくなります。
なぜPythonでAmazon Best Sellersをスクレイピングするのか?
手作業の商品調査は時間の浪費です。によると、従業員は週に平均9.3時間を情報の検索と収集に費やしています。Eコマースチームにとっては、Amazonの商品ページをクリックし、商品名と価格をコピーしてスプレッドシートに貼り付け、翌週にまた同じ作業を繰り返す、ということです。
Best Sellersのスクレイピングが価値を持つユースケースをざっと見てみましょう。
| ユースケース | 得られるもの | 恩恵を受ける人 |
|---|---|---|
| FBA商品リサーチ | BSRとレビュー数から需要が高く競争が少ない商品を見つける | Amazon販売者、ドロップシッパー |
| 競合価格の追跡 | 自分のカテゴリ上位商品の価格変動を把握する | Eコマースチーム、価格アナリスト |
| 市場トレンド監視 | 伸びているカテゴリーや季節変動を見つける | プロダクトマネージャー、市場調査担当 |
| リード獲得 | 上位ブランドとその商品ラインの一覧を作る | 営業チーム、B2Bアウトリーチ担当 |
| 競合分析 | 自社製品をカテゴリ上位商品と比較する | ブランドマネージャー、戦略チーム |
ROIは本物です。では、2,700人のコマース専門家のうち、AIツールによってEコマース担当者は平均を節約できることが分かっています。また、自動価格追跡を使っている販売者は、Buy Boxをで獲得しており、手動トラッカーの42%を大きく上回ります。価格変動に素早く対応できることで、売上が37%伸びたということです。
PythonでAmazon Best Sellersをスクレイピングする4つの方法を比較
手順に入る前に、最初にこれが欲しかった、と思える比較表を置いておきます。自分の状況に合う方法を選ぶ参考にしてください。
| 基準 | requests + BS4 | Selenium | スクレイピングAPI(例: Scrape.do) | Thunderbit(ノーコード) |
|---|---|---|---|---|
| 初期設定の難易度 | 中 | 高(ドライバー、ブラウザ) | 低(APIキー) | 非常に低い(Chrome拡張) |
| 遅延読み込みへの対応 | いいえ | はい(スクロール再現) | はい(レンダリング済みHTML) | はい(AIがレンダリング対応) |
| 反ボット耐性 | 低い(IP停止のリスク) | 中(検出されやすい) | 高い(プロキシ自動切替) | 高い(クラウド+ブラウザモード) |
| 保守負荷 | 高い(セレクタが壊れやすい) | 高い(ドライバー更新+セレクタ調整) | 低い | 非常に低い(AIがレイアウト変更に適応) |
| コスト | 無料 | 無料 | 有料(リクエストごと) | 無料枠+有料プラン |
| 向いている用途 | 単発スクレイプ、学習用 | JSが多いページ、ログイン必須ページ | 本番運用、スケール処理 | 非エンジニア、素早い調査、定期監視 |
Pythonスクレイピングの基礎を学びたいなら、方法1か2から始めるのがよいでしょう。本番環境レベルの信頼性が必要なら、方法3が向いています。コードを書かずに2クリックで結果を得たいなら、方法4に直接進んでください。
始める前に
- 難易度: 初級〜中級(方法による)
- 所要時間: Thunderbitなら約15分、Pythonの方法なら約45分
- 必要なもの: Python 3.8以上(方法1〜3)、Chromeブラウザ、(方法4)、対象のAmazon Best SellersカテゴリURL
方法1: requests + BeautifulSoupでAmazon Best Sellersをスクレイピングする
これは軽量で初心者向けの方法です。ブラウザ自動化は使わず、HTTPリクエストとHTML解析だけで処理します。Amazonのスクレイピング対策について最も学べた方法でもありました。
ステップ1: 環境を準備する
必要なパッケージをインストールします。
1pip install requests beautifulsoup4 pandas
続いて、インポートを用意します。
1import requests
2from bs4 import BeautifulSoup
3import pandas as pd
4import random
5import time
ステップ2: 実在のブラウザらしいヘッダーでリクエストする
Amazonは、ボットっぽいリクエストを弾きます。最も基本的な対策は、実際のブラウザを装うUser-Agentヘッダーを付けることです。以下は、現在使えるリアルなUser-Agent文字列の例です(より、2026年3月時点)。
1USER_AGENTS = [
2 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
3 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
4 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0",
5 "Mozilla/5.0 (Macintosh; Intel Mac OS X 15.7; rv:149.0) Gecko/20100101 Firefox/149.0",
6 "Mozilla/5.0 (Macintosh; Intel Mac OS X 15_7_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Safari/605.1.15",
7]
8headers = {"User-Agent": random.choice(USER_AGENTS)}
9url = "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/"
10response = requests.get(url, headers=headers)
11print(response.status_code) # 200なら成功
ステータスコードが200なら成功です。503が返る、あるいはCAPTCHAページへ飛ばされる場合は、Amazonがリクエストをブロックしています。
ステップ3: BeautifulSoupで商品データを解析する
ブラウザのDevTools(右クリック → 検証)でAmazonページのHTMLを確認しましょう。商品コンテナにはgridItemRootというIDが使われています。その中に商品名、価格、評価、URLが含まれています。
1soup = BeautifulSoup(response.text, "html.parser")
2products = []
3for item in soup.find_all("div", id="gridItemRoot"):
4 title_tag = item.find("div", class_="_cDEzb_p13n-sc-css-line-clamp-3_g3dy1")
5 price_tag = item.find("span", class_="_cDEzb_p13n-sc-price_3mJ9Z")
6 link_tag = item.find("a", class_="a-link-normal")
7 title = title_tag.get_text(strip=True) if title_tag else "N/A"
8 price = price_tag.get_text(strip=True) if price_tag else "N/A"
9 url = "https://www.amazon.com" + link_tag["href"] if link_tag else "N/A"
10 products.append({"Title": title, "Price": price, "URL": url})
注意:
_cDEzb_で始まるクラス名は、Amazonが定期的に再生成するCSSモジュールのハッシュです。gridItemRootのIDとa-link-normalのクラスのほうが比較的安定していますが、スクレイパーを動かす前には必ずDevToolsでセレクタを確認してください。
ステップ4: CSVに出力する
1df = pd.DataFrame(products)
2df.to_csv("amazon_best_sellers.csv", index=False)
3print(f"{len(products)}件の商品を取得しました")
何が起こるのか、そして何がうまくいかないのか
私のテストでは、この方法で取得できたのは50件ではなく約30件でした。コードのバグではありません。Amazonの遅延読み込みが原因です。初回表示時に描画されるのは約30件で、残りはスクロール後にJavaScriptで表示されます。requestsではこれを処理できません。
ほかにも制限があります。
- プロキシを回さないとIP停止がすぐ起こる(私は短時間に15回ほど送ったところでブロックされました)
- Amazonがページ構成を更新するとCSSセレクタが壊れる。しかも更新頻度は高いです
- ページネーションの処理が最初からは入っていない
Pythonスクレイピングの学習にはとても良い方法ですが、本番利用には脆いです。
方法2: SeleniumでAmazon Best Sellersをスクレイピングする
Seleniumは、実際のブラウザを使って遅延読み込み問題を解決します。セットアップは重めですが、1ページあたり50件すべてを取得できます。
ステップ1: Seleniumをインストールする
1pip install selenium pandas
朗報です。Selenium 4.6以降では、webdriver-managerは不要です。Selenium Managerがドライバーのダウンロードを自動で処理してくれます。
1from selenium import webdriver
2from selenium.webdriver.chrome.options import Options
3from selenium.webdriver.common.by import By
4from selenium.webdriver.common.keys import Keys
5import time
6import pandas as pd
7options = Options()
8options.add_argument("--headless=new")
9options.add_argument("--window-size=1920,1080")
10options.add_argument("--disable-blink-features=AutomationControlled")
11driver = webdriver.Chrome(options=options)
--headless=newフラグ(Chrome 109以降で導入)は、通常表示のChromeと同じレンダリング経路を使うため、Amazonに検出されにくくなります。
ステップ2: 遅延読み込みをスクロールで読み切る
Seleniumの価値が出るのがこの部分です。Amazon Best Sellersは最初に約30件しか読み込まれず、残りはスクロール後に表示されます。
1def scroll_page(driver, scrolls=5, delay=2):
2 for _ in range(scrolls):
3 driver.find_element(By.TAG_NAME, "body").send_keys(Keys.PAGE_DOWN)
4 time.sleep(delay)
5driver.get("https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/")
6time.sleep(3)
7scroll_page(driver)
スクロール後は、50件すべてがDOMに描画されるはずです。私の環境では、2秒間隔で5回Page Downするだけで十分でしたが、通信速度によって調整が必要になる場合があります。
ステップ3: 商品データを抽出する
1items = driver.find_elements(By.ID, "gridItemRoot")
2products = []
3for item in items:
4 try:
5 title = item.find_element(By.CSS_SELECTOR, "div._cDEzb_p13n-sc-css-line-clamp-3_g3dy1").text
6 except:
7 title = "N/A"
8 try:
9 price = item.find_element(By.CSS_SELECTOR, "span._cDEzb_p13n-sc-price_3mJ9Z").text
10 except:
11 price = "N/A"
12 try:
13 url = item.find_element(By.CSS_SELECTOR, "a.a-link-normal").get_attribute("href")
14 except:
15 url = "N/A"
16 products.append({"Title": title, "Price": price, "URL": url})
各抽出処理をtry/exceptで囲むのは重要です。商品によっては在庫切れだったり、項目が欠けていたりするので、1件の失敗で全体が止まらないようにします。
ステップ4: ページネーションを処理する
AmazonはBest Sellersの上位100件を2ページに分けて表示し、URL構造も異なります。
1urls = [
2 "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/",
3 "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/ref=zg_bs_pg_2_electronics?_encoding=UTF8&pg=2"
4]
5all_products = []
6for url in urls:
7 driver.get(url)
8 time.sleep(3)
9 scroll_page(driver)
10 # ... 上記と同じように商品を抽出 ...
11 all_products.extend(products)
12driver.quit()
何が期待できるか
私のテストでは、Seleniumは各ページの50件すべてを取得できました。requests + BS4と比べると明らかな勝ちです。ただし、スクロール待ちを含めると1ページあたり約45秒かかり、プロキシなしで何度も実行するとやはりブロックされました。Seleniumはアンチ検出フラグを付けてもAmazonのボット検知に見つかることがあり、本格的に大量処理するには追加対策が必要です(後述のAnti-Ban Playbookを参照)。
ほかの悩みどころ:
- Selenium Managerでかなり減ったとはいえ、WebDriverのバージョン不一致はまだ時々起きる
- AmazonがDOMを変えるたびにCSSセレクタの更新が必要
- メモリ使用量が大きい。ブラウザインスタンス1つで200〜400MBのRAMを消費する
方法3: スクレイピングAPIでAmazon Best Sellersをスクレイピングする
スクレイピングAPIは、「面倒な部分は全部お任せ」という考え方です。Scrape.do、Oxylabs、ScrapingBeeなどのサービスが、プロキシの切り替え、JavaScriptレンダリング、反ボット対策を引き受けてくれます。こちらはURLを送るだけで、HTMLかJSONが返ってきます。
仕組み
対象URLをAPIエンドポイントに送信します。API側が自社インフラ上の実ブラウザでページをレンダリングし、プロキシを切り替え、CAPTCHAを処理し、きれいなHTMLを返します。あとは返ってきたHTMLをいつも通りBeautifulSoupで解析するだけです。
ステップ1: API経由でリクエストを送る
ここではScrape.doの例を示します(料金は150,000クレジットで月29ドル〜、1クレジット=レンダリング有無に関わらず1リクエスト)。
1import requests
2from bs4 import BeautifulSoup
3api_token = "YOUR_API_TOKEN"
4target_url = "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/"
5api_url = f"https://api.scrape.do?token={api_token}&url={target_url}&render=true&geoCode=us"
6response = requests.get(api_url)
7soup = BeautifulSoup(response.text, "html.parser")
ここから先の解析は方法1と同じです。セレクタも抽出ロジックも同じで問題ありません。
料金の現実
主要APIのAmazon向け料金を、最安レートで1,000リクエストあたりに換算すると次の通りです。
| プロバイダー | 1,000リクエストあたりのコスト | 備考 |
|---|---|---|
| Scrape.do | 約$0.19 | 一律料金、クレジット倍率なし |
| Oxylabs | 約$1.80 | JavaScriptレンダリングは5倍換算 |
| ScrapingBee | 約$4.90 | プレミアム機能は5〜25倍換算 |
| Bright Data | $5.00超 | 最も豊富なデータ(1商品あたり686項目)だが最も遅い(約66秒/リクエスト) |
メリットとデメリット
メリット: 高い信頼性(主要プロバイダーではAmazonで)、ドライバー管理不要、反ボット対策を自動処理、スケールしやすい。
デメリット: リクエストごとに課金されるため、規模が大きいとコストが増える。解析コードは自分で書く必要がある。CSSセレクタ変更にも依然として弱い。月10万ページを処理する場合、総コストの差は大きく、内製開発は3年間で約かかるのに対し、プロバイダー利用は約$293,000で済むとされています。71%の節約です。
損益分岐点は、一般的には月50万〜100万リクエスト前後です。それ以下なら、APIによる時間短縮効果のほうがコストを大きく上回ります。
方法4: ThunderbitでAmazon Best Sellersをスクレイピングする(Python不要)
率直に言うと、私はThunderbitで働いています。その前提はありますが、4つの方法を実際に続けて試したうえで、データ取得までの速さの差は本当に大きいと感じました。
は、Chrome拡張機能として動作するAIウェブスクレイパーです。基本の考え方はシンプルで、CSSセレクタやPythonコードを書く代わりに、AIがページを読み取り、何を抽出すべきかを判断します。Amazon Best Sellersに関しては、Thunderbitにはワンクリックで使える事前構築テンプレートがあります。
ステップ1: Thunderbit Chrome拡張を入れる
を開き、「Chromeに追加」をクリックします。無料アカウントを作成してください。無料プランでも試すのに十分なクレジットがあります。
ステップ2: Amazon Best Sellersページを開く
Chromeで任意のAmazon Best Sellersカテゴリページを開きます。たとえば:
https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/
ステップ3: 「AI Suggest Fields」をクリックする
Thunderbitのサイドバーを開き、「AI Suggest Fields」をクリックします。AIがページ構造を解析し、Product Name、Price、Rating、Image URL、Vendor、Product URL、Rankなどの列を提案します。私のテストでは、約3秒で必要な項目をすべて正しく認識しました。

列名の変更、削除、追加もできます。さらに、各項目に独自のAIプロンプトを追加することも可能です。たとえば「Electronics/Apparel/Homeに分類する」といった指示を入れれば、各商品にカテゴリタグを付けられます。
ステップ4: 「Scrape」をクリックする
「Scrape」ボタンを押します。Thunderbitがページ上のすべての商品データを構造化テーブルにまとめます。クラウドモードでは最大50ページを並列処理でき、遅延読み込みやページネーションも自動で処理します。
ステップ5: 無料でエクスポートする
「Export」をクリックして、Excel、Google Sheets、Airtable、Notionのどれかを選びます。エクスポートはどのプランでも無料で、追加料金はありません。

ページを開いてから完全なスプレッドシートができるまで、全体で約90秒でした。比較すると、方法1は約20分(遅延読み込み問題のデバッグ込み)、方法2は約35分(Seleniumのセットアップ込み)、方法3は約15分(APIアカウント作成込み)でした。
ThunderbitがAmazonに強い理由
AIが毎回ページを新しく読み取るため、レイアウト変更にも自動で適応します。CSSセレクタの保守が不要です。これはスクレイピングの定番の不満、「普通のウェブスクレイパーでは足りない。要素変更に備えて色々な例外処理を入れないといけない」に直接対応しています。AmazonがDOMを変えても(これがよく起こるのですが)、何も更新する必要はありません。
クラウドスクレイピングモードでは、プロキシの切り替え、レンダリング、反ボット対策を意識せずに使えます。「とにかく動く」ソリューションを求める人にとって、面倒なブロック対策を丸ごと省けるのは大きな利点です。
Anti-Ban Playbook: Amazonにブロックされないための対策
Amazonのボット検知はかなり厳しめです。私もテスト中に一時的にIPをブロックされましたし、フォーラムでも「エラーだらけで、Amazonがホームページにリダイレクトしてくる」といった声を見かけます。Pythonで行くなら(方法1〜3)、この項目は重要です。
基本から高度なものまで、対策を段階的に並べると次の通りです。
1. User-Agent文字列をローテーションする
同じUser-Agentを何度も送るのは不自然です。方法1のコード例にある5種類以上の文字列を用意し、リクエストごとにランダム選択しましょう。
1headers = {"User-Agent": random.choice(USER_AGENTS)}
2. リクエスト間にランダムな待機時間を入れる
固定間隔はパターンとして検知されやすいです。ランダムな待機のほうが安全です。
1time.sleep(random.uniform(2, 5))
私の経験では、リクエスト間を2〜5秒空けると、小規模バッチ(50リクエスト未満)では目立ちにくくなりました。大きい処理では3〜7秒に伸ばすとよいです。
3. プロキシをローテーションする
これが最重要です。では、Amazonでの成功率は住宅用プロキシが平均約94%、データセンター系プロキシは約59%でした。35ポイントもの差があります。Amazonの検知スタックにはTLSフィンガープリント、行動分析、IPごとのレート制限が含まれているため、一般的なデータセンターIPは数秒で弾かれます。
住宅用プロキシは高価ですが(プロバイダーによっては1GBあたり$2〜$12)、信頼性は圧倒的に高いです。コード例は以下の通りです。
1proxies = {
2 "http": "http://user:pass@residential-proxy.example.com:8080",
3 "https": "http://user:pass@residential-proxy.example.com:8080"
4}
5response = requests.get(url, headers=headers, proxies=proxies)
4. ブラウザのフィンガープリントを強化する(Selenium)
1options.add_argument('--disable-blink-features=AutomationControlled')
2options.add_experimental_option("excludeSwitches", ["enable-automation"])
3options.add_experimental_option('useAutomationExtension', False)
4# driver初期化後にnavigator.webdriverフラグを消す
5driver.execute_cdp_cmd('Page.addScriptToEvaluateOnNewDocument', {
6 'source': "Object.defineProperty(navigator, 'webdriver', {get: () => undefined})"
7})
5. セッションとCookieを管理する
Cookieをリクエスト間で保持すると、より実在ユーザーの操作に近づきます。
1session = requests.Session()
2# まずホームページを訪れて自然なCookieを取得する
3session.get("https://www.amazon.com", headers=headers)
4time.sleep(2)
5# その後で対象ページを取得する
6response = session.get(target_url, headers=headers)
6. 面倒を丸ごと避けるべき場面
こうした管理を一切したくない人には、Thunderbitのクラウドスクレイピングが役立ちます。プロキシ切り替え、レンダリング、反ボット対策を透過的に処理します。スクレイピングAPIも同様に多くの部分を標準でカバーします。私の経験では、Anti-Ban対策のデバッグに使う時間が、実際のスクレイピングコードを書く時間を上回ることも珍しくありません。だからこそ、「とにかく動く」方式には本当のROIがあります。
サブページの拡張: 商品詳細ページもスクレイピングして情報を増やす
Best Sellersの一覧ページでは、タイトル、価格、評価、順位といった基本情報しか取れません。でも、FBAリサーチで本当に価値がある情報は、各商品の詳細ページにあります。一覧だけをスクレイピングすると、次の情報を取りこぼします。
| 項目 | 一覧ページ | 商品詳細ページ |
|---|---|---|
| 商品名 | ✅ | ✅ |
| 価格 | ✅ | ✅ |
| 評価 | ✅ | ✅ |
| BSR順位 | ✅ | ✅(サブカテゴリー順位も含む) |
| ブランド | ❌ | ✅ |
| ASIN | ❌ | ✅ |
| 初回販売日 | ❌ | ✅ |
| サイズ/重量 | ❌ | ✅ |
| 販売者数 | ❌ | ✅ |
| 箇条書きの特徴 | ❌ | ✅ |
| Buy Box所有者 | ❌ | ✅ |
特に「初回販売日」は重要です。商品がどれだけ長く市場にあるかを示し、競合分析の大きな手がかりになります。また、販売者数とBuy Box所有者が分かれば、その商品領域に参入する価値があるかどうかを見極めやすくなります(もしAmazon自身がBuy Boxシェアの30%以上を握っているなら、競争はかなり厳しいです)。
Pythonでのやり方: 商品URLをループする
一覧ページから商品URLを集めたら、1件ずつ遅延を入れながら巡回します。
1for product in products:
2 time.sleep(random.uniform(3, 6))
3 detail_response = session.get(product["URL"], headers={"User-Agent": random.choice(USER_AGENTS)})
4 detail_soup = BeautifulSoup(detail_response.text, "html.parser")
5 # ブランドを抽出
6 brand_tag = detail_soup.find("a", id="bylineInfo")
7 product["Brand"] = brand_tag.get_text(strip=True) if brand_tag else "N/A"
8 # ページソースまたはURLからASINを抽出
9 # 商品詳細テーブルから初回販売日を抽出
10 # ... 追加項目 ...
注意点として、100件の商品ページを個別に回ると、ブロックされるリスクがかなり上がります。プロキシのローテーションと長めの待機時間を前提にしてください。
Thunderbitのやり方: ワンクリックでサブページも取得
一覧ページをテーブルにした後、Thunderbitで「Scrape Subpages」をクリックします。するとAIが各商品のURLへ移動し、ブランド、ASIN、仕様、特徴などの列を自動で追加してくれます。追加コードも、セレクタ調整も、セットアップも不要です。仕入れ判断のために全体像が必要だが、詳細ページのパーサーを自分で書きたくないEコマースチームに特に向いています。
定期スクレイプの自動化: Amazon Best Sellersを継続監視する
一度だけのスクレイプも役に立ちますが、本当の競争優位は継続監視にあります。どの商品が上がって下がるのかを追い、トレンドを早めに見つけ、数週間〜数か月単位で価格変動を監視する——これが、単なる調査とデータ駆動の意思決定を分けるポイントです。
Pythonのやり方: cronでスケジュールする
Linux/Macでは、cronでPythonスクリプトを定期実行できます。毎日午前8時に実行する場合のcrontabは次の通りです。
10 8 * * * /usr/bin/python3 /home/user/amazon_scraper.py >> /home/user/logs/scrape.log 2>&1
毎週月曜の午前9時に実行するなら、次のようになります。
10 9 * * 1 /usr/bin/python3 /home/user/amazon_scraper.py >> /home/user/logs/scrape.log 2>&1
Windowsでは、同じことをタスクスケジューラで実現できます。ノートPCを起動しっぱなしにせず常時稼働させたい場合は、VPSやAWS Lambdaに置く方法もありますが、その分インフラの複雑さが増します。
失敗を検知するために、ログ記録とエラー通知を入れておきましょう。2週間前に静かに壊れていたことを後から知るほど嫌なものはありません。
Thunderbitのやり方: 自然言語でスケジュールできる
ThunderbitのScheduled Scraperでは、実行間隔を自然文で指定できます。「毎週月曜の9時」や「毎日8時」と入力するだけで、AIがスケジュールを解釈します。スクレイプはThunderbitのクラウドサーバー上で実行されるため、ブラウザやPCを起動しておく必要はありません。データはGoogle SheetsやAirtableに自動でエクスポートされます。これにより、サーバー管理なしでライブ監視ダッシュボードを作れます。DevOps負荷なしで継続的な可視化が欲しいオペレーションチームに最適です。
Amazonをスクレイピングする際の法的・倫理的な注意点
私は弁護士ではなく、これは法的助言でもありません。ただし、スクレイピング解説で法的リスクを無視するのは無責任です。フォーラムでもToSへの懸念がはっきり挙がっており、もっともなことです。
Amazonのrobots.txt: 2026年時点で、Amazonのrobots.txtには80以上のDisallowパスがありますが、/gp/bestsellers/は標準的なユーザーエージェントに対して明示的にはブロックされていません。ただし、ClaudeBot、GPTBot、Scrapyなど35以上のAI系ユーザーエージェントには、一律でDisallow: /が適用されています。特定のDisallowがないからといって、Amazonがスクレイピングを認めているわけではありません。
Amazonの利用規約: Amazonの(2025年5月更新)では、書面による許可なしに「Amazonウェブサイトのいかなる部分にもアクセス、取得、コピー、監視するために自動化されたプロセスや技術を使用すること」を明確に禁止しています。これは理論だけの話ではありません。Amazonは2025年11月に、無許可の自動アクセスをめぐってし、仮差止命令を勝ち取っています。
hiQ対LinkedInの前例: (第9巡回区、2022年)では、公開データのスクレイピングはComputer Fraud and Abuse Actに違反しない可能性が高いと判断されました。ただし、hiQは最終的に和解し、スクレイピング停止に同意しています。CFAAで勝っても、契約違反の主張までは防げません。
実務上のガイドライン:
- 公開されているデータだけを対象にする(価格、BSR、商品名など。個人情報は対象外)
- レート制限を守り、サーバーに負荷をかけすぎない
- 正当な競合分析用途に限定する
- 大規模実行の前に自分の法務担当に相談する
- で包括的なプライバシー法が施行されていることを意識する
Thunderbitのクラウドスクレイピングはブラウザに近い標準的なリクエストパターンを使いますが、必ず自分の法務担当と整合性を確認してください。
どの方法を使うべき?すぐ分かる判断ガイド
要するに、こうです。
- 「Pythonを学んでいて、週末のプロジェクトにしたい」 → 方法1(requests + BeautifulSoup)。HTTPリクエスト、HTML解析、Amazonのボット対策をたっぷり学べます。
- 「JavaScriptが多いページやログイン済みセッションを扱いたい」 → 方法2(Selenium)。重いですが、動的コンテンツに対応できます。
- 「本番環境で大規模に回したい」 → 方法3(スクレイピングAPI)。プロキシやレンダリング管理は外部に任せましょう。は月50万リクエスト未満ならAPI有利です。
- 「開発者ではないし、2分でデータが欲しい」 → 方法4()。コード不要、セレクタ不要、保守不要。
- 「サーバー管理なしで継続監視したい」 → Thunderbit Scheduled Scraper。設定して忘れてOKです。
結論と重要ポイント
週末を使って検証した結果、実際に分かったことは次の通りです。
requests + BeautifulSoup は学習には最適ですが、遅延読み込みの制限(50件中約30件しか取れない)と壊れやすいCSSセレクタのせいで、本番利用には向きません。
Selenium は遅延読み込みの問題を解決し、1ページ50件すべてを取得できますが、遅く、メモリを食い、Amazonのボット対策にもなお検出されやすいです。
スクレイピングAPI は本番規模のスクレイピングで最も信頼性が高く、Amazonでがあります。ただしコストは増え、解析コードは依然として自分で書く必要があります。
Thunderbit は、圧倒的に最速でデータを取得できました。AIがレイアウト変更、遅延読み込み、ページネーション、反ボット対策まで設定なしで処理してくれます。非技術者や、DevOps負荷なしで繰り返しデータが必要なチームにとっては、最も実用的な選択肢です。
最大の教訓は、Amazonのボット対策と頻繁なレイアウト変更を考えると、保守不要のソリューションほど長期的に時間を節約できるということです。壊れたセレクタの修正やプロキシの切り替えに使う1時間は、実際の分析に使うべき1時間です。
ノーコードの方法を試してみたいですか?なら、いくつかのBest Sellersカテゴリをスクレイピングして結果を確認するのに十分なクレジットがあります。Python派なら、上のコード例から始められます。どちらにしても、Amazon Best Sellerのデータをブラウザタブではなくスプレッドシートで扱えるようになります。
ウェブスクレイピングのほかの方法については、、、もご覧ください。では、手順付きの解説動画も公開しています。
さらに詳しく知る
