TypeSafeというAI企業が9月15日、Jevというモデルを公開しました。Jevは文章を書かず、判定だけをするモデルです。選択肢から一つを選ぶ、点数をつける、はい・いいえで答える、といった仕事をします。TypeSafeは、セキュリティインシデント対応、請求書処理、顧客サポートなど4つのワークフローを複数のモデルに同じ条件で任せて作ったランキングも、評価ページで公開しました。

このランキングでJevは、判定1回を1セントの何分の一かでこなしました。ところが、その点数をつけるときに何を正解としたのかをたどっていくと、判定モデルを選ぶときにまず見るべきなのはモデルの値段ではなく、正解データだということが見えてきます。

夜の机。採点を終えた答案用紙の束が二つ並び、その間に赤ペンが置かれている。右のクリップボードには何も挟まれていない。
生成した画像です。

TypeSafeの判定モデルJevは、判定1件0.0004ドルでClaude Sonnet 5と同じ67.8%を出しました

ランキングの点数は、4つのワークフローの平均です。JevとClaude Sonnet 5を並べるとこうなります。

モデルスコア(4ワークフローの平均)判定1件あたりの費用判定1件あたりの所要時間
Jev67.8%0.0004ドル0.4秒
Claude Sonnet 567.8%0.1174ドル78.1秒

ランキングに載っているモデルは9つです。Jevより点数が高いのはGPT-5.6 Sol(74.1%)、Claude Opus 5(73.1%)、GPT-5.6 Terra(67.9%)の3つで、判定1件あたりの費用はそれぞれ0.0836ドル、0.1761ドル、0.0304ドルでした。JevはそのすぐあとにClaude Sonnet 5と同点で並び、9モデルの中で最も安く、最も速いモデルです。 発表記事に書かれた価格は入力トークン100万あたり0.042ドルで、出力トークンには料金がかかりません。 AIに判定を任せるコストは、ほぼゼロになったわけです。

ところがその67.8%は、人が決めた正解との一致率ではなく、ランキングに載っていない2つのAIモデルの答えとの一致率です

67.8%が何と照らし合わせた数字なのかは、同じページの採点方法の説明に書かれています。

「ハーネスやラベルの正しさを議論する代わりに、コードは正しいと仮定し、現時点で最も賢い大規模モデルを基準に測ります。この評価では、GPT-6 AstraとClaude Fable 5.1をどちらもhigh thinkingで動かしてハーネスのすべての質問に答えさせ、その回答の平均から参照ラベルを作っています。」

TypeSafe AI, Workflow evals, 「How we evaluate」

TypeSafeは正解を人に決めさせませんでした。GPT-6 AstraとClaude Fable 5.1がすべての質問に答え、2つのモデルの答えを平均したものを正解にしました。そして、この2つのモデルはランキングに載っていません。つまり67.8%は、人が決めた正解を当てた割合ではなく、TypeSafeが今いちばん賢いと見なした2つのモデルと同じ答えを出した割合です。

こうしてつけた点数がどちらに傾くかは、TypeSafe自身も発表記事の注に書いています。2つのモデルの平均を正解にするとOpenAIとAnthropicのモデルに有利になり、JevとDeepSeekのモデルの性能は実際より低く出ているはずだ、というものです。

Jevで作られたプロジェクト194件のうち、答えが合っていたかを数字で示したのは3件。AIの答え以外の正解と照らし合わせたのは2件だけでした

Jevで作られたプロジェクトを選んで集めているjevable.comというサイトがあります。9月21日にこのサイトの公開APIが返したプロジェクトは194件でした。紹介文にドル金額を書いていたのが27件、所要時間を書いていたのが33件で、答えが合っていたかを数字で示していたのは3件でした。

作ったもの示された結果何を正解にしたか
詐欺メールの判別100通中96通を正解。判断の難しいメールは別のモデルに回した、パイプライン全体の結果正解があらかじめわかっているメール100通
Postgresのクエリプランナークエリが12%高速化ベンチマークで実際にかかったクエリ時間
建設図面の分類100%一致GPT-4.1とGPT-6 Astraが出した答え

詐欺メールの判別とクエリプランナーは、AIの答えではないところから正解を持ってきました。建設図面の分類はランキングと同じやり方で、別のAIモデルが出した答えを正解にしました。

同じリストにあるjevcalというツールは、紹介文を「みんなJevの確信度のしきい値をノリで決めている。0.95? 0.5?」(Everyone picks Jev confidence thresholds by vibes. 0.95? 0.5?)という一文で始めています。Jevが判定と一緒に出す確信度スコアがいくつ以上ならその判定を信じるか、みんな勘で決めているという意味です。jevcalは、自分のデータを入れて目標の精度を伝えれば、そのしきい値を決めてくれると説明しています。 公開から4日間のツイートを集めて分析したOpenChamberの記事も、同じ問いを取り上げました。0.95というスコアが自分の業務で本当に95%当たるという意味なのかはスコアだけ見てもわからず、正解のついた例と照らし合わせて初めてわかる、と書いています。

