目次を見る
することができます。 Google Places API を使用してビジネスディレクトリを構築する 事業者を検索し、リスティング、地図、フィルター、および場所ページ用の場所データを取得するためです。事業者名、住所、座標、カテゴリ、評価、営業時間、電話番号、ウェブサイトなどは、すべてディレクトリ構造の一部として組み込むことができます。.
最初の判断は、APIリクエストを行う前に下されます。ある都市のレストランディレクトリを構築する開発者と、全国の医療提供者のディレクトリを構築するチームとでは、必要なデータセットが異なります。カテゴリ、対象地域、掲載項目、検索機能によって、ディレクトリに必要なデータや、それらのレコードをどのように整理すべきかが決まります。.
これらの要件を早い段階で計画しておくことで、ディレクトリが拡大していくにつれて、ビジネスデータの収集、構造化、表示、更新の方法をより容易に決定できるようになります。.
【手っ取り早い答え】Google Places API を使ってビジネスディレクトリを作成する方法
- ディレクトリの範囲を定義する
- 掲載項目を選択してください
- Google Places API を使用してビジネスデータを収集する
- ディレクトリレコードの構成
- ディレクトリページを作成する
- 業務データの維持・更新を行う
Watch the Business Directory Workflow
This short walkthrough shows how to plan your directory, collect business data with Google Places API, structure the records, build directory pages, and keep the data updated.
The video summarizes how to build a business directory using Google Places API, from planning the data fields to publishing and updating the listings. The next sections explain each step in more detail.
ディレクトリで対象としている場所やカテゴリについて、Google マップのビジネスデータを収集してください。.
Google Places API を使用したビジネスディレクトリの計画
明確なデータプランがあれば、何をお願いすべきか判断しやすくなります。 Google Places API また、各結果がディレクトリ内でどのように配置されるかについても検討します。まずは次の3つの質問から始めましょう:
- どのような事業が対象となるのでしょうか?
- このディレクトリの範囲はどこまでですか?
- 各掲載情報にはどのような情報が必要ですか?
事業分野および対象地域を定義する
まずはディレクトリの範囲を設定することから始めましょう。プロジェクトの対象範囲は、1つの都市における1つの業種、1つの州にわたる複数の関連業種、あるいは複数の国にわたる特定の業種など、さまざまです。.
たとえば、ディレクトリでは次のような内容に焦点を当てることができます:
- シカゴの歯科医
- カリフォルニア州のコワーキングスペース
- ドイツ各地のEV充電ステーション
- いくつかの観光地にあるレストラン
これらの選択は、場所の検索方法や検索結果の整理方法に影響を与えます。都市別のディレクトリでは場所ごとのページを多用する場合もありますが、より大規模なディレクトリでは、国、州、都市、業種に基づく階層構造が必要になる場合があります。.
早い段階で範囲を明確にしておくことは、完成したディレクトリ内で明確な配置先のないレコードが収集されるのを防ぐのにも役立ちます。.
ディレクトリに必要な事業分野を選択してください
次のステップは、各掲載情報にどのような情報を掲載すべきかを決定することです。具体的な項目は、ユーザーがディレクトリ内の事業者を検索・比較する際に何を必要としているかによって異なります。.
ディレクトリによく見られるフィールドには、次のようなものがあります:
| フィールド | ディレクトリの活用例 |
|---|---|
| 商号 | 物件タイトル |
| 住所 | 位置情報 |
| 座標 | マップ上の配置 |
| 事業形態 | カテゴリとフィルタ |
| 電話番号 | 連絡先 |
| Webサイト | ビジネス用ウェブサイトのリンク |
| 評価 | 企業情報 |
| 営業時間 | 在庫状況 |
| プレイスID | Googleプレイスへのリンク |
単に利用可能だという理由だけで、入力を求める項目を追加するのは避けましょう。まずはディレクトリの利用体験に必要な情報から始め、明確な目的がある場合にのみ項目を追加してください。.
掲載情報の整理方法を計画する
データ構造は、ユーザーがディレクトリをどのように閲覧するかを反映したものであるべきです。ほとんどのプロジェクトでは、個々の企業ページだけでは不十分です。.
ディレクトリでは、同じレコードを次のように整理することができます:
- カテゴリページ(例:
/歯科医/ - 以下のようなロケーションページ、例えば
/chicago/ - カテゴリおよび場所のページ(例:
/chicago/dentists/ - 各企業のページ
- 地図または検索結果
データ収集の前にこれらのページタイプを計画しておくことで、フィルタリング、グループ化、URL、地図、および個々のリスト表示にどのフィールドが必要になるかを特定しやすくなります。.
ディレクトリの範囲、フィールド、およびページ構造が定義されたら、それらの要件をGoogle Places APIの検索やリクエストに反映させることができます。.
Google Places API を使ってビジネスデータを収集する
ディレクトリに必要な業種や分野がわかったら、次のステップは該当する場所を取得することです。Google Places API では、ディレクトリが検索語、地域、または既知の場所のいずれから始まるかによって、異なる検索方法が用意されています。.
ビジネスディレクトリの場合、一般的な流れとしては、まず該当する企業を見つけ、その後、各掲載情報に必要な詳細情報を依頼するというものです。.
テキスト検索や周辺検索で店舗を探す
テキスト検索 この機能は、ディレクトリ検索で業種、名称、その他の検索語と場所を組み合わせて検索する場合に有効です。たとえば、次のようなクエリでは シカゴの歯科医 また ベルリンのコワーキングスペース これはわかりやすい例です。.
周辺検索 これは、特定の地域から検索を開始する場合に役立ちます。指定した場所周辺の場所を検索することができ、近接性が検索体験の一部となっているディレクトリサイトなどで効果を発揮します。.
The right method depends on how the directory defines its coverage.
The process of finding local businesses with Google Places API also requires choosing the appropriate search parameters, selecting business data fields, and accounting for result limits before using the records in a directory.
A category-and-city directory may start with text-based searches, while a location-based application may rely more on coordinates and nearby searches.
最初のデータ収集にあたっては、クエリを先に定義した範囲に合わせてください。例えば、対象がシカゴの歯科医である場合、関係のない事業者を収集してから後でフィルタリングするのではなく、そのカテゴリーと地域に合わせて収集プロセスを設計する必要があります。.
プレイスIDとプレイスの詳細情報の活用
ディレクトリレコードに場所IDを保持しておくことで、アプリケーションがその場所を再度扱う必要が生じた際、参照先として利用できるようになります。.
ディレクトリに必要なフィールドのみをリクエストする
前のセクションで計画されたフィールドの一覧に基づいて、アプリケーションが何を要求するかを決定する必要があります。.
基本的なディレクトリ掲載情報には、名称、カテゴリ、住所、座標だけで十分な場合もあります。詳細なビジネスページには、電話番号、ウェブサイト、営業時間、評価、その他対応している情報も必要になる場合があります。.
実際の使用状況に基づいてフィールドをリクエストすることで、APIのワークフローをディレクトリに密接に結びつけることができ、目的もなく情報を収集してしまうことを防げます。.
また、ページの種類ごとにフィールドを分けておくのも有効です。検索結果には最小限の情報で済む場合もありますが、個々のビジネスページでは、必要に応じて追加の詳細情報を要求することができます。.
ディレクトリ検索のための Google Places API の例
収集のワークフローは、次のようなものになるでしょう:
- 対象地域内の歯科医を検索します。.
- Google Places API から一致する場所を取得します。.
- Place ID と、ディレクトリに必要なフィールドは残しておいてください。.
- 掲載情報で追加の場所の詳細が求められている場合は、その詳細をリクエストしてください。.
- 返されたフィールドを、ディレクトリのレコード構造にマッピングします。.
- それらの記録を利用して、歯科医院のリストや、関連する地域・カテゴリのページに情報を掲載してください。.
カテゴリ、場所、およびフィールドを変更することで、この同じパターンを他のディレクトリにも再利用できます。ロンドンのジムやシドニーの動物病院のディレクトリであっても、レコードやページの要件は異なるかもしれませんが、基本的なデータの流れは同じです。.
この段階では、APIのレスポンスを、ディレクトリで利用できる一貫性のある構造に変換する必要があります。次のステップは、返された各フィールドをビジネスレコードにどのように対応させるか、またそれらのレコードがディレクトリのページをどのように支えるかを決定することです。.
Google Places API の検索結果をディレクトリ掲載情報に変換する
Google Places API から返されるビジネスデータは、ディレクトリページ全体で利用できるようになる前に、一貫性のある構造に整える必要があります。各施設は、識別情報、所在地、カテゴリ、連絡先情報、およびプロジェクトで選択されたその他の情報を含むフィールドを持つディレクトリレコードとして登録されます。.
これらの記録は、また、 地域企業データベース ディレクトリ全体で使用される情報を格納するものです。.
一貫性のあるレコード構造があれば、検索結果、カテゴリページ、所在地ページ、地図、個々のリスティングなど、さまざまな場所で同じビジネスデータを容易に活用できるようになります。.
Map Places API のフィールドをディレクトリ構造にマッピングする
まず、各APIフィールドをディレクトリ内のフィールドに紐付けます。.
たとえば、ディレクトリレコードには次のような内容が含まれる場合があります:
| ディレクトリフィールド | 場所のデータ | 用途 |
|---|---|---|
| 商号 | 表示名 | 掲載情報とビジネスページ |
| プレイスID | 場所識別子 | その場所について言及する |
| 住所 | 書式設定済みの住所 | 物件情報および所在地情報 |
| 緯度/経度 | 位置座標 | 地図と位置検索 |
| 事業形態 | 場所の種類 | カテゴリとフィルタ |
| 電話番号 | 電話番号欄 | 連絡先 |
| Webサイト | Webサイトのフィールド | ビジネス用ウェブサイトのリンク |
| 評価 | 評価欄 | 物件情報 |
| 営業時間 | 営業時間データ | 事業の利用可能性 |
ディレクトリのすべての箇所で、保存されているすべてのフィールドを表示する必要はありません。検索結果には、会社名、カテゴリ、住所、評価が表示される場合がありますが、個々の掲載ページでは、さらに詳しい情報を表示することができます。.
基となるレコードの一貫性を保つことで、さまざまな種類のページで必要なフィールドを利用できるようになります。.
未入力の項目や重複する事業者の処理
すべての事業情報に同じ情報が記載されているわけではありません。ある事業者の情報にはウェブサイト、電話番号、営業時間などが記載されている一方で、別の事業者については基本的な所在地情報しか表示されない場合もあります。.
ディレクトリは、すべてのフィールドが存在すると仮定するのではなく、欠落値に対応できるようにすべきです。たとえば、リスト表示テンプレートでは、ウェブサイトが存在しない場合、空のフィールドを表示するのではなく、ウェブサイトボタンを非表示にすることができます。.
複数の検索を通じて業務データを収集する場合、重複データの処理も重要です。例えば、歯科医は次のような検索で表示される可能性があります。 シカゴの歯科医 さらに、周辺地域を対象とした別の捜索も行われた。.
Place ID を使用すると、同じ Google プレイスを指すレコードを特定するのに役立ちます。新しい結果を追加する前に、アプリケーションはその Place ID がディレクトリにすでに存在するかどうかを確認できます。.
これにより、繰り返し検索を行った際に、同じ出品が自動的に重複して作成されるのを防ぐことができます。具体的な例については、当社のガイドで解説しています。 ローカルの企業ディレクトリを更新する際の重複レコードの処理.
カテゴリ、所在地、およびビジネスページの作成
レコードの構造が統一されれば、同じデータセットでディレクトリの複数の部分をカバーできるようになります。.
たとえば、歯科医のディレクトリでは、その記録を利用して次のようなものを作成することができます:
- 「歯科医」のメインカテゴリページ
- 都市や地域のページ
- 各地域の歯科医院一覧
- 各企業のページ
- 検索結果の地図表示
- 利用可能な事業分野に基づくフィルター
したがって、シカゴの歯科医の記録は、次の両方に掲載される可能性がある。 歯科医師 カテゴリページと シカゴ 自社のビジネスリスティングへのリンクを掲載したロケーションページ。.
この構造により、ディレクトリの拡張余地も確保されています。別の都市や業種カテゴリを追加する場合でも、別途データ形式を作成する必要はありません。新しいレコードは同じ構造に従って作成し、適切なカテゴリと場所に割り当てることができます。.
その結果、Google Places API が場所に関する情報を提供し、アプリケーションがそれらのレコードの保存方法、グループ分け、および訪問者への表示方法を決定するディレクトリが作成されます。.
これらの記録をどのように活用できるか、ご覧ください。 検索機能と構造化された企業情報掲載機能を備えた地域ビジネスディレクトリを構築する.
コスト、データ規則、およびディレクトリのメンテナンスへの対応
ディレクトリが拡大するにつれて、APIの利用状況、Googleのデータに関するルール、および企業情報の変更という3つの点を考慮してください。.
APIリクエストとフィールドの使用を制御する
Places API(新機能)では、 フィールドマスク APIリクエストがどの情報を返すかを指定するためです。リクエストするフィールドによっては、適用される課金プランに影響する場合もあります。.
ディレクトリに必要なフィールドのみをリクエストしてください。検索ページでは基本的な事業内容や所在地情報を使用する場合がありますが、個々の掲載情報では、ウェブサイト、電話番号、評価、営業時間などの追加フィールドが必要になる場合があります。.
これにより、APIリクエストの目的が明確になり、掲載件数が増えても利用状況を管理しやすくなります。.
「場所データの保存に関する規則」を確認してください
現在の状況を再確認する Google Maps Platformの利用規約 ディレクトリにどのような情報を保存するかを決定する前に、Places API のポリシーを確認してください。.
Googleでは、一部のマップコンテンツのキャッシュや保存について制限を設けています。. 場所IDを保存できます, そのため、アプリケーションで再びその場所を扱う必要が生じた際の参考資料として役立ちます。.
ディレクトリを本番環境に導入する前に、データの保存、出典の明記、および表示に関する現在の要件を確認してください。.
ビジネス情報を常に最新の状態に保つ
企業情報は変更されることがあります。掲載開始から数ヶ月後には、営業時間、電話番号、ウェブサイト、住所、営業状況などが当初の情報と異なる場合があります。.
ディレクトリが重要なレコードをどのように再確認するか、また情報が欠落したり変更されたりした場合にどのように対処するかを計画してください。また、Googleでは、保存されているPlace IDのうち、12か月以上経過しているものは更新することを推奨しています。.
更新の頻度は、ディレクトリの規模や目的によって異なります。重要なのは、最初のAPIレスポンスを恒久的なものとして扱うのではなく、重要なリスト情報を常に最新の状態に保つためのプロセスを確立することです。.
ビジネスディレクトリでOutscraperをいつ使用すべきか
Google Places API を直接活用することで、開発者はアプリケーション内での場所の検索や事業者の詳細情報の利用方法を制御できるようになります。一部のディレクトリプロジェクトでは、収集プロセス全体を構築・維持することよりも、事業者のデータを大規模に収集することが主な要件となります。.
アウトスクレーパー これは、大量のレコード、構造化されたエクスポート、またはAPIベースのデータ収集を必要とするディレクトリ向けに、Googleマップのビジネスデータを収集する別の方法を提供します。.
抽出することができます Google マップのビジネス情報 ご自身のデータベース、ディレクトリ、またはアプリケーションで使用してください。.

Google マップのビジネスデータを、以下の方法を通じて収集する API その結果を、ディレクトリ、データベース、またはアプリケーションで活用してください。.
Google Places API 対 一括ビジネスデータ収集
適切なアプローチは、そのディレクトリにどのような機能が必要かによって異なります。.
| 要件 | Google Places API | アウトスクレーパー |
|---|---|---|
| アプリケーション内の場所を検索する | 対応済み | 異なる主なユースケース |
| 既知の場所に関する情報を取得する | 対応済み | ビジネスデータワークフローを通じて利用可能 |
| 多くの業務記録を収集する | APIリクエストの計画が必要 | 一括収集に対応しています |
| ノーコードによるビジネスデータの収集 | 別のワークフローが必要です | Google Mapsスクラッパーが利用可能になりました |
| プログラムによるデータ収集 | Googleの「Places」機能を通じてサポートされています | Google Maps API が利用可能です |
| 収集したレコードをエクスポートする | アプリケーションが保存とエクスポートを処理します | 利用可能なデータセットのエクスポートオプション |
アプリケーションに実店舗検索機能を組み込む開発者は、Google Places APIを直接利用することを好むかもしれません。一方、ディレクトリデータセットを構築するチームは、多くの企業レコードを収集し、収集プロセス以外でも利用できるよう準備することに重点を置くかもしれません。.
ノーコードまたはAPIベースの収集機能を使用する
Outscraperでは、プロジェクトに応じて、Googleマップのビジネスデータを収集するさまざまな方法を提供しています。.
NS グーグルマップスクレーパー ビジネスレコードを収集するためのノーコードの選択肢を提供します。これは、チームが独自の収集アプリケーションを事前に構築することなく、ディレクトリ用のデータセットを必要とする場合に役立ちます。.
プログラムによるワークフローの場合、 Outscraper Google Maps API ビジネスデータの収集をアプリケーションや自動化されたプロセスの一部として組み込む必要がある場合に利用できます。.
こうして収集された記録は、ディレクトリアプリケーションにデータ収集のすべての工程を任せるのではなく、ディレクトリのデータベースやページ生成プロセスに反映させることができます。.
ディレクトリに適したワークフローを選択してください
その決定は、結局のところ、アプリケーションの要件次第です。.
アプリケーションの機能に場所の検索や場所の詳細が含まれる場合は、Google Places API を使用してください。プロジェクトが主に以下の点に重点を置いている場合は、Outscraper の採用を検討してください。 業務記録を一括で収集したり、業務データをエクスポートしたり、チームが維持管理する必要のあるデータ収集インフラの規模を縮小したりすること.
どちらのアプローチもビジネスディレクトリプロジェクトを支援できますが、データワークフローの異なる部分を担っています。.
ビジネスディレクトリ構築のための最終チェックリスト
ディレクトリを公開する前に、以下の点を確認してください:
- 事業分野と拠点を定義してください。.
- 各掲載情報に必要な項目を選択してください。.
- 必要な業務データを収集してください。.
- データをディレクトリレコードに整理する。.
- 業務情報の更新方法を計画してください。.
- 公開する前に、ディレクトリをテストしてください。.
必要なGoogleマップのビジネスデータを収集するには、 アウトスクレーパー さあ、今日からディレクトリ作りを始めましょう。.
よくある質問
最も頻繁な質問と回答
はい。Google Places API を使用すると、企業を検索し、ディレクトリ掲載情報の場所情報を取得できます。その後、アプリケーションでは、それらの検索結果をカテゴリ、場所、地図、および個々の企業ページごとに整理することができます。.
まずは、ディレクトリ内で明確な目的を持つフィールドから始めましょう。これには、会社名、住所、座標、業種、電話番号、ウェブサイト、評価、営業時間、Place IDなどが含まれます。.
Googleでは、一部のマップコンテンツの保存やキャッシュに関するルールが定められているため、データベースに何を保存するかを決定する前に、最新のGoogle Maps Platformポリシーを確認してください。場所のIDは保存しておき、後でその場所を参照するために使用することができます。.
情報の収集後、事業内容に変更が生じる可能性があるため、重要な記録は再度確認するようにしてください。特に、住所、電話番号、ウェブサイト、営業時間、営業状況などの情報には細心の注意を払ってください。.
はい。Outscraperでは、Googleマップのビジネスデータを収集するためのノーコードおよびAPIオプションを提供しています。データ収集プロセス全体を自ら管理することなく、必要なビジネスレコードを収集し、それらを活用してディレクトリを構築することができます。.