TypeSafe AIのJevを調べてみた。GPT・Claude・Geminiと判断の仕方が違う話

ChatGPTの開発に関わった研究者が、文章を生成しないAIを発表したというニュースが気になりました。問い合わせの担当部署を決めたいだけなのに、毎回LLMから文章を受け取る必要があるのか。Jevの資料を読むと、その疑問をかなり突き詰めた設計でした。

今回は公式発表とAPIドキュメントを読み、既存モデルとの違いと業務への使い道を整理します。2026年9月17日時点の調査メモです。JevのAPIを実行した検証記事ではありません。

JevはTypeSafe AIが2026年9月15日に早期アクセスを発表したモデルです。同社を率いるDiogo Almeida氏は、OpenAIでChatGPTの基礎となる研究に関わった人物です。見出しの肩書きより、どんな入出力を持つモデルなのかが気になりました。公式発表

同社はこの分類をSystem One Modelと呼んでいます。自然言語などで状況を渡し、事前に定めた範囲の判断を受け取る仕組みです。返信文やコード、判断理由の文章を生成する機能はありません。System Oneの説明

例えば、問い合わせ本文を渡して担当部署を選ばせる。緊急度を採点する。返金を求めているか確率で答えさせる。その結果をプログラムの条件分岐に使います。私は、既存の業務コードに判断処理を追加するためのAPI、と捉えると理解しやすくなりました。

質問の型は3つです。返答の形を見たほうが、チャットとの違いが分かります。

Choiceは最大255候補を指定できます。Scoreは順序のある評価基準を2〜10段階で定義し、段階の間の値も返します。Noulには独立したconfidenceフィールドがありません。Choice、Score、Noul

複数の質問は、同じ入力に対して独立に並列評価されます。ただし、同じ呼び出しの質問Bが質問Aの答えを読んで判断するわけではありません。依存する処理は、呼び出しを分けるか、返ってきた結果をコードで組み合わせます。Introduction

ここは使い方にも影響しそうです。担当部署、緊急度、返金希望の有無を先にまとめて聞く。その後で、必要な結果だけを使って処理を分ける。業務全体を一つの長い指示に押し込むより、質問とルールを分けて設計することになります。

最初に引っかかったのは、型を守るだけなら既存のLLMでもできるのでは、という点でした。実際に各社の資料を確認すると、そこは既に機能があります。

各行は対応モデルでの機能を比較したものです。全モデル・全スキーマへの無条件の対応を意味しません。OpenAI公式、Anthropic公式、Google公式

そのため、従来モデルは文字列しか返せず、Jevだけが型を扱える、という比較では不十分だと思います。Jevの特徴は、自由な文章生成を提供せず、限定された判断と確率を直接返すことに設計を集中させた点です。

既存モデルでも確信度の数値を出すことはできます。ただ、JSONのconfidence欄を埋められることと、その値が実際の正答率に対応していることは別です。TypeSafeは後者を狙う学習方式をRLCDと呼んでいます。例えば、確率0.8と予測した事例群で、およそ8割がその結果になるような性質です。個別の判断が正しいという保証ではありません。AI primer

なお、Jevのconfidenceは確率分布から計算した指標です。confidence: 0.9を、そのまま正答率90%と読むこともできません。運用するなら、候補ごとの確率と、自社データでの実際の正誤を照合する必要があります。Confidence

公式サイトには強い表現が並びますが、型が正しいことと、業務上の判断が正しいことは分けて考えたいです。

例えば候補をbillingとtechnicalに限定すれば、存在しない部署名を返す問題は防げます。それでも、技術的な相談をbillingに振り分ける誤りは残ります。候補の設計が悪ければ、適切な答えを選ぶこと自体ができません。

問い合わせ分類ならotherやneeds_reviewも用意しておきたいです。TypeSafeも、選択肢で入力を網羅できない場合は、その他に相当する候補を追加するよう案内しています。Choiceの設計指針

また、型が合っていても、入力にない事実の推測や、誤った前提に基づく判断まで消えるわけではありません。Googleの構造化出力の説明も、形式の保証と値の意味的な正しさを区別しています。これはJevと既存LLMの両方を見るときに残しておきたい区別です。Googleの注意点

公式サイトの表示は193.6倍高速、444.6倍低コストです。料金は入力100万トークンあたり0.042ドルで、公式発表では出力は無料とされています。提供元による測定・料金であり、すべての業務で同じ倍率になるという意味ではありません。TypeSafe公式サイト、公式発表

