Jevとは｜TypeSafe AIの仕組み・LLMとの違い・料金と使い方

業務システムにAIを組み込むとき、必要なのは長い文章ではなく「この問い合わせはどの部署か」「この請求書は自動承認してよいか」といったひと言の判断であることが少なくありません。それでも大規模言語モデル（LLM）は文章を生成する前提で作られているため、JSONで返すよう指示し、文字列を解析し、想定外の形式に備える、という往復が要ります。

TypeSafe AIが2026年9月にアーリーアクセスを開始した「Jev」は、この往復そのものをなくす方向に振ったモデルです。文章を一切生成せず、あらかじめ定義した選択肢・採点・確率だけを返します。

01.結論

Jevは「速くて安いLLM」ではなく、用途を判断処理に絞った別カテゴリのモデルです。既存のワークフローを丸ごと移すのではなく、LLMに任せている処理のうち答えが有限の選択肢に収まる部分だけを切り出して置き換える、という使い方が前提になります。

何を渡すと何が返るのかを先に置きます。公式のAPIリファレンスにある最小の例で、判断材料の文章と、聞きたいこと1つを渡す形です。

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "Does this convey urgency?"
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": {
      "type": "noul",
      "noul": 0.95
    }
  },
  "usage": { "input_tokens": 296, "output_tokens": 20 }
}

「支払いが3日間失敗し続けている」という文面に緊急性を伝えているかを聞き、0.95が返っています。理由の説明も要約も付きません。質問に付けた名前がそのままanswersのキーになるので、呼び出し側はanswers.is_urgent.noulを読んで分岐を書けます。この「文章を読ませずに値だけ受け取る」形が、速さ・安さ・型の保証すべての前提です。

日本語での精度は公式の記述だけでは判断できないため、同じ問い合わせを日本語と英語で実際に投げて比べました。結果は日本語と英語で同じ内容を投げて比べた結果にあります。

02.Jevとは｜System Oneモデルという新しい区分

「System Oneモデル」という区分は、公式ドキュメントのSystem Oneの説明によると、ソフトウェアが直接使える速く構造化された判断を行うために作られたAIモデルを指します。LLMと同じように自然言語の入力を理解しますが、生成された文章ではなく型付きの判断と確率を返します。名称はダニエル・カーネマンの著書『ファスト＆スロー』で知られる「システム1（速く直感的な思考）」に由来すると同ページに記載されています。

製品名の由来も公表されています。同社の発表ブログは、蒸気機関の効率が上がった結果かえって石炭の消費が増えたのと同じ道を機械の知能もたどると述べ、知能のコストが一桁下がるたびに用途はそれ以上に増えると見ています。判断の単価が下がれば判断の回数が増える、という想定です。

その延長にある設計思想が、公式ドキュメントのAI入門ページの「Machine Native Intelligence（機械にとって自然な知能）」です。同ページは大規模な自動化の99%が機械どうしのやり取りになると想定し、設計目標を読んで心地よい応答から、ソフトウェアの中で予測どおりに振る舞う出力へ移したと述べています。

03.LLMとの違い｜文章を作らず、決めた型で返す設計

最も大きな違いは、答えの作り方です。LLMはトークンを1つずつ生成するため、答えの長さに比例して時間がかかります。公式ドキュメントの導入ページによると、Jevは判断材料（state）に対して質問（question）を並列に評価し、型付きの値と確率分布を直接返します。各質問は同じstateに対して独立に評価されるため、質問を増やしても応答時間はほとんど変わらず、質問どうしが互いの精度を落とすこともないと同ページは説明しています。

この構造の結果として、公式は2つの保証を挙げています。発表ブログは型エラーがゼロであることと、定義した答えの外を返さないことを、アーキテクチャ上の保証として説明しています。ただしこれは「答えの形が崩れない」保証であって、「判断が正しい」保証ではありません。同社のSystem Oneの説明ページも、較正は予測の集団に対して測られるものであり、個々の答えが正しいことを保証しないと明記しています。LLMで起きる事実の取り違えに相当する誤りは、Jevでも「選択肢の選び間違い」として起こります。

LLM側で同じ誤りがなぜ起こるのかはハルシネーションとは｜なぜ起こり、なぜ完全には防げないかで整理しています。

