genkit

Genkit

このスキルは、主な疑問が「この Firebase AI 機能は、クライアント SDK に直接統合するべきか、それともサーバーが所有する再利用可能な Genkit ワークフローにするべきか？」である場合に使用します。

目的は、長大な Genkit チュートリアルや CLI の一覧、Firebase 製品の紹介を並べることではありません。 現在のパケットを整理し、所有境界と運用モードを 1 つ選んだうえで、Firebase プラットフォームの運用や広範なフレームワークの比較は関連するスキルに振り分けます。

混在したリクエストや曖昧なリクエストを扱う前に、references/intake-packets-and-fallbacks.md を読んでください。 主要モードを選ぶ前に、references/modes-and-routing.md を読んでください。 実行環境の選択が本当の未解決課題である場合は、references/deployment-and-runtime-boundaries.md を読んでください。 ワークフローがすでに存在し、信頼性がボトルネックである場合は、references/evals-and-observability.md を読んでください。

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

• モバイルアプリまたはウェブアプリで、モデルのセットアップ、構造化出力、ストリーミング、App Check、安全なクライアント／サーバー境界など、Firebase AI Logic クライアント SDK の直接統合が必要
• バックエンドまたはフルスタック機能で、ルートハンドラーに個別のプロバイダー呼び出しを散在させるのではなく、再利用可能な Genkit フロー が必要
• 型付きコントラクト、ツール呼び出し、検索拡張、プロンプトファイル、評価、トレース、またはサーバーが所有する境界下でのデプロイが必要
• リクエストが Firebase AI Logic、Genkit、またはクライアントが所有する形とサーバーが所有する形の選択について明示的に尋ねている
• 既存の Firebase AI 機能に、デバッグ、評価、オブザーバビリティ、またはリリース準備状況のレビューが必要

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

• 主な作業が Firebase の初期設定、エミュレーターの使用、Hosting／Functions のデプロイ、認証／ログイン、または Admin CLI の作業である → firebase-cli
• Firebase AI SDK や Genkit の境界が関係しない、一般的なフロントエンドのストリーミング／レンダリングに関するリクエストである → 該当するフロントエンド／ウェブのスキル
• 本当の疑問が、広範なフレームワークの選択（Genkit と Vercel AI SDK など）である → survey
• 標準的なプロバイダー SDK またはシンプルなルートハンドラーで十分で、Firebase／Genkit が必須ではない → 代替案を示し、回答は簡潔にします

手順

ステップ 1：現在のパケットを整理する

Genkit を推奨する前に、役立つ最小限の情報を整理します。

以下を記録します。

• アプリの形態：web | mobile | backend | fullstack | mixed | unknown
• 所有主体：client feature | backend capability | mixed | unknown
• パケット：route handler | feature brief | architecture note | deployed flow | eval/trace complaint | deploy plan | none
• ワークフローの必要性：simple generation | structured output | tools | retrieval | prompt files | evals | observability | deployment | unknown
• 提供上の優先事項：single endpoint | multi-surface reuse | launch readiness | migration | reliability concern | unknown

簡易整理：

App shape: fullstack
Ownership: backend capability
Packet: existing API route + support feature brief
Workflow need: retrieval + one ticket tool + evals later
Delivery pressure: reuse across web app and internal ops panel

ステップ 2：まずインテークパケットを選ぶ

references/intake-packets-and-fallbacks.md を使用します。

ユーザーが現在実際に持っているパケットを選びます。

• 新しいバックエンド機能のパケット
• 既存のルート／ハンドラーのパケット
• デプロイ済みフローの品質に関するパケット
• デプロイ／実行環境のパケット
• 比較／代替案のパケット
• まだ使えるパケットがない

このステップの出力形式：

## Intake Packet
- Current packet:
- Why it is enough (or not enough):
- Missing context to collect next:

ルール：アプリがすでに Firebase を使用しているという理由だけで、サーバーが所有する Genkit フローを無理に選ばないでください。

