どういう課題に、
どう関わったか。

事業背景

なぜ作ったのか

課題仮説

ユーザーの何を解決したかったのか

• 選択の疲れ

  選択肢が多すぎて、決めきれない。

• 口コミの迷子

  情報を読んでも、自分に合うかがわからない。

• 時間の消費

  毎日のことなのに、決めるまでに時間がかかる。

条件で絞り込む検索ではなく、そのときの「気分」やシーンから候補を比べて提示できれば、決めるまでの時間を短くできるのではないか。

プロダクト設計

どういう体験にしたのか

実施内容

企画から運営まで、すべての工程を担当しています

• 企画
• 市場・競合調査
• UX 設計
• UI 設計
• 要件定義
• システム設計
• 実装
• AI 検索
• インフラ構築
• SEO
• アクセス解析
• 運用
• 改善
• アプリ化（開発中）

意思決定

なぜこの仕様にしたのか

1. 検索を「言葉を広げる → 探す → 並べ替える」の 3 段にした

   気分やシーンを表す言葉は、店舗情報に書かれている言葉と一致しないことが多くあります。AI で検索語を複数の言い回しに広げてから探し、最後に好みに合わせて並べ替えることで、言い方の違いによる取りこぼしを減らしました。

2. 取りこぼしと運用コストを理由に、検索基盤を切り替えた

   当初のベクトル検索の構成では、キーワードの取りこぼしと運用の負担が課題になりました。マネージドの検索サービスに移し、必要な機能と費用のバランスから上位プランではなく標準プランを選んでいます。

3. 「事実」と「推測」を混ぜない

   推薦理由に添えるラベルは店舗の事実データから決まる対応表で作り、AI はその中から選ぶだけにしました。AI がもっともらしい誤情報を出すリスクを、プロンプトではなく仕組みで抑えるためです。

4. 会員登録なしで試せるようにし、利用回数に上限を設けた

   最初の体験のハードルを下げるため、ゲストでも AI 検索を使えるようにしました。一方で AI の利用料が際限なく膨らまないよう、回数の上限とボット対策を組み合わせています。

5. 気分を言葉にしなくても選べる導線を足した

   「気分を言葉にする」こと自体が負担になる場面に向けて、選択肢を選んでいくだけで提案まで進める導線をリリース後に追加しました。

   もとの導線

   気分を言葉にして入力し、提案を受け取る。

   公開後に追加した導線 →

   選択肢を選んでいくだけでも、提案まで進める。

   狙いは、「気分を言葉にする」負担を減らすこと。入力する方法に加え、選んで進む方法も用意しました。

6. 処理が詰まらない構成に切り替えた

   外部サービスの応答を待つ処理が長引くと、ほかのリクエストまで止まってしまう構成だったため、利用が増える前に並行して処理できる構成へ移しました。

運用・改善

リリース後に続けていること

• Search Console で事実を確かめながらの SEO 改善（AI 検索結果ページの検索エンジン対応など）
• アクセス解析のイベント設計と、投稿導線の離脱計測
• メニュー画像・店舗写真からの AI による情報読み取りなど、運営作業を減らす機能の追加
• サインイン手段の追加、ジャンル・営業形態での絞り込みなど、利用状況を踏まえた機能改善
• AI によるコードレビューを組み込んだリリース前チェック
• iOS / Android アプリ化（開発中）

技術

上記の判断を支えている構成

Frontend

Nuxt 4（SSR）/ TypeScript

Backend

Laravel 12 / PostgreSQL・PostGIS

AI / Search

Gemini / Vertex AI Search

Infrastructure

AWS Lightsail / Cloudflare（CDN・R2・Turnstile）

Mobile

Capacitor（開発中）