Jev は何ができるのか：8 つのシーンで用途と LLM 連携を解説

日本語ナレーション · 1080p · 字幕トラック付き · MP4

記事：Jev は何に使えるのか。LLM が考え、Jev が LLM を制御する

AIをプログラムに組み込むと、文章を書いてほしいわけではなく、判断だけしてほしい場面がたくさんあります。このレビューは苦情か、この注文は人の審査に回すべきか、エージェントは次にどのツールを呼ぶべきか、といった判断です。大規模言語モデル（LLM）でもこなせますが、毎回1文字ずつ生成するのを待つことになり、遅くて費用もかかります。

Jev は、こうした判断に特化したモデルです。TypeSafe AI が2026年9月に公開し、心理学の「速い思考」になぞらえて「システム1モデル」（System One Model）と呼んでいます。Jev は文章を生成しません。呼び出し側があらかじめ選択肢を示すと、フォワードパス1回ですべての選択肢に較正された確率を付け、構造化された結果を返します。返し方は、選択肢から1つ選ぶ Choice、段階で評価する Score、はい・いいえで答える Noul の3種類です。公式の発表記事によると、応答時間は70〜500ミリ秒、入力は100万tokenあたり0.042ドルで、出力は無料です。いずれもメーカーの自己申告で、第三者による検証はまだありません。

前回の動画ではこの仕組みを解説しました。公開後、コメント欄で一番多かった質問は「で、結局これ何に使えるの？」でした。今回はこの質問に答えます。仕組みの説明は繰り返さず、Jev が向いている場面と、LLM との組み合わせ方に絞ります。先に結論を書いておくと、「LLM が考え、Jev が LLM を制御する」です。なお、ここで紹介する場面は TypeSafe の定義や公開資料をもとに整理した使い方の案で、一つずつ実測したものではありません。

学習できる if/else

TypeSafe は Jev の能力を、分類、ルーティング、スコアリング、抽出、分岐とまとめ、smart if-statements（賢い条件分岐）と呼んでいます。従来の if/else にできるのは、大小比較、テーブル参照、キーワードの一致くらいで、自然言語が相手になるとお手上げでした。Jev はテキストを受け取って構造化された判断結果を返すので、呼び出す側から見れば普通の関数と変わりません。

つまり Jev は「学習できる if/else」だと考えられます。コンテキストを受け取り、判断して、次の処理を決める。長い文章を生成する必要がない限り、そうした処理はすべて Jev の守備範囲です。「このレビューは苦情か」のように、これまで条件式に書けなかった判断を、そのまま if 文に入れられるようになります。

大量のオフラインデータ加工

データエンジニアにとって一番わかりやすいのは、蓄積したデータの一括加工です。たとえば10億件のユーザーレビューに、トピック、感情、購買意図、リスクレベルのラベルを付ける。同じ判断を膨大なデータに配って結果を集める、意味レベルの MapReduce です。TypeSafe も、こうした大規模データの処理を想定用途として挙げています。

これまでは、ルールを書けば取りこぼしが出て、LLM を呼べば遅くて高い、というどちらも中途半端な状態でした。公式の例では、Jev で5000万件のレビューを処理して約20ドル、速度は LLM の40〜200倍とされています。

エージェントの小脳

エージェントとは、ツールを呼び出しながら段階的にタスクをこなすAIプログラムのことです。今のエージェントには、はっきりしたボトルネックがあります。1ステップ進むたびに LLM を呼び出して、次の行動を決めているのです。ところが中身を分解すると、ツールを呼ぶか、どれを呼ぶか、リトライするかといった判断の大半は、深い思考を必要としません。

こうした判断を Jev に任せれば、Jev がエージェントの「小脳」になります。タスクは完了したか、ユーザーに確認すべきか、人間に引き継ぐべきか。数百ミリ秒で結果が出るので、毎回フルの推論を走らせずに済みます。

AIが画面を見ながらパソコンを操作する Computer Use でも同じです。スクリーンショットを受け取り、次はクリックか、スクロールか、入力か、待機かを決める。LLM が操作の計画を立て、数百回に及ぶ細かい操作の一つひとつは Jev が判断します。マウスを1回クリックするたびに大規模モデルで推論するのは、コストが大きすぎます。

RAG のふるい分けと、LLM 出力の審判

RAG（検索拡張生成）は、資料を検索してから、それをもとに LLM に回答させる手法です。検索で返ってくるチャンク（文書の断片）がすべて役に立つとは限らず、多くはノイズです。Jev は、関連度はどうか、回答の根拠を含むか、他の資料と矛盾しないかといった観点で、チャンクごとにスコアを付けられます。資料に紛れ込んだモデルを操る指示、つまり prompt injection の疑いを検知したり、ある記憶を長期保存する価値があるかを判定したりすることもできます。ここでは回答文は必要なく、チャンクごとのスコアがあれば十分です。

もう一つ大きいのが、LLM の出力を審査する役割です。質問に答えているか、脱線していないか、根拠は十分か、フォーマットは規定どおりか、前後で矛盾していないか、生成し直すべきか、2つの案のどちらが良いか。こうした確認のために LLM に長い講評を書かせる必要はありません。Jev が構造化された確率スコアをまとめて返せば済みます。

ただし、はっきりさせておくべき点があります。Jev の型安全性が保証するのは、選択肢の外にある答えを出さないことです。判断そのものが常に正しいという保証ではありません。用意された選択肢の中で、間違ったものを選ぶことはあります。

