テキストを一切生成しないAIモデル、と言われたら何を思い浮かべるでしょうか。2026年9月15日、サンフランシスコのスタートアップ TypeSafe AI がステルスを脱して公開した「Jev(ジェヴ)」は、まさにそういうモデルです。自由文も、コードも、思考過程の説明も返しません。返すのは「この問い合わせは二重請求カテゴリである確率0.94」といった、型の付いた判断と確率だけです。
公開直後から日本の技術コミュニティでも一気に話題になりました。「既存のLLMがCPUなら、JevはそのGPU版」という評価がある一方で、「それ、既存LLMのlogitを読めば同じことができませんか?」という冷静な検証も同時に出てきています。TypeSafe自身は「最大193.6倍高速・444.6倍安価」と謳っていますが、この数字がどこまで一般化できるのかは、発表資料を読むだけでは判断できません。
先に結論を書きます。Jevは「回答候補が事前に定義できる判断」を高速・低コストで大量に回す用途には十分な実用性があります。ただし公称性能値はベンダー自己評価であり、参照値すら客観的な正解ラベルではありません。基幹の不可逆な意思決定をJev単独に委ねるのは時期尚早で、誤りを検出・救済できる判断層から、自前の評価データを用意して始めるのが妥当です。以下、その根拠を順に見ていきます。
1. Jevとは何か
Jevは TypeSafe AI の旗艦モデルであり、同社が「System One Model」と呼ぶ新カテゴリの最初の公開モデルです。公式サイトは Jev の役割を unstructured state in, typed probabilistic decisions out(非構造の状態を入力し、型付きの確率的判断を出力する)と表現しています。入力として状況説明(state)と型付きの質問を受け取り、質問のスキーマが定める範囲の値と確率を返す。それだけです。
名称の由来は公式FAQとプレスリリースで説明されています。System One はダニエル・カーネマンが広めた「速い直感的思考(システム1)」に、Jev は「効率の改善がかえって総需要を増やす」というジェヴォンズのパラドックスで知られる経済学者 William Stanley Jevons に由来します。知能が安くなれば、これまで使う気にならなかった場所にまで知能が入り込む、という含意でしょう。
開発元の TypeSafe AI は2024年創業、サンフランシスコ本拠のAIラボです。2026年9月15日に DCVC 主導で約4,000万ドルのシード調達を公表しました。共同創業者は Diogo Almeida(CEO)、Erik Gafni(CTO)、Sasha Sheng(COO)で、Almeida は元OpenAIの研究者であり InstructGPT 論文やRLHF系の研究に貢献した人物です。プレスリリースでは「ChatGPTの共同発明者」と紹介されていますが、これは企業広報の表現であり、実態としては上記の理解が中立でしょう。
設計思想として TypeSafe が掲げるのは、「LLMは人間が読むテキストを生成するよう最適化されており、コードが判断を消費する用途にはミスマッチがある」という問題意識です。従来はLLMに構造化出力を無理やり吐かせ、パースし、検証し、それでも型エラーやリクエスト間のブレのリスクが残りました。Jevはその判断部分だけを切り出し、出力空間をスキーマで閉じてしまおうという発想です。公式ドキュメントは、大規模な自動化では機械対機械のやり取りが大半を占め、人間との対話はその一部にすぎない、という想定を置いています。
2. 3つのプリミティブと並列評価
Jevが答えられる質問は3種類だけです。この割り切りが設計の核心にあたります。
| プリミティブ | 返すもの | confidence | 主な用途 |
|---|---|---|---|
| Choice | 定義済み選択肢から選ばれた1つと、全選択肢にわたる確率分布 | あり | 問い合わせ分類、ルーティング、カテゴリ判定。選択肢は最大255 |
| Score | 順序付きルーブリック上の確率加重位置と、レベル別の分布 | あり | 品質採点、優先度付け、リランキング |
| Noul | yes/no命題が真である確率(0〜1)のみ | なし(確率そのものが答えのため) | 条件判定、ガードレール、フラグ立て |
実際のリクエストは、1つの state に対して複数の質問をまとめて投げる形になります。
"model": "jev-latest",
"state": "先ほどの注文が二重に請求されています。返金してください。先週も問い合わせましたが返事がありません。",
"questions": {
"category": { "type": "choice", "options": ["二重請求", "配送", "その他"] },
"refund_requested": { "type": "noul", "statement": "顧客は返金を要求している" },
"is_followup": { "type": "noul", "statement": "これは再問い合わせである" }
}
}
この3つの質問は、1回のAPI呼び出しの中で並列かつ互いに独立に評価されます。質問を増やしてもレイテンシの増加は小さく、追加されるのは安価な入力トークン分だけです。質問同士が文脈を汚し合わないので、「カテゴリ判定の結果に引きずられて返金要求の判定が歪む」といった現象は起きません。
ただし、ここは誤解しやすいところです。質問の追加による文脈汚染(context rot)が起きないことと、state そのものが長くなっても劣化しないことは別の話です。公式のモデル特性文書(jaggedness)は、無関係な情報を多く含む大きな state は精度を落とすと明記しています。state は絞り込む必要があります。
推奨される使い方は、大きな問いを原子的な質問に分解し、合成はコード側で行う、というものです。「このスタートアップのピッチを評価して」と丸投げするのではなく、市場規模・技術的実現性・差別化をそれぞれ独立した質問にし、重み付けはプログラムで明示的に書く。判断ロジックがブラックボックスの中ではなくコードの中にあるので、レビューもテストも効きます。
3. 価格・制限・提供チャネル
公式の料金は入力10億トークンあたり42ドル、すなわち100万トークンあたり0.042ドルで、出力は無料です。出力が型に閉じているので課金対象にする意味がない、という設計です。逆に言えば、課金は完全に入力トークン依存であり、「1判断いくら」という固定単価は存在しません。1判断あたりのコストを見積もるなら、自分の state の長さで計算する必要があります。
現行モデルは jev-1.13.0 で、jev-latest と jev-preview は現在ともにこれを指します。エイリアスは更新時に挙動が変わり得るため、confidence の閾値をチューニングした本番システムではバージョンを固定し、レスポンスの model フィールドを記録しておくことが公式にも推奨されています。
| 項目 | 内容 |
|---|---|
| 入力形式 | テキストのみ(文字列 / JSONオブジェクト / テキスト配列)。画像・音声・動画は非対応 |
| コンテキスト長 | リクエスト全体で64kトークン、state+最長の質問の組み合わせで32kトークン |
| レート上限 | 250,000 tokens/秒、1,200 requests/分(早期アクセス段階のため変動しうる) |
| Choiceの選択肢上限 | 255。超える場合はScoreで絞ってからChoiceで確定する二段構成を利用者側で組む |
| 言語 | 英語が主要訓練言語で最も精度が高い。日本語を含むCJKは処理可能だが同等ではなく、自前評価が必要と公式が明記 |
| 提供形態 | ホスト型APIのみ(重み非公開)。早期アクセスのwaitlist制 |
利用チャネルは公式HTTP API(POST https://api.typesafe.ai/v1/systemone)に加え、Python / JavaScript の公式SDK、Vercel AI Gateway、Cloudflare Workers AI、OpenRouter などのゲートウェイ経由があります。ただし各ゲートウェイで課金体系や表示される機能名に差があるため、TypeSafe直販APIの価格・上限をそのまま適用できると考えない方が安全です。
なお、GitHubの typesafe-ai/system-one-adapter-python を「Jevの公式SDK」と紹介している記事が散見されますが、これは誤りです。Adapterは OpenAI や Anthropic のLLMを TypeSafe 互換インターフェースに載せて比較するためのOSSであり、Jevを呼ぶためのものでも、Jevをローカルで動かすためのものでもありません。Jevの重みや学習実装は含まれていません。
4. 公称値をどう読むか
ここが本記事でもっとも注意して書きたい部分です。
TypeSafe は自社の workflow evals において「最大193.6倍高速、444.6倍安価」と報告しています。ただし同社自身が、これは現実世界で得られるゲインの上限側の結果だと公式ブログで注記しています。さらに重要なのは、この評価の作り方です。ワークフローは同社の model capabilities team が作成したもので、正解ラベルは用意されていません。参照値として使われているのは GPT-6 Astra と Claude Fable 5.1 の予測の平均です。
つまり、このベンチマークが測っているのは客観的な正解率ではなく、「特定の計算グラフの上で、2つのフロンティアモデルの平均とどれだけ近い答えを出すか」という一致度です。TypeSafe 自身もブログで、この参照解答の取り方が OpenAI・Anthropic のモデルに有利なバイアスをかけると認めています。
したがって、この eval で報告されている集約値(Jev 約67.8%、最良の比較対象 約74.1%)を「精度」と呼ぶのは不正確です。参照モデル平均との一致度として読むべきものであり、一般的な分類精度や、まして一般知能の指標として外挿することはできません。請求書処理のワークフローでは差が大きく開いており、タスク依存性もはっきりしています。
| 公称された主張 | 正確な読み方 |
|---|---|
| 最大193.6倍高速・444.6倍安価 | TypeSafe自社evalにおける最大値。同社自身が現実的ゲインの上限側と注記している |
| 集約スコア67.8% | 正解率ではなく、GPT-6 AstraとFable 5.1の予測平均を参照値とした一致度 |
| ハルシネーションが起きない | スキーマ適合性の保証に限定される。出力空間外の生成や型違反は設計上防げるが、候補内での意味的な誤判定は防げない |
| 較正された確率を返す | 較正は予測群についての統計的性質であり、個々の回答の正しさを保証しない、と公式も明記 |
| LLMではない | 外部インターフェースと推論目的が生成LLMと異なる、という製品分類。内部アーキテクチャは非公開のため、言語モデル的な要素を一切使わないとまでは確認できない |
訓練手法として TypeSafe が名前を出しているのは RLCD(Reinforcement Learning for Calibrated Decisions)で、RLHF(人間の好み)やRLVR(検証可能報酬)に対して「較正された判断」を最適化目標に置く、と説明されています。ただし報酬関数の設計、較正手法の詳細、較正曲線はいずれも非公開です。アーキテクチャについても「新規アーキテクチャ」「parallel sampler」「全確率を並列に出力」までは公開されていますが、内部の層反復や sampling 回数は開示されていません。したがって「1回のforward passで完結する」という説明は踏み込みすぎで、「自己回帰的にトークン列を生成せず、単一リクエストで複数の型付き判断を並列に返す」と書くのが正確です。
訓練データについては、TechCrunch が Almeida の説明として合成データのみを用いたと報じています。公式サイトやドキュメントの範囲では、査読論文・技術論文は確認できませんでした。
5. 第三者検証で見えたこと
公開から日が浅いため、独立した検証はいずれも小規模です。それでも、速度とコストの優位については複数の独立した観測が一致しています。
| 検証 | 規模 | 主な結果 | 留意点 |
|---|---|---|---|
| Every(米メディア) | 37文書 × 21問=777判定 | 0.7秒未満、約0.0025ドルで完了。別途12文書の欠陥検出比較では、Jevが6/7検出に対しFable 5.1が7/7、速度は約25倍と報告 | 公式ベンチの再現試験ではなく、別用途のハンズオン。タスク条件とコスト算定を公開本文から完全には再構成できない |
| lindfors.no(ノルウェー語) | 24文書 × 各11問 | 中央値0.32秒、1,000文書換算0.22ドル。Choiceのトップ確率0.9以上では stance 14/15、respondent 20/20 が参照ラベルと一致 | 著者自身が「benchmarkではなくfirst look」と明記。基準ラベルはFable 5.1生成のため、正解率ではなくモデル間一致 |
| Near Here(英国) | 実出品50件のモデレーション判定 | Jev 96%に対しMistral Small 4が84%、Gemini 3.5 Flash-Liteが86%。平均0.59秒/判定、1,000件あたり0.043ドル | サンプル数50件と小さく、単一サービスのドメイン特化タスク |
これらを「公式の193.6倍/444.6倍を独立に追認した」と表現するのは不適切です。いずれも別のタスクで、別の条件下で、低レイテンシと低コストを観測した、というのが正しい整理です。一方で、精度については「フロンティアモデルにやや劣るが実用範囲」という傾向が共通して見えており、これはTypeSafe自身のeval結果とも矛盾しません。
lindfors.no の検証で興味深いのは、質問文の書き方で較正が悪化したという報告です。同じタスクで、短いdraft wordingを長いcareful wordingに変更したところ、ECE(期待較正誤差)が0.040から0.116に悪化しました。これは「質問文一般に敏感」という広い証明ではなく一例ですが、プロンプトエンジニアリング的な感度がJevにも存在することは示しています。
6. 較正はどこで崩れるか
Jevの売りは「較正された確率」です。85%と言ったら実際に85%正しい、という性質が成立していれば、confidence を閾値にした自動化・エスカレーション設計が可能になります。では、その較正はどこまで信頼できるのか。
公開されている反例として、サイコロの実験があります。隠されたサイコロの出目をChoiceで400回尋ねたところ、Jevは400件すべてで「1」を選び、平均約83%の確信度を付けました。真の確率は1/6です。同じ問いをNoulで尋ねると約19%となり、1/6(約16.7%)にかなり近い値が返りました。実験者本人がコードとデータを公開したうえで報告しています。
ただしこれは、「観測情報がまったくない対称な問題について、事前確率を答えられるか」という分布外・認識的不確実性の試験です。業務文書の分類における較正が一般に失敗することを直接証明するものではありません。適切な理解は、RLCDによる較正は万能ではなく、プリミティブの選び方や情報の欠如した対称問題では大きく崩れる反例が存在する、というものでしょう。
実務への含意は明確です。Choiceのトップ確率をそのまま「正しさの確率」として読んではいけません。自分の用途のデータで reliability diagram、ECE、Brier score、coverage-risk 曲線を測り、そのうえで閾値を決める。accuracy だけを見て calibration を見ないと、confidence ゲーティングの設計自体が砂上の楼閣になります。
7. 「それ、既存LLMでできませんか?」
日本の技術コミュニティで最も鋭かった反応がこれです。回答候補をそれぞれ単一のトークンIDに割り当て、最初のトークンのlogitsを読み出す。あとはバッチ推論とKVキャッシュの再利用を組み合わせれば、既存のLLMでもJevに近い高速な限定選択が実装できるのではないか、という指摘です。
この批判は技術的に妥当です。Zennでは Gemma 3 270M を用いた自作実装でJSON生成比77倍の高速化が報告され、海外でも Sean Goedecke が、1トークン制約とバッチングによって速度・一貫性・並列性の多くは再現できると論じています。実際、オープンモデルのlogitを直接読む模倣実装が公開数日でGitHubトレンド入りしました。
ただし、これがJevの性能全体を再現した証拠ではない点も押さえておく必要があります。TypeSafe の差別化仮説は、専用訓練、確率較正、APIとしての一貫した型、並列推論基盤、そして低価格での運用を一体化した点にあります。個々の要素は模倣可能でも、束ねて安定運用するのは別の話です。とはいえ、公開情報だけでは技術的moatの強弱を確定できないのも事実で、大手が同等機能を提供してきた場合にどうなるかは未知数です。
現時点で言えるのは、「Jevでしかできないこと」があるというより、「Jevだと考えなくていいことが増える」という性質の優位だろう、ということです。既存LLMがCPUでJevがGPUだという比喩は、この感覚をよく捉えています。汎用性を捨てて特定の形の計算に特化し、その代わり桁で速い。
8. 導入をどう判断するか
ここからは筆者の評価です。事実認定ではなくリスク判断として読んでください。
早期アクセス段階であること、レート上限が動的であること、モデルが更新されうること、非英語での性能差があること、公開されている技術情報が少ないこと。これらを踏まえると、基幹的で高リスクで不可逆な判断をJev単独に委ねるのは時期尚早です。一方で、「Jevは本番投入すべきでない」という一般命題は強すぎます。
誤りを検出・救済できる判断層であれば、shadow mode や限定トラフィックでの本番導入は合理的です。具体的には以下のような領域が該当します。
- 問い合わせの分類とルーティング(誤分類は後段で人が拾える)
- LLM出力の検証・スコアリング(判定そのものが補助信号)
- ガードレールの一次フィルタ(危険コマンド、不適切コンテンツの検出)
- RAGのリランキングや候補絞り込み(最終判断は別途)
- 既存LLM呼び出しのうち、実質的に分類しかしていない箇所の置き換え
導入時の設計原則としては、confidence を行動可否の第二軸に置くこと。公式も confidence-gated routing のパターンを示しています。ただし「0.9以上なら自動、0.4未満ならフォールバック」といった閾値は普遍的な値ではありません。誤判定のコスト行列、偽陽性と偽陰性の非対称性、クラス別の較正、カバレッジ目標から決めるべきもので、記事や文書に出てくる数値はあくまで例示です。
日本語環境で使うなら、自前のベンチマークは必須です。英語前提で訓練されたモデルである以上、日本語での confidence 分布やECEが英語と同じである保証はありません。LLMに英訳させてから渡すという回避策もありますが、それでは速度とコストの優位が消えてしまうので、まず日本語のまま評価するのが筋でしょう。なお、サービスが米国西海岸で提供されている点は公式ブログから読み取れますが、リージョン一覧や日本からの具体的な追加レイテンシについて公式の保証は確認できていません。国内から使う際のネットワーク遅延は、自分の環境で実測してください。
判断を切り替えるべきタイミングとしては、次のあたりが目安になります。第三者の中立なハーネスで精度パリティが再現されること。較正が難易度や敵対的入力に対しても崩れないことが示されること。日本語で confidence 0.9以上の正答率が自社の運用要件を満たすこと。そして料金体系が維持されること。現状の価格が補助金的なものである可能性は、TypeSafe自身も否定していません。
まとめ
Jevは、AIに「考えさせる」のではなく「判定させる」ためのモデルです。出力空間をスキーマで閉じ、確率を較正し、並列に返す。この割り切りによって、これまでコストとレイテンシの制約でAIを入れられなかった場所に判断を差し込めるようになりました。LayerXが社内勉強会で得た気づきとして「既存のLLM呼び出しを置き換えるだけでなく、これまでAIを使うと考えなかった場所に差し込む」発想の転換を挙げているのは、この性質を的確に言い当てています。
一方で、公開されている性能値の多くはベンダー自己評価であり、参照値すら客観的な正解ラベルではありません。「ハルシネーションゼロ」はスキーマ適合性の話であって意味的な正しさの話ではなく、「較正されている」は予測群の統計的性質であって個々の回答の保証ではない。この区別を曖昧にしたまま設計すると、静かに間違い続けるシステムができあがります。
技術としては面白く、実用的価値もある。ただし、ベンダーの宣伝値と、第三者の小規模試用と、客観的に検証された事実は、それぞれ別のものとして扱う必要があります。低リスクな判断層から、自前の評価データで calibration まで測りながら始める。当面はそれが現実的な向き合い方だと考えます。
参考資料
- Introducing System One Models & Jev - TypeSafe AI Blog
- Models - TypeSafe AI / Introduction / System One
- Jev 1.13 jaggedness - TypeSafe AI / Confidence-gated routing
- TypeSafe AI Emerges From Stealth With $40M in Funding(プレスリリース)
- A new kind of AI model from a ChatGPT inventor is thrilling developers - TechCrunch
- Mini-Vibe Check: TypeSafe's Jev - Every / A first look at TypeSafe's Jev - lindfors.no
- Jev means structured output is interesting again - Sean Goedecke
- 既存の LLM が CPU なら、Jev はその GPU 版みたいなやつ - Zenn / TypeSafeのJevを正しく驚く、それってLLMでできませんか? - Zenn
- Jevとは何か? 従来型LLMやAIエージェントとの違いを理解する - Qiita / 緊急で社内Jev勉強会を開催したら - LayerX