Firebase AI Logicとは｜クライアント直呼びの構成とApp Check強制への移行【2026年8月時点】

Firebase AI Logic は、モバイルアプリやWebアプリのクライアントコードから Gemini のモデルを直接呼び出すための、SDKとプロキシサービスの組み合わせです。2024年に「Vertex AI in Firebase」として出た機能が、対応するAPIプロバイダを増やした段階で今の名前へ変わりました。この記事で扱うのは、2つのAPIプロバイダの選び分け、2026年11月2日から必須になる App Check の強制、自前バックエンドを挟む構成との費用と運用の差、そして受託開発でこの構成を採ってよい条件です。日付と版番号は2026年8月時点の公式ドキュメントの記載に基づきます。

まとめ：2026年11月2日の期限から逆算して構成を決める

最初に見るべきは機能表ではなく日付です。公式ドキュメントは「2026年11月2日以降、Firebase AI Logic を使うには App Check の強制が必須になる」と明記しています。2026年7月上旬より後にコンソールのガイド付きセットアップを通ったプロジェクトは自動で強制が入りますが、それ以前に組んだものは手動で切り替える必要があります。PoCのまま本番へ持ち込んだ案件ほど、この設定が抜けたまま期限を迎えやすいところ。

構成の選択そのものは単純です。バックエンドを1枚も書かずに生成AI機能を出したいなら直呼び、リクエスト単位で自社のビジネスルールを差し込みたいなら Cloud Functions などを挟む。前者を採るなら App Check の構成証明、単回使用トークン、ユーザーあたり既定100 RPM のレート制限、予算アラートの4点を最初から入れておくこと。後から足す作業ではありません。

Firebase AI Logicがクライアントとモデルの間で担う3つの役割

名前が2年で二度変わっている製品です。ここを取り違えると、古い記事のコード例をそのまま持ち込んで動かない、という遠回りになります。

旧称Vertex AI in Firebaseから改称に至った経緯と適用範囲

2024年の提供開始時、この機能は「Vertex AI in Firebase」という名前でした。当時の呼び出し先は Vertex AI 側の Gemini API のみ。その後 Gemini Developer API にも対応したことで、公式FAQの表現を借りれば「Vertex AI in Firebase という名前が製品の広がった範囲を正確に表さなくなった」ため、Firebase AI Logic へ改称されています。

もう一段ややこしいのが、呼び出し先の側でも改称が起きている点です。公式FAQは「2026年半ばに Google Cloud が Vertex AI を Gemini Enterprise Agent Platform へブランド変更した」と記載しています。サービス名 aiplatform.googleapis.com は変わっておらず、ドキュメント上の表記だけが「Agent Platform Gemini API（旧 Vertex AI）」に統一された形。Google CloudのAI開発基盤の機能と料金を実装者目線で整理した記事は旧名称の時点の内容なので、両方の名前が同じものを指すと読み替えて参照してください。

Gemini Developer APIとAgent Platform版の選択基準

SDKの初期化時に、どちらのAPIプロバイダを通すか選びます。コードの書き分けは初期化の1行ぶんですが、料金プランの前提と使える入力形式が変わります。

判断はこうなります。検証段階と、課金を伴わない小規模なアプリなら Gemini Developer API。Cloud Storage 上のファイルをURLでそのまま渡したい、あるいは組織のGoogle Cloud側の統制に寄せたいなら Agent Platform 版で、こちらは無条件で従量課金の Blaze プランが前提です。無料枠とBlaze超過単価の実額をまとめた記事と併せ、月次の見込みを先に置いてから決めます。

プロキシ経由でAPIキーが端末のバイナリに残らない仕組みと限界

クライアントから直接モデルを呼ぶ、と聞いて最初に浮かぶ懸念がAPIキーの埋め込みでしょう。この構成では、アプリが叩くのは Gemini のエンドポイントではなく Firebase 側のプロキシです。公式ドキュメントは、このプロキシと App Check の統合によって「Gemini のAPIキーはサーバー側にとどまり、アプリのコードベースには埋め込まれない」と説明しています。

