文章を書かないAI「Jev」を、自分の回線で Claude Opus 5 / GPT-6 Astra / Gemini 3.8 Flash と測り比べました。この資料は、その実測値と、今日から動かすためのコードをまとめたものです。
Jev は TypeSafe AI が 2026年9月15日に公開したモデルです。作ったのは Diogo Almeida(InstructGPT・RLHF の共同発明者)。「なぜ超人的なチャットモデルが AGI につながらないのか」を問い続けた結果、2年のステルス開発で RLCD(Reinforcement Learning from Calibrated Decisions)という学習手法を作り、そこから生まれたのがこのモデルです。
公式は System One モデルと呼んでいます。人間の思考でいう「直感」の側だけを担当し、文章生成の口をそもそも持っていません。入力は「判定したい文章(state)+型のついた質問」、出力は「判定+較正済みの確率」だけです。
つまり立ち位置は「LLMの代わり」ではなく、LLMの前に置くもの。この資料の8章で、それを実測で確かめます。
呼び出す側が先に選択肢を定義します。だから定義にない答えは返ってきません。これが「ハルシネーションしない」と言われる仕組みの正体です(=出力形式の話であって、判断の中身が正しい保証ではありません。11章参照)。
| 項目 | 値 |
|---|---|
| 料金(入力) | $0.042 / 100万トークン(約6円) |
| 料金(出力) | $0(無料) |
| コンテキスト長 | 32,000トークン |
| 公称レイテンシ | 70〜500ms(LLM比 40〜200倍速と主張) |
| エンドポイント | POST /api/alpha/decisions(チャットAPIとは別) |
公開直後は待機リスト制で、申し込みが殺到して API が一時停止するほどでしたが、2026年9月21日に待機リストが撤廃されました。今は登録するだけで使えます。
console.typesafe.ai)。登録すると $5 のクレジットが付きます。$0.042 / 100万トークンで割ると約1.2億トークン相当で、個人の検証ではまず使い切れません。typesafe/jev-1.13。この資料のコードはこちらの経路です(LLM側と同じ入口から叩かないと、速度の比較が公平にならないため)。chat/completions に投げると 400 で弾かれます。専用の /api/alpha/decisions を使ってください。また Jev は OpenRouter のモデル一覧(446件)に出てきません(alpha エンドポイント専用のため)。一覧にないから使えない、ではありません。
キーを1本入れれば、そのまま動きます。
curl -s -X POST "https://openrouter.ai/api/alpha/decisions" \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "typesafe/jev-1.13",
"state": "払い出しが3日間ずっと失敗しています。至急なんとかしてください。",
"questions": {
"is_urgent": {
"type": "noul",
"instructions": "この問い合わせは緊急対応が必要ですか?",
"criteria": {
"true": "業務が止まっている・金銭的被害・期限が迫っている",
"false": "すぐ対応しなくても実害が出ない"
}
}
}
}'
返ってくる JSON はこれだけです。パースも整形も要りません。
{
"model": "typesafe/jev-1.13-20260917",
"answers": { "is_urgent": { "type": "noul", "noul": 0.92 } },
"usage": { "input_tokens": 365, "output_tokens": 23, "cost": 0.00001533 },
"provider": "TypeSafe"
}
typesafe/jev-1.13 ですが、返ってくる実体は 1.13-20260917(9月17日版)です。モデルの世代を記録に残すときは、リクエストではなくレスポンスの model を見てください。
import json, os, time, urllib.request
KEY = os.environ["OPENROUTER_API_KEY"]
CATS = ["請求・支払い", "不具合・障害", "使い方の質問", "解約・契約変更", "その他"]
QUESTIONS = {
# Noul: criteria は true / false のキーを持つ辞書
"is_urgent": {
"type": "noul",
"instructions": "この問い合わせは緊急対応が必要ですか?",
"criteria": {"true": "業務が止まっている・金銭的被害・期限が迫っている",
"false": "すぐ対応しなくても実害が出ない"},
},
# Choice: criteria は「選択肢 → その条件」の辞書
"category": {
"type": "choice",
"instructions": "一次カテゴリを選んでください。",
"criteria": {c: c for c in CATS},
},
# Score: criteria は低→高の順に並べた配列(★ここだけ配列)
"frustration": {
"type": "score",
"instructions": "書き手の不満度",
"criteria": ["満足・好意的", "中立", "やや不満", "強い不満", "激怒・解約寸前"],
},
}
def jev(state, questions):
req = urllib.request.Request(
"https://openrouter.ai/api/alpha/decisions",
data=json.dumps({"model": "typesafe/jev-1.13",
"state": state, "questions": questions}).encode(),
headers={"Authorization": f"Bearer {KEY}",
"Content-Type": "application/json"})
t0 = time.perf_counter()
with urllib.request.urlopen(req, timeout=60) as r:
body = json.loads(r.read())
return body, (time.perf_counter() - t0) * 1000
body, ms = jev("解約したいのに導線が見つかりません。もう3回問い合わせています。", QUESTIONS)
a = body["answers"]
print(f"緊急度 {a['is_urgent']['noul']:.2f}")
print(f"カテゴリ {a['category']['choice']}(確信度 {a['category'].get('confidence')})")
print(f"不満度 {a['frustration']['score']:.2f}")
print(f"{ms:.0f}ms / ${body['usage']['cost']:.8f}")
これが Jev のいちばんおいしい使い方です。質問を何個束ねても1リクエストで返ります。
CHECKS = [
"第三者提供について記載があるか", "削除請求の手段が記載されているか",
"削除対応の期限が明記されているか", "データの保管国が明記されているか",
"未成年の扱いが記載されているか", "Cookieのオプトアウトが可能か",
# …24個でも48個でも、まとめて1回で投げる
]
questions = {
f"q{i}": {"type": "noul", "instructions": c,
"criteria": {"true": "文書中に明記がある", "false": "明記がない"}}
for i, c in enumerate(CHECKS)
}
body, ms = jev(規約の本文, questions)
for i, c in enumerate(CHECKS):
print(f"{body['answers'][f'q{i}']['noul']:.2f} {c}")
公称は「40〜200倍速い」。本当かどうか、いつも新モデルを検証しているツールに速度モードを足して、同じ課題・同じ入口(OpenRouter)・全レーン同時スタートで測りました。
| モデル | 所要時間 | 費用 | Jev比(時間) | Jev比(費用) |
|---|---|---|---|---|
| Jev | 332ms | $0.000070 | — | — |
| GPT-6 Astra | 6,378ms | $0.020610 | 19.2倍 | 294倍 |
| Gemini 3.8 Flash | 7,427ms | $0.004330 | 22.4倍 | 62倍 |
| Claude Opus 5 | 18,966ms | $0.028800 | 57.1倍 | 411倍 |
| モデル | 所要時間 | 費用 | Jev比(時間) | Jev比(費用) |
|---|---|---|---|---|
| Jev | 3,047ms | $0.000243 | — | — |
| GPT-6 Astra | 27.7s | $0.032840 | 9.1倍 | 135倍 |
| Claude Opus 5 | 37.8s | $0.027130 | 12.4倍 | 112倍 |
| Gemini 3.8 Flash | 48.8s | $0.015627 | 16.0倍 | 64倍 |
この課題では、Jev 側だけカテゴリに確信度が付きます。「自信の低い件だけ人間に回す」運用ができるのは、この確信度があるからです。
同じ課題を1項目だけにして測り直すと、差はぐっと縮みます。ここがいちばん大事なところです。
なぜこうなるのか。LLM は答えを「文字として書く」ので、項目が増えるほど書く量が増え、時間が伸びます。Jev は文字を書かず全部を同時に返すので伸びません。
効くのは答えが「言葉」ではなく「どれか」や「何点」で済む仕事だけです。具体的には3つの型に分かれます。
| 型 | 具体例 |
|---|---|
| 大量の文章を仕分ける | 問い合わせ・レビュー・メール・応募書類 |
| 1つの対象を多くの観点で採点する | 規約・契約書・コードレビュー・チェックリスト |
| LLMに渡す前の門番 | 難易度判定・安全確認・振り分け |
開発者コミュニティで広まっている整理がこれです。今までは内側か外側しかなく、その真ん中が空いていたという見方です。
既存の判定を置き換えるより、これまで高すぎて検査を置けなかった場所に、検査を足せるようになったことが大きい、という見方です。具体的な設置場所として挙がっているのがこの5つです。
問い合わせ12件を、(A) 全部 Claude Opus 5 で回答する場合と、(B) Jev に難易度を判定させて振り分ける場合で比べました。
choice の criteria は「辞書」、score の criteria は「配列」。逆にすると 400 Bad Request が返り、エラー文は expected array, received object の形になります。ここでいちばん時間を溶かします。score は整数で返りません。加重平均の小数(例 3.07)です。段階に戻したいなら自分で丸めてください。chat/completions では通りません。/api/alpha/decisions を使います。1番は実際にエラーを出して確かめられます。
# ✗ わざと間違える(score の criteria を辞書にする)→ 400
curl -s -X POST "https://openrouter.ai/api/alpha/decisions" \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"typesafe/jev-1.13","state":"解約したいのに導線が見つかりません。",
"questions":{"unhappy":{"type":"score","instructions":"不満度",
"criteria":{"0":"満足","1":"中立","2":"不満"}}}}'
# ✓ 正しい形(低→高の順に並べた配列)
curl -s -X POST "https://openrouter.ai/api/alpha/decisions" \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"typesafe/jev-1.13","state":"解約したいのに導線が見つかりません。",
"questions":{"unhappy":{"type":"score","instructions":"不満度",
"criteria":["満足","中立","やや不満","強い不満"]}}}'
Jev は「0.72」のような確率を返してきます。それをどう扱うかは、使う側が決めなければいけません。ここは自動では決まらない部分です。
判定の精度は、モデルより聞き方で決まります。実装するときの4点セットがこれです。
運用としては、グレーゾーンを人間に回す設計が扱いやすいです。たとえば「0.8以上は自動処理・0.3以下は自動で除外・その間だけ人が見る」といった三分割にすると、確信度の低い判定で事故が起きにくくなります。
ここは正直に書きます。万能の置き換えではありません。
入力 $0.042 / 100万トークン、出力 $0。実際に払った額で言うと、こうなります。
| やったこと | 実費 | 日本円 |
|---|---|---|
| 規約を24項目でチェック(1回) | $0.000070 | 約0.011円 |
| 問い合わせ10件を3観点で仕分け | $0.000243 | 約0.038円 |
| 問い合わせ12件の難易度判定(門番) | $0.000188 | 約0.029円 |
登録時の $5 クレジットは、この単価なら約1.2億トークンに相当します。上の24項目チェックなら、ざっと7万回ぶんです。個人の検証で使い切ることはまずありません。