要点：Jevは『文章を正しいJSONへ整形する』より前に、判断の選択肢をcode側で閉じるAPIである

TypeSafe AIは2026年9月15日、最初のSystem One ModelとしてJevをearly accessで公開した。Jevへ渡すのは評価対象のstateと、Choice、Score、Noulという型付きquestionであり、返るのは自由な文章ではなく、選択肢・確率分布・必要に応じたconfidenceだ。中心的な違いは、LLMに『このschemaで答えて』と指示して生成文をparseするのではなく、applicationが判断の候補とrubricを先に定義し、その範囲のdecisionを受け取る点にある。

ただし、これはsemantic correctnessを自動で得る仕組みではない。TypeSafeがいう型安全性は、定義済みのoutput shapeから外れないことを指す。例えばrefundかtechnical supportかというChoiceが合法なkeyを返しても、そのticketを正しく読めているか、選択肢が業務上十分か、実行してよいactionかは別の検証対象である。Jevの導入判断は『JSON parse errorが減るか』だけでなく、判断を小さく分解し、間違いを止めるcodeを自分たちで持てるかで行いたい。

  • Fact：Jevはstateとtyped questionを受け、Choice・Score・Noulのanswerを返す
  • Fact：ChoiceとScoreには確率分布から導かれるconfidenceがあり、Noulはyesの確率を0から1で返す
  • Fact：公式documentationは、長い推論・数値計算・日付比較・生成には別の設計またはmodelを勧めている
  • Inference：Jevは万能LLMの代替ではなく、codeが所有する狭い判断を埋めるcomponentとして読むと境界を保ちやすい

何が起きたか：9月15日に公開、direct APIはearly accessとして提供

発表主体はTypeSafe AI、発表日は2026年9月15日である。公式発表はJevを同社初のpublic System One Modelとし、direct accessはearly accessとしてwaitlistから順に提供すると説明する。公開docsにはPOST /v1/systemone、model aliasのjev-latest、versioned IDのjev-1.13.0が記載されているが、これは誰でも無条件にkeyを発行できるという意味ではない。実際に利用できるmodel名はaccountのGET /v1/modelsで確認する仕様だ。

2026年9月19日に確認したModelsページでは、Jev 1.13の入力価格は100万input tokenあたり0.042米ドル、output tokenは無料、rate limitは毎秒25万tokenかつ毎分1,200 request、contextはrequestあたり64k tokenとされる。TypeSafe自身がrate limitは需要に応じて予告なく調整し得るとしているため、ここでの価格・上限は契約上の見積もりや永続的なSLAとして扱えない。

入力と出力：三つのdecision primitiveを一度に投げ、applicationが次のactionを決める

Choiceはcode側で定めた選択肢から一つを選び、各選択肢のprobabilityとconfidenceを返す。Scoreは順序付きrubric上の確率加重score、Noulはyes／noのうちyesである確率を返す。複数のquestionは同じstateに対して一つのrequestへ混在でき、公式documentationでは各questionをparallelかつindependentlyに評価すると説明する。Noulには別のconfidence fieldがないので、0.5に近い値や質問文の曖昧さをapplication側で扱う必要がある。

ここでいうstateは文章だけに限られず、string、JSON object、text valuesのarrayを渡せる。一方でJev 1.13のinputはtext-onlyであり、画像、音声、videoは事前にtextまたは構造化fieldへ変換する必要がある。選択肢やrubricをproviderのpromptへ隠すのでなく、review可能なapplication codeとして持てることは、routing ruleを変更・テストするsoftware teamにとって実務上の差になる。これは公式API shapeから導く編集部のInferenceである。

Jev、LLM structured output、一般的なclassifierを『契約と責任の位置』で比較
観点JevLLMのstructured output一般的なclassifier
applicationが定義するものChoiceの選択肢、Scoreのlevels、Noulの判定基準JSON schemaやfunction arguments通常は事前学習・実装済みのlabel set
主なresponsetyped decision、確率分布、Choice／Scoreのconfidenceschemaに沿うJSONまたはtool argumentlabel、score、確率などmodelごとの出力
防げる問題定義済みdecision primitiveのshape逸脱を防ぐというTypeSafeの設計parseしにくい自由文をschemaへ寄せる固定タスクのlabelingを高速化できる場合がある
なお残る責任意味の正しさ、選択肢の完全性、threshold、外部actionの承認schemaが合っていても内容が妥当かのvalidationtraining dataの適合、drift、class定義、校正の確認

