Ollamaの使い方 2026｜ローカルLLMでAIエージェント

2026年9月のOllamaは何が変わったのか

まず旧版（2026年5月）から実際に変わった点を並べます。

項目	2026年5月時点の記述	2026年9月時点の実際
安定版	0.5系という記述	v0.33.2（2026年8月27日）。v0.33.3-rc2 が9月2日公開
推論エンジン	llama.cpp のみ	MLX と llama.cpp の2系統。リポジトリ直下に LLAMA_CPP_VERSION と MLX_VERSION / MLX_C_VERSION が並ぶ
CLI	run / pull / serve 中心	素の ollama で対話メニュー、ollama launch、ollama signin が追加
API	/api/chat と /v1/chat/completions	ネイティブに加え OpenAI 互換（/v1/responses 含む）と Anthropic 互換 /v1/messages
主力モデル	llama3.3 / qwen3 / mistral	gemma4 / qwen3.5 / qwen3.6 / gpt-oss / nemotron-3-super
量子化タグ	Q4_K_M / Q5_K_M 中心	qat / q8_0 / bf16 / mlx / mxfp8 / nvfp4 が公式タグに並ぶ
クラウド	なし	Ollama Cloud（Free / Pro / Max / Team）が同じ CLI から使える

重い変更は3つ。エンジンの二重化、コンテキスト長の既定値が VRAM 依存になったこと、ローカルとクラウドが同じコマンド体系に同居したことです。

エンジンは2系統になった — MLXとllama.cppの分担

旧版では「Ollama は llama.cpp の上に乗ったラッパー」と書きました。2026年9月時点では半分しか当たっていません。

ollama/ollama のリポジトリ直下には、llama.cpp のビルドを固定する LLAMA_CPP_VERSION（2026年9月3日時点で b10760）と、MLX のコミットを固定する MLX_VERSION / MLX_C_VERSION が並びます。リリースノートでも MLX ランナーへの機能追加が続いており、v0.33.1（2026年8月26日）で構造化出力対応、v0.31.1（2026年6月30日）で Apple Silicon 上の Gemma 4 が multi-token prediction によりコーディングエージェント系ベンチマークで平均約90%高速化したと記載されています。一方 README の「Supported backends」節に載っているのは llama.cpp だけで、公式が正面から2エンジン構成を宣言してはいないものの、実装・リリースノート・モデルタグの三方から MLX エンジンの存在が確認できる状態です。

実務上の影響はモデルタグに直接出ます。ollama.com のライブラリでは、同じ gemma4:31b でも 31b-it-q4_K_M（20GB）のような GGUF 系と、31b-mlx（19GB）・31b-mxfp8（34GB）・31b-nvfp4（19GB）のように MLX と明示されたタグが並んでいます。

Apple Silicon の開発機と Linux の GPU サーバで同じタグ名を書いていても、走るランナーが違い得るということです。回帰テストは開発機と本番サーバの両方で回してください。片方だけでは、もう片方の品質は保証されません。

インストールと最初の5分

README に記載されている手順です。旧版の「Windows は公式インストーラのみ」は古く、PowerShell のワンライナーが用意されています。

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# Windows（PowerShell）
irm https://ollama.com/install.ps1 | iex

# Docker（Docker Hub の公式イメージ）
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

インストール後、引数なしで ollama を実行すると対話メニューが開き、モデル実行か外部ツールへの接続（launch）を選べます。ollama run しか知らないと、この入口を見落とします。

ollama                      # 対話メニューを開く
ollama run gemma4           # モデルを直接動かす

ollama launch                        # 統合先を対話で選ぶ
ollama launch claude                 # Claude Code
ollama launch claude --model qwen3.5 # モデル指定
ollama launch droid --config         # 起動せず設定だけ

ollama ps                   # ロード中のモデルと割り当てを見る

統合先として CLI リファレンスには OpenCode / Claude Code / Codex / VS Code / Droid、README にはさらに Copilot CLI・DeepSeek Harness・OpenClaw が挙がっています。エージェント側の設定ファイルを手で書き換えなくても Ollama が仲介する設計です。

