LLM Confidence Score：信頼する前にキャリブレーションする

LLM confidence score は、何を予測するのかを定義し、測定プロトコルを固定し、自分のタスクのラベル付き結果に対してテストした後にのみ役立ちます。自己申告の「90%」、token log probability、10サンプル中9つの回答が一致することは、3つの異なるシグナルです。どれも、回答が正しい確率が普遍的に0.9であることを示すものではありません。

対象読者: 中級者 — LLM に回答、エスカレーション、または棄権をさせる必要があるプロダクトエンジニア、データチーム、テクニカルリード。

生の数値は意思決定ではなく、特徴量として扱いましょう。ホールドアウトセットでキャリブレーションし、低スコアの回答を拒否したときにエラーがどう変化するかを確認し、金銭を動かしたり、データを公開したり、本番状態を変更したりする可能性のあるアクションには、決定論的な制御を設けてください。

LLM confidence score は何を測定するのか？

LLM confidence score は、モデル出力の信頼性を順位付け、または推定するための数値シグナルです。その意味は、どのように生成されたかによって異なります。

スコアがキャリブレーションされた確率として機能するには、0.8を割り当てられた出力が、同じ種類の作業で約80%の確率で正しくなければなりません。この主張には、次の4つの詳細が必要です。

これらの詳細のいずれか1つを取り除くと、「0.8の信頼度」は曖昧になります。モデルがその表現をもっともらしいと判断したこと、同じ回答を一貫して繰り返したこと、数値を出力する指示に従ったこと、または代替案よりも1つの回答を上位に順位付けしたことを意味している可能性があります。これらの特性は正しさと相関することがあります。しかし、それ自体が正しさではありません。

キャリブレーションは、識別性能とも異なります。正しい回答が通常、誤った回答より上位に順位付けされる場合、そのスコアは優れた識別性能を持ちます。数値が観測された頻度と一致する場合、そのスコアは優れたキャリブレーションを持ちます。システムは順位付けには有用でもパーセンテージが間違っていることがあり、逆に平均的には妥当なキャリブレーションを示していても、正誤を分離できないことがあります。

一般に confidence と呼ばれる3つのシグナル

どれを選ぶかはエンジニアリング上の判断です。組み合わせることで役立つ場合もありますが、アンサンブルであっても対象タスクでの評価が必要です。

言語化された confidence は引き出された回答である

最も簡単な方法は、次のように尋ねることです。

text Return your answer and the probability that it is correct from 0 to 1.

これはほぼすべてのモデルで機能します。一方で、confidence の値も生成の一部になります。プロンプトの文言、回答スケール、提供されたコンテキスト、そしてモデル自身が回答を生成したかどうかによって、結果は変わります。

2026年の研究では、4つの question-answering ベンチマークを対象に、3つのオープンな7–8B base/instruction-tuned model family がテストされました。研究者は verbal-confidence prompt を固定したまま、どの回答を採点するか、どの回答トークンが token score を提供するか、そしてそれらのトークンの前にどのコンテキストを置くかを変更しました。conditioning context の変更は、calibration estimator の変更よりも verbal と token のキャリブレーション比較に大きな影響を与え、ECE と Brier-score の両方の比較において、12の instruction-tuned 設定のうち9つで、どちらのシグナルが優れて見えるかを逆転させました。モデルが提供された回答を採点した場合、もっともらしい誤答は、提供された正答とほぼ同じ verbal confidence を受け取りました。そのため著者らは、両方のシグナルを不確実性の直接的な読み出しではなく、プロトコルに依存する行動測定として説明しています（Kim and Kang, 2026）。

この結果は、すべての verbal score が役に立たないことを証明するものではありません。「confidence について正直になれ」といったプロンプトが、キャリブレーションセットの代わりにはならない理由を示しています。

Token logprobs は次のトークンの尤度を測定する

Log probability は、モデルの条件付き生成分布において、あるトークンがどの程度ありそうだったかを記録します。OpenAI のドキュメントでは、直前のコンテキストを条件とした特定位置のトークンの確率として定義されており、系列の log probability はスコアリングや順位付けのために合計できます（OpenAI Cookbook）。Google の GenerateContent response でも、選択した API とモデルが対応している場合、候補の平均 log probability とトークン単位の logprob 結果が公開されます（Gemini API reference）。

これは `approve` と `reject` のようなクローズドな選択肢では有用です。許可されたラベルに割り当てられた確率質量を収集し、そのスコアをキャリブレーションできます。長い自由記述の回答を解釈するのは、はるかに困難です。トークン化、回答の長さ、言い換え、条件付けに使うプロンプトが、すべて系列尤度に影響します。

流暢な誤った記述が高い尤度を持つこともあります。正しいが珍しい名前が低い尤度になることもあります。このスコアが答えるのは「このコンテキストで、このトークン系列はどの程度予想されていたか？」です。「その主張は真実か？」に自動的に答えるものではありません。

反復サンプリングは一致度を測定する

