Android で AI を作る 3 つの選択肢 — Florina Muntenescu & Oli Gaymond (Google DeepMind) AMA

AI Engineer 2026 / 約 20 分 / Q&A 形式

Oli Gaymond · 09:00 付近「これ (= フラグシップ級 on-device モデル) は全アプリで必要な訳じゃない。動作を遅くするし、高価でもある」

AI Engineer 2026 のブース横で開かれた約 20 分の AMA セッション。登壇は Florina Muntenescu (Google DeepMind、 Developer Relations Engineer — Intelligent experiences と Developer productivity の両領域を担当) と Oli Gaymond (Google DeepMind、 PM for Android AI — Applied AI、 DevTools、 Hardware acceleration を横断統括)。冒頭 7 分の TLDR + 約 13 分の Q&A 形式

AMA の構造は珍しく、ステージ上の発表と、会場の開発者から飛ぶ質問の往復で進む。 Florina が「Android で AI を作る 3 つの選択肢 — on-device / hybrid / cloud」を 6 分弱で総ざらいし、残り 13 分強を完全に質問駆動に明け渡す。結果として、公式発表動画では拾われにくい開発者側の懸念 — RAM や battery、 OS 共有モデルのスケール、 RAG との互換性、 Gemini app と開発者向け API の境界 — が一通り表面化した。

Florina の TLDR が組み立てる骨格は単純。 prompts をデバイス内で処理する on-device、デバイスに Gemini Nano が無い時だけクラウドに落ちる hybrid、そして Gemini Pro / Flash / Flashlight をフルにクラウドで叩く cloud。「機微データはデバイスから出さない」「オフライン動作」「追加コストゼロ」を on-device の理由として並べ、翻訳や短い context window で済むユースケースを推奨用途として挙げる。

重要なのは on-device の到達ルート。 Florina は二本立てで紹介する。 ML Kit Gen AI APIs 経由で Gemini Nano を呼ぶ標準ルート、そしてカスタムモデルが必要な場合のための LytRT LM (= 別セッションで詳細解説予定)。 prompt API はテキスト + 画像入力 / テキスト出力に対応、 image understanding や entity extraction、 content analysis を 1 つの API で吸収する。

Gemini Nano がデバイスに来る経路として、 Oli は AI Core という system service を提示する。これが本セッションで最も含意の重い設計判断 — 「デバイスに 1 つのモデルだけを置き、全アプリで共有する」。 1 アプリが 1 - 4 GB のモデルを個別に出荷する世界は、単純に成立しない、という認識が背景にある。

Hybrid の経路として紹介されるのは Firebase AI logic の hybrid inference (数週間前に launch)。「Gemini Nano があれば on-device で、無ければクラウドで」を 1 つの API で扱える。 Gemma 4 ベースの次世代 Gemini Nano が利用可能になると、 on-device と Gemini Flash 系がほぼ等価な体験を提供する見通し、とも語られる。

Q&A 主要テーマ

RAM / battery 影響 — 「day に 10 - 20 回なら問題ない」 (08:00 - 09:55)

最初の質問は当然この論点に向かう。「RAM 使用量や battery 影響は確認済みか」 — 開発者の素朴な懸念。 Oli の応答は二段構え。まず「モデルは可能な限り小さくしたが、機能性を維持しようとすれば flagship 級が必要」。続いて使い方依存の見立て: 「day 10 - 20 回の使用なら battery への影響は気にする水準ではない」、「batch 処理 (一晩で大量に処理する系) なら overnight charging 中に走らせる」。

AI Core で OS が全部の最適化を引き受ける、という構造が battery 議論の前提として機能する。「アプリ側は inference を呼ぶだけ、 scheduling と queue は OS が管理」という分業によって、個別アプリのチューニング負担を持ち上げない設計。ただし custom model 採用組には profiling tool を提供しつつ「自分で testing する負担を持つ」と境界を明示する。

システムレベル model 共有の経済合理性 (10:02 - 12:21)

次の質問が AMA の核心に触れる。「ML Kit を使う = デバイス内で共有されたモデルを使うことになるのか?」 → 「はい」。「ユーザーが 100 アプリ持っていて、 2 年後に全部が同じモデルを使う、という状況で latency をどう保つのか?」 — 開発者側の合理的な懸念。