ollama ps の出力例です。PROCESSOR 列が 100% GPU か、CONTEXT 列が意図した値かを本番投入前に必ず確認してください。

NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
gemma4:latest    c6eb396dbd59    9.6 GB    100% GPU     131072     2 minutes from now

モデル選定 — 2026年9月にエージェント基盤へ載せる候補

旧版で第一候補にしていた llama3.3 / qwen2.5-coder は、いま選ぶ理由が薄くなりました。v0.32.0（2026年7月11日）のリリースノートに、CodeLlama、Qwen2.5（および -coder）、Llama 3.x、Mistral、素の DeepSeek-R1 タグは ollama launch 時に非推奨の警告を出すと明記されています。以下は2026年9月3日に ollama.com のライブラリで確認した値です（サイズは既定量子化）。

モデル	サイズ	コンテキスト	特徴（公式説明より）
gemma4:12b	7.6GB	256K	推論・エージェント・コーディング・マルチモーダル。vision / tools / thinking / audio
gemma4:31b	20GB	256K	同系列の上位。単一GPUに載せやすい上限帯
qwen3.5:9b	6.6GB	256K	マルチモーダル。0.8bから122bまで7サイズ展開
qwen3.5:27b	17GB	256K	ローカル本番の主力帯
qwen3.6:27b	18GB	256K	エージェント的コーディングと thinking 保持を強化した最新世代
gpt-oss:20b	14GB	128K	OpenAI のオープンウェイト。tools / thinking
nemotron-3-super:120b	87GB	256K	NVIDIA の MoE。総パラメータ120Bで活性12B、マルチエージェント向けと明記
embeddinggemma	622MB	2K	Google の300Mパラメータ埋め込みモデル
qwen3-embedding	4.7GB	40K	埋め込み。0.6b / 4b / 8b

選び方の原則は変わりません。「載る一番大きいモデル」ではなく「そのタスクで品質が確保できる組み合わせ」を選ぶことです。ただしコンテキストは 128K〜256K が標準になり、MoE 構成（nemotron-3-super は総パラメータ120Bで活性12B）が増えてパラメータ数から必要 VRAM を推定できなくなりました。ライブラリの実サイズを見てください。日本語性能は、Ollama 公式が言語別ベンチマークを出していないため本稿では順位付けをしません。自社のゴールデンセットで測るのが唯一の答えです。

量子化タグの読み方 — qat / mxfp8 / nvfp4 が増えた

旧版では GGUF の Q4_K_M / Q5_K_M / Q8_0 / BF16 を軸に整理しました。この軸は今も生きていますが、公式ライブラリのタグに新しい系統が加わっています。

タグ	系統	実務での読み方
q4_K_M / q8_0	GGUF	従来どおり。多くのモデルで既定タグは q4_K_M と同一ダイジェスト
qat	GGUF	QAT（量子化を意識した学習）系。gemma4:31b-it-qat は19GBで q4_K_M の20GBより小さい
bf16	GGUF	ほぼ無損失。31bクラスで63GB
mlx / mlx-bf16	MLX	Apple Silicon 向け。ライブラリ上で MLX と明示される
mxfp8	MLX	新形式。gemma4:31b-mxfp8 は34GBで q8_0 と同サイズ
nvfp4	MLX	新形式。gemma4:31b-nvfp4 は19GB

NVFP4 について ollama.com の料金ページ FAQ には、クラウドモデルは提供元がリリースしたネイティブの重みを使い、最新の NVIDIA ハードウェアでは Blackwell や Vera Rubin がサポートする高速なデータ形式（NVFP4 など）を使う場合がある、と記載があります。数年前の「4bit は品質が落ちる」という直感をそのまま NVFP4 に当てはめないでください。形式が違います。

エージェント用途での実務ルールは3つに絞れます。

