Claudeの回答が毎回違うのはなぜか — 非決定性の3つの発生源と対処

同じプロンプトを2回送ると、Claudeは違う答えを返すことがあります。これは不具合ではありません。語の選択がそもそも確率的であること、推論サービス側の計算が完全には固定されないこと、そしてエージェントでは行動の経路自体が分岐すること。ばらつきはこの3層で仕組みとして発生します。どの層から来ている揺れかを見分けると、抑えられるものと抑えられないものの区別がつきます。

3つの発生源を先に整理する

上から順に、応答の1文字ずつ・API呼び出し1回ごと・タスク1件ごと、と揺れのスケールが大きくなります。順に見ます。

発生源1: Claudeは次の語を確率で選んでいる

言語モデルは、次のトークン(語の断片。Claudeでは英語約3.5文字に相当)を1つに決めているわけではなく、候補の確率分布から選んでいます。文章は数百〜数千個のトークン選択の積み重ねなので、途中のどこか1箇所で2番手の候補が選ばれれば、そこから先は別の文章になります。このランダム性を制御するのがtemperatureです。高くすると多様で創造的な言い回しが増え、低くすると最も確からしい表現に寄った保守的な出力になります。

Messages APIではこの値を直接指定でき、既定値は1.0、範囲は0.0〜1.0です。公式リファレンスは、分析や選択式のタスクは0.0寄り、創作系のタスクは1.0寄りという使い分けを示しています。つまり既定のClaudeは「毎回同じ答えを返す」設定ではなく、表現の幅を持たせる側に振ってあります。同じ質問への回答が言い回しごと変わるのは、この設計の直接の帰結です。

ばらつき自体は欠陥ではありません。ブレインストーミングや文章の代替案出しは、この確率的な選択があって初めて機能します。問題になるのは、再現性を暗黙に期待した使い方と組み合わせたときだけです。

発生源2: temperatureを0にしても同一にはならない

では0.0にすれば毎回同じになるかというと、なりません。Messages APIのリファレンスには「temperatureを0.0にしても、結果は完全には決定的にならない」と明記されています。用語集はさらに踏み込んで、同一の入力でもAPI呼び出しごとに異なる出力になりうること、これがAnthropic自身の推論サービスでも、サードパーティーのクラウドプロバイダー経由でも当てはまることを記しています。

内部要因の詳細は公表されていませんが、一般にGPUでの並列計算は浮動小数点演算の順序やバッチの組まれ方で結果がごくわずかに揺れることが知られており、その微小な差が確率上位の候補が拮抗する場面で別のトークンを選ばせます。一度分岐すれば、そこから先の文は別の文章です。

実務上の含意ははっきりしています。「temperature 0なら出力は再現される」という前提で回帰テストや差分検知を組むと、いつか必ず壊れます。完全一致の比較はLLMの生の出力に直接張れません。

発生源3: エージェントは経路そのものが分岐する

Claude Codeのようなエージェントでは、揺れのスケールがさらに上がります。エージェントはプロンプトと途中で得た情報にもとづいて、どのツールをどの順で使うかを自分で決めながら、数十手のアクションを連鎖させます。最初に読むファイルの選択が1つ変わるだけで、以降の探索・編集・検証の全経路が変わります。1文字の揺れではなく、仕事の進め方ごと分岐するわけです。

Anthropicのエージェント評価ガイドも、エージェントの挙動は実行ごとに変わり、同じタスクがある回は成功して次の回は失敗することを前提として扱っています。加えてエージェントには「環境」という入力があります。作業ディレクトリの中身、gitの状態、残っているキャッシュ。同じプロンプトでも環境が違えば、モデルから見れば別のタスクです。

環境の影響は思わぬ形で出ます。同ガイドには、社内evalで前回の試行が残したgit履歴をClaudeが読んで課題を有利に解いてしまった、という実例が載っています。前の実行の痕跡が次の実行の入力になっていたわけです。だからエージェント評価では、試行ごとにクリーンな環境から始めることが信頼できる計測の条件とされています。これは評価に限らず、日々の運用で「昨日と同じ指示なのに違う動きをする」ときの点検項目でもあります。

再現性が要る場面の対処 — 固定できるものから固定する

揺れの層ごとに、使える手段と保証の強さが違います。

