GitHub で「amazon scraper」と検索すると、約 が見つかります。そこから「過去6か月以内に更新された」ものに絞ると、約 まで減り、全体の20%弱にすぎません。残りは？ 使われなくなったチュートリアル、古いラッパー、そして Amazon が防御を強化した瞬間に動かなくなったスクリプトです。
私はこれまで、Amazon スクレイパーのリポジトリをかなり時間をかけて調べ、GitHub の issue を読み込み、Reddit や Stack Overflow のコミュニティスレッドも追ってきました。傾向は一貫しています。人気リポジトリを見つけて1時間ほどセットアップし、一度実行したら、CAPTCHA か 503 エラーの壁にぶつかる。2026年の Amazon の対ボット対策は、2年前と比べてもまったく同じではありません。TLS フィンガープリント、行動分析、積極的な CAPTCHA 配信によって、昔ながらの「User-Agent をローテーションして運を祈る」やり方は、ほとんど通用しなくなっています。このガイドでは、GitHub リポジトリから信頼できる Amazon データを取得したいときに本当に重要なベストプラクティスと、スクレイパーが壊れたとき（壊れないと思っていても）の対処法を解説します。
GitHub 上の Amazon スクレイパーとは何か、なぜ多くが失敗するのか？
GitHub の Amazon スクレイパーのリポジトリは、通常オープンソースのスクリプトです。多くは Python、Node.js、または Scrapy ベースで、Amazon のページから構造化データを抽出します。対象データはおなじみのものです。商品タイトル、価格、ASIN、評価、レビュー数、在庫状況、出品者情報、検索結果カード、レビュー本文などです。
アーキテクチャはたいていシンプルです。
- HTTP クライアントまたはヘッドレスブラウザでページを取得する。
- HTML または JSON パーサーで項目を抽出する。
- データを CSV、JSON、またはデータベースに保存する。
リポジトリは大きく4つのタイプに分かれます。
- 軽量な Python ライブラリ（例: ）
- Scrapy スパイダー（例: ）
- Selenium や Playwright によるブラウザ自動化
- API ラッパー系プロジェクト。実際には商用スクレイピングサービスのフロントエンドになっているもの（例: ）
失敗のパターンは予測できます。多くのリポジトリが壊れる理由は次のとおりです。
- Amazon がページレイアウトや HTML の断片を変更する
- 実データの代わりに 503 や CAPTCHA が返される
- スクレイパーの TLS や HTTP フィンガープリントが、もはやブラウザらしく見えない
- ロケール、言語、ヘッダーの不一致で不審と判定される
- 元の限定的な用途を解決したあと、メンテナーが離れてしまう
スター数が多いことと「今使える」ことは、まったく別問題です。この記事のために行った監査では、広く見つかった8つのリポジトリのうち、2026年時点で明らかにアクティブだと判断できたのは3つ程度でした。
2026年版の鮮度監査を、Amazon スクレイパーの GitHub リポジトリをクローンする前に行う
この手順は、Amazon では他の多くの対象よりも重要です。Amazon の防御姿勢は一般的な EC サイトより速く変わるため、紹介サイトでは問題なく動くリポジトリでも、Amazon 上では数週間で無価値になることがあります。それでも「best amazon scraper github」といった一覧の多くは、まだ動くかどうかを確認せずにリポジトリを勧めています。ユーザーは壊れたツールのセットアップに何時間も費やしてしまいます。
GitHub リポジトリがまだ生きているか確認する方法
git clone する前に、次のチェックを行ってください。
- 最終コミット日: Amazon では、6か月以上前のものは強い警告サインです。
- 未解決 issue と応答率: Issues タブで「captcha」「503」「blocked」「not working」を検索してください。報告が積み上がっているのにメンテナーの返信がなければ、やめておくべきです。
- 依存関係の健全性:
requirements.txtやpackage.jsonを開きます。古いライブラリ（例: 最新の TLS 対応がない古いrequests）は危険信号です。 - Amazon のページ種別への対応範囲: 商品ページ、検索結果、レビューのすべてに対応しているか、それとも1種類だけか。
- 対ボット対策への向き合い方: プロキシ対応なしのハードコードされたヘッダーだけ、というのは 2023年レベルの発想で、2026年には通用しません。
Amazon スクレイパー GitHub 鮮度チェックリスト
| 鮮度のシグナル | 確認ポイント | 危険信号 🚩 |
|---|---|---|
| 最終コミット日 | コミットフィードまたはリポジトリの push 日 | 6か月以上前 |
| 未解決 issue | Issues タブ — 「captcha」「503」「blocked」で絞り込み | メンテナーの返信なしで障害報告が繰り返される |
| 依存関係の健全性 | requirements.txt / package.json | 廃止済みライブラリ、最新の TLS 戦略なし |
| Amazon ページの対応範囲 | README + コード例 | 1種類のページしか扱えない（例: 商品ページのみで検索やレビューは不可） |
| 対ボット対策 | ソースコード、プロキシ設定 | ハードコードされたヘッダーと UA 文字列のみ |
| メンテナンス形態 | 本物のスクレイパーか、チュートリアルか、商用 API ラッパーか | 実態は有料サービスのフロントエンドにすぎない |
実際の監査で分かったこと
広く見つかった Amazon スクレイパーのリポジトリ8件を、この基準で確認しました。結果はかなり厳しいものでした。
| リポジトリ / ツール | スター数 | 最終コミットの目安 | スコープ | 2026年の状態 | メモ |
|---|---|---|---|---|---|
| oxylabs/amazon-scraper | 約2,872 | 2026-04-02 | 管理型スクレイピング API ラッパー | 生存しているが DIY ではない | 新しいが、実際には管理サービスのフロントエンド |
| omkarcloud/amazon-scraper | 約214 | 2026-02-25 | 検索、詳細、レビュー用の管理 API | 生存しているが DIY ではない | 対応範囲は広いが、純粋なスクレイパーではなく API 製品 |
| theonlyanil/amzpy | 約110 | 2026-02-26 | 軽量な Python ライブラリ | 生存 | curl_cffi を使う、GitHub 上で直接使えるスクレイパーとして最も明快 |
| philipperemy/amazon-reviews-scraper | 約134 | 2024-11-21 | レビュー専用 | 狭いが使用可能 | 古く、レビュー特化がかなり強い |
| python-scrapy-playbook/amazon-python-scrapy-scraper | 約74 | 最終コミット 2023年; repo pushed 2024-08-20 | Scrapy スパイダー + プロキシミドルウェア | チュートリアル級で古い | 学習用には有用だが、2026年の即戦力スタックではない |
| drawrowfly/amazon-product-api | 約744 | 2022-11-13 | 検索、詳細、レビュー用の Node CLI | 高リスク | 対応範囲は広いが、メンテナンスが古すぎる |
| tducret/amazon-scraper-python | 約881 | 2020-10-13 | 検索結果を CSV に出力 | 2026年には事実上終了 | 歴史的には人気だが、明らかに古い |
| scrapehero-code/amazon-scraper | 約432 | 2020-06-21 | 検索 / 商品のチュートリアル | 2026年には事実上終了 | 実質的にアーカイブ |
公開 issue を見ても同じです。 には「All requests receive captcha response.」という issue があります。 には「Doesn't seem to be working.」があります。 には「Bypass Amazon protection.」があります。どれも珍しい例外ではなく、ユーザーが最初にぶつかる典型的な問題です。
BAN 回避のプレイブック: GitHub の Amazon スクレイパーでブロックされないための方法
ブロックされることは、amazon scraper github プロジェクトを使う人にとって最大の悩みです。「プロキシを使って User-Agent をローテーションしましょう」といった一般論では、もはや十分ではありません。Amazon の 2025〜2026年の対ボットスタックには、TLS フィンガープリント、行動分析、そして積極的な CAPTCHA 配信が含まれます。多層的な対策が必要です。
TLS フィンガープリントの一致: なぜ素の requests では BAN されるのか
これは、見落とされがちな BAN 回避テクニックのひとつです。TLS フィンガープリントはこう機能します。スクリプトが Amazon と安全な接続を確立すると、サーバーは「どの暗号スイートを提示したか」「拡張の順序はどうか」「HTTP/2 の設定はどうか」といった“握手”の仕方から、クライアントについて多くを判断できます。ブラウザは比較的固定された TLS と HTTP/2 の設定を使っており、それらは のような手法で識別できます。
素の requests や通常の httpx はヘッダーを真似ることはできますが、Chrome っぽい TLS や HTTP/2 の挙動までは真似できません。Amazon はその違いを見分けます。
はこの問題に直接対応します。ブラウザ偽装を提供しており、対応先には chrome136、safari184、firefox133 などがあります。これにより、HTTP クライアントの TLS フィンガープリントを本物のブラウザに合わせられます。ドキュメントでも、ランダムな JA3 文字列を作るのは避けるよう明確に警告しています。ブラウザのフィンガープリントはバージョンごとにほぼ固定されており、ランダムなでたらめよりも、実在するフィンガープリントをコピーしたほうが検出されにくいからです。
コミュニティのデータも一致しています。 では、impersonate 引数がブラウザプロファイルを切り替えつつヘッダー整合性を保てるため有用だと確認されています。別の では、Amazon はおよそ「1〜2か月後」に TLS フィンガープリントを基準にクライアントをブロックすると述べられています。 でも、Amazon が python-requests をフィンガープリントしているのか、という点が具体的に問われています（答えは、はい、です）。
まだ最初の Amazon 向けクライアントに素の requests を使っているなら、他をいじる前に、その前提を先に見直してください。
正しいプロキシローテーション（ただ「プロキシを使う」だけではない）
プロキシの目的は、できるだけ頻繁に切り替えることではありません。セッションをそれらしく見せることです。
住宅用 vs. データセンター用: データセンター用プロキシは安価ですが、検出されやすいです。住宅用プロキシは高価ですが、Amazon にフラグを立てられにくくなります。 は従量課金で 4.00ドル/GB から始まり、大きめのプランでは 3.50ドル/GB まで下がります。 は 6ドル/GB からです。Amazon は「高度な対象」に属し、住宅用プロキシに上乗せ料金を払う価値があります。
リクエストごとの切り替え vs. セッションごとの切り替え: ここを間違えるチュートリアルは多いです。Cookie とヘッダーを固定したままリクエストごとにプロキシを切り替えると、かえって人間らしさが下がることがあります。より安全なパターンは次のとおりです。
- 可能な限り、検索 → 商品 → レビューの流れは同じ sticky セッションで通す
- 新しい検索の流れを始めるときにセッションを切り替える。毎リクエストではない
- 1つのブラウジングセッション内でランダムに切り替えるのではなく、セッション間でローテーションする
ある では、一般的な ISP の IP は人気 EC サイトではモバイル IP ほど良く機能しないと指摘されていました。別の では、User-Agent を回し、住宅用プロキシを使っていてもブロックされたと報告されており、プロキシだけでは不十分だという良い注意喚起になっています。
リクエストの間隔、バックオフ、レート制限
Amazon の 503 ページは、単なる不運ではありません。フィードバックです。
500個以上の ASIN をスクレイピングすることに関する では、sleep を入れていても毎回同じ地点、ASIN 101 前後で 503 が出ると報告されています。このパターン自体は古いですが、教訓は今も有効です。1つの IP やフィンガープリントからの大量アクセスは、いずれ防御に引っかかります。
DIY の GitHub スクレイパーにおける、推奨ペース配分は次のとおりです。
- リクエスト間にランダムな遅延を入れる（一定間隔は検出されやすい）
- 単純な HTTP クライアントなら、公開商品ページのリクエスト間は2〜5秒
- 503 や CAPTCHA の後は指数バックオフを使う — すぐ再試行せず、段階的に間隔を広げる
- 必要だと思うより同時実行数を少なくする
- ループ再試行を厳密に回すのではなく、失敗してもログを残して先へ進める
多くの amazon scraper github リポジトリには、レート制限が組み込まれていません。自分で追加する必要があります。
ヘッダーの統制: User-Agent だけではない
Amazon は User-Agent だけでなく、ヘッダー全体をチェックします。
現実的なブラウザのヘッダーセットには、次のものが含まれるべきです。
User-AgentAcceptAccept-LanguageAccept-Encoding- 適切な場合の
Sec-CH-*ヒント - 選択したブラウザプロファイルと整合する接続挙動
ヘッダーはマーケットプレイスのロケールに合わせる必要があります。10個の Amazon ロケールをスクレイピングしていた は、同じボット設定でも一部のロケールでしか検出されず、別のコメントでは Accept-Language のような地域関連ヘッダーが原因ではないかと指摘されていました。
ルールは明確です。ヘッダー、TLS/ブラウザプロファイル、プロキシの地理情報は互いに矛盾してはいけません。Chrome のヘッダーを Firefox UA と一緒に送らないこと。Accept-Language: de-DE に対して米国のプロキシを使わないことです。
CAPTCHA 対応: 解くべきときと、引くべきとき
CAPTCHA に遭遇した時点で、Amazon はすでに疑っています。解いたからといって信頼スコアがリセットされるわけではありません。
単発で、頻度の低い CAPTCHA の場合:
- の PyPI パッケージは、Python 製の Amazon テキスト CAPTCHA ソルバーです。ただし最新リリースは 2023年5月なので、長期戦略ではなく戦術的ツールとして扱ってください
- では、Amazon Captcha の解決は 1,000件あたり 0.45ドルとされています
繰り返し CAPTCHA ループに入る場合:
- 解くのをやめて、間隔を空ける
- CAPTCHA が繰り返されるということは、そのセッションは焼かれているということです。解いても、フィンガープリント、セッション履歴、IP 評判の信頼は戻りません
- CAPTCHA がプロキシのサブネットごとに集中しているなら、問題はパーサーではなくネットワーク層です
いつ本当にヘッドレスブラウザが必要か、いつ過剰か
間違った発想は、何でも Playwright で回すことです。
ブラウザを使うべきケース:
- JavaScript レンダリングやロケール依存の状態に左右される検索結果
- ログインやサインインページへリダイレクトされるレビューの流れ
- Cookie やブラウザコンテキストの重要度が、速度より高いワークフロー
ブラウザを使わなくてよいケース:
- 普通の公開商品ページ
- ブラウザ風の HTTP クライアントで十分な、静的な商品詳細抽出
- 計算効率が重要な大規模一括取得
まずは、最も軽いクライアントで動くか試してください。大規模スクレイピングについての では、requests から始め、次に curl_cffi を使い、軽い方法が失敗したときだけフルブラウザに進む、という流れが紹介されています。ヘッドレスブラウザは、Amazon の商品ページをスクレイピングする用途では、HTTP クライアントよりかなり遅く、リソース消費も大きいです。
Amazon スクレイパー GitHub プロジェクト向けの BAN 回避判断マトリクス
| シナリオ | 推奨アプローチ | 理由 |
|---|---|---|
| 公開商品ページ（小規模） | curl_cffi + sticky な住宅用セッション | もっとも安価で、それでもブラウザらしく見える方法 |
| 検索結果ページ | まず curl_cffi、レンダリングや状態で HTTP が崩れる場合のみ Playwright | 検索は状態依存が強く、ロケールの影響も受けやすい |
| レビュー（ログイン必須） | 実Cookie / セッションを使ったブラウザモード | ログインと動的なレビューの流れは、素の HTTP では再現しにくい |
| 大規模（1日5,000件以上） | 管理型スクレイピング API、アンロッカー、またはノーコードツール | DIY の GitHub コードだけでは、インフラ問題になりやすい |
Amazon スクレイパーの GitHub プロジェクトが壊れたとき: ノーコードの代替手段を用意しておく
経験豊富なスクレイパーは、必ず Plan B を持っています。
Amazon の更新は、最悪のタイミングでどんな GitHub リポジトリも壊します。EC チームにとってスクレイパーが壊れることは、価格変更の取りこぼし、競合データの陳腐化、ダッシュボードの空白を意味します。
「amazon scraper github」で検索する人の多くは、実はビジネスユーザーです。EC 運用担当、マーケター、FBA リサーチャーなどで、他に良い選択肢が見つからず、やむを得ずコードに挑戦した人たちです。フォーラムのデータからも、Amazon 公式の に対する不満は明らかです。アクセス制限が厳しく、データが限られ、 を満たせない販売者も少なくありません。
GitHub の Amazon スクレイパーが継続的なメンテナンスを必要とする理由
上の監査結果が、それを具体的に示しています。
- 古いリポジトリには、修正のない breakage 報告が積み上がる
- 「動く」リポジトリでも、README で対ボット対策について率直に触れるようになっている
- コミュニティの話題は、CSS セレクターではなく、TLS フィンガープリント、CAPTCHA ループ、プロキシ品質へと移っている
ビジネスユーザーにとって、そのメンテナンス負担こそが本当の隠れコストです。リポジトリ自体は無料でも、午前2時にデバッグする時間は無料ではありません。
実用的な Amazon スクレイパーの代替としての Thunderbit
は、コードを書かずにタイトル、価格、ASIN、評価、ブランド、在庫、出荷元、元 URL を抽出できる を提供しています。
実際には、次のような違いがあります。
- Python 環境、依存関係、プロキシ設定を整える代わりに、2クリックでスクレイピング
- Amazon 向けのテンプレートを即利用 — AI の下準備は不要で、1クリック抽出だけ
- ログインが必要なページ（GitHub スクレイパーユーザーを悩ませるレビュー頁など）向けのブラウザスクレイピングモード
- 公開商品ページを高速に取得するクラウドスクレイピング（一度に50ページ）
- Google Sheets、Airtable、Notion、Excel への無料エクスポート — CSV/JSON だけではない
- 継続的な価格監視のためのスケジュールスクレイパー
- AI がレイアウト変更に適応 — メンテナンス負担はほぼ不要
GitHub の Amazon スクレイパー vs. Thunderbit: 正直な比較
| 要素 | GitHub スクレイパー（例: AmzPy） | Thunderbit |
|---|---|---|
| セットアップ時間 | 15〜60分（Python、依存関係、プロキシ） | 約2分（Chrome 拡張機能 を入れるだけ） |
| メンテナンス | 壊れたら自分で直す | AI がレイアウト変更に適応 |
| 対ボット対策 | 自前対応（プロキシ、ヘッダー、TLS） | 標準搭載（クラウド + ブラウザモード） |
| レビュー抽出（ログイン済み） | 複雑なセッション管理 | |
| データ出力 | CSV/JSON のみ | Sheets、Airtable、Notion、Excel、CSV、JSON |
| スケジューリング | 自前（cron、Airflow など） | 標準搭載のスケジュールスクレイパー |
| カスタマイズ性 | 高い | 低い |
| コスト | 無料（プロキシ費用は別） | 無料プランあり；クレジット制 |
率直に言うと、GitHub リポジトリはカスタマイズ性に優れ、Thunderbit は信頼性に優れています。可用性を柔軟性より重視するチームなら、ノーコードのほうがたいてい合理的です。
定期的・継続的な Amazon スクレイピングのベストプラクティス
多くの amazon scraper github プロジェクトは一回限りの実行を想定していますが、価格監視、在庫追跡、競合分析といった実際のビジネス用途では、定期的なスクレイピングが必要です。GitHub リポジトリにはスケジューリングが最初から入っていることはほとんどなく、ユーザーは cron、Airflow、n8n のワークフローをつなぎ合わせることになります。
GitHub の Amazon スクレイパーを DIY で定期実行する方法
最低限必要な反復実行の構成は次のとおりです。
- Linux または macOS 上の cron ジョブで、スクリプトをスケジュール実行する
- 後から失敗原因を追えるように、追記型ログを残す
- 既存データの重複保存を避けるため、ASIN + タイムスタンプで重複排除する
- 失敗に気づけるように、失敗通知を入れる（非ゼロ終了時の簡単なメールでも可）
より複雑なチームでは、次のような選択肢があります。
- 軽量なワークフロー自動化には n8n（コミュニティスレッドで頻繁に言及されます）
- より重い定期パイプラインには Airflow
- 差分と履歴が必要なら データベースで状態を持つ
重要なのはスケジューラ自体ではなく、状態管理です。最後に成功した実行、最後に取得した ASIN 集合、変化した価格、失敗した URL を追跡してください。
Thunderbit ならスケジューリングがもっと簡単に
Thunderbit の では、間隔を自然な日本語で記述し、URL を入力して「スケジュール」をクリックするだけです。AI が自然言語を cron スケジュールに変換してくれるので、技術的なセットアップは不要です。価格や競合商品の発売を監視する非エンジニアの EC チームにとって、運用負荷の削減はかなり大きいです。
継続的な Amazon スクレイピングのベストプラクティス
どのツールを使っても、次の点は共通です。
- ASIN + タイムスタンプの窓で重複排除する — 同じ商品を1回の実行で2回保存しない
- 価格は生文字列ではなく数値として保存する — 後処理が楽になります
- 各行にスクレイプ時刻を追加する — トレンド分析に必要です
- 現在値だけでなく差分を追う — 「先週より12%下がった」のほうが、「価格は24.99ドル」より有用です
- 意味のある変化だけ通知する — 競合が15%値下げしたら通知価値がありますが、0.5%の変動はノイズです
- データ保存方法を考える — 小規模ならフラットファイルで十分ですが、1日5,000件以上の ASIN ならデータベースやクラウド表計算を検討してください
出力品質の横並び比較: 各 Amazon スクレイパー GitHub アプローチは実際に何を返すか
誰も、amazon scraper github リポジトリ間で実際の出力品質を比較しません。ユーザーはデータ品質に非常に敏感です。「どのツールが最もきれいで完全なデータを返すのか」を知りたいのに、自分で各リポジトリをクローンして試すしかありません。このセクションでは、そのギャップを埋めます。
人気 GitHub リポジトリが実際に抽出するものと、取りこぼすもの
README のサンプル、公開例、文書化された出力形式をもとにすると、次のようになります。
| アプローチ | 明確に抽出できるもの | よくある欠落 / トレードオフ |
|---|---|---|
| amzpy | タイトル、価格、通貨、画像 URL、評価、レビュー、バリエーション、ASIN | 商品ページ寄り。レビュー全文や仕様セクションはやや弱い |
| tducret/amazon-scraper-python | タイトル、評価、レビュー数、商品 URL、画像 URL、ASIN を含む CSV | 古く、リスティング中心で、対ボット対策が弱い |
| python-scrapy-playbook scraper | 検索結果、商品ページ、レビュー、CSV/JSON パイプライン | チュートリアル級。外部プロキシミドルウェアに依存し、後処理が必要になりやすい |
| omkarcloud/amazon-scraper | 検索、カテゴリ、詳細、トップレビュー、多数の画像 / 動画 / 仕様 | 純粋なスクレイパーではなく、管理型 API サービスです |
| Thunderbit Amazon template | タイトル、価格、ASIN、ブランド、評価、レビュー、在庫、出荷元、サブページ補完 | カスタムスクリプトほどのコードレベル制御はない |
出力品質比較表
| データ項目 | AmzPy | Scrapy ベースのリポジトリ | Selenium リポジトリ | Thunderbit |
|---|---|---|---|---|
| 商品タイトル | ✅ | ✅ | ✅ | ✅ |
| 価格（数値） | ⚠️ 文字列 | ✅ | ⚠️ 文字列 | ✅（数値型） |
| 評価 | ✅ | ✅ | ✅ | ✅ |
| レビュー数 | ❌ | ✅ | ✅ | ✅ |
| ASIN | ✅ | ✅ | ✅ | ✅ |
| 商品画像 | ❌ | ⚠️ サムネイルのみ | ✅ | ✅（高解像度、エクスポート可） |
| 原材料 / 仕様 | ❌ | ❌ | ❌ | ✅（サブページスクレイピング + AI 経由） |
| Sheets/Airtable へのエクスポート | ❌ | ❌ | ❌ | ✅ 無料 |
ビジネスユーザーにとってデータ形式が重要な理由
雑なデータは、見えない労力を生みます。たとえスクレイパーが動いても、次のようなら運用上の失敗です。
- 価格が通貨記号付きの文字列で、きれいな数値ではない
- 欠損値の表現が統一されていない（空文字、null、"N/A" が混在）
- 画像が低解像度のサムネイルしかない
- 分析前にレビュー項目や仕様を後処理する必要がある
EC 運用チームにとって、きれいなデータは分析速度と意思決定に直接効きます。Thunderbit の AI は、数値は数値、日付は日付、URL は URL として型に合わせて整形するため、そのまますぐ使えます。GitHub リポジトリはこの点にかなり差があり、後片付けの時間はすぐに膨らみます。
すぐ使える参考: Amazon スクレイパー GitHub ベストプラクティス チェックリスト
- クローン前に最終コミット日を確認する。6か月以上前なら Amazon では強い警告サイン。
- セットアップ前に issue で「captcha」「503」「blocked」「not working」を検索する。
- 素の
requestsより、curl_cffiなどのブラウザ偽装 HTTP クライアントを優先する。 - ヘッダー、TLS プロファイル、言語、プロキシの地理情報を一致させる。矛盾は禁物。
- ブラウジングの流れではsticky セッションを使い、毎回盲目的に切り替えない。
- ランダムな間隔と指数バックオフを入れる。
- 繰り返し出る CAPTCHA は、解くパズルではなく、焼けたセッションとみなす。
- ヘッドレスブラウザは、HTTP クライアントで再現できない場合だけ使う。
- 失敗した実行を安全に再開できるよう、チェックポイントと状態を保存する。
- 代替手段を用意する。管理型 API でも、 のようなノーコードツールでもかまいません。
2026年の Amazon スクレイピングにおける法務・倫理面の注意点
短く、知っておくべきことだけ。
Amazon の姿勢は制限的で、今後さらに厳しくなる可能性があります。強いシグナルは次のとおりです。
- Amazon 自身のヘルプページは現在、 を返し、「Amazon データへの自動アクセスについては api-services-support@amazon.com へ संपर्कしてください」と案内しています。
- Amazon の は、動的ページ、レビュー、プロフィール、ほしい物リスト、出品一覧の多くのパスを許可していません。
- Amazon は で、秘密裏または偽装されたエージェントアクセス、セキュリティ対策の回避、エージェントを Google Chrome と誤認させることに明確に異議を唱えました。Amazon はこの件について も出しています。
- Amazon は 2025年後半に、OpenAI のクローラーに対して しました。
公開商品ページから、認証が必要なフロー、偽装された自動化、高ボリュームの商用抽出へ進むほど、実務上のリスクは明らかに高くなります。これは法的助言ではありません。具体的な状況については、必ず自社の法務チームに相談してください。
要点: BAN されずに信頼できる Amazon データを取るには
重要度順にまとめます。
- クローン前に監査する。 GitHub の検索結果の多くは、古い、チュートリアル、または商用 API のラッパーだと考えておく。
- まずネットワーク層を強化する。 TLS フィンガープリントとセッションの一貫性は、HTML セレクターより重要です。
- ランダムなプロキシの混乱ではなく、sticky な住宅用セッションを使う。 セッション内で回すのではなく、セッション間でローテーションする。
- ユーザーのようにペース配分する。 ストレステストのような速度は禁物で、ランダムな遅延と指数バックオフは必須です。
- 単発 CAPTCHA は解く、繰り返し挑戦されるセッションは捨てる。 焼けたフィンガープリントを力技で突破しようとしない。
- 代替手段を持つ。 Amazon は週の途中で何かを変えます。GitHub のスクレイパーは壊れます。 のような保守済みノーコードツールや管理型 API があれば、デバッグ中もデータパイプラインを止めずに済みます。
- 出力品質を優先する。 速いけれど雑なスクレイパーより、きれいで型の整ったデータのほうが、下流の時間を大きく節約できます。
カスタマイズ性より信頼性を重視するなら、Thunderbit は保守された代替手段を提供します。 を確認するか、 のチュートリアルをご覧ください。完全な制御を求める開発者は、もちろん GitHub リポジトリを使えます。ただし、このガイドで説明した BAN 回避とメンテナンスの実践は、必ず併用してください。
FAQ
GitHub のスクレイパーで Amazon の商品データを取得するのは合法ですか？
Amazon の利用規約は自動データ収集を制限しており、Amazon は差し止め通知や技術的対抗策を通じて実際にこれを執行しています（特に 2025〜2026年）。公開されている商品データのスクレイピングはグレーゾーンですが、ログイン後の情報を取ることや、ボットを本物のブラウザに偽装することはリスクが高くなります。これは法的助言ではありません。具体的な用途については法務チームに相談してください。
Amazon のスクレイパー GitHub リポジトリは、どのくらいの頻度で壊れますか？
かなり頻繁です。Amazon はページレイアウトを変え、新しい対ボット層を追加し、エンドポイントを定期的に廃止します。この記事の監査では、広く見つかった8件のうち、2026年に明らかに機能していたのは約3件だけでした。「動く」とされるリポジトリでも、CAPTCHA や 503 エラーに関する issue が残っていることは珍しくありません。数週間から数か月ごとに、セットアップの修正や更新が必要になると考えてください。
2026年に GitHub で最良の Amazon スクレイパーは何ですか？
唯一の勝者はありません。用途と技術的な慣れ次第です。軽量な直接型の Python スクレイパーなら、 は比較的新しい選択肢のひとつです。管理型 API を通じてより広い対応範囲を求めるなら、 は使えますが、完全な DIY ではありません。どのリポジトリでも、コミットする前にこの記事の鮮度チェックリストで自分で評価してください。
Thunderbit はコードなしで Amazon をスクレイピングできますか？
はい。Thunderbit の は、商品タイトル、価格、ASIN、評価、ブランド、在庫などをワンクリックで抽出します。ログイン必須ページ向けのブラウザスクレイピングモード、公開ページ向けの高速クラウドスクレイピング、定期ジョブ向けのスケジュールスクレイピング、Google Sheets、Airtable、Notion、Excel への無料エクスポートに対応しています。 をインストールすれば始められます。
Amazon をスクレイピングするときに IP を BAN されないようにするには？
多層的な対策を使ってください。(1) 素の requests から curl_cffi のような TLS 偽装クライアントへ切り替える、(2) ランダムなデータセンター切り替えではなく sticky セッション付きの住宅用プロキシを使う、(3) ランダムなペース配分と指数バックオフを加える、(4) ヘッダー一式をブラウザプロファイルとマーケットプレイスのロケールに一致させる、(5) 繰り返し出る CAPTCHA は、永遠に解くパズルではなく、セッション終了のサインとして扱う。詳細は、この記事前半の BAN 回避判断マトリクスを参照してください。