LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

オンデバイス生成AIとアプリ組み込みの全体像

アプリ オンデバイス生成AI 組み込みとは、端末内で生成AIモデルを直接動作させ、クラウドサーバーに問い合わせずにテキスト生成・要約等の機能をアプリに実装する開発手法である^*1。

Appleは2025年のWWDCでFoundation Models frameworkを発表しました。Apple Intelligenceの中核をなすオンデバイス言語モデルへの直接アクセスをアプリ開発者に開放する仕組みです^*1。GoogleもML Kit GenAI APIsを通じて仕組みを提供しています。AICore（オンデバイスAI実行を担うシステムサービス）上でGemini Nanoを動かす方式です^*2。

この組み込みが注目される背景には、モバイルアプリ開発全体でAI活用が加速しているという流れがあります。すでにクラウド型の生成AI機能をアプリに実装した企業もありますが、通信環境や応答速度、利用料金の制約に直面する場面があります。オンデバイス生成AIは、この制約に対する解決策の一つとして位置づけられます。

Foundation ModelsとGemini Nano — 2大OSの実装基盤

iOSとAndroidでは、それぞれ異なる仕組みでオンデバイス生成AIへのアクセスを提供しています。以下ではOS別の基盤技術を確認し、実装時に踏まえるべき前提条件を整理します。

iOS：Foundation Models frameworkとApple Intelligence

Foundation Models frameworkは、Apple Intelligenceの中核をなす言語基盤モデルです。パラメータ規模は約30億で、Swiftのコードから直接アクセスできる仕組みになっています^*1。要約・情報抽出・文章のリファインメント・短い対話文生成・創作的なコンテンツ生成といったテキストタスクに強みを持ちます。一方、一般的な世界知識に答えるチャットボット用途を想定した設計ではありません^*1。

開発者は「@Generable」というSwiftのマクロを構造体・列举型に付与することで、モデルの出力をあらかじめ定義した型に沿った形で受け取れます。この仕組みは「ガイド付き生成」と呼ばれます^*1。サーバー費用が発生せず、数行のコードでテキスト抽出や要約機能をアプリに追加できる点も特徴です^*1。

Android：AICoreとGemini Nano、ML Kit GenAI APIs

Android側では、Gemini Nano（Googleがオンデバイス向けに設計した基盤モデル）が特定のシステムサービス上で動作します。このサービスはAICoreと呼ばれます^*2。ML Kit GenAI APIsはこのAICoreの上位に構築されています。プロンプト生成・要約・文章校正・文章のリライト・画像の説明文生成・音声認識といった機能を、扱いやすい高レベルインターフェースで提供します^*2。

AICoreはPrivate Compute Core（Googleが定めるプライバシー保護の設計原則）に準拠しています。パッケージバインディングを制限したうえで、リクエストごとにデータを隔離し、処理後の入出力を保持しない設計です^*2。稼働対象はMediaTek Dimensity・Qualcomm Snapdragon・Google Tensorの各プラットフォームを搭載した端末に限られます^*2。

両OSに共通するのは、モデルの実行主体がOSベンダー側のシステムサービスであり、アプリ開発者はAPIを呼び出す立場にとどまる点です。したがって組み込みの実装難易度は、モデルそのものの開発ではなく「対応環境の見極めと呼び出し設計」に集中することになります。

クラウドAPI型との違い — 比較表で見る4つの軸

アプリに生成AI機能を実装する方法は、オンデバイス型とクラウドAPI型の2つに大別されます。どちらを選ぶかは要件によって変わるため、まず両者の違いを整理します。

この表からわかるように、オンデバイス生成AIはプライバシー・オフライン動作・コストの面で優位性を持ちますが、対応範囲の広さではクラウドAPI型に及びません。実装するアプリの用途に応じて、どちらの特性を優先するかを最初に決める必要があります。

オフライン動作とAPI費用ゼロ — 組み込みで得られる利点

オンデバイス生成AIをアプリに組み込む中心的な動機は、クラウド型では実現しにくい特性を得られる点にあります。ここでは代表的な3つの利点を確認します。

プライバシー — データを外部に送らない設計

AICoreはリクエストごとにデータを隔離し、処理後に入出力を保持しない設計です^*2。医療・金融・社内文書のように機密性の高い情報を扱うアプリでは、データを端末外に出さないという特性が導入判断の決め手になりやすいでしょう。

オフライン動作とレイテンシ — 通信品質に依存しない体験

ネットワーク接続なしにローカルで処理が完結するため、通信環境が不安定な状況でも機能を利用できます^*2。ネットワーク遅延が発生しない分、応答速度の面でも有利に働くと考えられます^*2。工場・店舗・移動中など、通信が不安定な現場作業を想定したアプリでは、この特性が実用性を大きく左右します。

コスト — 推論のAPI利用料が発生しない

Foundation Models frameworkでは、サーバー費用が発生せず数行のコードでAI機能を追加できる点が特徴として挙げられています^*1。利用者数やリクエスト数が増えても推論コストが比例して増加しないため、大規模なユーザーベースを持つアプリほど費用面のメリットが大きくなるでしょう。

モデルサイズと対応端末限定 — 組み込みで直面する制約

利点の裏側には、無視できない制約も存在します。組み込みを検討する段階で、以下の制約を前提に要件を設計する必要があります。

モデルサイズと処理能力の上限

Appleのオンデバイス言語基盤モデルは約30億パラメータの規模で構成されています。要約や情報抽出といった特定タスクに強みを持つ一方、一般的な世界知識を要する用途には向かないと説明されています^*1。クラウド型の大規模モデルと同水準の汎用性を期待すると、要件と実力にギャップが生じる恐れがあります。

対応OS・対応端末の限定

