Jevを使ってわかった。「LLMの代わり」ではなく“曖昧なif文”をAIにするためのものだった
2026年9月、TypeSafe AIから「Jev」というかなり変わったAIが公開された。
最初に見たときは、正直よく分からなかった。ChatGPTやClaudeがあるのに、なぜ新しいAIが必要なのか。しかもJevは文章を書かない。長文の回答もしない。コードを書いてくれるわけでもない。画像を直接見て理解するマルチモーダルAIでもない。
では何に使うのか。
実際にJevの使い方を追いながら、どういう処理ならJevに任せる意味があるのかを考えていくと、ようやく腑に落ちた。
JevはLLMの代わりではない。
むしろ、
普通のif文では書けない「曖昧な判断」を、ソフトウェアの中に大量に埋め込むためのAI
と考えるとかなり分かりやすい。
そして、実際に使ううえではもう一つ重要なことがある。
Jevに「答え」を考えさせるより、「判断材料」を大量に判定させる方が強い。
ここまで分かると、ChatGPT、Claude、Codexとはまったく違う役割が見えてくる。
この記事では、自分用の備忘録も兼ねて、Jevをどう理解し、どう使い分ければいいのかを整理しておく。
ChatGPTやClaudeとは根本的に違う
ChatGPTやClaudeなどのLLMは、
入力
↓
推論
↓
文章やコードを生成
という使い方が基本になる。
たとえば、
この問い合わせは解約依頼か、返金依頼か判断してください。
と聞けば、
{
"category": "解約"
}
のような回答を生成できる。
もちろんこれで動く。ただ、よく考えるとこの仕事に「文章生成能力」はほとんど必要ない。欲しいのは、**解約なのか。返金なのか。**という判断だけだ。
ここがJevの領域になる。
Jevではあらかじめ、
解約
返金
技術トラブル
その他
という候補を渡しておき、その中から判断させる。
イメージとしては、
解約 0.91
返金 0.05
技術トラブル 0.02
その他 0.02
のような結果を受け取る。
長い説明文を生成しない。TypeSafeはこうしたモデルを「System One Model」と呼んでいる。
料金もLLMとはかなり違い、現在のJevは入力100万tokenあたり$0.042で、出力tokenには課金されない。
つまり、文章を考えて書くモデルというより、高速な意味判断エンジンに近い。
私の中では「AI版if文」と考えると一気に理解できた
普通のコードなら、
if age >= 65:
high_risk = True
のような条件は簡単に書ける。
でも、
if this_customer_seems_angry:
は難しい。
同じように、
if this_log_is_worth_waking_someone_up_for:
if this_document_actually_supports_the_claim:
if this_tool_result_is_still_relevant:
if this_pull_request_looks_risky:
も普通のif文では書きにくい。
今まではこういう処理までLLMに投げていた。Jevを使うと、この「曖昧なif文」だけを切り出せる。
例えば、
「この問い合わせは返金を求めている？」
→ Jev
「なぜ返金を求めているのか分析し、
適切な返信を書いて」
→ Claude / ChatGPT
という分担になる。
ここがJevを理解するうえで一番重要だった。
Jevには基本的に3種類の判断しかない
Jevを使っていて最初に覚えておけばいいのは、主にこの3つ。
Choice
候補の中から選ぶ。
循環器
呼吸器
消化器
その他
のような分類。
Noul
ある命題が成立する確率を返す。
例えば、
顧客は返金を要求しているか？
に対して、
0.82
のような値が返る。
Score
事前に決めた尺度で評価する。
例えば、
1 = 業務への影響なし
2 = 軽微
3 = 代替手段あり
4 = 主要業務へ影響
5 = 業務停止、代替手段なし
のどこに当てはまるかを判定する。
ここでかなり大事なのが、
「1〜5で評価して」だけでは弱い
ということ。
それぞれの段階が何を意味するかまで書いた方が安定する。これはJevを使うときにかなり意識するようになった。
Jevは「最終回答」を聞くより、判断を分解した方がいい
Jevを使ううえで最も重要だった考え方がこれ。
例えば、
この問い合わせは危険ですか？
と聞く。
一見正しそうだが、「危険」の意味が広すぎる。
そこで、
個人情報を要求しているか？
緊急性を過剰に煽っているか？
URLと表示ドメインが一致しているか？
認証情報を要求しているか？
送信者偽装の兆候があるか？
と分解する。
Jevにはそれぞれを別々に判断させる。
すると、
credential_request 0.94
urgent_language 0.82
domain_mismatch 0.71
sender_spoofing 0.63
のようなfeature vectorが得られる。
最後は普通のコードで、
if credential_request > 0.8 and domain_mismatch > 0.6:
review_required = True
と決めればいい。
公開されているフィッシングメール2,000件の独立検証でも、この違いはかなり大きかった。
Jevに直接、
「これはフィッシングか？」
と判断させた場合のaccuracyは62.6%。
一方、メールを複数の特徴へ分解してJevで評価し、それをロジスティック回帰で統合した構成では95.1%、AUROC 0.988まで改善している。
つまり、
Jevに結論を丸投げするより、結論を構成する小さな観察をさせる。
この方がJevらしい。
AIに全部考えさせる発想とは逆だった
LLMでは、
状況を全部渡す
↓
AIが考える
↓
結論を返す
という使い方をしがち。
Jevはむしろ、
┌ 条件A → 0.92
├ 条件B → 0.14
入力 → Jev ──┼ 条件C → 0.81
├ 条件D → 0.03
└ 条件E → 0.71
↓
普通のコード
↓
判断
という設計がしっくりくる。
AIには意味を読ませる。
処理のルールはこちらで持つ。
Jevに触れてから、この分離をかなり意識するようになった。
実際に使うと「質問の書き方」がかなり重要
ここからが、Jevを単に知っている状態と、実際に使う状態の差だと思う。
Jevは自然言語を理解してくれるが、雑に質問を書けば当然雑な判定になる。
特にいくつか注意点がある。
質問IDには意味を期待しない
例えばコード上で、
id: refund_requested
question: 該当しますか？
としてもダメ。
refund_requestedという便利な名前を付けたからといって、それだけでJevに意図が伝わるわけではない。
質問本文に、
顧客は金銭の返還を要求しているか。料金への不満を述べているだけの場合は該当しない。
くらい具体的に書く。
Choiceなら候補同士の境界も明確にする。
Jevでは、プログラム側で分かりやすい名前を付けることと、モデルに意味を伝えることは別だと考えた方がいい。
stateも「全部貼ればいい」ではない
Jevに大量の情報を渡すときも、
顧客のメッセージ
注文内容
利用規約
過去の対応
を全部一つの文章として貼るより、
{
"customer_message": "...",
"order": {
...
},
"policy": "...",
"previous_actions": [
...
]
}
のように関係を明示した方が扱いやすい。
そして質問も、
customer_messageから、顧客が返金を要求しているか判断する
と対象を明確にする。
これは地味だがかなり重要。ユーザーの希望と会社の規約を同じ文章に混ぜると、誰が何を言っているのかという別の問題までJevに解かせることになる。
Noulの0.8を「80%自信がある」と解釈しない
ここも最初は混同しやすかった。
Noulで、
refund_requested = 0.80
と返ってきた場合、これは、
「返金を要求している」という命題が成立する確率を0.8とモデルが推定した
という意味。
「Jevの判断が80%信頼できる」という意味ではない。
また、ChoiceやScoreには回答分布に基づくconfidenceがあるが、
confidence = 0.9
だから、
実際に90%正解する
という意味でもない。
ここは本番でかなり重要になる。
結局、
0.7以上なら自動処理
のようなthresholdは、Jevの数字だけ見て決めるのではなく、自分のデータでcalibrationする必要がある。
間違ったときの被害が大きい処理ほど、
高確率 → 自動処理
中間 → 人が確認
低確率 → 処理しない
という逃げ道を残した方がいい。
「AIに数字を書かせない」という使い方がかなり良かった
Jevの思想と非常に相性がいいのが、値の抽出。
例えば請求書から請求総額を取りたい。
LLMなら、
この請求書の合計金額を抽出してください
と頼めば、
39,800円
と生成してくれる。
ほとんどの場合は問題ない。ただ、AIが文字列そのものを生成する以上、存在しない数字を作る余地は残る。
Jevを使うなら別の設計にできる。
まず普通のコードで、
3,980円
39,800円
1,200円
という候補を原文から抽出する。
そのうえでJevに、
この中で請求総額に該当するものはどれか？
と選択させる。
最後にコードが、選ばれた値を原文からそのままコピーする。
つまり、
原文
↓
候補をコードで抽出
↓
Jevが意味で選択
↓
原文をコードでコピー
となる。
Jevには文字を書かせない。意味だけ判断させる。
この設計はかなり気に入っている。電話番号、メールアドレス、日付、商品番号などにも応用できる。
引用チェックにもかなり使いやすい
もう一つ面白いのが、文章のfact check。
例えばLLMが、
この研究では死亡率が30%低下した。
と記事を書いたとする。
引用元の文章が存在するかどうかは、普通のコードで確認できる。
でも、
その引用文が本当に「死亡率30%低下」という主張を支持しているか
は文字列検索では分からない。
ここをJevに判断させる。
つまり、
引用文が原文に存在する？
→ コード
引用文はこの主張を支持している？
→ Jev
という分担になる。
これもまさに、確定的な処理はコード、意味的な判断はJevという使い方。
ただし当然、
出典が主張を支持している
ことと、
その出典自体が正しい
ことは別問題。
最新情報の検索もJev自身がやってくれるわけではない。この境界は残る。
Jevは現在「テキストを判断するモデル」
ブラウザ操作やゲームのデモを見ると誤解しやすいので、ここも整理しておきたい。
現在のJevは基本的にテキスト入力を扱うモデル。
画像・音声・動画をそのまま渡して理解させるものではない。
例えばブラウザAgentなら、
画面
↓
DOMやアクセシビリティ情報などへ変換
↓
Jev
↓
CLICK / TYPE / SCROLL
という構造になる。
画像なら、
画像
↓
OCR / Vision model
↓
テキスト・構造化情報
↓
Jev
になる。
なので、
Jevが画面を見ながら高速操作している
というより、
画面から抽出された状態を読み、次の行動を高速に選んでいる
と理解する方が正確。
Browser AgentはJevの思想がかなり分かりやすい
jev-ultrafastというBrowser Agent実装がある。
普通のBrowser Agentでは、画面を見るたびにLLMへ、
今の状況から次に何をすべきか？
と推論させる。
jev-ultrafastでは、
CLICK
TYPE_TEXT
SCROLL
DONE
などをJevに選ばせる。
さらに、
CLICKなら、どのelementか？
もChoiceとして決める。
そして文字入力が必要になった瞬間だけ、別モデルで文字列を生成する。
つまり、
Jev＝行動を決める
生成モデル＝必要な文字を書く
という分業になっている。
公開されているGoogle Flightsのデモでは、同一条件3回ずつの小規模比較ながら、中央値9.45秒から7.09秒へ短縮され、ブラウザプロトコル呼び出しも1,092回から101回へ減っている。
もちろん、これは一つのタスクを数回測っただけで、一般的なBrowser Agent性能を証明するものではない。
それでも、
Jevに高速な小さな判断をループさせるとAgentになる
という発想はかなり面白い。
Coding Agentのcontext整理にも使われている
もう一つ面白かったのがfast-jev-compaction。
Claude CodeのようなCoding Agentを長時間動かすと、
ファイルを読む
grep
テストする
エラー
別のファイルを読む
git diff
またテスト
...
と大量のtool resultが溜まっていく。
普通のcontext compactionでは、この履歴をLLMが要約する。
ただし要約すると、
正確なファイルパス
エラーメッセージ
過去に試した失敗
細かい制約
などが失われる可能性がある。
fast-jev-compactionでは要約しない。
代わりに、過去のtool callについて、
このtool callをまだ残す必要があるか？
このtool result全文をまだ残す必要があるか？
をJevに判定させる。
重要 → 原文を残す
不要 → 削除
一部必要 → 短く残す
という仕組み。
つまり、何を書き直すかではなく、何を捨ててよいかだけJevに判断させる。
これもかなりJevらしい使い方。
ただし、Jevが「不要」と判断した情報が後で必要になる可能性は当然ある。確率は安全性の証明ではない。
LLM Routerは期待したほど単純ではなかった
Jevを見たとき、かなり魅力的に見えたのがLLM Router。
例えば、
簡単
↓
Haiku
普通
↓
Sonnet
難しい
↓
Opus
とJevに振り分けてもらえば、AI代を大幅に下げられそうに見える。
実際、jev-model-routerの公開評価では100ケース中97件が許容範囲に入り、弱すぎるモデルを選んだ例は0。一定の仮定では、すべてOpusへ投げる場合よりモデル化されたコストが26.3%低くなっている。
ただし、ここにも罠がある。
長い会話では、モデルを変更することでprompt cacheが効かなくなり、理論上安いモデルへ切り替えたのに総コストが増えることがある。
さらに別のRouterArena系検証では、Jevのdifficulty signalを追加しても、Jevなしのretrieval evidenceだけでほぼ同じ成績になった。
つまり、
Jevを入れれば自動的にLLM routingが賢くなる
わけではない。
これはJevを使ううえでかなり大事な教訓だった。
日本語は英語と同じように動く前提にしない
個人的に、日本語でJevを使うならここは必ず評価した方がいいと思っている。
TypeSafeは英語を主要言語としている。
日本語も扱えるが、
英語と同じ精度
と最初から仮定する理由はない。
特に、
「返金してください」
なら簡単でも、
「できれば返金していただけると助かります」
のような遠回しな表現や、
「返金は不要ですが原因は教えてください」
のような否定表現は、実運用ではかなり重要。
そこで自分なら、
① 質問もstateも日本語
② 質問は英語、stateは日本語
③ 日本語原文＋英訳
を同じテストセットで比較する。
英語にすれば必ず良くなるとも限らない。翻訳段階でも情報は失われるからだ。
ここは印象ではなく、実データで決めるべきところだと思う。
そして一番悩んだ。「結局、自分でJevを使うのは面倒」
Jevの仕組みを理解すると、「なるほど、これは便利そう」とは思う。
でも個人開発で毎回、
これはChoice？
Noul？
Score？
質問は何個に分ける？
thresholdは？
普通のコードでいい？
LLMの方がいい？
と考えるのは正直かなり面倒。
ここで、
結局ClaudeやCodexに全部頼んだ方が楽では？
となる。
自分もここが一番引っかかった。
そして今は、
Jevを「自分が直接使う」のではなく、Codexの道具にする
という形がかなりしっくりきている。
TypeSafe SkillとMCPは別物
ここは最初、少し分かりにくかった。
TypeSafeはCodexなどのCoding Agent向けに公式Skillを公開している。
Skillを入れると、
Jevには何を任せるべきか
どう質問を設計するか
どこを普通のコードに残すべきか
といった知識をCodex側に持たせられる。
ただし、Skillをインストールしただけで、CodexがJev APIを自由に呼べるようになるわけではない。
Skillは言ってみれば、
Jevの使い方をCodexへ渡す説明書
に近い。
一方MCPでJevを接続すると、
Codex
├ terminal
├ git
├ browser
├ tests
└ Jev
というように、Jev自体をAgentの道具にできる。
コミュニティのjev-codeは、この2つを組み合わせている。
JevをtoolとしてAgentへ渡す
Skillで「いつ使うべきか」も教える
という構成。
これが自分の欲しかった形にかなり近かった。
自分は「Jevを使いこなす」より「Jevを使いこなすAgent」を使いたい
例えばCodexに、
この50件のエラーを整理して原因別にまとめて。
とだけ頼む。
Codexが普通に解けばいいなら普通に処理する。
一方、
50件をsemanticに分類した方が速い
と判断したらJevを使う。
50 errors
↓
Jev
↓
dependency issue 18
test assertion 14
environment 9
unknown 9
↓
Codexが必要なものだけ詳しく調査
という流れ。
自分が毎回、
これはJevを使うべきです
と指定する必要はない。
この方が圧倒的に楽。
ただし、毎回Codexを通すのも違う
ここでもう一段大事になる。
例えば100万件を処理するシステムで、
100万件
↓
毎回Codex
↓
「Jevを使おう」
↓
Jev
としていたら意味がない。
Jevを使うか判断するために、毎回高価なLLMを動かしているからだ。
なので自分の中では、
開発時
自分
↓
Codex
↓
普通のコード / LLM / Jev
と自由に選ばせる。
そして、
この判定では毎回Jevを使っているな
というパターンが見えてきたら、Codexに、
この処理を本番コードへ固定して。
と頼む。
すると本番では、
入力
↓
Jev
↓
コード
↓
必要な場合だけLLM
になる。
つまり、
開発中はLLMにJevの使いどころを探させる。
本番では、その使いどころをコードに固定する。
これが一番合理的だと思っている。
AgentのSkill選択そのものにもJevが使える
ここも面白い。
TypeSafe自身が、
大量にあるAgent Skillの中から、どのSkillを使うべきか
という判断にJevを利用した公開実験を出している。
182種類のSkill、488件の依頼を使った実験では、適切なSkillが存在するケースでの選択ミスが、
16.8% → 7.3%
適切なSkillが存在しないのに無理に使ってしまう率が、
9.8% → 4.0%
まで低下したと報告されている。
もちろんこれは特定のSkill群、Claude Haiku 4.5、特定バージョンのJevを使った実験。
Codexの能力がJevを入れるだけで倍になる
という話ではない。
ただ、
大量の候補
↓
Jevで候補を絞る
↓
LLMが詳しく読む
という構成がAgent内部でも使えることは分かる。
これはかなりJevらしい。
Jevが向いている処理、向いていない処理
ここまで使い方を考えて、自分の中ではかなり単純になった。
まず、
普通のコードで判定できるか？
できるならコード。
age >= 65
合計金額
日付比較
文字列一致
権限チェック
をJevに聞く必要はない。
コードでは難しいが、
候補や評価基準をあらかじめ決められるか？
できるならJev。
この問い合わせの意図は？
このログは重要？
この文書は質問に関連している？
この主張を引用は支持している？
このtool resultをまだ残す必要がある？
そして、
新しい文章やコードを作る必要があるか？
ならLLM。
なぜそう判断したか説明する
返信を書く
コードを書く
論文を要約する
設計を考える
つまり、
① 普通のコードでできる？
↓ YES
CODE
↓ NO
② 選択肢や判断軸を事前に定義できる？
↓ YES
JEV
↓ NO
③ 自由な推論・生成が必要
↓
GPT / Claude
今のところ、これが一番分かりやすい。
Jevを使うときの自分用ルール
最後に、Jevを触るときのルールを備忘録としてまとめておく。
普通のコードで解けることをJevに聞かない。 数字、日付、完全一致、権限などはコード。
「この問題は良い？」と聞かない。 判断を小さい質問へ分ける。
Jevにはできるだけ意味判断だけをさせる。 文章生成や数値のコピーまで任せない。
質問IDではなく質問本文に条件を書く。 モデルが何を判断すべきか明示する。
stateの構造を分ける。 ユーザーの発言、規約、履歴、データを混ぜない。
Scoreの各段階を言語化する。 「1〜5」だけではなく意味を書く。
probabilityやconfidenceを正解率と思わない。 thresholdは自分のデータで決める。
該当なし・保留・人間確認を用意する。 無理に自動化率100%を目指さない。
日本語は自分のデータで評価する。 英語と同じ性能だと仮定しない。
Jevを使うこと自体を目的にしない。 コードやLLMの方が適切ならそちらを使う。
Jevは「安いLLM」ではなかった
最初は、
ChatGPTより高速で安い新しいAI
くらいに見えていた。
今はかなり違うものとして捉えている。
LLMは、
読む
↓
考える
↓
生成する
を一つの大きなモデルでやる。
Jevが面白いのは、その中から、
判断
判断
判断
判断
だけを切り離せること。
これまでソフトウェアは、
if x > 10:
のような明確なルールしか簡単には書けなかった。
Jevが狙っているのは、
if this_looks_suspicious:
if this_is_probably_irrelevant:
if this_needs_human_review:
if this_is_the_best_next_action:
if this_claim_is_supported_by_the_source:
のような、コードでは定義しづらかったif文だと思う。
個人開発者としての今の結論
今の自分は、Jev APIを全部覚えて直接操作することにはあまり興味がない。
理想は、
自分
↓
Codex / Claude Code
↓
┌ 普通のコード
├ テスト
├ LLM
└ Jev
という構造。
JevをSkillとMCPでAgentへ渡しておき、
Jevが向いているところだけAgentに使わせる。
そして有効な使い方が見つかったら、
そのJev利用を本番コードへ固定する。
これなら、自分が毎回Choice、Noul、Scoreのどれを使うべきか考える必要はない。
そして本番環境では、無駄にLLMを経由する必要もない。
Jevはまだ出たばかりで、周辺ツールも急速に変わっている。
性能についても、TypeSafe自身の数字だけではなく独立した検証を見る必要があるし、実際にJevを入れても効果がなかったLLM Routerのような例もすでにある。
だから、
Jevを入れれば何でも速く安く賢くなる
とは思っていない。
ただ、Jevを知ってから自分の中で一つ変わったことがある。
以前なら何かAI化したい処理を見つけたら、
「どのLLMに投げよう？」
と考えていた。
今はその前に、
「これは本当に文章を生成する必要があるのか？」
と考える。
必要なのが単なる意味判断なら、LLMを一回丸ごと呼ぶ必要はないかもしれない。
普通のコードでも書けない。でも、LLMに全部考えさせるほどでもない。
その間に存在していた大量の仕事。
そこを埋めるのがJevなんだと思う。
