Ollama（オラマ）とは、オープンウェイトの大規模言語モデルを手元のPCやサーバーで動かすための実行環境です。モデルの取得、量子化済みファイルの管理、GPUへの割り当て、HTTP APIの提供までを1つのバイナリが受け持ち、ollama run の一行でチャットが始まります。本体はMITライセンスで無料ですが、動かすモデルのライセンスは別物なので、商用利用ではモデル側の条件を確認する必要があります。
対応OSはWindows・macOS・Linuxで、Linuxではsystemdサービスとして常駐します。ここではインストールから、メモリに収まるモデルの見分け方、日本語で使えるモデルの探し方、curlでのAPI呼び出し、そして社内公開で最初に踏みがちな「0.0.0.0で無認証公開」の落とし穴までを、確認コマンドと期待される出力つきで進めます。
この記事でわかること
- OllamaがGGUF形式のモデルをどう扱い、なぜ既定で127.0.0.1:11434にしか待ち受けないのか
- 「12b」「q4_K_M」といったタグの読み方と、ファイルサイズからVRAM必要量を見積もる計算
- 日本語で実用になるモデルの探し方と、コミュニティ配布モデルを使う前の確認事項
- REST APIとOpenAI互換APIの使い分け、社内公開時のリバースプロキシ構成
- 実際に出るエラーメッセージ6種類と、その原因の切り分け方
Ollamaが裏で何をしているか
Ollamaの中身は、llama.cppという推論エンジンを組み込んだサーバープロセスと、それに指示を出すCLIの2つです。ollama run gemma4:12b と打つと、CLIはまず http://127.0.0.1:11434 に接続し、モデルが手元になければレジストリ（ollama.com）から量子化済みのGGUFファイルをダウンロードします。ファイルはSHA-256ダイジェスト名の「ブロブ」として保存され、複数のタグが同じブロブを共有します。ダウンロード後はサーバーがモデルをメモリへ読み込み、GPUがあれば載せられるだけの層をVRAMに置き、残りをCPU側に置きます。この「載せられる範囲」がそのまま速度を決めます。
サーバーが既定で127.0.0.1にしか待ち受けないのは、APIに認証機構が一切ないからです。ポートに到達できる相手は誰でも推論を実行でき、/api/pull や /api/delete でモデルの追加や削除もできます。ループバックに閉じておけばリスクはそのマシンのローカルユーザーに限定されます。LANに開けるときの正しい手順は後半で扱います。
読み込んだモデルは既定で5分間（OLLAMA_KEEP_ALIVE）メモリに常駐し、その間の2回目以降のリクエストは読み込み待ちなしで応答します。最初の1回だけ数秒から数十秒かかるのはこの読み込みが原因で、故障ではありません。
OS別インストール手順
Linux（Ubuntu 24.04）
公式のインストールスクリプトが、バイナリの配置（/usr/bin/ollama）、専用ユーザー ollama の作成、systemdユニット ollama.service の登録、NVIDIA・AMD GPUの検出までを行います。curl | sh を実行する前に中身を読んでおけば、社内サーバーで何が変わるかを説明できます。
# スクリプトを保存して中身を確認してから実行する
curl -fsSL https://ollama.com/install.sh -o /tmp/ollama-install.sh
less /tmp/ollama-install.sh
sh /tmp/ollama-install.sh
# サービス状態と待ち受けポートの確認
systemctl status ollama --no-pager
ss -ltnp | grep 11434
# 期待: LISTEN 0 4096 127.0.0.1:11434 ... users:(("ollama",pid=...))モデルの保存先は /usr/share/ollama/.ollama/models で、サービスは ollama ユーザーで動きます。別ディスクに置きたい場合は OLLAMA_MODELS を設定したうえで、そのディレクトリの所有者を ollama:ollama にしておかないと、起動はするのに ollama pull が書き込みエラーになります。ログは journalctl -u ollama -e で読めます。
Windows
公式サイトからダウンロードした OllamaSetup.exe を実行します。インストール先は %LOCALAPPDATA%\Programs\Ollama で管理者権限は不要、ログイン時にタスクトレイの常駐アプリとして起動します。モデルは %HOMEPATH%\.ollama 配下に保存され、変更したい場合は「環境変数を編集」から OLLAMA_MODELS を設定してOllamaを再起動します。サーバーログは %LOCALAPPDATA%\Ollama\server.log にあり、GPUが認識されないときは最初にここを開きます。NVIDIAの場合、執筆時点の公式要件はドライバ551.61以降です。
macOS
公式サイトのアプリ（メニューバー常駐）を入れる方法と、Homebrewの formula（brew install ollama のあと brew services start ollama）の2通りがあります。Apple SiliconではMetalによるGPUアクセラレーションが自動で有効になり、ユニファイドメモリの大部分をモデルに使えます。GPU搭載PCを買わずに27B級を試したいなら、メモリ32GB以上のMacが最も手軽です。モデルは ~/.ollama/models に置かれます。
最初の1モデルと基本コマンド
最初は3.4GBの qwen3.5:4b のように小さいモデルで、ダウンロードから応答までの流れを確認します。対話画面では /bye で抜け、/set parameter num_ctx 8192 のようにセッション中にパラメータも変えられます。
ollama run qwen3.5:4b
>>> 社内ヘルプデスク向けに、パスワード変更手順を3行で書いてください
（応答が流れる）
>>> /bye日常的に使うのは次の6つです。ollama show はコンテキスト長・埋め込み次元・量子化方式を表示するので、後述のメモリ見積もりや、RAGで埋め込みモデルの次元数を確かめるときに使います。
ollama pull gemma4:12b # ダウンロードのみ（実行しない）
ollama list # ローカルにあるモデルとサイズ
ollama ps # メモリにロード中のモデルと GPU/CPU の比率
ollama show gemma4:12b # context length / embedding length / quantization
ollama show gemma4:12b --license # モデルのライセンス全文
ollama rm qwen3.5:4b # 削除（他のタグから参照されないブロブも消える）ollama ps の PROCESSOR 列が「100% GPU」ならモデル全体がVRAMに載っています。「45%/55% CPU/GPU」のような分割表示や「100% CPU」なら、VRAM不足かGPUが認識されていないかのどちらかで、この列を見るだけで遅さの原因は半分まで絞れます。
モデルサイズとメモリの目安：量子化タグの読み方
モデル名の「12b」はパラメータ数120億、「q4_K_M」は各パラメータを約4ビットに丸めた量子化方式を表します。元のFP16なら1パラメータ2バイトなので12Bで24GBですが、4ビット量子化ならおよそ0.55〜0.6バイトになり7GB台に収まります。K_Mの「K」はllama.cppのK-quant方式、「M」は精度を残す層の割合がMedium、という意味で、同じ4ビットでも q4_0 より劣化が小さい代わりに少し大きくなります。Ollamaライブラリの既定タグ（例: gemma4:12b）は執筆時点ではほぼ4ビット系で、gemma4:12b-q8_0 のように明示すると8ビット版を選べます。
実行時に必要なメモリは「ファイルサイズ + KVキャッシュ + 1GB前後の作業領域」です。KVキャッシュは会話の文脈（コンテキスト長）に比例して増えるので、4Kで足りるチャットと32Kの長文RAGでは、同じモデルでも必要量が数GB違います。ファイルサイズに2〜4GBを足した値がVRAM（またはMacのユニファイドメモリ）に収まるか、で判断してください。
| モデル（タグ） | ファイルサイズ（執筆時点の既定タグ） | 全層をGPUに載せる目安 | 向く用途 |
|---|---|---|---|
| llama3.2:3b | 2.0GB | VRAM 4GB、CPUのみでも可 | 分類、短文要約、CPU運用 |
| qwen3.5:4b | 3.4GB | VRAM 6GB | 個人用チャット。日本語は9B以上に劣る |
| granite4.1:8b | 5.3GB | VRAM 8GB | RAG、ツール呼び出し（Apache 2.0） |
| qwen3.5:9b | 6.6GB | VRAM 10〜12GB | 日本語チャット、画像入力 |
| gemma4:12b | 7.6GB | VRAM 12GB | 日本語の文書作成、画像入力 |
| qwen3.8:27b | 18GB | VRAM 24GB、またはMac 32GB | コーディング、長文処理 |
| gemma4:31b | 20GB | VRAM 24GB（短い文脈のみ）、Mac 48GB以上 | 品質優先の社内用途 |
latest タグは中身が更新されると別の重みに置き換わります。評価済みのモデルを本番で使うなら gemma4:12b のようにサイズまで含めたタグを指定し、ollama show や ollama list に出るIDを記録してください。「先週まで正しく答えていたのに」の原因の多くはこれです。
日本語に強いモデルの選び方
執筆時点では、多言語で学習された汎用モデル（Qwen3.5/3.6/3.8系、Gemma 4系、Llama 3系）を9B以上のサイズで使えば、業務文書の日本語として十分読める品質になります。4B以下では敬語が崩れる、簡体字が混ざる、といった症状が出やすいので、社内向けでもVRAM 12GBを確保して9〜12B級を選ぶのを勧めます。日本語は英語よりトークン効率が悪く、同じ知識量を保つには多めのパラメータが要る、というのがその理由です。例外は、分類や定型文生成のように出力形式が固定される用途で、これは4B級でも十分こなせます。
日本語特化モデル（ELYZA、CyberAgent、SB IntuitionsのSarashina、LLM-jp、Swallow、PLaMoなど）は主にHugging FaceでGGUFとして配布されています。Ollamaライブラリ上にも ユーザー名/モデル名 形式のコミュニティアップロードが多数ありますが、これは第三者が変換して登録したもので、元モデルと同じ重み・同じチャットテンプレートである保証はありません。使うなら、アップロード者、元のモデルカードへの言及、更新日を確認し、可能なら自分でGGUFを取得して取り込むほうが確実です。取り込みは Modelfile に FROM で指すだけです。
FROM ./model-q4_K_M.gguf
PARAMETER num_ctx 8192ollama create my-jp-model -f Modelfile
ollama run my-jp-model候補を絞ったら自社の文書で試します。「社内規程の1段落を200字で要約」「取引先への謝罪メールを敬語で作成」「表を含む議事録から決定事項を箇条書きに」の3問で、簡体字の混入、数値の取り違え、敬語の破綻を見ます。ベンチマーク上位でも自社文書で外すモデルは珍しくありません。用途別の系列比較はローカルLLMの選び方にまとめています。
REST APIをcurlで使う
全機能は http://localhost:11434 のHTTP APIで提供され、CLIも内部ではこれを呼んでいます。/api/generate（単発生成）と /api/chat（会話形式）は既定でストリーミング応答（改行区切りのJSONが逐次届く）なので、スクリプトから扱うなら "stream": false を付けて1つのJSONで受け取ります。
curl http://localhost:11434/api/chat -d '{
"model": "gemma4:12b",
"messages": [
{"role": "system", "content": "あなたは社内ITヘルプデスクです。敬語で簡潔に答えてください。"},
{"role": "user", "content": "VPNに繋がらないときの確認手順を教えてください"}
],
"stream": false,
"options": {"num_ctx": 8192},
"keep_alive": "30m"
}'
curl http://localhost:11434/api/tags # ローカルのモデル一覧
curl http://localhost:11434/api/embed -d '{"model": "bge-m3", "input": ["有給休暇の申請方法", "経費精算の締め日"]}'OpenAI互換のエンドポイント /v1/chat/completions も執筆時点で提供されており、既存のOpenAI SDKは base_url を差し替えるだけで向けられます。APIキーは検証されないので、SDKが必須扱いにしている場合はダミー文字列で構いません。埋め込みは /api/embed で、input に配列を渡すと一度に複数文のベクトルが返り、RAGの取り込み処理が単発呼び出しより大幅に速くなります。
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "gemma4:12b", "messages": [{"role": "user", "content": "こんにちは"}]}'keep_alive はリクエスト単位でも指定でき、-1 で常駐、0 で応答後すぐ解放です。夜間バッチで複数モデルを順に使うなら、各リクエストに "keep_alive": 0 を付けてVRAMを明け渡すと、次のモデルの読み込みで詰まりません。
GPUなしで運用する現実
CPUだけでも動きますが、速度はメモリ帯域で頭打ちになります。1トークン生成するたびにモデル全体を読むため、理論上の上限は「メモリ帯域 ÷ モデルのバイト数」です。デュアルチャネルDDR5の帯域をおよそ80GB/sとすると、2GBの3Bモデルで40トークン/秒、5GBの8Bモデルで16トークン/秒が上限で、実効はその半分程度と見ておくと外れません。20GBの31Bモデルは計算上4トークン/秒を切り、対話用途では待てない速度です。
もうひとつ効くのが、入力を読み込むプリフィルの遅さです。GPUなら数千トークンの文書を数秒で処理しますが、CPUでは数十秒かかることがあり、RAGのように長い文脈を毎回渡す用途で目立ちます。GPUなしなら3〜4B級のモデルで分類・短文要約・定型文生成に用途を絞るのが現実的で、対話型の社内チャットを複数人で使うならGPUかApple Siliconを用意してください。
社内に公開するときの構成とセキュリティ
LANから使えるようにする最短の方法は OLLAMA_HOST=0.0.0.0:11434 を設定して全インターフェースで待ち受けることですが、これは無認証のAPIをそのままLANに晒す行為です。推奨は、Ollamaは127.0.0.1のままにし、同じホストのリバースプロキシ（nginxやCaddy）でTLSと認証を付けて公開する構成です。プロキシ経由ならOllama側の設定は変えずに済み、公開範囲もプロキシの設定だけで制御できます。
server {
listen 443 ssl;
server_name ollama.corp.example;
ssl_certificate /etc/nginx/certs/ollama.crt;
ssl_certificate_key /etc/nginx/certs/ollama.key;
auth_basic "Ollama API";
auth_basic_user_file /etc/nginx/.htpasswd; # htpasswd -c で作成
location / {
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host localhost:11434; # Ollama は Host ヘッダを検証する
proxy_read_timeout 600s; # 長文生成中に切られないように
proxy_buffering off; # ストリーミングをそのまま流す
}
}proxy_set_header Host localhost:11434 は飾りではありません。OllamaはDNSリバインディング対策としてHostヘッダを検証しており、公式FAQのプロキシ例もこの書き換えを含んでいます。書き換えを忘れると、プロキシ経由のリクエストだけが403で落ちます。
Docker上のOpen WebUIやDifyからホストのOllamaへ接続する場合だけは、コンテナからループバックには届かないため、0.0.0.0 での待ち受けが必要になります。その場合はsystemdの上書き設定で環境変数を入れ、ufwでDockerのサブネット以外からの11434番宛てを止めてください。Ollama自体をコンテナで動かし、Composeのネットワーク内だけで参照する構成なら、この問題は最初から起きません。手順はOpen WebUIの構築ガイドで扱っています。
sudo systemctl edit ollama.service
# 開いたエディタに以下を書いて保存
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
# Environment="OLLAMA_CONTEXT_LENGTH=8192"
sudo systemctl daemon-reload && sudo systemctl restart ollama
sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp # Docker のブリッジ帯だけ許可
sudo ufw deny 11434/tcpOLLAMA_ORIGINS は、ブラウザ上で動くWebアプリから直接APIを叩くときのCORS許可オリジンです。サーバー間通信には無関係なので、「繋がらないから」と * を設定しても解決せず、無駄に攻撃面を広げるだけです。繋がらない原因は待ち受けアドレスかファイアウォールにあります。
動作確認：ここまでできていれば完了
$ curl -s http://localhost:11434/
Ollama is running
$ ollama ps
NAME ID SIZE PROCESSOR UNTIL
gemma4:12b 3f2c1a9b8d7e 9.1 GB 100% GPU 4 minutes from now
$ journalctl -u ollama -e --no-pager | grep "inference compute"
... msg="inference compute" library=cuda name="NVIDIA GeForce RTX 3060" total="12.0 GiB" available="11.4 GiB"
$ curl -s http://localhost:11434/api/tags | python3 -c 'import json,sys;[print(m["name"]) for m in json.load(sys.stdin)["models"]]'
gemma4:12b
bge-m3:latestollama ps の SIZE がファイルサイズ（7.6GB）より大きいのはKVキャッシュ分が含まれるためです。この値がVRAM容量を超えるとCPU側に溢れ、PROCESSOR列が分割表示に変わります。ログの「inference compute」行が出ていなければGPUは認識されていません。
つまずきポイント
Error: could not connect to ollama server, run 'ollama serve' to start it
サーバープロセスが起動していません。Linuxは systemctl status ollama、WindowsとmacOSはトレイ（メニューバー）のアプリが動いているかを確認します。別ターミナルで ollama serve を手動起動しても動きますが、その場合はsystemd側と二重起動にならないよう注意してください。
Error: listen tcp 127.0.0.1:11434: bind: address already in use
すでに別のOllamaが11434番を掴んでいます。アプリ版とsystemd版を両方入れたときに起きやすく、ss -ltnp | grep 11434 で握っているPIDを確認し、片方を止めます。
Error: model requires more system memory (9.5 GiB) than is available (7.2 GiB)
GPUに載せきれず、システムRAMにも収まらなかった状態です。数値は環境で変わります。より小さいモデルか低ビットの量子化タグを選ぶか、他のプロセスを止めてメモリを空けます。free -h で空き容量を確認してから、表の目安と照らし合わせてください。
Error: pull model manifest: file does not exist
タグ名の綴り違いか、存在しないサイズ指定です。コミュニティモデルは ユーザー名/モデル名 の形式で、公式ライブラリの短い名前では引けません。ライブラリのモデルページに表示されるタグをそのままコピーしてください。
GPUがあるのに ollama ps が 100% CPU になる
ドライバが古い、コンテナでNVIDIA Container Toolkitが入っていない、あるいはモデルがVRAMより大きい、のいずれかです。サーバーログに「inference compute」行があるか、nvidia-smi がGPUを表示するかを順に確認します。Windowsはドライバ551.61以降、Linuxはcompute capability 5.0以上のNVIDIA GPUが執筆時点の要件です。
長い文書を渡すと前半が無視される
Ollamaの既定コンテキスト長は4096トークンで、超えた分は警告なく切り捨てられます。リクエストの options.num_ctx、または OLLAMA_CONTEXT_LENGTH で広げてください。RAGなら8192以上が実用ラインで、その分KVキャッシュのメモリが増える点は前述のとおりです。
よくある質問
Ollamaは無料で商用利用できますか？
Ollama本体はMITライセンスで、商用利用に制限はありません。制限があるのはモデル側で、GraniteやQwenの多くはApache 2.0、LlamaはLlama Community License、GemmaはGemma Terms of Useと条件が異なります。ollama show モデル名 --license で全文を確認し、社外向けサービスに使うなら法務にも見せてください。
GPUがなくても動きますか？
動きます。ただし生成速度はメモリ帯域で決まり、3〜4B級なら実用、8B級で数トークン/秒、27B以上は待てない速度になります。Apple Siliconのユニファイドメモリは例外で、GPU搭載PCなしでも27B級を実用速度で動かせます。
日本語に強いモデルはどれですか？
執筆時点ではQwen3.5/3.8系とGemma 4系の9〜12B以上が、追加の調整なしで業務文書の日本語を安定して扱えます。日本語特化モデルはHugging FaceからGGUFを取り込む形が確実です。最終判断は自社文書での要約・敬語メール・議事録整理の3テストで行ってください。
モデルはどこに保存されますか？
macOSは ~/.ollama/models、Linux（サービス運用）は /usr/share/ollama/.ollama/models、Windowsは %HOMEPATH%\.ollama\models です。OLLAMA_MODELS で変更でき、Linuxでは移動先の所有者を ollama:ollama にする必要があります。ブロブはダイジェスト名で共有されるので、タグを消しても他のタグが参照している実体は残ります。
まとめ
Ollamaは「モデル配布・量子化済み重みの管理・GPU割り当て・HTTP API」を1バイナリにまとめた実行環境で、既定の127.0.0.1:11434待ち受けは無認証APIを守るための設計です。モデル選びはファイルサイズに2〜4GBを足した値がVRAMに収まるかで決め、日本語用途は9〜12B級から始めると失敗が少なくなります。社内公開はOllama側を触らずリバースプロキシで認証とTLSを付け、0.0.0.0 はコンテナ連携で必要な場合だけファイアウォールとセットで使ってください。
次に読む
- Open WebUIで社内ChatGPT環境を作る：複数人でアカウント管理付きに使う構成
- ローカルLLMの選び方【2026年版】：用途別のモデル系列とGPUの目安
- pgvectorとPythonで作る社内文書RAG：
/api/embedを使った権限付き検索の実装 - 自宅サーバーで何ができる？用途10選：ホームラボでローカルLLMを常駐させる位置づけ