Jevは一語も書くことを拒否する：TypeSafe AIの意思決定モデルが何をするのか、そしてまだ誰も検証していないこと

JevはTypeSafe AIの最初のモデルであり、読者がチャットボックスではなく料金表を通じて出会う可能性が高い。なぜならチャットボックスが存在しないからだ。2026年9月15日にDiogo Almeida——ChatGPTをアシスタントのように振る舞わせた研究であるInstructGPT論文の共著者——によって発表されたJevは、テキストを一切生成しない。状態の断片（メール、ログ行、サポートチケット、ゲーム座標のJSONブロブ）と型付きの質問のリストを受け取り、型付きの回答を返す。あなたが提供した集合からの選択、ルーブリックに基づくスコア、またははい/いいえの確率で、それぞれが独自の信頼度値を持つ。文章もコードも説明もない。TypeSafeの売りは、この狭さこそが製品だという点にある。なぜならそれによって、生成モデルには太刀打ちできない速度と価格が得られるからだ——同社自身の発表資料によれば「同等のLLM」より20～200倍高速で40～400倍安く、入力トークン100万個あたり0.042ドル、出力は課金ゼロである。

最初の48時間に公表された最も有用な数字は、それらのどれでもない。それはEveryのもので、同社の評価責任者が、公開済みのEvery記事27本とAI風に仕立てた対応記事10本にわたってJevを走らせ、37文書すべてに一度に21の質問を投げかけた——0.7秒未満で777件の判断、費用はおよそ0.25セント。EveryのCEOが実施した2つ目のテストでは、12の合成パッセージ——6つは欠陥なし、6つには欠陥が意図的に仕込まれている——を4つの文章チェックに照らした。Jevは1パッセージあたり中央値0.35秒で返し、高エフォート設定のClaude Fable 5.1は8.83秒だった。約25倍高速で、コストはおよそ580分の1。Jevは仕込まれた7つの欠陥のうち6つを捉えた。Claude Fable 5.1は7つすべてを捉えた。Everyの評決は「good but not perfect（良いが完璧ではない）」であり、これまでに誰かが公表した唯一の独立テストから得られる、Jevについての正直な一行の読み方である——速度とコストの主張は第三者による検証に耐え、精度の主張はフロンティアより一段低く、そしてサンプルは、誰もそこから本番導入の結論を引き出すべきではないほど小さい。

この記事がどのような種類の証拠を扱っているかについて、ひとこと。というのも、これほど新しいモデルにしては、証拠の階層が異例なほど大きく隔たっているからだ。Jev は実在し、呼び出し可能だ。文書化されたエンドポイント、Python SDK、モデルエイリアス、公開価格が存在する。ローンチはベンダー発表であり、リークではなく、それが存在するかどうかを誰も推測してはいない。しかし TypeSafe が真っ先に掲げる性能主張はすべて TypeSafe 自身によるもので、アーキテクチャは非公開、重みも公開されておらず、20～200倍という見出しの背後にあるベンチマークダッシュボードは、公開リーダーボードではなく一連の社内ワークフロー評価だ。外部の1者だけがそれをテストしている。本記事は、ベンダーの数値、独立した数値、未解決の問いを、存在しないコンセンサスへと平均化するのではなく、目に見える形で分けておく。

TypeSafeが実際に出荷したもの

Jevは、TypeSafeがSystem Oneモデルと呼ぶものの最初の例だ。その名は、チャットボットが模倣するより遅い熟慮的モードとは対照的な、ダニエル・カーネマンによる認知の速く直感的な半面から借りている。TypeSafeが対置しているのは、テキスト生成器に構造化出力を出させるよう強制し、その後そのテキストをコードが信頼できるものへと解析し直すという標準的なパターンだ。Jevはテキストを完全に省略する。TypeSafe自身のドキュメントは、この点を率直に述べている。「大規模言語モデル（LLM）は、人間が読むためのテキストを生成するように設計されている。あなたのコードが消費する判断をモデルに下させる必要があるとき、そこに不一致が生じる。」

