推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応を実装目線で解説【2026年版】

推論パラメータとは、学習済みモデルが次のトークンを選ぶときの確率分布の扱い方を指定する設定値のことです。temperatureやtop_pを変えても重みそのものは書き換わらず、変わるのは「候補をどこまで許すか」という選び方だけになります。本記事では、各パラメータが確率分布に対して何をしているのかを整理したうえで、OpenAI・Anthropic・vLLMで実際に指定できる範囲と既定値の違い、用途別の初期値と調整の手順を実装者の視点でまとめました。あわせて、2026年時点の推論モデルでサンプリング指定そのものが受け付けられなくなっている変化と、その移行判断も扱います。

まとめ：推論パラメータの設定基準と推論モデル移行の結論

推論パラメータは大きく2種類に分かれます。分布の形を変えるtemperatureと、候補集合を切り詰めるtop_p・top_k・min_pです。前者が「どれだけ低確率のトークンを許すか」を連続的に決め、後者が「そもそも候補に残すのはどこまでか」を決める、という役割分担で理解すると設定を誤りにくくなります。

実務の初期値は、抽出・分類・RAG回答ならtemperatureを0近辺、文章生成やアイデア出しなら0.7前後から始めるのが定石です。動かすのは一度に1つだけにしてください。temperatureとtop_pを同時に触ると、出力の変化がどちらに由来するのか切り分けられなくなります。

そして2026年に入り、前提が一段変わりました。推論（reasoning）系のモデルではtemperatureやtop_pの指定が受け付けられず、代わりに思考量を指定するeffort系のパラメータが制御軸になっています。既存のコードが送っている設定値がそのまま400エラーになる構成もあるため、モデル更新の前にリクエスト生成箇所の入念な事前点検が不可欠です。判断の分かれ目は後半の章で条件付きで言い切ります。

推論パラメータの定義と、確率分布から出力トークンを絞り込む2段階

推論そのものの流れ（PrefillとDecodeの2フェーズ、KVキャッシュ、推論基盤の選定）はLLM推論の仕組みと推論基盤の選び方で扱っています。本記事はそのDecodeフェーズの内側、つまり「次の1トークンをどう選ぶか」に絞って掘り下げます。

学習との違い：重みを変えずに出力トークンの選び方だけを変える制御

モデルは各ステップで、語彙全体に対するスコア（ロジット）を出力します。このスコアをsoftmaxで確率に変換し、そこから1つを選ぶ処理が推論パラメータの適用範囲です。ファインチューニングが重みを書き換えるのに対し、推論パラメータは重みを一切触りません。

この違いは運用コストに直結します。パラメータ調整はリクエスト単位で即時に反映でき、切り戻しも設定値を戻すだけで済みます。逆に言えば、知識不足や指示理解の失敗はパラメータでは直りません。temperatureを下げても、モデルが知らない事実は出てこないためです。

temperatureの役割：確率分布の尖り具合を決める指数スケーリング

softmaxを適用する前に、各ロジットをtemperatureで割ります。値が1より小さいとロジットの差が拡大し、確率分布は最上位トークンに集中します。1より大きいと差が縮まり、下位のトークンにも確率が回る形です。

vLLMのSamplingParamsでは、temperatureが1e-5を下回るとgreedy decoding（毎回スコア最大のトークンを選ぶ方式）に切り替わり、同時にtop_pが1.0、top_kが0、min_pが0.0へ強制されます。さらにnが2以上だとエラーになります。0を指定したつもりでも他の絞り込み設定が黙って無効化される挙動なので、自前の推論基盤を運用するなら把握しておきたい仕様です（2026年8月時点）。

高い値の副作用も具体的です。分布の裾に確率が回るほど、文脈的に支持されないトークンが選ばれる余地が広がります。事実関係が崩れる誤答の背景についてはハルシネーションの原因と種類で整理しました。

top_pとtop_kの違い：累積確率で絞るか候補の個数で絞るか

両者はどちらも候補集合を切り詰めますが、基準が異なります。top_p（nucleus sampling）は確率の高い順に足していき、累積が閾値pに達するまでを候補に残す方式です。top_kは確率の順位で上位k個だけを残します。

差が出るのは分布の形が偏ったときです。1つのトークンが確率0.9を占める場面でtop_pを0.9にすると候補はほぼ1つに収束しますが、top_kを40にすると確率0.001未満のトークンまで候補に残ります。分布の状況に応じて候補数が伸縮するtop_pのほうが、実務では扱いやすい設計です。

