複数店舗のMEO対策で変更内容を管理｜店舗情報・担当・理由を記録

多店舗MEOの変更履歴を、店舗情報・変更前後・担当者・理由とともに確認している業務デスクのイメージ

複数店舗のGoogleビジネスプロフィール（GBP）を運用していると、「営業時間が変わっているが、誰が直したのか分からない」「店名を戻したら、別の担当者が再び変更した」といった問題が起こります。

多店舗MEOでは、最新情報を一元管理するだけでは不十分です。必要なのは、誰が・いつ・どの店舗の・どの項目を・何から何へ・なぜ変更したのかを追跡できる状態です。

GBPにはオーナーや管理者などの権限があります。ただし、自社の承認理由や変更前後の値まで含めた業務用の記録を、自動的に作ってくれるわけではありません。

この記事の答えは次のとおりです。現在の正しい情報の一覧と、変更の経緯を残す記録（変更履歴台帳）を分け、変更は1変更1行で記録します。承認の重さは変更のリスクに応じて変え、Googleに反映されたことを確認するまでを1件の変更として管理します。

GoogleスプレッドシートやExcelでも始められるよう、変更履歴台帳の項目、リスクに応じた承認ルール、店舗と本部の役割分担、問題が起きたときに元の状態へ戻す方法の順で整理します。変更履歴台帳を運用する前提となる本部・店舗・外部会社の役割設計は、MEOの体制構築・内製外注の判断基準で整理しています。

多店舗MEOでは「現在の店舗情報」だけでなく「変更履歴」を管理する

最初に整えるのは、全店舗の最新情報をまとめたマスター台帳と、変更の経緯を残す変更履歴台帳を分けることです。2つを分けておけば、「今、何を掲載すべきか」と「なぜ今の値になったのか」を別々に確認できます。

マスター台帳には、現在正しいと判断している店名、住所、電話番号、営業時間、カテゴリ、WebサイトURLなどを保存します。一方、変更履歴台帳には、「その情報が、いつ、誰によって、どのような理由で変更されたか」を1変更1行で記録します。

この記事で扱う管理表は、次の4つです。中心になるのは変更履歴台帳で、残りの表はそれを支える位置づけです。

管理表	主な役割	確認できること
店舗情報マスター	現在の正しい情報を管理	今、何を掲載すべきか
変更履歴台帳	過去の変更を記録	誰が、いつ、何を、なぜ変えたか
権限管理表	GBPを操作できる人を管理	誰が変更できる状態か
異常・復旧記録	意図しない変更への対応を記録	何が起き、どう戻したか

このうち、中心になる店舗情報マスターと変更履歴台帳の違いを図にまとめると、次のようになります。

店舗情報マスターは現在の正しい情報、変更履歴台帳はその値に至るまでの変更経緯を管理します。

もう一つ押さえておきたいのが権限です。Googleでは、オーナーと管理者にビジネス情報の編集権限が付与されています。管理者も店名、カテゴリ、Webサイトなど多くの情報を変更できるため、複数人で運用すると「変更できる人」が増えます。

したがって、多店舗運用では「変更権限があること」と「自由に変更してよいこと」を分けて考える必要があります。この線引きは、次の節で説明する変更履歴台帳の記録と、その後の承認ルールで運用します。

変更履歴台帳には最低12項目を記録する

変更後の値だけを残しても、原因の追跡には使えません。最低限、次の12項目を記録すると、変更理由の確認から復旧まで進めやすくなります。

項目	記録内容
変更ID	変更を一意に識別する番号
店舗コード	店舗を識別する固定コード
店舗名	対象店舗
変更日時	実際に変更操作を行った日時
変更項目	営業時間、電話番号、カテゴリなど
変更前	変更する前の値
変更後	新しく設定した値
変更理由	なぜ変更する必要があったか
申請者	変更を依頼した人
作業者	GBPを実際に変更した人
承認者	変更を承認した人
反映確認	Google検索・Googleマップ上で確認した結果

多店舗MEOの変更履歴台帳に記録する変更ID、変更前後、理由、担当者など12項目を整理した図

変更前後の値だけでなく、変更理由・申請者・作業者・承認者まで残すことで、後から変更経緯を追跡できます。

記入のイメージとして、営業時間と電話番号を変更した場合の例を示します。次の表は、店舗名や番号を仮に置いた記入例です。

