Googleビジネスプロフィールの複数店舗管理｜一括運用の始め方

目次 4 SECTIONS

店舗が3つのうちは、店長それぞれに管理画面を触ってもらう運用でも回ります。これが8つ、15と増えたあたりで、誰がどのアカウントでログインしているのか分からなくなり、退職した店長のGoogleアカウントにしかオーナー権限がない拠点が出てきます。

多店舗のGoogleビジネスプロフィール運用でつまずくのは、たいてい情報の中身ではなく体制のほうです。営業時間の一括更新ができないことよりも、権限が散らばっていて誰も全体を把握できないことのほうが、実務では重くのしかかります。

Googleは拠点数が一定を超えた事業者向けに、グループ単位の権限管理と、スプレッドシートによる一括管理、そして一括でのオーナー確認という仕組みを用意しています。ここでは公式ヘルプで確認できる範囲に絞って、それぞれが何を解決するのか、どの順番で移行すればよいのかを整理します。

複数店舗の管理はどこから難しくなるのか

Googleビジネスプロフィールのヘルプでは、ビジネス拠点が10以上ある場合に、一括での追加・オーナー確認・管理ができると案内されています。裏を返せば、9拠点までは個別に登録・確認していく前提の作りになっています。

実務上の分岐点も、この10という数字と近いところにあります。私たちが支援した範囲では、次の3つが同時に起きたときに個別管理が限界を迎えていました。

• 拠点ごとに別のGoogleアカウントでオーナー確認を取ってしまっている
• 営業時間や臨時休業のように、全店に同じ変更をかける作業が月に何度も発生する
• 担当者の異動・退職のたびに、権限の引き継ぎ漏れが起きる

このうち3つ目がもっとも厄介です。オーナー権限が個人のGoogleアカウントに紐づいたままだと、その人が組織を離れた時点で、プロフィールの主導権を取り戻す作業が発生します。

権限の集約を先に済ませる理由

Googleは、ポリシー違反によってアカウント全体が制限された場合、そのアカウントの管理下にあるすべてのプロフィールの掲載が停止されると説明しています。権限が個人アカウントに散らばっている状態は、逆に言えば、1つのアカウントの問題が全店に波及する構造でもあります。

だからこそ、情報の一括更新よりも先に、権限の集約から着手するほうが安全です。

管理体制の選択肢を整理する

公式に用意されている仕組みと、それぞれが解決する範囲は次のとおりです。

手段	何ができるか	向いている規模	注意点
個別ログイン	拠点ごとに1つずつ管理	〜数店舗	ユーザー名とパスワードの共有は避けるべきとされている
ビジネス拠点グループ	複数プロフィールを1つの単位にまとめ、オーナー・管理者を割り当てる	全規模。多店舗なら必須	ビジネスまたはブランドごとに1グループが推奨されている
スプレッドシートでの一括管理	全拠点の情報を1つの表で入力・更新する	10拠点以上	スプレッドシートのアップロードではホテル属性を更新できない
一括オーナー確認（チェーン）	まとめてオーナー確認を申請する	同一ビジネスのプロフィールが10件以上	重複・停止中のプロフィールは件数に数えられない

ビジネス拠点グループについて、ヘルプは「プロフィールの共有フォルダのようなもの」と説明しています。ユーザー名とパスワードを共有する代わりの、安全な共同管理の方法として位置づけられている点が重要です。

ビジネス拠点グループへ移行する

グループはプロフィールの入れ物であり、権限はグループ単位で付与します。オーナーと管理者という2つの役割があり、いずれもグループ内でプロフィールを作成・編集・削除できるとされています。

移行はおおむね次の順で進めます。

1. 会社として管理するGoogleアカウントを1つ決める（個人の私用アカウントは避ける）
2. そのアカウントでビジネス拠点グループを作成する
3. 既存のプロフィールをグループへ移管する
4. 店長・エリアマネージャー・代理店などに、グループ単位で権限を割り当てる
5. 個人アカウントに残っている個別の権限を棚卸しし、不要なものを外す

3の移管でつまずくケースが多いので、先に「どのプロフィールが、どのアカウントの管理下にあるか」の一覧を作っておくと手戻りが減ります。オーナー権限が社外の制作会社に残っている、というのは珍しい話ではありません。

拠点の移転には注意が要る

ヘルプでは、ビジネスの概要や性質が大幅に変わるような編集は多くの場合不正行為であると指摘されており、拠点を移転する場合は既存のプロフィールに閉業のマークを付け、新しいプロフィールを作成する必要があるとされています。

移転を住所の書き換えだけで済ませようとすると、ポリシー上の問題になりうるということです。多店舗運用では移転・閉店が定期的に発生するため、この手順は運用フローに組み込んでおくほうが安全です。

