生成AIは、モバイルアプリケーションの中でますます一般的な機能になりつつあります。AI機能を構築するとき、開発者はまず次のようなアーキテクチャから考えることがよくあります。

モバイルアプリ
    ↓
バックエンドAPI
    ↓
LLMプロバイダー

複雑なAIシステムであれば、このアーキテクチャは非常に合理的です。

バックエンドでは、例えば以下を処理する必要があります。

RAG（Retrieval-Augmented Generation：検索拡張生成）
ベクトルデータベース
LangChain / LangGraphワークフロー
Tool calling
ビジネスルール
会話メモリ
マルチエージェント・オーケストレーション
アクセス制御
プロンプト管理
利用状況のトラッキング
社内システムとの連携

しかし、AI機能そのものが非常にシンプルだったらどうでしょうか。

例えば、

モバイルアプリに必要なのは、ユーザーがメッセージを送信し、システムがそのメッセージとプロンプトを組み合わせ、Geminiが回答を生成するだけのチャットボット。

というケースです。

この場合、バックエンドサービスを追加することで、バックエンドが提供する価値以上にインフラや保守の作業が増えてしまう可能性があります。

Firebase AI Logicは、別のアプローチを提供します。次のような構成ではなく、

モバイルアプリ
    ↓
バックエンドAPI
    ↓
LangChain / LangGraph
    ↓
Gemini API

次のようにアーキテクチャを簡素化できます。

モバイルアプリ
    ↓
Firebase AI Logic
    ↓
Gemini

Firebase AI Logicは、モバイルアプリやWebアプリがアプリケーションコードからGemini APIを呼び出せるクライアントSDKを提供しています。現在、Appleプラットフォーム向けのSwift、Android向けのKotlin/Java、Web向けのJavaScript、Flutter向けのDart、Unityをサポートしています。

Firebase AI Logicでは、以下の2つのプロバイダーオプションを通じてGeminiを利用できます。

ここから、実務的なアーキテクチャ上の問いが生まれます。

システムを過剰設計せず、AI機能をより速く本番リリースするにはどうすればよいのでしょうか？

従来のアーキテクチャ

モバイルアプリ内にシンプルなチャットボットを構築するとします。バックエンドを使う場合、アーキテクチャは次のようになります。

┌─────────────────────┐
│    モバイルアプリ    │
└─────────┬───────────┘
          │ HTTPS
          ▼
┌─────────────────────┐
│    バックエンドAPI   │
│                     │
│ - 認証              │
│ - プロンプト生成     │
│ - APIプロキシ        │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│     Gemini API      │
└─────────────────────┘

この設計自体はまったく問題ありません。しかし、バックエンドが実質的に次の処理しかしていないのであれば、

const response = await model.generateContent([
  SYSTEM_PROMPT,
  userMessage,
]);

return response.text;

次の問いを考える価値があります。

このバックエンドは、構築・運用するコストに見合うだけの価値を本当に提供しているでしょうか？

本番環境でバックエンドサービスを持つ場合、通常は追加で次のような責任が発生します。

デプロイパイプライン
コンテナまたはサーバーレスのランタイム
ロギング
モニタリング
スケーリング
認証ミドルウェア
シークレット管理
APIレート制限
エラーハンドリング
インフラ設定
セキュリティパッチ

複雑なAIワークフローであれば、こうしたオーバーヘッドには十分な理由があります。しかし、シンプルなAI機能では、そうとは限りません。

Firebase AI Logicはどのように動くのか？

Firebase AI Logicは、モバイルアプリやWebアプリからFirebaseのクライアントSDKを通じてGeminiを呼び出せるように設計されています。

シンプルな構成は次のようになります。

┌─────────────────────┐
│    モバイルアプリ    │
│                     │
│ Firebase AI Logic   │
│ SDK                 │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Firebase AI Logic   │
│ Proxy / Gateway     │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│       Gemini        │
└─────────────────────┘

重要なのは次の点です。

Firebase AI Logicは、Gemini APIキーをAPKやIPAに埋め込み、Gemini REST APIを直接呼び出すだけの仕組みではありません。

Firebase AI Logicには、クライアントSDKとGemini APIプロバイダーの間にプロキシサービスが存在します。これはFirebase AI Logicのセキュリティモデルにおける重要な要素です。

Flutterコード例：数行でGeminiを呼び出す

FlutterプロジェクトでFirebaseを設定した後、基本的な連携コードは非常に小さくできます。

import 'package:firebase_ai/firebase_ai.dart';
import 'package:firebase_core/firebase_core.dart';
import 'firebase_options.dart';