ただし、これで呼び出しが無条件に守られるわけではありません。アプリのバイナリやWebのソースからは Firebase の設定オブジェクト（APIキーとプロジェクトID）が読み取れます。つまりプロキシのエンドポイントへ形式的に正しいリクエストを投げるところまでは、第三者にもできる。その先を止めるのが App Check であり、だからこそ強制が必須要件へ格上げされた、という筋道です。

対応する5系統のSDKとオンデバイス推論へのフォールバック条件

2026年8月時点で公式が挙げるクライアントSDKは、Apple向けのSwift、Android向けのKotlinとJava、Web向けのJavaScript、Flutter向けのDart、そしてUnityの5系統です。Swift版はSDK v12.5.0以降でモジュール名が FirebaseAI から FirebaseAILogic へ変わりました。公式は後方互換であり破壊的変更ではないとしつつ、旧名は将来削除する方針。既存プロジェクトを触るなら、この改名を追従作業として工数に入れておきます。

一部のSDKはハイブリッド推論に対応します。端末側のモデルが使える環境ではそれを使い、使えなければクラウド側のモデルへ切り替える動きです。通信量とレイテンシは下がりますが、端末側モデルの可用性はOSとハードウェアに依存するため、出力品質の差を前提にした設計が要ります。両方の経路で同じ品質を期待する作りにしないでください。

2026年11月2日から必須になるApp Check強制の逆算スケジュール

ここが実務上いちばん締め切りの近い論点です。機能追加ではなく、既存の稼働アプリが止まりうる変更として扱います。

2026年7月以降の自動強制と既存プロジェクトに残る手動作業

公式の記述は3箇所（FAQ・App Checkのページ・本番チェックリスト）で揃っており、いずれも「2026年11月2日以降、Firebase AI Logic の利用には App Check の強制が必須」という同一の文言です。加えて2026年7月上旬以降、コンソールのガイド付きセットアップを通った場合は、その工程の中で自動的に強制が有効化されます。

問題になるのはそれ以前に構築したプロジェクトです。自動化の恩恵を受けないため、コンソールで明示的に強制へ切り替える作業が残ります。逆算の段取りは次の順です。

1. 対象プロジェクトを棚卸しし、AI Logic を叩いているアプリを列挙する
2. 各アプリへ App Check SDK を組み込み、監視モードで指標を数日ぶん貯める
3. 未検証リクエストの内訳を確認し、旧バージョンの自社アプリを切り捨てないか判定する
4. 強制を有効化し、403の発生率とモニタリングの指標を並べて確認する

手順2で数日は空ける前提なので、期限当日に着手する類の作業ではありません。プロバイダ選定と監視から強制への移行を扱った記事に、指標の読み方と切り替えの判断材料をまとめてあります。

App Checkトークン無しの呼び出しが403で止まる挙動と順序

強制後の挙動は明快です。公式は「有効な App Check トークンを伴わない Firebase AI Logic へのリクエストはブロックされる」と記載しています。加えて、非アクティブと判定されたプロジェクトからのリクエストには 403 PERMISSION_DENIED が返り、再開には App Check の強制が要ると示されます。

怖いのは、失敗が生成AI機能の中だけに閉じないケースです。呼び出し失敗の例外処理を書いていないと、画面全体がエラーで潰れます。強制を入れる前に、トークン取得に失敗した経路をUI側でどう畳むかを決めておいてください。

プラットフォーム別の構成証明プロバイダと単回使用トークンの併用

構成証明プロバイダはプラットフォームで決まります。Apple系は DeviceCheck か App Attest、Android は Play Integrity、Web は reCAPTCHA Enterprise。Flutter と Unity は、公式の記述では既定のプロバイダ一式がそのまま使えます。選択の余地があるのは Apple 系だけ、と覚えておくと設計が速く進みます。

