問い合わせ内容をAIで分類するとき、プロンプトだけを作ると運用に戻しにくくなります。
AIは、カテゴリ、優先度、担当者候補、営業メールらしさ、返信下書きまで出せます。
ただし、その結果をどこに保存し、誰が確認し、どこから確定値に変えるかを決めていないと、AI出力はチャット欄で消えます。もっと悪い場合は、AIの候補がいつの間にか確定値として扱われます。
問い合わせAI分類は、プロンプトとレビュー列をセットで作ります。
AIに出してほしい項目
まず、AI出力を分けます。
summary
category_candidate
priority_candidate
owner_candidate
sales_or_legitimate_candidate
reply_draft
human_check_required
human_check_points
reason
confidence
ここで大事なのは、候補と確定を混ぜないことです。
| 項目 | AIが出すもの | 人間が確定するもの |
|---|---|---|
| カテゴリ | category_candidate |
final_category |
| 優先度 | priority_candidate |
final_priority |
| 担当者 | owner_candidate |
owner |
| 営業メール判定 | sales_or_legitimate_candidate |
final_sales_or_legitimate |
| 返信文 | reply_draft |
reply_final または送信判断 |
reply_draft は送信文ではなく下書きです。
reason は、なぜそう分類したかです。
confidence は、AI側の自己評価であって承認ではありません。
JSON形式を固定する
問い合わせ分類では、自然文の返答よりJSON形式のほうが運用に戻しやすいです。
たとえば、次のような形です。
{
"summary": "法人プランの料金と導入時期について相談している",
"category_candidate": "pricing",
"priority_candidate": "high",
"owner_candidate": "sales",
"sales_or_legitimate_candidate": "legitimate",
"reply_draft": "お問い合わせありがとうございます。導入予定時期と利用規模を確認させてください。",
"human_check_required": true,
"human_check_points": ["料金条件", "導入時期", "個人情報の有無"],
"reason": "料金、法人利用、今月中の導入という語が含まれているため",
"confidence": 0.72
}
JSONの項目を固定すると、レビュー列へそのまま保存できます。
プロンプト例
プロンプトは、役割、入力、出力形式、禁止事項を分けます。
あなたは問い合わせ対応の一次分類担当です。
以下の問い合わせ本文と周辺項目を読み、JSON形式で分類候補を返してください。
入力:
- inquiry_text: 問い合わせ本文
- submitted_at: 送信日時
- form_slug: フォーム種別
- source: 流入元
- current_status: 現在の対応状態
- followup_permission: 個別連絡可否
出力項目:
- summary: 担当者向け3行以内の要約
- category_candidate: pricing / support / bug / recruiting / pr / sales_pitch / other / needs_review
- priority_candidate: high / medium / low / needs_review
- owner_candidate: sales / support / recruiting / pr / admin / unknown
- sales_or_legitimate_candidate: legitimate / sales_pitch / needs_review
- reply_draft: 返信下書き。実送信ではない
- human_check_required: true / false
- human_check_points: 人間が確認すべき点
- reason: 分類理由
- confidence: 0から1の数値
禁止:
- 実返信したものとして扱わない
- 担当者を確定しない
- 営業メールを自動除外しない
- 契約、返金、採用、法務判断を確定しない
- 個人情報を不要に引用しない
ポイントは、needs_review を用意することです。
AIに白黒を強制すると、誤分類が増えます。迷うものは人間確認に回します。
レビュー列を作る
AI出力を受け止める列は、候補と確定を分けます。
ai_summary
ai_category_candidate
final_category
ai_priority_candidate
final_priority
owner_candidate
owner
sales_or_legitimate_candidate
final_sales_or_legitimate
reply_draft
reply_final
human_review_status
human_reviewed_by
human_reviewed_at
human_review_note
この列があると、AIが出した候補と、人間が確定した値を分けられます。
human_review_status は、次のような値で十分です。
unreviewed
approved
edited
rejected
needs_second_review
レビュー前は unreviewed。AI候補をそのまま採用したら approved。人間が直したら edited。使わなかったら rejected。判断が重いものは needs_second_review。
この状態があると、AI分類結果をどこまで信用してよいか、後から分かります。
confidenceを承認にしない
confidence はレビュー順の目安です。
承認ではありません。
confidence > 0.9 なら自動返信
このようなルールは避けます。
問い合わせには、契約、返金、採用、個人情報、障害、クレームが混ざります。AIが高い自信を出していても、外部送信してよい許可にはなりません。
confidence は、高いほど確認を省くためではなく、低いものを先にレビューするために使います。
レビュー画面で見る順番
実務では、レビュー順も決めます。
1. human_check_required = true
2. priority_candidate = high
3. sales_or_legitimate_candidate = needs_review
4. confidence が低い
5. followup_permission が未確認
6. owner_candidate が unknown
この順番なら、AI分類をそのまま信じるのではなく、危ないものから人間が確認できます。
レビュー待ちを残さない条件
AI分類を入れると、needs_review や unreviewed が溜まりがちです。
そのまま放置すると、分類したのに誰も確定していない状態になります。
最低限、次の条件でレビューキューを作ります。
human_review_status = unreviewed
or ai_confidence < 0.7
or sales_or_legitimate_candidate = needs_review
or priority_candidate = high
or human_check_required = true
このキューを毎日見るだけでも、AI候補が業務に戻りやすくなります。
AIに任せる範囲
AIに任せるのは、読む順番を整えるところまでです。
要約
カテゴリ候補
優先度候補
担当者候補
営業メールらしさの候補
返信下書き
確認ポイント抽出
人間確認を残すのは、次の領域です。
実返信送信
担当者確定
ステータス確定
営業メール除外
CRM登録
契約、返金、採用、法務、個人情報に関わる判断
ここを分けると、AI分類は便利になります。分けないと、問い合わせ対応の責任境界が曖昧になります。
まとめ
問い合わせAI分類は、プロンプトだけで始めないほうがよいです。
分類候補を出すプロンプトと、人間が確認するレビュー列を同時に作ります。
候補と確定を分ける。JSON形式を固定する。confidence を承認にしない。実返信や担当者確定は人間確認を残す。
問い合わせAI分類の全体設計は、FORMLOVA側の記事にまとめています。