私たちは、単純な判断も含め、AIに関するあらゆる問題にLLMを使ってきました。Jevは、そのような判断をミリ秒単位で、はるかに低いコストで処理します。その仕組みと、どのような場面で役立つのかを見ていきましょう。
TypeSafe AIは2026年9月15日にJevを公開しました。会話も、コードの記述も、役に立つ文章の生成もできないモデルとしては、異例の反響を呼びました。
実は、その制約にこそ意味があります。
多くのソフトウェアが必要としているのは、新しいチャットボットよりも、何千もの小さな判断です。たとえば「この問い合わせは緊急か」「この依頼はどのモデルに任せるべきか」「このシェルコマンドは危険か」「検索で見つけた文章は質問への答えになっているか」といった判断です。
開発チームは、こうした判断を一つずつ汎用LLMに任せがちです。モデルが1トークンずつ答えを生成し、アプリケーションがそれを解析して検証する。形式が間違っていれば、再試行する。この方法でも動きますが、選択肢が五つしかない判断には、時間もコストもかかりすぎます。
Jevは、まさにそのような判断のために作られました。TypeSafeはこれを「System Oneモデル」と呼んでいます。非構造化された状況の情報を入力すると、型の定まった回答と確率が返ってきます。
それは何を意味するのか。どこで役立ち、宣伝文句のどこを慎重に受け止めるべきなのか。順に見ていきます。
Jevが解こうとしている問題
ツール呼び出しと構造化出力の登場によって、LLMをソフトウェアに組み込むことは、ずっと簡単になりました。
ツール呼び出しでは、モデルが予測可能な形式で関数の実行を要求できます。構造化出力では、定義したスキーマに従うJSONを返せます。どちらも、壊れやすい解析処理を大幅に減らしました。
ただし、基盤にあるモデルは依然として生成モデルです。答えが「billing（請求）」の一語だけでも、トークンを順番に生成します。入力に料金がかかり、生成を待ち、多くの場合は出力にも料金がかかります。
これをエージェントの処理ループに組み込むと、どうなるでしょうか。
while not done:
action = llm(context)
result = run_tool(action)
context += result
ツールの選択、結果の評価、リスクの検出、タスク完了の判定、次に使うモデルの選択。そのたびに、モデルが再び呼び出されるかもしれません。一回のエージェント実行の中に、判断は必要でも文章の生成は不要な呼び出しが、いくつも含まれるのです。
Jevが対象とするのは、そうした呼び出しです。
その発想は単純です。コード側で答えの候補がわかっているなら、言語生成を通じて答えを受け取る必要はない、ということです。
Jevとは何か
最も短く、正確に表すなら、「意味を理解して判断するエンジン」です。
Jevには、二つの情報を渡します。
- State：現在の状況を説明するテキストやJSON。
- Questions：その状況について、判断してほしいこと。
それぞれの質問では、回答の形式をあらかじめ宣言します。Jevには、次の三つの基本機能があります。
- Choice：定義したリストから選択肢を一つ選び、すべての選択肢について確率を返します。
- Score：「低・中・高」など、定義した順序のある尺度で入力を評価します。
- Noul：はい・いいえで答えられる質問に対して、その命題が真である確率を返します。
Noulは、真偽値に相当する基本機能にTypeSafeが付けた名前です。少し変わった名前ですが、大切なのは出力です。コードの判断に使える、0から1の数値が返ってきます。
{
"model": "jev-latest",
"state": "The deploy failed twice and customers are seeing 500s.",
"questions": {
"urgent": {
"type": "noul",
"instructions": "Does this need attention right now?"
},
"owner": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"engineering": "Product failures and outages",
"billing": "Charges, invoices, and refunds",
"sales": "Pricing and new accounts"
}
}
}
}
返ってくるのは、緊急対応が必要である確率と、三つの担当チームに対する確率分布です。解釈しなければならない文章はなく、モデルが四つ目のチームを勝手に作ることもありません。
処理の制御は、プログラム側に残ります。
if urgent > 0.9 and owner == "engineering":
page_on_call()
elif confidence < 0.6:
send_to_human_review()
else:
add_to_queue(owner)
Jevが「賢いswitch文」と呼ばれるのは、このためです。軽く扱っているようにも聞こえますが、設計の有用な部分をよく捉えています。分岐は通常のコードが管理し、通常のコードでは確実に計算しきれない曖昧な判断を、モデルが補います。
LLMとの重要な違い
従来のLLMもJevも、サポートへの問い合わせを分類できます。ただし、答えに至る方法が異なり、システム内で役立つ場所も違います。
TypeSafeによると、Jevは一つのリクエストに含まれるすべての質問を並列に評価します。これによって、ワークフローの設計も変わります。一問ずつ質問して回答を待ち、次の質問を決める代わりに、同じ状況について互いに独立した質問を一度に送り、コード側で必要な回答を使えます。
同社の発表では、リクエストから応答までの遅延は70〜500ミリ秒。料金は入力100万トークンあたり0.042ドルで、出力は無料です。同等のLLMワークフローと比べて、最大で約200倍の速度、約400分の1のコストをうたっています。
この大きな倍率は、TypeSafe自身によるワークフロー評価のうち、特に有利な比較結果に基づいています。あらゆるアプリケーションで約束される性能ではなく、好条件での上限として捉えるべきです。
それでも、根本にある利点には納得できます。Jevは、答えの範囲が限られた判断のために設計されているため、長い推論過程や出力の生成を省けるのです。
確率が重要な理由
回答の型が決まっているだけでは、問題の半分しか解決しません。
Jevが問い合わせを請求担当に振り分けたとします。選ばれたラベルからわかるのは、どの候補が最上位だったかです。確率分布を見れば、ほかの候補とどれほど僅差だったのかもわかります。
{
"choice": "billing",
"probabilities": {
"billing": 0.52,
"technical": 0.46,
"sales": 0.02
},
"confidence": 0.18
}
この問い合わせを自動で振り分けるのは、慎重さを欠きます。請求担当が最上位ではありますが、わずかな差しかありません。確信度の低い回答は、別の処理へ分岐させるべきです。
開発者は、次のような実用的な処理を組めます。
- 確信度が高い：結果の影響が小さければ、自動で処理する。
- 確信度が中程度：確認を求めるか、より高性能なモデルを呼び出す。
- 確信度が低い：人に判断を任せるか、追加情報を集める。
しきい値は、レビューや変更ができるようにコードで管理します。ダッシュボードに表示するラベルなら、確度の低い予測を許容できるかもしれません。一方、データを削除するコマンドには、はるかに厳しい基準が必要です。
TypeSafeは、Reinforcement Learning for Calibrated Decisions（RLCD）という手法でJevを訓練しています。狙いは、多数の予測を通して見たときに、確信度が実際の正解率を反映するようにすることです。モデルが90％の確率を付けた回答を集めれば、その約90％が正しい状態を目指します。
「ハルシネーションを起こさない」の意味を正確に捉える
TypeSafeは、Jevはハルシネーションを起こさないと説明しています。ただし、これが成り立つのは、ハルシネーションを狭く定義した場合に限られます。
Jevはスキーマにない選択肢を返せません。請求・技術・営業を定義したなら、法務という選択肢を勝手に作ることはありません。コードがラベルを期待している箇所に、形式の合わない文章を返すこともありません。
しかし、有効な選択肢の中から、誤ったものを高い確信度で選ぶ可能性はあります。
型安全性が防ぐのは、不正な出力形式です。判断の正しさまでは保証しません。この区別は重要です。スキーマに適合した回答でも、間違った顧客に返金したり、障害の対応先を誤ったり、危険なコマンドを承認したりする可能性はあるからです。
より正確には、「Jevは宣言された出力スキーマを破らないが、判断を誤ることはある」と説明するべきでしょう。
エージェントの中でJevをどう使うか
Jevは、LLMと組み合わせて使うと力を発揮します。
言語や深い推論が必要な仕事は、LLMが担当します。計画を立て、文章を書き、説明し、ツールを使う。その周辺で頻繁に発生する判断を、Jevが担当します。
特に有望なのは、次の三つの使い方です。
モデルの振り分け
単純な情報検索に、アーキテクチャのレビューと同じモデルは必要ありません。Jevは依頼を評価し、完遂できそうなモデルの中から、最も安価なものを選べます。
route = jev.choice(
state=user_request,
options={
"fast": "Lookups, extraction, and small local edits",
"powerful": "Architecture, ambiguity, and high-stakes work",
},
)
model = fast_model if route == "fast" else powerful_model
振り分けを行うモデルの役割は、依頼に答えることではなく、どのモデルに答えさせるかを決めることです。
ツール実行前のリスク判定
エージェントがシェルコマンドを実行する前に、Jevで「読み取り専用」「元に戻せる操作」「破壊的な操作」に分類できます。別々の質問で、ファイルを削除するか、Gitの履歴を書き換えるか、本番環境に触れるか、リポジトリの外にアクセスするかも確認できます。
高い確信度で読み取り専用と判断できた操作は、そのまま進める。破壊的な操作や判断が不確かな操作は、人の承認を待つ。LangChainのJev連携では、実行前にツール呼び出しを確認するミドルウェアを通して、この方式を採用しています。
検証と監督
エージェントは、テストがまだ失敗していても、タスクが完了したと主張することがあります。Jevは状況を確認し、答えの範囲が限られた質問に回答できます。「テストは通ったか」「同じ操作を繰り返していないか」「出力は方針に従っているか」「この結果はレビューすべきか」といった質問です。
明確なテストがあるなら、それを置き換えるものではありません。意味を読み取らなければ判定できない箇所に、追加の確認を加えます。
Jevが現在対応できる用途
相性のよい用途には、三つの共通点があります。答えの候補を列挙できること、注意深い人なら入力を見て短時間で判断できること、そして遅延やコストが問題になるほど頻繁に判断が発生することです。
サポートと運用
- 問い合わせの意図、緊急度、担当部署、スパムかどうか、顧客の不満の度合いを分類する。
- 返金や規定の例外対応を、複数の小さな確認を通して適切な処理先に振り分ける。
- 人が読む前に、ログやインシデントを内容に基づく深刻度で順位付けする。
同じ問い合わせについて、これらすべてを一度のリクエストで質問できます。コード側で回答を組み合わせ、会社の実際の振り分け方針に沿って処理します。
検索と情報取得
- 検索された文章を、質問への答えになっているかどうかで並べ替える。
- 引用元が主張を裏付けているかを確認する。
- 高価なLLMにコンテキストを送る前に、無関係な文章の断片を除外する。
埋め込みは、意味的に関連する文章を見つけることに優れています。Jevは、そこからさらに踏み込み、「この文章は、この質問に役立つか」という判断を担えます。
品質と安全性
- プロンプトに、安全上の制約を回避する試みやプロンプトインジェクションがないかを調べる。
- 生成された内容を、方針や評価基準に照らして確認する。
- リスクのあるコード変更やツール呼び出しを、実行前に検出する。
こうした確認は、明確な規則に基づく制御と併用するべきです。意味を判断する分類器は曖昧なリスクの検出に役立ちます。一方、権限、サンドボックス、テストは、ソフトウェアが厳密に検証できる規則を強制します。
大量のデータの分類
- 文書、研究論文、商品情報、顧客メッセージにラベルを付ける。
- 自由記述の文章を、従来の機械学習モデルで使う特徴量に変換する。
- 大規模な文書集合の各項目を、同じ評価基準で採点する。
ここでは、一回あたりのコストの低さが、ベンチマークの数字以上の意味を持ちます。これまでは費用がかかりすぎて全件に適用できなかった判断を、通常のデータ処理に組み込めるようになるからです。
リアルタイムのインターフェース
- 既知のページ要素から、ブラウザーで次に行う操作を選ぶ。
- ユーザーが文章を書いている最中に、語調やわかりやすさを評価する。
- 構造化されたゲームやシミュレーターの状態から、行動を選択する。
現時点のJevが扱えるのはテキストだけなので、こうしたシステムでは、まず環境の情報をテキストやJSONに変換する必要があります。画面を直接見たり、画像のピクセルからゲームをプレイしたりするわけではありません。
Jevが向いていない用途
答えの候補があらかじめわからなくなると、Jevの有用性は下がります。
- 返答の文章を書く、文書を要約する、コードを生成する、判断理由を説明するといったことはできません。
- 四則演算、数を数える処理、日付の比較、厳密な文字列操作には信頼性の面で不安があります。これらはコードで処理してください。
- 判断に複数段階の推論が必要な場合は苦手です。判断を小さな質問に分けるか、推論モデルを使ってください。
- 未知の値を直接抽出することはできません。先に候補となる値を見つけ、その中からJevに選ばせてください。
- 無関係なコンテキストは精度を下げることがあります。判断に必要な状況だけを渡してください。
- モデルの重みは非公開で、提供は早期アクセスの段階です。入力はテキストのみで、確率の校正に関する独立した検証データも限られています。無条件に信頼するには、まだ早いでしょう。
さらに単純な原則もあります。決まった規則に従うコードで、すでに問題を正しく解けているなら、そのコードを使い続けてください。通常のif文は、どのモデルよりも速く、安価で、テストも容易です。
新たな失敗の原因を増やさずに導入する
安価なモデルでも、誤りによって再試行や人のレビュー、本番環境での障害が増えれば、結果的に高くつきます。トークン単価だけでなく、ワークフロー全体を測定してください。
現実的な導入手順は、次のとおりです。
- 答えの候補が明確で、範囲が限定された、リスクの低い判断を一つ選ぶ。
- モデルを呼び出す前に評価基準を書き、各選択肢に何が該当するのかを定義する。
- 期待する回答を付けた代表的な事例を集める。曖昧な事例や、意図的に誤判断を誘う事例も含める。
- 既存のワークフローと並行してJevを動かす。実際の動作には影響を与えない「シャドーモード」で評価する。
- 確信度と正解率の関係をグラフにし、自分たちのデータに基づいてしきい値を決める。
- 最も安全な分岐から自動化し、不確かなケースは人や、より高性能なモデルに任せる。
- モデルのバージョン、質問、判断基準、しきい値を固定するか記録する。変更時に、同じ評価データで再検証できるようにする。
質問もプログラムの一部です。コードと同じようにバージョン管理し、レビューし、モデルや評価基準を変更するたびにテストしてください。
Jevがもたらす変化
Jevの面白さは、文章を書かないという設計にあります。
回答の型が決まっている。不確実性が明示される。複数の質問を並列に評価できる。分岐はコードで制御する。Jevが提供するのは、ソフトウェアに組み込みやすいモデルのインターフェースです。
そのため、生成モデルと組み合わせる価値があります。LLMは計画や説明、コードを生成します。Jevは依頼を振り分け、危険な操作の実行可否を判断し、結果を確認し、不確実性が高いときに人や別のモデルへ判断を委ねます。
いずれ別のモデルがJevに取って代わったとしても、この考え方は重要です。私たちは何年も、あらゆる知的な処理を文章を通して行うよう、生成モデルに求めてきました。しかし、多くの本番システムが必要としているのは、通常のソフトウェアが安全に扱える、小さくて速い判断です。
Jevが作ろうとしているのは、そのようなモデルのカテゴリーです。
どこから始めるか
最初から、Jevを中心にエージェント全体を作り直す必要はありません。今、遅いLLM呼び出しや、頻繁にうまく動かなくなる正規表現で処理している判断を、一つ見つけてください。
Jevに必要最小限の状況を渡し、答えの候補を定義して、既存の処理結果と一緒に確率を記録します。ワークフロー全体を任せる前に、まず一つの分岐を任せる価値があるかを確かめましょう。
Jevは、通常のif文が値を扱えても、その意味までは理解できない場所に、判断を加えるものです。こう捉えると、その役割がわかりやすくなります。
出典・参考資料
- TypeSafe AI：Introducing System One Models and Jev
- LangChain：Building a Harness with Jev
- Flavio Copes：A deep dive into Jev
楽しんで読んでいただけたなら、うれしいです。
それでは、また次の記事で！