Jevとは｜文章を書かない判断モデルの仕組み・料金と、日本語で使う前に見る制約

この記事の要点

判断だけを取り出したい場合: Jev は state と型付きの質問を受け取り、Choice と Score は選んだ結果と確率分布 (confidence 付き)、Noul は 0 から 1 の単一の値を返す。文章は生成しない
LLM に JSON を出させる実装から移すか迷う場合: 公式は型エラーが起きないとする一方、較正は予測の集団に対して測るもので個々の答えの正しさは保証しないと明記
日本語のワークロードに入れる場合: 公式は英語を精度が最も良い言語とし、CJK を含む他言語は同等でないとして、頼る前に手元のコンテンツで試すよう書く
今すぐ触れるか確かめたい場合: TypeSafe 公式の直接提供は早期アクセスで、待機リストから順に案内すると書いている。OpenRouter は API 経由で使えるモデルとして案内 (当サイトでは未検証)

この結果が言える範囲: 2026年9月18日に公式ドキュメント・公式サイト・OpenRouter で確認した記載による。速度・単価・精度は掲載側の値で、当サイトでは実測していない。日本語の精度も日本から呼んだ応答時間も未測定。

Jev が返すもの — 文章ではなく型付きの判断
LLM に JSON を出させる方式と何が違うか
料金・レート制限・コンテキストの枠
触る経路 — Playground・API・SDK・エージェント skill
公式が挙げる苦手分野
日本語のワークロードで使う前に
速度と価格の数字は何を測った値か
どの処理を Jev に寄せられて、どれが手元に残るか
まとめ
よくある質問
参考資料

Jev が返すもの — 文章ではなく型付きの判断

Jev へ投げるのは、判断の材料になるテキスト (公式ドキュメントでは state と呼ぶ) と、型を決めた質問である。返ってくるのは型付きの値と確率分布で、文章は生成されない。TypeSafe AI が 2026年9月14日に発表したモデルで、同社が System One モデルと呼ぶ系列の最初の公開モデルにあたる。

質問は三つの型から選ぶ。三つを1回の API 呼び出しに混ぜてよく、各質問は同じ state に対して並列かつ独立に評価される。公式は、質問を増やしても応答時間はほとんど変わらないと説明している。

質問型	返る値	confidence
Choice	選択肢から1つを選んだ結果と、選択肢ごとの確率	付く
Score	段階評価の結果と、段階ごとの確率	付く
Noul	命題が真である度合いを表す 0 から 1 の単一の値 (Choice・Score の確率分布とは別の量)	付かない

confidence は、返ってきた確率分布から計算される統計量である。分布が一つの結果に集中していれば高く、平たければ低い。確率分布そのものは応答に含まれるため、公式は自前で別の指標を計算してもよいと書いている。

三つの型が返す 0 から 1 の数値は、同じ尺度ではない。Noul の値は Choice の確率と互換ではなく、ある質問とその否定の Noul を足しても 1 にならない (公式の掲載例では 0.72 と 0.47 で合計 1.19)。型をまたいで値を比べたり、同じしきい値を使い回したりはできない。

入力はテキストのみで、文字列・JSON オブジェクト・テキスト値の配列のいずれかで渡す。画像・音声・動画は受け付けない。それらを判断材料にするなら、テキストや構造化したフィールドへ前処理してから渡す。

公式サイトの FAQ が適する仕事として挙げているのは、内容の分類・要求の振り分け・応答の採点・情報の評価で、文章を作る処理は対象外になる。どこまで寄せられるかは後段で整理する。

LLM に JSON を出させる方式と何が違うか

公式サイトの FAQ は、構造化出力との違いを二段階で説明している。有効な JSON はソフトウェアが読める形式を与えるが、LLM をその形式に押し込むと持っている力の一部を取りこぼしうる、System One のモデルは最初から構造化された判断のために訓練されている、という組み立てである。

実装側から見える差は、出力の候補と構造を呼び出し前に定義する点にある。公式はこれを根拠に型エラーが起きないと説明し、ブログでは can’t hallucinate という表現を使っている。ただしこの表現が指しているのは、出力の型とスキーマが守られることであって、選ばれた答えの内容が事実として正しいことではない。公式自身、ハルシネーション率の比較図に置いた自社側の 0% について、実測ではなくスキーマ適合が保証されることから置いた値だと注記している。

