文章を作るわけじゃない。Jevは何をするAIなのか

概要

Jevという名前を見かけても、チャットで質問するAIなのか、検索用のモデルなのか、既存のLLMを小さくしたものなのかは分かりにくい。自分もJevを使うMCPサーバーを作ったが、APIの呼び方を知ることと、その返り値をどう理解すればよいかは別の問題だった。

TypeSafe AIのJev は、渡された情報に対して、あらかじめ定義した質問へ判断を返すモデルである。返ってくるのは自由な説明文ではなく、Yesの確率、候補ごとの確率、段階評価など、プログラムで扱うための値だ。例えば問い合わせの文章を渡し、「請求の相談か」「配送の相談か」「担当者へ回す必要があるか」を評価する。回答を読んで会話を続けるというより、回答を受け取ったコードが次の処理を決める使い方になる。

このような仕事はLLMでもできる。実際、多くのシステムがLLMへ分類や採点を依頼している。しかし、文章として答えを生成すること、指定した形の値を返すこと、正しい確率を返すこと、返された判断から行動を決めることは、それぞれ違う問題だ。出力がJSONとして正しくても、判断の中身は間違う。回答に0.9と書かれていても、その数値が実際の正解率を表しているとは限らない。

この記事では、まずLLMを判断処理へ組み込むときに何が難しいのかを考える。その後、Jevの公開された入出力と処理方式を確認し、確率予測、校正、適正スコアリング則、意思決定、判断の保留という基礎理論へ進む。最後には、それらを問い合わせ分類のシステムへ戻し、何をモデルへ任せ、何をコードで決めるかを考える。

対象は2026年10月1日に確認した公式資料と公開研究である。Jevのネットワーク構造、重み、具体的な学習レシピを再現した記事ではない。公開情報から確認できる仕様、理解するための一般理論、自分が考えた設計例を分けて扱う。以下の問い合わせ、確率、料金計算、評価表は、特に出典を付けた箇所以外は説明用に作った例であり、Jevへ送信して測定した結果ではない。

1. Jevを初めて聞いた人へ

1.1 文章を読んで、決めた範囲の答えを返す

例えばネットショップに、次の問い合わせが届いたとする。

商品は届いたのですが、カードの明細に同じ金額が二つあります。片方を取り消してほしいです。

人間なら、請求に関する話で、取り消しを求めていると読み取れる。ところが、コードで同じ処理を作ろうとすると、どの語を条件にするかが問題になる。「二重請求」という語があれば請求担当へ回す、と決めても、この文章にはその語がない。「カード」がある文章を全部請求へ回せば、商品に付属するカードの話まで混ざるかもしれない。

こうした、表現はばらばらだが意味で判定したい部分にモデルを使う。ただし、担当部署を選ぶだけなら、毎回丁寧な回答文を書いてもらう必要はない。システムが必要としているのは、例えばbilling、delivery、product、unknownのどれに近いかという情報だ。

Jevは、このような入力と回答範囲を与える形式で使う。資料の本文や顧客の文章をstateへ入れ、何を判断するかを質問として定義する。モデルが返した候補や確率を、呼び出し側のコードが受け取る。問い合わせを送る、担当者へ通知する、追加情報を聞くといった行動は、その後のシステムに残る。

flowchart TD
    A["問い合わせの文章"] --> B["状態を用意する<br/>注文情報・必要な履歴"]
    B --> C["Jevへ質問する<br/>担当分野はどれか"]
    C --> D["候補と確率を受け取る"]
    D --> E["コードで取扱いを決める"]
    E --> F["担当へ回す"]
    E --> G["情報を追加して確認する"]

この図のJevは、問い合わせ対応の全部を実行しているわけではない。カード会社へ連絡したり、実際の請求記録を調べたりするのは、別に用意した処理である。文章だけを見て「二重請求の相談らしい」と分類できても、本当に二重に決済されたかは決済記録を確認しなければ分からない。

ここを最初に分けておくと、Jevが何をする道具なのかを理解しやすい。与えた証拠について、決めた問いを評価する。外界の事実を調べることと、証拠の意味を判断することは、システムの中で別々の仕事になる。

1.2 名前とSystem Oneという呼び方

TypeSafeはJevをSystem One modelと呼んでいる。この名前を理解するために、先に心理学で使われているSystem 1とSystem 2を説明しておきたい。Jev独自の用語でも、コンピューターの規格名でもない。人間の考え方を、素早く自動的な処理と、注意を向けて考える処理に分けて説明するための呼び方だ。

System 1は、あまり意識して手順を組み立てなくても進む、直感的な処理を指す。例えば、よく知っている人の顔を見て誰なのかが分かるとき、顔の特徴を一つずつ文章へ書き出し、候補を順番に比較しているわけではない。簡単な例として「2足す2はいくつか」と聞かれたときも、多くの人は計算の手順を意識せず、すぐ4と答えられる。

一方、System 2は、注意を向け、途中の結果を保持しながら進めるような、熟考を伴う処理を指す。例えば「17掛ける24」を暗算するとき、17掛ける20と17掛ける4に分け、二つの結果を足す、といった手順を考えるかもしれない。見慣れない契約の条件を読み、例外と適用範囲を確認する作業も、こちらのイメージに近い。

この呼び方はKeith StanovichとRichard Westが用い、Daniel Kahnemanが広めた。Kahnemanの A Perspective on Judgment and Choice でも、二つの処理の特徴と名称の出所が説明されている。脳の中に「System 1という部品」と「System 2という部品」が、二台のコンピューターのように独立して存在するという意味ではない。ここでは、思考の進み方を区別するための枠組みとして読めばよい。

また、「直感は間違いで、熟考は正解」という区別でもない。慣れた仕事なら、経験を積んだ人が素早く適切に判断できることもある。反対に、時間をかけて考えても、使った情報や前提が間違っていれば答えは間違う。速さの違いと、正しさの違いを一緒にしないほうがよい。

この話をJevへ戻すと、 公式の説明 では、System Oneという名前を、この素早い判断と熟考の対比から取っている。必要な材料と質問を与え、限定された答えを返す使い方を、人間の直感的な判断になぞらえた名前だ。人間の脳の仕組みをそのまま再現しているという意味ではない。

例えば、長い問い合わせの履歴を集め、規約を調べ、矛盾する記録を確認するところには、調査や複数段階の処理が必要になる。その材料が揃った後で「この相談の担当分野はどれか」を短く判定する部分へJevを置く、という分担が考えられる。System Oneという名称だけで性能を判断するのではなく、システムのどの部分を担当させるモデルなのかを理解するための説明として捉えたい。

Jevの名前になったジェヴォンズとは誰か

System Oneが思考の進み方に由来する名前なのに対して、Jevというモデル名には経済学の話がある。William Stanley Jevons、ウィリアム・スタンレー・ジェヴォンズは、19世紀のイギリスの経済学者だ。ここで関係するのは、彼の名前が付いた「ジェヴォンズのパラドックス」という考え方になる。

ジェヴォンズは、1865年に初版が出たThe Coal Questionで、石炭の利用と産業の成長を論じた。 第7章の燃料の効率化に関する議論 では、燃料を効率よく使えることと、社会全体での消費が減ることは同じではないと述べている。個々の機械の燃料消費が減っても、利用する産業や機械の数が増えれば、全体では消費が増えるという見方だ。

直感的には、蒸気機関が少ない石炭で同じ仕事をできるようになれば、石炭を節約できそうに見える。同じ数の機械を同じ時間だけ動かすなら、その考え方でよい。しかし、動かす費用が下がれば、以前は採算が合わなかった仕事にも機械を使えるようになる。製品が安くなれば、その製品を作る量が増えることもある。

すると、一台あたりの石炭消費は減っているのに、使われる機械の台数や稼働時間が増え、総消費はむしろ大きくなる場合がある。「効率が上がったのに消費が増える」というところが、パラドックスと呼ばれる理由だ。効率化そのものが失敗したわけではなく、効率化によって利用の規模まで変わっている。

数量の関係だけを、説明用の例で確認してみる。一回の処理に使う資源が10から1へ減れば、一回あたりは90%の削減になる。ところが、処理回数が100回から2,000回へ増えれば、総使用量は1,000から2,000へ増える。

変更前: 1回あたり10 × 100回   = 1,000
変更後: 1回あたり 1 × 2,000回 = 2,000

この数字は石炭の歴史的な測定値でも、Jevの性能の測定値でもない。一回あたりの効率と、全体の使用量が別の量であることを示すための例だ。処理回数が100回のままなら総使用量は100へ減るし、500回へ増えても500で、変更前より少ない。効率化すれば必ず総消費が増えるという法則ではなく、利用の増加がどれくらい起きるかも考えなければならない、という話になる。

Jevの発表記事 では、このジェヴォンズにちなんでモデルを命名したと説明されている。判断を安く速く呼び出せるようになれば、同じ仕事の費用を下げるだけでなく、これまでAIを使わなかった仕事にも利用が広がる、という期待が背景にある。

例えば、一回の呼び出しで長く待つなら、利用者が送信した問い合わせを一度分類する程度に留めるかもしれない。それが短い待ち時間で処理できるなら、検索で見つけた候補を一件ずつ評価したり、入力途中の文章へ分類の候補を表示したりする使い方も考えられる。呼び出す回数を固定したまま速くすることと、速くなったから呼び出す場所を増やすことは別だ。

問い合わせを一件ずつ人が読んでいたところへ分類モデルを入れる場合も、同じ件数を安く処理するだけでなく、従来は分類していなかった社内メモや古い記録まで対象になるかもしれない。その場合、個々の判断は安くなっても、システム全体で行う判断の回数は増える。

ただし、これは命名に込められた提供者の見方で、Jevの精度や経済的な効果が証明されたという話ではない。自分の用途で利用がどれだけ増えるか、総費用がどう変わるか、判断を増やす価値があるかは別に確認する必要がある。名前から分かるのは、既存の会話を安くするだけでなく、ソフトウェアの中へ判断処理を広く組み込みたいという方向性だ。

1.3 検索や文章生成との関係

Jevへ「この商品の返品条件を調べて」と聞けば、必要な規約を勝手に集めてくれる、という使い方ではない。返品規約を取得し、注文の日時や状態を確認し、判断に必要な情報を渡す側が必要になる。Jevへ任せるなら、その資料に対して「この問い合わせは返品を求めているか」といった問いになる。

同じように、Embedding modelは文章をベクトルへ変換し、似た資料を探すために使えるが、似た資料が正しい根拠だと保証するものではない。LLMは情報を説明する文章や、利用者へ返す自然な返答を生成できる。その前にJevで扱う分野を分類する構成も考えられる。

以前の LLM・Embedding model・Jev・古典的なNLPをどう使い分けるか では、仕事の種類を分けて考えた。今回はさらに手前へ戻って、Jevの判断はどんな数学的な対象なのか、その数値から何を言えるのかを考えたい。使い分けの表だけでは、probabilitiesとconfidenceの違いや、閾値を決める意味までは説明しきれない。

2. LLMを判断処理に使うと、どこが難しいのか

2.1 人が読む文章と、コードが読む値

LLMへ「この問い合わせは請求、配送、商品のどれか」と聞くと、多くの場合は意味の通る答えが返ってくる。人が読むなら「請求の可能性が高いと思います」で十分かもしれない。しかし、コードから使うと、何を値として扱うかを決めなければならない。