モデルから複数回サンプリングすると、ブラックボックスの一貫性シグナルが得られます。10個の回答のうち8つが同じ回答を表現していれば、経験的な一致度スコアは0.8です。自由記述の回答では通常、言い換えを同じ回答として数えるために意味的クラスタリングが必要です。

このシグナルは、単一の自己申告より多くの情報を持つことがありますが、2つのコストがあります。第一に、バッチ処理、キャッシュ、短いプロンプトによって計算が変わる前は、10回の生成におよそ10倍の出力呼び出しが必要です。第二に、モデルが同じ誤解を繰り返すと、一致度が高くても間違っている可能性があります。

最近の研究は、これらの両方を示しています。2026年7月の論文では、短い factual および multi-hop question answering において、verbal confidence、logit-based verifier、SliCK と呼ばれる sampling-based method を比較しました。その設定では、SliCK は他の2つの手法より低い calibration error と、正答と誤答をより良く順位付けする性能を達成しました。それでも、評価されたケースの31%で entailment-based probability consistency test に違反しました。この研究は、LLM judge による semantic clustering、短答ベンチマーク、1つの主要モデルと小規模な cross-model subset、そして sampling frequency が belief を反映するという仮定に依存しています（Matta, Naphade, and Zou, 2026）。

実務上の解釈は、「sampling が confidence を解決する」というものより限定的です。一致度は有用な生のシグナルです。しかし、結果と照合する必要があるシグナルであることに変わりはありません。

*本番の閾値は、モデル出力の直後ではなく、タスク固有のラベル付けとキャリブレーションチェックの後に置くものです。*

もっともらしい confidence の数値が誤解を招く理由

最近の3つの結果は、LLM の回答の横に表示されたパーセンテージをチームがどう読むべきかを変えるはずです。

Accuracy と calibration は別々に変化する

ConfidenceBench は、空間推論、高精度数学、単語検索、不可知な質問を対象とする、200問の非公開英語 multiple-choice question に対して、15の frontier model がプロンプトで生成した確率を評価しました。各モデルはセットに3回回答しました。ベンチマークでは、報告された確率と二値の結果との二乗距離を罰する Brier score が使われました。

キャリブレーションによるモデル順位は、accuracy による順位を単純に再現しませんでした。著者らは、最良の Brier score が0.103であり、一部の評価システムは、キャリブレーションされた4択ランダムベースラインの0.1875より悪いスコアだったと報告しています。このベンチマークは意図的に小規模で、非公開、英語のみ、multiple-choice です。verbal score は instruction following と prompt framing を反映している可能性があるため、数値を長文や multi-turn の作業に一般化すべきではありません（ffrench-Constant et al., 2026）。

キャリブレーションは直接測定してください。モデル全体のベンチマーク accuracy から推測してはいけません。

測定プロトコルによって結論が変わる

スコアは特定のパイプラインに紐づいています。チームがプロンプト、モデルスナップショット、回答形式、候補ラベル、コンテキストウィンドウ、temperature、または logprob aggregation を変更した場合、測定器自体を変更したことになります。

すべての評価結果とともに、これらの選択を記録してください。生の code-agent activity metrics も、信頼性について何かを示す前に、システムと評価のコンテキストを必要とします。プロンプトまたはモデルが変わった場合、再キャリブレーションは任意の後処理ではなく、リリースチェックです。

キャリブレーションされたスコアでもスライスで失敗する

平均値は、ある言語、プロダクト、顧客セグメント、文書タイプ、または回答の長さにおける失敗を隠すことがあります。サポート分類器では、一般的な請求に関する質問がテストセットの大半を占めるため、全体としてはキャリブレーションされているように見えても、まれなセキュリティチケットでは依然として過信する可能性があります。

結論を支えるのに十分な例数があるスライスを、必ず確認してください。サンプルが少ない場合は、ノイズの多い割合を事実として扱わず、不確実性を報告しましょう。

再現可能な LLM confidence calibration workflow

以下のワークフローは意図的に小規模です。より大きな不確実性フレームワークを導入する前に実行できます。

1. イベントとアクションを定義する

次のテンプレートを完成させる1文を書いてください。

例：

「回答が良い」といったイベントは避けてください。一貫してラベル付けできません。

不可逆な影響を持つアクションでは、confidence が認可の代わりになってはいけません。モデルは経路の選択を支援できますが、AI agent permissions は、許可されたリソース、引数、承認ルール、receipt を引き続き強制すべきです。

2. タスク固有のホールドアウトセットを構築する

プロンプトやキャリブレーションマッピングの調整に使っていない、代表的な入力を収集します。次を含めてください。

可能な場合は、決定論的な verifier で正しさをラベル付けします。主観的なタスクでは、文書化された rubric と adjudication を使います。confidence score は、その結果ラベル以上に説得力を持つことはできません。

まずは大まかな miscalibration を明らかにするのに十分なデータから始め、その後、重要なスライスと閾値の周辺を拡張します。小さなベンチマークは探索の指針にはなりますが、高リスクな本番閾値を正当化することはできません。

3. プロトコルを変えずに生のシグナルを取得する

次を保存します。

