Jev のユースケース：System One モデルが下せる 12 の判断

Jev が下すのは、取りうる答えを事前に列挙できる判断です。たとえば、チケットをどのチームが担当するか、ツール呼び出しがユーザーの依頼と一致しているか、回答が出典に基づいているか、といった判断です。 返信や要約、理由の説明を書くことは決してありません。以下の各ユースケースはそうした判断の 1 つで、型付きの質問（Choice、Score、Noul）のセットとして書かれており、それぞれのツールページで自分のテキストに対して実行できます。

ここでの例はどれも、短い state に対して 2〜4 個の質問を使います。そのため JevStation では、state が 8,000 文字未満で、呼び出しの質問が 5 個以下である限り、どれも 1 クレジットの標準評価になります。質問は同じ state に対して並列に回答されるので、3 つ目や 4 つ目の質問を加えてもレイテンシはほとんど増えません。

すべてのユースケースはこの 3 つの形から組み立てられているので、簡単におさらいしておきます。

サポートと運用

1. サポートチケットのトリアージ

Choice が担当チーム（billing、integrations、bug、account）を選び、5 段階の Score が「Can wait」から「Critical」まで緊急度を評価し、Noul が顧客が解約しそうな確率を返します。役に立つ出力は、多くの場合その分かれ方です。Stripe に触れているものの実際にはサービスの接続に関するチケットは、確率が 2 つのチームに分かれて現れ、信頼度が低ければ自動割り当てすべきではないとわかります。大規模なメールのトリアージは、LangChain が Jev についての記事で挙げている構築例の 1 つです。サポートチケットのトリアージ

2. レビューの感情分析

Choice が全体的な感情（positive、mixed、negative）を読み取り、Score がレビューを暗黙の星評価に対応付け、Noul がレビュー投稿者が返金を望んでいるかを尋ねます。実際にアクションのきっかけになるのはたいてい返金の Noul で、残りの 2 つはダッシュボードに使われます。ここでは注意が必要です。最も近い独立したデータポイントである jev-benchmarks の感情（emotion）分類データセットは、Jev の成績が最も悪かったものです（精度 0.48、キャリブレーションも不十分）。感情分析（sentiment）と感情分類（emotion）は別物ですが、信頼する前に計測してください。レビューの感情分析

安全性とモデレーション

3. コンテンツモデレーション

3 択の Choice が allow、review、remove を決め、ルールごとに 1 つの Noul（ハラスメント、プラットフォーム外へのスパム）がコメントの問題点を示します。review という選択肢は意図的なものです。不確かな中間層に、無理やりのイエスかノー以外の行き先を与えるためで、その中間層こそ人間のモデレーターに回すべきものです。「リンクが 3 つ以上」のような数え上げはコードに残します。TypeSafe が、Jev は数え上げを確実には行えないと明記しているからです。コンテンツモデレーション

4. プロンプトインジェクションの検出

2 つの Noul が 2 種類の害を区別します。アシスタントの指示を上書きまたは抽出しようとする試みと、外部の宛先にデータを送らせようとする依頼です。Choice がその両方を、入力が LLM に届く前に pass、sanitize、block のいずれかに変えます。Jev には乗っ取られる指示チャネルがありませんが、TypeSafe 自身の jaggedness に関する注記 は、敵対的なコンテンツでも答えが動きうると述べています。そのため、セキュリティ境界ではなく防御層の 1 つとして扱ってください。プロンプトインジェクション検出

5. ツール呼び出しのガード

state にはユーザーの依頼と、エージェントが提案するツール呼び出しが入ります。Noul がその呼び出しがユーザーの依頼と一致しているかを尋ね、Score がリスクを「Harmless」から「Destructive」まで評価し、Choice が execute、confirm、block を決めます。例として挙げているのは、ステージングのデータの整理を頼まれたエージェントが、本番環境で DELETE FROM orders; を提案するケースです。LangChain の実験的な AutoModeMiddleware は同じ考え方をあらゆるエージェントに適用しており、Vercel のエンジニアは TechCrunch に対し、コマンドの安全性をレビューしていた LLM 分類器を Jev に置き換え、5 倍から 18 倍速い結果を得たと語っています。ツール呼び出しのガード

