話題のJevとは？文章を書かずに判断だけを返すAIモデルをざっくり解説

Posted at 2026-09-18

はじめに

Jevが話題ですね。
文章を書かないAIと紹介されていますが、では代わりに何を返すんでしょうか。

この記事は、Jevが何をするものかの解像度を上げるために自分なりに整理したものです。

ざっくりまとめ

公開元と時期 — サンフランシスコのTypeSafe AIが、2026年9月15日に早期アクセスとして公開した。同社が「System One Model」と呼ぶ分類のモデルの第1号¹
入出力 — 状況を表すテキストやJSON（state）と、型付きの問い（questions）を渡すと、選択肢ごとの確率と確信度が返る。文章は生成しない
問いの型 — Choice（選択肢から1つ）、Score（段階評価）、Noul（Yes/Noの確率）の3種類。複数の問いを1回の呼び出しで並列に評価する
公称の速さと料金 — 応答は70〜500ミリ秒、入力100万トークンあたり0.042ドル、出力は無料（公式ブログの値）
向く用途 — 分類、振り分け、採点、検証。文章の生成、計算、日付の比較は、公式が不得意と明記している

記述式とマークシートのたとえ

Jevが従来のLLMと何が違うのかを、答案の形にたとえて見ていきます。

LLMに「このレビューは苦情ですか。JSONで答えてください」と頼むのは、記述式の答案を書かせる方式に近い作りです。
モデルは答案を1トークンずつ順に書きます。
受け取ったプログラムはそれを読み、形式が崩れていないかを確かめてから中身を取り出します。

Jevは、マークシートに近い作りです。
出題するプログラムの側が選択肢を用意し、Jevはどの欄をどれくらいの確からしさで塗るかを返します。
答案を書く工程がないので応答が速く、用意していない選択肢が答えに出てくることもありません。

一方で、マークシートでも塗る欄を間違えることはあります。
公式ブログは型エラーが0%だと説明していますが、これは答えが用意した選択肢の枠からはみ出さないことを指しています。
選択肢の中でどれを選ぶかの誤りは残ります。

このたとえを、実際の入出力の形に置き換えます。

stateとquestionsの入出力

Jevへのリクエストは、stateとquestionsの2つでできています。

stateは、判断してほしい状況です。
文字列でも、JSONのような構造化データでも渡せます。
問い合わせの本文、チャットのログ、アプリケーションの状態などが入ります。

questionsは、stateに対する問いです。
問いにはそれぞれ型があり、次の3種類から選びます。

Choice — 用意した選択肢から1つを選ぶ。返るのは、選ばれた選択肢、全選択肢の確率、確信度
Score — 段階を順に並べた基準で評価する。段階は2つ以上。返るのは、確率で重み付けした値、各段階の確率、確信度
Noul — Yes/Noで答えられる問い。返るのは、Yesである確率（0〜1）

例えば、ECサイトに届いた商品レビューを、スパムかどうか、不満の度合い、最初に確認するチームの3つの観点で見る場合を考えます。
（あくまで一例です。）
リクエストは次の形になります。

{
  "model": "jev-latest",
  "state": "届いた箱が潰れていて、中のマグカップも欠けていました。交換をお願いします。",
  "questions": {
    "is_spam": {
      "type": "noul",
      "instructions": "この投稿は宣伝や無関係な内容のスパムか"
    },
    "dissatisfaction": {
      "type": "score",
      "instructions": "投稿者の不満の度合い",
      "criteria": ["不満はない", "やや不満", "強い不満"]
    },
    "team": {
      "type": "choice",
      "instructions": "この投稿を最初に確認すべきチーム",
      "criteria": {
        "shipping": "配送中の破損、遅延、誤配送",
        "product": "商品そのものの不良や品質",
        "payment": "決済、返金、請求",
        "other": "上記のいずれでもない"
      }
    }
  }
}

レスポンスでは、問いに付けた名前ごとに答えが返ります。

{
  "model": "jev-latest",
  "answers": {
    "is_spam": { "type": "noul", "noul": 0.02 },
    "dissatisfaction": {
      "type": "score",
      "score": 1.3,
      "legend": { "0": "不満はない", "1": "やや不満", "2": "強い不満" },
      "probabilities": { "0": 0.05, "1": 0.60, "2": 0.35 },
      "confidence": 0.58
    },
    "team": {
      "type": "choice",
      "choice": "shipping",
      "probabilities": { "shipping": 0.52, "product": 0.44, "payment": 0.01, "other": 0.03 },
      "confidence": 0.41
    }
  }
}

（リクエストとレスポンスの形は公式のAPIリファレンスに合わせています。数値は説明のために置いた例で、実際に呼び出して得た値ではありません。）

3つの問いは1回の呼び出しの中で並列に評価されます。
問いを増やしても、往復の回数は増えません。

この例では、箱の破損が配送の問題なのか商品の問題なのかが文面から決めきれず、team の確率が shipping と product に割れています。
この割れ方を、プログラムの側で分岐の条件に使えます。

確信度によるコード側の分岐

Jevの答えに付く確率と確信度を、プログラムの側でどう使うのかを見ていきます。

確信度（confidence） は、選択肢ごとの確率の分布を0〜1の1つの値にまとめたものです。
確率が1つの選択肢に集中していれば高く、複数の選択肢に割れていれば低くなります。
公式のガイドは、確信度に応じて処理を3つに分ける書き方を紹介しています。

team = answers["team"]

# しきい値は業務に合わせて決める。ここの値は一例
if team["confidence"] >= 0.9:
    assign_to_team(team["choice"])       # 自動で担当チームへ割り当てる
elif team["confidence"] >= 0.5:
    show_candidates(team["probabilities"])  # 候補を提示して担当者に尋ねる
