較正 · 信頼度 · エビデンス

判断モデルの較正:すべてのしきい値が暗黙に仮定している性質

判断モデルをどこまで自動化できるかは、信頼度をどこまで信頼できるかで決まります。較正と ECE の測定口順、当サイトのベンチマークによる検証可能な数値、判断モデルの信頼度を疑う 4 つの公開文献の要約、そして較正セットから監査付きレーンまでの 5 ステップをまとめました。

結論から

較正とは、モデルが申告する信頼度と実際の正解率の整合です。0.80 と申告した予測をすべて集めると、正解率はその 80% 近くにあるべきです。これはリライアビリティ図から読み取り、期待較正誤差(ECE)という 1 つの数値に要約します。較正されていない信頼度は自動化のゲートになりません。「0.85 以上は自動実行」が成立するのは、0.85 が実際に約 85% の正解率を意味するときだけです。2026 年 10 月に公開された 57 万 5000 回の有料 API 呼び出し監査では、あるホスト型判断モデルが、正解率 1% の答えられない設問で 32〜36% の信頼度を申告していたと報告されています。しかも再較正では直りませんでした。較正はスペック表の性質ではなく、自分のラベルで、モデルごとに測り、ワークロードのドリフトに合わせて検証し直すものです。

本ページの第三者数値は、いずれも名前の明らかな公開文献からの引用です(Synthpop.AI と Red Hat Developers は 10 月 2 日、Cloudflare の公式ブログは 10 月 1 日、DoubtBench は 10 月 4 日、anth.us は 10 月 1 日。いずれも 2026 年)。ベンダー公表のベンチマーク数値は「ベンダー計測」と明記し、当サイトは独立検証していません。当サイト自身の数値は、ベンチマークページに公開している 3 つの再現可能なテストスライスによるものです。

較正が測っているもの

予測は「答え」と「答えに添えられた数値」の 2 つでできています。較正が問題にするのは数値のほうです。申告された信頼度が経験的な正解率と一致するとき、モデルは較正されていると言います。0.70 と申告した予測をすべて集めて採点すると、約 70% が正解になっている状態です。標準的な道具はリライアビリティ図です。申告信頼度で予測をビン分けし、各ビンの実測正解率を対角線と並べて描き、2 本の線の差を 1 つの数値に圧縮したものが期待較正誤差(ECE)——ベンチマーク界における誠実さの指標です。

型付き判断モデル——ソフトウェアロジックの前に置く Choice / Score / Noul プリミティブ層——にとって、較正は飾りではなく、下流のすべてのパターンの前提条件です。Noul の yes/no 確率は注文を通すかを決め、Choice の信頼度はチケットを自動振り分けにするか人によるレビュー待ちにするかを決め、Score はコンテンツを出すかを決めます。3 つの下流パターンはいずれも、信頼度を確率として消費します。0.9 が「10 回中 9 回」を意味しないなら、その上に積まれた梯子——しきい値、レーン、フォールバックチェーン、監査記録——は全部飾りです。

失敗モード 1:自信満々に間違える

自信過剰なモデルは、半分しか正解できない案件に 0.95 を付けます。設定したしきい値がみんなゴミを自動レーンに入れ、監査ログは「そのときは確実に見えた誤り」で埋まっていきます。これが Synthpop 監査が知識の境界で記録した失敗です。次のセクションで扱います。

失敗モード 2:較正はされているが、控えめすぎる

自信過少なモデルは安全ですが高くつきます。正解に 0.55 しか付けないので、全部がレビュー待ちになり、自動化率はゼロ方向へ崩れます。ECE は両方向を対称に罰します。求めているのは謙虚な信頼度ではなく、判断に価格を付けられる信頼度です。

主張ではなく実測:検証可能な数字

当サイトの公開スライスは、ECE を Macro F1 やテールレイテンシと並べて報告しています。下のサポート振り分けスライスは、スキーマを凍結した 204 件の人手ラベル付きケース。3 スライス合計 654 件で、混同行列も再現スクリプトも公開しています。

ECE — サポート振り分けスライス

0.048

実測の誠実さ誤差、N = 204

Macro F1

78.4%

