TypeSafe AI Jevとは｜LLMではない「System One」モデルの仕組み・公式40〜200倍高速の根拠・使いどころを解説【2026年9月速報】

Jev（ジェブ）は、米TypeSafe AIが2026年9月15日に公開した「System One」モデルです。LLMのように文章を書くのではなく、テキスト（state）と型付きの問いを受け取り、「どの選択肢か」「何点か」「Yesの確率は何%か」を確率と信頼度付きの構造化データで即答します。LLMの代わりになるモデルではなく、LLMやエージェントの手前で分類・フィルタ・ルーティングを安く速く片付ける判断部品と考えるのが、現時点での正しい使い方です。

この記事でわかること:

• Jevと「System One」モデルの定義、LLMではないと言われる理由
• Choice / Score / Noul の3つの問いと、並列サンプラー・RLCDの仕組み
• 「20〜200倍高速・40〜400倍低価格」という数字は、どこまでが公式の数字なのか
• 信頼度の「校正（calibration）」が保証すること・保証しないこと
• エージェントの前段に置いてコストを下げる設計例と試算
• 弱点（説明ができない、日本語の精度、プロンプトインジェクション）とセキュリティ上の注意点
• 料金・仕様・使い方、安価なLLMや既存の分類器との違い

想定読者: 問い合わせ振り分け・RAG・AIエージェントのコストやレイテンシに悩んでいる開発者、プロダクトマネージャー、AI導入を検討している情シス・DX担当の方。

• Jevは判断専用のモデル。文章・要約・コードは生成できず、判断の理由も出力しない
• 速度とコストの差は大きい。公式ブログは「同水準の知能でLLMより40〜200倍高速」、自社ワークフロー評価では193.6倍高速・444.6倍低価格と説明している。一方でネット上に広まっている「20〜200倍・40〜400倍」は公式ブログ本文では確認できない
• 強みが出るのは「選択肢を列挙できる」「件数が多い」「結果をコードで処理できる」判断。与信・採用・医療のように説明責任を伴う判断を、Jev単独で自動化するのは避けるべき
• 2026年9月24日時点ではアーリーアクセス（ウェイトリスト制）。日本語は精度が下がると公式が明言しているため、本番前に自社データで検証する必要がある

TypeSafe AI Jevとは — 「System One」モデルの最初の公開モデル

出典: TypeSafe AI公式サイト

Jevは、TypeSafe AIが提唱する新しいモデル分類「System One モデル」の最初の公開モデルです。公式ドキュメントでは、「状況データ（state）と型付きの問いを送ると、コードがそのまま使える構造化された答えを返すモデル」と定義されています。

「System One」はカーネマンの「速い思考」から来ている

「System One」という名前は、心理学者ダニエル・カーネマンの『ファスト＆スロー』に由来します。人間の思考を、速く直感的に判断する System 1 と、遅く考え込む System 2 に分ける考え方です。

TypeSafeは、推論型LLMを System 2（熟考して文章を書く係）、Jevを System 1（反射的に判断を返す係）と位置づけています。人間も「このメールは急ぎかどうか」は一瞬で判断し、込み入った返信を書くときだけじっくり考えます。Jevはこの「一瞬の判断」だけを機械向けに切り出したモデルだと考えると分かりやすいでしょう。

ちなみに「Jev」という名前は、経済学者ウィリアム・スタンレー・ジェヴォンズに由来します。蒸気機関の効率が上がると石炭の需要がむしろ増えた、という「ジェヴォンズのパラドックス」のように、機械知能も安く速くなれば使われ方が爆発的に増える、という同社の見立てが込められています（公式ブログより）。

なぜ「LLMではない」と言われるのか

LLMはトークンを1つずつ順番に生成します。Jevはこの逐次生成を行わず、並列サンプラーで出力全体を1回のクエリで同時に出します。返ってくるのは文章ではなく、「choice: "billing"、確率 0.93、信頼度 0.9」のような型付きの値です。

TypeSafeのマニフェストは、AIの課題は「知能の量が足りないこと」ではなく、「今の知能がソフトウェアの部品として組み込みにくいこと」だと主張しています。チャットのように人間向けに設計されたAIではなく、プログラムから呼び出して組み合わせる、機械向け（machine-native）のAIを目指している点が、ChatGPTやClaudeとの根本的な違いです。

