2026.09.15 AI

オンデバイスAIとは？端末内で動くAIの仕組みと業務導入の判断基準【2026年版】

オンデバイスAIは、スマートフォンやPCの中だけでAIモデルの推論を終わらせる方式です。入力した文章も写真もネットワークへ出ていかないので、社外に出せないデータを扱う業務と相性がよく、通信の往復が無いぶん応答も返ってきます。ただし端末に載せられるモデルの規模には上限があり、Appleが公表している端末内モデルは約30億パラメータ、Chromeの内蔵AIには22GBの空き容量が必要です。この記事では、仕組みと必要な要件を数値で押さえたうえで、業務端末で任せてよい処理と精度が届かない処理、社内展開を見送るべき条件までを整理します。

まとめ：オンデバイスAIを業務端末へ入れてよい条件と見送る線引き

オンデバイスAIで成果が出るのは、要約・分類・翻訳・入力補助のように出力の形が決まっていて、実行回数が多く、扱うデータを社外へ出したくない業務です。この3条件のうち2つ以上に当てはまらない場合、クラウドのAPIを呼ぶ構成のままで足ります。端末内モデルはクラウド側の大規模モデルより小さく、社内文書の横断検索や長い資料の読解では精度が届きません。

導入の可否を分けるのは、端末の世代が揃っているかどうかです。Copilot+ PCの機能は40 TOPS超のNPUを前提に設計されており、社内に旧世代のPCが残っていると、同じ機能が一部の社員にしか届かない状態になります。まず対象業務を1つに絞り、既存のクラウドAIと同じ入力で出力を比べ、端末側の実効速度を自社のモデルで測る。ここまで済ませてから台数を増やす順序を守れるかどうかが、社内展開の成否を決めます。

端末内で推論が完結するオンデバイスAIの仕組みとクラウド送信型との境界

オンデバイスAIという言葉は、モデルの置き場所ではなく推論の実行場所を指しています。モデルの学習はデータセンター側で行い、できあがったモデルを縮めて端末へ配り、推論だけを端末の演算器で回す。この分業が全体像です。

端末のNPUが担う推論処理とCPU・GPUとの役割の分かれ方

端末側で推論を回すとき、実際に計算しているのはCPUだけではありません。行列演算を並列にこなす専用回路としてNPUが載っており、同じ処理をCPUで回すより消費電力あたりの処理量が大きくなります。Windowsの場合、OSが処理の内容を見てCPU・GPU・NPUのどこへ割り振るかを決める設計です。

ここで注意したいのが、NPUの性能値として示されるTOPSが理論値だという点です。実際の速度は、載せるモデルの構造・入力の大きさ・前処理の重さで変わります。NPUとは？CPU・GPUとの役割分担とTOPSの実効性能・採用判断で公称値と実測値の乖離を扱っているので、端末選定の段階ではそちらも合わせて確認してください。

30億パラメータ規模まで縮めたモデルを端末へ載せる量子化の役割

クラウドで動く大規模モデルをそのまま端末へ入れることはできません。メモリにも電力にも枠があるためです。そこで使われるのが、モデルの重みを低いビット数で表現し直す量子化という前処理になります。

Appleが2025年に公開したFoundation Modelsの技術報告では、端末側モデルは約30億パラメータ規模で、デコーダの重みを量子化認識学習（QAT）により1重みあたり2ビット、埋め込みを4ビット、KVキャッシュを8ビットへ落としたと説明されています。KVキャッシュのメモリ使用量は37.5%削減されたというのも、同報告にある記述です。Windows側でも事情は同じで、MicrosoftのCopilot+ PC開発者ガイドは、FP32で学習されたモデルをNPUで動かすにはINT8のような低ビット整数へ変換する必要があると明記しています。

エッジAI・ローカルLLMとオンデバイスAIが指す範囲の分かれ目

