Jevとは何か — 文章を生成しないAIモデルがLLMやAIエージェントと違う点

Jev（ジェヴ）は、2026年9月15日にTypeSafe AIが早期アクセスで公開したAIモデルです。最大の特徴は、文章を一切生成せず、あらかじめ型を決めた「判断」と確率だけを返すこと。同社はこれを「System One Model」という新しいモデル種別と呼んでいます。LLMとの違いはトークンを1つずつ生成するのをやめた点にあり、AIエージェントとの違いは制御フロー（次に何をするかの決定）をコード側が握り続ける点にあります。ChatGPTやClaudeの置き換えではなく、ソフトウェアの中に置く判断部品です。

Jevが返すのは「型付きの判断」だけ

Jevへの入力は、テキストまたはJSONのstate（対象となる状態）と、型の決まったquestion（問い）です。公式ドキュメントによると、問いの型は3つだけです。

• Choice: 定義済みの選択肢から1つ選ぶ。選択結果、全選択肢の確率、確信度を返す
• Score: 順序のある評価尺度で採点する。スコア、各水準の確率、確信度を返す
• Noul: 「この記述は真か」を0〜1の確率で返す

3種類は1回のAPI呼び出しに混在させられ、各問いは同じstateに対して並列・独立に評価されます。問いを増やしても応答時間はほとんど変わらない、というのが公式の説明です。逆に、前の答えを見てから次の問いを決める処理は1回では終わらず、コード側で2段に分ける必要があります。

公表されている仕様は、入力100万トークンあたり0.042ドル、出力トークンは無料（課金できないほど安い）、応答時間は70〜500ミリ秒。現行版はjev-1.13で、入力はテキストのみ、stateと最長の問いの合計で32,000トークンが上限です。OpenRouterやCloudflare Workers AIのモデル一覧にも掲載が始まっています。

LLMとの違いは「構造化出力できるか」ではない

「JSONを返せるAI」と説明すると誤解を招きます。既存のLLMにもJSON Schemaに沿って出力を強制する構造化出力の仕組みがあり、形式を守ること自体は新しくありません。違いは生成の仕方です。

LLMは構造化出力でも、内部では「JSON文字列を1トークンずつ予測する」逐次処理を行います。Jevにはテキスト生成の工程がなく、事前に定義された値の上の確率分布を1回のクエリで並列に出します。TypeSafeはこの結果として、型エラーが原理的に起きないこと（スキーマ一致が保証されるため0%と表記している）、および存在しない選択肢を答える形の幻覚が発生しないことを主張しています。ただしこれは形式の正しさの話で、判断の中身が常に正しいという意味ではありません。だからこそ全出力に確信度が付き、学習にもRLHFではなく「Reinforcement Learning for Calibrated Decisions（RLCD）」という独自手法を使い、確信度が高いほど実際に正確になるよう訓練したと説明しています。

AIエージェントとの違いは「誰が次の行動を決めるか」

AIエージェントは、ツール一覧や履歴をLLMに渡し、LLM自身が次に呼ぶツールと順序を決めます。柔軟ですが、判断の根拠が長いプロンプトの中に埋まり、どこで誤ったのか追いにくくなります。

Jevはエージェントではありません。自分で次の行動を選ばず、与えられたstateに対して問いへの答えを返すだけです。ルーティングやツール選択の基準はコードに書かれたままで、曖昧な意味判断だけをモデルに外注する形になります。公式ドキュメントはこの使い方を「smart if-statement（賢いif文）」と表現し、確信度をしきい値に使って自動実行・LLMへのフォールバック・人のレビューへ振り分ける設計パターンを示しています。

したがってエージェントと競合するというより、エージェントの内側に入る位置づけです。公式が挙げる用途にも、LLMの入出力や推論トレースの採点・ガードレール・ジェイルブレイク検知、大量データへのmap-reduce、100ms程度の遅延が許される実時間処理が並びます。実際にコマンド実行の安全審査やスキル選択に置き換えた事例報告も出始めています。

「193.6倍速い・444.6倍安い」の読み方

この数値は、TypeSafeが自社で設計した4種のワークフロー評価（請求書処理、顧客対応、セキュリティ対応、エージェント実行の監視）から出たもので、同社自身が「実世界で得られる改善幅としては大きい側」と留保しています。さらに注意すべき点が公式に明記されています。

