AIの回答が日によって変わる｜再現性のなさと付き合う型
昨日、うまくいったんです。
同じプロンプトを投げて、いい感じの回答が返ってきて、「よし、これで行ける」とスクリーンショットまで撮った。翌日、上司に見せようともう一度同じことを聞いたら——返ってきた答えが違う。悪くはないけれど、昨日ほど的確じゃない。手元にあるのは、昨日のスクリーンショットだけ。
この気まずさ、AIを実務に持ち込んだことがある人なら、たぶん一度は味わっています。自分の設定ミスを疑って、プロンプトを一字一句見比べて、でもどこも変えていない。変わったのはこちらではなく、AIのほうです。
この記事は、その「毎回同じにならない」性質——再現性のなさとどう付き合うかの話です。ゼロにする方法はありません。でも、①揺れを減らす → ②揺れる前提で組む → ③揺れを説明できるようにする、この3つを押さえておけば、デモと本番のギャップも、上への説明も、ずいぶん楽になります。
結論：AIの回答が日によって変わるのは、故障でも設定ミスでもなく、仕組み上そういうものです。だから対処は3方向。①減らす——temperature（出力のばらけ具合を決めるつまみ）を下げる、モデルのバージョンを固定する、プロンプトを版で管理する、入力に日付や乱れた文脈を混ぜない。②前提にする——「毎回同じ文字列が返る」ことを期待した実装・テストをやめ、中身が満たすべき条件（必須項目がある・値が範囲内・禁止事項を含まない）で判定する。③説明する——上や発注元には「AIは検索ではなく確率で文章を組み立てるので、同じ入力でも表現は揺れます。だから結果の形と最低条件を決めて、そこを保証します」と伝える。要は「同じ答え」ではなく「同じ品質」を約束するに、目標を置き換えることです。
一度に全部やらなくて大丈夫です。 まずは「temperature を下げて、モデルのバージョンを固定する」。ここだけでも体感がかなり変わります。
何が起きているのか——「同じ入力＝同じ出力」ではない
まず、AIが気まぐれなわけでも、あなたの使い方が下手なわけでもない、という話から。
AI（大規模言語モデル）は、質問に対する答えをどこかから引っ張ってくるのではなく、次に来そうな言葉を確率的に選びながら文章を組み立てています。「次はこの語が来る確率が高い」という候補の中から、少しゆらぎを持って選ぶ。だから、同じ質問でも通る道が毎回わずかに違い、結果として表現や構成が変わります。検索エンジンのように、同じキーを引けば同じレコードが返る、という作りではないのです。
そのうえで、現場で「変わった」と感じる原因は、だいたいこのあたりに分かれます。
- サンプリングのゆらぎ：上に書いた確率的な選び方そのもの。temperature（値が高いほど答えがばらけ、低いほど無難で安定する設定）が高いと、ゆらぎが大きく出ます。
- モデルのバージョンが変わった：提供元がモデルを更新すると、同じ名前でも中身が入れ替わっていることがあります。「先週と口調が変わった」の犯人は、たいていこれです。
- 入力が微妙に変わっている：プロンプトに今日の日付を差し込んでいる、参照する社内文書が更新された、会話の履歴が積み上がっている——本人は同じつもりでも、AIに届いている文字列は違います。
- 文脈の量が上限に当たっている：長い会話や大量の資料を渡していると、古い部分が押し出されて、参照されなくなることがあります。「途中から急に忘れる」はこれ。
- 裏側の仕組みが噛んでいる：RAG（社内資料を検索して渡す仕組み）を挟んでいる場合、検索で拾ってくる資料が変われば、答えも当然変わります。この場合はAIではなく検索側の揺れです。切り分け方はRAGの精度が出ないときの見直し所にまとめています。
やっかいなのは、これらが同時に効いていることです。だから「なぜ変わったのか」を1発で特定しようとすると、たいてい行き詰まります。順番に潰していきましょう。
① 揺れを減らす——先に固定できるものを固定する
完全には消せませんが、揺れ幅を小さくする手はいくつもあります。効くものから順に。
- temperature を下げる：業務で「決まった形の答え」がほしいなら、まずここ。分類・抽出・要約・整形のように正解の幅が狭い用途では、低め（0に近い値）にします。逆に、アイデア出しやコピー案のように幅がほしい用途では高めのままでいい。用途ごとに使い分けるのが実務的です。なお、低くしても完全に同じにはなりません（同じ結果を狙う設定を提供しているモデルもありますが、保証ではなく「近づける」程度に見ておくのが安全です）。
- モデルのバージョンを固定する：
最新版を指す名前ではなく、バージョンまで指定した名前（日付やリビジョンが入ったもの）を使う。提供元が更新しても、勝手に足元が変わらなくなります。ただし固定した版はいつか提供が終わるので、「いつまで使えるか」を公式の告知で確認し、乗り換え時期をカレンダーに入れておくのがセットです。ここを放置すると、ある日突然動かなくなります。 - プロンプトを版で管理する：「誰かが良かれと思って一行足した」で挙動が変わるのはよくある話です。プロンプトはコードと同じくGitなどで管理し、変更履歴を残す。詳しくは本番プロンプトのバージョン管理へ。
- 入力に「今日の日付」や余計な履歴を混ぜない：再現したいときは、入力を毎回まったく同じにできる形にしておきます。会話の履歴を引き回す設計なら、検証用は毎回まっさらな状態から始めるようにするだけでも、比較がしやすくなります。
- 出力の形を先に決める：文章で返させるより、決まった項目のJSONなどで返させるほうが、揺れの影響が小さくなります。やり方はAIの構造化出力（JSON）を安定させるに整理しました。
ここまでで、「昨日と全然違う」レベルの揺れはかなり収まります。それでも残る細かい揺れは、次の②で受け止めます。
② 揺れる前提で組む——「同じ文字列」で判定しない
減らしても、ゼロにはなりません。だから実装とテストのほうを、揺れに強い形に変えます。ここが一番効きます。
- 期待値を「完全一致」で書かない：AIの出力をテストするとき、
assertEqual(出力, "期待する文章")と書くと、まず安定しません。代わりに、満たすべき条件で判定します。たとえば「必須のキーが5つそろっている」「金額が0以上」「区分が決められた3つのどれか」「禁止語が含まれていない」。これなら表現が揺れても通ります。AIが書いたテストを鵜呑みにしない話はAIが書いた単体テストを信用しすぎないも合わせてどうぞ。 - 「だいたい合っている」を測る物差しを1つ持つ：要約や分類のように答えが一意でない機能は、評価用のサンプルを10〜30件ほど作って、正解率や合格率を見るのが実務的です。1件を目で見て一喜一憂するより、割合で見るほうが判断がぶれません。数を増やすのは後からで大丈夫。まずは10件でも、比較の土台になります。
- モデルやプロンプトを変えたら、同じサンプルで測り直す：この物差しがあると、「新しいモデルにしたら良くなったのか」が感覚ではなく数字で言えるようになります。上への説明もぐっと楽になります。
- 崩れたときの逃げ道を決めておく：たまたま形が崩れた1件で全体を止めない。再依頼の回数を決め、それでもダメなら安全側に倒す。この型はAI出力が不安定なときのフォールバック設計に書きました。
- 重要な判断は人が確認する経路を残す：揺れる以上、「AIの答えをそのまま最終決定にしない」箇所を決めておくのが安全です。どこに人を挟むかは人の確認を挟むAIワークフローへ。
言い方を変えると、目標を「毎回同じ答えを返す」から「毎回、決めた条件を満たす答えを返す」に置き換えるということです。この置き換えができると、揺れは事故ではなく、想定内の幅になります。
③ 揺れを説明できるようにする——デモと本番のギャップを埋める言葉
技術的に整えても、上や発注元への説明でつまずくことがあります。「先週見せてもらったやつと違うんだけど」と言われる場面ですね。ここは、言葉を先に用意しておくと落ち着いて話せます。
- 仕組みとして説明する：「不具合ではなく、AIは文章を確率的に組み立てるので、同じ質問でも表現は毎回少し変わります。検索のように同じ結果を引く仕組みとは別物です」。責任の話にせず、性質の話にするのがコツです。
- 約束の単位を言い換える：「毎回同じ文章はお約束できません。代わりに、出力の形と満たすべき条件（必須項目・値の範囲・禁止事項）を決めて、そこは機械で確認して保証します」。約束できることと、できないことを、先に線引きしておく。
- デモの見せ方を変える：一発勝負のデモは、揺れに弱いです。同じ入力で3回動かして、3回とも条件を満たすところまで見せるほうが、結果的に信頼されます。「毎回ちょっと違うけど、どれも使えますよね」と先に言ってしまうのが、いちばん強い。
- 記録を残す：いつ・どのモデルのどの版で・どのプロンプトで・何が返ったか。あとで「言った言わない」にならないよう、入出力とモデル名・版をログに残しておく。これは説明のためでもあり、劣化に気づくためでもあります。
過度な期待と現実の差に挟まれるのは、正直しんどい仕事です。でも、「できること・できないこと」を先に言葉にしておいた人は、あとで一番信用されます。似た場面の言い方は「で、効果あったの？」AI活用の成果を数字で報告するコツにもまとめました。
明日からやること（まずこの3つ）
大がかりな作り込みは要りません。今日触れる範囲だけ。
- temperature を用途に合わせて見直す：決まった形の答えがほしい処理は、低めに寄せる。設定した値がいくつなのか、そもそも把握できていなければ、まず確認するところから。
- モデルの指定を、バージョン込みの名前に変える：
最新を指す指定になっていないか見る。変えたら、その版の提供終了予定を公式で確認してカレンダーに入れる。 - 評価用のサンプルを10件だけ作る：入力と「満たすべき条件」を10組。これが、揺れを測る最初の物差しになります。完璧な評価基盤は要りません。10件で十分に始まります。
この3つは、いちど作れば使い回せます。「なんとなく調子が悪い気がする」を、「10件中8件は通っている」に変えられるだけでも、ずいぶん気が楽になります。
AIの再現性と付き合うチェックリスト
全部に○が要るわけではありません。いま気になっている機能について、関係する所だけで十分です。
① 揺れを減らす
- temperature を用途（決まった形／幅がほしい）で使い分けているか
- モデルをバージョン込みの名前で指定しているか
- その版の提供終了予定を確認し、乗り換え時期を決めているか
- プロンプトの変更履歴が残る形になっているか
- 入力に日付や会話履歴など、意図しない変動要素が混ざっていないか
② 揺れる前提で組む
- テストの期待値を「完全一致」ではなく条件で書いているか
- 評価用のサンプル（10件でも可）と合格の基準があるか
- モデル・プロンプトを変えたとき、同じサンプルで測り直しているか
- 形が崩れたときの逃げ道（再依頼の上限・安全な既定値）を決めているか
- 重要な判断に、人が確認する経路が残っているか
③ 説明できるようにする
- 「同じ文章」ではなく「同じ条件」を約束する言い方を用意しているか
- デモを複数回動かして見せる形にしているか
- 入出力・モデル名・版・プロンプトをログに残しているか
この記事のまとめ
AIの回答が日によって変わるのは、あなたの設定ミスではありません。そういう仕組みのものを使っている、というだけの話です。
だから、直そうとするのではなく、付き合い方を決める。temperature とモデルの版を固定して揺れを減らし、テストと実装を「条件で判定する」形に変えて揺れを受け止め、上には「同じ答え」ではなく「同じ品質」を約束する。この3方向がそろうと、昨日と違う答えが返ってきても、慌てなくてよくなります。
完璧な再現性は、そもそも手に入りません。手に入るのは、揺れても大丈夫な作りのほうです。
昨日のスクリーンショットと違う答えが返ってきた朝は、少し焦ります。 でも、そこで「おかしいな」と気づけたことこそが、揺れに強い作りを始める入口です。今日、temperature をひとつ見直せたなら、それで十分な前進です。