「LLMの構造化出力で足りるのでは」という疑問

LLMにもJSONスキーマを指定して型どおりに返させる機能があるのだから同じではないか、という疑問は当然出ます。TypeSafe自身も構造化出力との違いを公式サイトのよくある質問で説明しています。違いは出力の形ではなく、そこに至る計算の仕方です。構造化出力は文章を1トークンずつ作る過程に制約をかける仕組みなので、選択肢を1つ選ぶだけでも文章生成と同じ計算と待ち時間がかかります。Jevは文章を作る工程自体を持たないため、質問を増やしても待ち時間がほとんど変わりません。

もう1つの違いは確率です。構造化出力で返るのは選ばれた値だけで、他の選択肢がどれくらい競っていたかは分かりません。Jevは確率分布と信頼度を同じ応答に含めるため、しきい値で自動処理と人手を分ける設計がそのまま書けます。裏を返せば、質問が1回で待ち時間も気にならず確率も使わないなら、既存の構造化出力で足ります。

04.仕組み｜RLCDと「較正された確率」

Jevの学習方法はRLCD（Reinforcement Learning for Calibrated Decisions／較正された判断のための強化学習）と呼ばれます。公式のAI入門ページは、事前学習済みモデルの後段の学習を3系統に整理しています。

ただしRLCDは、RLHFやRLVRのように学界で定着した呼称ではなく、TypeSafeが自社の学習方法に付けた名前です。手法の詳細も査読論文も公開されておらず、外部から再現できません。上の表は対等な技術分類ではなく、同社が自社の位置づけを説明するために置いた対比として読むのが正確です。

ここで言う較正（キャリブレーション）とは、モデルが出す確率が実際の的中率と一致している状態です。同ページは、よく較正されたモデルなら確率0.2を付けた事象はおよそ20%、0.8を付けた事象はおよそ80%の頻度で起きると説明しています。

RLHFの副作用として同ページが挙げるのがモード脱落（mode dropping）です。人の好みに合わせて最適化すると特定の言い回しに偏り、人には説得力があるのに自動処理には信頼できない出力が生まれる、というのが同社の主張です。較正の考え方と事後補正の手法は確率較正（キャリブレーション）の基礎｜事後較正とVertex AIでの運用で扱っています。

弊社記事による、確率較正の実地検証

「高い確率が付いた答えほど実際に正しい」はJevの中心的な主張なので、実際に測りました。題材は弊社の記事で、タイトルとリード文だけを渡し、載っているカテゴリを当てさせます。正解は編集部が実際に付けているもので、後から作った正解ではありません。掲載数の多い上位6カテゴリの164本が対象です（2026年9月21日、jev-latestが返したjev-1.13.0、計252回の呼び出し）。

全体では正答率71.3%に対して平均confidenceが0.886で、どの帯でも信頼度のほうが実際の正答率を上回りました（帯ごとの差を件数で重み付けした値は0.173）。確率どおりなら差は0に近づくはずなので、この結果だけを見ると較正できていないことになります。

ところが誤答の中身を見ると話が変わります。最多は「AI × 開発効率化」を「AI・AIエージェント活用 基礎知識集」と答えたもので15件、次が「AI × 業務活用」を同じく答えた9件でした。いずれも当方のカテゴリの定義が重なっているために起きています。コーディング支援エージェントの記事は当方の分類では「開発効率化」ですが、「AIエージェント活用」とも読めます。Jevが判断を外したというより、答えが1つに決まらない問いを、決まるものとして渡していました。

そこで互いに重ならない3カテゴリ（SEO・AI検索／AI × データ分析／メディア運用・コンテンツ制作）に属する88本だけで、選択肢もその3つに絞って同じことをやり直しました。

正答率は92.0%、平均confidenceは0.916で、どの帯も信頼度と実際の正答率の差が0.08以内に収まりました（重み付けした差は0.019）。0.95以上を付けた72件は実際に98.6%当たり、0.60未満を付けた9件は44.4%しか当たっていません。確率を額面どおり受け取ってよい状態です。

05.3つの質問型｜Choice・Score・Noul

Jevに聞けることは3種類に限定されています。公式ドキュメントのPrimitivesページは、これらを「AIプリミティブ」と呼び、3種類を1回の呼び出しに混在させられると説明しています。