本番チェックリストはもう一段の対策として、単回使用トークン（リプレイ防御）の有効化を挙げています。通常の App Check トークンは有効期間内なら再利用できるため、傍受されたトークンが同じ時間帯に何度も使われうる。生成AIのエンドポイントは1リクエストごとに実費が出るので、この再利用は請求額として跳ね返ります。セキュリティ対策であり費用対策でもある、と読んでください。

自前バックエンド経由と直呼びで分かれる費用と運用面の判断材料

「クライアントから直接叩くのは危ないから、必ずバックエンドを立てるべきだ」という主張はよく見かけます。その通りになる案件と、そうならない案件があります。

Cloud Functionsを挟む構成と直呼びの往復回数とコスト差

自前バックエンドを挟む場合、典型的には トリガー設計と第2世代の実装判断をまとめた記事で扱う呼び出し可能関数を1枚置き、そこから Gemini を叩きます。コストは、関数の実行時間とインスタンス数ぶんが Gemini の従量課金へ上乗せされる形。生成AIの応答は数秒から数十秒かかるため、関数側は待ち時間ぶんも課金対象になります。

直呼びなら、この上乗せは発生しません。往復もクライアントとプロキシの1回で済み、コールドスタートの遅延も挟まらない。一方で、リクエストを書き換える・利用回数を数える・出力を保存してから返す、といった処理を置く場所がなくなります。差は費用より「どこに自社のロジックを置けるか」に出ます。

APIキー流出の懸念に対して直呼び構成が答えられる範囲と限界

直呼びを否定する議論の芯は、APIキーが信頼できない端末を通る点にあります。プロキシ構成が答えているのは「Gemini のAPIキーは端末に置かない」という一点。端末に置かれる Firebase の設定値は公開前提の情報なので、ここまでは設計として成立しています。

限界も明確です。呼び出し元が端末である以上、リクエストを送っているのが正規アプリかどうかは端末の外からは分かりません。App Check はこの不確かさを構成証明で狭める仕組みであって、ゼロにはしません。IAMのサービスアカウントでサーバー側から認証する構成と比べれば、信頼の根拠は一段弱い。この差を許容できるかが、次の章の分岐点になります。

既定100RPMのレート制限と予算アラートで費用膨張を止める設定

費用側の防波堤は3層あります。1層目がレート制限で、既定はユーザーあたり100 RPM。Google Cloud コンソールの Firebase AI Logic API のページから、Quotas & System Limits タブで変更や引き上げ申請ができます。2層目が予算アラートで、Blaze プランの支出に通知としきい値を設定するもの。3層目が AI モニタリングで、リクエスト数・レイテンシ・エラー・モダリティ別のトークン使用量をアプリ単位で見ます。

モニタリングのサンプリング率は1〜100%で既定は100%。トラフィックが増えてから絞る運用になるため、立ち上げ時は既定のままで構いません。注意が要るのは、予算アラートが通知であって遮断ではない点です。止めたいならレート制限の側を先に締めます。

サーバープロンプトテンプレートとモデル停止に備える構成の管理

この構成でいちばん壊れやすいのは、クライアントに埋め込んだプロンプトとモデル名です。どこまでサーバー側へ逃がすかを決めます。

プレビュー段階のサーバープロンプトテンプレートの採否と判断軸

サーバープロンプトテンプレートは、プロンプト本文・スキーマ・モデル構成をサーバー側に置き、クライアントはテンプレート名と変数だけを送る仕組みです。公式ブログでの公開は2025年12月。書式は Dotprompt ベースで、YAMLフロントマターにモデル名や入力スキーマを書き、本文では Handlebars 記法の変数や条件分岐、繰り返しが使えます。

採否の分かれ目は安定性です。公式は2026年8月時点でこの機能をプレビューと位置づけ、SLAの対象外であり、後方互換性のない変更があり得ると明記しています。プロンプトを審査なしで差し替えたい、社外に見せたくない、という要件が実際にあるなら採る価値がある。そうでないなら、次のh3で触れる Remote Config で足ります。プレビュー機能をリリースクリティカルな経路に置くのは、受託案件では見送る判断が妥当です。

