Jev は何に使える？

モデルを選ぶ前に、必要な判断を見つける

最初に取り組むのに適したタスクには、範囲の定まった質問、回答するための十分な根拠、明確な次の処理があります。顧客メッセージなら、求められているサービス、関連するアカウント記録、提案する受付キューが該当するでしょう。文書なら、読者の質問、本文、確認すべき箇所が該当します。

ここで紹介するワークフローは、公式例やコミュニティ報告と明記したものを除き、設計上の提案です。当サイトは機能確認のため実際にモデルを呼び出していますが、第三者の事例を独立して再現したり、品質や性能のベンチマークを公開したりはしていません。動作するデモや一回の結果は、その用途の正解率を証明しません。

コミュニティ事例：開発者による Jev の活用

ここでは、開発者が実際に試した具体的な判断タスクについての公開報告を紹介します。各要約に著者の原文へのリンクを付けています。掲載は、TypeSafe や紹介したチームによる当サイトの推奨を意味しません。

公式 Playground で文章チェックを試す

独自に作成した架空の学習用例です。モデルの実行結果は含みません。 文章レビューの用途を参考にした別の演習であり、Every のプロンプトや実験の再現ではありません。Orbit Notes は架空の製品です。コピーしやすいよう、入力と質問は全言語で同じ英語を使っています。

公式 Playground を開く

TypeSafe の外部ページに移動します。自分のアカウントでのログインと必要なアクセス権が求められます。ウェイトリストへの登録だけで利用権が得られるわけではありません。

1. 下の例を state 入力欄に貼り付けます。

2. 下の名前と指示文を使って、Noul の質問を 3 つ追加します。state と質問の入力方法は公式クイックスタートを参照してください。

3. 公式 Playground でリクエストを実行します。返された確率を各質問と照らし合わせて読み、必要に応じて例を編集して再実行します。

架空の入力

Orbit Notes saves your drafts locally.
Your drafts are stored on your device.
Click Export to download a copy.

入力する質問

repetition (Noul)
Does the text repeat a claim without adding new information?

clear_action (Noul)
Does the text explain what happens when the reader clicks Export?

guaranteed_safety (Noul)
Does the text claim that a draft can never be lost?

最初の 2 文が異なる情報を加えているか、Export 操作の結果が説明されているか、草稿が絶対に失われないと約束しているかを確認してください。各質問は独立しており、確率の合計が 1 になる必要はありません。判断を人によるレビューの手掛かりとして使います。この演習には、期待スコアや自動判断のしきい値は用意していません。

4 つの役割と、それぞれの始め方

開発者：意味に基づくルールを確認する

通常の lint では拾えない、範囲を絞った規約を試してみてください。たとえば、変更によって、対処方法の説明がないユーザー向けエラーが追加されていないか、という確認です。関連する差分とルールを渡し、レビューの手がかりを返させます。公式の用途マップには意味に基づくコードの lint が含まれていますが、この具体的なチェックは本サイトの説明用の提案です。

コンパイラ、テストスイート、厳密な lint ルールは維持してください。指摘された行はレビュー担当者が確認し、懸念が妥当か判断します。最初は助言のコメントとして運用し、誤検知の負担を把握してから、マージの必須条件にするかを検討してください。これは連携方法の提案であり、本サイトが利用可能な PR ボットを提供しているわけではありません。

サポートチーム：担当部署と緊急度を分ける

不満の強い顧客に必要なのは、開発担当ではなく請求担当かもしれません。一見落ち着いたメッセージが、緊急の障害を伝えている場合もあります。送付先と時間的な緊急性を別々に質問し、その後でキューの運用ルールを適用してください。以下のチケット例は、公式クイックスタートに掲載されています。

アカウントの事実情報の取得、チケットの重複排除、返金やアカウント変更に関するルールの強制は、引き続きアプリケーションが行います。分類したことは、報告された不具合が実際に起きたことの確認にはなりません。

検索・RAG チーム：文章を書く前に根拠を選ぶ

検索拡張生成（RAG）は、検索した資料を文章生成モデルに渡す手法です。Jev は、検索と生成の間に組み込む候補として評価できます。TypeSafe の RAG 用の文章分類クックブックでは、関連性、利用できる根拠、矛盾、指示を与えようとする内容を別々に確認し、その後、コードで文章を採用、要確認、除外に分けています。

判断とともに出典の識別子を保持してください。矛盾する根拠は、黙って削除するより、警告を表示するほうが適切な場合があります。難しい質問に答えるために必要な唯一の文章を、フィルターが取り除いてしまわないか評価します。最終的な文面を作るのは、引き続き生成モデルです。どちらの段階も、文書へのアクセス権を上書きしてはいけません。

セキュリティチーム：アナリストが確認する順序を決める

TypeSafe のガードレールのクックブックでは、受信メッセージと生成された返信をチェックし、危険性の確率と、順序付きの重大度評価を得る例を示しています。その後、コードが対応方針を適用します。