Choice｜選択肢から1つ選ぶ質問

担当部署、商品カテゴリ、対応方針といった分類に使います。公式のChoiceページは、選択肢を絞り込まずに全リストを渡すよう勧めています。選択肢1つあたりのコストが数トークン程度だからです。どれにも当てはまらない入力があるなら、「その他」にあたる選択肢を用意して、モデルが「どれも合わない」と言えるようにします。

Score｜順序のある段階で採点する質問

不満度、緊急度、リスクの高さのように程度を測るときに使います。公式のScoreページによると、criteriaには低い側から高い側へ並べた段階の説明を配列で渡します。同ページははっきり区別できる数だけ段階を作ることを推奨し、3段階でも十分だとしています。返るscoreは段階の期待値にあたる小数で、同ページの例では1.43や1.26が返ります。

Noul｜真である確率を返す質問

「返金を求めているか」「規約違反にあたるか」のように、真偽で答えられる判定に使います。公式のNoulページによると、確率そのものが答えにあたるためNoulにはconfidenceが付かず、0.5に近い値は真と偽がほぼ同じ確からしさであることを表します。

06.使い方｜APIの呼び出しと信頼度による振り分け

APIの呼び出し

判断を求める呼び出しは、1つのエンドポイントに集約されています。公式のクイックスタートによると、POST https://api.typesafe.ai/v1/systemoneにBearer認証でstate・model・questionsを送る形です。次は、問い合わせ1件に対して担当部署・不満度・緊急性の3つを同時に聞く例です。

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "3日前からStripe連携が失敗し続けています。売上が止まっていて困っています。",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "どのチームが対応すべきか",
        "criteria": {
          "billing": "支払い・サブスクリプションの問題",
          "technical": "不具合や連携の問題",
          "sales": "料金やアカウントに関する質問"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "顧客がどの程度いらだっているか",
        "criteria": ["落ち着いて事実を述べている", "不満はあるが冷静", "強い言葉を使って怒っている"]
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "このメッセージは緊急性・時間的制約を伝えている"
      }
    }
  }'

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.67,
      "probabilities": { "technical": 0.78, "billing": 0.22, "sales": 0.0 }
    },
    "frustration": {
      "type": "score",
      "score": 0.9,
      "confidence": 0.85,
      "legend": { "0": "落ち着いて事実を述べている", "1": "不満はあるが冷静", "2": "強い言葉を使って怒っている" },
      "probabilities": { "0": 0.1, "1": 0.9, "2": 0.0 }
    },
    "is_urgent": {
      "type": "noul",
      "noul": 0.96
    }
  },
  "usage": { "input_tokens": 505, "output_tokens": 73 }
}

質問名がanswersのキーになり、その下に型ごとの値が入ります。Noulだけはnoulの1値で信頼度が付きません。前掲のAPIリファレンスは、認証失敗の401、検証失敗の422、レート制限の429、過負荷の529というエラーを定義しており、429と529は指数バックオフでの再試行が推奨されています。

信頼度による自動処理と人手の線引き

実運用で要になるのが信頼度（confidence）の扱いです。公式のConfidenceページはconfidenceを確率分布の形を0〜1に要約した値と定義し、高ければ自動実行、中程度なら確認を挟む、低ければ人に回すという3段階を出発点に挙げています。しきい値は1つに固定せず処理の影響の大きさで変えるべきで、残高照会のような取り消しのきく操作は低めでよく、送金の承認には高いしきい値と確認を置く、という設計です。なお応答には確率分布（probabilities）そのものも含まれるため、confidenceが合わない用途では自前の指標に差し替えられます。同ページは保守的な値から始めて自社データで調整することを求めています。

07.料金・レート制限・コンテキスト長

料金と制限は公式のモデル一覧ページに公開されています。2026年9月18日時点の現行モデルはjev-1.13.0で、jev-latestとjev-previewという2つの別名が用意されています。

レート制限には、需要が非常に大きいため上限が予告なく変わりうるという但し書きが付いています。引き上げはカスタムプラン・エンタープライズプランでの相談です。別名は新しいリリースで指す先が移るため、しきい値を特定のバージョンに合わせているなら、別名ではなくバージョン付きのIDを指定して移行時期を自分で決めるよう推奨されています。

