ローカルLLMとオンデバイスAI：社用PC・スマホでできる業務と限界

2026年、ローカルLLMなどのオンデバイスAIを使えば、短い要約や下書きの推敲、音声処理を従業員の端末内で行えます。ただし、データを外部に送るかどうかを決めるのはアプリです。まずは対象を絞った業務から移行し、クラウドに処理を引き継ぐ場合は、その切り替えを明示してください。利用範囲を広げる前に、自社の文書で結果を確かめることが大切です。

業務を運用する立場で考えるべきなのは、仕事のどの部分をPCやスマートフォンの中で完結できるかです。全社の業務を横断して調査・推論・実行まで担うアシスタントを目指すより、現場担当者のメモを引き継ぎ用に要約する機能のほうが、導入の出発点として適しています。

2026年10月23日時点の各社の公式ドキュメントで確認済みです。 以下の業務別比較表は、公開されている機能と要件を整理・分析したもので、性能ベンチマークではありません。

オンデバイスAIとは？

オンデバイスAIは、端末自身のプロセッサでモデルを動かす仕組みです。 使用するのは中央処理装置（CPU）、画像処理装置（GPU）、または対応するAI演算向けに設計されたニューラル処理装置（NPU）です。モデルを動かして回答を生成する処理を「推論」と呼びます。NPUを使うには、それに対応したソフトウェアが必要です。NPUが搭載されているだけで、すべてのAIアプリが速くなるわけではありません。MicrosoftのNPU開発者ガイド

文書を別のオフィスに送り届ける代わりに、隣にいる翻訳者に訳してもらう場面を想像してください。ローカル推論は、このように手元で処理を済ませます。ただし、翻訳後の文書をメールで送れるのと同じように、アプリがコピーを別の場所に送ることはできます。

ローカルモデルの呼び出し自体では、データを端末の外へ出す必要はありません。それでも、そのモデルを使うアプリがプロンプトをアップロードしたり、文書を同期したり、オンラインのツールを呼び出したり、クラウドモデルを選んだりする可能性はあります。たとえばAppleのフレームワークでは、ローカルまたはオンラインのデータベースを検索するツールをモデルに与えられます。どこで処理するかと、アプリが何を外部に共有するかは、別々に判断する必要があります。 AppleのFoundation Modelsドキュメント

オフラインで機能を使うにも準備が必要です。モデルファイルをあらかじめ端末に保存し、ネットワークに接続しなくても入力データにアクセスできるようにしておかなければなりません。接続できない外部システムにしか存在しない文書は、ローカルモデルでは要約できません。

企業で使えるローカルLLM・オンデバイスAIには何がある？

まず業務に使えるソフトウェアを選び、その後にハードウェアの条件を確認します。 AppleとGoogleのフレームワークはアプリを作るための基盤であり、Windowsにはそのまま使える特定の機能があります。一方、デスクトップ向けのモデル実行ツールでは、従業員や開発者がモデルを自分で選べます。それぞれ導入の進め方が異なります。

Apple Foundation Models：自社アプリに用途を絞った機能を組み込む

AppleのFoundation Modelsフレームワークは、Appleのプログラミング言語であるSwiftで、モデルを利用した機能を開発するためのインターフェースです。オンデバイスモデルは、与えられた文章の要約、詳細情報の抽出、下書きの推敲などに対応しています。ガイド付き生成では、定義したSwiftのデータ構造で結果を返せます。文章ではなく、項目ごとの値をアプリで扱いたい場合に役立ちます。Appleのフレームワーク概要

プロダクト責任者にとって、技術者のメモを所定の項目に整理し、人が確認するための引き継ぎ資料に変換する機能は、現実的な選択肢です。アプリが元の情報を渡し、出力の形式を定めます。設備をどう修理すべきかまでモデルに判断させるより、はるかに範囲の限られた仕事です。

Appleの現行の生成ガイドは、オンデバイスモデルに任せるべきでない作業として、コード作成、基本的な計算、論理的推論などを挙げています。計算や検証には通常のアプリケーションコードを使い、重要な判断に関わる生成内容は評価してください。Appleによる機能と用途のガイダンス

