Kuboyage

・ AI

Jevとは何か — 文章を書かず確率を返すTypeSafeの新モデル

Jevとは何か — 文章を書かず確率を返すTypeSafeの新モデル

この記事について 📖

対象読者: LLM を分類・振り分け・採点のような「判断」に使っていて、遅さと料金と JSON の崩れに困っている方

この記事で扱うこと: Jev がどういう仕組みで何を返すのか、速さと安さの根拠はどこにあるのか、公式が自ら添えている但し書きは何かを整理いたします。TypeScript から呼ぶ形も示します。

はじめに 👋

こんにちは！H×H のセンリツ大好きエンジニアです！✌️

2026年9月15日、TypeSafe AI が2年の潜伏期間を終え、最初のモデル Jev を早期公開しました。創業者は OpenAI で RLHF を共同発明した Diogo Almeida 氏 (Google Scholar) です。The Register によれば、調達額は 4,000 万ドルとのことです。

Jev は LLM ではありません。文章を一切生成せず、あらかじめ定義した選択肢への確率だけを返します。公式はこれを「フロンティア級の知能を持つ関数呼び出し」と表現しています。

筆者は API の待機リストに登録した段階で、まだ手元で叩けていません。そのため本記事は、公式ドキュメントと同社の技術解説、報道各社の記事を突き合わせた整理です。実測が取れ次第、続報を書く予定です。

この記事はおよそ 6700 字なので、13 分で読めます！

※この記事は AI と 2 人 3 脚で執筆されています

目次 📚

  1. Jev の正体 — 確率を返す「判断関数」
  2. 3つの質問型 — Choice / Score / Noul
  3. 速さと価格の根拠 — 70ms と $0.042/MTok
  4. 「ハルシネーションしない」の正確な意味
  5. 開発者の実測と制約
  6. TypeScript から呼ぶ — SDK の形
  7. まとめ

1. Jev の正体 — 確率を返す「判断関数」 🧠

「入力は非構造のプログラム状態、出力は型付きの確率的判断です」

文章を生成しないモデル

一般的な LLM は次の語を1つずつ予測し、直前の語に条件付けて次を出します。Jev はこの自己回帰を捨てました。公式ブログの比較表によれば、出力は「並列」に、すべての答えを1回の問い合わせで同時に生成します。

返るのは、事前に定義した選択肢のどれか、あるいは 0 から 1 の確率です。だからこそ型エラーが起きません。値の形は呼び出し側が決めており、モデルはその枠の中でしか答えられないためです。

同社はこの種のモデルを System One モデル と呼びます。公式ドキュメントによれば、名前の由来は Daniel Kahneman が『ファスト＆スロー』で広めた概念です。速く直感的に判断する System 1 と、遅く熟考する System 2 の対比で、Jev は前者に特化しています。長い思考の連鎖を売りにする推論モデルとは、逆の方向を向いた設計です。

訓練手法 RLCD

学習方法も違います。AI primer によれば、ChatGPT を生んだ RLHF は「人が好む応答」を最適化します。Jev の訓練は RLCD（Reinforcement Learning for Calibrated Decisions） です。最適化の対象は「較正された確率を伴う判断」に変わります。

較正とは、確率 0.8 を付けた予測が実際に約 80% の割合で当たる性質のことです。同じ文書は、これが「予測の集合について成り立つ性質であり、個々の答えの正しさを保証しない」と明記しています。この一文が、後述する「ハルシネーションしない」を読み解く鍵です。

内部構造は非公開です。TechCrunch によれば Transformer を土台にしており、学習には合成データのみを使ったと Almeida 氏は語っています。外部の観測者は、公開重みの LLM の上に作られていると見ているそうです。

2. 3つの質問型 — Choice / Score / Noul 🧩

「状態と型付きの質問を送ると、型付きの答えと確率が返ります」

API は1本だけです。POST /v1/systemone に state（判断材料）と questions（質問の集合）を送る形です。質問型は次の3つで、定義は Primitives にあります。

質問型問いの形返るもの
Choice選択肢から1つ選ぶ選んだ選択肢、各選択肢の確率、confidence
Score段階に沿って採点するscore、各段階の確率、confidence
Noulはい / いいえはいである確率（0〜1）

3つは1回の呼び出しに混ぜられ、すべて並列に評価される仕組みです。Introduction は「1つの質問は1つの絞り込んだことだけを尋ねる」設計を勧めています。複雑な判断は小さな質問に分解し、コードで組み合わせる使い方が前提です。

Quick start の例を抜粋します。顧客の問い合わせ文を state に入れ、担当部署と緊急性を同時に尋ねる形です。

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. ...",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "is_urgent": { "type": "noul", "instructions": "The message conveys urgency or time-sensitivity" }
  }
}

応答は次の形です。公式の例にある Score の質問（frustration）は省いています。

