35,000行の料理アプリをVibe Codingしてみました
(recipeninja.ai)- 起業家出身の投資家が20時間のVibe Coding作業で開発した料理アプリ
- 中核機能は、料理中に手を使わず操作できる音声アシスタント
- Rails 8 APIバックエンド + Reactフロントエンド + OpenAIのリアルタイム音声API
- OpenAIの関数呼び出し機能を活用し、サイト内をリアルタイムに探索可能
- Claude CodeとGemini 2.5 Proを使って複雑な機能を補完
- 全体のコード規模は約35,000行
- 音声コマンドによって、ユーザーが手を触れずにさまざまなレシピを探索可能
- 自然な対話型インターフェースを提供
- 趣味プロジェクトとして始まったが、実際に役立つ機能とユーザー体験を備えた完成度の高い成果物になった
Vibecodingで料理アプリを完成させる
- わずか20時間で自ら企画して作った料理アプリ recipeninja.ai
- 筆者はスタートアップ創業者出身で、現在はY Combinator所属の投資家であり、2015年以降Rubyをほとんど使っていない**「さびついた開発者」**
- 普段から料理を楽しんでおり、「ハンズフリー料理アプリ」というアイデアを長年温めてきた
- 既存の料理サイトはSEO重視で、アプリもUXが古く、Paprikaのようなアプリは2009年の雰囲気のままだという不満
ツール選定とプロジェクト開始
- 当初はLovableを使って単語ゲームアプリを試したが、限界にぶつかった
- その後Windsurfを使い、Rails 8 APIバックエンド + Reactフロントエンド構成にした
- Homebrew、npm、Rubyバージョン設定、SSHキー、Heroku設定まで自動化
- Railsマイグレーションも標準ルールに合わせて自動処理された
基本機能の開発
- 「Lasagne」のような簡単な入力だけでレシピ全体を生成
- OpenAIによるレシピテキスト生成、ElevenLabsによる音声生成
- ステップごとの音声ガイドと画像出力機能を搭載
- セキュリティリスクを検知したWindsurfがAPIキー露出防止を強く求める挙動も印象的だった
機能拡張と反復的な開発フロー
- 写真ベースの「高度なレシピ取り込み」機能を数分で実装
- コンソールログやエラーメッセージをコピペするとWindsurfが自動で修正
- Google OAuth連携では設定スクリーンショットを貼り付けると誤りを即座に検出してくれた
- ユーザー別のレシピ保存、公開/非公開設定などの機能追加もほぼ自動で行われた
デプロイとDNS設定
- Herokuデプロイの自動化、一部の旧版API使用問題はドキュメントリンクで解決
- GoDaddyのドメイン接続も、押す場所のボタンや入力値まで案内してくれて簡単に設定完了
AIツールとしてのWindsurf使用体験
- 一部の機能は自分でcurlリクエストやWebプレビューを実行してテストした
- GitコミットとHerokuデプロイも内蔵ターミナルで自動処理
- ただし、過度な変更や確認なしのコミットにはユーザーの介入が必要
- 分析機能追加を依頼すると100件以上のイベントを追加してしまうなど、過剰反応もあった
惜しい点と改善点
- 自動テスト機能がなく、コード変更後は手動でテストが必要
- ログtail機能がなく、N+1クエリなどを検知するにはログを手動でコピーして貼り付ける必要がある
- 重複コードのリファクタリングはうまく機能せず、機能を維持したままコードだけをモジュール化するには具体的な指示が必要
- APIレスポンス形式が頻繁に変わり、フロントエンドが壊れる問題が発生
- Posthog分析導入の失敗、音声コマンドが既存音声と衝突する問題も発生
パフォーマンス最適化とコスト削減
- 高解像度画像の問題 → サムネイルと中解像度版を自動生成
- N+1問題を自動修正
- ElevenLabs APIキーをバックエンド側に移し、音声キャッシュ機能を追加してコスト削減
爆発的な生産性向上
- 毎セッションごとに10〜15個の機能アイデアをリストアップし、30分以内にすべて実装
- 従来なら数時間かかる作業が1〜2分で実装
- デザイン改善もスクリーンショットで指示するだけで、視覚的完成度の高いUIを生成
- DoorDashアプリのカルーセルを参考に類似デザインを実装し、むしろこちらの方が見やすいという評価も得た
仕上げ作業とセキュリティ問題
- Favicon設定もBashスクリプトで自動化
- Twitter投稿後に数百人のユーザーが訪問し、約1,000件のレシピを生成
- しかしabuseユーザーによってOpenAI料金が700ドル発生
- Windsurfが15個の防御戦略を提示し、10分でその大半を適用して問題を解決
今後の計画と技術的展望
- WebSocketベースのストリーミングレシピ生成機能を導入予定
- 例: 「ナッツを追加して」「8人分に変えて」「メートル法に変換して」のような指示をリアルタイムに反映
- 音声エージェントインターフェースも構築予定 — 画面に触れずに料理中の質問が可能に
- 例: 「パクチーがないけど代わりになる食材はある？」「30分タイマーを設定して」
- 技術的背景のあるユーザーにとって、AIツールはスーパーパワーになる
- 非開発者でも活用できる方向へ進化中: ログtailing、自動テスト、バージョン管理の統合を予定
- 近い将来、コード記述の95%がAIによって行われる時代が来る可能性に言及
RecipeNinjaの主要機能まとめ
- 中核コンセプト: このアプリはステップごとの音声案内を提供する料理支援アプリケーションで、ユーザーが手を使わずに料理を進められるよう支援する
バックエンド機能（Rails APIベース）
-
ユーザー認証と権限管理
- Google OAuth連携によるログイン機能
- セキュリティを強化したユーザーアカウント管理
- ユーザーは自分の非公開レシピにのみアクセス可能で、公開されたレシピだけを他人と共有可能
-
レシピ管理機能
- レシピモデル構成
- セキュリティのための一意な公開IDを付与（形式:
r_+ 14桁の乱数文字列） - ユーザー所有権の明確化（user_idフィールド、NOT NULL制約）
- レシピの公開/非公開切り替えが可能（デフォルト: 非公開）
- タイトル、材料、調理手順、調理時間などさまざまな情報を保存
- Active StorageとS3を活用した画像アップロード機能を含む
- セキュリティのための一意な公開IDを付与（形式:
- タグシステム
- レシピとタグの多対多（M:N）関係を構成
- タグは一意な名前を持つ別モデルとして実装
- レシピ-タグ間の接続のために中間モデル（RecipeTag）を使用
- タグ追加・削除のためのヘルパーメソッドを提供
- レシピAPIエンドポイント
- CRUD操作をサポート
- ページネーション機能とメタデータを提供（current_page、per_pageなど）
- デフォルトの並び順は作成日基準の新しい順（created_at DESC）
- タグフィルタリング機能をサポート
- 一覧と詳細情報をそれぞれ異なるシリアライザで出力（RecipeSummarySerializer、RecipeSerializer）
- レシピモデル構成
-
音声生成機能
- 音声録音システム
- 各レシピ手順に対する音声案内を生成
- Eleven Labs API連携でテキストを音声に変換
- 音声ファイルはS3にキャッシュされ、繰り返し呼び出し時のAPIコストを削減
- レシピID、手順ID、音声IDを組み合わせた一意識別子を生成
- 音声ファイルの強制再生成機能を提供
- オーディオ処理
streamio-ffmpeggemを用いてオーディオ分析を実施- Active Storageでオーディオファイルを管理
- 本番環境ではS3を活用した保存方式を適用
- 音声録音システム
-
レシピ取り込みと生成
- RecipeImporterサービス
- OpenAI連携による自動レシピ生成
- テキストベースのレシピを構造化形式へ変換
- 材料と手順を正規化およびパース処理
- 写真によるレシピ取り込み機能を含む
- RecipeImporterサービス
フロントエンド機能（Reactベース）
-
ユーザーインターフェース構成要素
- レシピ選択と探索
- ページネーション適用済みのレシピ一覧を表示
- 10秒間隔のリアルタイム更新機能
- タグベースのフィルタリング機能を提供
- 画像なしで要約情報を表示するレシピカードを提供
- 各レシピに「詳細を見る」と「料理を始める」ボタンを提供
- レシピ選択と探索
-
レシピ詳細表示
- レシピ全体の情報を表示
- レシピ画像を表示
- クリック可能なタグ一覧を提供
- そのページから直接料理を開始可能
-
調理中インターフェース
- ステップごとの調理ガイドを提供
- 各ステップに対して音声案内をサポート
- ハンズフリー操作のためのキーボードショートカットをサポート:
- 方向キー（←/→）: ステップ移動
- Spaceキー: 音声の再生/一時停止
- ESCキー: レシピ一覧へ戻る
- URLパスによるステップ追跡が可能（例:
/recipe/r_xlxG4bcTLs9jbM/classic-lasagna/steps/1）
状態管理とデータフロー
-
Recipe Service
- API経由でレシピデータを取得
- ページネーションパラメータをサポート
- タグベースのフィルタリング機能
- レシピデータのキャッシュ機構を適用
- 詳細表示で使用する画像URL処理機能
-
認証フロー
- 環境変数を活用したGoogle OAuth連携
- ユーザーセッション管理
- APIリクエスト時の認証ヘッダーを自動処理
PWA（Progressive Web App）機能
- さまざまなデバイスにインストール可能なPWAとして提供
- あらゆる画面サイズに対応するレスポンシブデザインを適用
- Faviconおよびアプリアイコンをサポート
デプロイアーキテクチャ
-
二重アプリ構成
cook-voice-api: HerokuにデプロイされたRailsバックエンドcook-voice-wizard: HerokuにデプロイされたReactフロントエンドおよびPWA
-
バックエンドインフラ
- Ruby 3.2.2を使用
- Heroku PostgreSQLアドオンによるデータベース構成
- Amazon S3を活用したファイル保存
- 環境変数による設定管理
-
フロントエンドインフラ
- Reactベースのアプリケーション
- 環境変数設定によってAPIキーなどの機密情報を管理
- Herokuの静的ビルドパックを使用
- SPA（Single Page Application）ルーティング構成
-
セキュリティ対策
- HTTPSを強制適用
- Rails Credentialsシステムを使用
- 機密情報は環境変数に分離
- DB IDの代わりに公開用Public IDを使用して内部構造を保護
1件のコメント
Hacker Newsのコメント
印象的。35 kLOCはかなりの分量。このアプリがどれほど直感的で保守しやすいのか気になる。ソースを見てみたい。良いRailsコードは簡潔だが、フロントエンドはかなり大規模になり得る
Diarrhea Walnutsのレシピを作ったが、クルミアレルギーがあるので問題になったという意見。法的措置を取るつもり
Claude Codeは有用だという意見。ただしデバッグはo1 Proのほうが優れていると思う
Jian YangとBig Headが新しいアプリを作っているみたいだという意見
レシピ簡略化サイトを書いたことがあるので、このプロジェクトは面白いと思う。保守プロジェクトにおけるエンジニアの主な価値はコンテキストだと思う。そのコンテキストを完全に機械へ渡すとどうなるのか気になる
OpenAIのRealtime APIを使った音声応答について、アプリが人気になったらコストの問題で破綻するのではないかという懸念がある。別件でOpenAI Audio APIを使う予定なので、このあたりの戦略が気になる
ウェブサイト上で材料をどこで入手できるか教えてくれる「vibecode」を作れるかという質問。特定の食材は見つけにくい
レシピは面白いが、AIが生成したものだと分かると創造性が失われるという意見。Comprehensive JavaScript Tutorialがいちばん気に入った
主要機能は音声操作なのかという質問。ほかの人気レシピサイトと比べて、このアプリを選ぶ理由が気になる。主にエンジニアリング/AIテストのための練習なのかという疑問
タイトルにNSFWを追加すべきだという意見。最初のページにNSFWレシピが50%以上ある