Practice

Gourmie β 運用で分かった、飲食コンシェルジュの需要と課題

XIORA INSIGHT xiora-official.com Gourmie β 運用で分かった、飲食コン シェルジュの需要と課題 Xiora — AI-native software, engineered for business.

会話型 AI と二層プロファイル学習を運用して見えた飲食コンシェルジュ需要と、店舗プランへの意思決定。

KR
沓澤 怜士 (Kutsuzawa Reo)
Xiora 代表 · info@xiora-official.com

Introduction

Xiora が運営する Gourmie (グルミー、https://gourmie.jp/) は、飲食コンシェルジュ型の PWA です。ユーザーは「今日の気分」「予算」「場所」を伝えると、AI がおすすめの店・メニュー・注文の順序を提案します。

β 運用フェーズを経て、以下が見えてきました。

  • どの層のユーザーが本当に価値を感じるか
  • 店舗側 (β 加盟店) が何を導入決定要因と見ているか
  • 店舗プラン (basic / pro / premium) がなぜこの区切りになったか

本記事では、β 運用中に得られた具体的なインサイトと、店舗プラン (basic / pro / premium) の設計思想を、飲食店経営者と product manager 向けに公開します。

免責: 本記事は Gourmie β 運用中の観察結果であり、GA (一般公開) 後の状況・料金・機能は変更となる可能性があります。導入判断は個別の店舗事情に応じてご判断ください。

---

Gourmie とは

Gourmie は「今日、どこで何を食べるか」の意思決定を支援する PWA です。

  • User 側: https://gourmie.jp/ — 気分・予算・場所を入力すると、店 + メニュー + 注文順を提案
  • 店舗側: https://gourmie.jp/merchant — 店舗情報・メニュー・在庫・予約枠の管理

技術的には Python (FastAPI) + PostgreSQL + PWA (Next.js) 構成。Stripe SDK 15.3.0 で店舗プランの課金を実装済み (STRIPE_SECRET_KEY + STRIPE_PRICE_{BASIC,PRO,PREMIUM} env で切替、services/systems/Gourmie/app/backend/app/api/billing.py 参照)。

現在 β 運用中。店舗プランは実装済みですが、Stripe live キーの本番設定と加盟店の同意プロセスは Reo action として保留中です (docs/REVENUE_ACTIVATION_PLAN.md §3 参照)。

---

β 運用で得られた 3 つのインサイト

インサイト 1: 「コンシェルジュ機能」への価値評価は、ユーザーの状況で 2 分される

β ユーザーへのヒアリングで、以下 2 パターンに分かれました。

Pattern A: 「決める疲れ」を抱える人 (高評価)

  • 平日夜 or 週末、外食するつもりだが「どこにするか決めるのが億劫」
  • 選択肢は多い (都市部・繁華街) が、選ぶのが疲れる
  • → Gourmie の提案がそのまま答えになる、価値評価は高い

Pattern B: 「探究好き」の人 (低評価)

  • 自分で新しい店を発掘するのが楽しい
  • 食べログ / Retty / Instagram でリサーチ済み
  • → AI 提案は「自分の判断を鈍らせるので不要」、価値評価は低い

これは「Gourmie を全ユーザーに広げるのは無理」を意味します。Pattern A に集中してマーケティング する方針に切り替えました。具体的には:

  • ターゲット: 20-40 代、フルタイム勤務、平日夕方以降の外食判断が多い層
  • Not target: 外食探究層 (別プラットフォームを既に使いこなしている)

インサイト 2: 店舗側が最も気にするのは「集客効果」ではなく「オペ負荷」

β 加盟店 (現時点で少数) にヒアリングして、意外だったのが導入時の関心事です。

予想していた質問:

  • 「集客はどれくらい増えますか？」
  • 「食べログとの違いは？」

実際に多かった質問:

  • 「メニュー登録の手間は？」
  • 「予約枠の管理は既存のシステムと重複しませんか？」
  • 「解約はしやすいですか？」

つまり、「導入時オペ負荷 + 解約容易性」が「集客期待」より優先 されていました。これは合理的で、既に食べログ + LINE 公式 + Instagram + 自社 HP を運用している店舗にとって、新プラットフォーム追加は「増えた作業」でしかありません。

Gourmie 側の対応:

  • メニュー登録の CSV import 対応 (実装済)
  • 既存 POS / 予約システムからのデータ移行支援 (β 加盟店には Reo が個別対応)
  • 解約時のデータエクスポート機能 (実装済、30 日以内)
  • 「集客保証」の売り文句を廃止 (景表法 + 過剰期待の温床になる)

インサイト 3: 「AI 提案」の説明可能性が信頼を決める

β ユーザーの継続利用の分かれ道は、「なぜこの店を勧めたか」を Gourmie が説明できるかどうか でした。

初期実装では「あなたにおすすめ」とだけ表示していましたが、継続率が低かった。

改善後: 「今日は雨予報なので駅から近い店」「予算 3,000 円以内で ★4.0 以上の店」「20 時以降でも入店可能な店」と、判断根拠を 3 行で見せる 実装に変更。継続率が改善しました。

これは Recommender System 全般の教訓ですが、Gourmie のような「体験と結びつく提案」では特に重要でした。ユーザーは「AI が神託を下す」よりも「AI がロジックを説明してくれる」を信頼します。

---

店舗プラン設計 (basic / pro / premium)

上記のインサイトを踏まえ、店舗プランは 3 tier に設計しました。詳細な料金は Stripe live 本番設定後に公表しますが、以下は設計思想です。

Basic

  • 想定利用者: 個人店・小規模店 (客席 30 席以下、SNS 発信は限定的)
  • 機能: 店舗情報公開、メニュー登録、Gourmie コンシェルジュ提案対象
  • オペ負荷: 最小 (メニュー登録さえすれば運用開始)
  • 設計意図: 「まず Gourmie に載る」を実現するためのエントリー tier

Pro

  • 想定利用者: 中規模店 (客席 30-80 席、既存 SNS 発信あり)
  • 機能: Basic + 予約枠管理、店舗ダッシュボード、リピーター管理
  • オペ負荷: 中 (予約枠の日次メンテが必要)
  • 設計意図: 「食べログ / LINE 公式と重複するオペを一本化」

Premium

  • 想定利用者: 複数店舗経営、または席単価 5,000 円超の店
  • 機能: Pro + 複数店舗管理、席単価分析、パーソナライズ提案の詳細ログ
  • オペ負荷: 大 (経営者が主体的にダッシュボードを見る必要)
  • 設計意図: 「Gourmie を経営判断ツールとして使う」

料金の正式公開は Stripe live activation 後に行います。β 加盟店には別途、有料化への移行案内をお送りする予定です。

---

「Gourmie に載せた方がいい店」の判断基準

前記事「2026 年、飲食店の QR モバイルオーダー導入で本当に得する店 / しない店」と同様、Gourmie も「載せない方がいい店」があります。フラットに書きます。

載せた方がいい店

  • 平日夜の集客に波があり、平均化したい店
  • 「決めきれない」ユーザーに向けて自店を提案してもらいたい店
  • 客単価 2,000-6,000 円のカジュアル業態
  • SNS 運用に手が回らないが、店の情報を届けたい店主

載せない方がいい店

  • 常連中心で、既に予約が満席 (Gourmie で追加流入しても運用できない)
  • カウンター寿司・割烹など「予約時の会話が接客価値」の店 (Gourmie の淡白な予約フローは合わない)
  • 席単価が極端に低い (500 円ラーメン等、Gourmie の月額を回収できない)

「Gourmie に載せれば必ず集客できる」とは言いません。載せる意味がない店に無理に売り込む気はありません。

---

GA (一般公開) 前の未解決課題

Gourmie の β → GA 移行前に、以下の課題を残しています。

1. Stripe live 特商法 URL 提出 (Reo action)

2. STRIPE_PRICE_BASIC/PRO/PREMIUM を live mode で発行 (Reo action、Stripe dashboard 操作)

3. β 加盟店の中で「有料化に同意する店舗」の抽出と案内 (10 名程度)

4. AI 提案の説明ロジック改善 (継続実装)

5. モバイル UI の PWA インストール率向上 (実装済だが UX 改善余地あり)

これらは 2026 年の後半に向けて段階的に着手します。

---

Xiora の受託開発について

Xiora は、飲食業界向け SaaS の受託開発も承っております。

  • 飲食コンシェルジュ / 予約プラットフォーム設計
  • QR モバイルオーダー導入支援 (XCloud Connect の応用)
  • POS / 既存予約システムとのデータ連携

お問い合わせは info@xiora-official.com までご連絡ください。

---

参考リンク

  • Gourmie ユーザーサイト: https://gourmie.jp/
  • Gourmie 店舗管理: https://gourmie.jp/merchant
  • Xiora コーポレートサイト: https://xiora-official.com/
  • 関連記事「2026 年、飲食店の QR モバイルオーダー導入で本当に得する店 / しない店」: (note にて公開予定)

---

筆者: Xiora 代表 沓澤 怜士 (kutsuzawa reo)

連絡: info@xiora-official.com

免責: 本記事は Gourmie β 運用中の観察結果であり、GA 後の状況・料金・機能は変更となる可能性があります。導入判断は個別の店舗事情に応じてご判断ください。

関連 Xiora プロダクト

本記事のトピックに直接関わる Xiora 自社プロダクトです。 いずれも公開情報、¥0 で概要確認できます。

関連ツール (提携リンク)

本記事の内容を実装するにあたり、Xiora が業務で採用しているツール群です。 リンクは提携リンク (advertisement) を含み、経由でお申込みの場合は Xiora に紹介料が入る場合があります。 記事内容の中立性は維持しています。

  • Notion — SMB のドキュメント / ナレッジ管理 SaaS
  • Vercel — Next.js を最速で公開する PaaS
  • Railway — コンテナ / DB を 1 分で立てる PaaS
  • Cloudflare — エッジ CDN + Zero Trust

※ Reo Absolute Gate (KYC) 承認待ちの placeholder URL。 承認後、代理人が sed で real referral ID に一括置換します。

← Insights 一覧へ