Google Maps店舗データの重複排除：Place IDは恒久的な事業者IDではない

Google Mapsの店舗データの重複排除は、店舗名が一致するかを確認したり、1つのエンティティが常に1つのPlace IDを持ち続けると想定したりするだけでは不十分です。Googleは、同じ場所が異なるIDを持つ場合があり、IDは時間とともに変わりうると明言しています。長期的に店舗リストを管理するなら、独自の社内エンティティIDを維持し、外部の場所IDとのマッピングを管理するほうが安全です。

この問題はStack Overflowの質問 https://stackoverflow.com/questions/29751398/geocoding-google-maps-api-return-different-place-id でも取り上げられています。Sergey Kuznetsov氏が、ある場所IDで問い合わせたところ、レスポンスでは別のIDが返されました。古い回答は問題の把握に役立ちますが、古いIDが恒久的に有効であることを裏づけるものではありません。本記事は2026年時点の公式ドキュメントに基づいています。

本記事はエンティティ認識とデータ品質に焦点を当てたもので、店舗の大量スクレイピングや、EveryInfraに自動統合機能があると主張するものではありません。ここで紹介する記録方法は、主に自社の店舗レコードや、処理する権限を持つデータを対象としています。

Place IDは変わる：それでも保持する価値がある理由

Google Place IDのドキュメントでは、IDは場所を識別するものの、同じ場所に複数のIDが存在する場合があり、IDは変わりうると説明されています。また、12か月以上保存しているIDは更新することを推奨しており、古いIDではNOT_FOUNDが返る場合があるとしています。EveryInfraのGoogle Mapsの場所検索APIは、各結果にplace_idを返します。本記事で説明するとおり、これはビジネスキーではなく外部識別子として保持してください。

これはPlace IDに価値がないという意味ではありません。むしろ、「コーヒーショップ」や「中央店」のような一般的な名称よりも優れた外部オブジェクト識別子になります。重要なのは、外部識別子にビジネス上の意味をすべて直接担わせないことです。

たとえば、チェーン店が街角から隣接するショッピングモールに移転した場合、事業上は同じ営業店舗とみなせても、場所は変わっています。逆に、同じブランド名の2店舗でも、事業と場所が異なれば統合すべきではありません。重複排除のルールを決める前に、テーブルが記録するのが「ブランド」なのか、「営業店舗」なのか、「物理的な場所」なのかを定義してください。

この3つのレイヤーを1つのstore_idにまとめると、最初は手間が省けますが、時間がたつにつれて店舗数、レビューの帰属、過去の推移に誤りが生じます。外部IDの変更が新規出店として誤って記録されたり、名称の正規化によって別々の2店舗が1件にまとめられたりするおそれがあります。

事業者マスターレコードの先行作成と外部識別子マッピングの管理

自社の店舗データについては、サードパーティのプラットフォームに依存しない社内識別子をビジネスオブジェクトに割り当てます。外部プラットフォーム、ロケーションID、確認日時、有効期間はマッピングレコードに保存します。名称や住所などの説明フィールドは、各ソースで許可されている利用範囲と保存範囲に従って管理してください。

大規模なマスターデータシステムを構築する必要はありません。小規模なチームであれば、管理する店舗を記録するリストと、各店舗の現在の外部識別子を記録するリストの2つから始められます。IDが変わったときは、事業の履歴をすべて作り直すのではなく、マッピングを更新します。

重要なのは、変更の理由を残しておくことです。新しいIDが同じ場所のものだと手動で確認した場合と、公式の移転リンクがある場合とでは意味が異なります。どちらも新旧のレコードを紐づける必要があるかもしれませんが、システム上で単なる「重複データの削除」イベントとして扱うべきではありません。

マッピングは元に戻せるようにしておくべきです。2つの店舗を誤って統合した場合でも、上書きされたテーブルから推測するのではなく、判断の根拠をたどり、帰属を元に戻し、影響を受けた集計を再計算できるようにします。こうすれば、プラットフォームのテキストをすべて複製しなくても、許可された識別子と操作ログを保持できます。

店舗名と近接性：最終統合基準ではなく候補としてのみ利用

実在の店舗とは関係のない架空の例で考えてみましょう。あるブランドが同じショッピングセンターの1階と4階で2店舗を運営しており、ブランド名と基本となる住所が同じで、座標も近接しています。名称の一致と距離の近さだけで自動的に統合すると、営業拠点数が過少に集計され、レビューも誤った店舗に帰属します。

別の例として、同じ店舗に英語名と現地語名がある場合があります。名称が異なっていても、別々の2店舗とは限りません。データソースのロケーション識別子、自社の店舗データ、その他の検証済みソースを組み合わせて判断すべきです。言語をまたいだ名称照合は候補の特定には役立ちますが、最終的な結論を決めるものではありません。

