OllamaのAPIパラメータで出力品質を制御する方法|temperature・top_p・num_ctxをPythonから動的に調整して用途別AIを実現する

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)ローカルLLM > OllamaのAPIパラメータで出力品質を制御する方法|temperature・top_p・num_ctxをPythonから動的に調整して用途別AIを実現する
「Ollamaでモデルを動かしているが、出力がプロンプトを変えるたびにバラバラで安定しない」
「temperature を変えたいのに、どこでどう指定すればいいか調べてもわからない」

そんな疑問を持つLinuxエンジニアやAI活用担当者は多いはずです。この記事では、Ollamaが受け付けるAPIパラメータ(temperature・top_p・top_k・num_ctx・num_predict)の役割と設定範囲を整理し、curlおよびPythonから動的に制御する具体的な手順を解説します。
コード生成・文書要約・社内Q&Aなど用途ごとの推奨パラメータセットも表にまとめているので、設定値で迷う時間を一気に短縮できます。

この記事のポイント

・temperature=0.0~0.2でコード生成の精度が安定し、num_predict・num_ctxで速度と長文対応を制御できる
・curl の /api/generate に options オブジェクトを渡すだけでパラメータを即時切り替えられる
・PythonのPRESETS辞書に用途別設定をまとめると、チーム全体の設定標準化と属人化防止につながる
・num_ctx を拡張するほど KV-cache が VRAM を消費するため、nvidia-smi で空き容量を確認してから設定変更する


OllamaのAPIパラメータで出力品質を制御する方法|temperature・top_p・num_ctxをPythonから動的に調整して用途別AIを実現する

「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

Ollamaのパラメータが出力品質を左右する理由

OllamaはLLMをローカルで動かすサーバーだが、「同じプロンプトを送っても毎回まったく違う答えが返る」「要約させると関係のない話が混入する」という経験をした人は少なくない。
この現象の多くは、モデルの生成パラメータが用途に合っていないことが原因だ。

LLMが次のトークン(単語の断片)を選ぶとき、内部では語彙全体に対する確率分布を計算している。
temperatureはその確率分布の「広がり方」を制御するパラメータで、値が大きいほどランダム性が増し、値が小さいほど最も確率の高いトークンに集中する。
コード生成のように「正しい構文だけを出してほしい」場面ではtemperatureを低くし、ブレインストーミングのように「多様なアイデアを出してほしい」場面では高くするのが基本原則だ。

Ollamaはデフォルト値でも動くが、デフォルト設定はあくまで汎用目的の設定だ。
業務用途にそのまま流用し続けると、精度の面で確実に損をしている。
パラメータを理解して用途別に調整することが、ローカルLLMを実用レベルに引き上げる最短経路になる。

なお、この記事での操作はOllamaが構築済みであることを前提にしている。まだ環境が整っていない場合は、Ubuntu ServerでローカルLLMを構築する方法で環境を整えてから戻ってきてほしい。

主要パラメータの役割と設定範囲を押さえる

Ollamaが受け付けるパラメータは多岐にわたるが、業務用途で実際に調整するのは以下の5つに絞られる。

1. temperature(デフォルト 0.8・範囲 0.0 ~ 2.0)

次トークンの確率分布をスケールするパラメータ。
0.0 に近づけるほど greedy decoding(最高確率のトークンだけを選ぶ)に近づき、出力が決定論的になる。
1.0 を超えると低確率のトークンも選ばれやすくなり、出力の多様性が増す代わりに事実誤認や構文崩れが起きやすくなる。
コード生成・SQL生成・データ抽出では 0.0 ~ 0.3 が実用域。会話・Q&Aでは 0.5 ~ 0.7。創作・アイデア出しでは 0.8 ~ 1.2 を試す。

2. top_p(デフォルト 0.9・範囲 0.0 ~ 1.0)

確率の累積が top_p に達するまでのトークン集合から次トークンをサンプリングする手法(Nucleus Sampling)。
top_p=0.9 なら、確率の上位90%を占めるトークンだけを候補にする。
temperatureと組み合わせて使うのが一般的で、精度重視なら top_p=0.5、多様性重視なら top_p=0.95 が出発点になる。

3. top_k(デフォルト 40・整数)

候補トークンを上位 k 個に絞ったうえでサンプリングするパラメータ。
top_p と組み合わせると、まず top_k で候補を k 個に絞り、次に top_p でさらに絞るという2段階のフィルタリングになる。
ほとんどの業務用途では top_p だけを調整すれば十分で、top_k は初期値のまま使うことが多い。