内容の正しさは別の記述で扱われている。公式ドキュメントの System One のページは、較正 (calibration) は予測の集団に対して測るもので、個々の答えが正しいことを保証しないと明記している。型が守られることと、判断が当たっていることは、公式の記述の上でも別の保証にあたる。この区別は confidence の扱いにもそのまま当てはまり、閾値を上げても個々の答えの正しさが保証に変わるわけではない。

移行の判断材料としては、置き換えで消えるコストがどこに集中しているかが分かれ目になる。スキーマ違反のリトライや検証の作り込みに寄っているなら効果は型の側に出るが、判断の当たり外れの監視は方式を変えても残る。LLM 側でスキーマを守らせる作り込みの比較はLLMの構造化出力を安定させる実装で扱っている。

料金・レート制限・コンテキストの枠

料金と制限は公式 Models ページに一覧で載っている。2026年9月18日に確認した時点の記載は次のとおり。

項目	公式 Models ページの記載
課金対象	入力トークンのみ。出力トークンは無料と記載
価格	10億トークンあたり 42 ドル (100万トークンあたり 0.042 ドル)
レート制限	毎秒 250,000 トークン、毎分 1,200 リクエスト。超えると 429 が返る
コンテキスト	1リクエストで 64k トークン、state と最も長い質問の合計で 32k トークン (Primitives ページには state と質問が共有する予算を約 32,000 トークンとする記述が残る)
入力形式	テキストのみ (文字列・JSON オブジェクト・テキスト値の配列)
モデルID	jev-1.13.0。jev-latest と jev-preview が別名としてそこを指す

出力が無料という料金の形は、返るものが文章ではなく型付きの値と確率だという設計と対応している。ただし支払いがゼロになるわけではなく、state と質問の長さがそのまま入力トークンとして乗る。

レート制限の数値は固定ではない。公式は、上限が動的に調整されていること、大きな需要をさばいている状況で予告なく変わりうることを Models ページに明記している。上限の近くで回す構成にするなら、429 が返る前提の待避処理を組み込めるかどうかが条件になる。

コンテキストの上限は、公式ドキュメントの中で表現が揃っていない。Models ページは、1リクエスト全体で 64k トークン、state と最も長い質問の合計で 32k トークンという二つの枠を明示している。一方 Primitives ページには、1回のリクエストに入れられる質問数を決めるのは state と質問が共有する予算で、その予算は約 32,000 トークンだという記述が残っている。両ページに共通して出てくるのは 32,000 という数字で、違いはその予算が掛かる範囲の書き方にある (1リクエスト全体の 64k は Models ページにだけ出る)。質問を多く並べる設計では、Models ページの二つの枠を前提に置きつつ、実際の上限は手元の構成で確かめることになる。

モデルIDは jev-1.13.0 で、jev-latest と jev-preview はそこを指す別名である。jev-latest は直近の安定リリースを、jev-preview は公式リリースかどうかを問わない直近のビルドを指すため、preview ビルドが出ると jev-preview だけが先へ進む。confidence のしきい値を特定のバージョンに合わせて調整した場合は、別名ではなくバージョン付きのモデルIDを固定する運用を公式が勧めている。なお応答の model フィールドについては公式内で記述が一致しておらず、Models ページは答えたバージョンのIDが入ると書く一方、API リファレンスの応答例には別名の jev-latest がそのまま入っている。ログでバージョンを確実に押さえるなら、別名ではなくバージョン付きのIDを指定して呼ぶ。

判断を安いモデルへ逃がすという発想そのものは Jev に限らない。利用量の可視化と使い分けの基準はLLMのトークンコストを抑えるモデルルーティング｜利用量の可視化と使い分けの基準で扱っている。

触る経路 — Playground・API・SDK・エージェント skill

ブラウザで試す Playground と API キーの発行は、コンソール (console.typesafe.ai) に用意されている。

API の呼び出しは POST https://api.typesafe.ai/v1/systemone に対して行い、認証は Bearer トークン。state・model・questions を含む JSON を送ると、answers と usage を含む JSON が返る。

1回のリクエストに三つの質問型を混ぜた例 (公式クイックスタートの構造に沿う)。

{
  "state": "3日前から決済連携が失敗していて、売上が止まっています。至急お願いします。",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "どのチームが担当するか",
      "criteria": {
        "billing": "支払い・契約に関する問い合わせ",
        "technical": "不具合や連携の問題",
        "sales": "価格やアカウントの相談"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "書き手の苛立ちの程度",
      "criteria": ["落ち着いて事実を述べている", "苛立っているが穏当", "強い言葉を使っている"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "この文面は緊急性を伝えている"
    }
  }
}