最初の導入では、既存の検知経路を残し、提案された確認キューをアナリストの判断と比較してください。見逃したインシデントと、不要なエスカレーションは別々に記録します。モデルのスコアが低いことを理由に、ツールへ権限を与えたり、既存の制御を無効にしたり、添付ファイルが無害だと認定したりしてはいけません。悪意ある入力に関する制約も参照してください。

完全な例：文書の中から答えを探す

1. タスクと入力

クックブックにある GitHub 利用規約のテキストを検索します。ID が付けられた 218 行を対象に、jev-1.12 を使用しています。クックブックと完全なスクリプトには、入力全文へのリンクと再生方法の説明があります。

2. 質問

1 回のリクエストで、where（行 ID を選択肢にした Choice）と exists（文書に答えが含まれるかを問う Noul）を質問します。

3. 公開された出力の抜粋

以下は選択した値の抜粋であり、API 応答の全体ではありません。

query: who owns the code I upload?
exists: 0.98
L052: 0.95

一致した原文の行は、L052 | You own Your Content. で始まります。

4. 後処理

クックブックでは、行の確率を並べ替え、ID を元のテキストに対応付けています。答えの存在に関する方針では、値が 0.7 以上なら「答えあり」、0.35 未満なら「答えなし」、その間なら「部分的」とします。そのため、この例は L052 を指し、答えが存在するかのチェックを通過します。

5. 制約と出典

この閾値と以前のモデルバージョンは、この例に属するものです。再生は、新たな測定ではありません。この例が示すのは検索であり、法律上の解釈や他の文書での正確さではありません。元の事例と表示された出力

なぜ 2 つの手がかりを使うのか？

Choice は、与えられた選択肢全体に、合計が 1 になるよう確率を割り当てます。そのため、最上位の選択肢は相対的な勝者であり、適切な選択肢が存在するという独立した保証ではありません。TypeSafe のドキュメントでは、Choice の選択肢は最大 255 個とされています。Choice の意味と制限

実装上の提案は、場所と存在の判断を両方とも結果の記録に残すことです。最上位の行を、無条件の答えに変えないでください。確認できるよう原文を表示し、根拠がない場合や一部しかない場合を明示的に扱い、文書のバージョンも保存します。後の編集によって、ID が指す内容が気付かないうちに変わらないようにするためです。

この設計を応用するときは、確認用のデータに答えのない文書も含めてください。複数行にまたがる答えや、質問の文面に誤った前提が含まれるケースも追加します。そうした例は、最上位の行がもっともらしいかどうかを超えて、実際に必要な検索方針を検証するものです。

完全な例：サポートチケットを振り分ける

入力、質問、文書に記載された出力

サンプルの顧客は、3 日間 Stripe への接続に失敗し、売上を失っており、緊急の支援が必要だと説明しています。リクエストでは、担当部署、不満の強さ、緊急度を質問します。ここではメッセージを要約しています。

出典：クイックスタートのリクエストと応答。

結果を提案に変える

以下は、本サイトが作成した説明用コードです。閾値は説明のために選んだ運用ルールであり、妥当性を検証した設定ではありません。

function proposeRoute(response) {
  const department = response.answers.department;
  const urgency = response.answers.is_urgent.noul;

  return {
    queue: department.confidence >= 0.7
      ? department.choice
      : "manual-triage",
    priority: urgency >= 0.9 ? "urgent" : "normal",
    suggestedTeam: department.choice,
  };
}

公開された値を使うと、この関数は緊急扱いでの手動振り分けを提案し、候補の担当として技術サポートを示します。最上位の部署は、ここで選んだ確信度の閾値を超えていません。この例でチケットが実際に割り当てられることはありません。

確率と確信度は、異なるフィールドです。TypeSafe は Choice と Score の確信度を分布から算出します。Noul には独立した確信度フィールドがありません。確信度のドキュメント

このような提案をチケット管理システムにつなぐ前に、応答を検証し、矛盾の解決方法を定義し、失敗を観測できるようにしてください。誤った振り分けと、緊急チケットの見逃しは別々に評価します。このサンプルは、顧客のアカウント状態を確認するものでも、連携の問題を解決するものでもありません。

コミュニティ報告：フィッシングメールの振り分けを試す

Discord の参加者が、2026 年 9 月 17 日の 14:24–14:27 UTC に、Python SDK を使った初期の実験を紹介しました。セキュリティ運用を支援し、将来 SOAR ワークフローにつなぐことを目指していたものです。投稿では、初期結果に手応えがあったことと、基準の言い回しや詳しさによって結果が変わることが述べられています。実験の紹介、観察の続報

これはコミュニティ参加者本人による報告です。 検知の正確さ、偽陽性率、速度、費用削減、決定論的な動作、本番環境との連携を確認できるものではありません。本サイトでは再現していません。記録したやり取りの中では、確認済みの公式回答は見つかりませんでした。調査対象は選んだ議論であり、コミュニティの全履歴ではありません。リンクを開くには、コミュニティへの参加が必要な場合があります。

次の一歩を 1 つ選ぶ

結果を確認でき、無理なくレビューできる判断を 1 つ選んでください。利用権限の確認とリクエスト送信から始め、料金ガイドで処理全体の予算を立て、出力を自動処理につなぐ前に制約を確認しましょう。