AIも間違いノートをつける: 過去の成績で確信度を測るXConf

言語モデルが今の推論だけを見るのではなく、過去の成績表を取り出して「この答えが正しい確率」を測るXConf。確信度の精度を上げながら、コストは自己無矛盾性(self-consistency)の10分の1に抑えた。
← 목록으로
온
온틀 리서치
2026년 10월 02일 更新 2026.10.16 読了 10分 閲覧 2

言語モデルが自分の答えをどこまで信じていいかを見極める、新しい方法が登場した。発想はシンプルだ。モデルがこれまで積み重ねてきた過去の経験(いわば成績表)を一緒に取り出して、「この答えが正しい確率」を測る。著者らはこの手法をXConf(eXperiential Confidence、経験的確信度)と呼ぶ。成果から言えば、九つのベンチマークのほとんどで、従来の手法より確信度を正確に当てながら、コストははるかに少なく済んだ。

この論文が解く問題

言語モデルを実際のサービスに載せるとき、必ずぶつかる問いがある。「この答えをそのまま出していいのか、人に引き継ぐべきか、やり直すべきか」。この判断の拠りどころになるのが確信度(confidence)の推定だ。モデルが「この答えは90%正しい」と言ったとき、実際に10回のうち9回は当たっていてはじめて、その数字を信じて自動化を任せられる。口にした確率と実際の正答率がこのように一致する性質を、較正(calibration、キャリブレーション)と呼ぶ。

較正がなぜ重要かは、外れたときを思い浮かべれば明らかだ。モデルが「90%確信」と言った答えが実際には半分しか当たらないなら、その数字を信じて回した自動化はまるごと誤作動したり、莫大なコスト損失につながったりする。確信度は単なる参考値ではなく、自動化の安全装置なのだ。

ところが、従来の確信度推定の手法はどれも同じ弱点を抱えている。いま進行中の推論一回だけを覗き込むという点だ。やり方は三つに分かれる。モデルに「これ、どれくらい確信してる?」と問い返すか、生成された文字の確率をスコア化するか、同じ質問を何度も解き直させて答えがどれだけ一致するかを見るか、である。三つ目がよく使われる自己無矛盾性(self-consistency)だが、10回解き直させれば生成コストも10倍かかる。

三つの方式すべてに欠けているのが、自分の履歴だ。試験会場で一問を解きながら「自分はこれを当てられただろうか?」を、その問題だけを睨んで判断する学生を思い浮かべればいい。肝心の決定的な情報 — 「自分はこの手のタイプで自信ありと言っておいて、よく外す」 — がすっぽり抜けている。人は経験を積むと、「このくらい確信しているときは、たいてい当たる」あるいは「こういうときに限って油断する」を知っている。XConfはまさにこの空白を埋める。

核心となるアイデア

XConfはモデルに個人の成績表を持たせ、新しい問題に出会ったときにその成績表を開いて見させる。まずどう動くのかを見てから、なぜ現実的なのかを押さえよう。

1. 動作原理: 記録し、取り出して見て、補正する

出発点は、経験を保存する方法だ。モデルは過去に解いた問題の一つひとつをエピソード(episode)として残す。ちょうど学生が間違いノートをつけるように、どんな問題で(課題)、そのとき何を考え(省察)、どれくらい自信があり(確信度)、結果はどうだったか(正誤)、最後に採点のあとで何を学んだか(教訓)を、一つの「経験」として書き留めておくのだ。「このタイプ、80%確信したのに外した、原因は条件を一つ見落とし」といった一行が積み重なって成績表になる。

新しい課題が入ってくると、二段階で動く。まず想起(Recall)の段階で、いまの課題と似たタイプで、かつ似た確信度で臨んだ過去のエピソードを取り出し、それらが実際に何パーセント当たっていたか(歴史的成功率)を読み取る。「以前これくらい自信ありと言ったとき、本当のところ何割当たっていたか?」をデータで確かめるのだ。続く省察(Reflect)の段階で、モデルはその記録を見ながら、自分が繰り返し犯す失敗のタイプに自ら名前をつけ、その履歴を反映して確信度を言い直す。たったいま出した答えへの素朴な自信ではなく、「自分はこういう状況で過大評価する癖があるから、低めに言おう」というように、自分の実績で補正された確信度が出てくる。

この構造は、見慣れたパラダイムをひねったものだ。検索拡張生成(RAG、外部知識を検索して答えに引き込む手法)が「知識」の外部記憶装置だとすれば、XConfは「判断」の外部記憶装置だ。引き込む対象が外の知識から自分の履歴に変わっただけで、検索して持ってきて使うという骨格は同じなのだが、この紙一重の違いが意味深い。AIが単に賢くなるのを超えて、自分の過去を振り返って自らを点検するメタ認知の段階に入りつつある、という兆しだからだ。

2. 実用面の強み: なぜ現実的か

動作原理から三つの強みが導かれる。第一に、形式を選ばない(format-general)。答えが数値でもコードでも自由記述でも、そのまま適用できる。第二に、モデルの内部を開けて見る必要がない。文字の確率値(ロジット)にアクセスしたり、重みを再学習させたりする工程がまったくないので、APIだけで接続する閉じた商用モデルにもそのまま載せられる。第三に、答えを一度生成したあとに短い省察呼び出しをもう一回するくらいなので、同じ質問を10回解き直す自己無矛盾性とは体格が違う。

結果と意味

評価は、推論・コーディング・マルチモーダルQA(画像と文章を一緒に見て答える問題)・インタラクティブエージェント(複数の段階にわたって道具を使いながら課題を解いていくAI)にまたがる9つのベンチマーク、そして三つの系統から選んだ四つのモデルで行われた。成果は三つの軸に分かれる。