// Initialize FirebaseApp
await Firebase.initializeApp(
  options: DefaultFirebaseOptions.currentPlatform,
);

// Initialize the Gemini Developer API backend service
// Create a `GenerativeModel` instance with a model that supports your use case
final model =
      FirebaseAI.googleAI().generativeModel(model: 'gemini-3.7-flash');

// Provide a prompt that contains text
final prompt = [Content.text('Write a story about a magic backpack.')];

// To generate text output, call generateContent with the text input
final response = await model.generateContent(prompt);
print(response.text);

クライアント側からのAI呼び出しは悪用されないのか？

AIをクライアントから直接呼び出すとき、通常もっとも大きな懸念になるのがこの点です。モバイルアプリからリクエストが送信される場合、攻撃者は次のようなことを試みる可能性があります。

APKを逆コンパイルする
ネットワークリクエストを調査する
アプリケーションの処理フローをリバースエンジニアリングする
自動リクエストを送信するスクリプトを書く
Geminiのクォータを消費する
想定外のコストを発生させる

Firebaseは、この問題の一部に Firebase App Check で対応しています。

2026年11月2日以降、Firebase AI Logicを利用するには Firebase App Checkの適用 が必須になります。

つまり、Firebase AI LogicへのリクエストはApp Checkの検証を通過する必要があり、正規のアプリケーションインスタンスから発生していないトラフィックを拒否しやすくなります。

概念的には次のようになります。

モバイルアプリ
    │
    │ App attestation
    ▼
App Check
    │
    │ 有効なトークン
    ▼
Firebase AI Logic
    │
    ▼
Gemini

App Checkによってモバイルクライアントが信頼できるサーバーになるわけではありません。

App Checkが解決するのは、別の問題です。

このリクエストは、私たちが許可している正規のアプリケーションインスタンスから本当に送られてきたものか？

生成AIの処理をクライアントに近づける場合、これは重要な保護レイヤーになります。

レート制限は依然として必要

App Checkだけを唯一の保護レイヤーにするべきではありません。正規ユーザーであっても、過剰なリクエストを送信することがあります。

Firebase AI Logicでは、利用するGeminiプロバイダー側のレート制限やクォータに加え、設定可能なユーザー単位のレート制限を利用できます。

例えば、

想定利用量：
ユーザー1人あたり 5〜10リクエスト / 分

設定する上限：
ユーザー1人あたり 20リクエスト / 分

本番環境では、次のように保護を多層化できます。

リクエスト
   │
   ▼
App Check
   │
   ▼
ユーザー単位のレート制限
   │
   ▼
Gemini APIクォータ
   │
   ▼
Gemini

これは次のような構成より、はるかに合理的です。

モバイルアプリ
    ↓
Gemini REST API
    ↓
アプリ内に埋め込まれたAPIキー

Server Prompt Templates：プロンプトをモバイルアプリに埋め込む必要がない

開発者がAIバックエンドを構築する一般的な理由の1つは、次の懸念です。

「システムプロンプトには業務上の指示が含まれているので、モバイルアプリの中には置けない」

これは妥当な懸念です。

モバイルアプリは、程度の差はあっても常にリバースエンジニアリングされる可能性があります。しかし、Firebase AI Logicは現在 Server Prompt Templates をサポートしています。

Server Prompt Templatesを使うと、プロンプト、スキーマ、モデル設定をサーバー側に保存できます。クライアントアプリは、テンプレートIDと必要な入力変数だけを送信します。

例えば、モバイルアプリ内に次のような内容をハードコードする代わりに、

SYSTEM PROMPT:

あなたは営業トレーニングの評価者です。

会話を以下の観点で評価してください：
- 質問
- 傾聴
- 提案
- 論理
- クロージング

このスキーマを使ってJSONを返してください...

クライアント側では次のように呼び出せます。

// Initialize the Gemini Developer API backend service.
// Create a `TemplateGenerativeModel` instance.
var _model = FirebaseAI.googleAI().templateGenerativeModel()

var customerName = 'Jane';

var response = await _model.generateContent(
        // Specify your template ID
        'my-first-template-v1-0-0',
        // Provide the values for any input variables required by your template.
        inputs: {
           'customerName': customerName,
        },
      );

var text = response?.text;
print(text);

実際のシステム指示はサーバー側で管理されます。

Server Prompt Templatesには、次のような明確な利点があります。

プロンプトをクライアントコードに直接露出させない
新しいアプリバージョンをリリースしなくてもプロンプトを更新できる
スキーマやモデル設定をサーバー側で管理できる
アプリのリリースとは独立してプロンプトのバージョンを進化させられる