• 参照値は人手の正解ラベルではなく、GPT-6 AstraとFable 5.1の回答確率の平均。参照側が誤れば一致率と実務上の正しさはずれる
• 比較対象のLLMは、同社が公開した「System One LLM」ラッパー経由で確率付きの構造化判断を出させている。確率を求めない使い方より遅く高くなりやすい
• ワークフローは自社のモデル能力チームが作成しており、バイアスの可能性を同社が認めている
• 速度計測は米国西海岸にあるサービス近くから実施。日本から呼べばネットワーク遅延が上乗せされる

つまり現時点で言えるのは「狭い判断を大量に繰り返す経路では、生成型LLMより大幅に速く安くなり得る」までです。第三者による独立検証はまだ乏しく、あらゆる知的作業でフロンティアLLMと同等という話ではありません。

向く用途と、避けるべき用途

TypeSafeはモデル版ごとに「jaggedness（苦手な点）」のページを公開しており、判断材料として最も実用的です。jev-1.13について挙げられているのは次のような制約です。

• 数値の精度が必要な処理は苦手。文字数や出現回数の数え上げ、値の近さの比較はコード側で計算して結果か区分名を渡す
• 問いは字面どおりに解釈される。限定語・否定・暗黙の条件は書いたとおりに読まれるため、基準を明示するか2つの問いに分ける
• stateは敵対的な入力として扱われない。埋め込まれた指示や誘導的な書き方で答えが動く可能性がある
• stateに不要な情報を詰めると精度が落ちる。検索と絞り込みはコードで先に済ませる
• 間接的な推論を重ねる課題、長文生成、コード生成、画像や音声は対象外

逆に相性が良いのは、問い合わせの分類とルーティング、コンテンツモデレーション、ログやチケットの優先度判定、検索候補の再ランキング、LLM出力の検査といった、同じ形の短い判断を繰り返す処理です。「確定ルールは通常のコード、曖昧で反復する狭い判断はJev、長文生成や複雑な説明はLLM、重大な例外は人」という分担が現実的な設計です。

検証するときに確かめる順番

早期アクセスはウェイトリスト経由で、一般提供の時期は未発表です。試すなら次の順で確かめると判断を誤りにくくなります。

1. いま生成LLMに投げている処理のうち、出力が実質「分類・採点・真偽」になっているものを洗い出す。ここが置き換え候補
2. その判断を原子的な問いに分解する。「この提案を評価して」ではなく、市場規模・実現性・差別化のように独立した問いに割る
3. 自社の実データで一致率を測る。参照は他モデルではなく人手ラベルにする
4. 確信度のしきい値を決め、低確信を人やLLMへ回した場合に「誤りがどれだけ減り、自動化できる件数がどれだけ残るか」を測る
5. 日本からのネットワーク遅延、レート制限、再判定を含めた実測でエンドツーエンドの時間と費用を出す。人手レビューの工数も費用に入れる
6. 本番ではjev-latestではなくjev-1.13.0のようにバージョンを固定し、応答のmodelフィールドをログに残す

注目すべきは倍率そのものより、設計の考え方です。TypeSafe自身の評価でも、判断を明示的なワークフローに分解した方が比較対象のLLMも速く安く正確になっていました。分解して確信度で分岐させ、決定的な部分をコードに残す設計は、いま手元にあるモデルでも今日から効きます。Jevを待たずに、まずその形にできるかを見直すのが最初の一歩です。

出典

• TypeSafe AI: System One ModelsとJevの発表（留保事項・評価方法を含む）
• TypeSafe AI 公式ドキュメント: はじめに（Choice / Score / Noul と設計方針）
• TypeSafe AI 公式ドキュメント: jev-1.13の苦手な点（32kトークン上限・数値精度・プロンプトインジェクション）
• TypeSafe AI: ワークフロー評価の詳細
• OpenRouter: Jev 1.13の価格とコンテキスト長
• Cloudflare AI ドキュメント: Jev（typesafe）のリクエストと応答例
• PC Watch: LLMの193倍速い“判断だけのAI”「Jev」
• GIGAZINE: LLMとは異なる方式でタスクを処理するAIモデル「Jev」
• Yahoo Finance掲載のプレスリリース: TypeSafe AIが4,000万ドルのシード資金でステルスを解除