Google Reviews API：カスタムダッシュボード・レポート・ツールを構築する

Google Reviews APIを探しているなら、おそらくもう1つ汎用的なAPIの解説記事が欲しいわけではないでしょう。あなたが求めているのは、フィルタリングし、結合し、チャート化し、意思決定をする人たちと共有できる、テーブル形式のレビューデータのはずです。

この要望は、代理店、フランチャイズチーム、多拠点事業者からよく寄せられます。Tableauのダッシュボード、Pythonスクリプト、週次のCSVエクスポート、あるいは各プロフィールを手作業で開くことなく複数のGoogle拠点からレビューを取得する信頼できる方法が必要になるのです。

手短に言えば、答えはイエスです。プロジェクトとユーザーが必要なアクセス権を持っていれば、Googleの公式Business Profile APIでレビューを取得できます。実際のワークフローは、Google上で直接構築するのか、Localithを連携オペレーションレイヤーとして使うのか、あるいはBIツール向けに整ったCSVをエクスポートするのかによって変わります。

このガイドでは、これら3つの現実的なアプローチを取り上げ、Tableau、Power BI、Looker Studio、スプレッドシート、Pythonに向けてGoogleレビューデータをどのように構造化するかを解説します。

Google Reviews APIは存在するのか

答えはイエスですが、その名称が混乱を招いています。Googleは、レビューへのアクセスを「Google Reviews API」という独立した製品として位置づけてはいません。自社で所有または管理するプロフィールのレビューについては、公式なルートはGoogle Business Profile APIです。

Googleのレビューデータのドキュメントでは、レビューの一覧取得、単一レビューの取得、複数拠点からのレビュー取得、返信、ビジネス返信の削除について説明されています。チームがプロジェクトの承認やOAuthの設定をまだ必要としている場合は、このGoogle Business Profile APIアクセスガイドから始めましょう。

公開されている場所の情報については、開発者はPlaces APIやサードパーティのデータサービスを検討することがあります。これらの製品は異なるユースケースに向けたものです。あなたの組織が管理するビジネスプロフィールの完全なレビュー履歴をエクスポートする代替手段にはなりません。

Google Business Profile API・Places API・Localithの比較

まずは所有権とレポートに関する問いから始めましょう。あなたが扱っているのは、組織が管理する拠点でしょうか、公開されている場所の情報の検索でしょうか、それとも接続済みプロフィールの定期レポートの作成でしょうか。

選択肢	最適な用途	レビューへのアクセス	主な制約
Localithのレポートとワークフロー	多拠点のレポートとレビュー運用	接続済みGBPのレビューデータ、分析、PDF／CSVレポート、ワークフロー連携	プロフィールがLocalithに接続され、同期されている必要がある
Google Places API	公開されている場所の検索と場所の詳細	選択したエンドポイントのルールの範囲内での公開場所データ	自社所有プロフィールの完全なレビューエクスポートではない
Google Business Profile API	自社で所有または管理するビジネス拠点	アクセス可能なプロフィールのレビューとビジネス返信	APIの承認、OAuth、プロフィールの権限、エンジニアリングが必要

どのようなレビューデータを取得できるのか

レポート作成においては、APIの名称よりもデータの形が重要です。役立つエクスポートには、アナリストが正規化できる行単位の事実が含まれているべきです。

• レビューID
• レビュアーの表示名
• 星評価
• レビュー本文
• 作成日時または更新日時
• ビジネスの拠点と安定した拠点ID
• 返信がある場合は、ビジネス返信の本文と返信日時
• 拠点の平均評価と総レビュー件数

Googleのレビュー一覧取得メソッドは、ページネーションされたレビューのコレクションに加えて、拠点の平均評価と総レビュー件数を返します。個々のレビューリソースは、レビューID、コメント、レビュアー、星評価、作成日時、返信といったフィールドを公開します。

データを一元化すれば、チームはGoogleレビューをキーワードで検索して、製品、サービス、人員、アクセシビリティに関して繰り返し現れるテーマを特定することもできます。

方法1：Localithでレビューデータをエクスポートする

「もう1つAPI連携を維持できるか？」ではなく「毎週、整った多拠点のレビューデータを取得できるか？」がビジネス上の問いであるとき、Localithは実用的なルートです。マネージド型のGoogle Business Profile APIツールが、レビュー、リスティング、レポート、自動化のワークフローを接続された状態に保ちます。

ワークフローはシンプルです。

1. Localithアカウントを作成するか、サインインします。
2. 管理しているGoogleビジネスプロフィールのアカウントと拠点を接続します。
3. レポート画面を開きます。
4. 期間、拠点、レビューレポートの種類を選択します。
5. レポートをPDFまたはCSVでダウンロードします。
6. CSVをスプレッドシート、データウェアハウス、またはBIツールに読み込みます。

