問い合わせメールを内容別に分類して担当へ振り分ける

処理の起点を決める

チケットが作成されたときを起点にします。問い合わせ管理システムがWebhookを提供していればそれを、なければ1分おきに新規チケットをポーリングします。

ポーリング間隔を長くしないでください。 この構成の価値は速さにあります。5分おきのポーリングだと、緊急案件の検出が最大5分遅れます。

入力データを集める

顧客の契約プランを渡すことが重要です。 同じ内容の問い合わせでも、上位プランの顧客は優先度が高い、という運用がある場合、これがないと判定できません。

過去の問い合わせ履歴も効きます。 「先週も同じ不具合を報告している」という文脈があれば、優先度が上がります。

データの取得方法を決める

問い合わせ本文： チケット管理システムのAPIで取得します。メール本文には引用と署名が含まれるため、除去が必要です。

顧客情報： 問い合わせ元のメールアドレスから顧客を特定します。個人のフリーメールから問い合わせが来ることがあるため、特定できない場合の分岐を用意します。

AIへ渡す前に整形する

1. 引用・署名の除去 … 過去のやり取りの引用が本文の大半を占めることがあります
2. 添付ファイルの扱い … 画像の内容は分類に使わない設計にします。画像解析を入れると処理が重くなり、速さという価値が損なわれます。 添付の有無だけをフラグとして渡します
3. 顧客の特定 … メールアドレスから顧客マスタを引きます
4. 自動送信メールの除外 … 配信停止依頼、システムからの自動返信を、送信元パターンで除外します

AIに処理させる

回答はさせません。 この構成は振り分けだけです。

指示内容を固定する

あなたはカスタマーサポートの一次受付です。
以下の問い合わせを分類し、担当チームと優先度を判定してください。

【厳守事項】
- 回答を作成しないでください。分類のみを行ってください。
- 分類は、提示された分類定義の中からのみ選んでください。
  新しい分類を作らないでください。
- どの分類にも当てはまらない場合は "分類不能" とし、
  confidence を low にしてください。無理に分類しないでください。
- 顧客の感情や態度を評価しないでください。
  （例：「クレーマー」「怒っている」ではなく
    「返金を要求する記述がある」と事実を書く）
- 緊急判定は、提示された緊急検出の定義に該当する場合のみ
  true にしてください。定義にない理由で緊急にしないでください。
- 問い合わせ内容に書かれていない事象を推測しないでください。
- 1件の問い合わせに複数の用件が含まれる場合、
  主たる用件で分類し、他を secondary_topics に列挙してください。

【分類定義】
{category_definitions}

【緊急検出の定義】
{urgent_criteria}

【顧客情報】
契約プラン: {plan} / 契約規模: {contract_size}
過去30日の問い合わせ件数: {recent_count}

【過去の問い合わせ（直近3件）】
{recent_history}

【問い合わせ本文】
件名: {subject}
本文: {body}
添付ファイル: {has_attachment}

「顧客の感情や態度を評価しない」の1行が重要です。 これがないと、AIは「クレーマーの可能性が高い」といった記述を返します。それがチケットに記録され、担当者の目に触れることは、顧客対応の質を下げます。 観測できる事実（返金の要求がある、複数回の問い合わせがある）だけを書かせます。

「定義にない理由で緊急にしない」も重要です。AIは文面の強い表現（「至急」「困っています」）に反応して緊急判定を出しがちですが、緊急の定義は自社が決めるものです。 全件が緊急になると、緊急通知の意味がなくなります。

出力形式を固定する

{
  "category": "",
  "assigned_team": "",
  "priority": "P1 | P2 | P3",
  "is_urgent": false,
  "urgent_reason": "",
  "product": "",
  "secondary_topics": [],
  "observed_facts": [],
  "confidence": "high | medium | low",
  "reason": "",
  "unclassifiable": false
}

• observed_facts … 「返金の要求がある」「解約に言及している」など、対応にあたって知っておくべき事実。評価ではなく事実として書かせます
• reason … 分類の根拠。一次受付が確認する際に使います

システムへ連携する

自動割り当て： confidence: high かつ unclassifiable: false の場合、問い合わせ管理システムのAPIで担当チームを設定します。

緊急通知： is_urgent: true の場合、通常のキュー割り当てに加えて、当番担当者へTeams/Slackで通知します。営業時間外は、当番の担当者へSMSまたは電話通知を行う設計も検討してください。

一次受付キュー： confidence: low または unclassifiable: true の場合、一次受付のキューへ回します。

この部分は、問い合わせ管理システムのAPI仕様に依存します。利用環境に応じた個別確認が必要です。

人が確認する

事前確認はしません。 自動で割り当てます。

理由は、この構成の価値が速さにあるからです。人が確認してから割り当てる設計にすると、現状と変わりません。

代わりに、事後の仕組みで品質を担保します。

1. 再割り当ての記録 … 割り当てられたチームが「これはうちではない」と判断して再割り当てした件を記録します。これが誤分類率の実測値になります
2. 日次のレビュー … 一次受付が、前日の自動割り当ての結果を一覧で確認します（10分程度）
3. 緊急判定の見直し … 緊急と判定されなかったが、実際は緊急だった件を記録します

導入初月は、自動割り当てをせず、AIの判定と人の判定を並行して記録してください。 一致率を測り、90%を超えることを確認してから自動割り当てに切り替えます。

例外に対処する

「AI処理が失敗したときにチケットが宙に浮かない」ことは、この構成で最も重要な例外処理です。 顧客からの問い合わせが誰にも届かない状態は、システム障害より深刻な結果になります。処理の成否にかかわらず、必ずどこかのキューに入る設計にしてください。

記録を残す

• 問い合わせ本文
• AIの分類結果と reason
• 実際に対応したチーム
• 再割り当ての履歴
• 緊急判定の的中・見逃し

再割り当ての履歴が、この構成の唯一の実測指標です。週次で誤分類率を見て、5%を超えたら分類定義を見直してください。