はじめに
最近ホットなJevの話をしましょう。
JevはTypeSafe AIが2026年9月15日に提供を始めたAIモデルです。
いわく判断に特化したモデルで、LLMのように文章を生成するモデルではありません。
ただ入力された情報を読んで以下のような判断を行います。
- この条件に当てはまるか
- どのカテゴリに近いか
- どの程度当てはまるか
そして、判断結果を確率として返します。
以下は例です。
「このメールはフィッシングか？」
→ Yes: 0.93 / No: 0.07
「このメールはどのカテゴリか？」
→ legitimate: 0.04
→ spam: 0.11
→ phishing: 0.85
このように、「フィッシングです」と文章で答えるのではなく、各判断や候補に対する確率を返します。
つまりJevは、コードでは書きにくい「意味的な条件分岐」を担当するモデルと考えると分かりやすいです。
公開からまだ1週間ほどですが、文書分類、メール判定、RAG、セキュリティ、LLMルーティング、アノテーションなど、すでに多くの実験が公開されています。
ただ正直どう使うのがベストかは分からないので、先駆者の事例を通してベストプラクティスを探ってみました。
結果として、Jevが得意な問題と苦手な問題にはかなりはっきりした傾向があります。
この記事では公開事例をもとに、Jevが何に強く、何に弱いのか、そして実際にどうタスク設計すればいいのかを整理します。
前提：Jevの概要
運用の話をする前に、軽く基本だけ押さえておきます。
jevとは以下の型のタスクを処理するためのモデルです。
| 質問の型 | 返るもの | 使いどころ |
|---|---|---|
| Noul | Yesの確率（0〜1） | 「この条件は成立するか」 |
| Choice | 候補ごとの確率分布 + confidence | 「候補のどれか」 |
| Score | 順序付きの段階に対する期待値 + confidence | 「どの程度か」 |
Jevでは、判断の対象として渡すデータを State と呼びます。
「このメールはスパムメールか？」という質問なら、そのメールにあたるのがStateです。
1リクエストに複数の質問を入れられ、質問同士は互いの答えを見ずに並列で評価されます。
なので基本形は同じStateに複数の判断を同時に入れて、結果をコードで受け取るというものです。
今から見る事例もこの形に基づいたものが多いです。
公開事例から分かったこと
先に結論をまとめると、Jevが安定する条件は次のようなものです。
- 答えの根拠がStateの中にある
- 何を判定するかが明確
- 選択肢や判定基準が具体的
- Jevには意味判断だけを任せ、最終処理はコードで行う
逆に、ここから外れるほど失敗しやすくなります。
上手くいったパターン1：入力の中に答えがあり、候補が明確
以下の通り、分類や検出ではJevの成功例が多くあります。
事例一覧
| 事例 | 結果 | 規模・条件 | 出典 |
|---|---|---|---|
| IRS税務フォーム分類 | 314/314 | 記入済み314ページ、261候補からChoice | tax-doc-classifier |
| IRS全フォーム分類 | 誤分類0 | 261種753ページ。confidence 0.95未満の38件は自動処理から除外 | 同上 |
| BANKING77 意図分類 | 92.40% | 3,080問い合わせ・77分類 | jev-banking77-experiment |
| AG News | 91% | 4カテゴリ・100件 | jev-benchmarks |
| Banking77/BTZSC | 87% | 72ラベル・100件 | 同上 |
| スパム二値判定 | 98.33% | 18,514通、判定基準を明記 | jev-spam-eval |
| 認証情報の検出 | 99/100 | 認証情報／ハッシュ／プレースホルダなど | jev-secret-detection |
| プロンプトインジェクション検出 | 96.5% | 公開データ662件 | jev-sec-bench |
| Belebele 読解（英語／韓国語） | 97/100、96/100 | 読解してChoice | jev-korean-benchmark |
| MedQA／KorMedMCQA | 89/100、80/100 | 医療の多肢選択 | 同上 |
| ビジネスメール10分類 | 96.4% | 1,565通、独英混在（二次情報） | 検証記事 |
そして中でも分かりやすいのが、IRS税務フォームの分類です。
以下の通り314件で全て正解しています。
| 事例 | 結果 |
|---|---|
| IRS税務フォーム分類 | 314/314 |
まずはこの事例を掘り下げてより良い分類タスクについて学びましょう。
税務フォーム分類
このタスクでやることは単純です。
PDFの1ページを見て、どのIRSフォームなのか判定するだけです。
Stateには以下のような形式で、1ページ分の文字列を入れています。
state = {
"header": "...",
"body": "...",
"footer": "..."
}
そしてこのページを、261種類のIRS様式のどれかに分類します。
ただし候補は様式名だけではありません。
choice("このページはどの様式か", {
"1040", "1099-INT", ... # 様式 約230件
"instructions", "blank", "cover_sheet", "state_tax_form",
"broker_or_bank_statement", "letter_or_other", # ページ種別7つ
"not_in_this_list", # 一覧にない
})
説明ページや白紙、州の様式のような「様式ではないページ」の候補と「この一覧にない」を入れて、様式以外のページが来たときに近い様式へ寄せる逃げ道を塞いでいます。
スケジュールの多い法人向け5様式だけは2段構えで、初段で親様式を当ててから2段目でどのスケジュールかを聞くため、初段の候補は約230に収まっています。
なぜうまくいったのか
理由はシンプルです。
IRSフォームには、フォーム番号やタイトルなど、種類を見分けるための情報がページ内に書かれていました。
そのためJevがやっているのは複雑な推論というより、「このページに書かれている特徴が、どのフォームの定義と一致するか」を照合する処理に近いです。
ちなみに評価には2つのデータセットが使われています。
| 評価データ | 分類対象 | ページ数 | 誤答 | confidence 0.95未満 |
|---|---|---|---|---|
| TaxCalcBench | 記入済み15様式 | 314 | 0 | 0 |
| IRS白紙様式 | 261様式 | 753 | 0 | 38 |
どちらも誤分類は0件でした。
IRS白紙様式では38ページだけconfidenceが0.95を下回りました。
ただこれらはフォーム名が書かれていない、判別材料が少ない、親フォームと区別しにくい、といったページでした。
作者はこの38件を自動処理から外し、既存の手順に落とす設計にしています。
つまりこの事例では、Stateの中に見分けるための情報が十分あるほど、Jevは安定して分類できるという傾向がはっきり出ています。
上手くいったパターン2：Jevには確率だけ返させ、最終判断はコードで行う
Jevの強みは最終的な答えを直接決めさせるだけでなく、判断結果を確率として取り出せることです。
取り出した確率を活用し、既存のルールや機械学習モデルの出力と組み合わせ、最終判断をアプリケーション側のコードで行うことができます。
こうした活用事例は以下の通りです。
事例一覧
| 事例 | 結果 | 構成・条件 | 出典 |
|---|---|---|---|
| スパム／フィッシング／正規 Jev + TF-IDF | 99.30% | Jev 98.64%とTF-IDF回帰98.87%を50/50平均。5,733通 | jev-spam-eval |
| 2026年の未知メール633通 | Jev 97.3% / TF-IDF 72.5% | 古いメールで学習した回帰は崩れ、Jevは保つ | 同上 |
| スパム二値 Jev + TF-IDF | 99.22% | 18,514通。誤り299件→144件 | 同上 |
| RAG再ランキング | nDCG@10 0.692 | 30候補を一括で4段階Score、並べ替えはコード。Cohere Rerank 4 Proは0.691、応答時間は約半分 | jev-rerank-bench |
| Androidレビュー1,000件のアノテーション | 4.6秒 / $0.023 | Gemini 3.8 Flashは18.8秒 / $0.158（二次情報） | ベンチマーク整理 |
そして中でも分かりやすい例が、メールを「正規・スパム・フィッシング」の3種類に分類する実験でした。
メールのスパム・フィッシング判定
この実験では、メール本文や送信者、リンク先などをStateとしてJevに渡し、3カテゴリそれぞれの確率を取得します。
イメージとしては次のような出力です。
メールが「正規・スパム・フィッシング」それぞれである確率を出しています。
legitimate: 0.05
spam: 0.10
phishing: 0.85
ただこのJevの結果をそのまま判断には使いません。
TF-IDFを使った既存の分類器で同じように確率を出し、JevとTF-IDFの確率を50/50で平均しています。
つまり構成はこうです。
TF-IDF ──→ 確率 ─┐
├─→ コードで平均 → 最終判断
Jev ─────→ 確率 ─┘
これは特別な学習を追加したわけではないです。
ただ2つのモデルが出した確率をコードで平均しただけです。
すると結果は次のようになりました。
| 構成 | 正解率 |
|---|---|
| Jev | 98.64% |
| TF-IDF | 98.87% |
| Jev + TF-IDF | 99.30% |
Jevの確率を加えることで99.30%まで改善しています。
ただし、Jevを混ぜれば必ず精度が上がるわけではありません。
別の3,300通のデータセットでは、アンサンブルはTF-IDF単体をわずかに下回りました。
| 構成 | 正解率 |
|---|---|
| Jev | 95.76% |
| TF-IDF | 96.33% |
| Jev + TF-IDF | 96.21% |
では、Jevを組み合わせる意味はどこにあるのでしょうか。
この実験で重要だったのは、JevとTF-IDFでは間違える箇所が違ったことです。
TF-IDFは、学習データに含まれる単語や表現のパターンを使って分類します。
一方Jevは、「実在する組織を装っているか」「認証情報を要求しているか」といった意味的な特徴で判断します。
この違いは、学習時とは異なる新しいメールを与えたときに大きく表れました。
2024〜2025年の新しいフィッシングメールでは以下の結果になりました。
| 構成 | フィッシング再現率 |
|---|---|
| Jev | 94.49% |
| TF-IDF | 75.26% |
| Jev + TF-IDF | 95.66% |
さらに2026年のメール633通ではこうです。
| モデル | 正解率 |
|---|---|
| Jev | 97.3% |
| TF-IDF | 72.5% |
こちらではアンサンブルの結果は報告されていません。
しかし過去のデータで学習したTF-IDFがかなり落ちた一方、Jevは高水準を維持しています。
つまり、この事例で重要なのは「Jevを混ぜれば必ず精度が上がる」という話ではありません。
既存モデルにJevを合わせれば、判断に意味的な軸を持たせられるということです。
普段は既存モデルと同程度でも、データの傾向が変わったときに、片方の弱点をもう片方が補える可能性があります。
Jevに最終判断まで任せる必要はありません。
Jevは意味的な判断を確率として返す部品にして、既存モデル（なんならルールベース分岐でも）との併用や閾値判定など、最終的な処理はコード側に持たせる。
これがこのパターンのポイントです。
上手くいかなかった事例
失敗例も、原因を見ると大きく3種類に分けられます。
一つ一つ見ていきましょう。
アンチパターン1：Stateの中にない答えを予測させる
| 事例 | 結果 | 条件 | 出典 |
|---|---|---|---|
| Upworthy見出しA/Bテスト | 64.5% | 実A/Bテスト10,984件。差が明確な一部に絞ると74.7% | awesome-jev 経由 |
| 金融ニュース → 株価 | 取引に使える予測力なし | jev-alpha-bench | 同上 |
Jevは入力された文章の意味を判断できますが、入力されていない未来の結果まで分かるわけではありません。
Upworthy見出しA/Bテストは以下のような質問をJevに投げていました。
AとB、どちらの見出しのクリック率が高くなる？
こうした問題では、文章Aと文章BはStateにあります。
しかし、実際に大勢の人がどちらをクリックするかという答えはStateにはありません。
株価予測も同じ理由で厳しいです。
「このニュースは企業にとって好材料か？」ならニュース本文から意味判断できます。
でも「このニュースのあと株価は上がるか？」なんて聞かれても分かりません。
つまりJevに未来予測はできません。
ちなみに、公式によるとチェスなどの戦略立案も苦手です。
私の先輩がボドゲなどをやらせてみたようですが、これも弱かったらしいです。
※jevにチェスさせる公式サンプルから引用
This is the wrong tool for this job, on purpose.
Jev’s own guidance puts chess-like planning outside what a fast decision model should be asked to do: positions that need lookahead, a search tree and an evaluation function belong to a dedicated engine, or to a large reasoning model that can think in extended steps. Jev answers in one classification and keeps nothing between calls — no plan, no memory of the last move, no idea what the reply will be. This page wires it up to a real board anyway, so the shape of that limit is something you can watch rather than something you have to take on trust.
改善方法
Jevには入力された情報から判断できることだけを聞くようにします。
上手くいった例に書いた通りですね。
アンチパターン2：判断の単位が大きすぎる、または細かすぎる
Jevへ任せる判断の大きさも重要です。
判断をお願いする部分の切り分けを誤ると以下の事例のような結果になります。
| 事例 | 結果 | 条件 | 出典 |
|---|---|---|---|
| フィッシング直接判定 | 62.6% | 2,000通。再現率43.2%、AUROC 0.689。Claude Haiku 4.5は81.3% | jev-phishing-bench |
| RAG再ランキングの多段化 | 0.692 → 0.668 | 一括Score 0.692 / Noul30本 0.685 / 段階絞り込み 0.674 / 一対比較 0.670 / トーナメント 0.668 | jev-rerank-bench |
判断が大きすぎる例
フィッシング直接判定は判断を任せる領域が大きすぎるアンチパターンに当てはまります。
具体的には「このメールのリンクをクリックして安全か？」と直接聞くようなタスクです。
この正解率は62.6%でした。
このタスクではStateにメール本文や送信者名などの材料はありますが、判断内容＋考慮範囲が大きすぎました。
一見シンプルな質問に見えるかもしれませんが、実際にはかなり複雑です。
なぜなら送信者は信用できるか、URLは怪しくないか、認証情報を要求していないか、添付ファイルは危険そうか、文面に不自然な点はないか、といった多数の判断が含まれているからです。
Jevへ聞くなら、以下のように直接判断できる単位に分けた方が向いています。
送信者アドレスは不自然か？
認証情報を要求しているか？
リンク先は不自然か？
判断を細かく分けすぎた例
逆に、Jevを何段階にも分けて使えば性能が上がるとも限りません。
RAGの再ランキング実験では、同じ30件の候補を並べ替えるタスクに対して、5種類の方法が比較されました。
① 一括Score：0.692
② Noul 30本：0.685
③ 段階絞り込み：0.674
④ 一対比較：0.670
⑤ トーナメント：0.668
※ 数値はランキング性能を表すnDCG@10です。
最も単純な「30候補を一括でScoreする方法」が最高で、判断を細かく分けたり多段化した方式ほど性能が下がりました。
特に段階絞り込みやトーナメントでは、前の段階で候補を誤って落とすと、その候補を後から再検討できません。
判断を細かく分ければ賢くなるわけではなく、各段階の誤りが積み重なる事例もあるという例です。
改善方法
公式のビルドガイド（Build with TypeSafe）に答えがあります。
Ask one narrow, coherent judgment per question. Split independently useful dimensions, without destroying the relationship being judged. A bounded action selection or contextual interpretation is valid; atomic does not mean literal fact extraction or a one-sentence limit.
前半が「大きすぎる」への答えで、1つの質問には1つの狭い判断を求めるようにするという内容です。
後半が「細かすぎる」への答えで、分けていいのは独立させる意味がある部分だけで、判断に必要な文脈を壊さない分け方をするという内容です。
判断の多段化についても同じガイドに基準があります。
A second request is warranted when an earlier answer is needed to fetch evidence, construct new state, or determine the next options.
分割していいのは前の答えを使って証拠を取りに行く、新しいStateを作る、次の選択肢を決める、のどれかに該当するケースのみです。
要は手順としてどうしても前の答えを利用しなければならない時だけ多段化するということです。
再ランキングの多段化はどれにも当てはまらず、同じ30候補を聞き直しているだけなので、下がったのは筋が通っています。
なのでタスク設計手順はまず1リクエストで一番素直な粒度から測り、独立した軸が混ざっているなら分けていいし、前の答えが次の入力に必要なときだけ多段化する、です。
アンチパターン3：Stateや判定基準が不足している
| 事例 | 結果 | 条件 | 出典 |
|---|---|---|---|
| メール3分類（本文のみ） | 93.62% | Reply-To・リンク先・添付情報を足すと97.98% | jev-spam-eval |
| スパム二値（単純な質問） | 95.96% | 基準を明記すると98.33% | 同上 |
| DAIR Emotion 感情分類 | 48% | 6感情・100件。正解に確率0を付けた例が16% | jev-benchmarks |
| PAWS-X 言い換え判定 | 80/100、76/100 | 英語／韓国語。普通の読解は97／96 | jev-korean-benchmark |
| 認証情報の難条件 | 15/20、16/20 | 設定ファイル風の難しい集合。通常は99/100 | jev-secret-detection |
Jevが間違えたとき、「質問文が悪い」と考えたくなります。
しかし実際には、判断に必要な情報をStateへ入れていないだけの場合があります。
メール3分類（本文のみ）が分かりやすい例です。
これは前述のメールのスパム・フィッシング判定を本文だけで行ったものです。
でも本文だけでは本物そっくりの偽業者メールなどを見分けられません。
しかしリンク先やReply-Toを追加すると判定できるようになります。
判定基準が曖昧な場合も失敗する
たとえば「これはスパムか？」だけでは「スパム」の意味が曖昧です。
こうしたあいまいな基準もJevの精度を落とします。
そこで以下のように具体化します。
- 関係のない送信者からの広告か
- 業者により大量送信されたメールか
- 見知らぬ相手からの前払い・宝くじ・遺産詐欺か
それだけでスパム判定は 95.96% → 98.33% まで改善しています。
一方で、そもそも分類対象の境界が曖昧な問題もあります。
DAIR Emotion 感情分類では、joy、sadness、anger、fear、love、surpriseの6択分類で48%でした。
恐怖と悲しみ、怒りと悲しみのように、人間でも一つに決めにくいカテゴリをChoiceで排他的に分類すると不安定になるようです。
改善方法
誤判定を見つけたら、まず以下を確認します。
- 必要な情報はStateに入っているか
- 判定基準は十分具体的か
- 候補同士の境界は明確か
質問文の微調整はその後です。
実運用でのベストプラクティス
ここまでの事例を、実際の設計手順に落とします。
設計1：答えの根拠がStateにある問題だけ渡す
まず、普通のコードで書ける条件はJevへ渡しません。
amount > 10000
status === "active"
daysUntilDue < 3
これはコードで十分です。
一方、以下のような人間なら意味を見れば判断できるが、if文にはしにくい条件はJev向きです。
この請求書は不自然に見えるか？
この文章は攻撃的か？
この検索結果は質問に関連しているか？
判断精度を底上げするため、Jevで意味的な軸を持たせる、という感じです。
よって普通のルールベース分岐や機械学習モデルとの相性はことのほかいいです。
設計2：最終結論ではなく、判断材料を取る
このメールは安全か？
この質問はダメです。
最初から一発で最終結論を聞くのではなく、具体的な確認事項をJevには渡しましょう。
送信者は不自然か？
認証情報を要求しているか？
リンク先は不自然か？
するとJevは意味的な特徴を確率で返してくれます。
必ずStateには判断材料が入るようにして、根拠と答えが一対一で結びつくシンプルな問いを投げればJevはかなり精度が高くやれる印象です。
設計3：選択肢と基準を具体的にする
これはスパムか？
この聞き方だと、「スパム」の意味をJevが決めることになります。
基準を、本文から観測できる形まで書き下します。
送信者と関係がない広告か？
見知らぬ相手からの前払い・宝くじ・遺産詐欺か？
頼んでいないのに購読やリスト登録を知らせてくるか？
質問の形を変えずに基準を明記しただけで、スパム二値判定は 95.96% → 98.33% でした。
逆に感情分類のように、基準を書いても候補同士の境界が重なる問題は、Choice 1本で排他的に分けるのをやめて「怒りが含まれるか」「恐怖が含まれるか」のようにNoulへ分けます。
またChoiceを使う場合は、その他、該当なし、不明……のような、いわゆる例外の逃げ道も必要です。
税務フォーム分類でも「この一覧にない」という候補を用意して、様式以外のページの逃げ道にしていました。
Tips
Tips1：誤判定したら、まずStateを確認する
Jevが間違えたとき、最初に見るべきはプロンプトではありません。
まず、正しく判断するための情報がStateに存在するかを確認します。
メール分類では、質問を変えずにリンク先とReply-Toを追加しただけで 93.62% → 97.98% まで改善しました。
Jevでは質問文だけでなく、State設計が非常に重要です。
Tips2：まず1リクエストの単純構成で試す
同じStateについて複数聞きたいことがある場合、一つのリクエストにまとめていいです。
つまり三つ聞きたいことがあるなら三回Jevを呼び出すのではなく、Stateに質問を三つぶら下げていいということです。
まず単純な構成で基準値を取り、必要な場合だけ多段化します。
まとめ：Jevは「頭脳」より「意味センサー」に近い
公開事例を横断して見ると、Jevが安定しているのは、人間なら文脈を見てすぐ判断できるが、コードのif文には落としにくい問題です。
この一瞬ってところがかなりだいじというか、考え込むようなことはJevにやらせるべきではないです。
たとえば、以下のようなタスクはJev向きです。
これは何の文書か？
このメールは認証情報を要求しているか？
この検索結果は質問に関連しているか？
この文章には怒りが含まれているか？
反対にこっちは向いてません。
この状況で何をするべきか？
株価は上がるか？
どちらの広告が人気になるか？
多段の推論や未来予測が必要な問題ほどJevの想定から外れていきます。
アンチパターン1で引用した通り、公式自身が「先読みや探索木が要る問題は専用エンジンか推論モデルの仕事で、Jevは1回の分類に答えるだけで呼び出しの間に何も保持しない」と言っています。
LLMとは違い、Jevはシステムに組み込む小さな部品です。
アプリケーションの主導権はコード側に置き、コードで表現しづらい意味判断だけJevへ任せる。
現時点の公開事例を見る限り、この使い方が最も再現性があります。
最終チェックリスト
ここまでの内容を振り返ると、実装前に次の8点を確認するといい感じになるかもです。
- 答えの根拠はStateの中にあるか
- Jevへ最終結論ではなく、観測できる判断を聞いているか
- 選択肢と判定基準は具体的か
- 判断に必要な情報をStateへ入れているか
- まず単純な1リクエスト構成で試したか
- confidenceが低い場合の逃げ道を用意したか
- Jevなしの構成と比較したか
- 評価指標が何を意味する数字なのか確認したか
公開からまだ1週間程度なので、これらは最終的な結論ではありません。
ただ、現在公開されている成功例と失敗例を見る限り、「何でも高速に判断するLLM」としてではなく、Stateの中から意味的な特徴を取り出す部品として使うのが、Jevを扱う上で重要なポイントです。
おまけ：その他のJev活用事例
ここまで取り上げた分類・メール判定・RAG以外にも、Jevを「意味判断の小さな部品」として利用する実装がいくつか公開されています。
LLMルーティング
jev-codex-router は、Codexへ届いた各リクエストをJevで判定し、タスクに応じて使用モデルや思考の深さを切り替える実装です。
モデルは安い順にLuna・Sol・Astraの3段階で、難易度に応じてどれを使うかと推論の深さ（5段階）を決めます。
実際の対話237ターンを再生した検証では、すべてを最上位のAstraへ送る場合より、推定コスト約60%削減と報告されています。
ただし作者自身が、この数字は旧ポリシーでの再生であり「実測のCodex利用枠の節約でも、現行ポリシーの根拠でもない」と断っています。
タスク品質が維持されたかも評価されていないため、「品質を落とさず60%削減できた」という結果ではありません。
また別のRouter実験では、Jevを使った構成とJevを外した構成がともに62.4%となっており、ルーティング用途でもJevが必ず効果を出すわけではありません。
Browser Agentの行動選択
jev-ultrafast は、ブラウザ上の操作可能なDOM要素を列挙し、どの要素にどんな操作を行うかをJevに選ばせるBrowser Agentです。
CLICK
TYPE_TEXT
SELECT
SCROLL
WAIT
DONE
Google Flightsの検索デモでは約7.1秒でタスクを完了しました。
同じJevを使った旧実装との6回の比較では両方式とも3/3成功し、中央値が9.45秒 → 7.09秒へ短縮されています。
ただし1タスク・3回ずつの小規模比較なので、一般的なBrowser Agent性能を示すベンチマークではありません。
LLMのコンテキスト圧縮
fast-jev-compaction はClaude Codeのコンテキストにあるツール呼び出しとその結果を1件ずつJevで採点し、現在の作業に不要になったものを削除・短縮するプラグインです（人とモデルの発言は対象外）。
通常のLLMによる要約とは違い、残すと判断した内容は元の文章をそのまま保持するため、ファイルパス、コマンド、エラーログなどが要約によって変形するのを避けられます。
同じ方向性のWinnowでは、Read・Bash・Grepの大きな出力を約25行のブロック単位で判定し、不要な部分をコンテキストから退避させます（必要になれば呼び戻せます）。
作者の例では10,000トークンの出力で、見える範囲が約5,000トークンから約1,800トークンに減っています。
現時点では分類ベンチのような強い精度評価より、エージェントのコンテキストGCとしての実装例と見るのがよさそうです。
Generative UIの部品選択
簡単に言うとAIがUIを作る時、どのUIコンポーネントを使うべきかの判断をしてくれる感じです。
Vercel Labsのjson-renderには、Jevを利用して事前定義されたUIコンポーネントの中から必要なものを選択・配置する実験的な経路があります。
LLMにUIのJSON全体を自由生成させるのではなく、Jevを補助に使う感じです。
利用可能なコンポーネント
↓
Jev
↓
使う部品・配置を選択
↓
コードでUIを構築
第三者による小規模な再現実験では、必要な7/7コンポーネントを正しく選択し、TypeSafe API直結で約2.8秒だったと報告されています。
ただし単一デモの結果であり、Vercel経由の実行までは再現されていません。
コーディングエージェントの判断ツール
JevをMCP経由でClaude CodeやCodexなどから利用する実装も増えています。
たとえばjev-mcpでは、次の処理をJevの型付き判断として提供しています。
- 主張が証拠と一致するか確認する
- コンテキストへ入れる情報を選別する
- 候補を並べ替える
- 項目を分類する
- 修正差分を確認する
- タスクの完了条件を満たしたか判定する
これは精度ベンチではありませんが、LLM自身にもう一度判断させるのではなく、軽量なJevへ部分的な判定を逃がすという利用パターンです。
Semantic Grep・コード検索
Jevを「意味で検索するgrep」のように使う実装もあります。
jev-semgrepでは各行に対してNoulを実行し、
"customer is angry or frustrated"
"network or remote connection failure" -v "a retry is happening"
"(finance AND negative) OR weather"
のような自然言語条件でテキストを抽出できます。条件と対象の言語が違っても動き、英語の条件で日本語の行を拾えます。
実装上は30行を1リクエストにまとめ、最大8リクエストを並列処理します。
精度は作者による10ケースのLLM判定で適合率0.94・再現率0.98と小規模な確認にとどまり、日本語は閾値付近で揺れると作者が注意しています。
それでも、正規表現では表現しづらい条件をJevに担当させる典型例です。
リアルタイム制御・トレーディング
jev-trader は、Monad上のDEXの注文板をStateとしてJevへ渡し、約300msごとのブロックでbuy / sellを判断させる実験です。
この事例が示しているのは収益性ではなく、数百ミリ秒単位の制御ループ内に意味判断モデルを組み込めることです。作者の計測では、ループ全体の中央値が約100ミリ秒、うちモデルの判断が約80ミリ秒でした。
公開実装には発注しない試運転と実注文の両方が用意されていますが、「Jevによって利益が出る」ことを示した検証ではありません。
これらの事例から見えること
用途はかなり違いますが、構造は共通しています。
コードが候補や状態を用意
↓
Jevが意味的に判断
↓
型付きの結果・確率
↓
コードや別モデルが実行
Browser Agentなら「どこをクリックするか」、モデルルーターなら「どのモデルへ送るか」、コンテキスト圧縮なら「何を残すか」、Generative UIなら「どの部品を使うか」。
やはりJev自身に仕事全体を実行させるのではなく、システム内に存在する小さな判断ポイントを担当させるという使い方が共通しています。
エビデンスについて
評価コード・予測結果・再現手順を含む公開GitHubリポジトリを優先しました。
税務フォーム分類とメール3分類は、State・質問文・基準の実物と、比較条件や失敗例まで公開されています。
- 掘り下げた2件: tax-doc-classifier / jev-spam-eval（phish.py、experiments/jev-context）
- 分類・検出: jev-banking77-experiment / jev-benchmarks / jev-secret-detection / jev-sec-bench / jev-phishing-bench
- 読解: jev-korean-benchmark
- 再ランキング／ルーティング: jev-rerank-bench / jev-routing-experiment
- 予測: awesome-jev（jev-headline-bench / jev-alpha-bench）
- アノテーション: jevmodel.ai benchmarks（二次）
- 公式: Introducing System One Models & Jev / docs.typesafe.ai / Build with TypeSafe（公式ビルドガイド）
- おまけの事例: jev-codex-router / jev-ultrafast / fast-jev-compaction / Winnow / json-render（再現実験） / jev-mcp (jkudish) / jev-mcp (blakestone-x) / jev-semgrep / jevgrep / jev-trader