問い合わせ対応をAIで分類する方法：カテゴリ・優先度・担当・要確認理由・有人引継ぎの設計

問い合わせ対応にAIを導入する際、返信文の作成から自動化したくなるかもしれません。しかし、実務で先に整えるべきなのは、返信前の「誰が、いつ、どの情報を基に対応するか」という判断です。

問い合わせ対応のAI分類では、受信した文章にカテゴリ名を付けるだけでは不十分です。カテゴリ、優先度、担当、要確認理由、有人引継ぎを一つのルールとして設計して、初めて現場の処理につながります。分類後の対応まで決めずにAIへ返信を任せると、緊急性の見落とし、担当範囲外の回答、確認不足による誤案内が起こります。

この記事では、「問い合わせ対応 AI 分類」を実務へ落とし込む方法を解説します。分類表、確認質問、記録項目、有人引継ぎを使い、分類結果を人の判断につなげる手順を整理します。目標は自動返信の件数を増やすことではなく、適切な担当者が必要な情報を受け取り、妥当な順番で確認できる状態を作ることです。

問い合わせ対応のAI分類とは

問い合わせ対応のAI分類とは、利用者の文章を読み取り、後工程に必要な情報を付与するトリアージです。例えば「予約を変更したい」という相談なら、カテゴリは「予約・変更」、主担当は店舗担当です。予約日が分からなければ「情報不足」を要確認理由として記録し、日付を尋ねてから引き継ぎます。重要なのは分類名そのものではなく、次に行う処理を決められることです。

分類と返信は別々に設計します。営業時間や公開済みの利用方法など、登録済みのナレッジを根拠に回答できる質問はAIで案内できます。一方、契約の確定、返金、例外対応、本人確認、強い不満、専門的な判断を含む相談は、人が確認すべき候補です。分類結果に応じて、AIが回答する、追加質問をする、回答を保留する、優先して有人対応へ切り替える、という出口を選びます。

5つの項目を一つの分類設計にする

カテゴリだけを細かく設定しても、担当者は分類結果から次の行動を判断できません。分類表には、カテゴリ、優先度、担当、要確認理由、有人引継ぎの5項目をまとめます。各項目について、判断に使う質問、記録する値、分類後の処理を決めてください。

1. カテゴリ：何についての問い合わせか

カテゴリは、商品名や部署名ではなく、実際の処理が変わる単位で分けます。「利用方法」「料金」「予約・変更」「不具合」「契約」「苦情・要望」など、確認手順、回答根拠、担当のいずれかが変わる地点が区切りです。担当も処理も同じなら、最初から細分化する必要はありません。

2. 優先度：いつ、どの順番で見るか

優先度は文面の強さではなく、期限と影響を基に判断します。利用期限や予約日が迫っているか、業務が止まっているか、影響が複数の利用者に及ぶか、個人情報・契約・返金の確認が必要かを見ます。判断材料がなければ推測で高・中・低を決めず、「期限確認」などの要確認理由を付けます。

3. 担当：誰が最初に確認するか

担当には、最終的な処理部署ではなく、最初に内容を確認する主担当を設定します。例えば、利用方法はサポート担当、予約変更は店舗担当、返金は承認できる担当が候補です。複数部門に関係する相談では主担当と確認先を分け、担当を確定できない場合の一次受け窓口も決めます。

4. 要確認理由：なぜAIが確定できないか

要確認理由は、AIが判断を保留した原因を記録する項目です。「情報不足」「根拠不足」「資料の更新確認」「個別判断」「本人確認」「専門・安全確認」などに分けます。「その他」だけでは、確認質問、ナレッジ、回答範囲、有人切替条件のどこを直すべきか判断できません。

5. 有人引継ぎ：どの状態で人へ渡すか

有人引継ぎは、AIの対応を終えるだけでなく、人の処理を開始する工程です。引継ぎ時には、相談の要約、カテゴリ、優先度とその根拠、担当候補、確認済みの事実、未確認事項、要確認理由、希望する次の行動を渡します。AIが回答できる範囲と、人の承認が必要な範囲を先に切り分けておきます。

カテゴリ設計は「商品名」より「処理の違い」から始める

問い合わせのカテゴリを商品名、店舗名、機能名だけで作ると、分類結果と実際の処理が一致しないことがあります。名称が異なっても、同じ担当者が同じ資料を確認して回答するなら、同じ処理としてまとめられます。反対に、同じ商品に関する相談でも、利用方法の案内と返金の判断では、担当者も必要な情報も異なります。

カテゴリを作る際は、過去の問い合わせを「誰が確認したか」「何を調べたか」「AIだけで回答できたか」「どの条件で人へ渡したか」という観点で整理します。これらが変わる位置をカテゴリの境界にすると、分類後の担当振り分けまで一貫します。

