Jevとは？文章ではなく“判断”を返すSystem One Modelを解説

Jevの要点を先に整理

Jevは、質問に文章で答えるチャットAIではありません。入力された文章やプログラムの状態を読み取り、分類、優先順位付け、ルーティング、承認・拒否といった判断を構造化された値で返すモデルです。TypeSafe AIはこの種類を『System One Model』と呼び、Jevを最初の公開モデルと位置付けています。

重要なのは、JevがLLMの全面的な代替ではない点です。説明文、要約、コード、会話など自由な文章を作る仕事はLLMが得意です。Jevが狙うのは、出力候補を事前に決められる反復的な判断を、ソフトウェアの処理経路へ低コストで組み込む領域です。

開発したTypeSafe AIとDiogo Almeida氏

TypeSafe AIの創業者Diogo Almeida氏は、OpenAIで言語モデルの指示追従や対話能力に関する研究開発へ関わった人物です。同社の公式発表によると、会話モデルが高性能になっても、ソフトウェアが自律的に使える判断へ直接つながりにくいことを問題意識として、約2年間のステルス開発を経てJevを公開しました。

TechCrunchは、Almeida氏が人間の好む回答を学ぶRLHFの開発に関与した元OpenAI研究者だと報じています。ただし『ChatGPTを一人で発明した人物』という意味ではありません。記事では、複数人・複数研究の積み重ねであることが伝わる表現を使う必要があります。

System One Modelは何が新しいのか

名称は、心理学者Daniel Kahnemanが広めた『速く直感的なSystem 1』と『遅く熟考するSystem 2』の区分に由来します。Jevは長い推論文を作るのではなく、ソフトウェアがすぐ利用できる判断を短時間で返す設計です。TypeSafe AIは、新しいモデル構造、並列サンプラー、Reinforcement Learning for Calibrated Decisions（RLCD）と呼ぶ学習方法を採用したと説明しています。

通常のLLMは次のトークンを一つずつ予測するため、出力が長いほど時間と料金が増えます。Jevは出力候補を事前に型として定義し、それぞれの確率を並列に返します。この制約が自由な文章生成を不可能にする一方、パース失敗や想定外の形式を減らし、機械処理へ接続しやすくしています。

• 入力：文章や構造化されたプログラム状態
• 出力：事前定義された型に沿う値、各候補の確率、信頼度
• 処理：自由文を1トークンずつ生成せず、複数の判断を並列に返す
• 制約：候補にない文章や新しい説明を自由に作る用途には向かない

料金と速度：公式値をどう読むか

TypeSafe AIの公開価格は、入力100万トークンあたり0.042ドル、つまり10億入力トークンあたり42ドルです。出力は短い型付きの値であり、同社は出力料金を設定していません。応答時間は公式発表で70〜500ミリ秒とされています。

Jev 1.14でも単価は変わりません。画像はテキストと同じ入力単価で課金され、レスポンスのusage.input_tokensへ含まれます。同社はワークフロー評価で既存LLMより最大193.6倍高速、444.6倍低コストという結果を示していますが、評価ワークフローを自社チームが作成したことによる偏りの可能性も明記しています。最大値を一般的な削減率として扱わず、自社データで再評価する必要があります。

Jev 1.14.0の変更点：画像・box型・262Kコンテキスト

Jev 1.14.0は2026年10月14日に公開されました。モデルIDはjev-1.14.0で、公開直後はjev-previewが1.14.0、jev-latestは1.13.0を指します。公式は1週間後にjev-latestを1.14.0へ移す予定としているため、確信度の閾値を調整済みの本番環境ではエイリアス任せにせず、バージョン固定と再評価が必要です。1.14は全般的な小幅改善、とくに多言語対応の改善を掲げていますが、外部の共通条件テストはまだありません。

画像はassetsへ一度登録し、その参照文字列をstate、instructions、criteriaの任意の場所へ置く仕組みです。同じ画像を複数の質問で使う場合はstateへ置くと重複トークンを抑えられます。画像入力自体は1.13と1.14の両方で使えますが、対象位置をtop・bottom・left・rightの0〜1で返すbox型は1.14専用です。

