MENU
ガジェット実機レビューとデスク構築を追求する検証ブログ
  1. ホーム
  2. PC・ガジェット
  3. AIに環境構築を丸投げしたら「Ollamaは使うな、llama.cppを使え」と言われた話【MacローカルLLM】

AIに環境構築を丸投げしたら「Ollamaは使うな、llama.cppを使え」と言われた話【MacローカルLLM】

PC・ガジェット
Mac miniにローカルllm構築

こんにちは、中のひとアツです。

いよいよM4 Mac miniの到着が目前に迫ってきました！

前回（第2回）の記事では、AIの「使用制限」への怒りを原動力に、AI同士を戦わせて「構築手順を丸投げする神プロンプト」を練り上げる狂気の沙汰をお届けしました。

実は当初の予定では、今回の「第3回」でいよいよ実機での構築編をお届けするはずでした。

しかし、実機到着を前に完成した神プロンプトを使って、実際にAIに「環境構築の手順書」を作らせてみたところ……AIから返ってきた構成案があまりにもピーキーすぎ、かつネットでもあまり情報として出ていない構成だったので、「ローカルLLM初心者の私が、この構成をこのまま丸呑みして本当に大丈夫なのか……？」と急に不安になってしまったのです。

そこで今回は急遽予定を変更し、構成内容チェック記事を追加しました！

実機で構築作業に入る前に、「なぜAIはこの構成を最適解として提示してきたのか？」を、初心者の私がAIに質問攻めにして納得するまでの「アーキテクチャの事前予習」をお届けします。

💡 この記事でわかること

  • M4 MacでAIの力を100%引き出す「最強の構成」の正体
  • 初心者定番の「Ollama」や、便利な仮想環境（Docker等）をAIが全否定した理由
  • 今どきのMacをヘッドレス運用する際の「ダミーHDMI」の最新事情
  • マニアックな専門用語（Metal、uv、GGUFなど）の超ざっくり解説

【連載：M4 Mac miniで最強ローカルLLM環境を作る！】

目次

1. AIに突きつけた「私のわがままな運用要件」

そもそも、私がMac miniを買ってまで、どんな用途でローカルLLMを使いたいのか。AIに神プロンプトを投げる際、以下の条件を伝えました。

  • 主な用途： ブログ記事執筆のための案出しや、構成の組み立て。
  • 必須機能： そのために、自分の過去記事や外部のWebページ（URL）を読み込ませて参照させたい。
  • 接続環境： 外出先のiPhoneや、メイン作業機のMac Studioからネットワーク経由で接続して使いたい。
  • 運用スタイル： Mac mini本体にはモニターもキーボードも繋がず、部屋の隅に置く「純粋なAI専用サーバー（ヘッドレス）」として稼働させたい。

つまり、「どこからでもアクセスできて、Webの知識も読み込める、最高に賢い自分専用のAIサーバーを作れ」という指示です。

【悲報】知ったかぶりで「ダミーHDMI」を提案したらAIに論破される

ここでちょっとした余談（恥ずかしいエピソード）を。

私は昔からの自作PC・ガジェット好きなので、「Macをモニターなし（ヘッドレス）で動かすなら、GPUを有効にするために『ダミーHDMIプラグ』を挿しておくのが常識だぜ」と小耳に挟んでいました。

そこで、ドヤ顔でAIに「ダミープラグも買っておくべきだよね？」と聞いたところ、AIから冷酷なレスポンスが返ってきました。

AI

「不要です。むしろ、かえって邪魔になります。」

えっ！？と驚いて理由を聞くと、AIはこう解説してくれました。

昔のIntel Mac時代は確かにダミープラグが必要でしたが、現在のApple Silicon（Mチップ）と最新macOSは、画面共有でアクセスされた瞬間に「接続元のデバイス（私のiPhoneやMac Studio）に完璧に最適化された仮想ディスプレイ」を自動生成する超優秀な仕様に進化しているそうです。

ここに物理的なダミープラグを挿してしまうと、「解像度がダミープラグの仕様に固定されてしまう」「存在しない画面（ゴーストモニター）にウィンドウが吸い込まれて迷子になる」という、最悪のデメリットしかないとのこと。