Python SDK は pip install typesafe-sdk で入り、Python 3.10 以上を要求する。JavaScript SDK も提供されている。SDK は環境変数 TYPESAFE_API_KEY を読み、既定では jev-latest を呼ぶ。バージョンを固定するという公式の勧めに沿うなら、SDK 側でもこの既定を明示的に上書きする。コーディングエージェント向けの skill も公式から配布されており、Claude Code ではプラグインとして、他のエージェントでは npx skills 経由で導入する手順が案内されている。

TypeSafe 公式からの直接提供は早期アクセスである。公式ブログは発表日に早期アクセスを開き、待機リストから順に案内すると書いている。2026年9月18日に確認した時点では、公式トップページに待機リストへの導線があり、API キーの発行と Playground の入口はコンソール側に置かれていた。以後の受け入れ状況は変わりうる。

公式の待機リストとは別に、OpenRouter のモデルページにも掲載がある。2026年9月18日に確認した時点で typesafe/jev-1.13 が載っており、入力 100万トークンあたり 0.042 ドル・出力 0 ドル、コンテキスト 32K、提供者は TypeSafe 一社と表示されていた。これは OpenRouter の掲載内容であって、TypeSafe 公式の記載ではない。OpenRouter 側は API 経由で利用できるモデルとして案内している。ただし当サイトでは実際の API 呼び出しまでは検証していない。コンテキストについても、公式 Models ページは、1リクエスト全体の 64k と、state と最も長い質問の合計に掛かる 32k という二つの枠を示している。OpenRouter に出ている 32K は後者と同じ数字だが、OpenRouter 側がどちらの枠を指して表示しているかは示されていない。ゲートウェイ側でモデルを束ねる構成の比較はAI Gateway比較｜LiteLLM・OpenRouter・Portkey・Cloudflare・Bifrostを一次ソースで検証にある。

公式が挙げる苦手分野

公式ドキュメントには、モデルが苦手とする領域を列挙したページがある。対象は jev-1.13 に限定され、最終レビュー日は 2026年9月17日と記されている。バージョンが上がれば内容が変わる前提で公開されており、多くの項目には後のバージョンで直すという趣旨が添えられている。

領域	公式の記述	公式が示す扱い方
字義どおりの読み	書いたとおりの質問に答える。限定語や否定、言外の条件は補われない	境界の条件を instructions と criteria に書き切る
数える処理	文字数・語の出現回数・長いリストの項目数は信頼できない。対象が大きくなるほど誤差が広がる	数えるのはコード側で行い、モデルには1件ごとの判定だけを任せる
数値の表現	数値表現より意味を持つ表現のほうを得意とする。二つの数値が近いかどうかの判断も不得手	色は数値の表記より色名で渡す。Score の期待値から二つの段階の間の実数を復元する使い方は避ける
日付	順序を持つ量ではなく文字列として読む。前後関係・日数の差・期間に入るかの判定は不安定	日付の要素を Choice で抜き出し、コード側で組み立てる
多段の指示と余分な state	二重否定や、属性の属性を問うような何段も辿る指示は精度が落ちる。判断と関係のない情報が state に増えるほど精度が下がる	絞り込みをコード側で先に行い、質問を平たくする
state の扱い	state はデータであり、既定で敵対的なものとしては扱われない	埋め込まれた指示や誘導的な文章が答えを動かしうる前提で組む (今後改善する見込みと付記)
instructions と criteria の食い違い	両者が別のことを求めていると結果が乱れる。真を no に、偽を yes に対応付けるような書き方は成績が落ちる	指示と基準の向く先をそろえる
構造的な関係	成り立ちそうに見える関係は保証されない。Noul と Choice の値は互換でなく、ある質問とその否定の Noul を足しても 1 にならない	否定形の質問の Noul を補数として使わない。Noul と Choice の値を同じしきい値で比べない (掲載例では 0.72 と 0.47 で合計 1.19)
文章の生成	文章を生成するようには訓練されていない。選択肢を連ねて無理にやらせることはできるが、うまく動かず非常に遅くなる	値を取り出すなら、候補を正規表現や生成モデルで先に作り、そこから選ばせる

state が既定で敵対的なものとして扱われないという記述は、判断材料を外部から受け取る構成で意味が変わる。問い合わせ本文やレビュー投稿をそのまま state へ入れる場合、文中に埋め込まれた指示や、投稿者に有利な分類へ誘導するように書かれた文章が答えを動かしうる。公式はこの点を今後改善する見込みと付記している。

