
TypeSafe AI の Jev とは何か - 文字列を返さない「System One モデル」の仕組みと使いどころ
System 1 / System 2 の元ネタ。命名の背景が分かる。
RLHF など LLM の学習手法を基礎から学べる。
LLM をアプリに組み込む設計の考え方を実践的に。
当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。
Jev の概要
Jev は、米国サンフランシスコの TypeSafe AI が2026年9月15日に発表した AI モデルです。同社はこれを「System One モデル」という新しいクラスの最初の公開モデルと位置付けており、発表と同時に早期アクセス(ウェイトリストから順次招待)を始めました。
最大の特徴は、文章を生成しないことです。Jev に渡すのは「状態(state)」と「型の決まった質問」で、返ってくるのは次のような値だけです。
- 選択肢から1つを選んだ結果と、各選択肢の確率
- ルーブリック上のスコアと、各段階の確率
- ある文が真である確率(0〜1)
公式ブログは Jev を「フロンティア級の知能を持つ関数呼び出し(unstructured state in, typed probabilistic decisions out)」と表現しています。チャットやコード生成の代わりにはならず、プログラムの中で if 文の判定材料を返す部品として使うモデルです。
この記事の数値や主張は、断りがない限り TypeSafe AI 自身の公式ブログ・公式サイト・ドキュメント(2026-09-23 時点)に基づきます。第三者による独立した検証は、執筆時点で確認できていません。
誰が作ったのか
公式ブログは創業者 Diogo Almeida 氏の署名記事です。同氏は OpenAI 在籍時に言語モデルの指示追従を研究し、その成果が ChatGPT の基礎になったと書いています。チームページでは CEO の Almeida 氏に加え、COO の Sasha Sheng 氏(元 Meta/FAIR)、CTO の Erik Gafni 氏の3名が創業者として紹介されています。ブログによれば、約2年間ステルスで開発していたとのことです。
名前の由来も公式 FAQ に書かれています。
- System One: ダニエル・カーネマンの『ファスト&スロー』にある、速く直感的な「システム1」と、遅く熟考する「システム2」の区別から。
- Jev: 経済学者ウィリアム・スタンレー・ジェヴォンズから。蒸気機関の効率向上が石炭の需要をかえって増やしたように、知能のコストが下がれば用途が桁違いに増える、という見立て(いわゆるジェヴォンズのパラドックス)を込めたそうです。
LLM と何が違うのか
公式ブログには、既存の LLM と System One モデルを比べた表があります。要点を抜き出すと次のとおりです。
| 観点 | 既存の LLM | System One(Jev) |
|---|---|---|
| 学習の最適化 | RLHF(人が好む応答)/ RLVR(機械的に検証できる報酬) | RLCD(較正された判断) |
| 出力 | 文字列。アプリで使うにはパースと検証が必要 | 事前に定義した型の値と確率。型エラーは起きない |
| サンプリング | 1トークンずつ逐次生成 | 全出力を1回のクエリで並列に算出 |
| 価格 | 入力 $0.20〜$10/MTok、出力は入力の約5倍 | 入力 $0.042/MTok、出力は無料 |
| 応答時間 | 3〜329秒 | 70〜500ミリ秒 |
| 確信度 | 求めれば答えるが過信しがちで一貫しない | 全出力に較正された確率と confidence が付く |
RLCD は Reinforcement Learning for Calibrated Decisions の略で、TypeSafe AI が名付けた学習手法です。「confidence が高いほど正答率も高い」という較正(calibration)を目的にしている、と説明されています。アーキテクチャ・サンプラー・学習手法のいずれも新しく作ったとしていますが、具体的な中身は公開されていません。FAQ の「Jev は小さな LLM なのか」という問いには「小さくもないし、LLM でもない」とだけ答えています。
「ハルシネーションしない」の意味
公式サイトは「Zero Hallucinations」と打ち出していますが、この主張の範囲には注意が必要です。ブログで説明されているのは、出力の型とスキーマが事前に決まっているので、存在しない選択肢を返したり型の違う値を返したりすることが原理的に起きないという点です。ハルシネーションのグラフで Jev を 0% としているのも「実測値ではなく、スキーマ一致が保証されているため」と注記されています。
一方で、選んだ選択肢そのものが間違っている可能性はあります。ドキュメントの jaggedness(苦手分野)ページでも、誤答しやすい条件がはっきり列挙されています(後述)。「型が壊れない」と「判断が常に正しい」は別物として読むのが妥当です。
3つの質問タイプ(プリミティブ)
Jev に投げる質問は3種類で、1回の API 呼び出しに混在させられます。
| 質問タイプ | 何を聞くか | 返る値 |
|---|---|---|
| Choice | 選択肢から1つを選ぶ | choice、probabilities、confidence |
| Score | ルーブリックの段階で採点する | score、probabilities、confidence |
| Noul | この文は真か | noul(0〜1) |
ドキュメントによると、各質問は同じ state に対して並列かつ互いに独立して評価されます。質問を増やしても応答時間はほとんど変わらず、質問同士が影響し合うこともない、としています。
API と Python SDK の使い方
エンドポイントは POST https://api.typesafe.ai/v1/systemone です。公式クイックスタートのリクエスト例は次のとおりです。
{
"state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
"model": "jev-latest",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this",
"criteria": {
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions"
}
},
"frustration": {
"type": "score",
"instructions": "How frustrated the customer appears",
"criteria": [
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language"
]
},
"is_urgent": {
"type": "noul",
"instructions": "The message conveys urgency or time-sensitivity"
}
}
}同じページに掲載されているレスポンス例です。
{
"model": "jev-1.13.0",
"answers": {
"department": {
"type": "choice",
"choice": "technical",
"confidence": 0.78,
"probabilities": { "technical": 0.85, "sales": 0.0, "billing": 0.15 }
},
"frustration": {
"type": "score",
"score": 1.0,
"confidence": 1.0,
"legend": {
"0": "Calm, just stating facts",
"1": "Frustrated but civil",
"2": "Very angry, strong language"
},
"probabilities": { "0": 0.0, "1": 1.0, "2": 0.0 }
},
"is_urgent": { "type": "noul", "noul": 1.0 }
},
"usage": { "input_tokens": 392, "output_tokens": 65 }
}問い合わせチケットを「技術チーム宛て(確率 0.85)」「苛立っているが礼儀正しい」「緊急性あり」と判定しています。choice には criteria で定義したキー以外が入ることはありません。
Python SDK(typesafe-sdk、Python 3.10 以上)では次のように書けます。
pip install typesafe-sdkfrom typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient() # 環境変数 TYPESAFE_API_KEY を読む
ticket = "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP."
response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
),
"frustration": Score(
instructions="How frustrated the customer appears",
criteria=[
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language",
],
),
"is_urgent": Noul(
instructions="The message conveys urgency or time-sensitivity",
),
},
)
print(response.answers["department"].choice) # "technical"
print(response.answers["frustration"].score) # 1.0
print(response.answers["is_urgent"].noul) # 1.0JavaScript SDK(@typesafe-ai/sdk)も用意されています。筆者は早期アクセスの招待を受けていないため、上記はいずれも公式ドキュメント掲載のコードと出力例で、手元では実行していません。
Claude Code から使う場合
公式は Claude Code や Codex 向けのエージェントスキルも配布しています。Claude Code では次の2コマンドで導入できると案内されています。
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-aiただし、これは「Jev を使うコードを書くときの知識をエージェントに与える」ためのものです。ドキュメントには、Jev は Claude Code や Cursor などの裏で動く LLM の代わりにはならない、と明記されています。
confidence で分岐を設計する
Jev の設計思想が一番よく出ているのが confidence の扱いです。ドキュメントでは、confidence を確率分布の偏り具合から計算した 0〜1 の値と説明しています。1つの選択肢に確率が集中していれば 1.0、均等に散らばるほど低くなります(Noul には confidence は付きません)。
推奨されているのは、confidence を3段階に分けて挙動を変える設計です。
- 高い: 自動で実行する
- 中程度: ユーザーに確認する、レビューに回す
- 低い: 実行せず、人間や別のシステムに回す
さらに、閾値は操作のリスクに応じて変えるべきだとして、次の例が載っています。
action = response.answers["action"]
confidence = action.confidence
if confidence < 0.5:
# Model is genuinely unsure. Don't guess.
route_to_human(user_message)
elif action.choice == "check_balance":
# Low stakes. Showing the wrong screen is recoverable.
show_balance(account_id)
elif action.choice == "approve_transfer":
if confidence > 0.9:
# High stakes, high confidence. Proceed with confirmation.
confirm_then_execute(account_id)
else:
# High stakes, moderate confidence. Verify first.
ask_user_to_confirm(account_id)残高照会のように間違えても戻せる操作は低い閾値で実行し、送金承認のように戻せない操作は高い閾値を要求する、という考え方です。閾値の具体的な値はドメインと用途次第なので、保守的に始めて自分のデータで調整するよう注記されています。
質問は小さく分けてコードで組み合わせる
もう1つの基本方針が「アトミックな質問」です。「このピッチを評価して」と1問で聞くのではなく、市場規模・技術的な実現性・差別化を別々の Score で聞き、重み付けはコード側で行います。優先度が変わったらプロンプトを書き直すのではなく係数を変えればよい、という設計です。LLM に長い推論をさせる代わりに、判断のロジック自体はプログラムが持つ、という役割分担になっています。
価格・制限・対応言語
モデルページ(2026-09-23 時点)の情報です。
| 項目 | jev-1.13.0 |
|---|---|
| 価格 | 入力 $0.042/MTok($42/10億トークン)。出力は無料 |
| レート制限 | 毎秒25万トークン / 毎分1,200リクエスト |
| コンテキスト長 | 1リクエスト64kトークン。state と最長の質問の合計は32kトークンまで |
| 入力 | テキストのみ(文字列、JSON オブジェクト、テキスト配列)。画像・音声・動画は不可 |
エイリアスとして jev-latest と jev-preview があり、どちらも執筆時点では jev-1.13.0 を指しています。エイリアスは新版の公開で移動するため、confidence の閾値を特定バージョンで調整した場合はバージョン番号で固定するよう勧められています。レート制限は需要に応じて予告なく変わりうる、とも書かれています。
日本語で使う予定の人が気にすべき点として、ドキュメントには学習の主言語は英語で、CJK を含む他の言語は扱えるが精度は同等ではないとあります。日本語の問い合わせ分類などに使う場合は、自分のデータで試し、confidence を見ながら運用するのが前提になります。
データの扱いについては、顧客のリクエストやレスポンスで学習しないこと、顧客ごとのファインチューニングや LoRA は提供せず全アカウントが同じ重みを使うことが明記されています。
公式が認める苦手分野
TypeSafe AI は「Jev 1.13 jaggedness」というページで、自社モデルの弱点を具体的に公開しています(2026-09-17 最終確認と記載)。主なものは次のとおりです。
| 苦手なこと | 推奨される回避策 |
|---|---|
| 字義どおりに読む(意図を汲まない) | 条件と境界ケースを instructions / criteria に明記する |
| 計算・数を数えること | 計算はコードで行い、要素ごとに1問ずつ聞いて合計する |
| 日付の前後比較・期間計算 | 年月日の抽出だけを Choice で聞き、比較はコードで行う |
| 何段階もの間接参照 | 質問を直接的にし、state の該当箇所を名指しする |
| 無関係な情報が多い大きな state | 先にコードで絞り込み、必要な部分だけ渡す |
| 敵対的な入力(プロンプトインジェクション等) | criteria を明確にし、デプロイ前に境界ケースを試す |
| 文章生成 | 生成モデルを使う |
興味深いのは「構造的な不変性は保証されない」という項目です。同じ「返金を求めているか」を Noul と Choice で聞くと値が一致しない、ある問いとその否定を別々の Noul で聞くと確率の合計が 1.19 になる、といった実例が載っています。Noul で調整した閾値を Choice に流用しない、別々の質問のあいだに算術的な関係を期待しない、というのが公式の注意です。
「193.6倍速い・444.6倍安い」をどう読むか
公式サイトのトップには「193.6x Faster, 444.6x Cheaper」と大きく書かれていますが、ブログ本文にはこの数字の前提がかなり率直に書かれています。
- 数字の出どころは、TypeSafe AI が独自に作った「workflow evals」です。同じワークフロー(コードで表した判断の流れ)を各モデルに実行させ、GPT-6 Astra と Claude Fable 5.1 の出力の平均を参照解として比較しています。
- この参照解の取り方は OpenAI と Anthropic のモデルに有利に働く、と TypeSafe AI 自身が認めています。
- ワークフローは Jev に有利になるよう選んだものではなく学習データにも含まれていないが、作成したのは同社のモデル能力チームなので偏りはありうる、としています。
- 193.6倍・444.6倍は「実際の利用での改善幅としては高い側の値だろう」と書いています。
- LLM 側は同社の System One LLM ラッパーで構造化出力を強制して計測しています。
- 速度は西海岸のノートPCから計測しており、サービスも現在は西海岸にあるとのことです。日本から呼ぶ場合はネットワーク遅延が上乗せされる点に注意が必要です(筆者は未計測)。
- 価格については「補助金で安くしていないことは証明できない。長期的に示すしかない(下がる見込みで、上がる見込みではない)」と書いています。
また、Jev は公開ベンチマークのスコアを意図的に公表していません。FAQ では「公開ベンチマークを重視せず、各自のユースケースで評価を作ることを勧める」としています。評価の詳細は evals.typesafe.ai で公開されています。
自社の数字の弱点をここまで書いている点は評価できますが、裏返せば、現時点で外部から検証された数字ではないということです。導入を検討するなら、自分の実データで小さな評価セットを作り、既存の LLM と比べるのが確実です。
デモ: Doom と Wikipedia レース
ブログでは2つのデモが紹介されています。
- Doom: ゲームの状態をテキストのデータ構造で渡し、毎秒10回 Jev に行動を判断させるデモ。コストは1時間あたり約7ドルとのことです。画像入力ではない点、AI を使わないボットの方がうまく遊べる点も注記されています。
- Wikiracing: Wikipedia のあるページから別のページまで、リンクだけをたどって到達する競争。1手ごとに数百から数千のリンクから選ぶ必要があります。Choice の選択肢数(cardinality)は最大255で、それを超える場合は各リンクを個別に採点してから選ぶ2段階方式を取っているとのことです。
どんな場面で使えそうか
公式ドキュメントとクックブックに挙がっている用途を見ると、次のような「LLM に JSON を返させて if 文で分岐している箇所」が置き換え候補になります。
- 問い合わせや依頼の振り分け(intent routing)
- コンテンツのモデレーション、LLM の入出力のガードレール
- RAG で取得したパッセージの関連度判定、再ランキング
- 引用が元文書で裏付けられているかの確認
- 大量データへの特徴量付け(ブログでは map-reduce と表現)
逆に、文章を作る、コードを書く、長い推論をする、といった用途は対象外です。Jev は LLM を置き換えるものではなく、LLM を使うアプリの中の「判断だけの部品」を担うもの、と整理するのが分かりやすいと思います。LLM の構造化出力(JSON モード)と比べた利点は、型が保証されること、確率と confidence が必ず付くこと、そして速度と価格です。
まとめ
- Jev は TypeSafe AI が2026年9月15日に早期アクセスを始めた System One モデルで、文章ではなく型の決まった判断と確率を返します。
- 質問タイプは Choice / Score / Noul の3つ。1回の呼び出しで並列に評価され、Choice と Score には confidence が付きます。
- 価格は入力 $0.042/MTok・出力無料、応答は70〜500ミリ秒と公表されています。
- 「ハルシネーションしない」は型とスキーマが壊れないという意味で、判断の正しさまでは保証しません。苦手分野は公式が具体的に公開しています。
- 性能・速度の数字は自社評価に基づくもので、第三者検証は執筆時点で確認できていません。日本語は英語より精度が落ちると明記されているので、自分のデータでの評価が前提です。
関連記事として、比較対象に使われた GPT-6 Astra と、Fable シリーズの初代を扱った Claude Fable 5、ブログのデモで比較に使われた GPT-5.6 Terra、LLM のツール呼び出し学習を扱った Google ToolGrad の記事もあわせてどうぞ。


