2026年、AIとローカルモデルを走らせるMacの選び方：メモリ・SSD・外付けストレージの落とし穴

まず「収まる」と「動く」を切り分ける

Apple Silicon MacでAI構成を考えるとき、混同しやすいのはファイルの保存容量と実行時メモリのふたつだ。前者は内蔵・外付けSSDが担い、GGUFをいくつ持てるか、データセットやHugging Faceキャッシュをどれだけ残せるかを決める。後者は購入時に選んだユニファイドメモリが決め、モデル読み込み後にどれだけコンテキストを残せるか、IDEとベクトルDBを同時に開けるか、swapが頻発するかに直結する。

2026年6月時点では、MacBook ProのM5 / M5 Pro / M5 Maxでユニファイドメモリは16GBから128GBまで選べる。Mac miniやMac Studioもおおむね同じ帯域だ。どのラインでもユニファイドメモリは出荷後に増設できない。一方Thunderbolt SSDはいつでもより大きく、速いものに差し替えられる。選び方の順番は、まずワークフローから実行時メモリの下限を見積もり、次にSSDの使い分けを設計し、最後に外付けで容量を補う——この順が安全だ。

70BモデルをQ4量子化するとファイルはおおよそ40GB。512GBの外付けSSDに入れるのは問題ない。でもマシンが16GBユニファイドメモリしかなければ、読み込み時点でOOMになるか、極端な量子化と極短コンテキストに追い込まれる。ディスクは「ファイルがあるか」、メモリは「同時に走らせられるか」を決める——ローカルAIでMacを選ぶ第一の鉄則だ。

ローカルAIでユニファイドメモリを先に見る理由

Apple Siliconに独立したVRAMはない。CPU、GPU、Neural Engineが同じ高帯域のユニファイドメモリを共有する。ローカル大規模言語モデルの推論では、モデル重み・活性化・KV cache・システムプロセスが同じプールを奪い合う。帯域が高いほどデータ移動は減り、量子化モデルの推論は同価格帯の「VRAMとRAMが分断された構成」より滑らかになりやすい——ただしプールの総容量は依然としてハードリミットだ。

ざっくり見積もるとき、占有は次のように分けられる（フレームワーク・量子化・コンテキスト長で変わる。特定モデルが特定構成で必ず快適とは約束しない）：

• macOS + 日常アプリ：ふつう4〜8GBを見込む。開発環境を全部開くとさらに増える。
• モデル重み（読み込み後）：7B Q4で約4〜5GB、14Bで約8〜10GB、32Bで約18〜22GB、70B Q4で約38〜42GB。
• コンテキスト（KV cache）：長いほど、並列が多いほど急増する。長文RAGは「モデルファイルそのもの」よりメモリを食うことも多い。
• 並列スタック：埋め込みモデル＋ベクトルDB、複数Agentツール、Docker、画像生成パイプラインが上乗せになる。

需要が物理メモリを超えると、macOSはSSDへswapする。たまの発動なら我慢できるが、常時swapはトークン生成を目に見えて遅くし、内蔵SSDの摩耗も早める。外付けSSDがどれだけ速くても、「仮想ユニファイドメモリ」として容量を増やすことはできない。あくまでページアウト先のディスクであって、実行時の演算力や帯域の延長ではない。

16GBの境界：入門には足りるが、本格ローカルには狭い

16GBは現行Macのエントリー帯で、「AIが動きそうに見えて、実際は窮屈」になりやすい構成だ。向いているのは次のような使い方で、ローカル大モデルを主力にする道ではない：

• クラウドAIが中心：ChatGPT、Claude、Cursorのクラウドモデルに重い推論を任せ、ローカルは編集と軽いスクリプト。
• 軽いローカル試行：3B〜7Bの小モデル、Apple組み込みのオンデバイス機能、たまにOllamaで8Bを試す程度。
• 単一ツール・短いコンテキスト：サービスを常駐させない、RAGを並列しない、Dockerと大型IDEを同時に開かない。

ローカルで14B以上、画像生成（Stable Diffusion / FLUX系）、データ処理パイプラインを常にメモリに載せたいなら、16GBはすぐ天井に当たる。この層にとって16GBは「あとからメモリを足せば救われる」類の問題ではない。最初から32GB以上を見るべきだ。

32GBの意味：小モデルとマルチタスクの主力ライン

多くのAI愛好家やライトな開発者にとって、32GBは2026年時点でバランスの取れたローカルAIの起点になる。7B〜14Bを主力モデルとして快適に走らせ、macOS・ブラウザ・開発ツールの余白も残せる。「コード補助＋ローカル小モデル＋日常マルチタスク」を並行する用途に合う。

