2026/08/28

問い合わせをAIで自動分類する方法｜担当振り分け・誤分類対策・人手確認の設計

カテゴリー：

システム開発

タグ：

メール、Webフォーム、チャット等から届く自由記述の問い合わせは、AIで分類し、担当部署へ振り分ける仕組みを作れます。要約や優先度付け、CRM・チケット管理への登録まで連携することも可能です。

ただし、すべてをAIだけで決める設計は適切ではありません。分類結果に応じて自動処理する範囲、固定ルールを優先する条件、人へ戻す条件を分ける必要があります。特に、苦情、解約、障害、緊急対応など、誤分類の影響が大きい問い合わせは精度の平均値だけで判断できません。

本記事では、問い合わせのAI自動分類について、処理の全体像、分類ルール、誤分類対策、評価方法、既存システムとの連携を整理します。

1. 問い合わせはAIで自動分類できる

AIによる問い合わせ分類は、本文の表現が一定でない場合に適しています。同じ不具合でも「画面が動かない」「登録できない」「エラーが出る」など書き方が異なるため、単純なキーワード一致では振り分けにくいからです。

AIを使うと、文章全体から問い合わせの種類を判定し、要約や優先度の候補を付けられます。たとえば、営業、サポート、契約、請求、不具合、解約、採用、苦情、緊急対応などのカテゴリへ整理し、担当部署の候補を出します。

一方で、自動化できるかは問い合わせ件数だけでは決まりません。分類カテゴリが明確か、過去データがあるか、誤分類時に業務へどの程度影響するか、分類後の連携先が決まっているかを確認します。

2. 問い合わせ分類で自動化できる範囲

分類を起点に、次の処理を組み合わせられます。

問い合わせ種別や対象サービスの分類
内容の要約と担当者向けの論点整理
緊急度・優先度の候補付け
担当部署・担当者の候補決定
顧客番号、契約番号、製品名等の項目抽出
CRMやチケット管理への登録
担当者へのメールやチャット通知

AI活用による自動化の全体像とメリット・デメリットも踏まえ、どこまで自動化するかは処理ごとに決めます。たとえば、要約と担当候補の作成までは自動化し、担当者の確定は人が行う方法があります。分類が安定したカテゴリだけを自動振り分けし、それ以外を受付担当へ戻す方法もあります。

問い合わせへの回答生成や自動送信まで含めると、確認すべき責任範囲が変わります。本記事では回答業務全体ではなく、分類・振り分けと付随する登録・通知までを中心に扱います。

3. AI自動分類の基本的な処理フロー

一般的な処理の流れは次のとおりです。

メール、Webフォーム、チャット等から問い合わせを取得する
取得内容を前処理し、送信元、受付時刻、件名、本文、添付ファイル等を必要な形式へそろえる
AIがカテゴリ、要約、優先度、担当候補を判定する
固定ルールで緊急語、重要顧客、禁止条件等を確認する
自動振り分けできるものと、人の確認が必要なものを分ける
担当部署・担当者を決定する
CRM、チケット、メール、通知先等へ結果を渡す
人が修正した結果を評価データとして記録する

発注担当者が最初に確認すべきなのは、「どのAIを使うか」より、問い合わせがどこから入り、判定結果をどこへ渡すかです。途中で受付番号や顧客情報が欠けたり、同じ問い合わせが重複登録されたりしないよう、入口から連携先までを一つの業務フローとして設計します。

4. 分類カテゴリと判断ルールの決め方

分類カテゴリは、文章の話題ではなく、その後に誰が何をするかを基準に決めます。「製品について」「契約について」のように広すぎる分類では、担当振り分けに使えない場合があります。

担当部署と次の処理から逆算する

営業、請求、契約、採用など担当が明確に分かれるカテゴリは、自動振り分けに向いています。不具合の中でも、操作案内、障害調査、緊急対応で担当が異なるなら、業務上必要な粒度まで分けます。ただし、カテゴリを増やしすぎると判定が曖昧になるため、実際の担当体制に合わせます。