「なるほど、今はそんなに進化しているのか……」と、自分のハードに関する知識の古さを痛感させられました。

【裏話】AIの第一候補は「MLX」。私が懇願して構成を変えさせた過去

ダミープラグの一件で完全にAIに主導権を握られた私。しかし、驚きはこれだけではありませんでした。

実はAIが最初に出してきた構成案は、さらに「尖りまくったバケモノ構成」だったのです。

AIの最初の回答はこうでした。

AI

「ブログ執筆という長文処理において、Apple Siliconの限界を引き出すならApple公式のフレームワーク『MLX』一択です。これを使って構築しましょう。」

確かにMLXはAppleが直々に開発しただけあって、Mチップでの推論速度は異次元です。しかし、大きな弱点がありました。それは「MLXは高速ですが、GGUFなど一般的なモデルフォーマットとの互換性がまだ限定的」なことです。

初心者の私にとって、専門的なことはよく分かりません。ただ純粋に、「スマホのアプリみたいに、気分に合わせて色々なAIを手軽に切り替えて遊びたい！」というのが最大の希望でした。そこで私はAIに懇願しました。

アツ

「ごめん、難しいことは分からない！ とにかく色々なLLMを簡単に切り替えて楽しみたいだけなんだ！」

AIは少し（数秒の演算処理で）考えた後、こう返してきました。

AI

「……分かりました。では今回は『llama.cpp』という推論エンジンに妥協しましょう。これなら『Hugging Face』というサイトにある無数のAIモデル（GGUF形式）を簡単にダウンロードして切り替えて使えます。」

アツ

「ハギングフェイス？ なにそれ？」

AI界隈の常識を一切知らない私に、AIは丁寧に教えてくれました。

Hugging Faceとは、AI界隈の「App Store」のような世界最大級のプラットフォームで、世界中の研究者や開発者が作ったAIモデルが無料でシェアされている夢のような場所だそうです。

「なるほど、AIのアプリストアか！そこから落としてくるのね！」

こうして、「初心者のワガママ」と「AIの妥協なきパフォーマンス追求」の折衷案として、AIの「脳みそ」となる推論エンジンはHugging Faceと相性の良い「llama.cpp」に決定しました。

2. 仮想環境を全否定！？AIから突きつけられた「ADR（設計記録）」

推論エンジンが「llama.cpp」に決まったところで、私は「じゃあ、それをどうやってMac上で動かすの？」と手順の続きを確認しました。

実は私、ローカルLLM初心者なりに下調べをするのが好きで、「Dockerは重いから、Macなら軽量なOrbStackを使うのが最近のトレンドらしいぞ」と小耳に挟んでいました。いわゆる「耳年増」な状態ですね（笑）。

そのため、「AIも当然、気を利かせてOrbStackあたりをスマートに提案してくるんだろうな」と予想していました。

しかし、AIが提示してきたのは、OrbStackすら飛び越えた「macOSネイティブ環境で直接動かし、Python周りは『uv』で管理する」という、人生で一度も聞いたことがないストイックな構成。

「えっ、uvって何？ 今どきDockerやOrbStackみたいな便利な仮想環境を使わないの！？」と驚いた私がその理由を尋ねると、AIからプロのアーキテクト（設計者）顔負けの「ADR（アーキテクチャ決定記録）」が返ってきたのです。

仮想化レイヤーによるMetalへのアクセス制限（致命的）

DockerやOrbStack自体が「遅い」わけではありません。問題は、それらがMac上で「Linuxの仮想マシン」を立ち上げて動くことにあります。

Docker / OrbStack環境ではLinux VMが介在するため、Metalを直接扱う構成が複雑になりやすい。そのため、最大性能を狙うならmacOSネイティブ構成がシンプルで有利と判断されました。

Metalのフルパワーを引き出すには、macOSネイティブ（Darwin）環境で直接動かすしかないのです。

※補足：Docker環境でも、推論エンジンをホスト側で動かし、UIだけをコンテナ化する構成は可能です。ただし今回は「構成を極限までシンプルにし、Metalの性能を最大限引き出す」ことを優先してネイティブ構成を採用しました。