営業と採用

6. リードの評価

Score が B2B プロダクトに対するインバウンドリードの適合度を評価し、Choice が購買段階（researching、evaluating、ready to buy）に位置づけ、Noul が具体的なスケジュールに触れているかを尋ねます。誰に当日中に返信するかを決めるにはこれで十分です。ビジネスメールの分類について唯一公開されている実務者の報告は、TechCrunch 経由の Bryo AI の CTO によるもので、Gemini のほうがわずかに精度が高いものの、コストは 10 倍から 20 倍だったというものでした。この CTO が最も関心を持ったのは、Jev が本物の確率を返すという点でした。リードの評価

7. 履歴書のスクリーニング

Score が候補者と職務の適合度を評価し、Noul が求めるシニアリティを満たしているかを尋ね、Choice が reject、phone screen、onsite のいずれかを提案します。採用は TypeSafe 自身の ユースケースマップ にも載っています。これは、理由が書かれないことが最も問題になるユースケースでもあります。36Kr の分析は、説明のない判断は規制のある分野ではコンプライアンスの壁にぶつかることが多いと論じています。人のためにキューを並べ替える用途に使い、単独で人を不採用にする用途には使わないでください。履歴書のスクリーニング

エージェントと RAG

8. LLM の回答の審査

Noul が回答が参照事実と矛盾しないかを確認し、Score が全体的な品質を評価し、Choice が ship、revise、reject を決めます。これは独立した根拠が最も強いユースケースです。ある AI コントロールのパイロットでは、単一の Noul がバックドア入りのコードを正直なコードより上位に、AUROC 0.976 で順位付けしました。同じパイロットでは明確な失敗パターンも見つかっており、その詳細は Jev as a Judge で解説しています。Jev as a judge

9. RAG の評価

2 つの Noul が、回答中のすべての主張が検索されたコンテキストに裏付けられているか、そしてそもそもコンテキストに質問に必要な情報が含まれていたかを尋ねます。Score が回答を評価し、Choice が誤った回答の失敗箇所を示します。retrieval（コンテキストに情報がなかった）か generation（コンテキストには情報があったのに回答が誤って述べた）かです。この最後の質問こそが評価を修正につなげます。2 つの失敗は担当者が異なるからです。RAG の評価

10. 引用のチェック

state には出典の一節と主張が入ります。Choice が supported、partially supported、unsupported を決め、Noul が主張が出典を誇張しているかを尋ねます。例では、調査では 38% とされているのに、主張は「most IT leaders（IT リーダーの大半）」が支出を増やす予定だったとしています。これは見つける価値のある、目立たない誇張の典型です。beam.ai が提案するように、このパターンは LLM と組み合わせるとうまく機能します。LLM に抽出させ、抽出した値とその出典を Jev に渡して検証させるのです。38% が「大半」に当たるかの判断は数値に依存しており、TypeSafe はそれを弱点として挙げているため、このような例はテストしてください。引用のチェック

11. LLM ルーター

Score がプロンプトの難しさを評価し、Choice が小・中・フロンティアのどのモデル階層を使うかを選び、Noul が回答にコードが必要かを尋ねます。独立した Classmethod のテスト では、40 回の呼び出しすべてで期待どおりの階層が得られました。階層ごとのプロンプトは 1 つずつで、著者はこれが精度のベンチマークではないとはっきり述べています。Jev が階層を選び、リクエストを送るのはあなたのコードです。LLM ルーター

12. コンテキストの圧縮

