firebase-ai-logic

Firebase AI Logic

このスキルを使用する場面

• Firebase アプリ内に Gemini を活用した機能を直接追加する場合。
• アプリ内でテキスト、チャット、マルチモーダル、構造化出力、ストリーミングの体験を構築する場合。
• リクエストをクライアント／アプリ層にとどめるか、バックエンドのワークフローに移すかを判断する場合。
• AI 機能に App Check、クォータへの配慮、Firebase サービスとの連携など、Firebase 固有の本番環境向け制御を追加する場合。
• Web、モバイル、Flutter、Unity など、Firebase がサポートするクライアント環境でアプリ側の AI 機能を扱う場合。

このスキルを使用しない場面

• サーバーが管理するフロー、ツール呼び出し、RAG、評価器、トレース、プロンプトファイル、再利用可能なバックエンドオーケストレーションが必要な場合 → genkit を使用してください。
• Firebase プロジェクトのセットアップ、エミュレーター、ホスティング／Functions のデプロイ、CLI 操作が必要な場合 → firebase-cli を使用してください。
• ユーザーが Firebase を使うと決めておらず、主に汎用プロバイダー SDK の比較が必要な場合 → プロバイダー固有またはフレームワーク選定用のスキルを使用してください。

運用モデル

firebase-ai-logic は、次の 3 つの役割分担におけるクライアント／アプリ連携の中心として扱います。

1. アプリ／クライアント機能の連携 → firebase-ai-logic
2. バックエンドのワークフローオーケストレーション → genkit
3. Firebase プラットフォーム／運用者のタスク → firebase-cli

これらの役割を混同しないでください。リクエストが複数の役割にまたがる場合は、依頼を分割し、それぞれの対応先を明示してください。

手順

ステップ 1：実装方法を案内する前にリクエストを分類する

まず、次のモードから 1 つ選びます。

モード A — 機能への直接的な適合

ユーザーが次のようなアプリ内 AI 機能の追加を希望する場合に使用します。

• チャットやアシスタント UI
• アプリ内での要約や書き換え
• ユーザーコンテンツを使ったマルチモーダルプロンプト
• アプリのワークフロー向け構造化出力
• モデルの応答を UI にストリーミング

提示する内容：

• Firebase AI Logic が適切な対応先かどうか
• アプリ層に含めるものと、別の層に移すべきもの
• 必要最小限の Firebase の依存関係／サービス

モード B — アプリの接続と UX 連携

ユーザーがすでに Firebase AI Logic を選択しており、アプリへの接続方法についてサポートが必要な場合に使用します。

次の点に注目します。

• アプリのアーキテクチャ内でモデル呼び出しを配置する場所
• UI の状態におけるリクエスト／レスポンスのライフサイクル
• 読み込み／エラー／再試行／フォールバック時の UX
• アプリ内でのプロンプト／テンプレートの管理
• アプリが提供すべきコンテンツモデレーション／安全性の仕組み

モード C — 本番環境への対応強化

機能がすでに存在するか、リリースが近い場合に使用します。

次の点に注目します。

• App Check／不正利用の防止
• クォータ、コスト、レート制限への影響
• モニタリングと障害の可視化
• 必要に応じたリモート展開／機能フラグ戦略
• ユーザー入力と生成結果に関するプライバシーの境界

モード D — エスカレーションの境界

ユーザーがクライアント側のリクエストから始めたものの、要件がバックエンドのオーケストレーションを示す場合に使用します。

次の要件がある場合は genkit にエスカレーションします。

• ツール呼び出しまたはエージェントループ
• 検索／RAG／データベースに基づく生成
• 複数のプラットフォームで共有する再利用可能なフロー
• 評価ハーネス、トレース、または体系的なオブザーバビリティ
• クライアントに置くべきではないシークレットや特権 API

ステップ 2：リクエストの内容を整理する

回答の前に、リクエストを次の概要に書き換えます。

## Firebase AI Logic packet
- App surface: web | iOS | Android | Flutter | Unity | mixed
- User-facing feature: chat | summary | generation | multimodal | structured output | streaming
- Data involved: user text | images | docs | app state | Firebase data
- Safety/privacy concern: none | moderate | high
- Production stage: prototype | internal beta | launch prep | live issue
- Boundary check: stays in app | split with backend | move to `genkit`

