宛先・添付・送信時刻を本文から分ける、AIメールの「送信封筒」

営業フォローの本文をAIに書かせても、宛先や添付まで同じ出力に任せると、文章の正しさだけでは安全を判断できません。本稿では、業務自動化の責任者が翌日から使える「送信封筒」と、下書きから送信までの5段階を示します。

本文と「送る条件」を別の成果物にする

メール自動化では、AIの役割を本文と件名の候補作成までに絞ります。宛先はCRMや社員名簿のIDから決定し、添付は保管庫のファイルIDで固定します。送信時刻、承認者、再実行を識別するキーも、本文とは別の構造化データにします。

OpenAIのStructured Outputsは、モデル出力を指定したJSON Schemaに従わせます。ただし内容の誤りは残るため、値は業務システム側で検証します。[1] 外部操作は自動検証と人の承認を組み合わせ、高リスクな実行をツール呼び出し前に止めます。[2]

この実行条件を「送信封筒」と呼びます。コピーして使える最小形は次の通りです。

send_envelope:
  request_id: MAIL-20261009-001
  purpose: 契約更新の案内
  sender_account: sales@company.example
  to_refs: [crm_contact_id:C-1842]
  cc_refs: []
  recipient_policy: external
  attachment_ids: [quote:Q-733-v3]
  attachment_hashes: [sha256:...]
  contains_personal_data: false
  send_after: 2026-10-09T15:00:00+09:00
  expires_at: 2026-10-10T15:00:00+09:00
  mode: approve
  approver_role: sales_manager
  idempotency_key: renewal-C-1842-202610

5段階で下書きから送信へ進める

Gmail APIでは、下書きの作成と送信は別の操作です。drafts.createで未送信の下書きを作り、drafts.sendで明示的に送信できます。下書きを送ると、その下書きは削除され、送信済みメッセージが新しいIDで作られます。[3] この境界をそのまま業務の承認点に使います。

1. 本文を作る：AIは件名、本文、目的、想定する受信者の役割だけを返します。メールアドレスやファイルパスは返させません。
2. 実体を解決する：業務システムが受信者の役割から有効な連絡先IDを引き、送信元の許可リストと照合します。
3. 封筒を凍結する：宛先、添付IDとハッシュ、送信可能時間、失効時刻を記録します。どれかが変われば既存の承認を無効にします。
4. 下書きを確認する：下書きを作成し、宛先ドメイン、To／Cc／Bcc、添付名と件数、本文のプレビューを同じ画面に並べます。
5. 一度だけ送る：承認後、失効時刻とハッシュを再検証し、同じidempotency_keyの送信記録がなければ実行します。送信結果のメッセージIDを封筒へ戻します。

完了条件は「メールが送れた」ではありません。承認時と送信直前の宛先・添付が一致し、送信記録が一件だけ残る状態です。

例：契約更新メールで旧担当者を除外する

たとえば、営業担当者が「A社へ更新見積を送って」と依頼する場面を考えます。CRMには現担当者と異動済み担当者が残っています。AIが氏名から宛先を推測する方式では、どちらを選ぶかを文章生成に混ぜてしまいます。

送信封筒では、まず契約IDから「現在有効な契約窓口」という役割を検索します。次に見積書v3のファイルIDとハッシュを固定します。外部宛てかつ添付ありなのでmode: approveとし、営業責任者へ回します。承認後にCRMの担当者が変更された場合は、宛先IDの差分で承認を失効させ、新しい封筒を作ります。

出力は「どの連絡先・どの版の添付・どの承認で送ったか」を再現できる記録です。本文を直しても封筒が同じなら承認は維持し、宛先や添付が変われば再承認します。

失敗モードをルーティング表にする

条件	動作
社内宛て・添付なし・定型通知	下書き。許可済みの通知だけ自動送信候補
外部宛て、または添付あり	人の承認
個人情報を含む、Bcc、Reply-all	必ず承認し、受信者一覧を展開表示
宛先を一意に解決できない	ブロック
添付ハッシュ変更、封筒失効	承認を破棄して再作成
同じ冪等キーの送信記録あり	再送せず、既存結果を返す

本文の生成品質だけを上げても、宛先展開、添付差し替え、再試行による二重送信は止まりません。承認画面に本文だけを出すのも不十分です。人が見るべきなのは、外部影響を決める封筒全体です。

なお、法令・契約上の通知を大量配信し、配信停止、到達管理、再送制御を専用基盤で扱うという場合には向きません。その場合は送信封筒を専用配信基盤への投入承認に使い、配送自体は基盤へ任せます。

明日から使える実装チェックリスト

• [ ] AIの出力からメールアドレスとファイルパスを外した
• [ ] 宛先を業務レコードのIDから解決している
• [ ] 添付IDとハッシュを承認時に保存している
• [ ] 外部宛て、添付、Bcc、Reply-allの承認規則がある
• [ ] 下書き作成と送信を別の権限・操作にしている
• [ ] 宛先または添付の変更で承認が失効する
• [ ] 冪等キーで二重送信を防いでいる
• [ ] 送信結果と承認者を同じ記録へ戻している

まず一つの自動メールを選び、本文生成の後ろにこの封筒を置いてください。最初の合格ラインは自動送信率ではなく、「変更された宛先や添付を、送信前に確実に止められること」です。

参考資料

1. OpenAI — Structured model outputs
2. OpenAI — Guardrails and human review
3. Google for Developers — Create and send draft emails

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-09。