Noul がトランスクリプトの一区間に、エージェントが覚えておくべき決定や制約が含まれているかを尋ね、Score がそれを残す重要度を評価します。圧縮は要約する代わりに、スコアの低い部分を削除し、残りを一字一句そのまま保持します。fast-jev-compaction は実際の例で、ツール呼び出しごとにイエス/ノーの質問を 2 つ行い、削減量が小さいときは組み込みの要約にフォールバックする Claude Code プラグインです。コンテキストの圧縮

Jev が適したツールではない場合

上の 12 の判断には共通の形があります。問題がその形を持たないなら、別のツールのほうが適しています。

• テキストが必要な場合。 返信、要約、批評、文章による理由の説明には生成モデルが必要です。TypeSafe の注記は、Jev にテキストを生成させようとしても「うまく機能しない」と述べています。
• 答えを列挙できない場合。 自由回答の質問には、立てるべき Choice がありません。
• 判断が数え上げ、算術、日付である場合。 「今週のチケットが 3 件」や「更新日を過ぎている」はコードで扱い、その結果を state に渡してください。
• ルールが厳密な場合。 ブロック対象のドメイン、キーワードリスト、サイズの上限は分類ではなくコードの仕事です。
• 入力の大半が英語ではない場合。 TypeSafe によると、CJK の文字体系を含む他の言語も扱えますが、英語ほどの精度ではありません。
• 判断される側がスコアを探れる場合。 AI コントロールのパイロットでは、提出前にスコアを確認できる攻撃者は、バックドアの 10 分の 1 ではなく約 3 分の 1 を通過させました。
• ラベルのセットが安定していて、ラベル付きデータが大量にある場合。 大量処理では、自分で学習させた分類器のほうが簡単で安上がりな選択になることがあります。そのトレードオフは Jev Alternatives で解説しています。

最初のユースケースの選び方

beam.ai がうまく表現しているテストのとおり、次の 3 つがすでに当てはまるところから始めてください。取りうる答えの集合がわかっていること、同じ判断を何度も行うこと、そして信頼度スコアに基づいて行動できることです。実際には、チケット、コメント、リードなど、すでに人が手作業で仕分けているキューがそれに当たります。過去の判断がそのままラベル付きデータになるからです。

1. 自分のキューに最も近いツールページを開き、例を実行します。
2. プレイグラウンド で、state を正解がわかっている実際の入力 20 件に置き換えます。行数がもっと多い場合は、バッチページ で 1 つの質問セットを CSV のすべての行に対して実行できます。
3. 選択肢を自分の言葉で書き直し、それぞれに 1 行の説明を付けます。
4. 信頼度が正解と不正解をどこで分けているかを確認し、act、review、reject の 3 つの帯を設定します。

最初の 200 回の評価は無料で、このテストを何度も繰り返せる量です。3 つの条件がなぜ重要なのかは System One モデルとは何か で、質問の書き方は Jev が答えられる質問の設計 で解説しています。12 のページをまとめて見るには、ツール から始めてください。

出典

• 質問セットと例の state。上記でリンクしている 12 の JevStation ツールページ （当サイトの設定）
• クレジットの段階と無料付与。料金 （JevStation）
• 大規模なメールのトリアージ、AutoModeMiddleware。LangChain （第三者）
• Vercel のコマンド安全性レビュー、Bryo AI のメール分類。TechCrunch via Yahoo （第三者、データ未公開の実務者の報告）
• ユースケースとしての採用とモデルルーティング。TypeSafe の ユースケースマップ （ベンダー）
• 数え上げ、日付、敵対的コンテンツ、生成。Jev 1.13 jaggedness （ベンダー）
• 言語サポート。TypeSafe のモデルドキュメント （ベンダー）
• 3 条件のヒューリスティック、抽出してから検証するパターン。beam.ai （第三者）
• 感情分類の結果。jev-benchmarks （独立）
• バックドア監視のパイロット、スコアを探る攻撃者。LessWrong （独立）
• ルーティングのテスト。DevelopersIO (Classmethod) （独立）
• コンプライアンスへの懸念。36Kr （第三者）