Jevは本当に実用的なのか。公式仕様・開発者の実測・日本語性能を調べた

AIに文章を書いてもらうのではなく、「判断だけ」を頼む。

TypeSafe AIのJevを知って、まず整理したかったのは、この違いです。

高速、低価格、Zero Hallucinations。紹介で目にする言葉は強いのですが、実際の開発へ入れるなら、どこまで任せられるのかを知る必要があります。

そこで、Codexを使って公式ドキュメント、Xの開発者投稿、GitHubの比較実装、日本語の検証記事を調査・整理しました。

現時点の結論は、「LLMに任せていた小さな分類・振り分け」の置き換え候補。ただし、判断の正しさを保証するAIではないというものです。

この記事は2026年9月19日時点の調査記事です。私自身はまだJevのAPIを実行していません。公式の説明、第三者が測った結果、そこからの考察を分けて書きます。

1. Jevは「返信を書くAI」ではなく「担当を選ぶAI」

Jevは、TypeSafe AIが公開した判断向けモデルです。同社は、この種類をSystem One Modelと呼んでいます。素早い判断を意識した名称で、業界共通の性能認証ではありません。

公式発表ページは2026年9月15日表記。創業者Diogo Almeidaの発表投稿は、日本時間では9月16日でした。公式発表

何が違うのか、架空の問い合わせで考えてみます。

生成型のLLMには、「この人への返信を書いて」と頼めます。

Jevには、「請求・技術・営業・情報不足のどれに分類するか」と聞きます。返ってくるのは、決めた候補と確率などの値です。

入力は判断対象の文章やJSONと、質問・判断基準。出力は自由な文章ではありません。

ここを分けると、「ChatGPTの代わりになるか」という問いより、「今LLMにさせている分類を置き換えられるか」という問いの方が近いと分かります。

2. Choice・Score・Noulは、何が違うのか

Choice：候補から選ぶ

問い合わせの担当部署を選ぶ場合です。

• 請求

• 技術

• 営業

• 情報不足・対象外

選択結果に加え、各候補の確率とconfidenceを返します。候補は開発者が定義するため、「どれにも当てはまらない」を想定するなら、その選択肢も必要です。Choiceの仕様

Score：説明を付けた段階で評価する

不具合の深刻さなら、例えば次のように段階を定義します。

• 0：見た目だけの問題

• 1：機能に問題があるが回避策はある

• 2：利用を続けられず、回避策もない

返るスコアは、段階ごとの確率を重みとした平均です。説明用に、各段階の確率が0.1、0.6、0.3なら、スコアは1.2になります。

これは架空の計算例です。また、「深刻度が厳密に1.2倍」という意味でもありません。段階の説明が曖昧なら、数値だけ細かく見ても業務での意味は定まりません。Scoreの仕様

Noul：Yesである確率を返す

「この文章は返金を求めているか」のような問いです。

0〜1の値でYesの確率を返します。0.8なら「80%の程度で返金する」ではありません。YesかNoかへ変える閾値は、後段のコード側で決めます。

Noulには、ChoiceやScoreにある別のconfidence値はありません。Noulの仕様

3. なぜ速いのか。どこまで仕組みが分かっているのか

TypeSafeは、自由文を逐次生成せず、同じ入力に対する複数の判断を並列に返す設計を説明しています。学習方式は、Reinforcement Learning for Calibrated Decisions、略してRLCDです。

一方、今回確認した範囲では、パラメータ数や詳細な内部構成、学習データ、報酬関数まで追試できる情報は見つかりませんでした。

そのため、「Transformerを使っていない」「従来の言語モデルと無関係」とは書けません。公式のAI primerには、事前学習した言語モデルからRLCDへ進む説明があります。公式AI primer

入出力の違いは確認できる。でも、内部方式の新しさまで検証できたわけではない。

ここは分けておきたい点です。

4. 安い。ただし、料金表だけでは導入効果を決められない

調査時点の公式仕様は、次のとおりです。

• 固定モデルID：jev-1.13.0

• 入力料金：100万tokenあたり0.042ドル

• 出力料金：無料

• リクエスト上限：1分あたり1,200回

• token上限：1秒あたり250,000token

