はじめに
番外編（0→100記事）で、「LLMはトークンを確率分布から引いている」という話をしました。今回はその続きで、分布の形自体を、どう歪めるかという一段深い話です。temperature（温度）というパラメータ、APIを触ったことがあれば必ず目にしますが、「0にすると賢くなる」「1にすると創造的になる」くらいの理解で止まっている人が多いと思います。
結論から言うと、この2つの通念は、両方ともかなり不正確でした。今回はそこを機構レベルで解きます。
1. 温度が何をしているか、機構
LLMが次の単語を選ぶとき、内部では各候補に対してLogits（生のスコア）という数値が計算されています。これがSoftmaxという関数を通って、合計が100%になる確率分布に変換される。ここまでは番外編の「分布から引く」の話そのままです。
温度は、Softmaxに入る前に、Logitsを割り算します。
調整後のLogits = 元のLogits ÷ 温度
割る数が小さいほど（低温）、差が誇張されて分布は尖ります。割る数が大きいほど（高温）、差が縮んで分布は平らになります。
具体例で見てみましょう。「犬」「猫」「鳥」の3つが次の候補で、元のLogitsが [4.0, 3.0, 1.0] だったとします。
| 温度 | p(犬) | p(猫) | p(鳥) |
|---|---|---|---|
| 0.5（低温） | 87.9% | 11.9% | 0.2% |
| 1.0（素の分布） | 70.5% | 26.0% | 3.5% |
| 2.0（高温） | 54.7% | 33.1% | 12.2% |
| 0（極限） | 100% | 0% | 0% |
同じ元スコアなのに、温度を変えるだけで確率の配分がまったく違って見えます。T=0は数式上「0で割る」という特異点になるので、実装上は「常に一番確率の高いトークンを選ぶ」（greedy）という特殊処理に置き換えられています。
人間で言うなら、ガチャの排出率調整が一番近いです。
- T=0：一番出やすいSSRを毎回確定で引く（排出率を無視した確定演出）
- T=1：素の排出率通りに引く
- T=2：排出率を無理やり均して、レア度に関係なくほぼ均等に引く
ここまでは、多くの人がなんとなく知っている話だと思います。ここから、2つの通念を崩していきます。
用語ミニ辞典
先に、この記事で出てくる言葉を整理しておきます。
| 用語 | 意味 |
|---|---|
| Logits | Softmaxに入る前の、各候補トークンの生のスコア。確率ではなくただの数値 |
| Softmax | 生のスコアを、合計が100%になる確率分布に変換する関数 |
| Temperature（温度） | Softmaxに入る前にLogitsを割る数。分布の尖り方を調整する |
| Greedy（貪欲法） | 常に一番確率の高いトークンだけを選ぶ方式。T=0の実装上の挙動 |
| サンプリング | 確率分布に従って、実際にどのトークンを選ぶか、くじ引き的に決める操作 |
| Top-k / Top-p | 温度とは別に、候補プールそのものを絞り込む手法（6章で扱います） |
なぜ、わざわざ確率で選ぶのか
そもそもの疑問として、「一番良さそうな答えを選べばいいのに、なぜ確率でくじ引きするのか」と思うかもしれません。
理由は、次に来る単語が、そもそも1つに決まらないからです。「今日の天気は」の後に続く単語は、「晴れ」かもしれないし「雨」かもしれないし「良い」かもしれない。どれも文法的にも意味的にもおかしくありません。
こういう「複数の妥当な続き方がある」状況で、モデルはそれぞれの妥当さを確率として持っているわけです。温度は、この確率の使い方——「一番妥当なものだけを機械的に採用するか」「妥当さに応じて、ある程度ランダムに選ぶか」——を調整するつまみです。
2. 通念①「温度を下げれば精度が上がる」は、ほぼ根拠がない
多くの人が「数学やコーディングのタスクは温度を下げるべき」と信じています。「一番確率の高い選択肢を選び続けた方が、正解に近づくはずだ」という直感です。
これを大規模に検証したのが Renze & Guven (2024)（EMNLP 2024 Findings）です。
9種類の主要なLLMに、5種類のプロンプト技法を組み合わせ、温度を0.0から1.6まで動かしながら、複数の問題領域にまたがる多肢選択問題を解かせました。
結果は、はっきりしています。
温度を0.0から1.0の範囲で変化させても、LLMの問題解決タスクの性能に統計的に有意な影響はなかった。しかもこの結果は、モデルの種類・プロンプト技法・問題領域を横断して一貫していた。
「数学は温度を下げるべき」という広く信じられた通念に、正面から反する結果です。
じゃあ、なぜAPIのデフォルトで温度0を勧める記事が多いのか。論文自身がその答えも出しています。
この結果を踏まえ、我々は問題解決タスクにおいてLLMのサンプリング温度を0.0に設定することを推奨する。この温度は、精度を犠牲にすることなく再現性を最大化する。
T=0を勧める理由は「精度が上がるから」ではなく、「精度を落とさずに再現性が最大化できるから」だったんです。 「賢さのつまみ」だと思っていたものが、実は「再現性のつまみ」でしかなかった。この違いは、実務でかなり効いてきます。「なぜT=0にしているんですか」と聞かれて「正解に近づくからです」と答えるのと、「毎回同じ挙動にしたいからです」と答えるのとでは、話の筋が変わります。
例外もあります
拡張思考（じっくり系）モデルでは、この結果がそのまま当てはまらないという報告もあります。Renze & Guvenの研究は拡張推論能力を持たない標準的なモデルを対象にしたもので、後続研究では拡張推論モデルにおいて温度の効果が再検討されています。解空間を探索する余地がある拡張思考モデルでは、ある程度の高温が探索の幅を広げて有効に働く場合がある、という報告です。ベースモデルと拡張思考モデルで話が変わる、というのは覚えておく価値があります。
3. じゃあ、なぜ「T=0=賢い」という直感が生まれたのか
ここで一度立ち止まります。なぜこんなに広く信じられた通念が、実は根拠薄弱だったのか。
直感としては筋が通って見えます。「T=0は、モデルが一番自信を持っている選択肢を常に選ぶ。だから一番正しいはずだ」。
でもこれは、1トークンの選択の話と、複数ステップにわたる推論全体の正しさの話を、混同しています。
数学の問題を解くには、複数のトークン（式変形の各ステップ）を積み重ねる必要があります。各ステップで「その時点で一番確率の高い1トークン」を貪欲に選び続けることは、全体として一番正しい解法にたどり着くことを保証しません。 これは探索理論ではよく知られた話で、各局面での最善手を積み重ねても、全体最適な道筋になるとは限らない。将棋で言えば、一手一手の最善手が、必ずしも詰みまでの最短ルートとは一致しないのと同じです。
つまり温度が影響するのは「その瞬間の1語の選び方」であって、「積み上げた末の解法全体の質」ではない。ここを混同すると、「T=0にすれば賢くなる」という誤解が生まれます。
4. 通念②の前に：「一番確率の高い語を常に選ぶ」は、実は下手
ここでもう1つ、根深い通念を崩します。「T=0（常に最尤トークンを選ぶ）は、少なくとも一番『自然』な文章になるはずだ」という直感です。
これも違いました。Holtzman et al. (2019)「The Curious Case of Neural Text Degeneration」という、この分野で非常に有名な論文があります。
尤度を最大化する訓練目的が、幅広い言語理解タスクにおいて高品質なモデルを生む一方で、貪欲法やビームサーチのような最大化ベースのデコード手法は、退化した出力——単調で、支離滅裂で、あるいは反復ループに陥る出力——を生む、という反直感的な経験則が確認されている。
常に一番確率の高い単語を選び続けると、文章は同じフレーズのループに陥る。
なぜか。理由は人間の書く文章の性質にあります。
自然な文章の1トークンあたりの確率は、平均するとビームサーチで生成された文章よりずっと低い。自然言語は、複数の連続したタイムステップにわたって高確率ゾーンに留まり続けることは稀で、代わりに、より情報量の多い低確率のトークンへと逸れていく。また自然言語は、モデルがそこに高い確率を割り当てる傾向があるにもかかわらず、反復ループに陥ることはほとんどない。
つまり人間の自然な文章は、常に一番「無難」な言葉を選んでいるわけではないんです。むしろ規則的に、意外性のある言葉を選んでいる。「賢い選択を毎回する」という戦略そのものが、不自然さの原因になる。
これが、**Top-p（nucleus sampling）**が生まれた理由です。分布の裾（低確率だが無意味な選択肢）を切り捨てつつ、頭（最尤トークンだけ）に固執しない、動的な範囲からサンプリングする手法です（詳しくは次章）。
ここまでの2つの通念を並べると、こうなります。
| 通念 | 実際 |
|---|---|
| T=0にすれば正答率が上がる | 精度への有意な効果はない。上がるのは再現性 |
| T=0にすれば一番自然な文章になる | むしろ反復ループに陥りやすい（退化） |
「T=0=賢い・自然」という直感は、精度についても自然さについても、根拠が薄いということです。
5. 「T=0にすれば毎回同じ答えが返る」も誤解だった
もう1つ、広く信じられている話があります。「温度を0にすれば、完全に決定的（毎回同じ出力）になるはずだ」というものです。
これも半分しか正しくありません。しかも通俗的な説明も、実は不正確でした。
よくある説明はこうです。「GPU上の並列計算では、浮動小数点演算の非結合性（計算順序によって結果がわずかに変わる性質）のせいで、毎回同じ答えにならない」。
2025年9月、Thinking Machines Lab（元OpenAI CTOのMira Muratiが設立）のHorace Heらが、この説明を検証しました。結論は——主因はそこではない、というものでした。
浮動小数点の非結合性と並行実行の組み合わせが、どの並行コアが先に処理を終えるかに応じて非決定性を生む、というのが一般的な仮説だ。しかし典型的なLLMのforward passには、通常atomic addは1つも存在しないため、これは問題の核心ではないことを説得力を持って示せる。
じゃあ本当の原因は何か。
ほぼ全てのLLM推論エンドポイントが非決定的になる主な理由は、負荷（つまりバッチサイズ）が非決定的に変動するからだ。
バッチサイズ依存です。サーバーは複数のリクエストをまとめて処理しますが、あなたのリクエストが、その瞬間に他の誰のリクエストと一緒にバッチ処理されるかは、毎回変わります。
本番のLLMサーバーは動的バッチ処理を使っていて、複数の無関係なリクエストが可変サイズのバッチにまとめられます。あなたの1つのプロンプトは、その瞬間に稼働している他のユーザーのリクエストと一緒にバッチ処理され、バッチサイズ・パディング・バッチ内での位置が予測不能に変化します。
バッチサイズが変わると、GPU内部でどの計算カーネル・どのリダクション（合計計算）の順序を使うかが変わります。浮動小数点の足し算は非結合的（足す順番で結果がわずかに変わる）なので、ここで極小の誤差が生まれる。そしてこの誤差が、層を伝播する過程で、貪欲法（greedy）における最大値の選択そのものをひっくり返してしまうことがあり、まったく異なる出力に繋がりえます。
人間で言えば、共同オーブンのクッキーです。 あなたのクッキー（リクエスト）の焼け方は、レシピ（プロンプトと温度設定）が同じでも、そのとき偶然一緒に焼かれている他の人のクッキー（同時に処理されている他のリクエスト）の数と種類によって、微妙に変わる。 混み具合は毎回違うので、結果も毎回わずかに違う。
実務上の含意
真に再現性が要る用途（監査ログ、テストスイート、規制対応）では、T=0だけでは足りません。 バッチサイズに依存しない専用の計算カーネル（batch-invariant kernels）や、固定バッチサイズでのサービングなど、インフラ側の設定まで踏み込む必要があります。実際、Thinking Machines Labはバッチサイズの変動が正規化・行列積・注意機構という3つの主要な演算で数値的な一貫性を崩すことを特定し、バッチ不変な実装を構築することで、1,000回の実行から1,000回とも同一の出力を得ることに成功したと報告しています。ただし、その代償として決定的な推論は通常より約60%遅くなるとのことです。通常のAPI利用者がここまで踏み込むことは稀で、**「T=0はかなり安定するが、ビット単位で同一とは限らない」**くらいの理解が現実的です。
6. Top-p / Top-kは、温度と別軸
温度は分布の「尖り方」を変えるだけで、候補プール自体は変えません。裾野の低確率トークンも、確率がゼロになるわけではなく、選ばれにくくなるだけです。
Top-k・Top-pは逆に、候補プールを切り詰める技術です。
Top-k：確率の高い順にk個だけ残して、それ以外を候補から除外する。
Top-p（nucleus sampling）：確率の高い順にトークンを足していき、累積確率が指定した割合pを超えるところで打ち切る。分布の中の信頼できるゾーン（nucleus）だけからサンプリングする、という発想です。
固定k個で切るTop-kには弱点があります。閾値をどこに置くかは、モデルの生成における「信頼できる予測範囲」をどう定義するかという話であり、固定値kは文脈によって最適ではないことが分かっています。分布が鋭く尖っているとき（候補がほぼ1つに絞られる場面）は、k個も残す必要がなく余計なノイズを拾ってしまう。逆に分布が平らなとき（本当に複数の妥当な候補がある場面）は、k個では足りず不自然に選択肢を狭めてしまう。
Top-pは、その場の分布の形に応じて、動的に打ち切り位置を変えることでこれを解決します。尖っているときは自動的に少数精鋭に、平らなときは自動的に広く取る。
| 手法 | 何を操作するか | 挙動 |
|---|---|---|
| 温度 | 分布全体の尖り方 | 候補は変えず、確率配分だけ歪める |
| Top-k | 候補の個数 | 固定k個で機械的に打ち切る |
| Top-p | 候補の累積確率 | 分布の形に応じて動的に打ち切る |
実務では、温度で分布の形を変えてから、Top-pで裾を切る、という2段構えが一般的です。温度を上げて多様性を出しつつ、Top-pで「明らかにおかしい」低確率トークンだけは排除する、という組み合わせです。
7. よくある疑問
ここまでの内容で湧きそうな疑問を、先回りして拾っておきます。
Q. じゃあ、コーディングタスクで温度を上げても問題ないんですか？
精度だけを見れば、理屈上は問題ないという結果になります。 ただし実務では話が別です。
コーディングタスクは、多くの場合「同じプロンプトに対して毎回同じコードが出てほしい」という再現性への要求が強い領域です。デバッグのしやすさ、レビューのしやすさ、CI/CDでの安定動作を考えると、精度が変わらないなら、再現性が高い低温を選ぶ理由の方が強い、というのが実務的な結論になります。「精度のために下げる」のではなく「安定性のために下げる」という理解の違いは、ここで効いてきます。
Q. デフォルトの温度（0.7や1.0）は、誰がどう決めているんですか？
はっきりした理由は公表されていません。Renze & Guvenの論文でも、OpenAIのGPT-3.5 APIは0.0〜1.0の範囲でデフォルト0.7、GPT-4は0.0〜2.0の範囲でデフォルト1.0だったが、これらのデフォルト値やモデル間での変更について、OpenAIから明確な説明は提供されていないと指摘されています。慣習的な値であって、根拠のある最適値とは限らない、というのが正直なところです。自分のタスクに最適な温度は、結局実測するしかありません。
Q. 温度を上げれば、AIは「創造的」になるんですか？
これも要注意です。温度を上げると出力の多様性は確かに増えますが、多様性と「意味のある新しさ・創造性」は別物です。ランダム性を強めているだけなので、支離滅裂になる方向にも多様化します。「創造的な文章が欲しいから温度を上げる」という発想自体は間違っていませんが、上げすぎれば単なる支離滅裂になるという上限があることは覚えておいた方がいいです。次章のTop-pは、この行き過ぎを抑えるための技術でもあります。
8. 実務指針
ここまでの内容を踏まえた指針です。
| 用途 | 温度 | 理由 |
|---|---|---|
| データ抽出・分類・コード生成 | 低め（0〜0.3） | 精度は上がらないが、再現性・デバッグのしやすさのため |
| 一般的な質問応答 | 中程度（0.5〜0.7、多くのAPIのデフォルト） | 自然さと安定性のバランス |
| ブレインストーミング・創作 | 高め（0.8〜1.2） | 多様性そのものが価値になる場面 |
| 監査ログ・規制対応で真の再現性が必要 | T=0 + インフラ側の対策 | T=0だけではビット単位の再現性は保証されない |
そして最後に1つ、次回以降への布石です。
自己整合性（self-consistency） という技法をご存知でしょうか。同じ問題を複数回解かせて、多数決で答えを決める手法です。これは実は、意図的に温度を上げて、多様な出力を複数取ることが前提になっています。もし温度を0にしたままだと、何回解かせても毎回同じ答えしか返ってこず、多数決の意味がなくなってしまう。
「精度を上げたいなら温度を下げる」ではなく、「精度を上げたいなら、むしろ温度を上げて複数回サンプリングし、それを多数決にかける」という、一見逆説的な戦略が存在するわけです。この技法は、この連載の候補トピックとしてまだ扱っていません。いずれ扱うことになると思います。
まとめ
機構の話
- 温度はSoftmaxに入る前にLogitsを割り算する。低いほど分布は尖り、高いほど平らになる。T=0は数式上の特異点で、実装上はgreedy（常に最尤トークンを選ぶ）に置き換えられる
通念①の崩れ方
- 「温度を下げれば精度が上がる」は、9モデル・5技法・複数領域を横断した検証で、統計的に有意な効果が確認できなかった
- T=0を推奨する本当の理由は「精度」ではなく「再現性」。この2つを混同すると、実務での説明が的外れになる
- 誤解が生まれた理由は、「1トークンの最善選択」と「複数ステップの推論全体の正しさ」の混同。各ステップの貪欲な最善手は、全体最適な解法を保証しない
通念②の崩れ方
- 「T=0が一番自然な文章になる」も誤り。常に最尤トークンを選び続けると、文章はむしろ反復ループに陥る（退化）。人間の自然な文章は、常に一番無難な語を選んでいるわけではない
- これがTop-p（nucleus sampling）が生まれた理由
もう1つの誤解
- 「T=0で完全に決定的になる」も不正確。通俗的な説明（浮動小数点の非結合性）は的を外していて、真の主因はバッチサイズ依存。同時に処理されている他人のリクエストの構成によって、内部の計算経路が変わり、僅差の判定を覆すことがある
- 真に再現性が必要な用途では、T=0だけでは足りず、インフラ側の対策が必要
別軸の話
- Top-k・Top-pは温度とは別軸で、候補プール自体を切り詰める技術。温度で形を変えてから、Top-pで裾を切る、という2段構えが実務のデフォルト
おわりに
CoT・Few-shot・ロールプロンプトと、ここまで扱ってきた技法はどれも「新しい能力を教えるのではなく、既存の振る舞いのどこを呼び出すかを選んでいるだけ」という結論に着地してきました。
温度は少し毛色が違います。**温度が変えているのは「何を呼び出すか」ではなく「呼び出し方そのもののブレ幅」**です。それでも今回見えてきたのは、同じ連載の教訓の変奏でした。「T=0にすれば賢くなる」という、もっともらしい直感は、精度の面でも自然さの面でも裏付けがなかった。もっともらしく見えることと、正しいことは別——このテーマは、パラメータの世界にも変わらず及んでいます。
次回のトピックはまだ確定していません。システムプロンプトとユーザープロンプトの重み、構造化出力・デリミタ、自己整合性——この3つが候補として残っています。
参考文献
- Renze, M., Guven, E. (2024). The Effect of Sampling Temperature on Problem Solving in Large Language Models. Findings of EMNLP 2024. arXiv:2402.05201
- Holtzman, A. et al. (2019/2020). The Curious Case of Neural Text Degeneration. ICLR 2020. arXiv:1904.09751
- He, H., Thinking Machines Lab (2025). Defeating Nondeterminism in LLM Inference. thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference