Jevでメールと問い合わせチケットを振り分ける：分類デモから実運用ワークフローまで

500通のメールを短時間でいくつかのカテゴリに分けるというのは、Jevの使い方を理解しやすいデモです。

コミュニティ事例の作者は、Jevなら500通のメールを数秒で一括分類でき、費用は約0.035米ドルだったと報告しています。ただし、そのデモではメールの構成、カテゴリ定義、人手による正解ラベル、精度、混同行列が公開されていません。そのため、これは呼び出し方の一例として見るべきであり、本番環境のカスタマーサポート振り分けをすでに置き換えられる証明とは言えません。

実際のメール・チケットシステムで難しいのは、「このメールをどの部門に送るか」だけではありません。

1件のチケットに、二重請求、返金要求、チャージバックの予告、何度連絡しても解決されないという苦情が同時に含まれることがあります。billing キューに分類すること自体は正しくても、最優先で扱うべきリスクシグナルを見落とす可能性があります。

Jevに適しているのは、「1回の分類でサポート業務全体を解決する」役割ではなく、ワークフローの判断レイヤーになることです。1通のメールを境界の明確な複数の質問に分解し、その構造化された結果を業務コードに渡して、組み合わせ、振り分け、実行を行います。

メールまたはサポートチケット
   ↓
前処理：件名、本文、必要な過去の文脈を抽出
   ↓
Jev：キュー選択、返金検知、リスク検知、緊急度スコアリング
   ↓
業務ルール：確率、しきい値、顧客情報、社内ポリシーを組み合わせる
   ↓
自動振り分け / 人手レビュー / 高リスクのエスカレーション / 返信案の生成

最も重要な役割分担は、Jevが意味判断を行い、コードが制御フローを握り、サポート担当者または生成モデルが最終返信を作ることです。

Jevがこの判断レイヤーに向いている理由

Jevは長文生成を目的としたチャットモデルではありません。state を受け取り、開発者があらかじめ定義した typed questions に回答します。主な形式は3つです。

種類	向いている質問	返される結果
Choice	このチケットを送るのに最も適したキューはどれか？	1つの選択肢、各選択肢の確率、confidence
Noul	ユーザーは明確に返金を求めているか？	0から1までの「はい」の確率
Score	このチケットの緊急度はどの段階か？	スコア、各段階の確率、confidence

1回のリクエスト内で複数の質問を並列評価できます。モデルにチケットを読ませて分析文を書かせ、その文章をプログラムで解析するよりも、いくつかの原子的な質問を直接投げ、後続コードでそのまま使える結果を受け取る方が明快です。

ただし、型付きの返答が保証するのは、結果が事前定義されたインターフェースに従うことだけです。業務判断が正しいことまでは保証しません。しきい値、フォールバック、人手レビュー、オフライン評価は依然として必要です。

1件のチケットを1つの質問だけで処理しない

たとえば、ユーザーから次のメールが届いたとします。

Proプランにアップグレードした後、料金を二重に請求されました。3日前にも連絡しましたが、まだ誰も解決してくれていません。今日中に返金してください。対応されなければ、銀行にチャージバックを申請します。

「このメールはどの部門に属するか」だけを聞けば、答えはおそらく billing です。しかし、本番システムでは少なくとも次の4点も把握する必要があります。

判断	質問タイプ	推奨する選択肢または基準	用途
どの主キューに入れるか	Choice	billing / shipping / technical / account / sales / legal / none	初期振り分け
返金要求があるか	Noul	返金、請求取消、支払額の返還を明示的に求めていれば「はい」	返金フローの開始
チャージバック、規制当局、法的リスクがあるか	Noul	chargeback、銀行への苦情、規制当局、法的措置への言及	高リスクのエスカレーション
緊急度	Score	期限のない一般的な問い合わせ / 利用に支障が出ている、または繰り返し連絡している / 金銭的損失、チャージバック、明確な期限がある	キュー内の優先順位
人手対応が必要か	Noul	金銭、法的問題、繰り返し未解決の苦情、またはモデル判断が不確実	自動処理を許可するかの判断

これらの質問は関連していますが、「このチケットを総合的にどう処理すべきか判断してください」という1つの質問にまとめるべきではありません。

Jevの公式な設計指針は、複雑なタスクを原子的な判断に分解することです。質問を分ければ、業務コードは、どのキューに送るか、優先度を上げるか、自動返信を止めるか、当番担当者に通知するかを個別に決められます。

Choice には none、other、unclear のような選択肢も残すべきです。正解が選択肢に含まれていなければ、モデルは新しいキューを作れず、既存の中で最も近いものを無理に選ぶしかありません。

モデル出力と業務アクションの間にはルール層が必要

以下の制御フローの疑似コードは、Jevと業務システムの責任分担を示すものです。公式SDKのリクエストをそのまま写したものではありません。

const decision = await evaluateTicket(ticket, ticketQuestions)

if (decision.transportFailed) {
  return moveToQueue("manual_triage", {
    reason: "decision_service_unavailable"
  })
}

