ChatGPTのようなAIは、質問を送るたびにデータがサーバーへ渡り、そこで処理されて返ってきます。当たり前のようですが、業務の資料、個人的な相談、まだ公開していないアイデアを扱うときには、これが引っかかることがあります。
そこで注目されているのがローカルLLM——モデルを自分の端末に置き、通信せずにその場で動かすという選択肢です。しかも近年は、iPhoneやiPad単体でも現実的に動くようになってきました。
この記事では、その仕組みと、実際に使うときの選び方を整理します。
📌 この記事の3行まとめ
① ローカルLLMの利点はプライバシー・オフライン動作・従量課金なしの3点
② 選ぶときは「パラメータ数」と「量子化」の2つを見る。おおよそファイルサイズがそのまま必要メモリ
③ 小型モデルは万能ではない。得意な仕事に絞って使うと、驚くほど実用になる
ローカルLLMとクラウドAI、何が違うのか
| クラウドAI | ローカルLLM | |
|---|---|---|
| 処理する場所 | 事業者のサーバー | 自分の端末の中 |
| 通信 | 必須 | 不要（機内モードでも動く） |
| データの行き先 | 外部に送信される | 端末外に出ない |
| 費用 | 従量課金 or 月額 | 電気代のみ |
| 賢さ | 非常に高い | 限定的（モデルサイズによる） |
| 速度 | 通信次第 | 端末性能次第。安定している |
| モデルの選択 | 事業者が決める | 自分で選べる・差し替えられる |
要するに、賢さを取るならクラウド、データの所在と安定性を取るならローカルという関係です。どちらが優れているという話ではなく、用途で選ぶものです。
ローカルLLMが向いているのは、次のようなケースです。
- 外に出したくない情報を扱う（未公開の企画、社内資料、個人的な内容）
- 通信できない環境で使う（機内、地下、電波の悪い場所、海外）
- 短い処理を大量に回す（従量課金だと積み上がる用途）
- モデルを自分で選びたい（用途に合わせて差し替える）
パラメータ数：モデルの「規模」
モデル名に付いている 1B、3B、7B という数字は、パラメータ数（B＝10億）です。ざっくり言えばモデルの規模で、大きいほど賢く、大きいほど重い。
スマートフォンで現実的な範囲は、おおむね次のとおりです。
| 規模 | 目安 | スマートフォンでの実用性 |
|---|---|---|
| 0.5B〜1B | 非常に小さい | 軽快に動く。単純な要約・分類・変換向け |
| 2B〜4B | 小型 | 現在のスマートフォンで最も現実的な帯域。会話、要約、翻訳、下書き |
| 7B〜8B | 中型 | 上位機種なら動く場合がある。メモリ余裕はほぼ無い |
| 13B以上 | 大型 | スマートフォンでは基本的に困難 |
ただし、パラメータ数だけで賢さは決まりません。 学習データの質、学習方法、日本語への対応度合いによって、同じ3Bでも実力は大きく違います。新しいモデルほど、同じサイズでの性能が上がっている傾向があります。
量子化：モデルを軽くする仕組み
そのままのモデルはスマートフォンには大きすぎます。そこで使われるのが量子化です。
モデルの内部は膨大な数値の集まりです。学習時はこれを16bit（あるいは32bit）の精度で持っていますが、推論するだけなら、そこまでの精度は要りません。そこで、数値を4bitや8bitに丸めて保存します。これが量子化です。
ファイル名に付く Q4_K_M、Q5_K_S、Q8_0 といった記号が、その方式を表しています。読み方は次のとおりです。
- Q のあとの数字 = ビット数。小さいほど軽く、小さいほど精度が落ちる
- K = より新しい方式（同じビット数でも精度が良い傾向）
- S / M / L = Small / Medium / Large。同じビット数の中での細かい配分
実用的な指針としては、Q4_K_M が容量と品質のバランスが良いとされ、最も広く使われています。
| 量子化 | 目安 | 傾向 |
|---|---|---|
| Q8_0 | 大きい | ほぼ劣化なし。ただし重い |
| Q6_K | やや大きい | 品質重視 |
| Q4_K_M | 中 | 迷ったらこれ。定番 |
| Q3_K_M | 小さい | 明らかに品質が落ち始める |
| Q2_K | 非常に小さい | 実用は厳しいことが多い |
メモリの見積もり方
ここが実務上いちばん重要です。モデルファイルのサイズは、ほぼそのまま必要メモリだと考えてください。
さらに、次のぶんが上乗せされます。
- KVキャッシュ：会話が長くなるほど増えます。長文を扱うと無視できません
- アプリ自体とOSの使用分
そして決定的な制約として、iOSではアプリが使えるメモリに上限があります。端末の搭載メモリ全部を使えるわけではありません。搭載8GBの端末でも、1つのアプリが自由に使えるのはその一部です。
したがって現実的な判断は、
- モデルファイルが2GB前後 → 多くの端末で動く
- 3〜4GB → 比較的新しい端末なら
- 5GB超 → かなり厳しい。動いても他のアプリを巻き込んで落ちやすい
「動くけれど、しばらく使っているとアプリが落ちる」という現象は、たいていメモリの上限に当たっています。1段階小さいモデルか、1段階強い量子化に落とすのが正解です。
小型モデルが得意なこと・苦手なこと
ここを理解しているかどうかで、満足度が大きく変わります。
得意なこと
- 要約：長い文章を短くする。元の情報が入力にあるので、モデルの知識に依存しません
- 翻訳・言い換え：文体変換、敬語化、平易化
- 分類・抽出：「この文はポジティブか」「日付を抜き出せ」
- 下書き：メールやメモの叩き台
- 形式変換：箇条書き化、表への整理
苦手なこと
- 事実の記憶：小型モデルは知識量が少なく、自信ありげに間違えます
- 長い文脈の保持：会話が長くなると前半を見失います
- 複雑な多段の推論：数学的な計算、込み入った論理
- 最新の情報：学習時点以降のことは知りません
共通しているのは、「入力に答えが含まれている仕事は得意、モデルの記憶に頼る仕事は苦手」という点です。これが小型モデルを使いこなす最大のコツです。
💡 使い分けの原則
「〇〇について教えて」（記憶に頼る）ではなく、「この文章を要約して」「この内容を英訳して」（入力に頼る）という形で使う。同じモデルでも、実用性がまったく違ってきます。
小型モデルを、設計で賢くする
とはいえ、苦手なことを完全に諦める必要はありません。モデル自体を大きくする代わりに、周辺の設計で補うという方向があります。実際、近年の研究で有効性が確認されている手法がいくつもあります。
- 検索してから答える（RAG）：モデルの記憶に頼らず、手元の資料から関連箇所を取り出してモデルに渡す。事実性と最新性を補えます
- ツールを呼ぶ：計算は計算機に、日付は端末の時計に任せる。モデルが苦手な作業を外に出します
- 段階に分ける：一度に全部やらせず、「要点を抽出する → それをもとに書く」と分割する
- 根拠を出させる：どこから導いたかを示させることで、検証できる形にする
当社がこの考え方を実際のアプリに落とし込んだ設計については、オンデバイスAIエージェントの開発事例で詳しく書きました。「どのAIを使うか」ではなく「AIに何をどう任せるか」が品質を決める、という話です。
使ってみるときの注意点
- 発熱とバッテリー：CPU・GPUを継続的に使うため、長時間の連続実行では端末が熱くなり、電池も減ります
- 初回のダウンロード：モデルファイルは数GBあります。Wi-Fi環境での取得を推奨します
- ストレージ：複数のモデルを入れると、あっという間に容量を圧迫します
- ライセンス：モデルごとに利用条件が異なります。商用利用の可否は必ず確認してください
LocaNecoで、端末内のAIを試す
当社が開発した LocaNeco@LLMエージェント は、iPhone・iPadに追加したAIモデルを端末上で動かすローカルAIアプリです。無料でご利用いただけます。
- 端末内でAIチャット：対応モデルを追加し、下書き、要約、翻訳、調べものの整理などを端末上で実行できます
- Project Memory：会話ごとの目的・要望・制約・決定事項を保存し、内容を確認・編集・削除できます。小型モデルが苦手な「長い文脈の保持」を、設計側で補う仕組みです
- ローカル画像生成：画像生成モデルを管理し、プロンプトから画像を生成して共有・保存できます
- 会話ログを原則として端末内に置きたい方、自分で選んだローカルLLMを試したい方に向けた設計です
この記事で書いた「小型モデルを設計で賢くする」という考え方を、そのまま実装したアプリです。まず手元で動かしてみて、どこまでできてどこからが厳しいのかを体感する——ローカルLLMの理解には、それがいちばん早いと思います。
なお、オンデバイスAIやLLMエージェントの受託開発についても、企画やPoCの段階からご相談を承っています。「データを外に出せない」「通信が不安定」「ランニングコストを抑えたい」といった条件のある案件で、ここで挙げた設計手法がそのまま効きます。お問い合わせからお気軽にどうぞ。
