初めてAIを搭載したアプリを開発するとき、開発者は特定の瞬間に直面します
楽しい部分ではありません。モデルが驚くべきことを行い、天才のように感じる部分ではありません。他の瞬間です。午前1時、クライアントコードを見つめているときに、あなたのGemini APIキーが平文で座っており、JavaScriptファイルにバンドルされようとしている瞬間。ブラウザと10分しか要らない誰でも開いて読めるのです。
Sambhavを構築している間にその瞬間が私に起こりました—SambhavはWhisperを通じてリアルタイム音声変換を行い、履歴書分析とGeminiを通じてパーソナライズされた指導を行うAIキャリアプラットフォームです。このアプリはNext.js 15のフロントエンドがFlaskのバックエンドと通信し、Supabaseが下にあり、多くの動く部分があり、それらはすべてLLMに何らかの点で触れる必要がありました。
私が最も誇りに思った機能：リアルタイムの模擬面接モードで、ユーザーが自然に話し、その回答を記録し、Geminiが即座に評価できる機能。それが完成度が高く、うまく動作していた。
その下のアーキテクチャは、問題を引き起こす可能性のある負債だった。
実際の問題
私が陥っていたパターンはこうだった：低レイテンシーの必要があるGeminiの呼び出しはクライアント側に行った。ライブトランスクリプションフィードバックのようなものは、サーバー側のラウンドトリップを追加すると体験が遅延して壊れてしまうから。しかしクライアントからGeminiを呼び出すと、APIキーはクライアントがアクセスできる場所に存在しなければならなかった。
開発者がここで通常選択する解決策は、それぞれ違う方法で悪い。
キーを環境変数に入れて、バンドラが漏れないことを願うこともできますが、それが漏れることがあり、監査が難しい方法で漏れます。すべてを自分のバックエンドを通じてプロキシすることもできます——それは機能しますが、今は2つのサービス間でセッション状態を維持しており、あなたのFlaskサーバーはただリクエストをフォワードし、遅延を追加するだけです。有効期間の短いトークンを使うこともできます——しかし、その場合、トークン生成とリフレッシュシステムを構築する必要があり、それはそれ自体のプロジェクトです。
根本的な問題は、これらがクォータ問題を解決しないことです。APIキーを隠しても、意欲的なユーザーは依然として転送中の有効な認証トークンをキャプチャして再放送できます。キーを盗むのではなく——ただ Billing クォータを枯渇させるだけです。個人プロジェクトやハッカソンデモの場合、それは煩わしいエッジケースです。実際のユーザーがいる本番環境の場合、それは本物の脅威です。
プロキシアプローチを実装することにしたのは、それが最も議論できる方法だからだったが、インタビューフィードバックループに有意義な遅延を加え、セッション管理を大幅に複雑にした。Flaskバックエンドは同時にWhisperセッション状態、Geminiコンテキスト、認証レイヤーを保持する必要があった。何か問題が発生した時——デモンストレーションでは問題はよく発生する——どのレイヤーが失敗したのかは決して明らかではなかった。
Firebase AI Logicが実際に変更するもの
Firebase AI Logicは新しいものではない—しかしGoogleがI/Oでリリースしたものは、6ヶ月前と比べて本質的に異なるツールにした、そして特定の2つの機能の組み合わせが上記の問題を正確に解決する。
最初のものであるのは テンプレートのみモード はここでのアーキテクチャはシンプルです：あなたの Gemini プロンプト — システムインストラクション、モデル設定、ツール定義 — は Firebase のサーバー上にありますが、あなたのクライアントコードにはありません。あなたのクライアントはテンプレートIDを参照します。それだけです。リクエストが入ってきたら、Firebase はサーバーサイドのテンプレートを実行します。もし誰かがクライアントリクエストを傍受してカスタムシステムプロンプトを注入しようとすると、フレームワークはそれを無視します。クライアントコードからプロンプト操作へのパスはありません。
サンバハブのインタビューモードのようなものでは、評価基準——ジェミニが候補者の回答を評価する方法を定義するプロンプト——は、それが属するサーバーに残り、フロントエンドにバンドルされることはなかった。クライアントはテキストを送信し、構造化されたレスポンスを返されるだけです。
二つ目はアプリチェックのリプレイ保護と一度きりトークンです。は、今月からFirebase AI LogicのApp Checkトークンは厳密に一度限り使用されます。一度使用されたトークンは無効になります。転送中に有効なトークンをキャプチャした攻撃者は、それを繰り返して追加のGeminiコールを行うことはできません。先に説明したクォータードレイン攻撃——技術的に見て、よく隠されたAPIキーでさえ可能な攻撃——は、インフラレベルで現在閉鎖されています。
レイテンシーのトレードオフは本物で、認識する価値があります：リクエストごとに新しいトークンを生成すると、ネットワークのラウンドトリップが追加されます。数秒ごとにジェミニコールを行うリアルタイムの音声認識機能では、そのコストが蓄積します。これをレイテンシーサensitiveなパスで有効にする前に、プロファイリングする価値があります.
混合推論の部分
第三のアナウンスがありますが、これは実際にはアーキテクチャ上の決定なのに、パフォーマンス最適化に聞こえてしまうため、私は報告が不十分だと思います。
Firebaseは現在、iOS、Android（Gemma 4を使用）、そして—すぐにGAに昇格する—Web上のChromeでハイブリッド推論をサポートしています。モデルは可能な限りデバイス上でローカルに実行し、不可能な場合にはクラウドのGeminiにフォールバックします。
「速くて安い」という理由を超えて、耐久性が重要なのです。Sambhavはハッカソン環境向けに作られており、会議のWiFiで動作するように設計されていました。会議のWiFiは敵対的です。インタビューモードがセッション中に時折停止してしまい、その理由はGeminiコールがタイムアウトしたからでした。これは、製品をデモンストレーションしようとしている人がその時点で体験を打ち切る原因となりました。
ハイブリッド推論とは、パイプラインの軽量部分——テキスト認識のクリーンアップ、基本的なレスポンスのフォーマット、簡単な分類——がネットワークの状態に関わらずローカルで実行できることを意味します。重い推論はまだクラウドに行きます。ネットワークが存在しないときでもアプリは生き残ります。
この技術を実装する人々にとっての実用的な問題点は、デバイス上のGemma 4モデルからは完全なGemini品質は得られないということです。能力のギャップは本物で、ローカル経路が破損したものではなく、優雅に劣化した体験を生み出すように機能を設計する必要があります。これは単なる設定問題ではなく、設計上の問題です.
これは実際には意味します
Firebase AI Logic GAは見出しの発表ではありません。トレンドになることもありません。しかし、クライアントアプリケーションでAI機能をリリースしたか、リリースしようとしたか、そして「APIキーはどこにあり、どうやってクォータを保護するか」という壁にぶつかった開発者にとって、これはI/Oから実際に重要な発表です。
テンプレートのみモード、App Check 再プレイ保護、およびハイブリッド推論の組み合わせにより、Sambhavのために私は組み立てたセキュリティと回復性アーキテクチャー — プロキシサーバー、セッション状態管理、手動トークン処理 — は現在、Firebase SDKの一流の機能となっています。パイプラインを構築する必要はありません。設定するだけです。
生産に入る際に注意深く見守るべきこと：テンプレートのみモードとリプレイ保護は問題の異なる部分を解決し、異なる遅延プロファイルを持っています。デフォルトで両方をすべての場所で有効にしないでください。まず、遅延に敏感なパスをプロファイルし、往復コストがどこに落ち着くかを理解し、トレードオフが受け入れ可能な場所で意図的な決定を下すこと。
従来はバックエンドプロジェクトが必要だったセキュリティアーキテクチャは、今は3つのFirebase設定オプションに存在します。これは、実装可能なものに意味のあるシフトです。