問い合わせ対応をAIで下書きするときの運用手順

問い合わせが届くたびに、担当者が過去の文面を探し、状況を読み取り、返信を書く運用では、定型的な内容でも確認に時間がかかります。そこで返信文の作成をAIに補助させる方法があります。ただし、AIが作った文章を確認せずに送信する運用は適切ではありません。相手の状況、契約条件、最新の案内、社内方針を確認しないまま文章だけ整えると、実際の問い合わせに合わない回答になる可能性があります。

問い合わせ対応をAIで下書きするときは、受付、情報整理、下書き、事実確認、人による承認、送信、記録と改善を別の工程として扱います。AIが担うのは返信案を作る工程の一部です。送信可否や個別判断をAIに確定させる運用とは分けて考えます。まず各工程の担当者と確認項目を決め、どの場面で人が判断するかを明確にします。

問い合わせ対応をAIで下書きする前に決めること

最初に決めるのは、AIに何をさせるかではなく、どの問い合わせを対象にするかです。営業時間、資料の場所、申込み方法など、正本となる情報を確認しやすい質問は、下書きの対象にしやすい内容です。一方、同じ「料金を知りたい」という質問でも、契約内容や利用条件によって回答が変わる場合は、条件確認や担当者への引き継ぎを前提にします。

対象範囲は、問い合わせの種類と回答後の処理で分けます。次の表を作ると、AIに下書きを作らせる範囲と、最初から人が確認する範囲を判断しやすくなります。

「AIに任せる」「人が書く」の二択にすると、確認が必要な問い合わせの扱いが曖昧になります。案内だけ作る、追加情報を尋ねる、担当者へ渡すの三つに分け、それぞれの次工程を決めてください。対象外を先に定義しておくと、文章が自然に見えても送信を止める判断がしやすくなります。

手順1：問い合わせ受付で必要な情報をそろえる

受付時に確認する情報が少ないと、下書きの段階で推測が入りやすくなります。問い合わせ本文だけでなく、受付日時、窓口、問い合わせの分類、相手が求めている次の行動を記録します。メールなら件名と本文、フォームなら選択項目と自由記述、電話なら担当者が聞き取った要点を、共通の項目へ置き換えます。

氏名や連絡先をすべてAIへ渡す必要はありません。返信案の作成に必要な情報と、担当者だけが確認する情報を分けます。氏名、住所、電話番号、契約番号、決済に関する情報などは、入力の要否と保管場所を自社のルールに沿って決めてください。下書きに不要な個人情報を含めなければ、確認対象も整理しやすくなります。

短い問い合わせほど、受付担当者が意味を補いすぎないよう注意します。「これについて知りたいです」だけであれば、何を知りたいのかを確認する質問を返す候補にします。相手が実際に述べたこと、担当者が確認したこと、未確認のことを別々に記録すると、下書きに入り込んだ推測を見つけやすくなります。

手順2：受付情報を返信に使える形へ整理する

AIへ問い合わせ本文をそのまま渡すのではなく、返信を作るための入力欄に整理します。最低限、「質問」「確定している事実」「不足している情報」「参照すべき根拠」「案内してよい範囲」「次の行動」を用意します。これらはAIへの指示だけでなく、承認者が下書きと元の問い合わせを照合するときにも使います。

たとえば「来週の見学はできますか」という質問では、希望日、人数、対象サービス、受付方法、現在確認できている空き状況を分けます。空き状況を確認していないなら、「空いています」と書かせず、確認に必要な項目と連絡先を案内する下書きにします。未確認のことを空欄のまま残すのは、文章を未完成にするためではありません。確認が必要な箇所を明確にするためです。

分類に迷う問い合わせは、無理に一つへ決めません。「料金と契約が混ざっている」「苦情と通常質問が同時に届いている」など、担当者が変わる論点は分けて記録します。問い合わせの優先順位や担当範囲を整理する方法は、AIから有人対応・電話へつなぐ設計も参考になります。

手順3：AIに下書きを依頼するときの指示をそろえる

下書きを依頼するときは、自然な文章を求めるだけでは不十分です。返信の目的、使ってよい根拠、答えてはいけない内容、未確認情報の扱い、文体、相手に求める次の行動を一つの指示に含めます。担当者ごとに指示が変わると、同じ問い合わせでも確認箇所が変わるため、共通の入力テンプレートを作ります。

指示には、次のような条件を置きます。「入力された事実だけを使う」「根拠が見つからない内容は断定せず、確認が必要と表示する」「個別契約、返金、苦情、緊急性のある内容は有人確認の候補にする」「必要な確認質問を箇条書きで示す」「返信案と確認メモを分ける」といった条件です。これらは返信の正しさを確定するものではないため、後工程で必ず元資料と照合します。

返信文の例を用意する場合も、固有名詞や金額を固定文として埋め込まないようにします。変更される情報は、根拠の名称と確認日を入力欄に置き、下書きの中で確認が必要な箇所を明示します。AIに渡す文章量を増やすことより、確定情報と未確認情報を分けることが、承認者の確認作業に直結します。

手順4：生成された下書きと事実を照合する

下書きが自然な日本語でも、事実が正しいとは限りません。承認者は文章の読みやすさより先に、質問への答えがずれていないか、条件が抜けていないか、根拠にない情報が加わっていないかを確認します。特に数字、日付、対象者、適用条件、否定表現、連絡先は、元資料と一つずつ照合します。

確認は「正しいか」だけでなく、「この相手に今送ってよいか」という観点でも行います。公開情報に基づく案内でも、相手の契約状況や本人確認を前提とするなら、一般案内のまま送らない判断が必要です。機能、提供時期、料金、効果に関する情報を根拠で確認できない場合は、下書きに含めず、確認先を示す表現に置き換えます。