長文コンテキストはTypeSafe-Danger-Zone-Long-Contextヘッダーで有効にすると、1リクエストと1質問の両方が262Kトークンになります。通常は64K／32Kです。料金は通常と同じ入力単価ですが、公式ドキュメントは速度と精度が悪化すると明記しており、長い契約書やログを無条件に丸ごと渡す設計は避けるべきです。

想定される6つのユースケース

Jevが向くのは、正解を長い文章として生成する仕事より、選択肢を定義できる大量の判断です。処理結果をそのまま採用するだけでなく、確信度が低いときだけ人間や高性能LLMへ回す設計と相性があります。

• 問い合わせを営業・請求・技術サポートへ振り分ける
• 文章やコマンドが安全ポリシーに抵触する可能性を判定する
• 取引やログをリスク別に分類し、要確認案件を抽出する
• AIエージェントの操作履歴を監視し、異常や脱線を検知する
• 複数のAIモデルから、処理に必要な品質・速度・料金に合う接続先を選ぶ
• 大量の文書から定義済み項目を抽出し、確信度の低い行だけ確認へ回す

海外で報告された開発者テスト

TechCrunchは、Vercelのエンジニアがコマンドの安全性を判定する分類器でJevを試し、従来使っていたOpenAIモデルより5〜18倍速い結果を得た事例を紹介しています。別の開発者が業務メール分類でGeminiと比較したテストでは、Geminiの方がわずかに高精度だった一方、料金は10〜20倍高かったと報じられています。

1.14公開直後のHacker News投稿は、確認時点で104点・36コメントに達しました。コメント欄では、メール分類での利用、生成LLMからフィルター・分類処理を置き換えて速度と料金が改善したという複数の実利用報告がある一方、公開ベンチマークで常に首位ではないこと、画像対応は競合やローカルモデルにも存在することも指摘されています。

これらは関心と利用の独立したシグナルですが、大規模な第三者ベンチマークではありません。データセット、候補定義、判定閾値、再試行、ネットワーク条件で結果は変わります。導入判断では、公開された倍率やコメントを転用せず、自社の誤判定コストを含めて検証する必要があります。

公開後に浮上した『本当に新しいのか』という論争

Jevの公開後、非自己回帰型の意思決定モデルに以前から取り組んでいたとする開発者が、オープンモデル『Laya』と比較記事を公開しました。この投稿は2026年9月20日確認時点でHacker Newsのトップに入り、1,000点超・230件超のコメントを集めています。急速な注目は確認できますが、投稿者の主張やコメント欄の意見は、それだけで技術的な正しさや先行性を証明するものではありません。

Layaの開発者は、2025年3月の論文と公開モデルがJevより先行したと主張しています。実際に論文、モデル、コードの公開履歴は確認できます。一方、2025年3月の論文は営業会話の成約確率を時系列で予測する特定用途の研究で、Jevが掲げる汎用的な型付き判断APIと同一ではありません。もう一つ引用される論文も、信頼度を使ったLLMルーティングとハルシネーション抑制が主題です。現時点の公開資料だけから、Jevが既存研究をコピーした、または完全に新規だと断定することはできません。

論争から得られる実務上の示唆は、名称や『新しいモデルクラス』という表現より、ゼロショットで別領域へ移せるか、追加学習が必要か、確率が較正されているか、運用コストを含めて再現できるかを比べるべきだという点です。

JevとLayaを比較するときの注意点

LayaはApache 2.0で公開された小型モデル群で、コード、重み、ベンチマーク手順を確認できます。開発者は単一T4 GPUで約32.8ミリ秒、バッチ時は1問あたり約7.2ミリ秒と報告しています。ただし、これはLaya側の測定です。Jev側のAPI計測とはハードウェア、ネットワーク、入力、学習条件がそろっておらず、速度倍率をそのまま優劣として扱えません。

特に重要なのは学習条件です。LayaのREADMEは、型付き意思決定ベンチマークで高い結果を出したチェックポイントが、そのベンチマークの訓練データで追加学習されていること、未調整のベースモデルはゼロショットで多数派ベースラインを下回ることを明記しています。Jevは追加学習なしで複数領域へ適用できることを価値として訴求していますが、技術論文や重みは公開されておらず、同条件での独立比較はまだできません。