分類と優先度を分ける

「不具合」と「緊急」は同じ軸ではありません。不具合という種類とは別に、サービス停止、期限、顧客区分等から優先度を判断します。AIの文章判定だけに任せず、契約情報や重要顧客フラグなど既存データのルールを組み合わせます。

複数候補と未分類を許容する

一つの問い合わせに請求と解約が含まれることもあります。単一カテゴリを無理に確定せず、主カテゴリと副カテゴリを持たせる、複数候補を人へ提示する、該当なしを未分類へ送る設計が必要です。

5. 誤分類・未判定を人へ戻す設計

AI＋固定ルール＋人手確認の役割を分けると、業務への影響を抑えながら自動化範囲を広げられます。

AI： 自由記述からカテゴリ、要約、担当候補を出す
固定ルール： 緊急語、重要顧客、契約条件、禁止処理を優先する
人：複数候補、未分類、影響の大きい問い合わせを確定する

自動振り分けは、評価データで安定しており、誤った場合も受付担当が修正できるカテゴリから始めます。苦情、重大障害、法的な連絡、解約などは、人による確認を必須にする判断もあります。

人が修正した分類は、元の問い合わせ、AIの判定、修正後のカテゴリ、修正理由を対応付けて残します。ただし、修正結果が自動的にAIへ学習されるとは限りません。評価データやルール見直しに使う運用を別途決めます。

6. 精度と業務効果をどう評価するか

問い合わせ分類は「精度が高い」という説明だけでは評価できません。導入前後で、次の指標を確認します。

誤分類率と、カテゴリ別の誤り方
AIが確定できず人へ戻した未判定率
人が分類を変更した修正率
受付から担当部署へ到達するまでの時間
担当部署から別部署へ回された再振り分け件数
分類・登録に使っていた作業時間
緊急問い合わせの見落とし件数

件数の多い一般問い合わせを正しく分類できても、件数の少ない重大障害を見落とせば、業務上は受け入れられない場合があります。全体平均だけでなく、カテゴリごとの誤分類と影響を見ます。

目標はAIモデル単体の正解率を上げることではなく、必要な問い合わせを適切な担当へ早く届け、再振り分けと受付作業を減らすことです。人へ戻した件数も失敗と決めつけず、安全に処理できた例として評価します。

7. 個人情報・ログ・権限で確認すること

問い合わせには、氏名、メールアドレス、電話番号、顧客情報、契約情報、問い合わせ本文等が含まれる可能性があります。AI処理に不要な情報は送らず、必要に応じて伏せ字や識別子への置換を検討します。

発注・設計時には次を確認します。

どの入力チャネルから何の情報を取得するか
AIへ送る情報と、社内だけに残す情報を分けられるか
入力、分類結果、要約、修正履歴をどこへ保存するか
ログを閲覧できる担当者と保存期間
本番データを検証へ使う場合の承認・加工方法
担当者が閲覧できる顧客情報の範囲

特定AIサービスの保持期間や契約条件は、採用するサービスの公式情報と契約内容で確認します。本記事では個別サービスの仕様や脅威対策の詳細には広げません。

8. メール・フォーム・CRM等との連携方法

連携先を考えるときはサービス名の一覧から選ぶのではなく、現在の受付経路と分類後の作業を整理します。

入口は、メール、Webフォーム、チャット、既存DB等が考えられます。出口は、CRM、SFA、チケット管理、メール、チャット通知、CSV、DB等です。CRMのメリットや導入時の注意点も確認し、分類後の運用に合う連携先を選びます。API連携が可能か、CSVの定期取込が必要か、既存画面へ機能を追加するかで構成が変わります。

連携では、問い合わせID、受信時刻、送信元、元本文、分類結果、担当者、処理状態を対応付けます。連携に失敗した場合の再処理、重複登録の防止、元の問い合わせを確認できる導線も必要です。分類機能だけでなく、担当者が実際に処理を始められる状態までを確認します。