Google Maps API用プロキシ：鍵のブロックなしでビジネスデータのジオコーディングとパース

Google Maps APIは、住所のジオコーディング、組織の検索、地域ビジネスのデータ収集のための強力なツールです。しかし、商業的な規模で使用を開始すると、キーのブロック、制限の超過、疑わしいリクエストが発生します。この記事では、なぜこれが起こるのか、そしてキーが燃え尽きず、データが安定して収集されるようにプロキシを設定する方法を説明します。

なぜGoogle Maps APIはキーやリクエストをブロックするのか

1つのIPアドレスまたは1つのキーからGoogle Maps APIに数百または数千のリクエストを送信すると、Googleはこれを異常な活動と見なします。保護システムは、リクエストの頻度、IPの地理、行動パターン、キーの履歴など、複数の基準に基づいて同時に機能します。

ここでは、キーが制限を受けたり完全にブロックされたりする主な理由を示します：

• 1日のリクエスト制限の超過 — 各キーにはクォータがあり、これが消費されるとAPIはエラーOVER_QUERY_LIMITを返します。
• 1つのIPからの高頻度リクエスト — 制限内でも、Googleはあまりにも速い連続リクエストを自動化と見なします。
• 複数のキーに対する1つのIP — キーをローテーションしているがIPをローテーションしていない場合、Googleはそれらを1つのセッションに結びつけます。
• キーとIPの地理的不一致 — キーが1つの国に登録されているが、リクエストが別の国から行われると疑わしさを引き起こします。
• リクエスト間の遅延がない — 停止なしの機械的なパターンはすぐに検出されます。
• マスキングなしのデータセンターIPの使用 — Googleはクラウドプロバイダー（AWS、GCP、Azure）のIP範囲をよく知っており、それに対する検証レベルを高めます。

重要なのは、Google Maps APIは有料の製品であり、Googleは悪用だけでなく請求の回避からも保護していることを理解することです。したがって、ここでの検出システムは、通常のウェブ検索よりもはるかに厳しいです。キーのブロックはデータへのアクセスを失うことを意味し、新しいGoogle Cloudアカウントを作成する必要があるため、これは手間がかかります。

ビジネスでGoogle Maps APIを使用する理由

技術的な詳細に入る前に、実際の使用シナリオを見てみましょう。これにより、特定のタスクに適したプロキシの種類とローテーション戦略を選択できます。

大量の住所のジオコーディング

物流会社、不動産アグリゲーター、デリバリーマーケットプレイスは、定期的に数千のテキストアドレスを座標に変換します。たとえば、ルートを構築するために50,000の顧客アドレスのデータベースをアップロードする場合です。Geocoding APIを使用すると、これを自動化できますが、短時間で1つのキーから50,000のリクエストを送信すると、ブロックの直接的な道になります。

地域ビジネスのデータのパース（Places API）

マーケティングエージェンシー、リードジェネレーター、企業データベースは、Places APIを使用して組織に関する情報を収集します：名前、電話番号、ウェブサイト、評価、営業時間、レビュー。典型的なタスクは、数都市のすべてのレストラン、歯科医院、または自動車修理工場を収集し、後で電話をかけたり、メールを送信したりすることです。

競合の監視と地理分析

小売業者は、自分の地域で競合他社の新しい店舗のオープンを追跡します。フランチャイズチェーンは、新しい店舗のための潜在的なロケーションを分析します。広告代理店は、特定の都市や地域でのジオターゲティングを確認します。

CRMデータの充実

SaaS製品やB2Bサービスは、CRM内の企業カードを自動的に充実させます：座標を追加し、住所の正確性を確認し、Googleビジネスプロファイルからデータを引き出します。これには、APIへの定期的なバックグラウンドリクエストが必要です。

これらのすべてのシナリオには共通点があります：高頻度のリクエストであり、プロキシなしではブロックが避けられません。この問題へのアプローチは、タスクによって異なります。

Google Maps APIで使用するのに適したプロキシの種類

プロキシの種類の選択は、安定した動作とブロックの可能性に直接影響します。Google Maps APIのタスクに関連する3つの主要なオプションを見てみましょう。

レジデンシャルプロキシ — 大多数のタスクに最適な選択