リスク管理、レコメンド、音声、ゲーム

リスク管理は Jev と相性の良い分野です。不正の確率、決済リスク、スパム、ボットの挙動は、どれも範囲の狭い判断です。第1段階の低コストなフィルタとして使い、確信度の高い正常な取引はそのまま通し、リスクの高いものはルールエンジンや上位のモデルに回します。中間の判断がつかないものだけを人がレビューすれば、人が見るべき件数は大きく減ります。

レコメンドや検索では、ベクトル検索やランキングモデルを置き換えるのではなく、最後の意味判断の層として使います。数十件の候補を並べ替えたり、ユーザーが今どのカテゴリを見たいかを判定したりする処理が、ミリ秒単位で終わります。

リアルタイム音声はさらに条件が厳しく、ユーザーが話し終えたか、割り込むべきかを100〜300ミリ秒以内に判断しなければなりません。ゲームの NPC が攻撃、防御、撤退、救援要請のどれを選ぶかも同じ種類の問題です。LLM がストーリーと会話を、Jev が高頻度の行動選択を受け持ちます。どれも判断の回数が多く、速さが求められる場面です。Jev は入力にだけ課金され出力は無料なので、判断を重ねても出力の分で費用が増えることはありません。

書けないルールをインターフェースにする

個人的には、ここがビジネス上の価値が最も大きいのに、まだあまり語られていない使い方だと考えています。多くのコードには、「金額が1万を超えたら」「送金元の国が合わなければ」審査に回す、といったハードコードされたルールがあります。しかし実際の業務では判断のかなりの部分があいまいで、正確な境界条件を1行のコードで書くことはできません。

Jev があれば、「この注文は異常か」と直接聞き、スコアが0.93を超えたら審査に回す、という書き方ができます。「この顧客は怒っているか」「これは返金の依頼か」「この bug は深刻か」「このメールは営業のチャンスか」「このクレームはすぐエスカレーションすべきか」も、すべて API の呼び出しになります。これまで人の勘に頼っていた業務判断が、コードに組み込めるインターフェースに変わるわけです。なお0.93は例として挙げた値で、実際のしきい値は業務ごとに決める必要があります。

LLM が考え、Jev が LLM を制御する

ここが今回一番大事なところです。ここまでの場面は Jev を単独で使うものが中心でしたが、より大きな価値は LLM との組み合わせにあります。LLM が考えて生成し、Jev が LLM を見張って次に何をさせるかを決めます。

基本のループはこうです。LLM が生成し、Jev が品質は十分か、ハルシネーション（事実でない内容）はないか、やり直すか、上位のモデルに切り替えるかを判断します。判断の部分が安いので、「生成、判断、修正、再判断」のループを何度も回せます。

コーディングエージェントの例も挙げます。Codex が、ファイルを探す、コードを直す、テストを走らせる、バグを直す、コミットする、という5ステップの計画を立てたとします。実行中は毎ステップ強いモデルを呼ぶ必要はありません。今どのステップか、成功したか、エラーはリトライする価値があるか、戻って別の方法を試すか、LLM に介入してもらうかを Jev が判断します。

計算リソースの振り分けにも使えます。簡単な問題は小さいモデルへ、難しい問題は最先端のモデルへ回し、さらに5秒かけて考える価値があるかどうかまで判断できます。ツール呼び出しも同じで、LLM が「調べものが必要」と言えば、Jev が「検索0.93、ファイルシステム0.04」のような確率を返し、プログラムがそのまま該当のツールに振り分けます。動画の画面に出てくるこうした確率は説明用の例で、実測値ではありません。

この分担は体にたとえられます。LLM は計画を立てる大脳、Jev は振り分けを担う小脳、コードは実行を担う脊髄です。1回の深い推論で100回以上の Jev の判断を動かす。これが効率の良いエージェントの形です。

推論1回と判断100回

冒頭の話に戻ります。Jev の最大の価値は、分類を速くすることにとどまりません。高価な LLM を、エージェントのあらゆる判断ノードから解放できることです。LLM は「何をすべきか」に答え、Jev は「やるべきか」「どこまで進んだか」「成功したか」「次は何か」に答え続け、コードが実行する。知性、制御、実行を分けることで、ようやくコストが本当に下がります。

この考え方を進めると、最終的には GPT-6 級の推論1回と Jev の判断100回で、GPT-6 級のエージェント呼び出し30回分を置き換える形になるかもしれません。この比率は私の推測で、測定した結果ではありません。

Jev を使わないほうがよい場面

Jev は自由な文章やコード、会話を生成できず、自然言語で理由を説明することもしません。内容を生成したいときや、「なぜそう判断したか」の説明が必要なときは、引き続き LLM や人の出番です。また、確率の較正や型安全性は判断の正しさを保証するものではなく、公式の速度や価格もメーカーの自己申告です。使う前に自分のデータで確かめる必要があります。

データエンジニアの方は、いま LLM でこなしている狭い判断を一つ選んで、Jev に置き換えてみてください。分類タスクかもしれないし、ルーティングのルールかもしれません。一番小さいところから始めて、自分のユースケースで価値があるかを確かめるのがよいと思います。

公開前に投稿のリスク、誤解されるおそれ、AI臭さを判定する「コンテンツ管理」の使い方は、のちに Jev Tweet Radar になりました。中国語版は 中文ページ。