はじめに

これは Jev を触って調べる全4回の第1回です。

2026年9月15日、TypeSafe AI は Jev の Early Access 開始を公開アナウンスしました。公式発表は同日付で、Jev を Early Access で提供すると記載しています。受付は waitlist 形式でした。

この情報が流れてきたことで Jev を知りました。発表直後に Early Access を申し込み、access を得てから調査を始めています。説明の中にあった「文章を生成せず、型付きの確率的判断を返す」という点が気になりました。

生成AIをアプリケーションへ組み込むとき、いつも文章が欲しいわけではありません。サポート問い合わせなら「障害報告か」「急ぎか」「どの担当へ送るか」といった判断だけが欲しい場面があります。一般的なLLMでもStructured OutputやJSON Schemaを使えば型付き出力を作れます。では、文章生成ではなく型付きの確率的判断に特化するJevは、何を返すのでしょうか。

公開されたばかりのAPIを実際に触り、まず返り値を見ることにしました。

まずは一件の問い合わせを渡してみる

TypeSafe は Jev を System One Model と呼びます。公式発表では、非構造化 data を受け、事前定義した型の確率的判断を返すモデルだと説明しています。文字列生成を行わず、構造化された出力を返すという説明もあります。ここまでは公式の主張です。

公式サイトにはさらに「Zero Hallucinations」という強い表現もあります。launch articleは、可能な出力と構造をあらかじめ定義し、schema matchingを保証するという範囲で説明しています。これは「アプリケーションが期待した扱いになる」ことや「誤答しない」こととは別です。この区別は次回、Choiceの設計とともに確認します。

用語だけでは使い心地が分かりません。そこで「全 checkout が 500 error になり、回避策はなく、今日中に調べてほしい」という ticket を用意しました。この文章について、問い合わせ種別、影響の大きさ、明示的な緊急性を同時に尋ねます。

state.ticket.message:
"Since this morning, customers receive a 500 error after clicking Pay.
 No payment is captured. This blocks every checkout; please investigate today."

Choice: primary issue type
  bug / feature_request / how_to / billing / other

Score: operational severity
  0: impactなし ... 3: 多数または全利用者の主要業務が停止

Noul: message は緊急性または時間的制約を明示しているか

ここでは実験時のScore criteriaをそのまま載せています。現行のScore仕様ではlevel番号はcriteria配列の順序で決まるため、criteria本文に0:のような番号を書く必要はありません。

この検証では、これを三種類の質問として一つのrequestに入れました。返ったのは文章ではなく、bug、Score 2.94、urgency 0.98でした。Choiceのbugにはprobability 1.00とconfidence 1.00が、Scoreには各段階のprobabilityとconfidenceが含まれます。HTTP 200、end-to-end latencyは約799 msでした。以下では、検証時の主要な入力と出力を本文中に掲載します。

Choice
  bug: 1.00
  selected: bug
  confidence: 1.00

Score
  0: 0.00 / 1: 0.01 / 2: 0.02 / 3: 0.97
  score: 2.94
  confidence: 0.94

Noul
  urgent: 0.98

ここで初めて、Choiceは候補から一つを選ぶもの、Scoreは順序ある程度を返すもの、Noulは条件が真である確率を返すものだと具体的に理解できました。Scoreの公式説明では、Scoreは各levelのprobabilityをlevel番号で加重平均した位置です。このためScoreは小数になり得て、2.94は「3に近い位置」を表し、3という離散labelそのものではありません。ただし、この保存済み応答では、表示したprobabilityから単純に再計算すると2.96になる一方、返却されたscoreは2.94でした。この差の原因は本調査では検証していません。Noulにはseparate confidence fieldはなく、返るnoulがyesのprobabilityです。Noulの公式説明

実際に呼ぶコードは、Python SDKなら次の程度です。API keyは環境変数TYPESAFE_API_KEYから読むため、コードへ書きません。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

with TypeSafeClient(model="jev-latest") as client:
    response = client.system_one(
        state={"ticket": {"message": "I was charged twice. Please fix this today."}},
        questions={
            "kind": Choice(instructions="What is the primary issue?", criteria={"billing": None, "bug": None}),
            "severity": Score(instructions="How severe is the impact?", criteria=["minor", "important", "blocking"]),
            "urgent": Noul(instructions="Does the message explicitly express urgency?"),
        },
    )
print(response.choices["kind"].choice, response.scores["severity"].score, response.nouls["urgent"].noul)

JSONを返すLLMと何が違うのでしょうか

JSON schema を指定したLLMでも、似た値は作れます。それでも Jev の API は、最初から「候補集合」「段階」「真偽条件」を質問として渡し、各回答をその型で返す形に寄っています。この検証の指定モデルは jev-latest、返却モデルは jev-1.13.0 でした。

比較対象はLLMだけではありません。taxonomyが固定され、十分な教師データがある用途なら、専用classifierも有力です。本稿では専用classifierとの精度・速度比較はしていません。Jevで気になったのは、利用者側で用途専用classifierを学習せず、質問とcriteriaを実行時に定義して、狭い意味判断を置ける点です。

アプリケーション側で文章を再解釈する代わりに、たとえば severity >= 2.5 かつ urgency >= 0.5 なら incident 担当へ送る、と普通の Python に書けます。Jev が担う範囲を文章の意味を小さく読む部分に限り、送信先や権限操作はコードで決める設計にできます。

confidence は安心度メーターではなさそうです

この感触はかなり扱いやすそうでした。しかし、すぐ別の疑問が出ました。Choice confidence が 1.00 なら、正しいと信じて自動処理してよいのでしょうか。

公式資料はChoiceとScoreのconfidenceを確率分布に関係する値として説明しています。一方、今回の観測では、脆弱性報告をbugと選ぶ例や、矛盾したimpactでScore confidenceが0.00になる例がありました。前者はbug criteriaにも入り得るため誤答の証拠ではありませんが、confidence 1.00を「アプリケーションにとって100%望ましい扱い」とは読めません。

ここまで触ると、Jev をどう捉えると分かりやすいかが少し見えてきます。今回は、文章を生成するAIというより、非構造化 input について型付きの意味判断を返す部品として見ると理解しやすい、と感じました。これは TypeSafe の公式定義ではなく、今回の実装から得た暫定的な整理です。

APIとしてはかなり扱いやすそうです。しかし、型に合った値が返ることと、判断が意味的に正しいことは同じことではないはずです。次回は、曖昧な入力や矛盾した入力に加え、選択肢や観測軸の設計が入力とうまく噛み合わない場合を試します。

検証条件: 保存済みAPI応答の取得日は2026年9月17日JSTです。Python 3.13.14、typesafe-sdk 0.6.0、requested modelはjev-latest、returned modelはjev-1.13.0でした。Early Access中のため、後日のmodel aliasやAPIの挙動が同じであることは保証されません。

次回は、「Jevはどこまで信用できる？ 曖昧な入力と選択肢の境界を試した」です。お楽しみに。