問い合わせ対応の返信文を生成AIで ── テンプレート化する手順と、そのまま送ってはいけない場面

問い合わせ対応に生成AIを入れる話になると、たいてい「返信が速くなりますか」と聞かれます。速くはなります。ただ、それは本題ではありません。

現場で効いてくるのは、返信の品質がそろうことのほうです。同じ質問に、ベテランは3行で的確に答え、入社半年の担当者は10行書いて要点が抜ける。この差がクレームの種になり、二次問い合わせを生みます。返信を型にしてAIに下書きさせると、この振れ幅が小さくなります。

この記事は二部構成です。前半で、過去ログからテンプレートを作るまでの5段階を書きます。後半は、AIの下書きをそのまま送ってはいけない場面を、独立させて書きます。後半のほうが実務では大事です。登場する数字と場面は架空の想定例で、実際の顧客事例ではありません。

速さではなく、振れ幅が縮むことが効果

返信が5分早くなっても、顧客はたいてい気づきません。気づくのは、回答が担当者によって違うときです。

相談は時間短縮の話から始まることが多いのですが、社内で実際に問題になっているのは、たいてい次の3つです。誰が答えても同じ結論になるか。過去の回答と食い違わないか。新しく入った人が、ベテランの水準に近づくまでどれくらいかかるか。

テンプレートとAIの下書きは、この3つに効きます。所要時間はその副産物です。

手順は5段階

問い合わせ返信をテンプレート化する5段階。過去の返信を集める、分類する、型を作る、AIに下書きさせる、人が確定して送る
AIが担当するのは4段階目だけです。効果を決めているのは、1から3の準備です。

1. 過去の返信を集める

直近3か月ぶんの送信済みメールとチャットの返信を、まとめて書き出します。件数が少なすぎると分類の傾向が見えず、多すぎると読み切れません。目安は300〜500件です。

このとき、対応した担当者の名前も残しておきます。「誰の返信を型の下敷きにするか」を選ぶ材料になります。

2. よくある問い合わせを分類する

集めた返信を、質問の内容で分類します。数え方は単純で、同じ趣旨の問い合わせを1つのグループにまとめ、件数の多い順に並べるだけです。

分類の粒度で迷ったら、次の基準で切ります。

  • 回答の文面がほぼ同じになるものは、同じ分類にする
  • 回答の結論が分かれるものは、分けた分類にする
  • 件数が全体の1%未満のものは、いったん「その他」に入れる
  • 分類は10〜15個までに収める。それ以上は運用できない

このやり方で並べると、上位10種類で全体の7割前後を占めるケースが多くあります。残りの3割に手を広げる前に、上位10種類を固めたほうが早く効きます。

分類をAIに手伝わせることもできます。指示の出し方は業務で使うプロンプトの型の4要素で組み立ててください。

3. 型を作る

分類ごとに、返信の型を1つ作ります。作り方は、その分類でいちばん出来のよかった返信を1通選び、顧客固有の部分を空欄に置き換えるだけです。

ゼロから理想の文面を書き起こす会社もありますが、あまりうまくいきません。実際に送って問題が起きなかった文面のほうが、社内の合意も取りやすいためです。

型に入れる項目は、おおむね次の5つで足ります。

項目書くこと
状況の確認顧客が書いてきた内容を、こちらの理解として1文で返す
結論できる/できない、いつまでに、いくらか
理由結論の根拠。長くしない
次の手順顧客にしてもらうこと、こちらでやること
問い合わせ先続きを誰にどう聞けばよいか

4. AIに下書きさせる

型と、その問い合わせの内容をAIに渡して、下書きを出させます。渡すのは型と本文だけで、顧客の氏名・メールアドレス・注文番号は伏せます。

下書きの段階で指定しておくと手戻りが減るのは、分量と語調です。「300字以内」「敬体、謝罪の言葉は入れない」のように先に決めます。謝罪の扱いは後半で書きます。

5. 人が確定して送る

出てきた下書きを、担当者が確認して送信します。確認するのは4点です。結論が社内の基準と合っているか、事実と違う記述が混ざっていないか、約束していない期日が書かれていないか、この顧客に送ってよい内容か。

送信後、修正した箇所を型に反映します。ここを回さないと、型は3か月で古くなります。月1回、修正の多かった型を見直します。

