クラウド不要で高速処理を実現するオンデバイスAIとは？

この記事のまとめ

オンデバイスAIは、スマートフォンやPCなどの端末そのものでAIモデルを動かす仕組みです。クラウドに頼らずに処理できるため、通信の遅れが少なく、個人情報を外に出さずに扱えます。この記事では、オンデバイスAIの特徴を次の観点で整理します。

クラウドAIとの違いと、注目が高まっている背景
端末内でAIが動く仕組みと、CPU・GPU・NPUの役割
プライバシーやコスト面でのメリットと、導入時の制約
スマートフォンやXR、医療などの実用例と選び方

オンデバイスAIの基礎知識

オンデバイスAIの定義

オンデバイスAIとは、スマートフォンやPC、ウェアラブル端末など、利用者の手元にある機器そのものでAIモデルを動かす方式のことです。

Metaは、オンデバイスAIを、速く、プライベートで、賢い体験を届けるための土台だと位置付けています。同社はこの仕組みを、自社アプリのさまざまな機能を支える柱として活用しています（参照*1）。

テキストを扱う用途では、1B〜3B程度のパラメータを持つ小さめの言語モデルが、モバイル端末で動かしやすい選択肢として広がっています（参照*2）。

私が日頃からChatGPTやClaudeをはじめとする生成AIを業務で使い続けてきた実感として、クラウド型の大規模モデルが担う領域と、端末側の小型モデルが担う領域は、性質がまったく異なります。大型モデルをクラウドで動かす方式とは別に、端末側で完結する軽量なAIを組み合わせる考え方が、オンデバイスAIの本質です。用途に合わせて、どの処理をどこで動かすかを選ぶ発想が前提になります。

クラウドAIとの違い

クラウドAIとオンデバイスAIの一番の違いは、AIモデルを動かす場所です。

Armは、クラウド中心のAIには通信の遅れ、費用、プライバシーの制約があると説明しています。Lumexは、こうした制約を避けるため、AIを端末側に持ち込み、速く、安全に、常に使える形にすることを狙いとしています（参照*3）。

SamsungはGalaxy AIを、端末側とクラウド側の両方で処理する機能群として説明しています。端末側で動く機能はモデル学習に利用者データを使わない一方、クラウドで動く機能は学習に利用される場合があると明記しています（参照*4）。

両者は対立するものではなく、処理内容やデータの性質によって使い分ける関係にあります。生成AIの導入支援をする中で感じるのは、「クラウドかオンデバイスか」という二択で考える人が多いことです。しかし実際には、機微な情報や即応性が求められる処理は端末側、大規模な処理はクラウド側に振り分けるハイブリッド設計が現実的です。

注目が高まる背景

オンデバイスAIが広く注目される背景には、企業側の見直しの動きがあります。

Omdiaが1,500人以上の企業の技術リーダーや実務者に行った調査では、多くの企業がクラウドや自社インフラを中心にAIを動かしてきた一方で、オンデバイスAIが有利になる場面を十分に評価できていないと指摘しています。セキュリティ要件、予測しづらい継続コスト、業務に見合ったインフラ選定の3点で、現状のあり方を問い直す企業が増えているとされています（参照*5）。

私が企業のAI導入相談を受ける中でも、同様の課題感を持つ担当者は少なくありません。クラウドAPIの従量課金が想定より膨らんだ、社内の機密データを外に出せないといった声は、規模を問わず出てきます。利用者側でも、リアルタイムの支援や個別化されたコンテンツを通信を待たずに使いたいという期待が強まっており（参照*3）、こうした需要の変化がオンデバイスAIへの関心を後押ししています。

どこで処理するかという設計判断が、コストとリスクの両面に直結する。企業のAI担当者にとって、これは今後ますます避けられない問いになっていくはずです。

オンデバイスAIの仕組みと処理の流れ

デバイス内で動くAIモデルの構造

端末の中でAIを動かすには、モデル本体と、それを実行する実行基盤（ランタイム）の組み合わせが必要になります。

PyTorchのExecuTorchは、軽量なランタイムを通じて、端末が持つCPU、AI専用の演算部（NPU）、信号処理向けの回路（DSP）といったハードウェアの力を引き出すことを狙いとしています。オンデバイスAIには、多様なハードウェア、限られた電力、通信が弱い環境、リアルタイム処理といった独自の課題があると整理しています（参照*6）。

大規模言語モデルを端末で動かす場合の課題としては、モデルサイズが端末のメモリに収まらない点、読み込みや推論に時間がかかる点、量子化が難しい点が挙げられます。対策として、事後の量子化やKVキャッシュの8ビット化、モデルを4つに分割する手法などが用いられます（参照*7）。