判断材料が長いときの渡し方

判断に長い前提が要るときも、stateに全文を積む方向には進めません。上限に当たる前に精度のほうが先に落ちるためで、公式は無関係な情報が多いstateを失敗パターンの1つに挙げ、その対処まで示しています。

広い判断は、1つの大きな質問にまとめず小さく分けます。質問は同じstateに対して並列に評価されるので、分割による待ち時間のコストはほぼありません。判断材料が日本語なら同じ内容でもトークンが英語より増えるため、絞り込みの効果は英語で使う場合より大きく出ます。

向かないのは、1回の呼び出しのstateに長い文書を丸ごと詰めて、その中から根拠を探させる使い方です。検索そのものをJevの外に置くという意味ではありません。公式が用途の5分類で挙げる巨大なコーパスからの検索は、短く区切った候補を大量に判定するmap-reduce型で、1回のstateを長くする形ではないからです。

08.公表ベンチマークと、その読み方

総合スコアと、その読み方

TypeSafeは評価結果を専用サイトで公開しています。セキュリティインシデント、エージェント実行ログの確認、請求書処理、カスタマーサービスの4ワークフローを同じ重みで平均した結果が次の数値です。評価サイトはワークフローとして構造化した場合と単一のプロンプトで解かせた場合の2通りを公開しており、ここではワークフロー側の9構成を正答率順に並べます（プロンプト側は後述）。

正答率だけを見ればJevはGPT-5.6 Terraと同水準で、上位の推論モデルには届きません。コストと時間の差は比較対象で変わります。正答率がほぼ同じGPT-5.6 Terraと比べると、コストは約76分の1、所要時間は約25分の1です。正答率が1.0ポイント低いかわりに安価なGPT-5.6 Lunaと比べても、コストは約8分の1、所要時間は約32分の1です。同社が掲げる193.6倍高速・444.6倍低コストは、速度をClaude Sonnet 5、コストをClaude Opus 5と比べた値です。所要時間が最長のDeepSeek v4 Pro（86.5秒）と比べれば、差はさらに開きます。倍率は比較対象で変わるので、自社が置き換えたいモデルを決めてから見る必要があります。

ワークフロー別の内訳

平均だけでは自社の用途に当てはめにくいので、内訳も見ます。

カスタマーサービスでは最上位のモデルと2.3ポイント差まで迫る一方、請求書処理では17.3ポイント離されます。平均の67.8%を見て「どの判断でも同じように使える」と読むと、用途によっては見込みが大きく外れます。金額や日付の扱いが絡む処理ほど差が開くのは、次の章で触れる苦手なパターンとも一致します。

この数値の前提

分類タスクを正答率だけで測れない理由は予測モデル評価の指標と使い分け｜分類のF1・回帰のRMSE・相関のPearsonで整理しています。

09.苦手なこと｜公式の9パターンと実測の揺れ

公式が開示する9つのパターン

TypeSafeは現行バージョンの失敗パターンをjev-1.13で確認されている弱点の一覧ページで自ら公開しています（最終レビュー日は2026年9月17日）。導入前に確認する価値が高いので9件すべて整理します。

このうち、stateに外部から入り込んだテキストが判断を動かしうる問題の全体像はプロンプトインジェクションとは｜仕組み・直接型と間接型・なぜ防ぎきれないかで扱っています。

質問をまたいだときの数値の不整合

もう1つ、設計に影響する項目として構造的な整合性が保証されない点が挙げられています。同ページは実測値を2つ示しています。1つは、同じ「返金を求めているか」という問いを、Noulと、Choiceの二択とで聞き比べた例です。比較できるはずの数値が大きく食い違いました（Noulが0.22に対してChoiceのyesが0.01）。もう1つは、ある問いとその否定形を別々のNoulで聞いた場合に、確率の合計が1にならなかった例です（0.72と0.47で合計1.19）。Noulで調整したしきい値をChoiceにそのまま持ち込まない、複数の質問の間で算術的な整合を前提にしない、という運用が必要です。

同じ入力でも変わる確率とconfidence