3つの言葉は重なりますが、指している範囲が違います。オンデバイスAIは、利用者が手に持つスマートフォンやPCの中で推論が完結する構成を指します。工場のカメラや検査装置のように、現場へ設置した機器の側で推論する構成はエッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準の領分です。

もう1つ紛らわしいのが、社内のサーバーや作業用PCへ大きめのモデルを置いて運用する構成で、こちらはローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順で扱っています。判断の軸は「推論するハードウェアを誰が持っているか」です。社員の端末ならオンデバイス、現場設備ならエッジ、社内の計算機ならローカルLLM。この区別を最初に決めておくと要件定義で話が噛み合います。

Apple・Google・Microsoftが公開している端末内AIの実装基盤と動作要件

端末内AIは3社がそれぞれ別の基盤を出しており、要求するハードウェアも提供形態も揃っていません。社内で使う端末がどの陣営かによって、できることが変わります。

Appleが公表する約30億パラメータと2ビット量子化の内部構成

Appleは端末内モデルを開発者へ開放しており、Foundation Models frameworkとしてSwiftのAPIから呼べる形になっています。同フレームワークはテキストと画像を組み合わせたマルチモーダルのプロンプトに対応し、端末内実行とPrivate Cloud Computeでの実行を切り替える設計です。

モデル側の仕様は技術報告に数値で出ています。端末内モデルは約30億パラメータ、扱えるのは最大65,000トークンの系列、対応言語は15言語という設計です。サーバー側モデルはParallel-Track Mixture-of-Experts構成で別物なので、「Apple Intelligenceで動く」と一括りにすると端末内処理とクラウド処理の区別が消えます。社外秘のデータを扱うなら、機能ごとにどちらで動くかの確認から始めてください。

Chrome内蔵Gemini Nanoに必要な22GBの空き容量と4GB超のVRAM

ブラウザ側にもモデルが入るようになりました。GoogleのChrome内蔵AIの開始ガイドが示す要件は具体的です。Windows 10/11・macOS 13以降・Linux・ChromeOS（Platform 16389.0.0以降のChromebook Plus）が対象で、少なくとも22GBの空きストレージ、4GBを超えるVRAMを持つGPU、CPU実行なら16GB以上のRAMと4コア以上を求めます。

見落としやすいのが削除条件です。モデルをダウンロードしたあとで空き容量が10GBを下回ると、モデルは端末から削除されます。社給PCのストレージが逼迫している職場では、機能が黙って止まる事態が起こりえます。Chromeでの有効化と呼び出し手順はGemini Nano（ジェミニナノ）とは？Chrome内蔵AIの性能・有効化・使い方で扱っているので、実装に入る段階ではそちらを参照してください。

Copilot+ PCの40 TOPS要件とWindows MLへ移った推論の経路

Microsoftは、40兆回毎秒（40 TOPS）を超える演算性能を持つNPUを搭載したWindows 11端末をCopilot+ PCと定義しています。同ガイドは対象機種としてSurface Laptop/Pro、HP OmniBook X 14、Dell Latitude 7455、Lenovo Yoga Slim 7xなどを挙げ、AMD Ryzen AI 300シリーズとIntel Core Ultra 200Vシリーズ搭載機も含まれると記載しています。

開発側の経路は2026年時点で切り替わりました。NPUへアクセスする推奨手段はDirectMLからWindows ML（WinML）へ移っており、実行プロバイダー（QualcommのQNN、IntelのOpenVINOなど）をWindowsが端末のハードウェアを見て自動で取得する方式です。優先した実行プロバイダーが使えなければGPUやCPUへ落ちます。自社アプリへ端末内推論を組み込むなら、どのハードウェアに落ちても業務が成立する応答時間かどうかを確かめておいてください。

業務端末でオンデバイスAIに任せられる処理と精度が届かない処理の線

端末内モデルは万能ではありません。任せられる処理の形はかなりはっきりしており、そこを外すと「使えない」という評価だけが社内に残ります。

