エージェントの中にある if 文を、文章を一切書かないAIに任せられるのか——2026年9月20日時点の答えは「型が Choice / Score / Noul のどれかに収まる判定なら、Jev で置き換えられる」です。
2026年9月20日時点のスナップショット
- Jev（ジェヴ）は TypeSafe AI が2026年9月15日に早期提供を開始した「System One Model」。文章を生成せず、型付きの質問に対して判断結果と確率・確信度だけを返す。
- APIは
POST PH_0_の1本のみ。リクエストはstate（判断材料）とquestions（型付き質問のマップ）の2つで成立する。 - 公式料金は入力100万トークンあたり0.042ドル、出力トークンは無料。公式ブログの実測レンジはエンドツーエンド70〜500ミリ秒。
- 現行モデルは
jev-1.13.0（エイリアスjev-latest）。入力はテキストのみ、1リクエスト64kトークン、state＋最長質問で32kトークンまで。 - 公式の Workflow evals では、4タスク平均でJevが正答率67.8%・1件0.4秒・1件0.0004ドル。Claude Opus 5（73.1%）には正答率で負けている。
- 利用は TypeSafe AI 公式サイトの「Join Waitlist」からの順次招待制。
この記事は、LLMに投げていた分岐判定・ルーティング・ガードレール判定をJevへ寄せるときの設計を、公式ドキュメントに書いてある範囲だけで組み立てます。公式docsに存在しないフィールドやメソッドは一切使いません。
【続編 2026年9月】ルーティング・ガードレール・評価まで、実装パターン 7 つ
入門で扱った 3 つの質問型を、既存のパイプラインにどう組み込むか。ルーティング、承認ゲート、抽出結果の検証、evals の見方、LLM とのハイブリッド、確信度のしきい値とフォールバックを、公式 docs のコード例だけで次の記事に整理しました。 Jev API実装パターン7つ｜Pythonコード例
Jevは「何を返さないか」で設計されている
Jevを理解する最短ルートは、機能表ではなく「捨てたもの」を見ることです。Jevは文字列生成を捨てました。TypeSafe AI の発表記事「Introducing System One Models & Jev」は、System One Model を「ソフトウェアがそのまま使える、速く構造化された判断を下すために作られた新しいフロンティアモデルのクラス」と定義し、その訓練手法を RLCD（Reinforcement Learning for Calibrated Decisions） と呼んでいます。
結果として、Jevには次の性質が生まれます。
- パースするものがない — JSONを「それっぽく書かせて」パースするのではなく、モデルが選択肢上の確率分布をそのまま返す。型エラーが構造的に起きない。
- 確信度が必ず付く — Choice と Score の回答には
confidence（0〜1）が付く。公式ブログは「確信度が高いほど正答率が高い、という意味で較正されている」と説明しています。 - 質問は並列評価される — 1リクエストに複数の質問を入れても、Jevは
stateを一度読んで全質問を並列に評価します。
逆に言えば、Jevは「返答文を作る」「要約する」「コードを書く」用途には使えません。ここは後半の「向かない処理」で具体的に潰します。
System One / System Two という区切り
命名の由来は、人間の思考を速い直感（System 1）と遅い熟考（System 2）に分ける古典的な区分です。TypeSafe AI は「エキスパートが文脈を渡されれば数秒で答えられる粒度の判断」をSystem Oneタスクと呼び、そこだけを専用モデルで刈り取る設計を選びました。公式docsのPrimitivesページも「質問は原子的でスコープが明確なときに最も機能する」と明記し、複雑な問いは分解してコード側で合成しろ、と繰り返し書いています。
この「モデルは判断だけ、合成はコード」という分担は、Claude Opus 5 世代で話題になったモデル振り分け設計と地続きです（Claude Opus 5登場｜エージェント設計のモデル振り分けが変わる）。Jevは、その振り分けの「最下層」に新しく置ける部品だと考えると位置づけが掴みやすくなります。
Choice・Score・Noul——3つの型と返り値を先に固める
Jevで最初に決めるのは、プロンプトではなく型です。公式APIリファレンスにある3種類しかありません。
| 型 | 用途 | criteria の形 | 返り値フィールド |
|---|---|---|---|
noul |
Yes/Noの命題を評価 | 任意。true / false の意味を説明できる |
noul（0〜1の確率） |
choice |
定義した選択肢から1つ選ぶ | 必須。選択肢キー → 説明のマップ（説明不要なら null） |
choice / probabilities / confidence |
score |
自分で定義した尺度で採点 | 必須。順序付きのレベル説明の配列（最低2段階） | score / legend / probabilities / confidence |
3つとも type と instructions を共通で持ちます。質問につけるキー（ID）は自分で決め、回答は同じキーの下に返ってきます。公式docsは「このキーはモデルに送られず、推論には使われない」と明記しているので、可読性重視の命名で構いません。
注意したいのが noul だけ confidence を持たないことです。公式のConfidenceページによれば、confidence は「回答がすでに持っている確率分布から計算される統計量」であり、Noulは返り値の noul 自体が確率なので、それがそのまま信号になります。1に近ければYes、0に近ければNo、0.5付近は「判断がつかない」です。
Score の score はレベルの中間値を取る
Score の返り値 score は、レベル間の確率加重平均です。レベルを3段階（0/1/2）で定義したとき、score が 1.035 のような小数で返ってきます。公式docsの model jaggedness ページは、ここを勘違いして「レベル間を補間して正確な数値を復元する」使い方をしないよう明確に警告しています。Scoreはしきい値判定に使うもので、精密な量の算出には使わない——これが公式の指示です。
最初の1リクエストを通す
ここからは公式クイックスタートに掲載されているコードです。まずHTTPで叩く場合。
curl -X POST PH_9_ \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d @- << 'EOF'
{
"state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
"model": "jev-latest",
"questions": {
"urgency": {
"type": "noul",
"instructions": "Does this message express urgency?"
}
}
}
EOFリクエストの必須フィールドは state、model、questions の3つだけです。state は文字列でもオブジェクトでも配列でもよく、チャットログやレコードのような構造化データをそのまま渡せます。
次にPython SDK。公式docsが示すインストールは以下のとおりで、Python 3.10以上が必要です。クライアントは環境変数 TYPESAFE_API_KEY を読み、既定で jev-latest を呼びます。
pip install typesafe-sdk
# uv を使う場合
uv add typesafe-sdkfrom typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
ticket = "Hi, I've been trying to connect my Stripe account for 3 days and it 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) # "billing"
print(response.answers["frustration"].score) # 1.035
print(response.answers["is_urgent"].noul) # 0.999
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。返ってくるJSONの形も公式に定義されています。Choice の回答は probabilities が全選択肢の確率（合計1）を持ち、confidence がそこから導かれます。
{
"model": "jev-latest",
"answers": {
"department": {
"type": "choice",
"choice": "billing",
"probabilities": { "billing": 0.84, "technical": 0.159, "sales": 0.001 },
"confidence": 0.596
},
"frustration": {
"type": "score",
"score": 1.035,
"legend": { "0": "Calm, just stating facts", "1": "Frustrated but civil", "2": "Very angry, strong language" },
"confidence": 0.842
},
"is_urgent": { "type": "noul", "noul": 0.999 }
},
"usage": { "input_tokens": 312, "output_tokens": 48 }
}JavaScript版SDKは @typesafe-ai/sdk として公開されており、公式docsのModelsページには TypeSafeClient を使ったモデル一覧取得の例が載っています。
エージェントの if をJevに寄せる設計
ここが本題です。LLMに投げていた分岐判定をJevへ移すとき、設計で決めるのは次の3点だけです。
1. 入出力の型を先に書き下す
「このチケットをどう扱うべきか」のような広い問いをそのまま投げるのは、Jevの使い方として最も筋が悪い。公式docsは判断を原子的な質問へ分解し、合成はアプリケーションコード側でやることを一貫して推奨しています。
たとえばサポートチケットの振り分けなら、こう分解します。
- カテゴリ判定 →
choice（bug_report / billing / feature_request） - バグの深刻度 →
score（4段階） - 再現手順の有無 →
noul - 返金要求か →
noul - 不満度 →
score
そのうえで、公式の Speculative fan-out パターンが推す通り、必要になるかもしれない質問も含めて全部1リクエストに入れます。公式の説明は明快で、「すべての質問が並列に評価されるため、質問を追加してもレスポンスのレイテンシはほとんど増えない」。カテゴリがバグ報告でなければ、深刻度の回答は単に無視すればいい。ラウンドトリップが1回減ります。
# 公式 Speculative fan-out パターンより
category = response.answers["category"]
bug_severity = response.answers["bug_severity"]
bug_repro = response.answers["has_reproducible_steps"]
refund = response.answers["refund_requested"]
frustration = response.answers["frustration"]
if category.choice == "bug_report":
if bug_severity.score > 1.5 and bug_repro.noul > 0.6:
escalate_to_engineering(ticket_id, severity="high")
else:
add_to_bug_backlog(ticket_id)
elif category.choice == "billing":
if refund.noul > 0.7:
route_to_billing_with_flag(ticket_id, refund_likely=True)
else:
route_to_billing(ticket_id)
elif category.choice == "feature_request":
log_feature_request(ticket_id)
# カテゴリに関わらず使える信号
if frustration.score > 1.5:
flag_for_priority_response(ticket_id)2. 確信度のしきい値を「賭け金」で決める
Jevへ移行する価値の大半はここにあります。LLMに「JSONで confidence も返して」と頼んだ場合、その数字は生成された文字列であって分布から導かれた統計量ではありません。Jevの confidence は後者です。
公式の Confidence-gated routing パターンは、しきい値を行為の重さに応じて変える例を示しています。
# 公式 Confidence-gated routing パターンより
action = response.answers["intent"]
if action.confidence < 0.6:
route_to_support_agent(account_id)
elif action.choice == "check_balance":
show_balance(account_id)
elif action.choice == "approve_transfer":
if action.confidence > 0.85:
approve_transfer(account_id)
else:
ask_user_to_confirm("Just to confirm: you would like to approve this transfer, is that correct?")
else:
route_to_support_agent(account_id)読み方はシンプルです。どの行為でも確信度0.6未満なら人間へ回すのが床。残高照会のような低リスク操作は0.6で十分。送金承認のような高リスク操作は0.85超でなければ自動実行せず、ユーザーに確認を取る。公式Confidenceページも「境界をどこに引くかは賭け金次第」「保守的に始めて、自分のデータでの挙動を見ながら調整せよ」と書いています。
公式ドキュメントが明示している通り、confidence はTypeSafe AI側が「多くのユースケースに合う便利な尺度」として提供しているものにすぎず、その定義に縛られる必要はありません。probabilities が生で返ってくるので、自分の運用に合う指標（上位2択の差など）を自前で計算する道は常に開いています。
3. フォールバック先を必ず2系統持つ
低確信度で人間に回す先は当然として、Jev自体が落ちたときの経路も設計に含めます。公式APIリファレンスは、レート超過で 429 Too Many Requests、過負荷で 529 Overloaded を返すと明記しています。SDKは既定で指数バックオフのリトライを行い、retry-after ヘッダを尊重しますが、HTTP APIを直接叩く場合は自分で実装が必要です。
さらにレート上限そのものが流動的です。公式Modelsページは現在 毎秒250,000トークン／毎分1,200リクエストと書いたうえで、「非常に大きな需要をさばいており、上限は予告なく変わりうる」と明記しています。早期アクセス段階のサービスを本番のクリティカルパスに置くなら、既存LLMかルールベースへの縮退経路は外せません。
レイテンシと単価：公式の数字だけで比べる
公表されている料金と制約は以下のとおりです（すべて公式Modelsページ・2026年9月20日確認）。
| 項目 | Jev 1.13（jev-1.13.0） |
|---|---|
| 入力料金 | 10億トークンあたり42ドル ／ 100万トークンあたり0.042ドル |
| 出力料金 | 無料（出力トークンは課金されない） |
| レート上限 | 毎秒250,000トークン ／ 毎分1,200リクエスト |
| コンテキスト | 1リクエスト64kトークン。state＋最長質問で32kトークン |
| 入力形式 | テキストのみ（文字列／JSONオブジェクト／テキスト配列）。画像・音声・動画は不可 |
| エイリアス | jev-latest → jev-1.13.0、jev-preview → 現在は同じ |
| レイテンシ | エンドツーエンド70〜500ミリ秒（公式ブログ記載値） |
速度と単価の比較は、TypeSafe AI が公開している Workflow evals が一次情報です。4つの業務ワークフロー（Security Incidents / Agent Trace Observability / Invoice Processing / Customer Service）を等重みで平均した数値が以下です。
| モデル（workflow構成） | 平均正答率 | 1件あたりコスト | 1件あたり時間 |
|---|---|---|---|
| sol | 74.1% | 0.0836ドル | 23.3秒 |
| Claude Opus 5 | 73.1% | 0.1761ドル | 37.8秒 |
| terra | 67.9% | 0.0304ドル | 10.1秒 |
| Jev | 67.8% | 0.0004ドル | 0.4秒 |
| Claude Sonnet 5 | 67.8% | 0.1174ドル | 78.1秒 |
| luna | 66.8% | 0.0033ドル | 12.9秒 |
| DS v4 pro | 65.5% | 0.0413ドル | 86.5秒 |
| DS v4 flash | 64.4% | 0.0059ドル | 51.9秒 |
| Claude Haiku 4.5 | 53.6% | 0.0195ドル | 12.5秒 |
読み方を間違えないようにしたいので、Jevが負けている点から先に書きます。
- 正答率ではOpus 5とsolに負けている。 平均で5〜6ポイントの差があります。精度が最優先で、1件あたり0.17ドル・38秒を許容できる処理なら、Opus 5のほうが素直に強い。
- タスクによる振れ幅が大きい。 Invoice Processing ではJevが61.8%に対し、Opus 5が78.4%、solが79.1%。16ポイント以上の差がつきます。逆に Customer Service ではJevが76.0%でOpus 5（72.4%）を上回る。自分のワークロードで測らないと判断できないタイプの差です。
- 正解ラベル自体がLLM由来。 同ページは、参照ラベルを GPT-6 Astra と Claude Fable 5.1（いずれもhigh thinking）の回答の平均で生成したと明記しています。つまりこのevalは「現時点で最も賢い大型モデルにどれだけ近いか」を測っており、人手の正解と照合したものではありません。
そのうえでコストと速度の差は桁が違います。Sonnet 5 とJevは平均正答率が同値（67.8%）でありながら、コストは0.1174ドル対0.0004ドルで約293倍、時間は78.1秒対0.4秒で約195倍の開きです。「同じ精度でこの差」という一点が、Jevを検討する最大の理由になります。
公式ブログがトップページで掲げる「193.6倍速い／444.6倍安い」という数字も、この eval が出典です。TypeSafe AI 自身が発表記事の中で「これらは現実の利得としては上振れした側だと考えている」「評価ワークフローは訓練分布外だが、自社のモデル能力チームのメンバーが作成したものなのでバイアスはありうる」と断っている点は、そのまま引用しておく価値があります。自己採点のベンチマークであることは前提です。
単価の比較設計そのものについては、従量課金とサブスクの境目を扱ったAIエージェントのコスト管理｜API従量とサブスク徹底比較も合わせて読むと、Jevを差し込む前後で何が変わるか見積もりやすくなります。
Jevに向かない処理——公式が認めている弱点
TypeSafe AI は Jev 1.13 の model jaggedness ページで、モデルが苦手な領域を11項目挙げています。ローンチブログよりこのページのほうが実装判断には効きます。主要なものを整理します。
| 苦手な処理 | 公式が示す回避策 |
|---|---|
| カウント（件数を数える） | コード側で数える。候補ごとに1問ずつ聞いて合計する |
| 日付・時刻の比較 | 日付は「順序を持つ量」ではなく文字として読まれる。抽出だけをChoiceで行い、順序・期間・演算はコードで |
| 数値表現（16進数・RGB等） | 変換はコードで行い、計算済みの数値や名前付きバケットを渡す |
| Scoreを使った算術 | しきい値判定だけに使う。レベル間の補間で正確な数値を作らない |
| 文章生成 | 生成用に訓練されていない。答えの空間が有限ならChoiceに変換し、生成は他モデルへ |
| 文字どおりに読む癖 | 「書いた問い」に答え、「意図した問い」には答えない。条件を明示し、解釈が要るなら2問に分けてコードで合成 |
| 二重否定・多段推論 | 指示はできるだけ直接的に書き、参照する情報を名前で指定する |
| 無関係な情報が多い state | コード側で先に絞り込み、その質問に必要なフィールドだけを送る |
| 敵対的な入力 | データを敵とは見なさない。criteriaを明示し、投入前に十分テストする |
| 矛盾した指示とcriteria | instructionsとcriteriaが別のことを聞いていると混乱する。表現を揃える |
| 構造的な恒等式 | P(noul) + P(not noul) = 1 のような同一性は保証されない。しきい値を質問型間で流用しない |
特に運用で効くのは日付比較とカウントです。「この請求書は支払期限を過ぎているか」「添付ファイルは3件以上あるか」をJevに聞くのは設計ミスで、どちらもコードの仕事です。Jevに任せるのは「この文面は支払期限に言及しているか（Noul）」までで、比較はPython側でやる。この線引きを最初に引いておかないと、確信度が高いまま静かに間違う経路ができます。
言語面の制約も見落とせません。公式Modelsページは「英語が主要な訓練言語であり、現時点で最も精度が高い。CJKを含む他言語も扱えるが同等ではない」と明記し、非英語ワークロードでは投入前に自分のコンテンツでテストし、ルーティング時はConfidenceに特に注意するよう求めています。日本語の問い合わせ本文や社内規程をそのまま state に入れるなら、この注記は前提条件として扱うべきです。
ガードレール判定に使うときの注意
Jevの用途として分かりやすいのが、LLMの入出力を検査するガードレールです。公式のLLM guardrailsクックブックは、入力側と出力側それぞれに4つのNoul質問と1つのScore質問を並べ、1リクエストで評価する構成を示しています。入力側はジェイルブレイク試行・有害要求・医療助言要求・自傷の兆候、出力側はポリシー違反・有害な手助け・医療助言・自傷の助長をチェックし、Scoreで「応じた場合にどれだけ害が生じうるか」を0〜3で採点します。
クックブックは2つのポリシーを例示しています。strict では review_threshold=0.35 / action_threshold=0.70 / severity_block=2.0、permissive では action_threshold のみ0.85。結果は pass / review（人間が見る）/ block（拒否）/ support（危機対応経路）の4分岐です。同じ評価結果でも、ポリシーを差し替えるだけで判定が変わる設計になっています。
ただし、ここは model jaggedness の「敵対的な入力」項目と正面からぶつかります。公式が「Jevはデータを敵対的なものとして扱わない。注入された指示や誤解を招く体裁に対して脆弱である」と明言している以上、Jevによるガードレールは多層防御の一層であって、単独の砦にはなりません。プロンプトインジェクション対策の全体設計はプロンプトインジェクション対策｜エージェント多層防御5層で整理しているので、Jevはそのうち「意味的検査の層」を高速・安価に埋める部品として組み込むのが妥当です。
つまずきやすい3つの設計ミス
公式ドキュメントの記述から、移行時に踏みやすい地雷を先回りで潰しておきます。
❌ 広い問いを1問で投げる
❌ Choice(instructions="このチケットをどう処理すべきか", criteria={...10択...})
⭕ カテゴリ・深刻度・再現性・返金要求を別々の質問に分解し、分岐はコードで書く。公式docsが繰り返す「原子的でスコープが明確な質問」の原則そのままです。質問を増やしてもレイテンシはほとんど増えません。
❌ 確信度のしきい値を質問型をまたいで使い回す
❌ 「Choiceで0.7以上を自動実行にしたから、Noulも0.7以上で自動実行」
⭕ 公式 model jaggedness は「しきい値を質問型の間で移送しない」と明記しています。Choiceの confidence は分布の集中度から導かれる統計量、Noulの noul はYesの確率そのもので、意味が違います。型ごとに別々にキャリブレーションしてください。
❌ エイリアスに乗ったまましきい値を固定する
❌ jev-latest を指定し、0.85というしきい値を本番にハードコードして放置
⭕ 公式Modelsページは「エイリアスは新リリースで移動するため、背後の答えが自分の変更なしに変わりうる」と警告し、特定バージョンで確信度をチューニングしたならバージョンIDをピン留めし、自分のスケジュールで移行せよと指示しています。レスポンスの model フィールドには実際に回答したバージョンIDが入るので、必ずログに残しておきます。この「無日付エイリアスの罠」はClaudeでも同じ議論がありました（無日付Claude IDの落とし穴と開発者の対処法）。
早期アクセスの申し込みと、周辺で起きていること
2026年9月20日時点で、Jevは誰でもすぐ使えるわけではありません。公式サイトの「Join Waitlist」から登録し、順次招待を受ける形です。公式ブログは「できる限り速くウェイトリストから開発者を通している」と書いています。APIキーはダッシュボードから取得し、環境変数 TYPESAFE_API_KEY に入れます。ブラウザ上のPlaygroundで state と質問を貼って挙動を見てから実装に入る導線も用意されています。
コーディングエージェントで使う場合、TypeSafe AI 自身が Agent Skill を配布しています。公式クイックスタートに記載されているコマンドは次のとおりです。
# Claude Code の場合
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai
# その他のエージェント
npx skills add typesafe-ai/skills --skill typesafe-aiコミュニティ側の動きも速い。9月15日の発表スレッドは Hacker News で1,914ポイント・500コメントに達し、その後も派生プロジェクトが続いています。一次で確認できた代表例を2つ挙げます。
- OpenJev（現・SemIf） — 9月18日にHacker Newsへ投稿され、9月20日時点で693ポイント。ブラウザ内で完結する独立研究プロジェクトで、Qwen3 0.6B / MiniCPM5 2B / Qwen3.5 4B のいずれかを選び、「選択肢のロジットを直接読んで、与えた選択肢の範囲だけで正規化する方式」と「JSONテキストを生成させる方式」を同一モデルで比較できます。入力はページ外に出ないと明記。サイト自身が「TypeSafeとは無関係であり、権利侵害の意図はない」と断っています。Jevの仕組みを手元で体感するには分かりやすい教材です。
- typesafe-computer-use — awlevin氏によるMITライセンスのmacOS自動操作ツール。9月16日にHacker Newsへ投稿されました。画面をOCRで読み、次の操作の選択をJevのChoiceに任せる構成で、リポジトリは1ステップあたり約0.0002ドル（Claude Opus使用時の0.032ドルに対して約155分の1）と記載しています。同時に限界も明示しており、OCRはアイコンを検出できない、アクセシビリティツリーの網羅率はアプリ次第（Finder 100%、Slack 85%、Spotify 0%）、同じラベルが2つあると曖昧になる、キャプチャはメインディスプレイのみ、と書かれています。TypeSafe AI との公式提携関係はありません。
この2つが示しているのは、「判断だけを返す」というインターフェースが、モデルの重みそのものより先に広がりつつあるということです。Jevが非公開モデルである以上、同じ発想をオープンモデルのロジット読み出しで再現する動きは今後も増えるでしょう。
よくある質問
Jevは日本語で使えますか？
使えますが、精度は英語と同等ではありません。公式Modelsページは「英語が主要な訓練言語であり、現時点で最も精度が高い。CJKスクリプトを含む他言語も扱われるが、同等には扱われない」と明記し、非英語ワークロードでは自分のコンテンツでテストし、ルーティング時はConfidenceに特に注意するよう求めています。日本語で本番投入するなら、確信度の分布を自社データで確認してからしきい値を決めてください。
LLMの「Structured Outputs」と何が違いますか？
LLMの構造化出力は、モデルがJSON文字列を生成し、それをスキーマで制約する仕組みです。Jevは文字列を生成せず、選択肢上の確率分布をそのまま返します。公式ブログはこれを「フロンティア知能の関数呼び出し。非構造化の状態を入れ、型付きの確率的判断が出る」と表現しています。したがってパース処理が存在せず、返ってくる confidence は生成された数字ではなく分布から計算された統計量になります。
画像やPDFを判定させられますか？
できません。公式Modelsページは入力を「テキストのみ。文字列、JSONオブジェクト、またはテキスト値の配列。画像・音声・動画の入力は不可」と規定しています。非テキスト入力は、テキストまたは構造化フィールドへ前処理してから state として送る必要があります。公式ブログも、画像ベースの構造化stateは現時点で未対応だと述べています。
質問をたくさん入れるとレイテンシは伸びますか？
公式のSpeculative fan-outパターンは「すべての質問が並列に評価されるため、1回の呼び出しに質問を追加してもレスポンスにレイテンシが加わることは通常ない」と説明しています。ただしコンテキスト上限は別で、1リクエスト64kトークン、state＋最長の質問で32kトークンという制約があります。
レート制限に当たったらどうなりますか？
毎秒250,000トークンまたは毎分1,200リクエストを超えると 429 Too Many Requests が返ります。過負荷時は 529 Overloaded です。公式SDKは既定で指数バックオフのリトライを行い、retry-after ヘッダがあれば尊重します。HTTP APIを直接使う場合は自前でバックオフを実装してください。なお公式は、需要増に伴い上限を予告なく変更しうると明記しています。
ファインチューニングはできますか？
できません。公式Modelsページは「Jevは顧客データでファインチューニングもLoRA適応もされない。RLCDで訓練され、同じ重みがすべてのアカウントに提供される」と述べています。ドメインへの適合は、state に自社の資料やレコードを入れること、instructions と criteria にドメインルールと境界事例を書くこと、広い判断を原子的な質問へ分解してコードで合成すること、の3つで行います。
ここまでの要点
- Jevは2026年9月15日に早期提供が始まった判定専用モデル。
POST /v1/systemoneにstateと型付きquestionsを送り、Choice / Score / Noul の判断と確率が返る。文章は返らない。 - 置き換え対象は型が閉じている分岐——ルーティング、分類、しきい値判定、意味的なガードレール検査。文章生成・計算・日付比較・カウントは公式が明確に不得手としており、コード側の仕事として残す。
- 設計の骨は3つ。①判断を原子的な質問に分解し1リクエストに束ねる ②確信度のしきい値を行為の重さで変える（公式例は床0.6・高リスク0.85超）③低確信度と429/529の両方にフォールバックを用意する。
- コストと速度は桁違い。公式evalの4タスク平均でJevは0.0004ドル・0.4秒。同じ平均正答率67.8%のSonnet 5と比べてコスト約293分の1、時間約195分の1。
- 一方で正答率はOpus 5（73.1%）とsol（74.1%）に負け、Invoice Processingでは16ポイント以上の差がつく。ラベル自体がGPT-6 AstraとClaude Fable 5.1の平均で作られた自己採点ベンチマークである点も含め、自分のワークロードで測ってから決めるのが唯一の正解。
- 日本語は「扱えるが英語と同等ではない」と公式が明記。CJKで本番投入するなら確信度分布の事前確認は必須。
- 利用は公式サイトのウェイトリスト経由。レート上限は流動的で、本番のクリティカルパスに置くなら縮退経路を先に作る。
法人での導入判断・稟議の観点（契約条件、データの扱い、既存フローへの載せ替え）については、Jevとは｜TypeSafe AIの料金・仕様・使い方【2026年9月】（Uravation）で整理しています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
出典・参考
- TypeSafe AI「Introducing System One Models & Jev」（公式ブログ／2026年9月20日参照）— System One Modelの定義、RLCD、70〜500ms、料金、193.6倍・444.6倍の出典とその但し書き
- TypeSafe AI 公式docs「API reference」（2026年9月20日参照）— エンドポイント、リクエスト／レスポンスの全フィールド、エラーコード
- TypeSafe AI 公式docs「Models」（2026年9月20日参照）—
jev-1.13.0、料金、レート上限、コンテキスト上限、入力形式、言語サポート、ファインチューニング不可 - TypeSafe AI 公式docs「Jev 1.13 jaggedness」（2026年9月20日参照）— 11項目の弱点と公式の回避策
- TypeSafe AI 公式docs「Confidence」（2026年9月20日参照）— confidenceの定義、しきい値の考え方
- TypeSafe AI 公式docs「Confidence-gated routing」 / 「Speculative fan-out」（2026年9月20日参照）— しきい値0.6／0.85の例、並列評価の設計
- TypeSafe AI 公式docs「Quick start」（2026年9月20日参照）— cURL例、Python SDK例、Agent Skill導入コマンド
- TypeSafe AI「Workflow evals」（2026年9月20日参照）— 4ワークフローの正答率・コスト・時間、参照ラベルの生成方法
- gihyo.jp「TypeSafe AI、AIモデル『Jev』の早期提供を開始」（2026年9月20日参照）— 早期提供開始日、創業者の経歴
- Hacker News「OpenJev」 / OpenJev（現SemIf）（2026年9月20日参照）— ロジット直読みとJSON生成の比較、対象モデル、非提携の明記
- GitHub: awlevin/typesafe-computer-use（2026年9月20日参照）— 1ステップ約0.0002ドル、OCRとアクセシビリティツリーの限界
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