分類表には、カテゴリ名に加えて、含める例、除外例、必要情報、回答可否、主担当、引継ぎ条件を記載します。例えば「料金」カテゴリでは、公開済み料金の案内は含めても、個別見積もりの確定は含めません。個別条件が必要なら確認質問を行い、承認できる担当へ渡します。

利用者の表現も代表例として蓄積します。「キャンセル」「取り消し」「日程を変えたい」「行けなくなった」が同じ予約変更の処理につながるなら、一つのカテゴリの表記例にまとめます。会話ログで未分類や誤分類を確認し、既存カテゴリでは処理できない場合に限って新しいカテゴリを追加します。

優先度は感情ではなく、影響と期限を合わせて判断する

問い合わせの優先度を文面の強さだけで決めると、穏やかな文章で届いた重大な不具合や、期限のある相談を見落とします。まず「対応が遅れた場合の影響」を確認し、次に「いつまでに判断が必要か」を確認します。複数の利用者に影響する不具合は、強い不満が書かれていなくても優先確認の候補です。

AIへ優先度判定を指示するときは、「急ぎなら高優先」のような抽象的な条件を避けます。利用期限、予約当日、業務停止、複数利用者への影響、個人情報に関する懸念など、確認すべき材料を列挙します。ただし、その語が含まれるだけで優先度を確定するのではなく、実際の期限と影響を確認するルールにします。

例えば「今日中に確認したい」という文面だけでは、高優先と断定できません。今日を過ぎると予約や手続きが無効になるのか、単なる希望時刻なのかを質問します。期限や影響が分からない場合は、「優先度_期限確認」などのタグを付け、担当者が確認するまで確定を保留します。

営業時間外、予約直前、支払期限、契約更新など、時間の経過によって選択肢が減る相談もあります。カテゴリだけでは期限を把握できないため、カテゴリごとに必要な確認質問を決めます。予約変更なら予約日、支払いなら期限、不具合なら利用への影響範囲を確認する、といった対応です。

Socratesで分類結果を運用につなげる

Socratesで問い合わせ分類を運用する際は、利用できる設定項目を公式仕様または管理画面で確認したうえで、回答範囲、分類条件、確認質問、有人引継ぎの順にルールを整理します。回答根拠には承認済みの資料を使い、確認できない内容は回答を確定せず、追加質問または有人対応へ進めます。

分類結果をタグで管理できることが公式仕様または管理画面で確認できる場合は、カテゴリ、優先度、担当、要確認理由を区別して整理します。「重要」「要対応」のように解釈が分かれる名称は避け、「カテゴリ_料金」「優先度_期限確認」「担当_店舗」「理由_本人確認」のように、項目と値が分かる命名規則を使います。タグを利用できない場合は、同じ項目を自社の問い合わせ管理表に記録します。

ここでは、Socratesが外部のチケットシステムへ担当者を自動的に割り当てることを前提にしません。担当者が確認できる情報の種類と閲覧場所を公式仕様または管理画面で確認し、処理を開始できる運用を作ります。問い合わせの管理先が別システムなら、誰が、どの情報を、どの時点で移すかを業務手順として決めてください。

顧客情報や対話履歴を確認できる範囲は、Socratesの公式仕様または管理画面で個別に確認してください。確認できる場合は、今回の問い合わせが新規相談か継続案件かを判断する材料として使います。引継ぎ文には処理に必要な情報だけをまとめ、取得項目、閲覧できる担当者、保管方針も自社のルールに沿って決めます。

分類ルールを指示文に書くときの順番

1. 問い合わせ対応の目的と、AIが回答してよい範囲を定義する
2. カテゴリごとに代表例、除外例、必要情報を示す
3. 優先度の判断に使う期限と影響の条件を示す
4. 主担当、確認先、要確認理由の候補を示す
5. 確定できない場合に行う確認質問を指定する
6. 有人引継ぎの条件と、担当者へ渡す形式を固定する

指示文には、利用者向けの案内と担当者向けの分類情報を分けて記載します。利用者には、回答、確認質問、引継ぎ先など、その時点で必要な案内だけを表示します。カテゴリ候補や内部の判断理由をそのまま表示すると、未確定の情報が確定事項として伝わるおそれがあります。

要確認理由を分類に組み込む

分類できなかった原因を一律に「AIの精度」と扱うと、修正箇所を特定できません。要確認理由を記録し、情報不足なら確認質問、根拠不足ならナレッジ、個別判断なら有人切替というように、原因と改善箇所を対応させます。

