TypeSafe AIが2026年9月15日に公開したJev（ジェブ）は、文章を一切生成しないAIモデルです。入力された状態に対して、分類・段階評価・確率だけを型付きで返します。同社はこれを、初の「System One Model」と位置づけています。
公式の説明は「unstructured state in, typed probabilistic decisions out（非構造化の状態を入れ、型付きの確率的判断を返す）」。ChatGPTやClaudeのようなテキスト生成AIとは用途が分かれており、ソフトウェアの内側で高速に判断を下す部品として設計されています。
料金は入力100万トークンあたり$0.042、出力トークンは無料。レイテンシはエンドツーエンドで70〜500msとしています。
TypeSafe AIは公開と同時にステルスを解除し、DCVCをリードとする4,000万ドルのシード調達も発表しました。拠点はサンフランシスコ。CEOはDiogo Almeidaで、共同創業者はErik GafniとSasha Shengです。AlmeidaはOpenAIでRLHFの研究に携わっており、その成果がChatGPTにつながったと同社は説明しています。
提供はEarly Access段階です。2026年9月19日時点では、ウェイトリストから順次アクセスが開放されています。
問い合わせメールを読ませて、担当部署だけ判定させたい。フォームの投稿がスパムかどうかだけ知りたい。AIエージェントに、次に使うツールだけ選ばせたい——。
こうした処理でChatGPTやClaudeのAPIを呼ぶと、毎回「文章を生成させて、JSONに整形させて、パースする」という遠回りが発生します。欲しいのは判定結果ひとつ。それなのに数百トークンの生成を待たされます。
通常のLLMは「入力 → 推論 → 文章生成」という流れをたどりますが、このうちレイテンシとコストの大半を占めているのは最後の生成部分です。ところが実務でLLMに投げている処理の多くは、文章そのものを必要としていません。問い合わせの振り分け、リードの品質判定、投稿のモデレーション、不正検知。いずれも最終的に欲しいのは「どれか1つ」か「0〜1の確率」だけです。
Jevが担当するのは、この判断の層だけです。文章は返りません。状態を渡して質問を投げると、決定と確率が返ってきます。
TypeSafe自身は、Jevを「smart if-statements（賢いif文）」と表現しています。開発元による言い回しですが、このモデルの性格を端的に言い当てています。
問い合わせフォームの本文から返金依頼を拾う処理を例に見てみます。従来はこう書いていたはずです。
python
if "返金" in message:\n handle_refund()問い合わせ本文（message）に「返金」という文字が入っていたら、返金対応の処理（handle_refund()）を呼ぶ。判定基準は文字があるかないか、それだけです。
ところが、お客様が必ず「返金」という単語を使うとは限りません。
実際の問い合わせ本文 | 「返金」の文字 | 判定結果 |
|---|---|---|
返金をお願いします | ある | ✅ 拾える |
お金を返してほしい | ない | ❌ 素通り |
キャンセルして請求を取り消して | ない | ❌ 素通り |
返金はしなくていいので交換して | ある | ⚠️ 誤って返金処理が走る |
4件目が特に厄介です。文字は入っているのに、意味は正反対。文字列一致は意味を見ていないため、取りこぼしと誤爆の両方が避けられません。
かといって、判定のたびにChatGPTやClaudeのAPIを呼ぶのも現実的ではありません。文章を生成する処理が挟まるためレスポンスに数秒かかり、1件あたりの単価も上がります。問い合わせが1日数千件あるような規模では、コストが先に効いてきます。
文字列一致では精度が足りず、LLMでは速度と単価が見合わない。 Jevが埋めるのは、この隙間です。
Jevに問い合わせ本文を渡すと、こういう値が返ってきます。
python
refund_probability = jev(message) # → 0.870.87は「この問い合わせが返金依頼である確率は87%」という判定です。文章は返ってきません。数字だけなので、速く、安く済みます。
実際のコードでは、この値を閾値で分岐させます。
python
refund_probability = jev(message) # → 0.87\n\nif refund_probability > 0.8: # 80%を超えていたら\n handle_refund() # 返金対応へ最初のコードと見比べると、変わったのは1か所だけです。
従来 | Jev | |
|---|---|---|
条件の部分 |
|
|
実行する処理 |
|
|
if文の「条件」だけをAIに差し替える。プログラムの構造はそのままに、判定の中身だけが賢くなる。これが「賢いif文」と呼ばれる理由です。
なお、上の jev(message) は説明用に簡略化した書き方です。実際のAPI呼び出しは次のセクションで扱うJSON形式になります。
Jevへの質問は、3種類のプリミティブで組み立てます。
種類 | 用途 | 例 |
|---|---|---|
Choice | 選択肢から1つ選ぶ | 営業 / 技術 / 請求 |
Score | 段階評価 | 重大度1〜5 |
Noul | Yesである確率 | 不正である確率 0.82 |
Choiceは最大255択まで対応します。Scoreは2〜10段階の尺度を自分で定義します。Noulはブール判定を確率で返すもので、0〜1の値が得られます。
入力として受け付けるのは文字列、JSONオブジェクト、テキストの配列です。画像・音声・動画は対象外です。
公式のQuick Startに掲載されている例で見てみます。顧客から「Stripe連携が3日間失敗していて売上を失っている。至急対応してほしい」という問い合わせが来たとします。
Jevには「返信文を書いて」とは頼みません。渡すのは質問です。
json
{\n "state": "Stripe連携が3日間失敗しています。売上を失っているので至急対応をお願いします。",\n "model": "jev-latest",\n "questions": {\n "department": {\n "type": "choice",\n "instructions": "Which team should handle this",\n "criteria": {\n "billing": "Payment issues",\n "technical": "Technical issues",\n "sales": "Sales questions"\n }\n }\n }\n}返ってくるのは、選ばれた選択肢だけではありません。
json
{\n "choice": "billing",\n "probabilities": {\n "billing": 0.84,\n "technical": 0.159,\n "sales": 0.001\n },\n "confidence": 0.596\n}全選択肢にわたる確率分布と、最上位にどれだけ確率が集中しているかを示すconfidenceが付きます。確率が平坦なら迷っているサイン。一点に集中していれば、モデルが自信を持っていると読めます。
この確率分布が、Jevの設計の中心にあります。
両者は用途がそもそも違います。優劣ではなく、役割分担として整理します。
項目 | ChatGPT / Claude など | Jev |
|---|---|---|
主目的 | テキスト生成・推論 | 判断 |
出力 | 文章 | 型付きデータ |
生成方式 | token-by-token | 並列判断 |
自由回答 | ○ | × |
コード生成 | ○ | × |
分類・スコアリング | ○ | ◎ |
確率出力 | 苦手 | 標準出力 |
レイテンシ | 秒単位の場合あり | 70〜500ms（同社測定） |
出力料金 | 通常有料 | 無料 |
TypeSafe自身も、Jevを「小型LLM」とは位置づけていません。新しいアーキテクチャ、parallel sampler、そして後述するRLCDという独自の訓練手法を採用した、別クラスのモデルだと説明しています。
現行のLLMはRLHFなどによって「人間が好む回答を返す」方向に最適化されています。TypeSafeが開発したのは、別の方向へ最適化する訓練手法です。RLCD（Reinforcement Learning for Calibrated Decisions＝校正された意思決定のための強化学習）と呼んでいます。
目指しているのは、epistemically honest（認識論的に正直）な確率を返すモデルです。「これが正解です」と断言するのではなく、「これが正しい確率は82%だと判断します」と言えることを狙っています。
確率が校正されていると、呼び出す側のコードの書き方が変わります。
python
if probability > 0.95:\n auto_process() # 自動処理\nelif probability > 0.70:\n needs_review() # 要確認\nelse:\n escalate_to_human() # 人間へエスカレーション公式ドキュメントも、低リスクな処理と送金のような高リスクな処理では異なるconfidence閾値を設定するよう勧めています。確信度に応じて自動化のレベルを変えるという発想は、AIエージェントを実運用に乗せるうえで重要になります。
料金体系が独特です。
出力が無料なのは、そもそも長文を生成しないからです。返ってくるのは {"spam": 0.98} 程度。通常のLLMのように数百〜数千トークンを生成する処理そのものが存在しません。
レイテンシはエンドツーエンドで70〜500ms。多くのクエリは100ms前後だと同社は説明しています。System One型の処理では、既存のフロンティアモデル比で40〜200倍高速。自社のWorkflow benchmarkでは、最大193.6倍高速・444.6倍安価という数字も出しています。
Early Access中のレート制限は、毎秒25万トークン・毎分1,200リクエストとされています。
TypeSafeはZero Hallucinationsを掲げています。ただし、Jevが間違えないという意味ではありません。ここは誤解しやすいところです。
正確には、定義していない形式の回答を勝手に生成しないという意味です。red / green / blue の3択を渡したとき、orangeが返ることは構造上ありえません。返り値は必ず定義済みの選択肢のどれかに収まります。
同社自身も、この0%が実測値ではないと明記しています。スキーマへの適合が保証されるため、定義上0になる。そういう話です。
つまり、次のように分けて理解する必要があります。
ここを混同したまま設計すると、confidenceによる分岐を組まずに判定結果をそのまま自動処理へ流してしまい、誤判定が誰にも気づかれないまま通過する構成になります。
Jevの設計で特徴的なのが、並列質問という仕組みです。
同じstateに対して、「これは詐欺か」「顧客は怒っているか」「返金が必要か」「VIP顧客か」「解約しそうか」「法的リスクはあるか」といった質問を並べます。これを何十個でも、1回のリクエストにまとめて投げられます。
質問数を増やしても、レスポンスタイムはほとんど伸びません。すべて並列で処理されるからです。公式のcookbookに載っている例では、13個の質問を1回のリクエストにまとめたところ、13回個別に呼ぶ場合と比べて12.2倍安価・10.0倍高速という結果が出ています。
トークン予算は、stateと全質問の合計で約6万4,000トークン、stateと最も長い質問1つの組み合わせで約3万2,000トークンです。
エンドポイントは POST https://api.typesafe.ai/v1/systemone です。モデルには jev-latest を指定します。
Python SDKも公開済みです。
bash
pip install typesafe-sdkJavaScript / TypeScript向けSDKも公開されており、Vercel AI SDKとAI Gateway経由でも利用できます。
Claude Code向けのAgent Skillも公式提供されています。
bash
claude plugin marketplace add typesafe-ai/skills\nclaude plugin install typesafe@typesafe-ai前述のとおり、いずれも2026年9月19日時点ではEarly Access段階での提供です。
便利な一方で、注意点もあります。導入を検討する前に、押さえておきたい点を3つ挙げます。
1. JevはLLMの代替ではありません
文章を書けないため、記事の執筆、コードの生成、深い思考を要する検討、Web調査、会話には向きません。数値計算や日付の比較が苦手であることも、公式ドキュメントに明記されています。
公式が向いているとしているのは、「知識のある人が適切なコンテキストを見れば数秒で判断できるような、1つの明確な判断」。複雑な判断は複数の小さな質問に分解し、最終的なロジックはコード側で組む設計が推奨されています。
2. 性能値はまだベンダーの自己評価です
193.6倍高速・444.6倍安価という数字について、TypeSafe自身が「現実世界で期待できる改善幅の上限寄り」だと認めています。評価用ワークフローを作ったのは同社のmodel capabilitiesチームで、バイアスの可能性も明記されています。常に200倍速いわけではありません。
3. 公開から日が浅く、第三者データがありません
2026年9月15日の公開から、まだ数日。第三者ベンチマークと実運用データが出揃うまでは、興味深い新方式だが性能評価は保留、という姿勢が現実的です。
Jevそのものの成否とは別に、この設計思想は注目に値します。高速な判断はJevのようなモデル、複雑な推論・生成はGPTやClaude。こうしたハイブリッド構成は、今後のAIエージェント設計で主流になっていく可能性があります。
名前の由来もこの思想を反映しています。Jevは経済学者William Stanley Jevonsから取られたもので、「効率が向上すると、その資源の消費量はむしろ増える」というジェボンズのパラドックスになぞらえています。AI推論コストが10分の1、100分の1になれば、AI呼び出し自体が爆発的に増える——という読みです。
Early Accessのウェイトリストは公式サイトから登録できます。判定処理でLLMのコストとレイテンシに悩んでいるなら、試す価値はあるはずです。