Googleビジネスプロフィール投稿の自動化|公式APIの申請から注意点まで実務解説

Googleビジネスプロフィール投稿の自動化|公式APIの申請から注意点まで実務解説

Googleビジネスプロフィール(旧Googleマイビジネス)の投稿を自動化したい。店舗ビジネスの集客支援をしていると、この相談は本当に多いです。毎週の投稿が続かない、店舗数が増えて手が回らない、というのが典型的な動機です。

先に結論をまとめます。

  • **Googleビジネスプロフィールの投稿自動化は、Googleの公式API(Business Profile API)を使うのが正攻法**。ただし利用には申請と承認が必要
  • 承認は「1ビジネス(会社)につき1つのGCPプロジェクト」が原則。申請の重複や、承認後の放置には落とし穴がある
  • **承認されたら、できるだけ早く実際のAPIコールまで通すこと**。ここを空けると、せっかくの承認が意味をなさなくなるリスクがある
  • 非公式ルート(管理画面のブラウザ自動操作など)は規約面・保守面のリスクが大きく、事業で使う仕組みとしてはおすすめしない

当社は名古屋でWEB制作とLINE公式アカウント支援をしている会社です。実際に、支援先である愛知県の美容サロンFC(多店舗展開)のGoogleビジネスプロフィール投稿を自動化するために、公式APIの申請から実装準備まで一通り経験しました。その過程で得た「事前に知っておけば防げるハマりどころ」を、この記事で共有します。

そもそも公式APIで何ができるのか

Google Business Profile APIは、ビジネスプロフィールの情報をプログラムから操作するための公式APIです。用途に応じて複数のAPIに分かれています。

  • **My Business Account Management API**:アカウントとロケーション(店舗)の一覧取得・管理
  • **My Business Business Information API**:店舗名・住所・営業時間などの基本情報の管理
  • **Business Profile Performance API**:閲覧数・検索数などのパフォーマンスデータ取得
  • **投稿(ローカル投稿)系のエンドポイント**:いわゆる「最新情報」の投稿作成

投稿自動化の基本フローはシンプルで、「アカウント配下のロケーション一覧を取得(accounts.locations.list)→ 対象ロケーションのIDを特定 → 投稿作成のエンドポイント(localPosts.create)を叩く」という流れです。技術的には難しくありません。**難所はコードではなく、その手前の申請・承認・認証まわりにあります。**

最大のハードル:APIは申請制で、承認には条件がある

Business Profile APIは、GoogleのAPIライブラリで「有効化」ボタンを押すだけでは使えません。**利用申請フォームから申請し、Googleに承認(allowlist登録)されて初めてクォータ(利用枠)が付与されます。**

ここで重要なのが「**1ビジネスにつき1プロジェクト**」の原則です。当社の実例では、承認済みの状態を正確に把握しないまま別途申請を出したところ、「あなたの会社にはすでにallowlistに登録されたプロジェクトがあります。1ビジネスにつき1プロジェクトです」という趣旨の定型返信が返ってきました。つまり、**社内で誰がいつどのGCPプロジェクトで申請したかを記録しておかないと、「承認は済んでいるはずなのに、どのプロジェクトが有効なのか分からない」という状態に陥ります。**

対策はシンプルです。

1. 申請時に「GCPプロジェクト名・プロジェクト番号・申請日・申請に使ったGoogleアカウント」を必ず記録する

2. 承認メール(Googleビジネスプロフィールのサポート窓口から届く)は削除せず保管する。記載のチケット番号が後の問い合わせで効く

3. 多店舗展開の場合も、店舗ごとにプロジェクトを分けない。同じ会社なら同一プロジェクトに店舗を追加していく

承認後に「放置」するとどうなるか:クォータ失効のリスク

ここが今回いちばん伝えたい注意点です。

APIの承認が下りると、通常はプロジェクトにクォータ(1分あたりのリクエスト数など)が付与されます。ところが、**承認後にAPIを一度も使わないまま長期間放置すると、クォータが0にリセットされることがあります。**

当社の実例では、承認から約3ヶ月、サイト制作など他の作業を優先してAPIコールを行わずにいたところ、いざ実装を始めた段階で `429 RESOURCE_EXHAUSTED` エラーが返り、詳細を確認すると `quota_limit_value: "0"`、つまり**利用枠そのものがゼロ**になっていました。OAuth認証は正常に通り、アクセストークンも取得できるのに、肝心のAPIが1回も叩けない。認証エラーではないため、原因の切り分けに時間がかかる厄介な状態です。

こうなると、Googleのサポートフォームからプロジェクト番号を明記して再度問い合わせる必要があり、審査・返信待ちの期間がまるごと手戻りになります。

