Ollamaとllama.cppは、しばしば「ローカルLLMを動かす二択」として並べられるが、その理解は半分正しく半分間違っている。 ローカルLLMを触り始めると、必ずこの2つの名前に出会う。「1コマンドで動くOllama」と「速いと評判のllama.cpp」。どちらで動かすべきか——そう身構えて調べ始めると、多くの記事が「Ollamaは手軽、llama.cppは高速」という粗い対比で終わっていて、かえって混乱する。
実際には、llama.cppはGGUFモデルを動かすC/C++製の推論エンジンそのものであり、Ollamaはそのllama.cpp由来の技術（ggml）を土台に、モデル取得・実行・API公開を1コマンドに畳んだ配布層だ。つまり両者は多くの場面で「競合」ではなく「土台と外装」の関係にある。この記事では、llama.cppとOllamaのそれぞれのやること、両者の関係、7つの軸での違い、そして「どちらを選ぶべきか」「どう併用・移行するか」を、公式リポジトリで裏取りしながら整理する。二択の霧が晴れれば、手軽さと制御性のどちらを取るかの判断は驚くほど単純になる。
ローカルLLMを1コマンドで動かすOllama単体の導入から実運用は Ollama入門2026｜Mac/Windows/Linuxでローカル大規模言語モデルを動かす完全ガイド で詳しく解説しています。本記事はそのOllamaと、土台にあるllama.cppを比較する視点編です。
この記事のポイント（30秒でわかるOllamaとllama.cpp）
・llama.cppとは？ GGUFモデルをCPU/GPUで動かすC/C++推論エンジン。ggmlが心臓部で、llama-cli・llama-serverなどのバイナリを提供。ライセンスMIT
・Ollamaとは？ そのllama.cpp/ggml系の技術を土台に、モデルレジストリ＋1コマンド実行＋OpenAI互換APIを被せた「配布層・外装」
・関係は？ 競合ではなく積層。多くのOllamaはllama.cpp由来のggmlの上に立つ。GGUFという同じモデル形式を共有する
・どちらを選ぶ？ 手軽さ・API公開・チーム配布ならOllama、量子化やGPUオフロードの細かな制御・組込み最小構成ならllama.cpp
・現実解 まずOllamaで動かし、チューニングやベンチの限界に当たった箇所だけllama.cppに降りる
・共通点 どちらもMITライセンス、GGUFモデル、ローカル完結・データ非送信という強み
まず全体像を1枚で掴んでおこう。下図のように、両者は上下に積み重なる「土台と外装」の関係にあり、同じGGUFモデルを共有している。この構図が頭に入っていれば、以降の細かな違いはすべて「どのレイヤーの話か」で整理できる。
Ollamaとllama.cppの関係——先に結論「土台と外装」
当サイトの読者が新しいツールに対して知りたいのは、いつも同じ3つだ。「結局それは何ができて、何を解決し、何を代替するのか」。Ollamaとllama.cppをこのフレームで先に整理する。
① それぞれ何ができるのか。 llama.cppは、GGUF形式に変換・量子化された大規模言語モデルを、手元のCPUやGPUで推論するための実行エンジンだ。C/C++で書かれ、外部依存を極力持たず、幅広いハードウェアで動く。一方Ollamaは、そのエンジン技術を土台に、モデルを ollama.com のレジストリから pull し、ollama run の1コマンドで起動し、OpenAI互換APIまで自動で公開する管理ツールである。
② 何を解決するのか。 llama.cppは「巨大なLLMを、GPUクラスタなしに個人のマシンで動かす」という計算資源の問題を解いた。量子化とggmlの最適化により、数十GB級のモデルをノートPCやApple Siliconで走らせられる。Ollamaはその上で、「ビルド・依存関係・モデル変換・API化といったセットアップの面倒」を解決する。つまり解決している層が違う。
③ 何を代替するのか。 両者ともクラウドLLM APIを、開発・検証・機密データ用途でローカルに置き換える。違いは抽象度で、llama.cppは推論ランタイムそのものを、Ollamaは「ローカルLLMを扱う開発者体験」全体を提供する。Dockerにたとえると分かりやすい。llama.cppがコンテナランタイム（実行の中核）なら、Ollamaは docker run とDockerHubとDocker Desktopを合わせたような、取得から実行までの一体化された体験に当たる。
この関係を1枚の積層図にすると、両者が競合ではなく重なっていることがはっきりする。
モデルレジストリ＋1コマンド実行
OpenAI互換API（:11434）"] end subgraph L2["推論エンジン層"] LC["llama.cpp
llama-cli / llama-server
GPUオフロード・量子化・バッチ"] end subgraph L1["数値計算コア層"] G["ggml テンソルライブラリ
CPU/Metal/CUDA/Vulkan カーネル"] end subgraph M["モデル層（共通）"] GGUF["GGUF 量子化モデル
Q4_K_M / Q5 / Q8 ..."] end O -->|土台として利用| LC LC -->|演算を委譲| G GGUF -->|ロード| LC GGUF -->|ロード| O
図の通り、GGUFという同じモデル形式を両者が読み込み、Ollamaはllama.cpp（そしてその中核のggml）を土台にしている。だから「Ollama vs llama.cpp」という問いの多くは、正確には「配布層で完結させるか、推論エンジンまで自分で触るか」という、抽象度をどこに置くかの選択なのだ。
llama.cppとは——ローカルLLM推論の心臓部
まず土台のllama.cppから見る。llama.cppは、Georgi Gerganov氏が始めたC/C++実装の推論エンジンで、いまローカルLLM分野の実質的な基盤技術になっている。設計思想は「最小限のセットアップと、幅広いハードウェアでの最先端の性能」。外部ライブラリへの依存を避け、単体で動くことを重視している。ライセンスはMITだ。
llama.cppが提供する主なバイナリ（ツール）は次の通り。単なるライブラリではなく、そのまま使える実行ファイル群が付いてくるのがポイントだ。
| ツール | 役割 |
|---|---|
llama-cli |
テキスト補完・対話・文法制約付き生成を行うCLI本体 |
llama-server |
OpenAI API互換の軽量HTTPサーバ。マルチモーダルや投機的デコードにも対応 |
llama-bench |
各種パラメータでの推論性能を測るベンチマーク |
llama-perplexity |
モデルの品質指標（perplexity）を測定 |
llama-quantize |
モデルを各種ビット幅に量子化して容量と速度を最適化 |
対応するハードウェアバックエンドが非常に広いのもllama.cppの強みだ。Apple SiliconのMetal、NVIDIAのCUDA、AMDのHIP、ベンダー非依存のVulkan、IntelのSYCL、ブラウザ向けWebGPU、そしてBLAS経由のCPU専用まで網羅する。量子化も1.5bitから8bitまで幅広く選べ、メモリと速度のトレードオフを細かく刻める。
動かし方はシンプルだ。ビルド（cmake）またはリリースバイナリを入手し、GGUFモデルを指定して実行する。Hugging Faceから直接引く -hf フラグも用意されている。
# ビルド（例: Apple Silicon / Metal 有効）
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release -j
# ローカルのGGUFモデルで対話
./build/bin/llama-cli -m ./models/gemma-3-1b-it-Q4_K_M.gguf -p "自己紹介して"
# Hugging Faceから直接引いて実行
./build/bin/llama-cli -hf ggml-org/gemma-3-1b-it-GGUF
サーバとして立ち上げれば、OpenAI互換の /v1/chat/completions エンドポイントが開く。ここはOllamaと機能的に重なる部分だ。
# OpenAI互換HTTPサーバを起動（既定 :8080）
./build/bin/llama-server -hf ggml-org/gemma-3-1b-it-GGUF --port 8080
# GPUに30層オフロード、コンテキスト8192で起動する例
./build/bin/llama-server -m ./models/qwen3-14b-Q4_K_M.gguf \
--n-gpu-layers 30 --ctx-size 8192 --port 8080
--n-gpu-layers（GPUに載せる層数）や --ctx-size（コンテキスト長）のような細かなノブを直接回せるのがllama.cppの本質的な自由度だ。VRAMぎりぎりまで層を積む、特定の量子化を選ぶ、バッチサイズを詰める——こうした最適化を自分の手で行える。裏を返せば、これらを自分で理解し設定する必要がある、ということでもある。
この「細かく選べる」の代表例が量子化タイプだ。同じ14Bのモデルでも、Q8_0（8bit・高品質・容量大）、Q5_K_M（5bit・バランス型）、Q4_K_M（4bit・省メモリの定番）、Q3_K_M（3bit・限界まで小さく）といったバリアントがあり、ビット幅を下げるほどファイルは小さくVRAM消費も減るが、品質はわずかずつ落ちる。llama.cppでは目的のGGUFを選ぶ（または llama-quantize で自作する）ことで、この容量・速度・品質のトレードオフを自分の手元で刻める。Ollamaはここを「多くの人にとって無難なQ4系」に寄せて自動で選んでくれるため楽な反面、「あえてQ5で品質を上げたい」「Q3で無理やり載せたい」といった尖った選択はllama.cppの直接指定に分がある。VRAMと品質のどちらを優先するかを自分で決めたい局面こそ、土台に降りる価値が出る場面だ。
Ollamaとは——llama.cppを「1コマンド」に畳んだ配布層
次に外装のOllama。Ollamaは、まさに前節でllama.cppを動かすときに発生した「ビルド、モデルの入手と変換、量子化タイプの選択、サーバ起動オプションの設定」といった一連の手間を、利用者から隠すことに徹したツールだ。
Ollamaで同じことをすると、こうなる。
# インストール後、これだけ。モデル取得・起動・API公開まで全部込み
ollama run gemma3
# API公開もサーバ起動も自動。OpenAI互換エンドポイントは :11434 に開く
curl http://localhost:11434/v1/chat/completions -d '{
"model": "gemma3",
"messages": [{ "role": "user", "content": "自己紹介して" }]
}' -H "Authorization: Bearer ollama"
llama.cppでは自分でビルドし、GGUFファイルを探して落とし、量子化タイプを選び、--n-gpu-layers を調整して llama-server を起動していた工程が、Ollamaでは ollama run gemma3 の一行に凝縮される。モデルはOllamaが管理するレジストリから取得され、適切な量子化バリアントが選ばれ、GPUオフロードも自動で見積もられる。この「判断と設定の自動化」がOllamaの価値の中心だ。
さらにOllamaは、Modelfile によるモデルのカスタマイズ（システムプロンプトやパラメータの焼き込み）、ollama list／ollama ps によるモデル管理、OpenAI互換API、OLLAMA_HOST や OLLAMA_KEEP_ALIVE といった環境変数での運用制御など、開発者体験の全体を整えている。この配布層としての完成度が、Ollamaをローカルの入口の定番にしている。ローカルLLM全体でOllamaがどの位置にいるかは ローカルLLMを動かす方法｜2026年最新オープンウェイト・ランタイム・VRAM要件まで総まとめ の俯瞰も合わせて読むと掴みやすい。
Ollamaとllama.cppの違いを7つの軸で比較
土台と外装という関係を踏まえた上で、実際の使用感の違いを7つの軸で並べる。どちらが「優れている」かではなく、抽象度をどこに置くかで何が変わるかという視点で見てほしい。
| 比較軸 | Ollama（外装・配布層） | llama.cpp（土台・推論エンジン） |
|---|---|---|
| セットアップ | インストーラ1つ、ollama run で即起動 |
ビルド（cmake）またはバイナリ入手が必要 |
| モデル入手 | レジストリから pull、量子化は自動選択 |
GGUFを自分で入手／変換、量子化も自分で選ぶ |
| API | OpenAI互換を既定公開（:11434）、設定不要 | llama-server で同等機能。起動オプションは手動 |
| チューニング | 自動見積り中心（簡単だが自由度は限定的） | --n-gpu-layers等を細かく手動調整できる |
| モデル管理 | list/ps/rm/Modelfileで一元管理 |
ファイルを自分で管理、管理機能は最小 |
| 更新頻度への追従 | 安定重視。最新機能はやや遅れて入ることがある | 最先端の量子化・オプションがいち早く入る |
| 向く用途 | 開発・検証・社内PoC・チーム配布・個人利用 | 組込み・エッジ・極限チューニング・研究 |
要点はこうだ。Ollamaは「決めてくれる」ツールで、llama.cppは「決めさせてくれる」ツールである。前者は認知負荷を下げて速く動かすことに、後者は自由度と最先端への追従に価値を置く。速度そのものは、土台が同じggml系である以上、同じモデル・同じ設定なら本質的に近い。差が出るとすれば、それはllama.cppで手動チューニングを詰めた場合か、Ollamaの自動見積りが保守的に振る舞った場合の「設定の差」であって、エンジンの地力の差ではないことが多い。この7軸を一言でまとめると、Ollamaは認知負荷を下げる方向に、llama.cppは自由度を上げる方向に最適化されている、ということになる。
どちらを選ぶ？——用途別の意思決定フロー
抽象的な比較を、具体的な選択に落とす。次のフローで自分の状況を当てはめてみてほしい。
試したい？"} B -->|はい| O1["Ollama
ollama run で1分で開始"] B -->|いいえ / 要件が明確| C{"量子化タイプやGPU
オフロードを細かく
制御したい？"} C -->|はい| L1["llama.cpp
llama-server で手動最適化"] C -->|いいえ| D{"OpenAI互換APIで
アプリに組み込みたい？"} D -->|はい| O2["Ollama
base_url差し替えで即移行"] D -->|いいえ| E{"組込み・エッジ・研究で
最小構成が要る？"} E -->|はい| L2["llama.cpp
依存最小のバイナリ"] E -->|いいえ| O3["Ollama
迷ったら外装から"]
大づかみの指針はこうだ。「とりあえず動かす」「アプリのバックエンドに組み込む」「チームで同じ環境を配る」ならOllama。理由は、判断を自動化してくれるぶん立ち上がりが速く、OpenAI互換APIで既存コードの宛先を差し替えるだけで移行でき、ollama pull でチーム全員が同じモデルを揃えられるからだ。一方、「量子化やオフロードを詰めて最後の性能を絞り出す」「組込み・エッジで依存を極限まで削る」「最新の推論オプションをいち早く使う」ならllama.cpp。Ollamaが隠している設定を、自分の手で開けられる。
多くの読者にとっては、入口はOllamaで正解だ。そこで動かして体感を掴み、速度やメモリ、量子化の限界に具体的な不満が出た「その一点」でllama.cppに降りる——という順序が、学習コストと成果のバランスが最もよい。GUIでモデルを試したいだけならLM Studioという選択肢もある。CLI中心のOllama、低レイヤのllama.cpp、GUIのLM Studioの棲み分けは LM Studio 2026ガイド と合わせて見ると立体的に理解できる。
併用と移行——llama.cppで測り、Ollamaで配る
最後に、二択で終わらせない「併用」の型を示す。土台と外装の関係だからこそ、両者は組み合わせられる。
パターン1：Ollamaで作り、llama.cppで詰める。 開発初期はOllamaで素早くプロトタイプを回し、モデルとプロンプトを固める。本番配置でVRAMや遅延の要件が厳しくなったら、同じGGUFモデルをllama.cppの llama-bench で計測し、--n-gpu-layers やバッチサイズ、量子化タイプを変えながら最適点を探る。エンジンの土台が同じなので、Ollamaで検証した挙動はllama.cppでも再現しやすい。
パターン2：llama.cppで量子化し、Ollamaで配る。 特殊なファインチューニング済みモデルや、レジストリに無いモデルを使いたい場合、まずllama.cppの llama-quantize で目的の量子化GGUFを作る。それをOllamaの Modelfile の FROM ./my-model.gguf で取り込めば、チームには ollama run my-model の1コマンドで配れる。最適化はllama.cppで、配布はOllamaでという役割分担だ。
# Modelfile — llama.cppで量子化した独自GGUFをOllamaに取り込む
FROM ./qwen3-14b-custom-Q4_K_M.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.4
SYSTEM """あなたは社内ドキュメント検索アシスタントです。日本語で簡潔に答えてください。"""
# 取り込んでチームに配布可能な名前で登録
ollama create doc-assistant -f Modelfile
ollama run doc-assistant
この2パターンが示すのは、Ollamaとllama.cppはOR（排他）ではなくAND（併用）で捉えられるということだ。片方に決め打ちする必要はない。手軽さが要る局面ではOllama、制御が要る局面ではllama.cpp——同じGGUFモデルを共有しながら、レイヤーを行き来すればいい。
なお、どちらのランタイムを選ぶにせよ、モデルの中身（アーキテクチャ・量子化・コンテキスト長）の理屈を押さえておくと選定精度が上がる。仕組みの基礎は LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 を、ローカルLLMをコーディングエージェントに繋ぐ実例は Ollama 0.24でOpenAI Codex CLIがローカルLLMで動く：API課金もレート制限もない開発体験 を参照してほしい。
結論として、「Ollamaとllama.cppのどちらか」という問いは、多くの場合「どのレイヤーで作業するか」に読み替えるのが正しい。迷ったら外装のOllamaから始め、必要になったら土台のllama.cppに降りる。この順序さえ押さえれば、ローカルLLMのランタイム選びで迷うことはもうない。
参照ソース
・ggml-org/llama.cpp — GitHub 公式リポジトリ（MIT）
・ollama/ollama — GitHub 公式リポジトリ（MIT）
・llama.cpp server（OpenAI互換HTTPサーバ）README
・GGUF フォーマット仕様（ggml リポジトリ）
・Ollama 公式サイト — モデルライブラリ
