AIでカスタマーサポート返信案を作る方法

AIでカスタマーサポートの返信案を作るなら、問い合わせを分類し、回答に使える最新の事実を決めてから文章化します。AIに返金、契約、障害状況、配送予定などを推測させると、自然な文面でも誤案内になり得ます。問い合わせ履歴に個人情報が含まれる場合は、入力してよい環境と必要な範囲を先に確認します。初期運用ではAIに送信させず、担当者が確認・承認してから送ります。

最初に問い合わせの種類と緊急度を分ける

返信を作る前に、何を解決する問い合わせかを整理します。操作案内、請求、契約変更、障害、返金、配送、苦情、要望など、組織の窓口で実際に扱うカテゴリへ分類します。ひとつのメールに複数の相談が含まれているなら、回答項目を分けます。AIへ「返信を書いて」とだけ頼むと、複数の論点を一文でまとめ、必要な確認が抜けることがあります。

緊急度や権限が必要な相談は、文章生成の前に人へ回す条件を決めます。たとえば、アカウント侵害の疑い、安全への影響、法的要求、返金例外、重大な苦情、本人確認が必要な手続きは、通常のFAQ返信と同じフローにしません。具体的な分類は組織の業務・契約に合わせ、AIが危険度を最終判断しないようにします。

表は横にスクロールできます

分類	AIに任せられる補助	担当者が確認すること
一般操作	承認済み手順の短文化	手順と画面版が最新か
請求・返金	問い合わせ論点の整理	契約・請求記録と権限
障害・安全	状況と質問事項の整理	incident ownerの最新情報
個人情報・本人確認	必要事項のチェックリスト化	確認手順とアクセス権
苦情・法的要求	要点の抽出	専門部署への引き継ぎ

この表は運用設計の例で、業界共通の法的分類ではありません。担当者とエスカレーション先を決めてから使います。

問い合わせから回答へ「事実の束」を作る

返信に使う事実を、問い合わせ文からそのまま推測せず、正本へ照合します。FAQ、利用規約、請求記録、障害告知、配送システムなど、事実の種類ごとに参照元と更新担当を定めます。返信案には、根拠となる資料名、更新日、対象プランや注文の条件を付けます。資料に答えがない場合は「確認が必要」とし、AIが一般知識で補完しないようにします。

問い合わせごとに、次の情報だけを利用します。

• 問い合わせの要点。全文を保管・入力する必要があるか別途判断する。

• 顧客が求めていること。返金、復旧、操作案内など。

• 確認済み事実と参照先。

• 未確認事項と確認担当。

• 返信期限や優先度。社内基準に基づく場合のみ。

• 次の作業と担当部署。

個人情報保護委員会は、個人情報の利用目的を具体的にし、生成AIへ個人情報を入力する場合も必要な範囲で適正に扱うよう注意しています。氏名や契約番号が返信案の文面に必要でないなら、入力データから外すか、承認済み手段で伏せます。置換後に個別の顧客や契約を特定できる場合もあるので、単なるマスキング表記だけを安全の根拠にしません。

返信を「結論・手順・条件・次の窓口」に組み立てる

問い合わせへの返信は、最初に受け取った内容と回答できる範囲を伝え、その後に手順や条件を置きます。顧客が次に何をすればよいかが分からない文章は、丁寧でも解決しません。解決しない場合の窓口、必要な追加情報、次回連絡の目安を、確定している場合だけ書きます。

定型構造の例：

1. 問い合わせ内容を短く受け止める。

2. 確認済みの結論を先に示す。

3. 操作手順や条件を番号付きで伝える。

4. 条件未確認の箇所や必要な本人確認を説明する。

5. 解決しない場合の連絡先と、次の対応者を示す。

謝罪表現は、状況に応じて人が決めます。原因や責任が未確認なのに「こちらの不具合が原因です」と断定したり、補償を約束したりしないでください。一方で、受け取った相談を無視するような機械的な文面にもなっていないか確認します。読み手の不安へ配慮しながら、確認前の事実は確認前と明示します。

下書きを作る依頼文

あなたはカスタマーサポート担当者の返信案を整える編集者です。送信や補償、契約判断はしないでください。

問い合わせに含まれる情報のうち、返信に必要な範囲だけ使い、不要な個人情報を繰り返さないでください。

承認済みのFAQ・手順・契約情報の範囲で回答し、根拠がない事実、返金条件、障害原因、納期を追加しないでください。

回答できない点は「確認中」とし、確認担当を列挙してください。

結論、手順、条件、次の窓口の順に短く書き、顧客が次にすることを明確にしてください。

出力：返信案｜根拠資料｜未確認事項｜人の確認が必要な理由

入力：［社内承認済み環境へ、必要最小限の情報のみ］

AIの出力は、問い合わせ者へそのまま送らず、担当者が原文と回答根拠を照らします。AIが「お客様の設定が原因です」と推定した場合、その原因をログや担当部署で確認するまで返信に入れません。顧客の文面から感情や意図を断定するのも避け、必要なら「こちらの理解が合っているか確認させてください」と質問します。

送信前に手動確認を入れるケース

