ディーラー所在地情報って、ひとつにまとまった便利なデータベースがあるとは限らないんです。あるメーカーは見やすい一覧ページを出していて、別のメーカーはインタラクティブな地図を使い、さらに別のメーカーは郵便番号検索を求めてきたり、個別プロフィールページの奥にディーラー情報を隠していたりします。
対象が数百サイト規模になると、作業はもう「住所を少し抜き出す」だけでは済みません。本当に必要なのは、次のようなビジネス課題にちゃんと答えられる、信頼できるディーラーマスターです。
- 流通網はどこで拡大、あるいは縮小しているのか？
- どの地域にカバレッジの抜けがあるのか？
- どのディーラーが追加、移転、削除されたのか？
- どの拠点が特定の製品ラインやサービスを扱っているのか？
- 新しく見つかったディーラーは、どの CRM 担当者に回すべきか？
- 競合のチャネル展開は時間とともにどう変化しているのか？
実務上のアーキテクチャはシンプルです。情報源を見つけ、ロケーターのパターンを分類し、共通スキーマへ抽出し、元データの証拠を残し、重複を解消し、意味のある変化を検知し、適切なチームへ振り分けます。
目指すシステム
本番運用のディーラートラッキングは、6つの層で構成されます。
- ソースレジストリ: ウェブサイト、ロケーター URL、国、担当者、パターン、実行スケジュール、最終実行ステータスを管理します。
- ディスカバリー: ディレクトリページ、サイトマップ、API、検索フォーム、詳細 URL を再現性高く見つける仕組みです。
- 抽出: さまざまなレイアウトから同じ意味のフィールドを集めるブラウザまたは API ジョブです。
- 正規化: 元の値を壊さずに、住所、電話番号、国、カテゴリ、ステータス表記を統一します。
- エンティティと変化の層: ディーラーの一意な識別、ブランド所属、初回検出・最終検出時刻、追加・削除の確定管理を行います。
- アクティベーション: アラート、CRM 連携、カバレッジ分析、ダッシュボード、レビューキューです。
いきなりウェブサイトから CRM へ流し込もうとすると、壊れやすい個別スクリプトの寄せ集めと重複レコードの山になりがちです。数百サイトを扱えるようにする鍵は、レジストリと共通モデルにあります。
ステップ 1: 共通のディーラースキーマを定義する
最初のウェブサイトではなく、最終的な出力から考え始めましょう。最低限、次のようなスキーマが有効です。
| グループ | フィールド |
|---|---|
| ソース証跡 | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| 識別情報 | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| 住所 | street_address, address_locality, address_region, postal_code, address_country |
| 連絡先 | phone_raw, phone_normalized, website |
| 位置情報 | latitude, longitude |
| 商業属性 | services, products, categories, authorized_status_raw |
| 観測情報 | observed_at, first_seen, last_seen, record_status |
| 変更管理 | source_hash, change_hash, parser_version |
Schema.org の PostalAddress は、street address、locality、region、postal code、country の命名基準として参考になります。正規化データでは ISO の2文字国コードを使い、元サイトが表示している国名表記もそのまま保持しましょう。
生データと正規化後の値は並べて残してください。たとえば、サイトが St. John's, NL と表示し、正規化層が標準化された州名や電話コードを作成した場合でも、レビュー用に両方を保持します。
ステップ 2: ソースレジストリを作る
ソースレジストリは、運用の司令塔です。各ウェブサイトを1行ずつ登録し、次の情報を持たせます。
- ドメインとブランド
- 国または市場
- 想定ロケーター URL
- ロケーターパターンの種類
- 推奨クロールモード
- パーサーまたはテンプレートのバージョン
- 実行頻度
- ビジネス担当者
- 最終の試行、成功、空結果、失敗実行
- 検索入力や操作要件に関するメモ
すべてのロケーターを理解するまで待つ必要はありません。まずレジストリを作り、パイロットの進行に合わせて分類精度を上げていきましょう。
ロケーター情報源の見つけ方
次を確認します。
- 「Find a dealer」「Where to buy」「Store locator」などのメインナビゲーションやフッターリンク
/sitemap.xmlとサイトマップインデックス- サイト内検索
site:brand.example dealer locatorのような検索エンジン問い合わせ- ページソースや埋め込み構造化データ
- ロケーター検索で発生するネットワークリクエスト
- 代替ソースとしての PDF や販売代理店ドキュメント
Sitemaps protocol では、各 sitemap エントリに <loc> URL が必要で、サイトマップインデックスもサポートされています。サイトマップはディスカバリーを加速しますが、動的ロケーターの全結果が必ず含まれるとは限りません。また <lastmod> があるからといって、ディーラー情報が最新である証拠にはなりません。
ステップ 3: スケール前に各ロケーターを分類する
多くのディーラーサイトは、少数のパターン群に分かれます。
- 静的 HTML の一覧または表 — 最も扱いやすく、レコードがページソース内にあります。
- ページネーション付きディレクトリまたは無限スクロール — レコードは繰り返し表示されますが、移動が必要です。
- 詳細リンク付きの地図カード — 要約カードに加えてサブページの情報補完が必要です。
- 検索フォーム — 国、州、市、郵便番号の入力が求められます。
- 埋め込み JSON またはネットワーク応答 — ページは構造化データの見た目の殻にすぎません。
- 薄い一覧＋ディーラー詳細ページ — 一覧には識別情報だけがあり、住所やサービスは詳細ページにあります。
- PDF または文書ディレクトリ — 抽出や変更確認には文書専用の手順が必要です。
ひとつの万能スクレイパーで数百サイトすべてをうまく扱うことはできません。スケーラブルな方法は、パターン群ごとに再利用可能なワークフローを作り、各ソースには設定だけを当てはめることです。
ステップ 4: Thunderbit でブラウザワークフローを試す
Thunderbit は、大量自動化に投資する前に、代表的なサイトでスキーマを検証するのに役立ちます。
パイロット手順
- 代表的なディーラー一覧を Chrome で開きます。
- Thunderbit を起動し、AI Suggest Fields を使います。
- 提案フィールド名を共通スキーマに合わせてリネームします。
- 正規化や分類のために Field AI Prompts を追加します。たとえば、表示上の国名を ISO コードに変換したり、サービスを承認済みカテゴリに分類したりします。
- 一覧ページに対してページネーションや無限スクロール対応を有効にします。
- 個別ディーラーページに電話番号、サイト、サービス、ソース ID がある場合は、サブページスクレイピングを使います。
- 小さなサンプルを Sheets や Excel に出力し、すべてのソース URL を検証します。
ブラウザモードは、ロケーターに操作が必要な場合、ログインセッションが必要な場合、あるいは単純なリクエストでは再現できないレンダリングがある場合に特に有効です。利用するのは、組織がアクセスを許可されたソースとアカウントに限定してください。
取りやすいサイトではなく、代表性のあるサイトを選ぶ
最初のパイロットには、主要なパターン、地域、ページ技術をカバーする20サイトを含めるべきです。もしパイロット対象がすべて単純な静的表なら、最初の地図ベースのロケーターが来た瞬間にワークフローは崩れます。
各パターン群について、少なくとも次を検証します。
- きれいな例を1件
- 大規模な例を1件
- 動的または不規則な例を1件
- ディーラー詳細ページがあるサイトを1件
- フィールドが少ない、または任意項目が多いサイトを1件
ステップ 5: 安定したソースは Batch Extract API へ移行する
繰り返し取得できる公開ページは、手動ブラウザ操作から Thunderbit Web Scraper API に移します。
Batch Extract endpoint は、1回のリクエストで最大50 URL を単一の JSON Schema とともに受け付けます。ジョブ ID を返し、URL を並列処理し、URL ごとのエラーに対応し、Webhook 通知も送信可能です。none、basic、full などの renderMode オプションも提供されています。
バッチ設計
- 同じ意味スキーマを共有する URL をまとめます。
- 1リクエストあたり 50 URL の上限を超えないようにします。
- データを確実に取得できる、最も軽いレンダリングモードを選びます。
- 実行時にジョブ ID とパーサーバージョンを保存します。
- バッチ全体の結果だけでなく、URL ごとの成功・空・エラーを記録します。
- 再実行は失敗した URL のみ行います。
- 正規化の前に、生の抽出値とソースリンクを保持します。
フィールドのビジネス上の意味が一致していれば、デザインの異なるサイトでも1つのスキーマで対応できます。これが、静的ディレクトリと地図カード型ロケーターを同じディーラーマスターに流し込める理由です。
ステップ 6: 証拠を消さずに正規化する
正規化はレコードを比較可能にしますが、監査不能にしてはいけません。
推奨される変換は次のとおりです。
- 空白や記号の揺れを整える
dealer_name_rawを残したまま大文字小文字を統一する- 国の文脈を明示して電話番号を解析する
- 国名や地域名を承認済みコードへマッピングする
- 住所コンポーネントを一貫したルールで分割・結合する
- 必要に応じて URL を正規化し、追跡パラメータを除去する
- 自由記述のサービス名を管理カテゴリへマッピングしつつ、元の表現も保持する
ソースの認定ラベルを書き換えてはいけません。あるメーカーが「Authorized Dealer」、別のメーカーが「Certified Reseller」としている場合は、表記をそのまま保存し、必要に応じて別フィールドに正規化カテゴリを追加します。
ステップ 7: ブランドや情報源をまたいでディーラーを照合する
ディーラー名だけでは不十分です。「Smith Auto」「Smith Automotive」「Smith Auto LLC」は、同一企業かもしれませんし、隣接する市の別会社かもしれません。
次のような複合候補キーを使います。
normalized name + postal code + phone
または、座標があるなら次のようにします。
normalized name + geospatial distance + address number
そのうえで、証拠をスコアリングします。
- 正規化名が完全一致、またはほぼ一致
- 電話番号が一致
- 郵便番号が同じ
- 通り住所が似ている
- 座標が小さな半径内にある
- Web サイトのドメインが一致する
レコードを即座に潰し込むのではなく、ソースから共通エンティティへのマッピング表を作成します。複数メーカーが同じ物理ディーラーを指していても、ブランド所属、サービス、ステータス表記は個別に保持できます。
ステップ 8: 意味のある変化を検知する
毎回の実行は、破壊的な上書きではなく「観測」であるべきです。
保存すべきもの:
- 現在の実行時刻
observed_at - ソースに初めて現れた時刻
first_seen - 最新の成功観測時刻
last_seen - 生レコードのソースハッシュ
- 正規化済みビジネス項目の変更ハッシュ
有用な変更タイプは次のとおりです。
- ディーラーの追加
- ディーラー不在
- 名前、住所、電話番号、Web サイトの変更
- 認定ステータスの変更
- サービスまたは製品カテゴリの変更
- 所在地の移転
- ソースページの失敗、またはレイアウトの崩れ
欠落レコードは、まず missing_pending_review とします。削除確定は、複数回の不在確認または手動レビュー後に行います。クロール失敗、空の応答、壊れたセレクターは、ディーラー閉鎖の証拠ではありません。
ステップ 9: Google Places を任意の検証に使う
Google Places Place Details は、リクエストした field mask と SKU に応じて、安定した place ID、表示名、整形済み住所、座標、電話番号、Web サイト、営業ステータス、移転情報などを使って、ディーラーレコードの補強や検証に役立ちます。
ただし、メーカーのディーラープログラムにその拠点が属するかどうかの最終判断は、あくまで二次的なシグナルとして扱ってください。会員資格の正本はメーカー側のソースです。検証プロバイダーと時刻を保存し、メーカーのステータスを静かに上書きしないでください。
ステップ 10: パターン別・ソース別に抽出品質を測定する
品質は、実行単位、パターン単位、ドメイン単位で追跡します。
実行ごとの指標
- 登録済みソース URL
- 試行した URL
- 成功、空、失敗 URL
- 抽出レコード数
- 追加、変更、不在、未変更レコード数
- 主要フィールドの充足率
- 重複候補数
- 要レビューの削除疑い件数
- スキーマドリフト発生件数
サンプル検証
各パターン群と主要実行ごとに次を行います。
- サンプル化した20〜50件のレコードをソースページと照合する。
- 期待 URL 数と、試行・成功件数を突き合わせる。
- ドメインごとに不足している主要フィールドを確認する。
- 重複クラスタと低信頼度のエンティティ一致を確認する。
- 座標の外れ値、国・郵便番号の不一致を確認する。
- 削除候補の一部を再確認する。
- 使用した抽出器またはテンプレートのバージョンを記録する。
目的は、単一の全体「精度率」を出すことではありません。どのパターンとソースが信頼でき、どのフィールドが弱く、どこにレビュー工数を割くべきかを把握することです。
ステップ 11: 変更を業務ワークフローへ振り分ける
変更の種類によって、送り先は変えるべきです。
- 新規ディーラー: CRM 作成、担当割り当て、エリア配分のために営業オペレーションへ送る
- 削除・閉鎖された拠点: アカウントステータスを変える前にレビューキューへ送る
- 住所または電話番号の変更: エンリッチメントを更新し、進行中案件やサービスカバレッジを確認する
- 認定変更: チャネル管理や顧客対応チームへ通知する
- カバレッジの抜け: エリア設計とパートナー開拓に反映する
- 競合の拡大: 流通インテリジェンスと地域戦略を更新する
- ソースの連続失敗: 営業チームではなく、データ運用キューへ送る
すべての通知には、共通ディーラー情報、ブランド所属、変更種別、変更前後の値、ソース URL、観測時刻、信頼度またはレビュー状態を含めます。
30/60/90日ローンチ計画
1〜30日: 設計と検証
- 共通スキーマと管理カテゴリを確定する
- ソースレジストリを作る
- 代表的な20サイトを分類する
- 3〜5種類のロケーターパターンを検証する
- サンプル検証ルールと実行指標を整備する
- ソース証跡付きの初期ディーラーマスターを納品する
31〜60日: 拡張と自動化
- ポートフォリオ全体へ分類を広げる
- 安定した公開 URL 群をバッチ抽出へ移行する
- スケジュール、ジョブ追跡、リトライロジック、エラーダッシュボードを追加する
- ソースから共通エンティティへのマッピングを導入する
- レビュー済みの追加・更新を CRM ワークフローへ接続する
61〜90日: 変化インテリジェンスの運用化
- 変化種別ごとのアラートとレビューキューを追加する
- first-seen、last-seen、削除確認を導入する
- 住所の信頼性向上に役立つ場合のみ Places 検証を追加する
- 実行レベルのサービス目標を定義する
- パターンとテンプレートの性能を毎月レビューする
- 各ソース群と各業務アクションに担当者を割り当てる
よくある失敗パターン
サイトごとに個別スクレイパーを作る。 これでは保守経路が何百本にも増えます。パターン群を分類し、再利用ロジックとソース固有設定を分けましょう。
ディーラー名だけで重複排除する。 名前は表記揺れが大きく、再利用も頻繁です。住所、郵便番号、電話番号、座標、Web サイトの証拠を組み合わせて照合してください。
生データを上書きする。 元表記が失われると、正規化ミスを監査できなくなります。
空の出力を「ディーラーゼロ」とみなす。 空結果は、操作失敗、レンダリング変更、ブロックされたリクエストを意味する場合があります。クロールの健全性とビジネス上のステータスは分けて管理してください。
1回の欠落で削除確定する。 欠落の反復確認または手動検証を必須にします。
地図プロバイダーをディーラーの権威情報源として扱う。 地図データは場所の検証には使えますが、メーカーとの認定関係までは証明できません。
品質測定より先にスケールする。 小さな抽出ミスでも、数百サイトに広がると大きな運用問題になります。
FAQ
1つのスキーマで数百の異なるディーラーサイトに対応できますか？
はい。ページの見た目は異なっても、ディーラー名、住所、電話番号、Web サイト、ブランド、サービス、ソース URL、ステータスといった意味的な項目はほぼ共通です。抽出パターンを使い分けて、1つの共通スキーマへ流し込みましょう。
郵便番号検索が必要なロケーターページはどう自動化すべきですか？
検索フォーム自体を独立したパターン群として扱います。入力地点のカバレッジグリッドを定義し、結果 ID または URL を取得し、重複する検索半径を排除し、各結果を生んだ入力条件をデバッグ用に残します。
ディーラー所在地はどのくらいの頻度で更新すべきですか？
業務上の重要度とソースの挙動に合わせます。競合情報やサービスカバレッジの高価値ソースは週次、更新の遅いメーカー一覧は月次が適しています。実行失敗は、ディーラー変更の頻度とは別に運用レビューの対象にしてください。
削除されたディーラーと、スクレイピング失敗をどう見分けますか？
ソース健全性とレコード存在を別管理にします。失敗または空のクロールでは、ディーラーの最終検出時刻は更新しません。不在の証拠を与えられるのは成功実行だけであり、削除確定には反復確認またはレビューが必要です。
Google Places は、サイト上の住所や営業ステータスに置き換えるべきですか？
いいえ。Places は補強または検証に使い、タイムスタンプと提供元を保存し、メーカーのロケーターをディーラープログラムの正本として保持してください。
自動ディーラートラッキングが成功するのは、これをデータプロダクトとして扱うときです。すなわち、統制されたソースレジストリ、再利用可能なパターン群、残された証拠、慎重なエンティティ解決、そして業務部門が持つ変更ワークフローです。この構成なら、20サイトの試行から数百サイトへ拡張しても、レイアウト変更のたびに緊急改修へ追われることはありません。
さらに詳しく
