【2026年最新】オンデバイスAI（エッジ推論）×論文4選｜「スマホや端末の中でLLMは使い物になるのか」を解く

【2026年最新】オンデバイスAI（エッジ推論）×論文4選｜「スマホや端末の中でLLMは使い物になるのか」を解く AIニュース
2026.09.29

クラウドにデータを送らず、スマートフォンやPCなどの端末の中でLLMを動かす「オンデバイスAI」への期待が高まっています。個人情報を外に出さずに済み、通信が不安定な場所でも使え、クラウドの利用料も抑えられる、というのが主な理由です。

しかし現場では、「実機で動かしてみたら遅すぎる」「バッテリーがもたない」「小さく圧縮したモデルは安全面で大丈夫なのか」といった疑問が次々に出てきます。カタログ上の「動く」と業務で「使える」は別物です。

この記事では、各社の公式ドキュメントをもとにクラウドとの使い分けと端末に載せる手段を整理し、端末でLLMを動かしたときの速さ・電池・安全性を実機で調べた論文4本を紹介します。結論を先に言うと、どこで動かすかは「何を守りたいか」で決め、速さと電池は自分の端末で測り、圧縮したモデルには安全装置を付けるのが基本です！

オンデバイス推論とは：クラウドとの使い分け

端末の中だけで答えを出す

オンデバイス推論とは、学習済みのモデルを端末に入れ、端末の計算資源だけで答えを出すことです。Apple の Core ML の説明では、モデルを端末だけで動かせばネットワーク接続が要らず、利用者のデータを手元に置いたまま、アプリの応答も速く保てるとしています（Apple「Core ML」）。Google の LiteRT も、スマホやPC、IoT機器の中だけで推論する実行環境です（Google「Getting started with LiteRT」）。

遅延・通信・プライバシー・コストで比べる

Android の公式ドキュメントは、端末で動かせばネットワークの遅延は消えるものの、推論の速さは端末のハードウェアしだいになるとしたうえで、機密データを端末に置いたままにでき、オフラインでも動き、推論の費用も減らせると説明しています（Android Developers「Gemini Nano」）。ML Kit の説明でも、呼び出しごとのサーバー費用がかからない点を利点に挙げています（Google「Overview of the ML Kit GenAI APIs」）。

観点端末で動かすクラウドで動かす
遅延通信の往復はないが、速さは端末の性能しだい通信の往復はあるが、強力なサーバーで処理
通信圏外でも動く接続が前提
プライバシー推論のためにデータを送らずに済む推論のたびにデータを事業者に送る
コスト呼び出しごとの利用料がない呼び出しごとに課金

ただし、端末のモデルは万能ではありません。Apple は Foundation Models の説明で、端末上のモデルは要約や情報の抜き出し、文章の手直しなどが得意で、より高度な推論や長い文脈が必要なときは同社のクラウド（Private Cloud Compute）や外部のサーバーのモデルを使うよう案内しています（Apple「Foundation Models」）。軽い処理は端末、重い処理はクラウドという使い分けが、公式にも前提になっているわけです。

端末に載せるための手段と実行環境

小さくする：量子化・蒸留・小型モデル

端末は計算力もメモリも限られるため、モデルを小さくする工夫が欠かせません。

  • 量子化: 数値を少ないビット数で表す方法です。LiteRT の説明では、学習後に8ビットへ量子化するとモデルはおよそ4分の1になり、CPUで2〜3倍以上速くなる場合がある一方、精度が落ちることもあるので必ず確かめるよう求めています（Google「Post-training quantization」）
  • 蒸留: 大きなモデル（教師）の出力で小さなモデル（生徒）を学習させる方法です。OpenAI は、特定の業務なら小さなモデルを大きなモデルに近づけられると説明しています（OpenAI「Supervised fine-tuning」）
  • 最初から小さいモデルを使う: 端末向けの小型モデルを選ぶ方法です。次の各社の実行環境には、こうしたモデルが組み込まれています

量子化で品質がどこまで保てるかは推論コスト削減の記事でも扱っています。

各社の公式ランタイム

提供元仕組み内容
AppleCore ML、Foundation ModelsCPU・GPU・Neural Engine を使って端末で推論。Apple Intelligence 対応機種では端末上の言語モデルを利用できる
GoogleLiteRT、LiteRT-LMAndroid・iOS・Web・PC・IoTで動く。LiteRT-LM は Gemma、Llama、Phi-4、Qwen などのLLMに対応
Google（Android）AICore、ML Kit GenAIOSに組み込まれた Gemini Nano を複数のアプリで共有。安全フィルタも内蔵
MicrosoftWindows AI APIs（Phi Silica）Copilot+ PC のNPUなどで動く端末上の言語モデル

