問い合わせメールの
返信を生成AIで効率化回答案の作成と
二重返信を防ぐ仕組み

代表メールに届く問い合わせを複数人で処理すると、返信文を作る時間に加え、「誰が対応中か」の確認も必要になります。

問い合わせメールのAI活用では、FAQを探して返信案を作る作業と、担当・承認・送信状態の管理をつなぐと、窓口全体の対応を見直せます。

この記事は、共有メールの返信を効率化したい責任者向けです。

回答案を作る流れと、二重返信や古い下書きの送信を防ぐ設計例を紹介します。

架空メール6通で確認した、回答案・保留・同じ受信イベントの再配信判定も公開します。複数担当者の同時編集や実送信は、試験ではなく設計例として説明します。

検証日：2026年9月12日。文章生成と分類はCodexで実行し、実行モデルの名称・版は確認できていません。

入力は編集部が作成した完全な架空データです。Gmailや実際のメールサーバーには接続せず、外部送信も行っていません。

6通だけの試験で、実運用の精度、処理時間、費用、削減効果は評価していません。

この記事で分かること

• 複数人の同時返信は対応管理で、同じ受信イベントの再処理はIDの照合で防ぎます
• Gmailでは下書き作成と送信の両方を扱えるため、最初は送信せず下書きに止めます
• 人の承認なしで送る候補は、誤っても契約・金額・納期・安全へ影響しない定型回答に限ります

受付メールだけなら
生成AIは必要ない

全員へ同じ文面を返す受付通知は、問い合わせフォームの通常機能で十分です。

AIが必要になるのは、質問内容を読み、FAQや商品情報から回答案を変える場面です。

メールの件数が少なく、担当者がテンプレートを選ぶだけで処理できる場合は、既存のメール機能から始めます。

毎回FAQを探すなら回答案の生成、担当が分からないなら対応状態の共有、承認待ちが長いなら確認先と通知を見直します。

文章を作るAIだけを追加しても、担当者の重複や承認待ちは解消しません。

共有メールの受付・返信の流れ

回答案だけでなく、担当者と承認した文面を一つの問い合わせに紐付けます。

例えば「資料をください。来週中に届きますか？」と質問された場合を考えます。

以下は実装・実送信をしていない設計例です。

問い合わせ内容と
不足情報を確認する

受信メールのID、送信者、件名、本文を対応記録へ登録します。添付資料や過去のやり取りは、担当者が閲覧できる範囲だけを参照します。

商品名がなければ、AIは「どの商品の資料をご希望ですか」という確認案を作ります。納期がFAQにない場合は、来週届くと約束せず、担当者の確認事項に残す設計です。

FAQの出典付きで返信案を作る

AIへ渡す資料は、社内で回答に使ってよいと確認したFAQと商品資料に絞ります。下書きには返信文のほか、根拠のFAQ番号・版・該当箇所を付けます。

例えばFAQに「資料はPDFで送付」とあれば、その案内は作れます。配送日が書かれていなければ、文章の自然さを理由に補いません。

担当者が確定した
下書きだけを送る

担当者を一人決め、他の人には「対応中」と表示します。確認が必要な回答は承認者へ回し、送信前に宛先・添付・根拠と文面を確定します。

下書きの版を承認記録に残せば、承認後に別の人が書き換えた文面を、そのまま送らない仕組みにできます。送信時は対応状態も再確認します。

追加のメールが届いたら、
古い下書きを見直す

「商品AではなくBでした」と追加連絡が来たら、Aの資料を付けた旧案は送信対象から外します。AIの再生成だけでなく、人の確認もやり直す設計です。

送信失敗時も、結果不明なら即再送しません。メール側の送信履歴と対応記録を照合し、実際に届いた可能性があるメールを二重に送らないようにします。

二重返信を防ぐ
担当管理と受信IDの照合

複数人の同時返信は対応管理で、同じ受信イベントの再処理はIDの照合で防ぎます。

二人が同じ問い合わせを開き、それぞれ返信する問題は、AIの指示文では止められません。

