判断モデル Jev とは？文章を書かない AI の仕組みと使い方

Jev は、TypeSafe AI が 2026年9月15日（米国時間。日本時間では16日）に早期アクセスを開始した「判断専用」の AI モデルです。文章を一切生成せず、あらかじめ決めた選択肢の中から答えを選び、その確率と確信度を返します。問い合わせの振り分けや申請の一次審査のように、コードの中で「どっちに進むか」を決める場面を 1 回の API 呼び出しで済ませるためのモデルです。

Jev とは：型付きの判断を返す System One モデル

TypeSafe AI は Jev を「System One モデル」という新しい分類の最初のモデルとして発表しました。名前は、ダニエル・カーネマンが『ファスト＆スロー』で広めた「システム 1（速く直感的な思考）」に由来します。熟考して文章を組み立てるのではなく、知識のある人が数秒で下せる判断を、速く・安く・型どおりに返すことを狙っています。

共同創業者で CEO の Diogo Almeida 氏は、OpenAI で ChatGPT の基盤になった RLHF（人間のフィードバックによる強化学習）の研究に携わった人物です。公式ブログの発表記事では「チャットモデルは何年も前から人間を超えているのに、自動化はどこにあるのか」という問いから、2 年間のステルス期間を経て Jev を公開したと述べています。

モデル名の Jev は、19 世紀の経済学者 William Stanley Jevons（ウィリアム・スタンレー・ジェヴォンズ）にちなんでいます。蒸気機関の効率が上がると石炭の消費がかえって増えた、という「ジェヴォンズのパラドックス」になぞらえ、知能のコストが桁違いに下がれば使い道も桁違いに増える、という考えを込めたと発表記事の FAQ で説明しています。読み方について公式の表記は見当たらず、名前の由来からは「ジェヴ」に近い音と推測できますが、確定情報ではありません。

入出力の考え方

Jev に渡すのは、評価対象の「state（状態）」と、答えてほしい「questions（問い）」の 2 つです。state には問い合わせ本文・注文データ・社内規程などのテキストや JSON を入れ、questions には「どの部署が対応すべきか」のような問いと、答えの候補を書きます。

返ってくるのは、候補の中から選ばれた値と、候補ごとの確率です。返信文やコード、判断理由の説明は生成しません。公式ドキュメントは、この性質を「LLM と同じく自然言語を理解するが、生成テキストの代わりに型付きの判断と確率を返す」と説明しています。

LLM との前提の違い

Jev は LLM の置き換えではなく、得意な仕事の形が違うモデルです。TypeSafe 自身も、チャットボットやコーディングエージェントのように人が見守る用途は LLM の領域と位置づけています。

表は TypeSafe の発表記事の比較表をもとに編集部で整理したものです（2026年9月18日参照）。

3 種類の問いの型：Choice・Score・Noul

Jev への問いは、答えの形に合わせて 3 つの型から選びます。1 回のリクエストに複数の型を混ぜられ、各問いは互いに影響せず独立に評価されます。

Choice：候補から 1 つを選ぶ

「どの部署が対応すべきか」のように、順序のない選択肢から 1 つを選ぶ問いです。選ばれた choice、候補ごとの probabilities、分布の偏り具合を 1 つの数値にまとめた confidence が返ります。候補は最大 255 個までで、公式ドキュメントは、どれにも当てはまらない入力に備えて other のような候補を足すよう勧めています。

Score：段階のどこに当たるかを測る

「顧客はどの程度怒っているか」のように、段階で測る問いです。「落ち着いている」「不満だが丁寧」「強い言葉で怒っている」のように各段階の意味を書くと、score が段階の間の連続値（例: 1.035）で返ります。

Noul：真偽の確率を返す

「このメッセージは返金を求めているか」のような yes/no の問いです。noul として、答えが yes である確率（0〜1）が返ります。独自の名前ですが、中身は真偽判定の確率と考えれば十分です。Choice・Score と違い、confidence は付きません。

公式ドキュメントは型選びの目安として「コードがそのまま分岐に使える型を選ぶ」ことを挙げています。Choice は if / elif の分岐に、Score はしきい値の比較に、Noul は単純な if にそのまま対応します。

Jev API の呼び出し方

TypeSafe の API はエンドポイント 1 つ（POST https://api.typesafe.ai/v1/systemone）で、SDK は Python と JavaScript が用意されています。API キーの発行は早期アクセスのウェイトリスト経由です。

