【ITニュース解説】TypeSafe's Jev Costs 400x Less Than an LLM. These 25 Lines of Python Do the Same Job for Free.

今日のIT業界では、ChatGPTのような大規模言語モデル（LLM）が注目を集めているが、これらのモデルには、小さな判断を下す際に過剰なリソースを消費するという課題がある。例えば、「これはスパムか？」「このツール呼び出しは安全か？」「この問い合わせはどの部署に送るべきか？」といった、言わば「コイントスの決定」のようなシンプルなタスクでも、LLMは複雑な思考プロセスを経てテキストを生成するため、時間もコストもかかる。

このような問題意識から、TypeSafe AIというスタートアップ企業が「Jev（ジェブ）」という新しいモデルを開発した。JevはLLMとは異なり、テキスト生成を一切行わない「System Oneモデル」と呼ばれる。ユーザーはJevに状況（入力データ）と、事前に定義されたいくつかの選択肢を与える。するとJevは、それぞれの選択肢が正しい可能性を確率として提示する。TypeSafeは、Jevが「RLCD（Reinforcement Learning for Calibrated Decisions）」という特殊な訓練方法によって、提示する確率が非常に正確であると主張している。つまり、Jevが「70%の確率」と言えば、それが本当に70%の信頼性を持つという意味だ。この技術によって、Jevは従来のLLMと比較して最大200倍高速で、400倍低コストで分類タスクを処理できると報じられている。Jevの主な用途としては、AIエージェントが危険な操作を実行しないように判断する「安全ゲート」、受信したリクエストを適切なエージェントやモデルに振り分ける「ルーティング」、大量のデータに対して感情分析やカテゴリ分類、リスク評価を行う「バルク分類」などが挙げられる。

しかし、Jevの発表後すぐに、NobodyWhoというグループが「Jevは25行のPythonコードで再現できる」という挑戦的なブログ記事を公開し、大きな議論を巻き起こした。彼らが示したコードは、Qwen3-0.6Bという比較的軽量なLLMをローカルで動かし、Jevと同様の機能を実現するものだった。その方法は、LLMがテキストを生成する代わりに、内部的に持っている「ロジット」という値を直接読み取るというものだ。「ロジット」とは、LLMが次にどの単語や文字を選ぶかの「可能性の強さ」を示す内部的な数値である。このロジットから特定の選択肢（例えば「スパム」や「正当」といった単語）に対応する確率を計算することで、テキスト生成のプロセスをスキップし、高速かつ低コストで分類結果と確率を得られる。この手法は、APIを通じて外部サービスを呼び出す必要がなく、データを外部に送信する心配もないため、プライバシーやセキュリティが重要な場面で非常に有利だ。NobodyWhoの主張は、Jevが提供する「高速で確率付きの分類」というコア機能が、実際には古くから知られている技術の応用であり、TypeSafe AI独自の工夫は訓練方法やブランド名にあるというものだった。実際、OpenJevをはじめとする複数のオープンソースプロジェクトが、このJevスタイルの分類機能を実装している。

さらに、Jevの「キャリブレーション」（モデルが提示する確率が、実際の事象の発生確率とどれだけ一致しているか）についても疑問が投げかけられた。アレックス・モラスは、「キャリブレーションはモデルだけでなく、そのモデルが適用されるデータの分布にも依存する」と指摘した。つまり、TypeSafe AIがJevを訓練したデータと、実際にユーザーがJevを使う際のデータが異なれば、Jevが「70%の確率」と提示しても、それが本当に70%の信頼性を持つとは限らないのだ。公正なコインの例で、Jevが「表が出る確率0.92」と不正確な予測をした事例や、アークツゥルス・ラボが行った詳細なテストでも、Jevの確率出力が理想的な線から大きくずれることが示された。これらの結果から、Jevの出力はそのまま「確率」として信用するのではなく、各選択肢の「スコア」として捉え、ユーザー自身で追加の検証を行うべきだという結論が導き出された。

システムエンジニアがこのような分類タスクを実装する際、Jevのようなマネージドサービスと、25行のPythonコードで示されたようなローカルで実行するアプローチのどちらを選ぶべきか、いくつかの判断基準がある。

まず、もし手元に訓練データがなく、今すぐ分類機能が必要な場合は、Jevのようなゼロショット（学習なし）で動作するユニバーサル分類器が非常に強力な選択肢となる。オープンソースの代替も同様に役立つだろう。 次に、扱うデータが機密性が高く、外部に送信できない場合は、ローカルで動作する25行のPythonスクリプトのようなアプローチが最適だ。既存のハードウェアで動く小規模なモデルを使えば、データのプライバシー問題を回避できる。 また、大規模なシステムでミリ秒単位の応答速度やわずかなコスト削減が重要になる場合は、TypeSafeが主張する200倍高速、400倍低コストという数字が自身のワークロードで再現されるか検証した上で、Jevのような最適化されたマネージドサービスを検討する価値がある。 しかし、リスク評価など、提示される確率の「正確さ」が極めて重要な場合は、どちらのソリューションもそのままでは不十分と考えるべきだ。少量のラベル付きデータを自身で用意し、モデルのキャリブレーションを測定し、その結果に基づいて信頼できるモデルを選ぶ必要がある。 そして、既に推論用のインフラストラクチャを運用している場合は、25行のスクリプトで示されたような「ロジット読み取り」のテクニックは、既存システムに比較的容易に組み込める。新たなAPIへの依存を増やし、管理コストを払うよりも、この手法を自身で実装する方が理にかなっている場合が多い。

この事例から得られるより大きな教訓は、新しい技術やサービスが華々しく登場した際、その裏側にある技術が本当に画期的なものなのか、それとも既存の知られた技術を新しい名前で再パッケージ化したものなのかを冷静に見極めることの重要性だ。時には、サービスの使いやすさや高度な訓練、安定した運用によって、その「抽象化の価格」が正当化されることもある。しかし、時には、シンプルなスクリプトで同等の機能を実現できてしまうこともある。

もし、今週エージェントパイプラインに意思決定ゲートを組み込むとしたら、まずローカルで動作する25行のスクリプトのような手法を試すだろう。実際のデータで分類を行い、モデルが提示する確率をログに記録し、その結果から何が正しく、何が間違っていたかを検証する。これにより、自身のデータに基づいた「キャリブレーションカーブ」を作成できる。もし、0.6Bのような小さなモデルで十分な性能が得られれば、それ以上のコストはかからない。もし不十分であれば、その性能を上回るJevや他のオープンソースの実装を検討することになる。このように、まず自身で測定し、それから最適なものを選択するというアプローチは、特に分類問題のように事後に正解データを比較的容易に収集できる分野では非常に有効だ。