Oli の応答が、 Google の Android AI 戦略の根拠を明文化する。「最小級モデルでも 1 GB、我々が出荷しているものは 3 - 4 GB に近い。これをアプリ開発者個人が出荷するのは現実的じゃない。端末を売れる絶対的キラー機能でないと、ユーザーに納得してもらえない」。「我々が system level でやれば、 1 回だけやって全員が共有して恩恵を受ける、そのコストを分散できる」。

スケール処理は OS の管理に組み込まれる。「foreground のアプリは top priority、 background は queue 待ち」、「centralizing、 queuing、全体管理を OS が行うことで battery 影響も attribution できる」、「GPS や WiFi で何度も見てきた構図 — ユーザーが価値を感じれば battery を喜んで使う、そうでなければ使わない」。 OS は capability を提供し、開発者は機能を作り、ユーザーが battery 消費を選ぶ、という三層の責任分担。

Gemini app と開発者向け API の境界 (12:21 - 14:48)

非 Pixel 端末を持つ参加者からの質問が、概念の混同を可視化する。「Hey Google で気温を聞くと答えが返る、これは local か remote か?」 — Oli の率直な応答: 「Gemini app または Gemini API 統合 search app に相当する。正直、確認はしていないが、想定では remote で動いている」。

質問者の次の問い — 「では、ここで紹介された API を入れて、 skill を書いて応答を改善できるのか?」 — に対して、 Florina が境界を引く。「2 つの異なるユーザージャーニーを混同している。自分のアプリを作るなら Gemini app と interaction はしない、 model 自体と直接話す。 on-device モデルを使えば、クラウドは気にしなくていい」。

Skill の話に踏み込んだ Oli は、さらに抽象度を上げる。「skill とは何かと言えば、 prompt の中に挿し込む何か、残りの context と一緒にね。ここで提供してるのは低レイヤーで、その上に何かを乗せて作る人 — 例えば OpenCode (旧 PokeClaw 表記) をインストールすれば、そういうものが skill を composé して prompt にまとめて、この API で実行する」。つまり Gemini app は完成された product、 ML Kit Gen AI APIs は構成要素 — 後者の上で開発者 (またはサードパーティ製エージェント) が新しい体験を構築する想定。

AI Edge Gallery vs AI Core — 「frontier 実証」と「production 実装」 (15:35 - 16:22)

別の参加者からの問い: 「Gemini Nano モデルと AI Edge で扱うモデルの違いは? RAG を実装したい、 PDF を入れて folder に置く、そういう構成は可能か?」

Oli は二段で答える。まず Gemini Nano + AI Core は完全に system が contain している、開発者は API 呼ぶだけで設定不要。 RAG については「prompt API でできる、 embedding API も coming soon — Gemma embedding model を直接 API から使えるようにする」。

AI Edge Gallery と AI Core の関係を Oli は明確に分ける。「 AI Edge Gallery は showcase、 frontier で何ができるかを見せる場所。 AI Core を裏で使えるし、 custom models も使える」、「AI Edge は uplift が必要、やる作業量が多い」、一方「AI Core は prompt と機能だけに focus できるよう設計してある — production-level アプリを作るためのもの」。同じ Google 内の 2 つの製品が、「先端を見せる」と「production に乗せる」という役割分担を持つ、という整理。

Embedding API は coming soon、 Gemma embedding 公開予定 (17:22 - 17:47)

最終盤の質問は明確。「vector / embedding 系のモデルもこの API で使えるのか? text node を vector 化して類似度を取りたい」。 Oli の応答: 「embedding API はまだ無い、けど近いうちに出す。 Gemma embedding model を、この API から直接使えるようにする」。

これは RAG 構築の前提条件をオンデバイスで揃える、という宣言。 prompt API + embedding API + ローカルストレージ (folder へのアクセスは既に prompt API がカバー) が揃えば、完全オンデバイスの RAG パイプラインが Android で組める世界が来る、という未来図。

device 多様性 × model 多様性のマトリクス (17:47 - 19:19)

最後の質問が AMA の射程を確認する。「device と model のマトリクス、どう考えればいいか? prompt と embedding 以外にもオンデバイスで動く model はあるか? それは flagship 限定か?」

Florina の整理: ML Kit API には classical な ML 系 (text、 OCR、 vision、自然言語) が広く含まれていて、これらは billion-plus デバイスで動く、小さい model なので。一方 Gen AI APIs (= prompt API、 embedding API 系) は flagship 過去 2 年世代に限定される、現時点では。 AI Core は「動くデバイスでなら必ず良く動く」を保証する範囲、 LytRT LM はそれより広いデバイスをカバーできるが testing を自分で担う必要がある。「もう数年待てば」ではなく、既存の Android 億単位デバイスに既に存在する 2 層構造 (classical ML 広範対応 + Gen AI フラグシップ限定) として、開発者に選択肢を提示する。

