メール返信の自動化は、最初に返信案だけを作り、宛先と内容を確認してから送る構成にします。入力メールの文章を、そのまま送信先や実行許可の指示として扱わないようにします。
返信案へ必要な情報だけを渡す
元メールのID、相手からの質問、確認済みの回答材料を用意します。会社として確定していない納期や金額を、AIにそれらしく補ってもらう構成にはしません。不明な点は質問へ戻すか、人の確認へ送ります。
返信案の依頼例
確認済みの情報だけで返信案を作成する。
未確定の納期や金額は断定しない。
不足する情報は「担当者へ確認する項目」として別に示す。
送信は行わず、本文案だけを返す。
返信案の言い回しは、AIでメールを作る方法へ分担します。ここでは送信に至る処理と確認を扱います。
GmailのDraftで、本文を確認できる状態にする
GmailノードにはDraftの作成・取得などの操作があります。対応する操作は公式Gmailノードで確認できます。試験用アカウントへ下書きを作り、保存された本文と件名を読むところから始めます。
新規のメール案と、元スレッドへの返信案を区別します。スレッドの参照、宛先、Reply-to、CC/BCCは入力の本文だけから決めず、元メールの項目と運用ルールから照合してください。
承認するのは、宛先を含めた特定の版
| 送信前に見るもの | 確認内容 |
|---|---|
| 宛先 | 返信先、CC/BCC、全員返信の必要性 |
| 本文 | 質問への回答、未確定の約束、添付 |
| 対象の版 | 確認後に書き換えられていないか |
| 送信記録 | 同じ元メールへ送信済みではないか |
下書きを直した後は、新しい版が承認対象です。古い承認結果で更新後の本文を送らないようにします。
送信に失敗した表示でも、再送前に照合する
通信が途切れた場合、送信済みなのに結果を受け取れなかった可能性があります。元メールID、下書きID、送信結果IDを記録し、相手側や送信済みフォルダを確認してから再開します。
まず架空の入力と自分宛ての下書きで、却下・本文変更・同じIDの再実行を試してください。判断の記録は承認フローへ分けます。