Template-only Mode

Firebase AI Logicは template-only mode も提供しています。

この機能を適用すると、Server Prompt Templatesを使っていないFirebase AI Logicのリクエストをブロックできます。これはFirebase AI Logic経由のリクエストに対するプロジェクト全体の設定です。

フローは次のようになります。

モバイルアプリ
    ↓
テンプレートID + 入力
    ↓
Firebase AI Logic
    ↓
Server Prompt Template
    ↓
Gemini

次のように任意のシステムプロンプトを送る構成ではありません。

モバイルアプリ
    ↓
任意のシステムプロンプト
    ↓
Gemini

これはアーキテクチャ上の判断を大きく変えます。以前であれば、次のように考えていたかもしれません。

機微なシステムプロンプト
        ↓
バックエンドが必要

Firebase AI Logicでは、

機微なシステムプロンプト
        ↓
Server Prompt Template
        ↓
Template-only Mode
        ↓
専用バックエンドが不要な場合もある

という構成を検討できます。

Firebaseは、悪用やプロンプトインジェクションのリスクを軽減するために、template-only modeと入力検証を組み合わせることも推奨しています。

Server Prompt Templatesはバックエンドを完全には置き換えない

重要な違いは次の点です。

プロンプトを保護することと、ビジネス操作を保護することは別です。

Server Prompt Templatesは、次の管理に適しています。

システムプロンプト
評価基準
出力スキーマ
モデル設定
プロンプト構造
入力検証
プロンプトのバージョン管理

しかし、これによってモバイルアプリが信頼できる実行環境になるわけではありません。したがって、

機微なプロンプト
      ↓
Server Prompt Template
      ↓
バックエンド不要の場合もある

一方、

機微なビジネス操作
      ↓
信頼できるバックエンド

という設計は、多くのケースで依然として正しい選択です。

それでもバックエンドを使うべきなのはいつか？

Firebase AI Logicを使うことで、多くのシンプルなAIユースケースでは専用AIバックエンドをなくせる可能性があります。ただし、バックエンドの方が適切なケースは依然として存在します。

1. RAGと非公開データ

AIが次のようなデータへアクセスする必要がある場合、

社内文書
非公開データベース
ベクトル検索
エンタープライズ検索
顧客データ
社内ナレッジベース

通常はバックエンド側に検索パイプラインを置く方が適切です。

例えば、

モバイル
   ↓
バックエンド
   ↓
Retriever
   ↓
Vector DB / Search
   ↓
Gemini

Server Prompt TemplateはRAGエンジンではありません。

2. 複雑なAIワークフロー

AIワークフローが次のような構成の場合、

ユーザーリクエスト
     ↓
Classifier
     ↓
Planner
     ↓
Retriever
     ↓
Tool A
     ↓
Tool B
     ↓
Validator
     ↓
Gemini

LangGraphのようなオーケストレーションフレームワークには、依然として明確な価値があります。

このようなワークフローでは、多くの場合、以下が必要です。

状態管理
リトライ
分岐
Tool実行
多段処理
人間による承認
長時間実行ジョブ

これは、もはや単純なモデル呼び出しではありません。

3. 信頼性が必要なビジネス操作

AIが次のような操作を実行できる場合、

注文を作成
注文をキャンセル
返金を実行
権限を変更
取引を承認
非公開レコードを更新

信頼できるサーバー側での認可が必要です。

例えば、

ユーザー：
「注文 #123 を返金して」
       ↓
AI
       ↓
返金対象か確認
       ↓
支払い状況を確認
       ↓
返金を実行

バックエンドは引き続き次を担うべきです。

認証
認可
ビジネスルールの検証
トランザクション整合性
監査ログ

AIの回答そのものを認可判断にしてはいけません。

4. 非公開APIとサーバーサイドツール

モデルが次のようなサービスを呼び出す必要がある場合、

CRM
ERP
決済ゲートウェイ
社内API
データベース
メールサービス
管理者API

バックエンドまたは信頼できるサーバーサイドのToolレイヤーが必要です。APIの認証情報や特権操作をモバイルアプリ内に置くべきではありません。

5. コンプライアンス、監査、ガバナンス

システムによっては、次のような集中管理が必要です。

AIリクエストのログ
プロンプト履歴
出力監査
モデレーション
コスト配賦
ユーザー単位の利用制御
コンプライアンスポリシー
データ保持ポリシー

このような場合は、専用バックエンドまたはAI Gatewayの方が適切なアーキテクチャになることがあります。