{
  "model": "jev-latest",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.84, "technical": 0.159, "sales": 0.001 },
      "confidence": 0.596
    },
    "is_urgent": { "type": "noul", "noul": 0.999 }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

department は billing が 0.84 で選ばれていますが、confidence は 0.596 とやや低めです。technical にも 0.159 が残っており、分布の広がりがそのまま確信度に反映されています。is_urgent は 0.999 で、ほぼ疑いなく緊急と読めます。

この並びが意味するのは、「答え」と「どれだけ信じてよいか」が別々に返ってくることです。LLM に JSON で確信度を書かせても、それは文章の一部として生成された数字に過ぎません。Jev の confidence は確率分布から計算した統計量で、閾値として使う前提で設計されています。

3. 速さと価格の根拠 — 70ms と $0.042/MTok 💸

「速さと単価は自分で検証できる、と公式自身が言っています」

公式の比較表

公式ブログの比較表から、既存の LLM と Jev の数字を並べます。

項目既存の LLM（公式の比較表）Jev
応答時間3〜329 秒70ms〜500ms
入力単価$0.20〜$10 / MTok$0.042 / MTok
出力単価入力の約5倍無料

The Register は、Doom を操作するデモで Jev が 0.114 秒、GPT-5.6 Terra が 8.566 秒だったと報じています。同記事にある Terra の単価は入力 $2.00、出力 $12 / MTok で、Fable 5.1 と比べると 238 分の 1 の費用とのことです。

Doom の裏話として、公式ブログには「毎秒 10 回の問い合わせで 1 時間あたり約 7 ドル」という記述があります。作った担当者は費用を心配していたものの、他の社員は「思ったより安い」と受け止めたそうです。毎秒 10 回という頻度で AI を呼ぶ発想自体が、これまでの単価では出てきませんでした。

「193.6 倍」の出どころ

公式サイトが掲げる「193.6 倍速く、444.6 倍安い」という数字にも触れておきます。これは同社が新たに作った「workflow evals」の結果です。コード上の決まった処理の流れに各モデルを差し込み、GPT-6 Astra と Fable 5.1 の平均を参照値として比べたものです。

ただし公式は、この数字に3つの但し書きを添えています。1つは「実世界で得られる効果の上限側」であること。もう1つは参照値が OpenAI と Anthropic のモデルに偏ること。最後に、評価を作ったのが同社のモデル能力チームであることです。宣伝の数字に自ら注釈を付ける姿勢には、率直に好感が持てました。

もう1つ、公開している応答速度は「米国西海岸のノート PC から測った値」だとブログにあります。日本から呼べば往復の遅延が上乗せされるため、70ms がそのまま出るとは考えない方がよいでしょう。

現行モデルと制限値

Models によれば、2026年9月時点の現行は jev-1.13.0 で、jev-latest がそれを指します。

  • 単価: 入力 $0.042 / MTok、出力は無料
  • 上限: 毎秒 25 万トークン、毎分 1,200 リクエスト
  • 文脈長: 1リクエスト 64k、state と最長の質問で 32k
  • 入力: テキストのみ

上限は需要に応じて予告なく変わる、と同ページに警告があります。GPU の調達が落ち着くまでは、上限値を前提にした設計は避けた方が安全です。

4. 「ハルシネーションしない」の正確な意味 🔍

「型を外さないことと、答えが正しいことは別です」

公式が「数学的に不可能」と言っているのは型エラーです。出力の形は呼び出し側が決めており、モデルは定義された選択肢の外を返せません。存在しない道具を呼ぶ、JSON が閉じていない、といった失敗はこの設計では起きようがありません。

一方で The Register は「構造化された確率を返すだけで、間違う可能性は排除されない」と指摘しています。公式ドキュメント自身も、較正は予測の集合に対する性質であり、個々の答えを保証しないと書いています。つまり「ハルシネーションしない」は「でたらめな形式を返さない」の意味で、「常に正しい」ではありません。

その代わりに「分からない」を数字で返します。Confidence のページは、確信度を3つの帯に分けて挙動を変える設計を勧めています。高ければ自動で実行し、中程度なら確認を挟み、低ければ人か推論モデルへ回す、という形です。

閾値はリスクに応じて変える、という例が同ページにあります。

action = response.answers["action"]
confidence = action.confidence

if confidence < 0.5:
    route_to_human(user_message)          # 迷っている。推測しない
elif action.choice == "check_balance":
    show_balance(account_id)              # 読み取りだけ。間違えても戻せる
elif action.choice == "approve_transfer":
    if confidence > 0.9:
        confirm_then_execute(account_id)  # 高リスク・高確信
    else:
        ask_user_to_confirm(account_id)   # 高リスク・確信不足

