LLMレビュー付きサポートメール分類

サポートキューには、プロダクトや運用上の課題が隠れています。機能要望、不具合報告、請求に関する質問、オンボーディング、緊急のアカウント問題が、同じ受信箱やヘルプデスクに届きます。

LLM分類は、最終判断ではなく意思決定支援として設計すると効果を出しやすくなります。違いは哲学ではなく運用にあります。モデルは読み、分類し、下書きする。人は承認し、送信する。この構造が、サポートチームを「会社の声をモデルの不調日に晒さずに」AIを採用できる状態にします。

最初のスコープ

最初のスプリントでは、メッセージ分類、重要情報の抽出、返信案の作成までに絞ります。

• 種別、緊急度、プロダクト領域、顧客ランクを分類
• アカウントID、エラー文、プラン情報、依頼内容を抽出
• 不足情報を検出
• 適切なキューへ振り分け
• プロダクトのトーンに合わせた返信案を作成

返信の承認は、サポートやカスタマーサクセスの担当者が行います。システムは読む時間、振り分け時間、下書き作成時間を減らします。

最初のスプリントの妥当なリファレンス構成:

受信: Gmail API / IMAP / Zendesk Webhook / Intercom Webhook
  → Ticket { id, channel, from, subject, body, attachments, customer_id? } へ正規化
  → エンリッチ:CRM/請求から顧客を引き、プランと最近のアクティビティを付加
  → LLM分類(JSON Schema):
      {
        type: "bug" | "billing" | "onboarding" | "feature_request" | "urgent",
        urgency: "low" | "normal" | "high" | "critical",
        product_area: "...",
        customer_tier: "free" | "pro" | "enterprise",
        missing_info: ["account_id" | "error_message" | ...],
        suggested_queue: "tier1" | "billing" | "engineering" | "csm",
        confidence: { type: 0.93, urgency: 0.71, ... }
      }
  → RAGステップ:上位のナレッジ記事、過去チケット、最新リリースノートを取得
  → LLM下書き(取得元への引用、トーンプロファイル、署名つき)
  → 小さなNext.js管理画面、またはZendeskマクロ内のレビューキュー
  → 承認時に元チャネルへ送信し、CRM/Zendeskへ書戻し、
                分析用に全実行ログを記録

重要な設計判断:

• 分類より先に顧客コンテキスト。 同じチケットでもフリーとエンタープライズでは別物。エンリッチ先行が、ルーティングと下書き品質の両方を改善。
• 下書きは必ず引用する。 下書きの主張(返金規程、機能可用性、トラブルシュート手順)はナレッジ記事またはリリースノートに紐づける。レビュアーが数秒で検証可能になる。

安全にするための設計

顧客対応は信頼に関わるため、根拠となる本文、信頼度、提案理由を表示するべきです。信頼度が低いものは手動キューに残します。

最初から実装に値する具体的なガードレール:

• 人手承認なしの送信禁止。 1クリックでもよい。要は監査可能性。
• ブランド別トーンプロファイル。 プロンプトに渡す短いスタイルガイド、加えて承認/却下の返信例を数件。なければモデルは汎用ヘルプデスク調になる。
• 禁止トピックリスト。 一定額以上の返金、法的表現、セキュリティ開示、価格例外は、信頼度に関わらず厳格キューへ。
• 境界でのPII遮蔽。 クレジットカード様パターン、各種ID、OAuthトークンはモデルへ送る前にマスク。
• 顧客あたり自動下書きのレート制限。 人手承認があっても、同一顧客に1時間で5通AI下書きが届く事態は避ける。

また、繰り返し発生する不具合、わかりにくいUX、ドキュメント不足をプロダクトチームが把握できるようにします。分類データは無料のプロダクトリサーチ・ストリームです。「missing_info: account_id」の週次クラスタはオンボーディング不具合を示し、特定領域への「feature_request」スパイクはロードマップに情報を与えます。

測るべき指標

初回返信時間、バックログ量、振り分け精度、返信案の採用率、エスカレーション率、繰り返し出る課題カテゴリを測ります。

実運用パイロットで通った具体的な目標:

• 初回返信時間。 1か月で中央値40〜70%短縮(主に即時の下書き準備による)。
• 振り分け精度。 主要4カテゴリで90%以上(チーム自身の再分類を正解とする)。
• 下書き採用率。 無編集採用40〜60%、軽編集採用20〜30%、書き直しが残り。「無編集採用率」は最もクリーンな信頼度シグナル。
• エスカレーション率。 上昇させない。上昇したら、モデルが機微を取りこぼしているか、プロンプト/ルーティング方針の調整が必要。
• チケットあたりレビュアー時間。 読解+判断の中央値。勝ち筋は処理総数ではなくここ。

最初のスプリントが機能すれば、アプリ内チャット、ナレッジベース提案、CRM更新、プロダクトフィードバック要約へ展開できます。「分類・エンリッチ・下書き・レビュー・ログ」という同じトリアージスタックが、これらすべての土台になります。