• context：全体64k。ただし入力stateと最長の質問の合計は32k以内

• 入力：テキストやJSON等。画像・音声・動画を直接読むものではない

250,000token／秒はAPIのrate limitで、文章生成速度ではありません。上限が変動し得ることも公式に書かれています。モデル仕様

料金表だけで計算すると、総入力1,000tokenの判断を1,000回行う費用は0.042ドルです。実請求ではなく、入力料金だけの計算です。

実際には、質問文のtoken、再試行、他のLLMへ回す費用、人の確認、組み込みと保守もあります。

「Jevの呼び出しは安い」と「自分の仕事全体が安くなる」は別です。少量の作業でほとんど人へ戻すなら、組み込みにかける時間の方が大きくなるかもしれません。

5. 「193.6倍高速・444.6倍安い」は、何との比較か

TypeSafeが掲げるこの倍率は、すべての仕事に当てはまる保証ではありません。

確認した公式評価は、セキュリティ事案、Agentの履歴、請求書処理、カスタマーサービスの4ワークフローです。規則をコードへ、狭い判断をモデルへ分ける構成を含みます。

さらに参照ラベルは、高性能LLMの回答を基にしています。人間が独立に確定した正解への一致率とは、評価の意味が異なります。公式の評価方法

今回、193.6と444.6の分子・分母をすべて確認し、自分で同じ値を再計算するところまではできていません。

したがって、「どのLLMよりも193倍速い」「判断力が193倍高い」とは解釈しません。

実際に比べるなら、同じ入力、同じ判定項目、同じ並列度で、完了までの時間と誤りを測ります。長い説明文を出させたLLMと、短い選択だけを返すJevの差を、そのままモデル全体の優劣にはしない方がよいと考えています。

6. 第三者の実測では、何が起きていたか

速さは出たが、すべての判断で勝ったわけではない

ShannonのX投稿から、比較コードを公開したGitHubまで確認しました。

合成シナリオの測定では、成功したリクエストの応答時間の中央値がJev176ms、Cerebras上のQwen215ms。問い合わせ分類の期待値一致は双方75／100でした。一方、HomeシナリオではJev15／24、Qwen24／24という結果です。

同じ測定内でも、速さと判断の良さは一致していません。出力形式やシナリオにも条件差があり、一度の開発機測定を一般性能には広げられません。本人の投稿、比較コード・結果

専用分類器を比較相手から外せない

Xでは、内部データで微調整したQwenがJevより速かったという報告や、Banking77で微調整したGLiNERが上回ったという報告も確認しました。

ただし、非公開データや特化学習との条件差があります。「Jevは不要」と結論づける材料ではありません。

ここから持ち帰りたいのは、固定の分類を大量に回すなら、汎用LLMだけでなく専用分類器も比較する、ということです。idenの報告、Josh Kuechlyの報告

7. 日本語で使えるか。少数の成功例と本番品質は分ける

公式は、英語が主な学習言語で最良性能と説明しています。日本語を含むCJKの入力は扱えますが、同等とはしていません。公式の言語対応

日本語を含む21入力を試したQiita記事では、期待値を付けた42項目が一致しています。一方、情報がほぼない「?」にもconfidence1.00の返答がありました。問い合わせ分類の検証

また、Zennのニュース選別では、過去53日分の素材を使って比較しています。Jevを53日間連続運用した記録ではありません。主評価のAUCはJev0.653、Haiku0.676、Sonnet0.697で、順位付けの精度と速さ・費用を分けて見る必要があります。比較用の実行環境にも差があります。ニュース選別の検証

日本語の実例があることは、試す理由になります。ただし、敬語での遠回しな依頼、否定、複数用件、社内用語、情報不足でも安定するかは別です。

日本語業務全般で安心して使える、と言えるだけの大規模な独立評価は、今回確認できませんでした。

8. Zero Hallucinationsでも、判断は間違える

ここが一番重要だと考えています。

選択肢がA・B・Cなら、存在しないDを返さない。それと、正解のBを選ぶことは別です。

問い合わせの部署を間違えても、返ってくる値の形は正常です。型のエラーが出ない分、そのまま後段の処理へ流れてしまう可能性もあります。

