Jevとは？LLMとの違いと並列構造化出力を図解
Jevは、TypeSafe AIが開発した並列構造化出力に特化したAIモデルです。複数の質問を一度に評価し、選択肢や数値、確率を返す。その結果をプログラムが受け取って、次の処理を決めるために使います。
ゲームで敵が現れたとき、移動する方向を決め、武器を使い、体力が減れば逃げる。そのたびにAIへ相談して、回答を数秒待っていたら、判断が返るころには状況が変わってしまいます。
ここで必要なのは、状況に合った小さな判断を、短い間隔で繰り返せることです。Jevは、この使い方を考えると面白さが見えてきます。TypeSafe AIはこうしたモデルを「System One Models」と呼んでおり、2026年9月15日の公式発表では、Doomを動かすデモも紹介されています。
気になるのは、こうした判断をアプリのどこに組み込めるかです。会話の途中で次の処理を選ぶ音声アシスタントにも使えそうだし、業務アプリの小さな確認作業にも使えるかもしれない。
Jevの並列構造化出力とは
ゲーム側から敵の位置や自分の体力、残弾などの情報を渡し、「どこへ移動するか」「攻撃すべきか」「退避すべきか」を聞くとします。Jevでは、一回のAPI呼び出しに複数の質問を入れ、同じ状態に対して並列に評価できます。質問と結果が対応して返るので、プログラムからそのまま扱えます。
選択肢から一つを選ぶChoice、基準に沿って評価するScore、ある内容が真である確率を返すNoul。質問にはこの三種類があり、ChoiceとScoreには確率分布と確信度も付きます。値の意味や形式が決まっているので、受け取った結果を次の処理に使えます。入出力の仕様
文章生成型LLMは、通常、出力の小さな単位であるトークンを順に生成します。Jevでは、一回の呼び出しの中で複数の質問を並列に評価します。開発者がリクエストを一件ずつ送って、結果を集める手間も省けます。開発元による出力方式の比較
状態の変化に合わせて判断を繰り返す
一度に複数の答えが返ることと、状況に合わせて動き続けられることは、別の話です。処理の結果や新しい入力によって、次に必要な対応も変わります。現在の状態を渡して判断し、その結果で処理を進め、更新された状態でまた判断する。この繰り返しが判断ループです。
TypeSafeが公開したDoomのデモでは、毎秒10回モデルに問い合わせています。入力は画面の画像ではなく、ゲーム状態のデータ。指示に沿った判断を短い間隔で繰り返し、操作につなげています。
仮に、一回3秒かかる判断を100回、順番に実行すると5分。一回0.1秒なら10秒で済みます。次の処理が判断待ちになるシステムでは、この差がそのまま全体の待ち時間になります。
ただし、質問を並列に増やせば、それだけでうまく動くわけでもありません。「自動で進めるべきか」と「人に確認すべきか」を別々に評価すると、両方が高い確率になる可能性があります。同時に選べない対応は一つの選択問題にまとめるか、コードで優先順位を決める。実行に必要な条件もコードで確かめておく。判断の結果をどう処理につなげるかは、アプリ側で設計する必要があります。
既存LLMや分類モデルとの違い
既存のLLMにも、決められた形式で答えを返す構造化出力があります。実際、TypeSafeが公開している比較用のアダプターでも、各社の構造化出力機能を使っています。JSONを返せることだけでは、Jevの新しさを説明できません。
Jevが特化しているのは、小さく分けた質問を評価し、ソフトウェアで使う値や確率を返す仕事です。TypeSafeは自動化を前提に、出力方式や学習方法を設計しています。自由な文章は書けませんが、必要なのが次の処理を選ぶための値なら、長い返答を生成する必要もありません。
この使い方は、従来の機械学習の分類・回帰モデルに近いと感じます。文章やデータを入力し、カテゴリや数値を処理に使う。ただ、「近い」のはソフトウェアから見た役割であって、内部の構造まで同じという意味ではありません。Jevでは、状態と一緒に自然言語の質問や評価基準を渡せます。どの程度幅広い判断に対応できるかは、試して確かめたい部分です。
速度とコストも気になります。公式サイトは特定のワークフロー評価に基づき、速度193.6倍、コスト約444.6分の1と公表しています。公開評価は四つのワークフローが中心で、参照する回答にも他の大規模モデルの出力を使っています。この倍率を、そのまま自分のアプリの見積もりには使えません。
音声対話への応用と600msの条件
音声対話では、返答するまでにいくつもの判断が必要です。「予約を明日に変えたい」と言われたとき、予約情報を検索するのか、まず本人確認をするのか、変更先の日付を聞き返すのか。会話の状態から、次に進める処理を選ぶ場面です。
ここにJevを組み込むなら、音声認識で得た内容を渡して、必要な処理を選ばせる構成が考えられます。アプリがその処理を実行し、別のモデルやテンプレートで返答を作って読み上げる。Jevには判断を、人に聞かせる返答は別の仕組みに任せるわけです。
仮に「話し終えてから声で返答を始めるまで600ms以内」を目標にするなら、Jev単体の速度だけでは足りません。発話終了の判定や音声認識、返答生成、音声合成、通信も含めた時間で見る必要があります。判断にかかる時間が短くなれば、ほかの処理に使える時間は増えますが、600msを達成できるかは全体を動かして初めてわかります。
まずは「検索が必要か」を選ぶ処理だけ差し替えて、会話全体の待ち時間がどう変わるかを比べてみたい。判断が速くなった分だけ返答も早まるのか、音声合成など別の処理を待つのか。このあたりは実際に動かしてみたくなります。
RLCDと、判断を任せるための確率
判断が速くても、間違った操作を繰り返してしまえば困ります。自動で進めてよい場合と、確認したほうがよい場合を分ける材料が必要です。Jevが返す確率は、そのために使うことを想定しています。
TypeSafeは、判断と校正された確率を返すための学習方法をRLCD（Reinforcement Learning for Calibrated Decisions）と呼んでいます。「校正」とは、たとえば80%の確率と予測した事例を多数集めると、実際にもおよそ80%でその結果が起こる関係です。多数の予測をまとめて確かめる性質であって、目の前の一件が必ず正しいという保証ではありません。
APIには少し紛らわしい点もあります。ChoiceとScoreのconfidenceは、確率分布から計算した確信度の指標で、「0.9だから正答率90%」とは読めません。Noulには別のconfidenceフィールドもありません。確信度の仕様を確認し、自分のデータで自動処理の基準を決める必要があります。
もう一つ気になるのが「ハルシネーションゼロ」という宣伝です。開発元の説明では、指定した出力形式に必ず一致することを根拠にしています。ただ、選択肢を「実行・保留」に限定しても、本来保留すべき処理を実行と判断する可能性は残ります。形式が崩れないことと、判断を間違えないことは別です。
RLHFが人の好む返答を学習させるのに対し、RLCDは判断と確率を学習の目標に置きます。音声アシスタントなら、利用者にわかりやすく話す能力も、次の処理を素早く選ぶ能力も必要です。用途に合わせてモデルを組み合わせる作り方が、今後は増えるかもしれません。
Jevの料金とAPIの使い始め方
2026年9月15日の発表時点の料金は、入力100万トークンあたり0.042ドルで、出力は無料です。仮に一回の入力が1,000トークンなら、10万回の呼び出しで入力料金は4.2ドル。ここには判断対象のデータだけでなく、質問や評価基準の長さも効いてきます。実際の費用は、自分の入力を使って見積もるのがよさそうです。
Jevは早期アクセスとして公開されており、利用案内はウェイトリストの登録者へ順次行われます。TypeSafe AIの公式サイトから登録し、アクセスが付与されたら、まずPlaygroundで入出力を確かめられます。
- 判断対象をstateに入れる。たとえば、問い合わせ文と、その時点でわかっている対応状況を渡します。
- questionsに質問を定義する。担当部署を選ぶならChoice、基準に沿った採点ならScore、緊急性の有無を確率で知りたいならNoulを使います。
- 返ってきたanswersを確認する。選択結果だけでなく、確率や確信度も見て、自動処理へ進める条件を決めます。
アプリから呼び出す場合は、コンソールでAPIキーを取得し、https://api.typesafe.ai/v1/systemoneにPOSTします。モデル名はjev-latest。公式のQuick startにリクエストとレスポンスの例があり、Python向けにはtypesafe-sdkも用意されています。
自分で試すなら、どんな処理から始めるか
判断ループを作るなら、まず次に実行する処理を選ぶ、小さな部分から始めると比較しやすくなります。今あるルールで動かした場合とJevに選ばせた場合を比べれば、判断の質、待ち時間、費用を確認できます。そのうえで、状態の表現や指示を変えたときに、どのくらい対応できるかを試す。
たとえば、問い合わせを担当部署へ振り分けるなら、過去の文面を使って正しく分類できるかを調べる。迷う案件を人に戻したとき、確認の手間がどれだけ残るかも測る。呼び出しが安くても、修正作業が増えれば業務は楽になりません。
Jevで試してみたいのは、情報が増えるたびに判断を更新できる仕組みです。問い合わせに補足が届いたら担当部署を見直す。確認待ちだった案件も、必要な情報がそろえば次の処理へ進める。何度も判断を挟める速さと費用なら、アプリの作り方にも選択肢が増えます。まずは、普段の作業で「新しい情報が来たので、もう一度確認する」ところを探してみたいと思います。