こんにちは、普段はクラウドインフラやSREの仕事をしてる者です。
今回は、LINEで食材の画像を送るとレシピを提案してくれるAIボット をMVPで作ったつもりが、
なぜか気づいたら、AWS SAMだの環境分離だのSSMパラメータ管理だの、本番顔負けのインフラ構成になっていた。
そんなCooksnap（クックスナップ）というプロダクトの話をします。
LINEで野菜を送るとAIが晩飯を教えてくれる。それだけ。
- 食材の画像をLINEで送る
- Claudeが画像から食材を判別してレシピを生成
- SNSでシェアも可能、紹介コードで友達招待もOK
こんなことができます。
想定ユーザーは「冷蔵庫にある食材で何作ればいいかわからん…」って40代後半から上の人。
なので考えささないUI を目指しました。
作成意欲の源は、嫁が料理をしてくれないからです。。。
作っただけのつもりが、AWS SAMでIaCまでやってた
ぼくの中ではこうだったんですよ。
最初は「Lambda一個でいいでしょ」と思ってました。
…だったはずが、気づいたらこう↓
* AWS SAM でIaC（環境分離済み）
* AWS SAM + Lambda + API Gateway
* DynamoDB（GSIあり）+ S3
* SSM Parameter StoreでSecrets管理
* Claude API（レシピ生成）
万が一、ユーザー反応を多く得られた場合を期待して、スケールアップが容易にできることを念頭に考えました。
これは、現場で見た数々のカオスから得た学びです。
「やってみた」感あるけど、わりと本気
Claude使った食材識別とか、それっぽくプロンプト設計したけど、
まあ正直、「家庭料理の中の家庭料理」みたいなレシピしか出てこない。
微調整などは、現在考慮していない。
でも設計は気合い入れた。
- リッチメニュー作った（LINE UXの山場）
- 紹介コード機能つけた
- レシピのSNSシェアもできる（広告をユーザーにやってもらうスタイル）
本当は書かなくてもいいけど、書くのがQiitaっぽい学び
ここが反省点
| 項目 | 内容 |
|---|---|
| GitHub Actions未導入 | MVPではまったく必要ないが、スケールアップするなら必要。 |
| Claudeの認識精度に波がある | 本番画像だと失敗もある。誰かが使ってくれるなら検討。 |
| LINEのUXは地味に難しい | 「迷わず使える」を設計するのに時間がかかる。 |
| バックエンドは知ったかだった | 分かったつもりでも、ゼロから作るのは時間がかかった。AI使っても |
MVPだけどSRE目線でやったこと
| 項目 | 具体内容 |
|---|---|
| 環境分離 | SSM, DynamoDB, Lambdaをdev/prodで切替 |
| Secrets管理 | SSM Parameter Storeでハードコード撲滅 |
| IAM制御 | Lambdaには最小権限ロールのみ付与 |
| コスト管理 | 無料枠の使用量を記録、料金通知をCloudWatchで試験中 |
宣伝タイム：LINEで使えます
もういいから使ってくれ！これが言いたかった！
そしてお母さん、お父さんに教えて！
ターゲットはAI を使いこなすQiitaユーザーではない！
以下のリンクから友達追加すれば、実家の冷蔵庫ライフがAIに救われる。かもしれない。
📲 Cooksnap LINE公式
🔗 友達紹介コード：NL9Y7E
次回予告（誰かが使ってくれたら）
- Terraform化し、Webアプリ版
- マネタイズ構想（広告か、プレミアムレシピ）
- GPT-4にするかClaude続けるか、レシピの精度の向上
最後に
MVPって本来はもっと雑でも良いはずなんですが、
「せっかくだし、今後ポートフォリオにもなるように」と思った瞬間、設計が真面目になってしまいました。
でも結果として、一人開発でも「再利用できるServerless基盤」として仕上がったと思います。