「出力が壊れない」と「判断が正しい」は分けて確認する必要があります。

公式も、計算、日付比較、多段の参照、無関係な長文、敵対的な入力などを弱点として挙げています。公式の既知問題

例えば、攻撃的な指示を文章として返さなくても、危険な操作を「許可」と誤分類すれば問題です。文章を生成しないことだけで、prompt injectionへの耐性を保証できるわけではありません。

9. confidenceを、そのまま「正解率」と読まない

ChoiceとScoreのconfidenceは、候補の確率分布がどれだけ集中しているかをまとめた値です。今回確認した公式ページでは、厳密な計算式までは示されていません。confidenceの説明

「confidenceが0.9以上なら自動処理」と決める前に、その範囲で実際にどれだけ間違うのかを見る必要があります。

さらに、モデルが返すクラス確率が現実の割合と合うか、という校正の問題もあります。例えばYes確率0.8と予測した多数の事例で、本当に約80%がYesなのか、という確認です。

私は検証するなら、次を分けて記録したいと考えています。

• 全体でどれだけ分類が合ったか。

• 高confidenceでも間違った例はあるか。

• 人へ戻す割合を増やすと、残る誤りはどう変わるか。

• 重大な見逃しが残っていないか。

平均の正解率が良くても、見逃した1件の影響が大きい業務では、そのまま自動化できません。

10. AI開発へ入れるなら、最終承認者にはしない

現時点で検証候補にしたいのは、作業の前後にある狭い判断です。

例えば、依頼を「調査のみ／コード修正／追加情報が必要」に分ける。生成後の記録から、要確認事項を拾う。次の処理を「再試行／人へ確認／停止」に分ける。

生成はLLM、正確な計算やテストはコード、重要な承認は人が担当します。Jevには、周辺の判断を補助してもらう設計です。これはまだ実装していない案です。

「テストしたと書いてあるか」と、「実際にテストが通ったか」は違います。Jevの判定だけで、自動mergeや公開まで進めるつもりはありません。

問い合わせ分類、ログの一次仕分け、取得済み文書の関連性判定なども候補です。一方、文章・コード生成、検索そのもの、正確な日付計算、自由な説明まで置き換える道具ではありません。

11. 導入前に埋めたい、6つの確認項目

Jevに限らず、判断用AIを試す前に次の項目を埋めておくと、何を測るかが決まります。

任せる判断を1つに絞ると：
選択肢と「情報不足・対象外」の扱い：
人が正解を決める基準：
間違えたときに起きること：
自動で進めず人へ戻す条件：
比較する方法と、記録する時間・費用・誤り：

「人が正解を決める基準」が曖昧なら、AIの比較より先にそこを整理します。速く返ってきても、何をもって正しいと言うか決まっていなければ、導入判断につながらないためです。

最初の候補は、合成の日本語問い合わせによる分類比較です。APIを呼ぶ前に20件の開発用データへ正解と理由を付け、別の未調整データで評価する方法を考えています。

実顧客のメールや障害ログを、そのまま外部APIへ送ることはしません。利用権・費用・送信できる情報を確認してから着手します。

まとめ：速さより先に、任せる判断を小さくする

Jevには、短い意味判断を低コストで組み込む可能性があります。第三者の実装・実測もあり、宣伝だけの話ではありません。

ただし、型が正しくても判断は間違う。確率が返っても、自分の業務でそのまま信用できるとは限らない。日本語の小さな成功例も、本番品質の保証ではない。

今回の調査で整理できたのは、「何でも任せられるAIが増えた」ということより、生成、判断、計算、人の確認を分けて設計する選択肢が増えたということです。

まずは一つの判断について、正解・失敗・人へ戻す条件を決める。そのうえで、Jevが役立つかを測りたいと考えています。

使うとしたら、問い合わせ分類・ログの仕分け・AIへの作業振り分けのどれでしょうか。具体的な場面があれば、コメントで教えてください。次に検証する題材の参考にします。

※本記事は全編無料です。料金・仕様は調査時点のもので、変更される可能性があります。第三者の実測はその方の環境・条件での報告です。私自身のAPI検証結果ではありません。