AI / LLM

Firebase AI Logic ハイブリッド推論が Web で GA — オンデバイスとクラウドを自動で切り替える仕組みを徹底解説

FirebaseGeminiAIWebオンデバイスAI

はじめに

Firebase AI Logic の「ハイブリッド推論（hybrid on-device inference）」が、ついに Web で GA（一般提供）になりました。これは、ブラウザ内に組み込まれたオンデバイスモデルが使えるならそれで推論し、使えなければクラウドのモデルへシームレスにフォールバックする、という仕組みを Firebase の SDK が肩代わりしてくれるものです。

「オンデバイス AI」と「クラウド AI」は、これまでどちらか一方を選ぶものでした。ハイブリッド推論はその二択を、SDK の mode パラメータひとつで橋渡しします。この記事では、その仕組みと前提条件、実際の使い方、そしてエンジニアがいま何を考えておくべきかを掘り下げます。

何が GA になったのか — Web 版ハイブリッド推論の中身

今回 Web で正式提供されたのは、Chrome デスクトップに組み込まれた Gemini Nano を使ったオンデバイス推論と、それが使えない環境でのクラウドモデルへの自動フォールバックです。

ポイントは、アプリ側のコードが「どこで推論が走っているか」をほとんど意識しなくて済むことです。GenerativeModel を生成するときに推論モードを指定するだけで、ルーティングは SDK が処理します。モードは次の4つです。

  • PREFER_ON_DEVICE: オンデバイスを優先し、使えなければクラウドへフォールバック
  • ONLY_ON_DEVICE: オンデバイスのみ（使えなければエラー）
  • PREFER_IN_CLOUD: クラウドを優先し、オフライン時などはオンデバイスへ
  • ONLY_IN_CLOUD: クラウドのみ（従来どおりの挙動）

つまり「オンライン時はクラウドのフルモデル、オフラインや機密データはオンデバイス」といった戦略も、その逆も、設定値だけで切り替えられるわけです。

ただし、現時点でオンデバイス推論に対応するのは Chrome デスクトップ（v139 以上）のみです。Safari や Firefox、モバイル版 Chrome では自動的にクラウド側で動くことになります。

技術的な背景 — W3C Prompt API と Gemini Nano

このハイブリッド推論を支えているのが、Chrome に組み込まれた Gemini Nano と、提案中の Web 標準である W3C Prompt API です。

Firebase AI Logic の Web SDK は、内部でこの Prompt API を呼び出してブラウザ内蔵モデル（Chrome なら Gemini Nano）にアクセスし、利用できなければサーバー上の Gemini モデルへ切り替えます。Gemini Nano はブラウザがオンデマンドでダウンロード・ホストする軽量モデルで、初回はダウンロードに数分かかることがあります。

オンデバイスで動かす利点ははっきりしています。プライバシー（データが端末から出ない）、オフライン動作、コスト（オンデバイス推論は無料）、そしてハードウェアアクセラレーションによる応答速度です。一方でクラウド側は、対応していない環境でも確実に動くという「広いアクセス性と信頼性」を担保します。ハイブリッド推論は、この両者のいいとこ取りを狙った設計だと言えます。

なお、Chrome 公式ドキュメントも「素の Prompt API を直接叩く」のではなく、フォールバックを内蔵した Firebase AI Logic 経由での利用を推奨しています。ブラウザ実装差を吸収してくれる点が大きいからです。

制約と前提条件 — ここを押さえないとハマる

GA とはいえ、オンデバイス側にはまだ無視できない制約があります。実装前に必ず確認しておきたいポイントです。

  • 対応は単一ターンのテキスト生成のみ。マルチターンチャット、音声・動画・PDF 入力、画像生成、関数呼び出し（ツール）、Live API、トークンカウントは非対応。
  • 入力は テキスト、または JPEG/PNG 画像 + テキスト。構造化出力（JSON・enum）には対応。
  • 最大 6000 トークン程度の制限。
  • セットアップでは Chrome のフラグ（chrome://flags/#prompt-api-for-gemini-nano-multimodal-input）を有効化する必要がある。
  • initializeDeviceModel() はユーザー操作（ボタンクリック等）の後に呼ぶ必要があり、モデルダウンロードの進捗もここで受け取れる。
  • 本番では Chrome の Origin Trial への登録が必須。トークンを meta タグや HTTP ヘッダー経由で渡す。
// オンデバイスモデルの初期化（ユーザー操作後に呼ぶ）
model.initializeDeviceModel((val) =>
  console.log(`Download progress: ${Math.round(val * 10000) / 100}%`)
);

これらを踏まえると、現時点の Web 版ハイブリッド推論は「短いテキスト処理を、プライバシー重視・低コストで回したいユースケース」にフィットします。チャットボットのような複数ターンの対話には、まだクラウド側が前提になります。

エンジニアへの影響 — どう使い分けるか

実務でまず効くのは、コストとプライバシーのコントロールです。要約・分類・タグ付け・簡単な書き換えといった「単発のテキスト処理」は、対応ブラウザならオンデバイスで無料かつローカル完結にでき、非対応環境だけクラウドに流す、という分担が現実的になります。入力フォームの補助やクライアントサイドの前処理など、レイテンシとプライバシーが効くところほど恩恵が大きいでしょう。

設計上の注意点として、Chrome 公式も指摘するとおり「クラウドにフォールバックした瞬間、データの処理場所が変わる」ことをユーザーに透明に伝える必要があります。オンデバイス前提で機密データを扱うつもりが、知らぬ間にクラウドへ送られていた、という事態は避けたい。ONLY_ON_DEVICE で明示的に閉じるか、フォールバック発生をユーザーに通知する設計が望ましいです。

そして、この流れは Web だけの話ではありません。ハイブリッド推論は Android でも提供されており、Flutter からオンデバイス/クラウドをルーティングする実装例もコミュニティで登場しています。マルチプラットフォームでアプリを作るなら、「推論をどこで走らせるか」を抽象化レイヤーで切り替える設計が、これから標準になっていきそうです。

まとめ

  • Firebase AI Logic のハイブリッド推論が Web で GA。Chrome デスクトップの Gemini Nano を使ったオンデバイス推論と、クラウドへの自動フォールバックを SDK が処理する。
  • 切り替えは PREFER_ON_DEVICE など4つの mode 設定だけ。利点はプライバシー・オフライン・コスト・速度。
  • 現状の制約は 単一ターンのテキスト生成・Chrome v139 以上・本番は Origin Trial 必須など。チャット用途はまだクラウド前提。
  • フォールバックでデータ処理場所が変わる点の透明性が設計上の鍵。

オンデバイスとクラウドの境界が SDK レベルで溶け始めた、という意味で象徴的なリリースです。対応ブラウザはまだ限られますが、「推論の置き場所」を設定値で選べる時代を見据えて、いまのうちにアーキテクチャを抽象化しておく価値はありそうです。

ソース

Back to articles