生成AIで問い合わせ対応を効率化する方法｜FAQ・RAG・一次回答の活用事例

問い合わせ対応に生成AIを使うとき、最初から顧客への返信まで自動化する必要はありません。まず対象にしやすいのは、問い合わせ分類、対応履歴の要約、FAQ候補作成、一次回答案、マニュアルやFAQの参照です。 PwC JapanのサプライチェーンAI調査では、AI活用の狙いとして、ドキュメント作成の自動化やデータ入力などの定型業務自動化に加えて、カスタマー／ユーザーサポートも挙げられています。問い合わせ対応は、文章を読み、分類し、根拠を探し、回答案を作る作業が多いため、生成AIを試しやすい領域です。 ただし、顧客への自動送信、クレーム対応、契約情報や個人情報を含む回答、法的・医療・金融の判断は慎重に扱います。最初は「AIが回答案を作り、担当者が確認して送る」形から始める方が安全です。

問い合わせが届いたとき、最初に必要なのはカテゴリと担当チームを決めることです。契約、請求、障害、使い方、解約、要望、社内申請などに分類できると、対応の初動をそろえやすくなります。 入力する情報は、問い合わせ本文、既存のカテゴリ一覧、過去チケットの分類例です。出力物は、カテゴリ候補、優先度、担当チーム候補、確認すべき追加情報です。 人が確認するのは、カテゴリが業務実態に合っているか、緊急度が過大または過小になっていないかです。最初は既存チケット50〜100件を使い、人が付けた分類とAIの分類を比較します。カテゴリが多すぎると判定がぶれやすいため、PoCでは5〜10カテゴリ程度から始めます。 <table fit-page-width="true" header-row="true"> <tr> <td>入力する情報</td> <td>出力物</td> <td>人が確認すること</td> </tr> <tr> <td>問い合わせ本文、カテゴリ一覧</td> <td>分類候補、優先度、担当チーム</td> <td>分類が業務実態に合うか。緊急度が妥当か</td> </tr> </table>

FAQは一度作って終わりではありません。製品、料金、社内制度、申請手順が変わると、FAQも更新が必要になります。問い合わせ履歴を使うと、よく聞かれる質問を抽出し、FAQ候補を作れます。 入力する情報は、過去の問い合わせ履歴、既存FAQ、製品マニュアルや社内規程です。出力物は、繰り返し聞かれている質問の一覧、Q&A形式の下書き、既存FAQにない項目です。 人が確認するのは、回答が現在の仕様や規程と合っているか、個人情報や顧客固有の事情が残っていないか、公開してよい表現になっているかです。問い合わせ履歴をそのまま公開用FAQにするのではなく、担当者が正式回答として整えます。

問い合わせ本文、FAQ、製品マニュアル、過去の対応履歴をもとに、一次回答案を作れます。担当者は、ゼロから返信を書くのではなく、回答案を確認して修正する流れにできます。 入力する情報は、問い合わせ本文、関連FAQ、マニュアル、顧客への回答テンプレートです。出力物は、一次回答案、追加で確認すべき事項、参照した文書です。 人が確認するのは、回答内容の正確性、トーン、顧客の契約条件や状況との整合です。PoC段階では、AIが作った回答を顧客に自動送信せず、担当者が確認してから送ります。 自動送信を検討する場合も、パスワード再設定手順や公開FAQへの案内など、低リスクで回答が定型化されたカテゴリに絞ります。障害、クレーム、契約、返金、法的判断を含む問い合わせは、自動送信の対象から外します。

長いやり取りや複数担当者の案件では、過去の履歴を読むだけで時間がかかります。生成AIで対応履歴を要約すると、エスカレーションや引き継ぎがしやすくなります。 入力する情報は、チケットのやり取り、対応メモ、添付資料の概要です。出力物は、発生事象、顧客要望、対応済み事項、未解決事項、次アクションです。 人が確認するのは、事実関係、時系列、未解決事項の抜け漏れです。特にクレームや障害対応では、表現の細かい違いが影響することがあるため、要約をそのまま顧客向け文章にしないようにします。

