Jev はテキストを生成せず、確率だけを出力する。「ひとつの判断」を API にした製品が解こうとしている問題を、実際に試してみた
TypeSafe AI の Jev は、モデルの出力を文字列から確率付きの型付き判断に置き換え、その確率は「キャリブレーション済み」だと主張している。この前提を裏付ける証拠は誰も出していない——そこで我々は、確定した答えのある229件の主張を用意し、通常の LLM の確信度が自動化に使えるのかを測った。
日本語
コピー
2026年9月15日、TypeSafe AIはJevを発表した。テキストを生成せず、確率付きの型付き判断だけを返すモデルだ。売りは「より賢い」ことではなく、「ソフトウェアからそのまま使える」こと——そして確率が校正されていることにある。この記事では、その位置づけ、論争、エンジニアリングとしての形を整理し、誰も検証していない前提を実測する。
大規模モデルの判断はすでに十分正確だが、自動化は進んでいない。TypeSafe AIの創業者Diogo Almeidaは、この問題をそのまま自分の創業テーマにした。OpenAIでは、言語モデルに指示追従を学ばせる手法（ChatGPTの背後にある研究の一部）に関わった。退社後、2年をかけて一見地味なことに取り組んだ——モデルの出力を「文字列」から「判断」に変えることだ。
Jevはまさにそれで、state（テキストでも構造化データでもよい）といくつかの型付きの問いを渡すと、テキスト生成は行わず、型付きの答えと確率分布を直接返す。3つのプリミティブが、3種類の問いの形に対応する。
| プリミティブ | 何を問うか | 返すもの |
|---|---|---|
Choice | これらの選択肢のどれか？ | choice、probabilities（選択肢上の分布）、confidence |
Score | どの等級に落ちるか？ | score（小数可、等級上の期待値）、legend、probabilities、confidence |
Noul | この文は真か？ | noul（0〜1の確率、独立したconfidenceはない） |
公式ドキュメントの例はこうなっている（quickstart）。
response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={"billing": "Payment or subscription issues", "technical": "Bugs or integration problems"},
),
"frustration": Score(instructions="How frustrated the customer appears", criteria=[...]),
"is_urgent": Noul(instructions="The message conveys urgency or time-sensitivity"),
},
)
response.answers["department"].choice # "billing"
response.answers["frustration"].score # 1.035
response.answers["is_urgent"].noul # 0.9993つの語はいずれも吟味に値する。Choiceの選択肢は自分で与えるもので（最大255個）、モデルはその中からしか選ばず、宣言していないカテゴリを勝手に作ることはない。Scoreが返すのは等級番号ではなく期待値なので、1.035のような小数が普通の出力になる。Noulは確率を1つだけ返し、それ自体がシグナルだ。
1回の呼び出しに複数の問いを詰め込める。ドキュメントによれば、各問いは「同じstateに対して独立に並列評価」され、「問いを追加しても応答時間はほとんど変わらず、その問いの分のトークンが増えるだけ」だという——この点は記事の後半で個別に検証する。
結局何を売っているのか
TypeSafe自身の対照表はかなり率直だ。LLMはRLHF/RLVRで訓練され、「人間が好む回答」と「検証可能な報酬」を最適化する。System Oneは同社がRLCD（Reinforcement Learning for Calibrated Decisions）と呼ぶ手法で訓練され、「校正の意味で正直な確率」を最適化する。使用感に対応させるとこうなる。
| 既存のLLM | Jev（公式の説明） | |
|---|---|---|
| 出力 | 文字列：正しい、誤り、拒否、幻覚のいずれもありうる | 型付きの値：宣言した選択肢しかありえない |
| 判断に使うための追加作業 | パース＋検証＋たまに起きるフォーマット崩壊への対処 | 不要（「型エラー」を学ぶこと自体が不可能で、数学的にありえないと公式は言う） |
| サンプリング | 自己回帰、トークン1つずつ | 並列、1回のフォワードで全回答 |
| レイテンシ | エンドツーエンドで3〜329秒（同社が引用するデータ） | 70〜500ミリ秒 |
| 価格 | 入力 $0.20〜10 / MTok、出力は入力の約5倍 | 入力 $0.042 / MTok、出力は課金なし |
| 信頼度 | 問い詰めれば答えるが、過信しやすく一貫しない | 各回答に付属。校正済みと主張：信頼度が高ければより正確なはず |
トップページには2つの数字が掲げられている。193.6倍高速、444.6倍安価（同社自身の4つのworkflowでの評価に基づき、比較対象はGPT-6 AstraとFable 5.1の平均）。トップページのデモは別の数値を使っている。Jevが0.114秒 / $0.000081、比較対象のLLMが8.566秒 / $0.013880。
名前にはいずれも出典がある。System One / System TwoはKahnemanの『ファスト&スロー』（速く直感的 vs 遅く推論的）から。JevはWilliam Stanley Jevonsから——蒸気機関の効率が上がった後、石炭の消費は減らずむしろ増えた、いわゆるジェヴォンズのパラドックスだ。TypeSafeの主張はこうだ。知能が1桁安くなれば、新しい使い方が何桁も生まれる。
論争：3者が「新しいか」を争い、「前提が成り立つか」は誰も検証していない
Jevは発表当日、Hacker Newsでかなり徹底的に分解された（議論）。ある人は一言でまとめた。「これは要するにzero-shot分類器だ」——TypeSafeの創業者は 「exactly right!」 と返した。技術的な記述を会社自ら認めたことで、議論は「これは何か」から「どこが新しいのか」へ移った。
| 何に似ているという指摘 | 誰が | 要点 |
|---|---|---|
| encoder分類器（BERT / DeBERTa） | 複数 | そもそもテキストを生成せず、幻覚もなく、推論も速い |
| GLiNER2 / GLiClass | 複数 | encoder路線で、1回のフォワードで複数タスクを出す |
| 制約付きデコーディング＋logitsの読み取り | 複数 | LLMをschemaに押し込み、logitsから確率を読む |
| テキスト拡散モデル | 複数 | 「並列生成」は拡散型デコーディングの特徴 |
| Conformal prediction | 1人 | 「conformal predictionを製品化しただけに感じる」 |
| DSPyの型付きシグネチャ | 1人 | モデルの上に型付き予測の抽象をかぶせるのは定番の套路 |
対立面を最も完整に書いているのは Sean Goedecke の「Jev means structured output is interesting again」だ。彼はインターフェースはクールだと認めつつ、高速な構造化出力は今日すでにあると主張する。回答を "choice": " で事前充填し、モデルには制約付きのトークンを1つだけ生成させ、logprobs から確率を読む——自分の Qwen2.5-1.5B-Instruct で試したところ2〜3倍の高速化が得られ、「Jev には本質的な技術的堀はないかもしれない」と結論づけている。
同じ記事には、この記事の出発点になる一文がある：
Jev claims that their generated probabilities are "calibrated", but I haven't seen anything to suggest that these aren't just regular logit probabilities. … If so, I wish they'd written more about that in the announcement.
訳すとこうだ：誰も（TypeSafe 自身も含めて）キャリブレーション曲線を出していない。 「幻覚を起こさない」という主張については彼らは誠実で、ブログには「我々の数値は経験的なものではなく、schema の一致は数学的に保証されている」と書いてある。だがそれは「宣言していない選択肢を返さない」ことしか保証せず、正しく選ぶことは保証しない。Goedecke はこれを「意味論的な詭弁」と呼ぶ。より正確に言うなら、これは「でたらめを言わない」と「間違えない」を切り離したのだ。前者は型システムの功績で、後者は証明されていない。
Hacker News にはずっと誰も答えていない質問が2つあり、これが最も価値のある2つでもある：
- RLCD は訓練目標の何を変えたのか？ その利点はアーキテクチャの変更と切り離せるのか？ 会社は「アーキテクチャは当面非公開、いずれ論文を書く」と言うだけだ。
- 「キャリブレーション」は何と比べているのか？ 「フロンティア LLM と同じくらいキャリブレーションされていて、ただ安いだけ」なら、ハードルはかなり低いかもしれない。「フロンティア LLM よりずっとよくキャリブレーションされている」なら、曲線が必要だ。
我々は Jev の early access を手に入れられない（waitlist があるだけで、公開された重みもまだない）。だから彼らの数値を検証することはできない。だが前提なら検証できる：普通の LLM が構造化された判断に対して出す確率は、自動化された意思決定に使えるのか？ 使えないなら、欠けているのは訓練目標なのか、それともプロンプトの書き方なのか？
ここからが実測パートだ。まずエンジニアリングとしての形をはっきりさせておく。「使う価値があるか」という問いの半分は、どう使うつもりかで決まるからだ。
エンジニアリングとしての形：置き換えようとしているのはチャットモデルではない
公式ドキュメントは4つのパターンを挙げていて、これは設計に取り込む価値がある（patterns）：
| パターン | やること |
|---|---|
| Speculative Fan-Out | 1回の呼び出しで、使う可能性のある問いを全部聞く（一部の入力でしか必要にならない問いも含む）。どの答えを使うかはコードが決める。限界コストが低く、「使わないかもしれない問いを1つ聞くのはほぼ無料」 |
| Confidence-Gated Routing | confidence を2本目の意思決定軸にする。高信頼なら自動実行、中信頼なら人に確認させ、低信頼なら実行しない |
| Composite Scoring | 「このチケットがどれだけ緊急か」を深刻度・感情・対応可能性の3つの Score に分解し、重みはプロンプトではなくコードに書く |
| Intent Routing | ユーザーの意図を分類し、対応する handler にルーティングする |
この使い方には暗黙の規律があり、ドキュメント自身も強調している：1つの問いでは、数秒で判断できることを1つだけ聞く。「このスタートアップのピッチは良いか」を判断したいなら、市場規模・技術的実現性・差別化の3つの独立した問いに分解し、コード側で重み付けする。理由は精度だけではない——重みがコードにあれば、優先度を変えるのは係数を1つ変えるだけで、プロンプトを書き直さなくていい。
Jev を既存のやり方と並べて比べる（左3列は pearpages の整理、右1列は我々の補足）：
| やり方 | ラベルデータ | レイテンシ | 判断1回のコスト | 確率の質 |
|---|---|---|---|---|
| 分類器の微調整（BERT 系） | 必要、数千件から | ミリ秒 | ほぼゼロ | ネイティブだが、キャリブレーションは自分でやる |
| 制約付きデコード + logprobs を読む | 不要 | 数百ミリ秒〜秒 | プロンプト量 | logits の生値、粗い |
| LLM + JSON schema（モデルに自信を自己申告させる） | 不要 | 秒〜分 | 入力 + 出力 | 自己申告、信頼できない |
| Jev（公式の主張） | 不要 | 70〜500ミリ秒 | 入力のみ、$0.042/MTok | ネイティブ、未検証 |
制約もはっきりしている：依存チェーンがない——同じリクエスト内の問いは互いに独立で、後の問いは前の答えを条件にできない。直列につなぐならリクエストをもう一度送る必要がある。リクエスト予算は約 32k token。画像と音声の入力は非対応。Choice は最大255個の選択肢。重みも論文もなく、コンテキスト／レート制限／リージョン／データ保持ポリシーも公開されていない。
これは公式ドキュメントと、私が読んだ第三者による分析の結論だ。ここからは、我々自身が実際に走らせて得た数字を示す。
実測：「信頼度」をしきい値として使うと何が起きるか
我々の問いは単純だ：公式が推奨する confidence-gated routing で自動化を組むとき、そのしきい値の軸は信用できるのか？
やり方はこうだ（完全なスクリプトと生の出力はリポジトリの content/system-one-models-jev-2026-09/verify/ にあり、コマンド一発で再実行できる）：
- 問題：229 問。各問には確定した答えがある。state は本サイトの既存記事から切り出した本文の一節（700〜2200 字。これらの記事は 2026 年 9 月に書かれたもので、モデルが暗記しているはずがない）。claim は state 内の原文そのまま（真）か、原文に単一点の改変を加えたもの（数値は有効数字一桁だけ変える、桁の単位、実体の置換、方向の反転）のいずれか。さらに最難関の一档を用意した：記事をまたぐ陳述——別の記事から具体的な量級を含む文を持ってきて、この state がそれを支持するかと問う。規則に従えば答えは「支持しない」だ。
- 確率の取り方が 8 通り。同じモデル、同じ問題群で：
| 条件 | 確率の出どころ |
|---|---|
| 自由テキスト · 判定が先 | モデルの自己申告（支持 1.00） |
| 自由テキスト · 確率が先 | モデルの自己申告、語順を反転（1.00 支持） |
JSON モード · probability フィールド | モデルの自己申告 |
| 自由テキスト · 意味を固定 | P= <支持的概率> VERDICT= <支持｜不支持> |
| JSON モード · 意味を固定 | フィールド名は p_supported、プロンプトに「claim が支持される確率」と明記 |
| 先頭 token の logprobs | Yes/No のみ回答させ、最初の token の確率を読む |
| 単一 token をプリフィル + logprobs | 回答を Verdict:、max_tokens=1 にプリフィルし、その 1 token の確率を読む（Goedecke が言う方法。beta エンドポイント経由） |
| 同じ問いを 5 回 | temperature=0.7 を 5 回走らせ、Yes の割合を取る |
結果1：正解率はほとんどばらつかない
| 確率の取り方 | 採点可能 | パース失敗 | 正解率 | 誤り数 |
|---|---|---|---|---|
| 自由テキスト · 判定が先 | 228/229 | 1 | 99.6% | 1 |
| 自由テキスト · 確率が先 | 227/229 | 2 | 99.6% | 1 |
JSON · probability フィールド | 227/229 | 2 | 100.0% | 0 |
| 自由テキスト · 意味を固定 | 226/229 | 3 | 100.0% | 0 |
| JSON · 意味を固定 | 227/229 | 2 | 99.6% | 1 |
| 先頭 token の logprobs | 228/229 | 1 | 100.0% | 0 |
| 単一 token をプリフィル | 229/229 | 0 | 99.1% | 2 |
| 5 回サンプリング | 229/229 | 0 | 99.1% | 2 |
8 通りを合わせても誤りは 7 個しかなく、しかも 4 点に集中している：15 秒内 → 16 秒内（3 回）、Claude 或 ChatGPT → OpenAI 或 ChatGPT（2 回）、半夜 11 点 → 12 点、SDK 54 → SDK 55。要するに、この問題群では「聞き方を変える」ことでモデルがより正確になることも、より不正確になることもない——我々が当初見たかった「LLM は平気で嘘をつく」という話とは別物だ。
結果2：本当にばらつくのは「この確率が使えるかどうか」
同じ問題群、同じモデルで、確率の取り方だけを変える。信頼度 ≥0.9 のときの自動化カバレッジは 64% から 100% まで振れる：
この列の差がどれほど意味を持つか。たとえば「確信度 ≥0.9」を自動実行のしきい値にするとしよう。JSON モードで自己申告させると、本来は完全に正しい判断のうち三分の一を人手による確認に回すことになる。一方、logprobs を読む方式ならほぼすべてが自動で通過し、誤りは 0 件だ。払っているのはモデルの代金ではなく、「確率の取り方」の代金である。
結果3：モデルが自己申告するあの数字は、何を指しているのか
このデータ全体で最も面白いマスだ。直感に反するのはここである。同じモデル、同じ問題群で、「確率」を判定の前に書くか後に書くかだけで、同じ数字の意味が変わる。
- 判定が先（
支持 1.00）の場合、125 件の否定回答すべてに ≥0.9 の数字が付いた——このときモデルは明らかにこの数字を「自分がその判定にどれだけ自信があるか」と捉えている。 - 確率が先（
0.99 支持）の場合、同じ問題群でも 88 件は依然としてそうだが、36 件は0.00 不支持に変わった——同じプロンプトの下で、モデル自身が「この数字は何か」を統一できていない。 - JSON モードはさらに混沌としている。44 件が「不支持 + 高スコア」、81 件が「不支持 + 低スコア」で、同じ問題群の中で 2 通りの読み方が半々になっている。
- 意味をプロンプトに書き込む（
P=/p_supported、かつ「これは claim が支持される確率であり、あなたが判定にどれだけ自信があるかではない」と明記する）と、読み方不明は 0 件に減った。
ECE（期待キャリブレーション誤差）を自分で計算しても同じことが見えてくる。JSON モードの自己申告 ECE は 0.359、自由テキスト（判定が先）は 0.002、logprobs を読む方式は 0.000。この 0.359 は「モデルの過信」ではなく意味の混乱だ——食い違いはすべてあの 81+44 件から来ている。
結果4：最速の方法は Goedecke のあの手
回答を Verdict: にプリフィルし、モデルには 1 トークンだけ生成させて、logprobs を読む：
| 確率の取り方 | レイテンシ p50 / p95 | ≥0.9 カバレッジ | ≥0.9 内の誤り |
|---|---|---|---|
| 単一トークンをプリフィル | 559 / 778 ms | 96.5% | 1 |
| 先頭トークンの logprobs（モデルに一度考えさせる） | 996 / 1591 ms | 100% | 0 |
| 自由テキスト · 判定が先 | 1197 / 2387 ms | 100% | 1 |
| JSON モード | 1018 / 1812 ms | 64% | 0 |
| 5 回サンプリング | 4530 / 6251 ms | 99.1% | 0 |
プリフィル方式は同じモデルの自由テキストより2.1 倍速く、5 回サンプリングより8.1 倍速く、精度は 99.1%。Jev が主張する 70–500ms と同じ桁だ（こちらは p50 で 559ms、しかも公網と推論モデルを挟んでいる）。そしてこれは今日から使える——waitlist は要らない。
タダというわけでもない。2 つの誤りはどちらも微妙な数字の書き換えにあり、一方は自ら低信頼を申告し（0.657、閾値で弾かれる）、もう一方は 0.905 を申告した（通ってしまう）。これがこのデータ群で「キャリブレーション」が唯一顔を出した姿だ：最速の方法は、細部で静かに間違える。
結果5:「質問を増やしても応答時間はほとんど変わらない」は通常の LLM では成り立たない
公式ドキュメントには、複数の質問は1回の呼び出しで並列に評価され、「質問を増やしても応答時間はほとんど変わらず、増えるのはその質問分のトークンだけ」と書かれている。同じ state で質問数を1から20まで増やし、通常の LLM で試した:
| 1回の呼び出しに含まれる質問数 | レイテンシ中央値 | 出力トークン中央値 | 切り捨ての有無 |
|---|---|---|---|
| 1 | 1036 ms | 92 | なし |
| 4 | 1846 ms | 369 | なし |
| 10 | 4463 ms | 1200 | 3回中2回切り捨て |
| 20 | 4823 ms | 1200 | 3回中3回切り捨て |
レイテンシは 4.6 倍、出力トークンは 13 倍、しかも N=10 から max_tokens で打ち切られる——普通の LLM では「20 問聞いてもほぼ無料」にはならない。ここがまさに System One 系モデルの構造的な強みだ。テキストを生成しなければ、「出力トークンが質問数に比例して増える」という問題自体が存在しない。
我々の判断
System One が売っているのは二つ、インターフェースの形と学習目標だ。 我々が検証できるのは前者だけであり、実測はこの形が確かに役立つことを示している。
- 「1 回のフォワードパス、単一トークン、確率を取る」という道は通じており、しかも今日にでも使える。 プリフィル + logprobs は我々の実測で 559ms、精度 99.1% だった。Jev の価値は「実現できるかどうか」ではなく、それをモデル + API 一式（255 択の Choice、Score の期待値、Noul の単一確率）として製品にし、さらに「型エラーを心配しなくていい」というエンジニアリング上の保証を付けた点にある。
- 自動化が実際に回るかどうかを決めるのは、モデルの賢さではなく、その確率がどこから来るかだ。 同じ問題セットで、logprobs を読む方式は 100% 自動実行できたが、モデルに JSON 内で自信度を自己申告させる方式は 64% だった。しかも自己申告の数値は意味づけすら統一されていない。したがって公式の Confidence-Gated Routing パターンは、「モデルに JSON で confidence を報告させる」形で実装してはいけない。意味を schema に書き込んで検証するか、logprobs を直接読むか、複数回サンプリングするかのいずれかだ。
- 「キャリブレーション」については、このデータでは方式間の差を検出できなかった。どの方式でも確率が 0.00/1.00 に飽和し、信頼性図は 1 点に退化する。唯一目立ったのは「最速の設定が、微妙な数字の書き換えに対して高信頼で誤る」ケースだ。これは Jev のキャリブレーションが無意味だという証明ではない。その価値は学習が実際に確率分布を変えたときに初めて生まれるということであり、それには曲線が要る。TypeSafe は今も公開していないし、我々も Jev を試せていない。
- どんな場面でこうしたモデルを入れる価値があるか：高頻度・低リスク・形が固定された判断（分類、ルーティング、スコアリング、検証）で、しかも閾値化が本当に必要——不確実なものを人間に回すか、高信頼のときに LLM の推論コストを省くか。価値がない場面：多段推論や長い思考連鎖が要るもの（Jev は test-time compute を明確に放棄しており、こうしたモデルの知能の上限はおそらく非推論モデルと同じあたりで止まる）、テキスト生成が要るもの、そして分野をまたいだ汎化が未検証のもの。
エンジニア向けの実行可能な結論を三つ。
- 確率を閾値の軸に使いたいなら、まず意味を検証せよ。モデルに確率を自己申告させるのは最も手軽で最も信頼できない道だ。安く確実にしたいなら、フィールドの定義を先に固く書き、数十件を抜き取り検査して本当に定義どおり答えているか確かめる。
- 「機械が使える判断」を早く手に入れたいなら、まずプリフィル単一トークンをやれ。waitlist を待つ必要はない。2 倍程度の高速化は我々の環境で計測済みだ。代償は、微妙な違いの誤りが警報を鳴らさないこと——だから低リスクの高頻度判断に向き、レビュー系のタスクには向かない。
- 複数質問の一括呼び出しを無料と考えるな。普通の LLM では線形コストであり、しかも出力上限にぶつかる。「20 問聞いてもほぼ無料」が本当に必要なら、それはまさに別の種類のモデルに乗り換えるべき場所だ。
境界：我々が測れなかったこと
- Jev そのものは測っていない。 waitlist があるだけで、key も公開重みもない。記事中の Jev の数字（70–500ms、$0.042/MTok、193.6x/444.6x、Doom demo の $7/時間）はすべて公式の主張であり、我々は再現していない。The Register が報じた $40M の調達と 2 年間のステルスも二次情報だ。
- 単一モデル、単一コーパス、問題は自作。 DeepSeek の推論モデル 1 つ、当サイトの中国語記事、我々が自分で作った問題。したがってこれらの数字が示すのはキャリブレーションの形であり、リーダーボード上の順位ではない。
- コーパス間のドリフトテストはやっていない：これが最もやるべき次の一歩だ。チケットでよくキャリブレーションされたモデルでも、あなたのコーパス、あなたの分野に移せば全くキャリブレーションされない可能性がある（pearpages のまとめもこの点に触れ、誰も測っていないと書いている）。スクリプトとデータセットをリポジトリに残したのはこのためだ。
verify/でcontent/のコーパスを差し替えれば、コマンド 1 つで再実行できる。 ScoreとChoiceは個別に測っていない。 本記事の問題はすべて二値判断（Noul の形）だ。多クラスおよび高基数（Jev は 255 択まで対応）のキャリブレーションは別の話であり、分けて測る必要がある。