請求に関する分類を、日本語の「請求」で返すのか、プログラム用に決めた識別子billingで返すのか。ここで英語を使っているのは、入力を英語へ翻訳するためではなく、コードが扱う分類名の例としてだ。識別子を日本語にしてもよいが、コードがbillingを受け取るように作られているなら、「請求」はそのままでは一致しない。人間には同じ意味でも、コードから使うには、どの値を返すかを先に決める必要がある。

さらに、理由を後ろに付けるのか。分類できない場合は何を返すのか。複数の分野にまたがる場合は一つに絞るのか。回答の先頭を切り出せばよいのか、JSONとして解析するのか。これらが曖昧だと、意味としては妥当な回答でもプログラムが処理できない。

例えば次の二つは、人間にはほぼ同じ判断に見える。

請求に関するお問い合わせです。

主な分類はbillingですが、返品の意図も含まれるかもしれません。

ところが、billingという文字列との一致だけを見るコードでは、一つ目は一致せず、二つ目も余分な文を含んでいる。逆に「請求」という語が含まれていれば一致させると、「請求に関する相談ではありません」のような否定文まで拾ってしまう。出力を人が解釈する前提で作ると、その解釈をコードへ移すための処理が必要になる。

この問題は、LLMが文章を生成する道具だから必ず失敗する、という話ではない。JSON Schemaや文法に基づく制約付き生成を使えば、出力する形をかなり厳密に制限できる。 GengらのGrammar-Constrained Decodingの研究 は、形式文法を使って生成可能な出力を限定する方法を扱っている。現在のLLMを単に「JSONが壊れるモデル」として説明するのは、対策を無視している。

それでも、形式を制限する仕組みと、中身が正しいかを評価する仕組みは別に残る。{"department":"billing"}というJSONを必ず返せても、配送の問い合わせを請求へ回してしまう可能性はある。スキーマに従うことは、判断の正しさを作るための一条件であって、十分条件ではない。

2.2 トークンの確率と、判断の確率

通常の自己回帰型言語モデルは、それまでの文脈と生成したトークンを条件として、次のトークンの分布を計算する。その処理を繰り返して文章を作る。説明のために書くと、文章全体の確率は各位置の条件付き確率の積になる。

P(文章 | 入力)
  = P(1番目のトークン | 入力)
    × P(2番目のトークン | 入力, 1番目)
    × ...

ここで、LLMが「次にどの文字列を書くか」を予測していることと、こちらが知りたい「どの分類が正しいか」は分けて考えたい。例えば、請求の問い合わせについて、モデルが次に「請求」と書く確率を調べたとする。同じ判断をしていても、モデルは「これは請求に関する相談です」と書くかもしれない。この場合、最初に書くのは「請求」ではなく「これは」になる。「請求」で書き始める確率だけでは、請求と判断している可能性を全て拾えない。

回答をbillingのような決めた分類名へ限定すれば、この表記の問題を減らせる。ただし、それでも「モデルがその分類名を選ぶ確率」と「その分類が実際に正しい割合」が、自動的に同じになるわけではない。例えば、モデルが請求へ0.9の確率を付けた問い合わせを多数集めても、確認すると請求に該当したのは70%だけ、ということはあり得る。この数字は説明用の例だが、出力の確率と実際の結果を照合する必要があることを示している。

つまり、欲しいのは単に「請求という答えを出しやすい」という情報ではない。「請求に該当する可能性を0.9と予測した案件では、実際にも約90%が請求に該当する」というように、判断対象の結果と対応した確率だ。LLMの出力からその確率を取り出したいなら、どの回答を同じ分類として数えるかを決め、その数値が実際の分類結果と合っているかを評価する必要がある。

もちろん、候補を限定してラベルの確率を読む方法はある。教師ありで分類に合わせて学習することもできる。問題は、どの数値を読んだとき、それが何に対する確率なのかを明らかにすることだ。「LLMが確率を計算しているから、その数値は現実の正解率だろう」という飛躍は避けたい。

もっと身近な例なら、モデルが「確信度90%です」と文章へ書き込む場合がある。この90%は、モデルが生成した文字列の一部でもある。実際に、その表現をした回答を多数集めて90%程度が正しかったかを確認しなければ、利用者が期待する確率の意味を持つか分からない。

数値が付いていると、文章だけの回答より測定可能に見える。しかし、測定値らしい外見を持つことと、正しい対象を測っていることは違う。問い合わせの緊急度を0.9と評価した数値、Yesの確率が0.9という数値、回答分布の集中度が0.9という数値も、それぞれ意味が異なる。

2.3 判断と説明の生成が一緒になりやすい

LLMへ判断を頼むと、理由も一緒に書いてもらいたくなる。理由があれば人が確認しやすいし、誤判定を調べる手掛かりにもなる。ただ、システムが必要とする値と説明が毎回同じ仕事かどうかは考えたい。

問い合わせ一万件を分類し、そのうち曖昧な五百件だけ人が読む構成なら、全件に長い理由文を付ける必要はないかもしれない。理由を生成するための時間、通信量、保存量が増える。人が読まない説明まで大量に作ると、後から分析するデータも増える。

さらに、生成された説明が整っていると、判断まで正しそうに見えることがある。「カード明細に二つ記載されているため、重複決済が発生しています」という説明は自然だが、実際には仮売上と確定売上が並んでいるだけかもしれない。顧客がそう述べたという証拠と、システムが重複決済を確認したという証拠は違う。

説明文を読むことには意味がある。ただし、その説明を独立した検証結果として扱ってはいけない。同じ入力から同じモデルが作った理由文は、新しく決済データを取得したものではない。文章が増えても、証拠が増えたとは限らないという点が、判断システムでは大事になる。

2.4 長い推論を毎回使うことのコスト

LLMが複雑な問題を解くとき、複数の段階を踏んだ推論やツールの利用が役に立つ。ところが、すべての分類に同じ深さが必要とは限らない。入力と候補を見れば短く決められる問いに、毎回長い生成処理を使うと、処理の頻度が増えるほど待ち時間が目立つ。

例えば、一回の判定は利用者が待てる時間でも、同じ資料に十の観点を順番に問い合わせると、全体の時間は積み上がる。並列に呼び出せば待ち時間を減らせる場合もあるが、同じ入力を繰り返し送るコスト、同時実行数、APIの制限、失敗時の再試行も考える必要がある。

一回で十の質問を答えさせれば、通信回数は減る。ただし、一般的なLLMでは出力する回答列そのものが逐次生成される。質問同士の評価をどこまで独立に保てるか、回答形式をどう固定するかも残る。入出力トークン数だけでなく、全体の処理方式を見る必要がある。

ここで大事なのは、推論時間を使うこと自体を否定しないことだ。曖昧な仕様を調査する、複数の資料から矛盾を探す、未知のバグを切り分ける仕事には、十分な探索が必要になる。短い判定と、答えを作るために追加調査が必要な仕事を同じものとして扱うと、速度の比較も用途の選定もおかしくなる。

2.5 LLMを評価者にした場合の偏り

別のモデルの回答をLLMへ読ませて採点する、いわゆるLLM-as-a-Judgeも便利な方法だ。人が全件を比較するより多くの事例を処理でき、文章の意味に踏み込んだ評価もできる。しかし、評価者として使う場合には、入力の順番や長さによる影響を調べる必要がある。

ZhengらのMT-BenchとChatbot Arenaの研究 では、LLMによる評価の有用性とともに、提示位置、冗長さ、自分に関係する回答への偏りなどを検討している。これは、LLMを評価者にすると必ず使い物にならないという結果ではない。評価方法自体に偏りがあるかを確認する研究だ。

例えば候補AとBを比較したとき、内容を変えず順番だけ入れ替えると判定が変わるなら、内容以外の影響が混ざっている。同じ回答を短くしただけで評価が下がるなら、長さが品質の代用品になっていないか調べたい。何を正しい判断として測っているのかを、モデル名より先に決める必要がある。

この注意はJevにも当てはまる。別の出力方式や学習目標を採用したから、意味的な偏りが全部なくなるとは言えない。比較実験では、モデルを入れ替えることだけでなく、候補順、質問、入力範囲、評価者の基準まで固定して、どこが変わったかを確認する。

2.6 LLMにも確率を扱う研究はある

ここまで読むと、LLMには信頼できる確率を出す能力がないように見えるかもしれない。それは言い過ぎになる。 KadavathらのLanguage Models (Mostly) Know What They Know では、回答の正しさや自分が答えられるかをモデルに評価させ、その確率を調べている。

また、 LinらのTeaching Models to Express Their Uncertainty in Words は、不確かさを言葉で表現するよう学習したモデルを評価する研究である。確率を文章として出す場合でも、目的に合わせた学習と検証を行えば、校正を研究できる。

したがって、LLMとJevの違いを「片方は必ず嘘の確率を出し、片方は必ず正しい確率を出す」と説明したくない。どんな出力を目的として学習し、どの形式で受け取り、どんな条件で評価したかという違いを見る。Jevの特徴は、限定された判断と確率をソフトウェアから使うことを中心に据えた仕様と設計目標にある。

3. Jevの仕組みを、公開情報から組み立てる

3.1 外から確認できる三つの要素

Jevについて公開情報から説明できる仕組みは、大きく分けると、入力と回答の契約、複数の回答を評価する方式、学習で目指す性質の三つになる。TypeSafeは、新しいモデル構造、並列のsampler、RLCDという学習方法を採用したと説明している。ただし、この記事で確認できた公式資料から、層の構成や具体的な最適化手順まで再現することはできない。

入力と回答の契約は、利用者が実際に確認しやすい。stateと質問を送り、回答型ごとの値を受け取る。生成された説明文を読み直して選択肢を拾うための処理を、主な使い方にしていない。返り値を受け取ったコードは、どの候補にどれだけ確率が付いたかを直接扱える。

処理方式については、 発表記事 が、出力を一トークンずつ自己回帰的に生成する方式との違いとして、並列に出力する設計を説明している。利用者からは、同じ状態に対する複数の質問を一回へまとめる形式として見える。単にHTTPリクエストをまとめたという説明だけでは、TypeSafeが主張するモデル側の違いを表しきれない。

学習目標については、 AI primer で、RLCDを、判断と校正された確率を返すための強化学習として説明している。どの損失や報酬を使い、どんなデータをどう集めたかは、ここで確認した資料からは分からない。後半で説明するBrier lossなどは、この目標を理解するための一般理論である。

flowchart TD
    A["公開されたJevの説明"] --> B["入出力の契約<br/>状態・質問・型付き回答"]
    A --> C["評価の方式<br/>複数の出力を並列に評価"]
    A --> D["学習の目標<br/>RLCDと確率の校正"]
    B --> E["APIの仕様から確認する"]
    C --> F["公式説明と計測を分けて読む"]
    D --> G["目標は公開<br/>具体的な学習手順は不明"]

「仕組み」という言葉には、HTTPの形式、モデルが返す数学的な対象、学習アルゴリズム、実行ハードウェアまで含められる。どこまでが公開されているかを示さずに一枚の内部構造図を書くと、推測したものが実装のように見える。ここでは公開された境界から説明を始める。

3.2 文章生成をやめると、何を捨てて何を得るか

自由な文字列は非常に強い出力形式だ。説明、コード、数式、会話、検索語、手順を、同じ仕組みで表現できる。利用者が最初に答えの形式を決めなくても、モデルが必要な文章を作ってくれる。未知の問題に取り組むとき、この自由度は大きな利点になる。