開発元TypeSafe AIと発表の経緯

TypeSafe AIのCEOは、元OpenAI研究者のDiogo Almeida氏です。InstructGPTやChatGPTの開発に携わり、RLHF（人間のフィードバックによる強化学習）の共同発明者の一人とされています。共同創業者はErik Gafni氏とSasha Sheng氏です。

2026年9月15日にステルス状態を解除し、DCVC主導のシードラウンドで4,000万ドルを調達したと発表しました（評価額2億ドルとの報道もありますが、関係者情報ベースで公式発表ではありません）。発表ブログはHacker Newsで大きな話題になり、2026年9月24日時点で2,000ポイント近く、500件を超えるコメントが付いています。

AIエージェントの全体像を先に押さえておきたい方は、「AIエージェントとは？仕組み・種類・活用事例・代表ツールをわかりやすく解説」もあわせて読むと、Jevがエージェントのどこに入る部品なのかがつかみやすくなります。

Jevの仕組み — 3つの問い・並列サンプラー・RLCD

出典: TypeSafe AI公式ドキュメント（Primitives）

Jevへの入力は「state（判断材料のテキスト）」と「questions（型付きの問い）」の2つで、問いの型は Choice / Score / Noul の3種類しかありません。この割り切りと、並列サンプラー・RLCDという独自の学習法が、速度と確率の精度を支えています。

3つの質問プリミティブ（Choice / Score / Noul）

1回のリクエストに複数の問いを入れると、同じstateに対して並列かつ独立に評価されます。公式ドキュメントでは、問いを増やしても応答時間への影響は小さいとされています（fan-outパターン）。たとえば1通のメールに対して「カテゴリ」「緊急度」「感情」「個人情報の有無」を一度に聞けます。

並列サンプラー — 速さと「出力無料」の理由

LLMは長い回答ほど生成に時間がかかり、出力トークンにも課金されます。Jevは並列サンプラーで全出力を1パスで出すため、出力の長さに応じて時間が延びにくい構造です。公式が出力料金を無料にしているのもこの構造によるもので、ブログでは「計測するまでもないほど安い（too cheap to meter）」と説明しています。

なお、アーキテクチャの詳細（パラメータ数やTransformerベースかどうか）は公式には公開されていません。

RLCD — 「それらしい答え」ではなく「正確な確率」に報酬を与える学習

JevはRLCD（Reinforcement Learning for Calibrated Decisions）という事後学習で訓練されています。TypeSafeはRLCDを、RLHF・RLVRに続く「第3の事後学習手法」と位置づけています。

公式ドキュメントの問題意識は次のとおりです。

• RLHFは「人間が説得力を感じる回答」に報酬を与えるため、自信ありげなハルシネーションまで報酬化してしまう可能性がある
• 学習の過程で確率分布が不自然に狭まる「mode dropping」が起き、確率の値が当てにならなくなる

RLCDは、テキストではなく「確率付きの構造化された判断」を返すように学習させ、確率そのものの正確さ（校正）を最適化の目標にしています。モデルの重みは全アカウント共通で、ファインチューニングはできません。カスタマイズは、リクエストごとのstate・instructions・criteria（判断基準）で行います。

「20〜200倍高速・40〜400倍低価格」の根拠 — 数字の出典を整理

Jevの性能として広く引用されている「20〜200倍高速・40〜400倍低価格」は、公式ブログ本文では同じ表現を確認できません。公式ブログが示しているのは「40〜200倍高速」と、自社ワークフロー評価での「193.6倍高速・444.6倍低価格」です。出典ごとに数字を並べると次のとおりです。

「193.6倍・444.6倍」を読むときの注意点

公式の数字は嘘ではありませんが、そのまま自社の削減率として見積もると外れます。公式ブログ自身が、次の点を透明性のための注記として挙げています。

• 評価用ワークフローはTypeSafe社内のチームが作成しており、バイアスの可能性がある
• デモ用に問いを簡略化して評価している
• 公平に比べるため、LLM側にはラッパーで構造化出力を強制している