これとは別に、9月16日（米国時間）には Vercel AI Gateway（モデル名 typesafe-ai/jev）での提供が始まり、Cloudflare Workers AI（モデル名 typesafe/jev）のモデル一覧にも掲載されています。経由するサービスによってコンテキスト長や料金体系が異なる場合があるため（Cloudflare の掲載値は 32,000 トークン）、使う経路のドキュメントで確認してください。

以下はクイックスタートに掲載されているリクエストとレスポンスの例です。

リクエストとレスポンスの例

サポート窓口に届いた問い合わせを state に入れ、担当部署（Choice）・不満度（Score）・緊急性（Noul）を一度に問う例です。

{
  "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": {
    "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"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": [
        "Calm, just stating facts",
        "Frustrated but civil",
        "Very angry, strong language"
      ]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

レスポンスは、問いの ID ごとに型付きの答えが入った 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
  }
}

この例で目を引いたのは department です。Stripe 連携の失敗は技術的な問題とも読めますが、Jev は billing を 0.84 で選びつつ、technical にも 0.159 を残しています。confidence が 0.596 と低めなのはこの迷いの表れで、答えそのものより「どれだけ迷ったか」が数値で取れる点が、文章で返ってくる LLM との使い勝手の違いになります。

Python SDK での書き方

Python SDK（typesafe-sdk、Python 3.10 以上）では、問いを Choice / Score / Noul のオブジェクトで書きます。API キーは環境変数 TYPESAFE_API_KEY から読み込まれ、モデルは既定で jev-latest になります。

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",
        ),
    },
)
print(response.answers["department"].choice)  # "billing"
print(response.answers["frustration"].score)  # 1.035
print(response.answers["is_urgent"].noul)     # 0.999

コーディングエージェント向けには、Agent Skills 形式のスキルも公開されています（Claude Code なら claude plugin marketplace add typesafe-ai/skills のあと claude plugin install typesafe@typesafe-ai）。スキルの仕組みは Agent Skills の解説記事で紹介しています。

確率と confidence で「迷い」を扱う

Jev の設計でいちばん特徴的なのは、答えと一緒に返る確率の扱いです。TypeSafe は RLHF・RLVR に続く第 3 の学習法として RLCD（Reinforcement Learning for Calibrated Decisions）を掲げ、確率が実際の正答率に一致する「較正（キャリブレーション）」を学習の目的にしています。

較正された確率の意味

較正されたモデルでは、確率 0.8 と答えた判断の集まりのうち、およそ 8 割が実際に正解になります。AI primer はこれを「予測の集団についての性質で、個々の答えの正しさを保証するものではない」と明記しています。

発表記事には「Jev はハルシネーションを起こさない」という強い表現もありますが、根拠は出力が必ず定義済みの候補に収まる（型エラーが起きない）ことです。候補の中で誤った選択をする可能性は残るため、確率と confidence を見て扱いを変える設計が前提になります。

confidence による 3 段階の振り分け

Confidence のドキュメントは、confidence を高・中・低の 3 つの範囲に分け、範囲ごとにシステムの振る舞いを変える方法を出発点として紹介しています。さらに、残高照会のように間違えても戻せる操作と、送金承認のように戻せない操作では、しきい値を変えるよう勧めています。

しきい値の具体値について、ドキュメントは「保守的な値から始め、自分のデータで試して調整する」としています。業務ごとに正解データを用意して調整する工程が、導入時の主な作業になりそうです。

設計の考え方：コードが主導し、判断だけを任せる

TypeSafe は Jev を「エージェントを作るためのモデル」ではなく、「AI を組み込んだソフトウェアを作るための部品」と位置づけています。制御フロー・決定的なルール・副作用のある処理はコードが持ち、非構造データの解釈が必要な箇所だけ Jev に問う、という分担です。

小さく分けた問い

How to build with TypeSafe がガイドの中で最も大事な考え方として挙げるのが、問いの分解です。Primitives のページは「このメッセージを分析して最適な対応を決めて」を悪い問いの例に挙げています。返金対応なら、System One の説明ページの例のように「返金を求めているか」「重複請求の証拠があるか」「規程上返金できるか」と 1 つの性質だけを問う形に分け、答えの組み合わせ方はコードに書きます。

問いを増やしても応答時間はほぼ変わらず、追加コストは問いの分の入力トークンだけです。そのため、使うか分からない問いもまとめて投げておき、コード側で必要なものだけ使う「Speculative fan-out」というパターンも紹介されています。