else:
    send_to_triage_queue()             # 人が振り分ける

先ほどのレビューは確信度が0.41なので、人が振り分ける側に回ります。
確率が1つの選択肢に集中しているレビューは、自動で担当チームへ割り当てられます。
問い合わせや投稿の一次振り分けのうち、人が見る必要のあるものだけを人に渡せるようになります。

上の図はこの役割分担を表しています。
処理の流れを決めるのはアプリのコードで、Jevは問いに対する判断だけを返します。
公式ドキュメントも、期限を30日過ぎたら回収部門へ回すといった決まったルールはコードに書き、文面の解釈のような部分だけをJevに渡す構成を勧めています。

しきい値による分岐が成り立つ前提として、公式は確率が調整（キャリブレーション） されていると説明しています²。
調整された確率とは、「80%」と答えた判断を集めると、およそ8割が実際に当たっている状態を指します。

Structured Outputや分類モデルとの違い

選択肢の中から答えさせる方法は、Jevの前からあります。
LLMに出力の形式を指定するStructured Outputと、ラベルを学習させた専用の分類モデルを並べて、違いを整理します。

方法	出力	答えの作り方	事前の学習	確からしさ
LLMの自由な文章	文章	トークンを順に生成	不要	文中の言葉で表現される
LLMのStructured Output	指定した形式のJSON	トークンを順に生成	不要	出力項目として書かせる
専用の分類モデル	学習したラベル	1回の計算で候補を採点	ラベル付きデータで学習	ラベルごとの確率
Jev	選択肢ごとの確率	1回の計算で候補を採点	不要。問いは自然言語で書く	確率と確信度

候補を1回の計算で採点する作りは、分類モデルと同じ考え方です。
既存のLLMでも、次の1トークンの確率を読み取る形で似た仕組みを組める、という指摘もあります（Sean Goedecke氏のブログや、nwnさんのZenn記事）。
そのうえでJevの特徴は、主に次の点にあります。

問いをその場で書ける — 問いと選択肢を自然言語で渡す。タスクごとの学習データを用意しない
複数の問いを1回で評価する — 同じstateに対する問いをまとめて渡し、並列に答えを得る
確率を分岐に使う前提で作られている — 確率の調整を目的にした学習法を採っていると公式が説明している

向いている用途と注意点

公式のユースケース一覧から、業務の場面が浮かびやすいものを挙げます。

問い合わせの振り分け — メール、チャット、フォームの投稿が届いた時点で、担当と緊急度を決める
投稿のモデレーション — スパム、攻撃的な表現、宣伝目的かどうかを、投稿ごとに複数の観点で同時に見る
検索結果の並べ替え — 検索やRAGで取り出した候補を、問いとの関連度で並べ直す
LLMの出力の検証 — 別のLLMの回答が根拠に沿っているか、指示から逸れていないかを採点する
エージェントの分岐 — ツールの選択や、続行、再試行、停止の判断を、文章を生成せずに決める

公式ドキュメントには、現行のモデル（jev-1.13）の苦手な点をまとめたページがあります。
設計に関わるものを抜き出します。

注意点：

問いを書かれたとおりに読み、意図を汲まない。条件は選択肢ごとに具体的に書く
数え上げと計算は信頼できない。計算はコードで行い、Jevには値の抽出だけを問う
日付を前後関係のある量として扱えない。日付の部品を抽出させ、比較はコードで行う
関係のない情報が多いstateは精度を下げる。問いに必要な部分だけを渡す
文章は生成しない。値を取り出したいときは、候補を選択肢にして選ばせる

公称値の読み方にも前提があります。
「193.6倍速い、444.6倍安い」という数字は、TypeSafe AIが自社で作ったワークフロー評価の結果で、比較の基準にはGPT-6 AstraとFable 5.1が使われています。
手元の題材でどの程度の差になるかは、実際に確かめる必要があります。

試す方法

2026年9月18日時点で、Jevを試す経路は主に次の3つです。

公式のAPI — typesafe.ai のウェイトリストに登録し、招待を待つ。招待後はコンソールのPlaygroundでstateとquestionsを試せる。SDKはPython（typesafe-sdk）とJavaScript（@typesafe-ai/sdk）が公開されている
Vercel AI Gateway — 9月16日から typesafe-ai/jev として提供されている。9月17日時点では無料クレジットの対象外で、クレジットをチャージすると招待を待たずに使える
Cloudflare Workers AI — typesafe/jev として提供されている。コンテキスト長は32,000トークン

まとめ

Jevは、文章を書く代わりに、用意した選択肢ごとの確率を返すモデルです。
答えに確率と確信度が付くので、どこまでを自動で進め、どこから人に渡すかをコードの側で決められます。

文章の生成、計算、日付の比較は不得意と公式が明記しています。
それらはLLMやコードに任せ、Jevには分類、振り分け、採点、検証のような小さな判断を渡す構成になります。

早期アクセスが始まったばかりで、公称値も自社評価の段階です。
少しでも参考になれば嬉しいです。

参考

公式の情報

参考にした記事と資料

公式ブログによると、System Oneという分類名は、心理学者ダニエル・カーネマンの著書『ファスト＆スロー』にある、速く直感的な思考「システム1」から取られています。Jevという名前は、経済学者ウィリアム・スタンレー・ジェヴォンズに由来します。蒸気機関の効率が上がったことで石炭の需要が増えたのと同じ道を、機械の知能もたどるという見立てです。 ↩
公式ブログは、この学習法をReinforcement Learning for Calibrated Decisions（RLCD）と呼んでいます。2026年9月18日時点で、詳細を説明した論文は公開されていません。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up