一方、担当部署を選ぶだけの処理では、その自由度が必要ない。システムは存在しない部署を受け付けないし、返答の口調も関係しない。どの答えを許可するかが先に決まっていれば、その範囲をモデルへ明示できる。

Jevは自由文の生成を主な出口にしないので、長い説明文や新しいコードが必要な仕事には別の手段が要る。その代わり、限定された回答空間を前提に、確率分布を返すことに処理を合わせられる。何でも表現できることを少し手放し、コードから利用する部分を狭くする考え方だ。

ここで「文章生成をしないから必ず計算が軽い」とまで断言はできない。入力を読む処理は必要だし、質問や候補が増えれば仕事も増える。処理方式の利点と実際の速度は、モデル、入力長、質問数、ネットワーク、サービスの混雑などを含めて測る必要がある。

それでも、どの処理を利用者に提供しようとしているかは明確になる。説明を生成する一回と、百個の限定された判断を返す一回は、入出力も仕事の量も違う。速さの数字だけを並べる前に、同じ問いと同じ品質を比較しているかを見るべきだ。

3.3 「型が安全」の意味を狭く正確に読む

Jevの発表には、型付き出力やhallucinationに関する強い表現がある。実際のシステムを考えるなら、それがどんな失敗を防ぐという話なのかを分けたい。候補がbillingとdeliveryだけなら、回答が存在しないsuper_departmentになることを防ぐ、という話は回答空間の制約である。

しかし、配送の文章にbillingを返すことは、候補の制約に違反しない。正しい型の値として、間違った分類が返ってくる。候補集合を制限しても、文章の読み間違い、必要な情報の欠落、質問の曖昧さは残る。

同じように、返された確率が0から1の範囲で、合計が1だったとしても、校正されているかは分からない。0.99と出した事例を集めると半分しか正しくない、という分布も、形式上は合法である。数値の範囲や合計を検査するコードでは、その意味上の問題を検出できない。

flowchart TD
    A["回答を受け取る"] --> B["形式が正しいか<br/>型・候補・数値の範囲"]
    B --> C["判断が妥当か<br/>証拠と正解ラベルを照合"]
    C --> D["確率が校正されているか<br/>多数の事例で確認"]
    D --> E["この行動を取ってよいか<br/>費用・権限・業務条件"]

この図は、後ろの条件が前の条件から自動的に得られるわけではないことを示している。形式が合えば中身が正しい、中身がある程度正しければ数値も正しい、確率が良ければ実行してよい、という連鎖にはならない。実際には、それぞれを別の仕組みで確認する。

また、型付きの判断でも、通信失敗やAPIエラーは起こり得る。回答が来なかったことをYesとして扱うか、Noとして扱うか、保留するかはアプリケーションの設計になる。「モデルが型を守る」と「サービス呼び出しが必ず成功する」も別の条件だ。

4. stateは、モデルが見る世界の範囲になる

4.1 質問が同じでも、証拠が違えば答えは変わる

公式のStateの説明 では、stateに文字列やJSONのオブジェクト、配列を渡せる。ここへ入れるのは、モデルが判断する材料である。問い合わせ本文だけなら、判断できるのは主にその本文の内容になる。

先ほどの文章から「取り消しを求めているか」は判断できるかもしれない。しかし、「重複した請求が存在するか」「今すぐ返金してよいか」は、注文や決済の情報がないと決められない。これらを同じ質問として扱うと、顧客の主張を事実として採用してしまう。

必要な材料を足すときも、何を観測した情報なのかを明確にしたい。顧客の文章、決済APIから取得した記録、担当者のメモ、社内規約は、すべて文字列にできるが、証拠としての性質は違う。単に一つの長い文章へつなぐより、出所と役割を名前付きで示す方が、後から調べやすい。

{
  "customer_message": "カードの明細に同じ金額が二つあります。",
  "payment_observation": {
    "status": "not_checked"
  },
  "task": "問い合わせの種類を分類する"
}

これはstateの説明用の例である。not_checkedは、支払いに問題がないことを意味しない。まだ確認していないという情報だ。未知をNoとして埋めないことは、モデルを使う前のデータ設計で決まる。

4.2 情報がないことと、条件が成立しないこと

例えば返品の可否を考えるなら、購入日が分からないことと、返品期限を過ぎていることは違う。日付が未入力だから期限外、と決めると、情報不足を否定へ変換してしまう。モデルへ渡す時点でこの変換が起きていれば、モデルが正しく文章を読んでも結果は誤る。

データベースでいうNULL、APIでいう未取得、顧客が言及していない、システムで対象外という状態も、同じ空欄にまとめない方がよい。少なくとも判断に関係する違いは保存したい。注文が存在しないのか、注文の取得に失敗したのかでも、次に取る行動は変わる。

この区別はJev固有の問題ではない。LLMへ文章を渡す場合でも、ルールエンジンを使う場合でも同じだ。モデルの高度さで解消する前に、入力に含める情報の意味を決める必要がある。どんなモデルも、入力の空欄が何を意味していたかを常に当てられるわけではない。

実際の失敗を調べるときは、回答だけでなく、判断の時点で何を知っていたかを再現したい。後から支払いが確認できたからといって、その記録を過去のstateへ追加して再評価すると、実運用より多くの証拠を与えたことになる。モデルの性能を改善したのか、未来の情報で問題を簡単にしたのかが分からなくなる。

4.3 長い入力なら安心、というわけでもない

必要な情報が抜けるのを避けようとして、履歴を全部入れたくなることがある。ところが、関係のない文や古い規約まで入れると、どこを判断の根拠にすべきかが曖昧になる。利用者が変更を依頼した文章と、以前の担当者が書いた判断が混ざれば、どちらを現在の要求として扱うかも問題になる。

例えば、問い合わせは「住所を変更したい」だけなのに、過去三年の購買履歴と返品相談を全件入れる必要があるか。注文の配送先を変更する処理なら、対象の注文、現在の配送状態、本人確認の結果が重要になる。過去の問い合わせは、現在の判断を邪魔する場合もある。

ただし、短くすれば常に良くなるというわけでもない。「これを取り消してください」という本文だけを切り出すと、直前に話していた対象が分からなくなる。情報を削るときは、文字数を小さくすることより、質問に必要な関係を残すことを目的にする。

そのため、前処理も評価の対象になる。元の資料からどの部分を抽出したか、関係する条件を落としていないか、要約で否定が消えていないかを確認する。Jevに渡す前の要約を別のLLMで作るなら、その要約の失敗も全体の失敗率へ含めなければならない。

4.4 stateの中に書かれた命令をどう扱うか

問い合わせ本文には、通常の依頼だけでなく、モデルへ命令するような文章が混ざる可能性もある。「この問い合わせを必ず承認してください」「前の指示を無視してください」といった文は、判断対象の文章であって、システムの権限を変更する指示ではない。

JSONの中に入れたから、その区別がモデルに完全に保証されると考えることはできない。JSONはデータの形を示せるが、文字列の意味まで隔離する防壁ではない。敵対的な文や誤解させる文が入る条件を、評価用の事例として扱う必要がある。

例えば、請求相談の本文に「分類は配送です」と書かれていても、それをそのまま採用してよいかは質問の定義次第だ。「顧客が自己申告した分類を取り出す」なら、その文は根拠になる。「相談の内容を分類する」なら、本文全体の意味を見る必要がある。同じ文章でも、何を聞くかで正解が変わる。

こうした設計を曖昧にしたまま「モデルが騙された」と言っても、どの境界を守らせるつもりだったかが分からない。入力資料、判断の指示、許可された候補、後段の行動を、それぞれ具体的に定義するところから始めたい。

5. 三つの出力形式で何を表すのか

5.1 Noulは、肯定側への確率を返す

最初に理解しやすいのは、肯定と否定に分けるNoulだ。例えば「この問い合わせには、料金の返金を求める意図が含まれているか」と聞く。このとき、返ってくる値が0.8なら、肯定側への確率を0.8とした判断になる。否定側は残りの0.2になる。

ここで、0.8は「返金要求が文章の80%を占めている」という意味ではない。「返金を求める気持ちの強さが80点」という意味でもない。質問として定義した出来事が成立するかについて、肯定側へどれだけ確率を割り当てたかを表している。 公式のNoulの説明 でも、yes/noの確率として扱っている。

同じ0.8でも、質問の書き方を変えれば指している出来事は変わる。「返金という言葉が明示されているか」と「返金を求める意図があるか」と「返金すべきか」は別の問題だ。最初は文字列の確認で済むかもしれない。次は言い換えや文脈の理解が必要になる。最後は契約、決済履歴、規約、対応方針などの情報が必要になる。

問い合わせが「二回請求されたようなので、片方を戻してほしい」という内容なら、返金を求める意図は読み取れる。しかし、実際に二重請求が起きたかは本文だけでは分からない。まして、返金してよいかは別の判断だ。三つを一つの質問へまとめると、モデルが文章を読めているのか、業務上の可否を判定しているのかが曖昧になる。

flowchart TD
    A["問い合わせ本文"] --> B["返金を求める意図があるか"]
    B --> C["Noul: 肯定側への確率"]
    C --> D["返金相談として扱う"]
    D --> E["決済履歴と規約を確認する"]
    E --> F["返金できるかを別に判断する"]

0.02という値も低い信頼度という意味ではない。肯定側の可能性が低く、否定側へ強く寄った予測だ。0.98も0.02も二択としては偏っていて、0.5付近はどちらとも決めにくい。ただし、数値が端へ寄っていること自体が、その予測の正しさを保証するわけではない。この点は、後で校正と評価の話へつながる。

Noulを使うときは、質問を一つの意味へ絞るほうがよい。「返金を要求しており、対応期限が近く、規約に反せず、不正利用でもないか」と聞けば、どの条件で否定されたか分からなくなる。それぞれを別に聞き、確定できる条件はコードで確認する。そのうえで、必要な条件が揃ったかを後段で組み立てる。

これは質問を大量に増やせばよいという話でもない。モデルに聞かなくても確定できることまで質問へ変えると、誤りを持ち込む箇所が増える。期限がデータベースに日時として入っているなら、時刻の比較はコードで行う。Noulが担当するのは、文章から意図を読み取るなど、決定的な計算では終わらない部分に絞りたい。

5.2 Choiceは、候補の集合へ確率を配る

Choiceでは、用意した候補の中から選ぶ。問い合わせの担当部署を「請求」「配送」「商品」「その他」へ分けるなら、それぞれに確率がつき、最大の確率を持つ候補がchoiceになる。 Choiceの仕様 では、候補ごとのprobabilitiesと、選ばれたchoice、confidenceが返る。

説明のために、次のような出力を考える。これは実際のAPIで測定した値ではない。

この例では「請求」を選ぶ。ただし、選ばれた文字列だけを残すと、0.78で選ばれた場合と0.29で辛うじて選ばれた場合を区別できなくなる。候補が四つあれば、どれも低めなのに最大値だけで一つを選べる。最大というのは、あくまで他の候補との相対関係だ。

候補の定義も、モデルから見える問題の一部になる。「請求」という名前だけでは、領収書の発行、支払い方法の変更、二重請求、返金相談まで含むか分からない。「配送」との境目も、送料を質問している場合に曖昧になる。候補には説明を付け、業務上どの範囲を担当させたいかを明示したい。