なぜ大本命の「Ollama」すら却下されたのか？（llama.cppとの比較）

AIの「仮想環境はMacのGPU（Metal）が使えないからダメ」という理屈は分かりました。

しかし、耳年増な私はここで気づきます。

「待って。仮想環境がダメなら、Mac用のネイティブアプリとしてインストールできる『Ollama（オラマ）』を使えばいいじゃん！ 初心者なら絶対Ollamaでしょ！」

Ollamaは、現在ローカルLLM界隈で最も人気のあるワンクリック導入ツールです。Macネイティブで動くならMetalの恩恵も受けられるはず。なぜAIはこれを提案しなかったのでしょうか？

私が食い下がると、AIは「Ollama」と「llama.cpp（AIの推奨）」の比較表を突きつけてきました。

比較項目llama.cpp 単体 (AI推奨・今回採用)Ollama (初心者定番・非採用)
中身の正体大元となる「推論エンジン」そのもの実は裏側で「llama.cpp」を動かしている
導入の難易度難しい（黒い画面で手動コンパイル）超簡単（ワンクリックインストール）
推論速度(Metal)M4用にチューニング可能Ollamaは汎用設定でビルドされているため、微妙に最適化の余地がある可能性があります。
最新モデル対応即日（本家なので最速）タイムラグあり（Ollama側の対応待ち）
モデルの管理透明（DLしたGGUFファイルを置くだけ）Ollamaは独自のモデル管理方式を採用しているため、ファイルの実体が少し分かりにくい構造になっています。

AIは冷静にこう告げました。

AI

「Ollamaは素晴らしいツールですが、その正体は『llama.cppを初心者向けに使いやすく包んだ（ラップした）アプリ』です。
M4 Macの性能を引き出すなら、わざわざラップされたアプリを通さず、中身の『llama.cpp』をあなたのM4チップ専用に直接コンパイル（ソースビルド）するべきです。」

アツ

「ソ、ソースビルド！？ いやいやいや、私プログラマーじゃないただの素人だよ！？ 黒い画面に謎の文字打ち込んで失敗したらどうするのさ！絶対やりたくない！」

全力で拒否反応を示す私に、AIは「Ollamaを避けるべき決定的な理由」と「ある提案」をしてきました。

1. M4チップ専用の究極のMetalチューニング

Ollamaは「どのMacでも動く」ように汎用的な設定でコンパイルされています。しかし、llama.cppを自分でソースビルドすれば、手元のM4チップのアーキテクチャに合わせた限界突破のチューニングが可能になります。

2. ブラックボックスな容量管理の排除（ストレージ問題の解決）

Ollamaはワンクリックでモデルをダウンロードできて便利な反面、数十GBもある巨大なAIモデルのデータが「OSの深い隠しフォルダ」に保存されます。初心者ほど「どこに何ギガ使っているか分からない！」とパニックになりがちです。

llama.cpp単体なら、指定フォルダにダウンロードしたファイルをポンと置くだけ。不要になったらゴミ箱へ入れるだけで、完全に自分のコントロール下に置けます。

3. SOTA（最新）モデルへの即日対応

昨日出たばかりの最新モデルを使いたいと思った時、Ollamaだと本体がアップデート対応するまで待つ必要がありますが、本家であるllama.cpp単体なら即座に最新モデルを試せます。

ぐうの音も出ないほどの正論。さらにAIはこう続けました。

AI

「それに、ソースビルドと言っても心配無用です。私（AI）がM4 Macに最適化したコマンドを1行ずつ手順書として出力します。
あなたはそれをターミナルに『コピペ』するだけで済みます。」

アツ

「……なんだ、AIの言う通りにコピペしていけば何とかなるのか。ならいけるっしょ！」

持ち前の楽観主義と、「最悪、失敗したらMacを初期化してやり直せばいいや」という甘い考えが発動し、私はこの「ADR」を前に完全に白旗を揚げました。

