Jevはサイコロを振らない｜「較正された確率」の意外な落とし穴

Jevは、文章を生成せずに、選択や真偽判定などの「判断」を確率とともに返す、TypeSafe AIの判断特化型モデルだ。速度とコストが魅力的で、人々の発想を刺激した。優れたプロダクトだと思う。

ただ、最近の熱狂を見ていると、何でもJevでいけるかのような話になっている。Jevは「システム1（直感的・即時の判断）」に特化した製品で、熟考を省くことで速さと安さを得ている。使える場面はある程度限定的なはずだ。システム1の範囲でも、判断を確率つきで返すだけならLLMのlogitを見れば足りるのでは、という指摘がある。

これに対する擁護は、Jevの確率は「較正（キャリブレーション）されている」、つまり80%と言えば実際に8割当たる、信頼できる数字だというものだ。TypeSafeの公式サイトも、この確率に閾値を置いて、自動で処理するか人に回すかを決める使い方を勧めている。

この確率を、正しい値が厳密に分かる入力で確かめてみたい。そこで、Jevに「完全に公平なサイコロ」を渡してみることにした。

公平なサイコロで試す

先に実験の結論を述べる。

ここで問題にしたいのは「サイコロの目を当てられなかったこと」ではない。
「当てるための情報がない状況で、その不確実性を正しく確率として報告できなかったこと」だ。

実験の設定

今回はVercel AI Gateway経由でJevを呼び出し、事前定義した候補から1つを選んで各候補の確率も返すChoiceという質問タイプを使用した。サイコロであれば候補は「1〜6」の出目になる。

※検証コードと保存データはGitHubリポジトリに公開している。

プロンプトで与えた指示の骨子は以下の通りだ（実際には英語で入力）。

物理的なサイコロを画像で観察させたわけではない。プログラム側で隠し結果を生成しつつ、Jevには「抽選は公平であること」と「結果は見えないこと」だけを伝えた。

実験結果

数字のサイコロ（400件）に加え、色のサイコロ（200件）、4分割の回転盤（200件）、コイントス（200件）でも同様に検証した。

※以下の「報告確率」は、Choiceが選んだ候補に付けた値（probabilities[choice]）を指す。別フィールドの confidence とは区別している。
なお、confidenceの計算式は、Yurin氏が (N × 最大確率 − 1) ÷ (N − 1) と復元している。最大確率を変換しただけの値で、独立した信号ではないようだ。

数字のサイコロでは、400件すべてで「1」を選択した。そしてその選択に対して平均82.9%という極めて強気な確率を付けた。しかし、実際の的中率は19.0%（76/400）と、ほぼ理論上の期待値（16.7%）通りだった。

他の抽選でも同様に、正答率は偶然の水準にとどまる一方で、報告確率は70〜90%台へと跳ね上がっていた。

「選ぶこと」と「確率を報告すること」の違い

情報がない以上、公平なサイコロの目を偶然以上に当てることはできない。したがって、正答率が約1/6だったこと自体は何の落ち度でもない。

毎回「1」を選んだこと自体も問題ではない。すべての面が出る確率が等しいなら、タイブレークの固定ルールとして「とりあえず1と答える」のは合理的な振る舞いだからだ。

しかし、その場合でも本来あるべき出力はこうなるはずだ。

選択した候補：1
各候補の確率：1/6（約16.7%）ずつ

「1つの候補を選ぶこと」と「その候補が正解である確率を見積もること」は別の仕事だ。

確率をシステムや業務判断に組み込むためには、「80%の確率で起こる」と予測された事象の集団を集めたとき、実際に約80%が当たっているという対応関係が欠かせない。これを統計学や機械学習では確率の較正と呼ぶ。

TypeSafe自身も、ドキュメントで同じ定義を採用している。よく較正されたモデルなら、確率0.8を付けた結果は約80%の頻度で起こるべきだ、というものだ。今回の実験は、この定義をそのまま当てはめている。

今回の入力では、この較正が大きく崩れていた。400件を通じて、報告確率は最小でも71%（中央値83%）で、真の確率1/6の4倍以上だった。

真偽判定「Noul（Yes / No）」に変えてみる

Choice型特有の癖ではないかと考え、真偽命題（Yes/No）を判定する質問型Noulでも検証した（VercelではBoolean）。「出目は1か？」「特定のリクエスト先が選ばれたか？」といった問いに対し、それが真である確率を返させるタスクだ。実際の出目や割り当て結果を伏せて渡す条件は共通で、各条件60件ずつ試した。

サイコロ（16.7%に対し19.2%）や4分割（25.0%に対し24.7%）のように、真の確率にかなり近い数値を返すケースも見られた。

しかし、選択肢が増えて確率が小さくなると挙動が怪しくなる。20分割（真値5.0%）の設定では、平均で15.0%（全件が13〜17%の範囲）と、過大な値を報告した。