**予防策は「承認されたら即、疎通確認まで済ませる」こと。** 具体的には、承認メールを受け取ったらその週のうちに、ロケーション一覧の取得(accounts.locations.list)だけでも実行しておくことを強くおすすめします。本格実装は後回しでも構いません。「承認 → 放置 → 実装開始時にクォータ0」という流れは、スケジュールへの打撃が大きい割に、30分の疎通確認で防げます。

OAuth設定の落とし穴:「テスト中」のままだとトークンが7日で切れる

もう一つ、実装前に必ず押さえておきたいのがOAuth同意画面の公開ステータスです。

自動投稿の仕組みでは、初回に取得したリフレッシュトークンを使って、以後は無人でアクセストークンを更新し続けます。ところが、**GCPのOAuth同意画面が「テスト中」ステータスのままだと、リフレッシュトークンは7日で失効します。** 開発中は動いていたのに、運用開始から1週間後に突然認証エラーで止まる、という事態が起こり得るということです。

無人運用を前提にするなら、OAuth同意画面を「本番環境」に切り替えてから、リフレッシュトークンを取得してください。外部公開アプリとしての検証(審査)が未完了でも、自社利用の範囲であれば本番環境ステータスへの切り替え自体は可能です。当社でもこの切り替えを行った上で、長期運用可能なトークンを取得しています。

初回のトークン取得は、GoogleのOAuth 2.0 Playgroundをリダイレクト先に指定する方法が手軽です。認可コードの受け口を自前で実装しなくても、client_idとclient_secretを設定すればリフレッシュトークンまで取得できます。

「公式API以外」の選択肢をどう判断するか

申請や審査に時間がかかると、別ルートを検討したくなります。実際に検討の俎上に載りやすいのは次の2つです。

**1. Zapier・Make などのノーコード連携ツール**

これらのツール経由でもGoogleビジネスプロフィールへの投稿は可能です。ただし、月額コストが継続的に発生し、仕組みの中核を他社サービスに依存することになるため、仕様変更や値上げの影響を直接受けます。自社で仕組みを持ちたい・運用を内製化したい事業者には、長期的には公式APIを直接使うほうが合理的というのが当社の判断です。

**2. 管理画面のブラウザ自動操作(RPA)**

business.google.com の管理画面をスクリプトで自動操作する方法も技術的には考えられますが、おすすめしません。理由は3つあります。(1) 利用規約上グレーであること、(2) ログインセッションの維持が不安定で、二段階認証や不審なログイン検知に引っかかりやすいこと、(3) 管理画面のUI変更のたびに壊れること。「動くには動くが、事業のインフラとして任せられない」仕組みになりがちです。

当社もクォータ問題で足止めされた際にこれらの代替案を比較検討しましたが、最終的には**公式APIのクォータ回復をGoogleサポートに正面から依頼して待つ**方針を取りました。急がば回れですが、無人で長期運用する仕組みの土台は公式ルートに置くべきだと考えています。

実装前チェックリスト

これから取り組む方向けに、当社の経験を踏まえた確認項目をまとめます。

1. **GCPプロジェクトを1つ決める**(会社で1つ。既存申請の有無を先に社内確認)

2. **API利用申請を出す**(プロジェクト番号・申請日・使用アカウントを記録)

3. **承認メールを保管する**(チケット番号つきで後の問い合わせに使う)

4. **承認されたらその週のうちに疎通確認**(ロケーション一覧の取得まで実行し、クォータが生きていることを確認)

5. **必要なAPIを有効化**(Account Management / Business Information / Performance など用途分を忘れず)

6. **OAuth同意画面を「本番環境」へ切り替えてからリフレッシュトークンを取得**(テスト中のままだと7日で失効)

7. **認証情報の保管ルールを決める**(client_secret・リフレッシュトークンは機密として管理し、コードに直書きしない)

8. **投稿処理の実装**(locations.list → localPosts.create の順で。エラー時の通知も忘れずに)

まとめ:技術より「段取り」で決まる

Googleビジネスプロフィールの投稿自動化は、コードを書く部分だけ見れば半日仕事です。しかし実際のプロジェクトでは、**API申請の承認待ち、プロジェクトの重複管理、クォータの維持、OAuthステータスの設定**といった段取りの部分が所要期間の大半を占めます。

特に「承認後の放置でクォータが失効し得る」「OAuth同意画面がテスト中のままだとトークンが7日で切れる」の2点は、事前に知っているかどうかで数週間の差がつくポイントです。

当社では美容室・店舗ビジネス向けに、Googleビジネスプロフィールを含むSNS・ブログ発信の自動化の仕組みづくりを支援しています。多店舗展開で投稿運用に手が回っていない、社内に仕組みを持ちたいという方は、お気軽にご相談ください。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

上部へスクロール