一括管理と一括オーナー確認の条件

拠点が10以上になったら、スプレッドシートでの一括管理を検討する段階です。ヘルプに沿うと、流れは次のようになります。

1. ビジネスのドメインと同じメールアドレスでGoogleアカウントを用意する
2. ビジネス拠点グループを作成する
3. 全店舗の情報を1つのスプレッドシートに入力する
4. スプレッドシートをアップロードする
5. エラーを修正してから公開する
6. 一括オーナー確認をリクエストする
7. 以降はダッシュボードまたはスプレッドシートから更新する

一括確認の申請は、ビジネス プロフィール マネージャーの「オーナー確認」から「チェーン」を選び、フォームに必要事項を入力して送信します。条件は、スプレッドシートに同じビジネスのプロフィールが10件以上含まれていること。重複しているものや停止中のものは、この件数に数えられません。あわせて、ビジネスの規模を示す証拠を求められます。

審査の所要日数はヘルプに明示されていません。追加情報が必要な場合はGoogleから連絡があり、完了すると確認メールが届く、という案内にとどまります。繁忙期の直前に申請を始めるのは避けたほうが無難です。

スプレッドシート運用の落とし穴

一括アップロードは強力ですが、上書きの単位が「表の内容」になります。誰かが手元のコピーを編集してアップロードすると、別の担当者が管理画面で入れた最新の変更が巻き戻ります。

• 正本となるスプレッドシートを1つに決め、編集権限を絞る
• 管理画面での直接編集を「する／しない」で運用を統一する
• ホテル属性はスプレッドシートでは更新できないため、該当業種は別の手順を用意する

このあたりを決めずに導入すると、情報の不整合がかえって増えます。

ツールを入れる前に決めておくこと

多店舗運用の支援ツールは各社から出ており、当社もLocalBuzzという自社製品を提供しています。ただ、ツールを比較する前に決めておくべきことがあります。

そもそも、権限の集約とスプレッドシートでの一括更新までは、Googleの標準機能だけで完結します。月次の情報更新と投稿がやりたいことのすべてなら、追加のツールなしで運用できる規模は思っているより広いはずです。

外部ツールの検討が現実的になるのは、次のような要件が加わったときです。

要件	標準機能での可否	補足
全店の営業時間・臨時休業の一括更新	できる	スプレッドシートまたはダッシュボード
権限の集約と共同管理	できる	ビジネス拠点グループ
拠点ごとの順位や流入の時系列比較	標準では手作業になる	インサイトの取得・蓄積を自前で行う必要がある
口コミの一元受信と返信の承認フロー	標準では手作業になる	拠点数に比例して負荷が増える
本部と店舗で編集できる項目を分ける	標準の権限区分では細かく分けられない	役割はオーナー／管理者の区分が基本

判断の順番としては、標準機能で回らない業務が具体的に挙がってから、その業務を解決する製品を比較する、という流れをおすすめします。先に製品を並べると、必要のない機能で比較することになりがちです。

よくある質問

拠点が10未満でもビジネス拠点グループは使えますか

使えます。一括オーナー確認には10件以上という条件がありますが、グループ自体に拠点数の下限は示されていません。むしろ2〜3拠点の段階でグループに集約しておくほうが、後の移行が楽になります。

一括オーナー確認はどれくらいで完了しますか

ヘルプに所要日数の記載はありません。追加情報が必要な場合はGoogleから連絡があり、完了すると確認メールが届くと案内されています。時期を保証できないため、キャンペーンや新店の開業に合わせた逆算は避けてください。

代理店に運用を任せている場合、権限はどうすべきですか

事業者側がオーナー権限を保持し、代理店には管理者権限を渡す形が扱いやすくなります。オーナー権限まで社外に渡していると、契約終了時に権限の回収が必要になります。契約前に、権限の種類と返却の手順を書面で決めておくことをおすすめします。

1つの拠点でポリシー違反があると、他の店舗にも影響しますか

ポリシー違反によってアカウント全体が制限された場合は、そのアカウントの管理下にあるすべてのプロフィールの掲載が停止されるとGoogleは説明しています。個別のプロフィールの停止で済むか、アカウント全体に及ぶかはケースによりますが、全店に波及しうる構造であることは前提に置いてください。

スプレッドシートで更新できない項目はありますか

ホテル属性はスプレッドシートのアップロードでは更新できないとされており、APIまたはダッシュボードでの操作が必要です。宿泊業では、一括管理と個別操作を組み合わせる前提で運用設計してください。

本記事の手順・仕様は2026年9月時点のものです。Googleの仕様は変更されることがあります。