判断は3段階に分けることをおすすめします。根拠が十分な場合はマッピングを確定し、根拠が矛盾する場合は統合を明示的に却下し、名称や場所が似ているだけの場合はレビューキューに回します。不明な状態はシステムの障害ではなく、疑わしい照合によってデータが恒久的に汚染されるのを防ぐために必要なステップです。

候補抽出ルールは状況に応じて調整すべきです。空港のカウンター、ショッピングモール、路面店では空間的な関係が異なり、すべての都市と業態に当てはまる単一の距離しきい値はありません。しきい値がチームの経験に基づく場合は、Googleの推奨事項として扱わず、社内ルールとして文書化してください。

IDの失効、閉業、移転は別々のイベント

NOT_FOUNDだけでは、店舗が閉業したことの証明にはなりません。GoogleのIDに関するドキュメントでは、古いIDやデータベースの更新などのケースが挙げられているため、営業状況を確認する前に、識別子の更新が必要かどうかを確認してください。クエリの失敗を、そのまま月間の閉業数に数えるべきではありません。

Place Details (New)では、businessStatusが提供されており、該当する移転についてはmovedPlaceとmovedPlaceIdによって移転先が示されると説明されています。実装前に、リクエストフィールド、権限、課金範囲を確認してください。これらはGoogleのフィールドであり、他のデータAPIでも利用できるとは限りません。

移転が発生した場合、ビジネスレポートでは少なくとも2点を明確にする必要があります。営業拠点が元のIDを保持しているかどうかと、新旧住所のデータをどのように区分するかです。移転前後のレビューを比較する際は、レビューの取得元となったロケーションオブジェクトを明記し、移転前のロケーションにあったすべてのコンテンツが自動的に移行したとは想定しないでください。

同じ事業者であっても、所在エリア、担当チーム、営業形態が変わることがあります。移転前後のデータを注記なしで1本のトレンドラインにつなげると、こうした変化が見えなくなります。より適切な表示方法ではイベントの注記を残し、どの指標が比較可能かを判断する前に、何が変わったのかを読み手が把握できるようにします。

Place IDの保持と、すべての詳細情報の長期保存は別問題

Places APIのポリシードキュメントでは、コンテンツのキャッシュ、保存、帰属表示に関する要件を定めるとともに、Place IDのキャッシュについては個別の例外を設けています。識別子の保存が認められているからといって、レビュー、写真、属性など、返された詳細情報を無期限にコピーしてよいことにはなりません。

設計はフィールドと用途ごとに区別すべきです。自社の店舗マスターは社内業務から生まれるデータです。外部ロケーションとのマッピングでは、IDの保存が認められています。外部コンテンツを表示する場合は、更新、保存、帰属表示についてそれぞれの規約に従う必要があります。条件は地域や用途によって異なり、本記事はプロジェクトごとのコンプライアンス審査に代わるものではありません。

レビュー分析が目的であれば、Google Maps Reviews APIガイドでレビュー系エンドポイントの違いを解説しています。取り込み元の選定とエンティティの重複排除は、順番に行う別々のステップです。前者は取得できるデータを決め、後者はデータの帰属先を決めます。

デプロイ前のエッジケースによる誤統合テスト

店舗の重複排除ルールは、明らかに同一のレコードが正しく統合されるかどうかだけでテストすべきではありません。統合してはいけないネガティブケースをテストし、復旧のワークフローを検証するほうが有益です。

自社データまたは合成データのサンプルを4グループ用意します。同一ブランドの別店舗、多言語の名称を持つ同一ロケーション、閉業が確認されていない失効ID、新しいロケーションIDが付与された移転店舗です。システムが別々の店舗を誤って統合しないこと、言語の違いだけでエンティティを分割しないこと、クエリの失敗を閉業として数えないこと、移転イベントを消去しないことを確認してください。

集計結果を抜き取りで確認する際は、「外部の結果件数」「一意のロケーション数」「事業上の店舗数」をそれぞれ別の指標として明記してください。これらの指標は本来異なる値になるため、レポートの都合で差異を無理に一致させないでください。マルチプラットフォーム評判モニタリングのブループリントでは、誤って帰属されたデータがビジネス上の意思決定に与える影響を解説しています。

店舗データ管理で最も難しいのは、その時点でどのオブジェクトを比較しているのかを把握することです。外部IDは有効期間とマッピングの根拠とあわせて保持し、未検証の一致候補は保留にしておきます。収集規模が拡大しても、この方法なら、元に戻しにくい誤った紐づけが生じるのではなく、利用可能なレコードが増えていきます。