（前掲の各社資料とGoogle「LiteRT-LM Overview」、Microsoft「Get started with Phi Silica」）

LiteRT-LM の公式ページ（2026年10月1日確認）に載っている Gemma 4 E2B（2.58GB）の速度表では、文章を生成する速さが、スマホ（S26 Ultra）のGPUで毎秒52トークン、Raspberry Pi 5 のCPUで毎秒8トークンと大きく違います。「使える速さで動くか」は、端末ごとに確かめるしかありません。

研究で見る「端末で動かしたときの実力」

📄 論文: スマホで意味のある答えが出たのは4モデル中1つ、応答には30秒超

Are We There Yet? A Measurement Study of Efficiency for LLM Applications on Mobile Devices（Xiao Yan ほか、2025年3月、arXiv:2504.00002）は、査読前の論文（プレプリント）です。

スマホのセンサーデータから利用者の居場所と動きをLLMに推定させる簡易アプリを作り、スマホ1台（Pixel 8、メモリ8GB）、クラウド上に用意したエッジサーバー（CPUのみ・GPU付きの2種類）、各社のクラウドAPIの3つの配置で、応答時間とメモリを比べた研究です。

この課題では、スマホに載せられたのは1B〜3Bの4モデルで、意味のある答えを返したのは Gemma2-2B の1つだけでした。7B以上のモデルはエッジサーバーでは常に妥当な答えを返しましたが、メモリが足りずスマホには載りません。同じ Llama3.2 でも、圧縮したスマホ版は答えられず、圧縮していない版はエッジサーバーで答えられたため、著者らは圧縮の危うさを指摘しています。応答時間は、意味のある答えが出たスマホで30秒超、クラウドAPIでは10秒未満でした。なお、クラウドの値には通信時間が含まれ、エッジサーバーの値には含まれていません。答えの正確さは体系的には測っておらず、手作業での確認にとどまります。

運営者にとっての意味は、「スマホで動いた」というデモで判断せず、業務の入力で答えの質と待ち時間を見るべきだということです。

📄 論文: どこが遅いのかを、端末の上で細かく測る

lm-Meter: Unveiling Runtime Inference Latency for On-Device Language Models（Haoxin Wang ほか、2025年10月、arXiv:2510.06126）は、SEC 2025（ACM/IEEE Symposium on Edge Computing）採録（abs のコメント欄と関連 DOI の記載）です。

端末上のLLMの処理時間を、入力を読み込む段階（プリフィル）や1トークンずつ文章を作る段階（デコード）などの段階ごと、さらにGPUの細かな計算単位ごとに、外部の機器なしで測るツールを作った研究です。Pixel 8 Pro などの実機で、既存ツールの値と照合して精度を確かめました。CPUを最低周波数に抑えた最も厳しい設定でも、計測による処理速度の低下は3%未満で、比べた既存の計測ツールよりはるかに小さく済みました。

このツールで調べたモデルと端末では、サーバーとは逆に、入力を読み込む段階が主な足かせになっていました。たとえば同じ系統のモデルを70Mから1.4Bパラメータに大きくすると、入力1トークンあたりの読み込み時間は158倍に延びた一方、出力1トークンあたりの生成時間は10倍の延びにとどまりました。4ビット量子化の効果も、モデルと課題によって違いました。

運営者にとっての意味は、遅さの原因を段階ごとに見ると打ち手が変わるということです。長い資料を毎回読ませる使い方は、端末ではとくに重くなります。

研究で見る「電池・環境負荷と安全性」

📄 論文: 端末で動かすほうが「エコ」とは限らない

The Battery Price of edge AI: A study of the Environmental Impact of LLM Inference on Mobile Devices（Édouard Guégain ほか、2026年7月、arXiv:2609.11940）は、査読前の論文（プレプリント。2026年10月1日時点で会議に投稿中）です。

Gemma 3・Llama 3.2・Qwen3 の1B〜4Bのモデルを2ビット・4ビット・6ビットに量子化した18通りを、Pixel 8 と iPhone 14 の実機、A100 GPU を積んだサーバーで動かし、1トークンあたりの消費電力と速さを測った研究です。サーバーは、1件ずつ順番に処理する場合と、100件をまとめて処理する場合の両方を測りました。正確さは4種類の試験問題（各200問）で、サーバー上だけで測っています。

