ふくふくHukuhuku Inc.
EP.14Toolbox 18分公開: 2026-08-29

ローカル LLM の道具箱:Ollama / LM Studio / MLX と Mac mini・Mac Studio 運用

手元の Mac で LLM を動かす選択肢を整理。ランタイム 4 種の比較、量子化とメモリ見積り、サブスク・API との使い分け、機種選定と常時起動運用まで。

#道具箱#ローカルLLM#Apple Silicon#Ollama#MLX
執筆 / 監修
松尾 亮合同会社ふくふく 代表社員

データ基盤・データパイプライン構築 / BI / 生成 AI 活用支援を専門とするエンジニア (28 年)。 本記事は AI 利用ポリシーに基づき、生成 AI の補助で執筆 → 人間が監修・編集して公開しています。

プロフィール詳細
シェア

を使う経路は、いまや「サブスクに課金する」「 を従量で叩く」だけではありません。手元の Mac で のモデルを動かすという 3 つ目の選択肢が、実務で十分使える水準に来ています。この記事では、ランタイムの選び方から量子化とメモリの見積り、サブスク・API との使い分け、そして 機の選定と常時起動運用までを一気通貫でまとめます。

この記事の前提

執筆時点(2026 年 8 月末)の情報です。ローカル LLM 界隈は数ヶ月で状況が変わります。モデル名やタグ、価格は必ず一次情報を確認してください。ハードウェア仕様は Apple の技術仕様 と公式発表を出典としています。

1. なぜ手元で動かすのか

「クラウドの方が賢いのに、わざわざ手元で動かす理由は何か」。ここが曖昧なまま機材を買うと、高価な置き物になります。実務で効いてくる動機は、おおむね次の 3 つに整理できます。

  • データを外に出せない: 個人情報・未公開の設計資料・顧客から預かったファイル。契約上そもそも外部送信が禁じられているケースは珍しくない。ローカルなら送信自体が発生しない
  • 量が多くて従量課金が効かない: 数万件のログ分類、全文書の要約、テストデータの大量生成。1 件あたりは安くても、掛け算になると無視できない。ローカルなら電気代だけで一晩回せる
  • 止まると困る / つながらない: 外部サービスの障害やレート制限に業務が引きずられない。オフラインの現場でも動く

逆に言えば、この 3 つに当てはまらないなら、素直にサブスクか API を使う方が安上がりで速いです。「なんとなく自前が良さそう」で始めると、まず間違いなくクラウドの方が総額で安く済みます。判断材料は 5 章の比較表にまとめました。

2. ランタイム 4 種の地図

ローカル LLM を動かすソフトウェアは、大きく 4 つの系統に分かれます。どれか 1 つを選ぶというより、入口を 1 つ決めて、必要になったら下のレイヤーに降りていくという関係です。

ツール形態強み向いている人
CLI + 常駐サーバ1 コマンドで取得〜起動。OpenAI 互換 API を最初から持つ既存のコードから叩きたい人
GUI アプリモデル探索・量子化の選択・API サーバ化を画面で完結まず触って感触を掴みたい人
ライブラリ / CLI対応ハードの広さ。組込み機やオフライン環境まで動く特殊な環境に載せたい人
/ MLX-LMPython フレームワークApple Silicon での速度を詰められる。 もできる速度を追い込みたい・学習もしたい人

実務での標準構成は 「入口は Ollama、GUI が要る人には LM Studio、速度を詰める段になったら MLX-LM」 です。Ollama は Apple Silicon 上では 0.19(2026-03-31)から MLX を実行エンジンに採用しており、以前のように「Ollama = llama.cpp のラッパー」という理解は古くなっています。

GGUF と MLX、どちらの重みを落とすか

同じモデルでも 版と MLX 版が配布されていることがあります。Apple Silicon 上では MLX 版の方が速い傾向が報告されていますが、配布されているバリアントの数と鮮度は GGUF の方が豊富です。迷ったら GGUF で動かし始めて、常用するモデルが決まってから MLX 版を探すのが手戻りが少ない。

3. モデルの選び方 ── 量子化とメモリ見積り

ローカル LLM で最初に詰まるのが「このモデル、うちの Mac に載るのか」です。ここは計算で概算できます。鍵になるのが 、つまり重みを低いビット精度に落として容量を削る技術です。