Imagen停止とGemini 2.5系停止に対する版番号の固定と移行

モデルの寿命は思ったより短いです。公式のモデル一覧は、Imagen 系について「早ければ2026年8月17日に停止する」と記載し、Gemini の画像生成モデルへの移行を促しています。Gemini 2.5 系も2026年10月に停止予定として非推奨の扱い。1年前に書かれたコード例がそのままでは動かない、という状況が現実に起きています。

本番チェックリストの指示は明快で、指定するのは安定版のみ。-latest のエイリアスや preview・experimental の版は本番で使わない、というものです。2026年8月時点で公式が推奨表示している既定候補は gemini-3.7-flash、課金なしで使える軽量版として gemini-3.5-flash-lite が並びます。版を固定したうえで、停止予告を追う担当を決めておく運用がセットになります。

Remote Configでモデル名を差し替える構成と監視の組み合わせ

版を固定すると、今度は停止のたびにアプリを更新する必要が出ます。ここで公式が「強く推奨」としているのが、モデル名を動的に管理する構成です。Remote Config にモデル名を持たせ、クライアントはそこから読む。停止予告が出たら、コンソールの値を書き換えるだけで切り替わります。

組み合わせるのは AI モニタリングです。モデルを差し替えた直後にエラー率とレイテンシがどう動いたかを、アプリ単位で確認できます。差し替えと観測がセットで初めて、無停止の移行になる。ローカル再現の構成とCI組み込みを扱った記事のエミュレータで事前に確かめられる範囲もありますが、モデルの応答そのものはクラウド側の挙動なので、本番の指標を見る工程は省けません。

受託開発で直呼び構成を採用してよい条件と見送るべき3つの場面

ここからは判断を言い切ります。案件の性質で答えが変わるので、条件のほうを固定します。

PoCから本番へ移す段階で直呼び構成のまま進めてよい3つの条件

次の3つがすべて揃うなら、バックエンドを挟まずそのまま本番化してよい、と考えています。

• 生成AIの呼び出しが「入力を渡して出力を表示する」で完結し、途中に自社ロジックを挟む要件がない
• 利用者が不特定多数の一般ユーザーで、構成証明プロバイダ（Play Integrity・App Attest・reCAPTCHA Enterprise）がそのまま効く配布経路にある
• App Check の強制と単回使用トークン、レート制限、予算アラートを、リリース前に設定し切れる

この3つが揃った案件でバックエンドを立てるのは、保守対象を1つ増やすだけの選択です。関数のランタイム更新、依存の追随、コールドスタートの調整。生成AI機能の価値と無関係な作業が毎年発生します。要件が薄いなら挟まない、と決めてよい。

基幹システムや社内向け管理画面で直呼び構成を見送る3つの場面

逆に、次の3つのどれか1つでも当てはまるなら見送ります。玉虫色にせず、バックエンド経由で組む前提にしてください。

• 入力に社内の機微情報や個人情報が含まれ、監査ログの保存とマスキングを経路上で強制する必要がある
• 社内配布や業務端末での運用で、Play Integrity などの構成証明が期待どおりに機能しない配布形態がある
• ユーザーごとの利用上限や部門別の課金按分を、サービス側の都合ではなく自社の規程どおりに実装する必要がある

3つ目は見落とされがちです。レート制限はユーザーあたりのRPMを絞る仕組みで、月間のトークン量を部門別に配分する用途には向きません。基幹系の要件に混ぜて考えると、ここで詰まります。GraphQLでCloud SQLを扱う仕組みの実装判断のように、業務データへ触る層を別に持つ構成なら、生成AIの呼び出しもそちら側へ寄せるほうが一貫します。

引き継ぎ時に渡す設定4点と内製化の段階で詰まりやすい確認事項