加えて、比較対象はフロンティアLLM（高価で遅いモデル）なので、安価な軽量LLMと比べれば差は縮まると考えるのが自然です。

さらに、公式評価ダッシュボード（evals.typesafe.ai）の「正解」は、人手で作った正解データではなく、GPT-6 AstraとClaude Fable 5.1（high thinking）の回答の平均です。つまりダッシュボードの精度は「上位LLMとどれだけ一致したか」を示す値で、絶対的な正しさではありません。Jevの平均一致率は67.8%前後で、比較LLMとの差は約6ポイントと報じられていますが、ダッシュボード上の数値は編集部で直接確認できていないため、参考値として扱ってください。

第三者による検証はまだ少ない

独立した検証として知られているのは、米メディアEveryの検証です。報道によると、文章の欠陥を抽出するタスクで、JevはClaude Fable 5.1比で約25倍高速（1パッセージ0.35秒 vs 8.83秒）・約580倍低価格でした。一方、仕込んだ欠陥7件のうち、Fableが7件すべてを検出したのに対し、Jevは6件で、評価は「good but not perfect（良いが完璧ではない）」です。

これは単一タスク・最も高価なモデルとの比較という限定された条件での結果です。現時点で、公式以外の独立ベンチマークはごくわずかしかありません。

信頼度スコアの「校正」は何を保証するのか

出典: TypeSafe AI公式ドキュメント（Confidence）

Jevの大きな売りは、確率と信頼度が校正（calibrated）されている点です。校正とは「確率0.8を付けた答えは、実際に約80%の頻度で当たる」という性質のことです。ただしこれは多数の答えをまとめて見たときの統計的な対応で、1件ごとの正しさを保証するものではありません。

具体的には、「信頼度0.9前後の答えを1,000件集めると、そのうち約900件が正しい」という意味です。裏返せば、信頼度0.9の答えでも約1割は間違っている前提で設計する必要があります。

probabilities と confidence の違い

• probabilities: 選択肢ごとの確率分布（例: 請求 0.90 / 技術 0.07 / 解約 0.03）
• confidence: その分布を0〜1の1つの数字にまとめた値。確率が1つの選択肢に集中していれば高く、散らばっていれば低くなる

公式ドキュメントによると、3択なら confidence ≈ (3 × 最大確率 − 1) ÷ 2 です。最大確率が0.9なら、信頼度は約0.85になります。

しきい値でエスカレーションする運用に直結する

校正された信頼度があると、「どの答えは自動で処理し、どれを人やもっと賢いモデルに回すか」を数字で決められます。公式ドキュメントの推奨は次のとおりです。

公式は「しきい値は1つの数字ではなく、結果の重大さに応じてアクションごとに変える」「保守的に始めて調整する」と明記しています。LLMガードレールのcookbookでも、レビュー用のしきい値は約0.35、アクション用は約0.70〜0.85とし、重大度が高いものはブロックに格上げする例を示したうえで、「デフォルト値を流用せず自社のトラフィックで調整すること」と注意しています。

なお、JSONモードなどでLLMに構造化出力を強制しても、形式はそろいますが、確率が校正されるわけではありません。この点は、既存のLLMで同じことをする場合との本質的な違いです。

Jevでできること・使いどころ

出典: TypeSafe AI公式ドキュメント（Example use cases）

Jevが向いているのは、「人間なら10秒以内に判断できる程度の判断を、大量かつ高速に回す」仕事です。公式ブログは「スマートなif文」という表現を使っています。コードの分岐条件に、ルールでは書ききれない曖昧な判断を差し込むイメージです。

実務での利用シーン

Jevに向く判断の3条件

判断をJevに任せるかどうかは、次の3条件で見分けられます。

1. 答えの候補を列挙できる — 「どれか1つ」「何段階か」「Yes/No」で答えられる。自由記述の答えが必要ならLLMの仕事
2. 1件1件が小さく、件数が多い — 1日数件ならLLMで十分。数万〜数百万件になるほど速度とコストの差が効く
3. 答えをコードで処理できる — 返り値をif文・集計・重み付けに使える。人が読む文章が必要な場面には向かない