候補同士が重なる場合もある。「急ぎ」と「請求」は同じ種類の分類ではない。請求の問い合わせで、なおかつ急ぎという状態が普通にある。この二つを同じChoiceの排他的な候補に置くと、本来両立する情報をどちらかへ押し込めることになる。担当分野をChoiceで聞き、緊急性を別のNoulやScoreで聞くほうが、問題の構造に合う。

また、候補に正解がなければ、どれかが選ばれたという事実だけでは意味がない。返品、アカウント、法務などを候補から落とした状態で、どんな問い合わせにも四択を強制すれば、それらも四つのどこかへ分類される。「その他」や「情報不足」を置くことは、その状況を表現するための設計になる。ただし、その候補を置いただけで未知の問題を確実に発見できるわけではない。

候補集合が変わると、質問そのものが変わることにも注意したい。「請求か配送か」の二択で0.9だった請求が、「請求、配送、返品、契約、アカウント」の五択でも0.9になるとは限らない。追加した候補がより適切な説明を持っていれば、確率の配分は変わる。それを単なる出力の不安定さと呼ぶ前に、何を条件とした確率なのかを確認する必要がある。

5.3 Scoreは、段階へ割り当てた分布を数値へまとめる

Scoreは、文章で定義した順序付きの段階を扱う。例えば問い合わせの緊急性について、次の四段階を定義する。

Scoreは各段階への確率から、段階のインデックスの加重平均を返す。 公式のScoreの説明 に沿うと、段階の位置が0、1、2、3で、確率が0.1、0.2、0.6、0.1なら、scoreは次のようになる。

score = 0 × 0.1 + 1 × 0.2 + 2 × 0.6 + 3 × 0.1
      = 1.7

1.7は、物理的な緊急度を直接測定した値ではない。用意した段階の位置へ分布を割り当て、それを一つの数へまとめたものだ。段階の説明を変えれば、1.7の意味も変わる。0から3までの間隔が、現実の損害の大きさとして等間隔だという保証もない。

ここは、平均だけを見ると分かりにくい。三段階の0、1、2を考える。全ての確率が段階1へ集まっている場合と、段階0と段階2へ半分ずつ分かれる場合では、どちらも平均は1になる。しかし、前者は中間の状態をはっきり選んでいて、後者は両端のどちらかを決めかねている。平均が同じでも、判断の状態はかなり違う。

後者を「普通の緊急度」と扱うと、非常に重要な問い合わせを落とす可能性がある。少なくとも、平均に加えて分布を見る設計にしたい。最大段階への確率が一定以上なら別の確認を行うなど、平均とは違う観点での処理も考えられる。どの扱いが適切かは、業務上の損失で決める。

公式の説明では、Scoreの各段階は個別に評価され、段階番号や隣の段階を前提にしない説明が求められる。「前の段階より少し強い」とだけ書くのではなく、その段階がどんな状態を意味するかを単独で読めるようにする。段階の説明が曖昧なら、平均を小数点以下まで計算しても精密な尺度にはならない。

5.4 三つの形式は、同じ問題の言い換えではない

Noul、Choice、Scoreは、それぞれ答えの空間を違う形へ制限している。二択の出来事、排他的な候補、順序付きの段階だ。何でもScoreへ押し込めば細かく評価できるというわけではないし、Choiceを使えばどんな曖昧さも整理できるわけではない。

質問の意味と出力形式が合っていることが先に必要になる。「対応するべきか」という質問も、担当へ振り分けるべきか、返金を実行するべきか、警察へ連絡するべきかで必要な証拠と責任が違う。出力の形式を決める前に、何の判断を切り出すのかを書き出したほうがよい。

モデルが出せる型に業務を無理やり合わせるのではなく、業務にある判断の構造から型を選ぶ。この順序を守ると、Jevを使わないほうがよい箇所も見えてくる。曖昧さがない入力から決定的な答えを計算するなら、モデルを通す理由は薄い。

6. Jevの確率は、何を条件にした確率なのか

6.1 世界全体ではなく、与えた情報について答えている

確率を少し数学的に書くなら、Jevが扱うのは次のような対象だと考えられる。

P(答え | state、質問、候補の定義、モデル)

これは内部計算式の断定ではなく、出力を解釈するための見方だ。何も条件を付けない「答えの確率」ではない。stateに含まれない契約情報や、まだ発生していない将来の出来事まで直接見ているわけではない。

例えば「顧客が二重請求を受けているか」と聞いて、stateに顧客の訴えしか入っていない場合、モデルは訴えの文章に基づいて判断する。決済記録が二件ある場合と、一件しかない場合では、与える情報が違う。文章の読みやすさが同じでも、判断材料の内容が変われば予測が変わるのは自然だ。

ここで質問を「本文は二重請求を訴えているか」へ変えると、必要な証拠が少なくなる。本文だけで答えられる問題に変わるからだ。逆に「実際に二重請求されたか」へ広げると、外部の事実確認が必要になる。モデルの性能を評価する前に、この二つを混同していないかを確認したい。

人間が文章を読んで判断するときも似た事情がある。「この人はそう言っている」と「実際にそうなった」は別だ。Jevに数値を出させると、後者まで客観的に確認されたように見えやすい。しかし、入力した証拠の範囲は変わらない。数値へ変えたことが、観測していない事実を増やすわけではない。

6.2 候補が閉じている問題と、答えが開いている問題

担当部署の四択のような問題では、出力の候補を先に定義できる。このような閉じた問題は、結果を評価しやすい。「請求を配送へ誤分類した」という形で、どこを間違えたかを記録できる。

一方、「この顧客にどう対応すればよいか」は、回答の候補が事前に決まっていない。追加質問、返金、規約の案内、別部署への相談などがあり、文章の丁寧さや法的な表現まで含まれる。この段階では、生成を担当するLLMの仕事が残る。Jevに分類させた結果をそのまま顧客向けの回答として使うことはできない。

閉じた候補を作れるかどうかは、対象の文章よりも、システムが何をしたいかで決まる。同じ問い合わせでも、担当部署を選ぶならChoice、返答文を書くならLLM、注文番号を確認するならパーサーやデータベースになる。入力が自然言語であることだけを理由に、全てを同じモデルへ投げる必要はない。

6.3 確率は、無知の万能な表現ではない

「分からない」を0.5として扱うと、二種類の状況が混ざることがある。材料が不足していてどちらにも寄れない場合と、十分な材料があるが、実際に境界付近の事例である場合だ。両方とも0.5付近になり得るが、次に行うべきことは違う。

材料不足なら、注文履歴を取得したり、顧客に追加質問したりすることで改善できる。境界付近なら、部署の運用ルールを決める必要があるかもしれない。「送料が高い」という相談を請求と配送のどちらへ回すかは、モデルが隠れた真実を発見する問題ではなく、組織側が責任分担を定める問題になり得る。

さらに、モデルが未知の入力に対して自信を持つ場合もある。低いconfidenceだけを未知判定に使えば、未知なのに高い値を返すケースを見落とす。入力形式、対象言語、資料の欠落、候補外の意図など、モデルの数値とは別の条件でも保留できるようにしたい。

7. 並列に評価できることと、独立であることは違う

7.1 同じstateから複数の観点を聞く

問い合わせの分類、返金要求の有無、緊急性は、同じ本文を材料にできる。Jevでは複数の質問をまとめて与えることができる。本文を読みながら、一つの質問の答えを文章で生成し、その文章を次の質問へ渡すという処理とは違う形になる。

flowchart TD
    S["共通のstate: 問い合わせと確認済みの情報"] --> C["Choice: 担当分野"]
    S --> N["Noul: 返金要求の有無"]
    S --> G["Score: 対応の緊急性"]
    C --> R["後段のコードで結果を組み合わせる"]
    N --> R
    G --> R

この構成では、分類の答えを待たずに緊急性を評価することができる。質問の数が増えても、一つずつ自由な説明文を生成する場合とは待ち方が変わる。ただし、質問を増やす費用や制約が消えるわけではない。実際の応答時間はstateの長さ、質問の内容、サーバーの混雑などにも依存するので、自分の入力で測る必要がある。

7.2 統計的な独立性を保証しているわけではない

独立した質問として評価することと、答えの確率変数が統計的に独立であることは別だ。返金要求がある問い合わせは、請求分類である可能性も高い。二つの判断には、本文の内容を介した関係がある。

例えば、返金要求の確率が0.8で、請求分類の確率が0.9だったとする。「両方が成立する確率」を単純に0.8掛ける0.9で0.72とするには、独立性を仮定する必要がある。問い合わせの内容について、その仮定が自然に成り立つとは言いにくい。

一般には、両方が成立する確率は、片方が成立した条件でのもう片方の確率を使って考える。

P(AかつB) = P(A) × P(B | A)

Jevへ別々に聞いたP(A)とP(B)だけでは、P(B | A)は得られない。複数の質問が一回のリクエストへまとまっていることは、この不足を埋めない。合成した確率が必要なら、合成事象を直接定義して評価するか、その合成方法を別の評価データで検証する必要がある。

7.3 論理の整合性は、コード側で守る

同じ出来事について「Aか」と「Aではないか」を別々に質問した場合、二つの肯定確率が必ず足して1になるとは限らない。質問の表現や解釈が変わるうえ、二つの出力を同時に制約する仕組みがあるとは限らないからだ。一つのNoulの肯定と否定は補数として扱えるが、別のNoulとして聞いた否定文は別の評価になる。

排他的な候補を一つのChoiceに置けば、少なくともその質問内では確率分布として扱える。対して、複数のNoulへ分けた条件が矛盾しないことは、別に確認する必要がある。「返金済み」と「未返金」を互いに排他的な状態として扱うなら、データベースの状態遷移を優先し、モデルの出力で同時に両方へ進ませない。

モデルへ論理の説明を長く書けば、システムの不変条件まで保証されるとは考えないほうがよい。返金を一回しか実行しない、注文の所有者以外へ情報を出さない、未確定の決済を確定済みとして扱わない、といった条件は、モデルに関係なく守るべきだ。Jevを使っても、整合性を確認するコードが不要になるわけではない。

8. 当たるモデルと、確率が正しいモデル

8.1 Accuracyだけでは確率の良し悪しが見えない

二択の問題を100件解き、90件正解したモデルを考える。正解率は90%だ。ただし、全ての答えに0.99の確率を付けていたのか、0.9を付けていたのか、0.6を付けていたのかで、確率の意味は変わる。

0.99を付けた100件のうち90件しか正しくなかったなら、確率は過剰に高い。0.6を付けた100件のうち90件正しかったなら、その集合では低く見積もっている。どちらも最大確率の側を選べば同じ90件を正解できる。正解率だけを見ると、この違いが消える。

確率を自動処理の条件に使うなら、この違いは大きい。0.99なら自動で処理し、0.6なら人間へ回すという方針の場合、同じ正解率でも自動処理の量が変わる。確率が過剰に高いモデルでは、誤りを含む判断をそのまま自動処理する割合が増える。

この区別を整理した代表的な研究として、 GuoらのOn Calibration of Modern Neural Networks がある。高い分類性能を持つニューラルネットワークでも、出力の確率が実際の正解頻度と合うとは限らない。Jevの「校正」を考えるにも、まずこの違いを押さえる必要がある。

8.2 Calibrationは、似た予測をした集合で確かめる

二択の肯定側の予測をp、実際に肯定だったかをyとする。yは肯定なら1、否定なら0だ。理想的な校正は、おおよそ次のような関係で表せる。

予測確率がpの事例を集めたとき、肯定の割合がpになる

