temperature を下げても答えは合いません ── LLM のつまみを読む

氷河期世代のクラウドエンジニア、terralien です。AIが書いたコードをレビューしていると、temperature=0.7 という行に一番よく出くわします。なぜ 0.7 なのかを聞いても、たぶん誰も答えられません。

そして厄介なことに、出力が間違っていたときの最初の一手も、だいたい「じゃあ temperature を下げよう」なんですよね。この記事は、それをやると何が起きるかを20回ずつ数えた記録です。

用途 ── つまみが決めるのは「品質」ではなく「ばらつき」

先に結論を出します。まったく同じ問いを、温度だけ変えて20回ずつ投げた結果です。問いは「税込合計はいくらか」で、正解は 14,168 円（1,280×7 ＋ 980×4 ＝ 12,880、×1.1）です。

温度をどう動かしても、正答は 0 のままです。動いたのは間違い方の散らばりだけでした。

temperature は正解率のつまみではありません。ここを取り違えたまま「0 にしたので大丈夫です」と書かれたコードは、監査を通してはいけません。

代表要素 ── 3つのつまみ

AIが書く例 ── 実際に書かせたもの

手元の Qwen3.8:27b に「議事録を要約する関数を書いてください」と頼んだら、これが返ってきました（一字も直していません）。

from openai import OpenAI

def summarize_minutes(text: str, model: str = "gpt-4o") -> str:
    client = OpenAI()
    response = client.chat.completions.create(
        model=model,
        messages=[
            {
                "role": "system",
                "content": "あなたは議事録の要約専門家です。提供された議事録テキストを簡潔かつ正確に要約してください。"
            },
            {
                "role": "user",
                "content": f"以下の議事録を要約してください：\n\n{text}"
            }
        ],
        temperature=0.3
    )
    return response.choices[0].message.content

つまみは temperature=0.3 の1つだけ。max_tokens は書かれていません。そして finish_reason を誰も見ていません。

max_tokens を書かないのは、一見すると「切り詰めないので安全」に見えます。実際は逆で、モデル側の既定上限に当たったときに、同じように黙って切れます。しかも上限が何トークンかはモデルを変えるたびに変わるので、切れる長さがコードのどこにも書いていない状態になります。長い議事録が来たら、この関数は途中で終わった要約を、成功として返します。

監査① ── temperature=0 は「正しい」ではなく「毎回同じ」

さっきの表の続きです。temperature=0 は再現性のためのつまみであって、正しさのつまみではありません。

では何が効いたのか。同じ問いに、思考（reasoning）を有効にして temperature=0 のまま投げ直しました。

温度は1ミリも動かしていません。動かしたのは途中計算をさせるかどうかでした。

つまり読むべき順序はこうです。出力が間違っているとき、まず疑うのは温度ではなく、タスクがそのモデルの1発では解けない形になっていないか。ここを飛ばして温度を下げると、間違いの再現性だけが上がります。

監査② ── top_p を一緒にいじると、temperature が消えます

これが2つめの罠です。AIが書いたコードには、両方が並んで置かれていることがよくあります。

top_p=0.1 を足した瞬間、temperature=1.5 の出力が temperature=0 とまったく同じものに戻りました。候補を上位1割に絞ってしまうと、そこにはもう最有力候補しか残っていないので、温度で分布を平らにしても選ばれるものが変わらないんです。

読むときのルールは単純です。

監査③ ── max_tokens は静かに切ります

3つめは、例外が飛ばないので気づけないやつです。同じ抽出タスクを JSON で返させ、max_tokens だけを変えて10回ずつ通しました。

max_tokens=16 のとき、API は HTTP 200 を返しています。例外は飛びません。response.choices[0].message.content にはちゃんと文字列が入っていて、それが { "date": "2026年8 なだけです。この文字列を json.loads() に渡した側が、遠く離れた場所で JSONDecodeError を出します。

だから読むところは1つです。

resp = client.chat.completions.create(..., max_tokens=1000)

# ★ここが無いコードは、切れた出力を正常系として下流に流す
if resp.choices[0].finish_reason == "length":
    raise ValueError("出力が max_tokens で打ち切られました")

return resp.choices[0].message.content

監査④ ── 思考する設定では、max_tokens は本文の前に消えます

最近のモデル特有の罠です。思考（reasoning）が有効なとき、max_tokens は思考ぶんも含めた上限として効きます。

max_tokens=200 のとき、200トークンぶんきっちり課金されて、返ってきた本文は空文字です。エラーではありません。「成功したリクエスト」として集計されます。

思考ありのモデルに切り替えたとたん出力が空になる、という報告が来たら、まずここを見ます。上限を上げれば直りますが、上げすぎても意味はありません。600 と 1500 で結果が同じなのは、必要なだけ使って止まっているからです。上限は蛇口の太さであって、水の量ではありません。

隣で読むもの

チートシート

読めるようになったか、ひとつだけ確認

Q. 抽出処理の答えが間違っています。temperature を 0.7 から 0 に下げるべきですか？

正解率は変わりません。実測では 0.7 でも 0 でも正答 0/20 で、下げたことで同じ誤答が20回そろって出るようになっただけでした。下げる価値があるのは「毎回結果が違って検証できない」という別の困りごとのほうです。答えを合わせにいくなら、つまみではなく手順を疑います。

……と書いておいてなんですが、こちらも去年まで、出力が安定しないと聞けば反射で温度を下げていました。「安定した」と報告して、実は同じ間違いが安定していただけ、という可能性を今になって思い出しています。当時の関係者の方、すみませんでした。