Server Prompt Templatesにも制約がある

Server Prompt Templatesは現在 Preview 機能です。そのため、機能は今後も変更される可能性があり、通常のSLAや非推奨化ポリシーの対象外となる場合があります。

またFirebaseは、Server Prompt Templatesで完全にはサポートされていない機能も明記しています。例えば、Gemini Liveモデルは現時点ではServer Prompt Templatesでサポートされていません。

したがって、アプリケーションがテンプレートで未サポートの機能に依存している場合、template-only modeを有効化すると、それらのリクエストがブロックされる可能性があります。

本番環境でtemplate-only modeを適用する前に確認すべき点です。

専用AIバックエンドをなくすメリット

シンプルなAIユースケースでは、最大のメリットは必ずしもインフラコストではありません。より大きなメリットは、アーキテクチャの複雑性を減らせることです。

従来のアーキテクチャ

モバイル
  ↓
API Gateway
  ↓
バックエンド
  ↓
AI SDK / Framework
  ↓
Gemini

チームは次のものを保守する必要があります。

モバイルアプリ
+
バックエンドリポジトリ
+
CI/CD
+
ランタイム
+
インフラ
+
シークレット
+
モニタリング
+
スケーリング
+
AI連携

Firebase AI Logic

モバイル
  ↓
Firebase AI Logic
  ↓
Gemini

プロンプトを保護する必要がある場合は、

モバイル
  ↓
Firebase AI Logic
  ↓
Server Prompt Template
  ↓
Gemini

となります。

チームはより次の領域に集中できます。

モバイルアプリ
+
Firebase設定
+
Prompt Templates
+
AI機能

これまでバックエンドが次の処理のためだけに存在していたのであれば、

リクエスト受信
       ↓
システムプロンプトを追加
       ↓
Geminiを呼び出す
       ↓
レスポンスを返す

Server Prompt Templatesによって、そのバックエンドを維持する理由は大幅に小さくなります。

ネットワークホップを減らし、運用対象も減らす

従来のアーキテクチャ：

モバイル
 → 自社API Gateway
 → 自社バックエンド
 → Gemini
 → 自社バックエンド
 → モバイル

Firebase AI Logic：

モバイル
 → Firebase AI Logic
 → Gemini
 → モバイル

もちろん、Firebase側にもクライアントとGeminiの間のインフラは存在します。

違いは、

「サーバーが完全になくなる」

ことではありません。

違いは、

チーム自身が専用AIプロキシサーバーを構築・運用する必要がなくなることです。

これにより、以下を減らせます。

インフラ構築
デプロイ
モニタリング
スケーリング責任
バックエンド保守

料金はどうなる？

Firebase AI Logicでは、Gemini Developer APIの無料・有料の両方のティアを利用できます。

有料ティアを利用するには、FirebaseプロジェクトをCloud Billingにリンクする必要があり、従量課金のBlazeプランを利用することになります。

重要なのは次の点です。

バックエンドが不要だからといって、コスト管理が不要になるわけではありません。

Firebaseには、Firebase AI Logicに関するコスト、利用状況、各種メトリクスを監視するためのツールがあります。

本番環境では、引き続き次のような組み合わせが必要です。

App Check
+
ユーザー単位のレート制限
+
Gemini APIクォータ
+
予算アラート
+
トークン / 利用量モニタリング

Firebase AI Logicが適しているケース

次のようなフローのAI機能は、有力な候補です。

ユーザー入力
    ↓
プロンプト
    ↓
Gemini
    ↓
レスポンス

例えば、

シンプルなチャットボット
リライト
翻訳
要約
分類
文法修正
コンテンツ提案
画像理解
基本的なマルチモーダル対話

プロンプトを保護する必要がある場合も、

ユーザー入力
    ↓
Server Prompt Template
    ↓
Gemini
    ↓
レスポンス

という構成にすることで、Firebase AI Logicだけで専用バックエンドなしに対応できる場合があります。

AIアーキテクチャをもっと実践的に分類する

すべてのAI機能を最初から、

LangChain
+
LangGraph
+
Vector Database
+
Redis
+
Backend API
+
Worker

で始めるのではなく、実際の複雑さに応じてアーキテクチャを選択できます。

Level 1 — 直接AI機能

モバイル
   ↓
Firebase AI Logic
   ↓
Gemini

適した用途：

リライト
要約
シンプルなチャット
分類

Level 1.5 — 保護されたプロンプト

モバイル
   ↓
Firebase AI Logic
   ↓
Server Prompt Template
   ↓
Gemini