0.8と予測した案件を十分に集めて、そのうち約80%が肯定なら、その範囲の予測は実際の頻度と合っている。この話は、一件の問い合わせが「80%だけ正しい」という意味ではない。一件の結果は肯定か否定のどちらかで、確率の良し悪しは複数の観測を使って評価する。

ここは直感に反する部分がある。0.8と予測された一件が否定だったとしても、それだけでは確率が悪いとは言えない。校正された0.8の予測でも、20%程度は否定になる。反対に、0.99の予測がたまたま一件当たったとしても、それだけで校正の良さが確認されたわけではない。

実際のデータでは、全ての予測がちょうど0.8になるわけではない。0.76から0.84などの区間へまとめ、予測の平均と肯定率を比べることになる。次の表は計算の見方を示す架空の例だ。

高い予測の側ほど、実際の肯定率を上回っている。この例では、肯定の可能性を高めに見積もっていると読める。ただし、この表も区間を変えると見え方が変わる。サンプルが少ない区間では、偶然による揺れも大きい。差があることだけを見て、全てをモデルの問題だと決めつけることはできない。

flowchart TD
    A["評価用の案件と正解ラベル"] --> B["モデルの予測確率を記録する"]
    B --> C["近い予測確率の案件をまとめる"]
    C --> D["予測確率の平均を計算する"]
    C --> E["実際の肯定率を計算する"]
    D --> F["二つを比較し、件数と揺れも確認する"]
    E --> F

8.3 二択の肯定確率と、選んだ答えの正解率

Noulのpが0.1だったとき、その値は肯定の可能性が低いという意味だ。否定を答えとして選ぶなら、その答えへ割り当てた確率は0.9になる。肯定側の頻度を調べる校正と、選んだ答えが正しい頻度を調べる校正では、集計する値が違う。

例えば、pが0.1付近の事例では肯定が約10%あることを確認する。これを、否定を選んだ事例の正解率として見れば約90%になる。両方とも同じ情報から出るが、「確率0.1なのに90%当たるから校正が悪い」と比較してはいけない。何の出来事への確率を見ているかを揃える必要がある。

Choiceでは、選ばれた候補への確率と、その候補が正しかった割合を比べる方法がある。ただし、それだけでは選ばれなかった各候補の確率まで確認できない。返金という重要な分類が常に二番手に置かれていた場合、最大候補の集計だけでは、その分類への過小評価が見えにくくなる。業務で重要なクラスは、クラスごとにも確認したい。

8.4 校正されているだけでは、役に立つとは限らない

肯定が全体の10%しかない仕事で、全ての案件へ0.1を返すモデルを考える。全体として見れば予測は実際の頻度と合う。しかし、どの案件が肯定になりそうかを区別できない。必要なのは、確率の正しさに加えて、案件ごとの差を見分ける力だ。

高い確率を返した案件ほど肯定が多く、低い確率を返した案件ほど肯定が少ないことを、識別の能力として考えられる。さらに、それぞれの確率が頻度に合っていることが校正になる。「全部に平均的な確率を返す」より、事例を区別したうえで頻度も合っている予測が欲しい。

このため、校正の一つの数値だけでモデルを選ぶのも危うい。識別、校正、具体的な閾値での誤り、対応できる件数を一緒に見る必要がある。Jevが校正を重視しているという説明も、校正だけあれば何でも判断できるという意味には広げないほうがよい。

8.5 全体で合っていても、一部では外れる

さらに難しいのは、集計すると誤差が打ち消される場合だ。日本語の問い合わせでは確率を高く出し、英語の問い合わせでは低く出しているとする。全てを一緒にすると平均が合っていても、それぞれの言語では確率が合っていない可能性がある。

案件の難しさ、部署、利用者の表現、資料の長さ、入力の欠落などでも同じことが起きる。自分のシステムが日本語の長い問い合わせを扱うなら、英語の短い問題で良好だった校正だけでは、その条件を確認できない。運用する対象の分布で評価することが重要になる。

ただし、細かく分けるほど件数が減る。部署、言語、文体、長さ、時期を全部掛け合わせれば、一つの区分が数件になることもある。その数件から精密な校正を断定することはできない。対象として重要な区分を決め、件数と不確実性を併記する。評価も、万能な一枚の表では終わらない。

9. 確率の良し悪しを、どう点数にするのか

9.1 外したかどうかだけでなく、どれだけ確率を付けたか

正解率は、最後に選んだ答えが正しかったかを見る。一方、確率を学習したり評価したりするには、予測の分布そのものへ点数を付けたい。そのための道具がscoring ruleだ。ここでは損失として説明するので、値は小さいほうがよい。

例えば、肯定が正解だった案件に0.9を付けた場合と、0.51を付けた場合は、どちらも肯定を選んで正解になる。しかし、確率としては異なる予測だ。逆に否定が正解だった案件へ0.99を付けたなら、僅かな間違いというより、強く確信して外したことを評価へ反映したい。

単純に「正解へ高い確率を付けたら褒める」とだけ考えると、全てを0か1へ振り切る戦略が有利になる採点方法も作れてしまう。確率として正直な予測を引き出すには、平均的に見て真の確率を申告することが最善になる採点方法が欲しい。この性質を持つものがproper scoring ruleで、最善の分布が一意になる場合はstrictly properと呼ぶ。

基礎理論は GneitingとRafteryのStrictly Proper Scoring Rules, Prediction, and Estimation に整理されている。ここから先の式は、Jevが実際にその式で学習していると説明するものではない。確率を評価する一般的な道具として見ていく。

9.2 Brier scoreを二択で考える

二択でのBrier scoreは、予測pと結果yの差を二乗する。

Brier score = (p - y)²

p: 肯定への予測確率
y: 肯定なら1、否定なら0

肯定が正解なら、pが0.9の場合の損失は0.01で、0.6なら0.16になる。否定が正解なら、0.9の場合は0.81になる。正解側へ近い予測ほど損失が小さく、外した側へ強く寄せた予測ほど損失が大きい。

なぜ真の確率を出すほうがよいのかも、この簡単な式で確認できる。実際に肯定になる確率をqとすると、平均的な損失は次のようになる。

期待損失 = q × (p - 1)² + (1 - q) × p²
         = (p - q)² + q × (1 - q)

qが決まっているとき、最後の項はpを変えても動かない。最初の項はpをqへ合わせたときに0になる。したがって平均的な損失を最小にするのはp=qだ。真の肯定確率が0.7なら、常に1と答えるより、0.7と答えるほうが期待損失は小さくなる。

もちろん、実際には真のqを直接知ることはできない。観測された案件と結果から評価する。ここでの計算が示すのは、その採点方法が、確率を過剰に端へ寄せることを常に得にする設計ではないという点だ。

多クラスへ広げる場合は、候補ごとの予測と正解の0/1ベクトルの差を使う。定義によって合計や平均の取り方が異なるので、報告されたBrier scoreを比較するときは、二択なのか多クラスなのか、どの正規化を使ったかも確認する必要がある。数値だけを並べると、その違いが落ちる。

9.3 Log lossは、強く外した予測を厳しく扱う

もう一つの代表例がlog lossだ。二択なら次の式になる。

log loss = -[y × log(p) + (1 - y) × log(1 - p)]

肯定が正解なら、予測した肯定確率の対数にマイナスを付ける。正解へ0.9を付けたときの損失は小さく、0.01しか付けていなかったときの損失は大きくなる。自然対数を使った場合、正解への確率が0.9なら約0.105、0.5なら約0.693、0.01なら約4.605だ。

正解への確率が0へ近づくほど、損失は大きくなる。「それは絶対に起きない」と扱った出来事が実際に起きた場合を、強く罰する性質がある。この性質は便利だが、評価データのラベルが誤っている場合にも大きな値が出る。極端に大きな損失があれば、モデルだけでなく入力とラベルを調べる必要がある。

実装では、丸めによってpが0や1になった場合をどう扱うかも決める。対数が計算できないから適当に除外すると、最も強く外したケースが評価から消えてしまう。クリッピングしたなら、その下限を記録する。評価の都合で行った処理と、モデルが実際に返した予測は分けて残す。

Brier scoreとlog lossでは、同じ予測でも損失の付き方が違う。特に端へ寄った誤りへの厳しさが違うので、二つのモデルの順位が同じになるとは限らない。どちらか一つが全てを説明するのではなく、目的に合わせて併せて見るのがよい。

9.4 校正誤差とproperな損失は、同じではない

予測を区間へ分け、平均予測と実際の頻度の差を件数で重み付けして足したものが、よく使われるECEの一つの形だ。直感的には分かりやすいが、区間の数や境界によって値が変わり、有限のデータでは偶然の差も含む。

また、ECEだけを小さくすることと、良い確率予測を作ることは同じではない。全てへ全体の肯定率を返せば、区間内の平均が合いやすくなる。しかし、案件を見分ける能力は低いままだ。Brier scoreやlog lossのような損失は、その区別まで含んだ確率予測を評価するために使える。

この違いは、RLCDという名前から具体的な学習方法を想像するときにも重要になる。「校正を重視している」という説明だけから、ECEを直接報酬へ使っているとか、Brier scoreを最適化しているとかは分からない。理論上使える方法と、製品に実装されている方法は別だ。

10. RLCDで分かっていること、分かっていないこと

10.1 何を良い出力として学習するか

RLCDはReinforcement Learning for Calibrated Decisionsの略として説明されている。TypeSafe AIの AI primer では、文章として好まれる応答や検証可能な回答だけでなく、判断と校正された確率へ学習の目的を向けるという位置付けになっている。

この違いは、出力に何を求めるかで考えると分かりやすい。相談に対して親切で読みやすい文章を返すモデルなら、文章の有用さや好ましさが重要になる。数学の答えを求めるモデルなら、答えが正しいかを検証できる場合がある。判断モデルでは、答えの選択だけでなく、どの確率を付けたかも評価したい。

ただし、これらの学習目的が完全に排他的なわけではない。人間の選好を使う学習でも、正直に不確実性を示すことを好ましい応答として評価できる。検証可能な結果を使う学習でも、誤りや不確実性を考慮する設計はあり得る。「RLHFは必ず自信過剰で、RLCDなら必ず正直」という二分法にはしないほうがよい。

Jevについて言えるのは、提供者が判断と校正を目的として明示していることだ。そして、その目的が自分の仕事でも達成されているかは、別に評価しなければならない。学習目的の説明は、評価を不要にする証明ではない。

10.2 名前だけでは報酬関数を復元できない

公開資料からは、実際の学習でどの損失を使い、どう報酬へ変換し、どんなデータ分布で訓練し、どの段階で確率を校正しているかまでは確認できなかった。先に説明したproper scoring ruleは、RLCDを理解する背景としては有用だが、Jevの実装そのものの説明にはならない。

同じ「校正された判断を学習する」という目的でも、直接の確率損失、報酬への組み込み、追加の校正処理、複数の目的の組み合わせなど、設計の選択肢がある。どれを採用したかを確認できないなら、その部分は不明として扱う。

flowchart TD
    A["公開されている学習上の目標"] --> B["判断を返す"]
    A --> C["確率の校正を重視する"]
    D["一般理論: proper scoring rule"] --> E["目標を考えるための背景"]
    E -. "実装を断定する根拠にはならない" .-> F["Jevの具体的な報酬関数や学習手順"]

