Jevの精度はどれくらいか|公式ベンチマーク・第三者の実測・苦手な判断と精度の上げ方
仕様確認・更新日: · 編集: 株式会社ウェステリア
「Jevの精度はどれくらいか」への短い答えは、TypeSafe AI自身の評価で67.8%、GPT-5.6 Terraとほぼ同じ、というものです。ただしこの数字は人間の正解と比べたものではなく、測り方を知らずに読むと過大にも過小にも受け取ってしまいます。この記事では、公式ベンチマークの数値とその作られ方、発表後に出てきた第三者の実測、「ハルシネーションしない」「確信度が校正されている」という説明が保証している範囲を、2026-09時点で確認できる情報をもとに整理し、業務でどう運用に落とすかまでをまとめます。
結論から
- TypeSafe AI公式の4ワークフロー評価では、Jevの精度は67.8%(GPT-5.6 Terra 67.9%、GPT-5.6 Sol 74.1%、Claude Opus 5 73.1%)。1件あたりのコストは0.0004ドル、応答は0.4秒で、Terraと同水準の精度を約76分の1のコストと約25分の1の時間で出す、というのが公式の主張です
- ただしこの「精度」は、GPT-6 AstraとClaude Fable 5.1の回答の平均を正解とみなした一致率であり、人間が付けた正解との比較ではありません。4つのワークフローもTypeSafe AI自身が設計したものです
- 第三者の実測では、公開データセットでの正答率がJev 0.57〜0.97(GPT-5.6 Terraと同等かやや下)、国内の検証では規則ベースとの組み合わせで95%、Jev単体では70%という結果が出ています。業務の切り方で数字は大きく動きます
- Jevが苦手なのは計算・件数・日付の比較・何段もの推論で、これらはコードで処理するのが前提です。精度を上げる方法は、Jevへの問いを意味の判断だけに絞り、観点ごとに分けて聞くことにほぼ集約されます
- Jevが仕組みとして保証しているのは「指定した選択肢の外を返さない」「型が壊れない」ことであり、選択肢の中で間違える可能性は残ります
- RLCDという学習手法で確信度を実際の正答率に近づけている点が特徴です。確信度で閾値を切り、高いものは自動処理、低いものは人間レビューに回す運用が基本形になります
- 閾値と期待される効果は業務ごとに違うため、導入前に自社の過去データで正答率と保留率を必ず測ってください。ベンダー公称値では判断できません
自社のその業務にJevが向くのか、月いくらになるのかを先に知りたい方へ。 業務と月の件数を一言送るだけで、向き不向きと月額コストの試算を2営業日以内に無料でお返しします → 料金の考え方・支援メニュー・よくあるご質問は「Jevの相談窓口」に →
公式ベンチマークの数値(2026-09時点)
TypeSafe AIは、Jevの評価結果を専用サイト(evals.typesafe.ai)で公開しています。対象は「セキュリティインシデントの対応判断」「エージェントのトレース確認」「請求書の支払い判定」「カスタマーサービスの次のアクション決定」の4つの業務ワークフローで、各モデルに同じ判断をさせて一致率・1件あたりのコスト・応答時間を比べています。4ワークフローを均等に平均した数値が次の表です。
ワークフロー別に見ると、Jevはカスタマーサービスで76.0%、エージェントのトレース確認で71.6%、セキュリティインシデントで61.7%、請求書処理で61.8%です。請求書処理では最上位のGPT-5.6 Solが79.1%を出しており、Jevとの差が17ポイント以上開いています。「平均でTerra並み」であっても、業務によっては上位LLMとの差が大きい、というのが公式数値から読み取れることです。
| モデル | 精度(4ワークフロー平均) | コスト/件 | 応答時間/件 |
|---|---|---|---|
| Jev | 67.8% | 0.0004ドル | 0.4秒 |
| GPT-5.6 Terra | 67.9% | 0.0304ドル | 10.1秒 |
| GPT-5.6 Luna | 66.8% | 0.0033ドル | 12.9秒 |
| GPT-5.6 Sol | 74.1% | 0.0836ドル | 23.3秒 |
| Claude Sonnet 5 | 67.8% | 0.1174ドル | 78.1秒 |
| Claude Opus 5 | 73.1% | 0.1761ドル | 37.8秒 |
この表を読むときに欠かせない注意が2つあります。第一に、「精度」の分母になっている正解ラベルは人間が付けたものではなく、GPT-6 AstraとClaude Fable 5.1を高い思考設定で動かした回答の平均です。つまり表の数字は「最上位のLLM 2つの平均とどれだけ一致したか」であって、両モデルが揃って間違える問いでは、その間違いに合わせた答えが正解扱いになります。第二に、4つのワークフローを設計したのはJevを作ったTypeSafe AI自身です。海外の技術記事(dev.to)では、この2点を根拠に「Terraに1ポイント差で並んだ」という見出しの読み方に注意を促す指摘が出ています。
それでも公式数値には使い道があります。約3分の1は参照ラベルと食い違う、という規模感がわかるからです。全件をJevの判断だけで流す前提は最初から成り立たず、確信度で閾値を切って人間のレビューを挟む設計が必要になります。この点は後半で扱います。
仕様の出典: TypeSafe AI「Workflow Evals」(evals.typesafe.ai) / TypeSafe AI「Introducing System One Models & Jev」 / dev.to「Jev Beat GPT Luna by 1 Point. GPT-6 and Claude Wrote the Answer Key.」
第三者による実測(2026-09時点)
発表(2026-09-15)から数日で、公式とは別のデータでJevを測った結果が出始めています。件数や条件がまちまちなので単純比較はできませんが、公式数値だけでは見えない傾向が読み取れます。
公開データセットでの比較としては、GitHubで公開されている独立評価(4esv/jev-eval)があります。意図分類のCLINC(151択)とBanking77(77択)、感情分析のSST-5(5択)とIMDB(2択)の4種類に、各300件を入れてJev(v1.13.0)とGPT-5.6 Terraを比べたものです。正答率はJevがCLINC 0.897、Banking77 0.780、SST-5 0.570、IMDB 0.970で、Terraが測られた3タスクではBanking77 0.847、SST-5 0.593、IMDB 0.970でした。選択肢が多い分類で互角、細かい感情の段階付けではやや下、という形です。作者は「ベンチマークのデータが学習に含まれているかどうかで勝者が決まる」「1台の環境での1回の実行」と断っており、確定的な序列ではありません。
校正の実測も同じ評価に含まれています。確信度と実際の正答率のずれを示すECE(期待校正誤差。0に近いほど良い)は、JevがCLINC 0.039、Banking77 0.110、SST-5 0.200、IMDB 0.042で、TerraはBanking77 0.081、SST-5 0.303、IMDB 0.020でした。2択や多択の分類ではよく校正されている一方、5段階の程度判定では両モデルとも大きくずれています。応答時間の中央値はJevが0.17〜0.20秒、Terraが約1.04秒で、Jevは選択肢の数が増えても応答時間がほぼ変わらない点が特徴として挙げられています。
問いの切り方で精度が変わる例も報告されています。海外のまとめ記事(BERI)が引いているフィッシングメール判定の検証では、2,000件のメールに対して1つの問いで「フィッシングか」を聞いたときの精度が62.6%だったのに対し、5つの狭い問いに分けて、ラベル付きデータ1,000件で重み付けを学習させると95.0%まで上がっています。同記事が引く別の校正研究では、公開データ全体でのECEが0.107、Yes/Noの問い(Noul)は自信が低めに、選択肢や点数の問い(Choice/Score)は自信が高めに出る傾向が示されています。いずれも二次情報を含むため、数値は元の検証ページで確認してください。
国内の検証も出ています。Zennの検証記事(kumewata氏)は12ケースを試し、店舗名の抽出では正規表現などの規則だけで81%、Jev単体で70%、規則で確定できるものを先に処理してJevに残りを回す組み合わせで95%という結果を報告しています。AI生成文の判別では16件中14件が正解(87.5%)で、太字や文の長さで判定する規則(16件中15件)に届きませんでした。Noulで「程度」を聞いた220件では、161件が確信度0.0〜0.1の帯に集中し、自前データでのECEは0.071でした。著者は、時間を使ったのはモデルの精度調整ではなく「試す前の見極めと設計」だったとまとめています。DevelopersIOの検証では、個人情報を含むかの判定で、氏名と住所を含む文に88%、含まない商品説明に5%、氏名を一般化した文に34%の確信度が返っており、実在の人名に強く反応する様子が示されています。
| 検証 | 対象 | 結果 | 読み方 |
|---|---|---|---|
| 4esv/jev-eval(GitHub) | 公開データ4種×300件、Jev対GPT-5.6 Terra | 正答率 Jev 0.57〜0.97、ECE 0.039〜0.200 | 多択分類で互角、段階付けは弱い。1回実行 |
| フィッシング判定(BERIまとめ) | メール2,000件 | 1問で62.6% → 5問に分けて95.0% | 問いの分解と重み付けで大きく変わる |
| Zenn 12ケース検証(国内) | 店舗名抽出・AI生成文判別など | 規則81% / Jev単体70% / 組み合わせ95% | 規則で先に絞ってからJevに渡すと効く |
| DevelopersIO(国内) | 個人情報の有無の判定 | 含む88% / 含まない5% / 氏名を一般化34% | 確信度の差が明確に出る例 |
共通して言えるのは、Jevの精度は「モデルの性能」というより「問いの設計」で決まる部分が大きい、ということです。1つの大きな問いを投げるより、規則で確定できるものを先に除き、残りを狭い問いに分けて聞くほうが、同じモデルでも数字が上がっています。自社で測るときも、この設計を含めて比較してください。
仕様の出典: GitHub 4esv/jev-eval「Independent eval of TypeSafe Jev vs GPT-5.6 Terra」 / BERI「TypeSafe's Jev Scores 62.6% Asked Once and 95% Split Five Ways」 / Zenn「Jev を試す前に決めること──12 ケースの検証で見えた、モデルの精度より時間を使ったもの」 / DevelopersIO「判断特化型AI「Jev」を簡単な具体例でわかりやすく解説!実際に試してみた」
精度が出にくい問いと、精度を上げる問いの立て方(2026-10時点)
Jevの精度が低く出るとき、原因はモデルより問いの側にあることが多いです。公式ドキュメントは、Jevが想定しているのは「知識のある人が数秒で下せる」程度の判断だとし、長い推論が必要な問いや、独立した複数の要素を比べる問いは分解するよう案内しています。また、Jevは返答文や推論の説明を生成せず、入力はテキストだけです(2026-10時点)。
第三者のガイド(Layer3 Labs、2026-09-22更新)は、さらに具体的に、計算、件数を数えること、日付の前後比較、何段もの間接的な推論はJevの苦手分野だと整理しています。例として挙げられているのは「請求書の日付が納品日より前か」の確認で、こうした処理は通常のプログラムで行うべきだとしています。敵対的な入力(判定をすり抜けるように細工された文)への強さも保証されていません。
裏返すと、精度を上げる方法はほぼ「Jevに渡す問いを、意味の判断だけに絞る」ことに集約されます。下の表は、精度が出にくい問いの典型と、書き換えの方向をまとめたものです。
- 精度が低い業務では、まず誤答を20〜30件集め、上の表のどれに当たるかを分類する
- 計算・比較・規則で確定できる部分をコードに移し、Jevへの問いを意味の判断だけにする
- 1つの問いに観点が2つ以上入っていれば分ける。複数の問いは1回のAPI呼び出しでまとめて送れる
- 選択肢の名前と説明を、業務担当者が読んで迷わない言葉に直す
- 直すたびに同じ正解ラベル付きデータで正答率と確信度の分布を測り直し、改善を数字で確かめる
| 精度が出にくい問い | 例 | 書き換え方 |
|---|---|---|
| 計算・件数を含む | 「明細の合計が請求額と一致するか」 | 計算はコードで行い、Jevには「この明細は経費として妥当か」のような意味の判断だけを聞く |
| 日付・数値の比較 | 「請求日が納品日より前か」 | 日付の抽出と比較はコードで行う。Jevは比較に使わない |
| 複数の観点を1問に詰める | 「この案件は優先度が高いか」 | 緊急性・金額・顧客区分など観点ごとに別の問いにし、重み付けはコードで行う(フィッシング判定では1問62.6%→5問95.0%の報告) |
| 規則で確定できるものまで渡す | 店舗名の抽出をすべてJevに任せる | 正規表現などで確定できる分を先に処理し、残りだけをJevに渡す(国内検証で単体70%→組み合わせ95%) |
| 程度をYes/Noで聞く | Noulで「どのくらい不満か」を聞く | 程度はScore(段階の基準=ルーブリックを書く)、真偽はNoul、選択はChoiceと使い分ける |
| 判断の理由まで欲しい | 「なぜ却下すべきか」 | Jevは理由を返さない。理由が要る判断は、Jevで絞った後に推論モデルや人に回す |
この手順で大事なのは、モデルを替える前に問いを直すことです。前節の検証でも、同じJevで数字が25〜32ポイント動いているのは、モデルの設定ではなく問いの分け方と規則との組み合わせを変えた結果でした。
仕様の出典: TypeSafe AI Docs「Introduction」 / TypeSafe AI Docs「System One」 / Layer3 Labs「Jev Benchmarks」(2026-09-22更新) / BERI「TypeSafe's Jev Scores 62.6% Asked Once and 95% Split Five Ways」 / Zenn「Jev を試す前に決めること──12 ケースの検証で見えた、モデルの精度より時間を使ったもの」
「ハルシネーションしない」が保証している範囲
TypeSafe AIは、Jevについて「構造上ハルシネーションや型エラーを起こせない」と説明しています。この主張自体は正しいのですが、対象を正確に押さえる必要があります。保証されているのは出力の形式です。
たとえば「請求」「技術」「アカウント」の3択を指定したとき、Jevは必ずこの3つのどれかを返します。存在しないカテゴリを作り出すことも、JSONのスキーマから外れた値を返すこともありません。LLMに構造化出力を指示したときに起きがちな、フォーマット崩れやパース失敗のリトライ処理は不要になります。
一方で、「請求」が正解の問い合わせに対してJevが「技術」と答える可能性は残ります。gihyo.jpの記事でも、指定外の答えや不正な出力構造は生じないが選択肢内での誤判断の可能性は残存する、という整理がされています。つまりJevが解決するのは「壊れた出力」の問題であって、「間違った判断」の問題ではありません。前節の公式数値で約3分の1が参照ラベルと食い違っているのは、まさにこの「選択肢の中での誤り」です。
RLCDと「校正された確信度」の意味
TypeSafe AIは、Jevの学習にRLCD(Reinforcement Learning for Calibrated Decisions)という強化学習手法を使っていると発表しています。狙いは、モデルが返す確率を実際の正答率に合わせることです。
校正(キャリブレーション)された確率とは、「確信度0.8で返した答えを集めると、そのうち約8割が正解している」という状態を指します。当たり前のようですが、通常のLLMでは成立しません。LLMに「確信度も教えて」と頼むと、0.9や0.95といった高い値を返しがちで、その数字と実際の正答率が対応していないことがよくあります。数字は出るが、閾値を切る根拠には使えない、という状態です。
Jevはここを学習の目的そのものに置いています。確信度が運用上の判断材料として使えるなら、「0.9以上は自動、それ未満は人間」という設計が成立します。判断特化モデルを名乗る以上、この性質がJevの実用上の中核といえます。
ただし「個別の答えの正しさ」は保証されない
ここで公式ドキュメントの但し書きを引いておきます。TypeSafe AIのドキュメントでは、System Oneモデルの確率は結果に対して最適化されているとしつつ、個々の回答の正確性を保証するものではなく、複数の予測をまとめた集団として最適化されている、という趣旨の説明がされています。
校正は統計的な性質です。「確信度0.95の判断は100件のうち95件正しい」は言えますが、「目の前のこの1件は正しい」は言えません。残りの5件がどれかは事前にわかりません。
この区別は運用設計に直接効きます。1件の誤りが取り返しのつかない損害になる業務——高額な与信の最終決定、人の処遇に関わる判定など——では、確信度がいくら高くてもJevの出力を最終決定にしない設計が必要です。逆に、誤りが後工程で検出でき、やり直しがきく業務であれば、閾値を切って自動処理に回す価値が出てきます。
確信度で自動処理と人間レビューを分ける
運用の基本形は、確信度の閾値で処理を3つに分ける構成です。上限の閾値を超えたものは自動で処理し、下限を下回ったものは明確に保留、その間は人間のレビューに回します。閾値を1つではなく2つ置くと、「自信を持って別物と判断した」ケースを自動処理に含められます。
閾値をいくつにするかは、業務ごとに決めるしかありません。決め方の考え方としては、誤って自動処理してしまったときのコストと、人間のレビューにかかるコストを比べます。誤りのコストが高い業務は閾値を上げて自動化率を下げ、レビューのコストが高い業務は閾値を下げて自動化率を上げます。
注意したいのは、閾値を上げれば上げるほど人間に回る件数が増え、自動化の効果が薄くなる点です。「精度を上げるために閾値を厳しくしたら、結局ほとんど人間が見ることになって工数が変わらなかった」という結末は実際に起こります。閾値の設定は、精度の問題ではなく費用対効果の問題として扱ってください。
- 自動処理に回る件数の割合(自動化率)を先に計算する
- 自動処理に回った中での誤り率を、過去データで測る
- 人間に回る件数が、現在の人員で処理できる量かを確認する
- 保留になったものを誰がどの頻度で処理するかを決める
- 閾値を変えたときに上の4つがどう動くかを、表にして比較する
導入前に自社データで測る手順
ベンダーが出す速度やコストの数値は、自社の精度を保証しません。TypeSafe AIが公表している「LLM比40〜200倍速」「最大444.6倍低コスト」といった数値は、いずれも同社自身の評価に基づくものです。判断材料としては、自社データで測った数字だけを使ってください。
実務的な手順は次のとおりです。まず、対象業務の過去データを300〜1,000件ほど用意し、人間が正解ラベルをつけます。次に、実際に運用するのと同じ選択肢・同じ入力形式でJevに判定させ、正答率と確信度の分布を出します。ここで、確信度の帯ごとに正答率を集計すると、校正が自社データでも成立しているかを確認できます。
比較対象を置くことも欠かせません。同じデータに対して、今使っているルールベースの処理、LLMに構造化出力を指示した場合、人間が判断した場合の3つを並べます。精度だけでなく、処理時間と総コストを同じ表に並べると判断しやすくなります。単価が安いモデルに変えても全体のコストが下がるとは限らないためです。
| 測る項目 | 測り方 | 判断の目安 |
|---|---|---|
| 正答率 | 正解ラベル付きデータでの一致率 | 現行手段と比べて同等以上か |
| 確信度の校正 | 確信度の帯ごとに正答率を集計 | 0.8の帯が実際に8割前後か |
| 自動化率 | 閾値を超えた件数の割合 | 人間の工数が実際に減る水準か |
| 保留の処理コスト | 保留分を戻す処理の費用と頻度 | 全体コストが下がるか(逆転しやすい) |
| 応答時間 | 自社の場所・経路での実測 | 処理フローに挟める速さか |
本番ログでの検証例が示していること
発表後に、本番の処理ログを使ってJevを再実行した検証記事が公開されています。知識グラフの名寄せを題材にしたもので、精度を測るときの落とし穴が具体的に示されている点で参考になります。
この検証では、確信度0.85を閾値にして判定したところ、保留の割合が条件によって大きく変わりました。ペア単位で数えると13.0%だったものが、ノード単位で集約すると39.6%になっています。著者は途中で「保留が多い」と見えた数字が評価単位と集約ルールに由来するものだったと自己修正しています。精度を語るとき、何を1件と数えるかで数字が変わるという実例です。
コスト面では、Jev単体の処理費は既存処理の約96%減だった一方、保留分を既存処理に戻すフォールバックを含めると全体で約4.1%増になりました。8通りの設計変更を試しても初版を明確に上回る方式が見つからず、この検証では採用見送りという結論になっています。著者は「Jevが名寄せに向かない」という一般化ではなく「今回の設計では」という限定付きの判断だと明記しています。
精度の話を扱うときの注意点
Jevは発表からまだ日が浅いモデルです。2026-09-20に順番待ちが撤廃されて誰でも使えるようになりましたが、モデルの重みは公開されておらず、学習手法(RLCD)の中身も明かされていません。第三者の実測はこの記事で挙げたように出始めていますが、いずれも数百〜数千件、1回の実行といった規模です。この記事の内容も「2026-09時点の整理」として読み、最新はTypeSafe AIの公式情報で確認してください。モデルの版が上がれば、正答率も確信度の性質も変わりうる段階です。
実務的な結論としては、精度の議論はモデルの一般的な性能ではなく、自社の業務・自社のデータ・自社の閾値の3点セットで行うのが確実です。「Jevは精度が高いか」ではなく「この業務でこの閾値を切ったとき、人間の工数がどれだけ減り、誤りがどれだけ残るか」を問いにすると、検証の設計がはっきりします。
この検証設計を社内だけで組むのが難しい場合は、ウェステリアで無料のヒアリングを承っています。実際に測るべき項目の洗い出しから対応しています。
よくあるご質問
- Jevの精度は何%ですか?
- TypeSafe AI公式の4ワークフロー評価(2026-09時点)では67.8%で、GPT-5.6 Terraの67.9%とほぼ同じ、GPT-5.6 Solの74.1%やClaude Opus 5の73.1%より低い水準です。ただしこれは人間の正解ではなく、GPT-6 AstraとClaude Fable 5.1の回答の平均との一致率です。第三者の実測では公開データで0.57〜0.97、国内の検証では問いの設計次第で70%から95%まで動いています。自社の業務での数字は、自社データで測るしかありません。
- Jevが苦手なことは何ですか?
- 公式ドキュメントは、Jevが想定するのは知識のある人が数秒で下せる程度の判断で、長い推論が必要な問いや複数の要素を比べる問いは分解するよう案内しています。第三者のガイドは、計算、件数を数えること、日付の前後比較、何段もの間接的な推論を苦手分野として挙げています(2026-10時点)。返答文や判断の理由も生成しません。こうした処理はコードや推論モデルに任せ、Jevには意味の判断だけを渡すのが基本です。
- Jevの精度が低いときはどうすればいいですか?
- モデルを替える前に問いを直します。誤答を20〜30件集めて原因を分類し、計算・比較・規則で確定できる部分をコードに移す、1つの問いに入った複数の観点を別々の問いに分ける、程度を聞くならNoulではなくScoreを使う、といった直し方が効きます。公開されている検証では、問いを5つに分けて62.6%が95.0%に、規則と組み合わせて70%が95%に上がった例があります。直すたびに同じ正解ラベル付きデータで測り直してください。
- JevはGPTやClaudeより精度が高いのですか?
- 公式評価では、精度はGPT-5.6 TerraやClaude Sonnet 5と同水準で、GPT-5.6 SolやClaude Opus 5には及びません。Jevの売りは精度で上回ることではなく、同じ精度をはるかに低いコストと短い時間で出すことです。独立評価でも、選択肢の多い分類では互角、5段階の程度判定ではやや下という結果でした。
- Jevは間違えないのですか?
- 間違えます。保証されているのは「指定した選択肢の外を返さない」「型が壊れない」ことだけで、選択肢の中で誤る可能性は残ります。誤りが許されない業務では、確信度で閾値を切って人間の判断を挟む設計が必要です。
- 確信度が校正されているとは何のことですか?
- 確信度0.8で返した答えを集めると実際に約8割が正解している、という状態を指します。TypeSafe AIはRLCDという学習手法でこれを実現していると説明しています。閾値を切って自動処理と人間レビューを分ける運用の根拠になる性質です。
- LLMに確信度を出させるのと何が違いますか?
- LLMに確信度を尋ねても、返ってくる数字と実際の正答率が対応しないことがよくあります。0.9や0.95に偏りがちで、閾値を切る根拠にはなりません。Jevはその対応関係を学習の目的に置いている点が違いです。ただし自社データで実際に成立するかは測って確認してください。
- 精度を測るのに何件のデータが必要ですか?
- 業務によりますが、確信度の帯ごとに正答率を見たいので、最低でも300件、できれば1,000件程度あると帯ごとの集計に意味が出ます。件数が少ないと、たまたまの当たり外れで数字が動いてしまいます。
- TypeSafe AIが公表している数値は信用できますか?
- 速度やコストの数値は同社自身の評価に基づくもので、比較対象の選び方によって結果が変わります。発注や導入の判断は、自社データで測った数字を根拠にしてください。