同じ質問なのに毎回答えが違う──これは「嘘をついている」のとは別の問題
2026年8月27日に各社の公式ドキュメントを取得して確認した。AnthropicのMessages APIはtemperatureを非推奨にしており、Claude Opus 4.6より後にリリースされたモデルでは1.0以外の値が400エラーになる。同じページは「temperatureが0.0でも結果は完全に決定的にはならない」と明記している。Thinking Machines Labの検証ではtemperature 0で1000回生成して80通りの出力が出た。出力のばらつきは幻覚とは別の現象であり、切り分け方と実務での回し方を分けて整理する。

同じ質問を2回投げて違う答えが返ってきたとき、多くの人はまず「AIが適当なことを言っている」と疑う。だがこれは2つの別々の現象で、混ぜて考えると対処を間違える。出力が回ごとに揺れること(非決定性)と、出力の中身が事実と違うこと(幻覚)は独立した軸だ。毎回違っても全部正しいことはあるし、毎回まったく同じ文面を返し続けても中身が全部間違っていることもある。そして揺れの主な原因は、公式資料と技術検証を読む限り、プロンプトの書き方でもモデルの気分でもなく、推論サーバーがそのとき何人分のリクエストを同時に処理していたか、という利用者からは見えない条件にある。この記事では、公式ドキュメントに書いてある事実、揺れの原因の技術的説明、そして「同じ質問を複数回回して割れ方を見る」という実務手順を、根拠を分けて整理する。
3行まとめ
- AnthropicのMessages APIリファレンスはtemperatureを非推奨とし、「Claude Opus 4.6より後にリリースされたモデルはtemperatureの設定に対応しない。後方互換のため1.0は受理するが、それ以外の値は400エラーで拒否される」と記載している(2026年8月27日に取得して確認)。top_p・top_kも同様に非推奨扱いになっている。
- 同じページは「temperatureが0.0であっても、結果は完全に決定的にはならない」と明記している。ゆらぎは利用者側の設定では消しきれない。
- Thinking Machines Lab(2025年9月10日公開)はQwen3-235B-A22B-Instruct-2507にtemperature 0で同一プロンプトを1000回投げ、80通りの異なる出力を得た。最初の102トークンまでは全1000件が完全一致し、103トークン目から分岐した。
主要APIのサンプリング系パラメータは今どうなっているか
以下は2026年8月27日に各社の公式ドキュメントをHTTP取得して読んだ内容である。
| 項目 | Anthropic Messages API | Google Gemini API(generationConfig) |
|---|---|---|
| temperature | 非推奨。Claude Opus 4.6より後のモデルは設定不可。1.0のみ後方互換で受理、それ以外は400エラー | 任意。範囲は0.0〜2.0。既定値はモデルごとに異なる |
| top_p / topP | 非推奨。0.99以上のみ後方互換で受理、それ以外は400エラー | 任意。Top-kとTop-pを組み合わせて使う |
| top_k / topK | 非推奨。値を渡すと400エラー | 任意。ただしnucleus samplingで動くモデルではtopKを設定できない |
| seed | リクエストのパラメータ一覧に存在しない | 任意。「未設定の場合、リクエストはランダムに生成されたseedを使う」 |
| temperature 0で決定的になるか | 「完全には決定的にならない」と公式が明記 | 同趣旨の記述は今回読んだページには見当たらなかった |
Anthropicの現行モデルはClaude Fable 5・Claude Opus 5・Claude Sonnet 5・Claude Haiku 4.5で、Claude Opus 4.8/4.7/4.6/4.5とSonnet 4.6/4.5はレガシー扱いとして公式一覧に残る。つまり「Claude Opus 4.6より後」に当たる現行の主力モデルでは、temperatureはもう触れないと考えたほうがいい。非推奨にした理由は今回読んだドキュメントに書かれていない。埋めると推測になるので書かない。
なぜ同じ質問で答えが変わるのか
よく見る説明は「GPUは並列計算だから浮動小数点の足し算の順序が毎回変わり、結果がずれる」というものだ。Thinking Machines LabのHorace Heらはこれを「並行実行+浮動小数点(concurrency + floating point)」仮説と名付け、「完全に間違いではないが全体像を示していない」として退けている。反例として、同じデータで同じ行列積をGPU上で繰り返してもビット単位で同一の結果が返るコードを載せている。並行実行でも浮動小数点でも、それだけでは実行ごとの揺れは起きない。
同記事が挙げる原因はバッチ不変性(batch invariance)の欠如である。行列積の実装は「同じ入力なら実行ごとに同じ結果」ではあるが、「バッチサイズが変わると、バッチ内の各要素の計算結果まで変わる」。数学的には、バッチの1要素の結果が他の要素の存在やバッチの大きさに左右されるのはおかしいが、実装上はそうなっている。同記事は、a[:1]とbの行列積と、a全体とbの行列積の先頭行を比べて最大1669.25の差が出る例を示している。
そして推論エンドポイントに問い合わせたとき、サーバーの混み具合は利用者から制御できない。混み具合がバッチサイズを決め、バッチサイズが計算結果を変える。記事の言い方を借りれば、他の同時利用者は「入力」ではなく「システムの非決定的な性質」として自分の出力に効いてくる。同記事はこれを、ほぼすべてのLLM推論エンドポイントが非決定的である主な理由だと結論づけ、GPU固有ではなくCPUやTPUで配信しても同じ原因の揺れが出るとしている。
対策としてバッチ不変なカーネルを実装すると、1000件の生成がすべて同一になった一方で速度は落ちた。Qwen3-8Bを1GPU、出力長90〜110の1000シーケンスで実測すると、vLLM既定が26秒、決定化版(未最適化)が55秒、アテンションカーネル改善後が42秒。同社は「性能は壊滅的ではない」と書いているが、既定比で1.6〜2.1倍かかっている。決定性はタダではない。
幻覚とどう違うのか
「揺れ」と「誤り」を2軸で切ると、対処法が変わるのが見える。
| 出力が毎回ほぼ同じ | 出力が毎回割れる | |
|---|---|---|
| 内容が正しい | 望ましい状態。ただし「同じだから正しい」ではない | 表現ゆれ。結論と数字が同じなら実務上の害は小さい |
| 内容が誤り | 最も危険。何度聞いても同じ誤りが返るので、繰り返しでは検出できない | 割れた箇所が「モデルが確信を持てていない場所」の地図になる |
ここに非対称性がある。同じ質問を何度も回して比べる運用は、右下の「割れる誤り」は拾えるが、左下の「安定した誤り」はまったく拾えない。分散を見れば幻覚が潰せるわけではない。幻覚そのものの原因と対策はLLMのハルシネーション(幻覚)とは?原因と対策で別に扱っている。
紛らわしい第3の失敗モードとして、反論すると正しかった答えを引っ込める追従性がある。これは同じ入力に対する揺れではなく入力(反論)が加わったことによる変化なので、非決定性とも幻覚とも別に切り分ける(AIは正しい答えを出した後、反論されると59%撤回する)。用語の整理はAI用語集にまとめてある。
実務では「複数回回して割れ方を見る」
複数回回す運用は思いつきではなく、ベンダー公式が手順として挙げている。Anthropicの「Reduce hallucinations」には、高度なテクニックのひとつとして「Best-of-N verification:同じプロンプトでClaudeを複数回走らせ、出力を比較する。出力間の不一致は幻覚の兆候になりうる」と書かれている。
実務に落とすなら、この順で回すのが扱いやすい。
- 判断に使う質問を1つに絞る。 「調べて」ではなく「この数字はいくつか」「この条件を満たすか」まで削り、割れたかどうかを機械的に判定できる形にする。
- 同じプロンプトを3〜5回、別々のセッションで投げる。 回数に統計的な根拠はない。コストと許容誤差で決める話だ。
- 数字・固有名詞・日付・結論(Yes/No)だけを抜き出して並べる。 文章全体は読み比べない。文体の揺れはノイズで、判断に効くのは抜き出した項目のほうだ。
- 全回一致した項目と、割れた項目に分ける。 割れた項目はそのまま使わず、一次ソースで確認する。
- 一致した項目も「一致=正しい」ではない。 分散チェックは一次ソース確認の代わりにはならず、どこを優先して確認するかの順番付けにしか使えない。
一方、出力形式のばらつきは、この方法で潰すものではない。Anthropicの「Increase output consistency」は冒頭で、特定のスキーマに準拠したJSONを常に出させたいならプロンプトエンジニアリングではなくStructured Outputsを使え、と書いている。キー名・列の順序・区分値のように機械的に決まるべき部分は、言い回しを工夫して安定させるよりスキーマで縛るほうが向いている。同ページはほかに、出力形式を厳密に指定する、抽象的な指示より実例を渡す、固定の情報源に接地させる(retrieval)、複雑なタスクを小さく分割して連鎖させる、といった方法を挙げている。プロンプト側で打てる手はプロンプトエンジニアリング入門にまとめてある。
この記事で確認できなかったこと
- OpenAIの仕様は扱っていない。 platform.openai.comのAPIリファレンスは今回HTTP 403で取得できず、seedなどの現在の挙動を公式原文で確認できなかった。記憶で書くとずれるため、OpenAIの数字と仕様には触れていない。
- Anthropicがtemperatureを非推奨にした理由は不明。 決定性のためなのか、内部のサンプリング方式が変わったためなのか、公式ドキュメントに説明がない。理由を書けば推測になる。
- Thinking Machines Labの検証は各社の商用エンドポイントの検証ではない。 対象はQwen3-235B-A22B-Instruct-2507とQwen3-8B、環境はvLLMで、公開は2025年9月10日。同じ機構がClaude・Gemini・GPTの本番推論スタック内部でそのまま成り立っているかは、各社が実装を公開していない以上、外部からは確認できない。「原理としてあり得る説明」であって「各社がそうなっていることの確認」ではない。
- 回数「3〜5回」に根拠はない。 何回で十分かはタスクと許容誤差で変わる。この記事は特定の回数を推奨しているのではなく、1回で決めないという運用を勧めている。
- 分散チェックの限界。 前述のとおり、モデルが安定して間違えている項目は、何回回しても検出できない。
出典と但し書き
- Messages(Claude API リファレンス) — temperature・top_p・top_kの非推奨、「0.0でも完全に決定的にならない」
- Reduce hallucinations(Anthropic) — Best-of-N verification
- Increase output consistency(Anthropic) — Structured Outputs、形式指定、retrieval
- Models overview(Anthropic) — 現行/レガシーモデル一覧
- Generating content / GenerationConfig(Gemini API) — temperatureの範囲、seedの説明
- Defeating Nondeterminism in LLM Inference(Thinking Machines Lab) — バッチ不変性、1000回生成で80通り、決定化時の速度実測
各社のAPI仕様は2026年8月27日に公式ドキュメントを取得して確認したものであり、予告なく変わる。実装の前に自分で公式ページを開いて確認してほしい。また本記事の手順は出力の正しさを保証するものではなく、確認すべき箇所に当たりをつけるための方法である。重要な判断に使う数字は、AIの出力が何回一致したかにかかわらず一次ソースで裏を取ること。
出典・参照資料
- 一次資料Messages(Claude API リファレンス) ↗
- 一次資料Reduce hallucinations(Anthropic 公式ドキュメント) ↗
- 一次資料Increase output consistency(Anthropic 公式ドキュメント) ↗
- 一次資料Models overview(Anthropic 公式ドキュメント) ↗
- 一次資料Generating content / GenerationConfig(Google Gemini API リファレンス) ↗
- 二次資料Defeating Nondeterminism in LLM Inference(Thinking Machines Lab, 2025年9月10日) ↗
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか?
AIについて聞きたいことはありますか?
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。