Jevとは？文章を生成しない判断特化AIの用途・料金・限界

Jevは、文章を入力すると「選択・評価値・Yes/Noの確率」を返すAIモデルです。文章は生成せず、問い合わせの振り分けのような判断をアプリの中で繰り返す用途に向きます。料金は入力100万トークン当たり0.042ドルで、出力は無料です。

1. Jevとは何か

TypeSafeが2026年9月15日に早期アクセスを発表しました。長い解説を返すチャットではなく、アプリの中で「どの担当へ回すか」「どれくらい条件に合うか」を判断する用途を想定しています。

特徴は、返す値の形が決まっていることです。ただし、形式が正しい回答でも、判断は間違えることがあります。発表にある「ハルシネーションがない」という表現を、どんな内容にも正答するという意味に読むと使い方を誤ります。

TypeSafeはJevを「System One model」と呼んでいます。発表によると、心理学者ダニエル・カーネマンの『ファスト&スロー』にある、速く直感的な「システム1」と、時間をかけて熟考する「システム2」の区別から取った同社の呼称で、AI全体で統一された性能等級ではありません。公式のSystem One解説では、自然言語を理解し、ソフトウェアが直接扱える型付きの判断を返すモデルとして説明されています。

Jevという名前は経済学者ウィリアム・スタンレー・ジェヴォンズにちなみ、効率化で需要がかえって増える「ジェヴォンズのパラドックス」のように、知能のコストが下がるほど使い道が桁違いに増える、という見立てを表しています（ホワイトカラーはAIで消滅するのか）。

state

判断する材料。文章やJSON形式のデータ。問い合わせ本文、利用者が選んだ項目、分類のための背景情報などを入れる。

questions

何を判断するか。「どの担当へ回すか」のような質問と、候補や判定基準を入れる。

出力の選択肢を先に決めるため、「おそらく技術担当でしょう」といった文章から分類名を取り出す処理は要りません。一方で、返信文・コード・判断理由の長文を作る用途には向きません。生成AIと組み合わせるなら、Jevで処理先を判定し、文章が必要な場面だけ生成モデルへ渡す、という分担になります。

LLMにJSONで答えさせる方法とは、何が違う？

JSONで受け取れること自体はJevだけの特徴ではありません。たとえばClaudeにも、JSON Schemaに沿って出力を制約する構造化出力があります。既存の生成モデルで分類を実装しているなら、「形式が決まるから」という理由だけで置き換える必要はありません。

Jevは選択・段階評価・二値判断と、それに伴う確率を返すことに特化しています。判断のあとに説明や返信も作るなら生成モデル、文章から候補を繰り返し選ぶならJevも比較候補、金額や日付を厳密に計算するなら通常のコード、と仕事を分けます。同じ入力と判定基準で正確さ・待ち時間・費用を比べてから選ぶのが実用的です。

2. Choice・Score・Noulの違い

公式のPrimitives説明では、質問の種類を次の3つに分けています。似た質問でも、ほしい出力に合わせて選びます。

3. 型の保証と判断の正確さは別

TypeSafeの発表が強調する型の保証は、定義した候補や値の範囲に出力を制約するというものです。問い合わせを請求担当か技術担当かに分ける設定なら、指定していない部署名を自由文で作ることはありません。ただし、正しい部署を選ぶかどうかは別の話です。

ChoiceとScoreの confidence は、公式説明によると、確率分布の集中度を0〜1の1つの数に要約した統計量です。あくまで既定の指標で、用途に合わない場合は、一緒に返る probabilities から別の指標を自分で計算してよいとされています。

候補が拮抗する

confidenceは低くなる。

1つの候補に集中する

confidenceは高くなる。

「0.9だから、この1件は90%正しい」とは読みません。確率の較正は多数の予測をまとめて評価する性質で、1件ごとの正解を示すものではありません。

使い方としては、confidenceで分岐するコードを書きます。公式の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.5の下限は、モデルが本当に迷っていると示した案件を拾うためのものです。そのうえで、出金の承認のような取り消しにくい操作には、読み取りだけの操作より高いしきい値を求めます。0.9を超えても、いきなり実行せず確認を挟んでいる点に注目してください。高いconfidenceは、実行してよいという権限の代わりにはなりません。

0.5と0.9は例で、一律の推奨値ではありません。公式も、適切な値は分野と自分の用途でのモデルの性能で決まるとし、控えめなしきい値から始めて自分のデータで調整するよう勧めています。

4. 問い合わせの振り分けに使う例

たとえば「請求書のダウンロードボタンを押しても反応しない」という問い合わせを考えます。「請求書」の語があるから請求担当、と振り分けると、画面の不具合を見落とします。Jevに判断させるなら、担当の境界を説明したうえで候補を選ばせます。

公式Quick startとAPI仕様に沿って書くと、リクエストは次の形になります。APIキーを用意し、POST https://api.typesafe.ai/v1/systemone へJSONを送ります。

