JevとLLMはどう違うのか？System Oneモデルがなぜ必要とされるか
TL;DR
- LLMは「テキストを生成するモデル」、Jevは「型付き判断を返すモデル」
- 分類・スコアリング・ルーティング等のタスクはLLMより200倍速く400倍安い
- 幻覚が構造的に不可能な設計（スキーマ外の出力はできない）
- 「全部LLMで解決する」から「System 1/2を使い分ける」設計へ
はじめに
2026年9月15日、TypeSafe AIが「Jev」をリリースしました。
「LLMの代替」という触れ込みで注目を集めていますが、実際にはLLMと競合するものではありません。Jevは「LLMが苦手なことを、LLMの代わりにやる」モデルです。
本記事では、LLMとJevを技術的・実用的に比較し、どう使い分けるかを整理します。
注意：本記事は個人として公開情報をもとに調査・まとめたものです。所属組織の見解を代表するものではありません。
アーキテクチャの根本的な違い
LLMの仕組み
入力プロンプト → トークン化 → Attention → トークンを1つずつ逐次生成 → テキスト出力
- 出力はテキスト（非構造化）
- 1トークンずつ逐次生成 → 遅い・コストがかかる
- 同じ入力でも出力が変わりうる（確率的サンプリング）
- 幻覚が起きうる（訓練データの分布に依存）
Jevの仕組み
入力（状態データ + 型付き質問）→ 並列生成 → 型付き構造化値 + 確率スコア出力
- 出力は型付き値（Choice / Score / Noul）
- すべての出力を1回のクエリで並列生成 → 高速・安価
- スキーマに完全準拠（幻覚が構造的に不可能）
- 確率が数学的にキャリブレーション済み
出力形式の比較
LLMの出力
# LLMに感情分析を依頼した場合
response = llm.generate(
"以下のレビューの感情を分析してください：「配送が遅かったが商品は良かった」"
)
# 出力例（非構造化）：
# "このレビューは混合感情を表しています。配送に対する不満（ネガティブ）と
# 商品品質への満足（ポジティブ）が共存しています。"
# → 後処理でパース必要、毎回出力が違う、信頼度が不明
Jevの出力
# Jevに同じタスクを投げた場合
response = jev.ask(
state="配送が遅かったが商品は良かった",
questions=[
Choice("sentiment", options=["positive", "negative", "mixed"]),
Score("delivery_satisfaction", levels=["very_low", "low", "medium", "high"]),
Noul("would_recommend", "このレビュアーは商品を推薦しそうか"),
]
)
# 出力例（型付き・確率付き）：
# {
# "sentiment": {"value": "mixed", "probabilities": {"positive": 0.08, "negative": 0.12, "mixed": 0.80}},
# "delivery_satisfaction": {"value": "low", "confidence": 0.89},
# "would_recommend": {"value": true, "probability": 0.74}
# }
型安全・後処理不要・確率付き・毎回一貫した構造。
パフォーマンス比較
TypeSafe AIが公表している数値（分類タスクでの比較）：
| 指標 | フロンティアLLM | Jev |
|---|---|---|
| 応答時間（平均） | 3〜329秒 | 70〜500ms |
| 速度比 | 基準 | 193.6倍高速 |
| コスト比 | 基準 | 444.6倍安価 |
| 出力コスト | 通常料金 | 事実上ゼロ |
⚠️ これらのベンチマークはTypeSafe AI自身のチームが作成したワークフローを使用。第三者検証はこれから。
精度の比較
Jevはフロンティアモデル（GPT-4o、Claude 3.5等）と同等水準の精度を、分類・判断タスクで達成できると主張しています。
ただし重要な前提条件：
- あらかじめ選択肢・スキーマを設計する必要がある
- 「思考を言語化するタスク」「創造的なタスク」は対象外
- 入力の品質（state設計）が精度に大きく影響する
訓練方法の比較
| 訓練方法 | LLM（RLHF） | Jev（RLCD） |
|---|---|---|
| フルネーム | Reinforcement Learning from Human Feedback | Reinforcement Learning for Calibrated Decisions |
| 最適化目標 | 人間の好み | 確率のキャリブレーション |
| 訓練データ | 人間の書いたテキスト | 合成データのみ |
| 結果 | テキスト生成が上手い | 確率が正直（過信も過小評価もしない） |
RLCDにより、Jevの出力する確率は「0.9」と言ったら実際に90%正しい（統計的に）という特性を持ちます。LLMの「confidence score」はこの保証がありません。
ユースケース別の使い分け
Jevを使うべきケース
# ✅ コンテンツモデレーション
questions = [Noul("contains_violation", "規約違反コンテンツか")]
# ✅ LLM出力のガードレール
questions = [
Noul("is_safe", "安全な回答か"),
Noul("is_on_topic", "質問に関連した回答か"),
Score("quality", levels=["poor", "fair", "good", "excellent"])
]
# ✅ ドキュメント分類・ルーティング
questions = [Choice("department", options=["sales", "support", "billing", "other"])]
# ✅ 大量データの特徴抽出（ペタバイト規模）
questions = [
Score("relevance", levels=["irrelevant", "low", "medium", "high"]),
Choice("category", options=[...])
]
LLMを使うべきケース
# ❌（Jevには向かない）
# ・文章の要約・翻訳
# ・コード生成
# ・創作・ライティング
# ・複雑な多段階推論
# ・ユーザーとの自然言語会話
設計パターン：System 1 + System 2の組み合わせ
最も効果的な使い方はLLMとJevを組み合わせる設計です。
# 設計パターン：高速なSystem 1でふるいをかけ、必要な場合だけLLMへ
def handle_request(user_input: str) -> str:
# Step 1: Jevで高速分類（数百ms）
classification = jev.ask(
state=user_input,
questions=[
Choice("intent", options=["faq", "complaint", "purchase", "other"]),
Score("complexity", levels=["simple", "moderate", "complex"]),
Noul("needs_human", "人間のサポートが必要か")
]
)
# Step 2: シンプルなケースはLLM不要（FAQ回答を返す）
if classification["intent"]["value"] == "faq" \
and classification["complexity"]["value"] == "simple":
return lookup_faq(user_input) # LLM不使用
# Step 3: 複雑なケースのみLLMへ（コスト・時間を節約）
if classification["complexity"]["value"] == "complex":
llm_response = llm.generate(user_input)
# Step 4: Jevで品質評価・フィルタ（ガードレール）
evaluation = jev.ask(
state=f"Q: {user_input}\nA: {llm_response}",
questions=[
Noul("is_safe", "安全な回答か"),
Score("quality", levels=["poor", "fair", "good", "excellent"])
]
)
if not evaluation["is_safe"]["value"]:
return fallback_response()
return llm_response
このパターンにより：
- 単純なリクエストはLLMコストゼロ
- 全リクエストにガードレールをかけられる
- 平均応答速度が大幅に向上
まとめ：LLMとJevは競合しない
| 観点 | LLM | Jev |
|---|---|---|
| カテゴリ | System 2（深い推論） | System 1（高速判断） |
| 出力 | テキスト | 型付き値＋確率 |
| 強み | 生成・推論・会話 | 分類・評価・ルーティング |
| 弱み | 遅い・高い・幻覚リスク | 生成タスク不可 |
「LLMか Jevか」ではなく「どのタスクをどちらに振るか」が設計の問いです。
Jevのリリースは「AIシステムの全タスクをLLMに任せる時代」から「用途に応じてモデルを使い分ける時代」への転換点になりうる出来事です。