出力サーフェスは3つのプリミティブであり、それ以外には何もない。あなたが尋ねるすべての質問は、それらのいずれかでなければならない：

• 選択 — 用意したリストから1つのオプションを選び、選択されたオプションに加えて各候補の確率と信頼度を返します。オプションはフィールドごとに255個が上限です。それを超える場合、TypeSafeのドキュメントでは、候補を個別にスコアリングしてから選択するという2段階のパターンが説明されています。

• スコア — 状態を順序付きルーブリック上に位置づけ、レベル、レベルごとの確率、および信頼度を返します。0～1 スケールのチャーンリスクがドキュメント内の例です。

・Noul — 「no」と「null」を組み合わせたかばん語 — 単一のイエス/ノーで答えられる主張であり、それが真である較正済みの確率を返す。

興味深い性質は、個々のプリミティブではなく、それらがどう組み合わさるかにある。3つすべてを単一の API 呼び出しに混在させることができ、すべての質問は、同じ状態への1回の共有読み取りに対して並列に評価される。TypeSafe のドキュメントは、質問を追加しても「応答時間はほとんど変わらない」と述べており、独立したテストがそれを実践で裏付けている——37 ドキュメントにまたがる 21 の質問が、同じ 0.7 秒以内に収まった。それこそが、判断あたりのコストを激減させる理由だ。支払っているのは、より長い生成のためではなく、1回のパスのためなのである。

文書化され、初期ユーザーから報告されている実用的な範囲は次のとおりです：おおよそ32,000トークンのリクエスト予算で、TypeSafeのドキュメントでは約150,000英字と説明されており、提供開始時には画像入力も音声入力もなく、リクエストとレスポンスの形式はOpenAI chat-completionsの慣例ではないため、呼び出すにはbase-URLの置き換えではなく専用クライアントが必要です。アクセスは早期アクセス待機リストとブラウザプレイグラウンドで、code>jev-latest/code> がモデルエイリアスです。

RLCDは校正済みという意味であり、優先という意味ではありません

TypeSafeは、同社自身のドキュメントによると、RLCD——Reinforcement Learning for Calibrated Decisions——と呼ぶ手法でJevを訓練している。この頭字語は新しく、初期の報道ではその展開が一貫していないため、それが実際に何を指すのかをはっきりさせる価値がある。というのも、その区別こそが研究上の主張のすべてだからだ。

RLHFは人間が好む出力に最適化する。RLVRは検証可能な正しさ、つまりテストケースが通るタイプの正しさに最適化する。RLCDはキャリブレーションに最適化する。モデルが70%の自信があると言うなら、約70%の確率で正しいはずである。それは正しいこととは別の目標であり、これがJevのすべての回答が単なる答えではなく確率分布を伴って提供される理由である。意図された故障モードは、自分が知らないときを知っているモデルであり、そうすればあなたのコードがそれについてどうすべきか判断できる。

それが実際にもたらすのは、コントロールサーフェスです。文書化されているパターンは3つの信頼バンドです — 上位では自動的に実行し、中位ではフラグを立てるか確認を求め、下位では人間に回す — しきい値はモデルではなくコード内に置きます。そのバンドが誠実かどうかは、あなたのデータに関する実証的な問いであり、TypeSafe が明示的に自分で答えるよう求めている問いの1つです。信頼しきい値はユースケース固有であり、自分のラベル付き事例に対してテストすべきだと指摘しています。その指示は文書の中で最も重要な一文であり、次のセクションが存在する理由でもあります。

数字を、誰が作成したかで並べ替えたもの

ここが、Jevに関するほとんどの報道が歯切れ悪くなるところだ。だからこそ、情報の出所をはっきりさせておく価値がある。以下は、ベンダーから出たもの、独立系テスターから出たもの、そして単に不明なものだ。

• ベンダー報告のみで未再現 — 主要な速度とコストの主張。フロンティアLLM呼び出しの3～329秒に対し、エンドツーエンドのレイテンシは70～500ms。20～200倍高速かつ40～400倍安価。単一のベストケースのワークフロー結果は193.6倍高速で444.6倍安価と宣伝されている。TypeSafeは、これらが普遍的な数値ではなくベストケースであることを認めている。