公開評価は、セキュリティ対応、エージェント実行の確認、請求書処理、顧客対応の4種類です。正解の基準は人が確定した業務上の正解ではなく、GPT-6 AstraとClaude Fable 5.1の回答を平均したものです。この評価が測るのは、主にその基準との一致度です。Workflow evals

さらに、比較対象のLLMにも確率を含む構造化判断を返させています。ラベル一つだけを返す安価なモデルとの比較ではありません。提供元自身も、短い入力はJevに有利で、測定は主に米国西海岸から行ったと説明しています。評価条件

私なら、今使っているモデルに加えて、小型・高速モデルの構造化出力も比較対象に入れます。同じ入力、同じ候補、同じ許容誤り率で、費用と待ち時間を比べたいからです。ラベルしか使わない業務では、確率を出力するコストを既存モデルに上乗せした比較だけでは判断できません。

DOOMデモについても補足があります。入力は画像ではなく、テキストを含む構造化されたゲーム状態です。毎秒10回の問い合わせを行うデモであり、あらゆる入力で100ms以内を保証するものではありません。公式発表の応答時間の目安は70〜500msです。DOOMデモの説明

ここからは、私が導入を検討するならどう組むか、という設計例です。APIの実測結果ではありません。

最初に、問い合わせと必要な業務情報をstateとしてまとめます。次に、判断させたい項目をquestionsに定義します。公式のHTTP API形式に合わせると、例えば次のようになります。API reference

{
  "model": "jev-latest",
  "state": {
    "message": "決済後にエラーが出ました。請求されたか確認したいです。"
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "一次対応する担当を選んでください。",
      "criteria": {
        "billing": "請求の有無や支払い状況の確認",
        "technical": "操作不具合やシステム障害の調査",
        "needs_review": "情報不足、または担当を決められない"
      }
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "顧客は返金を明示的に求めていますか。"
    }
  }
}

この例なら、請求状況の確認と返金の希望を分けて判断できます。担当の確率が割れたら人へ回す。十分に判別できたものだけ自動でキューに入れる。返金を求めているかどうかは、返金を実行してよいかどうかとは別なので、実行権限や決済記録の確認はコード側に残します。

返信文も必要なら、担当を決めた後でGPT・Claude・Geminiなどに生成させます。Jevが一次判定を受け持つ構成です。ただし、呼び出しを一段増やすことで、全体の応答が遅くなるケースもあると思います。

APIはPOST https://api.typesafe.ai/v1/systemoneです。利用には早期アクセスとAPIキーが必要で、公式にはPlaygroundとSDKの案内があります。今回は公開資料の確認までに留めています。Quick start

問い合わせの振り分けなら、最初に測りたいのは人が手で分類する件数です。誤った自動振り分けを増やさずに、何割を任せられるか。確率で保留を作れるなら、全件を自動化できなくても効果はありそうです。

例えば月10万件のうち6万件を同じ品質で自動分類できれば、人が分類する対象は4万件になります。これは効果の見方を示す仮定で、Jevが6割を自動化できると確認された数字ではありません。誤振り分けの修正時間まで含めて比べます。

費用も試算できます。仮に1件あたりの課金対象入力が、質問や候補を含めて2,000トークンなら、月10万件で2億トークンです。公表単価0.042ドル／100万トークンでは8.40ドルになります。これはJevの入力料金だけの計算です。再試行、後段のLLM、データ取得、運用の費用は別に見ます。公表単価

ほかには、大量のログへの分類付けや、AIエージェントの処理結果を人が見るべきかの一次判定が候補になります。ただ、検査役のAIも間違えます。見逃してはいけないケースを含め、検査を追加する前後で何が改善したかを測りたいです。

日本の業務で試すなら、日本語の省略や曖昧な依頼、社内用語、複数の用件を含む問い合わせを評価セットに入れます。東京の実行環境から測った応答時間の中央値とp95、失敗率、保留率も記録します。自動処理できた割合と、その中での誤り率を一緒に見るつもりです。

資料を読んで面白いと感じたのは、どれだけ長い答えを書けるかではなく、どこまで小さな判断に分けてコードへ戻せるか、という発想でした。ただ、質問の分解や保留条件の設計は、こちらの仕事として残ります。

長い説明、自由な文章抽出、多段の推論が必要な処理は、引き続き汎用モデルが候補になります。まずは既存の問い合わせ分類と並行してJevの結果を記録し、業務には反映しない形で比べたいです。日本語の実データで、人に戻すべき判断をどれだけ拾えるのか。次に確かめたいのはそこです。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

• 選考ではありません
• 履歴書不要
• 技術の話が中心
• 所要時間30分程度
• オンラインOK

エンジニアと話してみる