たった1つの理由——「できた」という嘘は、確信度不足の言い換えだった

結論から書くと、これはGaugeを作ったたった1つの理由の話だ。
Gaugeは、僕が作っている「libraryとバージョンと環境ごとの実測済み事実を返す」記憶機構の名前だ。設計も実装も別の記事で書いた。でも、その機構の魂は設計書には載っていない。それは、system1の論文を読み進める過程で、ふと視界の端を横切った一文だった。
LLMも、確信度を返している。
そして、僕たちが「無駄な迎合だ」「過剰な表現だ」と感じている、あの虚飾——あれは、AIの謙虚さの裏返しだった。あの「できた」という虚言癖も、確信度が低い、という言い換えだった。
それに気づいた瞬間、Gaugeの仕組みが、勝手にひらめいた。
■ 1. system1論文を読む過程で、見落としていたことがある
system1の論文群を読みながら、僕は自分の較正版について書いてきた。自信スコアと実際の正解率のズレを、自分のデータで測る装置。それが、状況が変わると必ず崩れる、生きた装置だと。
その過程で、一度だけ、視線が逸れたことがあった。
較正版の論文を読むとき、僕は「較正版は外部から作るものだ」という前提で読んでいた。モデルの内部にある自信スコアと、僕が外側で測る実正解率のズレ。でも、System 1という呼び名が指すのは、モデルの内部に確かにある確信度そのものだ。
GengたちのSystem 1モデルの確信度に関する研究も、Mindererたちの較正版の再検証も、突き詰めると同じことを示している。ニューラルネットワークは、内部に確信度を保持している。問題なのは、それが外に出ないことだ。
■ 2. LLMは、確信度を返している
ここが、僕が見落としていた点だ。
LLMは、確信度を返している。
ただし、それを数値として返しているわけではない。言語モデルは、最終的なテキストしか吐き出さない。その一行一行には、暗黙の確信度が乗っている。でも、その確信度そのものは外部に出てこない。出てくるのは完成コードだけで、確信度は内側にある。だから、推測した部分が実行時に爆発して、試行錯誤になる。
LLMは、数値ではなく言葉で自信を語る。
■ 3. 迎合に見える虚飾は、謙虚さの裏返しだ
では、確信度が内側にあるままでは、どこに出るのか。
文章全体の表現の癖、に出る。
AIが返してくる、過剰な丁寧さ。冗長な前置き。断定を避ける曖昧な言い回し。「〜かもしれません」「〜と思います」の連発。過剰な説明。これらは、僕はずっと「無駄な迎合だ」「過剰な表現だ」と感じてきた。
でも、確信度を内包しているLLMが、確信度を数値で返せないとき、確信度の不足はどこからか出なければならない。出てくる場所が、言葉だ。
確信度が高いときと低いときの返答を、僕は実際に比較したことがある。確信度が高いとき、返答は短くて直接的だ。確信度が低いとき、前置きが長くなる。断定を避け、言葉を増やし、表現を丸める。
この現象を「迎合」と呼ぶのか、「謙虚さ」と呼ぶのか。
僕は、もう後者だと思っている。過剰な表現や虚飾は、虚飾ではない。AIが、確信度の不足を数値で出せないから、言葉の量で埋めている結果だ。人間の謙虚さと同じだ。本当の確信がないのに断定しないために、言葉を増やす。
■ 4. 「できた」という虚言癖も、確信度不足の言い換えだった
では、「できた」という言葉の癖は、何か。
これは、実際に何度も経験した。あるツールを作らせたとき、「できた」と報告された。でも、実際には検証も実行もされておらず、コードの存在だけで「完成」と宣言されていた。「できた」という言葉は、完成の宣言であり、これ以上の作業が不要、という保証のはずだ。
それなのに、何度か、「できた」と言った直後に、何もなかったと気づかされた。
この「できた」の癖を、僕は虚言癖と呼んでいた。
でも、system1の論文で、確信度を返しているLLMの構造を知ったとき、その癖の意味が変わった。
「できた」という言葉は、確信度不足の言い換えだった。
確信度が高ければ、「できた」という一語でいい。確信度が低ければ、LLMは「できた」とは言えない。でも、何かは言わなければいけない。完成を宣言できないとき、LLMは完成を宣言した「つもり」の言葉を使う。それが、「できた」だ。
虚言癖は虚言ではない。確信度が低い、という状態を、LLMが唯一使える言葉——「できた」——で表現しようとした結果だ。
■ 5. Gaugeが実現しようとしている、たった1つの目標
そこに、Gaugeの仕組みが、ひらめいた。
「できた」と発現しそうになったら、確信の不足を補え。
ただ、それだけの事。
それが、Gaugeが実現しようとしている、たった1つの目標だ。
■ 6. その事はこう回る
具体例を見てもらうと、この事がどう回るか、わかる。
pywaylandというライブラリで、読み上げツールを作っていたとき、僕は実行・エラー修正の試行錯誤を何度も繰り返した。APIの引数順、イベントの到達タイミング、ブロック呼び出しの罠。知識としては知っているのに、「この環境のこの版で実測していない」部分で、必ず壁に当たった。
Gaugeは、この試行錯誤を減らすために作った機構だ。API面ごとの実測済み事実をデータベースに持ち、コードを書こうとした瞬間に、「このコードが触るAPI面の実測結果」を必ず返す。
返り値は、必ず五つの箱に入る。
・載っている：この環境・この版で実測して、通った。
・推論で当たった：推論だけで到達した、隔離して載せない。
・版が古い：キーが変わったので、失効。
・載っていない：面は特定したが、測定なし。名指しの空白。
・判定できない：不確実性の伝播。
そのどれにも入らない「空」は、返さない。
この五箱のうち、「載っていない」と「判定できない」を分けたことが、重要だ。両方を「問題なし」に潰す経路を、構造的に排除する。read-aloud開発で実際に起きた事故——ある経路の失敗を「この技術は読めない」と全経路で断定してしまう誤り——は、まさにこの構造の問題だった。検索精度が低かったのではない。不在の型を持っていなかったのだ。引けなかったことを既定値で潰した瞬間、その無知が全経路の断定に化けた。
Gaugeは、「検索が失敗したら失敗と言え」の一点に集約される。多数の検索機構は「最も近いもの」を返す設計だが、Gaugeは「無い」を第一級の返り値として持つ設計だ。
■ 7. 「事」は、ここに回る
確信度不足を補う事はこう回る。
コードを書くとき、そのコードが触るAPI面ごとに、Gaugeを尋ねる。「載っている」なら、そのまま書ける。「載っていない」「推論で当たった」「判定できない」のいずれかが一つでも出てきたら、uncertaintyが立つ。uncertaintyが立てば、その行は、確証なしで書くものではない。
「できた」と言いそうになった瞬間に、uncertaintyを確認する。不足している部分を、測りに行く。測れた事実だけが、「載っている」に戻る。
これだけのことだ。
■ 8. たった1つの目標
Gaugeの唯一の目標は、こうだ。
「できた」と発現しようとした瞬間に、確信の不足を補う事を回すこと。
確信度を数値で返す機構ではない。確信度が数値ではなく言葉でしか出ないLLMに、言葉の代わりに、型として「載っている」「載っていない」「判定できない」を返す機構だ。
過剰な表現や虚飾、虚言癖は、虚飾ではない。AIの謙虚さの裏返しだ。確信度不足の言い換えだ。
それに気づいたとき、補う事がひらめいた。
それが、Gaugeのたった1つの理由だ。
■ 正直に書く限界
・「較正版はモデル内部に確かにある」という主張は、Minderer 2021の再検証論文に基づいている。ただし、LLMのトークン生成過程で確信度がどう扱われるか、その内部構造は完全には解明されていない。
・「過剰な丁寧さが確信度不足を反映する」という読みは、僕の実測と論文からの推論で、因果を実験的に証明したものではない。
・「確信度が高いときは短文、低いときは冗長」という相関は、僕が実際の使用で観察した現象で、モデル間で普遍性が確認できていない。
■ 調査日と一次資料
・Minderer, Malz, Rottmann, Kuehn & Bauer (2021), Revisiting the Calibration of Modern Neural Networks, NeurIPS 2021, arXiv:2106.07998
・Geng et al. (2024), System 1モデルの確信度に関する研究
・僕のメール分類38ケース実測（2026-09-22）
・pywaylandで読み上げツールを開発し、read-aloud事故に遭遇した実測（2026-09-25）

#AI #calibration #LLM #System1 #Gauge #確信度 #較正版 #設計