決定モデル時代の「較正」
信頼度を型安全な動作へ変える

結論：確率は判断ではなく、契約の入力である

「自信がある」と「確率が正しい」は別

TypeSafe AI の Jev は Choice と Score の回答に、選択肢ごとの確率分布と confidence を返します。公式説明では、分布が一つの選択肢に集中するほど信頼度が高く、平らなほど低くなります。これは一件の回答の分布の形を要約した統計です。Noul は真である確率そのものを返し、別の confidence は持ちません。［TypeSafe Confidence］

一方、較正は集団についての性質です。「0.8」と答えた案件を十分に集めたとき、実際に約80%が正しいなら、その確率は較正されています。モデルが毎回答えに自信を持っていても、0.8の案件が実際には50%しか正しくなければ較正されていません。

最も危険なのは「高信頼の誤り」

Laya の公式モデルカードには、英語用チェックポイントがクメール語の入力で精度0.000、信頼度0.952を記録した例があります。モデルは読めない文字体系に対して、迷わず間違えました。公式 Router はそのため、推論前に文字体系と言語を検出し、多言語モデルへ送ります。［Laya model card］

これは重要な警告です。分布外入力では、信頼度ゲートだけでは守れません。 入力言語、長さ、スキーマ、欠損値、時点、対象領域などをモデルの前段で検証し、「このモデルが判断してよい入力か」を先に決める必要があります。較正は運用環境の分布が変われば崩れます。モデルを固定しても、顧客・商品・文章・攻撃手法が変われば再評価が必要です。

しきい値はモデルではなく、損失で決める

TypeSafe は高・中・低の3領域を出発点として、高信頼なら自動実行、中間なら確認や追加情報、低信頼なら実行せず人や別システムへ送る設計を示しています。同時に「しきい値は一つではない」と明記しています。破壊的操作は読み取り操作より高い値を要求すべきです。

実務では、しきい値 t は「モデルが何%正しいか」だけでなく、誤った自動実行の損失、見送った機会の損失、人手確認の費用を比較して決めます。

Signが保証する範囲

Signの役割を誤解してはいけません。Signはモデルの判断を正解にしません。保証するのは、どの型の回答を受け取り、どの条件で、どの分岐先だけが実行可能かです。モデルの確率は契約の入力になり、採否はコード側が決めます。

choice route { billing, technical, sales, other }
threshold read_only  # 0.72
threshold external_write # 0.94

p(route) < read_only       -> request_more_context
p(route) >= read_only      -> route_draft
p(route) < external_write  -> human_review
p(route) >= external_write -> signed_action

上の例で、同じモデルの同じ確率でも、下書き作成と外部送信では契約が異なります。確率が動作を直接呼ぶのではなく、型付き契約を通過した動作だけが呼ばれる。この一段が、デモと本番の境界です。

複雑な判断を一問に押し込まない

TypeSafe は「知識のある人が一秒でできる一つの判断」を一問にし、複数の要因がある場合は原子的な質問へ分解してコードで合成するよう勧めています。「この取引を承認すべきか」ではなく、本人確認、金額の異常、過去パターンとの一致、規約適合性を別々に聞き、重みと拒否条件をコードに置きます。質問を変えずに重みを監査できるからです。［TypeSafe Primitives］

本番導入の7点チェック

評価指標は精度だけでは足りない

精度は必要ですが、しきい値で動作を制御するシステムには不十分です。最低でも Brier score（確率予測全体の二乗誤差で、較正だけでなく識別にも依存）、ECE（信頼度帯ごとの予測と実績のずれ。ビン分割や多クラス定義に依存）、選択的精度（棄却した案件を除く自動処理部分の精度）、カバレッジ（自動処理できた割合）を一緒に見ます。

本番で最も重要なのは、精度と自動化率の交換条件です。信頼度が正答可能性を適切に順位づけている場合、しきい値を上げると受理部分の精度が改善する傾向があります。ただし分布外入力や誤較正では保証されず、棄却増による人手費用との交換条件を確認します。最適値はモデルのランキングではなく、業務上の損失関数で決まります。

較正は一度の設定ではなく、運用である

決定モデルの価値は、文章を短くしたことではありません。不確実性をコードが扱える値として返したことです。しかし、その値を安全な自動化へ変えるには、入力適格性、領域別の較正、リスク別しきい値、棄却、人へのエスカレーション、継続監視が必要です。

Signが目指すのは、確率を魔法の数字として扱わず、何を自動化し、何を自動化しないかを実行可能な契約として記述することです。決定モデルが「判断」を提供し、Signが「許可された動作」を定め、人が「責任」を引き受ける。この三者を混同しないことが、決定モデル時代の安全設計になります。