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

問い合わせ対応にAIを使うとき、最初に自動化したくなるのは返信文の作成です。しかし、実務で詰まりやすいのは返信を書く前の「この問い合わせを誰が、いつ、どの情報で扱うか」の判断です。

問い合わせ対応のAI分類は、受信した文章をカテゴリに分けるだけの機能ではありません。カテゴリ、優先度、担当、要確認理由、次の状態、有人引継ぎを揃えて初めて、現場の処理につながります。分類だけをして返信を丸投げすると、緊急性の見落としや、担当外の回答、確認不足のままの案内が起きます。

この記事では、問い合わせ対応をAIで分類するときの設計を、Socratesで実装できる範囲に合わせて説明します。AIへの指示文とDeep Logic Prompt、ナレッジ、タグ、CRM、会話ログ、ダッシュボードを使って、分類結果を人の判断につなげる方法を整理します。自動返信の量ではなく、適切な担当者が適切な順番で確認できることをゴールにします。

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

問い合わせ対応のAI分類は、利用者の文章を読み、後工程で扱うための情報を付ける作業です。例えば「予約を変更したい」は予約カテゴリ、「今日中に確認したい」は優先度に関わる情報、「予約担当」が候補の担当、「本人確認が必要」が要確認理由になります。ここで大切なのは、カテゴリ名を付けたことではなく、次の作業が明確になったことです。

分類と返信は別の工程です。営業時間や公開済みの利用方法など、根拠が明確な質問にはAIが案内できます。一方で、契約、返金、例外対応、本人確認、強い不満、専門的な判断が含まれる相談は、分類したうえで担当者に渡す方が安全です。分類の結果を使って、AIが回答するのか、確認質問をするのか、有人対応へ切り替えるのかを決めます。

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

カテゴリだけを増やすと、現場は分類結果を読んでも次の行動を決められません。最初から、問い合わせを受けた担当者が判断に使う項目を揃えます。項目は業務に合わせて減らしてよいですが、誰が処理し、いつ確認し、何が足りないのかは残してください。

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

カテゴリは、商品名や部署名だけでなく、処理の種類で分けると使いやすくなります。例えば「利用方法」「料金」「予約・変更」「不具合」「契約」「苦情・要望」のように、担当や確認手順が変わる単位で作ります。カテゴリが細かすぎると、表記揺れで分類が分かれます。最初は現場が迷わず選べる粒度に絞ります。

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

優先度を「怒っているか」だけで決めると、影響の大きい不具合や締切のある相談を見落とします。緊急性、影響範囲、期限、顧客との関係、放置した場合の損失など、業務に必要な判断材料を明文化します。AIが確定できない場合は、優先度を高く断定せず、要確認として担当者に渡します。

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

担当は、組織図の部署名だけでなく、最初の確認者を決める項目です。「料金」は請求担当、「利用方法」はサポート担当、「予約変更」は店舗担当など、一次受けの単位を揃えます。複数部署にまたがる相談は、主担当と確認先を分けて記録し、たらい回しを防ぎます。

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

要確認理由は、分類の品質を改善するための重要な項目です。情報不足、ナレッジに根拠がない、資料の更新確認が必要、個別契約、本人確認、例外規定、専門家判断、感情的な申し出など、理由を具体化します。「その他」だけにすると、後から何を直せばよいか分かりません。

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

有人引継ぎは、分類の終点ではなく次の処理を始める合図です。担当者に渡すときは、カテゴリ、優先度、相談の要約、確認済み情報、未確認事項、希望する連絡方法を揃えます。AIが返信してよい内容と、引き継ぐべき内容を分けることで、自動化と品質管理を両立できます。

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

問い合わせの分類を始めると、商品名、店舗名、機能名をそのままカテゴリにしたくなります。しかし、名前が違っても同じ手順で処理する相談はあります。反対に、同じ商品についての質問でも、使い方と返金では担当も確認内容も違います。カテゴリは、担当や回答の根拠が変わる境界から作ると運用しやすくなります。

分類表には、カテゴリ名だけでなく、含める例、含めない例、必要な確認項目、回答の可否、担当、引継ぎ条件を持たせます。例えば「料金」には公開料金の案内を含めても、個別見積もりの確定は含めない、という境界を書きます。AIにとっても担当者にとっても、同じ言葉で判断できることが重要です。

表記揺れは、利用者の言い方を集めることで見つかります。「キャンセル」「取り消し」「日程を変えたい」「行けなくなった」は、同じ処理へつながるかもしれません。最初から全表現を網羅するのではなく、会話ログを読みながら例を追加し、カテゴリを増やす理由を残します。

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

問い合わせの文面が強いから最優先、短いから低優先という決め方は危険です。優先度は、対応が遅れたときの影響と、いつまでに確認が必要かを分けて考えます。例えば、複数の利用者に影響する不具合は、個別の不満が穏やかでも優先確認の対象になります。

AIに優先度を付けさせる場合は、条件を抽象語で書かないようにします。「急ぎなら高優先」ではなく、「利用期限、予約当日、サービス停止、個人情報に関する懸念などが含まれる場合は、担当者が優先度を確認する」と、判断材料を具体化します。AIが推測するだけで確定できないものは、要確認理由を付けて引き継ぎます。