残高表示は間違えても戻せるので確信度を問いませんが、送金の承認は 0.9 を超えない限り確認を挟みます。リスクの許容度はコードが持ち、モデルはそれに材料を渡すだけ、という分担です。

Armin Ronacher 氏 (TechCrunch) は Earendil の CTO で、harness「Pi」の作者でもあります。同氏はこの構造を「ハルシネーションの問題を少し利用者に委ねている」と評しました。50% なら「コイン投げ」として捨て、95% なら使う。その判断を書く責任は開発者に残ります。

5. 開発者の実測と制約 ⚖️

「速さは実測で裏付けが出始め、精度は用途次第という評価です」

早期利用者の声

TechCrunch には早期利用者の声が2つ載っています。

Vercel の Pranit Sharma 氏は、実行するコマンドの安全性を審査する分類器を OpenAI の Luna 5.6 から Jev に替えました。結果は 5〜18 倍の高速化で、精度も上がったと述べています。

Bryo AI の CTO、Nikhil Mudholkar 氏は業務メールの分類で Gemini と比べました。精度は Gemini がわずかに上でしたが、費用は Gemini の方が 10〜20 倍高かったそうです。それ以上に評価していたのは確信度で、「本物の確率を返す唯一のモデル」と書いています。

ここで筆者の失敗を1つ書いておきます。この記事の下調べで、Web ページを要約する道具が Mudholkar 氏の発言を「Jev の方が 10〜20 倍高い」と逆に伝えてきました。原文を開いて読み直したから気づけたもので、要約だけを根拠にしていたら結論が反転していました。数字を載せる前に原文を開く、という当たり前が今回も効いた形です。

使う前に知っておく制約

公式が明示している制約を並べます。

  • 文章・コード・説明文は生成しない
  • 入力はテキストのみ
  • Choice の選択肢は最大 255
  • 顧客データによる微調整は不可
  • 上限値は予告なく変動

微調整ができない代わりに、業務知識は state と各質問の instructions / criteria に書き込む設計です。同じ重みを全アカウントで共有し、リクエストの中身だけで答えを自分の領域に寄せます。

日本語で使う方は、Models の一節に注意が要ります。「英語が主な学習言語で精度も最も高い。CJK を含む他言語は扱えるが同等ではない」と明記されています。日本語の分類に使うなら、自分のデータで確信度の分布を見てから閾値を決める必要があります。

筆者が試したい用途

筆者は毎朝 400 件の記事を 5 件に絞る bot、Research Desk を LLM で回しています。「この記事は読者に関係があるか」「重要度はどの段階か」という問いは、そのまま Noul と Score の形です。400 件を1件ずつ LLM に読ませる現状と比べれば、費用も待ち時間も桁で変わる計算になります。

ただし対象は日本語の記事が中心です。前述の言語の注意書きがそのまま当てはまるため、まず数百件で確信度と実際の採否を突き合わせるところから始めるつもりです。

6. TypeScript から呼ぶ — SDK の形 💻

「質問の型から答えの型が推論されます」

JavaScript SDK は npm の @typesafe-ai/sdk で、Node.js 20 以上で動きます。環境変数 TYPESAFE_API_KEY を読み、既定で jev-latest を呼びます。公式の例は次のとおりです。

import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const response = await client.systemOne({
  state: { document: "I was charged twice. Please fix this ASAP." },
  questions: {
    category: choice("What is this ticket about?", {
      billing: null,
      technical: null,
      other: null,
    }),
  },
});

console.log(response.answers.category.choice);

choice の第2引数に渡したキーが、そのまま answers.category.choice の型になります。公式の説明は「答えの型は質問から推論される」で、LLM の出力を zod で検証し直す工程が丸ごと消える形です。実装は GitHub で公開されています。

Python 版は typesafe-sdk という名前で、同期・非同期の両方の呼び出しに対応しています。どちらの SDK も、上限超過の 429 に対しては既定で退避しつつ再試行し、retry-after を尊重する作りです。

Claude Code から使う場合は、公式が用意した skill を導入できます。

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

まとめ 🎊

  • Jev は文章を生成せず、型付きの判断と確率を返す
  • 質問型は Choice / Score / Noul の3つ
  • 応答 70〜500ms、入力 $0.042/MTok、出力は無料
  • 型エラーは起きないが、答えの正しさは保証されない
  • 確信度で「実行・確認・人に回す」を分ける
  • 英語が主で、日本語は自分のデータで要検証

Jev が置き換えるのは、コードの中の「あいまいな if 文」です。分類・振り分け・採点のように、答えの形が先に決まっている場所ほど向いています。逆に、文章を書かせたい場面には最初から使えません。

数字はまだ公式と早期利用者のものだけです。待機リストが開き次第、日本語の記事分類で実測し、確信度の分布がどう出るかを続報として書きます。

参考リンク 🔗

一次情報

報道

関連記事

ブログの記事一覧へ