担当の割り当てと、返信編集中に別の人が送れない制御が必要です。

メールディーラーの公式説明は、対応状態の共有と返信中の排他ロックを案内しています。利用中のツールにも同等の機能があるか確認する材料になります。

独自に連携する場合は、画面に「対応中」と表示するだけでは足りません。担当の取得と送信直前の確認を、同時処理でも一人だけが通る仕組みにします。

一方、連携サービスが同じメールを再通知する問題は、受信元のメールIDと処理記録で判断します。本文が同じでも、別の顧客から届いたメールは別件です。

以下の試験で確認したのは、この再配信の分類です。共有受信箱の編集ロックや、同時に送信操作した際の制御は検証していません。

架空メール6通で試した結果

修正後は、回答案2通、人に確認3通、重複のため返信不要1通に分かれました。

成功率を示す試験ではなく、どの条件で人へ戻すかを確認する小規模な動作確認です。

初回は最後の再配信を別件として「人に確認」にしました。

受信元が付けたメールIDと処理記録を照合する指示がなかったためです。

この結果から、受信イベントのIDを入力へ含める必要が分かりました。ただし、AIの出力だけで実システムの二重処理を防げるという検証ではありません。

公開CSVの担当者・下書き作成日時も、試験で生成した架空の記録です。メールシステムに下書きが保存された記録や、担当者が実際に確認した証拠ではありません。

再配信を見分けた
修正版プロンプト

受信元のメールIDと本文ハッシュを処理記録に残し、両方が一致した受信イベントだけを重複とします。

ただし、受信記録があるだけでは処理済みとは限りません。

処理中、下書き作成済み、送信済み、失敗、結果不明の状態を分け、失敗や結果不明のメールを自動で返信不要にしないようにします。

同じスレッドに届いた別のメールは、催促や条件追加かもしれません。

スレッドIDや件名だけで返信不要にしてはいけません。

同文面でもメールIDが異なる別顧客の問い合わせは、新しい問い合わせとして扱います。

本文ハッシュは同じ内容かを確かめる補助情報で、受付を捨てる基準にはしません。

以下は試験で使った指示文です。実運用では、受信IDの照合と処理状態の確認をプログラム側で行い、AIの分類結果に受付の重複防止を任せません。

あなたは企業の問い合わせメールの回答案を作る担当です。
空の処理記録から始めます。添付したFAQと受信メールを受信時刻順に読み、各行の判定後に処理記録へ追記してください。各メールを「回答案を作成」「人に確認」「重複のため返信不要」のいずれかに分類してください。

判定ルール：
- FAQに書かれていない内容を推測しない。
- 返金、値引き、特注品、支払条件の変更は必ず「人に確認」にする。
- 注文内容や配送先などの情報は、本人確認と閲覧権限を確認できない限り「人に確認」にする。
- provider_message_idと本文ハッシュが、すでに処理記録にある受信イベントと両方一致する場合だけ「重複のため返信不要」にする。
- 同じthread_idでもprovider_message_idが異なるメールは重複にしない。催促、新しい質問、条件追加として必ず「人に確認」にする。
- 「回答案を作成」では根拠となるFAQ番号と返信文を書く。
- 「人に確認」では不足情報または担当者が判断する内容を書く。
- 処理記録にはdelivery_id、provider_message_id、thread_id、本文ハッシュ、処理状態、担当者、下書き作成日時、送信日時、duplicate_ofを残す。
- JSON配列で返す。

重複判定だけは、同じイベントの再配信、未処理中の催促、返信後の同じ質問、新しい条件の追加も別に確認しました。

期待する判定と実際の判定を公開CSVで照合し、返信不要にしたのは外部メールIDが同じ再配信だけです。

ほかの3件は、新しいメールを消さず人へ戻しました。

架空データと初回・修正後の出力を確認する

• 架空のFAQ
• 架空の問い合わせメール6通
• 初回の指示文
• 重複を見分けられなかった初回出力
• 修正した指示文
• 修正後の出力
• 修正後の処理記録
• 重複判定の追加ケース