形式の固定に効くのがstructured outputsです。生成そのものをJSONスキーマで拘束する(constrained decoding)ため、パースに失敗する出力や必須フィールドの欠落がなくなります。応答本体だけでなく、strict: trueを付ければツール呼び出しの引数にも同じスキーマ保証をかけられるため、エージェントのツール入力が壊れて落ちる系のばらつきも塞げます。ただし保証されるのは形式であって内容ではなく、同じスキーマの中で違う値が返ることは普通にあります。また、安全上の拒否・max_tokensでの途中終了・enum値の大文字小文字という例外ではスキーマに一致しないことがあります。実装手順はstructured outputsでJSON出力を固定する方法にまとまっています。

内容側のばらつきには、プロンプトエンジニアリングの定石が効きます。公式ガイドは、出力形式を厳密に指定する、応答の書き出しをこちらで与える(prefill)、良い例を見せる、根拠となる文書を渡して回答をそこに接地させる、といった手段を挙げています。prefillはJSON出力形式のstructured outputsと併用できない点だけ注意が要ります。指示の組み立て方の基礎はClaudeプロンプトの書き方が扱っています。

そして完全な再現が必要な部分は、生成の外に出すのが確実です。一度生成した出力を保存して使い回し、LLMは「生成時」だけに関与させる。コードなら生成結果をコミットした瞬間に再現性の問題は消えます。再現性を生成のたびに求めるのではなく、生成を1回に閉じ込める発想です。

ばらつきは消すものではなく測るもの — pass@kとpass^k

エージェントの揺れは設定では消えないので、Anthropicの評価設計では計測の対象として扱われます。使われる指標は2つあります。pass@kは「k回試して少なくとも1回成功する確率」で、試行を増やすほど上がります。pass^kは「k回すべて成功する確率」で、試行を増やすほど下がります。1回あたりの成功率が75%のエージェントでも、3回連続で成功する確率は約42%まで落ちます。

どちらで測るかは用途で決まります。1回でも良い解が出ればよい探索的な仕事はpass@k、毎回確実に動いてほしい顧客向けエージェントはpass^kです。エージェントの信頼性は1回のデモでは測れません。複数回走らせて比率で語るのが正しい測り方です。指標の背景とeval設計の全体像はAIエージェントのEval設計の解説で詳しく読めます。

よくある質問

同じチャットで聞き直しても答えが変わるのはなぜですか

聞き直した時点で会話履歴が伸びており、モデルに渡る入力そのものが前回と違うからです。コンテキストウィンドウには過去のやり取りが入るため、「同じ質問」でも条件は同じではありません。そこにサンプリングの揺れが重なります。

temperatureを0にすれば毎回同じ回答になりますか

なりません。公式リファレンスと用語集の両方が、temperature 0でも完全には決定的にならないことを明記しています。これはAnthropicの推論サービスを直接使う場合でも、サードパーティーのクラウドプロバイダー経由でも同じです。

回答が毎回違うのは精度が低いということですか

別の性質です。ばらつきは確率的な生成の帰結で、誤りの多さとは独立しています。事実関係の答えが実行のたびに割れる場合は、根拠となる資料を渡して接地させるか、複数回実行して一致を確認する使い方が向いています。

複数回実行して答えを比べるのは有効ですか

用途によります。探索的な仕事なら、複数回生成して最も良い案を選ぶ使い方はpass@kの考え方そのもので、揺れを味方につける方法です。事実確認の用途なら、複数回の回答が一致するかを見ることで、揺れやすい箇所(=確信度の低い箇所)をあぶり出せます。ただし一致は正しさの証明ではないため、最終的な裏取りは出典側で行う必要があります。

Claude Codeで同じ指示なのに結果が違うのを減らせますか

環境要因は固定できます。クリーンな作業ディレクトリから始める、CIでは--bareフラグでhooksやMCPサーバーの自動探索を省いてマシン間の条件を揃える、が定石です。残る経路の揺れには、テストのような検証手段をタスクと一緒に渡す方法が効きます。経路が違っても、検証を通った状態という着地点は揃えられます。

まとめ — 揺れの層で対処を選ぶ

Claudeの回答が毎回違うのは、サンプリング・推論サービス側・エージェントの経路分岐という3層の重なりで、故障でも劣化でもありません。形式はstructured outputsで保証でき、内容の揺れはtemperatureとプロンプトで縮小でき、サービング側の非決定性は誰にも消せません。消せない揺れを前提に、完全一致が要る部分を生成の外へ出し、エージェントは複数回実行の成功率で評価する。この切り分けができれば、非決定性は管理可能な性質になります。