TypeSafeのJevが変える分岐処理、遅延70msと破格コストの衝撃

• TypeSafe AIが文章生成を行わず判断と確率のみを返す高速AI「Jev」を公開し開発者界隈で注目を集める
• 応答70〜500ms、100万入力0.042ドルで出力無料。複数質問を同一stateに対し並列評価する新アーキテクチャ
• 従来の重厚なLLM呼び出しによるJSONパース処理を置換し、ゲーム制御や要件定義レビューの高速分岐を劇的に軽量化

深夜のバッチ処理やリアルタイム制御のパイプラインで、LLMからのJSONレスポンスを待ち受けてタイムアウトエラーを監視し続ける開発者の苛立ちは、想像に難くない。我々がAIエージェントやバックエンドの業務ロジックを組む際、LLMに求めているのは「美しい長文のエッセイ」ではなく、「ユーザーの入力が解約手続きなのか問い合わせなのか」という単なる1ビット、あるいは高々数個の有限選択肢の分岐フラグであることがほとんどだ。それにもかかわらず、これまでは重厚な数十億〜数百億パラメータのモデルを動かし、トークンを1つずつ自己回帰的にデコードさせ、最後に正規表現やPydanticでJSONパースを強いるという、計算資源の途方もない無駄遣いを強いられてきた。

この理不尽なアーキテクチャのボトルネックに決定打を突きつけたのが、TypeSafe AIが発表した「System One Model」の第1弾、Jev（ジェブ）である。Jevはテキスト生成を最初から放棄し、プログラムから与えられた状態に対して、事前定義された選択肢や尺度に対する「判断」と「その確率分布」のみをダイレクトに返す。公式が自ら「賢いif文」と称するように、プログラミング言語の制御構文そのものをニューラルネットの推論エンジンで置き換えるという極めて大胆な思想だ。

そのインターフェースは至って合理的である。APIへの入力は大きく「state」と「questions」の2つに分断されている。stateには判断対象となる自然言語テキストや構造化されたJSONなどの状態データを渡し、questionsにはその同一stateに対して問いかけたい質問のコレクションを渡す設計だ。質問タイプは明確に定義されており、事前定義した候補リストから1つを選ぶ「Choice」、順序付けられた尺度に沿って評価を行う「Score」、そして命題が正しいか否かの確信度を0から1の実数値で返す「Noul」の3種類が提供されている。これらを1回の呼び出しで混在させることができ、複数の質問を並行して一度に解決できるのだ。

既存のOpenAIやAnthropicが提供するStructured OutputやFunction Callingも、表層的にはスキーマに沿ったJSONを返してくれるため、Jevと同種のものと誤認されやすい。だが、その内部挙動と設計思想には決定的な断絶が存在する。従来のLLMにおけるStructured Outputは、トークンサンプリング時に正規表現や文法制約マスク（Grammar-guided decoding）を噛ませているだけであり、本質的には「1トークンずつ順番に文字列を生成していく自己回帰ループ」の軛から逃れられていない。そのため、出力トークン数が増えれば必然的にレイテンシは線形に増大し、生成が完了するまで次のロジックへ進めないというデッドロックに近い停止時間を我々のシステムにもたらす。

対照的にJevは、最初から自由記述の文章を生成するデコーダを排除し、定義済みの選択肢や確率をダイレクトに出力する機構を採用している。公式ドキュメントによれば、同一のstateに対して複数のquestionsをバッチ処理する場合、各質問は独立かつ並列に評価されるため、質問項目を追加しても応答時間はほとんど線形増加しない。文章のデコードと構文解析が完全にバイパスされるため、固定された判断を大量かつ低遅延でさばく必要があるシステムにおいて、圧倒的なアドバンテージを発揮するのだ。以下の表は、公式発表におけるJevの基本スペックとコスト体系である。

ただし、シニアエンジニアとして冷静に見極めなければならないのは、公式が謳う「ハルシネーションしない」という宣伝文句の真意だ。これは「未定義のキーや想定外のデータ型を絶対に返さない」という構文的（Syntactic）な保証を意味しているに過ぎず、選択肢の中から論理的に間違った選択肢を誤判定してしまう意味的（Semantic）なエラーを排除できるわけではない。構造化されたif文の型安全性が担保されたとしても、判定ロジックの精度自体の検証を怠れば、システムが致命的な判断ミスを高速かつ無言で垂れ流すリスクを内包していることは強く意識すべきである。

Jevが持つポテンシャルの高さは、発表からわずか数日でコミュニティから噴出した実験的なユースケースの多様性を見れば一目瞭然だ。特に象徴的だったのが、高頻度な判断ループが求められるリアルタイムゲームの制御への適用である。従来のLLMエージェントでは、数秒単位の推論遅延があるためターン制ゲームが関の山であったが、からあげ氏による検証では「Mario AI Framework」や「Vampire Survivors」の操作にJevを組み込む実験が行われた。構造化されたゲーム画面の状態データをstateとして流し込み、5つの行動候補から瞬時にChoiceさせることで、迫り来る敵を避けるリアルタイム性の高い操作ループを成立させている。

このリアルタイム性は、業務アプリケーションの現場でも直ちに威力を発揮する。例えば、要件定義書を19もの多角的な観点から一括評価するStreamlitアプリの実装では、長大なドキュメントをstateに配置し、並列なquestions群で品質チェックを一網打尽に判定させている。従来のLLMであれば、プロンプトを分割して何度もAPIを叩くか、長大なJSONスキーマを出力させて数分間待たされるところを、同一コンテキストの並列評価によって一瞬で処理を終えることができる。

