ローカルAI・オンデバイスAIとは──スマホとブラウザでAIを動かす利点と制約

「AIはクラウドの向こう側」だけではなくなってきた

これまで、生成AIといえば大きなデータセンターのサーバーに問い合わせて答えを受け取るもの、というイメージが一般的でした。手元のスマホやパソコンは、いわば入力と表示をする窓口にすぎない、という構図です。

ところが最近は、AIモデルそのものを手元の端末で動かす「ローカルAI」「オンデバイスAI」の実例が増えてきました。難しそうに聞こえますが、簡単に言うと「計算を自分の端末の中で完結させる」ということです。この記事では、スマホで動かす例とブラウザで動かす例を手がかりに、その利点と制約を整理していきます。

スマホの中でLLMを動かす──容量という壁と、その越え方

大きな言語モデルを手元で動かすうえで、最初に立ちはだかるのがメモリ容量です。PrismMLのBonsai 27BをiPhoneで実行可能にのBonsai 27Bの発表は、この壁の大きさと越え方の両方をわかりやすく示しています。

同社の説明によれば、270億パラメーターのモデルは通常16ビット精度で約54GBのメモリを占有し、4ビットに圧縮しても約18GBになります。スマホは限られたメモリをほかの処理とも分け合う必要があり、この容量では現実的に載りません。そこでBonsai 27Bは、各パラメーターの重みを1〜2ビット程度まで削り、スマホ向けの1-bit版を3.9GBに圧縮してiPhoneで実行可能な容量に収めた、とされています。

注目したいのは、削っても性能が大きくは落ちなかった点です。同社が知識・推論・数学・コーディングなど15のベンチマークで評価したところ、1-bit版はフル精度の90％、ノートPC向けのTernary版は95％の性能を維持したといいます。つまり「大きなモデルは手元では動かない」という前提が、圧縮技術の進歩でかなり崩れてきている、ということです。

ここから読み取れる、ローカルAIならではの利点は次のようなものです。

• 通信が要らない：ネットにつながっていない場所でも動く。
• 手元にデータがとどまる：入力内容をサーバーに送らずに済む。
• 待ち時間が読みやすい：混雑や通信状況にサーバー側の応答が左右されない。

一方で制約もはっきりしています。圧縮したぶん性能は本来のモデルより下がりますし、モデル本体でストレージを数GB消費し、動作中はバッテリーや発熱の負担もかかります。

ブラウザの中で動かす──アプリを入れずにAIを走らせる

もう一つの流れが、ブラウザの中でAIを動かすアプローチです。Google、LiteRT.jsでブラウザ内AI推論を最大約3倍に高速化で紹介されているGoogleのLiteRT.jsは、.tflite形式のAIモデルをウェブブラウザ内で実行する仕組みで、WebGPUやWebAssemblyを使って推論を加速します。

Googleの管理環境での測定では、画像認識・音声処理のモデルで既存ランタイム比としてCPU・WebGPUの双方で最大約3倍の性能が示された、とされています。ブラウザで動くということは、専用アプリのインストールが不要で、ページを開くだけでAI機能が使えるということです。処理が端末内で完結するため、通信の遅延やサーバーの運用コストを減らせる狙いもあります。

スマホでのLLM実行とブラウザでの推論は、動かす場所こそ違いますが、「クラウドに往復せず端末内で処理を終える」という発想は共通しています。GPUを活用して手元で計算を速くする、という方向性も重なっています。

制約は「どこで動かすか」で変わる

ローカルAIとクラウドAIは、優劣ではなく向き不向きで考えるのが実際的です。整理すると次のようになります。

• ローカル／オンデバイスが向く場面：オフラインで使いたい、入力データを外に出したくない、応答の速さや安定性を重視する、常時使うので通信・サーバー費用を抑えたい。
• クラウドが向く場面：とにかく最高精度が欲しい、端末の容量やバッテリーを消費したくない、巨大なモデルや最新モデルをそのまま使いたい。

端末で動かす以上、モデルの大きさや精度には上限があり、圧縮による性能低下やストレージ・電力の消費は避けられません。逆にクラウドは高性能な反面、通信が前提で、データを外部に送ることになります。この両面を天秤にかけて選ぶ、というのが基本の考え方です。

「どこで動かすか」自体が組織の選択になる

動かす場所の選択は、個人の使い勝手だけでなく、組織の方針にも関わってきます。ここで参考になるのがデジタル庁、国産3モデルを源内で試用し調達方針を検討の取り組みです。

デジタル庁は、ガバメントAI「源内」で国産の基盤モデル3種（tsuzumi 2、Takane 32B、PLaMo 2.0 Prime）を試用し、国産クラウド「さくらのクラウド」上で稼働させて、既存モデルとのA/Bテストで有用性・信頼性・経済性を検証する、としています。これはオンデバイスではなくクラウド上の話ですが、「AIをどこで、誰の管理する環境で動かすか」を主体的に選ぶ姿勢がはっきり表れた例です。

端末内で動かすローカルAIは、この「動かす場所を自分でコントロールする」という発想を、もっとも手元に引き寄せた形だと言えます。データを外に出さず、自分の端末で処理を完結させられることは、情報の扱いに慎重でありたい場面ほど意味を持ちます。

まとめ──手元で動かすという選択肢を持っておく

ローカルAI・オンデバイスAIは、「AIは必ずクラウドの向こうにあるもの」という前提を崩し、手元の端末という新しい選択肢を加えてくれます。

• Bonsai 27Bの例（PrismMLのBonsai 27BをiPhoneで実行可能に）は、圧縮技術によって大きなモデルがスマホに載るところまで来たことを示しています。
• LiteRT.jsの例（Google、LiteRT.jsでブラウザ内AI推論を最大約3倍に高速化）は、アプリを入れずブラウザだけでAI推論を高速に動かせることを示しています。
• デジタル庁の例（デジタル庁、国産3モデルを源内で試用し調達方針を検討）は、「どこで動かすか」を主体的に選ぶという視点を与えてくれます。

最先端の技術を追いかけなくても、「この用途ならクラウド、この用途なら手元で」と動かす場所を使い分けるだけで、AIとの付き合い方はぐっと現実的になります。まずは、自分が扱うデータや使う場面を思い浮かべながら、「これは手元で完結させたい処理かどうか」を考えてみるのがよい入り口になるはずです。