公式の一覧には無い挙動として、編集部で試した範囲では同じ入力を繰り返し送っても返り値が完全には一致しません。10組を各条件で複数回実行したところ、選ばれた選択肢は安定する一方、確率とconfidenceは呼び出しのたびに動き、振れ幅は平均0.012・最大0.05でした。選択肢が変わったのは、後述する日英比較で判断が割れた1組（confidenceが最も低かったもの）だけです。振れ幅は小さいものの、しきい値の境目に張り付いた案件は、同じ入力でも自動処理と人手に振れます。判定のキャッシュやしきい値の余裕で吸収し、テストの期待値も完全一致ではなく範囲で書いてください。

10.日本語で使うときの注意

日本語で使う場合は、公式が示す精度の前提から確認します。公式のモデル一覧ページは、Jevが受け付けるのは自然言語のテキストであるとしたうえで、主要な学習言語は英語であり、現時点で精度が最も高いのも英語であると明記しています。日中韓（CJK）の文字体系を含むそれ以外の言語も扱えますが、英語と同等ではないとされています。非英語のワークロードで使う前に自社のコンテンツで検証すること、振り分け時にconfidenceへ注意を払うことが、あわせて求められています。

公式が求める検証とconfidence運用を、日本語データで具体化すると次の手順になります。

質問文の言語は公式が明示していないため、自社データで比較して決める扱いです。stateに渡す業務データは日本語のままにせざるをえない場合が多いので、その条件でどう出るのかを編集部で小さく測ってみました。

日本語と英語で同じ内容を投げて比べた結果

意味の対応する日本語と英語のサポート問い合わせを10組用意し、使い方と同じ3問（担当部署・不満度・緊急性）を投げました。本文の言語と質問文の言語を独立に入れ替えた4条件で、各条件とも同じ入力を複数回実行しています。実施日は2026年9月21日、モデルはjev-latestが返したjev-1.13.0で、API呼び出しは計104回です。内訳は、4条件の比較に使った延べ100レコード（10組×10回）と、後述する固定ぶんのトークン数を測るための4回です。ここで言う「一致」は、担当部署の判定があらかじめ人手で付けた想定ラベルと同じだったかどうかです。

10組の内容は同じなので、日本語と英語で判定が割れるかどうかも見られます。担当部署の判定が一致したのは10組すべてで、所要時間も東京から呼んで100回の平均0.419秒（中央値0.408秒・最大0.694秒）と、言語による違いはありませんでした。

想定ラベルと違ったのは4条件を通じて同じ1組、「APIのレート制限を引き上げてもらえますか」だけでした。上位プランへの相談とみてsalesを想定ラベルにしていましたが、Jevはbillingを返しています。この1組は、confidenceが4条件すべてで突出して低く、全100レコード中の下位10件を占めました。confidenceが0.3未満の延べ10レコードはすべてこの1組で、0.3以上の延べ90レコードにはズレが1件もありません。しきい値を0.5に緩めても拾えるのは同じ1組で、人手に回る延べ件数だけが10から14に増えます。

ただし、この結果を適合率・再現率のような指標で語ることはできません。想定ラベルとズレた延べ9レコードは、すべて同じ1組を繰り返し実行したもので、独立した9件の誤りではないからです。独立した事例で数えれば「10組のうち1組」で、しきい値を評価できる母数ではありません。言えるのは「判断が割れる1組を、Jevは4条件のどれでも・何度実行しても最低のconfidenceで申告した」までです。1本につき1回だけ呼んで同じ関係を見たものが弊社記事による、確率較正の実地検証です。しきい値の決め方そのものは別記事で扱っています。confidenceのしきい値を自社データで決めるときは、適合率（Precision）と再現率（Recall）｜しきい値設計とF1スコアの使い分けもあわせて参照してください。

日本語で増えるトークンの内訳

費用面でははっきりした差が出ました。質問セットを英語に固定して本文だけ入れ替えると、入力トークンは日本語の本文が平均33.3トークン、英語の本文が平均16.2トークンで、同じ内容でも日本語は約2.06倍です。ただし短い入力では固定ぶんが支配的で、質問1問・本文1文字の最小構成でも272トークンかかります。条件ごとの入力トークンが400〜500台に収まるのはそのためです。