必要メモリのざっくり見積り
Bash
# 必要メモリ(GB) ≒ パラメータ数(B) × ビット幅 / 8 × オーバーヘッド# 32B のモデルを 4bit で動かす場合
python3 -c "params_b = 32     # パラメータ数(十億)bits     = 4      # 量子化ビット幅overhead = 1.2    # 実行時オーバーヘッド(KVキャッシュは含まない)
weights = params_b * bits / 8print(f'重みだけ : {weights:.1f} GB')print(f'実効     : {weights * overhead:.1f} GB')"# 重みだけ : 16.0 GB# 実効     : 19.2 GB

この計算に を伸ばした分の が上乗せされます。KV キャッシュは会話が長くなるほどほぼ線形に増えるので、「起動直後は動いたのに、長い文書を読ませたら落ちた」はここが原因であることが多い。搭載メモリいっぱいまで使う前提で選ばないのが安全です。

4bit 量子化時の概算。実際の配布物のサイズは量子化方式で前後します
モデル規模4bit 時の重み余裕をみた必要メモリ収まる機体の目安
8B約 4GB8GB 〜16GB の Mac mini
14B約 7GB12GB 〜16〜24GB
32B約 16GB24GB 〜32GB 以上
70B約 35GB48GB 〜64GB 以上
200B 超(約 100GB 〜160GB 〜Mac Studio の大容量構成

近年の傾向として、MoE 構成のモデルがローカル運用と相性が良いという点は押さえておく価値があります。総パラメータは大きいのでメモリは食いますが、1 トークンあたりに実際に使う重みは一部だけなので、「メモリさえ載れば、サイズの割に速い」という挙動になります。大容量メモリを積んだ Mac の強みがそのまま効く構成です。

4. 導入 ── Ollama で 10 分

まずは動くところまで。macOS なら Homebrew で入ります。モデルのタグは頻繁に入れ替わるので、下のコマンドでは変数に切り出しています。実際のタグは配布元のライブラリページで最新を確認してください。

導入から OpenAI 互換 API を叩くまで
Bash
# 1. 導入brew install ollamabrew services start ollama          # 常駐サーバとして起動
# 2. モデルを取得する#    タグは ollama.com/library で最新を確認すること(頻繁に入れ替わる)MODEL="<モデル名>:<タグ>"ollama pull "$MODEL"
# 3. 対話してみるollama run "$MODEL"
# 4. 手元のモデルと占有サイズを確認ollama list
# 5. OpenAI 互換エンドポイントとして叩くcurl http://localhost:11434/v1/chat/completions   -H "Content-Type: application/json"   -d "{    "model": "$MODEL",    "messages": [{"role": "user", "content": "SQLのWINDOW関数を3行で説明して"}]  }"

OpenAI 互換の API を最初から持っているのが Ollama の実務的な価値です。既存のコードで接続先を差し替えるだけで、クラウドとローカルを切り替えられます。

接続先を差し替えるだけでローカルに切り替わる
Python
import os
from openai import OpenAI
# base_url を差し替えるだけ。ローカルでは api_key の中身は使われないUSE_LOCAL = os.environ.get("USE_LOCAL") == "1"
client = (    OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")    if USE_LOCAL    else OpenAI()  # 通常どおり環境変数のキーを使う)
resp = client.chat.completions.create(    model="<モデル名>:<タグ>" if USE_LOCAL else "<クラウド側のモデル名>",    messages=[{"role": "user", "content": "このCSVの異常値を検出する方針を3案"}],)print(resp.choices[0].message.content)
互換 API は「互換」であって同一ではない

OpenAI 互換エンドポイントは チャット補完のような基本形は通りますが、ツール呼び出し・構造化出力・ストリーミングの細部は実装差が出ます。クラウド前提で書いたコードがそのまま全部動くとは考えず、使う機能ごとに疎通確認してください。

5. サブスク・API とどう使い分けるか

ここが本題です。3 つの経路はコスト構造がまったく違うので、同じ土俵で「安い / 高い」を比べても意味がありません。何が固定費で何が変動費かを分けて見ます。

観点サブスク(定額)API(従量)ローカル LLM
初期費用なしなし本体代(十万円〜百万円規模)
変動費月額固定トークン量に比例ほぼ電気代のみ
到達できる性能フロンティアモデルフロンティアモデル一段落ちる
データの外部送信ありありなし
オフライン動作不可不可
大量バッチレート制限にかかる課金が線形に増える時間はかかるが上限なし
運用の手間ほぼゼロ自分持ち

参考として、 の API 価格は執筆時点で Opus 5 が入力 $5 / 出力 $25(100 万トークンあたり)、Sonnet 5 が $3 / $15、Haiku 4.5 が $1 / $5 です。サブスクは Pro が月 $20、上位の Max が月 $100 / $200 の 2 段階。最新の価格は Anthropic の価格ページ で確認してください。

この数字を見ると分かりますが、軽いモデルの従量課金はかなり安い。「コスト削減のためにローカル化する」という動機は、よほどの物量がないと本体代を回収できません。ローカルを選ぶ理由は、コストより先に「データを出せない」「オフライン」「レート制限が邪魔」であるべきです。物量によるコスト逆転は、その次に来るおまけと考えた方が判断を誤りません。

現実的な落としどころ

難しい仕事はクラウド、量の出る仕事はローカル。設計判断・複雑なコード生成・長い推論はサブスクや API に任せ、分類・要約・整形・タグ付けといった「単純だが件数が多い」処理をローカルに逃がす。この分担が、性能と費用の両方で一番素直な形になります。LLM 呼び出しの記録と評価は データ屋の道具箱 EP.10「LLM 運用の道具」 で扱っています。

6. Mac mini か Mac Studio か

機種選定で見るべき数字は、実は の容量と の 2 つにほぼ集約されます。CPU のコア数は、ローカル LLM の生成速度にはあまり効きません。

理由はシンプルで、1 トークン生成するたびにモデルの重みを丸ごとメモリから読み出す必要があるからです。したがって速度の理論上限は「メモリ帯域 ÷ モデルの実サイズ」で決まります。たとえば帯域 546GB/s の機体で 20GB のモデルを動かすなら、上限は毎秒 27 回程度。実測はここから 5〜7 割に落ちるのが一般的な傾向なので、 は 15〜20 あたりを見込む、という読み方をします。

Mac Studio は 2025 年モデル、Mac mini は 2026-08-25 発表モデルの公表値
機種 / チップメモリ上限メモリ帯域ローカル LLM 目線の位置づけ
Mac mini(M6)32GB最大 170GB/s8〜14B を軽快に。入門機
Mac mini(M5 Pro)64GB307GB/s32B が快適圏。常時起動サーバの主力候補
Mac Studio(M4 Max)128GB410 / 546GB/s70B クラスまで狙える
Mac Studio(M3 Ultra)256GB819GB/s大規模 MoE も載る。現行の上限
買い時に注意(執筆時点)

Mac mini の M6 / M5 Pro は 2026-08-25 発表、出荷開始は 2026-09-22 です。Mac Studio も次世代(M5 Max / M5 Ultra)が同日出荷開始とアナウンスされています。いま店頭にある Mac Studio は 2025 年モデルなので、急ぎでなければ世代の切り替わりを待つ判断もあり得ます。Apple の発表では M5 Pro 搭載 Mac mini は Thunderbolt 5 で複数台をクラスタ化し、大きなモデルを分散して動かす構成にも触れられています。

選定の目安をひとことで言うと、「動かしたい最大のモデルが 4bit で何 GB か」を先に決めて、その 2 倍のメモリを積んだ機体を選ぶ。2 倍にするのは、KV キャッシュと OS・他アプリの取り分を確保するためです。帯域は「同じメモリ容量なら大きい方が速い」程度の見方で足ります。 の上限に縛られる外付け GPU 機との最大の違いがここです。

7. 常時起動サーバとして運用する

ローカル LLM が本当に効いてくるのは、手元の 1 台を「いつでも叩ける社内エンドポイント」にした瞬間です。Mac mini が候補に挙がりやすいのは、消費電力と静音性が常時起動に向いているからでもあります。

LAN 公開とメモリ挙動の設定
Bash
# 既定では 127.0.0.1 のみ待ち受ける。LAN に出すときだけ変更するlaunchctl setenv OLLAMA_HOST "0.0.0.0:11434"
# 同時にメモリへ載せるモデル数(増やすとメモリを食い合う)launchctl setenv OLLAMA_MAX_LOADED_MODELS 1
# アイドル時にモデルをメモリから降ろすまでの猶予launchctl setenv OLLAMA_KEEP_ALIVE 30m
brew services restart ollama
# 別マシンから疎通確認curl http://<サーバのIP>:11434/api/tags
LAN に出す前に必ず読む

Ollama の API には認証がありません。 0.0.0.0 で待ち受けさせるということは、そのネットワークに入れる全員がモデルを自由に叩けるということです。最低でも、①信頼できる LAN に限定する、②リバースプロキシを前段に置いて認証を掛ける、③ファイアウォールで送信元を絞る、のいずれかを併用してください。インターネットに直接晒すのは論外です。

  • 電源とスリープ: システム設定のエネルギー項目で自動スリープを切る。スリープすると当然応答しない
  • モデルの置き場所: 量子化済みとはいえ 1 モデルで数十 GB。内蔵 SSD の残容量を先に確認する
  • メモリの奪い合い: 常時起動機で他の作業もするなら、同時ロード数を 1 に絞る
  • リモートからの利用: 社外から使いたくなったら、ポート開放ではなく VPN か SSH トンネルを使う
  • : 可搬性は上がるが、macOS の Docker では GPU が使えず極端に遅くなる。Mac ではネイティブ実行が基本

8. 落とし穴とアンチパターン

ここまでの内容を踏まえて、実際にやりがちな失敗を並べます。多くは「クラウドと同じ感覚で使おうとした」ことに起因します。

  • フロンティアモデルと同じ品質を期待する: 手元で動く規模のモデルは、複雑な推論や長い文脈の一貫性で明確に劣る。得意な仕事を割り当てるのが前提
  • メモリいっぱいのモデルを選ぶ: 起動はしても、長い入力で KV キャッシュが膨らんだ途端に破綻する。搭載量の半分を目安に
  • コスト削減だけを理由に導入する: 軽量モデルの従量課金は十分安い。本体代の回収には相当な物量が要る
  • 評価をせずに本番投入する: 「動いた」と「使える」は別。クラウドと同じ評価セットで比較してから置き換える
  • ライセンスを確認しない: オープンウェイトでも商用利用や再配布に条件が付くものがある。モデルごとに必ず確認
  • 認証なしで LAN に公開する: 7 章のとおり。社内でも「誰でも叩ける」状態は事故のもと
  • 対策を忘れる: ローカルだから安全、ではない。外部由来のテキストを読ませる構成なら対策は同じだけ必要
  • の代わりになると思う: 手元で動かしても、モデルが知らない社内情報は答えられない。検索と組み合わせる設計は別途必要(RAG 実装ハマりどころ図鑑 EP.01
評価の最小セット

置き換えを検討するなら、自社の実データから 30〜50 件の入出力ペアを作り、クラウドとローカルで同じ入力を流して並べて比べてください。体感ではなく並べた結果で判断すると、「この用途は落とせる / この用途は無理」の線がはっきり出ます。

9. ふくふくの進め方

データを外に出せない制約があるが、AI は使いたい」というご相談が増えています。私たちは、①その業務が本当にローカルでなければならないかの切り分け、②必要なモデル規模から逆算した機材選定、③既存コードからの接続と評価セットの整備、という順で支援しています。いきなり機材を買わないところから始めるのが、結果的に一番安く済みます。

10. ここまでのまとめ

  • 入口は Ollama、GUI が欲しければ LM Studio、速度を詰める段で MLX-LM に降りる
  • 必要メモリ ≒ パラメータ数 × ビット幅 / 8 × 1.2。KV キャッシュの上乗せを見込んで搭載量の半分を目安に
  • 速度の上限はメモリ帯域 ÷ モデルサイズ。実測はその 5〜7 割
  • 難しい仕事はクラウド、量の出る仕事はローカル。コストは選定理由の 1 番手にしない
  • 機種選びは容量と帯域の 2 つ。動かす最大モデルの 2 倍のメモリを積む
  • LAN に出すなら認証を前段に置く。Ollama 自体は認証を持たない

ローカル LLM は「クラウドの安い代替」ではなく、制約のある場所で AI を使うための別の道具です。得意不得意を踏まえて役割を分ければ、両方使う構成が最も費用対効果が高くなります。続編では、MLX-LM でのファインチューニング手順社内向けエンドポイントに認証を付ける具体構成複数台クラスタで大きなモデルを動かす検証などを、読者リアクションに応じて随時追加していきます。

シェア

この記事の感想を教えてください

あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。

シリーズの外も探す:

まずは、現状を聞かせてください。

要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。

無料相談フォームへ hello [at] hukuhuku [dot] co [dot] jp