Jevとは何か：文章を書かず「判断だけ」を返すAIモデルを理解する

個人開発のアプリで「問い合わせ内容をLLMに読ませて、担当カテゴリに振り分ける」処理を書いたことがあります。動くには動くのですが、1件ごとに数秒待たされ、たまに {"category": "請求"} のように指定していない値が返ってきてパースで落ちる。「分類したいだけなのに、文章を書けるモデルを使うのは大げさでは？」とずっと思っていました。

そんな中で最近よく名前を見かけるのが Jev です。「文章を1文字も書かず、判断だけを返すAI」という触れ込みだったので、公式ドキュメントを読みながら整理してみました。

本記事の情報は2026年9月25日時点のものです。Jevはアーリーアクセス段階なので、数値やAPIは今後変わる可能性があります。引用はすべて公式サイト・公式ドキュメントからで、末尾の「参考」にリンクをまとめています。

そもそもJevとは何か

Jevは、TypeSafe AIが2026年9月15日にアーリーアクセスで公開したモデルです（公式ブログ）。公式ドキュメントでは次のように紹介されています。

Jev is TypeSafe’s flagship model and the first System One model. Send state and typed questions; get structured answers your code can use directly.

（訳）JevはTypeSafeの主力モデルで、最初のSystem Oneモデルです。状態と型付きの質問を送ると、コードからそのまま使える構造化された答えが返ってきます。

— Introduction | TypeSafe Docs

公式ブログの一文が、Jevをいちばん端的に表していると思います。

Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.

（訳）Jevは「最先端の知能を持った関数呼び出し」だと考えてください。構造化されていない状態を入れると、型の付いた確率的な判断が出てきます。

— Introducing System One Models & Jev

つまり、ChatGPTやClaudeのように「文章で答えるAI」ではなく、「関数のように呼び出すと、決められた型の答えと確率が返ってくるAI」 です。

LLMに「判断」をさせるときの3つの不満

Jevの立ち位置を理解するために、冒頭の「LLMで問い合わせを分類する」処理で困っていたことを整理しておきます。

やりたいのは「3つのカテゴリから1つ選ぶ」だけなのに、文章生成の仕組みを経由しているせいで、遅さ・コスト・不安定さを背負っているわけです。

System Oneモデルという考え方

TypeSafeは、Jevのようなモデルを System Oneモデル と呼んでいます。

System One models make fast, structured decisions for software.

（訳）System Oneモデルは、ソフトウェアのために速く構造化された判断を行います。

— System One | TypeSafe Docs

名前の由来は、人間の思考を「速くて直感的なシステム1」と「遅くて熟考するシステム2」に分ける考え方でしょう。じっくり考えて文章を書くLLMに対して、Jevは「パッと見て判断する」側を担当します。

ポイントは、できることを意図的に絞っていることです。公式ドキュメントでは、System Oneモデルは返信文やコード、説明文を生成しないと書かれています。入力もテキスト（文字列・JSONオブジェクト・テキストの配列）だけで、画像・音声・動画は “not supported (yet)”（まだ非対応）とされています（System One | TypeSafe Docs）。

公式ブログではこのトレードオフを次のように説明しています。

While Jev gives up string generation, it’s optimized for structured outputs and can’t hallucinate.

（訳）Jevは文字列の生成をあきらめる代わりに、構造化された出力に最適化されており、ハルシネーションを起こしえません。

— Introducing System One Models & Jev

「ハルシネーションを起こさない」は、「選択肢にない答えを作り出せない」という意味だと読むのがよさそうです。選んだ答えが間違っている可能性は当然あるので、そこは後述の確率とconfidenceで扱います。

3つの質問タイプ：Choice / Score / Noul

Jevへの質問は、次の3つの型のどれかで書きます（Primitives | TypeSafe Docs）。

使い分けの基準は「答えの形」です。

• Choice：選択肢の間に順序がない（billing / technical / sales など）
• Score：答えが段階の上にあって、各段階の意味を説明できる（落ち着いている → 怒っている など）
• Noul：Yes/Noで聞けて、その確率自体が知りたい

Choiceの選択肢は最大255個まで指定できます（“Jev supports a cardinality up to 255.” — 公式ブログ）。

もう1つ大事なのが、同じ入力に対する質問は1回のリクエストにまとめて送れることです。公式ドキュメントによると、質問は並列に評価されるので、質問を増やしても応答時間やトークンはほとんど増えない（“close to free”）とされています（Primitives | TypeSafe Docs）。

TypeScriptで問い合わせ振り分けを書いてみる

冒頭の「問い合わせの振り分け」をJevで書き直してみます。題材は架空のサブスクアプリの問い合わせフォームです。

SDKは npm で入れます。Node.js 20以上が必要で、APIキーは環境変数 TYPESAFE_API_KEY から読まれます（JavaScript SDK / Quickstart）。

npm install @typesafe-ai/sdk
export TYPESAFE_API_KEY=...  # コンソールで発行したキー

1通の問い合わせに対して「どのチームが担当か」「どれくらい怒っているか」「急ぎか」を1回のリクエストで聞きます。