ステップ 3：所有するレイヤーを選ぶ

モードを選ぶ前に、クライアントとサーバーのどちらが担うかを明確にします。

主なニーズが以下の場合は、client-ai-logic を選びます。

• モバイル／Web で Firebase AI Logic SDK を直接使用する
• クライアントでのストリーミングや構造化出力を、小規模なアプリ所有の機能境界で実現する
• App Check、クライアントから確認できるモデル設定、またはクライアント／サーバー間のデータ公開ルールに対応する

主なニーズが以下の場合は、サーバー所有の Genkit モードを選びます。

• 再利用可能なバックエンド AI コントラクト、または型付きフローの境界を定める
• ツール、検索拡張、プロンプト、評価、トレースを一元的に管理する
• クライアント、ジョブ、または保護されたサーバー側リソース間で機能を共有する

通常のプロバイダー SDK、通常のルートハンドラー、またはより広範なフレームワークの調査が適切な場合は、どちらかのレイヤーを無理に選ばないでください。

次のように、判断を 1 行で示します。

## Layer Decision
- Ownership: client-ai-logic | server-genkit | plain-sdk-fallback | survey-first
- Why:

ステップ 4：主要な運用モードを 1 つ選ぶ

references/modes-and-routing.md から主要なモードを 1 つ選びます。

主要なモード：

• client-ai-logic
• flow-foundation
• tool-and-agent
• retrieval-and-prompt
• evaluation-and-observability
• deployment-runtime
• comparison-or-fallback

ルール：主要なモードは 1 つ、必要に応じて副次的なモードを追加できます。 クライアント SDK の接続、バックエンドのフロー設計、デプロイ運用、アーキテクチャの比較を 1 つにまとめないでください。

ステップ 5：最小限の機能境界を確定する

client-ai-logic の場合は、次を定義します。

• 1 つのアプリ機能とモデルとのやり取り
• 入出力またはストリーミングのコントラクト
• クライアントから確認できるデータとサーバー専用のデータおよび設定
• App Check／認証／エラー処理と不正利用の境界

サーバー所有の Genkit モードの場合は、次を定義します。

• 名前を付けた 1 つのバックエンド機能と型付きフローのコントラクト
• サーバー側に残す必要があるもの
• ツール／検索拡張／プロンプト（該当する場合）
• 呼び出し元となるクライアントまたはジョブ

巨大なフロー、クライアントへのサーバーシークレットの公開、基本的なパスが 1 つ動く前にツールや検索拡張を追加することは避けてください。

ステップ 6：フォールバックまたは振り分け先を正確に示す

references/intake-packets-and-fallbacks.md を使用します。

よくある振り分け先：

• Firebase CLI／エミュレーター／デプロイ／管理者向け作業 → firebase-cli
• Firebase AI SDK の境界を伴わない汎用フロントエンドのレンダリング → 該当するフロントエンド／Web スキル
• 広範なフレームワークの比較やアーキテクチャの不確実性 → survey
• Firebase を介さない軽量なモデル呼び出し → 通常のプロバイダー SDK／ルートハンドラーへのフォールバック
• 耐久性、再試行、バックグラウンドのオーケストレーションが問題の中心となる場合 → キュー／ジョブ／ワークフロー基盤

ステップ 7：次に取り組む最小限の範囲を選ぶ

巨大なシステム図にいきなり飛びつかないでください。次のうち 1 つに絞ります。

• 検証と不正利用の境界を設けて、クライアント SDK の生成／ストリーミング経路を 1 つ接続する
• サーバーフローのコントラクトを 1 つ定義する、またはラップする
• ツールまたは検索拡張の境界を 1 つ追加する
• 代表的な評価セットを 1 つ追加する
• ランタイム／デプロイの構成を 1 つ選ぶ

ステップ 8：確信がボトルネックなら評価とトレースを活用する

references/evals-and-observability.md を使用します。

ワークフローがすでに存在する場合は、次の順序を優先します。

