ローカル環境で LLM を動かす、という選択肢が現実的になってきました。
これまでは ChatGPT のようなクラウド AI を使うのが前提でしたが、最近では、自分の PC 上でモデルを動かす構成も普通に選択肢に入ってきています。
その中でも、
- Ollama（ローカルLLM 実行環境）
- OpenClaw / Claude Code（ AI エージェント）
などを組み合わせることで、「ローカルで AI に作業をさせる」環境が作れるようになりました。
この記事では、
Mac mini M4 32GB / 1TB という環境で
- 実際にどこまで動くのか
- どこが限界なのか
を、実際の検証ベースで整理していきます。
Mac mini M4 でローカル LLM は実際に動くのか
結論から言うと、「普通に動く」です。
今回の環境は以下の通りです。
- Mac mini M4
- メモリ：32GB（ユニファイドメモリ）
- ストレージ：1TB
この構成で、以下のモデルを実際に動かしています。
- gpt-oss:20b
- qwen3.5:9b
- glm-ocr
- qwen3.5:35b-a3b-coding-nvfp4
特に印象が変わったのは、「35B クラスが普通に動いたこと」です。
少し前までは、35B = ハイスペック環境前提という感覚でしたが、今はギリギリではあるが実用ラインまで降りてきています。
もちろん余裕があるわけではありませんが、
- 起動できる
- 応答が返る
- エージェントとも連携できる
この時点で、実用としては十分成立しています。
なぜ 32GB メモリを選んだのか（予算とのバランス）
今回の構成を決める上で、一番大きかったのは「予算」です。
想定していたラインは、おおよそ 20万円前後。
この条件の中で考えたときに、
- M4 Pro（24GB）
- 無印 M4（32GB）
という選択肢になります。
ここで重視したのは「メモリ容量」です。
結果として、CPU / GPU性能よりもメモリの余裕を優先という判断になりました。
理由はシンプルで、ローカルLLM はメモリ依存が大きいからです。
実際に使ってみると、
- モデルをロードできるかどうか
- 長い文脈を保持できるか
- エージェントが安定するか
このあたりは、ほぼメモリで決まります。
ストレージも同時にカスタマイズした（512GB → 1TB）
もう一つ、同じくらい重要だったのがストレージです。
最初は 512GB で考えていましたが、検討の途中で 1TB に変更しました。
理由はシンプルで、モデルを複数試す前提だと、512GBでは足りなくなる可能性が高いと判断したためです。
実際、LLM は1つあたり数GB〜数十GBあるため、
- 複数モデルを並行して検証する
- 用途ごとにモデルを使い分ける
といった使い方をしていくと、ストレージは想像以上に消費されます。
外付け SSD ではなく内蔵を選んだ理由
当初は、「512GB + 外付けSSD」という構成も検討していました。
ただ、ここで一度整理すると、
- 高速な外付けSSD（40Gbps）＋ケース → 約3万円
- 内蔵 512GB → 1TB アップグレード → 約3万円
と、コストがほぼ同じでした。
この条件であれば、
- 配線不要
- 速度も安定
- 管理もシンプル
という理由から、内蔵ストレージを増やす方が合理的と判断しました。
今回の構成の整理
最終的な判断は以下の通りです。
- 予算制約あり → M4 + 32GB + 1TB が現実解
- 予算に余裕あり → M4 Pro + メモリ増設で OK
- さらに余裕あり → Mac Studio も視野
ここは「どっちが上か」ではなく、どこにリソースを振るかという話になります。
今回のケースでは、
- メモリ → モデルを動かすための余裕
- ストレージ → 複数モデルをダウンロードするための余裕
この2つを優先した形です。
35B モデルはどこまで現実的か
今回一番検証したかったのがここです。
qwen3.5:35b-a3b-coding-nvfp4 を中心に使ってみた結果としては、「普通に使えるが、余裕はない」というラインです。
体感としては、
- 軽量モデルより明らかに精度が高い
- 指示の理解が深い
- 修正時のブレが少ない
一方で、
- 他アプリと同時使用は厳しい
- メモリは常にギリギリ
という制約があります。
ただ、それを踏まえても、「メインで使えるレベル」には入っています。
以前のような「試すだけの存在」ではなく、実際の作業に組み込めるラインです。
エージェント運用（OpenClaw / Claude Code）の実際
ローカルLLM の価値が一気に上がるのが、ここです。
単なるチャットではなく、
- コード生成
- ファイル操作
- 自動処理
といった「作業」を任せる使い方になります。
実際に使ってみた印象としては、
- OpenClaw → 動くが少し不安定
- Claude Code → 比較的安定
という感触です。
特に感じたのは、モデル性能がそのまま体験に直結するという点です。
軽量モデルだと、
- 途中で崩れる
- 指示がズレる
といった問題が出やすいですが、35B クラスになるとかなり安定します。
そのため、エージェント用途ならできるだけ重いモデルを使う、というのが現実的な運用になります。
実運用で気づいた制約と最適化
32GB あれば十分、とは言い切れません。
実際には、かなりシビアです。
そのため、いくつかの最適化はほぼ必須になります。
メモリ周り
- 状況に合わせて Docker コンテナを停止
- ブラウザタブを最小限に
- 不要アプリは閉じる
OS設定
- 通知オフ
- ウィジェット削除
- バックグラウンド削減
運用の考え方
- 「LLM を使う時間」を分ける
- 同時作業を減らす
このあたりをやるだけで、体感はかなり変わります。
逆に言うと、何も考えずに使うと普通にキツいです。
コスト感と構成の考え方
今回の構成は、Mac mini M4 32GB / 1TB 約 21万円でした。
ここにディスプレイ、キーボード、マウスなどを加えると、トータルで 23〜25万円程度になります。
この金額をどう見るかですが、
- API 課金を気にしなくていい
- ローカルで完結できる
- 試行回数を増やせる
という点を考えると、「投資としては成立する」という判断です。
特に、試行錯誤の回数が多い人ほどメリットが出ます。
まとめ
Mac mini M4 32GB でのローカルLLM は、「普通に使えるライン」に入っています。
特に印象が大きかったのは、
- 35B モデルが現実的に動く
- エージェント運用が成立する
- ローカルで完結できる
この3点です。
もちろん、
- メモリは常にギリギリ
- 速度や性能はクラウドに劣る
- 運用の工夫は必要
といった制約はあります。
それでも、
- API 課金を気にしなくていい
- 自分の環境で完結する
- モデルを自由に試せる
というメリットはかなり大きいです。
現時点の結論としては、
- 基本は 35B を軸にする
- 軽量モデルを補助的に使う
- メモリは 32GB 以上を前提にする
この形が一番しっくりきています。
ローカルLLM はまだ発展途中ですが、「実験」から「実用」に入ってきた段階だと感じています。