4 キュー全体でバランス

P95 レイテンシ

410 ms

同時実行負荷下

0.85 ゲートでの適合率

94.2%

トラフィックの 78.0% を自動振り分け

しきい値曲線こそ、較正がお金に変わる場所です。信頼度 ≥ 0.85 ではスライスは適合率 94.2% でトラフィックの 78.0% を自動振り分け、0.65〜0.85 の帯(16.5%)は人によるワンクリック確認へ、0.65 未満(5.5%)は決して自動化しません。較正されていないモデルでは、この 3 レーンは絵空事です。数字が成立するのは、信頼度が成立しているからです。

スライス外のスケールとして。独立 49 タスクベンチマーク(49 タスク・869 ケース。第三者によるもので、当サイトのものではありません)は、ホスト型 Jev に macro accuracy 0.966、最強のオープンモデルに約 0.704 を付けています。軸が違う点には注意してください。あのリーダーボードは較正ではなく精度を測っています。だからこそ当サイトは、単一のスコアボードではなく、スライスごとに ECE を公開しているのです。

完全な方法論・混同行列・再現スクリプトは当サイトのベンチマークページで

信頼度をめぐる論争:4 つの公開検証

2026 年 10 月の最初の週、4 つの独立した公開物が判断モデルの信頼度を検証の俎上に載せました。1 つの監査、1 つの横断ベンチマーク、較正を売りに賭けたベンダー、そして人間の意見分裂を問うベンチマーク。以下、出典と各家自身の留保付きで要約します。

synthpop.ai · 監査 · 2026-10-02

Synthpop.AI:57 万 5000 回の呼び出し監査

Jev 1.13.0 に対する 57 万 5000 回の有料 API 呼び出し(約 11.5 億トークン、48 ドル)の監査です。馴染みのある領域ではモデルは良好に較正されていました。自己申告 0.90 以上の回答に絞ると正解率 99.75%、ECE は 0.031。失敗は知識の境界にありました。正解率 1% の答えられない設問でも、モデルは 32〜36% の信頼度を申告し続けた。公平なサイコロの設問では、720 通りの選択肢の並べ替えすべてで「one」に平均 0.80 を賭けた。知識カットオフを超えると、正解率はコイントス(51%)まで落ちたのに、信頼度は 82% まで上がりました。温度スケーリングも Platt 再較正も修復できず、24 ポイントの差が残りました。監査の言葉を借りれば、数値そのものがドリフトの信号を運んでいないからです。同じ週、anth.us は「The OpenAI Decisions API needs a confidence you can trust」で、OpenAI のプレビューにも同型の問題があると指摘しています。

developers.redhat.com · ベンチマーク · 2026-10-02

Red Hat:判断モデル対クラシック分類器

Red Hat のエンジニアリング ベンチマークは、4 つのパラダイム——フロンティア LLM、判断モデル、ファインチューニング分類器、LLM-as-judge——で 9 つのガードレール課題を実行しました。判断モデルは勝てませんでした。プロンプトインジェクションでは 35B のオープン LLM が 89.31%、CPU 上の deberta-v3 分類器が 89.01%・54.1ms、対する Jev は 86.35%・348.1ms。コンテンツ安全性では Jev が 86.20% で首位だった一方、判断モデル陣営の Laya は 57.87% まで落ちました。著者らの結論——判断モデルはまだ、LLM-as-judge やクラシック分類器に対する「より速く、安く、正確に」を実現できていない——には正直な留保が付いています(遠隔 API には大西洋横断のレイテンシが乗る、ポリシーはモデルごとに調整していない)。判断モデルと分類器を比較しに来た方への現時点の答えは、課題ごとに、公開されたガードレールの条件下で、現時点では引き分け、です。

blog.cloudflare.com · ベンダー計測 · 2026-10-01

Cloudflare Clef:較正を売りにする

