置き換えダイエット

置き換えダイエットアプリ

ダイエット中に「これが食べたい」と思ったとき、これまでは我慢するか諦めて食べるかの二択しかありませんでした。「何に置き換えればいいか分からない」という悩みを解消するために、料理名を入力するだけでAIが置き換えレシピを提案し、実際に食べたかどうかの記録が削減カロリーとして積み上がり、目標体重までの進捗が見えるアプリを作りました。

できること

• AIによる置き換え提案: 料理名を入力すると、カロリーを抑えた置き換えレシピをAIが提案
• 記録と可視化: 実際に食べた内容を記録し、削減カロリーを週単位で積算
• 目標管理: 目標体重・期日から、1日あたりの削減カロリー目安を自動算出
• 体重管理: 体重の記録とグラフ表示
• 深夜ラジオ: その日の記録をもとに、AIの2人組DJが本人の噂話をする構図でラジオを自動生成・音声合成
• 提案の多様性チェック・クイズ・レーティング: 同じ提案に偏らないようEmbeddingsで過去の提案と比較し、置き換え成功率をレーティングとして可視化
• 探すクエスト: 提案された置き換え食材を実店舗で探し、写真付きで発見報告(集合知でスーパーの在庫情報を代替)

システム構成

[システム構成図] app.pyが全ルートを持つ単一のFlaskアプリで、機能ごとにservice層・repository層を分離。データベース・認証・ファイルストレージはSupabase(Postgres)、AI生成はOpenAI API、音声合成は無料で使えるVOICEVOX(AWS EC2で別サービスとして分離運用)、地図表示にGoogle Maps APIを使用。機能間の連携はHTTP通信ではなく、DB経由の「Shared Database」パターンに統一しています。

こだわったところ

• 深夜ラジオの記憶システムはGenerative Agents方式を参考に、milestone(重要な出来事)・highlight(印象的な発言)・reflection(傾向の振り返り)の3種類を重要度と経過日数でスコアリングし、伝言ゲーム的に内容が歪まないよう追記型で設計
• 「今困っていないことのために部品を増やさない」という判断基準を徹底。Embeddingsは提案の多様性チェックで必要になった箇所だけに導入し、pgvectorのような専用の仕組みは使わずPythonでの全件比較に留めた
• スーパー横断のリアルタイム在庫APIは存在しないという技術的制約を早期に見極め、正確な在庫情報を追うのではなく、ユーザー投稿による集合知でカバーする設計に転換

学んだこと

• gunicornのワーカー数(-w)を複数にすると、プロセス内メモリで持っている状態(生成中フラグなど)が別プロセスからは見えなくなる、という並行処理の落とし穴
• Supabaseクライアントを毎回作り直すと、ポーリングするエンドポイントでメモリリークが起き、本番で自動再起動が繰り返される実害につながること
• RLSは「有効化」と「ポリシー設定」が別物で、有効化だけではデフォルト全拒否に近い状態になること

使用技術

• バックエンド: Python / Flask(gunicorn)
• データベース・認証・ストレージ: Supabase(Postgres)
• AI: OpenAI API(レシピ提案・深夜ラジオ台本生成・Embeddings)
• 音声合成: VOICEVOX(AWS EC2上で専用サービスとして運用)
• 地図: Google Maps API(探すクエスト機能)
• フロントエンド: HTML / CSS / JavaScript(素のまま、フレームワーク不使用)
• ホスティング: Render(メインアプリ、無料枠)、AWS EC2(VOICEVOXのみ)