日本語のワークロードで使う前に

公式 Models ページは、英語が主要な訓練言語であり、精度も現時点では英語が最も良いと記している。CJK を含む他の言語も扱えるが同等ではないとされ、非英語のワークロードで頼る前に手元のコンテンツで試すこと、経路を分けるときは confidence をよく見ることが併記されている。

日本語での精度は本記事では測定していない。この記事から言えるのは、英語が最も精度が良いと公式が書いていること、非英語では手元のコンテンツで試すよう公式が求めていること、この二つまでである。

その「試す」の組み立てについては、公式 Confidence ページが confidence の値で処理を三段階に振り分ける運用を出発点として示している。高ければ自動で処理し、中ほどなら確認や情報の追加を挟み、低ければ人へ回すか別の仕組みへ落とす。境界の値は、誤った場合の影響の大きさで変える。示されている値は例であり、適切なしきい値は用途とデータ次第だと明記されている。保守的な値から始め、手元のデータで試して調整するという順序も書かれている。なお confidence が付くのは Choice と Score で、Noul には付かない。しかも Noul にはこの三段階をそのまま移せない。Noul が返すのは確信の度合いではなく命題が真である度合いで、0 に近い値は「確信が低い」ではなく「偽に寄っている」を意味するからである。Noul で経路を分けるなら、高い側と低い側をそれぞれ判断として扱い、中ほどを確認へ回すという別の組み立てになる。本記事で確認した範囲では、公式は Noul 向けの振り分け方を示していない。

この段階の区切り方と、英語が最も精度が良いという記述は同じところを指す。日本語の入力で経路を分けるなら、同じ confidence の値が英語のときと同じ正答率に対応するとは限らないという前提でしきい値を置くことになる。各段階に入る件数がそろうように境界をずらすだけでは足りず、手元のデータで confidence ごとの当たり外れを数えるところからになる。confidence は確率分布から計算される統計量なので、区切り方が合わないときは、分布そのものから別の指標を作る余地も公式は認めている。

速度と価格の数字は何を測った値か

公開されている数字には、公式自身が条件を添えている。数字とその条件の対応は次のとおり。

数字	公式が示す出どころ	同時に書かれている条件
70ミリ秒〜500ミリ秒	端から端までの応答時間として公式ブログに記載	米西海岸にある自社のノートPCからの実行として公式が公開した値。サービスの拠点も同じ地域と記載されており、日本から呼んだ場合の値ではない
40倍〜200倍速い	System One 型のクエリで、同等の知能水準に対しての比	同じ実行環境の注記が掛かる。呼び出し元と拠点の距離が応答時間に与える影響は本記事では測っていない
193.6倍速い・444.6倍安い	トップページに載る数字で、ワークフロー評価から出たもの	公式自身が、現実の利得としては高い側にあたると考えていると書いている
ワークフロー評価の参照値	正解ラベルの代わりに GPT-6 Astra と Fable 5.1 の予測の平均を置き、全モデルに同じワークフローを通す方式	この作り方が OpenAI と Anthropic のモデル寄りに働くこと、ワークフロー自体が自社チームの手で作られたため偏りがありうることを注記
比較対象の LLM の値	自社のラッパーを通し、構造化された判断を出す形に制約した状態での測定	この方式は確率を伴わない出し方より遅く高価になりやすいと公式が書いている
ハルシネーションと型エラーの比較図	LLM 側の数値は OpenRouter 由来	バイアスがほぼ確実に含まれると公式が注記している
価格の水準	入力のみの課金で、100万トークンあたり 0.042 ドル	補助されたものでないことは証明できず、持続性は長期で示す必要があると公式が書いている。公式の見通しとしては下がる方向とされる

この並びでは、193.6倍・444.6倍はワークフロー評価由来の比で、「同じ判断を LLM に構造化出力で出させた場合」との比較にあたる。40倍〜200倍のほうは、同じ場所に添えられているのが実行環境の注記までで、比較相手をどう動かしたかは示されていない。参照値の作り方も、ワークフローの選び方も公式側にある。数字を手元のワークロードへ持ち込むなら、同じ判断を現在どの経路で出しているか、その経路の応答時間と単価を測るところが起点になる。日本のサーバーや手元の環境から呼ぶ構成なら、70ミリ秒〜500ミリ秒をそのまま前提には置けない。

どの処理を Jev に寄せられて、どれが手元に残るか