Red Hatが正解つきの公開データで比べ直すと、Jevの順位はタスクによって1位と4位に分かれました

Red HatのRob Geada、Mac Misiura、Shelton Cyrilの3人は10月2日、Jevのような判定モデルを既存のAIの安全装置(ガードレール)と比べた記事をRed Hat Developerに公開しました(10月5日更新)。タスクは、AIをだますための指示文(プロンプトインジェクション)を防ぐことと、有害なコンテンツをふるい落とすことの2つです。3人は安全装置を4系統・9通りの方式で組み、危険な文と安全な文にあらかじめ正解ラベルがついた公開データセットを各方式に判定させました。データは危険と安全が半々で、各方式が止めるか通すかで下した判定を、データセットの正解と比べています。

タスク順位方式正解率(accuracy)
プロンプトインジェクションの防止1位Qwen3.6-35B(汎用モデルに判定を任せる方式)89.31%
プロンプトインジェクションの防止2位Red Hatの事前学習済み分類器(パラメータ2億)89.01%
プロンプトインジェクションの防止4位Jev86.35%
有害コンテンツの除外1位Jev86.20%
有害コンテンツの除外2位DiffusionGemma85.53%
有害コンテンツの除外3位Qwen3.6-35B85.47%

速度でもJevが勝っていたわけではありません。プロンプトインジェクションの防止では、Red Hatの分類器のレイテンシが54.1ミリ秒、Jevが348.1ミリ秒でした。3人は、判定モデルが汎用モデルに判定を任せる方式より速い、安い、あるいはよい答えを出すという結果は見つからなかったと書いています。

「判定モデルがLLM-as-a-judgeと比べて、より速く、より安く、より質の高い答えを出すという結果は得られなかった。」

Rob Geada・Mac Misiura・Shelton Cyril, Red Hat Developer

この比較にも限界があります。3人は試験をイギリスで行っており、米国にあるJevのAPIとRed Hatのクラスタまでの往復で最低でも約56ミリ秒が上乗せされたと自ら書いています。タスクは2つだけで、使ったのは英語の文だけです。また、2位に入った事前学習済み分類器は、Red Hatが自社製品のOpenShift AI 3.6に標準の安全装置として載せているモデルです。

TypeSafeのランキングでJevは、9モデルのうち3モデルに次ぐ位置にClaude Sonnet 5と同点で並び、そのランキングの正解は2つのAIが出した答えでした。Red Hatの比較では、正解はデータセットに最初からついていたラベルで、Jevは有害コンテンツの除外で1位、プロンプトインジェクションの防止で4位でした。2つのランキングはタスクも違うため、順位が変わった理由を正解データだけに帰すことはできません。ただ、正解を決める側が変わった比較で、発表記事が掲げた「同程度の性能を、はるかに安く速く」という主張は、Red Hatの比較では確認されませんでした。

判定1件0.0004ドルで済む今、判定モデルを選ぶときにまず問うべきはモデルの値段ではなく、自分の仕事に正解データがあるかどうかです

TypeSafeは発表記事で、ランキングの正解を出したGPT-6 AstraとClaude Fable 5.1を、他社が作ったモデルの中で最も大きく、最も賢く、最も高価なモデルだと紹介しています。 ランキングに載ったモデルはすべて各社の標準設定で答え、正解を出した2つのモデルだけが長く考える設定で答えました。

判定1回を0.4秒、0.0004ドルでこなすモデルを売る会社でさえ、その判定を採点する正解は、最も高価な2つのモデルにじっくり考えさせて作りました。正解つきのデータを持つRed Hatが同じモデルを比べ直すと、順位はタスクごとに変わりました。

判定1件0.0004ドルで済むモデルまで登場した今、判定モデルを選ぶ人がまず問うべきなのはモデルの値段よりも、その判定が自分の仕事で正しかったかを見分けられる正解データがあるかどうかです。

さらに深く知りたい方へ

採点方法と4つのワークフロー 正解をどう作ったか、モデルごとにどのワークフローで点数に差がついたかが、ワークフロー別の表と一緒に載っています evals.typesafe.ai

正解つきデータで見たガードレール比較 9通りの方式の結果とレイテンシ、試験環境の限界をRed Hat自身がまとめた記事です developers.redhat.com

ツイート12,759件の集計 確信度スコアが実際の正解率と一致しているかを何で確かめるべきかが整理されています openchamber.dev