if (
  decision.chargebackRisk >= T_CHARGEBACK ||
  decision.legalRisk >= T_LEGAL
) {
  return moveToQueue("risk_escalation", {
    priority: "highest",
    requireHuman: true
  })
}

if (
  decision.teamTopProbability < T_ROUTE ||
  decision.teamProbabilityMargin < T_MARGIN
) {
  return moveToQueue("manual_triage", {
    reason: "uncertain_route"
  })
}

moveToQueue(decision.team)

if (decision.refundIntent >= T_REFUND) {
  attachWorkflow("refund_review")
}

if (decision.urgency >= T_URGENCY_HIGH) {
  raisePriority()
}

T_ROUTE や T_REFUND はJevに組み込まれた共通定数ではなく、業務ポリシーです。自社のチケットデータで調整する必要があり、リスク水準、言語、モデルバージョン、キュー定義によって変わります。

低リスクの一般問い合わせなら、自動振り分けに比較的緩いしきい値を使えるでしょう。一方、返金、チャージバック、アカウント停止、法的苦情には、より厳しいしきい値を設定し、人手レビューを残すべきです。

バッチ呼び出しは振り分けに向くが、高リスクのゲートは慎重に扱う

Jevの公式インターフェース仕様として、1回のリクエスト内で複数の質問に並列回答できます。「1通につき1回、さらに1問につき1回」のように呼び出すより、必要な判断をできるだけ少ないリクエストにまとめる方が、ネットワーク往復を減らし、スループットを管理しやすくなります。

ただし、複数のチケットを1回の呼び出しにまとめてグループ化した場合に、個別呼び出しと結果が一致すると想定すべきではありません。自社のデータを用いて、バッチ呼び出しと単独呼び出し（single-item）の挙動をベンチマークして比較検証する必要があります。

Noul の確率などの出力についても両者が等価であると仮定せず、事前に自社データで検証を行うべきです。その上で、返金や法的措置に関わる高リスクなチケットや、確率が不確実な範囲に入るチケットは、個別に分けて扱う設計が求められます。

より慎重な2段階設計は次のようになります。

1. 第1段階では、主キュー、トピック、明らかなスパムかどうかといった低リスク判断をバッチで行う。
2. 返金、チャージバック、法的リスクに関係するもの、または確率が不確実な範囲に入るチケットは、単独で再確認するか、そのまま人手キューに送る。

これはモデルに何度も投票させるためではなく、高リスクのアクションに、より明確な文脈と厳格な処理経路を与えるためです。

confidenceを「正解率」と見なさない

Choice と Score は confidence を返しますが、これは確率分布がどれだけ集中しているかを示す値です。「この答えが正しい確率」と直接解釈することはできません。

confidence は読者の業務における正解の確率として直接検証された値ではないため、自社データでの検証とキャリブレーションが欠かせません。したがって、次のようなルールは安全ではありません。

confidence = 1.0 → 自動実行

実際のシステムでは、複数の信号を同時に見るべきです。

• 最上位選択肢の probability
• 1位と2位の probability の差
• 対象となる業務リスクに対応した独立の Noul
• チケットが学習・検証データでカバーされていない新しい分布に属するか
• モデルバージョンや質問文が変更されていないか

「どのキューに入れるか」と「自動処理してよいか」も、1つの Choice だけで解決しない方がよいでしょう。前者は Choice で選び、後者は別の Noul で自動処理条件を満たすか判定します。

質問文はコードと同じように管理する

Jevのワークフローでは、質問文は単なるプロンプト文面ではなく、業務ロジックの一部です。

instructions と criteria の間に意味の矛盾がないかをレビューすることが不可欠です。定義同士に矛盾があると、モデルは例外を出さずに、構造上は正常でも意図と異なる結果を返してしまうリスクがあります。

そのため、メール振り分けプロジェクトでは、少なくとも次のように質問定義を管理する必要があります。

管理項目	具体的な方法
バージョン管理	質問文、選択肢、基準を変更するたびに新しいバージョンを作る
コードレビュー	質問定義と振り分けルールを管理画面のテキスト欄に散在させず、リポジトリでreviewする
テスト例	各質問について、正例、負例、境界例、複数意図を含むチケットを保存する
矛盾チェック	instruction と true/false criteria が同じ意味方向を向いているか確認する
モデルバージョンの固定	しきい値を調整した後は、変動する latest alias に直接依存せず、特定バージョンを固定する

特に Score の各段階は、「低・中・高」だけでなく、観察可能な業務状況を記述するべきです。「ユーザーが価格を尋ねているだけ」「ユーザーが何度も連絡しており、サービスも利用できない」といった表現の方が、「中程度の緊急度」より安定して判断しやすくなります。

ネットワーク障害時の動作をあらかじめ決めておく

分類モデルから応答が返らなかったからといって、「リスクなし」や「デフォルトで許可」と解釈してはいけません。

高並列リクエストやネットワークの揺らぎによって、通信失敗や遅延の増大が発生することがあります。本番システムが理想経路だけを実装してはいけないことは明らかです。

