私たちはこれまで、単純な意思決定を含むあらゆる AI の課題に対して LLM をハンマーのように使ってきました。Jev はこうした判断をミリ秒単位で、しかも大幅に低いコストで処理します。その仕組みと適用範囲について見ていきましょう。
TypeSafe AI は 2026 年 9 月 15 日に Jev をリリースしました。会話もできず、コードも書けず、有用な文章を一文字も生成できないモデルにもかかわらず、反応は異例なほど大きかったのです。
実は、その制約こそがポイントです。
ほとんどのソフトウェアには、もう一つのチャットボットは必要ありません。必要なのは、数千もの小さな判断を下すことです。例えば、「このチケットは緊急か？」「どのモデルがこのリクエストを処理すべきか？」「このシェルコマンドは危険か？」「取得したパッセージは質問に答えているか？」といったものです。
多くのチームは、こうした判断のたびに汎用 LLM に依頼しています。モデルはトークンを一つずつ生成し、アプリケーションはそれを解析・検証し、形式が合わなければ再試行します。動作はしますが、選択肢が 5 つしかないような判断に対しては遅く、高コストです。
Jev はまさにそうした判断専用に設計されています。TypeSafe はこれを「System One モデル」と呼んでいます。非構造化された状態を入力すると、型付きの回答と確率が出力されます。
これが何を意味するのか、どこで機能するのか、そしてマーケティング上の誇張をどこまで抑えるべきかを見ていきましょう。
まず、Jev が解決する問題
ツール呼び出し（Tool Calling）と構造化出力（Structured Outputs）が登場して以来、LLM とソフトウェアの接続は劇的に容易になりました。
ツール呼び出しにより、モデルは予測可能な形式で関数を要求できるようになりました。構造化出力により、スキーマに従った JSON を返せるようになりました。これらにより、脆いパーシング処理の大部分が不要になりました。
しかし、基盤となるモデルは依然として生成型です。たとえ答えが「billing」のような単語一つであっても、トークンを逐次的に生成します。入力分のコストを支払うだけでなく、生成を待ち、出力分でもさらに高いコストが発生することがよくあります。
これをエージェントループの中に組み込んでみてください。
1while not done:2 action = llm(context)3 result = run_tool(action)4 context += result
モデルは、ツールの選択、結果の判定、リスク検知、タスク完了の判断、次のモデルの選択など、何度も呼び出される可能性があります。単一のエージェント実行において、文章生成は不要だが判断が必要な呼び出しが多数含まれることになります。
Jev はこうした呼び出しを対象としています。
その前提はシンプルです。「コードがすでに既知の答えを持っている場合、言語生成は誤ったインターフェースである」というものです。
Jev の正体
最も正確な短い説明は、「セマンティックな意思決定エンジン」というものです。
Jev には以下の 2 つを送ります。
- State：現在の状況を記述したテキストまたは JSON。
- Questions：その状態に対して下させたい判断。
すべての質問は、事前に回答の形式を宣言します。Jev は以下の 3 つの基本要素をサポートしています。
- Choice：定義済みのリストから 1 つのオプションを選択し、各オプションに対する確率を返します。
- Score：入力を low、medium、high などの順序付きスケール上に配置します。
- Noul：Yes/No の質問に対し、真である確率を返します。
Noul は TypeSafe が付けたブール値スタイルの基本要素の名前です。この独特な名前よりも重要なのは、出力（コードで処理できる 0 から 1 の間の数値）です。
1{2 "model": "jev-latest",3 "state": "The deploy failed twice and customers are seeing 500s.",4 "questions": {5 "urgent": {6 "type": "noul",7 "instructions": "Does this need attention right now?"8 },9 "owner": {10 "type": "choice",11 "instructions": "Which team should handle this?",12 "criteria": {13 "engineering": "Product failures and outages",14 "billing": "Charges, invoices, and refunds",15 "sales": "Pricing and new accounts"16 }17 }18 }19}
レスポンスには、緊急度の確率と 3 チームに対する確率分布が含まれます。解釈すべき段落もなく、モデルが勝手に作り出す第 4 のチームも存在しません。
制御権限はプログラム側が保持します。
1if urgent > 0.9 and owner == "engineering":2 page_on_call()3elif confidence < 0.6:4 send_to_human_review()5else:6 add_to_queue(owner)
だからこそ、人々は Jev を「スマートな switch ステートメント」と呼ぶのです。この表現は軽視しているように聞こえますが、設計の本質的な利点を的確に捉えています。通常のコードが分岐を所有し、モデルは通常のコードでは確実に計算できない曖昧な判断を提供します。
LLM との重要な違い
従来の LLM と Jev はどちらもサポートチケットを分類できますが、答えに至るプロセスとシステム内の役割が異なります。
TypeSafe によれば、Jev はリクエスト内のすべての質問を並列で評価します。これによりワークフローの設計が変わります。一つ質問して待ってから次の質問を決めるのではなく、同じ状態に関する独立したすべての質問を一度のリクエストで行い、コードが必要とする回答だけを使用できるのです。
同社はエンドツーエンドのレイテンシを 70〜500 ミリ秒、価格は入力トークンあたり百万個につき $0.042（出力は無料）と報告しています。ヘッドラインでは、同等の LLM ワークフローと比較して約 200 倍高速かつ 400 倍安価であると主張しています。
これらの大きな倍率は TypeSafe 自身のワークフロー評価に基づいており、比較条件としては有利な側面を示しています。すべてのアプリケーションに対する保証ではなく、上限値として捉えるべきです。ただし、Jev が境界のある判断向けに設計されているため、長い推論トレースや生成出力を回避するという根本的な優位性は信頼できるものです。
確率が重要な理由
型付きの回答だけでは問題の半分しか解決しません。
Jev がチケットを billing にルーティングしたと仮定します。選択されたラベルは「何が勝ったか」を示しますが、確率分布は「接戦だったかどうか」を示します。
1{2 "choice": "billing",3 "probabilities": {4 "billing": 0.52,5 "technical": 0.46,6 "sales": 0.027 },8 "confidence": 0.189}
このチケットを自動的にルーティングするのは無謀です。billing が勝ちましたが、僅差でした。信頼度が低い回答は別の分岐をトリガーすべきです。
これにより開発者は実用的なパターンを得られます。
- 高信頼度：影響が小さい場合は自動で対応する。
- 中信頼度：確認を求めるか、より強力なモデルを呼び出す。
- 低信頼度：人間にエスカレーションするか、追加情報を収集する。
閾値はコード内で管理され、レビューや変更が可能になります。ダッシュボードのラベルであれば弱い予測でも許容されるかもしれません。データを削除するコマンドであれば、はるかに高い基準が必要です。
TypeSafe は Jev を「Calibrated Decisions 向け強化学習（RLCD）」を用いて訓練しています。目的は、多数の予測において信頼度が精度を反映するようにすることです。モデルがある答え群に 90 パーセントの確率を与えた場合、その答えの約 90 パーセントが正解であるべきです。
ハルシネーションに関する主張は厳密さが必要
TypeSafe は「Jev はハルシネーションを起こさない」と主張しています。この記述は狭い定義のもとでのみ真です。
Jev はスキーマ外のオプションを返すことはできません。billing、technical、sales を定義すれば、legal などを作り出すことは不可能です。また、ラベルを期待するコードに対して不正な文章を生成することもありません。
しかし、有効な選択肢の中から自信を持って誤ったものを選ぶことは可能です。
型安全性は無効な形式を防ぎますが、正しい判断を保証するものではありません。この区別は重要です。スキーマ上は有効な誤りが、間違った顧客への返金、インシデントの誤ったルーティング、危険なコマンドの承認につながる可能性があるからです。
より安全な表現は「Jev は宣言された出力スキーマを破ることはないが、間違える可能性はある」というものです。
エージェント内での Jev の位置づけ
Jev は LLM を置き換えるのではなく、LLM と併用することで最も効果を発揮します。
LLM は言語や深い推論が必要な作業を担当します。計画立案、執筆、説明、ツール使用などです。Jev はそうした作業に伴う頻繁な判断を担当します。
特に魅力的な配置場所は 3 つあります。
モデルルーティング
シンプルな検索とアーキテクチャレビューで同じモデルを使う必要はありません。Jev はリクエストをスコアリングし、完了見込みが高い最も安価なモデルを選択できます。
1route = jev.choice(2 state=user_request,3 options={4 "fast": "Lookups, extraction, and small local edits",5 "powerful": "Architecture, ambiguity, and high-stakes work",6 },7)89model = fast_model if route == "fast" else powerful_model
ルーターはリクエスト自体には回答せず、どのモデルが回答すべきかを決定します。
ツールリスクゲーティング
エージェントがシェルコマンドを実行する前に、Jev はそれを read-only、reversible、destructive に分類できます。ファイルを削除するか、Git 履歴を変更するか、本番環境に触れるか、リポジトリから離れるかなどを個別の質問でチェックできます。
高信頼度の read-only アクションは継続できます。破壊的または不確実なアクションは人間の承認のために一時停止できます。LangChain の Jev 統合は、実行前にツール呼び出しをチェックするミドルウェアを通じてこのパターンを適用しています。
検証と監督
エージェントはテストが失敗しているにもかかわらず、タスクが完了したと主張することがあります。Jev は状態を検査し、境界のある質問に回答できます。テストは通ったか？ エージェントは同じアクションを繰り返していないか？ 出力はポリシーに準拠しているか？ この結果はレビューすべきか？
ハードテストが存在する場合、Jev はそれを置き換えるわけではありません。ルールが意味に依存する場所でセマンティックなチェックを追加します。
今日 Jev で解決できる問題
最適なユースケースには 3 つの共通点があります。考えられる答えを名前付けでき、慎重な人間が入力を見て迅速に判断でき、レイテンシやコストが問題になるほど頻繁に判断が発生するということです。
サポートとオペレーション
- インテント、緊急度、部門、スパム、顧客の不満度を分類する。
- 複数の小さなチェックを通じて返金やポリシー例外をルーティングする。
- 人が読む前にログやインシデントをセマンティックな深刻度でランク付けする。
単一のリクエストで、同じチケットに対してこれらの質問すべてを行うことができます。その後、コードが回答を組み合わせて実際のルーティングポリシーを作成します。
検索とリトリーバル
- クエリに答えているかどうかで取得したパッセージをリランキングする。
- 引用が主張をサポートしているかを確認する。
- 高コストな LLM にコンテキストを送る前に、無関係なチャンクをフィルタリングする。
埋め込みベクトル（Embeddings）は意味的に関連するテキストを見つけるのに優れています。Jev は特定の質問に対してあるパッセージが有用かどうかという、より狭い判断を行うことができます。
品質と安全性
- プロンプトのジェイルブレイクやプロンプトインジェクションをスクリーニングする。
- ポリシーやルーブリックに基づいて生成コンテンツをチェックする。
- 実行前にリスクのあるコード変更やツール呼び出しをフラグ立てする。
これらのチェックは決定的なコントロールの隣に配置すべきです。セマンティック分類器は曖昧なリスクに有用ですが、権限、サンドボックス、テストはソフトウェアが正確に検証できるルールを強制します。
大量分類
- ドキュメント、研究論文、製品リスト、顧客メッセージにラベルを付ける。
- フリーテキストを従来の機械学習モデル用の特徴量に変換する。
- 大規模コーパス内のすべてのアイテムを同じルーブリックでスコアリングする。
ここが、低コストがベンチマークの数値以上の意味を持つ場所です。全行に対して実行するには高すぎた判断が、通常のデータパイプラインに移行できるようになります。
リアルタイムインターフェース
- 既知のページ要素から次のブラウザアクションを選択する。
- 人が入力中にトーンや明確さをスコアリングする。
- 構造化されたゲームやシミュレーターの状態からアクションを選択する。
Jev は現在テキストのみに対応しているため、これらのシステムはまず環境をテキストまたは JSON に変換する必要があります。画面を見ているわけでも、ピクセルからプレイしているわけでもありません。
Jev が不適切な場面
答えの空間が既知でなくなると、Jev の有用性は急速に低下します。
- 回答の作成、ドキュメントの要約、コード生成、推論の説明はできません。
- 算術、カウント、日付比較、正確な文字列操作には信頼性がありません。これらの操作はコードに残してください。
- 隠れた推論ステップが複数必要な判断では苦戦します。判断をより小さな質問に分割するか、推論モデルを使用してください。
- 未知の値を直接抽出することはできません。候補値を先に特定し、その中から Jev に選ばせてください。
- 無関係なコンテキストは精度を低下させる可能性があります。判断に必要な状態のみを送ってください。
- クローズドウェイト、早期アクセス、テキストのみ入力、限られた独立したキャリブレーションデータにより、盲信するには時期尚早です。
よりシンプルなルールもあります。決定的なコードで既に問題を正しく解決できているなら、コードのままにしておいてください。通常の if ステートメントは、どんなモデルよりも速く、安価で、テストしやすいからです。
新たな障害モードを作らずに Jev を使う方法
安価なモデルでも、その誤りが再試行、手動レビュー、本番インシデントを引き起こせば高コストになります。トークン価格だけでなく、ワークフロー全体を測定してください。
賢明なロールアウトは以下のような流れになります。
- 明確な答えがある、境界があり、低リスクな判断を一つ選ぶ。
- モデルを呼び出す前にルーブリックを書く。各オプションに何が含まれるかを定義する。
- 曖昧なケースや敵対的なケースを含めた、期待される回答が付いた代表的なサンプルを収集する。
- 現在のワークフローの横でシャドウモードとして Jev を実行し、挙動を変えないようにする。
- 精度と信頼度のグラフを描き、自社のデータから閾値を設定する。
- 最も安全な分岐から自動化し、不確実なケースには人間またはより強力なモデルを残す。
- モデルバージョン、質問、基準、閾値を固定またはログに取り、変更を同じ評価セットで再現できるようにする。
質問はプログラムの一部です。コードと同じように扱い、モデルやルーブリックが変わるたびにバージョン管理、レビュー、テストを行ってください。
本当の変革
Jev が LLM よりも文章作成で優れているから面白いわけではありません。Jev は文章を書かないことを拒否しているのです。
その貢献は、ソフトウェアのような形をしたモデルインターフェースにあります。固定された回答タイプ、明示的な不確実性、並列質問、コードによる分岐制御です。
これにより、生成モデルにとって有用なコンパニオンとなります。LLM は計画、説明、コードを作成します。Jev はリクエストをルーティングし、リスクのあるアクションをゲートし、結果をチェックし、不確実性が高すぎてエスカレーションすべきタイミングを決定します。
最終的に別のモデルが Jev を置き換えたとしても、この広範なアイデアは重要です。私たちは長年にわたり、あらゆる種類の知性をテキストを通じて生成モデルに求めてきました。多くの本番システムに必要なのは、さらなる言葉ではありません。通常のソフトウェアが安全に使える、小さく迅速な判断なのです。
Jev が構築しようとしているのは、まさにこのカテゴリーです。
始める場所
Jev のためにエージェント全体を再構築することから始めないでください。現在、遅い LLM 呼び出しや頻繁に壊れる正規表現を必要としている判断を一つ見つけてください。
Jev に最小限の状態を与え、考えられる答えを定義し、現在の結果の横にその確率をログに残してください。ワークフロー全体を任せる前に、一つの分岐を担う価値があることを証明させてください。
最も有用なメンタルモデルは依然として最もシンプルなものです → Jev は、通常の if ステートメントが値は理解できるが意味までは理解できない場所に判断を加えます。
情報源と参考資料
読んでくれてありがとう。
次回の記事でお会いしましょう。
乾杯！ :)