vLLMにはもう1つmin_pがあります。最上位トークンの確率に対する相対的な下限を指定する方式で、既定値は0.0、範囲は0から1です。絶対値ではなく相対値で切るため、分布が平坦な場面でも候補が過剰に広がりにくくなります。

主要APIで指定できる推論パラメータの範囲・既定値と上限の違い

同じ名前のパラメータでも、取りうる範囲と既定値はベンダーごとに異なります。移植のときにここを見落とすと、意図せず出力の性質が変わります。

OpenAI・Anthropic・vLLMで異なるtemperatureの範囲と既定値

代表的な3つの実行環境を並べると、差がはっきりします。以下は2026年8月時点の公開ドキュメントで確認できる範囲です。

注意したいのは上限の違いです。OpenAI系の感覚で「1.2くらいで多様性を出す」という設定をAnthropicのMessages APIにそのまま持ち込むと、上限1.0を超えて弾かれます。逆にAnthropicの0.7とOpenAIの0.7は分布上の位置づけが同じではありません。上限が2の環境での0.7は中央より下、上限が1.0の環境での0.7はかなり上寄りという扱いになるためです。移植時は絶対値ではなく、上限に対する相対位置で読み替えてください。

max_tokensの意味：思考トークンが出力枠を食い潰す構造

max_tokensは生成の打ち切り上限であり、出力の長さを保証する値ではありません。vLLMのSamplingParamsでは既定値がわずか16トークンで、指定を忘れると応答が途中で切れます。

推論モデルではこの枠の意味がさらに変わります。OpenAIのChat Completions APIでは推論モデル向けにmax_completion_tokensが用意されており、内部の思考トークンもこの枠を消費する構造です。思考が長引くと、可視の応答が出る前に上限へ到達して空の応答が返ることもあります。実装側では上限を厚めに取り、打ち切り理由を必ずログに残す設計が要ります。

入力側の上限とは別枠である点も混同しやすい部分です。入出力を合わせた総量の数え方はコンテキストウィンドウのトークン上限と溢れ対策で扱っています。

反復ペナルティとseedの役割：繰り返しの抑制と再現性の限界

同じ語句のループを抑える設定も推論パラメータの一部です。vLLMではrepetition_penaltyの既定値が1.0、presence_penaltyとfrequency_penaltyの既定値が0.0で、前者は出現の有無、後者は出現回数に応じてスコアを補正します。OpenAIのChat Completionsでは後者2つが同名で提供され、いずれも0が既定値です。

ペナルティは強くしすぎると副作用が出ます。専門用語や固有名詞は本来なら何度も出るべき語なので、値を上げると言い換えが増え、かえって文意がぶれます。まずはtemperature側で調整し、それでもループが消えない場合に0.1刻みで足す順序が扱いやすいでしょう。

seedは擬似乱数の初期値を固定する設定で、vLLMの既定値はNoneです。ただし同じseedでも、バッチ構成やハードウェア、モデルのバージョンが変われば出力は一致しません。再現性が本当に必要な評価環境では、seedに頼らずtemperatureを0にしてgreedyへ落とすほうが確実です。

用途別の初期値と、動かすパラメータを1つに絞る調整手順の組み立て

値の意味が分かっても、最初にどこへ置くかが決まらなければ調整は進みません。処理の性質から初期値を決め、そこから1軸ずつ動かすのが実務の手順です。

抽出・分類・RAG回答など再現性を優先する処理の初期値の決め方

構造化データの抽出、ラベル分類、検索結果に基づく回答生成は、同じ入力に同じ出力が返ることに価値があります。この系統はtemperatureを0から0.2、top_pは既定の1.0のままにしてください。候補を絞るのはtemperature側だけにして、変数を増やさないほうが原因追跡が楽になります。

JSON出力のように形式の厳密さを求める処理では、パラメータより先にスキーマ制約やツール定義の側で縛るほうが効きます。temperatureを0にしても、括弧の閉じ忘れが構造的に防げるわけではないためです。

文章生成とアイデア出しで多様性を広げるときの初期値と上限の目安

記事のドラフト、コピー案、ブレインストーミングでは、同じ出力が返ることに価値がありません。上限2の環境なら0.7前後、上限1.0の環境なら0.8前後を出発点にします。ここから0.1刻みで上げ、破綻が出る手前で止めるのが実務的な進め方です。

上げすぎの兆候ははっきり出ます。文の途中で主語が入れ替わる、存在しない固有名詞が混じる、語尾が不自然に崩れる、といった症状が見えたら1段戻してください。多様性はtemperatureだけでなく、プロンプト側で観点を複数指定する形でも作れます。

