Overview
Food Lens（仮） は、外食した料理の写真を撮るだけで、店名・料理名・ジャンルなどの情報をAIと位置情報から自動推定し、食事ログとして蓄積できるサービスである。
一言で言うと、「料理の写真を撮るだけで、食事ログが完成する」記録アプリである。
背景として、既存の食事記録アプリの多くは手入力が前提で継続しづらく、また外食は「お店」単位で管理されることが多いため、「料理」単位で体験や好みを蓄積できるサービスが少ないという状況がある。写真・位置情報・AIを組み合わせることで記録をほぼ自動化し、料理を中心とした新しい体験を提供することを目指す。
Problem
- 外食の記録は面倒で続かない。店名や料理名を毎回手入力する手間が、継続利用の障壁になっている。
- 「あの美味しかった料理」を後から思い出せない、同じ料理を複数店舗で食べ比べても記録として残せない、といった不満がある。
- 既存サービスの多くは店舗中心・手入力中心・健康管理目的（カロリー・栄養）に寄っており、「料理そのものへの興味・思い出の蓄積」というニーズに応えるサービスが手薄である。
Goals
- 料理写真とGPS位置情報の入力だけで、店名・料理名・ジャンル・撮影日時・位置情報を自動推定し、ワンタップで保存できる状態にする
- ユーザーが必要な場合のみ推定結果を修正できる、低負荷な確認フローを実現する
- 料理履歴・店舗履歴・ジャンル検索によって、蓄積したログを振り返れる状態にする
- 「店」ではなく「料理」を主語にした記録体験を、既存サービスとの差別化として確立する
Non Goals
- カロリー推定・栄養情報の提供：本サービスは健康管理目的ではなく、料理体験の記録・蓄積を目的とするため、MVPでは扱わない。
- 店舗検索・料理ランキング・AIによるおすすめ料理などの推薦系機能：MVPは記録の自動化に集中し、蓄積したデータを使った推薦・発見体験は今回のスコープに含めない。
- 上記以外の「将来的な機能」（食べ歩きマップ、コレクション機能、レビュー自動生成など）も同様にMVPでは扱わない前提だが、優先度は未整理のためOpen Questionsに記載する。
Users
- ペルソナ：外食が好きな人、食べ歩きが趣味の人。特定ジャンル（ラーメン、カレーなど）を継続的に記録したい人。旅行先での食体験を記録したい人。
- ユースケース：外食した直後にその場で写真を撮り、ほぼ無操作でログを残す。過去に食べた料理をジャンルや店舗単位で振り返る。
- 利用シーン：外出先・外食中のスマートフォン利用が中心。店を出た直後や食事中など、手が離せない・時間をかけたくない場面での利用を前提とする。
User Stories
- 外食が好きな人として、料理の写真を撮るだけで店名・料理名を毎回入力せずに記録したい。
- ラーメン好きとして、これまで食べたラーメンをジャンル単位で振り返り、食べ比べを記録したい。
- 旅行先で食事をした際、位置情報から店舗候補が自動で出てきて、選ぶだけで記録を完了したい。
- AIの推定が間違っていた場合、細かく入力し直すのではなく、必要な部分だけ簡単に修正したい。
- 過去に記録した料理履歴・店舗履歴を、後から見返して「あの美味しかった料理」を思い出したい。
Requirements
- 写真撮影：料理写真の撮影・アップロード機能（User Story: 写真を撮るだけで記録したい）
- 位置情報取得：GPS位置情報の取得（User Story: 位置情報から店舗候補が自動で出てほしい）
- 料理ジャンル推定（AI）：撮影した写真からジャンルを自動推定（User Story: ラーメンなどジャンル単位で記録したい）
- 店舗候補取得：位置情報を用いた周辺店舗候補の取得（User Story: 旅行先で店舗候補が自動で出てほしい）
- 店舗メニューとの照合：取得した店舗候補のメニュー情報と写真を照合（User Story: 店名・料理名を入力せずに記録したい）
- 料理名候補生成（AI）：店舗メニュー照合結果や画像から料理名候補を生成（User Story: 店名・料理名を入力せずに記録したい）
- 推定結果の確認・修正・保存：店名・料理名・ジャンル・撮影日時・位置情報を提示し、必要に応じて修正した上でワンタップ保存（User Story: 推定が間違っていた場合に簡単に修正したい）
- 食事ログ保存：確定した情報を食事ログとして保存（User Story: 過去の記録を振り返りたい）
- 料理履歴表示：保存済みログを料理単位で振り返れる一覧（User Story: あの美味しかった料理を思い出したい）
- 店舗履歴表示：保存済みログを店舗単位で振り返れる一覧（User Story: 過去の記録を振り返りたい）
- ジャンル検索：ジャンル単位でログを絞り込み・検索（User Story: ジャンル単位で記録・食べ比べを記録したい）
Success Metrics
- AIによる店舗・料理名の推定精度（ユーザー修正なしで保存された割合）
- ユーザーが修正操作を行った場合の平均修正時間・タップ数（入力負荷の指標）
- 記録の継続率（例：初回記録から1週間後・1ヶ月後の再利用率）
- 「料理」を主語にした検索・振り返り（料理履歴・ジャンル検索）の利用頻度
具体的な数値目標や測定期限は企画メモの時点では未設定のため、Open Questionsに記載した。
Open Questions
- AIだけでの推定精度がどの程度出るか：店舗・料理名の推定精度の実測値が未検証。検証したいこととして挙げられているが、MVPでどの精度を合格ラインとするかは未定。
- ユーザー修正を含めた入力負荷が十分低いといえる基準：「低負荷」の定量的な基準（タップ数・所要時間など）が未定義。
- 「店」ではなく「料理」で記録したいニーズの検証方法：仮説として掲げられているが、MVPでどう検証するか（アンケート、利用ログ分析など）は未定。
- 技術スタックの確定：フロントはFlutterかNext.jsか、AIはOpenAI VisionかGemini Visionか、いずれも「イメージ」段階であり確定していない。
- 「将来的な機能」の優先順位：カロリー推定・栄養情報・推薦系機能をNon Goalsとした一方、食べ歩きマップやコレクション機能などその他の将来機能の優先順位は未整理。
- stageの位置づけ：本PRDでは指示者判断によりfront matterの
stage項目を省略しているが、今後MVP後のフェーズ管理をどう扱うかは別途整理が必要。
Design Principles
- 記録の手間を徹底的に減らすことを最優先する：手入力の手間が既存サービスの継続率を下げている課題認識から、AとBで迷ったときは「入力の手間が少ない方」を選ぶ。
- 主語は「店」ではなく「料理」に置く：機能設計やデータ構造で店舗中心か料理中心か迷った場合、料理を主語にした設計を優先する。これが既存サービスとの差別化の核である。
- 健康管理ではなく体験・思い出の蓄積を目的とする：カロリー・栄養情報のような健康管理色の強い機能は、MVPでは意図的に避け、料理体験の記録・振り返りに集中する。
- AI推定は完璧を目指さず、修正しやすさで補う：AIによる自動推定の精度を過度に追求するより、外れた場合にユーザーが低負荷で修正できる体験を優先する。