典型的にカバーしやすいシーン：

• ローカル推論：8B〜14B Q4を単一モデルで、中程度の会話長。32Bは高量子化か極短コンテキストなら試せる。
• AI開発：Ollama / MLX / llama.cppの検証、軽量Agent、小規模RAGのプロトタイプ。
• マルチタスク：XcodeやVS Code＋ローカルモデル＋ブラウザ複数タブを、常にアクティビティモニタを凝視しなくてよい程度。
• 使い続ける期間：今後2〜3年で「クラウド中心」から「もっとローカル」へ寄る可能性があるなら、32GBは移行の余白を残しつつ、いきなり最上位に行かなくてよい。

32GBが万能というわけではない。32Bを主力にする、長コンテキストのバッチ推論、画像生成と高解像度出力を並行する——そこまで行くと再び窮屈になる。問題は「動くか」から「安定して快適か」へ移る。

64GB以上：大モデル・長コンテキスト・プロ開発向け

ローカルAIをおもちゃではなく生産ツールとして使うなら、64GBでハードな価値がはっきり出る。次のどれか以上を日常的に含むワークフローが対象だ：

• より大きなモデル：32B主力、70Bの量子化実験、タスク別の多層構成（小モデルでルーティング＋大モデルで仕上げ）。
• 長コンテキストとRAG：埋め込みモデル・ベクトル索引・生成モデルを同時常駐。法律文書、論文、大規模コードベースのQ&A。
• 画像生成：拡散モデル、LoRA、プレビュー並列——VRAM相当の占有がユニファイドメモリで一気に増える。
• データ処理：Pandas / Polarsの大テーブル、Jupyterとローカルモデルの同居、軽量な機械学習実験。
• プロ開発：常時稼働のローカルAPI（Ollama、OpenClawゲートウェイ）、CI横断の推論、複数コンテナの編成。

64GBは「将来みんな必須」という絶対基準ではなく、ワークフローがすでに大きいときの合理的な下限だ。今も主力はクラウドで、ローカルはたまに触る程度なら、想像上の70Bのために先払いする必要はない。

128GBの境界：要件がはっきりしている人だけ

128GBは需要が非常に明確なヘビーユーザー向けだ。たとえば70B級を毎日の主力にする、大規模ローカルRAGを回す、複数モデルを並列サービスする、言語と画像の大モデルを同じマシンに常駐させる——こうした人向け。クラウド中心のクリエイター、14Bを補助に使う開発者、普通のAI愛好家にとって128GBはデフォルトの答えではなく、しばしば過剰投資になる。

128GBが妥当かどうかは、次の三つで見るといい。① 今後12か月、クラウドではなく毎日ローカル大モデルに依存するか？ ② モデル規模とコンテキスト長の具体目標があるか（「いつか使うかも」だけではない）？ ③ 64GBから128GBへの予算増が、専用推論機をもう一台買うより安いか？ 三つのうち二つがNoなら、最上位を追う必要は薄い。

愛好家とプロ開発者：下限はどう違うか

愛好家の最大のリスクはワークフローの不確実さだ。今日は「70Bファイル、かっこいい」と思っても、明日は結局クラウドで済ませる。プロ開発者のリスクは並列とキャッシュの積み上げの過小評価——モデル単体は載るのに、Agent・索引・ビルドを足すとメモリが雪崩する。どちらも「AIなら64GB必須」に縛られる必要はなく、自分の主力モデルと並列スタックに戻って選べばよい。

SSDの設計：内蔵にアクティブ、外付けにライブラリ

SSD容量が効くのは四つだ。モデルファイルの体積、データセットとメディア、開発環境とキャッシュ、そしてメモリ不足時のswapと一時ファイル。原則は「毎日読み書きするもの」を内蔵の高速ディスクに、「大きいがアクセス頻度が低いもの」を外付けやNASへ。

• 内蔵SSDに置く：macOS、アプリ、現在の主力モデル1〜3個、アクティブなデータスライス、Docker/Xcode Derived Data、直近のHugging Faceキャッシュ。
• 外付けSSDに向く：複数サイズのGGUFモデル庫、過去のデータセット、バックアップイメージ、あまり使わないLoRAとcheckpoint。
• 容量の粗算：システムとソフトで80〜150GB。14B〜32Bモデルを複数常備するとさらに20〜80GB。画像・データサイエンスは実データ量で別途。

