← デモ一覧に戻る
MusubiMusubi環境構築ドキュメント

環境構築ロードマップ（細粒度）

プラットフォーム（管理アプリ・顧客サイト量産・口コミ自動返信・月次レポート・課金）を、振り返り可能な手順で構築するための実装ロードマップ。

サイト制作・運用ロードマップ は「1店舗の受注〜公開〜運用」の粒度。本書はその土台となる環境そのものの構築を、依存関係・受け入れ基準・残す証跡まで落とした粒度で扱う。

全体像（依存関係）

Phase 0 アカウント/API申請 ──▶ Phase 1 口コミ自動返信疎通 ──▶ Phase 6 承認UI統合
        │                                   ▲
        ├──▶ Phase 2 データ基盤/認証 ───────┘
        │            │
        │            ├──▶ Phase 3 顧客サイト量産基盤
        │            ├──▶ Phase 4 月次レポート自動集計
        │            └──▶ Phase 5 課金(Stripe)
        └──▶ Phase 7 監視・バックアップ（全体に横断）

デモ画面 ↔ Phase 対応（公開ハブのデモを「本番アプリとして組む」トレーサビリティ）

デモ（musubi-demos）にある管理アプリ6画面・顧客ポータル3画面は、各Phaseで段階的に本番実装する。

Phase 0 ・ アカウント準備とAPI申請（最優先）【完了 2026-06-27】

目的: 後工程の前提となる外部アカウントと、リードタイムの長いAPI審査を先に片付ける。

手順

使用サービス: Google Cloud / Anthropic / Supabase / Vercel / Cloudflare / Stripe / Resend / GA4

受け入れ基準: GBP API申請の受付完了。各SaaSにログインでき、キー類を安全に保管（パスワードマネージャ／Vercel・Supabaseのシークレット）。

残す証跡: 申請日・申請ID、各サービスのプロジェクト名／ID、発行キーの保管場所（値そのものは記録しない）。

Phase 1 ・ 口コミ自動返信の疎通（中核・最優先で検証）

目的: 月額価値の根幹「口コミ自動返信」が技術的に成立することを、実店舗1件で実証する。

前提: Phase 0 のGBP API承認・OAuth設定。検証用に協力してくれる実店舗1件（自店・知人店可）。

手順

使用サービス: Google Business Profile API / Anthropic / （ローカル実行）

受け入れ基準: 実店舗で「取得→下書き→承認→投稿」が1サイクル通る。低評価は自動投稿されない。

残す証跡: 投稿された返信のスクショ、調整したトーン設定、out/run-*.json。

Phase 2 ・ データ基盤と認証

目的: 顧客・契約・口コミ・請求を一元管理するDBと、運営/顧客の認証を用意する。

手順

使用サービス: Supabase（Postgres/Auth）/ Vercel / Next.js

受け入れ基準: 管理アプリからログインでき、DBに1件の店舗レコードをCRUDできる。顧客ロールは他店データが見えない。（顧客ポータルの土台・顧客認証も本Phaseで用意し、成果/レポート/承認の各UIは Phase 4・6 で中身を実装）

→ 達成（2026-06-27 実地クリア）。本番 Supabase に 0003/0004 適用、顧客ポータルを Vercel 本番デプロイ、顧客テストユーザー作成＋owner_user_id 紐付け、顧客／staff 両ロールのログインと RLS 分離（顧客=自店のみ・staff=全件）を本番で実証。Phase 2 完了。

残す証跡: スキーマ図／DDL、RLSポリシー、デプロイURL（管理アプリ・顧客ポータル）。

Phase 3 ・ 顧客サイト量産基盤

目的: content.json + テンプレHTML で店舗サイトを量産し、Cloudflare Pages へ自動デプロイできる状態にする。

手順

使用サービス: Cloudflare Pages / Registrar / GitHub Actions（任意）/ GA4

受け入れ基準: 新規店舗のJSONを用意 → 1コマンド／1操作で公開サイトがHTTPSで立ち上がり、計測タグが動く。

→ コード面は達成（publish_site.sh で JSON→ビルド→Pages公開を1コマンド・計測タグはビルド検証で動作確認済）。残るはCloudflare認証トークン発行とドメイン割当（外部操作）。

残す証跡: 追加テンプレ（beauty/）、publish_site.sh、計測タグのビルド検証（空=非出力・id有=出力を確認）。