着眼点

「OS level の model 共有」 vs 「app 個別 ship」の経済合理性

この AMA が示す Google の戦略判断のうち、最も含意の重いのは AI Core の存在自体。 1 - 4 GB の LLM を個別アプリが APK / AAB に同梱する未来は、単純に成立しない (= 端末ストレージ、ダウンロード時間、重複コストの観点で)。 Oli の言葉で「端末を売れる絶対的キラー機能でないと正当化できない」 — つまり多くのアプリにとって、これは「自分で出荷する選択肢ですらない」。

OS level の model 共有は、経済合理性と物理的制約の両方の帰結。これは Google 固有の Android プラットフォーム支配力を活用した戦略 (= モデルを OS にバンドルできるのは OS 提供者だけ)、同時に Prince Canuma の MLX (Apple Silicon) アプローチと並ぶ、オンデバイス AI の 2 大流派を構成する。 Apple は MLX という framework + Apple Silicon の unified memory で「アプリ側がモデルを持つ」を可能にし、 Google は AI Core で「OS が 1 つのモデルを持って分配」を選んだ。同じ問題 (= モデルサイズ vs 配布性) への 2 つの異なる解。

Q&A から見える開発者の不安 — battery、 scale、 RAG 互換性

質問の構成自体が現状の開発者の懸念マップを描いている。 (1) battery / RAM は本当に大丈夫か、 (2) 100 アプリが同じモデルを叩く未来で latency は保てるか、 (3) Gemini app と開発者 API は何が違うのか、 (4) RAG / embedding 系のワークロードが組めるのか — これらは仕様書やキーノートの一方向情報では出てこない、実装者側の不安。

Google の応答は概ね「OS と AI Core で抽象化する、開発者はその下を気にしなくていい」で一貫しているが、同時に embedding API は coming soon、 hybrid inference は数週間前 launch、次世代 Gemini Nano は preview 段階、と全てが進行中の状態。 Q&A の中身は、「製品として揃ってきている」と「まだ来ていない部品が残っている」の境界そのもの。

Google の 3 階層戦略 (on-device → hybrid → cloud) の一貫性