4. num_ctx(デフォルト 2048・整数)

モデルが一度に参照できるトークン数(コンテキストウィンドウ)を指定するパラメータ。
Ollama 3.x 以降のデフォルトは 2048 だが、モデル自体は 8,192 や 128,000 トークンまで対応していることが多い。
社内文書の要約や長いコードレビューでは 4,096 ~ 32,768 に拡張する。
ただしコンテキスト長を伸ばすほど KV-cache が VRAM を消費するため、GPU のメモリ残量を確認してから変更するのが鉄則だ。

5. num_predict(デフォルト -1・整数)

モデルが生成する最大トークン数を指定するパラメータ。-1 は無制限(num_ctx が事実上の上限)。
一言回答を期待する Q&A では 50 ~ 100 に絞ることでレスポンス速度が大幅に向上する。
長文レポートや要約では -1 のままか 2,048 以上を設定する。

curlでOllama APIにパラメータを渡す基本手順

OllamaのREST APIは `/api/generate`(単発生成)と `/api/chat`(会話形式)の2エンドポイントを持つ。
どちらもリクエストボディの `options` オブジェクトにパラメータを渡せる形式だ。

1. /api/generate でtemperatureを低く設定してコード生成する

# temperature=0.2、num_ctx=8192 でコード生成リクエストを送る $ curl -s http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{ "model": "llama3.3:70b-instruct-q4_0", "prompt": "Bashでファイルの行数を数えるワンライナーを書いてください", "stream": false, "options": { "temperature": 0.2, "top_p": 0.5, "num_ctx": 8192, "num_predict": 512 } }' | python3 -m json.tool # 出力例(responseフィールドに生成テキストが入る) { "model": "llama3.3:70b-instruct-q4_0", "created_at": "2026-07-21T10:15:32.841Z", "response": "wc -l ファイル名", "done": true, "total_duration": 4823691200, "prompt_eval_count": 32, "eval_count": 8 }

`stream: false` にするとバッファリングして一括返却されるため、スクリプト処理やログ確認に向いている。
`total_duration` はナノ秒単位の処理時間だ。パラメータ変更前後でこの値を比較すると応答速度への影響を定量で確認できる。

2. /api/chat で会話形式にパラメータを渡す

# temperature=0.5 で社内Q&A用チャットリクエストを送る $ curl -s http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "mistral:7b-instruct-q8_0", "messages": [ {"role": "user", "content": "Pythonの辞書型を一言で説明してください"} ], "stream": false, "options": { "temperature": 0.5, "top_p": 0.9, "num_ctx": 4096, "num_predict": 256 } }' | python3 -m json.tool # 出力例(message.contentに応答テキストが入る) { "model": "mistral:7b-instruct-q8_0", "created_at": "2026-07-21T10:16:44.120Z", "message": { "role": "assistant", "content": "キーと値のペアを管理するハッシュテーブル型のデータ構造です。" }, "done": true }

会話を継続するには、レスポンスの `message` オブジェクトを `messages` 配列に追記して次のリクエストを送る。
会話履歴はすべてクライアント側が管理する設計なので、num_ctx の範囲内に収まるよう履歴の長さを管理する必要がある。

PythonからAPIパラメータを動的に切り替える実装

用途ごとに毎回 curl コマンドを書き換えるのは非効率だ。
Pythonでラッパー関数を作り、プリセット辞書に用途別パラメータをまとめておくと、チーム全体で設定が標準化できる。

1. 最小構成の送信関数(requestsライブラリを使用)

import requests OLLAMA_URL = "http://localhost:11434/api/generate" def ask_ollama(prompt: str, model: str, options: dict) -> str: payload = { "model": model, "prompt": prompt, "stream": False, "options": options } resp = requests.post(OLLAMA_URL, json=payload, timeout=120) resp.raise_for_status() return resp.json()["response"] # コード生成プリセット(精度優先・低temperature) CODE_OPTIONS = { "temperature": 0.1, "top_p": 0.5, "num_ctx": 8192, "num_predict": 1024 } # 文書要約プリセット(長文対応・num_ctx拡張) SUMMARY_OPTIONS = { "temperature": 0.4, "top_p": 0.8, "num_ctx": 32768, "num_predict": 2048 } # 実行例 result = ask_ollama( "Pythonでリストをバブルソートするコードを書いてください", "llama3.3:70b-instruct-q4_0", CODE_OPTIONS ) print(result)

2. 用途名を引数で指定できるプリセット切替関数