フレームワークはiOS 26、iPadOS 26、macOS 26世代のOSから利用でき、より新しいAPIには個別の利用条件があります。ハードウェアはApple Intelligenceへの対応が必要で、対象にはiPhone 15 Pro、iPhone 16以降のモデル、M1以降のMacなどが含まれます。言語や地域、モデルのダウンロード状況も含め、実際に使うモデルが利用可能かを実行時に確認してください。フレームワークの利用条件、Appleのデバイス要件

実装では、オンデバイスモデルを明示的に指定してください。 このフレームワークは現在、Private Cloud Computeやその他のサーバープロバイダーにも対応しています。「Foundation Modelsを使っている」という説明だけでは、個々のリクエストがどこで実行されるのかは分かりません。Appleのモデル対応状況

GoogleのオンデバイスAI：AndroidとChrome

GoogleのGemini Nanoは、AndroidのシステムサービスであるAICoreで動くローカルモデルです。開発者はML Kitを通じて利用でき、要約、校正、書き換えなどのAPIが提供されています。現場業務向けアプリなら、担当者が入力したメモを短くまとめる機能が、試験導入の候補になります。GoogleのAndroid向け概要

対応端末はAPIとモデルのバージョンによって異なります。Googleの対応端末リストと利用可否の確認処理を使ってください。AndroidのバージョンやRAM容量だけでは、利用できるかどうかは判断できません。運用上の制約もあります。ML Kit GenAIの推論は、そのアプリが最前面のフォアグラウンドアプリである間だけ許可され、リクエスト数やバッテリー使用量にも上限があります。このため、バックグラウンドで文書を順次処理する無人運用の基盤には向きません。ML Kitの要件と制限

より柔軟なPrompt APIは、引き続きベータ版です。サービスレベル契約も廃止ポリシーもなく、Googleが互換性を損なう変更を行う可能性があります。従業員の業務に欠かせない機能として組み込む前に、この依存関係を評価してください。GoogleのPrompt APIの提供状況

Google Chromeでは、対応するデスクトップPCとノートPCで、ブラウザ組み込みAPIからGemini Nanoを使えます。Webサービスがすでに持っているテキストを、ローカルで要約する機能を提供できます。Summarizer APIはChromeの安定版で利用できますが、機能とモデルが利用可能かどうかの確認が必要です。ChromeのSummarizerドキュメント

CPUで実行する場合は、少なくとも16 GBのRAMと4つのCPUコアが必要です。GPUで実行する場合は、GPUのメモリであるVRAMが4 GBを超えていることが条件です。またGoogleは、Chromeのプロファイルが置かれたボリュームに22 GBのディスク空き容量を求めています。これは空き容量の要件であり、モデル自体がその容量を占めるという意味ではありません。これらの基盤モデルAPIは現在、Android版とiOS版のChromeでは動作しません。Chromeのハードウェア要件

社内向けWebツールに組み込む場合は、全員が使えると約束する前に、従業員が利用しているブラウザ環境を確認する必要があります。ローカルモデルが利用できなくても、元のテキストを参照し、手作業で進められる状態を保ってください。

Copilot+ PC：便利なWindows機能にも、できることの範囲がある

MicrosoftのCopilot+ PCは、Live Captionsの翻訳、Windows Studio Effects、強化されたWindows検索などの機能を動かすためのハードウェアを備えています。各機能には、それぞれ対応端末、言語、提供時期に関する条件があります。Microsoftの法人向け機能ガイド

この区分のPCには、Windowsの要件に加え、対応する40+ TOPSのNPU、16 GBのRAM、256 GBのストレージが必要です。TOPSは毎秒の演算回数を兆単位で表す指標です。演算能力を示すものであって、業務上の質問にモデルがどれだけ的確に答えられるかを示すものではありません。Microsoftのハードウェア仕様