• ベンダー報告であり、価格表で確認できる——入力トークン100万あたり0.042ドル、つまり10億あたり42ドルで、出力は無料。出力が無料なのは販促ではなく仕組み上の理由だ。計量すべき自己回帰デコーディングが存在しないため、請求すべき出力トークンもない。規模感を示すと、同じ発表資料では、一般的なフロンティアの入力価格は100万あたり0.20〜10ドルで、出力はしばしば入力価格の約5倍とされている。

• ベンダー報告による社内ベンチマーク — TypeSafe 自身のワークフローダッシュボードで、4つのタスクにわたる711件のケース。参照回答はグラウンドトゥルースではなく、GPT-6 Astra と Claude Fable 5.1 の平均判断から導出された。このダッシュボードで Jev は67.8%を集計し、最良の比較対象は74.1%。内訳：セキュリティインシデントは Opus 5 の66.2%に対して61.7%、エージェントトレース可観測性は76.6%に対して71.6%、請求書処理は79.1%に対して61.8%、カスタマーサービスは78.3%に対して76.0%。このチャートで Jev はコストとレイテンシの列で勝ち、精度の列では負けている。ダッシュボード自体はハーネスバイアスの可能性を注記しており、TypeSafe は製品アップデートに紐づく単発の評価を優先し、公開リーダーボードを意図的に避けたと述べている。

• 独立に測定された小規模サンプル — 上記で説明したEveryのテスト：777件の判定を0.7秒未満で約0.25セント；11の実験にわたる1,709件の判定を合計1セント未満；12のパッセージからなる分類タスクでは、Claude Fable 5.1より約25倍高速でコストは580分の1だったが、比較対象が捉えた7つの仕込まれた欠陥のうち1つを見逃した。Every自身の結論は、本番導入前にはるかに徹底的な精度チェックを行いたいというものだった。

• 不明 — アーキテクチャ。ローンチ時に論文はなく、パラメータ数もなく、学習コンピュートの開示もなく、重みもない。TypeSafeは詳細を「今のところ胸の内に留めておく」と述べており、論文は後日になる可能性がある。

それらの階層を通じて見られるパターンは一貫しており、それは200倍という見出しが示唆するパターンではない。独立系の数値もベンダーの数値も、すべてJevが劇的に安く、劇的に速いことで一致している。どこにも、TypeSafe自身の数値でさえ、価格帯の比較対象となるフロンティアモデルより精度が高いことを示すものはない。ベンダー自身のダッシュボード上でも、優れたミッドティアモデルと同程度の水準に位置する。成り立つ比較は「100分の1の価格でフロンティアモデル並みに賢い」ではなく、「1回の呼び出しあたり1セントの何分の一かで、ミッドティアモデルの判断力に近く、毎ターン実行できるほど速い」だ。

「ゼロハルシネーション」が意味することと意味しないこと

TypeSafeの発表資料には、Jevのツール呼び出しエラー率が0%である一方、比較モデルには非ゼロのエラー率があることを示すグラフが含まれており、「ハルシネーション耐性」という表現がモデルとともに広まっている。どちらも事実だが、どちらも読んだときに受ける印象より射程が狭い。

その保証は構造的なものだ。モデルが実行される前に、起こり得るすべての答えがあらかじめ列挙される——選択肢のリスト、評価基準、または真偽の主張をあなたが提供するのだから——したがって、宣言された型の外側の値を出力する余地はない。不正な形式のツール呼び出しは、Jev が生み出せるものではない。これは紛れもないエンジニアリング上の特性であり、JSON のパース失敗に対するリトライロジックを一週間書いてきたことのある人にとっては、実際の金銭的価値がある。