もう1つ、質問文を日本語で書くとその分だけ課金対象が増えます。今回の3問では英語より78トークン多く、呼び出しのたびにかかります。一方で一致件数は4条件とも9/10で、日本語にして精度が上がった形跡はありません。この結果だけを見るなら、instructionsとcriteriaは英語で書き、業務データである本文だけ日本語で渡すのが、精度を変えずにコストを下げる書き方です。日本語特有の言い回しをcriteriaに書きたい場合は別なので、ここも自社データで比較してください。

11.LLM・従来の分類器との使い分け

向き不向きは判断の性質ではっきり分かれます。判断材料が自然言語であること、答えの選択肢が事前に決まっていること、同じ判断が大量に繰り返されること。この3条件が揃うほど適します。

公式が挙げる用途の5分類

公式のユースケース一覧ページは用途を5つに整理しています。条件分岐だけを想定していると見落とす用途が含まれます。

このうち大規模データの一括処理（map-reduce＝大量のデータを分割して判定し、結果をまとめる方式）とリアルタイム用途は、条件分岐という言葉から想像しにくい使い方です。前者はデータセット全体を特徴量に変換する使い方で、料金・レート制限・コンテキスト長の「出力トークンが無料」がそのまま効きます。後者はリクエスト処理に同期で挟む使い方です。

同ページは業種別の例も挙げています。上の表と重なるもの（モデルルーティング・ガードレール・特徴量抽出）を除くと、残るのは4つです。検索と再ランキング（RAG の埋め込みの置き換え・補強）、コードと文章の意味的なlint、採用・リード獲得・カスタマーサポート、保険金請求と金融犯罪の検知です。

置き換え先の見つけ方

既存のワークフローで置き換え先を探すなら、LLMへ「JSONで返して」と指示している呼び出しを洗い出します。そこで求めているのが選択肢・段階・真偽のいずれかなら、Jevの3つの質問型にそのまま対応します。社内AIで何を選ぶかという上流の判断はファインチューニング・RAG・プロンプトの使い分け｜社内AIで何を選ぶかで整理しています。

判断理由が残らないことの扱い

判断理由の文章が返らない点は、監査や説明責任が求められる領域では制約になります。記録として残せるのは、選ばれた値・確率分布・信頼度・回答したモデルのバージョンIDです。呼び出しごとにこれらを記録して品質の変化を追う仕組みは別記事で詳しく整理しています。あわせてご覧ください。

12.始め方と対応サービス

クイックスタートのとおり、最初に触るのはブラウザのプレイグラウンド（console.typesafe.ai/playground）です。判断材料になる文章を「state」に、聞きたいことを「questions」に入れて実行すると、その場で返り値が表示されます。APIキーの発行はconsole.typesafe.ai/keysです。

公式ドキュメントに記載が無く、実際に叩いて分かった点もあります。認証の失敗は2種類に分かれます。キー未送信なら403でMust supply an API key!、キーが通らないなら401でCannot authenticate with the server.です。APIリファレンスは認証失敗を401としか書いていないため、Authorizationヘッダの付け忘れを401だと思って探すと遠回りになります。

提供元の告知によると、全利用者に5ドル（約1億2000万トークン相当）のクレジットが付きます。弊社のアカウントでも作成時点で Credit Balance は5ドルでした。§07の単価（入力100万トークンあたり0.042ドル）で割ると約1億1900万トークンで、公表値とほぼ一致します。この記事の計測では1回あたり400〜500トークンだったので、この5ドルの範囲だけで20万回以上は試せる計算になります。

またGET https://api.typesafe.ai/v1/modelsが返すのはjev-latestとjev-previewの2つだけです。いずれもrelease_dateは2026年9月10日です。レスポンスに現れるjev-1.13.0はこの一覧には出てきません。バージョンを固定したい場合は、一覧の名前ではなく返り値のmodelを記録しておく運用になります。jev-previewの説明文はA preview version of `jev-latest`: should be better in most waysです。ただしモデル一覧ページは、現時点ではjev-previewもjev-latestと同じjev-1.13.0を指しており、プレビュー版は存在しないと明記しています。プレビュー版が出たときに先行する枠、という位置づけです。

SDKからの呼び出し

公式のクライアントは、SDKページによるとPythonとJavaScriptの2種類です。いずれも環境変数TYPESAFE_API_KEYを読み、質問の型に応じた戻り値を返します。Python版は同期・非同期の両クライアントと再試行ポリシーを備えます。