Live Captionsは、ローカルで動く機能を理解するうえで分かりやすい例です。Microsoftによると、音声処理と字幕生成は端末内で完結します。標準的な字幕機能はすでにWindowsにあり、Copilot+では翻訳が追加されます。ただし、生成した字幕は保存されません。会議記録の保管用途や、文字起こしを残す必要がある業務の代わりにはなりません。MicrosoftのLive Captionsドキュメント

購入担当者は、どの機能のためにそのハードウェアが必要なのかを明確にすべきです。NPU搭載機を買っても、Microsoft Copilotのクラウド機能や、任意のデスクトップ向けモデルがそのチップ上で動くようになるわけではありません。WindowsのAI関連仕様、NPUのソフトウェア要件

OllamaとLM Studio：使うモデルを自分で選ぶ

Ollamaは、アプリケーションから呼び出せるAPIを備えたローカルモデル実行ツールです。ドキュメントでは、ローカルでのモデル実行と、任意で使うクラウド機能を区別しています。ローカルモデルを既存の業務フローにつなぎ、CPUとGPUのどちらで動いているかも確認したい技術者に向いています。Ollamaのドキュメント

ローカルに限定した運用にする方法として、Ollamaはサーバー設定のdisable_ollama_cloud: true、または環境変数OLLAMA_NO_CLOUD=1を設定して再起動する手順を案内しています。これにより、OllamaのクラウドモデルとWeb検索が無効になります。ただし、Ollamaに接続する別のアプリの通信までは制御できません。Ollamaのローカル専用設定

LM Studioは、モデルのダウンロード、読み込み、チャットを行うためのデスクトップインターフェースを提供しています。Qwen、Mistral、Gemmaなどのモデルファミリーを扱えます。開発元が学習済みのモデルファイルを公開しているものは「オープンウェイト」モデルですが、ライセンスはそれぞれ異なります。LM Studioの入門ガイド

モデルファイルをダウンロードすれば、LM Studioでオフラインのチャット、ローカル文書の処理、ローカルサーバーを利用できます。一方、現行のプライバシーポリシーでは、任意で使うクラウドモデルとWeb検索について別途説明しています。ローカルモデルを使う経路を意識して選んでください。オフラインでの利用、LM Studioの現行プライバシーポリシー

LM Studioは、プラットフォームごとの追加要件に加えて、少なくとも16 GBのRAMを推奨しています。これは出発点となる目安であり、どのモデルでも収まるという保証ではありません。Intel Macは非対応で、Apple Siliconに対応しています。Windowsのx64ビルドには、AVX2に対応したCPUが必要です。LM Studioのシステム要件

マシンに合ったモデルの選び方はおすすめのローカルLLMガイドを、実行ツールや導入方法、業務利用時のライセンスの比較はOllamaとLM Studioの比較を参照してください。実行ツールとモデルは、それぞれ選ぶ必要があります。

どの業務を従業員の端末に任せるべき？

入力データがすでに手元にあり、作業の範囲が限られ、人が結果を確認できる場合に、ローカル処理の利点が最も生きます。 端末の能力を超える仕事や、中央で運用するサービスが必要な仕事では、クラウドも有効な選択肢です。表の最後の列は導入に関する判断であり、実測による品質の順位ではありません。

文字起こしでは、音声認識と要約を分けて考えてください。文章を書き換えられる言語モデルが、そのまま音声の文字起こしもできるわけではありません。GoogleのBasic音声モードは従来型のオンデバイス音声モデルを使い、Advancedモードは生成モデルを使います。その結果得られたテキストを保存するか、どこに保存するかは、アプリケーション側で決める必要があります。GoogleのSpeech Recognitionガイド

費用を比べる際は、有料のクラウドAPI呼び出しと、呼び出しごとのクラウド推論料金が発生しない無料のローカル実行を比較します。そのうえで、ハードウェア、電力、管理のコストも含めて考えてください。GoogleによるローカルAPIの費用の説明

チップの性能表示より重視すべき制約は？