ここを曖昧にすると、「JevはBrier scoreを使うから確率が正しい」といった、二段階で根拠が抜けた説明になる。実際にBrier scoreを使っているか分からないうえ、仮に使っていても、未知の対象分布で確率が合うことは別の問題だからだ。

10.3 学習時と運用時の分布が違えば、確率もずれる

訓練時には返金相談が多く、運用時には配送相談が多いという違いがあれば、事前の割合が変わる。表現の仕方や規約が変われば、同じ言葉が意味する状態も変わる。新しい料金体系が導入されたら、過去の知識からの判断が合わなくなる場合もある。

校正を目的に学習したモデルも、こうした変化を超えて全ての場面で確率を保証するものではない。運用の入口で対象を絞り、その範囲で評価し、時間が経っても同じ状態かを確認する必要がある。特に「今のモデルは校正されている」と一度だけ判定して終わる運用では、変更後のずれを見逃す。

この点では、モデルの更新も一つの分布変化になる。同じ入力へ同じ形式で問い合わせても、新しいモデルが違う確率を返すことがある。分類の正解率が上がっていても、既存の閾値で扱う自動処理の件数は変わり得る。モデル名と質問の版を記録しておく理由は、ここにもある。

11. confidenceをどう読めばよいのか

11.1 分布の形を一つの値へまとめている

JevのChoiceとScoreにはconfidenceが付く。 公式の説明 では、出力された確率分布の集中度を一つの値へまとめたものとされている。Noulには別のconfidenceは付かない。

ここで重要なのは、confidenceがモデルの内面を直接測った値ではないという点だ。候補へ確率がどれだけ集中しているかという、返ってきた分布の形に関係する値として説明されている。高ければ、候補や段階の間で予測が比較的はっきりしていると解釈できる。

しかし、分布がはっきりしていることと、正解が保証されることは違う。資料を読み違えた結果、一つの候補へ強く寄っている場合もある。候補の定義が間違っていれば、その間違った問題に対して明確な答えが出る。高いconfidenceで誤るケースも、評価で集めて調べる必要がある。

11.2 最大確率、margin、entropyは別の要約になる

分布の形を要約する一般的な方法としては、最大確率を見る方法、上位二つの差を見る方法、entropyを見る方法などがある。ここでの説明は、それぞれの考え方を比較するためで、Jevのconfidenceがどれかの式で計算されていると断定するものではない。確認した公式ページには、具体的な計算式が示されていない。

四択で、次の二つの分布を考える。

最大確率はどちらも0.55だ。しかし、分布Aは候補1と2でほぼ争っている。分布Bは候補1が他の三つに対して明確に大きい。上位二つの差ならAは0.15、Bは0.40になる。一方、分布全体の散らばりを見ると、Bは残りの候補へ広く分かれている。どの観点を重視するかで評価が変わる。

entropyは、離散分布なら次のように書ける。

H = -Σ p_i × log(p_i)

一つの候補へ全て集まっていれば小さく、均等に広がるほど大きくなる。候補数が変われば取り得る最大値も変わるので、そのまま違う数の候補を比較するには注意が必要だ。正規化して使う方法もあるが、どんな正規化も業務上の正しさを自動で表すわけではない。

11.3 Noulの端への近さを、正解確率と混同しない

Noulのpが0.5からどれだけ離れているかを、自分のコードで一つの指標へ変えることはできる。例えば絶対値を使えば、肯定へ強く寄った場合と否定へ強く寄った場合を、どちらも明確な二択として扱える。

端への近さの一例 = 2 × |p - 0.5|

この値はp=0.9でもp=0.1でも0.8になる。しかし、0.8になったから80%の確率で正解という意味ではない。これは0.5からの距離を変換した指標にすぎない。そう解釈したいなら、その値と実際の正解率との関係を評価する必要がある。

特に、肯定の確率が高いことと、判断が明確であることは分けたい。「不正利用か」という質問でpが0.01なら、不正利用という肯定は弱く、否定へ強く寄っている。明確さが高いから不正利用として処理するというコードにしてはいけない。予測した方向と、その方向への確信を別に扱う必要がある。

11.4 一つの閾値を、全ての仕事に使わない

画面の表示順を変える処理と、返金を確定する処理では、間違ったときの影響が違う。confidenceが同じでも、行動を許す条件を同じにする理由はない。元へ戻せるか、利用者へ確認できるか、誤りが外部へ伝わるか、損失がどれくらい大きいかで扱いを変える。

公式のサンプルに出てくる閾値を、そのまま全ての用途へ移すことも避けたい。サンプルは制御の考え方を示すもので、特定の日本語業務で誤りが許容範囲に収まると測定された値ではない。自分の評価データで、閾値を変えると何件が自動処理され、何件が誤るのかを調べるところから始める。

12. 確率から行動へ進むには、損失を考える

12.1 正解を選ぶことと、良い行動を選ぶこと

モデルの出力は予測で、システムが何をするかは意思決定だ。肯定が最もありそうだから肯定側の処理を行う、という規則が適切とは限らない。間違いの影響が左右で違うからだ。

例えば、重大な障害の可能性がある問い合わせを見落とすと大きな損失になるが、通常の問い合わせを詳しい確認へ回してしまう損失は小さいとする。この場合、重大な障害の確率が0.5未満でも、確認へ回すことが合理的になる場合がある。

逆に、返金の実行を考えるなら、誤って返金することと、本来返金できる案件の確認が少し遅れることは対称ではない。さらに顧客の損失や対応の遅延もあるので、単に事業者側の費用だけでは決められない。どの損失をどう扱うかは、人間が定義しなければならない。

12.2 二択の閾値を、簡単な損失表から出す

説明用に、ある問題を「確認対象へ回すか、そのまま通常処理へ進めるか」の二択にする。対象でないのに確認へ回す損失をC_FP、対象なのに通常処理へ流して見落とす損失をC_FNとする。正しく処理した場合の損失は、簡略化して0とする。

確認が必要な確率をpとすると、それぞれの期待損失は次のようになる。

確認へ回す期待損失 = (1 - p) × C_FP
通常処理の期待損失 = p × C_FN

確認へ回すほうが小さくなる条件を整理する。

(1 - p) × C_FP < p × C_FN

p > C_FP / (C_FP + C_FN)

見落としの損失を99、余計な確認の損失を1とすれば、閾値は0.01になる。この単純な仮定では、1%を超える可能性があれば確認へ回すほうが期待損失を小さくする。0.5を使う理由は、左右の誤りを同じ重さに置くなどの条件がある場合に限られる。

ここで使うpは、問題としている出来事への確率だ。一般的なconfidenceをそのまま代入することはできない。また、確率が自分のデータで校正されていなければ、期待損失の計算もずれる。確率の校正と意思決定は、別々の概念だが、この箇所でつながってくる。

12.3 損失表は現実の全てを表せるわけではない

実際には確認の担当者が忙しく、確認へ回す件数が増えると待ち時間が増える。通常処理の誤りも、金額や案件の内容で違う。正しい処理でも費用がかかるし、確認しても間違える場合がある。先ほどの二行の表は、その全てを表したものではない。

それでも損失を明示する価値はある。「0.9以上だから安心」という曖昧な規則より、どんな間違いを減らしたいかが見える。担当者の確認能力を含めて考えるなら、確認後に残る誤りや、待ち時間による損失も加えることになる。

安全、権利、法的な制約のように、平均的な費用へ簡単に変えられない条件もある。期待損失が小さいから権限のない返金を実行してよい、ということにはならない。確率に関係なく守る制約と、確率によって選ぶ行動を分ける必要がある。

flowchart TD
    A["モデルの予測分布"] --> B["対象データで確率を評価する"]
    B --> C["行動ごとの損失と確認費用を定義する"]
    C --> D["候補となる行動を選ぶ"]
    D --> E{"権限と業務上の制約を満たすか"}
    E -->|はい| F["実行または利用者への確認"]
    E -->|いいえ| G["実行しない"]

12.4 「保留」も、一つの行動になる

肯定か否定かだけでなく、保留して情報を増やすという選択肢がある。決済履歴が未取得なら取得する。資料の記載が矛盾していれば担当者へ確認する。顧客の意図が分からなければ追加質問する。保留は、何もしない失敗ではなく、情報を得るための処理だ。

ただし、保留にも費用がある。問い合わせの待ち時間が伸びるし、人間へ回す件数も増える。全て保留すればモデルの誤判断を直接実行せずに済むが、そのシステムを導入する意味が薄くなる。どこまで自動化し、どこから確認するかを、誤りと処理量の両方で考える必要がある。

13. 難しい案件を残す設計と、risk-coverage

13.1 判断できる案件だけを処理する

全ての入力へ必ず答える分類器ではなく、一定の条件を満たした入力だけを処理し、残りを保留する分類器を考える。この問題はselective classificationとして研究されている。 GeifmanとEl-YanivのSelective Classification for Deep Neural Networks は、その代表例の一つだ。

coverageは、全体のうち判断を引き受けた割合になる。riskは、引き受けた案件における誤りや損失として定義する。難しい案件を保留すればriskを下げられる場合があるが、coverageも下がる。どの条件なら、その交換が運用上意味を持つかを見る。

例えば100件のうち80件を自動分類し、そのうち8件を誤ったなら、自動分類された集合の誤り率は10%になる。残り20件を保留したことと、全体の誤りが8%であることと、自動分類部分の誤りが10%であることは別だ。分母を曖昧にすると、保留を増やしただけで性能が良く見える報告になってしまう。

13.2 閾値を変えると何が起きるか

次の表は、仕組みを説明する架空の評価結果だ。実際のJevの測定値ではない。

下へ行くほど自動分類部分の誤りは減っているが、最後は900件の別処理が必要になる。自動分類の3%だけを見ればよく見えるものの、全体の仕事をほとんど減らしていないかもしれない。人間の処理能力を含めて評価したい。

また、閾値を上げれば必ず誤り率が下がるとは限らない。モデルが特定の誤りに強く確信していれば、高い値で残した集合にもその誤りが集まる。confidence順に並べることが、正しさの順序として使えるかを測る必要がある。

13.3 人間へ回した後まで測る

自動化部分だけでなく、保留後の処理も重要だ。担当者へ回した案件が難しいものばかりになれば、従来より確認に時間がかかる。モデルが誤った分類を見せることで、人間がその分類に引っ張られる場合もある。単に人間を挟んだことが、誤りの消滅を意味しない。

運用上は、確認に要した時間、最終的な誤り、利用者への回答までの時間、保留理由などを測りたい。モデルの自動分類を隠した状態で確認する比較も考えられる。誰が確認すればよいかという担当分野の分類と、その確認の品質は、別の評価対象になる。

保留を適切に使うには、受け皿が必要だ。追加情報を取得する処理、担当者の画面、利用者への質問、一定時間での再通知がなければ、単に未処理の案件が増えるだけになる。確率を返せるモデルを使う価値は、こうした後段の設計と一緒に考えたい。

14. Jevそのものを評価した研究から何が読めるか

14.1 判断の識別能力と校正を別々に見ている

Jevを扱った公開研究として、2026年9月24日のプレプリント Just Ask Jev: Reinforcement Learning for Calibrated Decisions as a Zero-Shot Detector of AI Alignment Failures がある。ここでは論文のv1を参照しており、自分で実験を再現した結果ではない。プレプリントの結果を、査読によって確定した事実として扱うこともしない。

