実績
多店舗向け MEO 運用 SaaS（GBP × AI × Human-in-the-loop）
運用担当 admin と店舗 client SPA の 2 層構造で、月次レポート、AI 投稿生成、口コミ返信、ポリシーセルフチェックを自動化。すべての AI 出力に人間の承認キューを挟む production SaaS。
クライアント
- 名称
- 多店舗運営事業者（飲食・小売）
- 事業
- Google ビジネスプロフィール運用対象（10店舗以上）
- 所在
- 東京・インバウンド集客エリア
- 規模
- Per-store monthly retainer model
- 人員
- One operator agency + N client stores
デモ
何が壊れていたか
01
投稿は店舗ごとに手書き。複数拠点での文体・露出量が揃わず、人を増やさないと回らない
02
多言語の口コミ返信が滞留。当日中の返信が構造的に不可能
03
プロフィールのポリシー違反が手動レビューを突破し、停止が発生 — 1 ヶ月単位で露出が消える
04
運用担当が tenant 間を context-switching で消耗。承認キューが分散
05
tenant データが spreadsheet 上に散在し、解約時のデータ分離が不衛生
Before / After
| 指標 | Before | After |
|---|---|---|
| 投稿作成サイクル | Manual per-store | 1 SPA / month |
| 口コミ返信 | Days, single language | Same-day, multilingual |
| ポリシー違反リスク | Manual review | AI self-check + human approval |
| 運用担当の負荷 | Per-store context-switch | Single approval queue |
| テナント分離 | Spreadsheet-based | RLS-enforced per client |
構築ノート
背景 — インバウンドの集客を握る店舗にとって Google ビジネスプロフィールは資産。だが投稿が止まった瞬間に露出が落ちる、揮発性の高い資産でもある。手作業で運用すると数店舗で破綻する。本案件のブリーフは「運用代行 1 社が数十店舗を、Human-in-the-loop の規律を保ちながら回す production SaaS」を作ること。
アーキテクチャ — 2 つのインターフェース + 共有バックエンド。
運用担当 admin は代行会社側のコンソール。月次インサイトレポートが毎月 1 日に自動バッチ生成され、AI が下書きした投稿と口コミ返信が承認キューに並ぶ。プロフィール改善提案もデータ分析からエスカレーション。Google API に到達する前に必ず人間が一度承認する。
店舗 client SPA は店舗単位。URL 1 つで「前月の成果」と「当月の投稿設定」を 1 ページで表示。店舗担当者は写真をアップロードして、文脈を一段落書くだけ。AI が日英のキャプションを生成。ログイン疲れも管理画面の習得負荷もない。
裏側は Supabase の RLS でテナント分離、n8n が GBP API のオーケストレーションを担当、OpenAI / Claude が日英コピーを生成、口コミは多言語自動検知レイヤーで返信言語を決める。
2 層 UI の決定理由 — 単一の admin に店舗を直接 onboard する誘惑があった。2 層に分けたのは、「公開」を押すのは代行会社のオペレーターだけに留めたかったから。店舗は結果と素材を提供し、代行会社が規模で運用する。SaaS がその運用モデルを製品としてコード化している。
切ったもの — GBP の自動 onboarding は無し（初期セットアップは代行会社が手作業で吸収する一回限りのコスト）。AI 単独公開は無し（全投稿・全返信が人間承認）。店舗向けアナリティクス画面も無し（月次インサイトメールで十分）。それぞれの「やらない」が、代行会社オペレーターの実際の仕事に向けて製品を尖らせた。