1. ツール呼び出しと構造化出力が主タスクなら、既定タグより上の帯（qat か q8_0）で先に品質を測ってから落とす。落としてから上げるより判断が速い。
2. 埋め込みモデルで容量を節約しない。embeddinggemma は622MB、qwen3-embedding の既定でも4.7GB。検索品質を削る節約先ではありません。
3. 本番はタグではなくダイジェストで固定する。ollama ps やライブラリの ID（例: c6eb396dbd59）を記録し、差し替えを検知できるようにします。

コンテキスト長の既定値とVRAM — エージェントは64,000トークン以上

本番設計に直結する変更です。公式の Context length ドキュメントに、Ollama は VRAM に応じて既定のコンテキスト長を自動で決めると明記されています。

VRAM	既定コンテキスト長
24GiB 未満	4K
24〜48GiB	32K
48GiB 以上	256K

同じページに、Web検索・エージェント・コーディングツールのように大きなコンテキストを要求するタスクは最低でも 64,000 トークンに設定すべきと書かれています。24GiB の GPU で既定 4K のままエージェントを回すと数ターンで履歴が押し出されます。「モデルが急に前の指示を忘れる」の相当数はこれです。

# サーバ起動時に既定コンテキスト長を上げる
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# 割り当てを確認する（CONTEXT 列と PROCESSOR 列を見る）
ollama ps

同時に効くのが並列数です。公式 FAQ には 必要 RAM は OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH でスケールすると明記されています。64,000 トークン × 並列4なら、4,000 トークン × 並列1 の64倍の KV キャッシュを積む計算です。旧版で「本番ピークで OOM になる原因のほぼ全例」と書いたものの正体が、公式の式として明示された形です。

エージェントから叩くAPI — ネイティブ / OpenAI互換 / Anthropic互換

Ollama は3系統のインタフェースを提供しています。既存のエージェント実装をほぼ書き換えずに載せ替えられるのが強みです。

1) ネイティブ API。ベース URL はローカルが http://localhost:11434/api、Cloud 直叩きが https://ollama.com/api。

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

レスポンスには total_duration / load_duration / prompt_eval_count / prompt_eval_cached_count / eval_count / eval_duration といった計測フィールドが入ります（時間はナノ秒）。とくに prompt_eval_cached_count（キャッシュから読めたプロンプトトークン数）は、毎ターン長い履歴を送り直すエージェントでは観測必須です。

2) OpenAI 互換 API。/v1/chat/completions に加え /v1/completions、/v1/models、/v1/embeddings、/v1/responses（v0.13.3で追加）が使えます。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1/",
    api_key="ollama",  # 必須だが無視される
)

chat = client.chat.completions.create(
    model="gpt-oss:20b",
    messages=[{"role": "user", "content": "Say this is a test"}],
)
print(chat.choices[0].message.content)

# Responses API（ステートフル機能は未対応）
res = client.responses.create(model="qwen3:8b", input="Write a haiku")
print(res.output_text)

対応状況は公式にチェックリストで載っています。設計に効くのは、tools / response_format / reasoning_effort（high・medium・low・max・none）は対応、tool_choice と logprobs と n は未対応という点。ツールの強制呼び出しを tool_choice に頼っている実装は書き換えが要ります。またコンテキストサイズは OpenAI API では指定できないため、Modelfile で num_ctx を設定した派生モデルを呼ぶよう公式に案内されています。

3) Anthropic 互換 API。/v1/messages が使え、Claude Code のように Anthropic API を前提としたツールを環境変数2つでローカルへ向けられます。

export ANTHROPIC_AUTH_TOKEN=ollama   # 必須だが無視される
export ANTHROPIC_BASE_URL=http://localhost:11434

Anthropic 公式 SDK を使う場合も base_url をこの値へ向けるだけです。

GitHub Copilot 側から Ollama を BYOK で使う構成は GitHub Copilot×Ollama接続ガイド に、Claude Code とローカル Qwen を組み合わせるハイブリッド開発は Claude Code × Qwen 3.5のハイブリッド開発 にまとめてあります。

ツール呼び出しとエージェントループの実装

