【2026年最新】TypeSafe AIの「Jev」がAIシステム設計を変える理由——LLMでやらなくていいことをやめる
TL;DR
- 2026年9月15日、TypeSafe AIが**System Oneモデル「Jev」**をリリース
- LLMの代替ではなく「LLMが苦手なタスクの専用モデル」
- 分類・スコアリング・ルーティングが193倍速く・444倍安くなる可能性
- 「全部LLMに投げる」設計から「System 1 / System 2を使い分ける」設計へのシフト
- Jevで変わる設計パターンを実際のコードで解説
「LLMに何でも投げる」時代の終わり
AIをプロダクションに組み込む際、多くの開発者が直面するのはコストと速度の問題です。
# よくある設計（全部LLMに投げる）
def handle_user_request(text: str):
# 分類も → LLM
category = llm.generate(f"このテキストを分類してください: {text}")
# スコアリングも → LLM
score = llm.generate(f"このテキストの品質を1〜5で評価してください: {text}")
# ガードレールも → LLM
is_safe = llm.generate(f"このテキストは安全ですか？: {text}")
...
問題点：
- 1リクエストにLLMを3回呼ぶ → コスト3倍・レイテンシ3倍
- LLMは「テキスト生成」に最適化されており、分類・判断タスクは過剰スペック
- 幻覚リスクがある（「5」と評価してほしいのに「この内容は5点相当です」と文章で返ってくる）
TypeSafe AIのJevとは
2026年9月15日、TypeSafe AI（サンフランシスコ）がJevをリリースしました。
Jevは「System Oneモデル」という新カテゴリのAIです。
System One / System Two の概念
ダニエル・カーネマン著『ファスト＆スロー』に由来。
- System 1：速い・直感的・自動的（→ Jev）
- System 2：遅い・熟慮的・論理的（→ LLM）
Jevは「テキストを生成しない」AIです。入力した質問に対して、型付きの値と確率スコアを返します。
# Jevの出力イメージ
{
"category": {
"value": "technical_support",
"probabilities": {
"billing": 0.04,
"technical_support": 0.89,
"general": 0.07
}
},
"urgency": {
"value": "high",
"confidence": 0.92
},
"is_escalation_needed": {
"value": true,
"probability": 0.81
}
}
JevとLLMの根本的な違い
| 比較項目 | LLM（GPT-4o, Claude等） | Jev（System One） |
|---|---|---|
| 出力 | テキスト文字列 | 型付き値 + 確率スコア |
| 生成方式 | トークン逐次生成 | 全出力を並列生成 |
| 応答時間 | 3〜329秒 | 70〜500ms |
| 幻覚 | 発生しうる | 構造的に不可能（スキーマ外の出力なし） |
| コスト（入力） | 各社料金 | $0.042 / 100万トークン |
| コスト（出力） | 各社料金 | 事実上ゼロ（並列生成のため） |
| 訓練手法 | RLHF | RLCD（確率キャリブレーション） |
TypeSafe AIが公表している分類タスクでの比較：
- 193.6倍高速
- 444.6倍安価
（※自社計測値。第三者検証はこれから）
3つの問いプリミティブ
Jevへの質問は3種類のみ。これがシンプルさと安定性の源です。
from typesafe import jev, Choice, Score, Noul
# 1. Choice：定義された選択肢から1つ選ぶ
Choice("sentiment", options=["positive", "negative", "neutral"])
# 2. Score：順序付きレベルで評価する
Score("quality", levels=["poor", "fair", "good", "excellent"])
# 3. Noul：Yes/No の確率的判断（"noul" = "not null"）
Noul("contains_pii", "個人情報（PII）が含まれているか")
実践：Jevで何が変わるか
Before：全部LLMで処理するRAGシステム
def rag_with_llm_only(query: str, chunks: list[str]) -> str:
# Step 1: 全チャンクをLLMでリランク（遅い・高い）
ranked = []
for chunk in chunks:
score = llm.generate(
f"質問: {query}\nチャンク: {chunk}\n関連度を1〜5で評価:"
)
ranked.append((chunk, int(score.strip())))
# Step 2: 上位チャンクでLLM生成（普通）
top_chunks = sorted(ranked, key=lambda x: x[1], reverse=True)[:3]
return llm.generate(f"質問: {query}\n文脈: {top_chunks}")
問題点：チャンク数が増えるとリランクのコスト・時間が線形増加
After：JevでリランクしてLLMは生成だけに集中
def rag_with_jev_rerank(query: str, chunks: list[str]) -> str:
# Step 1: Jevで並列リランク（超高速・激安）
scored_chunks = []
for chunk in chunks:
result = jev.ask(
state=f"質問: {query}\nチャンク: {chunk}",
questions=[
Score("relevance", levels=[
"not_relevant", "slightly", "moderately", "highly", "perfectly"
]),
Noul("directly_answers", "質問に直接答えているか")
]
)
scored_chunks.append({
"chunk": chunk,
"relevance": result["relevance"]["value"],
"direct": result["directly_answers"]["value"],
"confidence": result["relevance"]["probabilities"]["perfectly"]
+ result["relevance"]["probabilities"]["highly"]
})
# Step 2: スコア順で並べて上位3件を取得（70〜500ms）
top = sorted(scored_chunks, key=lambda x: x["confidence"], reverse=True)[:3]
context = "\n---\n".join([c["chunk"] for c in top])
# Step 3: LLMは生成だけ（本来の仕事）
return llm.generate(f"質問: {query}\n文脈:\n{context}")
改善点：リランクコストをほぼゼロに。LLMは「テキスト生成」だけに使う。
ガードレールの設計も変わる
def safe_llm_pipeline(user_input: str) -> str:
# Step 1: 入力チェック（Jev）
input_check = jev.ask(
state=user_input,
questions=[
Noul("is_safe_input", "安全なユーザー入力か"),
Choice("intent", options=["question", "task", "harmful", "other"])
]
)
if not input_check["is_safe_input"]["value"]:
return "申し訳ありませんが、その内容にはお答えできません。"
# Step 2: LLMで生成（必要な場合のみ）
response = llm.generate(user_input)
# Step 3: 出力チェック（Jev）
output_check = jev.ask(
state=f"Q: {user_input}\nA: {response}",
questions=[
Noul("is_safe_output", "安全な回答か"),
Noul("contains_pii", "個人情報が含まれているか"),
Score("quality", levels=["poor", "fair", "good", "excellent"])
]
)
if not output_check["is_safe_output"]["value"] \
or output_check["contains_pii"]["value"]:
return fallback_response()
return response
「ジェヴォンズのパラドックス」とAIの未来
Jevという名前は19世紀の経済学者ウィリアム・スタンリー・ジェヴォンズに由来します。
ジェヴォンズのパラドックス：蒸気機関の効率化（コールへの需要を減らすはず）が、実際には石炭需要をむしろ増加させた。
TypeSafe AIはこれをAIに適用しています：
AIのコストが下がれば、今まで「費用対効果が合わない」と諦めていた膨大な数のユースケースが一気に解放される。
分類タスクが1/400のコストになれば、「全データにAI評価をかける」「リアルタイムモデレーションを全ユーザーに適用する」といった設計が現実的になります。
Jevの注意点・現時点での限界
採用を検討する前に把握しておくべきポイント：
- Limited early access中（2026年9月時点）：本番導入前にSLA・可用性を確認
- ベンチマークは自社計測：第三者機関による独立した検証はこれから
- スキーマ設計が重要：選択肢・レベルの設計品質が精度に直結
- 生成タスクは対象外：要約・翻訳・コード生成はLLMを使うべき
- 資金調達・創業間もない：2024年創業、$4000万シードラウンド（DCVC主導）
まとめ：「LLMか、Jevか」ではなく「どちらが適切か」
判断基準：
出力が「テキスト」であるべきか？
YES → LLMを使う
NO → 型付き値（分類・スコア・判断）で十分か？
YES → Jevを検討する
NO → 要件を再確認する
Jevは2026年のAIシステム設計に新しいオプションをもたらしています。
「全部LLMで解決する」から「用途に応じてSystem 1とSystem 2を使い分ける」へ——このパラダイムシフトを今のうちに理解しておくことが、今後のAIシステム設計で競争優位を持つことにつながると思います。
最後に：このトピックについてさらに深掘りした記事を今後も書いていく予定です。Jev・AIアーキテクチャ・AIシステム設計に興味がある方は、フォローいただけると更新情報をお届けできます。