Firebase AI LogicとGeminiでAI食材庫を作る

ローカル優先のモバイルアプリを複数運営する個人開発者として、私が大切にしてきたのは速度、実用性、コスト効率です。TinyRecipeの目標はシンプルでした。冷蔵庫や食料庫に今ある食材だけを使った実用的な手順付きレシピを作り、食品ロスを減らすことです。

モバイルアプリに生成AIを追加する際、設計を慎重に行わないと、応答の遅延、予測できないJSON、APIコストの増加につながります。Firebase AI LogicとVertex AI上のGeminiを統合し、運用コストを抑えながら高速で構造化されたレシピ生成を実現した方法を紹介します。

中心となる課題：LLMに制約を設ける

LLMに自由にレシピを作らせると、すぐに3つの問題が生じます。

幻覚や奇妙な組み合わせ： オリーブオイル、醤油、レモンでスープを作るよう提案するかもしれません。
スキーマの不一致： 自由形式のテキストや構造化されていないMarkdownをモバイルUIのコンポーネントに変換すると、クライアント側で不安定なエラーが発生します。
トークン消費量の増加： 長さを制限しない回答は、複数手順の説明でトークン予算をすぐに使い切ります。

FirebaseのVertex AIバックエンド連携を使い、厳格なシステム指示と構造化出力の解析を適用しました。

1. システムプロンプトの制約とJSONスキーマの適用

モデルに良いレシピを尋ねるのではなく、システムプロンプトで厳密なJSONスキーマに従わせます。

{
  "title": "String",
  "prep_time_minutes": "Number",
  "difficulty": "Easy | Medium | Hard",
  "matched_pantry_items": ["Array of Strings"],
  "missing_staples_required": ["Array of Strings"],
  "instructions": [
    {
      "step_number": 1,
      "text": "String"
    }
  ]
}

次の2つの制約により、実用性が大きく向上しました。

基本調味料の除外： 塩、こしょう、水、食用油を食材リストでチェックする必要はありません。プロンプトでこれらを基本食材として許可し、選択UIの手間を減らします。
食材の厳密な分離： モデルは追加食材を提案する前に、デジタル食材庫で利用可能とされた食材を優先します。

2. クライアント側の最適化：スムーズなUX

料理中にモバイルキーボードで「角切り鶏むね肉250g」と入力したい人はいません。

[食材タグをタップ] -> [クライアントで配列を作成] -> [Firebase AIへリクエスト] -> [ネイティブUIに表示]

カテゴリ別のクイック選択タグ： 冷蔵庫や食料庫によくある食材をカテゴリ別のタグからすばやく選択できます。
ローカルキャッシュ： Firebase AI Logicへのリクエスト前に、選択した食材配列のハッシュを計算します。短時間のうちに同じ主な食材でレシピがリクエストされた場合、TinyRecipeはAPIを再度呼び出さず、キャッシュ結果をすぐに表示します。

3. 学んだことと今後の展開

Firebase AI Logicにより、個人開発者でも生成AI機能を簡単に拡張できました。モデルとの境界で厳密なJSONスキーマを適用し、状態をローカルに保つことで、TinyRecipeは次を実現しています。

2秒未満のレシピ生成
解析エラーのない予測可能なクライアント表示
APIトークンの無駄を最小限に抑制

AI食材庫機能はiOSとAndroidの両方で公開中です。