同じ質問でAIの答えが変わるのはなぜか。4つの原因と、検収で決める5項目

検収の場でいちばん揉めるのが、この一言である。

「先週と同じ書類を入れたのに、答えが違います」

開発会社は「AI なのでそういうものです」と答える。発注者は「それでは検収できない」と答える。どちらも間違っていないので、話が終わらない。

必要なのは、なぜ答えが変わるのかを原因ごとに分けることと、検収の合格条件を「一致」から別のものに置き換えることである。この 2 つを見積依頼の段階で決めておけば、検収で揉めない。

スキャナの手前に同じ書式の読み取り結果が2枚並び、虫眼鏡の下の1行だけ長さが違う

ハルシネーションとは別の問題である

先に区別しておく。

	非決定性（この記事）	ハルシネーション
症状	同じ入力で出力が変わる	事実と違うことを言う
1 回だけ見たとき	気づかない（正しく見える）	気づけることがある
対策の方向	固定・判定基準・合格率	根拠の提示・検索の併用・人の確認

ハルシネーションとは。AIが事実と違うことを言う理由は「答えの中身が合っているか」の問題である。この記事は「何度やっても同じ答えになるか」の問題を扱う。両方とも検収に関わるが、原因も対策も別である。

答えが変わる 4 つの原因

原因 1. サンプリング（温度）

LLM は次に来る単語の確率を計算し、そこから 1 つ選ぶ。この「選び方」を決めるのが temperature や top_p といった設定である。

温度が高い: 確率の低い候補も選ばれる。表現が多様になる
温度が 0: 常にいちばん確率の高い候補を選ぶ（貪欲法）

文章を書かせる用途では温度を上げ、分類・抽出では 0 に近づけるのが一般的な設計である。ここは開発会社が設定で決められる部分であり、見積書に書ける。

原因 2. 温度を 0 にしても一致しない（バッチ不変性）

ここが知られていない。温度 0 にすれば完全に同じ答えが返る、というのは誤りである。

Thinking Machines Lab が 2025 年 9 月 10 日に公開した解説「Defeating Nondeterminism in LLM Inference」は、その理由を次のように整理している。GPU 上の計算はそれ自体は毎回同じ結果を返すが、バッチサイズが変わると数値がわずかに変わる。そして、共有されている API サーバーでは、同時に来ている他の利用者のリクエスト数によってバッチサイズが変わる。

つまり、自分の入力を変えていなくても、サーバーの混み具合が結果を動かす。温度 0 は選び方を固定するだけで、選ぶ元になる確率そのものが揺れるため、ごく稀に違う単語が選ばれる。

対処はあるが、安くはない。

方法	実現性	代償
商用 API をそのまま使う	一致は保証されない	—
自社でモデルを動かし、バッチサイズ 1 に固定する	可能	処理能力が大きく落ちる
推論基盤のバッチ不変モードを使う	可能（推論基盤 vLLM に `VLLM_BATCH_INVARIANT` の設定がある）	スループットが落ちる。対応 GPU の条件がある

ビット単位の一致が本当に必要な案件は少ない。必要になるのは、監査で再実行が求められる業務や、出力そのものが証跡になる業務である。該当するかどうかを先に決めないと、過剰な構成に費用を払うことになる。

原因 3. モデル側が変わっている

利用者が何もしなくても、提供側が変えることがある。

エイリアス指定: 最新版 を指す名前を使っていると、提供側の更新でモデルが入れ替わる
スナップショット指定: 日付入りの固定名を使えばモデルは固定される。ただし停止日が来る
ルーティング: 1 つの窓口の裏で複数のモデルに振り分けるサービスでは、どれに当たるかで答えが変わる

実務で効くのはこれである。原因 2 の揺れは 1 行の差だが、モデルが変われば出力の傾向がまとめて変わる。検収が通った後に精度が落ちる事故は、ほとんどこれが原因である。

原因 4. 入力側が変わっている

モデルは同じでも、渡している内容が同じでないことがある。RAG を使う構成では特に起きやすい。

検索でヒットする文書が、文書を追加・更新した分だけ変わる
プロンプトに現在時刻や利用者名が埋め込まれている
外部ツール（在庫 API・社内システム）の戻り値が変わっている
会話履歴の要約（コンパクション）が走り、前提が縮んでいる

これは AI 特有の問題ではなく、入力が変わっているだけである。切り分けの第一手は、そのときモデルに渡した内容を丸ごとログに残しておくことである。ログがないと、原因 2 と原因 4 を区別できない。