Florina の TLDR が描く 3 階層は、単なる「選択肢が 3 つあります」ではなく、同じ API surface でグラデーションを作る、という設計思想。 ML Kit Gen AI APIs (on-device 限定)、 Firebase AI logic (on-device fall-back to cloud)、 Firebase AI logic (cloud-only でも Gemini Pro / Flash / Flashlight にアクセス) — これら 3 つは異なる API ではあるが、「一貫した実装感」を目標として設計されているとの言明 (= 「we're trying to make those APIs as consistent as possible」)。

これは Apple の MLX (オンデバイス専業) や、 Anthropic / OpenAI の API (クラウド専業) とは異なる立ち位置。デバイス能力と機能要件で開発者が層を選び、同じコードベースから移動できる、という設計。 hybrid inference の存在が特に象徴的 — 「on-device があれば使う、無ければクラウドに落ちる」を 1 つの呼び出しで完結させる、デベロッパーの判断負担を下げる仕掛け。

動画の構成

(00:00) 自己紹介 — Florina (DevRel)、 Oli (PM Android AI)、当 AMA の進行方針
(01:34) TLDR 開始 — Android で AI を作る 3 つの選択肢の俯瞰
(02:19) On-device の利点 — 機微データの非送信、オフライン動作、追加コスト無し
(03:06) ML Kit Gen AI APIs — Gemini Nano、 Gemma 4 アーキテクチャ、 prompt API + 特化 API
(03:51) AI Core system service — モデル 1 つを OS が保持、全アプリで共有、 privacy / safety
(05:26) Prompt API — テキスト + 画像入力、 image understanding 等のユースケース
(06:12) Hybrid inference — Firebase AI logic、 on-device 不可ならクラウド
(06:59) Cloud full — Pro / Flash / Flashlight、 Vertex AI / Gemini API / Gemini Developer API
(07:45) TLDR まとめ、 Q&A 開始の合図
(08:00) Q1: RAM / battery 影響
(10:02) Q2: ML Kit のモデル共有とスケール
(12:21) Q3: Gemini app と開発者 API の違い
(13:11) Q4: ローカル / リモートの判定、 skill 追加可能性
(15:35) Q5: AI Edge Gallery と AI Core の関係、 RAG 実装
(16:22) AI Edge は frontier 実証、 AI Core は production 実装
(17:08) ファイル / 画像入力経路の確認 (prompt API カバー)
(17:22) Q6: embedding API の有無 (= coming soon、 Gemma embedding)
(17:47) Q7: device × model のマトリクス、 classical ML と Gen AI の違い
(19:19) 締め — 「ブースに来てね」で終了

出典

AI on Android: Ask me Anything — Florina Muntenescu & Oli Gaymond, Google DeepMind (AI Engineer)

フロリナ・ムンテネスク

Florina Muntenescu

Google DeepMind Developer Relations Engineer / Android AI + Developer productivity 担当

オリ・ゲイモンド

Oli Gaymond

Google DeepMind PM for Android AI / Applied AI + DevTools + Hardware acceleration 担当

用語集

Gemini Nano: Google DeepMind がモバイル向けに最適化した最小級 LLM。 Gemma 4 と同じアーキテクチャを基盤にしつつ、 Android デバイスのハードウェアアクセラレーション (SoC 内 NPU 等) 向けに最適化済み。現時点で flagship 級デバイス (Pixel 9 / 10 世代、および同等の他 OEM) で動作。
AI Core (system service): Android の system service として動作する、オンデバイス AI 推論の基盤レイヤー。 Gemini Nano を OS レベルで 1 つだけ保持し、全アプリが共有する仕組み。 prompt の queue 管理、 hardware accelerator の選択、 input/output データの非保存、 foreground / background priority などを統合管理。「アプリ毎に LLM を出荷する」必要を消す設計判断の中核。
ML Kit Gen AI APIs: Android 開発者が Gemini Nano にアクセスするための公式 API スイート。 summarization、 proofreading、 rewrite といったタスク特化 API と、自由形式の prompt API を含む。 prompt API はテキスト + 画像入力 / テキスト出力に対応。 ML Kit 全体には vision / 自然言語 / OCR 等の classical ML API も含まれ、これらは billion-plus デバイスで動く。
LytRT LM: Android でカスタムモデルを動かすためのフレームワーク。 ML Kit Gen AI APIs では対応できない自前モデルや、 AI Core が対応していないデバイスで動かしたい場合の選択肢。 AI Engineer 2026 の同セッション直後に別講演が予定 (= Kormat 氏)。 testing と最適化の負担は開発者側に来る。
Firebase AI logic: Google の Firebase 経由で Android アプリが Gemini API / Vertex AI / Gemini Developer API を統合的に扱える SDK。数週間前に hybrid inference (= on-device 優先、不可ならクラウド) が公式化された。 Pro / Flash / Flashlight などのクラウド側モデルへのアクセスも提供。
Gemma 4: Google が直近 (この AMA の 1 週間前) に launch したオープンウェイトモデル系列。 Gemini Nano の次世代もこのアーキテクチャを共有する。同時期に発表された Gemma embedding model が、 ML Kit Gen AI APIs の embedding API (coming soon) で直接利用可能になる予定。
hybrid inference: 1 つの呼び出しの中で「on-device が利用可能ならそこで実行、不可ならクラウドに自動 fallback」を実現する設計。 Firebase AI logic が提供。開発者は「on-device か cloud か」の判断を毎回コードで書く必要がなく、デバイス能力に応じて自動的に経路が選ばれる。
AI Edge Gallery: Google が提供する、オンデバイス AI の可能性を示す showcase アプリ。 AI Core をバックエンドにすることも、 custom models を使うこともできる。 frontier の実証用途 — production 用途の開発者には、より高レベルの抽象化を持つ AI Core 経由のルートが推奨される。
embedding API (coming soon): ML Kit Gen AI APIs に追加予定の embedding 機能。 Gemma embedding model を直接利用可能にする想定。これにより、オンデバイス完結の RAG パイプライン (text vector 化 → 類似度検索 → prompt 注入) が Android で組めるようになる。公開時期は本 AMA 時点で未確定。
on-device inference: 推論をデバイス内で完結させる方式。機微データの非送信、オフライン動作、追加課金無し、低 latency が利点。一方でモデルサイズが端末ストレージや RAM の制約を受ける。 Gemini Nano の場合は flagship 級デバイス限定。