主観的で大きな問い（例:「この提案は良いか」）は、「根拠となるデータがあるか」「予算の記載があるか」「競合への言及があるか」のように小さな判断に分解し、重み付けはコード側で行うのが公式のおすすめです（Composite scoringパターン）。

エージェントのコストを下げる「前段の足切り」設計

AIエージェントでは、ユーザーのメッセージを毎回高価なLLMに通して「何の依頼か」を判定しているケースが少なくありません。公式ドキュメントのIntent routingパターンは、先にJevで分類し、振り先を決めてから必要なときだけLLMを呼ぶという考え方です。

設計例は次のようになります。

1. すべてのメッセージをJevで分類（カテゴリ＋信頼度）
2. 信頼度が高く、定型処理で済むもの → 決定的なロジック（コード）で処理
3. 信頼度が中程度のもの → 安価で高速なLLMで処理
4. 信頼度が低いもの、または重要度が高いもの → 上位LLMか人間へ

公式は「答えは"何か"を、信頼度は"実行してよいか"を示す」「コードが主導権を持ち、System Oneには狭く構造化された判断だけを任せる」と説明しています。

コスト試算（前提を明記した概算）

• 前提: 100万件のメッセージを分類し、1件あたりの入力は平均500トークン
• Jevの費用: 500トークン × 100万件 = 5億トークン → 5億 ÷ 100万 × $0.042 = 約$21（1ドル＝150円換算で約3,150円）。出力は無料
• 比較: 入力 $1 / 100万トークン、出力はその5倍（$5）の汎用LLMを使い、1件あたり出力20トークンと仮定した場合、入力$500＋出力$100＝約$600

実際の削減効果は、LLM側のモデル選択、Jevで自動処理できる割合、エスカレーションの割合によって大きく変わります。この試算は構造を理解するための仮定計算なので、本番前には自社データで見積もり直してください。

エージェントに組み込む実際の製品像をイメージしたい方は、「AIエージェントおすすめ比較【2026年最新】14選を個人・業務・開発用途別に徹底整理」で、主要なエージェント製品の特徴を確認できます。

Jevの強み

Jevの強みは、判断タスクに限れば「速い・安い・形式が崩れない・確率が使える」の4点が同時に成り立つことです。

• 応答が速い: 公式ブログによると応答は70ms〜500ms。フロンティアLLMの3〜329秒と比べると桁違いで、ユーザーを待たせるリアルタイム処理にも組み込みやすい
• コスト構造が単純で安い: 入力 $0.042 / 100万トークン、出力無料。問いを増やしても出力課金が増えない
• 出力が必ず定義した型に収まる: 選択肢にない値や壊れたJSONが返ってこないため、パース失敗の例外処理が不要になる
• 校正された確率が返る: しきい値で自動処理と人手確認を切り替える運用が組みやすい
• 学習データが不要: 問いと選択肢をリクエストごとに変えられるゼロショット型で、ラベル付けや再学習をせずに分類ルールを変更できる
• 複数の問いを並列評価: 1回の呼び出しで複数の観点を同時に判定できる

Jevの弱み・できないこと

Jevは「判断しかできない」ように設計されたモデルで、その裏返しとして明確な制約があります。特に、判断の理由を説明できない点は業務利用の前提を左右します。

公式が認めている制約

• 任意の文字列は生成できない（文章・コード・要約・返信は不可）
• 思考の過程（chain-of-thought）や説明文を出力できない
• Choiceの選択肢は最大255。それを超える場合は2段階で絞り込む必要がある
• 入力はテキストのみ（文字列・JSON・テキスト配列）。画像・音声・動画には未対応
• 主に英語向け。日本語を含むCJK言語にも対応するが、精度が下がると公式が明言。日本語の定量的なベンチマークは公式に公表されていない
• ファインチューニングはできない
• コンテキストは合計64kトークン（stateと最も長い問いで32k）

公式ドキュメント「Model jaggedness」が挙げる苦手分野

公式は現行モデル jev-1.13 の苦手分野を公開しています。主なものは次のとおりです。

批判的な視点: 説明できないこと、独立検証の不足