※実際の推論速度はモデルやビルド設定によって変わるため、Ollamaとllama.cppで大きな差が出るわけではありません。今回は「構成の透明性」と「最新機能への追従速度」を重視してllama.cppを選択しました。

AIの「顔」となるOpen WebUI。なぜここでも仮想環境を使わないのか？

さて、「脳みそ」となる推論エンジン（llama.cpp）の準備方針は決まりました。

しかし、このままでは黒い画面（ターミナル）でしかAIと会話できません。ここで登場するのが、私の要件であった「iPhoneからのアクセス」や「Webブラウザでの快適なチャット画面」を実現するフロントエンド（顔）の役割を果たす「Open WebUI」です。

Open WebUIはPythonという言語で作られた非常に高機能なアプリです。普通、こうしたアプリを動かす時は「Dockerでサクッとコンテナを立ち上げる」のが最近の常識です。

しかしAIはここでもDocker（OrbStack）を許さず、「Open WebUIは『uv』というツールを使って、Mac上で直接動かしなさい」と指示してきました。

なぜなのか？理由はとてもシンプルでした。

1. 遅延のない直接通信

脳みそ（llama.cpp）がMacのネイティブ環境で動いているのに、顔（Open WebUI）だけをわざわざ仮想環境（Docker等の中）に隔離してしまうと、両者の通信に不要な壁ができて遅延の元になります。

2. 爆速ツール「uv」の存在とユニファイドメモリの節約

Rustという言語で書かれた uv は、Pythonの環境を爆速で整えてくれる現在世界中で大流行中の超便利ツールです。これを使えば、Dockerのような重い仮想環境を立ち上げずとも、MacのOSを汚すことなく綺麗にOpen WebUIだけを分離してインストールできます。

OSの余分な負荷がゼロになるため、「32GBのユニファイドメモリのうち、OSの安定動作に最低限の領域を残し、残りの20GB強をまるまるAIのGPU推論用メモリとして全振りする」というシビアな限界設計を、1バイトの無駄もなく実現できるわけです。

つまり、脳みそ（llama.cpp）も顔（Open WebUI）も、間に余計なものを一切挟まず、Macネイティブの力でゴリゴリに動かす！というのが、今回の最強構成の全貌なのです。

3. 初心者向け：この記事の「専門用語」ざっくり解説事典

ここまでAIのガチすぎる解説を読んできて、「横文字ばっかりで頭が痛い……」と思った方、安心してください。私もそうです！

これからローカルLLMに挑む皆さんのために、今回の記事で登場したマニアックな専門用語を、初心者向けにざっくりと翻訳しておきます。

専門用語ざっくり言うと？（アツの超訳）
ローカルLLMクラウドではなく、自分のパソコンの中で直接動かすAIのこと。制限なしで使い放題！
ユニファイドメモリCPUとGPU（画像処理）で同じメモリを共有するApple Silicon特有の賢い仕組み。
GPU用メモリAIが思考するために使う「作業机の広さ（メモリ）」。MacはユニファイドメモリをGPU用メモリとして大量に割り当てられるのが最強の強みです。
Metal APIMac専用の「GPUを超高速で動かすためのルール」。
仮想環境（Docker / OrbStack）Macの中に「別のパソコン（Linux）」を作り出す技術。便利ですが、Linuxの壁に阻まれてMetal（GPU）がフルに使えなくなります。
ソースビルド（ネイティブ）完成品のアプリをDLするのではなく、設計図から「自分のM4 Mac専用」に直接組み立てること。AIがくれたコマンドをコピペすればヨシ！
Ollama（オラマ）初心者でもワンクリックでAIを動かせる超定番アプリ。実は裏側で「llama.cpp」が動いています。
Hugging FaceAIモデルの「App Store」。世界中の頭のいい人たちが作ったAIモデルが無料でダウンロードし放題の神サイト。
llama.cpp / GGUF今回採用したAIの「脳みそ」（エンジン）と、定番の「ファイル形式」。
Open WebUI今回採用したAIの「顔」。ブラウザ上でChatGPTのような画面を提供してくれます。
uv（ユーブイ）仮想環境（Docker等）を使わずに、Open WebUI（Python）をMac上で綺麗に動かしてくれるpip / venv / virtualenv の代替として開発されたRust製ツール。