RAGは、FAQ、製品マニュアル、利用規約、社内手順書などを検索し、その内容をもとに回答案を作る仕組みです。問い合わせ対応では、担当者が「どの資料のどこに書いてあるか」を探す時間を減らせます。 入力する情報は、問い合わせ内容や検索クエリです。出力物は、関連する文書、参照元リンク、回答案です。人が確認するのは、参照元が正しいか、回答が文書の内容から外れていないかです。 RAGで大事なのは、参照元リンクを出すことです。「AIがそう答えた」では確認できません。どのFAQ、どのマニュアル、どの規程を根拠にしたかを見られる形にします。 問い合わせ履歴や顧客情報を検索対象にする場合は、誰がどの情報を見られるかを設計段階で決めます。生成AI品質マネジメントガイドライン第1版でも、LLMを利用するAIシステムではアクセス制御や出力確認を設計時に考える必要があると整理されています。

この考え方は、外部のカスタマーサポートだけでなく、社内ヘルプデスクにも使えます。 情シスでは、PC設定、アカウントロック、SaaSの使い方、社内ネットワークのトラブルなどを分類し、手順書を参照した回答案を作れます。総務や人事では、経費精算、有休申請、勤怠、備品、社内規程に関する問い合わせを分類し、FAQ化できます。 社内向けの場合も、給与、評価、個人情報、契約情報は慎重に扱います。全社員向けFAQと、管理部門だけが見られるFAQを分ける設計が必要です。

問い合わせ対応でいきなり自動返信から始めると、誤回答がそのまま顧客に届く可能性があります。最初は分類と要約だけ、次に一次回答案、次に担当者確認後の送信、最後に低リスク領域の自動返信、という順番で進めます。

分類と要約だけなら、顧客に直接影響しにくく、PoCで試しやすいです。一次回答案は担当者の確認を前提にします。自動返信は、FAQの正確性、例外条件、ログ、停止手順、責任者を整えてから検討します。

問い合わせ対応のPoCでは、次の指標を見ます。 <table fit-page-width="true" header-row="true"> <tr> <td>指標</td> <td>見ること</td> </tr> <tr> <td>一次回答作成時間</td> <td>回答案作成にかかる時間が減ったか</td> </tr> <tr> <td>分類精度</td> <td>人の分類とAIの分類がどの程度一致するか</td> </tr> <tr> <td>自己解決率</td> <td>FAQやチャットで解決した割合が増えたか</td> </tr> <tr> <td>FAQ公開件数</td> <td>問い合わせ履歴から追加・更新したFAQ数</td> </tr> <tr> <td>エスカレーション時間</td> <td>引き継ぎ後、担当者が状況把握する時間が減ったか</td> </tr> <tr> <td>再問い合わせ率</td> <td>同じテーマの問い合わせが再発していないか</td> </tr> </table> 導入後だけ測ると、改善幅が分かりません。PoC前に、現在の一次回答作成時間、分類件数、FAQ更新件数を取っておきます。

いきなり自動返信から始めると、誤回答の影響が顧客に直接出ます。最初は担当者確認ありのワークフローにします。 古いFAQをそのまま検索対象にすると、古い回答が出ます。RAGやFAQ生成の前に、FAQ、マニュアル、規程の最新版を確認します。 参照元が出ない設計にすると、担当者が回答を確認できません。回答案には、根拠になったFAQやマニュアルへのリンクを出します。 評価用質問がないと、PoCの良し悪しを判断できません。よくある問い合わせと正しい回答例を50〜100件用意します。 更新担当がいないと、FAQや検索対象文書は古くなります。製品変更、価格改定、規程変更のたびに誰が更新するかを決めます。

Concretoでは、問い合わせ業務の棚卸しから、FAQやRAGの設計、評価用質問、PoC計画、運用ルール、権限設計、ログ設計まで整理します。 進め方は、最初から自動返信を目指すのではなく、レベル1の分類・要約、レベル2の一次回答案、レベル3の担当者確認後の送信へと段階的に広げます。各段階で、分類精度、回答案の正確性、参照元の妥当性、例外条件、担当者確認の負荷を確認し、次のレベルに進めるかを判断します。 自動返信を検討する場合も、Concretoはレベル4まで伴走します。ただし、すべての問い合わせを自動化するのではなく、公開FAQで根拠を確認できるもの、例外条件が少ないもの、誤回答時の影響が小さいものに対象を絞ります。停止手順、ログ確認、責任者、定期的なFAQ更新まで含めて設計し、現場が安全に運用できる状態を目指します。

※この記事は2026年5月21日時点の公開情報をもとにしています。生成AIサービスの仕様や利用規約は変わるため、導入時には利用するツールの公式情報と契約条件を確認してください。