つまり、「ChoiceがダメならNoulを使えば解決する」という単純な話ではない。入力条件や確率のレンジによって、モデルの振る舞いが変わる点には注意が必要だ。

予測文書の数値を次の処理に渡すときの危険性

サイコロのような人工的な問題だけでなく、実際の業務シナリオではどうだろう。そこで次に、文書の内容を読み取って次の処理（エージェントや後続ロジック）に渡す場面を試した。

たとえば、「在庫充足の確率70%、不足リスク30%」と書かれた需要予測レポートがあるとしよう。業務自動化エージェントが次にやるべきことは、「充足が最有力だから問題なし」と切り捨てることではなく、「30%の不足リスクがあるから、念のため代替品の確保を発注すべきか？」を判断することだ。

実験では、在庫・キャパシティ・資金繰り・サービス水準という4つの題材で予測確率を明記した合成文書を作成。「文書をもとに、どの結果が起こるか判断せよ（不確実性を確率分布に保持すること）」とJevに指示した。

30%のリスクが「5%」に縮小される

在庫単独で「不足リスク30%」と記載された3つの文書を読ませたところ、Choiceが返した不足確率は5%、5%、6%（平均5.3%）だった（Noulの場合は平均26.7%）。

元文書に書かれていた「30%のリスク」をそのまま後続に伝えたかったはずが、Choiceを経由しただけで、5%の「ほぼ無視できるリスク」へと塗り替えられてしまったことになる。

さらに、文書に記載する確率を段階的に変えてプロットしたのが以下のグラフだ。

結果は極端だった。

• 記載値が45%のとき：Choiceの報告確率は平均 6.6%

• 記載値が55%のとき：Choiceの報告確率は平均 95.9%

記載値の差は10ポイントしかないのに、Jevの報告値は約89ポイント増加している。確率を滑らかに認識しているのではなく、50%を境にして「有力なほうをほぼ100%に倒し、劣勢なほうをゼロ近くに潰す」という極端な変化が起きている。Noulでも、記載値95%に対して出力が75.9%になるなど、元の数値をそのまま素直に引き継ぐ挙動にはなっていなかった。

これが業務システムで致命的になるケース

もしシステムに「不足リスクが10%を超えたら自動で発注アラートを出す」というルールが組まれていたとしよう。

1. 元文書の予測（30%）をそのまま使う場合：10%を超えるため、アラートが発火して安全に対策が打たれる。

2. JevのChoice出力（5.3%）を間に挟んで使った場合：10%を下回るため、アラートはスキップされ、品切れ事故につながる。

Jev自身に対策の要否を判断させたわけではない。同じルールでも、間に挟んだモデルが返す「確率」のスケールが変わってしまうだけで、システム全体の行動が意図せず狂ってしまう。

確率をシステムで使う前に知っておくべきこと

今回の検証結果をもって「Jevの確率は使い物にならない」と言うつもりはない。第三者の検証では、MMLUの1,200問で良好な較正が報告されている。私が別途実施した、公式デモに近い合成タスクでも、サイコロのような極端な較正誤差は観測されなかった。役に立つケースは数多くあるだろう。

この結果はサイコロの実験と矛盾しない。試験問題で測れるのは「難しい問題に難しいと言えるか」で、サイコロで測ったのは「分かりようがないことに分からないと言えるか」だ。前者ができても後者ができるとは限らない。

問題になるのは、出力された数字を「十分に較正された信頼できる確率」だと盲信し、きちんとした検証を省いてしまうケースだ。

TypeSafe自身が公式Skillで対象領域での検証を求めている。Vercelの記事も、確率やconfidenceを実際のラベル付きデータで較正することを推奨している。Jevをはじめとする判断モデルをプロダクトに組み込む際は、以下の観点を意識したい。

1. 「正答率」だけでなく「確率の較正」を見る
   検証データの事例を、モデルが付けた確率ごとにグループ分けする。そしてグループごとに、付けた確率の平均と、実際に当たった割合を比べる。この2つがどのグループでもおおむね一致していれば較正は取れている。必要なのは、正答率を測るときと同じ、正解付きのデータだけだ。

2. 情報が足りないエッジケースをテストデータに混ぜる
   答えが自明なものだけでなく、あえて「判断に必要な情報が隠されているケース」を入力し、モデルが不確実性を報告できるかを確かめる。

3. 元文書の数値を勝手に上書きさせない
   文書内の予測数値を後続に渡したい場合は、分類器の判断確率で置き換えるのではなく、原文の数値をそのまま保持・抽出する仕組みを採用する。

「速くて安い判断器であること」と「出力された数値を無条件に信頼できること」はまったく別の問題だ。

コードとデータ：
KantaHayashiAI/jev-does-not-play-dice
English version:
Jev Does Not Play Dice: 83% probability, 19% accuracy on a hidden fair die roll