問い合わせ対応をAIで自動化するには？分類・回答・引き継ぎまでの設計

すべての問い合わせを同じAIへ任せない

問い合わせには、公開FAQで答えられる質問、注文や契約の状況確認、返金や条件変更の相談、苦情などが混在します。文章が似ていても必要な権限や対応責任は異なります。まず種類ごとの件数と現在の処理を調べ、どこまで支援するかを決めます。

最初の対象としては、根拠が整備され、誤った案内の影響を限定しやすい範囲から検討します。個別の顧客情報が必要な質問は、本人確認や閲覧権限の仕組みがないまま回答対象へ入れません。

本記事の表は当社の設計例です。特定業種の規制や企業の規程への適合を示すものではなく、自社の責任者が確認した運用条件に合わせて調整します。

問い合わせ別に、回答と実行の権限を分ける

「回答する」と「実際に注文を変える」は別の権限です。文章の案内が正しくても、システム上の変更を行ってよいとは限りません。問い合わせ本文をシステムへの命令として扱わず、許可された処理だけに接続します。

FAQの検索と顧客データの参照を分ける

FAQや製品マニュアルは一般的な回答の根拠です。一方、契約プランや配送状況は顧客ごとに異なる情報です。両者の参照元、更新時刻、閲覧条件を区別し、一般的な規程を個別の契約条件として断言しない構成にします。

社内向けの説明を顧客へそのまま表示してよいとも限りません。回答に使える公開範囲と、担当者の判断補助だけに使う範囲を分けます。根拠のない回答をそれらしく生成するより、確認中であることと次の対応を伝えられる設計が大切です。

検索を使った回答の仕組みは社内文書検索・RAGの導入で説明しています。検索できる資料が多いことと、安全に回答できることは同じではありません。

「担当者へ転送」で終わらせない

AIが対応できない場合は、会話全文だけを転送するのではなく、用件、確認済み情報、未確認事項、参照した根拠、希望する対応、期限を整理します。担当者が同じ質問を顧客へ繰り返さずに済むかを確認してください。

引き継ぎ先が未決定、休業中、受け付け上限に達した場合も想定します。受付済みの通知と、解決済みの通知は分け、担当者が受け取るまでは未処理として管理します。分類先を誤った案件の戻し先も必要です。

OWASPが整理する過度な権限のリスクを踏まえ、返金・解約・外部送信などの操作は、閲覧機能から分けて制御します。回答モデル自身の「問題ない」という判定だけに依存せず、実行側でも条件を確認します。

検証シナリオ：回答できない質問を正しく引き継ぐ

架空の試験として、公開FAQには載っていない個別契約の変更を顧客が求める場面を用意します。一般的な規程だけで変更できると答えず、必要な確認へ進められるかを見ます。

その際、顧客から既に受け取った情報を担当者がもう一度聞かなくてよいかも確認します。引き継ぎ内容には、確認済みの事項と確認が必要な事項を分け、顧客の希望と会社が承諾した内容を混ぜないようにします。

別の試験では、FAQの旧版と新版が同時に存在する条件を作ります。参照した版と適用条件を確認し、どちらが正しいか決まらない場合は回答を保留できるかを試します。回答が流暢かどうかだけで合格にしないことが重要です。

最後に担当者不在の条件を加え、問い合わせが宙に浮かないか確認します。受付の通知、未対応の管理、代替担当者への連絡までを通すことで、チャット画面の外側にある業務の抜けを見つけられます。

削減率より先に、誤回答と再問い合わせを測る

検証では、回答案が正しいか、根拠を提示できるか、答えるべきでない質問を人へ渡せるかを確認します。回答を送った件数だけを成果にせず、再問い合わせ、誤った振り分け、担当者の修正時間、対応完了までの時間を見ます。

過去の問い合わせを使う場合は、当時の正解が今も正しいかを点検します。製品や契約条件が変更された後の回答を、そのまま学習例や評価の正解にしないようにします。個人情報を含む履歴は、利用できる範囲と匿名化の方法を確認してください。

まず担当者向けの回答案から開始し、実際の修正を分類する案を推奨します。対象を広げる際も、回答が難しい種類を除外したまま改善率を比較しないことが重要です。監視と更新の運用はAIシステムの運用保守で整理しています。