「LLMに分類させているだけなのに、1件あたり数秒かかって料金も無視できない」「JSONで返せと指示しているのに、たまに形式が崩れて例外になる」「自信があるのか無いのか分からないので、結局すべて人がレビューしている」——AIをアプリケーションの判断ロジックに組み込むと、ぶつかるのはたいてい生成の品質ではなく、速度・コスト・出力の安定性です。

TypeSafe が公開した JEV（ジェブ） は、この領域だけを狙ったモデルです。文章を書かない代わりに「はい/いいえ」「どれか1つ」「何段階か」を返すことに特化しています。本記事では、JEV が何者なのか、なぜ速くて安いのか、今どうすれば触れるのか（公式APIは順番待ちですが、待たずに試す経路があります）、そして日本語で使うときの注意点までを、公式ドキュメントの記載値をもとにまとめます。

JEV は TypeSafe が「System One モデル」と呼ぶ新しいモデル群の第1弾です。名前はカーネマンの『ファスト＆スロー』に由来し、速く直感的な System 1 思考と、遅く熟慮する System 2 推論の区別から取られています。一般的な LLM が後者にあたるのに対し、JEV は前者――ソフトウェアがそのまま使える構造化された判断を、高速に返すことだけを担当します。

最大の特徴は、テキスト生成を完全に捨てている点です。返ってくるのは散文ではなく、次の3つのいずれかです。

• Noul：はい/いいえの確率（0〜1）
• Choice：定義済みの選択肢から1つ＋各選択肢の確率分布
• Score：順序のある段階評価の位置＋確率分布

出力がスキーマに拘束されているため、不正な値や型エラーが原理的に発生しません。TypeSafe は構造化出力のエラー率・ツール呼び出しエラー率をいずれも0%と報告しています。「JSONで返して」と頼んで祈る必要がなくなる、というのが実務上いちばん大きい変化です。

理由は2つあります。

1つ目は、トークンを順番に吐かないこと。 通常の LLM は出力を1トークンずつ逐次生成しますが、JEV は「すべての出力を1回のクエリで」並列に扱います。TypeSafe の比較では、同じ判断タスクで LLM が3〜329秒かかるところを JEV は 70ms〜500ms で返し、40〜200倍高速としています（サイト上の最良ケースでは 193.6倍高速・444.6倍安価という数字も出ています。条件付きの最高値なので、自分のワークロードで測り直す前提で見るのが妥当です）。

2つ目は、出力トークンが無料であること。 一般的なモデルでは出力トークンが入力の5倍程度に課金されますが、JEV は生成する文章がないため、課金対象は入力だけです。分類やスコアリングのように「入力は長いが出力は短い」タスクでは、この構造がそのままコスト差になります。

もう一つ効くのが、同じ `state` に対する複数の質問を1リクエストにまとめられる点です。質問を増やしても応答時間はほぼ変わらず、追加コストも最小限です。「緊急度」「担当部署」「不満度」を別々に3回問い合わせる必要がありません。

Score は「レベル1」「レベル2」ではなく、レベルの間の位置を小数で返します（後述の例では 1.035）。段階の境界にある入力を切り捨てずに扱えるのが利点です。

なお各質問は独立に評価され、他の回答に影響されません。回答Aの結果で回答Bを変えたい場合は、リクエストを分けて段階的に呼ぶ必要があります。

ここが最初の分かれ道です。JEV は early access（早期アクセス） の段階にあり、公式サイトにも「Try our first System One Model, Jev, in early access」と書かれています。公式APIのキーはウェイティングリスト制で、登録して順番を待つ必要があります。

一方で、Cloudflare Workers AI 経由なら待たずに使えます。サードパーティモデルとして提供されており、申請や順番待ちの案内はなく、通常の Workers AI のモデルと同じように呼べます。

⚠️ 早期アクセス中のため、価格・コンテキスト上限・ベンチマークの数値は今後変わる可能性があります。本記事の数値は執筆時点の公式ドキュメント記載値です。

Workers からはモデルID typesafe/jev で呼べます。TypeSafe のアカウント承認を待たずに済むのが最大の利点です。

const response = await env.AI.run('typesafe/jev', {
  state: 'Help! My payouts have been failing for 3 days.',
  questions: {
    is_urgent: {
      type: 'noul',
      instructions: 'Does this convey urgency?',
      criteria: { true: 'Explicitly time-sensitive', false: 'No urgency expressed' },
    },
    department: {
      type: 'choice',
      instructions: 'Which team should handle this?',
      criteria: {
        billing: 'Payments, invoicing, refunds',
        technical: 'Bugs, outages, integrations',
        sales: 'Pricing, upgrades, new accounts',
      },
    },
  },
})

返り値はこの形です。

{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.95 },
    "department": { "type": "choice", "choice": "billing", "confidence": 0.8 }
  },
  "usage": { "input_tokens": 426, "output_tokens": 73 }
}

APIキーは console.typesafe.ai で発行しますが、前述のとおり早期アクセスの承認が必要です。承認後は次のように叩けます。

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "urgency": {
      "type": "noul",
      "instructions": "Does this message express urgency?"
    }
  }
}
EOF

3種類の質問を1リクエストにまとめる例です。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
ticket = "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP."

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

返ってくる JSON はこの形です。

