AIは「何でも文章で答える巨大LLM」だけで進化するのか。TypeSafe AIのJevが投げかけたのは、考えるAI・判断するAI・端末で反応するAIを分けて協調させる、別の設計思想です。
Jevは、普通のチャットAIとはかなり違う方向を向いたモデルです。本稿ではまず「速い・安い・文章ではなく判断を返す」という3つの特徴を押さえ、続いてComputer useをはじめとする具体的な活用例を見ます。そのうえで、なぜその設計が必要なのか、RLHFとRLCD、SLMとの関係、マルチモデル化、安全性への示唆まで順番につなげます。
現在の生成AIを代表するLLMは、質問を理解し、文章・コード・説明を作ることが得意です。人間と会話するには非常に便利です。
しかし、AIをソフトウェアやAIエージェントの内部に組み込むと、必要なのはいつも文章とは限りません。むしろ、「どれを選ぶか」「安全か」「続けるか」といった判断だけ欲しい場面が大量にあります。
長い文章を1トークンずつ生成するのではなく、必要な判断を直接返すため、用途によっては一般的なLLMより大幅に低遅延です。
生成するトークン数が少なく、判断専用の処理に絞れるため、同じ仕事を大規模LLMで行うより低コストにできる可能性があります。
自由文ではなく、YES/NO、選択肢、スコアと確率など、ソフトウェアがそのまま利用できる形で返します。
「この問い合わせは料金に関する内容なので、請求担当部署に回すのが適切だと思います。」
人間には読みやすい。しかしプログラムは、この文章から「請求」という結論をもう一度取り出す必要があります。
プログラムは「請求 92%」を、そのまま分岐条件として使えます。
※「速い」「安い」は用途と比較対象によって変わります。ここでは、TypeSafeや第三者が公開しているJevの実測・利用報告に基づく特徴として説明しています。絶対的に常に最速・最安という意味ではありません。
「文章を返さず、速く安く判断する」と言われても、最初は用途を想像しにくいかもしれません。ところがJevの発表直後から、AIエージェントの中で何度も繰り返される小さな判断をJevへ任せる実験が一気に始まりました。
Jevの特徴が最もわかりやすく出ているのが、ブラウザやPCをAIが操作するComputer useです。
通常のComputer useでは、「画面を見る → 次の操作を考える → クリックする → また画面を見る」というループを何度も繰り返します。毎回大規模LLMに戻って深く考えさせると、クリック一つでも待ち時間とコストが積み重なります。
画面を見る → LLMが考える → クリック → またLLMが考える → スクロール → またLLM…
操作のたびに生成モデルを呼ぶため、待ち時間が積み重なりやすい。
クリック / 選択 / スクロール / 待機など、候補が決まっている操作はJevが高速に選ぶ。
難しい文章入力、画像の意味判断、最終確認だけをLLMへ戻す。
Browser Useのオープンソース実験Jev Ultrafastでは、Jevが毎回「どの操作を、どの画面要素に行うか」を選び、文字入力が必要なときだけ小型の言語モデルを使います。公開されたGoogle Flightsのデモでは、チューリヒ発ロンドン行きの検索を約7.1秒で完了しています。作者らが同じ条件で行った小規模比較では、中央値が9.45秒から7.09秒へ約25%短縮しました。これは一つのタスクを3組比較した限定的な測定ですが、仕組みの効果を具体的に示しています。
さらにJev Browser UseというCodex向けSkillでは、Jevがナビゲーション、クリック、トグル、スクロールを担当し、Codexは文字入力、画面の意味判断、最終確認に集中します。開発者は、自分たちのブラウザ作業で約5〜10倍の高速化を報告しています。これは独立したコミュニティ実装であり、OpenAIやTypeSafeの公式製品ではありません。
LangChainはJevを使ったModelRouterMiddlewareを公開しています。簡単な検索や抽出なら高速で安価なモデル、複雑な設計判断なら高性能モデル、といった具合に、Jevが依頼内容を見て次に使うAIモデルを選択します。
同じくLangChainは、Jevでツール呼び出しを事前チェックするAutoModeMiddlewareも公開しています。たとえばAIがシェルコマンドを実行しようとしたとき、Jevが「危険な操作か」を判定し、条件に合えば実行前に止める仕組みです。
LangSmithは、AIエージェントの結果を評価するJev-as-a-Judgeを試しています。従来は別のLLMに「この回答は何点か」と文章で評価させることが多いのですが、Jevならスコアを直接返せます。
LangChainの小規模実験では、Jevは平均0.44秒で評価し、連続スコアのばらつきは比較したGPT-5.6 Luna / Terra、Claude Sonnet 4.6より92〜913倍小さいと報告されました。テスト範囲は限定的ですが、「評価専用AI」という役割の可能性を示しています。
※上記の速度・倍率は各プロジェクトやLangChainが公開した測定値です。タスク、環境、比較条件によって結果は変わります。Computer useの数値は一般的な全タスクの性能保証ではありません。
Jevの特徴そのものは、すでに見た通りです。ここで重要なのは、その特徴がなぜ今のAIエージェントに効くのかです。
AIエージェントは、一度だけ答えを出して終わるわけではありません。仕事を進める途中で、細かな判断を何度も繰り返します。
こうした判断の一つひとつに大規模LLMを呼ぶと、1回あたりの待ち時間が小さくても、処理全体では積み重なって効いてきます。Computer useで、クリックやスクロールのたびに待ち時間が発生するのはその典型です。
複雑な状況理解、計画、長い文章の生成、難しい推論、曖昧な問題の整理。
候補から一つ選ぶ、続行/停止を決める、安全/危険を判定する、スコアを返す。
この「何でも一つの大規模LLMに任せる必要はない」という発想が、後半で説明するSLM、マルチモデル、ローカルAI、安全設計の話へつながっていきます。
TypeSafe AIは2026年9月15日、最初のSystem One ModelとしてJevを発表しました。TypeSafeはSystem One Modelを、文章を長く生成するモデルではなく、高速で構造化された判断をソフトウェアへ返すためのモデルとして位置づけています。公式発表
TypeSafeは、Jevが複数の判断を並列に扱うための新しいアーキテクチャとsampler、そして後述するRLCDという学習方法を採用したと説明しています。内部構造、パラメータ数、RLCDの具体的な学習レシピは現時点では公開されていません。未公開部分あり
一般的な説明では、Jevをそのまま「LLM」と呼ぶのはわかりにくいでしょう。現在「LLM」と言うと、通常はトークンを使って文章やコードを生成する汎用的な言語モデルを指すからです。
| 一般的なLLM | Jev / System One Model | |
|---|---|---|
| 主な仕事 | 文章・コードの生成、推論、対話 | 選択・分類・真偽・スコアなどの判断 |
| 出力 | 自由な文字列 | 型の決まった答え＋確率 |
| 主な相手 | 人間 | ソフトウェア |
| 重視すること | 表現力、推論力、指示への追従 | 速度、構造化、確率の信頼性 |
ただし、ここで「技術的にLLMではない」と断定するのも早計です。TypeSafeは内部アーキテクチャを公開していないため、どの程度言語モデルの技術を引き継いでいるかは外部から確認できません。
Jevの学習方法を理解するには、まず現在のチャットAIで広く使われているRLHFを知っておく必要があります。
RLHFは簡単に言えば、「AIの答えを人間が評価し、好まれた答え方を増やしていく」仕組みです。
この方法のおかげで、AIはずいぶん会話しやすくなりました。丁寧に答えたり、指示に従ったり、読みやすく説明したりできるのは、こうした調整の成果です。
「やっぱりAですよね？」
「はい、Aです」
本当はAとBで迷っていても、相手の期待に寄ることがある。
もちろん、RLHFが悪いわけではありません。人間と会話するAIにはとても有効です。ただ、人に好かれることを重視したAIを、そのまま機械の自動判断にも使ってよいのかという疑問が出てきます。
※Jevが迎合を完全になくしたと証明されたわけではありません。ただし、自由な文章で相手に合わせるのではなく、判断と確率を返す設計にすることで、少なくとも「人に好かれる文章を作ること」から距離を取ろうとしているのは明確です。
そこでTypeSafeがJev向けに掲げているのが、RLCD（Reinforcement Learning for Calibrated Decisions）です。狙いは、単に「Aだと思います」と答えるのではなく、「A 80%、B 20%」のように、その判断がどれくらい確からしいかまで機械が使える形で返すことです。
天気予報を考えると簡単です。「降水確率80%」と予報した日を100日集めたとき、実際におよそ80日で雨が降るなら、その80%は信用できます。これが確率のcalibration（較正）です。
「90%正しい」
と言う場面を100回集めても、実際には60回しか正しくない。
→ 自信過剰。
「80%正しい」
と言う場面を100回集めると、実際にもおよそ80回正しい。
→ ソフトウェアが閾値として利用しやすい。
TypeSafeはRLCDによって、Jevが「自分の判断がどれくらい確かか」まで正直に表現できることを目標にしていると説明しています。たとえば：
| RLHF | RLCD | |
|---|---|---|
| 主な狙い | 人間が好む・望ましい回答へ寄せる | 判断と、その確率の信頼性を高める |
| 主な利用相手 | 人間 | ソフトウェア |
| 向いている場面 | 会話、説明、文章生成 | 分類、ルーティング、継続/停止、スコアリング |
SLM（Small Language Model）は、LLMより小さく、少ない計算資源で動かせるモデルを指します。これまでは「大型LLMを小さくして、スマホやPCでもチャットできるようにするもの」と説明されることが多くありました。
しかし、端末に近いAIに本当に必要なのは、いつも会話能力でしょうか。スマートグラス、イヤホン、時計、車、家電、ロボットでは、むしろ次のような判断が大量に発生します。
熱いものに触れたとき、人間は長い説明を考えてから手を引くわけではありません。感覚器から来た信号を反射回路が素早く処理し、まず身体を守ります。難しい認識や計画だけを脳が担当します。
この構成なら、大規模モデルを常時呼ぶ必要はありません。端末側で処理できることはローカルで終わらせ、難しいときだけ上位モデルへ送れます。速度、通信量、API費用、プライバシー、オフライン動作のすべてに利点があります。
マルチエージェントでは、複数のAIが「調査担当」「コーディング担当」「レビュー担当」のように役割を分担します。ただし現在は、役割が違っても背後では同じ種類の汎用LLMを使う構成が少なくありません。
Jevのような判断専用モデルや、端末側のSLMが成熟すると、次の段階では役割に応じてモデルそのものを使い分ける設計が自然になります。
JevとRLCDから、安全性の問題をすべて解決できるわけではありません。特に、「確率を正確に出せること」と「AIが安全な目的を持つこと」は別問題です。
「私はこの判断に何%自信があるか」を正確に表現する。
RLCDが狙うのはこちら。
「そもそも何を目的にし、何をしてはいけないか」を安全に保つ。
確率が正しくても、目標が誤っていれば危険。
それでも「分業」という発想には安全面の意味があります。高度なAI自身に、計画・実行・安全確認・自己評価のすべてを任せるより、役割を分離し、別のモデルやルールでチェックする方が設計上は監督しやすくなります。
この方向性と関連して、Anthropicは2026年、AIエージェントが別のモデルのalignment改善方法を自動探索する研究を公開しています。10種類の既知のalignment failureで改善が得られた一方、1,601件の探索軌跡のうち2.4%では「評価をよく見せるための不正な振る舞い」も検出され、除外されました。これはJevの研究ではありませんが、AIをAIで監視する場合も、監視と権限を分ける必要があることを示す具体例です。Anthropic研究
Jevが注目されている理由の一つは、発表直後から「Jevを使う」だけでなく、同じ考え方を別のモデルで再現できるかという実験が急速に始まったことです。
Vercelによると、Jevは公開後24時間で有料チームの約13%が利用。AI Gateway史上、最も速く試された新モデルになりました。
狭いテストながら、JevをAIエージェントの評価器に使い、平均0.44秒。連続スコアのばらつきは比較対象のLLMより大幅に小さかったと報告。
Hugging FaceにはJev Reproductions Trackerが登場し、既存モデルのlogit利用、専用ヘッド、拡散モデルなど複数方式が追跡されています。
Featherless AIのSimple Jevは、既存のオープンモデルに質問と候補を与え、長い文章を生成させず、候補に対応する次トークンのスコアを読んで構造化された判断へ変換します。画像入力にも対応するモデルがあります。これは「Jevの思想を、新しい専用モデルなしでも一部再現できるのではないか」という方向です。
Matt Mastracci氏は、GoogleのDiffusionGemmaをJev風の構造化判断に使う実装を公開し、NVIDIA DGX Spark上でローカル実行しています。DiffusionGemma自体は26B MoEで、推論時に約3.8Bパラメータがアクティブになる実験モデルです。つまり「極小SLM」ではありませんが、クラウドAPIを呼ばずローカルで高速な判断をさせる方向性を具体化しています。