Localithのレビューレポートには、生のレビューデータに加えて、星評価の内訳、センチメントのグループ、総レビュー件数、返信、平均評価、最新のレビュー日といったサマリー指標を含めることができます。これにより、代理店や多拠点チームは、OAuthやページネーションのコードを保守することなく、再現性のあるオンラインレビューレポートのワークフローを手に入れられます。

定期的なワークフローにはLocalith APIアクセスとn8nを活用する

定期的な自動化のために、チームはLocalith APIキーを生成し、Localithをn8nに接続できます。Localithのn8nノードは、レビューの取得、リスティング操作、パフォーマンス指標に対応しており、これらをGoogle Sheets、Airtable、Slack、メール、その他のワークフローツールに連携できます。

スケジュールされたレビューの取り込み、アラート、または承認ワークフローが必要でありながら、下流のすべてのツールがGoogleと直接認証を行うのは避けたい場合に、このルートを使いましょう。

方法2：Tableau向けにGoogleレビューをCSVでエクスポートする

要件がTableauのダッシュボードであれば、API構築にエンジニアリングの時間を割く前に、CSVで問題が解決するかどうかを確認しましょう。月次や週次の多くのレポートでは、CSVで十分です。

次のワークフローを使いましょう。

1. Localithからレビュー単位のデータをCSVでエクスポートします。
2. Tableauを開き、データソースとしてテキストファイルを選択します。
3. レビューのエクスポートファイルを選択します。
4. 評価フィールドを数値に、レビュー日を日付に設定します。
5. 評価ごとにレビューを集計して、評価分布のチャートを作成します。
6. 拠点名または拠点IDをフィルターとして追加します。
7. 月次のレビュー件数と平均評価の推移を作成します。
8. 返信状況や返信までの時間のフィールドがある場合は、それらを追加します。
9. ワークブックを公開し、レポートの周期に合わせてソースを更新します。

CSVは、リアルタイムではなく日次・週次・月次といった周期でレポートを作成する場合に特に有効です。また、ダッシュボードを更新する前にアナリストが確認できる、目に見えるソースファイルを提供してくれます。

方法3：Google Business Profile APIでレビューを取得する

エンジニアリングのリソースがあり、プロフィールが適切なアカウント構造の下に配置されていて、アプリケーションがデータの取り込みと保存を完全にコントロールする必要がある場合は、API直接ルートを選びましょう。

現在の一覧取得エンドポイントは次のとおりです。

GET https://mybusiness.googleapis.com/v4/{parent=accounts/*/locations/*}/reviews

拠点は確認済み（verified）である必要があります。このメソッドは1ページあたり最大50件のレビューを返し、並べ替えに対応し、さらにページがある場合はnextPageTokenを提供します。https://www.googleapis.com/auth/business.manageのようなOAuthスコープが必要です。

Googleは、アクセス可能な拠点向けに一括取得メソッドも提供しています。

POST https://mybusiness.googleapis.com/v4/accounts/{accountId}/locations:batchGetReviews

複数拠点にわたってGoogleレビューを管理するチームは、ダッシュボードを設計する前に、アカウントの所有権、拠点へのアクセス、安定したIDの問題を解決しておくべきです。

Pythonワークフローの例

本番環境のワークフローは、通常次のステップに従います。

1. Business Profile APIへのアクセスが承認されたGoogle Cloudプロジェクトを作成または選択します。
2. business.manageスコープでOAuthを設定します。
3. サインインしたユーザーが利用できるアカウントを一覧取得します。
4. 選択したアカウントの拠点を一覧取得します。
5. 各拠点のレビューをリクエストします。
6. すべてのページを取得し終えるまでnextPageTokenをたどります。
7. 各レビューを1行に正規化します。
8. 各行をCSV、BigQuery、データウェアハウス、またはBI取り込み用テーブルに保存します。

ページネーションの中核部分は次のようになります。

import requests


def fetch_reviews(access_token, location_name):
    url = f"https://mybusiness.googleapis.com/v4/{location_name}/reviews"
    params = {"pageSize": 50, "orderBy": "updateTime desc"}
    headers = {"Authorization": f"Bearer {access_token}"}
    reviews = []

    while True:
        response = requests.get(
            url,
            headers=headers,
            params=params,
            timeout=30,
        )
        response.raise_for_status()
        payload = response.json()
        reviews.extend(payload.get("reviews", []))

        page_token = payload.get("nextPageToken")
        if not page_token:
            return reviews

        params["pageToken"] = page_token


# location_name example: accounts/123/locations/456

これは統合パターンの一例であり、完成した本番用クライアントではないと捉えてください。実運用の実装には、トークンの更新、バックオフを伴うリトライ、アカウントと拠点の探索、認証情報の安全な保管、ロギング、権限エラーの処理も必要です。

BIに推奨されるレビューデータモデル