レジデンシャルプロキシは、実際の家庭ユーザーのIPアドレスを使用します。Googleにとって、彼らはブラウザで地図を開く普通の人々のように見えます。これにより、Places APIや高頻度のジオコーディングでの作業に最も安全なオプションとなります。大規模なIPプールにより、リクエストごとまたは数回ごとにローテーションが可能で、Googleはそれらを1つのセッションに結びつけることができません。

モバイルプロキシ — 最大の信頼性が必要な場合

モバイルIPは携帯電話のキャリアからの特別なケースです。1つのモバイルIPは、NATの背後で多くのデバイスによって実際に使用されるため、Googleは高い活動があってもこれらのアドレスをブロックすることはほとんどありません。タスクが非常に重要で中断を許可できない場合、モバイルプロキシは最大の安定性を提供します。欠点は、より高い価格と小さなアドレスプールです。

データセンタープロキシ — 感度の低いタスク専用

サーバープロキシは高速で安価ですが、Google Maps APIはこれに対して高い疑念を持っています。中程度の頻度と良好なローテーションで大量の住所のジオコーディングに使用する場合、機能する可能性があります。しかし、Places APIのパースや厳しい制限のある地域での作業には、キーがブロックされるリスクが大幅に高まります。

ジオコーディングのためのプロキシ設定：ステップバイステップガイド

最も一般的なシナリオであるGeocoding APIの実践的な設定を見てみましょう。タスク：10,000の住所のリストをブロックなしで座標に変換します。

ステップ1. インフラを準備する

まず、キーとプロキシの数を決定します。基本的なルール：1つのキー — 1つのIPプール。異なるキーに対して同じプロキシプールを使用しないでください — Googleはそれらを行動パターンで結びつける可能性があります。10,000の住所のタスクには、少なくとも2〜3のGoogle Cloudキーと50以上のレジデンシャルIPプールを持つことをお勧めします。

ステップ2. IPのローテーションを設定する

ジオコーディングの最適な戦略は、各リクエストごとではなく、10〜20リクエストごとにIPを変更することです。IPの変更があまりにも頻繁すぎると、疑わしく見えることもあります。ほとんどのレジデンシャルプロキシプロバイダーは、指定された間隔で自動的にIPを変更するローテーションエンドポイントを提供しています。手動での切り替えではなく、これを使用してください。

import requests

GOOGLE_API_KEY = "あなたのキー"
PROXY_HOST = "rotating.proxyprovider.com"
PROXY_PORT = "8080"
PROXY_USER = "username"
PROXY_PASS = "password"

proxies = {
    "http":  f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}",
    "https": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
}

def geocode_address(address):
    url = "https://maps.googleapis.com/maps/api/geocode/json"
    params = {
        "address": address,
        "key": GOOGLE_API_KEY,
        "language": "ja"
    }
    response = requests.get(url, params=params, proxies=proxies, timeout=10)
    return response.json()

# 使用例
result = geocode_address("東京, 渋谷区, 1-1")
print(result["results"][0]["geometry"]["location"])

ステップ3. リクエスト間に遅延を追加する

リクエストを「できるだけ早く」送信しないでください。リクエスト間に0.5〜2秒のランダムな遅延を追加してください。ランダム性が重要です — 固定間隔（たとえば、正確に1秒）は機械的なパターンとして見なされます。Pythonでは、time.sleep(random.uniform(0.5, 2.0))を使用して実現できます。

ステップ4. リクエストヘッダーを正しく設定する

Google MapsへのAPIリクエストには、現実的なUser-Agentを含める必要があります。技術的にはAPIはブラウザのUser-Agentを要求しませんが、その不在や標準のPython User-Agentは検出の可能性を高めます。実際のブラウザを模倣したUser-Agentを使用し、1つのセッション内であまり頻繁に変更しないでください。

ステップ5. エラーと再試行を処理する

APIの応答ステータスを適切に処理する実装を行ってください。OVER_QUERY_LIMITを受け取った場合は、60秒の休止を取り、IPを変更してください。REQUEST_DENIEDの場合は、キーがブロックされているため、バックアップに切り替えてください。ZERO_RESULTSの場合は、問題はアドレスにあり、プロキシにはありません。

プロキシを使用したPlaces APIによるビジネスデータのパース

Places APIは、Geocoding APIよりもはるかに敏感なエンドポイントです。Googleは、大量のリクエストの主な目的が商業データの収集であることを理解しているため、ここでの保護は厳格です。正しいアプローチを見てみましょう。

Places APIを介したデータ収集戦略