PRESETS = { "code": {"temperature": 0.1, "top_p": 0.5, "num_ctx": 8192, "num_predict": 1024}, "sql": {"temperature": 0.0, "top_p": 0.5, "num_ctx": 4096, "num_predict": 512}, "summary": {"temperature": 0.4, "top_p": 0.8, "num_ctx": 32768, "num_predict": 2048}, "qa": {"temperature": 0.5, "top_p": 0.9, "num_ctx": 4096, "num_predict": 512}, "creative":{"temperature": 1.0, "top_p": 0.95,"num_ctx": 4096, "num_predict": 2048}, } def ask_ollama_preset( prompt: str, model: str = "llama3.3:70b-instruct-q4_0", preset: str = "qa" ) -> str: options = PRESETS.get(preset, PRESETS["qa"]) return ask_ollama(prompt, model, options) # コード生成モードで実行 print(ask_ollama_preset( "SQLのNULL値を含む行を除外するWHERE句を書いてください", preset="sql" )) # 文書要約モードで実行(長文を渡す場合) long_doc = open("report.txt").read() print(ask_ollama_preset( f"次の文書を200字以内で要約してください:\n{long_doc}", model="mistral:7b-instruct-q8_0", preset="summary" ))

業務システムへのAPI組み込み方法の全体像は、ローカルLLMのモデルを比較する方法のモデル別の特性整理と合わせて読むと、パラメータ設定とモデル選定の両面から最適解を導き出しやすくなる。

用途別の推奨パラメータセット早見表

実際の現場でよく使われる用途ごとにパラメータの推奨値をまとめた。
これはあくまで出発点で、同じプロンプトを5回実行して出力のブレを目視確認しながら0.1刻みで微調整するのが定石だ。
用途temperaturetop_pnum_ctxnum_predictモデル例
コード生成0.1 ~ 0.20.581921024llama3.3:70b-instruct-q4_0
SQL・構造化抽出0.0 ~ 0.10.54096512Phi-4:14b-q8_0
長文要約0.40.8327682048mistral:7b-instruct-q8_0
社内Q&A・チャット0.5 ~ 0.60.94096512Gemma 3:12b-instruct-q4_0
アイデア出し・創作0.9 ~ 1.10.9540962048llama3.3:70b-instruct-q4_0
ログ分類・ラベリング0.00.5204864Phi-4:14b-q8_0

Phi-4 を SQL 生成や分類タスクに推奨している理由は、14Bクラスのモデルの中で論理的一貫性が高く、temperature=0.0 に設定したときに構文崩れが少ないからだ。
Gemma 3 は日本語の応答品質が安定しており、Q&Aや問い合わせ対応のチャットボット用途に向いている。

情シス担当者が社内展開コストや承認フローを検討している場合は、社内でChatGPTが使えないときの代替手段でセキュリティ・コストの整理から読み始めると全体像をつかみやすい。

num_ctxを拡張してロング文書処理を最適化する

長い社内文書を一度に渡して要約させたい場合、デフォルトの num_ctx=2048 ではプロンプトが途中でカットされる。
ここでは、モデルの最大コンテキスト長を確認してから安全に num_ctx を拡張する手順を説明する。

1. モデルが対応する最大コンテキスト長を確認する

# モデル情報を取得してコンテキスト長を確認する $ curl -s http://localhost:11434/api/show \ -H "Content-Type: application/json" \ -d '{"model": "mistral:7b-instruct-q8_0"}' \ | python3 -c " import sys, json d = json.load(sys.stdin) info = d.get('model_info', {}) for k, v in info.items(): if 'context' in k.lower(): print(f'{k}: {v}') " # 出力例 # llama.context_length: 32768

`llama.context_length` の値がそのモデルが対応する最大 num_ctx だ。
この値を超えた num_ctx を指定してもモデル側でクランプされるため、無駄に VRAM を確保するだけになる。

2. VRAMの空き容量を確認してから num_ctx を変更する

num_ctx を 2,048 から 32,768 に変更すると、KV-cache のメモリ消費が約16倍に増える。
A4000(16GB VRAM)で 70B-q4_0 モデルを動かしている場合、num_ctx=8,192 が安全な上限になることが多い。

# VRAM空き容量を確認する $ nvidia-smi --query-gpu=memory.used,memory.free,memory.total \ --format=csv,noheader,nounits # 出力例(単位: MiB) # 8452, 7740, 16192 # num_ctx=16384 でテストリクエストを送る $ curl -s http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{ "model": "mistral:7b-instruct-q8_0", "prompt": "次の文章を3行で要約してください: テスト入力", "stream": false, "options": {"num_ctx": 16384, "temperature": 0.4, "num_predict": 512} }' | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['response'])"