優先度の設計では、低く見積もるリスクも確認します。営業時間外、予約直前、支払い期限、契約更新など、時間が過ぎると選択肢が減る相談は、単なるカテゴリ分類では足りません。期限を聞く確認質問を設計し、担当者が判断できる情報を先に集めます。

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

Socratesは、問い合わせを受けて自然な文章で案内するだけでなく、会話の情報を運用改善に使えるAIチャット基盤です。ナレッジに登録した資料を参照させ、AIへの指示文で回答範囲や口調を設定できます。Deep Logic Promptを使えば、条件に応じて確認質問や引き継ぎの案内を出すルールを設計できます。

分類の結果を、カテゴリ、優先度、担当、要確認理由のタグとして扱う設計が考えられます。ここで重要なのは、Socratesが外部の社内チケットシステムへ自動的に担当者を割り当てると断定しないことです。タグ、会話ログ、CRMの顧客情報を見て、現場の担当者が処理を開始できる運用にします。実際の連絡やチケット管理が別システムにある場合は、その移送方法を業務側で決めます。

タグ名は、担当者が読んで迷わない形にします。「重要」「要対応」のような曖昧な名前ではなく、「カテゴリ_料金」「優先度_期限確認」「担当_店舗」「理由_本人確認」のように、意味が分かる規則で揃えます。タグを増やしすぎると確認が遅くなるため、分類表とタグの対応を管理します。

CRMでは、顧客情報や対話履歴を確認しながら、今回の問い合わせが新規相談か既存顧客の継続案件かを見ます。過去の会話を前提にしすぎず、必要な情報だけを引き継ぎ文にまとめます。分析のために個人情報を過剰に保存しないよう、閲覧権限と保管方針も確認してください。

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

1. 最初に、問い合わせの目的と回答してよい情報を定義する
2. 次に、カテゴリと代表例、含めない例を示す
3. 優先度に関わる期限や影響の条件を示す
4. 担当と要確認理由の候補を示す
5. 確定できない場合の確認質問と有人引継ぎを指定する
6. 最後に、分類結果を担当者へ伝える形式を固定する

この順番にすると、AIがカテゴリ名だけを返して会話を終えることを防ぎやすくなります。利用者に表示する文章と、担当者が確認する情報を分けることも重要です。利用者には必要な案内だけを返し、分類の理由や内部メモをそのまま見せる必要はありません。

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

分類がうまくいかないとき、原因を「AIの精度」とだけ考えると改善が止まります。何が足りなかったかを理由に分ければ、ナレッジを追加するのか、確認質問を増やすのか、有人切替を早めるのかを判断できます。

例えば料金の質問に答えられなかった場合、料金表がないのか、個別条件が不足しているのか、情報が古い可能性があるのかで、対応は変わります。要確認理由を残すことで、似た問い合わせが来たときに同じ質問を繰り返さず、分類ルールとナレッジを別々に改善できます。

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

問い合わせ分類の目的は、AIに返信を続けさせることではありません。担当者が必要な相談を早く理解し、利用者に合った判断を返せる状態を作ることです。クレーム、契約確定、返金、個人情報、専門的判断などは、分類したうえで人へ渡す設計にします。

有人引継ぎの文章には、少なくとも次の項目を含めます。相談の目的、カテゴリ、優先度の根拠、確認できた事実、未確認の事項、利用者が希望する次の行動です。AIが事実と推測を混ぜないよう、推測は「要確認」と明示します。担当者が回答を確定するまで、利用者へ断定した表現を返さないこともルールにします。

Socratesの有人対応設計では、Deep Logic Promptに引き継ぎ条件を書き、問い合わせ先やサポートURLを案内します。Webなら埋め込み窓口、LINEなら連携した公式アカウントなど、利用者が実際に使える入口を設定します。窓口だけを示して情報を残さないと、担当者が最初から聞き直すことになるため、会話ログやCRMの使い方まで合わせて決めてください。

分類のKPIと改善サイクル

分類のKPIは、AIがどれだけ返信したかではなく、問い合わせが正しい次工程へ進んだかを見ます。Socratesのダッシュボードや会話ログ、タグを使えば、カテゴリ別の会話量、未解決の相談、有人切替、タグの発生状況を確認できます。担当者が実際に返信した時間や解決結果は、別の業務記録と組み合わせてください。

改善は、分類結果を一括で変更するのではなく、代表的な会話を原因別に読みます。カテゴリが曖昧なら例を追加し、情報不足なら確認質問を変え、根拠不足ならナレッジを整え、個別判断なら有人切替を早めます。変更日とテスト質問を残しておけば、次の担当者も同じ基準で確認できます。

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

公開前は、理想的な問い合わせだけでなく、短い質問、複数の依頼、言い換え、期限のない質問、強い不満、個人情報を含む質問でテストします。分類が正しくても、利用者への案内が不自然だったり、担当者が必要な情報を受け取れなかったりすれば、実務では止まります。利用者画面と内部の分類結果を分けて確認してください。

よくある質問

関連ガイド

• AI自動接客で問い合わせを整理する方法：ナレッジを使ったセルフサポートの全体像を確認できます。
• AIから有人対応へ切り替える設計：引き継ぎ条件と担当者への情報を整理できます。
• 顧客情報と対話履歴を管理する方法：分類後の顧客対応に使う情報を確認できます。
• ダッシュボードの指標の見方：カテゴリやタグの変化を運用改善に使えます。