temperatureとtop_pを同時に動かさない理由と切り分けの手順

両者はどちらも「低確率トークンをどこまで許すか」に作用するため、同時に動かすと寄与を分離できません。OpenAIの公開ドキュメントでも、両方を変更するのではなくどちらか一方で制御する運用が案内されています。調整は次の順序で回してください。

1. 評価用の入力を10件から20件、代表的なものを固定して用意する
2. 既定値のまま実行し、出力を基準として保存する
3. temperatureだけを0.1刻みで動かし、破綻が出る境界を記録する
4. それでも候補が広すぎる場合に限り、top_pを0.95から下げる
5. ループが残る場合にのみ、反復ペナルティを0.1刻みで足す

この順序なら、どの設定がどの症状に効いたかが1対1で残ります。設定を2つ同時に変えた記録は、後から読み返しても再現の手がかりになりません。

推論モデルではサンプリング指定が消える変化と移行判断の分かれ目

ここまでの前提が通用しない領域が広がっています。思考過程を内部で生成してから回答する推論モデルでは、サンプリング系のパラメータが指定できません。この章では判断を言い切ります。

推論モデルがtemperatureを受け付けない理由と400エラー

OpenAIの推論モデル向けガイドでは、temperature・top_p・presence_penalty・frequency_penalty・logprobs・logit_bias・max_tokensが非対応として明示されています。temperatureは既定値の1以外を受け付けません。Anthropic側も同じ方向で、Claudeの上位世代ではtemperature・top_p・top_kが廃止され、送信すると400が返る仕様になりました（いずれも2026年8月時点）。

背景は単純です。推論モデルは内部の思考過程が回答品質を決めており、その途中のサンプリング挙動を外から動かされると、学習時に想定した推論の安定性が崩れます。ベンダー側が制御の主導権を握り、利用者にはより粗い粒度の軸だけを開放する設計へ寄せた、と読むのが実態に近いでしょう。

実装への影響は見た目より大きくなります。共通のリクエストビルダーで全モデルに同じ設定値を積んでいる構成では、モデルIDを差し替えた瞬間に全リクエストが400で落ちます。移行前に、パラメータを組み立てている箇所を洗い出し、モデル世代ごとに送信するキーを分岐させておいてください。

reasoning effortという新しい制御軸への置き換えの考え方

置き換え先は思考量の指定です。OpenAIではreasoningのeffort、Anthropicではoutput_configのeffortで、low・medium・high といった段階を指定します。上位の段階ほど思考トークンを多く使い、精度と引き換えに待ち時間とコストが増える構造です。

ここで注意したいのは、effortがtemperatureの代替ではないという点です。temperatureが出力の揺らぎを決めていたのに対し、effortは考える深さを決めます。「出力を短くしたいからeffortを下げる」という置き換えは狙いどおりに働きません。出力の長さや文体は、プロンプト側の指示で制御するのが筋です。推論モデル向けの指示の書き分けは推論モデルでのプロンプトの使い分けが参考になります。

モデル世代をまたぐ構成を1つのコードベースで抱える場合、設定値を「サンプリング指定を受け付ける世代」と「effort系のみの世代」に分け、後者では前者のキーを送らないようにしてください。自社のワークロードでどちらに寄せるか判断がつかない、あるいは既存の推論処理を新世代へ移す設計を相談したい場合は、生成AI導入支援で移行方針の整理から対応しています。

採用を見送る場面：パラメータ調整では直せない3つの失敗パターン

推論パラメータの調整に時間を注ぐべきでない場面があります。次の症状が出ているなら、値をいじる前に別の層を直してください。

• 固有名詞や数値が誤る：知識の不足であり、検索や参照文書の追加で解く
• 指示の一部が無視される：プロンプトの構造の問題で、指示の分割や順序変更で解く
• 出力形式が崩れる：スキーマ制約やツール定義で縛るほうが確実に効く

とくに1つ目は誤りやすい判断です。temperatureを0にすると出力が安定するため、一見すると誤答が減ったように見えます。実際には「同じ誤答を毎回返す」状態になっただけで、正答率は上がりません。ここでパラメータ調整を続けるのは時間の浪費です。

逆に、パラメータ調整が効くのは「同じ入力で出力が揺れすぎる」「同じ言い回しが繰り返される」「文章が単調すぎる」の3系統に限られます。この範囲を外れた症状は、プロンプト設計か参照データの側で解決してください。