それは正しさについての主張ではない。スキーマに適合した回答でも、依然として間違っていることはある。Jev は請求に関する苦情を自信を持って技術キューに回すことができ、その出力は完全に整形式でありながら役に立たない、ということもあり得る。アルメイダ自身もそう述べており、自信を持って間違うことはあり得ると認めている。両方の事実をうまく抱えるなら、Jev は出力フォーマットに由来する種類のエラーを排除し、判断に由来する種類にはまったく何もしない、ということになる。つまり正確さの問題は完全にキャリブレーションの問題であり、キャリブレーションこそ自分で測定しなければならないものなのだ。

自分のデータでキャリブレーションの主張を検証する方法

キャリブレーションは、数百の例とMLインフラなしで適切に確認できる数少ないモデル特性の一つであり、Jevが本番経路に触れる前に重要な唯一のテストだ。手順は短い。

すでにラベルが付いている数百件のケースを用意する。Jev に重要な問い——ルーティング判断、リスクスコア、欠陥チェック——を尋ね、報告された信頼度ごとに回答をバケット分けする。次に、信頼度0.9のバケットが約90%の確率で正しいか、0.7のバケットが約70%か、以下同様に確認する。適切にキャリブレーションされたモデルは対角線を描く。単に自信があるだけのモデルは、すべてを0.9超に固めてしまい、実際に正しいのは70%の確率でしかなく、これが自動化パイプラインを静かに壊す形だ。

同じテストが、どのしきい値を使うべきかを教えてくれます。もし0.9のバケットがあなたのデータで本当に90%の精度があるなら、それを自動化できます。もし中間バンドがぐちゃぐちゃなら、それを人間に回すか、生成モデルに渡して、高コストなパスに曖昧さを処理させます。その分割 — 自信のある多数派には安価なモデル、不確実な残りには高価なモデル — こそが、Jevが主張している実際のアーキテクチャであり、モデルを置き換えではなくコンポーネントとして理解するのが最適である理由です。

費用はいくらか、計算して説明します

料金体系は、ちゃんと筋道立てて考えられるほどシンプルです。こういうのは珍しい。入力は100万トークンあたり0.042ドル。出力は無料です。ドキュメントに記載されているリクエスト予算の約15万文字では、最大サイズの呼び出し1回でも1セントをはるかに下回ります。

報告された2つの数字が規模感を伝えている。初期のユーザーは約5,000件のリクエストをおよそ2ドルで実行した。Doomのデモ — Jevが生のピクセルではなくゲーム状態のテキスト記述を使ってボットを操作したもの — は、1秒あたり約10回の呼び出しで、1時間あたり約7ドルだった。そしてEveryの37文書にわたる777件の判定は、およそ4分の1セントだった。これが、興味深いユースケースを明らかにする数字だ。その価格なら、エージェントループの毎ターンをチェックすることはコストの判断ではなくなり、デフォルトになる。

それがJevの本当の論拠だ。ターンごとの検証パス——このツール呼び出しは前回のものと矛盾していなかったか、この出力はユーザーが述べた意図と整合しているか、これはフラグを立てるべきか——は、フロンティアモデルを使えば技術的には常に可能だったが、規模の面では経済的に不合理だった。100万トークンあたり0.042ドル、出力課金なしであれば、同じパスが毎ターン手頃な価格になる。ここでの価値は、Jevがフロンティアモデルより優れた思考をするということではない。実際そうではないからだ。価値は、常に参照されるのに十分なほど安く、速く思考することにある。

率直に言っておく価値がある。それが明らかな次の疑問だからだ。OrcaRouterはJevを提供していない。TypeSafeのモデルは早期アクセスかつウェイトリスト制で、独自のリクエスト形式を採用しているため、それをテストする人はTypeSafeを直接経由することになる。ルーティング層が実際に適合するのは、ワークフローのもう半分だ。Jevが想定しているパターンは、1つではなく2つのモデルである——Jevが型付きの判断を下し、生成モデルが文章、コード、または説明を必要とする部分を処理する。その生成側の半分こそ、OrcaRouterがカバーする部分だ：15社のプロバイダーにまたがる197モデル単一のOpenAI互換キーの背後にあり、プロバイダーの定価を0%のマークアップでそのまま渡しているため、ベンダーの値下げはそれが実施された当日にこちらの側へ反映される。Jev型のワークフローの両方の半分は、2つ目の契約なしでテストでき、判断コンポーネントが未検証の場合、フェイルオーバーパスが、悪いキャリブレーション結果が本番インシデントになるのを防ぐ。