最初に問題になりやすいのは、モデルが起動するかではなく、処理したい内容がどこまで収まるかです。 コンテキストウィンドウとは、指示、元の資料、会話履歴、回答を入れる、モデルの作業領域です。

Appleの現行ガイドによると、標準のオンデバイスモデルのコンテキストウィンドウは4,096トークンです。トークンはテキストを区切った単位で、入力と出力がこの枠を共有します。ガイドには、実際に使うモデルの容量を取得する方法も示されています。長い文書を扱う際、ウィンドウ全体を元の文章だけに使えると考えてはいけません。Appleのコンテキストウィンドウガイド

文書をチャンクに分割すれば収めやすくなりますが、チャンク間の関係はアプリケーションで維持する必要があります。ある節に期限が書かれ、別の箇所にその例外が書かれている場合、個別の要約を集めるだけでは、その関係を見落としかねません。各チャンクから文章が出力されたかどうかだけでなく、業務として得られた最終結果を評価してください。

デスクトップ向けモデルには、重みと作業中の状態を保持するメモリも必要です。コンテキストが長くなったり、同時に複数のリクエストを処理したりすると、メモリ使用量が増える場合があります。返信の下書きを作る人には十分使えるモデルでも、ほかのアプリを開きながらバックグラウンドで一括処理する用途には適さないことがあります。Ollamaのメモリと並列処理のガイダンス

だからこそ、実用性の検証は、従業員が使う代表的な構成の端末で、普段のアプリを起動した状態で行うべきです。自社の作業について、完了までの時間、失敗したリクエスト、修正の手間、バッテリーへの影響を記録してください。前述のハードウェア要件を満たしていても、あらゆる状況で一定の速度や品質が得られるわけではありません。

プライバシーとコンプライアンスはアプリ全体で判断する

オンデバイス処理によって業務フローからクラウドへのデータ転送を取り除けても、その業務のコンプライアンスを保証することはできません。 選んだ機能が何を送信し、保存し、外部から参照できる状態にするのかを確認し、その構成をセキュリティとコンプライアンスの担当者に評価してもらってください。

各社の説明には、それぞれ適用される範囲があります。

• Apple： オンデバイスモデルは通信なしでも動きますが、Foundation Modelsはクラウドプロバイダーや、オンラインのデータを取得するツールにも対応しています。アプリが選択したモデルとツールを記録してください。Appleのモデル対応状況
• AndroidのGoogle機能： ML Kitは、入力データと出力をGoogleに送信しないと説明しています。一方で、性能と利用状況の指標は送信され、更新のためにサーバーへ接続します。コンテンツをローカルで処理することと、通信が一切ないことは同じではありません。ML Kitのプライバシーに関する規定
• ChromeのGoogle機能： Googleによると、ローカルモデルの利用ではGoogleや第三者にデータを送信せず、ネットワークは初回のモデルダウンロードに必要です。ただし、この説明は、APIを使うWebサイトが独自のコードでデータを送信することまで防ぐものではありません。Chromeのモデル要件
• Microsoft： Live Captionsの処理はローカルで完結しますが、ほかの機能では範囲が異なります。Paint CocreatorはNPUで画像を生成する一方、安全性のためのクラウドサービスを利用します。Microsoftは、不正利用防止のためにプロンプトと識別子を収集すると説明しています。結果をローカルで生成したというだけでは、機能全体がローカルで完結している証拠にはなりません。Cocreatorのプライバシーに関する説明
• デスクトップの実行ツール： Ollamaのローカル利用時のプライバシーに関する説明は、ローカルで実行する場合に適用されます。LM Studioの現行ポリシーも、ローカル処理と任意のクラウドサービスを区別しています。クラウド事業者がリクエストを保持しないと約束していても、そのリクエストが端末の外へ出たことに変わりはありません。Ollama、LM Studio

従業員が機密性の高い資料を扱う前に、元データの所在、選択したモデル、外向きのリクエスト、ローカルの履歴、バックアップ、削除時の動作を文書化してください。拡張機能や接続するツールも確認の対象に含めます。データをローカルに保つことは、従業員の端末にコピーを残すことでもあるため、端末の暗号化とアクセス制御も重要です。