Places APIは、Nearby Search（座標と半径による検索）とText Search（テキストクエリによる検索）の2つの主要なメソッドを介して機能します。広範囲をカバーするためには、グリッドメソッドを使用します — 地域をオーバーラップするセルに分割し、各セルを順番にリクエストします。

重要な特徴：Places APIは、1回の検索で最大60件の結果を返します（20件ずつの3ページ）。ゾーン内に60件以上のオブジェクトがある場合は、検索半径を減らし、グリッドの密度を増やす必要があります。これにより、リクエストの数が自動的に増加し、プロキシのローテーションが非常に重要になります。

import requests
import time
import random

def search_places_nearby(lat, lng, radius, place_type, api_key, proxies):
    results = []
    url = "https://maps.googleapis.com/maps/api/place/nearbysearch/json"
    
    params = {
        "location": f"{lat},{lng}",
        "radius": radius,
        "type": place_type,
        "key": api_key,
        "language": "ja"
    }
    
    while True:
        response = requests.get(url, params=params, proxies=proxies, timeout=15)
        data = response.json()
        
        if data.get("status") == "OVER_QUERY_LIMIT":
            print("リクエストの制限 — 60秒の休止")
            time.sleep(60)
            continue
            
        results.extend(data.get("results", []))
        
        # 次のページのトークン
        next_token = data.get("next_page_token")
        if not next_token:
            break
            
        # 次のページの前に必ず休止（Googleの要件）
        time.sleep(random.uniform(2.0, 3.5))
        params = {"pagetoken": next_token, "key": api_key}
    
    return results

Place Detailsを介して詳細データを取得する

Nearby SearchまたはText Searchを介してplace_idのリストを取得した後、各場所の電話番号、ウェブサイト、営業時間、レビューを取得するためにPlace Detailsへの別のリクエストを行う必要があります。これにより、リクエストの数が2倍になります。ここでは、IPのローテーションが特に重要です — 各Place Detailsリクエストは、プールから新しいアドレスで行うのが最善です。

必要なフィールドのみをfieldsパラメータを介してリクエストしてください。これにより、リクエストのコストが削減され、転送されるデータの量が減少し、トラフィックの観点からリクエストパターンが疑わしくなくなります。

キーとIPのローテーション：安定した運用を実現する方法

Google Maps APIをプロフェッショナルに扱うには、単なるプロキシではなく、キーとIPの管理に対するシステム的なアプローチが必要です。正しく構築されたインフラの例を見てみましょう。

Google Cloudのキーのプール

Google Cloud Consoleでいくつかのプロジェクトを作成します — 真剣なタスクには最低3〜5のプロジェクトが必要です。各プロジェクトには独自のAPIキーが付与されます。キー間の負荷を均等に分散させます：1日に10,000リクエストがあり、5つのキーがある場合、各キーは2,000リクエストを行います — 疑わしさの閾値を大幅に下げます。

重要なルール：各キーをプロキシプールの別々のIP範囲に結びつけます。キー1は範囲AのIPを介してのみ機能し、キー2は範囲Bを介して機能します。キーとIPを混合することは、主要なエラーの1つであり、大量のブロックを引き起こします。

リクエストのスケジュール

すべてのリクエストを夜間や非稼働時間に実行しないでください — これは「通常のユーザー」にとって典型的なパターンではありません。業務時間内にタスクを分散させ、自然な活動を模倣します。タスクが数日間の実行を許可する場合は、1晩で全てを行うよりも、3〜5日間にわたって適度な負荷で実行する方が良いです。

キーの状態を監視する

APIの応答ステータスを自動的に監視する実装を行ってください。制限の最初の兆候（OVER_QUERY_LIMITエラーの増加）が見られた場合は、すぐにそのキーのリクエスト頻度を下げ、数時間「休ませて」ください。完全なブロックを待たないでください — 治療するのは防止するよりもはるかに難しいです。

Google Maps APIの制限とその回避方法

Google Maps APIの制限を理解することは、インフラの計画にとって非常に重要です。制限には2種類あります：クォータ（1日/1ヶ月のリクエスト数）とレート制限（1秒あたりのリクエスト数）。プロキシは、正しく使用すれば両方のタイプで役立ちます。

注意：制限はキーに結びついており、IPには結びついていません。したがって、キーのローテーションとIPのローテーションを組み合わせることが、APIのコストを増やさずに作業をスケールする唯一の方法です。無料クォータが$200の複数のキーを持つことで、無料リクエストの総量を大幅に増やすことができます。