ローカル LLM でエージェントを組むときの核心です。まず単発呼び出し。Python SDK は関数をそのまま tools に渡せば、docstring と型注釈からツールスキーマを自動生成します。手書き不要です。

from ollama import chat

def get_temperature(city: str) -> str:
  """Get the current temperature for a city

  Args:
    city: The name of the city
  """
  return {"New York": "22C", "Tokyo": "18C"}.get(city, "Unknown")

messages = [{"role": "user", "content": "What is the temperature in Tokyo?"}]

# 関数をそのまま tools に渡せる
response = chat(model="qwen3", messages=messages, tools=[get_temperature], think=True)

messages.append(response.message)
if response.message.tool_calls:
    call = response.message.tool_calls[0]
    result = get_temperature(**call.function.arguments)
    # ツール結果は role=tool + tool_name で返す
    messages.append({"role": "tool", "tool_name": call.function.name, "content": str(result)})
    final = chat(model="qwen3", messages=messages, tools=[get_temperature], think=True)
    print(final.message.content)

見落としやすいのは、ツール結果が {"role": "tool", "tool_name": ..., "content": ...} という形である点です。OpenAI 形式の tool_call_id ではありません。移植時にここで詰まります。

次にエージェントループ。公式には「モデルにループの中にいること、複数回ツールを呼べることを伝えると効果がある場合がある」という注記が添えられています。

from ollama import chat, ChatResponse

def add(a: int, b: int) -> int:
  """Add two numbers"""
  return a + b

def multiply(a: int, b: int) -> int:
  """Multiply two numbers"""
  return a * b

available_functions = {"add": add, "multiply": multiply}
messages = [{"role": "user", "content": "(11434+12341)*412 は?"}]

while True:
    response: ChatResponse = chat(
        model="qwen3",
        messages=messages,
        tools=list(available_functions.values()),
        think=True,
    )
    messages.append(response.message)

    calls = response.message.tool_calls or []
    if not calls:
        break

    for call in calls:
        fn = available_functions.get(call.function.name)
        if fn is None:
            continue
        result = fn(**call.function.arguments)
        messages.append({
            "role": "tool",
            "tool_name": call.function.name,
            "content": str(result),
        })

print(messages[-1])

並列ツール呼び出しにも対応しており、1ターンで複数の tool_calls が返ります。1件目だけ処理して残りを捨てると、モデルは待っている結果が来ないまま推論を続け、無言で品質が落ちます。ストリーミング併用時は thinking・content・tool_calls を別々に蓄積し、次のリクエストで1つの assistant メッセージとしてまとめて戻す、と公式に明記されています。

構造化出力とthinkingの制御

旧版で「関数呼び出しの JSON が壊れる」と書いた問題は、いまは format パラメータに JSON Schema をそのまま渡して解けます。

from ollama import chat
from pydantic import BaseModel

class Plan(BaseModel):
  thought: str
  next_action: str
  tool_name: str | None
  tool_args: dict | None

response = chat(
  model="gpt-oss",
  messages=[{"role": "user", "content": "請求書PDFから合計金額を抽出する手順を計画して"}],
  format=Plan.model_json_schema(),
  options={"temperature": 0},
)

plan = Plan.model_validate_json(response.message.content)
print(plan)

公式が挙げるコツは3点。Pydantic や Zod でスキーマを定義して検証にも使い回す、temperature を 0 まで下げる、そしてスキーマを文字列としてプロンプトにも入れて出力を接地させる。3つ目は見落とされがちですが効きます。

重要な制約が1つ。Ollama Cloud は現時点で構造化出力に対応していないと公式ドキュメントの冒頭に注記されています。ローカルで構造化出力に依存した設計を組み、フォールバック先をクラウドモデルにしていると、切り替わった瞬間にスキーマが効かなくなります。設計時に切り分けてください。

thinking 系モデルの制御も整理されました。think フィールドに真偽値、またはレベル（low / medium / high / max）を渡します。推論トレースは message.thinking、最終回答は message.content に分かれて返ります。