すべての返信を同じ確認レベルにする必要はありません。FAQに明記された単純な操作案内は、組織の承認済みルールに沿って確認を簡素化できる場合があります。一方、次のような項目は担当者の確認を必須にします。

• 金額、請求、返金、契約期間、解約。

• アカウント停止、本人確認、個人データの開示・削除。

• 障害の原因、復旧時刻、損害や補償の約束。

• 安全上の問題、法務・規制に関係する相談。

• 顧客の怒りや苦情に対する責任の認定。

• 根拠資料が古い、または担当者間で回答が異なる。

送信ボタンの直前に、宛先、添付、リンク、顧客名、注文・契約の対象が合っているかも見ます。問い合わせ内容を解決するために追加情報を求める場合は、その必要性と送信先の安全性を確認します。承認者や回答期限が決まっていない案件は、AIに「適切な回答」を生成させて終わらせず、責任者へエスカレーションします。

承認済みの返信を再利用する管理

良い返信をそのままテンプレートへコピーすると、古い価格や制度が残ることがあります。テンプレートには、適用する問い合わせカテゴリ、根拠資料、適用条件、更新担当、最終確認日を付けます。変動情報は本文へ固定せず、最新情報を確認して差し込む運用を検討します。テンプレートをAIへ渡す場合も、適用条件を併記し、対象外の案件へ流用しないようにします。

チームで振り返るときは、返信案の修正率だけでなく、追加問い合わせ、再オープン、エスカレーションの理由を見ます。修正が多いなら、プロンプトの問題だけでなく、FAQの根拠が古い、社内の権限が不明、一次情報が見つからないなど業務側の原因かもしれません。顧客の理解度や満足を数値で示すなら、測定方法と対象期間が確認できてからにしてください。

返信案の例：事実・未確定・次の手順を分ける

仮に利用者から「二重に請求されたように見える」と連絡が来た場合、返信案を作る前に確認できた事実を分けます。たとえば、社内システムで請求が2件表示されている、片方が仮押さえかどうかは未確認、決済担当の確認には数営業日かかる、といった具合です。AIには確認済みの事実だけを渡し、「返金されます」「すぐ解決します」と補わないように指示します。

下書きの骨子は、①連絡への受け止め、②現在確認できている内容、③未確定事項、④担当部署が確認する次の手順、⑤追加で必要な情報や連絡先です。個人のカード番号やパスワードを返信で尋ねる必要がある場合は、通常のメールで送らせず、組織が承認した安全な窓口へ案内します。ここでの例は返信の構造を示すもので、特定企業の請求条件を表すものではありません。

表は横にスクロールできます

状況	AIに任せる部分	人へ回す条件
操作方法が既知	承認済み手順を短く説明	画面や権限が手順と異なる
請求・返金	問い合わせの要点整理	金額、契約、返金可否の判断が必要
障害・安全影響	既知のお知らせを引用して整文	情報が未確定、影響範囲が不明
苦情・法的要求	論点を箇条書きにする	責任認定、補償、期限付き要求を含む
個人情報の訂正	必要な確認項目を整理	本人確認や記録更新が必要

この表の分類名や期限は組織の運用に合わせて決めます。AIに危険度を最終判定させるのではなく、見落としを防ぐための事前ルールとして用います。

出力をそのまま送らない仕組みを作る

返信案には、元になったFAQ・規約・障害告知などの参照元を付け、担当者が案内文の各主張を確認できるようにします。根拠が見つからない一文は削るか、担当部署への確認事項に移します。テンプレートを使う場合も、返金・契約変更・障害・本人確認などは通常の案内文と別の承認経路にし、条件が揃っていない案件へ定型文を流用しないようにします。

担当者は、送信前に宛先、対象アカウント、数値、日付、約束した対応、添付ファイルを照合します。AIが丁寧な謝罪文を作っても、事実誤認を埋め合わせるものではありません。未解決なら、回答を急いで完成させるより「何が確認中で、いつ・どの窓口から続報するか」を承認済みの範囲で伝えます。

試行運用で品質を見る

小さく始める場合は、担当者が最終送信するカテゴリを選び、一定期間、AI案と人が実際に送った返信を記録します。記録するのは、修正した箇所、根拠の不足、分類の誤り、エスカレーションが必要だった理由です。顧客名や会話全文を評価資料へ複製せず、目的に必要な範囲に絞ります。

修正が減ったことだけで自動送信へ進めません。誤案内の影響が大きいカテゴリが残っていないか、回答ソースが更新された際に止められるか、担当者不在時に誰が承認するかを確認します。自動化の可否は別の業務・法務・セキュリティ判断です。返信文作成の精度だけで決めないでください。

返信案の品質が悪い場合は、次の順で原因を切り分けます。分類違いならカテゴリ設計、事実がないならFAQや正本、口調の不一致なら承認済み文例、不要な個人情報があるなら入力処理を見直します。毎回プロンプトに注意書きを足すだけでは、根本原因が残ります。

AIものさしの判断

AIをCSへ使うなら、最初から自動返信botにするより「返信案作成」から始める方が運用しやすいです。

問い合わせを分類し、正しいsourceを指定し、人間が最終確認する。

この流れなら速度を上げつつ、誤案内を抑えられます。