生成AIの設定画面やAPIには、temperature(Temperature)とtop_p(Top P)という項目があります。どちらも出力のばらつきに関係しますが、同じ計算をしているわけではありません。Temperatureは候補同士の確率差を調整し、Top Pは確率の合計を基準に候補の範囲を絞ります。
重要なのは、数値を上げれば文章力が上がり、下げれば正確になる、という単純な品質つまみではないことです。生成AIは設定値だけでなく、モデル、指示文、会話履歴、提供資料、サービス側の仕様にも影響されます。本記事では2つの役割を分けたうえで、用途ごとの出発点と、自分の仕事に合う値を比較する手順を説明します。
なお、対応する項目名、指定可能な範囲、初期値、Temperatureが0のときの挙動は、サービスやモデルによって異なります。ここで示す値は共通規格ではなく、比較実験を始めるための仮置きです。実際に使うサービスの公式仕様を先に確認してください。
1. 2つの設定が変えるもの
生成AIは文章を一度に完成させるのではなく、直前までの文脈をもとに、次に続くトークンの候補へ確率を割り当てながら出力します。トークンは、AIが文章を処理する単位です。基礎から確認したい場合は、トークンとコンテキストを図解も参照してください。
たとえば「空の色は」の次に、仮に「青い」「日による」「透明だ」などの候補が並んだとします。実際の候補はもっと多く、確率も文脈ごとに変わります。TemperatureとTop Pは、その候補から次のトークンを選ぶ「サンプリング」と呼ばれる段階に働きます。
| 設定 | 主に変えるもの | 値を下げたときの傾向 | 値を上げたときの傾向 |
|---|---|---|---|
| Temperature | 候補間の確率差 | 上位候補が選ばれやすくなる | 下位候補にも選択機会が広がる |
| Top P | 抽選に残す候補の集合 | 確率上位の狭い集合に絞る | より広い集合を残す |
Google Cloudの公式資料は、Top Pについて、確率の高いトークンから順に足し、累積確率が指定値へ達するまでの候補を使うと説明しています。Hugging Face Transformersの公式文書も、Top P未満の値では、合計確率が指定値以上になる最小の高確率候補集合を残すと説明しています。
この2つが調整するのは、主に「次の候補をどう選ぶか」です。回答が事実に合っているか、要求を満たしているかを直接保証する設定ではありません。低いTemperatureでも誤情報は出ますし、高いTemperatureでも正しい回答は出ます。事実確認は、AIのハルシネーションはなぜ起きるで扱うように、一次資料との照合を別工程にします。
2. Temperatureの仕組み
Temperatureは、各候補の確率分布を平らにしたり、尖らせたりする調整です。値を低くすると、もともと確率が高かった候補がさらに優位になり、同じ入力に対して似た言い回しが出やすくなります。値を高くすると候補間の差が縮まり、選ばれる表現の幅が広がりやすくなります。
仮に上位3候補の確率が大きく離れている場面では、Temperatureを下げると1位が強く残ります。反対に確率が近い場面では、わずかな変更でも選択結果が変わることがあります。このため、Temperatureの同じ数値を別モデルへ移しても、同じ文体や同じばらつきになるとは限りません。元になる確率分布がモデルと文脈ごとに違うからです。
低めの値は、要約、分類、情報抽出、コード修正など、評価基準が比較的はっきりした仕事の出発点に向きます。ただし、低くしすぎると、最初に選ばれやすい表現へ寄り、必要な代案が減る場合があります。高めの値は、見出し案、比喩、企画の切り口など、複数案を広く集めたい場面の候補になります。一方で、指示から外れた表現や一貫性の低下も検品対象になります。
「Temperature 0なら必ず同じ出力」とは扱わない方が安全です。Google Cloudの公式資料は、0では最も確率の高いトークンが選ばれ、回答はおおむね決定的になる一方、少量の変動は残り得ると説明しています。サービス側の処理、同率に近い候補、モデル更新などもあるため、0は「完全固定」ではなく「ばらつきを抑える設定」と考えます。
3. Top Pの仕組み
Top Pは「nucleus sampling(核サンプリング)」とも呼ばれる方式に使われます。固定個数の候補を残すのではなく、その場の確率分布に応じて候補数が変わる点が特徴です。
たとえば候補A、B、C、Dの確率が順に0.55、0.25、0.12、0.08だったと仮定します。Top Pが0.80なら、AとBを足した時点で累積確率が0.80へ達するため、主にその集合から次を選びます。別の場面で上位候補の確率が0.25、0.20、0.18、0.15のように分散していれば、同じTop Pでも残る候補数は増えます。数値例は仕組みを示すための仮定であり、特定モデルの実測値ではありません。
この動的な絞り込みにより、確率が集中している場面では少数の有力候補に寄せ、確率が分散した場面では複数候補を残せます。Top Pを下げるほど候補集合は狭くなり、定型的な出力へ寄りやすくなります。上げるほど低確率側まで候補に入りやすくなります。
nucleus samplingを提案した原論文は、確率分布の動的な「核」からサンプリングし、信頼性の低い確率分布の裾を切る方法として説明しています。ただし、論文上の改善結果を、現在のすべてのモデルや用途へそのまま当てはめることはできません。利用するモデルと評価データで確認が必要です。
注意したいのは、Top Pが「文章全体の上位何パーセントを使う」という設定ではないことです。次のトークンを選ぶ各段階で、候補確率の累積値に対して働きます。また、Top Pを0.9にしたからといって、回答の信頼度が90%になるわけでもありません。品質評価や事実の確度とは別の数値です。
4. TemperatureとTop Pを同時に変えない理由
両方を狭めると、Temperatureで上位候補を強めながら、Top Pでも候補集合を削ることになります。結果が悪くなったとき、どちらが原因なのかを切り分けにくくなります。逆に両方を広げれば、表現が変わった理由を特定しにくいまま、ばらつきだけが増える場合があります。
Google CloudのAPIリファレンスは、TemperatureかTop Pのどちらか一方を調整し、両方を同時に変えないことを推奨しています。OpenAIのAPIリファレンスもTop PをTemperatureの代替となるnucleus samplingの設定として説明しています。したがって、最初の比較では次のどちらかに固定します。
- Temperatureを試すときは、Top Pをサービスの初期値に固定する
- Top Pを試すときは、Temperatureをサービスの初期値に固定する
これは「両方を指定してはいけない」という禁止ではありません。採用するサービスが両方を受け付け、検証で効果が確認できるなら併用は可能です。ただし、最初から2軸を同時に動かすと組み合わせが増え、評価の説明が難しくなります。まず1軸ずつ効果を測り、併用が必要な理由を確認してから進める方が管理しやすくなります。
チャット画面では、これらの設定が表示されず、サービス側で管理されることもあります。その場合は、無理に数値を探すより、目的、禁止事項、出力形式、根拠資料を指示文で固定します。依頼文の作り方はAIへの指示書の作り方で整理しています。
5. 文章・要約・コード別の目安
次の表は、特定サービスの推奨値ではなく、比較を始めるための編集上の仮説です。利用中のモデルが受け付ける範囲を確認し、まずTemperatureだけを変える想定です。Top Pを試す場合はTemperatureを初期値へ戻し、同じ考え方で狭い側から段階的に比較します。
| 用途 | Temperatureの開始候補 | 見るポイント |
|---|---|---|
| 資料からの要約・項目抽出 | 0〜0.3 | 原文にない補足、数字、固有名詞、抜け漏れ |
| 既存コードの修正・変換 | 0〜0.3 | テスト合格、仕様順守、不要な変更 |
| 説明文・メールの下書き | 0.3〜0.7 | 読みやすさ、条件の保持、語調 |
| 見出し・企画案の発散 | 0.7〜1.0 | 案の重複、具体性、目的との距離 |
範囲は目安であり、値を受け付けないモデルや、設定を制限するサービスもあります。特に推論に特化したモデルでは、TemperatureやTop Pが利用できない場合があります。エラーになったときは値を無理に変換せず、そのモデルの公式仕様へ戻ります。
要約では、低い値にするだけで正確性が確定するわけではありません。原文だけを根拠にすること、対象範囲、残す項目、引用方法、分からない場合の表記を指示し、最後に原文と照合します。Temperatureを上げて表現を滑らかにするときも、数字や固有名詞が変わっていないかを確認します。
コードでは、見た目の違いより機械検証を優先します。同じテスト、静的解析、入力例を全候補に適用し、合格数と不要な差分を比べます。低い値でも、存在しない関数や古いAPIを使う可能性はあります。設定値を「正しさ」の代わりにせず、テストを合否判定に使います。
文章の発想では、1回の出力を極端にランダムにするより、少し高めの設定で複数候補を作り、人が選ぶ方法もあります。候補数を増やせば処理時間やAPI利用量も増えるため、料金が発生する環境では実行前に公式料金と上限を確認してください。本記事では料金を扱いません。
6. 再現性を高める設定
出力を比較したり、不具合を再現したりするには、Temperatureだけでなく実行条件全体を記録します。最低限、次の項目を一組として保存します。
- サービス名、モデル名、可能なら固定されたモデル版
- 実行日
- システム指示、ユーザー指示、会話履歴
- 入力資料と、その版またはハッシュ値
- Temperature、Top P、最大出力トークンなどの生成設定
- seed(乱数の初期値)に対応している場合はその値
- ツール利用、検索、構造化出力などの有無
- 実際の出力と評価結果
seedを固定できるサービスでは、比較時のばらつきを抑えやすくなります。ただし、seedも完全一致の保証ではありません。Google Cloudの公式資料は、seedを指定すると同じ応答を出すよう最大限試みる一方、決定的な出力は保証されず、モデルや設定を変えると結果も変わり得ると説明しています。
また、同じ表示名のモデルでも提供側の更新が影響する可能性があります。再現性が重要な処理では、利用可能なら固定版を選び、変更履歴を確認します。検索結果や外部ツールを使う処理は、取得内容そのものが変わるため、参照資料も保存しなければ比較条件が揃いません。
再現性は「毎回同じ文章を出すこと」だけではありません。入力が少し変わっても要件を守れるか、重要な事実を落とさないかという安定性も必要です。固定した代表例だけでなく、短文、長文、例外、曖昧な入力を含む評価セットを用意します。
7. 設定値を比較する実験手順
設定を感覚で決めず、小さな比較実験として記録すると、別の担当者やモデルへ引き継ぎやすくなります。
-
仕事と合格条件を1つに絞る
「良い文章」ではなく、「800字以内で、資料中の5項目をすべて含み、資料外の数字を足さない」のように判定可能な条件へ分けます。 -
代表的な入力を複数用意する
1例だけでは偶然の出力に左右されます。通常例、長い例、条件が曖昧な例、失敗しやすい例を含めます。個人情報や秘密情報はテストデータへ入れません。 -
基準値を固定して実行する
モデル、指示文、入力、最大出力長、Top Pなどを固定し、Temperatureの基準値で結果を保存します。同じ条件で複数回実行し、出力のばらつきも見ます。 -
1項目だけ段階的に変える
たとえばTemperatureを0、0.3、0.7のように比較します。これは実験例であり、推奨値の断定ではありません。Top Pを比べる回ではTemperatureを初期値へ戻します。 -
名前を隠して同じ基準で採点する
どの設定かを見ず、事実一致、要件充足、読みやすさ、重複、修正時間を採点します。文章なら人の評価、コードならテスト結果を中心にします。 -
平均だけでなく失敗例を見る
平均点が高くても、重要な数字を作る、JSONを壊す、安全条件を落とす出力があるなら採用を再検討します。高リスク用途では最悪例と失敗率を重視します。 -
採用値と再評価条件を記録する
「要約テスト20件で最少修正だったため採用」のように根拠を残します。モデル、指示文、入力形式を変えたときは、以前の最適値をそのまま流用せず再評価します。
8. FAQ
TemperatureとTop Pはどちらを先に調整すればよいですか
まず、利用サービスの初期値で基準結果を保存します。そのうえで、表現のばらつきを直接比べたいならTemperature、候補集合の広さを比べたいならTop Pを1つだけ動かします。迷う場合はTemperatureから始め、Top Pは初期値に固定すると比較しやすくなります。
Temperatureを0にすれば、毎回まったく同じ回答になりますか
完全一致は保証されません。出力のばらつきは抑えやすくなりますが、モデル更新、サービス側の処理、検索やツールの結果などで変わる可能性があります。再現性が必要なら、モデル版、入力、設定、seed、参照資料も一緒に記録します。
Top Pを0.9にすると、回答の正確性が90%になりますか
なりません。0.9は、次のトークン候補を累積確率で絞るためのしきい値です。回答全体の信頼度や事実の正確性を示す数値ではないため、重要な事実は一次資料と照合します。
Temperatureを上げると、ハルシネーションは増えますか
指示から外れた候補が選ばれる可能性は広がりますが、Temperatureだけでハルシネーションの有無は決まりません。低い値でも誤りは起こります。根拠資料の指定、回答範囲の制限、出力後の検証を組み合わせます。
毎回同じJSON形式で出したい場合は、設定値を下げれば十分ですか
十分ではありません。低いTemperatureはばらつきを抑える一手段ですが、形式の保証とは別です。対応サービスではJSON Schemaなどの構造化出力を使い、受信後も検証します。詳しくはAIの構造化JSON出力ガイドを参照してください。
9. まとめ
結論として、Temperatureは確率の山の形を調整し、Top Pは抽選に残す候補の範囲を調整します。どちらも出力の多様性に影響しますが、正確性や品質を単独で保証しません。まず初期値を確認し、片方だけを動かし、用途ごとの合格条件で比べることが実用的です。
一次情報メモ(確認日: 2026-07-24)
- OpenAI「API Reference: Graders」: Temperatureは値が高いほど出力のランダム性が増し、Top Pはnucleus samplingでTemperatureの代替となり、1.0では全トークンを含むという説明。https://platform.openai.com/docs/api-reference/graders
- Google Cloud「Content generation parameters」: Top Pによる候補選択、Temperature 0でも少量の変動が残り得ること、seed固定は決定的出力を保証しないことの説明。https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/content-generation-parameters
- Google Cloud「Package google.cloud.aiplatform.v1」: GenerationConfigにおけるTemperatureとTop Pの役割、両方ではなくどちらか一方の調整を推奨する記述。https://docs.cloud.google.com/vertex-ai/generative-ai/docs/reference/rpc/google.cloud.aiplatform.v1
- Hugging Face Transformers「Generation」: Temperatureによる確率調整と、Top Pで累積確率を満たす最小の高確率候補集合を残す仕様。https://huggingface.co/docs/transformers/main_classes/text_generation
- OpenAI「Responses API Reference」: TemperatureとTop Pの指定範囲、Top Pが確率質量に基づくnucleus samplingであること、両方ではなく片方の変更を推奨する説明。https://platform.openai.com/docs/api-reference/responses
- Holtzmanほか「The Curious Case of Neural Text Degeneration」: 確率分布の動的な核から選ぶnucleus samplingを提案した原論文。https://arxiv.org/abs/1904.09751