davidwsc

Jev：しゃべらずに「決める」モデル

本番環境で動いている AI コードの多くは、正体をばらせばただの if 文です。

このチケットは請求の話かバグの話か。このコメントはスパムか。この返信は電話番号を漏らしていないか。このリードは営業に回すかサポートに回すか。私たちはこうした問いをチャットモデルに投げ、JSON で答えてくださいと丁寧に頼み、結果をパースして、勝手に4つ目のカテゴリを作られていないことを祈ります。動きはします。でも遅いし、高いし、少し滑稽です。5つの単語から1つ選んでほしいだけなのに、文章を書くモデルにお金を払っているのですから。

TypeSafe AI の Jev は、この仕事には専用のモデルがふさわしい、という賭けです。2026年9月15日に限定アーリーアクセスが始まりました。私はまだ実際に使って何かを作ってはいないので、これは現場レポートではなく、ローンチ資料と初期のレビューを読み解いたものです。それでも理解しておく価値はあります。アイデアのほうが製品より大きいからです。

Jev とは

Jev はテキストを生成しません。状態（文字列、オブジェクト、配列）と、型付きの問いのセットを渡すと、問いごとに型付きの答えを、確率分布と確信度つきで返します。

問いの型は3種類です。

  • Choice：自分で定義した選択肢から1つを選ぶ。「このチケットは請求、バグ、機能要望、その他のどれ？」
  • Score：自分で定義した順序付きの尺度の上に位置づける。「緊急度は低〜致命的のどこ？」
  • Noul：イエスかノーか。「このメッセージに個人の連絡先は含まれている？」

答えは、許可した値のどれかにしかなりません。TypeSafe によれば、型エラーは「まれ」なのではなく構造的に「起こり得ない」。文字列の出力そのものがないので、幻覚を書き込む余地もないわけです。

TypeSafe はこれを System One モデルと呼んでいます。ダニエル・カーネマンの、速く直感的な「システム1」の思考から取った名前です。チャットモデルは遅く熟考するシステム2で、トークンを1つずつ声に出して推論します。Jev は即断のほうを担う。彼ら自身の言い方では「フロンティア級の知能を持った関数呼び出し」。構造化されていない状態を入れると、型付きの確率的な判断が出てくる。

名前は経済学者ウィリアム・スタンレー・ジェヴォンズへの目配せです。石炭エンジンの効率が上がると、石炭の消費は減るどころか 増えた、と指摘した人です。言いたいことは明快です。判断を十分に安くすれば、人はそれをあらゆる場所に置くようになる。

何が違うのか

TypeSafe によれば、ポイントは3つです。

すべての答えを並列にサンプリングする。 チャットモデルはトークンを1つずつ生成します。Jev のサンプラーは出力を一度に生成する（非自己回帰）ので、同じ入力に5つの問いを投げても、1つの問いとほぼ同じコストで済みます。速さの源はここです。TypeSafe はエンドツーエンドで70〜500ミリ秒としています。

好みではなく較正のために訓練されている。 チャットモデルは、人が好む答えに報酬を与える RLHF で調整されます。Jev は TypeSafe が RLCD（Reinforcement Learning for Calibrated Decisions、較正された判断のための強化学習）と呼ぶ方法で訓練され、正直な確率に報酬が与えられます。狙いは、Jev が90%と言ったら、実際に約90%の確率で正しいこと。これは見た目以上に重要です。信頼できる確信度があってはじめて、どこを自動化し、どこで人に聞くかを決められるからです。

公共料金のような価格設定。 ローンチ時の価格は入力100万トークンあたり0.042ドルで、出力は無料。TypeSafe は「安すぎて計測するまでもない」と言っていますが、出力が数個の数字なら妥当な表現です。

まとめると、この種のタスクではフロンティア LLM より40〜200倍速く、40〜400倍安い、というのが看板の主張です。社内のワークフロー評価では最大で193.6倍速く、444.6倍安いとしています。これはベンダーの数字として扱ってください。TypeSafe 自身、ワークフローは社内で作ったもので、おそらく上振れの結果だと認めています。

どこにはまるか

Jev はチャットボットでもエージェントでもありません。コードの中で判断が必要な箇所に置く部品です。

  • ルーティングとトリアージ：どのキューへ、どのチームへ、どのモデルに任せるか。
  • ガードレール：LLM の出力にポリシー違反やデータ漏えいがないかを、出荷前にチェックする。すべての応答に対して走らせられるほど速い。
  • スコアリング：リード、コンテンツの質、関連性のランク付け。
  • 大規模バッチ処理：数百万件のレコードの分類。1回あたりのコストが、そもそも実行可能かどうかを決めるような仕事。
  • リアルタイム処理：2秒のモデル呼び出しがユーザーに体感されてしまう場所すべて。

初期のレビューが勧めるパターンはよくできています。独立した問いはすべて1回の呼び出しでまとめて聞く。どうせ並列で走るからです。曖昧な「総合評価」を1つ聞くのではなく、複数の Score を自分のコードで組み合わせる。行動は確信度でゲートする。たとえば0.5未満は人に回し、破壊的な操作には0.9程度を求める。実際に動かす前に、既存のロジックと並べてシャドーモードで走らせる。

どこで壊れるか

限界は強みと同じくらい重要で、どれも設計から素直に導かれます。

  • 書けない。 要約も返信も下書きも無理。出力が文章なら、引き続き LLM が要ります。
  • 数えられないし、計算もできない。 集計、算術、正確な計測は当てになりません。Score は順位づけには使えても、大きさの測定には向きません。
  • 日付と順序に弱い。 2つの日付のどちらが先か、は聞かないこと。
  • 選ぶだけで、名付けない。 抽出は、候補を渡してそこから選ばせるなら機能しますが、新しい値を生み出させようとすると駄目です。
  • テキストのみ。 画像や音声は入力できません。
  • 答えの空間は有限。 1つの問いにつき最大255の選択肢で、それ以上は2段階の仕組みが必要。スキーマは事前に定義しておく必要があります。

ある初期レビューの率直なまとめが、私がいちばん覚えておきたいものです。事実は決定的なコードに任せ、その間にある曖昧な判断にだけ Jev を使う。そして、実際にどれだけ節約できるかは、そもそも AI の請求額のうち分類がどれだけを占めているかで決まる。多くのアプリでは大きな割合です。ほとんどゼロのアプリもあります。

なぜ重要だと思うか

ここ数年で私たちは、あらゆる AI タスクに一番大きなチャットモデルを持ち出し、そこから構造化データを絞り出す癖をつけてきました。Jev は、それが法則ではなく習慣にすぎない、というきれいな反論です。「AI 機能」と呼ばれるものの多くは判断で、判断には会話とは違う要件があります。速く、安く、範囲が決まっていて、どれくらい確かなのかを正直に言えること。

Jev そのものが勝つかどうかは分かりません。まだアーリーアクセスで、ベンチマークは自社のもの、大手ラボが似たものを出してくる可能性もあります。それでも、Jev が指し示す分業はしっくりきます。考えて書く遅いモデルと、ただ決める速いモデル。この分業が定着すれば、名前に込められたジェヴォンズのパラドックスこそが、ローンチでいちばん正確な部分だったと分かるかもしれません。安い判断は AI の利用を減らしはしない。すべての if の後ろに小さなモデルを置くことになるのです。

出典