パラメータ設定を本番運用に載せるログ設計と回帰テストの組み方

値が決まったあとに事故が起きるのは、設定がコードに散り、変更の履歴が追えなくなったときです。運用に載せる段階では、設定の置き場所と検証の仕組みをセットで用意します。

推論パラメータをコードに直書きしない構成管理と切り替えの組み方

推論パラメータは、処理の種類ごとに設定ファイルや環境変数へ切り出してください。抽出処理と生成処理で別の値を使うなら、その2つを名前付きのプリセットとして定義し、呼び出し側はプリセット名だけを指定する形にします。呼び出し箇所ごとにリテラルを書いていると、モデル世代の移行時に修正漏れが必ず出ます。

ログには、リクエストごとに使ったプリセット名・モデルID・実際に送信した設定値・打ち切り理由を残してください。障害調査で最初に見たいのは「そのとき何を送ったか」です。設定値をログに残していない構成では、再現も切り分けもできません。

出力の揺らぎを検知する回帰テストと評価データセットの用意の仕方

推論パラメータの変更は、単体テストでは壊れたことが分かりません。代表的な入力を20件から50件ほど固定した評価データセットを用意し、期待する性質（JSONとして解釈できる、指定ラベルのいずれかを返す、禁止語を含まない）を機械的に判定する形にしてください。

判定の基準は正解文字列との完全一致ではなく、性質のチェックです。生成系の処理では文面が毎回変わるため、完全一致テストはすぐに保守できなくなります。temperatureを上げたときに失敗率がどこから跳ね上がるかを記録しておけば、モデル更新のたびに同じ手順で境界を測り直せます。

よくある質問

推論パラメータの設定でつまずきやすい論点を、実装時の判断とあわせて整理しました。

temperatureを0にすれば毎回まったく同じ出力になりますか？

同一の実行環境なら、ほぼ同じ出力に収束します。ただし完全な一致は保証されません。並列実行時のバッチ構成、GPUでの浮動小数点演算の順序、モデルのバージョン更新のいずれかが変われば、結果がずれる場合があります。評価環境で厳密な再現が必要なら、モデルのバージョンを固定し、バッチサイズを揃えたうえでtemperatureを0にする、という条件をそろえてください。

temperatureとtop_pはどちらを先に調整すべきですか？

temperatureを先に調整してください。分布全体の形を決める設定なので、効果の見通しが立てやすくなります。top_pは候補集合の切り方を変える設定で、temperatureだけでは候補が広すぎると分かった場合の第2手として使います。両方を同時に動かすと、どちらが効いたか分からなくなるため避けてください。

推論モデルではtemperatureが使えないと聞きましたが本当ですか？

2026年8月時点の主要ベンダーでは、その通りです。OpenAIの推論モデルはtemperatureに既定値以外を受け付けず、Claudeの上位世代ではtemperature・top_p・top_kが廃止され、送信すると400エラーが返ります。代わりに思考量を指定するeffort系のパラメータが制御軸です。既存コードが全モデルへ同じ設定値を送っている場合、移行時に分岐を入れる必要があります。

max_tokensを大きくすれば出力は長くなりますか？

長くなるとは限りません。max_tokensは打ち切りの上限であり、生成量の指示ではないためです。出力の長さは、プロンプトで文字数や構成を指定して制御します。逆に上限が小さすぎると途中で切れるので、想定する最長出力より余裕のある値を設定してください。推論モデルでは内部の思考トークンも同じ枠を消費するため、通常のモデルより厚めの上限が要ります。

ローカルLLMでも同じパラメータの考え方が使えますか？

基本的な考え方は共通です。vLLMのSamplingParamsでもtemperature・top_p・top_k・min_p・repetition_penaltyが提供され、役割はクラウドAPIと同じになります。違いは既定値と細かい挙動です。max_tokensの既定値が16と小さい、temperatureが1e-5未満でgreedyへ切り替わり他の絞り込み設定が無効化される、といった仕様は実際のドキュメントで確認してから運用に載せてください。

関連記事

• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説：本記事で挙げたSamplingParamsを実際に指定する推論エンジンの導入手順を扱っています
• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】：パラメータ調整では変わらない、推論速度そのものを左右する仕組みを解説しています
• AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順：temperatureを下げても直らない誤答へ、別の層で対処する方法をまとめました
• LLMとは？大規模言語モデルの仕組み・生成AIとの違いと企業導入の判断基準を解説：推論パラメータの前提となる大規模言語モデルの全体像を扱っています