{
  "model": "jev-1.13.0",
  "state": "請求書のダウンロードボタンを押しても反応しません。",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "本文の主な依頼に対応する担当候補を選んでください。",
      "criteria": {
        "billing": "請求額、支払い方法、二重請求への問い合わせ。",
        "technical": "画面操作、エラー、機能が動かない問題。",
        "review": "複数の依頼が混在する、または担当を決める材料が足りない。"
      }
    },
    "service_unavailable": {
      "type": "noul",
      "instructions": "本文に、画面や機能が現在使えないという報告がありますか。"
    }
  }
}

送信と、返答を受け取った後の処理

管理画面でAPIキーを取得し、HTTPヘッダに Authorization: Bearer <API_KEY> と Content-Type: application/json を指定します。キーはサーバ側の環境変数などで管理し、公開するHTMLやリポジトリへ埋め込まないでください。

まず疎通を確かめるなら、公式Quick startに載っているcurlの例をそのまま貼り付けて試せます。キーを環境変数 TYPESAFE_API_KEY に入れてから実行します。英語の問い合わせに「緊急性を示しているか」をNoulで聞く例です。

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 the integration keeps failing. I'm losing sales. Please help ASAP.",
    "model": "jev-latest",
    "questions": {
      "urgency": {
        "type": "noul",
        "instructions": "Does this message express urgency?"
      }
    }
  }
EOF

前掲の日本語の例を送るなら、<<'EOF' と EOF の間をそのJSONに差し替えます。コードから呼ぶ場合と、開発を手伝うエージェントに仕様を読ませる場合は、公式が次の入り口を用意しています。

• Pythonから呼ぶ：pip install typesafe-sdk（Python 3.10以上）。SDKのクライアントは環境変数 TYPESAFE_API_KEY を読み、既定では jev-latest を呼びます。
• Claude Codeで開発する：claude plugin marketplace add typesafe-ai/skills の後に claude plugin install typesafe@typesafe-ai。質問の3つの型や設計パターンをコーディングエージェントに渡す公式スキルが入ります（Agent skill）。

日本語の例に戻ると、読むフィールドと用途は次の図・表のとおりです。Choiceで担当候補、Noulで利用不能の報告の有無を見ます。

401・422：設定や入力を直す

401はキーの欠落・無効、422は入力形式の検証失敗。設定や本文を直してから再送する。

429・529：待ってから再試行

短時間に繰り返さず、待ち時間を徐々に延ばす。公式SDKは既定でこの再試行を自動で行う。

HTTPエラーは、低いconfidenceとは別です。回答値として扱わないでください。根拠は前掲のAPI仕様です。

導入の最初は、既存の振り分けを変えず、人が決めた担当とJevの候補を並べるだけでも十分です。「請求」という語があっても技術的な問題なのか、複数の依頼が混じる場合にreviewへ回せるか、情報不足でも決めつけていないかを調べます。誤りを見つけたら失敗例を追加し、候補の説明が重なっていないかを見直します。

AIエージェントに組み込む場合も、「判断するモデル」「実行するツール」「実行してよい条件」を分け、金額計算や権限確認はコードに残します。誤判定が起きたときに、どこで間違えたかを調べやすくなります。

TypeSafeの公式ドキュメントには、ほかにもLLMアプリのガードレール、RAGで取ってきた文書の選別、検索結果の並べ替え、引用の検証の実装例があります。ガードレールや文書の選別に使う場合も、次章の「答えを誘導する入力」の弱点は残ります（入力と出力の両方で止める考え方はAIガードレールとはで解説しています）。

5. 向かない仕事と既知の弱点

TypeSafeは Jev 1.13の既知の弱点を公開しています。「判断専用だから正確」と考えず、次のように仕事を分けます。

また、別々に聞いたYes/Noの確率が、数学的な関係を満たすとは限りません。同じ条件とその否定を別のNoulで聞いても、合計が1になるとは限らず、Choiceの確率とNoulの確率を同じしきい値で扱うこともできません。質問の形を変えたら、以前の調整値をそのまま使わず評価し直します。

日本語で使う場合の確認点

6. 料金・入力制限・速度の読み方

2026年9月21日に確認した TypeSafeのModelsページでは、現行モデルは jev-1.13.0 でした。2026年10月14日には jev-1.14.0 も公開されています（料金・文脈長は同じ）。10月19日に確認した時点で、別名 jev-latest（安定版）は1.13、jev-preview は1.14を指します。別名は新しい版が出ると切り替わるので、結果を安定させたいなら版つきのIDを指定します。料金は入力100万トークン当たり0.042ドルで、出力トークンは無料です。問い合わせ1件当たりの固定料金ではなく、stateとquestionsを含む入力のトークン量で変わります。規模の目安として、公式Quick startの応答例（英語3文の問い合わせに質問3つ）では usage.input_tokens が数百トークン程度と示されています。なお発表でTypeSafeは、この価格が補助によるものでないことは現時点では証明できず、持続できるかは長い目で示すしかないと書いています（価格は上がるより下がると見込んでいます）。

