ユースケース
メールとリードのトリアージ
受信メールを billing、support、sales に振り分け、今日中に対応すべきものを印付けます。
問題
共有受信トレイは積み上げになります。更新の話が機能の質問の後ろで待たされます。
回答に対してコードが行うこと
意図で振り分けます。urgent の印が付いたものはバックログを飛び越えます。
1 回の呼び出しで受信トレイを読む
メール（件名と本文を 1 つの state に）が行き先を決めます：intent（billing、support、sales、other の選択）と urgent（今日中に返答すべきか）。サンプルのメール — finance が INV-2041 を受け取っていないため更新が止まっており、今日の再送を依頼 — は intent=billing と urgent が高く判定されます。共有受信トレイで機能の質問の後ろに待たせるわけにはいかないメールそのものです。
キューのルール
intent で振り分け、各キューは自分の SLA を保ちます。urgent のものはバックログを飛び越えます。もう 1 つのルールも役に立ちます：intent の確率が 2 つのキューの間で揺れているメールは、高い方だけでなく両方に送ります。1 通約 400 トークンなので、10,000 通のトリアージは数ドル分のクレジットです。
受信トレイのトリアージ特有の落とし穴
よくある失敗は返信文脈の喪失です："re:" が先行チェーンを削られた状態で届き、intent は何も読むものがありません。スレッドを state に貼り付けてください。さらに — 2 チームの SLA が違うなら（support は数時間で返答、sales は当日）、intent と urgent はそれぞれ別の経路が必要です。でないと "urgent" が sales のメールの半分を黙って後回しにします。
リクエストの形状
これは、このプリセットについて Playground が送る完全なリクエストです — 自分のサーバーが Bearer キー付きで /v1/systemone に送るのと同じ JSON です。
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Subject: Re: invoice INV-2041\nHi, we never received INV-2041 and finance is blocking our renewal until this is sorted. Can someone resend it today?",
"questions": {
"intent": {
"type": "choice",
"instructions": "What is the sender asking for?",
"criteria": {
"billing": "Invoice, payment or refund",
"support": "Product help",
"sales": "Pricing or a new deal",
"other": "Something else"
}
},
"urgent": {
"type": "noul",
"instructions": "Should this be answered today?"
}
}
}'このユースケースに関する FAQ
- 添付ファイルとスレッドはどうですか？
- スレッドをテキストとして state に貼り付けます。添付の要約は呼び出しの上流で行います。20 通のスレッドでも、トークンの上限には十分余裕を持って収まります。
- 「other」の意図はスパムを捕捉しますか？
- 部分的に — ほとんどのスパムは低緊急度の other として判定され、より速いフィルターが落とせる場所に入ります。フィッシングにはセキュリティ分類器がふさわしく、これは不適です：ここの誤った振り分けのコストは人間にかかります。
- 各チームは自分のキューを調整できますか？
- intent の選択は 1 つの共有された判断です — criteria の文言は共有受信トレイのオーナーが管理し、"sales" がチームごとに黙って別の意味にならないようにしてください。