# 単発で思考を有効化
ollama run deepseek-r1 --think "Where should I visit in Lisbon?"

# 思考は使うがトレースは隠す
ollama run deepseek-r1 --hidethinking "Is 9.9 bigger or 9.11?"

# 対話セッション中は /set think と /set nothink で切り替え

ただし gpt-oss だけは low / medium / high のレベル指定のみを受け付け、true / false は無視されると明記されています。共通ラッパーで think=True を全モデルに投げている実装は、gpt-oss で意図と違う挙動になります。

Modelfileと本番運用の環境変数

Modelfile の書き方自体は大きく変わっていませんが、命令が1つ増え、パラメータの既定値が一部変わりました。

# Modelfile.agent-planner
FROM gemma4:31b

REQUIRES 0.33.0

PARAMETER temperature 0.2
PARAMETER num_ctx 65536
PARAMETER top_p 0.9

SYSTEM """
あなたは AIエージェントのプランナーです。
出力は必ず与えられたJSONスキーマに従ってください。
"""

ollama create agent-planner -f Modelfile.agent-planner
ollama run agent-planner "請求書PDFから合計金額を抽出して"

REQUIRES は、そのモデルが必要とする Ollama の最小バージョンを宣言する命令です（v0.14.0で追加）。社内で Modelfile を共有するとき、古いクライアントで静かに壊れるのを防げます。パラメータ側で注意が要るのは repeat_penalty の既定値で、公式リファレンスには「Default: 1.0, disabled」と書かれています。既定で効いている前提だと、繰り返しが出たときに原因を取り違えます。投機デコード用の draft_num_predict も増えました。

本番の挙動を決める環境変数のうち、エージェント基盤で必ず握るべきものを抜き出します。

環境変数	既定	エージェント基盤での使いどころ
OLLAMA_CONTEXT_LENGTH	VRAM依存（4K/32K/256K）	エージェントは64,000以上に上げる
OLLAMA_NUM_PARALLEL	1	上げると必要RAMがコンテキスト長との積で増える
OLLAMA_MAX_LOADED_MODELS	GPU数×3（CPUは3）	本番ワーカーは1モデル専有にするため下げる
OLLAMA_MAX_QUEUE	512	超えると503を返す。上限設計はここ
OLLAMA_KEEP_ALIVE	5分	常時稼働ワーカーは負値で常駐、バッチ後は0で即解放
OLLAMA_KV_CACHE_TYPE	f16	q8_0 でKVキャッシュを約半分に（Flash Attention有効時。OLLAMA_FLASH_ATTENTION は1で強制・0で無効）

OLLAMA_KV_CACHE_TYPE は、q8_0 が f16 の約半分のメモリで体感品質への影響はほぼなし、q4_0 は約4分の1だが小〜中程度の精度低下があり長いコンテキストほど目立つ、と説明されています。全モデル共通のグローバル設定であること、GQA数の多いモデルほど影響を受けやすいことも明記されています。1台に複数用途を同居させると、この設定は分離できません。

API 単位では keep_alive を渡せます。プリウォームと即時解放の両方に使えます。

# 常駐させる（負値）
curl http://localhost:11434/api/generate -d '{"model": "gemma4:31b", "keep_alive": -1}'

# 即座にアンロードする
curl http://localhost:11434/api/generate -d '{"model": "gemma4:31b", "keep_alive": 0}'

GPU 要件も更新されました。NVIDIA は Compute Capability 5.0 以上かつドライバ 550 以降（CC 5.0〜6.2 は 570 以降）、AMD は ROCm v7 世代、Apple は Metal、加えて Windows / Linux で Vulkan サポートが入りました。絞り込みは CUDA_VISIBLE_DEVICES / ROCR_VISIBLE_DEVICES / GGML_VK_VISIBLE_DEVICES。

ローカルとOllama Cloudの使い分け

旧版で「クラウドAPI とローカルのハイブリッド」と書いた構図に、Ollama 自身がクラウドを持ち込みました。同じ CLI から gpt-oss:120b-cloud のようなタグを叩けます。

