「結局、どのやり方が一番ラクなんだろう」。AmazonのBest Sellersページからデータを抜く方法を4通り試したのは、その答えを自分の手で確かめたかったからです。検証に付き合ってくれたのはコーヒー1ポット。蓋を開けてみれば、すんなり成功が2つ、IP停止の崖っぷちが1つ、そして2クリックで終わったのが1つでした。その実体験を、まるごとお話しします。
そもそもAmazonは規模が桁違いです。出品数は6億件、アクティブな顧客アカウントは3億1,000万超。そしてBest Sellers Rank(BSR)は1時間ごとに塗り替わります。FBAの商品リサーチにせよ、競合の値付け分析にせよ、トレンドの先取りにせよ、Best Sellerのデータが効いてくる場面は数えきれません。まさに金脈なんです。
厄介なのは、その金脈をスプレッドシートに移す作業そのものです。思っているほど素直にはいきません。だからこの記事では、requests + BeautifulSoup、Selenium、スクレイピングAPI、そして私たちが手がけるノーコードAIウェブスクレイパーThunderbit、この4つを並べて検証しました。実戦で使えるのはどれで、どれがCAPTCHAの前で行き止まりになるのか——順に見ていきましょう。
Amazonのベストセラーとは?なぜ気にするべきなのか?
各カテゴリーの販売数量を土台に、Amazonがリアルタイムで弾き出すランキング。それがAmazon Best Sellers Rank(BSR)です。直近の売上も過去の売上も両方が反映され、1時間ごとに更新される——いわば絶え間なく開票が続く人気投票ですね。Amazon自身の説明はこうです。
「Amazon Best Sellersの算出はAmazonの売上に基づいており、Amazonで販売された各商品の最近および過去の売上を反映するために1時間ごとに更新されます。」 — Amazon Seller Central
表示は1カテゴリーにつき上位100商品。これが50件ずつ2ページに割られていて、1ページ目に#1〜#50、2ページ目に#51〜#100が並びます。ちなみに、ページ閲覧数やカスタマーレビューは順位に関係しません。Amazonがそう明言しているとおり、BSRを決めるのは売上だけなんです。
では、このデータを追いかけるのはどんな人たちでしょう。FBA向けの商材を探すEコマース販売者、競合を分析する営業チーム、価格動向を見張るオペレーション担当、市場の成長を測るリサーチャー——だいたいこのあたりです。Amazonで商売をしている人、あるいはAmazonと正面からぶつかっている人なら、遅かれ早かれこのデータをスプレッドシートに集めたくなる。私自身、何度もそう感じてきました。
なぜPythonでAmazon Best Sellersをスクレイピングするのか?
商品調査を手作業でやっていると、時間はいくらあっても足りません。McKinseyの調査によると、従業員が情報の検索と収集に使う時間は週平均9.3時間。Eコマースチームの日常に置き換えるなら、Amazonの商品ページを開いては商品名と価格をコピーしてスプレッドシートに貼り、来週また同じことをなぞる——そんな繰り返しです。
Best Sellersのスクレイピングが活きてくるユースケースを、表でざっと押さえておきましょう。
| ユースケース | 得られるもの | 恩恵を受ける人 |
|---|---|---|
| FBA商品リサーチ | BSRとレビュー数から需要が高く競争が少ない商品を見つける | Amazon販売者、ドロップシッパー |
| 競合価格の追跡 | 自分のカテゴリ上位商品の価格変動を把握する | Eコマースチーム、価格アナリスト |
| 市場トレンド監視 | 伸びているカテゴリーや季節変動を見つける | プロダクトマネージャー、市場調査担当 |
| リード獲得 | 上位ブランドとその商品ラインの一覧を作る | 営業チーム、B2Bアウトリーチ担当 |
| 競合分析 | 自社製品をカテゴリ上位商品と比較する | ブランドマネージャー、戦略チーム |
しかも、ここで言うROIは口先だけのものではありません。Salesforceの調査が2,700人のコマース専門家に尋ねたところ、AIツールの導入でEコマース担当者は平均週6.4時間を浮かせていました。価格追跡を自動化した販売者になると、Buy Box獲得率は67%。手動トラッカー組の42%を大きく引き離しています。値動きに即応できることが、売上37%増へとつながったわけです。
PythonでAmazon Best Sellersをスクレイピングする4つの方法を比較
細かい手順に踏み込む前に、まず全体像を一枚の表で。「最初からこれが見たかった」と思ってもらえるはずです。自分の状況に照らして、どの方法が合うか当たりをつけてみてください。
| 基準 | requests + BS4 | Selenium | スクレイピングAPI(例: Scrape.do) | Thunderbit(ノーコード) |
|---|---|---|---|---|
| 初期設定の難易度 | 中 | 高(ドライバー、ブラウザ) | 低(APIキー) | 非常に低い(Chrome拡張) |
| 遅延読み込みへの対応 | いいえ | はい(スクロール再現) | はい(レンダリング済みHTML) | はい(AIがレンダリング対応) |
| 反ボット耐性 | 低い(IP停止のリスク) | 中(検出されやすい) | 高い(プロキシ自動切替) | 高い(クラウド+ブラウザモード) |
| 保守負荷 | 高い(セレクタが壊れやすい) | 高い(ドライバー更新+セレクタ調整) | 低い | 非常に低い(AIがレイアウト変更に適応) |
| コスト | 無料 | 無料 | 有料(リクエストごと) | 無料枠+有料プラン |
| 向いている用途 | 単発スクレイプ、学習用 | JSが多いページ、ログイン必須ページ | 本番運用、スケール処理 | 非エンジニア、素早い調査、定期監視 |
スクレイピングの基礎を手を動かして覚えたいなら、入り口は方法1か方法2。本番で通用する安定性が欲しいなら方法3。コードを書かずに2クリックで結果だけ欲しいなら、迷わず方法4へどうぞ。
始める前に
- 難易度: 初級〜中級(方法による)
- 所要時間: Thunderbitなら約15分、Pythonの方法なら約45分
- 必要なもの: Python 3.8以上(方法1〜3)、Chromeブラウザ、Thunderbit Chrome拡張機能(方法4)、対象のAmazon Best SellersカテゴリURL
方法1: requests + BeautifulSoupでAmazon Best Sellersをスクレイピングする
最初に挙げるのは、いちばん身軽で初心者にやさしいやり方です。ブラウザの自動化には頼らず、HTTPリクエストとHTML解析だけで完結します。じつのところ、Amazonのスクレイピング対策の手の内をいちばん勉強できたのも、この方法でした。
ステップ1: 環境を準備する
まずは必要なパッケージのインストールから。
pip install requests beautifulsoup4 pandas
そのあと、インポート文をそろえておきます。
import requests
from bs4 import BeautifulSoup
import pandas as pd
import random
import time
ステップ2: 実在のブラウザらしいヘッダーでリクエストする
ボットくさいリクエストを、Amazonはあっさり跳ね返します。だから最初の一手は、本物のブラウザを名乗るUser-Agentヘッダーを添えること。下に挙げたのは、いま実際に通用するUser-Agent文字列の例です(Geekflareより、2026年3月時点)。
USER_AGENTS = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"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",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 15.7; rv:149.0) Gecko/20100101 Firefox/149.0",
"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",
]
headers = {"User-Agent": random.choice(USER_AGENTS)}
url = "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/"
response = requests.get(url, headers=headers)
print(response.status_code) # 200なら成功
返ってきたステータスコードが200なら成功の合図。逆に503が返る、もしくはCAPTCHAページへ飛ばされたなら、それはAmazonがリクエストを弾いているサインです。
ステップ3: BeautifulSoupで商品データを解析する
手を動かす前に、ブラウザのDevTools(右クリック → 検証)でAmazonページのHTMLを覗いておきましょう。商品コンテナにはgridItemRootというIDが割り当てられていて、その内側に商品名・価格・評価・URLが収まっています。
soup = BeautifulSoup(response.text, "html.parser")
products = []
for item in soup.find_all("div", id="gridItemRoot"):
title_tag = item.find("div", class_="_cDEzb_p13n-sc-css-line-clamp-3_g3dy1")
price_tag = item.find("span", class_="_cDEzb_p13n-sc-price_3mJ9Z")
link_tag = item.find("a", class_="a-link-normal")
title = title_tag.get_text(strip=True) if title_tag else "N/A"
price = price_tag.get_text(strip=True) if price_tag else "N/A"
url = "https://www.amazon.com" + link_tag["href"] if link_tag else "N/A"
products.append({"Title": title, "Price": price, "URL": url})
注意:
_cDEzb_から始まるクラス名は、Amazonが折に触れて生成し直すCSSモジュールのハッシュです。比較的長持ちするのはgridItemRootのIDやa-link-normalのクラスのほう。とはいえ、スクレイパーを動かす前にはDevToolsでセレクタを確認する習慣をつけてください。
ステップ4: CSVに出力する
df = pd.DataFrame(products)
df.to_csv("amazon_best_sellers.csv", index=False)
print(f"{len(products)}件の商品を取得しました")
何が起こるのか、そして何がうまくいかないのか
私が試した限り、この方法で手元に残ったのは50件ではなく約30件でした。コードがバグっているわけではありません。犯人はAmazonの遅延読み込みです。最初に描画されるのは約30件で、残りはスクロールしてはじめてJavaScriptが吐き出してくる。requestsにはそこへ踏み込む手段がないんです。
つまずきどころは、ほかにもあります。
- プロキシを回さないとIP停止がすぐ飛んでくる(私は短時間に15回ほど投げたところで止められました)
- Amazonがページ構成をいじるとCSSセレクタが崩れる。しかもその頻度がなかなか高い
- ページネーションが最初から考慮されていない
学習教材としては申し分ないものの、本番に投入するには心もとない——それが正直な評価です。
方法2: SeleniumでAmazon Best Sellersをスクレイピングする
遅延読み込みの壁を、実物のブラウザを動かして突破する。それがSeleniumのアプローチです。準備はやや重いですが、その代わり1ページ50件をきっちり取り切れます。
ステップ1: Seleniumをインストールする
pip install selenium pandas
ここで嬉しい知らせを。Selenium 4.6以降ならwebdriver-managerはもう要りません。ドライバーのダウンロードは、Selenium Managerが裏で自動的に片付けてくれます。
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
import time
import pandas as pd
options = Options()
options.add_argument("--headless=new")
options.add_argument("--window-size=1920,1080")
options.add_argument("--disable-blink-features=AutomationControlled")
driver = webdriver.Chrome(options=options)
--headless=newフラグはChrome 109から入ったもので、通常表示のChromeと同じレンダリング経路をたどります。だからこそAmazonの目をかいくぐりやすいわけです。
ステップ2: 遅延読み込みをスクロールで読み切る
Seleniumの真骨頂が顔を出すのは、まさにここ。Amazon Best Sellersは初期表示で約30件しか読み込まず、残りはスクロールしてようやく姿を現します。
def scroll_page(driver, scrolls=5, delay=2):
for _ in range(scrolls):
driver.find_element(By.TAG_NAME, "body").send_keys(Keys.PAGE_DOWN)
time.sleep(delay)
driver.get("https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/")
time.sleep(3)
scroll_page(driver)
スクロールを終えれば、50件すべてがDOMに描き出されているはず。私の環境では2秒間隔で5回Page Downを送れば足りましたが、回線次第でこのあたりは加減してください。
ステップ3: 商品データを抽出する
items = driver.find_elements(By.ID, "gridItemRoot")
products = []
for item in items:
try:
title = item.find_element(By.CSS_SELECTOR, "div._cDEzb_p13n-sc-css-line-clamp-3_g3dy1").text
except:
title = "N/A"
try:
price = item.find_element(By.CSS_SELECTOR, "span._cDEzb_p13n-sc-price_3mJ9Z").text
except:
price = "N/A"
try:
url = item.find_element(By.CSS_SELECTOR, "a.a-link-normal").get_attribute("href")
except:
url = "N/A"
products.append({"Title": title, "Price": price, "URL": url})
抽出処理を一つひとつtry/exceptで包んでおく——これが地味に効きます。在庫切れの商品や項目が欠けたものに当たっても、1件のつまずきで全体が止まらずに済むからです。
ステップ4: ページネーションを処理する
上位100件を、AmazonはBest Sellersで2ページに分割します。しかもページごとにURLの作りが違うので注意が必要です。
urls = [
"https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/",
"https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/ref=zg_bs_pg_2_electronics?_encoding=UTF8&pg=2"
]
all_products = []
for url in urls:
driver.get(url)
time.sleep(3)
scroll_page(driver)
# ... 上記と同じように商品を抽出 ...
all_products.extend(products)
driver.quit()
何が期待できるか
実測では、Seleniumは各ページの50件を漏れなく取得できました。requests + BS4と比べれば、これは明らかに一段上です。ただ、スクロール待ちまで勘定に入れると1ページあたり約45秒。プロキシなしで繰り返し回せば、やはりブロックを食らいました。アンチ検出フラグを盛り込んでも、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を返してくる。あとはその戻り値を、いつものようにBeautifulSoupに食わせて解析するだけです。
ステップ1: API経由でリクエストを送る
ここではScrape.doを例に取ります(料金は150,000クレジットで月29ドル〜。1クレジットはレンダリングの有無を問わず1リクエスト換算です)。
import requests
from bs4 import BeautifulSoup
api_token = "YOUR_API_TOKEN"
target_url = "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/"
api_url = f"https://api.scrape.do?token={api_token}&url={target_url}&render=true&geoCode=us"
response = requests.get(api_url)
soup = 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で約99%の成功率)、ドライバー管理から解放され、反ボット対策は自動、しかもスケールしやすい。
デメリット: 課金がリクエスト単位なので、規模が膨らむほどコストもふくらむ。解析コードは結局こちらで書く必要があり、CSSセレクタの変更にはやはり弱い。月10万ページ規模だと差は無視できません。内製は3年で約$1,028,000に達するのに対し、プロバイダー利用なら約$293,000——71%もの圧縮です。
損益分岐の目安は、おおよそ月50万〜100万リクエストのあたり。これを下回る規模なら、APIで浮く時間がコストをはっきり上回ります。
方法4: ThunderbitでAmazon Best Sellersをスクレイピングする(Python不要)
先に白状しておくと、私はThunderbitの中の人です。そのバイアスは差し引いてもらって構いませんが、4つの方法を立て続けに自分で回してみて、データが手元に届くまでのスピード差は本当に大きい、と素直に感じました。
ThunderbitはChrome拡張として動くAIウェブスクレイパーです。考え方はいたってシンプル。CSSセレクタやPythonコードを書く役目をAIに肩代わりさせ、ページを読んで「何を抜くべきか」をAIが判断します。Amazon Best Sellers向けには、ワンクリックで呼び出せる事前構築テンプレートまで用意してあります。
ステップ1: Thunderbit Chrome拡張を入れる
Chrome Web Storeを開いて「Chromeに追加」をクリック。あとは無料アカウントを作るだけです。試すだけなら、無料プランのクレジットで十分まかなえます。
ステップ2: Amazon Best Sellersページを開く
Chromeで、好きなAmazon Best Sellersのカテゴリページを開きます。たとえばこんなURLです。
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種類以上の文字列を手元に置き、リクエストのたびにランダムに引いてください。
headers = {"User-Agent": random.choice(USER_AGENTS)}
2. リクエスト間にランダムな待機時間を入れる
きっちり固定した間隔は、パターンとして見抜かれやすい。だから待機はランダムにするほうが安全です。
time.sleep(random.uniform(2, 5))
私の経験では、リクエストの間を2〜5秒空けておくと、小規模バッチ(50リクエスト未満)ではほとんど目立ちませんでした。規模が大きくなるなら、3〜7秒へ伸ばすのが無難です。
3. プロキシをローテーションする
ここが一番の勘どころです。Proxywayのベンチマークでは、Amazonでの成功率が住宅用プロキシで平均約94%、データセンター系で約59%。実に35ポイントの開きがありました。AmazonはTLSフィンガープリント、行動分析、IP単位のレート制限を検知スタックに組み込んでいるので、ありふれたデータセンターIPは数秒で弾き飛ばされます。
住宅用プロキシは出費がかさみます(プロバイダーによっては1GBあたり$2〜$12)が、信頼性は段違い。コードに落とすとこうなります。
proxies = {
"http": "http://user:pass@residential-proxy.example.com:8080",
"https": "http://user:pass@residential-proxy.example.com:8080"
}
response = requests.get(url, headers=headers, proxies=proxies)
4. ブラウザのフィンガープリントを強化する(Selenium)
options.add_argument('--disable-blink-features=AutomationControlled')
options.add_experimental_option("excludeSwitches", ["enable-automation"])
options.add_experimental_option('useAutomationExtension', False)
# driver初期化後にnavigator.webdriverフラグを消す
driver.execute_cdp_cmd('Page.addScriptToEvaluateOnNewDocument', {
'source': "Object.defineProperty(navigator, 'webdriver', {get: () => undefined})"
})
5. セッションとCookieを管理する
Cookieをリクエストをまたいで持ち回ると、実在ユーザーの動きにぐっと寄せられます。
session = requests.Session()
# まずホームページを訪れて自然なCookieを取得する
session.get("https://www.amazon.com", headers=headers)
time.sleep(2)
# その後で対象ページを取得する
response = session.get(target_url, headers=headers)
6. 面倒を丸ごと避けるべき場面
こうした管理ごとを一切抱えたくないなら、Thunderbitのクラウドスクレイピングが効いてきます。プロキシ切り替えもレンダリングも反ボット対策も、ぜんぶ裏側で処理してくれるからです。スクレイピングAPIも、似たような守備範囲を標準でカバーします。私の感覚では、Anti-Ban対策のデバッグに溶ける時間が、本来のスクレイピングコードを書く時間を上回ることすら珍しくありません。だから「とにかく動く」方式には、ちゃんとしたROIがあるんです。
サブページの拡張: 商品詳細ページもスクレイピングして情報を増やす
一覧ページから取れるのは、タイトル・価格・評価・順位といった表層情報だけ。けれどFBAリサーチで本当に効くデータは、各商品の詳細ページに眠っています。一覧だけで済ませると、こんな情報を取りこぼします。
| 項目 | 一覧ページ | 商品詳細ページ |
|---|---|---|
| 商品名 | ✅ | ✅ |
| 価格 | ✅ | ✅ |
| 評価 | ✅ | ✅ |
| BSR順位 | ✅ | ✅(サブカテゴリー順位も含む) |
| ブランド | ❌ | ✅ |
| ASIN | ❌ | ✅ |
| 初回販売日 | ❌ | ✅ |
| サイズ/重量 | ❌ | ✅ |
| 販売者数 | ❌ | ✅ |
| 箇条書きの特徴 | ❌ | ✅ |
| Buy Box所有者 | ❌ | ✅ |
なかでも見逃せないのが「初回販売日」。その商品がどれだけ長く市場に居座っているかが分かり、競合分析の有力な手がかりになります。加えて販売者数とBuy Box所有者が見えれば、その領域に攻め込む価値があるかどうかの判断もぐっと楽になる(Amazon自身がBuy Boxシェアの30%以上を握っているようなら、戦いはかなり険しい、ということです)。
Pythonでのやり方: 商品URLをループする
一覧ページで商品URLを集め終えたら、遅延を挟みつつ1件ずつ巡回していきます。
for product in products:
time.sleep(random.uniform(3, 6))
detail_response = session.get(product["URL"], headers={"User-Agent": random.choice(USER_AGENTS)})
detail_soup = BeautifulSoup(detail_response.text, "html.parser")
# ブランドを抽出
brand_tag = detail_soup.find("a", id="bylineInfo")
product["Brand"] = brand_tag.get_text(strip=True) if brand_tag else "N/A"
# ページソースまたはURLからASINを抽出
# 商品詳細テーブルから初回販売日を抽出
# ... 追加項目 ...
ひとつ釘を刺しておくと、100件の商品ページを個別に叩いて回ると、ブロックのリスクは一気に跳ね上がります。プロキシのローテーションと長めの待機は、前提として組み込んでおいてください。
Thunderbitのやり方: ワンクリックでサブページも取得
一覧ページをテーブル化したあと、Thunderbitで「Scrape Subpages」を押す。たったそれだけで、AIが各商品のURLへ移動し、ブランド・ASIN・仕様・特徴といった列を勝手に足してくれます。追加コードも、セレクタの調整も、セットアップも要りません。仕入れ判断のために全体像は欲しいけれど、詳細ページのパーサーまで自前で書く気はない——そんなEコマースチームには、とりわけ刺さるはずです。
定期スクレイプの自動化: Amazon Best Sellersを継続監視する
一度きりのスクレイプにも価値はあります。でも、本当の差がつくのは継続監視のほう。どの商品が浮上し、どれが沈んでいくのかを追い、トレンドを早めに掴み、数週間〜数か月のスパンで価格の動きを見張る——ここが、ただの調査とデータ駆動の意思決定とを分ける分水嶺です。
Pythonのやり方: cronでスケジュールする
Linux/Macなら、cronでPythonスクリプトを定期実行できます。毎日午前8時に走らせたいなら、crontabはこう書きます。
0 8 * * * /usr/bin/python3 /home/user/amazon_scraper.py >> /home/user/logs/scrape.log 2>&1
毎週月曜の午前9時なら、こちらです。
0 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のConditions of Use(2025年5月更新)は、書面の許可なしに「Amazonウェブサイトのいかなる部分にもアクセス、取得、コピー、監視するために自動化されたプロセスや技術を使用すること」をはっきり禁じています。これは机上の空論ではありません。Amazonは2025年11月、無許可の自動アクセスをめぐってPerplexity AIを提訴し、仮差止命令まで勝ち取っています。
hiQ対LinkedInの前例: hiQ Labs v. LinkedIn(第9巡回区、2022年)では、公開データのスクレイピングはComputer Fraud and Abuse Actに抵触しない公算が大きい、との判断が示されました。もっとも、hiQは最終的に和解し、スクレイピングの停止に同意しています。CFAAで勝ったところで、契約違反の主張まで封じられるわけではない、ということです。
実務上のガイドライン:
- 対象は公開データに限る(価格、BSR、商品名など。個人情報には手を出さない)
- レート制限を守り、サーバーに過度な負荷をかけない
- 用途は正当な競合分析に限定する
- 大規模に回す前には、自社の法務担当に一声かける
- 米国の20州以上で包括的なプライバシー法が動いていることを頭に入れておく
Thunderbitのクラウドスクレイピングはブラウザに近い標準的なリクエストパターンを使いますが、それでも自社の法務担当との整合は必ず取ってください。
どの方法を使うべき?すぐ分かる判断ガイド
ざっくりまとめると、こういうことです。
- 「Pythonを学んでいて、週末のプロジェクトにしたい」 → 方法1(requests + BeautifulSoup)。HTTPリクエスト、HTML解析、Amazonのボット対策をたっぷり学べます。
- 「JavaScriptが多いページやログイン済みセッションを扱いたい」 → 方法2(Selenium)。重いですが、動的コンテンツに対応できます。
- 「本番環境で大規模に回したい」 → 方法3(スクレイピングAPI)。プロキシやレンダリング管理は外部に任せましょう。総保有コストは月50万リクエスト未満ならAPI有利です。
- 「開発者ではないし、2分でデータが欲しい」 → 方法4(Thunderbit)。コード不要、セレクタ不要、保守不要。
- 「サーバー管理なしで継続監視したい」 → Thunderbit Scheduled Scraper。設定して忘れてOKです。
結論と重要ポイント
週末をまるごとつぎ込んだ検証から、実際に見えてきたことを並べます。
requests + BeautifulSoup は学習用なら申し分ありません。ただ、遅延読み込みの壁(50件中およそ30件しか取れない)と崩れやすいCSSセレクタのせいで、本番運用には向かないのが実情です。
Selenium は遅延読み込みを乗り越えて1ページ50件を取り切れますが、動作は遅く、メモリは重く、Amazonのボット対策にはやはり見つかりやすい。
スクレイピングAPI は本番規模で最も頼りになり、Amazonでも約99%の成功率を叩き出します。代わりにコストはかさみ、解析コードは相変わらず自分の仕事として残ります。
Thunderbit は、データ到達までの速さで他を寄せつけませんでした。レイアウト変更も、遅延読み込みも、ページネーションも、反ボット対策も、AIが設定ゼロでさばいてくれる。非技術者や、DevOpsの負荷なしに繰り返しデータを必要とするチームにとっては、いちばん実用的な落としどころです。
突き詰めると、教訓はひとつ。Amazonのボット対策と頻繁なレイアウト変更を前提にすれば、保守のいらないソリューションほど、長い目で見て時間を返してくれる、ということ。壊れたセレクタの修正やプロキシ切り替えに溶かす1時間は、本来なら分析に注ぐべき1時間なのです。
ノーコードの方法を試してみたいですか?Thunderbitの無料プランなら、いくつかのBest Sellersカテゴリをスクレイピングして結果を確かめるのに十分なクレジットがあります。Python派なら、上のコード例から始められます。どちらにしても、Amazon Best Sellerのデータをブラウザタブではなくスプレッドシートで扱えるようになります。
ウェブスクレイピングのほかの方法については、Amazonの商品とレビューのスクレイピング、ウェブサイトからExcelにデータを抽出する方法、おすすめのAIウェブスクレイパーもご覧ください。ThunderbitのYouTubeチャンネルでは、手順付きの解説動画も公開しています。
さらに詳しく知る


