kohei yamada

Ai-meshi ― AIを活用したSNS型レシピアプリ（個人開発・本番公開中） 冷蔵庫の残り物からAIが献立を提案し、レシピの投稿・共有・保存・コメント・買い物リスト作成までつなげるWebアプリです。要件定義から本番運用まで一人で担当しました。 ▼ サービス / API / GitHub ・https://aimeshi.com ・https://api.aimeshi.com ・https://github.com/kou-pro/ai-meshi 【解決したい課題 / 想定ユーザー】 「冷蔵庫にある食材で何を作るか考えるのが面倒」「食材を無駄にしたくない」という日常の負担を減らすためのアプリです。自炊する一人暮らし〜共働き世帯を想定しています。 【主要機能】 AIレシピ生成（OpenAI API）／メール認証・Google OAuth・ゲストログイン／レシピ投稿・編集・公開非公開／いいね・コメント・保存／フォロー／キーワード・タグ検索／買い物リスト 【技術スタック】 ・バックエンド：Ruby on Rails 7.2（APIモード） ・フロントエンド：Next.js（App Router）/ React / TypeScript / Tailwind CSS ・DB：MySQL（Amazon RDS） ・インフラ：AWS（ECS Fargate / ALB / S3 / Route 53 / ACM / ECR / CloudWatch）/ Docker ・CI/CD：GitHub Actions（RSpec・RuboCop・ESLint・Vitest） 【設計でこだわった点（“AIのAPIを呼ぶだけ”では終わらせない）】 このアプリは、認証・データ・インフラ・セキュリティ・運用まで一貫して設計しています。 ・認証：BFF構成を採用。devise_token_authで発行したトークンをHttpOnly Cookieに保持し、フロントのJavaScriptから触れない形にしてXSSによる漏えいリスクを低減。SameSite属性でCSRF対策も実施。Google OAuthもこのBFFフローに統合。 ・インフラ/ネットワーク：フロント用とAPI用にALBを分離したBFF構成。ECSタスクはALBのセキュリティグループからのみ、RDSはRails ECSのセキュリティグループからのみ通信を許可し、最小限の経路に限定。 ・運用：mainブランチへのpushを起点に、GitHub ActionsでECRへのイメージpush〜ECSデプロイまで自動化。 【最も苦労した実装：BFF認証アーキテクチャ】 Google OAuthで得た認証情報をフロント側に置くと、XSSでトークンが漏れるリスクがあります。これを避けるため、devise_token_authで発行したトークンをHttpOnly Cookieに格納し、フロントのJSから触れない構成にしました。認可コードを短命なうちにサーバー側で交換する処理、Cookieのドメイン/SameSite設定、Next.js↔Rails API間の中継を、断片的な情報を調べながら一つずつ組み上げるのに最も時間がかかりました。「動けばいい」ではなく「なぜこの構成が安全か」を理解する必要があった点が核心です。 【発生した障害と改善】 当初、買い物リストに追加した食材が、元レシピの作成者がそのレシピを削除すると一緒に消えてしまう不具合がありました。買い物リストがレシピを参照していたため、親（レシピ）の削除に子（リスト項目）が巻き込まれていたのが原因です。改善として、リストに追加する時点でレシピ名や材料を買い物リスト側のテーブルに保存（スナップショット化）し、レシピ本体への依存を切りました。これにより、レシピが削除されても買い物リストは保持されます。「データの所有者と参照のあり方」を考える良い経験になりました。 【今後改善したいこと】 ・1週間分のレシピをまとめて買い物リストに追加できる一括登録（1件ずつ追加する手間を減らす） ・AIが生成したレシピに不満がある場合に、その場で修正・再生成できるインタラクティブな調整 ※ 画像はトップ画面に加え、AWSインフラ構成図・ER図、主要操作の短い動画を掲載予定。