生成AIの出力のばらつき｜原因を5つに分けて再現性を上げる

「昨日はうまくいったのに、今日は違うものが返ってきます」。生成AIを業務へ入れた人から、この相談をよく受けます。

指示文は変えていない。モデルも変えていない。それでも文章の並びが入れ替わり、拾ってくる数値が変わる。これが何度か続くと、話は「このAIは不安定だ」というところで止まります。

そこで止めてしまうと、直せたはずの原因まで一緒に諦めることになります。この記事では、出力のばらつきをどの順番で切り分け、どこまで数字で確かめ、どこから先を設計で押さえるのかを扱います。素材は公式ドキュメントの記載と、運営元での運用実例です。

進行役は3人です。若葉さんが言葉の側から、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。

01生成AIの出力のばらつきって、そもそも何が起きているんですか？

若葉さん

若葉さんの発言

同じことを聞いているのに、返事が毎回ちがうんです。これは故障でしょうか。

鈴木さん

鈴木さんの発言

故障ではないと思っています。料理人に「いつもの感じで」と頼むのに近くて、頼み方のほうに幅があると、出てくるものにも幅が出ます。

出力のばらつきとは、同じ生成AIに同じ指示を渡しても、実行のたびに文章や数値が変わる現象を指します。

ここで先に押さえたいのは、ひとつの現象に見えているものが、性質の違う2種類の差の合計だという点です。片方は書き手の側にあり、手を入れれば減ります。もう片方はモデルの側にあり、減らすというより、どこまで許すかを決める対象になります。

この2つを分けないまま眺めていると、減らせる差まで「AIだから仕方ない」の箱へ入ります。逆に、モデル側の差を書き方だけで消そうとすると、終わりの見えない作業になります。

図の左右で違うのは大きさではありません。打ち手の置き場所です。左は指示文や運用の側に手がかりがあり、右にはそれがありません。だから右へ回すものが増えるほど、できることは減ります。

診断の目的は、右の箱をできるだけ小さくしておくことです。最初から右へ入れてしまうと、小さくする作業そのものが始まりません。

02生成AIの出力のばらつきと再現性は、まず自分側の何を疑うんですか？

出力が変わったとき、多くの人は最初にモデルを疑います。ところが公式のプロンプトガイドは、指示が明確で具体的であるほど良い結果につながると説明しています（出典: Claude公式プロンプトエンジニアリングガイド）。

順番を逆にすると、直せる原因を素通りしたまま結論だけが出ます。要因は5つあり、手前の4つは自分側、いちばん奥の1つだけがモデル側です。

並べてみると、表からは読み取れないものが1つ見えます。引き返せる地点が、前半にしかないことです。

①〜④はどれも、見つかった時点でその場が直しどころになります。⑤に着いてしまうと、直す場所は前へ戻るしかありません。だから順番は好みではなく、やり直しの量を決める設計です。

03指示の書き方が出力のばらつきの原因かどうかは、AIエージェントに渡す前にどう見分けるんですか？

高梨課長

高梨課長の発言

自分の指示が曖昧かどうかって、書いた本人には分からない気がします。

鈴木さん

鈴木さんの発言

そうなんです。なので、自分では判定しないことにしています。前提を知らない人に読ませて、同じ動きになるかどうかを見ます。人によって解釈が割れるなら、それは指示の側の問題です。

①の見分け方は、公式ガイドが挙げている基準がそのまま使えます。前提知識のない同僚にその指示文を見せて、同じ動きをしてもらえるかを見ます（出典: Claude公式プロンプトエンジニアリングガイド）。

読んだ人によって解釈が割れるなら、モデルが不安定なのではなく、指示に幅が残っています。AIエージェントへ渡す前に、この一手間を入れておくと、あとの切り分けが短くなります。

たとえに置き換えると、抜けているのは知識ではなく決めごとだと分かります。分量を書かない、どの棚のものか言わない、味の合否を自分の舌の中に置いたまま渡す。どれも作り手の腕前とは別の話です。

指示文でも同じで、足りないのは説明の長さではありません。読み手が選ばずに済むところまで、決めて渡せているかどうかです。

04再現性を保つには、渡す文脈と参照資料は、AI社員に毎回同じものを渡せているんですか？

②は、渡している文脈が実行のたびに同じかどうかの問題です。長いやり取りの途中で古い指示が薄れていく現象とは別で、ほぼまっさらな状態から同じ指示を渡しているのに結果が変わる場合を指します。

③は、参照する資料のどの版を見るかを指示文が示していない状態です。「最新の規約を見て」とだけ書くと、同じフォルダに複数の版があるとき、どれを開くかが実行のたびに変わります。

②と③をまとめて言うと、入口に置いた材料が毎回同じかという話になります。出てくるものだけを見比べても、ここは見えません。

長いやり取りでの文脈の扱いは、Claude Codeのコンテキスト管理｜指示がぶれない3つの手で扱っています。手順はそちらを参照してください。