pip install typesafe-sdk

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

with TypeSafeClient() as client:
    response = client.system_one(
        state={"document": "3日前からStripe連携が失敗し続けています。売上が止まっていて困っています。"},
        questions={
            "billing": Noul(instructions="この問い合わせは支払いに関するものか"),
            "tone": Choice(
                instructions="顧客の語調はどれに当たるか",
                criteria={"calm": None, "frustrated": None, "angry": None},
            ),
            "urgency": Score(
                instructions="この問い合わせの緊急度",
                criteria=["急がない", "今週中", "今日中"],
            ),
        },
    )

print(response.nouls["billing"].noul)
print(response.choices["tone"].choice)
print(response.scores["urgency"].score)

この例のChoiceは選択肢の説明を省いています。APIリファレンスのChoiceの定義がcriteriaの値を「説明またはnull」としており、選択肢名だけで意味が明らかなら省略できるためです。判断が分かれる選択肢や境界事例があるなら、curlの例のように説明を書いたほうが精度が安定します。

JavaScriptから使う場合はnpm install @typesafe-ai/sdkでインストールし、JavaScript SDKページによるとNode.js 20以降が必要です。質問の定義から戻り値の型が推論されるため、TypeScriptでは回答の取り出しに型が付きます。

ゲートウェイ経由での利用

TypeSafeのAPIを直接呼び出さずに使える経路も広がっています。

エージェント向けの公式スキル

Claude Code・Codexなどに組み込む公式スキルも配布されています。3つの質問型・設計パターン・評価の組み立て方をエージェント側に渡すもので、配布元はtypesafe-ai/skills、リポジトリのLICENSEファイルはMITライセンスです。

# Claude Code のプラグインとして入れる
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

# それ以外のエージェント
npx skills add typesafe-ai/skills --skill typesafe-ai

公式は導入方法を1つに絞るよう明記しています。両方入れると同じスキルが二重に入るためです。更新はプラグインならclaude plugin updateのあと/reload-plugins、skills.sh経由ならnpx skills updateです。Claude Codeでは/typesafe:typesafe-aiで直接呼び出せますが、どのエージェントでも「TypeSafeのスキルを使って」と書けば読み込まれます。

実装に直接関わる注意点は次の3つです。

• 質問文としきい値の定数を1つのファイルにまとめます。人がレビューすべきなのはそこだけで、散らばると追えなくなるためです。
• エージェントは質問文を書くのが得意ではありません。共同で直す前提に立ちます。
• しきい値を置きすぎないようにします。最も良い選択肢を選びたいだけならconfidenceのしきい値ではなく最大値を採ればよく、統計的な処理をしたいならconfidenceではなく確率を使うべきだと案内されています。振り分けが意図どおり動かないときは、しきい値が高すぎて取りこぼしているのか低すぎて拾いすぎているのかを先に切り分けます。

13.類似サービス

Jevと同じ入出力の形を公開モデルで再現する独立プロジェクトが、発表直後から複数現れています。いずれも小さな公開モデルに文章を作らせず、選択肢に対応するトークンの確率を直接読んで選ばせる方式です。

ただしこれらはJevの代わりにはなりません。自社環境で動かす必要がある案件で検討する価値はありますが、同じ精度を前提にせず、同じ考え方を手元で確かめる実装として見るのが実態に近いところです。LLMや従来の分類器との比較は第11章で整理しています。

14.よくある質問（FAQ）

15.まとめ

Jevは、AIに文章を書かせる前提を外し、判断と確率だけを返す設計に振ったモデルです。選択肢・段階・真偽の3つの型で聞ける範囲に用途は限られますが、その範囲では待ち時間もコストも桁違いに小さく、答えの形が崩れないことがアーキテクチャ上保証されます。他方で判断の正しさは保証されず、公表ベンチマークも開発元自身が偏りを認めた自社評価です。

検討を始めるなら、出発点は次の3段階です。

どの処理をAIに任せ、どこから人が確認するかの線引きは、モデルの性能だけでなく業務側の許容度で決まります。検証の設計から運用ルールの整備までを自社だけで進めるのは手間のかかる部分です。