// 公式のQuickstart・JavaScript SDKの例をもとに改変
import { choice, noul, score, TypeSafeClient } from '@typesafe-ai/sdk';

const client = new TypeSafeClient();

const response = await client.systemOne({
  state: {
    message: '3日前から決済の連携ができません。今日中に直らないと解約します。',
  },
  questions: {
    // Choice：順序のない選択肢から1つ
    department: choice('どのチームが対応すべきか', {
      billing: '支払い・請求に関する問い合わせ',
      technical: 'バグや連携の不具合',
      sales: '料金プランや契約の相談',
    }),
    // Score：順序のある段階（0から始まる）
    frustration: score('顧客がどれくらい苛立っているか', [
      '落ち着いて事実を伝えている',
      '苛立っているが丁寧',
      '強い言葉で怒っている',
    ]),
    // Noul：Yesである確率
    isUrgent: noul('急ぎの対応を求めている'),
  },
});

const { department, frustration, isUrgent } = response.answers;

console.log(department.choice);      // 例: "technical"
console.log(department.confidence);  // 例: 0.78
console.log(frustration.score);
console.log(isUrgent.noul);          // 0〜1の数値

ここで嬉しいのは、返り値の型が質問の書き方から推論されることです（“Answer types are inferred from your questions” — JavaScript SDK）。department.choice は billing / technical / sales のどれかという前提でコードを書けるので、LLMのときに書いていた JSON.parse の try/catch や「想定外のカテゴリ名だったら…」という分岐がいりません。

APIのレスポンスは次のような形です（Quickstartの例をそのまま引用。数値は例の値です）。

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": {...}
    },
    "frustration": {
      "type": "score",
      "score": 1.0,
      "confidence": 1.0,
      "legend": {...},
      "probabilities": {...}
    },
    "is_urgent": {
      "type": "noul",
      "noul": 1.0
    }
  },
  "usage": {
    "input_tokens": 392,
    "output_tokens": 65
  }
}

— Quickstart | TypeSafe Docs

choice の横に probabilities（各選択肢の確率）と confidence が付いてくるのがJevの特徴です。次の2つの節で、この数字がどういう意味を持つのかを見ていきます。

返ってくる確率は信用できるのか：RLCDとキャリブレーション

LLMにも「確率っぽい数字」を答えさせることはできますが、それは文章として生成した数字であって、本当にその確率で当たる保証はありません。Jevは、ここを学習方法から変えています。

TypeSafeはこの学習方法を RLCD（Reinforcement Learning for Calibrated Decisions） と呼んでいます。

Reinforcement learning for calibrated decisions trains TypeSafe to return decisions and calibrated probabilities instead of generated text.

（訳）RLCDは、生成されたテキストの代わりに、判断とキャリブレーションされた確率を返すようにモデルを訓練します。

— Machine Learning Primer | TypeSafe Docs

「キャリブレーションされている」とは、次の状態のことです。

Outcomes assigned a probability of 0.2 should occur about 20% of the time. Outcomes assigned a probability of 0.8 should occur about 80% of the time.

（訳）確率0.2とされた結果は約20%の割合で起き、確率0.8とされた結果は約80%の割合で起きるべきです。

— Machine Learning Primer | TypeSafe Docs

ChatGPTなどの学習で使われるRLHF（人間のフィードバックによる強化学習）は「人が読んで良いと感じる回答」に寄せていく方法です。同じページでは、RLHFは自信ありげなハルシネーション（“confident-sounding hallucinations”）を評価してしまうことがあり、人が見ていない本番システムには向かない、と説明されています。

だからこそ、Jevの確率は if (isUrgent.noul > 0.8) のようなしきい値の判定にそのまま使える数字として設計されているわけです。

confidenceで「任せる／人に回す」を分ける

Choice と Score には、probabilities とは別に confidence が付いてきます。2つの違いは次のとおりです（Confidence | TypeSafe Docs）。

• probabilities：各選択肢に確率をどう配分したか（billing 0.1 / technical 0.8 / sales 0.1 など）
• confidence：その配分が1つにどれだけ集中しているかを0〜1で表した値。1つの選択肢に全部集まれば1.0、均等に散らばるほど低くなる

公式ドキュメントでは、confidenceを「答えを信じて自動で動いてよいか」の判断に使うことを勧めています。

Use confidence as a second axis. The answer tells you what; confidence tells you whether to act.

（訳）confidenceを2本目の軸として使いましょう。答えは「何か」を教え、confidenceは「動いてよいか」を教えます。

— Confidence Routing | TypeSafe Docs

さらに、しきい値は1つに決めるものではないとも書かれています。

A confidence threshold is not one number.

（訳）confidenceのしきい値は1つの数字ではありません。

— Confidence | TypeSafe Docs

間違えたときの影響が大きい操作ほど、高いconfidenceを求めるということです。公式の銀行アプリの例（残高表示は0.6以上で自動、送金は0.85を超えたら自動、それ未満はユーザーに確認）を、問い合わせの例に当てはめるとこうなります。