概要に split with backend または move to genkit とある場合は、1 つのスキルですべての解決策を担うかのように扱わず、すぐにその旨を伝えてください。

ステップ 3：アプリ層の指針を示し、膨大なコードを一度に提示しない

Firebase AI Logic のリクエストには、次の順序で回答を構成します。

1. アプリ層にとどめるべき理由
2. クライアント UI／ランタイムで接続する内容
3. 重要な Firebase 固有の制御
4. クライアントに含めないもの
5. genkit または firebase-cli にエスカレーションするタイミング

連携の説明に役立つ場合に限り、短いコードや疑似構造を使用してください。長い SDK のコード例より、アーキテクチャと境界に関する指針を優先してください。

Step 4: Firebase 固有の懸念事項に対応する

このレーンをプロバイダー SDK の直接利用と区別する懸念事項には、必ず触れてください。

• 該当する場合は、App Check／不正利用の防止
• クォータ／コスト／レートへの配慮
• Firebase サービス間の連携（Auth、Remote Config、分析／モニタリング、ストレージ、必要に応じた Functions への引き継ぎ）
• 対象アプリのサーフェスに対するプラットフォームサポートの影響
• 本番環境向けのリクエストでは、モデル変更や機能公開のロールアウト戦略

Step 5: 適切なルートへの案内を徹底する

次のルートへの案内を明示的に使用してください。

ユーザーが必要としているもの	案内先
サーバー側が所有するフローまたはツール呼び出し	genkit
検索拡張生成（RAG）／評価／トレース	genkit
デプロイ、エミュレーター、ホスティング、または Functions の運用	firebase-cli
Firebase 以外のプロバイダーの選択	プロバイダー／フレームワークのスキル

Step 6: 出力形式

次のような簡潔なパケットで回答してください。

## Recommendation
- Lane: Firebase AI Logic | Split with Genkit | Not a Firebase AI Logic fit
- Why: ...

## App-layer plan
1. ...
2. ...
3. ...

## Firebase-specific controls
- App Check / abuse:
- Quota / cost:
- Monitoring / rollout:

## Route-outs
- `genkit`: ...
- `firebase-cli`: ...

ベストプラクティス

1. 低い権限で、オーケストレーションも少ない状態である間は、ユーザー向けのシンプルな AIをアプリ層だけにとどめます。
2. バックエンド向けの動作は早い段階で切り離します。クライアントだけの設計に、ツール／RAG／評価を後付けしないでください。
3. App Check、クォータ、リリース準備を、後回しにせず最優先の懸念事項として扱います。
4. アプリの UX、バックエンドのオーケストレーション、Firebase の運用をひとまとめにせず、回答ごとに明確な機能パケットを 1 つ提示することを優先します。
5. 判断に迷う場合は、実装手順を提案する前に、アプリ側の Firebase AI Logic とバックエンド側の genkit の役割分担を説明します。

例

例 1: Firebase AI Logic にとどめるべきケース

入力:「Firebase のウェブアプリで、記事のプレビュー向けに Gemini によるストリーミング要約を追加してください。」

出力の形式:

• レーン = Firebase AI Logic
• アプリの UI 状態、ストリーミング表示、プロンプトの管理、失敗時の状態、App Check／クォータの保護策に焦点を当てた計画
• 再利用可能な要約パイプラインや評価ハーネスは genkit の担当であることを案内する注記

例 2: Genkit と役割を分けるべきケース

入力:「モバイルアプリに、Firebase データを対象としたチャット、ツール呼び出し、検索機能と、サーバー側のオブザーバビリティが必要です。」

出力の形式:

• レーン = Genkit と役割を分担
• 必要な場合に限り、Firebase AI Logic はアプリとのやり取りの境界部分にとどめる
• バックエンドのワークフロー、検索、ツール、オブザーバビリティは genkit に移す

リファレンス

• Firebase AI Logic の概要
• Firebase AI Logic のスタートガイド
• Firebase AI Logic の本番環境チェックリスト
• Genkit のドキュメント