05判断基準が人の頭の中にあると、生成AIの出力は何がぶれるんですか？

④は、合否や採用・不採用を決める基準が文書になっていない状態です。基準が担当者の記憶の中だけにあると、同じ担当者でもその日の判断で線が動きます。

ここが厄介なのは、動いているのが人側の線なのに、揺れて見えるのがAIの出力だという点です。原因と現れる場所がずれているので、いくら出力を眺めても手がかりが出てきません。

前後で入れ替わったのは、基準の厳しさではありません。基準の置き場所です。頭の中にあるうちは、本人にも変化に気づけません。外へ出したとたん、変わったかどうかを見比べられるようになります。

判断基準を書き出す先の作り方は、AIエージェントのスキル設計｜呼ばれる単位に分ける4つの型にまとめています。

06生成AIの出力のばらつきを測ると、再現性は何の数字で見えるんですか？

原因の見当がついたら、次は感覚ではなく数字で確かめます。やることは、同一の指示を複数回実行し、4つの軸で採点することです。

採点は実行の前に基準を決めます。終わってから「今回は特殊だったので除外」と動かすと、測定そのものが成り立ちません。公式の評価設計ガイドも、成功基準はテストを組む前に具体的な数値で定義するよう勧めています（出典: Claude公式Test and Evaluateガイド）。

進め方は3ステップです。変えたい変数（モデル・プロンプト文言・渡す文脈）を1つも動かさずに同一の指示を用意し、それをN回実行して出力を1回ずつ保存し、決めておいた合格ラインと照らして判定します。

1回の実行結果は、こうした記録として残しておくと、あとから比較できます。

{
  "run_id": 1,
  "required_elements_ratio": 1.0,
  "structure_match": true,
  "numeric_match": true,
  "verdict_match": true
}

図の真ん中に置いたものが、この章のいちばん大事なところです。試行の数を増やしても、合格ラインを先に決めていなければ、増えるのは記録だけになります。

同じ「感覚ではなく測る」という組み立ては、Agent Skillsの発火精度｜59本の監査で見えた検証の組み立て方でも使っています。先に採点基準を置いてから検証に入る点が共通しています。

07何回流せば、生成AIの再現性を判断していいんですか？

高梨課長

高梨課長の発言

何回まわせば「揃っている」と言っていいのか、そこが分かりません。

鈴木さん

鈴木さんの発言

用途で変わります。1回きりの下書きなら、3〜5回で傾向がつかめれば十分だと考えています。毎週使う型なら、採点のほうを自動にして本数を増やすほうが安全です。

回数の決め方は、その指示文をこの先どれだけ使うかで変わります。公式ガイドは、自動で採点できる評価は数を増やすほうを優先すべきだと述べています（出典: Claude公式Test and Evaluateガイド）。

言い換えると、上限を決めているのは採点する側の手間です。人が目で採点している限り、増やせる数はすぐ頭打ちになります。採点を機械に渡せた分だけ、試行の数を増やせます。

1回きりの下書きなら、3〜5回まわして傾向をつかめば十分です。繰り返し使う定型プロンプトなら、採点を自動化したうえで本数を増やすほうが安全です。

08生成AIの出力のブレを抑える手立ては、プロンプト側に何があるんですか？

自分側の原因を潰しても、ばらつきがすべて消えるとは限りません。残った分は、プロンプトと運用の設計で押さえます。

①は、公式ドキュメントが示す出力一貫性を高める手法と重なります。出力形式を厳密に指定する方法が効くと説明されています（出典: Claude公式Increase Output Consistencyガイド）。例をいくつか示して挟む方法も、出力を安定させる手法として公式が勧めています（出典: Claude公式プロンプトエンジニアリングガイド）。

厳密なJSON形式が要る場合は、Structured Outputs機能を使います。すると、スキーマ違反そのものが起きなくなります（出典: Claude公式Structured Outputsドキュメント）。

②は、判断基準を人の記憶から外へ出す手段です。運営元WEBMARKSは.agents/skills配下で59本のスキルを運用しています（2026-07-28時点、自社実例の実測台帳）。判断基準をSKILL.mdへ書き出す運用を重ねてきました（出典: Claude Code公式スキルドキュメント）。基準が文書になっていれば、担当者やセッションが変わっても同じ判定になります。

③は、参照する資料をその場の検索結果へ任せず、固定のリストから読ませる手段です（出典: Claude公式Increase Output Consistencyガイド）。ここまでの3つは、どれも渡す前に効かせる手立てです。

09出力を点検して、AI社員のやり直しはどこで止めるんですか？

残りの2つは、出てきたあとに効かせる手立てです。前の3つが入口の話だとすると、こちらは出口の話になります。

④は、出力を受け取った直後に、決めた項目で自己点検させる手段です。公式ガイドも、仕上げる前に基準と照らして自己検証するよう指示すると誤りを減らせると説明しています（出典: Claude公式プロンプトエンジニアリングガイド）。