LLM の手前に置く振り分け役

Intent routing のパターンでは、Jev を問い合わせ処理の入口に置き、用件（Choice）と複雑さ（Score）を 1 回で判定します。注文状況はコードで照会し、商品の質問や返品は専門の LLM に回します。クレームは複雑さが高いか判定に自信がないときだけ担当者へ回し、用件自体の confidence が 0.5 未満なら最初から担当者に回す、という構成です。

高価な処理は本当に必要なリクエストにだけ使う、という発想です。LLM を使ったシステムの前段でコストと待ち時間を抑える部品として、既存構成にも足しやすい形だと考えられます。

公式が挙げる Jev 1.13 の苦手分野

TypeSafe はドキュメントに Jev 1.13 の苦手分野（jaggedness）をまとめたページを用意しています（2026年9月17日更新）。設計時に最初に読んでおきたいページで、苦手な入力と代わりの設計が対になって書かれています。

苦手な入力と代わりの設計

同じ意味の問いでも確率は揃わない

特に注意したいのは「問い同士の数学的な整合」です。公式ページの例では、「二重請求されたので確認してほしい」という問い合わせに「返金を求めているか」と「返金以外を求めているか」を別々の Noul で聞くと、確率が 0.72 と 0.47 になり、合計は 1 を超えます。Noul で調整したしきい値を Choice に流用しない、裏返しの問いで検算しない、という設計上の注意として覚えておく必要があります。

料金と制約（Jev 1.13 時点）

料金は入力トークンにのみかかり、出力トークンは無料です。Models のページに記載の仕様を、2026年9月18日時点でまとめます。

jev-latest は新版が出ると自動で切り替わるため、confidence のしきい値を特定の版で調整した場合は jev-1.13.0 のように版を固定して呼ぶよう推奨されています。モデル更新への備え方はモデル更新ラッシュ時代の開発プロセス設計でも扱っています。

導入前に見込んでおくこと

Jev は公開から数日のモデルで、TypeSafe 自身も発表記事で評価の前提を細かく開示しています。前章の苦手分野に加えて、日本の業務で使う前提で見込んでおきたい点を挙げます。

• 日本語の精度: Models のページは、英語が主な学習言語で、CJK を含む他の言語は扱えるが同じ水準の精度ではない、と明記しています。日本語の問い合わせや規程を state に入れる場合は、自社データで精度と confidence の分布を確かめてから本番に載せる必要があります
• 公表値の前提: トップページの「193.6 倍速く、444.6 倍安い」は TypeSafe が作った 4 つのワークフロー評価に基づく値で、発表記事自身が「実運用で得られる効果の上限寄り」と説明しています。判断の正誤は GPT-6 Astra と Fable 5.1 の回答の平均を参照解として測っており、評価用ワークフローはモデル能力チームのメンバーが作ったため偏りの可能性がある、とも開示しています
• 提供形態と応答時間: TypeSafe の API は早期アクセス段階で、レート制限も需要に応じて変わるとされています。公表の応答時間は、サービスの拠点がある米国西海岸から計測した値です。日本から呼ぶ場合は通信の往復が加わるため、自社の環境から計測して見積もる必要があります
• 問いの事前設計: 候補・段階・しきい値を先に決める必要があります。InfoWorld の記事では、HyperFrame Research の Stephanie Walter 氏が、確率が業務上何を意味するかを開発者が決める必要がある点を挙げています。同じ記事で Doozer AI 共同創業者の Paul Chada 氏は、確率は確信の度合いを示しても判断の理由は説明しない、と監査性の観点から指摘しています

どれも設計と検証で扱える種類の論点です。とくに日本語精度は、confidence の低い判定を人に回す構成にしておけば、精度の実測値に合わせて自動化の範囲を少しずつ広げられます。

まとめ

Jev は、LLM が得意な「文章を書く」仕事を手放し、「選ぶ・測る・真偽を判定する」仕事に絞った判断モデルです。

問い合わせの一次振り分けや書類の分類のように、判断の回数が多く、1 件ごとの判断は小さい業務ほど効果が出やすいモデルです。gaipack では、業務プロセスの分析から AI による自動化までを支援する gaipack BPO を提供しています。どの判断を AI に任せ、どこを人に残すかの設計からご相談いただけます。

AI エージェントを含む AI 活用の全体像は AI エンジニアリング5層の進化史で整理しています。あわせてご覧ください。