9月21日、Arcturus Labsが「Will OpenAI Eat Jev's Lunch?」と題した記事を公開した。テキストを生成せず「即時の確率的判断」だけを返すAIモデル「Jev」は、Vercelが「AI Gatewayの歴史上どのモデルよりも速く採用された」と評するほど急速に普及した。だがOpenAIはその仕組みをすでに2024年初頭から実装していた——そう聞けば、Jevを開発したTypeSafeが築いた「堀」がどこにあるのかが気になる。
AI業界では「LLMで分類タスクを解く」試みは以前からあったが、Jevはそれを汎用的なAPIとして整備し、一般開発者が使いやすい形で提供した点が新しい。問題は、OpenAIがその気になれば同じことを即座に実現できるかどうかだ。AIコンサルティング会社Arcturus Labsの著者はこの問いを正面から分析し、TypeSafeの勝ち筋と死角を論じている。
OpenAIはすでに同じ仕組みを使っていた
著者が最も力を入れて論じているのが、「OpenAIはJevの核心部分をずっと使っていた」という指摘だ。
OpenAIのツール呼び出し（function calling）の内部では、モデルが<|im_start|>assistant直後に生成する最初のトークンが\nかto=function.のどちらかになる。このトークン1つが「ツールを呼ぶか否か」を決める分類器として機能している。続くトークン列がどのツールを呼ぶかを決め、引数値もそれぞれ一種の分類・推定として機能する。さらに<|im_end|>トークンは「応答が完了したか」を判定するミニ分類器だ。
つまりOpenAIは、単一トークンを微小な分類器として使う手法を少なくとも2024年初頭から実装してきた。JevはこれをGeneralな分類タスク向けに拡張したものとも見られ、アーキテクチャ上の距離は著者の見立てでは小さい。
Jevとは何か
TypeSafe（共同創業者：Diogo Almeida）が開発した「Jev」は、LLMを使って「テキスト生成」ではなく「確率的な即時判断」を返すことに特化したモデルだ。その詳細な仕組みについては、Arcturus Labs自身が別途解説記事を公開している。
仕組みはシンプルだ。LLMに状態（state）と質問（questions）を与えると、モデルは次トークンの確率分布を生成する。Jevはその分布から特定のトークンだけを取り出す。例えばbool（true/false）型の質問ならtrueとfalseの2トークンだけを正規化して確率値として返す。choice型なら選択肢に対応するトークンの相対確率を比較して勝者を決める。テキスト生成は一切行わず、判断だけを返す設計だ。
Latent Space（AI分野の著名なポッドキャスト・ニュースレター）によれば、公開直後からLLMベースのクローンが多数登場しており、アーキテクチャの再現は技術的に難しくないことが示唆されている。
TypeSafeの「堀」はどこにあるか
著者がTypeSafeを応援しつつも懸念するのがこの点だ。アーキテクチャ面での堀はほぼないというのが著者の結論だ。
本命の堀として著者が挙げるのは訓練データと訓練プロセスだ。TypeSafe共同創業者のDiogo Almeida自身も、アーキテクチャよりデータが重要だと示唆している。
著者が想定する理想的な訓練データのイメージはこうだ：サポートチケットと実際のルーティング結果、履歴書と採用結果、商品レビューと実際の星評価、モデレーションキューと実際の判定、予測市場とその結果——いずれも「正解がすでに分かっている」事例を大量に集め、幅広いドメインをまたいで汎化させる。特定ドメインの知識を教えるのではなく、分類する能力そのものを鍛えるアプローチだ。
ただし、これらの堀はJevが実際に精度を出せる場合に限って有効だ。著者自身もJevの確率値が通用しないドメインをすでに発見しており、汎化精度の検証はこれからだと指摘している。
OpenAIが「Jevを超える」シナリオ
著者が最も興味深い論点として提示するのが、OpenAIが単にJevをコピーするだけでなく、分類能力をLLM本体に統合するシナリオだ。
具体的には、モデルが思考ブロック内で<prediction>タグを使い、外部ツールを呼ばずにGPU上で即座に分類判断を行うというアイデアだ。以下は著者が示したイメージ例で、モデルが推論中に確率値を内部で計算しつつ、ユーザーへの返答を続ける様子を示している：
<assistant>
<thinking>
<prediction>
claim: Donny is romantically interested in Jess.
probability: 0.04
</prediction>
Yeah, "nice haircut" is not exactly a love confession.
</thinking>
I hate to break it to you, but... probably not.
</assistant>
通常のツール呼び出しでは、モデルが関数名と引数を生成した後、エージェント側が実際に関数を呼び出し、結果を次のターンでモデルに返す。しかしこの設計ではハンドオフが不要だ。probability:の位置でtrueとfalseのlogprobだけを正規化した値をシーケンスに書き戻し、モデルはそれを自分が生成した数値として処理を続ける。
このパターンが実現すると、モデルは以下のことが可能になると著者は論じる：
- 長い推論トレースの途中で自分が「完了しているか」を確認し、次に何をすべきかを選択する
- ツール呼び出しの前に、その呼び出しが安全かどうかをチェックする（例：平文で渡されたAPIキーの危険性を検出する）
- ツールのレスポンスにプロンプトインジェクションが含まれていないかスキャンする
いずれも「GPU外に出ずに」実行できる点がポイントだ。これはTypeSafeが単体製品として提供できる範囲を超えており、モデルプロバイダーとしてのOpenAIにしか実現できない優位性だ。
まとめ：日本のエンジニアにとっての示唆
著者の見立てをまとめると、OpenAIがJevを模倣する技術的障壁は低く、さらにその能力をモデル本体に統合することで、TypeSafeには再現できない優位性を得られる可能性がある。TypeSafeの本当の勝負どころは精度と訓練プロセスの独自性にあるが、それが堀として機能するかは、Jevが幅広いユースケースで安定した精度を出せるかどうかにかかっている。
日本のエンジニアにとっても、分類・判定タスクをLLMで汎用的に解くというアプローチは実用上の需要が高い。Jevのような専用モデルが普及するか、それともOpenAIが同等機能を標準APIに組み込むかは、設計の選択肢に直結する問いだ。今後のTypeSafeとOpenAIの動向は注視しておく価値がある。
詳細はWill OpenAI Eat Jev's Lunch?を参照していただきたい。
