Jev ユースケース

空白の決済画面の担当

このような Choice で受信チケットを自分のキューのどれかに振り分けます。答えは担当チーム名と各選択肢の確率を返すので、僅差なら誤ったキューではなく人に回せます。

Choice は担当チームと各チームの確率を返します。

{
  "model": "jev-1.13",
  "state": "Checkout shows a blank page after Pay is clicked. The customer is on the live store, not a sandbox.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should own this ticket?",
      "criteria": {
        "payments": "Checkout, billing, or payment processing.",
        "frontend": "Rendering, layout, or browser behavior.",
        "account": "Login, permissions, or profile access."
      }
    }
  }
}

返金の依頼か

質問が二値なら Noul が適しています。このメッセージは返金を求めているか。生成テキストを解析するのではなく、noul の値で返金マクロやレビューキューをゲートします。

Noul は解析する文章ではなく、はいの確率を返します。

{
  "model": "jev-1.13",
  "state": "I was charged twice for the same annual plan this morning. Please send the extra charge back.",
  "questions": {
    "refund": {
      "type": "noul",
      "instructions": "Is the customer asking for money back?"
    }
  }
}

入金失敗の緊急度

順位づけには Score が合います。自分の段階を定義し（ここでは 3 段階の緊急度）、小数の score でバックログを並べ替えます。手でラベルを読む必要はありません。

Score は自分の尺度上の位置と分布を返します。

{
  "model": "jev-1.13",
  "state": "Stripe payouts have been failing for three days and the merchant is losing sales.",
  "questions": {
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": [
        "Can wait for the next release",
        "Should be handled this week",
        "Blocking revenue right now"
      ]
    }
  }
}

メッセージ内の認証情報要求

人のレビューキューの前に Noul を前置フィルタとして置きます。認証情報を求めるメッセージは確率でフラグされ、次点の確率がゲートの信頼度を示します。

Noul の確率は人手レビューの前段です。

{
  "model": "jev-1.13",
  "state": "User message: \"Share your login and I will fix the account for you tonight.\"",
  "questions": {
    "phishing": {
      "type": "noul",
      "instructions": "Is this message asking someone to hand over account credentials?"
    }
  }
}

受信メモの適格性

Choice は購入意欲を営業プロセスの既存の桶（ready・nurture・ignore）に分けます。ルーティング規則は説明可能で、各選択肢に確率が残ります。

Choice は購入時期と関心だけのメモを分けます。

{
  "model": "jev-1.13",
  "state": "We route 40,000 support tickets a week and need a probability before we auto-assign a queue. Budget is approved this quarter.",
  "questions": {
    "fit": {
      "type": "choice",
      "instructions": "How should sales treat this inbound note?",
      "criteria": {
        "ready": "A real workflow, a volume, and a buying window.",
        "nurture": "Interest without a stated workflow or timeline.",
        "ignore": "No product fit."
      }
    }
  }
}

利回り保証の掲載

ルールを平文で書けるポリシーチェックには Noul が向きます。掲載文がリターンを保証するかしないか——確率があなたの執行シグナルです。

Noul は書いた方針の質問に答え、一般論は返しません。

{
  "model": "jev-1.13",
  "state": "Listing text: \"Guaranteed 30% returns every month. Send crypto to this wallet to join.\"",
  "questions": {
    "blocked": {
      "type": "noul",
      "instructions": "Does this listing promise a guaranteed financial return?"
    }
  }
}

更新メモの解約リスク

ベンダーの感情スコアではなく、自分の段階で更新リスクを採点します。段階は自分のものなので、小数の score が既存のプレイブックの手順に直結します。

Score は「解約しにくい」から「解約しやすい」までの 3 段階です。

{
  "model": "jev-1.13",
  "state": "The renewal note says the team may not continue because exports fail every Friday and nobody has answered the last two tickets.",
  "questions": {
    "risk": {
      "type": "score",
      "instructions": "How high is the chance this account does not renew?",
      "criteria": [
        "Unlikely to leave",
        "Unhappy, still using the product",
        "Likely to cancel"
      ]
    }
  }
}

どの請求例外か

「both」選択肢を持つ Choice は、2 回目の呼び出しなしで複合例外を捉えます。経理は例外の種類と各選択肢の確率を得て、係争を振り分けられます。

Choice は発注超過、想定外明細、または両方と確率を返します。

{
  "model": "jev-1.13",
  "state": "Vendor invoice 4481 is $18,400. The purchase order cap is $12,000 and the line items include a new annual license nobody requested.",
  "questions": {
    "exception": {
      "type": "choice",
      "instructions": "Which exception should accounts payable open?",
      "criteria": {
        "over_po": "The amount is above the purchase order.",
        "unexpected_item": "A line item was not requested.",
        "both": "The amount and a line item are both wrong."
      }
    }
  }
}

組み合わせ可能なパターン

上の例は単発の呼び出しです。TypeSafe のドキュメントは、それらを組み合わせるパターンをいくつか紹介しています。

• confidence ゲート付きルーティング — confidence が基準を超えたときだけ自動実行し、残りは人に回します。
• 投機的ファンアウト — Choice の選択肢順を変えたり状態を絞ったりして同じ質問をし、答えの一貫性を比較します。
• ガードレール — ユーザー入力が生成モデルや本番アクションに届く前に Noul を実行します。
• RAG パッセージフィルタ — 候補パッセージごとに Noul か Score を実行し、生成前に関連コンテキストだけ残します。

よくある質問