対象はjev-1.13.0で、英語のAI alignment failureを扱うベンチマーク群だ。一般的なNoulの質問を使える31ベンチマークで、AUROCの中央値0.886を報告している。一方、まとめた集合のECEは0.047でも、ベンチマークごとのECEの中央値は0.168だった。完全に校正された確率から有限の結果を生成する比較では中央値0.074となり、31のうち24がその比較の95パーセンタイルを超えていた。

読み取りたいのは、確率による順位付けと、個別の対象でその確率をそのまま使えるかが分かれていることだ。全体をまとめた評価だけでは、対象ごとの確率のずれを見逃し得る。ただし、この結果を日本語の問い合わせ分類へ直接移せるわけではない。モデルの版、質問、入力、正解の定義が違う。

14.2 AUROCが高いことは、0.5で分ければよいことではない

AUROCは、閾値を動かしたときの識別の状態をまとめた指標だ。肯定の事例を否定の事例より高く並べられるか、という観点で理解できる。同点の扱いを含めた定義はあるが、初心者向けには「並べ方の良さ」を見るものと考えると分かりやすい。

例えば、肯定の事例へ0.4、否定の事例へ0.2を返すモデルがあれば、両者の順序はよい。しかし0.5で分ければ、全て否定になってしまう。順位がよいことだけでは、予測確率の絶対値が実際の頻度と合うとも、0.5が用途に合うとも言えない。

この例を理由に、閾値を必ず低くすればよいということでもない。運用時の肯定率や、誤りの損失が変われば適切な閾値も変わる。評価用データで閾値を選び、別のデータで確かめる。その手順を飛ばして、公開ベンチマークのよい数値だけから自動化の条件を決めないほうがよい。

研究の面白い点は、Jevの特徴を示すだけでなく、使い方にも条件があると分かるところだ。「校正を目的にしたモデルだから評価を省ける」ではなく、「確率を受け取れるから、識別と校正と行動の条件を別々に測れる」と読むほうが実装へつながる。

14.3 正解ラベルも、観測対象として扱う

ここからは、特定の論文の結果ではなく、自分の用途へ評価を持ち込むときの問題になる。自然言語の判断では、正解ラベル自体が一意に決まらない場合がある。担当部署の分類なら、組織の運用によって送料の質問を請求へ回す場合も、配送へ回す場合もある。

複数の人が違うラベルを付けたとき、それを全てモデルの誤りとして扱うのは適切ではない。まず分類規則が曖昧なのか、資料が足りないのか、人が見落としたのかを確認する。人間の一致率が低い仕事へ、モデルだけ100%の一致を期待することも難しい。

だからといって、人間が割れた事例を全て評価から消すのも違う。運用ではその事例が来る。曖昧な事例を保留すべきか、追加資料を要求すべきか、部署の優先規則で決めるべきかを定義する必要がある。正解データを作る作業は、業務の定義を明確にする作業でもある。

15. 自分の用途で評価するなら、何を測るか

15.1 データを作る前に、質問を固定する

評価を始める前に、モデルへ何を問うかを一度固定する。「請求に関係するか」の正解を付けていたのに、途中から「請求部署へ回すべきか」へ変えれば、同じデータでも正解の意味が変わる。質問とラベルの定義を一緒に版管理したい。

stateの構築方法も固定する。本文だけの入力なのか、注文情報を加えるのか、担当者のメモを含めるのかで課題は変わる。正解が付いた後の担当者のメモを入力へ入れれば、解答が資料の中へ漏れる場合がある。過去の案件を再生するなら、判断時点で利用できた情報だけに制限する。

説明用に、一件の評価記録へ次の項目を残すと考える。実際の保存形式はシステムに合わせればよい。

案件ID
判断時点で使えたstate
質問と候補の版
正解ラベルと、その定義
モデルの識別子
返った確率分布
後段が選んだ行動
応答時間と失敗の種類

個人情報を含む本文を何でも保存すればよいわけではない。再現に必要な情報と、保存してよい情報を分ける。匿名化やアクセス制限、保存期間も必要になる。外部APIへ送信する資料については、その取り扱いを先に確認したい。

15.2 調整用と最終評価用のデータを分ける

質問の書き方を変え、候補の説明を変え、閾値を変えるたびに同じデータを見ていたら、そのデータへ合う設定を選んでいることになる。モデルの重みを変えていなくても、評価の結果を使ってシステムを調整していることは変わらない。

少なくとも、質問や閾値を調整する集合と、最後に性能を確かめる集合は分けたい。同じ顧客のほぼ同じ問い合わせが両方へ入る場合も注意する。ランダムに一件ずつ分けただけでは、同じ出来事の言い換えが両側へ入る可能性がある。

運用で将来の案件を扱うなら、過去の時期で調整し、その後の時期で確認する分け方も考えられる。時間の経過による表現や業務の変化まで含めた評価になる。ただし、期間の中でルールそのものが変わったなら、その変更も記録する必要がある。

flowchart TD
    A["評価対象の案件を集める"] --> B["同じ出来事や利用者の重複を確認する"]
    B --> C["調整用の集合"]
    B --> D["最終評価用の集合"]
    C --> E["質問・候補・閾値を調整する"]
    E --> F["設定を固定する"]
    F --> G["最終評価を一度行う"]
    D --> G
    G --> H["新しい運用データで継続確認する"]

15.3 正解率だけでなく、間違い方を見る

問い合わせ分類なら、全体のaccuracyに加えて混同行列を見る。どの分野をどの分野へ間違えるかが分かる。請求と配送を混同するのか、重大な問題をその他へ落とすのかでは、修正すべき箇所が違う。

二択なら、precisionとrecallを使える。precisionは肯定として扱った中で、実際に肯定だった割合だ。recallは実際の肯定の中で、肯定として拾えた割合になる。確認担当へ回す仕事でrecallを高めれば見落としを減らせる場合があるが、precisionが下がれば余計な確認が増える。

F1はその二つをまとめる一つの方法だが、業務の損失を直接表すものではない。安全上の見落としと、余計な確認を同じ重さで扱ってよいかは別に考える。モデル比較のための指標と、実際の行動を決める指標を区別する。

確率については、Brier score、log loss、校正の区間別の表を確認する。さらに自動処理の閾値を動かし、coverageと処理部分の誤りを確認する。数字が多くなるが、全てを一つへまとめるより、どの性質が良くてどこに問題があるかを説明しやすい。

15.4 少ない件数で「ほぼ間違えない」と言わない

評価で100件を処理して一度も誤らなかったとしても、誤り率が0だと確認されたわけではない。珍しい入力が含まれていない可能性があるし、偶然全て正しかった可能性もある。特にごく高いconfidenceの案件だけを選ぶと、その部分の件数は少なくなる。

簡単な目安として、独立で同じ誤り率を持つ試行をn回行い、誤りが0だった場合を考える。誤り率rに対して全て正しい確率は次のようになる。

誤りが0回になる確率 = (1 - r)^n

これを0.05へ合わせると、rの片側95%上限は1 - 0.05^(1/n)になる。nが十分大きい場合は約3/nなので、100件で誤りが0でも、上限の目安は約3%になる。これは仮定を置いた二項モデルの計算で、実際の問い合わせが独立とは限らない。少なくとも「100件で無事故だから誤り率0.1%以下」とは言えないことが分かる。

同じパターンの問い合わせを何百件も集めれば、件数は増えるが、珍しい表現や資料の欠落を試したことにはならない。通常の分布を測る集合と、失敗しそうな条件を狙った集合を分けて持つほうがよい。後者から通常時の発生頻度を推定することはできないが、壊れ方を見つける役に立つ。

15.5 APIの失敗も、モデルの間違いとは別に測る

答えが誤ったことと、APIから答えが返らなかったことは別だ。タイムアウト、認証エラー、レート制限、通信エラー、想定外のレスポンスを全て否定として扱うと、正常な予測の分布へ運用の障害が混ざる。

返金要求の検出APIが落ちたときに「返金要求なし」と記録してしまえば、業務の分類も評価のデータも壊れる。失敗は失敗として記録し、再試行するか、保留するか、別の方法へ戻すかを決める。正常なNoulの0と、答えが存在しない状態を同じ値へ変換しないことが大事だ。

応答時間も中央値だけでなく、遅い側を見る。普段は速くても一部の問い合わせで長く待つなら、その間の画面や保留処理が必要になる。費用もAPIの呼び出しだけでなく、人間の確認と誤分類の対応を含める。モデル単体の小さい費用が、そのままシステム全体の小さい費用になるとは限らない。

16. 問い合わせを振り分ける小さな構成

16.1 まず、モデルを使わない処理を終わらせる

ここまでの話を、問い合わせの振り分けへ戻してみる。入力を受け取ったら、まず認証と権限を確認する。注文IDがあれば形式を検証して、許された範囲で注文情報を取得する。これらはJevに判断させる処理ではない。

次に、本文と確認済みの情報からstateを作る。顧客の主張、取得した事実、まだ確認していない項目を分ける。その状態で、担当分野と返金要求の有無を聞く。緊急性も必要なら別の質問として追加するが、最初からあらゆる観点をモデルへ聞く必要はない。

flowchart TD
    A["問い合わせを受け取る"] --> B["認証・権限・入力形式の確認"]
    B --> C["必要な注文情報を取得する"]
    C --> D["主張・事実・未確認を分けてstateを作る"]
    D --> E["Jevへ担当分野と意図を聞く"]
    E --> F{"APIが正常に応答したか"}
    F -->|いいえ| G["失敗として記録し、保留する"]
    F -->|はい| H["分布と運用ルールを評価する"]
    H --> I["振り分け・追加確認・保留"]

16.2 リクエストは、stateと質問の集合になる

APIのリファレンス で公開されている形では、/v1/systemoneへmodel、state、questionsを送る。次は問い合わせ分類用に自分で作ったリクエスト本体の例だ。モデルの指定は利用できる識別子へ置き換える必要があり、この例自体を実行した結果ではない。

{
  "model": "<利用するモデルの識別子>",
  "state": {
    "customer_message": "カードに二回請求されたようです。片方を戻してもらえますか。",
    "payment_check": "未実施",
    "order_status": "発送済み"
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "本文の主な相談内容に対応する担当分野を選ぶ。実際に二重請求が起きたかは判定しない。",
      "criteria": {
        "billing": "料金、支払い、請求、返金に関する相談",
        "delivery": "発送、配送、受け取りに関する相談",
        "product": "商品の仕様や使い方に関する相談",
        "other": "上記に当てはまらない、または主な相談内容を特定できない"
      }
    },
    "refund_intent": {
      "type": "noul",
      "instructions": "本文に、お金を戻してほしいという要求の意図が含まれているか。返金の可否は判定しない。"
    }
  }
}

この例の目的は、返金できると結論を出すことではない。請求の相談として扱うことと、返金を求める意図を読み取ることを切り出している。決済の確認が未実施であることは、その後の処理を止めるための別の状態になる。

質問のキーは、後段のコードがどの結果かを識別するために使う。分類の出力を返金の承認として扱わないように、キーや型を分けると実装上の混同を減らせる。ただし、よい名前を付けること自体がセキュリティ対策になるわけではない。実行側で権限と状態を確認する必要がある。

16.3 出力を受け取ったら、すぐ実行しない

APIの出力はまず型と内容を検査する。必要な質問への答えがあるか、候補が許された集合に入っているか、確率が有限の値か、分布が想定に合っているかを確認する。サービス側が型付きの応答を提供していても、通信やバージョン変更に備え、利用側の境界で確認する理由は残る。