1. 判断の理由を説明できない

Jevは「なぜその答えになったか」を出力しません。与信審査、採用選考、医療判断、行政手続きのように、判断根拠の説明や異議申し立てへの対応が求められる領域では、Jevを単独の意思決定者として使うべきではありません。こうした領域で使う場合は、「stateの内容・問い・確率・信頼度・実行したアクション」をログとして保存し、最終判断は人間かLLM＋人の確認で行う設計が必要です。AIエージェントの事故調査の難しさについては、「AIエージェント暴走事故に公式な調査プロセスがない」でも取り上げています。

2. 「ハルシネーションしない」は「間違えない」ではない

公式は「ハルシネーションできない（型エラーを起こさない）」と表現していますが、保証されるのは出力が定義した型・選択肢に必ず収まることです。答えの中身が正しいことまでは保証されません。Hacker Newsでも「無効な型は出さないが、間違った有効な値は出せる」という指摘が最も多くの返信を集めました。さらに、選択肢の中から必ず答えを選ぶため、「分からない」と棄権できない点を問題視する声もあります。対策としては、選択肢に「該当なし／判断不能」を加え、低信頼度の答えを人に回すのが現実的です。

3. アーリーアクセス段階で、独立ベンチマークが少ない

現時点で公式以外の検証は、Everyのレビューなどごく一部です。公式評価の「正解」も他のLLMの回答の平均です。ファインチューニングした分類器と校正の精度を比べたベンチマークもまだ見当たりません。

4. コンセプトの新しさ・価格の持続性への疑問

Hacker Newsでは、「Facebookのゼロショット分類モデル（BART）で同じような仕組みは何年も前からある」「クローズドソースなので再現性がない」「Doomのデモは映像ではなく、テキスト化したゲーム状態を入力している」といった指摘も出ています。発表から約1週間で一般向けGPUで動くOSSのクローンが登場したとの報道もあり、独自性がどこまで続くかは今後の検証待ちです。料金についても、公式ブログ自身が「価格が赤字覚悟の補助でないことは、現時点では証明できない」と認めています。

セキュリティ・データ取り扱いの注意点

公式によると、Jevは顧客のリクエストやレスポンスを学習に使いません。一方で、エンタープライズ向けのセキュリティ認証やSLAは、現時点では公式ドキュメントで確認できません。業務で使う前に確認したいポイントを整理します。

プロンプトインジェクション対策に使うときの注意

JevはLLMの入力フィルタやジェイルブレイク検知にも使えますが、公式の苦手分野に「データ内に仕込まれた指示・誤誘導に影響されうる」と明記されています。つまり、ガードレール自体が攻撃を受ける可能性があります。Jevを唯一の防御にせず、権限の最小化、ツール実行前の確認、出力の検証などと組み合わせた多層防御にしてください。具体的な対策の全体像は「AIエージェントのセキュリティ対策｜リスクの全体像と実務で使える対策チェックリスト」で整理しています。エージェントの出力を安価に自動チェックする必要性は、「OpenAIのエージェント群がドイツのWikiを乗っ取り」の事例からもうかがえます。

非公式サイトに注意

「jevtypesafeai.com」というサイトは、TypeSafe AIとは無関係の事業者（CODEFASHION TECH LTD）が運営する非公式サイトで、独自にAPIキーを発行しています。サイト上にも「TypeSafe AIとは無関係・非公認」と記載されています。公式のドメインは次の3つです。APIキーの取得やデータの送信前に、必ずドメインを確認してください。

• https://typesafe.ai/ （公式サイト・ブログ）
• https://docs.typesafe.ai/ （公式ドキュメント）
• https://console.typesafe.ai/ （コンソール・APIキー発行）

Jevの料金・プラン・仕様

Jevの料金は入力 $0.042 / 100万トークン、出力は無料です（公式ドキュメント「Models」、2026年9月24日時点）。Free・Proのような段階別プランや無料枠は、現時点では公開されていません。

この料金は発表直後のアーリーアクセス価格です。公式ブログ自身が「価格の持続性は長期的に示す必要がある」と述べているため、長期の予算計画では値上げの可能性も織り込んでおくのが安全です。