端末内でAIを動かすためには、モデルを軽くする工夫と、ハードウェアをうまく使う実行基盤の両輪が欠かせないと整理できます。開発者はこの2つを組み合わせて、限られたリソースの中に処理を収めていきます。

CPU・GPU・NPUの役割分担

オンデバイスAIでは、端末内の複数の演算装置が役割を分担して動きます。

ArmはScalable Matrix Extension 2（SME2）について、行列計算専用のユニットをCPUクラスタに組み込むことで、CPUを高性能なAIアクセラレータとして働かせる仕組みだと説明しています。生成AIで多く使われる行列計算では、最大で5倍速い推論が可能だとしています（参照*8）。

ExecuTorchとArm SME2を組み合わせた計測では、1つのCPUコア上で、8ビット整数（INT8）推論の遅延が556msから304msへと1.83倍に、16ビット浮動小数点（FP16）は1,163msから298msへと3.9倍に短縮されたと報告されています（参照*9）。

このように、CPU側にAI向けの機能を持たせる流れが進んでいます。GPUやNPUと合わせて、処理の内容に応じて最適な演算装置に処理を割り振ることで、限られた端末の中でも高い性能を引き出せる構造になっています。

軽量化を支える量子化技術

量子化とは、モデル内部の数値の精度をあえて下げて、サイズや必要メモリを減らす手法です。

Omdiaの資料では、精度を下げてもメモリ要件を減らせる一方、多くの推論用途では8ビット量子化が実質的に劣化のない選択肢と見なされていると整理しています。メモリが特に厳しい端末側の運用では、4ビット量子化も広く使われていると説明しています（参照*5）。

Llama 3を端末で動かす際には、事後量子化に加えて、KVキャッシュを8ビットに圧縮し、LMヘッド部分に別の量子化設定を使う混合精度の手法が用いられます（参照*7）。

量子化は、モデル全体を一律に軽くするだけの手法ではありません。部位ごとに精度を変えて、品質とサイズのバランスを取る設計が、オンデバイスAIの実装では前提になっています。

オンデバイスAIのメリットとデメリット

プライバシー保護と低遅延の強み

オンデバイスAIの大きな強みは、データを端末の外に出さずに処理できる点です。

Omdiaの調査では、企業がオンデバイスを使う理由の上位にセキュリティ要件が挙がっています。セキュリティ強化に関する87%という数字に加え、AIモデルの学習や調整に独自データを使う企業が99%にのぼると報告されています。この結果、通信リスクの排除や手続き上の負担軽減につながるとしています（参照*5）。

機微なデータが通信網を通らずに端末内にとどまる点が、プライバシー面での利点として研究者向けの整理でも挙げられています（参照*2）。私自身、生成AI事業を立ち上げて以来、企業から「顧客データや社内情報をクラウドに送ることへの懸念」を何度も聞いてきました。法務やコンプライアンス部門が絡む案件ほど、この懸念は大きく、導入を止める要因になりやすい。オンデバイスAIは、その障壁を下げる現実的な手段として機能します。

速さと守りを両立させたい業務に向いた仕組みであり、個人情報や社外秘のデータを扱う処理では、選択肢として検討する価値が高くなります。

コストと運用面での優位性

端末側で処理を完結できると、通信費やクラウド利用料の負担を抑えやすくなります。

Microsoft Edgeでは、オンデバイス向けのAPIを通じて、サイトや拡張機能からJavaScriptでAI機能を呼び出せる仕組みが提供されています。クラウドを使う場合と比べ、プライバシーの向上、通信への依存の低下、翻訳などのコスト削減につながると説明されています（参照*10）。

Omdiaは、企業が使うモデルの57%が100億パラメータ未満で、MacBook AirやエントリーモデルのMacBook Proなど、現行の端末で動かせる範囲に収まると指摘しています（参照*5）。つまり多くの企業は、すでに手元の端末で動く規模のモデルを使っているわけです。

使う頻度が高い処理ほど、端末側に寄せる経済的な合理性が出てきます。クラウドAPIの従量課金は、使えば使うほど積み上がります。日常的に繰り返す処理をオンデバイスへ移すことは、コスト管理の観点からも理にかなった判断です。

導入時の制約と課題

一方で、オンデバイスAIには端末側の性能に縛られる制約があります。

PyTorchの資料では、多様なハードウェア、電力、通信の弱さ、リアルタイム処理の要求といった条件が、オンデバイスAIならではの難しさとして挙げられています（参照*6）。大規模言語モデルの場合、モデルサイズが端末のメモリを超える、読み込みや推論に時間がかかる、量子化の設計が難しいといった具体的な課題もあります（参照*7）。

