問い合わせ本文をAIで分類するとき、最初に作るべきものはプロンプトではなくJSONスキーマです。
プロンプトだけで始めると、出力が毎回少しずつ変わります。
カテゴリだけ返る
優先度が文章で返る
担当者候補と部署名が混ざる
返信文まで勝手に作られる
人間確認が必要な理由が残らない
これだと、AI分類は便利でも業務システムに戻しにくくなります。
問い合わせ対応では、AIに「正解を決めてもらう」より、次の確認を速くするための構造化出力を作るほうが扱いやすいです。
入力には本文だけを渡さない
問い合わせ分類では、自由記述だけをAIに渡すと文脈が足りません。
フォームや受付画面で取れている項目があるなら、本文と一緒に渡します。
{
"submitted_at": "2026-06-23T10:15:00+09:00",
"inquiry_type_hint": "料金について",
"company_size": "10-50",
"planned_start": "今月中",
"contact_permission": true,
"message": "料金プランと初期設定について相談したいです。今月中に導入できるかも知りたいです。"
}
message だけでは「料金相談」ですが、planned_start があると優先度の候補も出しやすくなります。
AI分類は、本文だけの自然言語処理ではなく、周辺項目を含めた業務判断の補助として設計します。
出力スキーマを先に決める
最小構成なら、このくらいで始められます。
{
"summary": "料金プランと今月中の導入可否に関する相談",
"category": "pricing",
"priority": "high",
"owner_candidate": "sales",
"sales_or_legitimate": "legitimate",
"reply_draft": "お問い合わせありがとうございます。料金プランと導入時期について確認いたします。",
"human_check_required": true,
"human_check_points": ["料金条件", "導入時期", "契約条件"],
"reason": "導入希望時期が今月中で、料金相談が含まれるため",
"confidence": 0.78
}
大事なのは、分類結果を一つのテキストにしないことです。
category、priority、owner_candidate、reply_draft、human_check_required を分けます。
分けておけば、画面、通知、集計、担当者確認で使い回せます。
JSON Schemaの例
実装では、AIに自由形式で返させず、許可する値を決めます。
{
"type": "object",
"required": [
"summary",
"category",
"priority",
"owner_candidate",
"sales_or_legitimate",
"human_check_required",
"human_check_points",
"reason",
"confidence"
],
"properties": {
"summary": {
"type": "string",
"maxLength": 160
},
"category": {
"type": "string",
"enum": ["pricing", "support", "bug", "partnership", "recruiting", "other"]
},
"priority": {
"type": "string",
"enum": ["low", "normal", "high", "urgent"]
},
"owner_candidate": {
"type": "string",
"enum": ["sales", "support", "product", "hr", "admin", "unknown"]
},
"sales_or_legitimate": {
"type": "string",
"enum": ["sales_pitch", "legitimate", "unknown"]
},
"reply_draft": {
"type": "string"
},
"human_check_required": {
"type": "boolean"
},
"human_check_points": {
"type": "array",
"items": { "type": "string" },
"maxItems": 5
},
"reason": {
"type": "string",
"maxLength": 240
},
"confidence": {
"type": "number",
"minimum": 0,
"maximum": 1
}
}
}
カテゴリ名は、自社の対応単位に合わせます。
重要なのは、カテゴリを細かくしすぎないことです。
最初から20カテゴリ作るより、担当者や次アクションが変わる単位に絞ったほうが運用できます。
confidenceを承認にしない
confidence は便利ですが、承認ではありません。
confidence が 0.9 以上なら自動返信する
このルールは避けたほうがよいです。
問い合わせには、契約、返金、採用、個人情報、障害、クレームが混ざります。
AIが高い自信を出していても、外部送信してよい許可にはなりません。
confidence は、レビュー順や再確認の目安として使います。
confidence < 0.6 -> 要確認
priority = urgent -> 要確認
category = bug -> 要確認
sales_or_legitimate = unknown -> 要確認
判断の確定は別の状態にします。
ai_classification_status = done
human_review_status = unreviewed
返信下書きと実送信を分ける
AIに返信文を作らせるのは便利です。
ただし、返信下書きと実送信は別です。
reply_draft
reply_final
reply_sent_at
reply_sent_by
AIの下書きは reply_draft に入れます。
人間が確認して直したものを reply_final に入れます。
送信したときだけ reply_sent_at を入れます。
これで、AIが作っただけなのか、実際に送ったのかが分かります。
プロンプトはスキーマに合わせる
プロンプトは長くしすぎず、出力型を守ることに集中します。
あなたは問い合わせ対応の一次分類担当です。
次の問い合わせを読み、指定されたJSON Schemaに一致するJSONだけを返してください。
目的:
- 問い合わせの要約
- カテゴリ候補
- 優先度候補
- 担当者候補
- 営業メールか正規問い合わせかの候補
- 人間が確認すべき点の抽出
禁止:
- 実返信したものとして扱わない
- 担当者を確定しない
- 契約、返金、採用、法務判断を確定しない
- JSON以外の文章を返さない
AIに期待するのは、対応の確定ではありません。
確認前の材料を揃えることです。
最小チェックリスト
[ ] 本文だけでなく周辺項目も入力に含めた
[ ] category / priority / owner_candidate を分けた
[ ] sales_or_legitimate をカテゴリから分けた
[ ] reply_draft と実送信を分けた
[ ] human_check_required を必ず返す
[ ] confidence を承認として扱わない
[ ] AI分類完了と人間レビュー完了を別状態にした
問い合わせAI分類は、AIに任せるほど良いわけではありません。
AIが候補を出し、人間が確認し、状態として残るところまで設計すると、問い合わせ対応の運用に戻しやすくなります。
問い合わせ対応AIと送信後ワークフローの設計は、こちらに整理しています。