⑤は、④で不合格になったときにどこまで粘るかの線です。ここを決めずに再実行を重ねると、たまたま基準を満たした1回だけを採用する「都合のよい抜き取り」になります。

積み上げてみると、①〜⑤が同じ列の手段ではないことが分かります。材料を決める段・形を決める段・出たものを見る段・引き返す線の4つに分かれます。

どれか1段だけを厚くしても、抜けた段からばらつきが戻ってきます。逆に、全部を一度に作らなくても、下の段から順に置いていけば、そのつど効きます。

10ばらつきを抑えたくても温度を下げる手が使えないモデルでは、AI活用の何が変わるんですか？

モデル側の確率的な挙動そのものを抑える手段には、注意が要ります。公式ドキュメントによると、temperatureを最小の0.0にしても、結果は完全な決定論的にはなりません（出典: Claude公式messages APIドキュメント）。

さらにClaude Opus 4.7以降のモデル（Opus 5を含む）では、temperature・top_p・top_kを既定値以外にできません。既定値以外を指定すると400エラーになります（出典: Claude公式移行ガイド）。同じガイドは、モデルの挙動を細かく導きたい場合の手段は、サンプリングパラメータではなくプロンプトだと案内しています（出典: Claude公式移行ガイド）。

ここで変わるのは、対策の順位です。温度を下げるという手が使えないモデルが主力になりつつある以上、前章の①〜⑤は代わりの案ではなく、はじめから主力の側にあります。

11出力のばらつきについて、揃えるべき工程と揃えてはいけない工程は、AI導入でどう線を引くんですか？

出力のばらつきは、いつでも悪いわけではありません。揃えるべき工程と、揃えてはいけない工程を混ぜると、かえって成果物の質を落とします。

判断そのものは単純です。正誤・合否の基準が外に存在するなら揃え、存在しないなら揃えません。確認は2点で行います。ひとつは、その基準を担当者以外にも説明できる形にできるか。もうひとつは、その基準を使う人が自分以外にもいるか、将来増える見込みを含めて考えることです。

2軸に置き直すと、表では見えなかった区画が1つ出てきます。基準は外にあるのに、使う人が自分だけという区画です。ここは今すぐ固めなくても回りますが、担当が増えた瞬間に揃える側へ移ります。

基準の無い工程まで①〜⑤で固めると、案の似通いという形で跳ね返ります。揃えるかどうかは、工程の性質を見て決める話であり、全体の方針で決める話ではありません。

ここまでは、同じモデル・同じ指示を繰り返したときのばらつきを扱いました。モデル自体を切り替えたときの検証には別の設計が要ります。詳しくはAIモデル乗り換え検証の設計｜指標4観点と合否3段階の決め方を参照してください。

12生成AIの出力のばらつきで、AIエージェント運用の何につまずくんですか？

若葉さん

若葉さんの発言

気をつけていても、やってしまいがちなことってありますか。

鈴木さん

鈴木さんの発言

いくつかあります。どれも「作業としては進んでいるのに、測れていない」形になるのが共通点です。手が止まらないぶん、気づくのが遅れます。

つまずきやすいのは、次の4つです。

1. 温度を下げれば片づくと思い込む：モデルによっては、そもそもtemperatureを既定値以外に設定できません。出力形式・判断基準・文脈・チェックリストを試さないまま、存在しない調整つまみを探して時間を使います。
2. 合格ラインを実行のあとで決める：先にN回流してから「だいたい合っていればよい」と緩めると、測定ではなく後付けの正当化になります。
3. 判断基準を個人の記憶に置いたまま外へ出さない：担当者が変わった途端に線が動いても、原因を「AIのばらつき」だと読み違えます。
4. 発散が要る工程まで出力形式を固める：企画案やキャッチコピーの案出しに厳しいテンプレートを課すと、案が似通い、揃えるべきでない工程まで均してしまいます。

4つとも、共通しているのは進行が止まらない点です。作業が回っている限り、間違った方向へ進んでいることに気づく合図が出ません。

だから、確かめる場所を先に置いておきます。次の項目は、着手前に自分で通しておくと、あとで戻る量が減ります。

• 指示文を、前提知識のない人に見せても同じ動きをするか確かめたか
• 実行のたびに渡す文脈（会話履歴・読み込むファイル）が同じか確かめたか
• 参照する資料の版やファイルを、指示文自体で指定したか
• 合否・採用の判断基準を、文書として外へ出したか
• N回試行を始める前に、合格ラインを決めたか
• 出力形式やセクション構成を、指示文かStructured Outputsで固定したか
• 出力後の自己点検チェックリストを用意したか
• やり直しの上限を先に決めたか
• 発散が要る工程にまで、固定の手段を課していないか

13よくある質問

14まとめ｜今日やる3つのこと

切り分けは、モデルからではなく自分側から始めました。測るときは、合格ラインを実行の前に置きました。そして抑える手立ては、つまみではなくプロンプトと運用の側にありました。