私が企業のAI導入を支援する中で痛感するのは、技術的な制約よりも「何をオンデバイスでやらせるか」を決める判断の難しさです。モデル選定や量子化の知識がなくても、業務側が目的と品質基準を定義できなければ、導入は実験で終わります。すべてを端末に寄せるのではなく、処理内容ごとに配置を選ぶ設計が現実的です。技術の問題である以前に、業務設計の問題だと考えています。

主要プラットフォームと実装フレームワーク

ExecuTorchによるPyTorchネイティブ実装

ExecuTorchは、PyTorchで作ったモデルを端末側でそのまま動かすためのオープンソースの推論エンジンです。

Metaは、ExecuTorchが従来必要だったモデル変換の手順をなくし、PyTorchから直接動かせる流れを実現したと説明しています。PyTorchの書き出し機能を使い、端末と開発環境の両方で動く形にすることで、配信前の検証も行いやすくなります（参照*1）。

プロジェクトはオープンソースで開発されており、Apple、Arm、Cadence、Intel、MediaTek、NXP Semiconductors、Qualcomm Technologies、Samsungといった企業が協力しています（参照*1）。

つまりExecuTorchは、単一の企業に依存しない開発体制を持つ推論基盤として整理できます。多様な端末に同じ流れで対応したい場合の選択肢になります。

Arm SME2とKleidiAIの高速化

Armは、AI向けの拡張命令とソフトウェア基盤を組み合わせて、端末側の処理速度を引き上げる取り組みを進めています。

SME2に対応したArm CPUクラスタでは、AI性能で最大5倍の向上、音声系ワークロードで4.7倍の低遅延、音声生成で2.8倍の高速化が示されています。Alipayやvivoとともに、利用者とのやり取りにおけるLLMの応答時間を40%短縮した事例も報告されており、SME2が生成AIのリアルタイム処理を後押ししていると説明されています（参照*3）。

ExecuTorchとSME2を組み合わせた測定では、モデルをPyTorchで定義し、ExecuTorchで書き出して実行し、CPU演算はXNNPACKに委ねる構成が使われています。1コア環境で、INT8推論が1.83倍、FP16推論が3.9倍高速化したと報告されています（参照*9）。

これらの数値は、CPU側の拡張とソフトウェアの最適化を組み合わせることで、既存の端末構成のままで生成AIの実用性を引き上げられることを示しています。ハードウェアとソフトウェアを一緒に設計する重要性がうかがえます。

iOSとAndroidの推論基盤

スマートフォン向けのオンデバイスAIは、プラットフォームごとの基盤モデルを軸に整えられています。

Appleは、第3世代のApple Foundation Models（AFM）として、端末側からサーバー側まで含む5つのモデル群を用意していると説明しています。端末側のモデルには、30億パラメータのAFM 3 Coreと、より高性能なAFM 3 Core Advancedが含まれています（参照*11）。

Android側では、MLPerf Mobile v6.0が、Llama 3.2 1B Instruct、Llama 3.2 3B Instruct、Llama 3.1 8B InstructをLLM向けベンチマークに採用しています。Qualcomm Snapdragon 8 Elite Gen 5では、Llama 3.1 8B InstructのNPU実行にも対応しています（参照*12）。

iOSとAndroidのどちらも、端末側で動くLLMを前提とした基盤づくりが進んでいます。開発者は、対応モデルとハードウェアの組み合わせから、実装先を選ぶ形になります。

実用化が進むユースケース

スマートフォンとウェアラブル

スマートフォンとウェアラブル端末は、オンデバイスAIが最も身近に使われる領域です。

iOS 27の最も高性能なオンデバイスモデルを動かすには、iPhone 17 ProまたはiPhone Air、M4以降で12GB以上のメモリを搭載したiPad、M3以降で12GB以上のメモリを搭載したMacが必要だとされています。以前のApple Intelligenceが最低8GBだったのに対し、新しい高性能モデルは12GBが前提になったと説明されています（参照*13）。

Metaは、Ray-Ban MetaとMeta Ray-Ban Displayグラス上で、リアルタイム翻訳や視覚的なキャプション表示といった機能を動かしています。加えて、周囲の文字をその場で読み取るtext-in-the-wildと呼ばれる機能を、端末側のOCR（光学式文字認識）によって実現しています（参照*1）。

こうした事例は、AIが端末側で常時動く前提の設計へと移っている流れを示しています。搭載メモリや対応チップの違いが、使える機能の幅に直結します。

XRグラスとVRヘッドセット

XRグラスやVRヘッドセットのように、身につけて使う端末でもオンデバイスAIの活用が進んでいます。