店舗	項目	変更前	変更後	理由	作業者	承認者
新宿店	月曜営業時間	10:00〜20:00	11:00〜20:00	店舗営業時間変更	本部A	営業部長
渋谷店	電話番号	03-XXXX-1111	03-XXXX-2222	回線変更	本部B	店舗責任者

12項目の中でも、特に重要なのが「変更前」と「変更理由」です。変更前の値がなければ、問題が発生したときにどこへ戻せばよいか分かりません。変更理由がなければ、変更が正当だったのか、それとも操作ミスだったのかを後から判断できません。

変更項目を3段階のリスクに分ける

すべての変更を同じ承認フローにすると、軽微な更新まで本部の確認が必要になり、運用が止まります。そこで、変更項目を「高・中・低」の3段階に分けます。

次の表は、この記事が推奨する運用例です。リスクが高い項目ほど、変更前の確認を重くする考え方で並べています。

リスク	主な変更	推奨ルール
高	店名、住所、メインカテゴリ、WebサイトURL、閉業設定	事前承認必須
中	電話番号、通常営業時間、追加カテゴリ、サービス情報	担当者確認後に変更
低	写真、投稿、説明文など	ガイドライン内で担当者判断

店名や住所など影響の大きい変更だけを事前承認にし、軽微な更新は現場の判断に任せることで、統制と運用速度を両立できます。

高リスクの項目を重く扱うのは、店名、住所、メインカテゴリ、WebサイトURLなどが、検索ユーザーが店舗を選ぶ際の基本情報だからです。誤った変更が複数店舗へ広がると、問い合わせ先の誤認や来店トラブルにつながります。

権限との関係も確認しておきます。Googleでは、オーナーと管理者の両方が店名・カテゴリ・Webサイトなどを更新できます。一方、ユーザーの追加・削除などはオーナーに限定されています。

そのため、権限設定だけに頼らず、「システム上は変更可能だが、社内ルールでは承認が必要」という運用を加えるのが現実的です。

本部・店舗・責任者の役割は項目ごとに決める

多店舗MEOでは、本部だけですべての更新を行う方法も、各店舗へ完全に任せる方法も、問題が起きやすくなります。本部に集中させれば、営業時間のように現場でしか分からない変更への対応が遅れます。一方、店舗に完全に任せると、店名、カテゴリ、説明文などの基準が店舗ごとにばらつきます。

そのため、項目ごとに「誰が申請し、誰が承認し、誰が変更するか」を決めます。次の表は、その分担の例です。「-」の欄は、その役割が通常は関わらない項目を表します。

項目	店舗	本部MEO担当	責任者
営業時間変更	申請	更新	必要時確認
電話番号	申請	更新	確認
店名	申請	更新	承認
メインカテゴリ	意見提出	更新	承認
写真	更新可	監査	–
投稿	更新可	ガイドライン管理	–
オーナー追加	–	申請	承認・実行

項目の影響が大きいほど、責任者の承認が必要になります。店名とメインカテゴリは責任者が承認し、写真と投稿は店舗が更新できます。

外部の運用会社に任せる場合の役割設計は、冒頭で紹介した記事で整理しています。

権限の面では、Googleはアカウントのパスワード共有ではなく、各ユーザーへ個別のGoogleアカウントを使わせ、オーナーまたは管理者として追加する方法を案内しています。また、ビジネスプロフィールへのアクセスを必要なオーナー・管理者だけに制限し、退職者など不要になったユーザーのアクセスを削除することも推奨しています。

したがって、変更履歴台帳と権限の棚卸しはセットで運用する必要があります。

10店舗以上ではGoogleの一括管理を使い、案件単位で履歴を残す

この節では、10店舗以上で一括更新を行うときに、何を単位に履歴を残すかを決めます。

Googleは、10拠点以上を持つ事業者向けに、ビジネスプロフィールの一括管理機能を提供しています。公式ヘルプでは、10拠点以上の場合、ビジネスグループとスプレッドシートを使って、複数店舗の追加、オーナー確認、管理をまとめて行えると説明しています。

一括更新は作業効率を高めますが、誤った情報を複数店舗へ同時に反映するリスクもあります。そのため、一括変更では「1店舗の変更」ではなく「変更案件単位」で履歴を残します。

たとえば、年末年始の営業時間を50店舗へ反映する場合は、次の項目を1案件として残します。