要約・分類・入力補助といった端末内の小型モデルで完結する定型処理

ブラウザ側のAPIの提供状況が、任せられる処理の範囲をよく表しています。Chromeでは内蔵AIのAPI一覧のうち、Translator API・Language Detector API・Summarizer APIがChrome 138の安定版で利用でき、自由な指示を渡すPrompt APIはウェブ向けがChrome 148での提供です。翻訳・言語判定・要約という出力の形が決まっている処理から先に安定版へ入っている点に注目してください。

業務へ当てはめるなら、問い合わせメールの分類、議事メモの要点抽出、入力フォームの表記ゆれ補正、社内文書の翻訳あたりが該当します。いずれも入力が数百字から数千字に収まり、出力の正しさを人が数秒で判断できる処理です。迷ったら、出力を見た担当者が即座に正誤を言えるかどうかで切り分けてください。

社内文書の横断検索や長い文脈の推論でクラウド側モデルが要る理由

端末内モデルが苦手なのは、知識量と推論の深さを要求される処理です。約30億パラメータという規模は、数千億規模とされるクラウド側モデルとは桁が違います。社内規程を根拠付きで引用させる、複数の契約書を突き合わせて差分を出す、数値の根拠をたどって計算するといった処理では、誤りの混入率が業務で許容できる水準を超えます。

実務では、端末内で下処理をして判断が要る部分だけクラウドへ回す構成が現実的です。会議音声を端末内で文字起こしして個人名を伏せ、伏せた後の文章だけをクラウドの大規模モデルへ渡す。この形なら生データを社外へ出さずに精度も確保できます。線引きは扱うデータの機密区分で決まるので、要件定義の最初に決めてください。

65Kトークンという上限が業務文書の投入量に与える制約の現れ方

入力できる長さにも上限があります。Appleの端末内モデルは最大65,000トークンの系列を扱う設計です。日本語はおおむね1文字あたり1トークン前後を消費するため、目安としては数万字程度の文書が上限になります。100ページ規模の仕様書やマニュアルを丸ごと投入する使い方は成立しません。

回避策は、文書を章ごとに分けて渡し、章ごとの要約を積み上げる方式です。ただし分割した時点で章をまたぐ参照は追えません。「第3章の条件が第8章の例外規定で覆る」といった構造の文書では、分割要約の結果が実態とずれます。長い文書を扱う業務なら、検索と根拠提示はサーバー側に置く構成を先に検討したほうが早いです。

通信費とAPI課金が消える代わりに増える端末調達と配布の費用構造

費用の話は「クラウド利用料が浮く」で終わらせると判断を誤ります。消える費用と、代わりに現れる費用の両方を並べてください。

推論回数が増えるほど効いてくるAPI従量課金との損益の分かれ目

クラウドAPIの課金は入出力トークン量に比例するため、費用は実行回数に比例して増えます。対して端末内実行は、端末を調達してしまえば1回あたりの追加費用が発生しません。損益が入れ替わる分岐点は、対象業務の月間実行回数と1回あたりのトークン量で決まります。

見立て方は単純です。まず現行のクラウドAPIで1か月運用し、実際のトークン消費量と請求額を確定させる。次に端末の入れ替え費用を出し、何か月で回収できるかを見ます。回収に3年以上かかるなら端末の更新周期のほうが先に来るため、投資として成立しません。この計算を省いて「コスト削減」を目的に据えると、端末調達費のほうが大きい構成に着地しがちです。

データを端末の外へ出さない構成が監査の場面で説明しやすくなる理由

金額に表れない側の利点が、説明のしやすさです。入力データが端末から出ないなら、外部送信の有無という論点そのものが消えます。委託先の選定審査や情報セキュリティ監査で問われる「どこへ送信され、どこに保存され、学習に使われるか」の確認が不要になり、稟議の所要時間が短くなります。

