Jev — 文章を書かないLLM、判断だけを速く

LLMに「この問い合わせは請求の件？不具合の件？JSONで答えて」とやらせたことがあるなら、Jevが狙っているのはまさにそこだ。Jevは文章をまったく書かず、決めた選択肢ごとに確率だけを返す。この記事を読めば、自分のサービスのどのAI呼び出しを判断専用モデルに置き換えられるか選べるようになる。

TypeSafe AIが2026-09-15に公開し、自ら「System One Model」と呼んでいる。速く直感で選ぶ側（System 1）だけを受け持つという名前だ。

入力はLLM、出力は分類器

入力   自然文の状況説明 + プログラムの状態 + 選択肢の一覧
出力   選択肢ごとの確率   {"approve": 0.91, "reject": 0.06, "escalate": 0.03}

文字列の生成を捨てたので、型が壊れることがない。公式記事によればRLCD（Reinforcement Learning for Calibrated Decisions）で学習していて、確率が較正（calibrated）されている。較正されているとは、0.9と言ったら実際に10回中9回は当たるという意味だ。

使う側から見ると「学習のいらないBERT」に近いと感じた。中身がBERTだという話ではない。公式記事は新しいアーキテクチャだとしか言っておらず、詳細は明かしていない。使い心地がそうだということだ。

BERT・LLMと並べると

	BERT系の分類器	LLM（structured output）	Jev
タスクごとの学習	必要（ファインチューニング）	不要	不要
選択肢を決めるタイミング	学習時に固定	プロンプトで	呼び出しごとに自由
出力	ラベルの確率	テキスト（JSON）— たまに壊れる	型付きの値 + 確率
確率の信頼度	過信しがち	実質なし	較正済みと主張
理由の説明	なし	あり	なし
レイテンシ	とても速い	秒単位	70〜500ms（公式）
コスト	自前ホスティング	出力トークンが高い	入力 $0.042/100万トークン、出力無料（公式）

価格は公式記事の値だ。著者自身が「補助金の入った価格ではないと証明はできない」と書いているので、この値がずっと続くとは思わない方がいい。

肝は「わからない」と言ってくれること

速さよりこちらが大きい。確率が信用できれば、しきい値で仕事を3つに分けられる。

case answer['confidence']
when 0.9.. then auto_apply!(answer['choice'])  # 自動確定
when 0.5...0.9 then flag_for_review!(answer)    # 人が見て確定
else escalate_to_human!                         # 人（またはLLM）に回す
end

しきい値は間違えたときの被害に合わせる。読み取りだけなら低めに、削除・課金・送信なら0.9以上。全部を自動確定にする設計は作らない。自分たちのコードにつなぐための利用ルールをまとめたとき、真っ先に書いたのがこの一行だった。

使うところ、使わないところ

使う： モデルのルーティング（簡単なものは安いモデル、難しいものは高いモデル）、画面操作の自動化（ボタンの一覧を渡してボタンごとの確率をもらう）、正規表現であきらめていた自然文の判定、問い合わせ分類のような大量分類。

使わない： 判断の根拠を残す必要がある業務（理由を返さない）、画像入力（今はテキストのみ）、選択肢が256個以上（直接選べる上限は255）。

Chrome内蔵LLMが「ブラウザで補助だけ」だったとすれば（Chrome内蔵LLMはタダのAPIではない）、Jevはその反対側にいる。サーバーで、判定そのものを速く安くやる。

まだ確かめていないこと

自分のデータで精度と較正はまだ測っていない。0.9の区間が本当に90%当たるのか（reliability diagram）、同じタスクでLLMのstructured outputと速度・コスト・精度がどう違うのかは、測ってから追記する。それまでは表のレイテンシ・価格・較正はすべて公式の主張だ。

LLMで分類やルーティングを回していて、コストや速度が負担になっているなら、negabaroに相談してもらって構わない。どの呼び出しを判断専用モデルに切り出し、どれをLLMに残すか、一緒に仕分けられる。