オンデバイスAIの何が過大評価されている？

「ノートPCがクラウドAIサービスを置き換える」という主張は、計算処理と運用の仕組みを混同しています。 推論を端末へ移しても、モデルの更新、サポート、権限管理、評価、作業が失敗した場合の対処は引き続き必要になり得ます。

NPUは対応する処理には有効ですが、あらゆるモデルとの互換性を保証するものではありません。オフラインで回答を生成すれば、推論時にネットワークを往復する必要はなくなります。ただし、それだけで回答が速く届くとは言えません。また、ローカルにインストールしたモデルでも、事実にない詳細を作り出したり、不適切な内容を出力したりする可能性があります。

逆の主張も有益ではありません。ローカルモデルは、最も高性能なクラウドモデルを置き換えられなくても役立ちます。信頼して使える下書きの推敲や短い要約だけでも、導入する価値はあります。判断すべきなのは、その機能が、実際に従業員の持つ端末で自社の受け入れ基準を満たすかどうかです。

今、オンデバイスAIを導入すべきなのは誰？

業務運用の担当者は、範囲が限られ、結果を確認できる作業の試験導入を始めるべきです。一方、購入担当者は、必要性が実証されるまでハードウェアの調達を待つべきです。 次に取るべき行動は役割によって異なります。

業務運用の担当者は、 社内の引き継ぎメモを短くまとめる、といった定期的に発生する作業から始めてください。期待する結果が分かっている入力を選び、出力には人の承認を必須にします。比較できるように元の資料も残しておきます。

開発者やプロダクト責任者は、 導入済みの端末と実現したい機能に合う場合、プラットフォームのAPIを使ってください。モデルの利用可否の確認、入力の制限、手作業への切り替えを、製品の機能として実装します。スマートフォンの機種が混在する環境では、その機能を実行できない端末の利用者にも、業務を進められる手段が必要です。

購入担当者やCTOは、 買い替えを発注する前に既存のマシンを棚卸ししてください。Windowsの特定のNPU機能を使うための購入と、デスクトップのモデル実行ツールを使うための購入は、分けて検討します。代表的な構成のマシンで、選んだ業務に有用な結果が得られると実証されてから、ハードウェアへの支出を承認してください。

バックグラウンド推論を禁止するAPIで無人の一括処理を行おうとしている場合や、ローカルモデルが必要な品質を満たさない場合は、導入を待ってください。 承認済みのクラウド業務フローですでに要件を満たしており、ローカル化によってプライバシー、接続性、運用の面で有用な利点が得られないなら、現在の構成を維持してください。

月曜日に始めること：業務をひとつ選んで試す

1. 1

   対象の作業と、データを外に出せる範囲を決める

   引き継ぎメモを短い下書きにするなど、入力と出力を具体的に決めます。代替手段を設定する前に、その内容のどこまでを端末の外へ送ってよいかを決めてください。

2. 2

   実際の端末とモデルの準備状況を確認する

   対象端末のOS、チップ、メモリ、ストレージの空き容量を棚卸しします。必要なモデルをダウンロードし、利用できることを確かめ、非対応のマシン向けに手作業で進める経路を残してください。

3. 3

   出力の品質と通信の動作を別々に評価する

   利用が承認されたサンプル資料を使います。結果を元の資料と比較し、外向きの通信を調べ、準備した業務フローをオフラインでも繰り返してください。オフラインで動くことは、その処理経路について有用な証拠になります。ただし、接続時のアプリが一切データをアップロードしない証明にはなりません。

4. 4

   利用範囲を広げるか判断する

   完了までの時間に加え、失敗、修正の手間、サポートの負担を記録します。作業が役に立ち、データの取り扱いが想定した範囲に収まる場合にだけ、利用を広げてください。クラウド利用が許可されている箇所では、アクセスすることを明示します。

AI導入を判断するための実践的な情報は、ニュースレターにご登録ください。