抄録は、スマホはまとめて処理するサーバーより電力効率が平均で約3倍悪いとしています。ただし本文の表の平均削減率から換算すると、出力1トークンあたりのエネルギーは Pixel 8 で約2.9倍、iPhone 14 で約1.9倍と、機種で差があります。また、1件ずつ処理するサーバーと比べると、スマホのほうが効率は良くなりました。量子化はビット数を減らすほど省エネとは限らず、2台とも4ビットが最も省エネでした。さらに、電池の寿命と製造時の排出まで含めた著者らの試算では、スマホのほうがまとめて処理するサーバーより環境負荷が大きく、スマホで推論したときの負荷の84〜87%を端末の製造が占めていました（本文の結果。抄録では88〜90%）。

運営者にとっての意味は、「通信しないから省エネ」とは言い切れないということです。省エネな設定は対象の端末で測って決めます。

📄 論文: 圧縮した小型モデルには、端末の中で働く安全装置を

LiteLMGuard: Seamless and Lightweight On-Device Prompt Filtering for Safeguarding Small Language Models against Quantization-induced Risks and Vulnerabilities（Kalyan Nakka ほか、2025年5月投稿・2026年3月改訂、arXiv:2505.05619）は、査読前の論文（プレプリント）です。

7種類の量子化した小型モデルをスマホで動かし、有害な指示を集めた公開データ2種（計170件）をそのままの形と既知の脱獄手法2種で包んだ形で入力して安全性を、OnePlus 12・Pixel 8・Galaxy S21 の3機種で判定時間を測った研究です。

量子化した小型モデルは、特別な攻撃を受けなくても有害な質問に答えてしまうことがあります。実際、フィルタなしでは3つのモデルがそのままの指示にも80%を超えて答えました。そこでこの論文は、質問を渡す前に「答えてよい質問か」を判定する、端末内だけで動く軽量なフィルタを提案しました。判定には約1500万パラメータの小さなモデル（ELECTRA）を使っています。

フィルタを入れると、この2種のデータでの評価では、フィルタなしと比べた危険な応答の割合が平均で少なくとも87%減り（v3本文の値。抄録では85%超）、判定時間は平均約135ミリ秒でした。実運用で同じ効果が出る保証ではありません。

運営者にとっての意味は、公開モデルを量子化して載せるなら、安全面の確認と端末内の安全装置をセットで考えるということです。

現場でやること

端末とクラウドの役割を先に決める

扱う処理を「データを外に出せない」「圏外でも動かしたい」「高度な推論が必要」に分け、前の2つは端末、最後はクラウドを候補にします。医療や車載など各分野の事例は、医療・臨床現場のオンデバイスAIの記事と車載・運転支援のオンデバイスAIの記事で紹介しています。

速さは自分の端末と業務の入力で測る

  • 実際に使う端末（できれば性能の低い機種も含める）で測る
  • 業務で使う長さの入力で、最初の文字が出るまでの時間と、答え終わるまでの時間を分けて記録する
  • 答えの質も同じ入力で確かめる

電池と量子化の設定は測って選ぶ

量子化の候補の設定ごとに電池の減りと正確さを測って選びます。電池残量で軽いモデルに切り替える設計も一案です。

圧縮したモデルには安全装置を付ける

公開モデルを量子化して載せる場合は、有害な質問への応答を量子化の前後で比べます。そのうえで、質問を判定するフィルタを端末内に置き、判定にかかる時間も含めて応答時間を見積もります。

オンデバイスAI導入の鍵は次の3点です

  1. どこで動かすかは「何を守りたいか」で決める
    データを外に出せない処理や圏外で使う処理は端末、高度な推論はクラウドと役割を分けます。
  2. 速さと電池は、自分の端末と業務の入力で測る
    機種や入力の長さで結果は大きく変わります。遅い段階まで分けて見ると打ち手を選べます。
  3. 圧縮したモデルには安全装置をセットで用意する
    量子化した小型モデルは有害な質問に答えてしまうことがあります。オフラインでも働くフィルタを組み合わせます。

まとめ：オンデバイスAIは「とりあえず端末へ」から「測って選ぶ」へ！

オンデバイスAIには、圏外でも動く、データを外に出さない、呼び出しごとの費用がかからないといった利点があり、各社が実行環境と小型モデルを用意しています。ただ今回の論文が示すように、スマホでは答えの質と待ち時間に限界があり、電池や環境負荷の面でも常に有利とは限らず、圧縮したモデルの安全性にも注意が必要です。

まずは使う端末で業務の質問を10件ほど動かし、待ち時間・電池の減り・答えの質を記録してみてください。端末に任せる処理と、クラウドに任せる処理の線引きが見えてきます！

参考文献

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、端末とサーバーの電力効率の比較条件と機種差、省エネになる量子化の設定、端末の製造が環境負荷に占める割合の記述の誤りを修正しました

タイトルとURLをコピーしました