Ollama(オラマ)は、話題のオープンウェイトLLMを手元のPCで動かすためのオープンソースツールだ。 「ChatGPTやClaudeのAPIは便利だが、毎月の課金とレート制限が地味に効く。何より、社内の設計書や顧客データを外部サーバに投げることに稟議が通らない」——AIをプロダクトや業務に組み込もうとすると、多くのチームがこの壁にぶつかる。その回避策として2024年以降に一気に定着したのが、手元のPCでLLMを動かす「ローカルLLM」であり、その入口としていま事実上の標準になっているのがOllamaである。
Ollamaは、LlamaやGemma、Qwen、DeepSeek-R1といったオープンウェイトの大規模言語モデルを、たった1コマンドでダウンロードして実行できるOSSである。難しいセットアップも、Pythonの依存地獄も、GPUドライバの格闘もほぼ不要。ollama run gemma3 と打てば、モデルが降ってきて対話が始まり、同時にローカルAPIサーバまで立ち上がる。この記事では、そのOllamaを「インストール → 基本操作 → API連携 → モデル選び → 実運用 → 注意点 → 他ツール比較」の順に、公式ドキュメントで裏取りしながら体系的に解説する。
ローカルLLM全体の選び方・ランタイム・VRAM要件の俯瞰は ローカルLLMを動かす方法|2026年6月最新オープンウェイト・ランタイム・VRAM要件まで総まとめ をご覧ください。本記事はその中でも「Ollama」という具体ツールに絞った実践編です。
この記事のポイント(30秒でわかるOllama)
・何ができる? オープンウェイトLLM(Llama/Gemma/Qwen/DeepSeek-R1等)を1コマンドでローカル実行。裏側はllama.cpp+GGUF量子化モデル
・何を解決する? クラウドAPIの課金・レート制限・データ外部送信の不安を解消。推論は完全にオフラインで完結
・何を代替する? OpenAI/Anthropic等のクラウドLLM APIを、開発・検証・機密データ用途でローカルに置き換える
・強み OpenAI互換APIを既定で公開(ポート11434)。既存コードのエンドポイントを差し替えるだけで移行できる
・つまずきやすい点 VRAM要件とモデル選び、そして 0.0.0.0 公開時の認証欠如。この記事で全部つぶす
・ライセンス 本体はMIT。ただしモデルごとのライセンスは別途確認が必要
Ollamaとは何か——3つの疑問に先に答える
当サイトの読者が新しいOSSに対して知りたいのは、いつも同じ3つだ。「結局それは何ができて、何を解決し、何を代替するのか」。Ollamaについて先に答えを置く。
① 何ができるのか。 Ollamaは、Hugging Faceなどで公開されているオープンウェイトのLLMを、量子化済みの扱いやすい形(GGUF)でパッケージし、ollama run の1コマンドで実行できるようにするランタイム兼モデル管理ツールだ。モデルの取得・キャッシュ・起動・対話・API公開・破棄までを、Dockerの docker run によく似た操作感で一元管理する。
② 何を解決するのか。 クラウドLLM APIの3大痛点——従量課金・レート制限・データの外部送信——を、推論をローカルに閉じることで解消する。ネットワークが切れていてもモデルは動き、プロンプトに含めた機密情報が第三者のサーバに渡ることもない。開発中に何万回とAPIを叩いても請求は増えない。
③ 何を代替するのか。 OpenAIやAnthropicのクラウドAPIを、開発・検証・プライバシー重視の用途で置き換える。特にOllamaはOpenAI互換のエンドポイントを標準装備するため、base_url を差し替えるだけで既存のOpenAI向けコードがそのまま動く。本番の最高精度はクラウドの巨大モデルに任せ、日常のコード補助や社内チャット、機密文書のRAGはローカルのOllamaに——という使い分けが現実的な落とし所になる。
アーキテクチャを一枚で捉えると、Ollamaは「モデルレジストリ」「llama.cppベースの推論エンジン」「REST APIサーバ」の3層を1つのバイナリに束ねた構造だと理解すると腑に落ちる。
既定ポート 11434"] S -->|初回のみ取得| R["モデルレジストリ
ollama.com/library"] R -->|GGUF量子化モデルをpull| C["ローカルモデルキャッシュ
~/.ollama/models"] S -->|ロード&推論| E["推論エンジン
llama.cpp(GPU/CPU)"] C --> E E -->|生成トークン| S S -->|/api/chat・/v1/chat/completions| U
図の通り、外部と通信するのはモデルを初回に取得するときだけで、以降のプロンプト処理はすべて手元のマシン内で回る。この「一度落としたら後はオフライン」という性質が、Ollamaを社内利用やオフライン環境で選ぶ最大の理由だ。本体はMITライセンスで、GitHubで10万を超えるスターを集める、ローカルLLM分野で最も採用の広いプロジェクトである。
Ollamaのインストール(Mac / Windows / Linux / Docker)
OllamaのインストールはどのOSでも数分で終わる。公式サイト ollama.com/download からGUIアプリを入れるのが最も簡単だが、CLI派やサーバ用途にはワンライナーが速い。
macOS — アプリ版(.dmg)をダウンロードして起動するか、ターミナルからインストールスクリプトを実行する。アプリ版を入れるとメニューバーにアイコンが常駐し、ollama コマンドも同時に使えるようになる。
# 方法1: 公式アプリ(推奨)
# https://ollama.com/download から Ollama.dmg を入手してインストール
# 方法2: インストールスクリプト
curl -fsSL https://ollama.com/install.sh | sh
Windows — OllamaSetup.exe を実行するか、PowerShellでインストールする。WSLなしのネイティブWindowsでGPU(NVIDIA/AMD)が使える。
# インストーラ: https://ollama.com/download/OllamaSetup.exe
# または PowerShell:
irm https://ollama.com/install.ps1 | iex
Linux — 公式スクリプトが依存関係とsystemdサービスまで面倒を見てくれる。NVIDIA/AMDのGPUドライバを検出して自動設定する。
curl -fsSL https://ollama.com/install.sh | sh
# サービスとして常駐しているか確認
systemctl status ollama
Docker — サーバ運用やCI、コンテナ化したい場合は公式イメージ ollama/ollama を使う。NVIDIA GPUを渡すには --gpus=all を付ける。
# CPU版
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
# NVIDIA GPU版(nvidia-container-toolkit が必要)
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
# コンテナ内でモデルを実行
docker exec -it ollama ollama run llama3.3
インストールが終わったら、動作確認を兼ねて軽量モデルを1つ走らせてみる。初回は数百MB〜数GBのダウンロードが走るが、2回目以降はキャッシュから即起動する。
ollama run gemma3
# >>> こんにちは、と挨拶したら日本語で返ってくればOK
ollama run→対話&API公開」の3〜4ステップで動き出す。図はローカル生成(HTML/CSS)。基本操作とModelfile——run / pull / list / ps
Ollamaの操作は、Dockerを触ったことがある人なら直感で分かる。中心になるサブコマンドは次の通りだ。
| コマンド | 役割 | 例 |
|---|---|---|
ollama run |
モデルを起動して対話(無ければ自動でpull) | ollama run qwen3 |
ollama pull |
モデルをダウンロードだけする | ollama pull llama3.3 |
ollama list |
ローカルにあるモデル一覧 | ollama list |
ollama ps |
いま起動中(メモリ常駐)のモデル | ollama ps |
ollama show |
モデルの詳細(パラメータ・テンプレート) | ollama show llama3.3 |
ollama rm |
モデルを削除して容量を空ける | ollama rm gemma3 |
ollama create |
Modelfileから独自モデルを作成 | ollama create mybot -f Modelfile |
ollama serve |
APIサーバを前面起動(アプリ未使用時) | ollama serve |
対話モード(ollama run 後のプロンプト)では、スラッシュコマンドで挙動を変えられる。/set system "あなたは丁寧な日本語アシスタントです" でシステムプロンプトを差し込み、/set parameter num_ctx 8192 でコンテキスト長を広げ、/bye で終了する。ここが後述のコンテキスト長調整の入口になる。
Modelfileで「自分専用モデル」を作る
Ollamaの隠れた主役が Modelfile だ。ベースモデルにシステムプロンプトやパラメータ、独自テンプレートを焼き込み、再利用可能な「キャラクター付きモデル」として保存できる。Dockerfileの発想をLLMに持ち込んだものと考えると分かりやすい。
# Modelfile
FROM llama3.3
# 生成の温度(低いほど堅実、高いほど多様)
PARAMETER temperature 0.4
# 一度に扱える文脈の長さ
PARAMETER num_ctx 8192
# このモデルの人格・役割を固定する
SYSTEM """
あなたは社内ドキュメント検索アシスタントです。
回答は必ず日本語で、根拠が不確かな場合は「確認が必要です」と述べてください。
"""
# Modelfileから独自モデルを作成して実行
ollama create doc-assistant -f Modelfile
ollama run doc-assistant
こうして作った doc-assistant は ollama list に並び、APIからもモデル名で呼び出せる。プロンプトをアプリ側に毎回書く代わりに、モデル自体に役割を持たせておくことで、呼び出し側のコードが軽くなる。
OpenAI互換APIでアプリに組み込む
Ollamaが開発者に選ばれる決定打が、OpenAI互換APIを既定で公開している点だ。サーバが動いていれば(アプリ常駐 or ollama serve)、http://localhost:11434 に対して2種類のAPIが同時に開いている。
ひとつはOllamaネイティブの /api/chat・/api/generate。もうひとつがOpenAI互換の /v1/chat/completions で、こちらは既存のOpenAIクライアントをそのまま流用できる。
# ネイティブAPI(/api/chat)
curl http://localhost:11434/api/chat -d '{
"model": "llama3.3",
"messages": [{ "role": "user", "content": "日本語で自己紹介して" }],
"stream": false
}'
# OpenAI互換API(/v1/chat/completions)— api_key はダミーでよい
curl http://localhost:11434/v1/chat/completions -d '{
"model": "llama3.3",
"messages": [{ "role": "user", "content": "Ollamaの利点を3つ" }]
}' -H "Authorization: Bearer ollama"
Pythonなら、公式OpenAI SDKの base_url と api_key を差し替えるだけでいい。アプリのロジックは一切変えずに、宛先だけをクラウドからローカルに向けることができる。
from openai import OpenAI
# base_url をローカルの Ollama に向けるだけ。api_key は形式的なダミー
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
model="llama3.3",
messages=[{"role": "user", "content": "ローカルLLMの用途を教えて"}],
)
print(resp.choices[0].message.content)
この互換性のおかげで、LangChainやLlamaIndex、各種エージェントフレームワーク、VS Code拡張(Continueなど)は、設定でエンドポイントをOllamaに向けるだけで動く。「まずクラウドで作り、コスト最適化のためにローカルへ逃がす」という移行が、コード変更ほぼゼロで実現するわけだ。ローカルLLMをコーディングエージェントに繋ぐ具体例は Ollama 0.24でOpenAI Codex CLIがローカルLLMで動く:API課金もレート制限もない開発体験 でも扱っている。
チャットUIのように逐次表示(ストリーミング)したい場合は、stream=True を渡してトークンを1つずつ受け取る。体感の待ち時間が大きく減り、UXが向上する。
stream = client.chat.completions.create(
model="llama3.3",
messages=[{"role": "user", "content": "ローカルLLMの利点を長めに説明して"}],
stream=True,
)
for chunk in stream:
delta = chunk.choices[0].delta.content or ""
print(delta, end="", flush=True)
本番運用のためのチューニング(環境変数)
複数人・複数アプリでOllamaを共有するなら、環境変数でサーバの挙動を調整する。よく使う4つを押さえておけば、メモリと同時実行のバランスを取れる。
・OLLAMA_KEEP_ALIVE — モデルをメモリに保持する時間(既定5分)。頻繁に使うなら -1(常駐)や 30m にすると、毎回のロード待ちが消える
・OLLAMA_NUM_PARALLEL — 1モデルが同時に処理するリクエスト数。複数ユーザーが同時に叩くサーバでは増やす(その分VRAMを消費)
・OLLAMA_MAX_LOADED_MODELS — 同時にメモリへ載せるモデル数の上限。生成用と埋め込み用を両方常駐させたいときに効く
・OLLAMA_FLASH_ATTENTION — Flash Attentionを有効化し、長いコンテキストでのメモリ効率と速度を改善する
# 例: モデルを常駐させ、同時4リクエストまで捌く設定でサーバを起動
OLLAMA_KEEP_ALIVE=-1 OLLAMA_NUM_PARALLEL=4 OLLAMA_FLASH_ATTENTION=1 ollama serve
こうした設定は、Ollamaを「手元で試すツール」から「チームの共有推論サーバ」へと引き上げるための第一歩だ。GPUのVRAMと相談しながら、同時実行数とモデル常駐のバランスを詰めていく。
モデルの選び方——VRAMと量子化で決める
Ollamaで最初に迷うのが「どのモデルを選ぶか」だ。判断軸は主に3つ——用途・パラメータ規模(B)・量子化の強さ。そして規模を決めるのは、あなたのマシンのVRAM(Apple Siliconならユニファイドメモリ)だ。目安を表にまとめる。
| 規模 | 代表モデル例 | Q4量子化の必要VRAM目安 | 向く用途 |
|---|---|---|---|
| 1〜4B | gemma3:1b / llama3.2:3b / phi | 2〜4GB | 軽量チャット・分類・エッジ/低スペック機 |
| 7〜9B | llama3.1:8b / gemma3 / qwen3:8b | 5〜6GB | 日常のチャット・要約・コード補助の主力 |
| 12〜14B | phi4 / qwen3:14b | 9〜11GB | やや複雑な推論・長めの文書処理 |
| 27〜32B | gemma3:27b / qwen3:32b / deepseek-r1:32b | 18〜22GB | 高品質な生成・推論特化(要ハイエンドGPU) |
| 70B〜 | llama3.3:70b | 40GB以上 | クラウド級の品質をローカルで(要複数GPU/大容量) |
量子化は、モデルの重みを低ビットに圧縮してメモリと速度を稼ぐ技術だ。Ollamaのタグは既定で Q4_K_M(4bit)が選ばれることが多く、品質と省メモリのバランスが良い。より高品質を狙うなら q5_K_M や q8_0、極限まで省メモリにするなら q3 系という具合に、ollama pull gemma3:27b-q4_K_M のようにタグで明示指定できる。迷ったら「動く範囲でいちばん大きいモデルをQ4で」が実務的なスタート地点だ。
モデルは大きいほど賢いが、VRAMに乗り切らないとCPUへオフロードされて劇的に遅くなる。まず ollama ps で実際のメモリ占有を見ながら、体感速度と品質の折り合いをつけていくとよい。用途別のモデル選定は、下の判断フローも参考にしてほしい。
qwen3 / llama3.1:8b"] Q -->|軽量・低スペック機| B["1〜4Bクラス
gemma3:1b / llama3.2:3b"] Q -->|難しい推論・数学| C["推論特化
deepseek-r1"] Q -->|埋め込み(RAG用ベクトル化)| D["nomic-embed-text
mxbai-embed-large"] A --> V{"VRAMは足りる?"} V -->|足りる| OK["そのまま実行"] V -->|足りない| Z["量子化を強める or 小さいモデルへ"]
RAG用途では、生成モデルとは別に埋め込み(Embedding)モデルが要る点も押さえておきたい。ollama pull nomic-embed-text で埋め込み専用モデルを入れ、/api/embeddings でテキストをベクトル化する。生成と埋め込みを両方ローカルで賄えるのがOllamaの強みで、これにより「文書のベクトル化 → 検索 → 回答生成」というRAGの全工程を1台の中で完結できる。
# 埋め込みモデルでテキストをベクトル化(RAGの検索インデックス用)
ollama pull nomic-embed-text
curl http://localhost:11434/api/embeddings -d '{
"model": "nomic-embed-text",
"prompt": "退職金の計算方法を教えてください"
}'
# → 数百次元の float 配列が返る。これをベクトルDBに保存して類似検索に使う
実運用ユースケース——RAG・コーディング補助・社内チャット
Ollamaは「試して終わり」ではなく、実務に載る。代表的な3つの使い方を、なぜローカルが効くのかとセットで挙げる。
① 機密文書のローカルRAG(社内ナレッジ検索)。 設計書・議事録・契約書など、外部に出せない文書をベクトル化し、質問に対して該当箇所を根拠付きで答えさせる。埋め込みも生成もOllamaで完結するため、文書が一切ネットワークに出ない。LlamaIndexやDifyのモデルプロバイダをOllamaに向ければ、RAGパイプライン全体をオフラインで組める。RAGの設計原則は RAG完全ガイド2026 を参照。
② コーディング補助(IDE/CLIエージェント)。 VS Codeの拡張やコーディングCLIのバックエンドをOllamaに差し替え、コード補完・リファクタ提案・テスト生成をローカルで回す。クラウドのコード補助はトークン課金が積み上がるが、ローカルなら何回補完させても無料で、社内コードを外部に送らずに済む。qwen3やdeepseek-r1系のコード対応モデルが主力になる。
③ プライバシー配慮の社内チャットボット。 人事規程やFAQをModelfileのシステムプロンプト+RAGに載せ、社内向けアシスタントを立てる。OpenAI互換APIなので、社内Webアプリのバックエンドにそのまま繋がる。ネットワークが不安定な現場・工場・オフライン環境でも動くのは、クラウドAPIにはできない芸当だ。
④ 開発時のコスト削減(クラウド前の下書き)。 プロンプトの試行錯誤やパイプラインのデバッグをローカルのOllamaで行い、本番だけクラウドの高精度モデルに切り替える。開発中に何万回叩いても請求ゼロ、という体験は生産性に効く。
これらに共通するのは、「データを手元に置きたい」「回数課金を避けたい」「オフラインで動かしたい」という要求だ。どれか一つでも当てはまるなら、Ollamaは検討に値する。
注意点と既知の課題——VRAM・セキュリティ・コンテキスト
便利な一方で、つまずきポイントもはっきりしている。導入前に知っておきたい4点を挙げる。
① VRAM不足による激遅化。 モデルがVRAMに乗り切らないと、一部がCPU/システムメモリにオフロードされ、生成速度が桁で落ちる。ollama ps の PROCESSOR 列がGPUかCPUかを見て、CPU比率が高いなら1段小さいモデルか強い量子化に落とすのが定石だ。
② 0.0.0.0 公開時の認証欠如(重要)。 既定のOllamaは 127.0.0.1(ローカルのみ)で待ち受けるが、OLLAMA_HOST=0.0.0.0 を設定してLANや外部に公開すると、Ollamaには組み込みの認証機構がないため、到達できる者は誰でもモデルを叩ける。過去には公開状態のOllamaサーバが大量にスキャンされた事例も報告されている。外部公開する場合は、必ずリバースプロキシ(nginx等)でBasic認証やトークン検証を挟むか、VPN/ファイアウォールでアクセス元を絞ること。安易な全開放は厳禁だ。
③ モデルファイル由来の脆弱性。 GGUFなどモデルファイルの解析処理に起因する脆弱性が報告されている(例:Ollamaで報告された CVE-2026-7482(GGUF処理のメモリリーク))。信頼できないソースのモデルを無闇に読み込まず、Ollama本体は最新版に保つ。ソフトウェアのサプライチェーンと同じ衛生管理が、モデルにも要る。
④ コンテキスト長の既定値。 長いプロンプトや長文RAGを投げても、既定のコンテキスト長で静かに切り詰められることがある。前述の num_ctx(対話中は /set parameter num_ctx 8192、Modelfileは PARAMETER num_ctx、APIは options.num_ctx)で明示的に広げる。ただし伸ばすほどメモリと時間を食うので、VRAMと相談して決める。
| 症状 | 原因 | 対処 |
|---|---|---|
| 生成が異常に遅い | VRAM不足でCPUオフロード | 小さいモデル/強い量子化へ、ollama psで確認 |
| 長文が途中で無視される | コンテキスト長が既定で不足 | num_ctxを明示指定 |
| 他PCからアクセスできてしまう | 0.0.0.0公開+認証なし | リバースプロキシ認証/VPN/FWで制限 |
| ディスクが逼迫 | モデルの重複ダウンロード | ollama list→不要分をollama rm |
他のローカルLLMツールとの比較——どれを選ぶべきか
ローカルでLLMを動かす手段はOllamaだけではない。代表的な選択肢と、Ollamaの立ち位置を整理する。
| ツール | 形態 | 強み | 向くユーザー |
|---|---|---|---|
| Ollama | CLI+API常駐 | 1コマンド実行・OpenAI互換API・スクリプト/サーバ連携 | アプリに組み込む開発者・API利用 |
| LM Studio | GUIアプリ | モデル探索・チャットを画面で完結、可視化が豊富 | GUIで手軽に試したい人 |
| llama.cpp | ライブラリ/CLI | Ollamaの土台。最も低レイヤで細かく制御 | 量子化や実行を自前で詰めたい上級者 |
| vLLM | 推論サーバ | 高スループット・並列処理。本番の大量リクエスト向き | GPUサーバで多人数に配信する運用 |
| クラウドAPI | SaaS | 最高精度・セットアップ不要・巨大モデル | 精度最優先・データ外部送信が許容される用途 |
ざっくり言えば、手軽に試すGUIならLM Studio、細部まで制御する低レイヤならllama.cpp、本番で多人数に高速配信するならvLLM、最高精度ならクラウドAPI。そしてOllamaは、その中間で最も「開発者にとって扱いやすいバランス点」に位置する。1コマンドで動き、OpenAI互換APIを吐き、スクリプトやサーバに組み込みやすい——この総合力が、Ollamaを個人開発から社内PoCまでの定番にしている。
正直に、Ollamaが向かないケースも挙げておく。ひとつは、数百〜数千の同時リクエストを捌く高スループット本番。この領域はページアテンションで最適化されたvLLMやTGIの方が適している(Ollamaは手軽さと引き換えにスループット最適化では譲る)。もうひとつは、GPTやClaudeの最上位モデルでしか到達できない精度が要る用途。ローカルで動く量子化モデルは年々賢くなっているが、フロンティアの巨大モデルとは依然として差がある。「機密性・コスト・オフライン性」を取るか「最高精度・スループット」を取るか——この軸で判断すれば、Ollamaを選ぶべき場面は自ずと見えてくる。LM Studioとの詳しい違いは LM Studio 2026ガイド、モデルの中身や量子化の理屈は LLMとは?仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 で深掘りしている。
まずは ollama run gemma3 の1行から始めてみてほしい。手元のマシンがそのままAIの実行環境になる感覚は、一度味わうと戻れない。
参照ソース
・ollama/ollama — GitHub 公式リポジトリ(MIT)
・Ollama 公式サイト — ダウンロード
・Ollama モデルライブラリ(提供モデル一覧)
・Ollama API ドキュメント(docs/api.md)
・OpenAI 互換API(docs/openai.md)
・Modelfile リファレンス(docs/modelfile.md)
・Docker Hub — ollama/ollama 公式イメージ