Phase 4 ・ 月次レポート自動集計

目的: 解約防止の武器「月次レポート」を、手作業を最小化して毎月生成・公開する。

手順

使用サービス: GA4 Data API / GBP API / Vercel Cron / Resend

受け入れ基準: 1店舗ぶんのレポートが自動でデータ取得〜生成〜ポータル公開まで通る。手作業はコメント追記だけ。

→ 集計パイプライン・Cron・公開通知・WIF認証まで実通し確認済（2026-06-28・本番200）。GA4由来指標（access_count/phone_tap_count/reservation_count）は WIF で自動取得が稼働、GBP由来（review_count/avg_rating/reply_rate/search_views/map_views）は承認まで手入力。残る外部待ちは GBP API承認のみ（実データは実店舗サイト公開＋実訪問で自動的に乗る）。

残す証跡: 自動生成されたレポート、Cron実行ログ。

現時点の証跡: 0004_reports_metrics.sql、管理 /report（作成・公開・公開時Resend通知）、ポータル /report（表示・前月比）、musubi-admin/app/api/cron/ingest-ga4/route.ts（GA4集計）、musubi-admin/vercel.json（月次Cron）。

Phase 5 ・ 課金（Stripe サブスク）

目的: 月額の自動回収と未入金対応を仕組み化し、請求業務をゼロに近づける。

手順

使用サービス: Stripe / Vercel（Webhook）/ Supabase / Resend

受け入れ基準: テストモードで「契約→毎月課金→失敗時リトライ→解約」が一通り動き、状態がDBに同期される。

→ 実テスト完了・受け入れ基準クリア（2026-06-28）。0005 を Supabase 本番へ適用（contracts に3列追加・確認済）、stripe_setup_products.mjs で Price 作成、Stripe CLI stripe listen で本番 webhook secret を取得し next dev へ転送、stripe trigger で各イベントを発火。全分岐が実 DB に同期されることを実証＝invoice.payment_succeeded→invoices(paid) 記録＋contracts.last_payment_status='paid'、invoice.payment_failed→invoices(failed)＋last_payment_status='failed'、customer.subscription.deleted→contracts.status='cancelled'。実テストで silent failure バグを発見・修正＝webhook が supabase-js の {error} を未チェックで、invoice.paid の invoices insert が失敗しても contracts 側は paid に更新される状態だった（amount: inv.amount_paid が undefined で NOT NULL 違反）。各 insert/update の error を検査し失敗時 500（Stripe リトライ）、amount を amount_paid ?? amount_due ?? 0 にフォールバック、stripe_invoice_id で冪等化（既存はスキップ）。tsc/lint clean。Resend リトライ・未入金フロー・領収書は未実装（Phase 7）。（2026-06-28 追記・整合）: 上記「silent failure 修正（error 検査／amount フォールバック／冪等化）」は当時 40bcb2b には未コミットだったことが後日判明。本日のコミットで webhook に実反映（recordInvoice で stripe_invoice_id 冪等＋各 DB 失敗を throw→500 で Stripe リトライ、amount = amount_paid ?? amount_due ?? 0）し、併せて支払失敗時の Resend 案内（line 178）も実装した。

残す証跡: Stripeダッシュボードのテスト履歴、Webhookログ、状態遷移の確認。

現時点の証跡: musubi-admin 40bcb2b（app/billing/・app/api/stripe/webhook/・lib/plans.ts・lib/stripe.ts・lib/auth.ts・lib/supabase/service.ts）、0005_billing_sync.sql、06_スクリプト/stripe_setup_products.mjs。

Phase 6 ・ 顧客ポータルへ承認UI統合

目的: 口コミ承認をCLIからWeb（顧客ポータル）へ移し、店舗オーナー自身が承認できるようにする。

手順

使用サービス: Next.js（ポータル）/ Supabase / GBP API / Vercel Cron

受け入れ基準: 店舗オーナーがポータル上で下書きを確認→承認→投稿でき、低評価には警告が出る。

→ 承認フロー（確認→承認/修正/スキップ・低評価警告）を本番で実証済（2026-06-28）＝portal-demo で /reviews ログイン・承認/スキップが DB に反映（approved/skipped・下書き空は承認不可）。投稿（posted）は GBP API 承認後に Cron で実施＝承認＝投稿待ちキューまでが現状の到達点。

