Jev の公式ベンチマーク（Workflow Evals）の読み方と注意点

TypeSafe のトップページにある「193.6 倍速く、444.6 倍安い」は、公式の評価サイト Workflow Evals の結果から来ています。結論から言うと、これは特定の条件での、公式自身による計測の上限寄りの値です。何を測った数字なのかを知っておくと、自分の用途に当てはまるかを判断できます。

このページは公式の公開情報を読み解いたもので、このサイトではベンチマークを再現していません。 数値は 2026-09-21 時点の公式サイトの表示です。

何を測っているのか

Workflow Evals は、業務の自動化を題材にした4つのワークフロー（セキュリティインシデント、エージェントの実行記録の監視、請求書の処理、カスタマーサービス）で、モデルを比べています。

特徴は、全モデルに同じワークフローを与えることです。1つの大きな問題を丸ごと解かせるのではなく、判断を Noul・Choice・Score の小さな質問に分け、分岐はコードが行います。言語モデルには、同じ形式で答えさせるためのラッパーを使っています。比較として、同じ方針を1つのプロンプトにまとめて解かせた場合（prompt）も載っています。

公表されている数字

各点は、4つのワークフローの平均（均等な重み）です。

読み取れること:

• Jev は一致率で1位ではありません。 上に sol、opus 5、terra がいます
• Jev の位置は「sonnet 5 や terra と同程度の一致率を、費用でおよそ2桁、時間で1〜2桁小さく出す」です。公式の言い方では、費用と時間のどちらの軸でも、Jev より安くて（速くて）かつ一致率が高いモデルが無い、ということになります
• 同じモデルでも、1つのプロンプトで解かせるより、ワークフローに分けたほうが、一致率・費用・時間のすべてで良い結果でした（例: opus 5 は 64.8% → 73.1%）。分けて聞くこと自体が効いています

「精度」は正解との一致ではない

ここが最も大事な点です。この評価には人が付けた正解データがありません。公式の説明では、GPT-6 Astra と Claude Fable 5.1（どちらも高い思考設定）の回答の平均を基準とし、それとの一致を測っています。

つまり表の「一致率」は、「最も大きく高価な2つのモデルと、どのくらい同じ答えを出すか」 です。

• 基準のモデルが間違えていれば、正しく答えたモデルが不一致と数えられます
• 公式は、この方法は OpenAI と Anthropic のモデルに有利に働き、Jev と DeepSeek のモデルの相対的な性能を低く見積もっている可能性が高い、と書いています
• 「ワークフローのコードは正しい」と仮定しています。ワークフローの設計が良いかどうかは測っていません

公式自身が認めている注意点

発表ブログの「Nuance」の節に、次のことが書かれています。

• 193.6 倍・444.6 倍という数字は、現実の改善幅の中でも高いほうになると見込んでいる
• ワークフローの内容は、Jev をよく見せるために選んだり作ったりしたものではなく、学習データにも入っていない
• ただし、TypeSafe のモデル開発チームのメンバーが作ったものなので、偏りはあり得る

公式がここまで書いていること自体は評価できます。読む側は、これを「第三者の検証」ではなく「開発元による、条件を明示した計測」として受け取るのが適切です。このサイトが確認した範囲では、査読論文や公開された重みは見つかっておらず、外部から同じ条件で追試する手段は限られています。

見出しの倍率は、別々の相手との比較らしい

公式は、193.6 倍と 444.6 倍がそれぞれどのモデルとの比較かを、このサイトが確認した範囲では明記していません。表の値から計算してみると、こうなります（Jev は表示上 $0.0004・0.4 秒）。

速さは sonnet 5、安さは opus 5 との比較に最も近い値です。 表示が丸められているので断定はできませんが、2つの数字が同じ相手との比較ではない可能性があります（これはこのサイトの計算による推測で、公式の説明ではありません）。

この表からもう1つ分かるのは、比較相手で倍率が大きく変わることです。小型で安い luna が相手なら、費用の差は約 8 倍です。「何倍」という数字は、いま自分が使っているモデルを相手に置き直して読む必要があります。

速度の数字について

ブログには、端から端までの応答時間は 70〜500ms、という記述があります。このサイトで日本から呼んだときの実測は、1回あたり 0.2〜0.7 秒でした（REST API の使い方、AI Gateway 経由）。公称の範囲とおおむね合いますが、通信の距離で変わります。

一方、ベンチマークの「1件 0.4 秒」は、複数の質問を含むワークフロー1件ぶんの時間です。Jev は1回のリクエストに多数の質問をまとめられるので、ここで差が開きます。

自分の用途で確かめる

ベンチマークは出発点であって、答えではありません。特に日本語のデータでは、公式が「英語以外では精度が下がる」と明記しているので、なおさらです。

1. 正解の分かっているデータを用意する。 過去に人が振り分けた問い合わせ、レビュー済みの分類など。必要な件数は、分類の数や、まれにしか起きない重大な取り違えをどこまで見たいかで変わります。少ない件数で出した数字は、幅を持って読んでください
2. いまの方法と同じデータで比べる。 一致率だけでなく、間違え方も見る。重大な取り違えが無いか
3. 確信度で切ったときの数字を見る。 しきい値を上げると、自動で処理できる割合は下がります。残ったものの正解率が上がるかどうかは、自分のデータで確かめてください（苦手な種類の質問では、確信度が高くても外れることがあります）。用途に合う点を探します（確率と confidence の読み方）
4. 費用と時間を実測する。 usage.input_tokens と往復時間を記録する。料金は入力 100 万トークンあたり $0.042 です（料金と制限）
5. Jev に向かない判断が混ざっていないか確かめる。 計算、日付の比較、何段もの推論は、結果を悪く見せます（Jev が苦手なこと）

個人による実測は Zenn や Qiita にも出ています。条件（データ、言語、質問の書き方）が自分と違う点に注意して、参考にしてください。