// 公式のConfidence Routingの例（Python）をもとに、問い合わせ振り分け向けに改変
if (department.confidence < 0.6) {
  // 自信がない → 人が振り分ける
  assignToHuman(ticket);
} else if (isUrgent.noul > 0.9) {
  // 急ぎの可能性が高い → 担当チームに即通知
  notifyNow(department.choice, ticket);
} else {
  addToQueue(department.choice, ticket);
}

LLMの答えを「正しいか間違っているか」の二択で扱うのではなく、「どれくらい自信があるか」でコード側が処理を分ける、というのがJevを使うときの基本的な考え方です。

LLMと比べて何がうれしいのか

公式ブログでは、フロンティアLLMとの比較として次の数字が挙げられています。

— Introducing System One Models & Jev / Models | TypeSafe Docs

公式ブログでは「40〜200倍速い」とされていて、70〜500msなら画面操作に合わせてリアルタイムで呼んでも待たされている感じはほとんどありません。

ただし、この比較にはいくつか前提があります。公式ブログ自身が次のように書いています。

• 比較は「System Oneタスク（分類・振り分け・採点のような判断）」で同程度の知能を出せる、という条件付き
• “These are on the higher end of real world gains”（実際の効果としては高めの数字）
• 比較に使ったワークフローは自社のモデル能力チームのメンバーが作ったもので、“some bias could exist”（多少の偏りがありうる）

— Introducing System One Models & Jev

「文章を書くLLMより何でも優れている」わけではなく、判断だけに絞ったときに速くて安い、と理解しておくのが正確だと思います。

どこで使うと効くか

公式ドキュメントのパターン集やクックブックには、具体的な使い方がたくさん載っています。個人的に使えそうだと思ったものを挙げます。

共通しているのは、LLMを置き換えるのではなく、LLMの手前や後ろに置く使い方だという点です。Intent Routingのページでは、分類をJevで先に済ませることで、高いLLMは本当に必要なリクエストにだけ使う、という構成が紹介されています。

注意点

苦手なことが公式にまとめられている

TypeSafeは、現行モデル jev-1.13 の弱点を公式ドキュメントで公開しています（Model Jaggedness: jev-1.13）。主なものは次のとおりです。

• 書いたとおりに読む：否定や条件は文字どおりに解釈され、「意図した質問」ではなく「書いた質問」に答える
• 数を数えるのが苦手：文字数、単語の出現回数、長いリストの件数など
• 数値・日付の比較が苦手：日付は順序のある量ではなく文字として読むので、前後関係や期間の判断には向かない
• 二重否定や回りくどい指示：答えの信頼性が下がる
• 判断に関係ない入力が多い：state に無関係な内容が増えるほど精度が下がる
• 敵対的な入力：モデルを誘導しようとする文章で答えが動くことがある
• 文章生成：Choiceを連鎖させれば無理やり文章を作れるが、うまくいかない

数値の比較や件数のカウントは、Jevに聞かずにコードで計算してから渡すのが正解です。

制限とバージョン固定

Models のページには、次の制限が書かれています。

• 1リクエストあたり最大64kトークン、state と一番長い質問の合計は32kトークンまで
• レート制限は 250,000トークン/秒・1,200リクエスト/分（需要に応じて変わることがある）

また、モデル指定を省略すると jev-latest が使われます。確率のしきい値でロジックを組むなら、モデルが更新されたときに判定結果が変わらないよう、本番では model: 'jev-1.13.0' のようにバージョンを固定し、レスポンスの model をログに残しておくのが安全です。

まとめ

• Jevは、TypeSafe AIが2026年9月に公開した System Oneモデル。文章を生成せず、型の付いた判断と確率だけを返す
• 質問は Choice（選択肢から1つ）・Score（段階で評価）・Noul（Yesの確率） の3種類。同じ入力への質問は1回にまとめて送れる
• RLCD という学習方法で、確率が実際の正解率と一致するように訓練されている。だから confidence や noul をしきい値にそのまま使える
• LLMより大幅に速くて安いが、それは「判断だけ」に絞った場合の話。数を数える・日付を比べるなどは苦手
• LLMを置き換えるものではなく、振り分け・ガードレール・選別のように LLMの前後に置く部品 として使うのが向いている

「文章を作るAI」と「判断するAI」を分けて考える、というのがJevを理解するいちばんのポイントだと思います。冒頭の問い合わせ振り分けも、分類はJev、返信文の下書きはLLM、と役割を分けると、速さとコストの両方が改善できそうです。

参考

• Introducing System One Models & Jev - TypeSafe AI Blog
• Introduction | TypeSafe Docs
• Quickstart | TypeSafe Docs
• System One | TypeSafe Docs
• Primitives | TypeSafe Docs
• Machine Learning Primer | TypeSafe Docs
• Confidence | TypeSafe Docs
• Confidence Routing | TypeSafe Docs
• Intent Routing | TypeSafe Docs
• LLM Guardrails | TypeSafe Docs
• Classifying RAG Passages | TypeSafe Docs
• Parallel Questions | TypeSafe Docs
• Model Jaggedness: jev-1.13 | TypeSafe Docs
• Models | TypeSafe Docs
• JavaScript SDK | TypeSafe Docs