内蔵256GBは「システム＋ローカルモデル1つ＋外付け庫」ならギリだが、Xcode、Photos、HFキャッシュですぐ逼迫する。AI開発なら内蔵512GBが安心の起点、複数のアクティブモデルを内蔵に置きたいなら1TB。内蔵をケチって全部外付けに寄せると、短期的には安く見えても、読み込み速度とパス管理で長期的に損しやすい。

外付けSSDにモデルとデータセットは置ける。メモリは増やせない

外付けストレージはMacローカルAIでコスパのよい容量拡張になる。ただし何ができて何ができないかをはっきりさせておく：

できること：数十〜数百GBのモデル倉庫を持つ。OllamaやLM Studioのモデルディレクトリとしてマウントする。TB級データセットを置き、必要時だけ読む。Time Machineやコールドバックアップに使う。

できないこと：ユニファイドメモリを増やす。16GBマシンを64GB相当で70Bを走らせる。内蔵の代わりに激しいswap先にする（どれだけ速くても物理メモリより桁が違う）。

外付けからモデルを読み込んでも、推論フレームワークは重みをユニファイドメモリへ載せる（またはmmapしてページインする）。ボトルネックは最終的にメモリ容量と帯域であって、「ファイルが外付けにあるか」ではない。外付けの主役は内蔵容量の節約と、差し替え可能なモデル庫の維持だ。

外付けストレージの落とし穴：速度・接続・放熱・パス

外付けSSDの使い方を誤ると、「ディスクはあるのに内蔵より遅い」「Macを替えたらパスが全部壊れた」「大容量コピーで熱暴走して速度低下」といった症状が出る。選び方と運用の要点：

• 接続：Thunderbolt 3/4・USB4 40Gbpsのエンクロージャを優先。USB 3.0のHDDはアーカイブ向きで、大モデルの頻繁な読み込みには向かない。
• 速度：NVMe＋十分な放熱。安価な筐体は連続読み書きでスロットリングし、初トークン待ちが伸びる。
• 給電と放熱：ノートの単一ポート給電が弱いときは電源付きか低消費ディスクを。筐体が熱いほどスロットリングのサイン。
• バックアップ：モデル庫はコピーできるが、独自データセットとベクトル索引は別途バックアップを。外付け故障＝メモリ上のサービスが自動復旧するわけではない。
• パス管理：OLLAMA_MODELS、シンボリックリンク、各ツールの「モデルディレクトリ」設定で外付けを一本化。バラバラの相対パスはスクリプト破綻の元。
• スリープと取り外し：スリープ前に安全に取り外すか、据え置きノードとして固定運用。推論や書き込み中のホットスワップは避ける。

予算が限られるなら、まずユニファイドメモリを要件に合わせ、外付けSSDでモデル庫を広げる方が、「低メモリ＋内蔵2TB」の組み合わせより、ローカルAIの本当の詰まりどころに合っていることが多い。

シーン別クイック対照：メモリとディスクはどれくらい？

以上は2026年6月時点のApple Siliconユニファイドメモリ構成と一般的な量子化モデルに基づく選び方の枠組みであり、特定モデルが特定ハードで必ず快適に動くという保証ではない。注文前にApple公式で現行機種の選択肢を確認すること。チップ階層（M5 / M5 Pro / M5 Max）は帯域と持続負荷の余裕に影響する。チップとメモリ速度の選び方、ローカルAIプログラミング環境の記事もあわせて読んでほしい。

ユニファイドメモリ構成：ローカルAIノードにMac miniが向く理由

「メモリを先に買い、ストレージを層分けする」という設計をハードに落とすなら、Mac miniはノートより安定した選択肢になりやすい。Apple SiliconのユニファイドメモリはCPU・GPU・Neural Engineが高帯域プールを共有し、量子化大モデルの推論で「専用GPUへコピーする」一手間が減る。筐体は小さく静音で、待機時の消費電力はおおよそ4W級——7×24のOllamaやOpenClawノードとして主力機のメモリを空けられる。macOSはHomebrew、Docker、SSH、主要な推論フレームワークをネイティブに扱え、GatekeeperとFileVaultはローカル重みやRAG文書にもう一段の保護を与える。

32GBの日常ローカルアシスタントでも、64GBの本格RAGでも、専用Mac miniで推論を担い、大モデル庫をThunderbolt SSDに置く構成は、メモリ不足のノートで無理に耐えるより持続しやすい。「動く」と「収まる」の境界が見えたなら、Mac miniはその設計を長く回すコスパのよい起点だ——プランを確認する。メモリ優先・ストレージ層分けの原則で構成を選び、ローカルモデルを静かに安定して走らせてほしい。