店舗に付いたGoogleの口コミを読み分けて、返信案と本部への報告を作る

処理の起点を決める

毎朝決まった時刻の定期起動にします。Google Apps Script の時間主導型トリガーで、日単位の起動を設定します。

口コミが付くたびに即時で処理する構成も考えられますが、この業務では朝1回で足ります。店長が返信案を見るのは開店前の時間帯で、それまでに一覧が揃っていれば十分だからです。 即時にすると、営業中に通知が鳴り続けます。

例外は、本部確認に分類された苦情です。こちらは朝を待たずに本部担当へ通知したほうがよいため、本格構成では昼と夕方にも取得を回します。

入力データを集める

4番目は、同じ文面の繰り返しを避けるために渡します。 過去の返信と似た書き出しを避けるよう指示すると、返信欄に同じ文が並ぶのを防げます。

データの取得方法を決める

口コミの取得には2つの経路があり、段階によって使い分けます。

半自動化：通知メールから取る。 Googleビジネスプロフィールでは、新しいクチコミが投稿されたときの通知をメールで受け取るよう設定できます。店舗ごとの通知を本部の共有アドレスに集め、Apps Script でそのメールを読んで一覧に追加します。API の申請が不要で、すぐに始められます。 ただし、メールの書式が変わると読み取りが壊れるため、取得できた件数を毎朝確認する仕組みを併せて作ります。

本格構成：Business Profile API から取る。 API では、店舗ごとの口コミを accounts.locations.reviews.list で一覧取得でき、口コミID、本文、投稿者、星の数、投稿日時、既存の返信を扱えます。返信の投稿は accounts.locations.reviews.updateReply で行い、返信が無ければ作成、あれば更新になります。返信の操作はオーナー確認済みのビジネスに限られます。 返信の削除には deleteReply があります。

API を使うには事前の申請が必要です。 Google Cloud のプロジェクトを作り、所定のフォームから利用を申請します。申請には、60日以上運用されているオーナー確認済みのビジネスプロフィールと、プロフィールに掲載されたWebサイトが求められます。承認されるまでは、Google Cloud のコンソール上でクォータが 0 QPM と表示され、承認後に 300 QPM になります。承認までの期間は読めないため、半自動化で運用を始めてから並行して申請する順番を勧めます。

グルメサイト・宿泊予約サイトの口コミ： 返信の投稿方法はサイトごとに異なり、多くは各サイトの管理画面から入力する形です。この構成では、Googleの口コミを対象にし、他のサイトは返信案の作成だけに使う（投稿は管理画面へ貼り付け）形にとどめます。

AIへ渡す前に整形する

1. 返信済みの除外 … すでに返信がある口コミは処理しません
2. 本文のない口コミの扱い … 星の数だけで本文がない口コミは、短い定型のお礼にとどめるか、返信しない方針にします。本文がないのにAIに文面を作らせると、書かれていない内容に触れた返信ができあがります
3. 言語の判定 … 外国語の口コミは、その言語で返信するかを方針として決めておきます
4. 個人情報の検出 … 口コミ本文に電話番号や他の客の特徴などが書かれている場合があります。返信案に引用しないよう、検出して印を付けます
5. 苦情の語の事前検出 … 「髪の毛」「異物」「お腹を壊した」「虫」「アレルギー」などの語をあらかじめ辞書で拾い、AIの分類とは別の経路で本部確認へ回します。AIの分類だけに頼らず、二重で拾います

5番の二重化が重要です。衛生や健康にかかわる苦情を1件でも取りこぼすと、店長が知らずに軽いお詫びを返してしまいます。

AIに処理させる

2段階に分けます。

第1段階：分類。

星の数で分類しないでください。 星5でも「料理は最高だがトイレが汚れていた」と書かれていることがあり、星1でも「駐車場が分かりにくかった」だけのことがあります。

第2段階：返信案の作成。 「お礼」と「お詫び（店舗で対応可）」だけが対象です。

指示内容を固定する

あなたは飲食店の店長に代わって、Googleの口コミへの返信案を作る担当者です。
まず口コミを分類し、分類が「お礼」または「お詫び（店舗で対応可）」のときだけ返信案を作ってください。

【分類の基準】
- 本部確認：衛生、異物、体調不良、アレルギー、スタッフの言動、会計の誤り、
  法令にかかわる内容が1つでも含まれる場合。星の数に関係なくこちらにしてください。
- 返信しない：明らかにこの店舗の内容ではない、宣伝、意味が通らない投稿。

【返信案の厳守事項】
- 口コミに書かれていない出来事に触れないでください。
  「またのご来店時には〇〇をご用意します」など、書かれていない内容を補わないでください。
- 投稿者の来店日時・人数・席・服装など、本人を特定できる情報を書かないでください。
- 事実を確認していない出来事について、非を認める表現を使わないでください。
  「ご不快な思いをおかけしました」は可、「スタッフが失礼な対応をいたしました」は不可。
- クーポン、割引、特典を案内しないでください。
- 改善を約束する場合は、下の店舗情報に書かれている取り組みの範囲にしてください。
- 過去の返信の書き出しと同じ文で始めないでください。
- 200字以内、店長名で署名してください。

【店舗情報】
{store_info}

【この店舗の過去の返信（直近20件）】
{past_replies}

【口コミ】
星: {star_rating}
本文: {comment}

「星の数に関係なく本部確認にする」の一文が、この構成でもっとも重要です。 これが無いと、星4の口コミに書かれた「一緒に来た子どもがアレルギー反応を起こした」を、お礼の返信で流してしまいます。

出力形式を固定する

{
  "review_id": "",
  "store": "",
  "category": "お礼 | お詫び | 本部確認 | 返信しない",
  "category_reason": "",
  "risk_terms": [],
  "contains_personal_info": false,
  "reply_draft": "",
  "reply_length": 0,
  "needs_hq": false
}

category_reason を持たせるのは、店長や本部が分類を見直すときに、なぜその分類になったのかを確認できるようにするためです。

risk_terms には、前処理の辞書とAIの両方で拾った語を入れます。辞書で拾ったのにAIが「お礼」に分類した場合は、分類を「本部確認」に上書きします。安全側に倒す判定は、プログラム側で強制します。

システムへ連携する

本格構成でも、承認欄にチェックが入った行だけを投稿します。 返信案ができた時点で自動投稿する設定は作りません。

人が確認する

返信は全件、店長が承認します。本部確認の口コミは、本部の担当者が対応を決めます。

理由は、返信が店舗の公式な発言として公開され、消しても見た人の記憶に残るためです。特に苦情への返信は、書いた内容が「店が認めた事実」として読まれます。

店長の確認を速くするための設計が要ります。

• スマートフォンで開いたときに、口コミと返信案が上下に並ぶ表示にする
• 直す必要がなければ、承認のチェックだけで済むようにする
• 本部確認に回った口コミは、店長の一覧にも「本部対応中」と表示し、店長が個別に返信しないようにする

例外に対処する

記録を残す

• 口コミの本文と取得日時
• AIの分類とその理由、拾ったリスク語
• 返信案と、店長が直した後の最終版
• 承認者と投稿日時
• 本部確認に回した口コミと、その後の対応結果

2番目と5番目を月に1度見比べてください。 本部確認に回したが実際は店舗で対応できたもの、逆に「お礼」に分類されたが本部が知るべきだったものを洗い出すと、分類の基準が育ちます。

本部確認に回った苦情は、店舗をまたいで集計します。同じ種類の苦情が複数店舗で出ていれば、それは店舗の問題ではなく、本部の手順やメニューの問題です。