温度（temperature）¶

このダイヤルは何か¶

温度（temperature）は、LLM が次のトークンを選ぶ際の確率分布をどれだけ「尖らせる」か「平らにする」かを制御するパラメータです。温度 0 に近いほど最も確率の高いトークンが選ばれやすくなり、出力は決定論的で安定します。温度を上げると確率分布が平坦化し、低確率のトークンも選ばれるようになるため、出力の多様性と創造性が増します。

AI エージェントシステムにおいて温度は単なる「創造性の調整つまみ」ではありません。エージェントが構造化出力を生成する場面、ツール呼び出しの引数を組み立てる場面、自由形式のテキストを生成する場面のそれぞれで、求められる温度は異なります。温度の設定を誤ると、構造化出力のスキーマ違反率が跳ね上がったり、逆に対話がロボット的で不自然になったりします。

重要なのは、温度は単一の固定値ではなく、タスクの種別と [task_variability] に応じて動的に切り替えるべき変数だということです。1 つのエージェントの中でも、計画フェーズ・実行フェーズ・応答生成フェーズで異なる温度を使い分けることが実践的です。

効かなすぎる害 ⇔ 効きすぎる害¶

温度が低すぎる場合（効かなすぎ）¶

温度を 0 付近に固定すると、出力は安定しますが以下の害が生じます。

対話の硬直化：ユーザーとの会話が機械的で紋切り型になります。同じ質問には毎回まったく同じ回答を返すため、人間側に「テンプレート応答」の印象を与えます。カスタマーサポートや対話エージェントでは、この不自然さがユーザー体験を損ないます。
Best-of-N サンプリングが無意味化：B6 Critic/Judge & Sampling-Aggregation では複数候補を生成して最良を選びますが、温度が低すぎると候補がほぼ同一になり、多様性に基づく品質向上効果が失われます。N 倍のコストだけかかって実質 N=1 と同じ結果になります。
局所最適への固着：推論や計画タスクで、最初に浮かんだアプローチだけを繰り返し選択し、代替案を探索できません。エージェントの自己修正ループでも、同じ誤りパターンに嵌り続けることがあります。

温度が高すぎる場合（効きすぎ）¶

温度を 0.8 以上に上げすぎると、以下の問題が顕在化します。

構造化出力の破壊：JSON Schema に準拠すべき出力でフィールド名が揺れたり、型が合わなくなったりします。E4 Verified Structured Output の自己修正リトライが頻発し、レイテンシとコストが膨張します。
ハルシネーションの増加：低確率トークンが選ばれやすくなるため、事実に基づかない記述が混入する確率が上がります。とくに固有名詞・数値・日付などの正確性が要求される領域で危険です。
ツール呼び出しの不安定化：関数名や引数の生成が不安定になり、存在しないツールを呼び出そうとしたり、引数の型を間違えたりする頻度が上がります。
再現性の喪失：同一入力に対する出力のばらつきが大きくなるため、テストやデバッグが困難になります。障害発生時の再現が難しくなり、観測コストが増加します。

決め方¶

温度の設定は主に [task_variability] によって決まります。タスクが定型的で正確な出力が求められるほど低温に、創造性や多様性が求められるほど高温に設定します。

加えて、以下の駆動変数が温度の上限を制約します。

[failure_cost]：失敗コストが高いほど、温度の上限を下げて安定性を優先します。医療・法務・金融のように誤りが重大な結果を招く領域では、対話であっても温度を抑えます。
[cost_sensitivity]：温度が高いと自己修正リトライの発生率が上がり、トークン消費が増えます。コスト感度が高い環境では、リトライによるコスト増を見込んで温度を下げるか、構造化出力のパスだけ低温にします。
[request_value]：1 リクエストの価値が高い場合、Best-of-N サンプリングを併用するために中程度の温度が必要になることがあります。ただし N=1 の場合は温度を下げた方が安全です。

実践的な判定フローは次のとおりです。

出力は構造化（JSON/関数呼び出し）か → はい → 0.0〜0.3
正確性が最優先（事実抽出・分類・要約）か → はい → 0.2〜0.5
対話・説明・コミュニケーションか → はい → 0.5〜0.7
創作・ブレインストーミング・多様な候補生成か → はい → 0.7〜1.0

目安値（出発点）¶

以下はあくまで出発点です。本番環境のメトリクス（スキーマ違反率、リトライ率、ユーザー満足度）をもとに調整してください。

タスク種別	温度の目安	根拠
構造化出力（JSON / function calling）	0.0〜0.3	スキーマ違反を最小化するため。多くの API プロバイダは構造化出力モードで内部的に低温に寄せている
分類・抽出・データ変換	0.0〜0.2	正確性が最優先。再現性も重要
要約・説明・カスタマー対応	0.5〜0.7	自然さと正確性のバランス。硬直的な応答を避けつつ逸脱を防ぐ
創作・ブレスト・候補生成	0.7〜1.0	多様性が価値の源泉。Best-of-N と組み合わせる場合は 0.7〜0.9
ツール引数の生成	0.0〜0.2	関数名・引数名の正確性が不可欠
計画・推論	0.3〜0.6	多少の探索は有益だが、論理の一貫性を保つ

温度 1.0 を超える値（一部 API で設定可能）は、エージェントシステムでは基本的に使いません。出力の制御が極めて困難になります。

実践的なアドバイス¶

エージェント内の経路ごとに温度を変えるのが基本です。計画ステップは 0.3〜0.5、ツール呼び出しの引数生成は 0.0〜0.2、ユーザー向け応答は 0.5〜0.7 というように、同一エージェント内でも使い分けます。B7 Model Router でモデルを切り替える際に、温度も同時に切り替えると自然です。
構造化出力の温度はまず 0 から始めることを推奨します。0 でもスキーマ違反が発生する場合はプロンプトかスキーマの問題です。温度を上げて「偶然正しい出力が出る」ことに依存してはいけません。
Best-of-N を使うなら温度を上げる必要があることを忘れないでください。温度 0 で N=5 を生成しても、ほぼ同一の候補が 5 つ返るだけです。N>1 のときは 0.5〜0.8 程度に設定し、多様な候補の中から Judge が最良を選ぶ構成にします。
温度によるリトライコストの増加を計測してください。温度を上げるとスキーマ違反や品質不足によるリトライが増え、実効コストが上がります。スキーマ違反率を継続的にモニタリングし、リトライ率が概ね 5% を超えたら温度を下げることを検討します。
top_p（nucleus sampling）との併用に注意してください。温度と top_p を両方変更すると効果が掛け算になり、予測困難な挙動を示します。原則としてどちらか一方だけを調整し、もう一方はデフォルト（top_p=1.0）にしておく方が制御しやすいです。