次の機能と組み合わせられます。

App Check
+
Template-only Mode
+
Rate Limiting

適した用途：

サーバー管理のシステムプロンプト
評価指示
標準化されたAIの挙動
アプリリリースとは独立して管理するプロンプト設定

Level 2 — 信頼性が必要なビジネスロジックを伴うAI

モバイル
   ↓
バックエンド
   ↓
Gemini

適した用途：

非公開API
ビジネス上の認可
機微な操作
集中監査

Level 3 — RAG

モバイル
   ↓
バックエンド
   ↓
Retriever
   ↓
Vector DB / Search
   ↓
Gemini

適した用途：

社内ナレッジアシスタント
企業文書のQ&A
非公開ナレッジの検索

Level 4 — AIワークフロー / エージェント

モバイル
   ↓
バックエンド
   ↓
LangGraph / Agent Workflow
   ├── Planner
   ├── Retriever
   ├── Tools
   ├── APIs
   └── Validator
          ↓
        Gemini

適した用途：

AIエージェント
複雑なワークフロー
多段自動化
Toolを多用するAIシステム

Level 1の問題にLevel 4のアーキテクチャを使わない

生成AIによって、多くの技術が登場しました。

LangChain
LangGraph
Vector Databases
Embeddings
Rerankers
Agent Frameworks
MCP
AI Gateways

いずれも実際の課題を解決する技術です。

しかし、それらが存在するからといって、すべてのAI機能に必要なわけではありません。

本当の要件が次のようなものだけなら、

入力
  ↓
プロンプト
  ↓
モデル
  ↓
出力

アーキテクチャも同じようにシンプルにできます。

まとめ

Firebase AI Logicは、クライアントから直接利用できる次の機能群を提供することで、モバイル・Webアプリに生成AI機能を組み込みやすくします。

Firebase AI Logic SDK
+
App Check
+
ユーザー単位のレート制限
+
Server Prompt Templates
+
Template-only Mode

Server Prompt Templatesを使えば、プロンプト、スキーマ、設定をモバイルアプリにハードコードする代わりに、サーバー側に保持できます。Template-only Modeを使えば、Firebase AI Logicへのリクエストにそれらのテンプレート利用を強制することもできます。

ただし、Firebase AI Logicがすべてのバックエンドを置き換えるわけではありません。AIが次のものを必要とする場合、バックエンドは依然として重要です。

非公開データ
RAG
信頼性が必要なビジネス操作
非公開API
複雑なオーケストレーション
コンプライアンスまたは集中監査

この記事の中心的なメッセージは次の通りです。

セキュリティ、ビジネス、運用上の要件を満たせる範囲で、最もシンプルなアーキテクチャを選ぶ。

シンプルなAI機能にAPI Gateway、Backend Service、LangChain、LangGraph、Redis、Vector Database、Agent Frameworkを追加する前に、まず次のことを問いかけるだけでよいのかもしれません。

「このAI機能に、本当にバックエンドは必要なのか？」

Firebase AI LogicでAI機能をより速く本番リリースする

従来のアーキテクチャ

Firebase AI Logicはどのように動くのか？

Flutterコード例：数行でGeminiを呼び出す

クライアント側からのAI呼び出しは悪用されないのか？

レート制限は依然として必要

Server Prompt Templates：プロンプトをモバイルアプリに埋め込む必要がない

Template-only Mode

Server Prompt Templatesはバックエンドを完全には置き換えない

それでもバックエンドを使うべきなのはいつか？

1. RAGと非公開データ

2. 複雑なAIワークフロー

3. 信頼性が必要なビジネス操作

4. 非公開APIとサーバーサイドツール

5. コンプライアンス、監査、ガバナンス

Server Prompt Templatesにも制約がある

専用AIバックエンドをなくすメリット

従来のアーキテクチャ

Firebase AI Logic

ネットワークホップを減らし、運用対象も減らす

料金はどうなる？

Firebase AI Logicが適しているケース

AIアーキテクチャをもっと実践的に分類する

Level 1 — 直接AI機能

Level 1.5 — 保護されたプロンプト

Level 2 — 信頼性が必要なビジネスロジックを伴うAI

Level 3 — RAG

Level 4 — AIワークフロー / エージェント

Level 1の問題にLevel 4のアーキテクチャを使わない

まとめ

参考資料

関連記事

三面図から立体を起こす AI ― SDF で「形のアタリ」をつかむ

ロボットに相撲を教えてみたら、ラリアット・コサックダンス・空中戦を極めた件

曖昧な要件を見積もり可能にするAgent Skillを開発しました。