受託で作って社内チームへ引き継ぐ場合、コードより先に渡すべき設定が4点あります。使っているAPIプロバイダ（Gemini Developer API か Agent Platform 版か）、固定したモデルIDとその停止予定、App Check の強制状態と構成証明プロバイダの設定値、そしてレート制限と予算アラートのしきい値です。この4点が引き継ぎ書に無いと、モデル停止の通知が来た時点で誰も動けません。

内製化の段階で詰まるのは、たいてい構成証明の再取得です。アプリの署名鍵やドメインが変わると、構成証明の登録もやり直しになる。生成AI開発・AI受託開発の相談窓口では、この引き継ぎ範囲まで含めた設計と、既存アプリへの後付けの可否判断を扱っています。強制期限が近い案件ほど、棚卸しの段階から相談してもらうほうが手戻りが少なく済みます。

よくある質問

Firebase AI Logic の検討時に、実装前の段階で聞かれることの多い質問をまとめました。

Firebase AI Logicは無料で使えますか？

APIプロバイダによって変わります。Gemini Developer API なら無料の Spark プランでも利用でき、無料枠が付きます。Agent Platform 版（旧 Vertex AI）は無料枠が無く、従量課金の Blaze プランが必須。ただし Spark でも、モデル次第で課金が前提になります。2026年8月時点で公式が「課金不要」と示すのは gemini-3.7-flash や gemini-3.5-flash-lite などで、画像生成系は課金が要ります。

Vertex AI in Firebaseから移行するには何が必要ですか？

製品は同じもので名前が変わっただけなので、呼び出し先を変えないなら作り替えは要りません。残る作業は3つ。Swift のモジュール名の変更（SDK v12.5.0以降で FirebaseAI から FirebaseAILogic へ）、ドキュメントの読み替え、App Check の強制設定です。2026年7月上旬より前に作ったプロジェクトは自動強制の対象外なので、2026年11月2日までに手動で有効化してください。

App Checkを入れないとどうなりますか？

2026年11月2日以降は、有効な App Check トークンを伴わないリクエストがブロックされます。それまでの期間も、入れていない状態は「Firebase の設定値さえ読めれば第三者が生成AIのエンドポイントを叩ける」状態です。生成AIの呼び出しは1回ごとに実費が発生するため、放置した場合の損害は請求額として出ます。期限を待たず、リリース前に入れる前提で設計してください。

自前バックエンドを完全に置き換えられますか？

置き換えられるのは「モデルを呼ぶためだけのバックエンド」に限られます。入力の検証や書き換え、監査ログの保存、ユーザー単位の利用上限の管理といった処理が要るなら、それを置く場所は残ります。サーバープロンプトテンプレートで一部は寄せられるものの、2026年8月時点ではプレビュー段階の機能。業務要件の中核をここへ載せるのは避けるほうが無難です。

本番で指定するモデルはどれを選べばよいですか？

公式の本番チェックリストは、安定版のモデルIDを明示的に指定し、-latest のエイリアスや preview・experimental の版を使わないよう指示しています。2026年8月時点で推奨表示されているのは gemini-3.7-flash。あわせてモデル名を Remote Config から動的に読む構成にしておくと、停止予告が出てもアプリの更新なしで切り替えられます。Imagen 系は新規に選ぶ対象から外してください。

関連記事

• Firebase App Checkとは｜プロバイダ選定と監視から強制への移行：App Check の設定手順と指標の読み方
• Firebaseの料金｜無料枠とBlaze超過単価の実額：Spark と Blaze の境目と予算上限の範囲
• Cloud Functions for Firebaseとは｜トリガー設計と第2世代の実装判断：バックエンドを挟む側の構成と費用の内訳
• Vertex AIとは｜Google CloudのAI開発プラットフォームの機能と料金：Agent Platform 版の呼び出し先の全体像
• Firebaseの導入手順｜プロジェクト作成からSDK導入と初回デプロイまで：前提になるプロジェクト作成とSDK組み込み