Gemini 最新モデルで temperature / top_p / top_k が無視される — サンプリング廃止を運用者目線で読む

まず結論 — temperature を回しても、もう出力は変わらない

結論から書きます。Google の Gemini API 公式ドキュメント（Gemini API Latest models）が、最新世代の Gemini モデルでは temperature・top_p・top_k といった従来のサンプリングパラメータを「deprecated（非推奨）かつ無視する」と明記しました。つまり、これらの値をいくら渡しても出力の揺らぎは変わりません。ノブは回るのに、配線がつながっていない状態です。

対象は Gemini 3.6 Flash と Gemini 3.5 Flash-Lite、そして「今後リリースされる全ての Gemini モデル」です。ドキュメントはさらに踏み込んで、将来の世代ではこれらのパラメータを渡すと HTTP 400 エラーを返す、と書いています。長年 temperature=0 で出力の再現性を担保してきた私にとっては、前提が一つ崩れた話でした。何が効かなくなり、既存コードのどこを直すかを運用者目線で書き残しておきます。

何が deprecated になったか — 公式ドキュメントの記述

deprecated 扱いになったのは、出力の多様性を数値で調整する 3 つのノブです。temperature（乱雑さの度合い）、top_p（累積確率で候補を絞る nucleus sampling）、top_k（上位 k 個のトークンだけを残す）。いずれも LLM のサンプリングを外から制御する定番のパラメータでした。

ドキュメントの表現はかなり強い。「これらのパラメータは deprecated で無視される。将来のモデル世代では、これらを渡すと HTTP 400 を返す」。そして移行ガイドには「全てのリクエストからこれらのパラメータを削除せよ」と一行で書かれています。ここで大事なのは、「いつか非推奨になる」という予告ではなく、「今の 3.6 Flash / 3.5 Flash-Lite で既に無視されている」という現在形だという点です。手元の抽出バッチで temperature を 0.2 から 1.0 まで振ってみましたが、出力の分布は目に見えて動きませんでした。エアコンのダイヤルが実は裏で配線を抜かれていて、回すと安心はするけれど部屋の温度は別の誰かが決めている、という感覚に近い。

なぜ効かなくなったのか — 制御がモデル側に移った

背景を一言で言えば、出力の質を決める主導権が「呼ぶ側のパラメータ」から「モデル内部の推論」へ移ったからです。thinking（内部で一度考えてから答える推論ステップ）を前提にした世代では、モデルが自分でどれだけ探索し、どこで決め打つかを内部で調整します。そこへ外から温度を上書きされると、内部の設計と正面衝突する。

だから Google は、ユーザーが握れるノブを減らし、制御を自社側に寄せる選択をしたのだと読めます。これは good/bad の話ではなく設計思想の変更で、OpenAI や Anthropic の推論寄りモデルでも「temperature を下げても reasoning の質はそんなに変わらない」という体感は前からありました。Gemini はそれを、ドキュメント上で明示的に「無視する」と言い切った。曖昧に効くパラメータを残すより、効かないと宣言してくれた方が、運用側としてはむしろ判断が楽です。効くのか効かないのか分からないノブほど、デバッグの時間を溶かすものはありません。

既存コードのどこを直すか

影響が出るのは主に 2 か所です。ひとつは再現性のために temperature=0（または近い値）を固定していた箇所。もうひとつは、リトライで temperature を上げて別解を引く、という多様性狙いのループです。

私が以前書いた分類パイプラインは、1 回目を temperature=0 で決め打ち、外したら 2 回目を 0.7 に上げて別の答えを引く、という二段構えでした。この 2 段目の前提が今回で消えます。Gemini 側では温度を上げても分布が広がらないので、リトライしても同じ答えが返りやすい。リトライ前提の設計はコストも膨らむという話はLLM API のコスト暴走を「呼ばない」で防ぐ三段防御でも書きましたが、そもそも温度で多様性を作る手が使えないなら、多様性はプロンプトの言い換えや few-shot の差し替えで作るしかありません。まずは generationConfig から temperature / topP / topK を機械的に grep して外す。将来世代で 400 になる前に消しておくのが安全です。

代わりに何で出力を制御するか — system instruction と構造化出力

公式が示す代替は 2 本柱です。ひとつは system instruction（システム指示）に、その用途固有のルールを明文で書くこと。もうひとつは、形式を固定したいなら Structured outputs（構造化出力）で JSON スキーマを渡すこと。

発想の転換が要ります。これまでは「temperature を下げれば堅くなる」と数値で祈っていたところを、「どう振る舞ってほしいか」を日本語や英語のルールとして書き下す。たとえば「不明な項目は推測せず null を返す」「箇条書きは 3 項目まで」といった制約は、温度ではなく指示で縛る。形式のブレは Structured outputs に任せれば、JSON として壊れる心配自体が消えます。重みを手元で回せるローカルモデルなら、まだ自分でサンプリングを制御できる余地があります（ローカルLLMが「使える」に変わった2026年に書いた通り）。制御をどこまで自分の手に残したいかも、API とローカルを選ぶ判断軸になってきました。

運用者としての判断 — 再現性テストをどう組み直すか

一番影響が大きいのは、temperature=0 を「決定的な出力の保証」として扱っていたテストです。これは元々、Gemini に限らず完全な保証ではありませんでしたが、今回で「保証のつもり」ですらなくなりました。

私の現実的な線引きはこうです。出力の一致を 1 文字単位で assert していたテストは、意味的な一致（キーの有無、値の型、想定ラベル集合に入っているか）を見る方式に組み直す。この「文字列一致ではなく性質で検証する」考え方は、コーディング評価で信号とノイズを切り分けるで書いた評価設計と地続きです。temperature が消えたことを損失として嘆くより、そもそも数値のノブに寄りかかっていた設計を見直す機会と捉える方が健全でしょう。祈りをパラメータに込めるより、期待する振る舞いを指示とスキーマで書き下す。地味ですが、こちらの方が壊れにくい。