ollama signin
ollama run gpt-oss:120b-cloud

# API キー経由で ollama.com を直接叩く場合
export OLLAMA_API_KEY=your_api_key
curl https://ollama.com/api/generate \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{"model": "gpt-oss:120b", "prompt": "Why is the sky blue?", "stream": false}'

2026年9月3日時点の ollama.com/pricing 掲載プランです（別途 Enterprise は個別見積もり）。

プラン	月額	月あたり利用クレジット	同時実行数
Free	$0	スターター分のみ	1
Pro	$20（年払い $200 / 月あたり $16.67）	$60	3
Max	$100	$300	10
Team（早期アクセス）	$500	$1,000（チーム共有）	10

トークン単価も公開されています（100万トークンあたり）。代表的なものを引きます。

モデル	入力	キャッシュ入力	出力
gemma4	$0.14	$0.05	$0.40
gpt-oss:20b	$0.07	$0.035	$0.30
gpt-oss:120b	$0.15	$0.014	$0.60
nemotron-3-super	$0.015	$0.015	$0.60
qwen3.5:397b	$0.60	$0.60	$3.60
kimi-k3	$3.00	$0.30	$15.00

設計判断の軸は、旧版から1つ増えて4つになりました。

1. 機密境界: データがローカルから出てはいけないなら無条件でローカル。Ollama Cloud も外部送信です。
2. 難易度: 長い計画・複雑な設計は大型モデル。分類・抽出・要約・ルーティングはローカルの小型モデル。
3. 同時実行数: Ollama Cloud は Free 1 / Pro 3 / Max・Team 10 という上限が明示されています。超えた分はキューに入り、キューが埋まると拒否されます。並列エージェントを回す設計では、この数がそのままスループットの天井です。
4. 機能差: 前述のとおり構造化出力はクラウド非対応です。ローカルとクラウドで使える機能が同一ではありません。

もう1点、Ollama Cloud にはモデルの退役スケジュールが日付付きで公開されています（例: 2026年7月31日付で minimax-m2.5 は minimax-m2.7 へ）。退役はローカルモデルには影響しないとも明記されています。固定費と可用性を取るならローカル、最新の大型モデルを都度使いたいならクラウド、という分岐がここでも効きます。

エージェント全体のコスト設計は AIエージェントのコスト最適化:7原則と具体的削減手法 に、GPU サーバでのセルフホスト推論を本気で組む場合は vLLMでオープンLLMをセルフホスト推論する本番運用ガイド にまとめてあります。

機密データ運用とローカル限定モード

「ローカルLLM を採用したから安全」ではありません。クラウド機能が同じバイナリに同居した2026年9月の Ollama では、意図せず外に出ない構成を明示的に作る必要があります。公式 FAQ にクラウド機能を完全に切る手順が用意されています。

// ~/.ollama/server.json
{
  "disable_ollama_cloud": true
}

# 環境変数でも同じことができる
OLLAMA_NO_CLOUD=1 ollama serve

# 有効化されるとログに次が出る
# Ollama cloud disabled: true

切ると Ollama Cloud のモデルと Web 検索が使えなくなります。逆に言えばログでこの1行を確認できていない環境は「ローカル限定」と言い切れません。機密案件では監査項目に入れてください。

ネットワーク設計は旧版から変わりません。OLLAMA_HOST の既定は 127.0.0.1:11434。社内共有時も公開ネットワークに直接開けず、Nginx などのプロキシか VPN の内側に置きます（公式 FAQ に Nginx 例あり）。

公式 FAQ には、ローカル実行時はプロンプトもデータも見ない、クラウド利用時も内容の保存・ログ・学習利用はしない、モデルは主に米国でホストし需要に応じて欧州とシンガポールへルーティングする場合がある、と記載があります。この記述をそのまま社内規程に貼らず、契約書と利用規約で裏を取ってから採否を決めてください。