Gemini NanoベースのML Kit GenAI APIsは、特定のチップセットを搭載した端末でのみ動作します。対象はMediaTek Dimensity・Qualcomm Snapdragon・Google Tensorです^*2。iOS側のFoundation Models frameworkも、Apple Intelligenceに対応する機種・OSバージョンが前提となります^*1。つまり組み込んだ機能が全ユーザーの端末で動作するとは限りません。対応外の端末をどう扱うかという設計課題が常に発生します。

対応端末判定・モデル配布・フォールバック — 実装の3つの難所

上記の制約を踏まえると、実装工程では次の3つが技術的な難所になります。内製で対応する場合、いずれも相応の検証工数を要する領域です。

対応端末・OSバージョンの判定ロジック

組み込み前に、ユーザーの端末がオンデバイス生成AI機能に対応しているかを実行時に正確に判定する仕組みが必要です。OSバージョン・チップセット・Apple Intelligenceの有効化状態など、複数の条件を組み合わせて判定するロジックを実装しなければなりません。判定漏れによるクラッシュを防ぐ検証も欠かせません。

モデルのダウンロード・配布管理

オンデバイスモデルは端末に事前搭載されているとは限らず、初回利用時にダウンロードが発生する場合があります。ダウンロード中のユーザー体験（進行表示・失敗時の再試行）や、モデルの更新タイミングをどう扱うかも設計対象です。

非対応端末へのフォールバック設計

対応外の端末では、機能自体を非表示にするか、クラウドAPI型の代替処理に切り替えるかを選択する必要があります。フォールバック処理を用意しないと、対応端末とそれ以外で提供価値に差が生まれ、レビュー評価やサポート対応の負荷に直結しかねません。

これらの実装を誤ると、特定端末でのみ機能が動作しない、あるいは想定外のエラーでアプリ全体が不安定になるといった不具合につながります。リリース後に発覚すれば、ストアでの評価低下や再開発の手戻りという形でコストが跳ね返ってきます。

要件整理から性能検証まで — 組み込みの進め方

実際に組み込みを進める場合、次の順序で検討すると要件の抜け漏れを防ぎやすくなります。

1. 対象機能の選定：要約・文章校正・画像説明生成など、オンデバイスモデルの得意領域に合う機能を選びます。
2. 対応環境の確認：ターゲットユーザーの端末・OSバージョン分布を踏まえ、対応端末カバー率を見積もります。
3. API・SDKの実装：Foundation Models frameworkまたはML Kit GenAI APIsを組み込み、判定ロジックと合わせて動作させます。
4. 実機での性能検証：対応端末の実機で応答速度・生成品質・電池消費への影響を確認します。
5. フォールバック運用の確立：非対応端末向けの代替導線を用意し、リリース後も継続的に動作確認します。

この工程を一通り実施するには、モバイルOSのプラットフォーム知識とAI機能特有の検証観点の両方が求められます。工程数自体は多くありませんが、各工程で必要な専門知識の幅が広いという点が、この開発領域の特徴です^*3。

内製が難しい理由と外注によるリスク最小化

ここまで見てきた実装難所は、いずれも一時的な学習で解決しにくい領域です。内製で対応する場合に必要な知識・工数を整理し、外注によって得られる価値を確認します。

内製に必要なスキルと工数

対応端末判定・モデル配布・フォールバック設計を内製で行うには、iOS/AndroidそれぞれのプラットフォームAPIへの理解が欠かせません。加えて、生成AI機能特有の性能検証ノウハウも求められます。既存のモバイルエンジニアがこの領域を独学で習得しようとすると、検証環境の構築や実機テストに相応の時間がかかるでしょう。

専門家に依頼した場合との差分

専門知見を持つ外部パートナーに依頼する場合、対応端末の切り分けやフォールバック設計のパターンをすでに把握していると考えられます。そのため要件定義から実装・検証までの見通しを立てやすくなるでしょう。内製で進める場合はこの知見をゼロから積み上げる必要があり、検証不足のまま本番リリースに進むリスクが相対的に高まります。

リスクを抑えるための外注という選択

外注は「自社では難しいから任せる」というだけの選択ではありません。対応端末の見落としやフォールバック未実装による不具合を未然に防ぎ、リリース後の手戻りコストを抑える手段として位置づけられます。LASSICでは、モバイルアプリ開発とAI機能実装の両方の知見を組み合わせ、要件定義から実機検証までを支援する体制を整えています。

まとめ：オンデバイス生成AI組み込みの3つの判断軸

本稿では、アプリへのオンデバイス生成AI組み込みについて、仕組み・クラウドAPI型との違い・実装課題を整理しました。要点を3つに集約すると次の通りです。第一に、Foundation Models frameworkとGemini Nanoは、いずれもプライバシー・オフライン動作・コストの面で優位性を持ちます。一方でモデルサイズと対応端末には制約があります。第二に、実装では対応端末判定・モデル配布・フォールバック設計という3つの難所を丁寧に検証する必要があります。第三に、この検証を内製で完結させるには専門知識と工数の両面でハードルがあり、外注によってリスクを抑える選択肢が有効です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple Developer「Foundation Models」（2025年）https://developer.apple.com/documentation/FoundationModels／Apple Newsroom「Apple’s Foundation Models framework unlocks new intelligent app experiences」（2025年）https://www.apple.com/newsroom/2025/09/apples-foundation-models-framework-unlocks-new-intelligent-app-experiences/
2. *2　出典：Android Developers「Gemini Nano」（2025年）https://developer.android.com/ai/gemini-nano／Android Developers Blog「On-device GenAI APIs as part of ML Kit help you easily build with Gemini Nano」（2025年5月）https://android-developers.googleblog.com/2025/05/on-device-gen-ai-apis-ml-kit-gemini-nano.html

Tweet