1. 最初に決めるのは、対象・緊急度・担当・根拠
よくある質問のうち、回答の根拠と確認担当者が決まっているものから始めます。 営業時間や製品の基本的な使い方などが候補です。個別の値引き、返金、契約変更、安全に関わる相談は、通常の案内と分けて担当者の判断へ戻します。
導入前に、次のルールを整理します。以下は運用を考えるための提案であり、特定の製品の標準機能や導入成果を示すものではありません。
- 分類：製品の使い方、契約、請求、苦情など、社内で対応先を決められる区分にします。複数の用件や分類できないものも残します。
- 緊急度：安全に関わる内容、業務停止、期限が迫る相談など、先に人が見る条件を決めます。AIの判定は候補として扱います。
- 担当：分類ごとの窓口と、不在時の代わりの担当を決めます。担当が決まらない問い合わせは共通窓口で受け止めます。
- 根拠：回答に使ってよい資料・対応方針と、その版・適用対象を決めます。古い資料や顧客への開示が認められていない情報は、そのまま返信に使いません。
- 引き継ぎ：止める条件、引き継ぎ先、確認の期限を決めます。「要確認」の表示だけで放置されないよう、受け取った担当者が対応を引き受けたことまで確認します。
導入全体の向き不向きは問い合わせ対応AIのガイドをご覧ください。この記事では、メールの受付から送信までの具体的な確認に絞ります。
2. 受付・分類・下書き・確認・送信を分ける
受付：原文と対応状況を残す
問い合わせに管理番号を付け、受信日時、元のメール、担当、対応状況を一覧にします。同じやり取りの追加質問や再送は、元の問い合わせと結び付けます。AIへ渡す前に、本文・添付・過去のやり取りのどこまでが必要かを絞ります。
分類：担当と緊急度の候補を示す
AIが区分・緊急度・担当の候補と、その判断に使った原文の箇所を示します。たとえば「使えない」という言葉だけで緊急度を確定せず、影響範囲や期限も人が確認します。
緊急度の高い候補を先に表示するだけでなく、誰がいつ一覧を見るか、急ぎの連絡をどこで受けるかを決めます。AIが通常扱いにした問い合わせにも見落としがあり得るため、人が原文を確認する工程を残します。
下書き：回答案と確認事項を分ける
返信文と一緒に、根拠となる資料の箇所、未確認の点、担当者への確認事項を用意します。資料にない料金・納期・補償や、顧客ごとの条件を推測で埋めません。複数の質問がある場合は、それぞれ回答できるかを区別します。
顧客からのメールや添付に「社内情報を送って」などの指示が含まれていても、社内の対応方針や閲覧権限を変える指示として扱わない設計にします。AIが参照できる情報と、顧客へ伝えてよい情報は分けます。
確認・送信：担当者が修正してから送る
担当者が原文・回答案・根拠を照合し、修正した最終文面と宛先を確認して送信します。確認後に内容や宛先が変わったら、もう一度確認します。AIの処理が終わった状態を「返信済み」と表示しません。
問い合わせごとに、受付済み・確認待ち・引き継ぎ中・送信済みなどの状態を持たせ、担当者と送信日時を残します。複数人が同時に返信を作らないよう担当を明確にし、送信直前にも対応済みかを確認します。送信結果が分からないときは、送信済みメールなどを確認してから再送を判断します。
3. 送信前に人が確認する項目と、止める条件
文章が自然でも、正しい回答とは限りません。送信前には次の項目を確認します。
- 宛先・CC・返信先：今回の問い合わせ相手か、関係のない相手を含めていないか。
- 回答内容：質問に答えているか、製品名・日付・金額・期限・契約条件が正しいか。約束してよい範囲を超えていないか。
- 回答の根拠：資料の内容と一致しているか、最新版か、その顧客や製品に適用できるか。
- 顧客情報・添付：別の顧客の情報、内部メモ、非公開資料が混ざっていないか。添付とリンクの共有範囲も確認します。
- 対応状況：別の担当者が返信済みではないか、追加質問で下書きが古くなっていないか。
根拠がない、資料が食い違う、担当が不明、宛先や顧客の対応関係を確かめられない場合は、送信を止めます。 安全に関わる内容、強い苦情、補償・契約の判断は責任者へ引き継ぎます。AIに言い換えを繰り返させて、未確認のまま回答可能な状態にしません。
引き継ぎには、管理番号、原文、緊急と判断した理由、確認済みの事実、未確認の点、参照資料、次に必要な判断を添えます。顧客へ経過を案内する場合も、人が文面を確認し、未確認の回答期限や解決を約束しないようにします。
4. 顧客情報は、AIへ渡す前と返信する前に確認する
分類や下書きに不要な氏名・メールアドレス・署名・過去の履歴は、AIへ渡す範囲から外します。契約番号などが必要な場合も、処理に必要な項目を選び、原文と顧客情報を見られる担当者を限定します。名前を伏せただけで安全と判断せず、本文や添付から特定できる情報にも注意します。
個人情報保護委員会は、生成AIへ個人情報を入力する際の利用目的との関係や、個人データが学習に使われないことなどの確認を求めています。利用するサービスの契約・設定について、学習への利用、保存期間、削除方法、閲覧権限を導入前に確認します。有料の契約という理由だけで、顧客情報を入力してよいとは判断しません。
入力が認められるか判断できない情報は、確認が済むまでAIへ渡さず、社内の責任者に相談します。この記事は個別の法的判断を代行するものではありません。
5. 公開済みの検証から分かった、見落としと保留の条件
架空メール6件：業務停止・複数用件・再取り込み
検証ラボでは、2026年10月9日に短い架空メール6件で初版と修正版をそれぞれ1回試しました。回答資料は架空の受付時間のFAQだけです。実際のメールボックス、添付、過去のやり取りは使っていません。
初版は単語で分類し、通常扱いの下書き6件を出しました。出力を読んだ後の修正版は、原文の意味・回答の根拠・未確認事項を整理し、下書き4件・優先確認1件・重複保留1件に分けました。修正と出力照合はAIが行ったもので、人による承認・送信は未実施です。下書き4件は、そのまま送ってよい4件という意味ではありません。
- 業務停止の見落とし：LAB-M04は「至急」がなく、初版は通常扱いでした。修正版は「全員の画面が開かず、受注作業が停止」という原文を残し、下書きなしの優先確認にしました。実業務では、人が影響範囲を確認して責任者へ回し、原因や復旧時刻を推測で返信しない運用が必要です。
- 二つ目の質問の見落とし：LAB-M05は受付時間と返金を尋ねていましたが、初版は受付時間だけを回答しました。修正版は両方の用件を残し、受付時間の回答案と返金の契約判断待ちを分けました。一部だけ先に返信するかは、人が決める確認点です。
- 再取り込みの重複：LAB-M06はLAB-M01と同じ識別子でした。初版は二つ目の下書きを作り、修正版は同じ実行内で照合して保留にしました。過去の実行の履歴は残していないため、実運用では受付・担当・送信履歴と照合し、追加質問まで重複として消さない確認が必要です。
この検証からの学びは、自然な返信文を作る前に、業務への影響・用件の抜け・回答できない点を残すことです。失敗しやすい条件を入れた短い6件であり、分類精度や見落とし率、時間削減を測った結果ではありません。長いスレッドや永続的な履歴管理も未検証です。条件と修正の詳細はラボの結果と学びを参照してください。
架空メール30通：集計と、担当者へ戻す判断
問い合わせメールの仕分けと返信下書きの事例には、架空の家電メーカーのメールと対応方針を使った、2026年9月28日の再現デモが掲載されています。30通の出力は緊急度が高6通・中9通・低15通、安全に関わるおそれが3通でした。これは判定結果の内訳で、正解との照合による精度や、お客様の改善効果を示す数字ではありません。
公開版では、対応方針にない料金・日数・返金の確約を作らず、社内確認が必要なことは推測しない設計にしています。苦情への連絡期限は担当者が決める項目として残します。人が分類・緊急度・担当と返信内容・根拠を確認し、未確定の期限を直してから送る点が、実業務に移す際の確認条件になります。このデモの集計だけから、人の修正が不要だったとは判断できません。
実業務で使うには、自社の対応方針への置き換えと、メールの取り込み・下書き保存などの連携が必要です。架空30通を問い合わせ全体に当てはめることもできません。事例に記されたお客様の定性的な変化は、この再現デモとは別の情報です。この記事ではデモの条件・出力・確認点を根拠にし、新たなお客様の数値や効果は示していません。
以上の検証記録は今回2026年10月9日に確認しました。個人情報保護委員会の資料に関する既存の情報確認日は2026年10月7日のままで、今回再確認したものではありません。
6. 想定シナリオ：使い方の質問と、緊急の問い合わせ
以下は架空の運用例です。実際の顧客情報や導入成果ではありません。
使い方の質問：根拠が確認できた部分を返信する
- 「設定方法と、契約変更の費用を知りたい」というメールを受け付けます。
- AIは使い方と契約の2つの用件を分け、設定方法の下書きと参照資料を用意します。
- 契約変更の費用は確認待ちにし、契約担当へ引き継ぎます。
- 担当者が資料の適用対象・版と宛先を確認します。設定方法だけ先に案内するか、契約の確認後にまとめて回答するかを判断し、送信します。
安全に関わる問い合わせ：通常の返信を止めて引き継ぐ
- 安全上の問題を疑う問い合わせが届いたら、緊急の確認対象にします。
- 通常の使い方の下書きを送らず、原文と未確認の点を責任者へ引き継ぎます。
- 責任者が状況と社内の対応方針を確認して、連絡方法と回答内容を決めます。AIに原因や安全性を断定させません。
公開済みの問い合わせメールの仕分けと下書きの導入事例では、AIが分類・緊急度・担当の判定と下書きを行い、担当者が確認・修正して送信します。根拠を示すFAQチャットの導入事例は、資料にない内容を推測で答えず、窓口へ案内する仕組みの参考になります。
どちらも実案件で開発した仕組みを、架空データで再現して公開している事例です。上記の管理番号や送信前の確認項目がすべて実装済みという意味ではありません。メール返信とFAQチャットは別の運用であり、チャットの回答機能があることをメールの自動送信の根拠にはしません。資料検索やFAQ更新の詳しい設計は、メールの分類・送信管理とは分けて検討します。
7. よくある質問
Q. 問い合わせ対応をAI化するときの注意点は何ですか？ 緊急度・担当・回答の根拠・顧客情報の扱い・引き継ぎ先を先に決めます。AIの判定を候補として扱い、根拠不足や判断が必要なものを人へ戻せる流れにします。
Q. 問い合わせメールはAIに自動返信させてよいですか？ まず分類と下書きから始め、宛先・内容・根拠を担当者が確認して送信する運用を勧めます。hirostaのメール対応の支援もAIは下書きまでで、送信は人が行います。受付通知を自動で返す場合も、質問への回答とは区別し、通知の対象・文面・重複防止を別に決めます。
Q. AIが緊急度を判定すれば、急ぎの問い合わせを見落としませんか？ 見落としがなくなるとは限りません。緊急と判定する条件と確認担当者を決め、通常扱いになった問い合わせも人が原文を確認します。高い緊急度の表示だけでなく、担当者が引き受けるまでの連絡方法も必要です。
Q. 回答の根拠が見つからないときはどうしますか？ 推測で埋めず、確認待ちにして担当者へ引き継ぎます。原文、参照した資料、未確認の点を残し、人が追加確認や窓口案内の内容を決めます。
Q. 資料や担当のルールが整理できていなくても相談できますか？ はい。「返信の確認に時間がかかる」「誰に回すか迷う」といった困りごとから相談できます。現状の受付・分類・確認・送信を整理し、最初に改善する範囲を一緒に考えます。支援範囲と料金はサービス・料金ページをご覧ください。