次に、評価で決めた運用条件を適用する。担当分野が曖昧なら追加確認へ回す。請求分野へ明確に寄っていても、返金そのものは決済情報を確認した後の処理にする。ここで判断の型を行動の権限へ変換しないことが重要になる。

生成LLMを後段へ置くなら、案内文を書くための役割に限定できる。「二重請求であることが確認されました」と勝手に書かせるのではなく、確認がまだ終わっていないことを資料に含める。モデルを二つ組み合わせる場合も、前段の推測を後段で確認済みの事実へ格上げしないようにする。

16.4 監査に必要なのは、流暢な理由文だけではない

Jevが自由な説明を出さないことを、監査ができないことと同一視する必要はない。どの資料をどの質問へ渡し、どんな分布が返り、どんなルールで行動を選んだかは記録できる。後から同じモデルで完全に同じ値が再現される保証とは別だが、その時点の入力と出力を保存すれば追跡の材料になる。

一方、数値だけでは、モデルがどの記述を重視したかを直接確認できない。別のLLMへ説明を求めても、その説明がJev内部の計算を忠実に復元したと扱うことはできない。説明文は、入力を解釈する助けや人間の確認材料にはなっても、判断モデルの内部証明にはならない。

監査では、事実の出所、質問の定義、適用された規則、実際の結果が重要になる。決済履歴が一件しかないのに二重請求の返金をしたなら、流暢な理由が付いていても問題は解決しない。まず、どの段階で未確認の情報を確定させたかを追う必要がある。

17. Jevへ任せないほうがよい仕事

17.1 正確な計算や状態管理を、判断問題へ変えない

請求額の合計、日付の差、注文の所有者、返金済みかどうかは、できるならデータとコードで確定する。モデルが自然言語を理解できるからといって、全ての計算を文章にして聞く必要はない。

例えば、返金可能期間が購入から30日と決まっていて、購入日時が記録されているなら、日時とタイムゾーンを使って判定する。文章で「一か月くらい前」としか言われていない場合は、日時を取得する必要がある。そこをモデルの確信で埋めると、実際には確認できていない条件を通してしまう。

Jevは数値を返すので、計算器に近く見えるかもしれない。しかし、出力が数値であることと、入力中の数値に対して厳密な算術を保証することは別だ。Scoreも、段階へ割り当てた確率をまとめる値であり、請求額の計算結果を表すものではない。

17.2 公開されている不得意な条件も確認する

TypeSafe AIは、 Jev 1.13 jaggedness として、その版の得意不得意を説明している。正確な計算、複雑な多段の推論、長い不要情報、質問間の論理的な一致などを、自動的に保証するものではない。また、 stateの説明 では、主に英語で訓練されていることと、CJK言語での精度について注意が示されている。

この説明は確認した版と資料の範囲で読む必要がある。将来の全てのJevが同じ制約を持つと断定するものでもないし、日本語で一律に使えないという意味でもない。自分が扱う日本語の省略、敬語、遠回しな要求、業界用語でどう振る舞うかを測る必要がある。

例えば「返金してほしい」と直接書く人だけではない。「この請求、どうにかなりませんか」「片方は取り消せないでしょうか」と書く人もいる。否定を含んだ言い方や、引用された過去の会話もある。こうした表現を評価の対象へ入れないと、単純な例だけで良い結果を確認して終わってしまう。

17.3 検索と判断は、別の段階になる

大量の文書から関係しそうなものを探すなら、全文検索やEmbedding modelで候補を絞ることができる。Jevへ全ての文書を渡して関連度を聞くことも形式上は考えられるが、そのための通信量や費用、資料の制限を考える必要がある。

検索は「候補を見つける」仕事で、判断は「その候補が条件を満たすかを評価する」仕事だ。検索で候補を落とせば、後段の判断モデルはその文書を見られない。Jevが優秀でも、取得されなかった証拠を使うことはできない。検索のrecallと判断の品質を別に評価する必要がある。

さらに、Embeddingの近さは、質問への肯定確率と同じではない。似た言葉を含む規約が見つかっても、対象の商品や契約期間が違う場合がある。「似ている」から「適用できる」へ進むには、必要な条件の確認が残る。逆に、文書IDや契約の版が既に分かっているなら、意味検索を使わず直接取得したほうが確実な場合もある。

18. LLM、Jev、検索、ルールをどう分担するか

18.1 一つの技術で最初から最後まで処理しない

システムの各段階で、何が未確定なのかを考える。探す資料が分からないなら検索する。資料があり、条件に関する意味判断が必要ならJevを候補にする。文章を作る必要があるならLLMを使う。形式と値が確定していて規則で計算できるならコードで処理する。

Jevは、この表の全てを置き換えるものではない。自然言語から判断を取り出す部分を、生成する文章とは別の部品にするための選択肢だ。分類器を自分で学習できる仕事なら、それも比較対象になる。十分なラベルがあり、対象が狭く固定されているなら、既存の機械学習やルールで必要な性能を出せる場合がある。

18.2 最初はモデルで、後から規則へ置き換えることもある

開発の初期には、問い合わせの表現が分からず、どんな分類があるかも固まっていない。その段階でLLMやJevを使うと、未知の入力を整理しながら仕様を作ることができる。しかし、運用で例が集まり、条件が明確になった後も、全てを同じモデルで処理し続ける必要はない。

例えば、特定のフォームから送られる固定の問い合わせでは、フォームの種類から担当部署が確定するかもしれない。料金の規則が明確になれば、返金条件の多くをコードへ移せる。残った自由記述だけをモデルへ渡せば、費用や待ち時間だけでなく、誤る場所も減らせる。

この置き換えは、モデルの敗北という話ではない。最初に曖昧だった仕事が、観測と仕様化によって決定的な仕事へ変わったということだ。使う技術は、その時点で残っている不確実性に合わせて見直すほうが自然だと思う。

18.3 複数モデルを重ねる前に、何を確認するか決める

Jevの判断を別のLLMで確認すれば安心、という設計もすぐには成立しない。二つとも同じ不足した資料を読めば、同じ方向へ間違える可能性がある。片方の答えをもう片方へ見せれば、その答えに引っ張られることもある。

別のモデルを使うなら、何を新しく確認するかを定義したい。候補の意味を読み直すのか、見落とした証拠を探すのか、質問とstateの不一致を調べるのかで役割は違う。確定できる証拠があるなら、モデルを重ねるより、その証拠を取得するほうがよい場合もある。

複数のモデルが同意したことは、一つの観測として使える。しかし、同意した数をそのまま正解確率へ変換するには、その組み合わせでの評価が必要になる。各モデルの誤りが独立とは限らないという問題は、ここでも残る。

19. Jevを使う前に、小さく確かめたいこと

初めから本番の行動を任せるより、既存の処理と並行して予測だけを記録する方法がある。担当者へ表示せずに判断させ、その後の確定結果と比較すれば、モデルが人間の判断へ影響を与えない状態で観測できる。この段階では、誤った出力が実行へ直結しない。

最初に選ぶ仕事は、入力と答えの定義が比較的はっきりしているものがよい。担当分野の候補が整理されている問い合わせ分類などだ。逆に、契約上の承認、医療上の判定、利用者の権利へ大きく影響する処理を、少数の成功例だけから自動化するべきではない。

比較対象も置きたい。多数派を常に選ぶだけの方法、単純なキーワード規則、既存の分類器、構造化出力のLLMなどだ。Jevだけ測ると、何に対して改善したのか分からない。全体の正解率が高くても、もともと簡単な案件が多いだけかもしれない。

次に、確率の集計と誤りの観察を行う。高い値で間違えた案件を読み、入力の欠落、候補の重複、質問の曖昧さ、言語の違いなどを分類する。ここで質問を変えたら、再び別のデータで確かめる。評価を繰り返した同じ集合で、最後の数字だけを報告しない。

実際に自動化する場合も、最初は元へ戻せる処理から始める。担当の候補を提示する、検索結果の優先順位を変えるなどで、影響を観測する。誤りの損失が大きい行動には、別の確認を残す。モデルの出力と実行結果を関連付けて記録しておけば、問題が起きたときに戻って調べられる。

モデルや質問を更新するときは、固定した代表例で回帰を確認する。ただし、固定した例だけでは新しい問題を見つけられない。最近の運用データも、保存の条件を守りながら評価へ取り込む。モデルを導入した後も、判断する対象は変化し続ける。

20. まとめ: 判断を文章から切り離すと、設計するものが見える

Jevは、自然言語の入力に対して自由な文章を返す代わりに、定義された質問へ判断と確率を返すモデルだ。Noulは二択、Choiceは候補、Scoreは順序付きの段階を扱う。公開資料では、並列の評価と、RLCDによる校正された判断を目的としていることが説明されている。ただし、具体的な内部構造や学習の報酬関数まで確認できたわけではない。

LLMを判断に使う場合、答えの形式、文章生成の待ち時間、説明と証拠の違い、確率の解釈などが問題になることがある。Jevは、その仕事を判断向けの入出力へ切り出す選択肢になる。しかし、形式が揃っていることは意味が正しいことではなく、分布が集中していることは必ず当たることでもない。

確率を利用するなら、正解率だけでは足りない。対象のデータで、予測した確率と実際の頻度が合っているかを確認する。高い値の案件を自動処理する場合も、引き受ける割合と、その部分の誤りを一緒に測る。公開されたJevの研究も、識別能力の評価と、個別の対象での校正を分けて読む必要があった。

さらに、確率から行動へ進む段階には、人間が決めることが残る。何を正解と呼ぶか、どの証拠を必要とするか、見落としと誤処理をどう扱うか、何を保留するか、どの行動には確認が必要か。認証、権限、業務の不変条件も、モデルの確信によって省略してよいものではない。

自分がJevに感じる面白さは、単に短いJSONを返すことより、文章の生成と判断の出力を分けて考えられるところにある。何を聞いているか、どんな確率を受け取り、その結果をどう使うかを、システムの部品として見直せる。そこで曖昧な部分をモデルに任せる一方、確定できる部分はコードへ戻す。その分担を決めることが、使う側の仕事になる。

参考資料

本文のリンクは、それぞれの説明の根拠へ直接つなげている。読み進める順序としては、まず公式の入出力を確認し、次に校正と確率予測の基礎理論、最後にJevを対象にした評価研究を見ると理解しやすい。

• TypeSafe AI: Introduction : Jevと判断モデルの概要。
• TypeSafe AI: System One : 生成と判断の違いについての公式説明。
• TypeSafe AI: Noul 、 Choice 、 Score : 出力形式の定義。
• TypeSafe AI: Confidence : 分布とconfidenceの関係。
• TypeSafe AI: AI primer : RLCDの位置付け。
• Guo et al., On Calibration of Modern Neural Networks, ICML 2017 : 分類性能と校正の区別。
• Gneiting and Raftery, Strictly Proper Scoring Rules, Prediction, and Estimation, 2007 : 確率予測を採点する理論。
• Geifman and El-Yaniv, Selective Classification for Deep Neural Networks, NeurIPS 2017 : 保留を含む分類とrisk-coverage。
• Guo et al., Just Ask Jev, arXiv:2609.29429v1, 2026 : Jevを判断用途で評価したプレプリント。

資料の確認日は2026年10月1日。この記事の問い合わせ例、確率の表、損失の計算例は、断りのある研究結果を除き説明用に作ったもので、Jev APIで実測した結果ではない。