AIによるメール分類：受信メールにはルール、LLMプロンプト、型付き意思決定APIのどれを使うか

サポートチケットは通常1つの整った説明として届きます。メールは封筒のように届きます。From・To・Reply-Toヘッダー、「Re: Fwd: 請求書」のような件名、最上部の最新返信、その下に重なる複数の引用、署名、機密保持フッター、時に添付ファイル。ルートを決めるのは主に最新の人が書いた段落と少数のヘッダーです。どのエイリアス宛てか、送信元ドメインが顧客か取引先か、自動返信やバウンスかどうか。生のメールをそのまま送ると、モデルは引用履歴やフッターを根拠として読み、3週間前のメールの話題で分類しがちです。インテント分類は「書き手が何を望むか」を問い、メール分類はまず「どの部分が今の書き手の発言か」を決める必要があります。キュー設計はsupport-triage、チャネル横断のインテントはintent-classificationを参照してください。

本番の受信箱の多くは3層すべてを使うことになります。既知の事実はルール、本文はモデル、しきい値はコード。下表は保守性と失敗モードの比較でありベンチマークではありません。どの選択肢も自社メールのラベル付きテストセットの代わりにはなりません。

メールの解析は自分のコードで行い、小さなJSON stateだけを送ります。残すもの：「Re:」「Fwd:」を除いた件名、宛先エイリアス（billing@、sales@）、送信元ドメインとそれが顧客・取引先リストにあるか、最新メッセージの本文。除くもの：引用返信（「>」で始まる行や「On … wrote:」以降のブロック）、署名、機密保持フッター、トラッキングピクセル、HTML。転送チェーンは転送者のメモと元送信者の最初の段落の短い抜粋を「転送」と明記して残します。添付はファイル名と種類だけを渡します。JevModelはテキストかJSONを受け付け、ファイルや画像は受け付けないため、「invoice.pdf添付」は手がかりであってPDFの中身の証拠ではありません。JevModelではシリアライズ後のstateとリクエスト全体がそれぞれ8,000文字以内である必要がありますが、整形済みメールならほぼ収まります。例ではルート用のChoice質問と、今すぐ人が見るべきかのNoul質問を1つずつ使います。

{
  "state": {
    "subject": "Invoice 2291 charged twice",
    "to_alias": "billing@",
    "sender_domain": "customer-example.com",
    "sender_known_as": "customer",
    "latest_message": "Hi, our card was charged twice for invoice 2291 this morning. Can you refund the duplicate?",
    "attachments": [
      "receipt.png (not read)"
    ]
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Which team should own the newest message in this email? Ignore attachment names as evidence.",
      "criteria": {
        "support": "Product questions, bugs, how-to or account access problems.",
        "sales": "Pricing, plans, demos, procurement or purchase questions from prospects.",
        "billing": "Charges, refunds, invoices, receipts or payment method changes.",
        "vendor": "Messages from suppliers or partners about their own services or invoices to us.",
        "low_value": "Cold outreach, newsletters, automatic notifications needing no action."
      }
    },
    "needs_person_now": {
      "type": "noul",
      "instructions": "Should a person read this email today instead of waiting in a queue?",
      "criteria": {
        "true": "Money, access, legal or a clear deadline is at stake today.",
        "false": "It can wait in the normal queue."
      }
    }
  }
}

ルールごとに3つの帯を、自社の保留メールで設定します。高帯：チームのフォルダーやキューへ移動しラベル付け（低リスクで取り消し可能な動作）。中帯：上位2候補ルートを添えて共有レビュー画面へ。「デモありがとう、ところで請求書が違う」のような混在メールはここに入ります。低帯や2ルートの僅差：共通受信箱に残します。ルートラベルだけで返金・契約関連の返信・メール削除といった取り消せない処理を起動しないでください。コード側で別のチェックを要求し、needs_person_nowのようなNoul質問でルートに関係なく緊急メールを前に出します。billing@とinfo@では構成が大きく違うため、エイリアスごとに帯を調整します。一般的なパターンはconfidence-and-abstentionにあります。

実在のメールを匿名化してfixtureを作り、固定します。メール振り分けを特に壊す形をカバーします。引用履歴が別の話題の返信、転送者が「下記参照」としか書いていない転送チェーン、不在通知、配信エラー（バウンス）、billing@宛ての取引先請求書（billingではなくvendor）、個人アドレスから書く顧客、第2言語のメール、中帯に入るべき混在依頼。パーサーと分類器を一緒に実行します。回帰の多くはモデルではなく整形処理の変更から生じるためです。JevModelのConsole → BatchではCSV・TXT・JSONLを固定質問でアップロードし、行ごとの回答をエクスポートしてスクリプトでラベルと突き合わせられます。Batchは正解率を計算しません。ゴールデンのルートが反転したり、中帯fixtureが棄権しなくなったら変更を不合格にします。手順はevaluationとbatch-text-classification-apiを参照してください。

JevModelはホスト型の意思決定APIです。整形したメールをstateとして、1〜8個の名前付き質問と共に/api/v1/systemoneへPOSTすると、OpenRouter経由で固定モデルtypesafe/jev-1.13が呼ばれます。メールワーカー、ヘルプデスク、CRM同期など複数サービスが確率付きの同一ルート定義を共有したいとき、中帯を推測せず人に届けたいときに向きます。Choiceは2〜12ルート、Scoreは緊急度などの順序付き段階、Noulははい／いいえを確率で答えます。スパムやフィッシングのフィルターには向きません。メールプロバイダーのスパム判定と送信者認証チェックを前段に置いてください。添付・画像・スキャンPDFは読めず、オープンソースではなく重みのダウンロードもありません。無料の認証済みアカウントはUTC日ごとに成功5回までなので、忙しい共有受信箱には有料プランかバッチ計画が必要です。ヘルプデスク向けはzendesk-ai-ticket-classificationを参照。