プロキシがレート制限にどのように役立つか

Geocoding APIの50 QPSのレート制限は、1つのキーから1秒あたり50リクエストを超えてはならないことを意味します。ここでプロキシはこの制限を回避するのには役立ちません — これはキーに結びついています。しかし、プロキシはキー間の負荷を分散させるのに役立ち、各キーが安全なゾーンに留まるようにします（最大レート制限の70〜80％を超えないことをお勧めします）。

よくある間違いとその回避方法

Google Maps APIを使用している間に、キーを失う原因となる典型的なエラーのリストが形成されます。それぞれを見て、具体的な解決策を提供します。

エラー1：複数のキーに対して1つのIPを使用する

これは最も一般的なエラーです。キーをローテーションしているが、すべてのリクエストが1つのプロキシまたは小さなIPプールから行われる場合、Googleは異なるキーが同じアドレスから使用されていることを見て、それらを1つのセッションに結びつけます。1つのキーがブロックされると、他のすべてのキーも危険にさらされます。

解決策：キーごとにIPプールを厳密に分けてください。各キーは専用のアドレス範囲を介してのみ機能します。

エラー2：Places APIのページ間の必須の休止を無視する

Places APIは、pagetokenを使用して次のページのリクエストの前に最低2秒の休止を要求します。次のページをすぐにリクエストすると、APIは空の結果またはエラーを返します。多くの開発者はこの要件を無視し、不正確なデータを取得します。

解決策：次のページのリクエストの前に常に2〜3秒の休止を追加してください。これはGoogleの文書化された要件であり、オプションの推奨事項ではありません。

エラー3：コード内の保護されていないキー

公開リポジトリにあるGoogle Maps APIキーは、自動的にボットによってスキャンされ、悪意のあるユーザーによって使用されます。Googleは自動的にキーの漏洩を検出し、通知を送信しますが、損害はそれ以前に発生する可能性があります。

解決策：キーを環境変数や秘密管理システム（Vault、AWS Secrets Manager）に保存してください。キーをソースコードにハードコーディングしないでください。Google Cloud ConsoleでIP制限を設定してください — キーはあなたのプロキシアドレスからのみ機能する必要があります。

エラー4：Place Detailsでのすべてのフィールドのリクエスト

デフォルトでは、Place Detailsはすべての利用可能なフィールドを返しますが、高価なフィールド（雰囲気、レビューを含む）も含まれます。これにより、各リクエストのコストが2〜4倍に増加します。さらに、大きな応答は処理を遅くします。

解決策：常にfieldsパラメータを使用し、必要なデータのみをリクエストしてください。たとえば：fields=name,formatted_phone_number,website,opening_hours,rating。

エラー5：無料または公開プロキシの使用

公開リストからの無料プロキシは、キーを失う確実な方法です。このようなIPは、他の多くのユーザーによってすでに使用されており、その多くはGoogleが防ぐことを目的とした活動を行っています。このようなIPの評判は非常に低く、Googleは予防的にこれらをブロックします。

解決策：信頼できるプロバイダーからのクリーンなIPアドレスを持つ有料プロキシのみを使用し、使用の独占性を保証してください。

結論

Google Maps APIを商業的な規模で扱うことは、データ収集の速度とキーの安全性の間のバランスを常に取ることです。プロキシはIPによるブロックの問題を解決しますが、適切なアーキテクチャ — キーのローテーション、リクエスト頻度の制御、エラーの適切な処理、タスクごとのIPプールの分離 — を置き換えるものではありません。

記事の主な結論：レジデンシャルプロキシとローテーションは、Places APIやジオコーディングに関するほとんどのタスクに適しています。各キーは独自の隔離されたアドレスプールを介して機能する必要があります。リクエスト間の遅延は必須であり、キーの状態の監視は自動化されるべきです。

Google Maps APIを定期的に使用する予定がある場合 — 住所をジオコーディングしたり、ビジネスデータを収集したり、競合を監視したりする場合 — レジデンシャルプロキシに注目することをお勧めします。これにより、Googleからの高い信頼性と、適切に設定されたIPローテーションによるキーのブロックリスクの最小化が実現されます。中断のない最大の信頼性が必要なタスクには、モバイルプロキシを検討する価値があります — これらのIPは高い活動があってもほとんどブロックされることはありません。