Google Shopping の検索結果ページには、オーガニック一覧の途中に広告枠が混ざったり、在庫切れ商品では価格が消えたり、同じ商品が複数の販売者で重複して表示されたりすることがあります。ここ数週間、私は「この複雑な構造をきれいで使えるデータに変換できる」とうたう 9 つのツールを実際に深掘りして検証してきました。率直に言うと、「これが最強」と言い切れるものは一つではありません。開発者がパイプラインを組むのか、それとも金曜までにスプレッドシートへ数字を入れたいマーケターなのかで、最適解はまったく変わります。
調査を進めると、その違いはあちこちに表れていました。r/learnpython や r/node では、Puppeteer、Playwright、プロキシローテーションについて知見が飛び交っています。一方で r/PPC では、「コードには触りたくないから、とにかくデータだけほしい」という声が目立ちます。そこで今回は、9 ツールをアルファベット順に並べたり、派手なサイトを持つベンダーに安易に「総合ベスト」を与えたりはしませんでした。6 つの具体的な評価軸で採点し、ワークフロー別に並べています。順番は、まずマネージド SERP API、その次にプロキシ＋スクレイパー基盤、続いて開発者向け actor プラットフォーム、最後にノーコードのブラウザツールです。
「最強」の Google Shopping Scraper とは？評価基準
多くの比較記事で「最強」は便利な言葉として使われがちですが、この比較ではその意味をはっきりさせます。各ベンダーの宣伝文句をなぞるのではなく、9 ツールを同じ 6 項目で評価しました。
- データの網羅性 — 価格、販売者、評価、レビュー数、送料、そして広告枠とオーガニック枠を本当に区別できるか。
- ロケール／地域対応 — 国、言語、デバイスを狙いどおりに指定できるか。それともプロキシの IP がたまたま解釈される結果に左右されるのか。
- 導入の難易度 — API キーを付けた GET リクエストで済むのか、キュー処理とコールバックが必要なのか、トークンをつなぐ 2 段階フローなのか、それともクリック操作だけで使えるのか。
- 保守負荷 — Google が HTML 構造を変えたり CAPTCHA を出したりしたとき、対応するのは自分なのかベンダーなのか。
- 出力／連携経路 — JSON を吐き出すだけか、Sheets、Airtable、データウェアハウスへ直接流し込めるか。
- 価格の透明性 — 単価が明示されていて計算できるのか、それとも「営業にお問い合わせ」でないと費用がわからないのか。
ここで私がやらないのは、成功率、速度ベンチマーク、精度率を捏造することです。この一覧のどのベンダーも、互いに独立した比較テストをしていませんし、「成功率 99.9%」や「超高速」といった主張は測定値ではなく宣伝文です。代わりにお見せするのは、各ベンダーの公式ドキュメントで実際に確認できる内容です。これで十分、判断材料になります。
開発者はコードを求め、マーケターはノーコードを求める
スクレイピング周辺のフォーラムを見たことがあるなら、この分かれ目はもう知っているはずです。ただ、順番の理由を理解するうえで重要なので、あえて言語化しておきます。データパイプラインを作る開発者は、API キー、予測可能な JSON、明示的なロケール指定、そして下流で検証・正規化しやすいスキーマを求めます。彼らが気にするのは、プロキシローテーションやヘッドレスブラウザ描画です。
一方で、マーケティング担当や PPC 担当が求めるのは、「ページを指定したらスプレッドシートが返ってくる」ような体験です。Google が今四半期 3 回目の Shopping レイアウト変更をしたたびに Puppeteer スクリプトを保守したいわけではありません（実際、Google は Shopping のマークアップを頻繁に変えるため、API ベンダー側が変更履歴を公開するほどです）。
そのため、この一覧はマネージド SERP API ベンダー（SerpApi、Serper、SearchAPI、DataForSEO）から始めます。これらは構造化 JSON を返し、プロキシ設定は不要ですが、コードは必要です。次に、より自由度はあるものの設定量も増えるプロキシ＋スクレイパー基盤（Bright Data、Oxylabs）へ進み、その後、自由に組み立てられる開発者向け actor プラットフォーム（Apify）、最後に、スクレイピングコードを本当に書きたくない人向けのノーコード・エージェント型ブラウザツール Thunderbit で締めます。
ひと目でわかる 9 つの Google Shopping Scraper
| ツール | 収集モデル | 導入の難易度 | ロケール対応 | 最適な利用者 | 保守負荷 |
|---|---|---|---|---|---|
| SerpApi | マネージド Shopping API | 低（API キー） | 強い（location、gl、hl、device） | データエンジニア、SEO ツール | ベンダー管理 |
| Serper | 汎用 SERP API、Shopping は結果タイプの一つ | 低 | 中程度（国／言語は明示あり） | コスト重視の開発者 | ベンダー管理 |
| SearchAPI | マネージド Shopping + Product Offers API | 低〜中（offers は 2 段階） | 中程度 | オファー／販売者比較チーム | ベンダー管理 |
| DataForSEO | タスクベースの Merchant API | 中（キュー／コールバック） | 強い | 大量処理・定期実行パイプライン | ベンダー管理 |
| Bright Data | データセット + Scraper API + SERP API | 中（対象機能による） | 非常に強い | エンタープライズのデータチーム | 共有 |
| Oxylabs | 2 段階の検索＋商品詳細 API | 中（トークン連携） | 非常に強い | エンタープライズのデータチーム | 共有 |
| Scrapingdog | 専用 Shopping エンドポイント | 低〜中 | 中程度 | 予算重視の開発者 | ベンダー管理 |
| Apify | Actor／開発者向けプラットフォーム | 中〜高 | Actor に依存 | カスタムパイプライン構築者 | ユーザー管理 |
| Thunderbit | エージェント型ノーコード・ブラウザ抽出 | 非常に低い（1 クリック抽出） | 対象ページに依存 | マーケター／PPC 担当、非開発者 | 低、ページ依存 |
(価格、クレジット上限、ロケール対応範囲は、導入前に必ず各ベンダーの最新ドキュメントで確認してください。変更が速く、2026 年にはすでにいくつかのベンダーが破壊的変更を出しています。)
1. SerpApi — 機能豊富で、キャッシュ挙動を明示している
SerpApi は専用の Google Shopping エンジン（engine=google_shopping）を提供しており、クエリを送ると構造化された shopping_results を返します。含まれるのは、順位、タイトル、商品 ID、価格と抽出後の数値価格、旧価格／分割払い価格、配送、コンディション、評価、レビュー、画像です。かなり強力なスキーマです。さらに SerpApi は Google Ads Shopping スキーマを別途用意しており、広告枠も把握できます。ただし、専用 Shopping レスポンス内に sponsored: true/false のような単一フラグが最初から入るわけではありません。
SerpApi の強みは、あとで困りやすい部分を最初から明確に説明している点です。地域指定は、都市レベルの location もしくは厳密な uule、さらに gl（国）、hl（言語）、device（desktop、tablet、mobile）を個別に指定できます。加えて、同じクエリはデフォルトで最大 1 時間キャッシュされること、キャッシュヒットは無料で、no_cache=true にすると新規取得になることも明記しています。こうした情報をきちんと開示するベンダーは意外と多くありません。
価格は公開されており、月額制です（2026-08-13 時点）。Free tier は 250 検索、Starter は 1,000 件で $25、Big Data は 30,000 件で $275 です。課金対象になるのは成功した検索のみで、キャッシュ済みや失敗リクエストはクォータに含まれません。なお、Google は 2026 年初頭に SerpApi のデータ取得手法をめぐって提訴しました。SerpApi 側はその解釈に異議を唱え、公開された非認証の結果にアクセスしていると説明しています。これは確定判決ではないため、避けるべき理由というより、リスク要因として注視すべき事案です。
向いている人: 最も豊富な Shopping スキーマと、キャッシュ・ロケール制御の明示性を重視する開発者。
2. Serper — 高速で低コスト、鮮度の主張が最も明快
Serper は、Google の一般的な SERP API として位置づけられており、Shopping は Search、Images、News、Maps など複数の結果タイプの一つとして扱われます。すでに通常の検索結果を取得していて、そこへ Shopping データを追加したいなら、別の専用ベンダーを立ち上げるよりも導入摩擦が少ない選択肢です。
公開されている Shopping の例では、title、source、直接の販売者リンク、整形済み価格、配送、評価、評価数、オファー数、商品 ID、順位が返ります。基本的な商品カードの監視には十分ですが、公開ドキュメントでは SearchAPI や Oxylabs のような販売者オファーの深い情報や、プロモーション価格のフィールドまでは示されていません。Serper の最大の売りは鮮度の約束です。各呼び出しは Google に対してライブで問い合わせを行い、キャッシュしないと明言しています。これにより、SerpApi のようにキャッシュを使うかどうかの判断は不要になりますが、同じクエリを繰り返すたびにその都度課金されます。
価格体系はサブスクリプションではなく、前払いクレジット制です。最初に 2,500 クエリ分の無料枠があり、その後は $50 で 50,000 クレジット、上位になるほど 1,000 件あたり $0.30 まで下がります。クレジットの有効期限は 6 か月です。価格ページには、リクエストを Google に再試行する必要があるときは個別のリクエストに 2〜4 秒かかることもあると、かなり率直に書かれています。これはベンチマークではなく、実運用で想定すべき遅延の尾です。
向いている人: より広い SERP API に既に統合しており、Shopping は追加機能として欲しいチーム。
3. SearchAPI — オファー単位の情報は強いが、仕様の注意点あり
SearchAPI は、販売者ごとの価格比較が必要な場合に非常に役立つ 2 段階フローを採用しています。Shopping エンドポイントは一般的なカード項目に加えて product_token を返し、そのトークンを使うと別の Product Offers API が呼べます。そこでは offers 配列として、販売者リンク、価格、送料、合計価格、在庫状況、支払い方法が販売者別に返ってきます。ユースケースが「この商品が各販売者でいくらで売られているかを全部見たい」なら、この一覧ではかなり短いルートです。
ただし、注意点があります。2026 年 5 月 15 日の Google 側変更により、SearchAPI はリクエストごとに新しい product_token を要求するようになりました。以前の product_id や prds パラメータは、今では単純な 400 エラーになります。古いコード例やチュートリアルを参考に実装すると、気づくまで静かに壊れます。
また SearchAPI は、クエリ内の自然言語フィルター（たとえば「30 ドル以下」「中古」）はあくまでヒントであり、厳密な絞り込みではないと明示しています。対象が少ないと、Google は条件外の結果も返すことがあります。厳密に絞るなら、エンコードされた shoprs フィルターを使う必要があります。さらに、ドキュメント上の矛盾も見逃せません。SearchAPI はこのエンドポイントを「リアルタイム」と宣伝していますが、データ処理契約にはパフォーマンス向上のため結果をキャッシュすると書かれています。TTL の公表はどちらにもなく、鮮度が重要なら、パイプライン化する前に同じクエリを繰り返して確認すべきです。
価格は 2026-08-13 時点で、Developer tier が月額 $40、1,000 検索あたり $4 から始まり、大量利用で単価が下がります。文書上の上限として、月間クレジットの 20% までを 1 時間あたりに使えるという制限があります。
向いている人: 2 リクエストのフローや鮮度テストを許容できる、販売者／オファー単位の比較業務を行うチーム。
4. DataForSEO — キュー処理で、大量の Merchant / Shopping データを扱う
DataForSEO は、このグループではかなり異色です。理由は、ライブの request/response API ではなく、タスクベースのキューだからです。キーワード、地域、言語を指定してタスクを POST すると、タスク ID が返り、結果をポーリングするか、コールバック URL を設定します。一般的なマーケティング文ではどう表現されていても、Shopping の主要エンドポイントにはライブモードはありません。
これは導入難易度の考え方を変えます。「API を呼べば JSON が返る」という感覚ではなく、タスク状態を管理する必要があるからです。DataForSEO のドキュメントによると、コールバックサーバーが 10 秒以内に応答しない場合、タスクは「Tasks Ready」キューへ移り、手動でポーリングする必要があります。
このツールがリストに入る理由は、大量調査に強いからです。Products エンドポイントは、順位、ドメイン、タイトル、価格、旧価格、評価、投票数を返し、google_shopping_sponsored_carousel、google_shopping_paid、オーガニック結果を区別する明示的な結果タイプ識別子もあります。この一覧全体の中でも、広告枠とオーガニック枠の区別がかなり明確です。また、product_id は動的で null になることがあること、ユーザー履歴や位置情報の好みといった個人化要因は意図的に結果から除外されることも明示しており、こうした正直な注記は他社では省略されがちです。
料金は結果ブロック単位で請求されます（Products は 40 件、Sellers／Reviews は 10 件）。通常キューは最大 45 分、優先キューは価格が 2 倍になる代わりに最大 1 分です。新規アカウントには、有効期限なしの $1 トライアルクレジットが付与されます。
向いている人: キュー型のタスクベース運用に慣れていて、定期的に大量の merchant/product データが必要なチーム。
5. Bright Data — 1 つの名前で 3 つの製品を提供している
ここは少し整理して話す必要があります。Bright Data は、Google Shopping データを取得する方法を 3 通り提供しており、それぞれ挙動がまったく異なります。ひとつは事前収集済みデータセット（74 億件超のレコードをうたい、JSON/CSV/Parquet でクラウドウェアハウスへスケジュール配信）。次に、同期または非同期ジョブで動く専用 Shopping スクレイパー ID を持つ Google Scraper API。そして、ライブの Shopping URL を取得して結果をリアルタイム解析する SERP API です。これらを 1 つの製品として扱う比較記事は多いですが、ここでは分けて考えます。
データセットのサンプルを見ると、いくつかのレコードで product ID、description、rating、reviews count が null になっています。つまり、「構造化データセット」だからといって「すべての項目が常に埋まっている」わけではない、という一次情報がはっきり示されています。SERP API では、Product Listing Ads を top_pla、bottom_pla、jackpot_pla といった別の結果タイプとして扱っており、SERP API を使う場合に限れば、広告枠とオーガニック枠の区別として実用性があります。データセットにはこの粒度はありません。
Scraper API の非同期ジョブでは、バッチ全体が「success」でも、内部の個別入力が失敗することがあります。ドキュメントでは errors フィールドを確認し、失敗したものだけ個別に再試行するよう明示しています。大規模バッチを運用するなら、これを前提に設計する必要があります。
価格は 2026-08-13 時点で提供面によってかなり異なります。データセットは 100,000 件の一括レコードで $250、SERP API は月 5,000 リクエスト無料で従量課金が 1,000 件あたり $1.50、専用 Shopping Scraper API にはまた別の無料枠と料金があります。数値は互換ではないので、実際に使う製品ページを必ず確認してください。
向いている人: 事前収集データとライブ API の両方をひとつのプラットフォームで扱いたいエンタープライズチーム。面ごとに個別価格を確認できることが前提です。
6. Oxylabs — 検索結果から商品詳細までの 2 段階連携が最も明確
Oxylabs は Shopping を 2 つの専用ターゲットに分けています。リストレベルの結果を返す google_shopping_search と、商品ごとの詳細データを返す google_shopping_product です。両者は product token でつながります。検索レスポンスでは pla（有料 listing ads）と organic 商品がきれいに分かれており、この一覧の中でもおそらく最も明快な広告／オーガニックの区別です。商品エンドポイントでは、販売者ごとのオファーに加えて、数値価格、コンディション、税、合計価格、送料が返ります。
ただし、ここにも重要な条件があります。この token フローは、検索リクエストで render: "html" と parse: true の両方を指定した場合にのみ機能します。どちらか一方でも欠けると product token が取れず、商品詳細のステップ全体が成立しません。また Oxylabs は、検索リクエストと商品リクエストで完全に同じローカライズ値を使わなければならないと明示しています。2 回の呼び出しで geo_location がずれると、商品結果が不完全または誤ったものになることがあります。さらに、追加の販売者候補を開く「More stores」パネルを展開したい場合は、それにもレンダリングを有効にする必要があり、コストが増えます。
見落としやすい点として、Oxylabs の料金 FAQ では「成功した」リクエストは 2xx だけでなく 4xx も含むと定義されています。つまり、自分のリクエストが不正でも課金される可能性があります。
商品レビューは US ロケール限定で、ロケール／言語とロケール／結果言語は実際には別の制御です。片方を設定しても、もう片方は自動では変わりません。
向いている人: ランキングレベルのデータと販売者別のオファー詳細の両方が必要で、トークン連携とロケールの一貫性を設定の一部として扱える技術チーム。
7. Scrapingdog — シンプルだが、公開情報は薄め
Scrapingdog は、API キーとクエリを受け取る専用の Google Shopping エンドポイントを 1 つ提供しています。返ってくる JSON には、title、価格と抽出後の数値価格、旧価格、評価、レビュー、source／seller、配送、順位が含まれます。価格、ブランド、国、言語でのフィルタリングも用意されており、広告枠追跡用に別の「ads」レスポンスカテゴリもあります。ただし、広告スキーマの正確な構造やロケールフィルターの正確なパラメータ名は公開ページで完全には説明されていません。自動化に組み込む前に、自分の用途で実際に試す時間を見込んでください。
この一覧の中で、公開ドキュメントだけではクレジット消費の計算が成立しないのは Scrapingdog です。料金ページには LITE（$40/月で 200,000 クレジット）、STANDARD（$90/月で 1,000,000 クレジット）といった月間クレジット枠はありますが、Google Shopping の 1 リクエストが何クレジットかは明確に書かれていません。一般的な検索 API の例と 1 対 1 だと思い込まないでください。実際の単価はベンダーに直接確認するのが安全です。
他の多くのベンダーと同様に、Scrapingdog は 回転住宅プロキシ と自動 CAPTCHA 処理をベンダー側で管理すると案内しています。ただし、これは保守責任の境界を示すものであって、常時アクセス保証の証明ではありません。
向いている人: 予算重視の開発者で、用途が限定された専用エンドポイントを求め、導入前にクレジット費用を自分で確認できる人。
8. Apify — マーケットプレイス全体ではなく、Actor 単位で判断する
最初に正直に言っておきます。Apify は 1 つの Google Shopping Scraper ではありません。独立して管理される「Actor」のマーケットプレイスです。今回詳しく見たのは、開発者 epctex が公開し「Community 管理」とされている Google Shopping Insights で、上のベンダー管理ツールとはかなり挙動が違います。Apify はランタイム、プロキシ基盤、データセット／エクスポート機能を提供しますが、実際の Shopping 抽出ロジックと保守は Apify ではなく epctex の責任です。
この違いは重要です。なぜなら、この Actor の公式サンプル出力ではprice フィールドが null になっているからです。「時々」でも「在庫切れだけ」でもありません。公開サンプルそのものが、product name、merchant、rating は埋まっているのに、price: null と withoutDiscountPrice: null を示しています。価格データを完全と仮定できないことを、ツール自身のドキュメントが最もはっきり示している例です。
設定可能な入力としては、includeSponsoredResults、販売者横断価格比較のための includeComparisonPrices、国コード指定、maxItemsPerQuery などがあります。プロキシ設定は必須で、自分のものか Apify のものを使います。結果は Apify の Dataset システム経由で JSON、XML、CSV、Excel にエクスポートできます。私が確認した Store の掲載情報では、総ユーザー数は約 2,300 でしたが、当時の月間アクティブユーザーは 2 でした。「コミュニティ管理」は柔軟ですが、実際に誰が使い、誰が問題報告しているかに依存するという意味でもあります。
向いている人: 特定 Actor の保守状況と実際の出力スキーマを見てから導入判断したい開発者。Apify というブランドが一貫した挙動を保証してくれると期待する人には向きません。
9. Thunderbit — マーケター向けのノーコード収集
Thunderbit はこの一覧のもう一方の極にあります。見えているページをそのまま確認し、構造化テーブルへ変換したい人向けの、ブラウザベース・ノーコードのワークフローです。Google Shopping API を統合するのではなく、画面上の内容をそのまま扱います。これは、マーケター、PPC 担当、小規模 EC チームなど、都度の確認作業が中心で、大量のバックエンドパイプラインが不要な人に自然に合います。
できることはブラウザ側の抽出です。必要な Shopping 結果ページを開き、Thunderbit にレンダリング済みページを 1 クリックで読み取らせ、フィールドを Excel、Google Sheets、Airtable、Notion に直接書き出します。ただし、Shopping 自体に由来する重要な注意点があります。抽出は目の前のページに対して行われるため、その結果はブラウザのロケーション、言語、セッションを引き継ぎます。今週の取得結果を先週のものと比較するなら、その設定を固定しておく必要があります。これは次のセクションで説明するフィールド信頼性の問題であり、この一覧のすべての選択肢に当てはまります。
向いている人: 開発者が管理する JSON パイプラインより、目に見えるブラウザ抽出を重視する非技術チーム。しかも、高頻度・多地域のクローリングではなく、必要な Shopping ページを都度取得する使い方をする人。
実際にどのデータを信頼できるのか？フィールド信頼性の問題
ここは、多くの Google Shopping 比較記事が完全に省略している部分であり、自動化する前にいちばん理解しておくべき点です。すべての項目がすべての掲載に出るわけではありませんし、「欠損」を「0」と扱うと、データは静かに壊れます。
| 項目 | 信頼性 | 注意点 |
|---|---|---|
| タイトル | 高い | 形式違いやバンドル品は、ソース間で照合する前に正規化する |
| 商品 ID | 条件付き | DataForSEO はこれを動的で、時には null になると明記している |
| 価格 | 条件付き | Apify の公式サンプルでは、完全に埋まったレコードでも価格が null |
| 販売者／merchant | 通常は存在 | 複数販売者の一覧では、1 商品に複数の個別オファーがある |
| 評価／レビュー数 | 条件付き | 新商品や未評価商品では単に出ないことがある。0 に丸めないこと |
| 送料／配送 | 一貫しない | 配送先、在庫、セッションによって変わる |
| 広告フラグ | ツール依存 | Oxylabs は pla と organic をきれいに分けるが、他ツールの多くは広告を含める／除外する設定はあっても、行ごとの信頼できるラベルは返さない |
実務上のルールはシンプルです。どんなワークフローも自動化する前に、自分の実際のキーワードでサンプルを取得し、何が null、重複、欠損になっているのかを確認してください。ドキュメントが「ここにあるはず」と示しているものではなく、実際に何が返るかを見るべきです。
公式の Google Merchant Center と Google Shopping Scraper、どちらが必要？
EC チームがベンダー比較を始める前によく聞く質問です。答えははっきりしています。自社の商品掲載、価格設定、Shopping 広告を管理するなら、それは Google 公式の Merchant Center ツールの仕事であり、第三者スクレイパーの仕事ではありません。この一覧のスクレイピングツールは、競合価格、市場での露出、カテゴリ調査、広告枠の監視など、他社の掲載を観察するためのものです。ここを混同しないでください。Google の一次資料は名称や構成が定期的に変わるので、最新の公式ドキュメントで現在の API 名と適用範囲を直接確認してください。
これらのツールは Google の対ボット対策をどう扱うのか
ここは「Google をどう突破するか」ではなく、ガバナンスの問題として捉えるのが正直です。SerpApi、SearchAPI、Bright Data、Oxylabs、Scrapingdog など、いくつかのベンダーはプロキシローテーション、ブラウザレンダリング、CAPTCHA 対応 を自社で管理すると公表しています。これは本当に価値のある保守境界です。深夜 2 時にブロックされた IP を自分で調査しなくて済むからです。ただし、それは永続的・万能なアクセスを保証するものではありませんし、そう読んではいけません。
完全にマネージドなベンダーを使っても消えないものがあります。レート／支出の制御、エラー分類、リトライ、そして Google 側の変更監視です。SearchAPI と Oxylabs の更新履歴を見る限り、Google の仕様変更はかなり定期的に起きています。Bright Data はバッチ内の部分失敗を明示し、DataForSEO はコールバックのタイムアウト挙動を明記し、Oxylabs は無効トークンの失敗を文書化しています。これは何かを回避する方法ではなく、どの失敗モードを誰が責任を持つのかを正直に整理したものです。
チームに最適な Google Shopping Scraper の選び方
次の順で考えると整理しやすいです。
- 自分の立場を明確にする。 パイプラインを作る開発者なのか、コードに触れずに結果だけ欲しいマーケター／運用担当なのか。
- 本当に必要な項目を決める。 ランキングレベルのデータと、販売者／オファー単位の価格詳細は別物です。後者が必要なら SearchAPI と Oxylabs が候補になります。
- 保守できる範囲を正直に見積もる。 API のマッピングとエラーハンドリング、Actor の設定とプロキシ構成、あるいはページを見ながらの抽出。チームが長期的に持てるものを選んでください。
- 実際のクエリでロケール／デバイス挙動をテストする。 公開ドキュメントと実際の挙動は必ずしも完全一致しません。
- 出力先が既存スタックに合うか確認する。 JSON をデータウェアハウスへ流すのと、マーケターが直接開けるスプレッドシートにするのとでは、工数がかなり違います。
結論: どの Google Shopping Scraper を使うべきか？
ここに万能の「最強」はありません。もしそう書いてある記事があれば、慎重に読んでください。データパイプラインを作る開発者で、最も豊富なスキーマと明示的なキャッシュ／ロケール制御を求めるなら、まずは SerpApi から始めるとよいでしょう。販売者ごとのオファー価格比較が目的なら、SearchAPI か Oxylabs のトークン連携フローの方が直接的です。大量の定期調査を行い、キュー処理を許容できるなら DataForSEO はスケールしやすいです。ひとつのエンタープライズ基盤で、事前収集データとライブクエリの両方を扱いたいなら Bright Data が最も広くカバーします。ただし、面ごとに個別で価格を確認してください。
そして、PPC やマーケティングチームで、API キーを触りたくないなら、Thunderbit のようなブラウザベースのカテゴリが、「コードを書くプロジェクトではなく、データだけ欲しい」という要望への最短回答です。ただし、どの面を選んでいるのかは明確にしてください。ブラウザワークフローは、自分で開いて確認するページ向けに作られています。一方で Thunderbit の API ドキュメント と CLI は別の、開発者向けの経路です。自分たちの実際の働き方に合うものを選んでください。
どれを選ぶにせよ、まずは実データでサンプルを取りましょう。この一覧のどのベンダーも、少なくとも 1 つは「常に存在するわけではない」項目を明記しています。何かを構築する前に、自分の用途で確認してください。
FAQ
Google Shopping データをスクレイピングするのは合法ですか？ これは一概には答えられませんし、比較記事が断定するべきでもありません。公開されているデータやベンダーのコンプライアンス主張が、すべてのユースケースを自動的に合法にするわけではありません。何かを作る前に、Google の最新利用規約、管轄地域の適用法、そして収集方法が許可されているかを確認してください。これはブログで決着をつける話ではなく、「自分の法務に確認する」案件です。
SERP API と Google Shopping Scraper の違いは何ですか？ SERP API や Shopping API は、構造化されたリクエストパラメータを受け取り、解析済みの JSON を返します。取得基盤の多くはベンダー側が管理します。Thunderbit のようなブラウザベースのスクレイパーは、実際に開いているページから抽出します。Bright Data の一部のようなデータセット製品は、ライブリクエストではなく、スケジュールに沿って事前収集済みレコードを届けます。目的は似ていますが、鮮度、ロケール制御、保守負荷はかなり異なります。
Google Shopping をスクレイピングするのにプログラミングは必要ですか？ 必ずしも必要ではありません。Thunderbit の売りはまさにそこにある、ノーコードのクリック型ワークフローです。Apify も Web UI だけである程度は使えますが、十分なカスタマイズを引き出すには多少の技術的理解があると有利です。この一覧にある API ベースのツール、つまり SerpApi、Serper、SearchAPI、DataForSEO、Bright Data、Oxylabs、Scrapingdog は、少なくとも認証、パラメータ処理、エラーチェックといった基本的な開発スキルを必要とします。
Google Shopping のデータはどのくらいの頻度で変わりますか？ 多くの人が思うより頻繁に変わりますが、「何時間ごとに更新される」といった普遍的なルールはありません。価格、在庫、広告枠、順位はセッション、地域、時間帯によって変動します。ここに挙げたベンダーの多くがライブ／リアルタイムモードを提供しているのは、キャッシュデータがこの分野ではすぐ古くなるからです。意思決定が現在の価格に依存するなら、昨日の結果を信用するのではなく、もう一度クエリを実行してください。
さらに詳しく
