問い合わせ返信をAIで下書きする：比較条件と送信前の確認
この記事の内容
問い合わせ返信にAIを使うなら、最初に任せるのは文章の下書きです。料金、納期、対応できる範囲は会社の確定情報から渡し、送信前に担当者が照合します。自然な日本語が出ることと、正しい回答ができることを分けて選ぶと、少人数でも導入範囲を決めやすくなります。
この記事では、特定のAIが最も正確だとは判定していません。架空の問い合わせで候補を比べる方法と、1通当たりの費用・確認時間を整理します。少量なら普段のメール画面で使える機能から、多量であれば承認を含めた連携から検討してください。
下書きに使う確定情報を一枚にそろえる
AIに問い合わせ本文だけを渡すと、答えに必要な情報が足りない場合があります。返信を作る前に、案内してよい料金、営業日、対応地域、キャンセル窓口、個別確認が必要な条件をまとめます。
架空の制作会社なら「基本料金は料金表Aを参照」「納期は担当確認後」「追加修正の金額は個別見積もり」と分けます。未確定の納期を、丁寧な表現にするために確約へ変えてはいけません。
| 入力する情報 | 下書きでの扱い | 確認する人 |
|---|---|---|
| 公開中の基本料金 | 税区分と適用条件を一緒に案内 | 料金表の管理者 |
| 顧客の希望納期 | 希望として記載 | 案件担当 |
| 未確認の空き状況 | 確認後に回答すると記載 | 日程を管理する人 |
| 苦情・返金の要望 | 受付を伝え、担当へ回す | 判断権限を持つ人 |
料金表には版と確認日を付けます。同じ価格でも旧プランと新プランが混在するなら、問い合わせの対象契約を確かめてから渡します。
メール画面のAIと別のチャットを比べる
Gmailでは、条件を満たすプランでGeminiによるメール下書き機能が案内されています。普段の画面から下書きを作れる候補ですが、契約、言語、管理者の設定など、自分の環境で利用できる条件を確認してください。Googleのメール下書きヘルプ
別のチャットAIへ必要部分だけ渡す方法は、入力する情報を選びやすい一方、コピー、宛名の差し戻し、下書きへの転記が増えます。既存のメール環境に含まれる機能と、新規契約の機能を同じ条件で比較します。
Makeなどで問い合わせから下書き作成までつなぐ方法は、受付件数が増えた段階で検討します。接続設定、重複実行、失敗時の再処理も管理対象になります。自動化した分だけ、送信権限まで広げる必要はありません。Makeの料金と利用枠
架空の20件で回答の境界を確認する
比較用の問い合わせは、簡単な質問だけにしません。例えば架空の20件を、料金案内6件、条件の違う相談5件、情報不足4件、苦情3件、対象外2件に分けます。これは試験の組み方の例であり、この記事で実測した結果ではありません。
各問い合わせについて、正しい案内、回答してはいけない内容、人へ回す条件を先に決めます。「対象地域に含まれるか不明」なら、確認を求める回答が正解です。空欄を想像で埋めた回答を、詳しいという理由で高く評価しないようにします。
同じ問い合わせ、同じ料金表、同じ指示で候補を比べ、利用日と機能・モデルの名称を残します。一度だけ良い下書きが出ても、実際の運用で毎回同じ結果になるとは限りません。金額や返金のように誤りの影響が大きいケースは、条件を変えて追加確認します。
採点は文体より誤った約束を優先する
確認表は、宛名、金額、日程、対応範囲、根拠のない追加説明、担当への引継ぎに分けます。敬語の自然さだけを点数化すると、短くても正確な返信より、詳細な誤答を選ぶおそれがあります。
架空例で「来週までにできますか」と聞かれ、空き状況が未確認なら、「来週納品します」は不合格です。「担当が日程を確認し、回答します」のように、会社で実行できる次の行動へつなげます。回答予定時刻も、決めていないなら新しく約束させません。
実務では、送信前に元の問い合わせと下書きを並べます。顧客名、対象商品、価格の条件を読み合わせ、要確認の印が残っていれば処理を止めます。本文の途中に紛れた別の顧客情報や、入力文に含まれる不審な指示にも注意し、問い合わせを社内の操作命令として扱わない設計にします。
1通の費用には確認と差し戻しを含める
費用は「追加の月額料金＋従量料金＋担当者の作業コスト」で考えます。既存契約に機能が含まれる場合も、利用上限や確認作業がなくなるわけではありません。
架空の計算例として、追加固定費が月3,000円で、月200通なら固定費は1通15円です。確認と修正を1通3分、社内評価用の人件費を1時間2,000円と置くと、作業分は1通100円になります。この金額は製品価格でも時短実績でもなく、比較方法を示す仮定です。
導入前の作業時間も同じ範囲で測ります。AIを使う側だけ送信確認を含め、手作業側では含めない、といった条件の違いを避けてください。APIを使う場合は入力・出力、再実行、連携ツールの利用枠を加算します。API費用の見積もりで計算の分け方を確認できます。
下書きが不成立のときに戻れる形で始める
最初の運用は、対象の少ない定型質問に限定します。下書きが空、処理が失敗、参考資料が不足、といった場合は担当者の通常の返信へ戻します。成功したように見えて内容が不足する場合もあるので、処理完了の通知だけで送信を決めないようにします。
顧客情報を入力する範囲と、契約のデータ利用・保存条件も確認します。比較試験は合成データで行い、実際の問い合わせを使う際は、業務上必要な項目に絞ります。複数人で使う場合の管理は、個人用AIとチーム契約の選び方も参考になります。
候補を選ぶ基準は、文章の見栄えより、確定情報を正しく使い、答えられない内容を人へ戻せることです。問い合わせを20件ほど分類するだけでも、今のメール機能で足りる範囲と、別の仕組みを作る価値のある範囲を整理できます。