オンデバイスAIは機能ではなく作業で選ぶ
Apple・Googleのドキュメントに記された上限と、継続負荷の実測が判断基準です
ビジネスAppleが判断の順序を開発者向けドキュメントに記している
Appleの開発者向けドキュメントには、オンデバイスモデルとサーバーモデルのどちらを使うかを決める順序が記されています。まず端末内で動くモデルで実装し、評価ツールで品質を確認したうえで、推論能力やコンテキストウィンドウ1が足りないと判断された場合にのみサーバーに送る、という順序です。
この記述が置かれている位置を見ると、端末で処理するかどうかを製品全体でまとめて一度に決めろという話ではありません。機能をひとつ実際に作ってみて測った結果で決めろと、ベンダー側がまず言っているのです。つまり判断の単位はサービスではなく、作業だということです。
同じコード、異なる上限
Appleが同じドキュメントに添えている比較表は5行です。両モデルとも個人情報は保護され、オフライン動作は端末側のみ可能で、使用量は端末側が無制限、サーバー側が1日あたりの上限付きです。複数段階で考える推論モードはサーバーでのみ動作し、一度に入力できるトークン数は4Kと32Kで8倍の差があります。
| 項目 | 端末内モデル | サーバーモデル（Private Cloud Compute） |
|---|---|---|
| オフライン動作 | 可能 | 不可能 |
| 使用量制限 | なし | ユーザーあたり1日の上限 |
| 推論モード | なし | 3段階対応 |
| コンテキスト | 4Kトークン | 32Kトークン |
セッションを作成する際にモデルオブジェクトを1行変えるだけで、同じプロンプトがサーバーに送られます。ツールも指示文もそのまま引き継がれます。そのため開発チームが実際に答えるべき問いは「オンデバイスを使うか」ではなく、「この作業は4K以内で完結するか、複数段階で判断する必要があるか、機内でも動作する必要があるか」に絞られます。
Androidも構造は似ています。GoogleはML Kit GenAIというまとまりで、要約、文章校正、文体変換、画像説明、音声認識、自由プロンプトを提供しており、これらの機能はAICore2が管理する共有のGemini Nanoの上で動作します。Googleがドキュメントに記している利点は3つです。入力・推論・出力が端末内で処理されること、インターネットが不安定でも機能がそのまま動作すること、呼び出しごとに発生するサーバー費用がないことです。
文書の下のほうには上限が書いてある
同じGoogleドキュメントを最後までスクロールすると、話が変わってきます。
GenAI APIの推論は、アプリが画面の最前面にあるときだけ許可されます。フォアグラウンドサービスを使っても弾かれ、BACKGROUND_USE_BLOCKEDエラーが返ってきます。夜間に溜まった通知をバックグラウンドで要約しておくという設計は、この一行で終わりです。
アプリごとに推論クォータも設定されています。短時間にリクエストを詰め込むとErrorCode.BUSYが出て、1日単位の長時間使用の上限を超えるとバッテリー使用量超過エラーが別に出ます。デバイス上で動かしているからといって無制限というわけではなく、請求書の中身がバッテリーとクォータに置き換わるということなのです。
対応デバイスのリストも確認が必要です。2026年9月10日時点の文書に記載されている対応デバイスは、Pixel 9〜11シリーズ、Galaxy S25・S26とその折りたたみ型、その他各社のフラッグシップ機です。中低価格帯のモデルはリストに入っていません。しかも搭載されているGemini Nanoのバージョンは機種ごとにnano-v2、v3、v4と分かれており、Googleは同じプロンプトでもバージョンによって異なる出力になり得るため事前に評価するよう案内しています。韓国語を含む言語サポートも、デバイスの設定とダウンロード済みモデルによって変わり得ると書かれています。
ブラウザのほうは、条件の線引きがより明確です。Chrome内蔵AIを使うには、Chromeのプロファイルがあるボリュームに22GB以上の空き容量が必要で、VRAM 4GB超のGPU、またはRAM 16GBかつ4コア以上のCPUという条件も課されます。初回のモデルダウンロードには従量制でない接続が必要で、ダウンロード後に残り容量が10GBを下回るとモデルは削除されます。AndroidとiOSのChromeはまだ対応しておらず、Chrome 149時点の文書が入出力言語として挙げているのは英語、スペイン語、日本語、ドイツ語、フランス語です。韓国語はそのリストに入っていません。
韓国のサービスであれば、この時点で計算が一度狂います。ウェブでオンデバイス処理を基本の経路に据えた瞬間、その機能を試せるユーザーが何パーセントいるのかを、まず数え直さなければならないからです。
ピークではなく平坦化した後を測るべき
性能比較はさらに条件が厳しくなります。2026年3月に公開され、6月に改訂された実測論文が参考になります。4ビットに圧縮したQwen 2.5 1.5Bを1つ、4種類の機器に載せて、258トークンの同一プロンプトを1秒間隔で20回連続して投げながら、速度と温度を記録した研究です。
iPhone 16 Proは最初の2回で毎秒40.49トークンまで出たものの、3回目の繰り返しから温度状態が上がり、17回目以降は毎秒23.67トークンで平坦化しました。ピーク比で41.5%低い値です。Galaxy S24 Ultraは毎秒12.21トークンから10.38トークンへ15%落ちましたが、この緩やかな曲線は画面を消してコンテキストを2,048トークンに固定し、プリフィル3の断片を128トークンに縮小した状態でのみ得られたものです。論文の著者らは、この数値がアプリ開発者の初期設定から得られる動作ではないと自ら明記しています。
ここから、プロダクトチームが持ち帰るべき基準が1つ見えてきます。連続してリクエストが入る機能であれば、計算に入れるべき値はピークではなく平坦化した後の速度です。ベンチマーク映像や発表資料の数字は、たいてい最初の数回の値だからです。
チップの仕様から速度をそのまま推測するのも見当違いです。同じ研究で、40 TOPS4の専用NPUを搭載したボードは毎秒6.914トークンを出しました。答えを1文字ずつ生成するデコード区間が、計算量ではなくメモリ帯域幅に制約されるためです。一方でこのボードは2W未満で、20回を通して速度のばらつきがほとんどなく、発熱による性能低下も観測されませんでした。500トークンの回答に72秒かかるため対話型には使えませんが、ユーザーが待たない夜間の要約処理にはむしろ適した性質です。
電力の数値を扱う際にはもう一段の注意が必要です。この論文もトークンあたりのエネルギー値をプラットフォームごとに異なる方式で測定したと明言し、3つの数値を直接比較しないよう記しています。GPU単位で測った値と、機器全体で測った値、そして画面を消した状態でのバッテリーゲージから推定した値を並べても、比較は成立しません。
使わないと決めることも、一つの結論です
ここまで確認してきた条件を作業単位で整理すると、次のように分かれます。
| 作業の性質 | 端末で処理 | サーバーに送る |
|---|---|---|
| 入力の長さ | 短いメッセージ、画面一枚分 | 長い文書、蓄積された会話 |
| 判断の深さ | 分類、抽出、整形 | 複数段階で検討する問題 |
| 接続状態 | オフラインが要件のとき | 常時接続を前提にできるとき |
| 実行タイミング | ユーザーが画面を見ているとき | バックグラウンド、予約実行 |
| 頻度 | 断続的なリクエスト | 連続・大量処理 |
この表では、右に行くほど端末内処理の利点が薄れていきます。左側に該当する作業が自社のサービスに一つもないなら、結論は「まだ導入しない」ということになります。
導入する側を選んだとしても、コストが消えるわけではなく、居場所が移るだけです。モデルのバージョンが端末ごとに異なるため、バージョンごとに出力品質を評価しなければなりませんし、対応端末を持たないユーザーのためのサーバー経路も、どのみちもう一組作る必要があります。クォータを超えたときにユーザーに何を表示するかも設計しなければなりません。Appleは、1日の上限に近づいたときにアプリが状態を表示できるよう、わざわざAPIを開放しているほどです。
個人情報とコストに関する約束も、確認した範囲の中でしかできません。端末で処理するということは、その作業の入力が外部に出ないという意味であって、製品の他の経路まで一緒に安全になるという意味ではないからです。SamsungがGalaxy AIの設定で、データを端末で処理するかクラウドで処理するかをユーザーに選ばせているのも、二つの経路が同じ製品の中に並んで存在していることを前提にした設計です。
Oswarldの視点
私はオンデバイスAIにかなり肯定的なほうです。その楽観の根拠を今回資料で改めて確認してみると、期待していい部分と、今すぐ製品に使える部分は、同じ場所にはありませんでした。
期待していいのは方向性です。ベンダーが端末とサーバーを同じAPIの後ろに置き、一行で切り替えられるようにしたということは、この先この選択がアーキテクチャの決定ではなく、機能ごとの設定値に近いものになっていくというシグナルとして読めます。専用NPUが2W以下で20回とも揺らがなかったという記録も、今遅いのは原理の限界というより構成の限界であるという見方を裏づけています。
おわりに
オンデバイスAIを導入するかどうかは、技術の未来をどう見るかでは決まりません。自社サービスのどの作業が4Kの範囲内で終わるのか、ユーザーが画面を見ている最中に起きることなのか、対応端末を使っているユーザーが何パーセントなのかで決まります。この三つは、今あるベンダーの資料と公開されている実測データだけでも確認できます。
ただし、ここに書いた数字はある時点の資料と一回分の実測から出た値です。対応端末と言語のリストはアップデートのたびに変わりますし、実測はモデル一つ・プロンプト一つを使った結果です。自社サービスの実際の作業で改めて測り直す段階は、どのみち残っています。
💬 読者さんのサービスで、端末の中に移してみる価値がありそうな作業は何でしょうか。入力の長さと実行タイミングだけでも書いていただければ、一緒に検討します。
📨 AI機能の導入を検討している同僚がいたら、この記事の作業別比較表だけでも送ってあげてください。
参考資料と関連リンク
主要出典
- Apple Developer, “Adding server-side intelligence with Private Cloud Compute”, 2026. ··· 端末モデルとサーバーモデルの5つの違いと切り替えの順序をベンダー自身がまとめた文書です。
- Google for Developers, “Overview of the ML Kit GenAI APIs”, 2026年9月10日更新。 ··· 対応機能、対応端末一覧、アプリ別クォータ、フォアグラウンド制約が1ページにまとまっています。
- Chrome for Developers, “Get started with built-in AI”。 ··· ストレージ、GPU、通信環境、対応言語といった、ウェブ上での有効化率を左右する条件が書かれています。
- Tummalapalli, P. 他、“LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs Under Sustained Load”, arXiv:2603.23640, 2026. ··· ピーク性能と持続性能がどれだけ乖離するか、測定条件をどこまで開示すべきかを併せて示しています。
背景知識
- Apple Security Research, “Private Cloud Compute: A new frontier for AI privacy in the cloud”。 ··· サーバーに送られたリクエストをどう処理し、どう消去するのか、その設計根拠がまとめられています。
- サムスン電子、“Galaxy AI”。 ··· 端末処理とクラウド処理をユーザーが選べるようにした制御方式を確認できます。
関連する過去の号
📝 用語解説
각주
-
コンテキストウィンドウ：モデルが一度に受け取り処理できる入力と出力の総量です。4Kは約4,000トークンを意味し、長い文書をまるごと入れるにはこの値が大きくなければなりません。 ↩
-
AICore：Androidが端末内で生成モデルを実行し、配布・更新を管理するシステムサービスです。アプリごとにモデルを個別にダウンロードするのではなく、1つを共有して使えるようにしてくれます。 ↩
-
プリフィルとデコード：プリフィルは入力プロンプトを一度に読み込む区間、デコードは答えを1トークンずつ生成していく区間です。プリフィルは主に演算量に、デコードは主にメモリ帯域幅に律速されます。 ↩
-
TOPS：1秒間に処理できる演算回数を兆単位で示すチップの仕様です。理想条件下での最大値であるため、実際の応答速度をそのまま予測できるものではありません。 ↩
あなたの視点が次の号をつくります
この号で最も共感した点、あるいは違う経験をした点はどこですか。