検収で決める 5 項目

原因が分かれば、検収条件は書ける。「毎回同じ答えを返すこと」を条件にしないのが要点である。

1. 合格の判定方法を「一致」から変える

判定方法	向く用途
完全一致率	分類・区分コードの付与・数値の抽出
項目単位の一致率	帳票からの項目抽出（項目ごとに正解と照合）
許容範囲内か	金額・日付（表記の揺れを正規化してから比較）
人による採点（複数名）	要約・文章生成。採点基準表を先に作る
ブレ幅の上限	同じ入力を 5 回通し、結果が割れる割合が N% 以下であること

最後の行が非決定性に対する直接の答えである。「同じ入力を複数回通したときに答えが割れる割合」を測り、その上限を決める。 判定の作り方そのものはAIの精度をどう評価するか。発注者が知るべき指標と落とし穴に揃えてある。

2. モデルを固定することを書く

見積書・仕様書に次の 2 行を入れる。

使用モデルは日付入りのスナップショット名で固定する。エイリアス（最新版を指す名前）は使用しない。提供側の停止予告があった場合の載せ替え手順と、その費用の負担を定める。

固定しないと、検収の条件を満たしていた構成が勝手に別物になる。構造化出力を使う構成では、構造化出力（JSONスキーマ）とは。AIの答えを型にはめる仕組みと見積書で見る4点のとおり、型を固定するだけでも揺れの影響をかなり抑えられる。

3. 設定値を納品物に含める

温度・top_p・seed・最大出力長・システムプロンプトは、すべて成果物である。納品物の一覧に入っていないと、担当者が変わったときに再現できない。

4. ログの保存範囲と期間を決める

切り分けに必要なのは次の 4 つである。

モデルに渡した入力の全文（RAG の検索結果を含む）
モデル名とバージョン
設定値
出力の全文と、トークン数

個人情報を含む場合は保存の可否が変わるため、AI開発で外部APIに送ってよいデータの決め方。4区分と見積依頼に書く5行の区分で先に決める。ログの量は費用に効くので、保存期間（例: 90 日）を決めて見積額に反映してもらう。

5. 稼働後の再評価を保守に含める

検収時の合格率は、そのときの数字である。モデルの入れ替えや文書の追加で変わる。

月 1 回、同じ評価セットで合格率を測り、低下した場合に報告する。

この 1 行を保守の範囲に入れておく。費用の相場はAI開発の保守費用の相場。契約に含めるべき範囲で確認できる。評価を誰がやるかで費用と独立性が変わる点はAIの精度評価は誰がやるか。ベンダー・自社・第三者の3つの型を費用と独立性で比較に整理した。

見積書を比べるときに見る 3 点

ここまでの内容は、相見積もりの比較に直接使える。

合格の判定方法が書いてあるか（「精度 90%」だけでは何の 90% か分からない）
モデルの固定とログの保存が項目として立っているか（書いていない会社は、検収時に揉める）
再評価が保守に入っているか（入っていない見積書は、その分だけ安く見える）

3 番目が価格差の正体であることは多い。安い見積書が悪いのではなく、範囲が違うものを金額だけで比べていることが問題である。AIの精度目標を5ポイント下げると費用はどこが減るか。緩めてよい3条件と危険な4場面のとおり、目標の設定次第で削れる費用もある。

無料で相見積もり・相談の案件票では、精度の判定方法・ログの保存要件・保守範囲を選択式で揃えている。同じ検収条件を前提にしなければ、見積額を並べても比較にならない。

まとめ

AI の答えが変わる原因は 4 つ。サンプリング設定・バッチ不変性・モデル側の変更・入力側の変更である
温度 0 でも完全な一致は保証されない。共有 API ではサーバーの混み具合でバッチサイズが変わり、数値がわずかに動く
ビット単位の一致が要る案件は少ない。必要なら自社運用やバッチ不変モードが必要で、処理能力を犠牲にする
検収は「一致」ではなく、合格率とブレ幅の上限で判定する
見積依頼にはモデルのスナップショット固定・設定値の納品・ログの保存範囲と期間・月次の再評価を入れる
相見積もりでは、判定方法とログと再評価が書かれているかを見る。書かれていない見積書は安く見えるだけである

参考

Thinking Machines Lab「Defeating Nondeterminism in LLM Inference」（2025 年 9 月 10 日） https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
vLLM ドキュメント「Batch Invariance」（VLLM_BATCH_INVARIANT の設定と対応 GPU の条件） https://docs.vllm.ai/en/stable/features/batch_invariance/