64kと32kの二重制限

入力はテキストのみです。画像・音声・動画は直接渡せないため、別の処理で文字や構造化データにする必要があります。

レート制限は変わりうる

レート制限は組織ごとに決まり、自分の組織の上限は開発者コンソールで確かめます（2026年10月19日時点のModelsページ。以前は固定の数値が載っていました）。単位は毎秒のトークン数と毎秒のリクエスト数で、どちらかを超えると 429 Too Many Requests が返ります。公式SDKは既定でバックオフしながら再試行し、応答に retry-after ヘッダがあればそれに従います。HTTP APIを直接呼ぶなら、前掲のとおり待ち時間を延ばしながら再試行する処理を自分で書きます。

公式は、需要が非常に大きいため上限を動的に調整しており、予告なく変わることがあると注記しています。より高い上限はカスタム契約・エンタープライズ契約で用意されています。大量の文章を一度に流す設計なら、着手時点の値を確認し、上限に当たったときの待ち方を決めておきましょう。

速さ・安さは、同じ仕事で比較する

TypeSafeは発表で、リクエストから結果が返るまでの時間を70ms〜500msとしています。ただし同社の公開評価は、主に米国西海岸（サービスの拠点）にある同社のノートPCから実行したものです。

生成モデルとの比較では「193.6倍速く、444.6倍安い」という数字を掲げています。これは同社が作ったワークフロー評価によるもので、TypeSafe自身、実際に得られる改善の中では高めの側だろうと見込んでいます。評価用のワークフローは自社に有利になるよう選んだものではなく学習データにも含まれないとしつつ、自社のモデル能力チームのメンバーが作ったため偏りがありうるとも書いています。どちらもベンダー自身の数字として読み、次の点に注意して自分の仕事で比べてください。

• 条件が変わると結果も変わる：通信距離、入力の長さ、質問数、比較モデルの設定をそろえて見る。
• 普段のチャットとの倍率比較には使えない：公式の比較には、生成モデルから確率分布を取り出すための処理も含まれている。

実際に比べる項目

費用：API単価 ＋ 運用の手間

前処理・再試行・確認待ちの割合も含める。分類が安くても、人の確認が増えれば全体の手間は減らない。

速度：平均 ＋ 遅いリクエスト

混雑時や応答が遅いときにも、仕事が止まらないか確認する。

7. 試すときに確認すること

最初は Playground で、質問の基準が伝わるか試します。公式Quick startにはPlaygroundとAPIキーを取得して呼ぶ手順があります。早期アクセス中なので、まずログイン後に利用権限を確認してください。

評価で押さえる4つのこと

1. 01

   正解と境界を用意する。

   人が担当を決めた例に加え、複数の依頼、短すぎる文、否定、誘導文を含めます。実データを使う際は、外部へ送ってよい内容かを確認します。

2. 02

   質問の基準を固定する。

   何をもって各候補とするかを書き、「その他」へ回す条件も定めます。基準の調整に使った例とは別の例でも確かめます。

3. 03

   正解率と確認待ちの割合を一緒に見る。

   しきい値ごとに自動処理した件数と、その中の誤判定件数を数えます。確認待ちの量も併記し、精度だけを高く見せないようにします。

4. 04

   モデルと質問を記録する。

   モデルID、入力の種類、質問の版、返答、処理時間を残し、変更前後を比較します。

この記事の前提：TypeSafeの発表と公式ドキュメント（2026年9月21日確認、10月19日に更新を確認）をもとにしています。筆者はAPIを実行しておらず、日本語での精度や実際の待ち時間は測っていません。

FAQ

Q. JevはChatGPTのように会話できますか？
A. 自由な返信文を生成するモデルではありません。文章を入力し、Choice・Score・Noulで決めた形の判断を受け取る用途です。返信文や説明文が必要なら、生成モデルやテンプレートと組み合わせます。

Q. 「ハルシネーションがない」なら間違えませんか？
A. 型や候補に出力を制約することと、内容を正しく判断することは別です。公式にも計算、日付、無関係な情報が多い入力、誘導する文章などの弱点が掲載されています。自分のデータで正確さを測る必要があります。

Q. Noulの0.5は中程度という意味ですか？
A. YesとNoを同程度の確率で評価しているという意味です。深刻度や品質の中間を表す値ではありません。程度を測るなら、説明付きの段階を定めるScoreが候補になります。

Q. 日本語でも使えますか？
A. 公式はCJK文字を含む言語の入力を扱えるとしていますが、英語が主な学習言語で、精度も現状は英語が最もよいと説明しています。業務で使う前に日本語の評価用データで確かめてください。

Q. 画像や音声の判定にも使えますか？
A. 現行モデルの入力はテキストのみです。画像や音声を直接渡すことはできません。別の処理で得た文字や構造化データを渡す設計なら、その前処理の誤りも含めて評価します。