Jevの使い方（Quick Start）

出典: TypeSafe AI公式ドキュメント（Quick start）

Jevは現在ウェイトリスト制です。招待を受けた後は、公式SDKを入れてAPIキーを設定すれば、数行のコードで呼び出せます。

1. ウェイトリストに登録する — 公式サイト（typesafe.ai）から申し込む。公式ブログでは「できるだけ早く招待している」とされている
2. APIキーを取得する — console.typesafe.ai でキーを発行し、環境変数 TYPESAFE_API_KEY に設定する
3. SDKをインストールする — Pythonは pip install typesafe-sdk（Python 3.10以上）または uv add typesafe-sdk。JavaScript SDKも提供されている
4. 問いを定義して呼び出す — stateと、Choice / Score / Noul の問いを渡す

公式Quick Startの最小コードは次のとおりです。

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient()
response = client.system_one(
    state="Your text here",
    questions={"urgency": Noul(instructions="Does this convey urgency?")}
)
print(response.answers["urgency"].noul)

REST APIを直接使う場合のエンドポイントは POST https://api.typesafe.ai/v1/systemone です。エラーは401（キー不正）、422（リクエスト形式の誤り）、429（レート超過）、529（過負荷）で、429と529は指数バックオフでリトライするよう公式が推奨しています。

実務で失敗しないためのコツ

• 正解付きのサンプルで先に検証する — 数百件程度のラベル付きデータで一致率と、信頼度ごとの正答率（校正）を確認してから本番に入れる。日本語データでは特に重要
• 「緊急」などの定義を言語化する — criteriaに境界ケースを書く。曖昧な定義はそのまま精度の低下につながる
• stateを絞る — 判断に関係する情報だけを渡す。長いメールスレッドをそのまま入れない
• 計算・日付・件数はコードで処理する — Jevには意味的な判断だけを任せる
• 公式のagent skillを使う — Claude CodeやCodexなどのコーディングエージェント向けに公式skillが用意されており、問いの設計や実装を手伝わせられる

Jevと他の手法の違い — 安価なLLM・BERT分類器・埋め込み・ゼロショット分類

Jevと同じような判断は、既存の手法でもある程度こなせます。違いは、「学習が不要で、校正された確率を、LLM級の理解力で、非常に安く返す」と主張している点です。ただし、この優位性の多くはまだ独立した検証を待つ段階です。次の表では、公式の主張と一般的な性質を分けて整理しています。

使い分けの目安

• Jevを選ぶ: 分類ルールが頻繁に変わる、件数が非常に多い、確率でエスカレーションしたい、英語中心のデータ
• 安価なLLMを選ぶ: 判断に加えて要約や返信文の作成も必要、日本語の精度を優先したい、理由の説明も欲しい。軽量LLMの最新動向は「Gemini 3.8 Flashとは」で解説しています
• BERT系分類器を選ぶ: ラベルが固定されていて十分な学習データがある、データを外部に出せない、精度検証を厳密に行いたい
• 埋め込みを選ぶ: 類似文書の検索や重複の検出が目的で、「判断」まではいらない

実際には、Jevで一次仕分けを行い、中〜低信頼度のものだけLLMに回す、というように組み合わせて使うのが最も現実的です。

Jevはこんな人におすすめ / おすすめしない人

Jevは「LLMを置き換えたい人」ではなく、「LLMの呼び出し回数と待ち時間を減らしたい人」に向いたモデルです。

こんな人におすすめ

• 問い合わせ・チケット・メールを大量に振り分けていて、LLMのコストやレイテンシが課題になっている開発チーム
• RAGの検索結果を絞り込み、LLMに渡すトークン量を減らしたい人
• LLMの入出力に、低遅延のガードレールを1枚追加したい人
• AIエージェントのツール選択や意図判定を、安く速くしたいプロダクトチーム
• 数万〜数百万件のテキストを一括で評価・ラベル付けしたいデータ分析担当者
• 確率としきい値で、自動処理と人の確認を切り分ける運用を組みたい人

おすすめしない人