Cloudflare はオープンウェイトの Clef と Clef-flash でカテゴリに参入し、さらに本ページの主題そのものの名前を冠したファインチューニング サービスを出しました。RLCD——Reinforcement Learning for Calibrated Decisions です。公表ベンチマークでは Clef-flash が BFCL 98.76(対 Jev 95.75)、レイテンシ 38.8ms(対 524.1ms)。これらはベンダー公表値——ローンチ週に自分の試験を自分で採点した値——であり、当サイトは独立検証していません。それより構造的な信号のほうが重要です。このカテゴリの最新で最も大きな製品主張が較正そのものになった。つまり、このセクションの論争はベンダー層にまで届いている、ということです。

Show HN · ベンチマーク · 2026-10-04

DoubtBench:人間が意見を分けるとき、モデルは知っているか

2026 年 10 月 4 日公開の DoubtBench は、別の問いを立てます。人間のあいだで正解について意見が分かれる項目で、モデルの信頼度はそもそも何を意味すべきなのか、と。真値が争われている項目で、自信満々の単一回答は誤った形状です。不確実性は世界の側にあり、モデルの欠陥ではありません。較正監査と横断ベンチマークに続く批判線の 3 つ目であり、その狙いはすべてのしきい値の足元にある仮定——入力ごとに正解が 1 つに決まっている——に向いています。

Jev の信頼度はどこから来るか——そして各ベンダーの答え

チャットモデルが「少し自信がありません」と言うとき、それは確率についての生成テキストです。すべての出力に使うのと同じチャネルで、自分自身を報告しています。型付き判断モデルの信頼度は構造的に作られます。答えは宣言した決定契約の固定選択肢から 1 つ、信頼度は 1 回の順伝播で宣言済み全選択肢に付けられた並列スコアです。はぐらかすための自由文チャネルはなく、プロンプトで操作できる自己申告もありません。これは数値が較正済みという意味ではありません——上の Synthpop 監査は、まさにこのアーキテクチャに対して行われたものです。しかし検査可能にはなっています。宣言済み選択肢ごとに 1 つの数値、スキーマを凍結すれば再現できる。それが、下のワークフローのステップ 1〜4 が消費するものです。

ベンダーは 2 つの軸で答えました。TypeSafe は Jev 1.13 の 6 つの失敗モードをドキュメント化し、ホスト型モデルを「信頼度 90% は 10 回中 9 回」に較正していると説明します。一方、独立のメール実測では現実はもう少し雑で、同じ較正チャート上で Jev の ECE は 0.134、claude-haiku-4.5 は 0.097 でした。この内容は「Jev をいつ使うか」ガイドで詳しく扱っています。Cloudflare の答えは RLCD です。事後測定ではなく、訓練中に較正を強制する。どちらも動く標的についての主張です。モデルのバージョンは変わり、較正の数値は測定したその正確なバージョンについてしか真ではありません。本ページの信頼度数値は、当サイトのものも含めて、自分のラベルで検証し直すべき仮説として扱ってください。

較正からしきい値までの 5 ステップ

ホスト型の判断 API でもセルフホストのエンコーダでも、手順は同じです。ステップ 1〜4 で測り、ステップ 5 で測定をレーンに変えます。

  1. 01

    較正セットを作る

    自分のワークロードから 200〜500 件のラベル付きケースをホールドアウトします。どのベンチマークとも同じ金標準の規律です。複数回の人手ラベリング、凍結した判定基準、正解に揺れのない境界ケース。完全に分けておくこと。訓練分布の上で採点すると、較正は実態より良く見えます。

  2. 02

    予測を走らせ、全部記録する

    各ケースを送り、出力をすべて記録します。選ばれた選択肢、全選択肢の確率、申告信頼度、レイテンシ、モデル バージョン。派生値ではなく生の値を記録すること。あとでビン分けをやり直すとき、API に二重課金されずに済みます。

  3. 03

    リライアビリティ図を描く

    申告信頼度で予測をビン分けし(慣例は 10 等分)、各ビンの実測正解率を対角線と並べて描きます。対角線より下のビンは自信過剰、上は自信過少。図形の形が、そもそも修正可能かどうかを教えてくれます。答えられない設問での 32% のフラットな線は、温度スケーリングで直る類のものではありません。

  4. 04

    ECE を算出し、精度と並べて報告する

    ECE は、ビンごとの「信頼度と正解率の差」をビンのサンプル数で重み付けして平均したものです。Macro F1 の隣に掲載し、決して置き換えにしないこと。較正は良いのに精度が低いモデル(自分が推しているときを知っている)も、精度は高いのに較正が壊れているモデル(正解の理由を価格付けできない)も存在します。当サイトのスライスが両方を公表しているのは、まさにそのためです。

  5. 05

    曲線をレーンに変え、監査する

    しきい値は、図が信頼度の実在を裏付ける位置にだけ置きます。最上位ゲートの上は自動実行、中間帯は人間の確認、下限の下は決して自動化しない。そして、ゲートを通った判断を信頼度ごと証拠として記録し、モデルが変わったら CI でリプレイします。