Metaは、ExecuTorchを使うことで、Meta Quest 3およびQuest 3S上で、深度推定やシーン理解といった高度なAIワークロードを端末側で直接動かせるようにしたと説明しています（参照*1）。

Ray-Ban MetaやMeta Ray-Ban Displayグラスでは、リアルタイム翻訳や視覚キャプションといった機能が、端末側の処理によって提供されていると報告されています（参照*1）。

XR領域では、視界に映るものへの即時反応が体験の質を左右します。通信の遅れを避けるという意味でも、オンデバイスAIとの相性が良い分野だと言えます。

エンタープライズと医療分野

業務用途や医療分野でも、オンデバイスAIの活用事例が増えています。

NVIDIAは、RTX Sparkについて、1ペタフロップスのAI性能と最大128GBの統合メモリを備えた、個人向けAIエージェント用途を想定した基盤だと説明しています（参照*14）。

医療分野では、皮膚病変を良性と悪性に分類するSkinGuardianの研究が報告されています。ISIC 2019データセットでAUROC 0.956、SIIM-ISIC 2020設定でAUROC 0.927を達成し、端末側の推論はINT8で95パーセンタイル遅延が160ms以下とされています（参照*15）。医療のように患者データの外部送信が倫理的・法的に制約される領域では、オンデバイスAIの意義は特に大きいと言えます。

Microsoft EdgeのLanguage DetectorとTranslator APIは、端末側の専用モデルによって145以上の言語に対応する翻訳と言語判定を提供しています（参照*10）。

機微な情報を扱う分野ほど、データを外に出さずに処理できる仕組みの価値は大きくなります。応答速度と情報管理の両立を求める場面で、オンデバイスAIは有力な選択肢になっています。

導入時の判断基準と注意点

モデルサイズとメモリ要件の見極め

オンデバイスAIを導入する際は、モデルサイズと端末のメモリ要件のバランスを最初に検討する必要があります。

Omdiaは、企業で使われるモデルの57%が100億パラメータ未満で、MacBook AirやエントリーモデルのMacBook Proでも動かせる範囲に収まると整理しています。一方、オンデバイス中心の企業では、1,000億パラメータを超えるモデルを扱う割合が、そうでない企業の約2倍にのぼると報告しています（参照*5）。

iOSの最上位のオンデバイスモデルでは、12GB以上のメモリを持つ端末が前提となるなど、機能ごとに要件が細かく決まっています（参照*13）。

この2つの情報からは、対象となる利用者の端末構成と、想定するモデルサイズの両方をあわせて確認する必要があると読み取れます。導入前に、想定端末で動くモデル規模の上限を整理しておくと判断がしやすくなります。

性能ベンチマークの活用

導入判断では、公開されている性能ベンチマークを手がかりにする方法があります。

MLCommonsは、MLPerf MobileをGoogle Play Storeで初めて公開し、実際のAIや機械学習の処理を端末上で計測できる無料のアプリとして提供しています。アプリは端末側のハードウェアアクセラレーションを使い、Android向けにTensorFlow Liteのdelegate fallbackで最適化されていると説明しています（参照*16）。

MLPerf Mobile v6.0では、Llama 3.2 1B Instruct、Llama 3.2 3B Instruct、Llama 3.1 8B InstructがLLM向けの新しいベンチマークに採用され、Qualcomm Snapdragon 8 Elite Gen 5ではLlama 3.1 8B InstructのNPU実行にも対応しました（参照*12）。

こうした共通の指標を使うと、モデルとハードウェアの組み合わせを揃えたうえで、実際の処理性能を比べやすくなります。導入検討の初期段階で、条件をそろえた比較を行う土台として役立ちます。

おわりに

オンデバイスAIは、通信を介さずに端末側でAIを動かすことで、プライバシー、遅延、コストの3つの観点でクラウドAIとは異なる価値を持ちます。ExecuTorchやArm SME2、iOSとAndroidの基盤モデル、量子化などの技術が組み合わさり、実用に耐える性能が現実の端末で得られる段階に入っています。

導入を検討するときに重要なのは、技術選定より先に「何をオンデバイスでやらせるか」を決めることです。扱うデータの性質、対象端末のメモリと演算性能、処理の頻度とコスト構造を突き合わせて考える必要があります。MLPerf Mobileのような共通指標を使い、想定する利用シーンに近い条件で比較してから、端末側とクラウド側の役割分担を設計する順序が現実的です。

「クラウドかオンデバイスか」という二択ではなく、業務の工程ごとに最適な処理場所を選ぶ発想が、これからのAI導入設計の基本になっていくはずです。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、82万部（2025年3月時点）を売り上げる。
（”2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））