モデルは意図的にシンプルに保ちましょう。1レビューにつき1つの安定した行、1拠点につき1つの安定したIDです。

フィールド	型	なぜ重要か
review_id	テキスト	インポートや更新時の重複を排除する
location_id	テキスト	レビューをリスティング、地域、クライアントに結びつける
location_name	テキスト	読みやすいダッシュボードのフィルターになる
rating	数値	平均値と星評価の分布を算出できる
review_text	テキスト	トピック、センチメント、定性分析を可能にする
review_date	日付／時刻	推移やレポート期間の集計に使える
reply_text	テキスト	ビジネスが返信したかどうかを示す
reply_date	日付／時刻	返信までの時間のレポートに使える
source	テキスト	複数のレビュープラットフォームを統合する際に役立つ

拠点のサマリー行と個々のレビュー行を同じテーブルに混在させてはいけません。レビューの事実は1つのテーブルに、拠点レベルのスナップショットは別のテーブルに保ち、location_idで結合しましょう。

エクスポートしたレビューデータで何を構築できるか

レビューデータを正規化すれば、同じパイプラインで次のようなものに対応できます。

• 多拠点のレビューダッシュボード
• 代理店のクライアントレポート
• レビュー返信のSLA追跡
• センチメントとトピックの分析
• ネガティブレビューのアラート
• 拠点間のパフォーマンス比較
• レビューのバックアップとアーカイブ
• 地域ごとの顧客体験分析

レビューデータは、運用と接続された状態を保つことで、より役立つものになります。ダッシュボードは未返信のレビューを明らかにし、文書化されたプロセスはGoogleレビューへの返信方法を示し、Googleレビューの自動返信ワークフローが適切なケースを大規模に処理します。

また、レピュテーションとローカル検索を別々の取り組みとして扱うのではなく、レビューの傾向と視認性の変化を比較したい場合には、ローカル順位トラッキングを補完することもできます。

Googleを直接使うべきか、Localithを使うべきか

シナリオ	最適なアプローチ
Google APIへのアクセスが承認されたカスタムアプリケーション	Google Business Profile API
多拠点のレビューレポート	LocalithのレポートまたはAPIワークフロー
TableauまたはPower BIのダッシュボード	CSVエクスポートまたはスケジュールされた取り込み
Slack、Sheets、Airtable、メールの自動化	Localithとn8nの組み合わせ
クライアントに提出できるレビューレポート	LocalithのPDF／CSVレポート
運用としてのレビュー返信業務	Localithのレビューワークフロー

カスタムインフラが製品要件であり、チームがそれを自ら保守できる場合は、Googleを直接使いましょう。完全なGoogle連携基盤を保守することなく、レポート、エクスポート、アラート、レビュー運用が必要な場合は、Localithを使いましょう。

プロフィールのガバナンスも必要とするチームにとっては、複数のGoogleビジネスプロフィールを管理するためのより広範なワークフローが、アカウント構造、権限、一括更新、運用管理をカバーしています。

Google Reviews APIでよくある落とし穴

失敗のほとんどは、Pythonの構文ではなく、ワークフローに関する思い込みから生じます。

• Places APIとGoogle Business Profile APIを混同する
• OAuthユーザーがアクセスできないプロフィールのレビューをリクエストする
• 未確認の拠点のレビューを一覧取得しようとする
• ページネーションを省略し、最初の50件のレビューだけをエクスポートする
• 安定したレビューIDと拠点IDを保存しない
• 行単位のレビューデータと集計指標を混在させる
• トークンの更新、リトライ、クォータの挙動を無視する
• すべてのレポートツールにリアルタイムAPIが必要だと思い込む

最後のリスクは組織的なものです。それは、データに基づいて行動する担当者を決めないままダッシュボードを構築してしまうことです。レビューのエクスポートは、担当者、返信に関する期待値、エスカレーションのルール、定期的なレポートを備えた明確なGoogleレピュテーション管理のプロセスにつなげるべきです。

Googleレビューを信頼できるレポートに変える

Google Reviews APIのワークフローが価値を持つのは、ビジネスがレビューデータに基づいて確実に行動できる手段を提供する場合だけです。その成果物は、評価の変動、レビュー件数、繰り返し現れるテーマ、未返信のレビュー、拠点レベルの外れ値を示すべきです。

エンジニアリングのリソースと、承認されたGoogle Business Profile APIへのアクセスがあれば、そのパイプラインを直接構築できます。より速く進めたい場合は、Localithを使ってプロフィールを接続し、レビューデータをエクスポートし、レポートのワークフローを構築して、分析をチームがレビューと拠点のパフォーマンスを管理するのと同じシステムに結びつけておきましょう。

何かを構築する前に、チームが自社のプロフィールに紐づくGoogleレビューを確認でき、必要なすべての拠点にアクセスでき、ダッシュボードが支えるべきレポート上の意思決定を定義できることを確認しましょう。