ジェヴが当てはまらない場所

制約事項はベンダーによって異例なほど明確に示されている。そのため、このセクションは正直に書きやすい。Jevはフリーテキストを生成できない。コードを書くこともできない。会話をすることもできない。チャットインターフェースも画像入力もなく、コンテキスト予算は約32,000トークン——価格で比較されている長コンテキストモデルより1桁少ない。選択フィールドの選択肢は最大255個に制限されている。そして、「ハルシネーションなし」という特性は、前述のとおり、真実性ではなく出力形式に関するものだ。

このネットはかなり狭い用途にしか適合しない。良い用途：大量の分類とルーティング、ガードレールと検証パス、レイテンシが重要な意思決定、大規模な文書セットの並列スコアリング、正解が本当に選択肢、尺度上の数値、またはブール値であるようなあらゆる場面。悪い用途：あらゆる種類のオープンエンド生成、長いコンテキストの推論、マルチターン対話、または正解が文であるようなタスク。あなたの問題が型付きの質問に還元できないなら、Jev はそれを解決する安価な方法ではない — そもそも解決する方法ではない。

また、その位置づけには、今後も引き継ぐ価値のある公正な批判もある。Jevをフロンティアモデルと呼ぶのは、このモデルが獲得していない信用を借りることになる。Jevはコードを書くことも、チャットすることも、一文を書くこともできない。しかも比較チャートはフロンティアモデルをベースラインとして頼っている一方で、精度の列は別のことを物語っている。より擁護に耐える主張、そして証拠が実際に支持する主張は、TypeSafeが構造化された意思決定における速度とコストのフロンティアをはるか先まで押し広げた、というものだ。それは成し遂げたこととして大きなものだ。それはGPT-6 AstraやClaude Fable 5.1に匹敵するモデルを構築することとは別物である。

何がこの状況を変えるでしょうか

三つある。おおよそ、重要度が高い順に並べると。

• 公開されたアーキテクチャ論文、またはオープンウェイト。Jevがどのようにしてその速度を達成しているかは、現時点ではすべてブラックボックスであり、並列評価がそのメカニズムであるという主張——Almeidaが引くアナロジーは、transformersがリカレントネットワークを置き換えたのと同じように逐次計算を置き換えるというものだ——は、実証された結果ではなく主張にすぎない。設計が公開されるまで、速度は事実であり、説明はマーケティングである。

• より大きなサンプルによる2回目の独立評価。Everyのテストは利用可能な中で最も強力な証拠であり、決定的な精度の問いについて12のパッセージをカバーしている。さらに数百件のラベル付きケースで独立した実行をもう1回行えば、7件に1件の欠陥を見逃したのがノイズだったのか、それとも実際のエラー率なのかが決着するだろう。

• 現実的で雑然とした入力に対するキャリブレーション監査。これまで公表されたものはすべて、クリーンなテストハーネスを使っている。信頼できる信頼度スコアに価値提案のすべてを賭けているモデルにとっての未解決の問いは、それらのスコアが真に曖昧なケース——人間のレビュアーもためらうようなケース——でどう振る舞うかだ。それこそが、Jev に対して自動化して安全かどうかを決める数値であり、誰もそれを公表していない。

それまでは、妥当な姿勢は一般的というより具体的である。Jevは実際に出荷されている、異常に安価なモデルであり、出力信頼性において真に構造的な優位性を持ち、精度プロファイルは中位層あたりに位置し、キャリブレーションの主張はもっともらしく、自社ベンダーによって明示的に自己テストが推奨されており、独立に検証されているのは小規模サンプルのみである。あなたのワークフローに、フロンティアモデルを使うのが無駄になるほど頻繁に尋ねられる型付きの質問へと還元できるステップがあるなら、これはそれを尋ねる最も安価な方法の一つである——そして、信頼する前にテストすべきなのは、それが返す信頼度の値であり、速度ではない。