まず判別力だ。正しい答えと間違った答えを確信度でどれだけうまく切り分けられるかを測るAUROC指標を見よう。一度で答える非エージェント課題は、6つのベンチマークに4つのモデル、つまり24通りの組み合わせで、10サンプルの自己無矛盾性と対決した。結果は21勝2分1敗で、24のうち23で上回るか互角だった。エージェント課題の3つのベンチマークでは、10回の再実行の代わりに別のベースラインと比較した。

次は較正誤差だ。口にした確率と実際の正答率のずれを測るECE(Expected Calibration Error)がはるかに低かった。「90%確信」が実際の90%により近づいた、という意味だ。

コストは、この記事の始まりと終わりをつなぐ箇所だ。XConfは上記の成果を、自己無矛盾性に比べて答えの生成回数10分の1でやってのけた。ただし、この「10分の1」は答えの生成回数だけを数えた値だ。過去を想起するには埋め込み(文章を数値ベクトルに変換して似たものを探す技術)と検索が必要で、そのコストが付録Lに別途明記されているため、API全体のコストがきっかり10分の1に落ちるわけではない。それでも、同じ質問を10回解き直す方式よりは全体として格段に効率的だ。

もっとも実戦的に響く結果は、選択的予測から出てくる。ここで注意すべきは、先の判別力・較正の成果は「確信度をうまく当てた」という話であって、答えそのものの正答率が上がったという意味ではない、という点だ。選択的予測は、このうまく当てた確信度をどこに使うのかを示してくれる。確信度がもっとも低い下位10%のエピソードについて答えを出さずに保留(abstain)したところ、実際に届けられた答えの成功率がエージェント課題で最大8.7ポイントまで上がった。自信のないものだけを選んで振るい落とすだけで、届ける品質が目に見えて良くなったのだ。何を出し、何を上位の段階に引き継ぎ、何をやり直すかを決める実務判断に直結する数字であり、とりわけ多段階で道具を使うエージェント課題で効果が際立った。

より少ないコストで確信度をよりうまく当てた、という点 — これが経験的確信度推定を、汎用的な確信度推定の次の候補へと押し上げる核心だ。

限界と残る問い

実際のプロダクトに載せる前に検討すべき構造的な限界がいくつかある。以下は要旨に数値で記された内容ではなく、手法の設計から導かれる問いだ。

  • コールドスタート: XConfは過去の成績表に頼る。経験がほとんどない初期状態や、まったく新しいタイプの課題では、取り出して見る記録が乏しい。
  • 類似性の定義: 「似た課題」「似た確信度」をどう判定するかが、想起の品質を左右する。この基準がずれると、見当違いの過去を引っ張ってきて誤って補正する危険がある。
  • 分布シフト: 過去の成功率で未来を予測するには、課題の性格がある程度安定していなければならない。環境や道具が変わって前提が揺らげば、歴史的成功率の信頼性も揺らぐ。
  • 記録管理コスト: 採点済みのエピソードを保存・検索するインフラ、事実上の経験ストアを別途維持しなければならない。この負担は、生成回数だけを比較した計算とは別物だ。

ONTLEの視点

ONTLEは、顧客プロジェクトごとにAIプロジェクトマネージャーを派遣するサービスだ。AI PMが人の代わりに判断し、仕事を引き継ぐなら、もっとも危険な瞬間は「間違っているのに自信満々で押し通す」ときだ。では、ONTLEのAI PMがXConfを搭載すると何が起きるだろうか。

顧客が外部システム連携を依頼し、AI PMが「これは半日あれば終わります」と答えようとする瞬間を描いてみよう。答えを出す前に、モデルは自分の成績表を開く。「似たように簡単に見えた連携作業で、自分は実際に何度スケジュールを守れただろう?」。過去に同じ大言を吐いては、しょっちゅう外していたなら、確信度を自ら低く見積もり、この件を自動処理ではなく人の担当者へ上げる(エスカレーション、つまり現場で曖昧な案件を上位の担当者に引き継ぐこと)。過去の記録照会 → 確信度の修正 → 人への引き継ぎという流れが、そのまま保留・エスカレーションの設計になる。曖昧なものだけ人へ、確実なものは自動で。

ちょうどONTLEのようなプロダクトは、すでにプロジェクト履歴と作業結果を蓄積している。XConfは、この履歴を確信度補正用の「経験ストア」として再活用しようという発想と地続きであり、ロジットアクセスも再学習も要らず、短い省察呼び出しを足すだけでいいという点は、商用モデルをAPIで接続して使うプロダクト環境とよく噛み合う。

ただし、論文のベンチマーク成果がそのままこのワークフローの保証になるわけではない。下位10%の保留を実際の業務自動化に適用するなら、先に挙げた限界がそのまま検証課題になる。成績表が十分に貯まっているか(コールドスタート)、課題の分布が安定しているか(分布シフト)、「似た課題」をきちんと判定できているか(類似性の基準)をまず整えてはじめて、保留の判断を信じて自動化を任せられる。それでも、「いま一度の推論ではなく、積み重ねた経験で確信を測る」という方向性は、信頼できる自動化を目指すプロダクトにとって明確な参照点だ。

XConfはモデルを新しく学習させる必要がありますか?

いいえ。重みの更新もロジットアクセスもなしで動作するため(原文§5.1基準)、APIだけでアクセスする閉じたモデルにも、追加学習なしですぐに適用できます。

自己無矛盾性より本当にコストが安いのですか?

答えの生成回数を10分の1に減らします。ただし過去を想起する埋め込み・検索のコストが加わるため(付録L)、API全体のコストがきっかり10分の1になるわけではありません。それでも、同じ質問を10回解き直す方式よりは効率的です。

参考資料