VRAM が不足すると Ollama がモデルをCPUにオフロードし、処理速度が10分の1以下になる。
`nvidia-smi` で空き容量を確認したうえでリクエストを送り、`total_duration` が想定内かチェックするのが安全な進め方だ。

3. 文書トークン数を事前に見積もる

num_ctx を設定する前に、渡す文書のトークン数を大まかに把握しておくと無駄な設定変更を避けられる。
日本語テキストは概ね「文字数 × 1.3 ~ 1.8」がトークン数の目安になる(モデルのトークナイザーに依存する)。
1,000字の文書なら 1,300 ~ 1,800 トークン、10,000字なら 13,000 ~ 18,000 トークン程度を見込む。
プロンプト全体(システムプロンプト+文書+指示文)を合算したトークン数が num_ctx の8割以内に収まるよう設定すると、出力トークン分の余裕を確保できる。

よくあるトラブルと対処法

出力が短すぎて途中で止まる

`num_predict` が意図せず低い値になっているか、プロンプトが num_ctx を超えてコンテキストが切り詰められているケースが多い。

対処手順:
・`"num_predict": -1` を明示的に指定してリトライする
・`journalctl -u ollama -f` でリアルタイムログを確認し、`context limit reached` 警告が出ていないか見る
・プロンプトのトークン数を文字数 × 1.5 で概算し、num_ctx を超えていないか確認する

# Ollamaのリアルタイムログを確認する(別ターミナルで実行) $ journalctl -u ollama -f # コンテキスト超過警告の出力例 # Jul 21 10:22:11 server ollama[1234]: WARN runner.go:890 context limit reached # Jul 21 10:22:11 server ollama[1234]: truncating to 2048 tokens

出力内容がブレる・毎回まったく違う結果になる

temperature が 0.8 以上に設定されているか、top_p が 1.0 に近い場合に起きやすい。
再現性が必要なバッチ処理では `"temperature": 0.0` を指定して greedy decoding に近づける。
それでもブレが続く場合は `seed` パラメータ(整数)を固定することで、同一入力に対して毎回同じ出力を得られる(一部モデルで有効)。

処理が急に遅くなった

num_ctx を大きく設定した直後にVRAMが不足し、CPUオフロードが発生しているサインだ。
`nvidia-smi` で GPU 使用率と `Memory-Usage` を確認し、以下のいずれかを試す:
・num_ctx を元の値に戻す
・モデルの量子化レベルを落とす(q8_0 → q4_0 など)
・同時リクエスト数を減らして VRAM の競合を解消する

パフォーマンス監視の詳細(GPU使用率・レスポンス時間のダッシュボード化)は、OllamaのUbuntu Serverへのインストールとサーバー構成でサーバー構成の基礎を確認したうえで、Prometheus+Grafanaの監視記事と合わせて参照するとよい。

まとめ:APIパラメータ制御でローカルLLMを業務に最適化する

パラメータ役割精度重視多様性重視
temperature出力のランダム性制御0.0 ~ 0.20.8 ~ 1.2
top_p候補トークンの絞り込み幅0.50.9 ~ 0.95
top_k上位k候補への絞り込み初期値(40)のまま初期値のまま
num_ctx参照できるトークン長2048(短文)8192 ~ 32768(長文)
num_predict最大出力トークン数64 ~ 512-1(無制限)

Ollamaのパラメータ制御で大切なのは、最初から完璧な設定を探そうとしないことだ。
まずデフォルト設定(temperature=0.8・num_ctx=2048)で動作確認し、「出力が毎回違いすぎる」「文書が途中で切れる」といった具体的な不満が出た段階で1つずつ変更する。
PythonのPRESETS辞書に用途別設定をまとめておくと、チームメンバーが設定値を覚えなくても用途名を指定するだけで最適なパラメータを使えるようになる。属人化を防ぐ意味でも、このひと手間は早めにやっておく価値がある。

ローカルLLMのパラメータ調整を実機で体験する

temperature・num_ctx・用途別プリセットの実装を自分の環境で確かめたい方向けに、「ローカルAIマスターセミナー」を開催しています。
実機GPU環境でAPIパラメータを手を動かしながら調整し、業務ユースケースへの適用まで体験できます。少人数(最大8名)ZOOMハンズオン形式で実施しています。

>> ローカルAIマスターセミナーの詳細を確認する
ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。