メール自動返信のAI活用
回答案・保留・重複防止を
架空メール6通で試験

問い合わせメールへの返信にAIを使うなら、最初から送信まで任せるのではなく、FAQに根拠がある回答案だけを作り、人が承認して送るところから始めます。営業時間や添付条件には答えられても、値引き率や納期をAIが勝手に約束してはいけません。

本記事では、架空のFAQと問い合わせメール6通を使い、回答案の作成、担当者への保留、重複返信の防止を試しました。初回に重複メールを見分けられなかった失敗と、修正した指示文も全文公開します。

試した範囲は文章の分類と処理記録への書き出しです。Gmailへの接続、下書き保存、人の承認、外部送信は実行していません。

検証日：2026年9月12日。文章生成と分類はCodexで実行し、実行モデルの名称・版は確認できていません。Gmailや実際のメールサーバーには接続せず、外部送信も行っていません。入力は編集部が作成した完全な架空データです。6通だけの試験で、実運用の精度、処理時間、費用、削減効果は評価していません。

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

全員へ同じ文面を返す受付通知は、問い合わせフォームの通常機能で十分です。 AIが必要になるのは、質問内容を読み、FAQや商品情報から回答案を変える場面です。

メールの件数が少なく、担当者がテンプレートを選ぶだけで処理できる場合は、既存のメール機能から始めます。毎回FAQを探す、複数人で同じ問い合わせを開く、回答の承認待ちが分からないといった問題が出てから、自動化する範囲を広げます。

回答案を作ってから人が承認する

安全な最初の形は「受信→FAQ照合→回答案→人の承認→送信」です。 FAQに根拠がないメールは回答案を作らず、担当者へ戻します。

実装では、各メールに「回答案」「根拠にしたFAQ」「保留理由」「処理したスレッド」を残します。担当者は文章だけでなく、根拠と約束の有無を確認できます。自動送信を検討する場合も、まず承認された質問だけに範囲を絞ります。

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

修正後は、回答案2通、人に確認3通、重複のため返信不要1通に分かれました。 成功率を示す試験ではなく、どの条件で人へ戻すかを確認する小規模な動作確認です。

初回は最後の再配信を別件として「人に確認」にしました。受信元が付けたメールIDと処理記録を照合する指示がなかったためです。実際の運用で同じ受信イベントが再実行されると、複数の担当者が二重に処理する可能性があります。

重複返信を防ぐ指示文

受信元のメールIDと本文ハッシュを処理記録に残し、両方が一致した受信イベントだけを重複とします。 同じスレッドに届いた別のメールは、催促や条件追加かもしれません。スレッドIDや件名だけで返信不要にしてはいけません。

あなたは企業の問い合わせメールの回答案を作る担当です。
空の処理記録から始めます。添付した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とつなぐ前に確認すること

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導入の進め方も参考になります。

メール自動返信を小さく試す

最初の一歩は、過去メールではなく架空の6〜10通で、回答・保留・重複の正解を決めることです。 次に送信を止めた下書き運用で、根拠、文章、宛先、重複を担当者が確認します。

定型の受付通知で足りるなら、AI連携を作る必要はありません。FAQ検索や承認待ちが毎日の負担になっている場合は、メール、FAQ、担当者、対応記録をつなぐ範囲を整理します。まるっとAIでは、現在の運用を確認し、既存機能で足りる部分と専用の仕組みが必要な部分を分けて設計します。