TypeSafe Jevは、米TypeSafe AIが2026年9月中旬に早期アクセスで公開した、文章を生成せずに「判断」だけを返すAIモデルです。テキストと型付きの質問を渡すと、選択肢・段階評価・はい/いいえの確率が構造化された値で返ってきます。この記事では、Jevの仕組みと3種類の質問、入力100万トークン0.042ドルという料金、32kトークンの文脈長、日本語での精度の扱いを公式ドキュメントで確認し、Python SDKとPydantic AIでの実装コードを示します。最後に示すのは、問い合わせの振り分けやLLM出力の検査にJevを採用する条件と、見送るべき場面の判断基準です。
まとめ:TypeSafe Jevは分類と振り分けを安く速く返す判断専用API
結論から書きます。答えの候補が事前に決まっていて、同じ種類の判断を大量に回す処理なら、Jevは2026年10月時点で試す価値のある選択肢です。料金は入力100万トークンあたり0.042ドルで、出力は課金されません。1件1,000トークンの問い合わせを100万件振り分けても、入力は10億トークンで約42ドルです。
文章は一切書けません。要約・回答文の作成・判断理由の説明が要るなら、LLMと組み合わせる前提になります。
もう一つの前提は言語です。公式のモデルページは、学習の主言語を英語とし、日本語を含むCJKは「扱えるが同等ではない」と明記しています。日本語の問い合わせを流す案件では、自社データで正答率とconfidenceの分布を測ってから本番に入れてください。
TypeSafe Jevの正体と文章を生成しないSystem Oneモデルの仕組み
TypeSafe AIの発表記事は、Jevを「System One Model」という新しい種類の最初の公開モデルと位置づけています。名前はダニエル・カーネマンの『ファスト&スロー』の速い直感的思考(System 1)と、経済学者ウィリアム・スタンレー・ジェヴォンズに由来します。創業者のDiogo Almeida氏は、OpenAIでChatGPTの基礎になった指示追従の研究に関わった人物です。
状態と型付き質問を渡して確率付きの答えを受け取るAPIの入出力の形
Jevへの入力は、判断材料のテキスト(state)と、名前を付けた質問の集まり(questions)です。公式ドキュメントの概要によると、出力は文字列ではなく型の決まった値と確率分布で、コード側はそれをそのまま分岐・並べ替え・振り分けに使えます。
LLMとの違いは、文章を生成する処理のしかたです。LLMは1トークンずつ順に文章を出しますが、Jevは全質問を1回の処理で並列に評価します。発表記事は応答時間を70ミリ秒〜500ミリ秒としています。質問は互いに独立して評価されるため、1回のリクエストに質問を足しても応答時間はほとんど伸びません。
答えは定義した選択肢の中からしか返らないので、存在しない分類名が返ってくる「型エラー」は起きません。発表記事はこれを経験的な測定値ではなく、仕組みによる保証だと説明しています。
Choice・Score・Noulの3種類の質問で返ってくる値の違い
質問の型は3種類です。1回のリクエストで混ぜて使えます。
| 質問の型 | 用途 | 返る値 | 上限 |
|---|---|---|---|
| Choice | 候補から1つ選ぶ | 選択結果・確率分布・自信 | 選択肢255個 |
| Score | 段階の基準で評価する | 評価値・段階の説明・確率分布・自信 | 段階10個 |
| Noul | はい/いいえを判定する | noul(0〜1の確率) | なし |
Choiceの返却項目は、選択結果のchoice、確率分布のprobabilities、自信のconfidenceです。Scoreでは評価値のscore、段階の説明のlegendに加え、probabilitiesとconfidenceが返ります。
上限はAPIリファレンスの記載です。Scoreのscoreは確率で重み付けした値なので、段階と段階の間の数値(例:1.05)になることがあります。Noulだけはconfidenceを返しません。
2026年9月中旬の早期アクセス公開とjev-1.13.0の版管理
公開時期について、公式の発表記事には日付の記載がありません。Python SDKの変更履歴では初回公開版v0.5.7が2026年9月14日付で、報道各社は9月15日の発表として伝えています。提供は早期アクセスで、待機リストから順に利用者を招待する形です。
2026年10月10日時点の現行モデルはjev-1.13.0だけです。公式のModelsページによると、別名のjev-latestとjev-previewはどちらもjev-1.13.0を指しています。別名は新版が出ると指す先が変わるため、confidenceの閾値を調整したら、その版のIDに固定するよう公式が勧めています。
Jev 1.13の料金・文脈長・レート制限と日本語対応の実測値
この章の数値はすべて公式のModelsページ(2026年10月10日取得)に基づきます。
入力100万トークン0.042ドル・出力無料で試算する月額費用
| 項目 | jev-1.13.0の値 |
|---|---|
| 入力料金 | 100万トークンあたり0.042ドル |
| 出力料金 | 無料 |
| レート制限 | 毎秒10万トークン・毎秒80リクエスト |
| 文脈長 | 1リクエスト64k、stateと最長の質問で32k |
| 入力形式 | テキストのみ(画像・音声・動画は不可) |
入力料金を10億トークンあたりに換算すると42ドルです。公式クイックスタートの例では、3問を投げたリクエストの入力が392トークンでした。この規模なら1回あたり約0.0000165ドルです。月100万件でも約16ドルに収まり、費用が判断の妨げになることはまずありません。
レート制限は需要に合わせて予告なく変わると、同じページに警告があります。毎秒80リクエストを超えると429が返るため、バッチで大量に流す場合はSDKの再試行に任せるか、送信側で流量を絞ってください。発表記事も、料金が補助で成り立っていないことはまだ証明できず、持続性は長期で示すと書いています。単価が上がっても成り立つ設計にしておくのが無難です。
stateと最長の質問で32kトークンという文脈長の上限の意味
上限は2つあります。stateと一番長い質問を足して32kトークン、stateと全質問を足して64kトークンです。stateは1回だけ数えるので、実務で先に当たるのは32kのほうです。
超えると失敗します。Pydantic公式のJevのページによると、エラーはmax_tokens_exceededです。チャット履歴をそのままstateに入れる構成では、会話が長くなるといずれ必ず上限を超えます。ツールの実行結果は丸ごと履歴に残るため、特に早く上限に達する構成です。直近の数往復だけを残すか、LLMで要約してから渡す処理を最初から組み込んでおきます。
英語が主の学習言語で日本語は精度が落ちる前提での自社データ評価手順
Modelsページの「Language support」の項は、英語を主な学習言語とし、精度も現時点で英語がいちばん高いと書いています。CJKを含む他言語は扱えるものの同等ではなく、英語以外で使う前に自社のデータで試すよう求めています。日本語での精度は、数値としては公開されていません。
評価は次の順で進めます。
- 過去の問い合わせなど、人が正解を付けたデータを200〜300件そろえる
- 質問文と選択肢の説明を日本語版と英語版の2通り用意し、同じデータで正答率を比べる
- 正解・不正解ごとに
confidenceの分布を描き、不正解が集まる帯を確かめる - その帯より下を人へ回す閾値を決め、自動処理される割合を見積もる
手順4で自動処理の割合が低すぎるなら、日本語のテキストでJevを使う利点は薄れます。その場合は無理に採用しません。
Python SDKとcurlでJevのAPIを呼び出す実装手順
エンドポイントはPOST https://api.typesafe.ai/v1/systemoneの1本だけで、認証はAuthorization: Bearerヘッダーで行います。APIキーは公式クイックスタートにあるとおり、TypeSafeのコンソールで発行します。
typesafe-sdkのインストールとcurlでの最初のリクエスト送信
まずcurlで、リクエストの形を確かめます。次のJSONをrequest.jsonとして保存します。
{
"state": "昨日の更新から請求書PDFがダウンロードできません。月末締めなので今日中に必要です。",
"model": "jev-1.13.0",
"questions": {
"team": {
"type": "choice",
"instructions": "この問い合わせを担当すべきチームはどれか",
"criteria": {
"billing": "請求・支払い・契約プランに関する問い合わせ",
"bug": "製品の機能が正しく動かないという報告",
"account": "ログイン・権限・アカウント設定に関する問い合わせ"
}
},
"deadline_today": {
"type": "noul",
"instructions": "顧客は今日中という期限を示しているか"
}
}
}
export TYPESAFE_API_KEY='コンソールで発行したキー'
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d @request.json
応答にはanswersの下にteamとdeadline_todayが同じ名前で入り、modelに応答した版、usageに入力・出力のトークン数が入ります。質問の名前(キー)はモデルには送られず、推論にも使われません。判断に必要な情報はすべてinstructionsとcriteriaに書きます。
Pythonから使う場合はpip install typesafe-sdkで公式SDKを入れます。対応はPython 3.10以上で、クライアントは環境変数TYPESAFE_API_KEYを自動で読みます。
confidenceの値で自動処理と人の確認を分ける振り分けコード
Jevの使いどころは、答えと一緒に返るconfidenceです。公式のConfidenceページの計算式では、Choiceのconfidenceは選択肢の数をn、最大の確率をpとして(n×p−1)÷(n−1)です。3択で最大の確率が0.85なら約0.78で、クイックスタートの応答例と一致します。
from typesafe_sdk import Choice, Noul, TypeSafeClient
client = TypeSafeClient(model="jev-1.13.0") # 閾値を調整した版に固定する
def triage(ticket: str) -> dict:
res = client.system_one(
state=ticket,
questions={
"team": Choice(
instructions="この問い合わせを担当すべきチームはどれか",
criteria={
"billing": "請求・支払い・契約プランに関する問い合わせ",
"bug": "製品の機能が正しく動かないという報告",
"account": "ログイン・権限・アカウント設定に関する問い合わせ",
},
),
"deadline_today": Noul(instructions="顧客は今日中という期限を示しているか"),
},
)
team = res.answers["team"]
if team.confidence < 0.6:
route = "human" # 自信が低いものは人が振り分ける
elif res.answers["deadline_today"].noul > 0.8:
route = f"{team.choice}:high" # 当日締切は優先キューへ
else:
route = f"{team.choice}:normal"
# 応答した版・リクエストID・課金トークンを記録しておく
return {"route": route, "model": res.model,
"request_id": res.request_id, "input_tokens": res.usage.input_tokens}
print(triage("昨日の更新から請求書PDFがダウンロードできません。月末締めなので今日中に必要です。"))
閾値の0.6は、公式のConfidence-gated routingの例が下限に置いている値です。同じ例では、送金の承認のように誤りの影響が大きい操作だけ0.85を超えたときに自動実行し、それ以下は本人に確認させています。誤判定のコストで操作ごとに閾値を変える、という考え方はそのまま使えます。数値そのものは、前章の評価で自社データから決め直してください。
Pydantic AIのFallbackModelで自信の低い判断をLLMへ渡す構成
Pydantic AIは、JevをTypeSafeModelとして公式に扱っています。pip install "pydantic-ai-slim[typesafe]"で入り、出力の型を定義するとJevが各項目に答えます。次は公式ページの例を、版を固定した形で載せたものです。
from enum import StrEnum
from typing import Annotated
from pydantic import BaseModel, ConfigDict
from pydantic_ai import Agent, BoolCriteria, UseEnumMemberDocstrings
class Area(UseEnumMemberDocstrings, StrEnum):
billing = 'billing'
"""Charges, invoices, plans and payment methods."""
bug = 'bug'
"""Part of the product does not work as it should."""
account = 'account'
"""Logging in, access, and account settings."""
class Ticket(BaseModel):
"""Triage a support ticket."""
model_config = ConfigDict(use_attribute_docstrings=True)
area: Area
"""Which team owns this ticket?"""
urgent: Annotated[bool, BoolCriteria(
true='The customer is losing money or has a deadline today.',
false='It can wait its turn in the queue.',
)]
"""Should this ticket jump the queue?"""
agent = Agent('typesafe:jev-1.13.0', output_type=Ticket)
result = agent.run_sync('The timeline on my Android phone has been blank since the update this morning, '
'and my standup is in ten minutes.')
print(result.output) # 型どおりの値が返る
print(result.response.provider_details['confidence']) # 項目ごとの自信
公式ページの出力例では、areaの自信は1.0、urgentは0.24でした。質問はクラスと各項目のdocstringに書き、選択肢の意味はEnumのdocstringとBoolCriteriaで伝えます。この書き方はPydanticAIで型安全なエージェントを作る手順と共通です。
自信の低い判断をLLMへ渡すには、FallbackModel('typesafe:jev-latest', 'openai:gpt-5.6-sol')のようにJevを先頭に置き、設定decision_route_thresholdで受け渡しの基準を決めます。Jevが文章を書けないため、文字列型の項目を含む出力は後ろのLLMへ回ります。文脈長は、組み合わせたモデルのうち最も小さいJevの32kで測られる点に注意してください。
Jevが苦手な処理と公式jaggednessページに載る失敗パターン
TypeSafeはjev-1.13の苦手な処理をまとめたページを公開しています(2026年10月2日見直し)。挙げられた9項目は、どれもエラーにならず「それらしい答え」が返る点が厄介です。
計算・日付の比較・件数カウントをコード側へ逃がすJevとの役割分担設計
Jevは計算機ではない、と公式ははっきり書いています。文字数や出現回数を数えるのは苦手で、対象が大きいほど誤差が増えます。日付は順序のある量ではなくテキストとして読むため、どちらが先か、期間内かといった比較は信頼できません。
対処は「抽出はJev、計算はコード」です。日付なら、年・月・日をそれぞれ選択肢の決まったChoiceとして抜き出し、「記載なし」の選択肢も用意します。抽出した日付の組み立てと比較を担当するのはPythonです。件数を数えたいときは、候補を1件ずつNoulで判定して、合計をコードで取ります。請求書の金額照合のように数値の正しさが要る工程に、Jevを置いてはいけません。
選択肢の並び順とプロンプトインジェクションでJevの答えが動く問題
見落としやすいのが2点あります。1つは、Choiceの選択肢の並び順で答えが変わることがあり、先頭の選択肢に寄りやすいという報告です。公式は、順序を入れ替えて答えが変わらないか確かめるよう勧めています。
もう1つは敵対的な入力です。Jevはstateを敵意のないデータとして扱うため、仕込まれた指示や誘導的な書き方で答えが動きえます。TypeSafe自身も改善はこれからとしています。Jevで不正検知や有害判定のガードを作るなら、正規表現やルールによる決定的なチェックと併用し、単独の防御にしないでください。入出力の検査層の組み方はAIガードレールの設計と選定基準で整理しています。
TypeSafe Jevを採用する業務条件と見送るべき場面の判断
仕様と苦手な処理を踏まえて、採用と見送りの線を引きます。
問い合わせ振り分けやLLM出力の検査を大量に回す業務での採用条件
採用してよいのは、次の3つがそろう処理です。答えの候補が事前に決まっていること、同じ判断を大量または高頻度で繰り返すこと、自信の低い分を人かLLMへ回す経路を作れること。問い合わせの担当振り分け、LLMの回答が社内規程に触れていないかの判定、RAGで取得した文書の関連度の選別、エージェントが次に呼ぶツールの選択が当てはまります。
LLMの構造化出力でも同じ形の答えは得られます。違いは、LLMでは出力を検証して再試行する処理が要るのに対し、Jevは仕組みとして型外の値を返さない点と、確率が必ず付く点です。LLMで型を守らせる方法との比較はLLM構造化出力の仕組みと見送り条件、ツール選択をLLMに任せる従来の方式はFunction Callingの仕組みと実装で解説しています。
精度の目安について、TypeSafeのワークフロー評価は、GPT-6 AstraとClaude Fable 5.1の回答の平均を正解とみなして各モデルを比べています。評価課題は同社の社員が作ったもので、同社もバイアスの可能性を認めています。第三者による再現はまだ出ていません。
判断理由の説明・個人データの国外送信・日本語精度が要件なら見送る
次のどれかに当たるなら、Jevは採用しません。
- 判断ごとに理由を文章で残す必要がある(Jevは確率を返すだけで、説明は書かない)
- 個人データを国外のAPIへ送れない(発表記事によるとサービス拠点は米国西海岸で、データを保持しないZDRは企業向け契約の扱い)
- 日本語のテキストで評価した結果、自動処理できる割合が低い
- 判断の大半が金額・日付・件数の計算でできている
融資や採用の審査のように、なぜその判定になったかを説明する責任がある業務では、確率だけでは監査に耐えません。Jevを一次の振り分けに使う場合も、説明が要る案件は説明を書けるモデルか人の審査へ回す構成にします。
同じ「新しいAIモデル」でも、文章を生成する汎用LLMとは選定の物差しが違います。長文の推論やコード生成が主役なら、Qwen3.8-MaxのAPI料金と移行判断のような汎用LLMの比較が先です。振り分けの層と生成の層をどう分け、業務システムのどこに組み込むかから詰めたい場合は、生成AI導入支援のページで対応範囲を確認できます。
TypeSafe Jevの料金・日本語対応・使い方についてよくある質問
検索されることの多い疑問に、2026年10月10日時点の公式情報で答えます。
TypeSafe Jevは無料で使えますか?
公式の発表資料とModelsページに、無料枠や無料トライアルの記載はありません。料金は入力100万トークンあたり0.042ドルで、出力は無料です。早期アクセスのため、まず待機リストに登録して招待を待つ必要があります。ブラウザで質問を試せるPlaygroundもありますが、利用にはログインが要ります。課金の扱いは公式の案内で確認してください。
Jevは日本語のテキストを判断できますか?
扱えます。ただし公式のModelsページは、学習の主言語を英語とし、日本語を含むCJKは英語と同等の精度ではないと明記しています。日本語の正答率は公表されていません。本文の評価手順のとおり、正解付きのデータで日本語版と英語版の質問文を比べ、confidenceの分布を見てから自動処理の範囲を決めてください。
LLMの構造化出力やJSONモードとは何が違いますか?
LLMの構造化出力は、文章を生成するモデルに出力の形を守らせる仕組みです。Jevは最初から文章を生成せず、定義した選択肢の確率を並列に計算します。そのため型外の値は返らず、すべての答えに確率が付きます。反対に、要約や理由の説明のような自由な文章はJevでは作れません。両者は置き換えではなく、役割分担で組み合わせるものです。
画像や音声もJevに渡せますか?
渡せません。jev-1.13.0の入力はテキストのみで、受け付ける形式は文字列・JSONオブジェクト・テキストの配列です。画像・音声・動画は、OCRや文字起こしで先にテキストや構造化した項目に変換してからstateに入れるよう、公式は案内しています。発表記事のゲームのデモも、画面ではなくゲームの状態をテキストで表したデータで動かしています。
Jevを自社データで追加学習できますか?
できません。Modelsページによると、Jevは顧客データでのファインチューニングやLoRAに対応しておらず、全アカウントが同じ重みを使います。自社向けに合わせる手段は、stateに参照資料を入れること、質問のinstructionsとcriteriaに判断基準や境界の例を書くこと、大きな判断を小さな質問に分けてコードで組み合わせることの3つです。顧客のリクエストが学習に使われないことも同じページに明記されています。
関連記事
- LLM構造化出力とは?JSON Schemaで出力形式を保証する仕組みと実装・見送り条件を解説:LLM側で型を守らせる方式との比較に。
- PydanticAIとは|型安全なPythonエージェントの作り方を実装コードで解説:JevをTypeSafeModelとして組み込む前提知識に。
- AIガードレールとは?入力・出力を検査する実装層の設計と選定基準:Jevを検査層に使う場合の全体設計に。
- Function Callingとは|仕組みとOpenAI APIでの実装をコードで解説:LLMにツールを選ばせる従来方式の確認に。
- Pydanticとは?読み方・BaseModelの使い方とV1との違い:出力の型定義に使うBaseModelの基礎に。