Jevの使い方。文章を生成しない判定モデルを、実務のどこに差し込むか
Jevを試してから、やめた作業が3つあります。
プロンプトの末尾に「JSONだけを出力してください」と書き足すこと。出力が崩れたときのリトライ処理を書くこと。そして、単純な分類のために数秒待つこと。
JevはTypeSafe AIが公開したSystem Oneという構造化意思決定モデルです。想定されている読み手は人間ではなくプログラムで、名前は認知心理学のファスト思考とスロー思考の区別から取られています。これまで脆弱なルールか、割に合わないほど高価なLLMに押し付けていた軽量な意味分類を引き受けるために設計されました。
一番の特徴は、テキスト生成をきっぱり捨てていることです。並列サンプリングと、キャリブレーションされた意思決定のための強化学習（RLCD）で訓練されています。文章を作るモデルではなく、決まった選択肢から選ぶモデルだと考えたほうが実際の挙動に近いです。
Jevが返すのは文章ではなく型付きの判定
Choice、Score、Noulという3つの原語
判定の種類は3つの原語に集約されています。
Choiceは集合からの単一選択で、候補は最大255件まで扱えます。カテゴリ分類やルーティング先の決定に使います。
Scoreは順序付きの段階評価で、2段階から10段階まで設定できます。程度や強度を数値で受け取りたいときに使います。
Noulははい・いいえの二値確率を返す原語で、出力は0.0から1.0の確率値です。閾値を決めてそれ以上なら通す、という使い方ができます。
構造はリクエストの時点で決まっている
返り値の形は、リクエストを投げる時点で厳密に定義されます。構造が数学的なレベルで確定しているので、JSONの構文解析エラーや型の幻覚が入り込む余地がありません。
呼び出しの仕組みも単純です。プログラムの状態と型付きの質問を渡すと、確率と信頼度スコアが付いた型付きデータ構造がそのまま返ってきます。単一の順伝播で完結し、自己回帰的にトークンを積み上げる処理はありません。
平均のエンドツーエンド遅延は70ミリ秒から500ミリ秒です。入力は100万トークンあたり約0.042ドルで、判断結果の出力はトークン課金の対象外になっています。
汎用LLMに判定を任せると、どこで崩れるか
出力形式がずれる
汎用LLMは自己回帰で1トークンずつ生成するため、形式が指示から外れることがあります。JSON Schemaで検証をかけても、構文エラーや型の取り違えは残ります。
待ち時間と課金が重い
エンドツーエンドの遅延は3秒から30秒程度になり、リアルタイムの処理経路には載せにくいです。入力も出力もトークンで課金されるため、長いテキストを判定のためだけに流すとコストが膨らみます。
自信ありげに間違える
判断が難しいケースでも、確定した答えを出してしまう傾向があります。自己申告の確信度は振れ幅が大きく、過信しがちです。JevはRLCDで確率分布をキャリブレーションしているので、返ってきた数値を統計的に扱えます。
用途そのものも違います。汎用LLMはテキスト生成、コード生成、多段の複雑な推論、オープンな対話が担当範囲です。Jevが担当するのは状態ルーティング、ツールの振り分け、意図分類、条件フィルタといった判断です。
実務での組み込みパターン
問い合わせの一次振り分けと深刻度の判定
カスタマーサポートのチケットを例にすると、Choiceで担当する業務グループを決め、Scoreで感情的などれくらい苛立っているかを数値化し、Noulで顧客の基幹業務が止まっているかどうかを判定します。この3つを1回のリクエストにまとめれば、200ミリ秒以内に振り分けまで終わります。
RAGの断片フィルタ
検索で拾った上位の断片には、意味が広く取りすぎられて無関係な内容が混ざることがあります。それをそのままLLMに渡すと幻覚を招き、コストも上がります。Noulで、その断片に問いへの回答に必要な事実が含まれているかを判定し、低いものはローカルのコード側で落とします。
エージェントのツール選択
数十個のツール定義を毎回まとめて高価なモデルに渡すと、コンテキストが膨らむうえに選択も外れやすくなります。Jevを手前の門番として置き、ツール一覧からラベルを1つ選ばせます。LLMにはその1つだけを渡して引数を埋めさせる流れにすると、渡す情報量が減ります。
同じリクエストに判定をまとめて載せる
1つの質問を投げる場合と10個同時に投げる場合で、所要時間はほぼ同じです。出力は課金対象外でもあります。後続の処理で必要になる判定は、バラバラに投げず最初から全部まとめて出すほうが合理的です。
信頼度しきい値で自動と人手を分ける
業務のリスクに応じて閾値を変えます。参照系の低リスクなクエリは基礎的な信頼度で自動通過させ、データの書き換えや資産の移動を伴う高リスクな操作には非常に高い信頼度を要求する、という切り分けです。
コミュニティ投稿やリードのスクリーニング
投稿の風評・コンプライアンスの一次スクリーニングは、Noulで違反確率を出して段階的な漏斗にする使い方が向いています。営業のリードなら、Scoreで購買意欲を1から5段階で評価し、Choiceで業界別のソリューションを割り当て、Noulで明確な予算があるかを確認する、といった組み合わせになります。
導入前に把握しておきたい4つの制約
書かれたことしか読まない
プロンプトに書かれていない前提を補ってくれません。書いてある文字の意味に沿って確率を出すだけです。分類が思った通りにならないときは、まず指示の中でカテゴリの定義が互いに排他的になっているかを見直すところから始めます。
数えられない
記号的な算術と実体のカウントはできません。件数を数えたい場合は、業務コード側でループを回して1件ずつNoulに投げ、最後にローカルで合計します。
時間の前後関係が分からない
日付の文字列は普通の文字として扱われます。時差や順序関係は、Stateに渡す前にコードで計算しておく必要があります。
長いテキストで注意力が落ちる
無関係なテキストをStateに積むと判定の正確さが下がります。呼び出す前にテキストを洗っておく工程を挟んだほうが結果が安定します。
汎用LLMとどう役割を分けるか
計算とデータの流れはコード、判断はJev、創作と推論はLLM
ローカルの通常コードは、正確な計算とデータの受け渡しを担当する
Jevは、ミリ秒単位の自然言語の確率判断を担当する
汎用LLMは、深い内容の生成と複雑な推論を担当する
複数のモデルを併用しているなら、モデルの切り替えやキーの管理はAIゲートウェイ側に寄せておき、Jevは判定レイヤーに専念させる、という分け方も取れます。層を混ぜないほうが、あとから差し替えやすくなります。
セットアップでつまずきやすいところ
SDKとランタイムのバージョン
公式のPython SDKとNode.js SDKが用意されていて、同期呼び出しと非同期呼び出しの両方に対応しています。ランタイムはPython 3.10以上、Node.js 20以上が必要です。APIキーはOSの環境変数に入れておくと、公式SDKがTYPESAFE_API_KEYを既定で読みに行きます。
バージョン管理を手でやらない
手元のランタイムを手作業で揃えるのが面倒なときは、ServBayというAI開発環境管理ツールのソフトウェアパッケージパネルから、必要なPythonとNode.jsのインスタンスをワンクリックで入れる方法もあります。環境準備そのものを短くしたい場合の選択肢です。
どんな判定をJevに移すか
向いている判定
すでにシステムの中に、はい・いいえ、何点か、どのカテゴリか、という判断が大量にあるなら、それはJevの守備範囲です。状態ルーティング、ツールの振り分け、意図分類、条件フィルタが該当します。
向いていない判定
文章を作る、コードを書く、多段の複雑な推論をする、開放的な対話をする。これらは汎用LLMの仕事です。数値の計算や時間の推論もJevには向いていません。
すべてを置き換える話ではありません。すでに動いている判断のうち、待ち時間とコストが気になっている一部だけを切り出してJevに渡してみると、返ってくるものの形が変わり、扱いやすさの違いがはっきり分かります。