Layaが掲げる『100万トークンあたり0ドル』はAPI利用料がないという意味です。セルフホストにはGPU、メモリ、監視、更新、障害対応の費用がかかります。従量課金APIのJevと比べる場合は、モデル単価ではなく、完了した判断1件あたりの総保有コストで見る必要があります。

SOLO：表データの並べ替えでprefix cacheを効かせる

SOLO（System One Layout Optimizer）は、同じ自然言語の判断を大量の表データへ適用するとき、行と列の並びを変えて共有prefixを増やすオープンソース実装です。モデルそのものを軽量化するのではなく、ポリシー、顧客属性、商品属性など繰り返す入力を先頭側へまとめ、vLLMなどのprefix cachingがprefill計算を再利用しやすくします。判定後は結果を元の行順へ戻すため、利用側のデータ順序は維持されます。

公式リポジトリのRTX 4090・JEV-9B BF16・vLLM 0.31.0による合成テストでは、長い共有文脈で元の並びより最大11.71倍、相関する列を持つ条件でNDV順より3.28倍の処理量を報告しています。別のContractNLI評価では、17バッチ・1,088判断の処理時間が293.64秒から115.73秒へ短縮されました。ただし、これらは開発チーム自身の測定であり、入力構造、キャッシュのブロックサイズ、同時実行数、GPU、prefill比率で効果は大きく変わります。

背景にあるICML 2026採択論文は、表の行・列順序をradix treeの形として最適化し、固定したprefix cache容量の下でprefill throughputを最大90.3%改善、計画処理を既存手法より最大242倍高速化したと報告しています。これは査読済み研究として仕組みを裏付けますが、JEV-9Bへ接続した11.71倍という数値を第三者が再現した証拠ではありません。2026年10月19日時点のGitHubは810 starsで、公開コード、raw計測、再現コマンドが揃っています。

SOLOが向くのは、同じ契約・ルール・質問を多数の行へ繰り返し適用し、入力の多くを共有できるバッチ判断です。各行がほぼ固有、リアルタイムに1件ずつ到着する、生成時間が支配的、利用基盤がprefix cacheを持たない場合は効果が薄くなります。入力トークン数そのものは減らないため、従量課金APIで請求額が下がるとは限りません。セルフホスト時のGPU時間や処理待ちを減らす技術として評価し、API課金とインフラ原価を分けて測る必要があります。

CUA-S1も登場：『System 1』は一社だけの呼び方ではない

同じ日にHacker News上位へ入ったCUA-S1は、コンピューター操作エージェントの小さな意思決定に特化した研究実装です。フォームの項目と文書内の値を照合するような限定判断を、文章生成なしで処理します。開発元は『System 1』を厳密なモデル分類ではなく、速く範囲を限定した判断を示す工学的なたとえだと説明しています。

CUA-S1は2026年9月20日時点でソースのみの初期研究リリースで、学習済み重みは同梱されていません。JevやLayaと直ちに置き換え比較できる段階ではありませんが、生成LLMにすべてを任せず、小型の判断モデルをエージェント内部へ組み込む方向が複数の開発者コミュニティで同時に進んでいる証拠にはなります。

『ハルシネーションゼロ』の意味と限界

TypeSafe AIはJevについて、定義された型以外を返さないため、型エラーや自由文の作り話が発生しないという意味で『Zero Hallucinations』を掲げています。ただし、これは判断が常に正しいという意味ではありません。許可された候補の中から誤った選択肢を高い確率で返す可能性は残ります。

実務では、型の正しさと意味の正しさを分けて評価します。確信度が一定未満なら人間へ回す、重大な操作は別ルールでも検証する、誤判定を定期的に再評価する、といった安全設計が必要です。信頼度を返す機能は判断材料になりますが、閾値をどこに置くかは利用者側の責任です。

一般的なLLMと併用する構成

現実的なのはJevかLLMかを一つだけ選ぶ構成ではなく、役割分担です。最初の分類、危険度判定、モデル選択、出力チェックをJevで行い、説明や生成が必要な処理だけLLMへ渡します。確信度が低い案件を高性能モデルや人間へ送れば、品質を落とさずに高価な推論回数を絞れる可能性があります。

