Corkive

課題

飲んだワインはすぐ忘れます。おいしかったという記憶は残っても、銘柄も産地も残らない。しかも記録すべきタイミングは「飲んでいる最中」、つまり最もメモを取りたくない状態です。

AI チャットで調べる方法もありますが、会話は流れて消えます。撮った写真と、調べた分析結果が結びつかないまま別々の場所に溜まっていく——これが解きたかった問題でした。

やったこと

ボトルの正面・背面を2枚撮影すると、LLM が銘柄・産地・品種・味わいを分析します。結果は Markdown 形式でユーザー自身の Google Drive に保存され、Strava 風の透過シェア画像が自動生成されます。

体験は「撮るだけ」に絞りました。保存・整形・命名・分類はすべて自動化し、手動セーブという操作自体をなくしています。

設計上の意思決定

分析結果をユーザー自身の Google Drive に置き、囲い込みを放棄した

• 判断：データの保存先をサービス側の DB ではなく、ユーザーの Google Drive にした（drive.file スコープ）。
• 選択肢：自前 DB に保存してエクスポート機能を付ける、という一般的な構成。
• 理由：飲んだ記録は本人の資産であって、サービスの資産ではない。drive.file スコープならサービスは自分が作ったファイルしか触れず、プライバシー面の説明が単純になる。
• 結果：ロックインを放棄する代わりに、認証・ストレージ・バックアップの実装が消えた。この方針がその後の技術選定全体を規定した。

精度ではなく「出力の型」を先に固めた

• 判断：LLM の分析結果を、先に決めた Markdown スキーマに必ず流し込む形にした。
• 選択肢：自由記述で出力させ、表示側で整形する。
• 理由：LLM の出力は精度を上げても揺れる。揺れても壊れない受け口を先に作る方が、プロダクトとして成立させやすい。
• 結果：スキーマが決まったことで、シェア画像の生成も検索も後付けできるようになった。

詰まったところ・失敗

学び

• LLM を使ったプロダクトでは、精度より先に出力の型を決める。型が決まっていれば、精度は後から上げられる。
• 「データを誰のものとして置くか」は思想の話に見えて、実際にはアーキテクチャ全体を決める技術判断だった。