同じ指示文でも、使うAIや設定によって結果は変わります。

自社のFAQに置き換える前に、実在する個人名・メールアドレス・注文番号を含まない架空データで試し、正解を人が用意して比較してください。

今のメール環境と
対応管理ツールを比べる

Gmailでは下書き作成と送信の両方を扱えるため、最初は送信せず下書きに止めます。

Google Apps ScriptのGmailサービスには、メールの検索、下書き、ラベル、送信を扱う機能があります。

Gmailの本文へアクセスする方法は権限が広いため、利用者と対象メールボックスを絞る必要があります。

Googleは2026年9月2日、Workspace Studioに「Reply to email」を追加すると公式ブログで発表しました。

受信メールを起点にGeminiへ質問し、既存スレッドへ返信する流れを画面上で作れるため、対象プランと管理者設定が合えば最初の候補になります。

Gmail向け機能の展開開始は9月14日と案内されており、本記事の検証日には実アカウントで試していません。

Workspace Studioの公式ヘルプには、受信メールを起点に、GeminiへFAQ資料を参照させて回答案を作り、下書きへ保存する例があります。

一方、利用できる機能や承認はアカウントと管理者の設定で変わります。

複数人の承認、独自の顧客台帳、複雑な重複防止が必要なら、Apps Scriptや既製の問い合わせ管理ツール、専用連携を比較します。

共有メールや委任されたメールボックスで同じ機能を使えるかは、本記事では確認していません。

利用中のプラン、管理者設定、対象メールボックスで、読み取り、下書き、承認、送信を一つずつ確かめてください。

Google公式のGmailサービスでは、`createDraft`で下書きを作り、下書きから送信できると案内しています。

GmailAppの権限説明では、対象メソッドにGmail全体へアクセスする権限が必要です。

自動処理用アカウントを分けるか、既製ツールを使うかも含めて判断します。

Apps Scriptにはメールの読み書きや送信、実行時間などの上限があります。

上限はアカウント種別で異なり、変更される場合があります。

固定値を設計へ埋め込まず、運用開始時にGoogle公式の最新クォータと実行履歴を確認してください。

自動送信へ進める条件

人の承認なしで送る候補は、誤っても契約・金額・納期・安全へ影響しない定型回答に限ります。

例えば営業時間や公開済みの添付条件です。

それでも、FAQの更新後やシステム変更後は再試験します。

一方、苦情、解約、返金、値引き、在庫、納期、個別契約、個人情報の訂正は担当者へ戻します。

AIが文章を自然に書けることと、会社として回答してよいことは別です。

回答の根拠が見つからない場合も、もっともらしい文章を作らず保留します。

送信まで自動化する前に、自動返信どうしのループ、処理の再実行、送信失敗、承認後の内容変更を試します。

失敗したときは自動送信を止め、下書きと処理記録を残して担当者へ戻せる状態にします。

社内問い合わせのAI化では、資料の権限と回答根拠の考え方を解説しています。

対象業務を決めるところから始める場合は、AI導入の進め方も参考になります。

一つの窓口で
返信作成と確認の負担を比べる

AIが作った案の数ではなく、確認を含めた対応時間と、未対応が残る理由を見ます。

対象窓口を一つ選び、匿名化した質問の傾向から、FAQで回答できるものと個別判断が必要なものを分けてください。試験用メールは実在の顧客情報を含まない形で用意します。

次に、送信を止めた状態で、根拠を探す時間、下書きの修正、担当者の確認を記録します。

AIが即座に生成しても確認が増えるなら、回答資料か対象質問を見直す必要があります。

弊社は、返信案の生成だけを先に導入するより、問い合わせごとの担当と送信履歴を確認できる形を優先します。既存の共有管理で足りる場合は、その機能を残す方針です。

顧客台帳の照会や独自の承認が必要になった時点で、専用連携との違いを比較できます。相談時はメール本文ではなく、窓口・担当人数・今の確認方法を伝えれば、見直す範囲を整理できます。