公式サイトの FAQ は、適する仕事として内容の分類、要求の振り分け、応答の採点、情報の評価を挙げている。一方で、数学やチェスのような筋道を立てる計画が要る仕事は大きな推論モデルのほうが適する場合があるとも書かれている。jaggedness ページが文章の生成を適さない用途として挙げていることと合わせると、置き換えの対象になるのは、文章を作る必要がなく、筋道を立てる推論も要らず、公式が苦手分野として挙げている計数・日付の演算・数値どうしの比較・多段の指示にも当たらない判断の部分にとどまる。

質問の粒度についても記述がある。長い推論を要するもの、独立した複数の要因を天秤にかけるものは、一つの質問に詰めずに分解する。要素ごとに聞き、重み付けはコード側で行う形が示されている。苦手分野の一覧にある「数えるのはコード側」「日付の組み立てはコード側」も同じ方針の延長にある。

ドメインへの適応の手段は三つに限られている。顧客ごとの追加学習は行われず、全アカウントが同じ重みを使う (公式は顧客データでのファインチューニングや LoRA 適応を行わないと記載している)。適応は、state に材料を入れること、質問の instructions と criteria に規則と境界事例を書くこと、判断を分解してコード側で合成すること、この三つで行うと公式は書いている。

データの扱いについては、顧客のリクエストとレスポンスを学習に使わないという記載が Models ページにある。データ処理契約やゼロデータ保持の扱いは Legal ページに置かれ、ゼロデータ保持は enterprise 向けとされている。

まとめ

型が守られることと判断が当たっていることは別の保証で、較正は予測の集団に対して測るものだと公式が明記している。方式を移しても、監視の対象がスキーマ違反から判断の当たり外れへ移るだけで消えはしない
公式が精度の最も良い言語として挙げているのは英語で、CJK を含む他の言語は同等ではないとされる。日本語のワークロードでは、手元のコンテンツで試し、confidence ごとの当たり外れを数える段階が前に挟まる
193.6倍速い・444.6倍安いという比は、公式自身が現実の利得としては高い側だと書いているワークフロー評価の値で、参照値も比較相手の動かし方も公式側の設計による
置き換えの候補になるのは、生成が要らない分類・振り分けのうち、計数・日付の演算・数値どうしの比較・多段の指示という公式が挙げる苦手分野に当たらないものに限られる。移して得があるかは、スキーマ違反のリトライや検証の作り込みが今どれだけコストを占めているかによる。まず同じ判断を出している現在の経路の応答時間と単価を測り、日本語で使うなら手元のデータで confidence ごとの当たり外れを数えるところからになる

よくある質問

いま試すには何が要るのか

TypeSafe 公式からの直接提供は早期アクセスで、公式ブログは待機リストから順に案内すると書いている。2026年9月18日に確認した時点では、公式トップページに待機リストへの導線があり、Playground と API キー発行の入口はコンソール (console.typesafe.ai) 側に置かれていた。案内を受けていない状態でコンソールのどこまでが使えるかは本記事では確認していない。案内を受けたあとは、Playground を触るか、API キーを発行して POST https://api.typesafe.ai/v1/systemone を呼ぶ形になる。別経路として、OpenRouter が API 経由で利用できるモデルとして案内している。ただし当サイトでは実際の呼び出しまでは検証していない。

ハルシネーションしない、という説明はどこまでを指すのか

公式ブログの can’t hallucinate という表現が指すのは、出力の候補と構造を事前に定義するため型とスキーマが守られることである。選ばれた答えの内容が事実として正しいかどうかは別で、公式もハルシネーション率の比較図に置いた自社側の 0% について、実測ではなくスキーマ適合が保証されることから置いた値だと注記している。

同じ入力を投げれば必ず同じ答えが返るのか

公式サイトの FAQ は、同じ入力に同じ結果を返すこと (決定性) より、意味が近い入力に近い判断を返すこと (一貫性) のほうを設計目標に置いていると説明している。

既存の LLM を置き換えるものなのか

公式サイトの FAQ が適する仕事として挙げているのは、内容の分類・要求の振り分け・応答の採点・情報の評価である。数学やチェスのような筋道を立てる計画が要る仕事は大きな推論モデルのほうが適する場合がある、とも書かれている。切り出せるのは、文章の生成に加えて計数・日付の演算・数値どうしの比較・多段の指示といった苦手分野にも当たらない判断の部分にとどまる。生成が必要な処理は既存の LLM 側に残る。