4. 初心者でも大丈夫？実は管理がラクな理由とFAQ

AIに言われるがまま「ソースビルド」や「コマンド操作」を受け入れた私ですが、「構築できた後の日々の保守管理は大丈夫なの？」と不安になりました。

しかしAIは、「ブラックボックスになりがちなOllama等と比べ、構造がシンプルなので、実はアップデートやトラブル対応がラクな構成です」と断言しました。

日々のメンテナンス・ワークフロー

① 「顔」のアップデート（Open WebUI × uv）

uv を使っているため、環境競合に怯える必要がありません。コマンド2行をコピペするだけで数秒で完了します。

Bash

cd ~/llm-server/open-webui
source .venv/bin/activate
uv pip install --upgrade open-webui

② 「脳みそ」のアップデート（llama.cpp）

開発スピードが異常に速いllama.cpp。Ollama本体のアップデート対応を待つ必要はなく、最新データを引っ張ってきて再ビルドするだけ。M4のCPUなら一瞬です。

Bash

cd ~/llm-server/llama.cpp
git pull
# macOS向けにMetalを有効化して構成し、並列ビルド
cmake -B build -DGGML_METAL=ON
cmake --build build --config Release -j

③ モデルの追加・削除

先ほども書いた通り、Hugging Faceからダウンロードした「.ggufファイル」を、指定したフォルダにポンと置くだけ。不要になったらゴミ箱へ入れるだけです！

よくある質問（FAQ）

初心者の私が抱いた疑問をFAQにまとめました。

やっぱり初心者にはOllamaの方がいいですか？

「とりあえず動かしてみたい」という方にはOllamaが圧倒的におすすめです！しかし、M4 Macの性能を100%引き出したい、最新のモデルを最速で試したい、限られたストレージを自分で管理したいという「沼」に足を踏み入れるなら、今回のネイティブ構成に挑戦する価値は十分にあります。

黒い画面（コマンド操作）でエラーが出たらどうするの？

もし構築中にエラーの壁にぶつかって泣きそうになっても大丈夫です。第2回で作った「神プロンプト」を使って、エラー画面のスクショごとGeminiに泣きつけば、手取り足取り解決策を教えてくれるはずです。

M1やM2 Macでも、同じ「ネイティブ＋uv」構成にするべき？

はい！Apple Silicon（M1〜M4）であれば構造は同じです。AI曰く、どの世代のMacであっても、速度とRAM効率を最大化したいならこの構成が圧倒的におすすめとのことです。

5. まとめ：AIの妥協なき提案に納得！いざ実践へ！

いかがでしたでしょうか。

当初の予定を変更してまで急遽挟んだ今回のチェック記事。「ダミーHDMIプラグ」や「OrbStack」の件で知識の古さや耳年増っぷりを痛感し、「ソースビルドなんて絶対やりたくない！」と駄々をこねた初心者の私でした。

しかし、AIが突きつけてきた「アーキテクチャ決定記録（ADR）」を読み解くことで、この構成が結果的に最も理にかなっていると完全に納得できました。

  • 脳みそ（llama.cpp）：ソースビルドでM4専用に極限チューニングし、Metalのフルパワーを解放する！
  • 顔（Open WebUI）：仮想環境を避け、「uv」を使ってMac上で直接綺麗に動かす！
  • 全体：無駄な処理を一切省き、32GBのユニファイドメモリをAIのRAMに全振りする！
  • （※作業はAIのコマンドをコピペするだけ！）

この「事前予習」をもって、私の中での心の準備は完全に整いました。不安も消え去り、あとは主役である「M4 Mac mini」の到着を待つのみです。

次回、【シリーズ第4回：LLMの検証編】。

次は神プロンプトが選んだLLMは本当に私の環境に合っているのか、最近のLLMを比較検討していきます！

PC・ガジェット
M4 Mac MLX Ollama OrbStack uv サーバー ローカルLLM
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

コメント

コメントする

コメントは日本語で入力してください。(スパム対策)

目次