RAG パイプラインを内側に抱える場合の設計は Agentic RAG 4パターン比較、本番の監視設計は AIエージェントのSRE実装ガイド を参照してください。ローカルLLM では、外部 API にはない GPU 利用率・VRAM 残量・モデルプロセスのクラッシュリカバリが監視項目に加わります。

llama.cpp直叩き・vLLM・GUIツールとの分岐

Ollama で全部済むわけではありません。現実的な分岐を整理します。

状況	選択	理由
複数モデルを差し替えて評価したい / エージェントから OpenAI・Anthropic 互換で叩きたい	Ollama	3系統のAPIとモデル管理が揃っている
1モデルを高並列・高スループットで本番提供したい	vLLM	連続バッチングとページドアテンションが本領
組み込み・エッジ・独自ビルド	llama.cpp 直叩き	依存が最小。llama-server の細かいフラグを握れる
非エンジニアに配って触ってもらいたい	GUIツール	CLIの学習コストを外せる

llama.cpp 本体のリポジトリは ggml-org/llama.cpp（Ollama の README もここをリンク）で、2026年9月3日時点で Ollama が固定しているビルドは b10760、llama.cpp 側の最新ビルドは b10775 です。最新機能が Ollama に降りてくるまで数日〜数週のラグがあると考えてください。新しい量子化やバックエンドをすぐ試したいなら直叩きです。

GUI 側の比較は LM Studio Bionicとは に、Ollama で30Bクラスのモデルをローカル実行する具体例は Muse Glimmerの使い方 にまとめています。

本番でハマる失敗パターン

実装レビューでよく指摘する順に並べます。

❌ 24GiBのGPUに載せて既定のまま回し、数ターンで指示を忘れる
⭕ OLLAMA_CONTEXT_LENGTH=64000 を設定し、ollama ps の CONTEXT 列で実際の割り当てを確認する。24GiB 未満の既定は 4K。公式が「エージェントは最低64,000」と書く理由がここです。

❌ 並列数を上げてスループットを稼ごうとして、ピーク時にOOMする
⭕ 必要 RAM は OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH で増える、と公式が明記しています。並列を上げる前にコンテキスト長との積で見積もり、足りなければ OLLAMA_KV_CACHE_TYPE=q8_0 を先に検討する。

❌ 複数の tool_calls が返ってきたのに1件目だけ処理する
⭕ 並列ツール呼び出しに対応しているので、返ってきた tool_calls を全部実行し、全部の結果を role: tool で積んでから次のターンへ渡す。1件でも欠けるとモデルは欠けた前提で推論を続けます。

❌ 構造化出力に依存した設計のまま、フォールバック先をOllama Cloudにしている
⭕ Ollama Cloud は構造化出力に未対応と公式に注記されています。フォールバック経路では JSON Schema が効かない前提で、パース失敗時のリトライか、別の検証層を必ず用意する。

❌ 共通ラッパーで全モデルに think=True を投げ、タグ名だけでモデルを固定したつもりになっている
⭕ gpt-oss は low / medium / high のレベル指定のみを受け付け、真偽値は無視されます。またタグが同じでも配信内容は更新されるため、ダイジェストを記録し、モデル変更・量子化変更・システムプロンプト変更・Ollama バージョンアップの4タイミングで100〜300件規模のゴールデンセット回帰テストを回す。

❌ 「ローカルで動かしているから外に出ていない」と口頭で説明する
⭕ ~/.ollama/server.json の disable_ollama_cloud か OLLAMA_NO_CLOUD=1 を設定し、ログの Ollama cloud disabled: true を証跡として残す。

よくある質問

Ollamaは無料ですか

自分のハードウェアで動かす分は無料です。料金ページにも「自分のハードウェアで動かす分は常に無制限」と記載があります。有料になるのは Ollama Cloud のモデルを使う場合で、Free でもスターター分の利用枠が付き、Pro が月額 $20、Max が月額 $100 です。

Ollamaのモデル一覧はどこで見られますか