さらに、デスクトップロボット「スタックチャン」の会話振り分けエンジンとしての活用や、RPA運用保守における一次障害切り分けにおいて、これまでMicrosoft Copilot等の重厚なサービスを呼び出していた部分をJevの判定に置き換える動きも登場している。ユーザーの発話テキストから「表情をどう変えるか」「どのツールを呼び出すべきか」を低遅延でChoiceし、即座に次のアクションを発火させる。このような「巨大な知能を必要とせず、的確な条件分岐だけをミリ秒単位でさばきたい」という開発現場の無数の隙間に、Jevはパズルのピースのように完璧に嵌まり込んでいるのだ。

現在進行形でエンジニアコミュニティを最も熱狂させているのは、オープンソース界隈における「Jevクローン」の実装ラッシュである。TypeSafe社が提供するJev本体は完全なプロプライエタリ製品であり、モデルの重みはもちろんのこと、新アーキテクチャの内部詳細、並列サンプラーの機構、そして学習に用いられたRLCD（Reinforcement Learning from AI Feedback / Critic Distribution）の具体的なパイプラインはブラックボックスのままだ。しかし、そのコンセプトに触発された世界のハッカーたちが、既存のオープンモデルや独自エンコーダを駆使して、驚くべきスピードでJevライクな実装をOSSとして形にし始めている。

これらのオープン実装は、アプローチごとに明確なアーキテクチャの差異があり、エンジニアとして実に興味深い知見の宝庫となっている。主に以下の3つの系統に分類して把握することができる。

• 公式互換・ラッパー系：TypeSafe自身が提供する「System One Adapter」やGitHub Nextの実験プロジェクト「LocalJev」のように、既存のLLM APIを背後に置きつつJev互換のインターフェースを提供する層。
• 事前学習済みLLMのLogits活用系：任意のモデルの次トークン予測確率を選択肢のスコアとして転用する「Simple Jev」、Apple Silicon上でQwenから有効な選択肢のlogitsのみを抽出する「System One Lite」、同一プロンプトのprefill計算を共有してキャッシュ効率を極限まで高める「SemIf」およびそのHTTPサーバー実装「semif-serve」。また、候補を一括採点する「jevlike」や「LitJev」、さらには「DiffusionGemma」を応用する「OpenJev」などもこの潮流にある。
• 専用エンコーダ＆ヘッド学習系：小型LLMに学習済みのreadout headを結合した「kev」、約4.2億パラメータの軽量encoderと判断headを組み合わせた「Laya」およびそのApple Silicon最適化版「Laya-MLX」、DeBERTa系エンコーダでstateと複数質問を単一シーケンスとして処理する「typed-decisions」。さらには、マルチモーダル領域へ拡張し画像や音声コマンドを有限選択肢として扱う「openvons」や、画像入力からゲーム操作を直接選択するVLM実装「PlayJev」まで登場している。

我々が自社基盤やエッジ環境でJev的なアーキテクチャを内製化しようとする場合、巨大な生成モデルをホストする必要はもはやない。Layaやtyped-decisionsのように、4億パラメータ程度のコンパクトなエンコーダに分類ヘッドを乗せて蒸留・ファインチューニングを施せば、オンプレミスのGPUやローカルのApple Siliconマシン上で、商用APIに依存しないプライベートな「超高速判断エンジン」を自前で構築できる時代がすでに来ているのだ。

Jevの登場が我々ソフトウェアエンジニアに突きつけている本質的な問いは、「我々はこれまで、単なる条件分岐のために、どれほどの無駄な生成コストをLLMプロバイダーへ支払い続けてきたのか」という冷徹な現実だ。チャットUIのブームに流され、何でもかんでも汎用LLMにプロンプトを投げ、冗長な文字列を出力させてからJSONへパースするというアーキテクチャは、システム工学の観点から見れば極めて非効率なアンチパターンであったと言わざるを得ない。

「System One」という認知的比喩が示す通り、人間も日常の瞬時の判断において、脳内で長大な論理的言語化を行っているわけではない。直感的に状況を把握し、反射的に選択肢を選び取っている。Jevが切り拓いたのは、まさにこの直感的な反射層（System One）をソフトウェアの制御ループとしてAIで実装するパラダイムである。文章生成を司る重厚な「System Two」と、瞬時の判断を下す軽量な「System One」を適切に疎結合にし、パイプラインを再設計することこそが、次世代のAIアーキテクチャの必須要件となるだろう。

明日から我々が取るべき実践的なアプローチは明確だ。現在本番環境で稼働しているLLM呼び出しパイプラインを即座に棚卸しし、「その出力は本当に文章である必要があるのか」「事前定義されたフラグや分類値の抽出で事足りないか」を厳しく問い直すことだ。もしそれが単なる分岐処理であるならば、Jev APIの検証、あるいはSemIfやLaya-MLXといったオープン実装を用いたローカル推論基盤へのオフロードをただちに検討すべきである。思考停止でLLMを呼び出し続けるシステムを放置するか、それとも「賢いif文」による極小のレイテンシとゼロに近いコスト構造へアーキテクチャを刷新するか。その選択が、数カ月後のシステムの堅牢性と運用コストに決定的な差を生み出すことになるはずだ。