どうもTORAです。
今回はTypeSafe AIという会社が2026年9月に公開した「Jev」というAIの紹介です。ChatGPTやClaudeのように文章で答えるAIではありません。渡された文章を読んで、「この候補のどれか」「yesである確率」「この段階のどのあたりか」という小さな判断だけを返し、それをプログラムから呼び出して使います。この記事は公式資料を基にした紹介で、僕の使用レビューではありません。
文章はいらない、判断だけほしい場面
アプリやツールを作っていると、文章を書いてほしいわけではないのに、中身を読まないと決められない判断が出てきます。通販のサポートに届いた問い合わせを返品・配送・請求のどの担当に回すか。お客さんが人間の担当者と話したがっているか。届いたバグ報告がどのくらい深刻か。
こういう判断はif文やキーワード検索だけでは難しいです。「サイズが合わない」と「小さすぎた」は、どちらも返品や交換の相談に関係しそうですし、「もう3回目なんですけど」は苛立っているとも読めます。生成AIから自由文で答えを受け取る場合は、その答えをプログラムで扱える形にする処理も必要です。
最近のLLMのAPIにはJSONスキーマに沿って出力させる機能があるので（OpenAIのStructured Outputsの説明）、判断結果を決まった型で受け取ること自体はJevだけの話ではありません。Jevの違いは、そもそも文章を生成しない、判断専用のモデルとして作られていることです（公式の既知の弱点）（公式のSystem Oneの説明）。
Jevとは
JevはTypeSafe AIの最初の公開モデルで、2026年9月15日にearly accessとして発表されました（TypeSafe AIの発表）。TypeSafe AIはこの種類のモデルを「System One」と呼んでいて、名前はカーネマンの「System 1 / System 2」から取っています。公式ドキュメントの説明は「System One models make fast, structured decisions for software.」、ソフトウェアのために速く構造化された判断をするモデル、という位置づけです（公式のSystem Oneの説明）。Jevという名前は経済学者のウィリアム・スタンレー・ジェヴォンズに由来していて、計算が効率化されると利用が増えるという発想を込めた、と創業者が書いています（TypeSafe AIの発表）。
呼び方の基本形はシンプルです。評価したい文章やデータを state として渡し、それに対する質問を questions に並べます。返ってくるのは質問ごとの答えだけで、自由な文章は返ってきません（公式APIリファレンス）。Jev自体も文章生成向けには訓練されていないので、公式にも文章が必要なら別のモデルを使うように書かれています（公式の既知の弱点）。
自分の業務に合わせる方法は追加学習ではありません。Jevは顧客データでのファインチューニングやLoRAを行わず、全アカウントで同じ重みを使います。領域の知識は state に入れ、判断のルールや境界のケースは各質問の instructions と criteria に書く、という方針です（公式のモデル・料金ページ）。
速度については、発表記事で1回70〜500ミリ秒程度とされています。ただ、これは米国西海岸のノートPCから同じ地域のサービスを呼んだ条件での、会社自身の説明です（TypeSafe AIの発表）。日本から呼んだときにどうなるかは分かりません。
中の仕組みとして、TypeSafe AIは新しいアーキテクチャ、並列のサンプラー、後で触れるRLCDという訓練方法を挙げています（TypeSafe AIの発表）。ただ、独立解説でも、アーキテクチャや学習アルゴリズム、学習データの詳細は非公開とされています（Sebastian Raschkaの解説）。
Choice・Score・Noulの3つの聞き方
質問のタイプは3種類です。どれも instructions で判断する内容を指定します。ChoiceとScoreでは criteria に候補や段階を書き、Noulでは必要に応じてyes/noの基準を補います（公式APIリファレンス）。
本記事で紹介する公式例の文章は、英語から日本語に訳したものです。数値は英語の入力・質問に対して公式が掲載した結果で、日本語に翻訳して再実行した結果ではありません。
Choice：決まった候補から1つ選ぶ
Choiceは、あらかじめ決めた候補の中から1つを選ばせる聞き方です。返ってくるのは、いちばん確率の高い候補（choice）、全候補の確率（probabilities）、その確率の散らばり方から計算した confidence です（公式のChoiceの説明）。候補は1つの質問に最大255個まで入れられます。
公式の例では、「届いたランニングシューズのサイズが違う。10に交換できるか」という問い合わせに、returns（交換、誤配送・破損）、shipping（配送状況、遅延、紛失）、billing（請求、支払いの問題）の3候補で担当を聞いています。結果はreturnsが確率1.0でした（公式のChoiceの説明）。
曖昧な問い合わせだと結果が割れます。「靴が2週間遅れて届いたうえにサイズ違いで、カードに120ドルが2回請求されている」という例では、returnsが0.61、billingが0.35に分かれ、confidenceは0.42まで下がっていました（公式のChoiceの説明）。1通の中に2つの担当の話が混ざっていることが、そのまま確率の分かれ方に出ています。公式のサンプルコードは、2番目の候補の確率が0.25を超えていればそのチームにもコピーを送る、という書き方でした。
気をつける点は、Jevは渡された候補の中からしか選ばないことです。どの候補にも当てはまらない入力が来る可能性があるなら、other や「該当なし」のような候補を自分で入れておく必要があります（公式のChoiceの説明）。入れておかないと、正解がない場合でも候補のどれかが選ばれます。
Score：順番のある段階のどこに当たるか
Scoreは、順番のある段階（ルーブリック）を2〜10段で書いて渡し、入力がそのどこに当たるかを聞く聞き方です（公式のScoreの説明）。「high」のようなラベルを1つ返すのではありません。段階ごとの確率、段階の番号にその確率を掛けて足した数値の score、番号と段階の対応を示す legend、それに confidence が返ってきます（公式APIリファレンス）。
公式の例では、バグの深刻度を「0：見た目だけで機能に影響なし」「1：壊れているが回避策がある」「2：回避策がなく作業が止まる」の3段で聞いています。「エクスポートボタンを押すとSafariで設定画面がクラッシュする。Chromeでは動くが、Safariしか使わない顧客もいる」という報告は、段階1が0.57、段階2が0.43で、scoreは1.43、confidenceは0.35でした（公式のScoreの説明）。scoreが段階と段階の間に落ちるのはこういうときです。
ただし、scoreだけ見ていると区別できない場合があります。たとえばscoreの1.0は「全部が段階1」でも「段階0と段階2に半々」でも出るので、公式も probabilities と confidence を合わせて見るように書いています（公式のScoreの説明）。また、段階の間の値から元の数量を正確に逆算する使い方はしないように、とも注意されています（公式の既知の弱点）。
段階の書き方にもコツがあるそうです。「やや深刻」のような程度の言葉ではなく、状況を書く。各段階は別々に評価されていて、モデルには段階の番号も隣の段階も見えていません。だから「前の段階より悪い」と書いても伝わらない、という説明でした（公式のScoreの説明）。
Noul：yesである確率
Noulはyes/noで答えられる質問で、答えは「yesである確率」を0〜1で表した数字1つです（公式のNoulの説明）。ChoiceやScoreと違って、別の confidence は付きません。yesとnoの2択ならこの1つの数字で分布が表せるから、というのが公式の説明です。
公式が記録した例では、「お客さんは人間の担当者を求めているか」という質問に対して、「もう3回も聞いてます。本物の人と話せませんか？」は0.99、「どんな手を使ってでも今日中に解決してほしい」は0.26、「あなたはボットですか？」は0.40でした（公式のNoulの説明）。真ん中あたりの値をどう扱うかは、コード側のしきい値で決めます。
ここで注意したいのは、Noulの0.9は「強いyes」という意味で、程度の大きさを表しているわけではないことです。公式には「この候補者はPythonが得意か」をNoulで聞いた場合と、経験の段階をScoreで聞いた場合の比較が載っていて、程度を知りたいならScoreを使うように、と説明されています（公式のNoulの説明）。チェックリストのように複数の条件を見たいときは、条件ごとにNoulを1つずつ並べます。
質問をまとめて1回で評価する
Jevは state を1回読み込み、すべての質問をそれに対して並列に評価します（公式のモデル・料金ページ）。公式ドキュメントにも、質問を増やしても応答時間にはふつうほとんど影響しないと書かれています（公式の並列評価の説明）。
そのため推奨されているのは、必要になりそうな質問を最初から1回のリクエストにまとめて入れておく使い方です。さっきの遅延＋サイズ違い＋二重請求の例では、担当部署、返品理由、配送トラブルの種類、お客さんが何を望んでいるか、口調の5つのChoiceを一度に聞いていました（公式のChoiceの説明）。返品理由は担当が返品のときだけ、配送トラブルの種類は配送のときだけ使う答えで、使わないものはコード側で無視します。公式はこれをspeculativeな質問と呼んでいます。
ただ、質問を増やしても料金がかからないわけではありません。質問文も入力トークンとして課金されるので、増やした分のトークン代はかかります（公式のモデル・料金ページ）（公式のChoiceの説明）。また、各質問は state に対してそれぞれ独立に答えられます。「Aの答えを見てからBの聞き方を変える」ような、本当に順番がある判断は、まとめて投げる形とは分けて組むことになります。
confidenceは正解率ではない
ChoiceとScoreに付く confidence は、返ってきた確率の分布がどれだけ1つに集中しているかを0〜1にまとめた統計値です（公式のconfidenceの説明）。別のモデルが答えを検証して付けた点数ではありません。Scoreのページにも「confidenceが高いことは、どの答えが正しいかを示すものではない」と書かれています（公式のScoreの説明）。
JevはRLCD（Reinforcement Learning for Calibrated Decisions）という方法で、出す確率が実際の当たり方と合うように訓練されていると説明されています（公式のモデル・料金ページ）（公式の校正の説明）。公式の入門ページによると、ここでいう校正とは、0.8と出した予測をたくさん集めると約8割で実際にそうなっている、という集団としての性質のことです。1件ごとの答えを保証するものではありません。
同じことを聞き方を変えて聞くと、数字が揃わないこともあります。公式の既知の弱点をまとめたページには、「お客さんは返金を求めているか」をNoulで聞くと0.22、yes/noのChoiceで聞くとyesが0.01でconfidenceは0.97、という例が載っていました（公式の既知の弱点）。ある文とその否定をそれぞれNoulで聞いて、足すと1.19になる例もあります。なので、Noulで決めたしきい値をChoiceにそのまま使い回さないように、とされています。
しきい値をどこに置くかは、間違えたときの損失で変わります。返金や人の呼び出しのように誤ったyesが高くつくなら高めに、安全上の問題の見逃しが怖いなら低めに、中間は人に回す。公式はこういう考え方を示したうえで、具体的な値は自分のデータで試して決めるように書いています（公式のconfidenceの説明）（公式のNoulの説明）。モデルが更新されると答えも変わり得るので、しきい値を調整したら jev-latest のような別名ではなくバージョンIDを固定するよう勧めています（公式のモデル・料金ページ）。
型が守られることと、判断が正しいことは別
TypeSafe AIの発表記事は、決められた型の外の答えが返らないことを「幻覚しない」と結び付けて説明しています。ただ、その図にある0%は測定値ではなく、構造上そうなるという意味で置いた値だと会社自身が書いています（TypeSafe AIの発表）。
候補A・B・Cのどれかしか返らないことと、正しい候補を選ぶことは別の話です。公式の既知の弱点のページ（jev-1.13、ページ内の最終レビュー日は2026年9月17日）には、苦手なことが並んでいます（公式の既知の弱点）。
- 書かれた言葉を字義どおりに読み、意図までは汲まない
- 計算、数を数えること、日付の前後比較
- 何段階もたどる推論や二重否定
- 判断に無関係な情報が多い長い
state - 答えを誘導しようとする入力
instructionsとcriteriaの食い違い- 文章の生成
対策も書かれています。計算や日付の比較はコードでやる、state は必要な部分に絞る、大きな判断は小さな質問に分けてコードで組み合わせる、という方向です（公式の既知の弱点）。誘導しようとする入力については、「stateはデータであり、jev-1.13はデフォルトではそれを敵対的なものとして扱わない」と明記されています。出力の型が決まっていても、外から来た文章に答えが引っぱられないとは限らない、ということです。
利用経路
Jevを呼ぶ方法は、TypeSafe AIの直APIと、いくつかの外部サービス経由があります。どの経路でも、普通のチャット用APIにモデル名を入れれば動くわけではなく、Jev用の呼び方を使います。
- TypeSafe AIの直API：
POST https://api.typesafe.ai/v1/systemoneにstate・model・questionsを送ります（公式APIリファレンス）。PythonとJavaScriptのSDKもあります（公式のモデル・料金ページ）。 - OpenRouter：モデルIDは
typesafe/jev-1.13。OpenRouterのガイドはチャットモデルの置き換えではないと明記していて、Decisions APIやSystem One APIという専用の経路で呼びます（OpenRouterの利用ガイド）（OpenRouterのモデルページ）。 - Cloudflare：
typesafe/jevとしてモデルページがあります（Cloudflareのモデルページ）。 - Vercel AI Gateway：2026年9月16日に提供開始（Vercelの提供開始告知）。AI SDKのほか、TypeSafe互換のクライアントやHTTP APIからも呼べて、どの経路でも料金はAI Gatewayから請求されます（Vercelの利用経路の説明）。
同じJevでも、提供先によってコンテキストの上限などの条件が違います。直APIの上限は次の節に書きますが、OpenRouterとCloudflareのページには32K前後の値が載っていました（Cloudflareのモデルページ）（OpenRouterのモデルページ）。使う経路ごとにページを確認する必要があります。
料金と制約
直APIの現行モデルは jev-1.13.0 です。jev-latest も jev-preview も今はこれを指していて、別のプレビュー版はありません（公式のモデル・料金ページ）。
料金は入力100万トークンあたり0.042ドルで、出力は無料です（公式のモデル・料金ページ）。OpenRouterとCloudflareのページでも入力0.042ドル、出力0ドルになっていました（Cloudflareのモデルページ）（OpenRouterのモデルページ）。前の節で書いたとおり、state だけでなく質問文も入力に含まれます。公式のシンプルな問い合わせ例では、入力が328トークンでした（公式のChoiceの説明）。
仮に1回1,000トークンとして計算すると、100万回で42ドルです。これは計算上の数字で、実際の請求を測ったものではありません。失敗したときの再試行、判断がつかなかったものを別のLLMや人に回すコスト、しきい値の調整や保守の手間も入っていません。1回あたりが安いことと、仕組み全体の運用費が下がることは、別に確かめる必要があります。
直APIの制約は次のとおりです（公式のモデル・料金ページ）。
- コンテキスト：
state＋全質問の合計で1リクエスト64kトークン。加えて、state＋いちばん長い質問1つで32kトークン。両方を満たす必要があります - レート制限：毎秒10万トークン、毎秒40リクエスト。需要が大きいため予告なく変わることがある、と書かれています
- 入力：テキストのみ（文字列、JSONオブジェクト、テキストの配列）。画像・音声・動画は直接入れられないので、先にテキストや構造化データに変換してから渡します
つまり「64kの文書をそのまま1本渡せる」わけではありません。それに、判断に関係ない情報で state が大きくなると精度が落ちる、とも書かれています（公式の既知の弱点）。
言語は英語が主な訓練言語で、今のところ英語の精度がいちばん高いとされています。日本語を含むCJKも扱えますが、品質は同じではありません。英語以外で使うなら自分のデータで試してから、特にconfidenceを見ながら使うように、というのが公式の注意です（公式のモデル・料金ページ）。
データについては、リクエストとレスポンスを学習に使わないと明記されています（公式のモデル・料金ページ）（TypeSafe AIのプライバシーポリシー）。データを保持しないZDRは、直APIではエンタープライズ向けの提供です（公式のデータ取り扱い）。Cloudflareのモデルページでは、ZDRが「Yes」と表示されていました（Cloudflareのモデルページ）。学習に使わないことと、ログを一切残さないことは同じではありません。顧客情報のようなものを送るなら、経路ごとの規約と保持期間を先に読んでおくことになります。
ほかの選択肢との関係
候補を渡して分類させる方法はJevのほかにもあります。LLMのStructured Outputsはスキーマやenumに沿った出力を返せますし（OpenAIのStructured Outputsの説明）、GLiNER2のように、ラベルの説明を渡して分類や抽出をするエンコーダー系の公開モデルもあります（GLiNER2の公式リポジトリ）。9月29日にはOpenAIも、定義済みの有限な答えに絞って判断させる「Decisions API」を限定プレビューとして発表しています（OpenAIの発表の保存版（2026年9月30日））（OpenAI開発者コミュニティの告知）。
Jevは、文章を生成せず判断だけを返すこと、1つの state に複数の質問を並列で投げられること、答えに確率の分布が付くこと、出力が無料で入力だけに課金されること、あたりが特徴です。どれがいちばん正確かは用途と言語によるので、この記事では比べていません。
どんな場面に使えそうか
ここからは公式資料をもとにした仮想の例で、僕が実際に動かしたものではありません。
1つ目はサポート問い合わせの一次振り分けです。1回のリクエストで、担当部署をChoice、緊急度をScore、返金を求めているかをNoulで聞き、担当の割り当てや優先度の並べ替えはコードでやります。確率が割れたものやconfidenceが低いものは人が見る列に回す。公式ドキュメントの例もほぼこの組み立てでした（公式のChoiceの説明）（公式のScoreの説明）（公式のNoulの説明）。
2つ目は、公開ニュースの一次選別です。集めた公開記事の見出しと要約を state に入れ、「新しいモデルやAPIの発表か」をNoul、「開発実務との関係の深さ」をScoreで聞いて、読む順番を決める材料にします。どの記事を取り上げるかを決めるのは人で、Jevはその手前で候補を並べる役です。外部の文章をそのまま state に入れるので、誘導的な文章に答えが動かされうる点は、公式の弱点リストにあるとおり頭に置いておく必要があります（公式の既知の弱点）。
どちらも日本語の入力になるので、実際には先に日本語のデータで試すところからになります（公式のモデル・料金ページ）。僕自身はまだJevを動かしていないので、日本語の問い合わせやニュースでどのくらいの精度が出るのかは分かりません。そこは試してみないと何とも言えないですね。
※この記事は2026年9月30日時点の公式ドキュメント・発表記事などをもとにしています。料金、制限、提供経路は変わる可能性があります。