評価前に丸めないでください。モデルが `0.7`、`0.8`、`0.9` だけを出力する場合、それを精密な確率測定として提示するのではなく、3つの粗いバケットとして評価する必要があります。

4. Brier score と reliability table を計算する

二値の正しさに対する Brier score は次のとおりです。

text mean((confidence - outcome)²)

低いほど良いですが、その数値にはベースラインと比較可能なデータセットが必要です。reliability table を使うと、誤差を確認しやすくなります。似たスコアをグループ化し、各グループの平均スコアと観測された accuracy を比較します。

この依存関係のない Python script は、CSV ファイルから `id,score,correct` を読み取ります。

python import csv

with open("predictions.csv", newline="") as source: rows = [ (float(row["score"]), int(row["correct"])) for row in csv.DictReader(source) ]

if not rows: raise SystemExit("predictions.csv has no rows")

brier = sum((score - correct) ** 2 for score, correct in rows) / len(rows) print(f"Brier score: {brier:.4f}")

bin_count = 10 bins = [[] for _ in range(bin_count)]

for score, correct in rows: if not 0 <= score <= 1 or correct not in (0, 1): raise ValueError("score must be 0..1 and correct must be 0 or 1") index = min(int(score * bin_count), bin_count - 1) bins[index].append((score, correct))

print("range,count,mean_score,accuracy,gap") for index, values in enumerate(bins): if not values: continue mean_score = sum(score for score, _ in values) / len(values) accuracy = sum(correct for _, correct in values) / len(values) lower = index / bin_count upper = (index + 1) / bin_count print( f"{lower:.1f}-{upper:.1f},{len(values)}," f"{mean_score:.3f},{accuracy:.3f},{mean_score - accuracy:+.3f}" )

この表は記述的なものです。特に小規模なセットでは、ビンの境界によって ECE-style summary が変わることがあります。1つのグラフだけを最適化するのではなく、Brier score、reliability view、アクションに焦点を当てた metric を組み合わせて使いましょう。

5. リスクとカバレッジから閾値を選ぶ

0.8という閾値に普遍的な意味はありません。候補となる各閾値以上の出力だけをシステムが受け入れた場合に何が起きるかを評価します。

python print("threshold,coverage,accepted_accuracy") for threshold in (0.5, 0.6, 0.7, 0.8, 0.9): accepted = [ correct for score, correct in rows if score >= threshold ] coverage = len(accepted) / len(rows) accuracy = sum(accepted) / len(accepted) if accepted else float("nan") print(f"{threshold:.1f},{coverage:.3f},{accuracy:.3f}")

これは基本的な risk–coverage view を作成します。閾値を上げると、受け入れたケースのエラーは減る可能性がありますが、同時に fallback handling に送られる作業が増えます。false acceptance、false rejection、review、latency、user harm のコストから閾値を選んでください。

プロダクトが対応している場合は、少なくとも次の3つの結果を使います。

6. ドリフトとプロトコル変更をテストする

次の変更後にはホールドアウトを実行します。

反復サンプリングと深い reasoning には、追加の計算コストもかかります。トレードオフを評価に含め、more reasoning tokens は常に購入する価値があると決めつけず、エラー削減と latency、token cost を比較してください。

どの confidence method を使うべきか？

オープンソースの library は実装作業を減らせます。たとえば UQLM は、black-box consistency、white-box token-probability、judge、ensemble、long-text scorer を提供します。そのドキュメントでは latency とアクセスのトレードオフも明確にされています。consistency method にはより多くの呼び出しが必要で、white-box method には logprobs が必要です（UQLM documentation）。repository は2026年7月にもリリースを受け取っており、v0.6.4 の修正が含まれています。これは lifetime stars だけよりも強いメンテナンスのシグナルです（UQLM v0.6.4）。

library は estimator を提供します。しかし、閾値を正当化するためのラベル、タスク定義、リスク許容度、本番モニタリングを提供するものではありません。

現在の研究が確立していないこと

引用した研究は、すべての LLM application において1つの手法が勝つことを証明していません。

研究は候補となるシグナルを特定できます。実際に実行する作業で、完全なシステムを検証してください。

よくある質問

LLM confidence score は正確ですか？

正しさと相関することはありますが、accuracy はモデル、タスク、スコアリング手法、プロンプト、評価分布に依存します。キャリブレーションされていないスコアは、順位付けの特徴量として扱いましょう。確率として解釈する前に、ラベル付き結果に対してテストしてください。

Token logprobs は confidence と同じですか？

いいえ。Token logprob は、コンテキストを条件としたトークンの条件付き尤度です。特に closed-label task では confidence estimate を支えることがありますが、自由記述の回答が事実として正しい確率を自動的に示すものではありません。

どの LLM confidence threshold を使うべきですか？

普遍的な閾値はありません。誤った受け入れ、手動レビュー、棄権、automation の取りこぼしのコストを反映した、ホールドアウトによる risk–coverage analysis から選んでください。モデル、プロンプト、またはデータ分布が変わった後には再検証します。

Claim checks

Sources