変更案件ID
対象店舗数
対象店舗一覧
使用した更新ファイル
変更前データ
変更後データ
作業者
承認者
実行日時
反映確認結果

Googleの一括アップロードには、アップロード前に変更内容をプレビューしてから適用する仕組みがあります。この仕組みを活かし、「作成→レビュー→承認→適用→反映確認」の5段階を社内標準にすると、一括更新による事故を減らしやすくなります。

Googleによる変更と社内変更を分けて記録する

GBPの情報が変わる原因は、自社の担当者だけとは限りません。Googleは、ユーザーからの報告やライセンスされたコンテンツなど複数の情報源を使って、プロフィール情報を更新する場合があります。プロフィールエディタでは、Googleによって変更された情報を確認できます。

そのため、先に挙げた12項目に加えて、変更履歴台帳に「変更元」という列を設けます。推奨する分類は次の4つです。

社内担当者
店舗担当者
外部運用会社
Googleによる変更・その他

変更元を記録しておくと、意図しない変更を見つけたときに、「社内の操作ミスなのか」「Google側の更新なのか」を切り分けやすくなります。

ただし、Google公式も、すべてのGoogleによる変更をビジネスプロフィール上で管理できるわけではないと説明しています。Google側の画面を完全な変更の監査ログとして扱わず、自社の業務記録を別に持つことが重要です。

変更後は「入力したか」ではなく「反映されたか」まで確認する

変更履歴は、GBPの編集ボタンを押した時点で完了にしてはいけません。Googleでは、確認済みビジネスプロフィールへの変更が審査され、変更後の状態が「承認済み」「審査中」「不承認」などになる場合があります。通常は短時間で審査される一方、Google公式では場合によって最大30日かかることもあると案内しています。

入力しただけでは、公開された状態になったとは言えません。変更案件には、少なくとも次のステータスを設定します。

申請
承認待ち
変更実施
Google確認中
反映確認済み
不承認・要対応
差し戻し

ポイントは、「変更実施」と「反映確認済み」を分けることです。たとえば、電話番号を変更した担当者が「変更しました」と報告しても、実際のGoogle検索やGoogleマップ上で旧番号のままであれば、運用上は完了していません。

問題が起きたときは変更IDから復旧する

変更履歴台帳の最大の価値は、異常が発生したときに、原因と復旧先をすぐ特定できることです。

多店舗MEOの変更申請から反映確認、異常発生時の変更ID確認と復旧までを示したフロー図

GBPの編集操作だけで完了とせず、実際の反映確認まで管理します。異常時は変更IDから直前の正常値を確認し、復旧と再発防止につなげます。

たとえば、ある店舗で突然カテゴリが変わった場合、次の6つの手順で確認します。

1. 現在値を確認する

Google検索、Googleマップ、管理画面で、現在の情報を確認します。

2. 店舗情報マスターと比較する

本来設定すべきカテゴリとの差を確認します。

3. 変更履歴を検索する

対象店舗・対象項目で絞り込み、直近の変更IDを確認します。

4. 変更元を確認する

社内担当者、店舗、外部会社、Googleのどこから発生した変更かを切り分けます。

5. 変更前の値へ戻す

台帳に保存してある直前の正常値を基準に復旧します。

6. 再発防止策を記録する

権限の見直し、承認ルールの変更、店舗への周知などを記録します。

この流れにしておけば、「とりあえず元に戻した」で終わらず、同じ変更が再発する原因まで管理できます。

変更履歴台帳は週次確認と月次監査で運用する

変更履歴台帳は、作成しただけでは機能しません。日々の変更記録に加えて、週次、月次、四半期で確認する内容を分けると、続けやすくなります。次の表は、その頻度の例です。

頻度	確認内容
変更時	変更前後・理由・担当者を記録
週次	未承認・未反映・不承認案件を確認
月次	店舗別変更件数、権限、異常変更を監査
四半期	運用ルール・承認基準を見直す

月次監査では、単純な変更件数だけでなく、次の指標を見ると問題を見つけやすくなります。

承認なしで変更された件数
変更理由が空欄の件数
反映未確認の件数
同一項目を短期間に複数回変更した件数
店舗ごとの変更件数
不承認になった変更件数
Googleによる意図しない変更件数
退職者・外部会社など不要な権限数