ただし端末内で処理した事実を後から証明する手段は別途必要です。OSやブラウザの機能を使う場合、どのモデルがどの版で動いたかをアプリ側から記録できるとは限りません。監査で処理内容の再現を求められる業務では、この点を先に確認してください。

OS更新とモデル更新が連動する端末群で起きる版ずれとその備え方

端末内モデルの版は、こちらの都合で固定できないことがあります。OSやブラウザの更新に伴ってモデルが差し替わると、同じ入力に対する出力も変わるということです。Chromeのように空き容量が10GBを下回ればモデルが削除される仕様もあるため、端末ごとに「モデルがある状態」と「無い状態」が混在します。

備え方は2つです。1つは、モデルが使えないときにクラウド側へ切り替える経路をアプリに用意しておくこと。もう1つは、出力の形式をアプリ側で検証してから業務データへ反映することです。台数が増えたときの更新・故障交換・供給終了といった管理の負担はエッジAIのメリット・デメリット｜低遅延と引き換えに増える運用負荷の実際で扱っており、端末群を抱える構成では同じ論点が効いてきます。

オンデバイスAIを採用してよい条件と社内展開を見送る3つの場面

ここからは判断です。条件を満たさない状態で社内展開すると、一部の端末でしか動かない機能が残り、問い合わせ対応の負担だけが増えます。

採用の条件は端末世代が揃い処理が定型で回数の多い業務という3点

採用してよいのは、次の3つが同時に成立する場合です。対象の社員が使う端末の世代が揃っていて必要な演算性能を満たしていること。処理の出力形式が決まっていて正誤を人が即座に判断できること。実行回数が多く、クラウドAPIの従量課金が積み上がっていること。

3つのうち2つしか満たさない場合は、まだ端末内へ寄せる段階ではありません。特に「回数が多い」が欠けている業務では、端末の入れ替え費用を回収できず、クラウドAPIを呼ぶ構成のほうが安く終わります。この線引きは感覚ではなく、前章の回収期間の計算で決めてください。

見送る場面は端末世代の混在と精度検証の体制不足という2つの条件

社内のPCに40 TOPS未満の旧世代が残っている状態で展開すると、同じ機能が人によって動いたり動かなかったりします。情報システム部門への問い合わせは、動かない側の人数に比例して増えます。端末の更新計画と足並みを揃えられないなら、この段階では見送りの判断が正しいです。

もう1つが検証体制です。量子化したモデルは出力が変わります。変わった結果を業務として許せるかどうかを判断できるのは、現場の担当者だけです。評価用の入力を50件から100件用意し、業務が壊れる側の指標（見落とし・誤分類）で合格ラインを決める。引き受ける部署が決まっていないなら、精度が落ちても誰も気づけません。着手しないほうが安全です。

出力の根拠の保存と監査提出が必要な業務で端末内完結が向かない理由

出力の根拠を保存して後から提出する必要がある業務は、端末内完結に向きません。端末側で処理した内容はその端末にしか残らず、退職や故障で端末が手を離れれば記録も一緒に消えます。集約するなら結局サーバーへ送ることになり、データを外へ出さないという前提が崩れます。

該当するのは、与信判断、採用選考、医療行為の補助、金融商品の説明といった、判断の経緯を第三者へ示す義務がある業務です。端末内では下処理だけを行い、判断そのものはサーバー側で記録しながら実行する構成に寄せてください。端末内完結にこだわると、監査対応の段階で作り直しになります。

検証端末の選定から社内展開までオンデバイスAIを試す進め方の手順

最後に、判断材料を自分たちで作る手順を示します。カタログの数値だけで決めると、実機で動かした瞬間に前提が崩れます。

対象業務を1つに絞り既存のクラウドAIと同じ入力で比べる検証手順

最初にやるのは比較条件を揃えることです。対象業務を1つだけ選び、現在クラウドAPIへ渡している入力をそのまま端末内モデルへ渡して、出力を並べます。