確認結果を承認者の記憶だけに残してはいけません。元の質問、下書き、参照資料、修正点、確認者、確認日を紐づけると、後から表現の理由を確認できます。会話ログを分類して改善へつなげる場合は、チャットボットの会話ログ分析方法も参考になります。

手順5：人による承認で送信可否を決める

承認者は、AIが書いた文章を採点する人ではありません。問い合わせに対する会社としての回答を確定する担当者です。受付担当、業務の確認担当、送信担当が同じ人になる場合もありますが、役割を分けられる場合は分けます。特に契約、返金、苦情、個人情報、専門的な判断を含む問い合わせは、担当部署の確認を通してから返信します。

承認の判定を「問題なし」「修正して送信」「追加確認」「有人対応へ引き継ぎ」「保留」に分けると、差し戻し理由を記録できます。担当者が迷った場合は送信を急がず、質問内容と未確認点を次の担当へ渡します。相手に同じ説明を何度も求めないため、受付情報、AIの下書き、案内済みの内容、未解決の点を一緒に共有します。

• 問題なし：根拠、条件、宛先、次の行動を確認できる
• 修正して送信：内容は確定しているが、表現や順序を直す
• 追加確認：相手または社内から不足情報を集める
• 有人対応へ引き継ぎ：個別判断、苦情、契約、緊急性がある
• 保留：正本や担当者が定まらず、送信条件を満たしていない

チャットボットの回答範囲、根拠、更新担当、有人対応への切り替え条件を運用表にまとめる方法は、チャットボット運用ルールの作り方で整理できます。下書き運用でも、送信を止める条件を先に表へ書いておくと、忙しい時間帯でも判断をそろえやすくなります。

手順6：承認済みの返信を送信し、送信後を確認する

送信工程では、承認済みの本文と宛先、返信先、添付ファイル、案内リンクを確認します。下書き作成と送信を同じ画面で行う場合でも、「承認済みか」「誰がいつ承認したか」を記録してから送信します。承認前の文面が混ざらないよう、版や更新日時も残します。

送信後は、返信が届いたかだけで完了にしません。追加質問が発生したか、担当者へ渡した後に処理できたか、案内したページや窓口が相手の次の行動につながったかを確認します。すぐに解決できない場合は、再連絡の担当者と確認時期を決め、送信した事実だけで処理済みと扱わないようにします。

手順7：ログを残し、次の改善へつなげる

AI下書きの運用では、送信件数だけを見ても改善点は分かりません。どの問い合わせで下書きが役立ったか、どこで人が修正したか、何が不足していたかを記録します。ログは担当者を評価するためだけでなく、回答の正本、受付項目、指示文、有人対応の境界を見直す材料になります。

記録項目は、問い合わせID、受付日時、分類、使用した根拠、下書きの判定、修正理由、承認者、送信日時、送信後の結果、次回対応を基本にします。問い合わせ本文を保存する期間や、個人情報を含めて保存するかどうかは、自社規程と利用サービスの条件を確認して決めてください。分析用には、氏名や連絡先を除いた分類情報だけを使う方法も検討できます。

改善は、誤りの影響と発生頻度を組み合わせて優先します。発生頻度が低くても影響が大きい誤案内には、対象範囲を狭める、承認者を追加する、送信前の確認項目を増やすなどの対応を先に行います。頻繁に修正する定型案内は、FAQや正本の更新、入力テンプレートの見直しで改善できるか確認します。修正後は同じ質問だけでなく、言い換えや条件違いでも再確認します。

週次や月次などの確認周期は、問い合わせ量、情報の変更頻度、担当者の体制に合わせて決めます。重要なのは周期を固定することではなく、料金や営業時間などの変更があったときにも見直しを始める条件を決めることです。改善内容、確認した質問、担当者、次回の確認日を一行で残すと、担当交代後も経緯を追えます。

問い合わせ対応をAIで下書きするときの運用チェックリスト

導入直後は、すべての問い合わせを対象にせず、根拠が明確で、承認者が確認しやすい種類から始めます。次の項目を一つの運用表にし、未決定の箇所を残したまま開始しないようにします。

1. 対象にする問い合わせと、対象外にする問い合わせを分類した
2. 受付時に残す事実、不足情報、個人情報の扱いを決めた
3. AIへ渡す入力項目と、下書きの出力形式を統一した
4. 根拠、数字、日付、条件、リンクを確認する担当を決めた
5. 契約、返金、苦情、専門判断、緊急相談の引き継ぎ先を決めた
6. 承認の判定、送信者、承認日時、修正理由を記録できるようにした
7. 送信後の結果と、次回改善へ回す条件を決めた

この表の空欄が多い場合は、AIへの指示文を工夫する前に、業務の境界を整理します。下書きは担当者の確認を補助する手段であり、事実確認や承認の責任を置き換えるものではありません。自社の問い合わせ分類、参照資料、有人対応の体制に合わせて、扱う範囲を調整します。

よくある質問

自社の返信下書き運用を整理する

問い合わせ対応の下書き運用は、文章を作る工程だけでなく、受付情報、根拠、承認、送信後の記録までそろえて初めて見直せます。まずは対象にする問い合わせを一種類に絞り、現在の受付項目と確認者を書き出してください。次に、対応範囲、有人対応へ切り替える条件、ナレッジの更新方法を運用表へ整理します。自社の業務に合う進め方をSocratesで確認したい場合は、導入相談をご利用ください。対応できる範囲や条件は、実際の業務内容をもとに個別に確認することが大切です。