1. 代表的な入力
2. ローカルでのトレース確認／Developer UI の調査
3. 小規模な評価セット
4. コントラクト／プロンプト／ツールの整理
5. 十分な証拠を得られるサイクルが確立してからロールアウトする

ステップ 9：Firebase AI 実装ブリーフを返す

# Firebase AI Implementation Brief

## Scope
- App shape:
- Ownership: client-ai-logic | server-genkit | fallback
- Intake packet:
- Primary mode:
- Confidence:

## Layer Decision
- Why this ownership fits:

## Feature Boundary
- Capability:
- Input / output or streaming contract:
- Client-visible / server-only responsibilities:
- Tools / retrieval / prompt-file needs:
- Auth, App Check, errors, and abuse boundaries:

## Smallest Next Slice
1. ...
2. ...
3. ...

## Route-outs / Fallbacks
- ...

例

例 1：再利用可能なバックエンドのサポートワークフロー

入力： 「サポートアプリ向けの Genkit バックエンドフローを構築してください。ヘルプ記事を検索拡張し、チケット用ツールを 1 つ呼び出して、Web アプリが再利用できるサーバーエンドポイントを 1 つ公開します。」

期待される形： tool-and-agent または retrieval-and-prompt、明確なサーバー所有のフロー境界、そしてツール／検索拡張の計画が 1 つ。

例 2：Firebase アプリに直接組み込む機能

入力： 「Firebase SDK を使って、Firebase Web アプリ内に Gemini による要約機能を直接追加してください。」

期待される形： client-ai-logic。アプリ所有の SDK 境界、構造化出力またはストリーミングのコントラクト、App Check／認証を備え、不要なサーバーフローは追加しません。

例 3：既存のフローをリリース前に確信を持って運用したい

入力：「Genkit のフローはローカルで動作していますが、Cloud Run にデプロイする前に、実用的な評価と可観測性の計画が必要です。」

想定される形： evaluation-and-observability、小規模なエビデンスループ、実行環境の詳細は Firebase CLI の操作とは分けて扱います。

例 4：フレームワークの選択がまだ明確でない

入力：「この Firebase アプリでは Genkit、Firebase AI Logic、Vercel AI SDK、または SDK を直接呼び出す方法のうち、どれを使うべきですか？」

想定される形： comparison-or-fallback。幅広いフレームワークの選定は survey に誘導し、その後、client-ai-logic またはサーバー側で管理する Genkit モードのいずれかを選んで、ここに戻ります。

ベストプラクティス

1. ツールやモデルを挙げる前に、クライアントとサーバーのどちらが責任を持つか、その境界を決めます。
2. 巨大な AI 機能の分類より、明確な機能／フローの境界を 1 つ選びます。
3. シークレットと保護対象のリソースはサーバー側に置きます。クライアントから直接処理する場合は、App Check／認証と不正利用対策の境界を定義します。
4. 十分な場合は、通常のルートハンドラー／プロバイダー SDK を使う代替案も検討します。
5. 実行環境の選択はアーキテクチャ上の判断として扱い、Genkit が必須である根拠とはみなしません。
6. ロールアウトを拡大する前に、トレースと評価を活用します。
7. フロントドアの境界が変わった場合は、簡潔なディスカバリー用サーフェスも同期します。

参考資料

• Firebase Genkit のドキュメント：https://firebase.google.com/docs/genkit
• Genkit のドキュメント：https://genkit.dev/docs/
• Genkit フローのドキュメント：https://genkit.dev/docs/js/flows/
• Genkit クライアントアクセスのドキュメント：https://genkit.dev/docs/client/
• Firebase AI Logic のドキュメント：https://firebase.google.com/docs/ai-logic
• Firebase AI Logic Web SDK のドキュメント：https://firebase.google.com/docs/ai-logic/get-started?api=web
• ../firebase-cli/SKILL.md
• ../survey/SKILL.md
• ../survey/SKILL.md