対象業務を1つ選び、実際の入力データを50件から100件そろえる
同じ入力をクラウドAPIと端末内モデルの両方へ渡し、出力を保存する
業務側の担当者が、許容できる出力かどうかを1件ずつ判定する
合格率と、誤りが出たときの業務影響の大きさを記録する

ここで合格率が業務の許容ラインを下回るなら、端末側の性能を上げても解決しません。モデルの規模が足りていないので、クラウド側との分担を見直す段階へ戻ります。

段階配信とロールバックを用意してから台数を増やす社内展開の順序

検証を通ったあとも、一度に全社へ配らないでください。まず1部署、次に関連部署という順で広げ、各段階で問い合わせ件数と処理時間を記録します。端末の世代ごとに実効速度が違うので、対象が広がるほど遅い端末が混ざってくるためです。

同時に用意しておくのが、前の状態へ戻せる経路です。モデルが使えない端末ではクラウド側へ切り替える、あるいは機能そのものを無効化して従来の手作業へ戻す。この切り替えをアプリの設定で行えるようにしておくと、不具合のたびに端末を回収せずに済みます。端末内とクラウドのどちらへ寄せるかを含めて設計から相談したい場合は、生成AI開発・AI受託開発で要件定義から実装まで対応しています。

よくある質問

オンデバイスAIの検討でよく挙がる質問を、公式資料の数値をもとに整理しました。

オンデバイスAIとエッジAIは何が違うのですか？

推論を実行するハードウェアの持ち主が違います。オンデバイスAIが指すのは、社員が使うスマートフォンやPCの中で推論が完結する構成のことです。エッジAIは、工場のカメラや検査装置など現場へ設置した機器の側で推論する構成を指すことが多く、端末の台数や管理方法が変わります。技術としては同じ量子化やNPUを使うため、仕組みの説明は重なります。違いが出るのは調達・配布・更新の運用面です。

オンデバイスAIを使うために必要なPCのスペックはどれくらいですか？

必要なPCの要件は、使う基盤によってそれぞれ異なるものです。Chromeの内蔵AIは、少なくとも22GBの空きストレージ、4GBを超えるVRAMを持つGPU、CPUで動かす場合は16GB以上のRAMと4コア以上を求めます。ダウンロード後に空き容量が10GBを下回るとモデルは削除されます。WindowsのCopilot+ PC向け機能は40兆回毎秒（40 TOPS）を超えるNPUが前提です。社内の標準機がこれらを満たすかを、導入検討の最初に確認してください。

端末内のAIはクラウドのAIと同じ精度が出ますか？

同じではありません。Appleが公表している端末内モデルは約30億パラメータで、数千億規模とされるクラウド側モデルとは規模が違います。翻訳・要約・分類のように出力の形が決まっている処理では実用水準に達しますが、社内規程の根拠付き引用や複数文書の突き合わせでは誤りが増えます。量子化によって出力が変わる点も含め、導入前に自社データ50件から100件で比較してから判断してください。

オンデバイスAIにするとクラウドの利用料はどれくらい下がりますか？

金額は実行回数とトークン量で決まるため、一律には言えません。判断の手順としては、まず現行のクラウドAPIで1か月運用して請求額を確定させ、次に端末内実行へ移すために必要な端末入れ替え費用を出して、回収期間を計算します。回収に3年以上かかるようなら、端末の更新周期のほうが先に来るため投資として成立しません。実行回数が少ない業務では、クラウドAPIのままのほうが安く済みます。

社内の端末で使う場合、情報漏えいのリスクは無くなりますか？

外部送信に起因するリスクは減りますが、ゼロにはなりません。データが端末に残る以上、紛失・盗難・退職時の持ち出しという経路が残ります。どの機能が端末内で完結し、どの機能がクラウドへ出るかも基盤ごとに異なります。Appleの構成では端末内実行とPrivate Cloud Computeでの実行が切り替わるため、機能単位で処理場所を確認したうえで、端末の暗号化と遠隔消去を前提に運用してください。