1. はじめに
想定読者
- Jevという名前を見かけたけれど、何をするものなのかよく分からない方
- 「それ普通の分類モデルでは？」と思った方
- LLMのStructured Outputsとの違いが気になった方
- AIモデルには詳しくないけれどアプリケーションへの組み込み方には興味がある方
2026年9月15日、TypeSafe AIから「Jev」というAIモデルが公開されましたね。
私は最近の技術に疎い傾向があるのですが、あまりにも見かけるので調べてみました。
内容をみてみると、以下の特徴が分かりました。
- 文章を生成しない
- 型付きの値を返す
- 分類やスコアリングができる
- 高速・低コストを謳っている
これを踏まえて最初に思ったのは、「あれ普通の分類モデルと何が違うんだろう？」 ということでした。
さらに、今はLLMでもStructured Outputs（※）を使えば、決められたJSON Schemaに沿った結果を返すことができます。
※ Structured Outputs
LLMの出力を、指定したJSON Schemaに準拠させる仕組みです。
単に有効なJSONを返すJSON modeとは異なり、指定したSchemaへの準拠まで保証する点が特徴です。
この記事ではモデルの内部構造や学習アルゴリズムの詳細には深く踏み込まず、
Webアプリケーションを作るエンジニア目線で、Jevの立ち位置を理解することを目的にしています。
- ✅ Jevはそもそも何をするモデルなのか
- ✅ 従来の分類モデルとは何が違うのか
- ✅ LLMのStructured Outputsとは何が違うのか
- ✅ 「System One Model」の何が新しいのか
- ✅ 実際のシステムではどこで使えそうなのか
2. 結論：Jevは「文章を作るAI」ではなく「判断を返すAI」
先んじて概要を整理すると、JevはChatGPTのように文章を書くためのモデルではありません。
TypeSafe AIはJevを、非構造化な入力を受け取り、型付きの確率的な判断を返すモデルとして説明しています。
例えば、ユーザーから次のような問い合わせが来たとします。
昨日からログインできません。
業務で使っているのでなるたけ早く確認してほしいです。
LLMであれば、以下のような文章を生成することができます。
ログイン障害に関する問い合わせです。
緊急度は比較的高いと考えられます。
一方、Jevが担当するのは以下のような部分です。
category = 障害
urgency = 4
さらに、出力形式に応じて判断の確率やconfidenceも返されます。
イメージとしては、以下の通りです。
問い合わせ
↓
Jev
↓
カテゴリ：障害
緊急度：4
解約意図：0.82
↓
アプリケーション側の処理
文章を考えて返すというより、後続のプログラムが利用するための判断材料を返すことに特化しています。
大まかに比較すると以下のようになります。
| 従来の分類モデル | LLM | Jev | |
|---|---|---|---|
| 主な仕事 | 特定の分類 | 文章生成・要約・推論など | 判断・分類・スコアリング |
| 出力 | クラスや確率 | 主に生成された文字列 | 型付きの値と確率 |
| 分類軸の変更 | 再学習が必要な場合が多い | 指示で変更できる | リクエスト時に変更できる |
| 自由な文章生成 | しない | できる | しない |
| 主な用途 | 特定タスクの分類 | 汎用的な処理 | ソフトウェア内部の判断 |
最初は新しいLLMなのかなと思っていたのですが、そうではなく、
LLMにやらせていた仕事のうち、「判断する部分」を切り出して専用化したモデル
として捉えると分かりやすそうだなと思いました。
3. Jevは具体的に何を返すのか
Jevでは、大きく3種類の質問が用意されています。
ChoiceScoreNoul
Choice：選択肢から1つ選ぶ
例：問い合わせカテゴリを判定したい場合
この問い合わせはどれに該当するか？
- 障害
- 質問
- 請求
これに対して、どの選択肢が適切かを判断します。
イメージとしては、以下のような結果です。
障害：0.91
質問：0.07
請求：0.02
単に「障害」と返すだけではなく、それぞれの選択肢に対する確率も扱えるのが特徴的であると思いました。
Score：段階的に評価する
例：緊急度を評価する場合
緊急度を次の5段階で評価する。
1: 低い
2: やや低い
3: 普通
4: 高い
5: 非常に高い
このような順序のある評価に使えるのがScoreです。
問い合わせの優先度やリスクレベル、顧客満足度などがイメージしやすそうだなという印象を持ちました。
Noul：Yes / Noを確率で返す
例：解約意向を判定したい場合
このユーザーは解約を検討しているか？
結果は、次のように「Yesである確率」として返されます。
0.82
true / falseだけではなく確率なので、アプリケーション側で、以下のように閾値を決めて処理することができます。
if (churnProbability >= 0.8) {
notifyCustomerSuccess();
}
4. 「それ普通の分類モデルでは？」を考える
ここが最初によく分からず、躓いた点でした。。
例えば、問い合わせを以下のように分類するなら、従来の分類モデルでもできます。
- 障害
- 質問
- 請求
問い合わせ
↓
分類モデル
↓
障害：0.91
質問：0.07
請求：0.02
結果だけ見るとかなり似ているのに、、何が違うのか続けてみていきます👀
従来の分類モデル
例えば「障害 / 質問 / 請求」を分類するモデルを作るなら、それぞれのラベルが付いたデータを用意し、そのタスク用のモデルとして学習させます。
モデルは、
問い合わせ分類モデル
として作られているので、突然、
この文章の感情を
- Positive
- Neutral
- Negative
に分類してください
と言っても、その仕事をするために作られていなければ対応できません。
別の仕事をさせるなら、別途モデルを用意したり追加学習したりする必要があります。
Jev
Jevでは、判断してほしい内容や選択肢をリクエスト時に指定できます。
ここは次のように分類して、
- 障害
- 質問
- 請求
別の処理では、
- Positive
- Neutral
- Negative
で分類する、といった使い方ができます。
つまり、特定の分類だけをする専用モデルではなく、何について判断するのかを実行時に渡せるところが違います。
5. zero-shotとは
Jevについて調べていると「zero-shot classifier」という言葉もよく見かけました。
zero-shotとは、かなり簡単に言うと、そのタスク専用の追加学習をしていない状態で、指示だけを渡して初見のタスクを解かせることです。
例えば、
この問い合わせを
- 障害
- 質問
- 請求
のどれかに分類してください。
という指示だけを渡して分類させます。
この分類専用の教師データを用意して、モデルを追加学習しているわけではありません。
関連する言葉として、以下があります。
| 呼び方 | イメージ |
|---|---|
| zero-shot | 説明だけでやらせる |
| one-shot | お手本を1つ見せる |
| few-shot | お手本を数個見せる |
| fine-tuning | モデル自体を追加学習する |
Jevが行っている「実行時に選択肢を渡して分類する」というタスク自体は、zero-shot classificationとして以前から存在するものです。
そのため、「分類できること自体がJevによって初めて実現された」というわけではありません。
では何が新しいのかは、もう少し後で整理します。
6. LLMのStructured Outputsとは何が違うのか
今のLLMにはStructured Outputsがあります。
例えばJSON Schemaを指定して、
{
"category": "障害",
"urgency": 4
}
のような形式で結果を返してもらえます。
それなら、「Jevを使わなくてもLLMにJSONを返してもらえばいいのでは？」 と思いました。
Structured Outputsの場合
Structured Outputsは、LLMの出力を定義したSchemaに従わせる仕組みです。
例えば以下のようなSchemaを定義します。
{
"type": "object",
"properties": {
"category": {
"type": "string",
"enum": ["障害", "質問", "請求"]
},
"urgency": {
"type": "integer"
}
}
}
するとLLMの柔軟な能力を使いながら、
{
"category": "障害",
"urgency": 4
}
という構造化された結果を受け取ることができます。
重要なのは、中にいるのはあくまでLLMというところです。
通常のLLMはトークンを順番に生成していくモデルなので、Structured Outputsを使っても「LLMが構造に従った出力を生成する」という基本的な役割は変わりません。
Jevの場合
Jevは、そもそも自由な文章を生成する機能を持たせず、最初から以下のような決められた型の判断を返すことに特化しています。
Choice
Score
Noul
もう少し雑に表現すると、
LLM + Structured Outputs
文章を生成できるLLM
↓
今回はこのSchemaに収めてください
↓
構造化された結果
に対して、
Jev
入力
↓
判断
↓
型付きの結果
という違いがあることを学びました。
Structured Outputsは「LLMの出力を構造化する」 のに対して、
Jevは「そもそも構造化された判断を返すためのモデル」 という設計思想の違いがあると思っています。
7. ではJevの何が新しいのか
ここまでの整理から以下のことが分かりました。
- 分類自体は以前からある
- zero-shot classificationも以前からある
- 構造化された値をAIから受け取ることもLLMでできる
ではJevの特徴はどこにあるのか、改めて整理してみます。
1. 自由な文章生成を捨てている
LLMは、
- チャット
- 要約
- コード生成
- 翻訳
- 分類
など、かなり幅広い仕事ができます。
Jevはその自由度を持たず、判断に特化しています。
できることを減らす代わりに、その用途に必要な速度や効率を重視しているようです。
2. 複数の判断をまとめて処理できる
例えば問い合わせについて、以下複数の判断をしたい場合があります。
・問い合わせカテゴリは何か
・緊急度はどの程度か
・解約を検討しているか
・人間による確認が必要か
Jevでは、同じ入力に対する複数の質問をまとめて渡すことができます。
TypeSafeは、LLMのように回答をトークン単位で逐次生成するのではなく、これらの出力を並列に処理することを特徴として挙げています。
3. 確率をアプリケーション側で利用することを前提としている
例えば、
人間による確認が必要：0.97
なら、
if (needsReview >= 0.9) {
sendToHuman();
}
のようにできます。
一方、
人間による確認が必要：0.52
なら、自動処理せず別の処理に回す、といった設計もできます。
TypeSafeは、この確率を実際の正答率に近付けることを目的とした学習方法として、RLCD（Reinforcement Learning for Calibrated Decisions）（※）を使用していると説明しています。
※ RLCD（Reinforcement Learning for Calibrated Decisions）
TypeSafeがJevの学習に使用していると説明している手法のこと。
判断時に返す確率と、実際にその判断が正しい割合ができるだけ一致する状態（calibration）を目指している。
例えばconfidenceが0.8の判断を多数集めたとき、実際にもおおよそ80%が正しい、という状態を指すなど。
なお、2026年9月時点ではRLCDの詳細な論文や学習レシピは公開されていない。
一方で、Jevは2026年9月時点で公開されたばかりのEarly Accessのモデルです。
TypeSafeは高速性やコスト、confidenceのcalibrationなどについて強い性能を公表していますが、現時点ではTypeSafe自身による評価が中心です。
そのため、このあたりは今後の第三者による検証も見ていきたいなと思っています。
8. Webアプリケーションではどこで使えそうか
Jevの用途として個人的にイメージしやすかったのが、コードだけでは書きづらい曖昧な条件判定です。
普通の条件分岐なら、以下のように実装すれば良いと思います。
これならわざわざAIに判断させる必要はないかなと。
if (status === "ERROR") {
notify();
}
一方で、以下のような条件・判断が必要な問いは、単純なif文では書きづらいと思います。
このユーザーはかなり怒っている？
この問い合わせは緊急対応が必要？
この内容は解約を検討していそう？
「怒っている」「緊急」「解約を検討していそう」といった判断は、単純な値の比較ではなく文章全体の意味や文脈に依存するため、条件式として網羅的に定義するのが難しいためです。
例えば、
if (
message.includes("怒っている") ||
message.includes("至急") ||
message.includes("解約")
) {
// ...
}
のようなキーワード判定だけでは、表現の揺れや文脈までは拾いきれません。
LLMを使うこともできますが、この用途では文章生成そのものは必要ありません。
ここにJevを挟むと、以下のような構成にできるのかなと。
ユーザー問い合わせ
↓
Jev
↓
┌──────────────────┐
│ category = 障害 │
│ urgency = 4 │
│ churn = 0.82 │
└──────────────────┘
↓
アプリケーション
↓
├─ urgency >= 4
│ → 緊急対応キュー
│
├─ churn >= 0.8
│ → CSへ通知
│
└─ その他
→ 通常キュー
「AIに次に何をするかまで全部任せる」のではなく、AIには曖昧な判断だけを担当してもらい、実際の制御フローはコード側に置くという設計です。
TypeSafeはこれを「smart if-statements」と表現しています。
9. じゃあ何を使えばいいのか
ここまでを踏まえて、私の中では以下のように整理しました。
| やりたいこと | 選択肢 |
|---|---|
| 明確な条件で分岐したい | 普通のコード |
| 固定された分類を大量に処理したい | 専用の分類モデル |
| 分類軸を柔軟に変えながら曖昧な判断をしたい | Jevのようなモデル |
| 要約・回答・コードなどを生成したい | LLM |
| LLMの柔軟さを使いつつJSONなどで受け取りたい | LLM + Structured Outputs |
もちろん実際には性能やコスト、レイテンシ、学習データの有無などによって選択は変わると思います。
Jevが「分類モデルとLLMの間にある」というより、LLMが今まで担当していた仕事から、判断だけを別のモデルとして切り出す選択肢が増えたと考えたほうが近いのかなと思いました。
10. 「System One Model」という名前について
Jevは、TypeSafe AIが「System One Model」と呼んでいるモデル群の最初のモデルです。
名前は、Daniel Kahneman氏の著書『Thinking, Fast and Slow（ファスト＆スロー）』に登場する、
- System 1：速く、直感的な思考
- System 2：遅く、熟考する思考
という区分に由来しているそうです。
Jevは長い文章を考えて生成するのではなく、高速に判断を返すことから「System One」と名付けられています。
ただし、System One Modelという呼び方自体もTypeSafe AIが今回打ち出しているものらしいです。
現時点でAI業界全体で一般的に使われているモデル分類というわけではないので、その点は分けて考えたほうがよさそうかなと思いました。
11. まとめ
最初にJevの紹介を読んだときは、「普通の分類モデルと何が違うんだ？」 と思っていました。
調べてみると、確かに分類というタスクそのものは以前から存在しており、zero-shot classificationも新しいものではありません。
また、LLMでもStructured Outputsを使えば、構造化された結果をアプリケーションから受け取ることができます。
そのうえで、Jevについて覚えておくとよさそうなポイントは以下の3つだと思っています。
- Jevは文章生成ではなく、分類・スコア・確率などの「判断」を返すモデル
- 従来の専用分類モデルと違い、実行時に質問や選択肢を変えることができる
- LLMのStructured Outputsとは異なり、最初から型付きの判断を返す用途に特化して設計されている
新しい分類方法が生まれたというより、
AIによる曖昧な判断を、普通のソフトウェアの中に組み込みやすくする方向へ振り切ったモデルと考えると、かなり理解しやすくなりました。
特に、以下の役割分担は面白いなと思いました。
明確な条件 → コードで判断する
曖昧な条件 → AIに判断させる
実際に何をするか → 再びコードで制御する
Jevはまだ公開されたばかりなので、今後実際のユースケースや第三者による評価が増えてきたら、そのあたりも引き続き追っていこうと思います！
この記事が少しでも参考になりましたら、いいね／ストックをしてもらえるととっても励みになります！