ただし判断レイヤーを追加すると、障害点、ログ、評価対象も増えます。Jevが停止した場合のフォールバック、判断根拠を追跡するID、モデル更新前後の比較データを用意しておくことが、本番運用では欠かせません。

Jevという名前とジェボンズのパラドックス

Jevの名称は、19世紀の経済学者William Stanley Jevonsに由来します。ジェボンズのパラドックスは、資源を効率よく使えるようになると単位あたり消費は減っても、利用範囲が広がり、全体の消費量が増えることがあるという考え方です。

TypeSafe AIは、知能を使う単価が桁違いに下がれば、これまで費用や遅延のため実装できなかった小さな判断がソフトウェア全体へ広がると見ています。1回のAI処理が安くなることと、企業全体のAI支出が減ることは同義ではありません。利用回数が急増すれば、総額、監視対象、誤判定の影響範囲はむしろ拡大します。

導入検証で測るべき項目

最初から重要な判断を全面移行せず、正解ラベルを用意できる限定的な分類から始めます。平均精度だけではなく、見逃しと誤検知を分け、各ミスが業務へ与える損失を数値化します。

• クラス別の適合率・再現率と、重要クラスの見逃し率
• 信頼度と実際の正解率が一致しているかという較正
• p50・p95・p99レイテンシとタイムアウト率
• 入力100万件、または完了タスク1件あたりの総コスト
• 低確信度として人間・LLMへ移管される割合
• モデル更新後の精度差と、障害時のフォールバック成功率

現時点の評価

Jevは、生成AIを『人が読む文章を作る道具』から『ソフトウェア内部で大量の判断を行う部品』へ広げる提案です。1.14で画像と位置検出へ広がり、SOLOのような周辺実装が入力レイアウトとキャッシュ効率を最適化し始めたことで、モデル単体から推論システム全体へ競争軸が広がっています。

一方、2026年10月19日時点で画像、box型、262KコンテキストはいずれもDanger Zoneの実験機能です。SOLOの速度値も開発元測定で、共有prefixが少ない処理やprefix cache非対応のAPIには一般化できません。公式ベンチマーク、開発者コメント、査読論文、第三者テストを分け、モデルのバージョンだけでなく入力レイアウト、cache hit率、prefill時間、請求方式まで同じ条件で測るのが現実的です。

よくある質問

Q. JevはLLMを置き換えますか？　A. 全面置換ではありません。説明や生成はLLM、分類・ルーティング・監視など候補を事前定義できる判断はJevや小型決定モデル、という役割分担が想定されます。

Q. Layaの方が安くて速いと断定できますか？　A. できません。LayaはAPI料金なしでセルフホストできますが、GPUと運用費がかかります。公開された速度値も測定条件が異なるため、自社データと同一環境で比べる必要があります。

Q. SOLOを入れればJevのAPI料金も最大11.71分の1になりますか？　A. いいえ。SOLOは同じ入力トークンのprefill計算をキャッシュで再利用する技術で、入力トークン数は減りません。セルフホストの処理時間は下げられる可能性がありますが、外部APIの請求がキャッシュ計算を割り引かなければ料金は変わりません。

Q. Jev 1.14は画像の中にある物体を見つけられますか？　A. box型で対象1件の位置を返せます。ただし対象がなくても座標を返すため、存在を判定するNoul質問を同じリクエストに入れ、低いconfidenceでは再確認してください。

Q. 262Kトークンは標準で使えますか？　A. いいえ。専用ヘッダーで有効にする実験機能です。単価は同じですが、公式は通常コンテキストより遅く、精度も下がると説明しています。

Q. 『ゼロハルシネーション』なら誤判定しませんか？　A. 誤判定は起こり得ます。形式外の文章を生成しないことと、候補の中から正しい答えを選ぶことは別です。重要処理では閾値、人間確認、フォールバックが必要です。

Q. 今すぐ本番導入すべきですか？　A. まず正解データを用意できる限定用途で試し、精度、較正、p95レイテンシ、判断1件あたりの総コスト、低確信度の移管率を測るのが安全です。