従来LLMとの違い：structured outputは構文の契約、Jevはdecision contractだが、意味の保証ではない

LLMのJSON mode、schema constrained decoding、function callingも、applicationが扱いやすいshapeを得る有効な方法だ。だが一般にそれらはtext-generating modelの出力をschemaへ合わせる層であり、schemaが満たされたことと、値が正しいことは別である。Jevも後者を魔法のように解決するわけではない。ただしJevのofficial APIは、生成する文章をvalueへ変換するのではなく、最初からchoice、ordered score、yes probabilityというdecision operationをinterfaceにしている。

TypeSafeは『model never makes type errors』および『Zero Hallucinations』という表現を用いる。前者は公式発表で、possible outputとstructureがadvanceに定義されることに結び付けられたformalなclaimである。本稿ではこれを『schemaに合わないkeyや文字列を返さない設計』として扱い、引用・事実・policy判断が正しいというclaimへ広げない。後者のmarketing表現も、返答が自由文ではないこと、確率で不確実性を表すことの説明であって、誤分類ゼロや幻覚的な意味誤りゼロの独立検証ではない。

classifierとの比較では、Jevは事前に固定された一つのtaskへmodelを当てるだけでなく、applicationが毎requestのquestionとcriteriaを組み立てられる点が特徴になる。ただしその柔軟さは、criteriaの書き方が結果を左右する責任も意味する。Noulのtrue／falseが反転していたり、instructionsとcriteriaが矛盾したりすると性能が落ちることを、TypeSafe自身も既知のjaggednessとして挙げている。

速度・価格・calibration：公開数値はTypeSafeのworkflow評価と条件に限定して読む

公式発表はend-to-end latencyを70msから500ms、System One shaped queryで既存LLMより40倍から200倍速いと説明する。homepageの193.6倍高速、444.6倍安価という数値は、TypeSafeが公開した四つのworkflow evaluationに由来する。同社の説明では、workflowのcompute graphを固定し、最大級の外部LLM二種の平均predictionをreference probabilityとして比較した。評価は正解labelだけを当てるbenchmarkではなく、code内でprobabilityを使うworkflowへの一致を測る設計だ。

この測定は『どのLLMにも、どんなclassifierにも常にこれだけ速く安い』ことを示さない。発表自身も、公開workflowはmodel capabilities teamのメンバーが作ったためbiasがあり得ること、193.6倍／444.6倍はreal-world gainの高い側だと注記する。LLM側はTypeSafeのwrapperを通じて互換decisionを返す設定であり、自由文一回だけの生成、reasoningを厚くした回答、画像入力、長いcontext、network条件の違うsystemへそのまま外挿できない。独立した第三者benchmarkは本稿の調査で確認できていない。

calibrationについても、公式documentationはChoice／Scoreのprobability distributionから0から1のconfidenceを計算すると説明する。confidenceが高いほど実際のaccuracyが高いという発表の主張を、ここではproviderのmodel propertyとして紹介するにとどめる。自社workflowでは、holdout dataでconfidence bucketごとの正解率、false positive／false negativeのcost、reviewへ送る割合を測り、actionごとにthresholdを決める必要がある。これはRecommendationである。

誰に向くか：文章生成ではなく、狭い判断をcodeへ戻すworkflow

向くのは、support ticketのroute、RAG取得文書のrelevance判定、候補のrerank、policyに沿ったguardrail、抽出結果のreview queue振り分けのように、stateを読み、あらかじめ定義した少数のactionへ分岐するworkflowだ。特に『低confidenceなら人へ送る』『上位候補だけ次の高価なmodelへ渡す』のように、AIの出力を最終actionではなくrouting signalとして使う設計と相性がよい。TypeSafeのdocsはintent routing、confidence-gated routing、LLM input／outputのguardrailを例に挙げている。