ollama.com のライブラリと検索ページが一次情報です。2026年9月3日時点のエージェント用途の主要どころは gemma4、qwen3.5、qwen3.6、gpt-oss、nemotron-3-super、埋め込みは embeddinggemma と qwen3-embedding。CLI では ollama ls と ollama ps で確認できます。

GPUが使われないのはなぜですか

まず ollama ps の PROCESSOR 列を見てください。100% GPU でなければ CPU へオフロードされています。原因の多くは VRAM 不足（モデルサイズとコンテキスト長の合計が入りきらない）か、ドライバ要件未達です。Linux ではサスペンド復帰後に GPU を見失う既知の挙動もあり、公式は nvidia_uvm の再読み込みを回避策として案内しています。

Modelfileとは何ですか

ベースモデルにシステムプロンプト・パラメータ・テンプレート等を宣言的に載せて派生モデルを作る設定ファイルです。命令は FROM（必須）、PARAMETER、TEMPLATE、SYSTEM、ADAPTER、LICENSE、MESSAGE、REQUIRES の8つ。ollama create モデル名 -f Modelfile で作ります。プランナー層・要約層のように役割ごとに派生モデルを作ると運用が安定します。

Ollama Cloudの制限は何ですか

同時実行数が Free 1、Pro 3、Max と Team は 10 です。超えた分はキューに入り、満杯だとリクエストは拒否されます。月あたりの利用クレジットは繰り越しできません。機能面では構造化出力が未対応です。モデルの退役スケジュールも公開されており、事前にメールとウェブサイトで告知されるとされています。

LM StudioとOllamaはどちらを選ぶべきですか

用途が違います。Ollama は CLI と API 中心のランタイムで、エージェントやアプリケーションから叩く前提の設計。GUI 中心のツールは非エンジニアへの配布や手元での試行に向きます。エージェント基盤に組み込むなら Ollama、人が画面で触る前提なら GUI ツール、という切り分けが実務的です。

まとめ：今日から始める3つのアクション

1. 今日やること: 手元の Ollama を最新版（v0.33.2）に上げ、ollama ps の CONTEXT 列と PROCESSOR 列を確認する。CONTEXT が 4096 のままなら OLLAMA_CONTEXT_LENGTH=64000 を設定して再起動する。
2. 今週中: 既存エージェントの1機能だけを OpenAI 互換 API か Anthropic 互換 API でローカルへ向け、ツール呼び出しと構造化出力が期待どおり動くか確認する。tool_choice に依存していた箇所があれば書き換える。
3. 今月中: 自社タスクのゴールデンセットを100件用意し、ローカルモデル・量子化タグ・クラウドモデルの3通りで通す。あわせて disable_ollama_cloud の設定とログ確認を機密案件向け構成として文書化する。

参考・出典

• Ollama documentation — 公式ドキュメント（参照日: 2026-09-03）
• ollama/ollama — README・docs（参照日: 2026-09-03）
• Ollama Releases — v0.30.0 / v0.31.1 / v0.32.0 / v0.33.0 / v0.33.2（参照日: 2026-09-03）
• Ollama Model Library — タグ・サイズ・コンテキスト長（参照日: 2026-09-03）
• Ollama Pricing — プラン・トークン単価・同時実行数（参照日: 2026-09-03）
• ggml-org/llama.cpp — 推論エンジン本体（参照日: 2026-09-03）

著者:佐藤傑(さとう・すぐる)。株式会社Uravation 代表取締役。X(@SuguruKun_ai)フォロワー約10万人。著書『AIエージェント仕事術』。

関連記事: GitHub Copilot×Ollama接続ガイド｜BYOKでローカルLLM

あわせて読みたい

• ▸ gpt-image-2.5 API｜Flare/Sunburstの料金と移行手順
• ▸ Anthropic MHSとは？AIが実験装置を動かす新標準を解説
• ▸ Agent Pluginsとは｜Claude SkillsとMCPを統一する標準
• ▸ Gemini Managed Agents強化、予算管理と環境フックを追加
• ▸ Gemini SparkとAntigravityの違い｜関係と使い分け