数か月前、Stack Overflow である開発者が、2012年から未解決のまま残っている質問を投稿していました: "Google Places API の Place Details はレビューを5件までしか取得できないのか？" 14年が経ち、何百もの高評価がついても、答えは今も同じです。——はい、最大5件です。この1つの制限だけでも、この議論がなぜ続いているのかがよく分かります。
Google Places のデータを大規模に扱う必要があるなら、リード一覧、競合レビュー、来店傾向、ローカルSEO監査など、誰もが同じ分岐点にぶつかるはずです。公式の Google Places API は整然としていて、構造化されており、ドキュメントも充実しています。ただし、Google Maps のページ上で見えている情報をすべて返すわけではありませんし、無料枠を超えてスケールすると請求額が一気に跳ね上がることもあります。一方、スクレイピングはより多くの情報を取得でき、費用の考え方も異なりますが、CAPTCHA、壊れたセレクタ、法的なグレーゾーンといった悩みもつきものです。私は API ドキュメント、料金 SKU、スクレイピングのツール群、そして実運用でのトレードオフまで、かなり深く掘り下げてきました。この記事はその集大成です。項目ごとのデータ差分、10K/100K/1M件での本当のコスト、対ボット対策の現実、そして実践的なハイブリッド運用まで解説します。最後に判断フローチャートも付けました。3,000語読んだのに、結局どれを選べばいいか分からない、なんてことは避けたいですからね。
Google Places API とは何か？ そして実際に何が取得できるのか？
Google Places API は、Google が公式に提供する構造化データ取得の方法です。企業名、住所、電話番号、評価、レビュー、写真など、ビジネス情報を Google のデータベースから取り出せます。HTTP リクエストを送ると、整形された JSON が返ってきます。これは Google 公認の経路です。
現在のバージョンである Places API "New" は、すべてを field mask を中心に整理しています。Place Details を呼び出す際は、displayName、formattedAddress、rating、reviews、photos など、欲しい項目を正確に指定します。課金は、要求した中で最も高い階層のフィールドに基づいて行われます。field mask を付け忘れると、デフォルト値ではなくエラーになります。これは、使った分だけ支払う仕組みにしたい、という Google の設計思想です（もちろん、欲しい情報ほど高くなります）。
利用可能なフィールド は、料金ティアごとに整理されています。
| ティア | 代表的なフィールド | 取得できる内容 |
|---|---|---|
| Essentials | Place ID、整形済み住所、位置情報、写真メタデータ | 基本的な識別情報と所在地 |
| Pro | 表示名、営業状況、Google Maps URI、主な業種 | より詳しい事業情報 |
| Enterprise | 評価、レビュー数、Webサイト、電話番号、営業時間、価格帯 | ビジネスユーザーが本当に欲しい項目が中心 |
| Enterprise + Atmosphere | レビュー、レビュー要約、生成要約、設備情報、駐車場、テイクアウト/デリバリー | 最も豊富で、最も高価なデータ |
多くのユーザーが使う主要エンドポイントは、検索候補を出す Autocomplete、場所を探す Text Search と Nearby Search、既知の場所を詳細化する Place Details、画像を取得する Place Photos です。
ただし、重要な制限もあります。
- レビュー: Place リソース では、場所ごとに 最大5件 のレビューしか返りません。しかも関連性順です。50件でもなく、「すべて」でもなく、5件だけです。
- 写真: Place リソースでは、場所ごとに 10件の写真参照 までです。
- 混雑状況 / ライブのにぎわい: 標準の Places API フィールドとしては提供されていません。Google 自身は、集計・匿名化された Location History に基づくこのデータが一般向け画面には存在すると 説明しており、Maps のブログでも仕組みを解説しています。ただし、フィールド一覧 には含まれていません。
- Q&A セクション: 公開されていません。
- 「People also search for」系の競合情報: 公開されていません。
- メニュー / 価格表: 標準フィールドではありません。
Google Places API はどんな人が使うのか？
- 物流企業: 住所の検証やジオコーディング
- 旅行・宿泊系アプリ: 周辺のホテル、レストラン、観光スポットの表示
- 不動産プラットフォーム: 物件情報に周辺の店舗データを付加
- ローカルSEO代理店: NAP（name, address, phone）の整合性監査
- 営業チーム: Place ID と基本的な事業情報からリード一覧を作成
用途が「構造化された店舗データを本番アプリで使いたい」にきれいに当てはまるなら、API が出発点として最適です。もし用途に「全レビュー」「人気時間帯」「競合分析」という言葉が入るなら、続きを読んでください。
Google Places データの「スクレイピング」とは何か？
Web scraping とは、公式 API ではなくソフトウェアを使って Web ページから自動的にデータを抽出する方法です。この場合は Google Maps や Google Search の結果ページを対象にします。スクレイパーはブラウザと同じようにページを読み取り、画面上に表示されている構造化データを抜き出します。たとえば、店舗名、住所、レビュー本文、星評価、人気時間帯のヒストグラム、Q&A、競合候補、写真ギャラリーなどです。
大事な違いは、API は Google が公開してよいと決めたものだけを返すのに対し、スクレイピングは（理論上は）人間がページで見られるものをすべて取れる、という点です。
ただし「スクレイピング」といっても1種類ではありません。アプローチは大きく3つあり、それぞれトレードオフがかなり違います。
自作スクリプト、管理型スクレイピング API、ノーコードツールの違い
| アプローチ | 仕組み | 向いている用途 | 主なトレードオフ |
|---|---|---|---|
| 自作スクリプト（Puppeteer、Playwright、Selenium） | Google Maps を巡回し DOM を解析するヘッドレスブラウザのスクリプトを自分で書いて保守する | 完全な制御と独自ロジックが必要な開発者 | 保守負荷が最大。Google の UI 変更でセレクタが壊れる |
| 管理型スクレイピング API（Thunderbit API、SerpApi、Outscraper） | URL やクエリを API に送ると、レンダリング、対ボット対策、解析まで任せられ、構造化データで返ってくる | スクレイパーを自分で維持せず、整った出力が欲しい開発者 | 価格や品質はベンダー次第。第三者を信頼する必要がある |
| ノーコードのブラウザ拡張（Thunderbit Chrome Extension） | ブラウザ上でクリック操作だけで抽出。AI が項目を提案し、「Scrape」を押して Sheets/Excel に出力 | すぐにスプレッドシートが欲しいビジネスユーザー、マーケ、営業 | 複雑なパイプラインには柔軟性が低い。AI の精度に依存する |
要するに、DIY は最も柔軟だが最も手間がかかる。管理型 API は構造化出力で保守不要。ノーコードは非エンジニアにとって最速です。
Google Places API とスクレイピングの比較: 項目ごとの取得可否
私がこのテーマを調べ始めたときに、こういう表があればよかった、と思っていたものです。ビジネスユーザーや開発者が必要とする項目を、横並びで比較しています。
| データ項目 | Google Places API | Web Scraping |
|---|---|---|
| 企業名 | ✅ 完全取得（Pro ティア） | ✅ 完全取得 |
| 住所 / 位置情報 | ✅ 完全取得（Essentials ティア） | ✅ 完全取得 |
| 電話番号 | ✅ Enterprise ティア | ✅ 表示されていれば取得可 |
| Webサイト URL | ✅ Enterprise ティア | ✅ 表示されていれば取得可 |
| 総合評価 | ✅ Enterprise ティア | ✅ 完全取得 |
| レビュー数 | ✅ Enterprise ティア | ✅ 完全取得 |
| 個別レビュー（本文 + 評価） | ⚠️ 最大5件 | ✅ 取得可能なレビューをすべて取得 |
| 人気時間帯 / ライブ混雑 | ❌ 標準 API フィールドではない | ✅ 表示されていれば抽出可能 |
| Q&A セクション | ❌ 公開されていない | ✅ 抽出可能 |
| 写真メタデータ | ✅ Photos エンドポイント経由で 最大10参照 | ✅ ギャラリー全体 |
| メニュー / 価格表 | ❌ 標準フィールドではない | ⚠️ ページに表示されていれば可 |
| 「People also search for」（競合） | ❌ 公開されていない | ✅ 抽出可能 |
| 営業時間 | ✅ Enterprise ティア | ✅ 表示されていれば取得可 |
| 価格帯 | ✅ Enterprise ティア | ✅ 表示されていれば取得可 |
| Place ID | ✅ 非常に信頼性が高い（Essentials） | ⚠️ 取得は可能だが、API が正規ソース |
| Google Maps URI | ✅ Pro ティア | ✅ ページ URL そのもの |
| 口コミへのオーナー返信 | ⚠️ 最新の提供状況を確認 | ✅ 表示されることが多い |
| SERP / map-pack の順位 | ❌ API の目的ではない | ✅ SERP スクレイピングで取得可能 |
一番大きいギャップは、感情分析、評判モニタリング、競合ベンチマークのためにレビューを丸ごと使いたいなら、API だけでは足りない、という点です。1店舗あたり5件のレビューはサンプルであって、データセットではありません。
人気時間帯や来店傾向も同じです。小売コンサルや商業不動産のアナリストなら、スクレイピングが唯一の手段です。あのデータは API には入っていません。
逆に、正規の Place ID、ジオコーディング用の構造化住所、店舗検索機能の基盤が欲しいだけなら、API のほうがシンプルで、信頼性が高く、公式サポートも受けられます。
本当のコスト: 10K、100K、1M件で見た Google Places API とスクレイピング
この比較でもっとも誤解されやすいのがコストです。多くの人は API の無料枠で試作し、そのままスケールした途端、請求額を見て青ざめます。一方でスクレイピング側では、プロキシ代や開発工数を軽く見積もりがちです。
では、数字で見てみましょう。
Google Places API の料金内訳
Google は 2025年3月に Maps Platform の料金体系を刷新し、従来の一律 月額 $200 クレジット を、SKU ごとの無料利用枠とボリューム課金に置き換えました。現在の 料金 は次のとおりです。
- Essentials フィールド（Place Details）: 月 10,000回まで無料、その後は 100K 件まで 1,000回あたり $5.00
- Pro フィールド（Place Details）: 5,000回まで無料、その後は 1,000回あたり $7.00
- Enterprise フィールド（Place Details）: 1,000回まで無料、その後は 1,000回あたり $20.00
- Enterprise + Atmosphere（レビュー、設備情報など）: 1,000回まで無料、その後は 1,000回あたり $25.00
重要なのは、field mask に 1つでも Enterprise + Atmosphere の項目（たとえば reviews）を含めると、そのリクエスト全体がそのティアで課金されることです。また、実際のワークフローでは、場所の発見に Text Search Pro を使い、その後に Place Details Enterprise + Atmosphere で情報を補強する、といった形で複数 SKU をまたぐことが多く、費用は積み上がります。
1回の「検索」が、請求上の1リクエストとは限りません。
スクレイピングのコスト: ツール、プロキシ、開発工数
スクレイピングのコストは3つに分かれます。
- ツールのサブスクまたは API クレジット: 管理型スクレイピング API は、リクエストごと、クレジットごと、またはレコードごとに課金します。SerpApi は検索単位課金。Outscraper は従量課金です。Thunderbit の API はクレジット制で、Extract は 1回あたり 20クレジットです。Thunderbit Chrome Extension は出力1行につき1クレジットです。
- プロキシ費用（DIY のみ）: Google Maps スクレイピング用の住宅用プロキシは、ボリュームや提供元によって月 $50〜$300 程度が一般的です。
- 開発工数（DIY のみ）: Puppeteer / Playwright スクリプトの構築と保守。ここが DIY の経済性を壊す隠れコストです（後ほど詳しく触れます）。
スケール別のコスト比較表: API vs. スクレイピング
| 規模 | Google Places API（Enterprise + Atmosphere） | 管理型スクレイピング API（推定） | DIY スクレイピング（プロキシ + 開発工数） |
|---|---|---|---|
| 月10K件 | 約 $225（1K 件無料、9K × $25/1K） | 提供元により約 $50〜$150 | 約 $50 のプロキシ + 月 2〜4 時間の開発工数 |
| 月100K件 | 約 $2,475（無料枠後はボリューム階層適用） | 約 $250〜$500 | 約 $150 のプロキシ + 月 8〜16 時間の開発工数 |
| 月1M件 | 約 $17,975（ボリューム階層で単価は下がるが、総額は依然高い） | 約 $1,500〜$3,000 | 約 $300 のプロキシ + 月 20 時間超の開発工数 + 壊れるリスク |
注: API の見積もりは 公開されているボリューム階層 を、Place Details Enterprise + Atmosphere に対して 1K 件の無料枠後に適用したものです。管理型スクレイピング API の見積もりは各社の概算レンジです。DIY の開発工数は、実効時給 $50〜$100 を想定しています。
傾向は明確です。趣味レベル、つまり 10K 件未満なら、API の無料枠のおかげで最も安くなることが多いです。特に Essentials や Pro だけで足りるならなおさらです。ビジネス規模、つまり 100K 件を超えると、特にリッチな項目では API のコストが急増します。エンタープライズ規模、つまり 1M 件以上になると、API は月額5桁に近づき、しかも API が返さない追加項目が本当に必要なら、スクレイピングやデータセットサービスのほうが経済的に見えてきます。
必要なのが住所と Place ID だけなら、スクレイピングは不要です。その用途では API のほうが安く、優れています。スクレイピングのコストが正当化されるのは、API では取れないデータが必要なときだけです。
対ボットの現実: DIY の Google スクレイパーが壊れる理由
ここが、スクレイピング推進派が省略しがちな部分です。Google は Google Maps をスクレイピングしてほしくありません。そのため複数の防御層を用意し、継続的に更新しています。
Google の多層防御
- reCAPTCHA チャレンジ: 自動ブラウザは人間よりも高い頻度で CAPTCHA を引き起こします
- クライアントサイドの JavaScript レンダリング: Google Maps は JavaScript の重いアプリです。単純な HTTP リクエストでは描画後の内容を取得できず、フルのヘッドレスブラウザが必要です
- ブラウザフィンガープリンティング: Google は canvas fingerprint、WebGL、navigator プロパティ、その他のシグナルでヘッドレスブラウザを検出します
- IP レート制限: 同じ IP、または同じプロキシサブネットから大量にアクセスするとブロックされます
- DOM 構造の変更: Google はページ構造を頻繁に変えます。Reddit や GitHub の issue を見ると、セレクタは数週間から数か月で壊れるというのがほぼ共通認識です
最後の1つが静かな殺し屋です。6月には完璧に動いていた Puppeteer スクリプトが、7月には空結果を返すことがあります。CSS クラス名が変わった、あるいは div の構造が組み替わっただけで、です。
DIY スクリプト保守の隠れコスト
Google が DOM を変えるたびに、チームの誰かが次の作業をしなければなりません。
- スクレイパーが壊れたことに気づく（できれば誤データが広がる前に）
- 新しいページ構造を調べる
- セレクタを更新し、新しい CAPTCHA に対応し、リトライロジックを調整する
- テストして再デプロイする
1年単位で見ると、この保守時間は管理型スクレイピング API のサブスク費用を簡単に上回ります。私は、Google Maps スクレイパーを維持するためだけに年間 40時間以上の開発工数を消耗しているチームを見たことがあります。しかも、これは中程度の複雑さを想定した控えめな見積もりです。
なぜ管理型スクレイピング API が存在するのか
この保守負荷こそが、Thunderbit の API、SerpApi、Outscraper のようなサービスが存在する理由です。これらは対ボットの複雑さ——JS レンダリング、CAPTCHA 解決、プロキシローテーション、セレクタ保守——を引き受け、構造化データを返してくれます。
Thunderbit の POST /extract エンドポイントは、renderMode: "full" を使うことで Google Maps のような JavaScript-heavy なページを処理し、まだ解析が必要な生 HTML ではなく、スキーマに一致した構造化 JSON を返します。MCP サーバー ではこれが AI エージェントにも拡張され、Claude、Cursor、その他の LLM ベースのワークフローが、自分の環境を離れずに Google Maps データをタスクの途中でスクレイピングできます。
非技術系ユーザーにとっては、Thunderbit Chrome Extension が保守ゼロの選択肢です。Google Maps のページを開き、「AI Suggest Fields」をクリックし、「Scrape」を押すだけで Sheets に出力できます。セレクタ不要、プロキシ不要、デバッグ不要です。
SerpApi と Outscraper も、価格体系と出力形式の異なる有力な代替手段です。SerpApi は検索ごとに構造化 JSON を返し、Outscraper はレコード単位の従量課金です。最適な選択は、ボリューム、予算、そして構造化 JSON が必要か、それとも半構造化出力を自分で処理できるかに左右されます。
ハイブリッド運用: Google Places API とスクレイピングを組み合わせる
このテーマで上位表示されている記事の多くは、実務で最も効果的だと私が見てきたやり方、つまり両方を使う、という案をあまり勧めていません。多くのチームは、あるタスクには公式 API、別のタスクにはスクレイピングを使っています。コツは、ツールを仕事に合わせて使い分けることです。
公式 API が勝つ場面
- 本番アプリの Autocomplete: 低遅延、利用規約準拠、安定した SLA。文句なしです。
- 位置情報ベースのアプリ基盤: 店舗検索、住所検証、Place ID の照合。API は構造化され、サポートもあり、ドキュメントも整っています。
- コンプライアンス重視の統合: エンタープライズ契約、公開向けプロダクト、Google の利用規約準拠が絶対条件のケース。
スクレイピングが勝つ場面
- レビューの全件抽出（1店舗5K件以上）: 感情分析、評判監視、競合ベンチマーク。API の5件制限では話になりません。
- 単発のリード一覧抽出: 継続課金のないバッチ処理では、スクレイピングのほうが安いです。Thunderbit のようなノーコードツール を使えば、数分で店舗一覧をスクレイプしてスプレッドシートに出力できます。
- 人気時間帯 / 来店分析: API では提供されていません。それだけです。
- Q&A や競合の「People also search for」: ページ上にしか表示されず、API にはありません。
ハイブリッドが向いているケース
- 継続的な価格 / 評価モニタリング: API で基本の構造化データ（Place ID、住所、総合評価）を取り、スクレイピングで API にない深い項目（全レビュー、人気時間帯）を補完する。
- エンリッチメントのワークフロー: API で Place ID と正規の事業情報を取り、その後に個別の掲載ページをスクレイピングして、レビュー全件、Q&A、競合文脈を取得する。
- 定期監視: ノーコードなら Thunderbit のスケジュールスクレイパー、開発者なら cron 付き CLI バッチ抽出で、独自インフラなしに定期実行できます。
ユースケース別の判断表
| ユースケース | 推奨手法 | 理由 |
|---|---|---|
| 本番アプリの Autocomplete | ✅ 公式 API | 低遅延、利用規約準拠、安定 |
| 5K件超のレビュー全件取得 | ✅ スクレイピング / スクレイピング API | API は1店舗5件まで |
| 単発のローカルビジネスのリード一覧 | ✅ スクレイピング（または Thunderbit 拡張機能） | バッチ処理なら安く、継続課金なし |
| 人気時間帯 / 来店分析 | ✅ スクレイピングのみ | API では利用不可 |
| 継続的な価格 / 評価モニタリング | ⚠️ ハイブリッド | 基本データは API、深い項目はスクレイピング |
| 位置情報ベースのアプリ基盤 | ✅ 公式 API | 構造化、サポートあり、SLA あり |
| ローカルSEOの SERP 順位追跡 | ✅ スクレイピング / SERP API | Places API の用途ではない |
| 競合の「People also search for」 | ✅ スクレイピングのみ | API では公開されていない |
判断フローチャート: Google Places API とスクレイピング、どちらを選ぶ？
曖昧な「場合による」ではなく、具体的な判断フレームにしましょう。次の4つの質問を順に見てください。
1. 本番アプリでリアルタイムデータが必要ですか？ → Yes: 公式 API を使ってください。サポートがあり、SLA があり、利用規約にも準拠しています。ここで終了です。 → No: 次へ。
2. API が返さないデータ（全レビュー、人気時間帯、Q&A）が必要ですか？ → Yes: スクレイピングが必要です。API では物理的に取得できません。 → No: 次へ。
3. 月に何件処理しますか？ → 10K件未満: 特に Essentials や Pro だけで足りるなら、API が最も安い可能性が高いです。この規模なら無料枠の恩恵も大きいです。 → 10K件超: スクレイピング、または管理型スクレイピング API のほうが経済的なことが多いです。特にリッチな項目を取るならなおさらです。
4. スクレイパーを作って保守する開発リソースはありますか？ → Yes: Puppeteer / Playwright で DIY するのが最も自由度が高いです（ただし継続保守の予算は確保してください）。 → No: 管理型スクレイピング API（Thunderbit API、SerpApi、Outscraper）か、ノーコードツール（Thunderbit Chrome Extension）を使いましょう。
開発者向け代替手段の簡易比較
| ツール | 料金体系 | 出力形式 | 対ボット対策 | バッチ対応 |
|---|---|---|---|---|
| Thunderbit API / MCP | クレジット制（Extract = 1回20クレジット） | スキーマ一致の構造化 JSON | ✅ JS レンダリング、プロキシローテーション、ジオルーティング | ✅ 1バッチ最大 100 URLs |
| SerpApi | 検索単位（段階課金） | 構造化 JSON | ✅ | ✅ API パラメータ経由 |
| Outscraper | レコード単位（従量課金） | JSON / CSV | ✅ | ✅ タスクキュー経由 |
| DIY（Puppeteer/Playwright） | プロキシ + 開発工数 | 生 HTML（自分で解析） | ❌ 自分で対応 | ✅ 自分で作った分だけ |
Thunderbit の API の強みは、JSON Schema で定義したスキーマに合わせて構造化 JSON を返すことです。生 HTML や、まだ解析が必要な Markdown ではありません。LLM パイプラインやデータベース投入を考えるなら、後処理の時間をかなり節約できます。
Thunderbit はどこに当てはまるのか（ビジネスユーザーと開発者向け）
私たちは Thunderbit を、「Google Maps のデータが欲しい」と「スクレイピング基盤のエンジニアにはなりたくない」の間のギャップを埋めるために作りました。両方のユーザーに向けて、どう動くのかを紹介します。
非技術ユーザー向け: Chrome 拡張機能
- Google Maps のページを開く — 検索結果ページでも、個別の店舗ページでもOK
- 「AI Suggest Fields」をクリック — Thunderbit の AI がページを読み取り、列を提案します（企業名、住所、評価、レビュー、電話番号など）
- 「Scrape」をクリック — 拡張機能がデータを構造化テーブルに抽出します。cloud mode を使えば最大 50ページを同時処理 できます
- サブページをスクレイプ — 「Scrape Subpages」をクリックすると、各店舗ページに移動して詳細を取得します
- エクスポート — Excel、Google Sheets、Airtable、Notion へ出力。無料でデータ書き出し可能、ペイウォールなし
週次の競合評価チェックや新規店舗リストのような定期監視には、スケジュールスクレイパーを設定した頻度で自動実行できます。
開発者向け: API、MCP サーバー、CLI
POST /extractと JSON Schema: Google Maps の URL を送り、欲しい項目を定義すると、構造化 JSON が返ります。JavaScript-heavy なページではrenderMode: "full"を使います。Thunderbit は レンダリング、対ボット対策、プロキシローテーション、ジオルーティングを処理します。POST /distill: 任意のページからきれいな Markdown を取得できます。構造化項目ではなく生の内容が欲しい LLM パイプラインに便利です。Extract の 20クレジットに対して、1リクエスト 1クレジットです。- MCP サーバー: AI エージェント（Claude、Cursor など）が、作業の途中で Google Maps データをスクレイプできます。distill、構造化抽出、フィールド提案、最大100URLのバッチ処理に対応します。
- CLI:
thunderbit batch extract --file urls.txt --schema places.jsonのようにして、定期実行や CI/CD に組み込んだスクレイピングができます。
クレジット料金は、Extract が 1回20クレジット、Distill が 1回1クレジットです。API のクレジットはリクエスト単位であり、行単位ではありません（拡張機能は1クレジット = 出力1行）。最新のプランは Thunderbit Pricing をご確認ください。
法務と利用規約の観点
ここは簡潔に、事実ベースでまとめます。怖がらせる意図も、売り込みもありません。
Google Places API には明確な利用条件があります。Google のサービス別規約 では、Places API のコンテンツは Google Map なしでも使えますが、Google 以外の地図と組み合わせてはいけないとされています。緯度・経度は 30連続暦日 までキャッシュ可能で、Place ID は無期限保存できます。詳細、写真、レビューには帰属表示が必要です。
Google Maps のスクレイピング は、Google の利用規約に違反する可能性があります。執行はケースによって異なり、IP ブロック、CAPTCHA の壁、まれに法的措置といったリスクがあります。管理型スクレイピング API は、ユーザーに代わって一定のコンプライアンス負担を引き受けることが一般的ですが、法的な免責ではありません。
エンドユーザー向けの本番アプリなら、公式 API のほうが安全です。社内調査、バッチ分析、競合インテリジェンスでは、スクレイピングは業界でよくある実務です。商用ワークフローについては、自社の法務に相談してください。
私なら実際にどちらを選ぶか、その理由
料金 SKU、フィールド一覧、コミュニティのスレッド、ツールドキュメントまで見たうえで、私の結論はこうです。
- 公式 API を使う場面: 本番アプリでリアルタイムかつ利用規約準拠のデータが必要なとき。あるいは Essentials / Pro で十分で、月10K件未満のとき。小規模なら無料枠がかなり大きく、データ品質も文句なしです。
- スクレイピングを使う場面: 全レビュー、人気時間帯、Q&A、競合文脈、または API が公開していない項目が必要なとき。さらに、月10K〜100K件を超えていて、リッチな（Enterprise + Atmosphere）項目を取るなら、API の請求額は正当化しづらくなります。
- 両方を使う場面: ワークフローに、正規の Place ID と基本構造化データ（API）に加えて、ページ上の深い情報（スクレイピング）が必要なとき。実際には、この記事が認める以上にこのパターンは一般的です。
コストの分岐点はこうです。月約10K件未満で基本項目だけなら、API のほうがシンプルで、しばしば無料です。それを超え、特にリッチデータが必要なら、スクレイピングのほうが経済的になります。Enterprise + Atmosphere の項目で月1M件を扱うなら、API では月額約1.8万ドル、管理型スクレイパーならその一部で済むでしょう。
自分で試したいなら、Thunderbit Chrome Extension が、スクレイピングで何が取れて、API で何が取れないかを確認する最速の方法です。開発者向けには、Thunderbit API ドキュメント に始めるための情報が揃っています。さらに、コードなしのウェブスクレイピング や AI を使ったウェブスクレイピング についても、ブログで詳しく紹介しています。
重要ポイント
- Google Places API は、本番アプリ、Autocomplete、正規の店舗検索には最適ですが、レビューは5件まで、写真は10件までで、人気時間帯、Q&A、競合候補は標準フィールドとして返しません。
- スクレイピングなら、Google Maps ページ上で見えるものをすべて取得できます。レビュー全件や人気時間帯データも含まれますが、対ボット対策の管理か、管理型サービスの利用が必要です。
- 月10K件未満なら、API の無料枠が最安になることが多いです。100K件を超えると、リッチデータではスクレイピングや管理型 API のほうが経済的になりがちです。
- DIY スクレイパーは、Google の対ボット対策や DOM 変更で頻繁に壊れます。保守には年間40時間超の開発工数を見込むか、管理型ツールを使いましょう。
- 実務では、API で正規 ID と基本項目を取り、スクレイピングで API では得られない深い情報を補うハイブリッド戦略が最も有効なことが多いです。
- Thunderbit は両方に対応しています。ノーコード向けの Chrome 拡張機能と、開発者向けの構造化 JSON API / MCP サーバーを提供します。
FAQ
Places API で Google レビューを5件以上取得できますか？
いいえ。 Google Places API はレビュー返却を1店舗あたり最大5件に制限しており、関連性順で返します。これは API 登場時から続いている仕様で、開発者から長年要望が出ているにもかかわらず変わっていません。ビジネスのレビューを取得可能な限りすべて見たいなら、スクレイピング（DIY でも管理型 API でも）が唯一の選択肢です。
Google Maps のスクレイピングは合法ですか？
一律に「はい」「いいえ」とは言えません。公開されている Google Maps データのスクレイピングは、Google の利用規約に違反する可能性がありますし、執行も IP ブロックから、まれに法的措置まで幅があります。多くの企業は社内調査や競合分析のために問題なく活用しています。管理型スクレイピング API は一定のリスクを吸収しますが、法的保証ではありません。商用プロダクトや個人データを扱う場合は、法務に相談してください。
100K件の検索で Google Places API はいくらかかりますか？
要求するフィールドによって変わります。Place Details の Essentials ティアなら約 $450、Pro ティアなら約 $1,615、Enterprise + Atmosphere（レビューや設備情報を含む）なら約 $2,475 です。さらにワークフローで発見用に Text Search Pro が必要なら、約 $3,040 が追加されます。これらは Google が公開しているボリューム階層 に基づき、無料枠後に1件1課金として見積もったものです。
スクレイピング API とノーコードのスクレイピングツールの違いは何ですか？
スクレイピング API（Thunderbit の Open API のようなもの）は、開発者が HTTP リクエスト経由でスクレイピングをコード、オートメーション、AI エージェントのワークフローに組み込むためのものです。ノーコードツール（Thunderbit Chrome Extension のようなもの）は、非技術者がコードを書かずにブラウザ上でポイント、クリック、エクスポートできるようにします。どちらも構造化データを返せますが、違いはインターフェースと統合の形です。
Thunderbit は Google Maps のページで使えますか？
はい。Chrome 拡張機能は Google Maps の検索結果や個別の店舗一覧をスクレイプできます。AI が自動でフィールドを提案し、cloud mode なら最大50ページを同時に扱えます。API の POST /extract エンドポイントは renderMode: "full" を使うことで Google Maps の JavaScript レンダリングページに対応し、スキーマ一致の構造化 JSON を返します。MCP サーバー を使えば、AI エージェントがワークフロー中に Google Maps データをスクレイプできます。
さらに詳しく