例えば、料金に関する質問へ回答できなかった場合でも、原因は一つではありません。料金表がナレッジに登録されていないなら根拠不足です。利用条件が分からないなら情報不足、資料が現行版か判断できないなら更新確認、個別見積もりが必要なら個別判断に該当します。理由を切り分ければ、資料を追加すべきか、条件を質問すべきか、人へ渡すべきかを判断できます。

要確認理由は、分類不能の記録だけでなく誤分類の分析にも使えます。担当者が分類を変更した際は、「表記例が不足していた」「複数の依頼が混在していた」「期限を確認できていなかった」など、変更理由を残します。次回の改善では、カテゴリ、質問、ナレッジ、引継ぎ条件のうち、原因に対応する箇所だけを修正します。

返信を丸投げしない有人引継ぎ

有人引継ぎの判断は、「AIが答えられなかったとき」だけに限定しません。AIが情報を整理できても、人の承認や本人確認が必要な相談があります。契約確定、返金、例外対応、本人確認、強い不満、専門・安全上の判断を含む場合は、有人対応の候補として扱います。

境界は三段階に分けると整理しやすくなります。公開情報を根拠に回答できる場合はAIが案内します。追加情報があれば案内できる場合は確認質問を行います。承認、例外判断、本人確認、専門判断が必要な場合は、必要な情報を集めたうえで担当者へ渡します。追加質問を重ねても人の判断が必要な相談は、無理に会話を続けません。

引継ぎ文では、確認済みの事実と推測を明確に分けます。利用者が述べた予約日や希望内容は確認済み情報として記録できます。一方、カテゴリ、原因、担当候補など、AIが推定した内容には「要確認」と記載します。担当者が確定する前に、返金可能、契約変更済みなどと利用者へ断定しないルールも必要です。

有人引継ぎでは、自社で運用している問い合わせ窓口のうち、実際に担当者が確認できる入口を案内します。Socrates上で引継ぎ条件や案内内容を設定できる範囲は、公式仕様または管理画面で確認してください。窓口だけを示すのではなく、相談の要約、確認済みの事実、未確認事項をどこに記録し、担当者がどの順番で確認するかまで運用手順に含めます。

分類のKPIと改善サイクル

分類品質は、AIの返信件数ではなく、問い合わせが正しい次工程へ進んだかで確認します。カテゴリ別の会話数、分類不能、要確認理由、有人切替などを記録し、変化を見ます。Socratesのダッシュボード、会話履歴、タグで確認できる項目は公式仕様または管理画面で個別に確認し、取得できない項目は自社の業務記録で補います。

改善時は、すべてのルールを一度に変更せず、代表的な会話を原因別に確認します。カテゴリの境界が曖昧なら代表例と除外例を追加します。情報不足なら確認質問を変更し、根拠不足ならナレッジを更新します。個別判断が多い場合は、AIの回答範囲または有人切替条件を見直します。

変更した内容、変更日、確認担当者、テストに使った質問を記録します。同じテスト質問で変更前後の分類、確認質問、引継ぎ内容を比べれば、修正したルールが別のカテゴリへ影響していないか確認できます。

導入時の実装チェックリスト

公開前のテストには、短文、複数の依頼を含む文章、言い換え、期限不明の相談、強い不満、個人情報を含む質問を使います。例えば「予約を変えたい。料金も知りたい」という複数依頼では、主な相談だけを残してもう一方を見落としていないか確認します。「今日中にお願い」という期限不明の相談では、根拠なく高優先とせず、必要な質問が出るかを見ます。

テストでは、利用者に表示する案内と、担当者が受け取る分類結果を分けて確認します。利用者への文面が自然でも、担当候補や未確認事項が内部情報に残っていなければ、引継ぎ後に聞き直しが発生します。反対に、内部の分類が正しくても、利用者へ推測を断定していれば公開できません。両方の画面で、回答範囲と引継ぎ内容を確認してください。

よくある質問

関連ガイド

• 分類後にAIが案内できる範囲を決める際は、AI自動接客で問い合わせを整理する方法で、ナレッジを使ったセルフサポートの全体像を確認できます。
• 契約、返金、本人確認、強い不満などの切替条件は、AIから有人対応へ切り替える設計で詳しく整理しています。
• 分類後に参照できる顧客情報と対話履歴の範囲を確認する際は、顧客情報と対話履歴を管理する方法を参照してください。継続案件か新規相談かの判断に使える項目は、実際の設定と表示内容を確認します。
• 分類改善に利用できる指標を確認する際は、ダッシュボードの指標の見方を参照してください。カテゴリ、タグ、有人切替に関する指標が表示されるかは、実際の仕様と画面で個別に確認します。