「請求書を再発行してほしい」「ログインできない」「振込先の口座を変更したい」。問い合わせをAIで処理するとき、毎回長い返答を生成させる必要はありません。まず知りたいのは、どの担当へ回すか、手続きを伴う依頼か、判断を保留すべきかです。
TypeSafe AIが2026年9月15日に発表した Jev は、こうした限定された判断をソフトウェアへ返すモデルです。同社はこのモデル群を System One Models と呼び、判断の確率を適切に表すための学習方法としてRLCD（Reinforcement Learning for Calibrated Decisions）を掲げています。公式発表
開発者として注目したいのは、分類結果だけでなく確率分布を受け取り、その後の処理を普通のコードで組める点です。一方、型の保証、判断の正しさ、実行してよい権限はそれぞれ別に扱う必要があります。
この記事では問い合わせの振り分けを題材に、その境界を具体化します。
確認日: 2026年9月25日。仕様は公式資料、性能数値は提供者または第三者の公開報告に基づきます。筆者が実行したのは添付サンプルのローカル分岐検証です。実APIでの日本語精度・遅延・料金は測定していません。本文の問い合わせと模擬応答は説明用に作成したものです。
Jevには「状態」と「質問」を渡す
JevのAPIには、判断材料となる state と、何を判断するかを記述した questions を渡します。返るのは質問ごとの値や確率です。質問を複数まとめると、同じ状態に対して独立に並列評価されます。公式Introduction
たとえば、問い合わせ本文を状態として渡し、「担当部署はどこか」「口座変更などの手続きが必要か」を同時に聞きます。
問い合わせ本文
↓ state + questions
Jev: 担当部署の候補 / 手続き要求の確率
↓
アプリのコード: 保留条件・権限・既存ルールを確認
↓
担当先の候補を表示、または人間の確認へ回すこの構成なら、問い合わせを読む判断にはモデルを使い、通知先の決定や操作権限の確認はコードへ残せます。Jevへ「問い合わせ対応を全部完了して」と頼むより、モデルに渡す仕事とアプリの責任が明確になります。
2026年9月25日時点の公式モデルは jev-1.13.0 です。入力はテキスト、またはテキストを含むJSONで、画像・音声をそのまま渡すモデルではありません。比較を再現したい場合は、jev-1.13.0 のようにバージョンを指定し、応答の model も記録します。jev-latest の参照先は更新されるため、比較時の条件を追えるようにしておきます。Models
Choice・Score・Noulの使い分け
Jevには3種類の質問があります。用途に合わせて、必要な答えの形を選びます。
| 質問 | 問い合わせでの使い方 | 返る値 |
|---|---|---|
| Choice | 請求・技術・その他から担当を選ぶ | 選択肢、選択肢ごとの確率、confidence |
| Score | 対応の緊急度を説明付きの段階で評価する | スコア、段階ごとの確率、confidence |
| Noul | 口座情報の変更を求めているかを聞く | Yesである確率を0〜1で返す |
Choice は候補の集合から選びます。公式上限は255選択肢です。「その他」「情報不足」を表す候補がないと、どれも当てはまらない入力にも既存候補から答えを選ばせることになります。Choice
Score は2〜10段階の説明を渡します。たとえば「通常対応」「業務の一部が停止」「業務全体が停止」です。返るスコアは段階番号の確率加重平均なので、小数になり得ます。score = 1.6 は段階上の評価値であり、「緊急である確率が160%」という意味ではありません。Score
Noul は一つの命題がYesである確率です。「顧客が怒っているか」と「怒りの程度はどれくらいか」では質問が違います。前者ならNoul、段階ごとの程度を扱いたいならScoreが候補になります。Noul
複数の質問を一度に送れても、ある質問の回答を別の質問が読むわけではありません。担当部署を選んだ結果によって次の質問が変わる処理は、コードで回答を組み合わせるか、必要に応じて次のAPI呼び出しへ分けます。
LLMのStructured Outputsとの違い
「JSONを返せること」だけなら、既存LLMでもできます。OpenAIのStructured Outputsも、対応するスキーマへの適合を保証する仕組みです。拒否や未完了を処理する必要があり、スキーマに沿った値でも意味的に間違うことはあります。OpenAI公式ドキュメント
したがって、「LLMは型を守れないがJevは守れる」という比較では不十分です。比較するなら、次の点を見ます。
| 観点 | LLM＋構造化出力 | Jev |
|---|---|---|
| 欲しい成果物 | 説明文や自由な文字列を含む構造化データ | 定義した候補・段階・命題に対する判断 |
| 確率の扱い | 使うAPIと実装によって異なる。自己申告の自信は別途評価が必要 | 判断の確率がAPIの基本的な返却値 |
| 複数の判断 | モデル・プロンプト・呼び出し方で設計 | 同じ状態への質問を独立に並列評価 |
| 得意な仕事の見極め | 文章生成や推論を含めて評価 | 狭い判断を繰り返す処理で評価 |
Jev側の位置づけは、同社のSystem Oneの説明に基づきます。RLCDや並列出力による性能上の利点は、設計の説明と、自分の用途で得られる結果を分けて読む必要があります。
速度については、出力する仕事そのものの違いがポイントです。同社は、LLMがトークンを順番に生成するのに対し、Jevは定義された判断の確率を並列に出力すると説明しています。説明文やコードを書かせる自由度を持たせず、必要な判断に出力を絞る設計です。入力の処理や通信時間までなくなるわけではないため、実際の待ち時間は別途確認します。公式発表のSampling比較
たとえば問い合わせの返信文まで作りたいなら、Jevで担当候補を選び、文章生成はLLMへ渡す構成が考えられます。分類だけで済む処理にまで生成モデルを使う必要があるかを見直せることが、Jevを検討する入口です。
「ハルシネーションゼロ」とconfidenceを読み違えない
公式発表では「ハルシネーションゼロ」が強調されています。ただし、その根拠として書かれているのは、出力のスキーマ一致を保証するため、公式発表のグラフでハルシネーション率を0%と示した、という説明です。あらゆる判断の正答率を測って100%だったという話ではありません。公式発表のHallucination and Type-safety節
候補が billing、technical、other なら、候補外の部署名を生成しないことと、請求の相談を正しく billing に分類することは別です。返す値を限定しても、間違った候補を選ぶ可能性は残ります。
また、confidence を「この回答が正しい確率」として読まないことも大切です。公式資料では、ChoiceとScoreの確率分布がどれだけ一つの結果に集中しているかを、0〜1にまとめた統計と説明されています。最大の選択肢確率そのものでもありません。Noulには別の confidence フィールドはありません。Confidence
確率の「校正」がよいとは、たとえば0.8程度の確率を付けた判断を多数集めると、実際に正しい割合もそれに近い、という対応です。一つの回答を保証する仕組みではなく、どのデータや条件で対応が成り立つかを確かめる対象です。
「分からない」を選べるようにする
以下の例では、担当先を決める材料が足りない問い合わせも扱えるように、other に対象外・情報不足・複数部署で判断が割れる場合を含めます。これはサンプルで採用する分岐設計です。other に分類されたら担当先を自動決定せず、人間確認へ回します。
Pythonで問い合わせの振り分けを組み立てる
実装例はjev-ticket-routing.pyとしてダウンロードできます。Python 3.10以上の標準ライブラリだけで動作します。通常実行では外部通信せず、模擬応答を使って分岐を確かめます。
python3 jev-ticket-routing.pyAPIへ送るのは、問い合わせ本文と2問です。次はリクエストの構成を示す説明用のJSONです。本文中の問い合わせは架空で、実顧客の情報ではありません。
{
"model": "jev-1.13.0",
"state": "今月の請求書にある消費税欄の意味を教えてください。",
"questions": {
"department": {
"type": "choice",
"instructions": "この問い合わせの主な担当部門はどれですか。",
"criteria": {
"billing": "料金、請求書、支払いに関する問い合わせ。",
"technical": "不具合、障害、API連携に関する問い合わせ。",
"other": "上記以外、複数部門で決められない、または情報不足。"
}
},
"needs_account_action": {
"type": "noul",
"instructions": "口座・契約・請求などの利用者記録を変更する操作を求めていますか。",
"criteria": {
"true": "口座変更、契約変更、返金などの操作を依頼している。",
"false": "説明や不具合調査のみを求め、記録の変更は依頼していない。"
}
}
}
}公式HTTP APIは POST https://api.typesafe.ai/v1/systemone です。Bearer認証でAPIキーを渡し、応答の answers から質問IDごとの結果を読みます。Quick start
この2問で十分に安全性を判定できる、という意味ではありません。担当先の候補表示を題材に、判断を小さく分けるための例です。返金の実行や口座変更の可否は、このモデル出力で許可しません。
返ってきた値をコードで扱う
サンプルでは、応答の形や確率の範囲を確認したうえで、次の条件を適用します。
otherが選ばれたら、人間確認。- 手続き要求の確率が0.1以上なら、人間確認。
- 選ばれた担当の確率が0.9未満なら、人間確認。
- それ以外は担当先の候補を表示。
0.1と0.9は分岐を説明するための仮の閾値で、本番用の推奨値ではありません。 confidence を正答率として使うこともしていません。実際には、見逃しと確認工数のどちらをどこまで許容できるかを決めてから、評価データで閾値を選びます。
APIが失敗した場合や必要な値が欠けている場合も、人間確認として扱います。添付例が行うのは候補の表示だけで、チケットの更新、メール送信、支払情報の変更は行いません。
ローカルで確かめられること
模擬応答では、明確な分類、判断が割れる分類、対象外、手続き要求、応答の欠落、不正な確率、通信失敗などを確認できます。さらに、APIの500エラーについての問い合わせに対して、高い確率で billing を返す模擬応答も用意しています。
この最後のケースは、型も確率の形式も正しく、閾値を満たすため、誤った担当先が候補として表示されます。意図的に通過させることで、分岐の実装が正しくても、モデルの意味的な誤答をそれだけでは検出できないことを確かめます。
ローカル実行結果の抜粋です。これもJevの回答結果ではなく、用意した模擬応答に対するコードの動作です。
曖昧: 支払い画面が進みません。 => human_review / 担当部門の確率が閾値未満
高確率の意味的誤答: APIが500エラーを返します。 => billing / 担当候補のみ（操作は実行しない）
分岐確認: 11/11 一致。高確率の意味的誤答もbillingとして通過しました。ここで確認できるのはアプリ側の動作です。Jevが日本語の問い合わせを正しく読めるか、高い確率を返すときにどの程度正しいかは、別途実APIで測る必要があります。
APIを使える状態になったら、環境変数 TYPESAFE_API_KEY を設定し、明示的に次を実行します。実際のAPI呼び出しには利用料金が発生し得ます。
python3 jev-ticket-routing.py --live添付例の --live は架空の問い合わせを1回送信し、タイムアウトを設定しています。比較実験では、入力・質問・モデル版を保存して、何を変えたために結果が変わったのか追えるようにしてください。
速度と価格は、比較した処理まで確認する
公式が掲げる「193.6倍高速・444.6倍安価」は、同社のワークフロー評価に由来する値です。同社自身が実運用での改善幅の上側と説明しており、あらゆるモデルや処理に対する倍率ではありません。公式発表のWorkflow evals節
公式評価サイトでは4種類のワークフローを扱い、高性能モデルの回答から作った参照確率と比較しています。人手で確定した正解に対する正答率とは指標が異なります。また、LLM側も公開アダプターで確率を含む判断を返す構成です。自分が比較したい「ラベルを一つだけ返す小型LLM」と同条件かは確認が必要です。
独立した分類ベンチマークにも参考例があります。dhruvmehraの jevbench は、OpenRouter経由で typesafe/jev-1.13 とLLMを比較し、SST-2の500件でJevの正答率95.4%、遅延中央値376msを報告しています。同じ表のClaude Sonnet 5は95.6%、2,076msです。2026年9月22日の結果表
この条件では速度差が見えますが、正答率の0.2ポイント差は500件中1件です。この数字で精度の優劣を断定するのは避けたいところです。英語の既存データセットでの第三者報告であり、本記事で再測定した値でも、日本語対応の証拠でもありません。
料金は、公式のモデル表では入力100万トークンあたり 0.042米ドル、出力トークンは無料です。たとえば課金対象の入力が合計1,000万トークンなら、単純計算は0.42米ドルになります。これは料金表からの計算例であり、実請求の測定ではありません。Modelsの料金表
入力には本文だけでなく質問や候補の記述も含まれるため、1件の費用は実際の usage で確認します。前処理、再試行、後段のLLM、人間確認まで含めた費用も別にあります。入力単価が安いことと、業務全体がその割合で安くなることは同じではありません。
最初に試すなら、狭い判断を一つ選ぶ
このAPIの形から、問い合わせの担当候補、検索候補の関連度、複数モデルへの振り分けなどは、最初の評価対象にしやすいと考えます。いずれも候補や判断基準を先に定義でき、誤りを人間が確認できる処理です。
一方、現在の公式資料には、計数・数値計算・日時比較、複雑な間接参照、無関係な情報の多い入力、敵対的な入力などの弱点が記載されています。金額の計算や期限判定はコードで行い、プロンプトインジェクションの検査に使う場合も、Jevだけを防御の根拠にしない方がよいでしょう。Jev 1.13の既知の弱点
日本語で使う場合は、もう一つ確認が必要です。公式には英語が主な学習言語で精度も最良、CJKを含む他言語は同等ではないと明記されています。日本語を受け付けることだけでは、日本語の実務へ導入する根拠になりません。Modelsの言語対応
問い合わせの振り分けなら、最初の評価を次のように組みます。
- 実務に近い日本語へ正解を付ける。 一つの部署で完結する例に加え、複数の依頼、情報不足、対象外、否定表現、本文内の指示を混ぜる。評価用データには実顧客の秘密情報を持ち込まない。
- 閾値を決めるデータと最終評価のデータを分ける。 同じ例を見ながら質問を直し続け、その結果を未知の入力への性能として報告しない。
- 候補表示率と、その中の誤分類率を一緒に見る。 全件を保留すれば誤った自動振り分けは減るが、業務上の価値も分からなくなる。手続き要求の見逃しは別に数える。
- 同じ入力・同じ出力要件で比較する。 既存ルールや小型LLMを比較対象に含め、モデル版、質問、実行地域、同時実行数、再試行、p50/p95遅延、実費用を記録する。
分類値をツール実行へ接続する段階では、操作対象・権限・承認条件を別に定義します。この部分はAIエージェントのtool schema設計で扱っています。作業全体の成果物や検証結果をどう返すかは、AIエージェントの出力契約設計の領域です。
Jevを試すなら、まず既存処理の「文章の意味を読んで担当候補を選ぶ」箇所を一つ置き換え、候補表示まで動かしてみるのがよいと思います。そこで日本語の誤分類と保留の割合を測れば、速度や単価の魅力が自分の処理でも役立つかを判断できます。