判断モデルの較正:よくある質問

判断モデルの較正とは何ですか?

較正とは、モデルが申告する信頼度と実際の正解率の統計的な整合です。70% の信頼度を申告した予測すべてを集めたとき、正解率が約 70% に乗っていれば、そのモデルは較正されています。型付きの選択肢と確率を返す判断モデルにとって、較正はしきい値が意味を持つための前提です。「0.85 以上は自動化」は、0.85 が自分のラベル上で実際に約 85% の正解率に対応してきたときにしか成立しない、ワークロードの将来についての主張です。

ECE(期待較正誤差)はどう計算しますか?

すべての予測を信頼度ビンに分け(慣例は 10 ビン)、各ビン内の実測正解率と平均申告信頼度の差を求め、各ビンの予測数の割合で重み付けして平均します。0.9 と言えば必ず正解、0.4 と言えば必ず不正解というモデルは、全体の精度が平凡でも ECE はほぼゼロです。ECE は能力ではなく誠実さを測る指標だからです。必ずリライアビリティ図と並べて読んでください。同じ ECE の 2 モデルが、片方は系統的な自信過剰、もう片方は自信過少と、正反対の失敗をすることがあります。

信頼度が高ければ回答は信頼できますか?

それ単体では、いいえ。Synthpop 監査が最もきれいな反例です。正解率 1% の答えられない設問で、モデルはそれでも 32〜36% の信頼度を報告し、知識カットオフ後は正解率がコイントスまで落ちたのに信頼度は 82% に上がりました。高い信頼度は主張であって証拠ではありません。自分のラベル付きワークロードで、その信頼度水準が実際にどの程度正解してきたかを測って初めて証拠になります。それが、本ページの 5 ステップ ワークフローが生み出すものです。

自分のモデルを較正するには?

ワークロードからホールドアウトのラベル付きセットを凍結し、モデルに通して全確率を記録し、リライアビリティ図を描き、ECE を算出します。そのうえで、曲線が誠実な位置にだけ自動/レビュー/人間のみのしきい値を置き、四半期ごと、またはモデル バージョンやトラフィック構成が変わったときに検証し直します。図が温度スケーリング型の系統的な歪みを示すなら、較正セット上でのスケーリング フィットが役立ちます。答えられない設問での高信頼回答——前述の監査の失敗——であれば、事後の再較正では直りません。そういう設問を別のプロセスへ回すしかありません。

Jev の信頼度はどこから来ますか?

モデルが自分についてコメントしたものではありません。Jev の呼び出しは、宣言した選択肢から選ばれた型付きの答えと、1 回のパスで付けられた全選択肢の並列スコアを返します。信頼度は決定契約の構造的な出力であり、生成された文章ではありません。スキーマを凍結すれば検査も再現もできる——当サイトのベンチマークがスライスごとに ECE を公表できる理由です。ただし監査が免除されるわけではありません。公開された Synthpop の較正監査は、まさにこのアーキテクチャに対して行われ、知識の境界で高信頼の失敗を確認しました。

較正と精度の違いは何ですか?

精度はモデルがどのくらい正解するか。較正は、その信頼度が「いつ正解するか」について真実を語っているか。95% の精度で較正が壊れているモデル(すべての誤りに 0.99 の印)も、70% の精度でほぼ完璧に較正されたモデル(推っているときを確実に自覚している)も存在します。自動化には 2 番目の性質が、1 番目と同等以上に必要です。しきい値もフォールバック レーンも監査証拠も、精度ではなく信頼度の数値の上に築かれるからです。