Jev覚書

作ったのは元 OpenAI の研究者 Diogo Almeida 氏が創業した TypeSafe AI。InstructGPT の論文（第1回・三章の RLHF の出どころ）の共著者です。同氏は Jev を「賢い if 文だと思ってほしい」と説明しています。

LLM に問い合わせの分類をさせると、返ってくるのは文章です。JSON で返せと頼んでも、長さも形もモデル側が決める以上、こちらは毎回それを検証しなければなりません。Jev にはそもそも文字列を出す機能がありません。返り値は、こちらが定義した型に必ず収まります。

LLM は一語ずつ順番に書きます（第1回・一章）。100語書くなら100回まわす。Jev は文章を書かないので、その繰り返しがありません。出力が短いのではなく、出力の仕組みそのものが違うわけです。

出力トークンが無料なのは、請求できるほどの量を出さないからです。返ってくるのは確率がいくつかと確信度だけ。課金の単位が「100万」ではなく「10億」で語られるのも同じ理由です。

「193.6倍速く、444.6倍安い」という数字も出ていますが、これは TypeSafe 自身の評価によるもので、比較対象も同社が選んだものです。速さと安さの桁は信じてよさそうですが、自分のデータで測り直すのが前提だと考えてください。

呼び出しは二つだけ

API に渡すのは state（見てほしいもの）と questions（訊きたいこと）の二つです。

state は「モデルに見てほしいもの」であればなんでも構いません。文字列でも、オブジェクトでも、配列でもよく、JSON のまま渡せます。上の例では件名・本文・プランを入れています。

質問は三種類

どの型にも instructions（何を訊いているか）を書きます。criteria は任意で、選択肢や段階の意味を説明する欄です。SDK 経由だと名前が変わることがあり、たとえば Vercel の AI SDK では Noul が boolean になっています。

返ってくるもの

ここが LLM といちばん違うところです。選ばれなかった選択肢の確率まで返ってくる。そして確信度が別についてくる。つまり「billing だと思うが自信はない」という状態を、こちら側のコードが読み取れます。

確信度が高ければそのまま自動で処理し、低ければ LLM か人間にまわす。しきい値を決めるのは自分のコードで、モデルはその材料を返すだけです。この役割分担が Jev の設計思想そのものだと思います。

まず大前提として、Jev はブラウザを操作しません。動かすのは Playwright などのコードで、Jev は「いまの画面を見て、次にどうするか・合格か」を判定するだけです。

state に入れるもの

ここが質問の核心だと思います。HTML をそのまま渡してはいけません。文脈長は32,000トークンで、実際のページの DOM はすぐにこれを超えます。入れるのは「要約した画面」です。

• goal・expected ── 何を確かめたいのか。これがないと合否の判定ができません
• step・history ── いま何手目で、ここまで何をしたか。同じ操作のループを検知できます
• page ── URL、タイトル、見えているテキスト、警告やトーストの文言
• actions ── 押せる要素の一覧。これがそのまま選択肢になります

questions の組み方

nextAction の選択肢は最大255なので、押せる要素が255を超える画面では、先にコード側で絞り込む必要があります。

スクリーンショットは渡せません（テキストのみ）。見た目そのものを判定させたい場合は、先に画像を読めるモデルに説明させ、その文章を state に入れる、という二段構えになります。

公開から数日で、板情報を約300msごとに判断させる取引ボット、複数の銘柄ごとに独立した建玉を持つ構成、ペーパートレードでの検証などが出ています。香港株の方向予測や、銀行の問い合わせ分類（正答率92.4%）といった、もう少し落ち着いた使い方も報告されています。

実例に共通しているのは、400トークン程度に圧縮した state を渡し、返ってきた確率をコード側のポリシーで扱うという形です。Jev は相場を見にいきません。何を特徴量にするか、どう圧縮するかは、すべてこちらの仕事です。

気をつけるところ

• 較正は「当たる」ことではありません ── 確率が較正されているとは、学習した分布の上で 0.7 と言ったら約7割当たる、という意味です。相場は非定常で、しかも相手がいます。学習時の分布の外側です
• 70〜500ms は AI としては速いだけ ── 時間優先の戦略には遅すぎます
• テキストのみ・32,000トークン ── チャート画像は渡せず、履歴も入れ放題ではありません
• 確率的です ── 同じ入力で必ず同じ答えが返るわけではありません。損失限度や建玉上限のような絶対に守るべき規則は、モデルではなくコードに置く
• ベンチマークは自社評価 ── 速さと安さの主張は、自分の環境で測り直してから判断するのが安全です

Jev は LLM の置き換えではありません。第2回・一章で書いた「何を当てさせたか」の違いが、そのまま守備範囲の違いになっています。

もうひとつ有望なのが、LLM の見張り役としての使い方です。エージェントが道具を呼ぶ直前に、その呼び出しが危険でないかを Jev に判定させて止める。第1回・六章で書いた「信頼性の積算」への現実的な答えのひとつになりそうです。

まず試すなら

すでに LLM で分類だけさせている箇所が、いちばん置き換えやすいはずです。入力も期待する出力も手元にあるので、同じデータで両方を流して突き合わせることができます。速さと安さの主張を、自分の土俵で検算するところから始めるのがよいと思います。