そのまま送ってはいけない場面

ここからが本題です。下書きをそのまま送ってはいけない問い合わせが、はっきりあります。

クレーム。 顧客が怒っている問い合わせは、型から外します。文面の巧拙より、誰が、どの立場で応答するかが問われる場面です。

返金・補償の判断。 金銭が動く回答は、社内の決裁を経た内容だけを書きます。AIは過去の返信をまねて「返金いたします」と書くことがありますが、判断はしていません。

不具合の原因説明。 原因が特定できていない段階で原因らしき文章を出させると、もっともらしい推測が混じります。調査中は「調査中である」としか書かない、と型のほうに書いておきます。

契約内容の解釈。 規約のどの条項がどう適用されるか、という質問です。ここは法務または責任者の確認を通します。

謝罪が必要な場面。 次の節で分けて書きます。

この5つは、型の一覧に「AI下書き対象外」と明記しておくのが確実です。担当者の判断に任せると、忙しい日に線が動きます。

お詫び文をAIに書かせると、何が起きるか

謝罪の文章は、AIが最も器用に書く種類の文章です。そして、最も危ない種類でもあります。

よく起きるのが2つあります。ひとつは、責任範囲を勝手に広げること。こちらに非がない部分まで「弊社の不手際により」と書かれる。送ってしまえば、それが会社の見解になります。

もうひとつは、事実でない原因を書くこと。「システムの一時的な不具合により」という一文が、調査前に入る。あとで原因が別だと分かったとき、訂正の連絡がもう一往復増えます。

対処は、謝罪文を型から外すことではなく、謝罪の範囲を人が先に決めることです。「お待たせした点を謝罪する。原因には触れない」と決めてから下書きを頼む。この順番なら問題は起きにくくなります。

社外に出す文書の確認者を決める考え方は、提案書の初稿を出す4ステップでも触れています。作成者以外が確認する、という点は共通です。

顧客の個人情報を入力しない運用

問い合わせ本文には、氏名、住所、電話番号、注文番号、ときには事情まで書かれています。そのまま貼り付ける運用は、最初に止めます。

現実的なやり方は、貼り付ける前に置き換えることです。

元の情報置き換え
氏名「お客様」
注文番号・会員番号「(番号)」
住所・電話番号削除する
具体的な日付「◯月◯日」に置換、または残す
商品名・型番そのまま残してよい場合が多い

下書きが出たあと、担当者が実際の氏名と番号を戻します。手間は1件あたり十数秒で、慣れると気になりません。

人手に頼らない方法として、問い合わせ管理システム側で伏字にしてから渡す構成もあります。ただ、仕組みを作るのに時間がかかるので、まずは手作業で構いません。入力してよい情報の線引きの決め方は、社内ルールは第3条と第8条だけ先に決めるにまとめました。

よくある質問

テンプレートを使うと、返信が機械的になりませんか?

型で固定するのは、結論と次の手順の並べ方までです。状況の確認の1文は、顧客が書いてきた言葉を使って毎回変わります。実際には、型がないほうが「よくあるご質問をご参照ください」のような定型で済まされがちです。型を決めるほうが、個別の事情に触れる余裕が生まれます。

分類は最初から完璧に作る必要がありますか?

いいえ。上位10種類ができれば運用を始められます。残りは「その他」に入れたまま、月1回の見直しで件数が増えたものを分類に昇格させる形で足ります。最初から30分類を作ると、担当者がどれを使うか選べなくなります。

問い合わせ対応は研修のテーマになりますか?

はい。過去ログの分類と、型を1つ作るところまでを演習にした形を想定しています。分類は自社のデータがないと作れないため、受講者が自社の問い合わせを匿名化して持ち込む前提です。実業務への展開は、研修後に受講者自身が行います。

型を作る前に、送らない範囲を決める

手順を5段階に分けて書きましたが、順番を入れ替えたほうがよい会社もあります。クレームと返金と原因説明をAIの対象外にする、という線を先に引いてから、残った範囲で型を作る順番です。

線を引かずに始めると、いちばん難しい問い合わせにAIの下書きが使われます。そこで一度事故が起きると、使える範囲まで含めて全部が止まります。

自社の問い合わせのどこから手をつけるか整理したい段階でも、お気軽にご相談ください。