10 秒結論（Runbook）
Claude Code は常に Ollama（:11434）。MLX はオフライン計測とモデル検証のみ。
本記事の規範（Claude Code / Cursor ローカルモデル）では、選択はランタイム層だけ。既定かつ推奨は Ollama。第三の「公式ルート」はない。
Ollama vs MLX を聞く人の多くはランタイム層の話をしている。Claude Code ローカルモデルの答えは次のとおり。
覆らない結論
Claude Code のデフォルトスタックは Ollama だけ。 MLX は本記事の Agent ランタイム選定に参加しない（ベンチマーク・CI・研究のみ）。
- ランタイム（Claude Code / ローカル API） → Ollama のみ
- オフライン（計測 / CI / 研究） → MLX
- M4 Mac Mini ローカル LLM · 16GB → まず 7B クラス、その後
ollama serve
一覧で見る違い（比較表はこれだけ）
M4 Mac Mini ローカル LLM で Claude Code ローカルモデル（Ollama vs MLX） を見るとき、まず下の二行「致命次元」— MLX は「代替ランタイム」ではなく、Agent 経路に入れないツール。
| 次元 | Ollama | MLX |
|---|---|---|
| Agent ランタイムになれるか（Claude Code / Cursor / tool loop） | ✅ | ❌ |
| Claude Code が追加胶水なしで使えるか（zero glue code） | ✅ :11434 | ❌ 自前ゲートウェイ必須 |
| 組み込み HTTP 推論サービス | ✅ | ❌（本記事では自前 GW 非推奨） |
| tok/s（8B、swap なし） | 基準 | おおよそ +3 % ～ +12 %（オフライン参考のみ） |
チーム ollama serve | ✅ 標準 | ❌ Agent 経路外 |
上二行が生死線。tok/s は 下文、Claude Code ランタイム選定には使わない。
核心的な誤解：9 割が間違った質問をする
Ollama vs MLX で「どちらが速い？」と聞く人が多いが、M4 Mac Mini ローカル LLM では誤った質問。
Claude Code ローカルモデル でも同じ。本当の問いは：
このモデルは本番ランタイムとして Agent に使えるか？
順序を間違えた（先に 7B/14B・メモリ）→ 文頭 特集ルート。
MLX 派のよくある誤判断（転換の要点）
ベンチで Apple Silicon 推論 が MLX やや有利だから Claude Code の後ろに繋ぐ — 誤り。
Claude Code のボトルネックは tok/s ではなく、たいてい：
- 安定した HTTP serve（
:11434） - 複数回の tool loop における遅延とタイムアウト
- context / モデル tag の管理とチーム共有
Claude Code / Cursor にとって MLX はランタイムバックエンドにしない。FastAPI で HTTP を包むのは自前実装の胶水層で、運用コストは多くの場合 Ollama 直結より高い。
Claude Code ランタイムの三層（選択は中間層だけ）
Claude Code ローカルモデル の正しいモデルは「Ollama と MLX の二択」ではなく三層分担：
| 層 | 内容 | 選択？ |
|---|---|---|
| アプリ層 | Claude Code、Cursor、Agent tool loop | いいえ（ここで作業） |
| ランタイム層 | Ollama（本記事の唯一の推奨） · HTTP :11434 | はい — 本規範は Ollama 固定 |
| 計算層 | MLX · オフライン計測 / CI / 研究 | いいえ（Claude Code 主経路外） |
選択はランタイム層だけ。計算層ではない。 Claude Code ローカルモデル向け読者にとって、MLX が速くてもランタイム結論は変わらない。
Claude Code でローカルモデル（実践）
Claude Code ローカルモデル のデフォルト：ANTHROPIC_BASE_URL → ローカル Ollama :11434。MLX はこのチェーンに入らない。
brew install ollama
ollama pull qwen2.5-coder:7b
ollama serveexport ANTHROPIC_BASE_URL=http://127.0.0.1:11434
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=設定後 Claude Code はローカルモデル経由。または ollama launch claude --model qwen2.5-coder:7b。課金・チーム → Claude Code + Ollama 実測。
16GB M4 Mac Mini では強く推奨
- 7B モデル（例
qwen2.5-coder:7b） - 14B + Chrome + IDE でメモリを常時圧迫しない
- MLX に替えても swap は「最適化」されない
MLX が速いことがある理由（ランタイム判断は変わらない）
以下の数字は Ollama vs MLX の Apple Silicon 推論 計測差の説明のみ — 「Claude Code → Ollama のみ」は変わらない。
- MLX：Metal カーネル直叩き + 配列計算
- Ollama：llama.cpp + HTTP + ランタイムのサービス層
MLX はサービス殻が薄い — 差は通常小さい：
- 16GB：おおよそ 0 %～5 %
- 24GB：おおよそ 5 %～8 %
- 48GB：おおよそ 8 %～12 %
注： 区間は Macstripe Lab 傾向（Llama-3.1-8B 4-bit、2026 年 6 月）、選定には使わない。16GB Ollama 約 27–31、MLX 約 28–32 tok/s；48GB Ollama 約 72–78、MLX 約 80–88 tok/s。手法 → Hub 実測。
Claude Code に Ollama しかない理由
M4 Mac Mini ローカル LLM の日常開発で、Claude Code が気にするのは生成速度だけではない：
| 指標 | Agent にとって |
|---|---|
| tok/s | 低 |
| API の安定性 | 高 |
| tool loop 遅延 | 極めて高 |
| 保守性（pull / serve / 共有） | 極めて高 |
Agent の接続方法 ≫ 数ポイントの推論差。
実際に起きた失敗（16GB · M4 Mac Mini ローカル LLM）
Claude Code ローカルモデル の日常負荷で同時実行：Claude Code · Ollama qwen2.5-coder:14b · Chrome（約 15 タブ）· VS Code（m4-16gb-lab-01、2026-05-28）。
- メモリ圧力：赤
- swap：8GB 超
- tok/s：約 28–31 → 一桁
- Claude Code：タイムアウト
結論： MLX / Ollama の問題ではなく、メモリ段階とモデルサイズの選び間違い。→ 7B vs 14B
2026 推奨モデル組み合わせ（実践）
| シナリオ | 推奨 |
|---|---|
| Claude Code | qwen2.5-coder:7b |
| 汎用 Agent | Qwen3 8B（ollama pull qwen3:8b） |
| 推論向け | DeepSeek-R1 distill |
| 計測対照 | Llama 3.1 8B |
M4 Mac Mini ローカル LLM チーム：1 台で ollama serve、全員の Claude Code を同一 :11434 へ；MLX はそのマシンで夜間計測のみ、Agent には接続しない。
最終ルール（本記事 Runtime Spec）
Claude Code / Cursor / 標準 Agent tool loop では、ローカルモデルは HTTP 推論ランタイム を持つ層へ — 本規範では Ollama。MLX は計算層ツールで、Agent ランタイムは箱から出ない；本記事は 「MLX + 自前 HTTP」 を Claude Code の推奨構成に載せない。
エンジニアリング留保： ごく稀な 自社 Agent ランタイム（Claude Code / Cursor 以外、自前 GW と SLA）では MLX + 自前 HTTP もあり得る — 本記事の範囲外で、Claude Code ローカルモデルへの上記結論は変わらない。
FAQ
MLX で HTTP を自前構築して Claude Code に繋げる？
Claude Code 向け：非推奨。 技術的には可能だが、互換層・モデル管理・安定性を背負う — 多くの場合 Ollama 直結より重い。自社 Agent 基盤（Claude Code 以外）は MLX+HTTP もあり得るが、本記事では推奨構成にしない（留保条項参照）。
MLX は Ollama を置き換えられる？
本規範ではいいえ。 Claude Code / Cursor の推奨ランタイムは Ollama；MLX はオフライン計測用で、Agent 接続の 代替にならない。
Ollama は遅い？
swap なし・同一モデル計測では Ollama が数ポイント遅いこともある。日常のコーディング・Agent では ほぼ体感できない — ボトルネックは接続とメモリ。
24GB と 48GB の選び方？
24GB：7B / 8B、個人または軽量 Agent。48GB：14B、複数人共有、長い num_ctx。マシン更新の効果は Ollama↔MLX より大きいことが多い。
MLX が必須になるのはいつ？
ベンチマーク、CI 回帰、研究スクリプト（夜間 tok/s、新量子化、mlx-community 検証）のみ。Claude Code ランタイムには入れない；同一 Mac に MLX があっても Agent は Ollama のみ。
意思決定パス（まとめ）
詳細 → 最終ルール。設定 → Claude Code + Ollama（Step ④）。
メモリノード（必然の導出、主観の推奨ではない）
前提（固定）：ランタイム = Ollama（Claude Code ローカルモデル規範）
負荷：Claude Code（Ollama）+ 14B + 複数人 tool loop + ollama serve
唯一のボトルネック：ユニファイドメモリ — 重み + KV + コンテキスト + IDE/ブラウザが同一プール
結論（導出）：24GB / 48GB 専有 M4 推論ノードが必要 — 「MLX を選ぶ」ではなく メモリ段階不足
16GB は個人 7B + ローカル Ollama；14B 共有に入ると変数は「Ollama vs MLX」から「ユニファイドメモリは足りるか」へ → Macstripe 24GB/48GB + ollama serve クラスタ。
最終結論
Apple Silicon 上で Ollama vs MLX は対等な選択ではない：Agent は Ollama、計測は MLX；本当に止めるのは M4 Mac Mini ローカル LLM のメモリ段階とモデルサイズ。