{
  "model": "jev-latest",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.84, "technical": 0.159, "sales": 0.001 },
      "confidence": 0.596
    },
    "frustration": {
      "type": "score",
      "score": 1.035,
      "legend": { "0": "Calm, just stating facts", "1": "Frustrated but civil", "2": "Very angry, strong language" },
      "confidence": 0.842
    },
    "is_urgent": { "type": "noul", "noul": 0.999 }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

LangChain からは TypeSafeClassifier 経由で、チャット応答ではなく分類結果として受け取れます。

from langchain_typesafe import Noul, TypeSafeClassifier

classifier = TypeSafeClassifier()

response = classifier.invoke(
    state="The deploy failed twice and customers are seeing 500s",
    questions={
        "urgent": Noul(instructions="Does this need attention?"),
    },
)

urgency = response.nouls["urgent"].noul

JEV の確率はキャリブレーション済みです。つまり「0.8」と返ってきたら実際におよそ8割の精度で当たる、という意味を持ちます。ここが普通の LLM に「自信を10段階で教えて」と聞いた値との決定的な違いで、そのまま分岐条件に書けるようになります。

confidence は確率分布から計算される 0〜1 の統計量で、確率そのものではなく「分布の鋭さ＝確からしさ」を表します。公式が示す設計は3段階です。

ただし公式も「適切な閾値はドメインによる」と明記しています。保守的な値から始め、実データで誤判定のコストと突き合わせて調整するのが前提です。この「高信頼なら自動、低信頼なら人間か遅いLLMへ」という振り分けは、公式ドキュメントでも confidence-gated routing というパターンとして整理されています。

向いているのは、判断そのものが目的で、文章が要らない場面です。

• リクエストの振り分け（サポートチケット、問い合わせメール、モデルルーティング）
• 大量データへの一括ラベル付け・特徴量抽出
• エージェントの安全ゲート（危険なツール呼び出しの検出、ジェイルブレイク検知）
• 品質チェック（生成結果の採点、ガードレール、実行後レビュー）
• UXが速度に左右されるリアルタイム機能（100ms級で返るため画面をブロックしない）

向かないのは次の場合です。

• 文章を書かせたい（要約・翻訳・コード生成）——JEV は生成できません
• 選択肢を事前に定義できない（自由記述の抽出）
• 画像・音声・動画を入力にしたい——テキスト専用です
• 回答Aを踏まえて回答Bを変える、といった質問間の依存が必要な場合

位置づけとしては LLM の代替ではなく補完です。判定は JEV に任せ、生成が要る部分だけ LLM に渡す、という分担になります。

公式ドキュメントは、最高精度が出るのは英語で、日本語を含むCJK言語は「対応しているが同等の精度ではない」と明記しています。本番投入前にテストするよう推奨されているので、日本語のチケットやレビューを判定させるなら、自前のデータで精度を実測してから使うのが安全です。instructions と criteria を英語で書き、state だけ日本語にする構成も検討の余地があります。

• JEV は TypeSafe の System One モデル第1弾で、生成を捨てて判定に特化したモデル
• 質問は Noul / Choice / Score の3種類。出力はスキーマに拘束され、型エラーが起こらない
• 出力トークンが無料（入力 $0.042/MTok）、応答 70ms〜500ms。同じ state への複数質問は1リクエストにまとめられる
• 確率がキャリブレーションされているため、閾値をそのまま分岐条件に書ける（目安は 0.9以上で自動、0.5未満は人へ）
• ⚠️ 公式APIは早期アクセス（ウェイティングリスト制）。今すぐ触るなら Cloudflare Workers AI 経由が最短。早期アクセス中のため提供条件や価格は変わりうる
• ⚠️ テキスト専用・生成不可・日本語は精度が英語と同等ではないため、実データでの検証が前提

「AIに文章を書かせる」フェーズから「AIに判断させてソフトウェアに組み込む」フェーズへ進むと、必要になるのは賢さより速さと安定性です。JEV はその一点を狙った設計になっています。

公式APIは早期アクセス段階で、console.typesafe.ai でウェイティングリストに登録して順番を待つ必要があります。一方 Cloudflare Workers AI 経由なら待ちなしで呼べます（モデルID typesafe/jev）。手元で挙動を確かめたいだけなら、Workers から試すのがいちばん早い経路です。

なりません。JEV はテキストを生成できないため、要約・翻訳・コード生成といった用途には使えません。用途は分類・スコアリング・判定に限られ、LLM を置き換えるのではなく、判断部分だけを切り出して任せる補完的な使い方になります。

返ってくる確率が実際の的中率と一致するように設計されている、という意味です。「0.8」と出た判定群を集めると、実際におよそ8割が正しい、という関係が成り立ちます。そのため確率をそのまま閾値判定に使えます。LLM に自己申告させた信頼度はこの保証がなく、過信・過小評価が混ざります。

使えますが、精度は英語ほどではありません。公式ドキュメントは英語で最高精度が出るとし、CJK を含む他言語は対応するものの同等ではないため本番前のテストを推奨しています。日本語で運用するなら、自分のデータで誤判定率を測ってから閾値を決めてください。

入力100万トークンあたり $0.042、出力トークンは無料です。判定タスクは出力が短いため、出力課金が無いぶんの差が大きく出ます。公式ブログでは、毎秒10クエリを投げ続けるデモ（Doom のプレイ）でも1時間あたり約7ドルという例が示されています。