少なくとも次の4つの保護が必要です。

1. リトライとバックオフ：一時的なネットワークエラーでチケットを失わないよう、リトライと retry-after に対応したSDKを優先する。
2. 明示的なフォールバック動作：判断サービスが使えない場合、人手トリアージに送るのか、処理を延期するのか、決定論的なルールだけを実行するのかを事前に決める。
3. 冪等性と重複排除：メール再配信、キュー再試行、タイムアウト後の再送で重複チケットを作らない。
4. 完全なログ：モデルバージョン、質問バージョン、probabilities、呼び出し時間、使用量、人手による最終結果を記録する。

金銭、アカウント、法務に関わるチケットでは、最も安全な既定のフォールバックは「自動承認」ではなく、「自動処理を停止して人に渡す」ことです。

多言語キューで同じScoreしきい値を共用しない

多言語でチケットを処理する際、ある言語向けに調整した Score や confidence のしきい値が、他の言語にもそのまま適用できる（transferable）と想定すべきではありません。しきい値の移行可能性を前提とせず、言語ごとに個別に検証を行う必要があります。

したがって、多言語サポートシステムでは最低限、次の対応が必要です。

• 言語ごとに別の検証データセットを作る
• 緊急度と人手エスカレーションのしきい値を言語別に調整する
• 英語データで設定したスコア範囲を、中国語や他言語へそのままコピーしない
• 翻訳文、原文、過去の会話履歴をどう使うかについて、一貫した方針を適用する

公開前に何を評価すべきか

メール振り分けシステムは、全体精度だけでは評価できません。誤りの種類によってコストが大きく異なるからです。営業前の問い合わせをサポートキューへ送っても、引き継ぎが1回増えるだけかもしれません。一方、チャージバック予告や法的苦情を見落とせば、直接的な金銭・コンプライアンスリスクにつながります。

少なくとも次の指標を分けて確認するべきです。

指標	答えるべき問い
主キュー精度	チケットは最初に正しい処理キューへ届いたか？
高リスク再現率	チャージバック、法務、規制、アカウントセキュリティのチケットをどれだけ見落としたか？
自動振り分けカバレッジ	人手による最初の仕分けが不要だったチケットはどの程度か？
誤自動処理率	本来は人手が必要だったチケットを、どれだけ自動で通してしまったか？
人手レビュー率	しきい値が慎重すぎて、人手キューの意味が失われていないか？
遅延と失敗率	実際の並列数、メール長、ネットワーク条件で安定しているか？
1件あたり総コスト	判断、リトライ、後続モデル、人手レビューを含めても経済的か？

比較対象を選ぶ際、Jevを高価な最先端チャットモデルとだけ比較してはいけません。ルールシステム、構造化出力を備えたFlashモデル、embeddingと分類器の組み合わせ、自社のラベル付きデータで学習した小型モデルも、妥当な選択肢になり得ます。

十分なラベル付きデータが存在する場合は、特化した専用分類器をベンチマークして比較することを推奨します。現実的な移行経路は、コールドスタートやラベル変更が多い段階ではJevを使い、高頻度キューにラベル付きデータが蓄積した時点で、専用分類器をベンチマークして再評価することです。

Jevは最終的なサポート返信を書かない

振り分け後も、問題の要約、注文の検索、返金条件の確認、返信案の作成が必要になる場合があります。これらをすべてJevに任せるべきではありません。

より明確な役割分担は次の通りです。

工程	より適した実行主体
正確な注文検索、金額計算、日付比較	業務コードとデータベース
キュー、リスク、意図、緊急度の判断	Jevまたは別の分類モデル
ナレッジベース検索	検索・RAGシステム
返信案、説明、自然言語でのやり取り	生成LLM
返金承認、アカウント停止、法的対応	人と社内ポリシー

この構成は、Jevを「自動サポート担当」にするものではありません。各メールが高価なモデルや人手キューに届く前に、コードが直接利用できる低コストで構造化された判断レイヤーを追加するだけです。

まとめ：分類ではなく、制御フローがプロダクトになる

Jevが示す方向性には価値があります。ソフトウェアが必要とするのがキュー、確率、段階だけなら、毎回生成モデルに文章を書かせ、コード側でその意味を推測する必要はありません。

ただし、メール分類デモから完全な業務フローへ進むには、分類後の制御フローを設計する必要があります。どのチケットを自動振り分けできるか、どのシグナルを個別に検出すべきか、いつ人へ渡すか、サービス障害時にどう縮退するか、実際のラベル付きデータでしきい値をどう継続検証するかを決めなければなりません。

したがって、Jevを使ったチケットシステムは、「500通のメールをどれだけ速く分類できたか」だけで評価すべきではありません。問うべきなのは次です。

高リスクのチケットを見落とさずに、不要な引き継ぎ、モデル呼び出し、人手による一次仕分けを安定して減らせるか？

自社の業務データでこの問いに肯定的に答えられて初めて、メール振り分けはモデルのデモから、実際に使える業務ワークフローになります。