Jevの使い方｜choice・score・noulを6ステップで解説

2026年10月2日

Jevの使い方は、判断したい業務を選び、候補や評価基準を定義し、状態と質問をAPIへ送る流れです。最初から自動化せず、人の判断と比較できる小さな業務で検証します。

使い方を理解するうえで重要なのは、プロンプトを書く前に「正解とは何か」を決めることです。問い合わせを営業、サポート、請求へ分ける場合、境界が曖昧なら人同士でも正解が一致しません。その状態でAIだけを評価しても、改善すべき場所がモデルなのか業務ルールなのか分からなくなります。

最初の検証では、典型例だけでなく、候補が重なる例、情報不足、高リスク、表記ゆれを含めます。誤判定が出たら、候補定義、入力状態、質問文、モデル判断の順に原因を切り分け、一度に一つだけ変更して再評価してください。

業界・職種別「生成AI活用事例集」全11種無料ダウンロード

無料で資料をダウンロード

Jevを使う前に理解する3つの型

型	設計するもの	例
choice	選択肢	営業・サポート・請求
score	順序付き基準	低・中・高・重大
noul	Yesの条件	人の確認が必要か

この3つを使い分けることで、自由文を解析する後処理を減らし、プログラムが扱いやすい結果を得られます。

使い方を6ステップで整理

1. 判断業務を一つ選ぶ

問い合わせの振り分け、レビュー優先度、ツール実行前の確認など、正解を人が判定できるものを選びます。

2. 合格・中止基準を決める

「誤判定率が基準以下」「低確信度は必ず人へ回る」など、検証前に条件を決めます。

3. 出力の型を選ぶ

候補から一つならchoice、段階評価ならscore、Yesの確率ならnoulを使います。

4. 状態を最小限に整える

判断に必要な情報だけを渡します。パスワード、APIキー、無関係な個人情報は含めません。

5. 過去データで比較する

人の正解とJevの結果を並べ、誤り、確信度、処理時間を確認します。

6. 安全な範囲で運用する

低確信度、形式不正、エラー時は自動処理せず、人へ回します。

choiceを使う例

問い合わせの振り分けでは、選択肢を業務上の担当区分と一致させます。

{
  "state": "請求書の金額が契約内容と異なるという問い合わせ",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "最初に対応する担当部署を選ぶ",
      "criteria": ["sales", "support", "billing"]
    }
  }
}

選択結果だけでなく各候補の確率を確認し、上位候補が拮抗している場合は人へ回します。

scoreを使う例

リスク評価では、各段階の意味を具体化します。

段階	業務上の定義
低	通常手順で処理できる
中	担当者の確認が必要
高	管理者の承認が必要
重大	処理を停止する

単に「リスクを評価」と指示せず、判断基準を仕様として残します。

noulを使う例

noulは「人の確認が必要か」のようなYes確率を返す場面に使います。確率が閾値を超えたら確認へ回す設計にできますが、閾値は過去データで検証して決めてください。

自社に合う研修内容を、業務内容から一緒に整理します

無料で相談する

失敗しやすい使い方

選択肢が重複している

「営業相談」と「製品相談」の境界が曖昧だと、結果を評価しにくくなります。候補ごとの定義と具体例を作ります。

状態に情報を詰め込みすぎる

無関係な情報は判断を難しくし、機密情報の送信範囲も広げます。必要な項目だけへ絞ります。

高確信度なら自動実行する

確率は実行権限ではありません。副作用がある操作では、アプリ側の権限検証と人の承認を残します。

運用チェックリスト

判断対象が一つに絞られている
選択肢・評価基準が重複していない
人による正解データがある
低確信度時の処理を決めた
エラー時に安全側へ戻る
入力から機密情報を除いた
結果と人の判断をログで比較できる

最初の検証データセットを作る

Jevの使い方を理解する最短の方法は、正解が分かる小さなデータセットを作ることです。問い合わせ分類なら、通常例だけでなく、候補が重なる例、情報不足、緊急案件を含めます。

データ種別	件数の目安	目的
典型例	30	基本的な一致を確認
境界例	20	候補の重複を見つける
情報不足	10	人へ戻せるか確認
高リスク	10	重大な見逃しを確認
表記ゆれ	10	入力のばらつきを確認

担当者2名で正解が一致しないデータは、モデル評価の前に業務基準を整理します。人同士で判断が分かれる問題を、AIだけで解決しようとしないでください。

失敗結果から改善する順番

誤判定が出たとき、すぐに長いinstructionsへ書き換えるのではなく、原因を4つに分けます。

候補の定義が重複している
stateに必要情報がない
質問文が業務基準と一致していない
モデルが基準どおり判断できていない

最初の3つは設計側の問題です。候補の統合、必要項目の追加、質問文の修正を一度に行わず、一つずつ変えて再評価します。

検証結果の記録表

ID	人の正解	Jev結果	確信度	原因	対応
001	billing	billing	高	なし	採用
002	support	sales	中	候補定義が重複	定義修正
003	要確認	billing	低	情報不足	人へ戻す

この記録を残すことで、モデル更新や質問変更の前後を比較できます。

よくある質問

プログラミングなしで使えますか？

JevはAPIを通じて業務システムへ組み込む用途が中心です。検証用UIが提供される場合でも、本番運用には実装と監視が必要です。

どの型から試すべきですか？

選択肢が明確なchoiceから始めると、正解と比較しやすくなります。

何件テストすればよいですか？

まず50〜100件で誤りの種類を確認し、重要業務では条件を変えず追加検証します。

MoMoなら業務判断から逆算したAI活用を実現できます

AIの使い方はモデル操作だけでは決まりません。判断基準、例外処理、人の承認、評価指標を業務フローへ落とす必要があります。株式会社MoMoでは、検証設計から運用ルールまで支援します。

1. 向いている企業・向いていない企業

反復する判断を整理し、改善データを残せる企業に向いています。例外が多く担当者ごとに基準が違う場合は、先に基準をそろえます。

2. 活用例

架空の問い合わせデータでchoiceを実行し、人の正解との一致、低確信度率、担当者へ回す条件を検証します。

業界・職種別の活用事例11種を無料で配布しています