向かないのは、利用者へ説明文・code・要約を生成する仕事、正確な算術、date/timeの比較、image／audio／videoを直接読む仕事、長い多段推論である。Jev 1.13の公式jaggednessはliteralな読み、count、numeric representation、関連しないlarge state、adversarial content、structural invariantを明示的な弱点としている。日本語を含むCJK textも処理はできるが、primary training languageの英語と同水準ではなく、自分のcontentで試すようModelsページは求める。

今できること：live APIを急がず、decision contractとoffline evaluationを先に作る

まず、既存workflowで『人が数秒で一つに答えられる狭い判断』を一つ選び、state、選択肢、definition of correct、誤るcostをfixtureとして固定する。Choiceにはotherまたはnone of the aboveを入れる余地を検討し、Scoreは数値の推定ではなく順序付きrubricとして設計する。そのうえで、high／medium／low confidenceごとにauto action、追加情報、human reviewをどう分けるかをcodeに書く。公式SDKの型推論は便利でも、policyとside effectの承認をSDKへ委ねないことが重要だ。

下のTypeScriptは公式JavaScript SDKのquickstartを基にした接続例であり、編集部ではAPI key、waitlist承認、課金を伴うlive callを実行していない。choiceの候補はapplicationが所有し、返った値をいきなりrefund実行へ接続せず、confidenceを使ってreview pathへ分ける例として読む。実装時にはmock responseを使ったunit test、代表的な日本語inputを含むholdout evaluation、timeout・429・provider障害時のfallbackを追加したい。

公式SDKを基にした未実行のTypeScript接続例
import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const result = await client.systemOne({
  state: { ticket: "二重請求された。至急返金してほしい。" },
  questions: {
    route: choice("この問い合わせをどこへ送るか", {
      billing: "請求、返金、支払いの問題",
      technical: "障害、bug、integrationの問題",
      other: "どちらにも明確には当てはまらない",
    }),
  },
});

const answer = result.answers.route;
if (answer.confidence < 0.8 || answer.choice === "other") {
  await queueForHumanReview();
} else {
  await routeTicket(answer.choice);
}

まだ分からないこと：early accessの実利用、privacyの細部、独立評価と日本語での精度

公開資料だけでは、waitlistの承認基準・所要時間、account／regionごとのavailability、実運用でのp50／p95 latency、rate limitの安定性、価格改定条件、特定taskでのcalibration error、誤分類率は確認できない。公開evaluationは興味深いが、外部のground truth benchmarkや第三者によるend-to-end再現を代替しない。導入判断では、providerの速度・価格表と、自社のqueue volume、review cost、error budgetを同じ条件で比較する必要がある。

data handlingについて、Modelsページとprivacy policyはcustomer request／responseをtrainingやfine-tuningに使わないとする。enterpriseにはzero data retention optionも案内されているが、一般の公開policyはdataをservice提供または事業目的に合理的に必要な期間保持すると記す。さらにserviceは米国でhostされるとされる。したがって『trainingしない』だけで機密dataの送信可否を決めず、retention、DPA、subprocessor、data transfer、ZDRの契約可否を個別に確認する。

次に確認する条件：GA、model version、価格・limit、evaluation、data termsが更新されたとき

次の確認条件は、Jevのgeneral availability、jev-latestが指すversion、early-access範囲、priceまたはrate limit、公開evaluationのdataset・第三者追試、Jev 1.13の既知制約、privacy／DPA／ZDR条件の更新である。特にproduction actionへつなぐteamは、model aliasの変更前後で同じfixtureを再評価し、thresholdとhuman review率を見直すべきだ。

現時点の結論はシンプルである。JevはLLMの出力を見栄えよく整形する代替品というより、applicationが定義したatomic decisionをprobability付きで返すための新しいAPI surfaceだ。条件がはまるworkflowでは、prompt parsingを減らし、低confidenceをreviewへ逃がす設計を取りやすい。一方で、型安全性、速度、calibrationというproviderの主張を、semantic accuracy、security、業務上の正しさへ短絡させず、code-owned policyと自社evaluationを残すことが採用の前提になる。