残す証跡: 画面スクショ、承認〜投稿の通しテスト。

Phase 7 ・ 監視・運用・バックアップ（横断）

目的: 公開後に落ちない・データを失わない運用基盤。

手順

使用サービス: UptimeRobot / Supabase / Vercel / Resend

受け入れ基準: 監視が通知を出せる。バックアップから復元できることを1度確認。

→ 達成（2026-06-28）。(1) コスト暴走通知=cost-alert を通し検証し Resend 送信＋cost_alerts 記録＋冪等を確認（cap一時0で強制発火・検証後復元）。(2) 死活監視=UptimeRobot 3モニタ登録・全件 UP・通知先紐付け確認。(3) 復元=論理バックアップ→一時テーブル復元の件数一致（4/4）を実証。Phase 7 完了。 残る運用整備（エラー通知の Slack 化・Pro バックアップ移行など）は本番スケール時に随時。

残す証跡: 監視設定、復元テストの記録。

完了の定義（環境構築フェーズのゴール）

ここまで到達したら、営業で獲得した顧客を本番投入してスケールフェーズへ移る。

事業再構築フェーズ（2026-07・飲食店特化）

環境構築（Phase 0–7）で道具は揃ったが実顧客ゼロのため、「稼げるサービス」への再構築を行う。

ターゲットを食べログ掲載 × Google高評価 × 公式サイト無しの飲食店に特化し、受注導線・テンプレ品質・GBP実投稿・商品設計を刷新する。他業種はカスタム（個別見積）でスポット対応。金額は据え置き（初期5/10/15万・月額5,000/15,000/20,000円）。

Phase R0 ・ GBP live 疎通確認（最優先）

目的: 口コミ実投稿の前提となる GBP API の実疎通を確認し、アカウント/ロケーションIDを確定する。

手順

次のアクション（ユーザー）: GBP API 申請ステータスの確認。申請時の返信メール（Google Business Profile API アクセス申請）を確認、未返信なら https://support.google.com/business/contact/api_default から問い合わせ。Cloud Console → API とサービス → mybusinessaccountmanagement.googleapis.com → 割り当て で Requests per minute が 0 のままか確認できる（project 361193620042）。

受け入れ基準: 実店舗 1 location の口コミ一覧が live で取得できる。

Phase R1 ・ 価格・商品の飲食特化再パッケージ

目的: 金額据え置きのまま、プラン内容・訴求を飲食店の意思決定単位に再定義する。

手順

受け入れ基準: 価格表・提案資料が飲食特化文言で再生成でき、金額・特典がアプリ側と一致。数値は全て出典付きか「試算」明記。

→ 達成（2026-07-03）。PDF 実描画確認済（レイアウト崩れなし・TableCheck 2022 出典表記あり）。

Phase R2 ・ テンプレ強化（飲食4系統＋汎用＋単一ソース化）

目的: 売り物の見た目を受注水準に引き上げ、テンプレの二重管理を解消する。

手順

受け入れ基準: 飲食4＋generic の5テンプレが build_site.py と admin builder の両方でビルドできる。口コミは実データが無ければ非表示。

→ 達成（2026-07-03）。5テンプレ×4変種（既定/テーマ変更/テーマ削除/custom_css）＝32ビルド警告ゼロ、admin npm run build 通過。

Phase R3 ・ 受注導線（本体LP＋先作りデモ営業）

目的: 「Musubi 自身の公式サイトが無い」状態を解消し、営業を仕組み化する。

手順

受け入れ基準: LP が公開されフォーム送信できる。CSV 1行から1コマンドでデモURLが生成され CRM に記録される。

Phase R4 ・ GBP 実投稿の本番接続

目的: 口コミ返信を「承認＝投稿待ちキュー」から実投稿まで通し、月額の中核価値を完成させる。

手順

受け入れ基準: 実店舗1件で 取得→下書き→ポータル承認→実投稿→GBP画面に返信表示 の一周。approved 以外が投稿される経路が無い。

Phase R5 ・ 資料・デモ・ハブ再構成

目的: 見せる面（ハブ・デモ・資料）を飲食特化の商品構成に揃える。

手順

受け入れ基準: ハブから新LP・全テンプレ・新価格表に到達できる。旧価格の表示が残らない。

🧭 社内ドキュメント（環境構築の証跡・手順）。Musubi / local-web-sales プロジェクト。