特に「同じ項目を何度も変更している店舗」は、単なる作業ミスではなく、正しい店舗情報の定義が本部と店舗で一致していない可能性があります。その場合は、記録を増やすよりも、まず定義をそろえることが先になります。

変更履歴台帳を作る7つの手順

最初から大規模な管理システムを導入する必要はありません。ExcelやGoogleスプレッドシートでも始められます。次の7つのSTEPで進めましょう。

STEP1　全店舗へ店舗コードを付ける

店舗名は変更される可能性があるため、店舗を識別する固定コードを作ります。たとえば、次のような形です。

TOKYO-001
TOKYO-002
OSAKA-001

GBPにも店舗コードを設定できます。Googleの詳細設定では店舗コードの追加・編集が可能なので、多店舗管理ではコードをそろえておくと照合しやすくなります。

STEP2　現在の店舗情報マスターを作る

全店舗について、店名、住所、電話番号、営業時間、カテゴリ、URLなどの現在値を確定します。

STEP3　変更履歴シートを作る

1変更1行で記録できるように、変更前後、担当者、理由、承認者を設定します。

STEP4　項目ごとの変更権限を決める

「変更できる人」ではなく、「社内ルール上変更してよい人」を定義します。

STEP5　高リスク変更だけ承認制にする

すべてを承認制にせず、店名、住所、メインカテゴリ、URL、閉業など影響の大きな変更を重点的に管理します。

STEP6　反映確認までステータス管理する

変更操作だけで完了にせず、Google検索・Googleマップ上の反映まで確認します。

STEP7　月1回、変更履歴と権限を監査する

異常な変更、不要な権限、記録漏れをまとめて確認します。

多店舗MEOの変更履歴台帳チェックリスト

すでに変更履歴台帳を運用している場合は、次の項目で現状を確認してください。

店舗ごとに固定の店舗コードがある
変更日時を残している
変更した項目が分かる
変更前の値を残している
変更後の値を残している
変更理由を記録している
申請者と作業者を区別している
必要な変更には承認者がいる
Googleによる変更と社内変更を区別できる
反映確認までステータス管理している
一括変更時の対象店舗一覧を保存している
過去の正常値へ戻せる
月次で変更履歴を監査している
GBPのユーザー権限も定期的に棚卸ししている

目安として、3項目以上不足している場合は、単なる「店舗情報一覧」になっている可能性があります。不足している項目から順に、台帳へ列や手順を足していきましょう。

まとめ

多店舗MEOの変更履歴台帳では、現在のGBP情報を一覧にするだけでなく、誰が・いつ・どの店舗で・何を・何から何へ・なぜ変更したかを1変更単位で記録します。

12項目のうち特に重要なのは、変更前の値、変更理由、作業者、承認者、反映確認です。これに、Googleによる変更と社内の変更を区別する「変更元」を加えた6項目を欠かさず残してください。

GBPには、オーナー・管理者による共同管理、ビジネスグループ、10拠点以上の一括管理といった機能があります。一方、多人数・多店舗になるほど変更できる場所と人が増えるため、自社側の変更統制が必要になります。

最初の一歩は、全店舗の店舗情報マスターと変更履歴台帳を分け、店名・住所・メインカテゴリ・WebサイトURLなど影響の大きい項目から承認ルールを設定することです。変更履歴が残れば、異常が起きたときにも「何が変わったか」だけでなく、「なぜ変わったか」「どこへ戻せばよいか」まで追跡できます。

参考文献・データ元

この記事で参照した情報を確認できます。

Google「ビジネスプロフィールのオーナーと管理者を管理する」
オーナー・管理者の権限、ユーザー管理、プロフィール編集権限の確認に使用。
Google公式ページを確認する

Google「一括指定するビジネス情報の管理の概要」
10拠点以上の一括管理、ビジネスグループ、スプレッドシート管理の確認に使用。
Google公式ページを確認する

Google「ビジネスプロフィールに対する Google による変更を管理する」
Googleによる情報更新と一括更新時の挙動確認に使用。
Google公式ページを確認する

Google「Understand what happens to your Business Profile edits」
変更内容の審査、承認・審査中・不承認の状態確認に使用。
Google公式ページを確認する

Google「Help protect your Google Business Profile」
アクセスユーザーを必要最小限にすること、退職者などのアクセス削除に関する確認に使用。

‹ 親記事: MEO導入は内製か外注か？企業の体制構築、判断基準と進め方