• 文章の生成、要約、翻訳、コード生成が目的の人（ChatGPTやClaudeなどのLLMを使う）
• 与信・採用・医療判断など、判断理由の説明が必須の業務をJev単独で自動化したい人
• 日本語データのみで高い精度が必須なのに、事前検証に工数をかけられないチーム
• ノーコードでチャットのように使いたい非エンジニア（APIとSDKでの利用が前提）
• 本番運用にSLAやセキュリティ認証が必須の企業（現時点ではアーリーアクセスで、公式の記載が確認できない）
• 画像・音声を含むデータを判断させたい人（テキストのみ対応）

よくある質問

Q. Jevは無料で使えますか？

無料プランや無料枠は、2026年9月24日時点では公開されていません。料金は入力 $0.042 / 100万トークンと非常に安く、出力は無料です。ただし、利用するにはウェイトリストに登録し、招待を受ける必要があります。

Q. ChatGPTやClaudeの代わりになりますか？

なりません。Jevは文章を生成できず、決められた選択肢・スコア・Yes/Noの確率しか返しません。ChatGPTやClaudeが担う「考えて書く」仕事の手前で、仕分けや足切りを担う部品として組み合わせるのが想定された使い方です。

Q. 日本語の問い合わせ分類に使えますか？

使えますが、公式は日本語を含むCJK言語では精度が下がると明言しており、日本語の定量ベンチマークも公式には公表されていません。英語データでの評判をそのまま当てにせず、自社の日本語データ数百件で一致率と信頼度ごとの正答率を確かめてから導入を判断してください。問いやcriteriaを英語で書き、stateだけ日本語にする構成を比べてみる価値もあります。

Q. 「信頼度0.95」なら、その答えは必ず正しいですか？

必ずではありません。校正が保証するのは「信頼度0.95前後の答えを多数集めると、約95%が正しい」という統計的な性質です。重大な結果につながる判断では、信頼度が高くても人の確認を挟む、あるいはアクションごとにしきい値を厳しくするといった設計が必要です。

Q. オープンソースですか？自社サーバーで動かせますか？

Jevはクローズドソースで、TypeSafeのクラウドAPI経由でのみ提供されています。オンプレミスや自社クラウドでの実行は、現時点では公式に案内されていません。データを外部に出せない場合は、ゼロデータ保持（エンタープライズ向け）の条件を問い合わせるか、自前でホストできる分類器を検討してください。

Q. Vercel AI GatewayやOpenRouterから使えますか？

非公式サイトではこうした経路での提供に触れていますが、2026年9月24日時点で公式ドキュメントでは確認できません。公式に案内されている利用方法は、公式APIとPython / JavaScript SDKです。

まとめ

TypeSafe AIのJevは、文章を書く代わりに、型付きの答えと校正された確率を1秒未満で返す判断専用の「System One」モデルです。

• LLMの代替ではなく、LLMやエージェントの前段で分類・フィルタ・ルーティングを担う部品
• 公式の速度は「40〜200倍高速」、自社評価では「193.6倍高速・444.6倍低価格」。「20〜200倍・40〜400倍」は公式ブログ本文では確認できない流通値
• 料金は入力 $0.042 / 100万トークン、出力無料。ただし価格の持続性は公式も未証明と認めている
• 校正された信頼度は「多数の答えの統計的な正しさ」を示すもの。しきい値で自動処理・安価LLM・人間に振り分ける運用で真価を発揮する
• 判断理由を説明できない、日本語は精度が下がる、プロンプトインジェクションに影響されうる、アーリーアクセスで独立検証が少ない、といった制約がある

まずは自社で最も件数の多い「単純だけれど曖昧な判断」を1つ選び、正解付きのサンプルでLLMと比べてみるのが、Jevを評価するいちばん確実な方法です。エージェント全体の設計から見直したい方は、「AIエージェントとは？仕組み・種類・活用事例・代表ツールをわかりやすく解説」もあわせてご覧ください。

主な出典

• TypeSafe AI 公式ブログ「Introducing System One Models & Jev」
• TypeSafe AI 公式ドキュメント
• TypeSafe AI マニフェスト
• DCVC「TypeSafe emerges from stealth」
• Every「How to Get the Most Out of Jev」
• Hacker News の議論スレッド