- 公開日
AIにメール送信を任せるときは、宛先を実際の送信先へ確定し、本文・添付・送信元を一組にして承認します。承認後に宛先や添付が変わったら送信を止め、送信結果が不明なら同じメールをすぐに再送せず照会します。宛先の確認、承認内容の固定、結果の照会を、送信ツールの前後につなげて設計します。
送信全般の役割分担（プロンプトでの指示、システムによる強制、人間の承認）は「AIの送信をどう制御する？ 指示・システムの強制・人間承認の役割」で扱います。この記事では、宛先の取り違えや添付の版など、メール送信に特有の失敗に絞って確認点を整理します。
下書きの完成と、送信の許可を分ける
「メールを書いて」という依頼で下書きができたことと、それを送ってよいことは別に扱います。メールは、別会社の同名担当者へ届いたり、社内コメントの残る資料を添付したりすると、文章の修正だけでは戻せません。送信権限を持つ接続があることも、個別の一通を送る承認の代わりにはなりません。
OWASPのLLM06:2025 Excessive Agencyが示すように、機能・権限・自律性は必要な範囲へ絞ります。メールでは、AIに全メールボックスからの送信を一括で許す前に、担当業務で使う送信元と宛先の範囲を決めます。宛先が決まるまでは本文の準備だけを進め、送信は保留します。
表示名から、正しい送信先へたどる
「山田さんに送って」という名前は、宛先の候補を探す入口です。正式な送信先を確定する際は、所属会社、担当案件、連絡先の記録、確認済みのやり取りを照合します。表示名や検索順位が一致しただけで一人に決めず、異動や連絡先変更の情報があれば更新状況も確認します。
以下は架空の営業業務です。実在の顧客情報やメールシステムは使わず、送信もしません。元の依頼は「山田健さんに打合せ資料を送ってください」で、連絡先には二人の同名顧客がいるとします。
| 候補 | 案件との対応 | 記録されている送信先 |
|---|---|---|
| 青葉設備の山田健さん、顧客C-17 | 設備更新の打合せ | yamada@aoba.example |
| 青葉商事の山田健さん、顧客C-71 | 販売企画の打合せ | yamada@shoji.example |
依頼にある「打合せ」だけでは、どちらの案件か決まりません。この時点では送信せず、依頼者へ「青葉設備の設備更新案件と、青葉商事の販売企画案件のどちらですか」と確認します。例では「青葉設備の設備更新案件」と回答があり、登録済みの案件記録と照合できた場合にC-17の送信先を選ぶ設計です。ドメインの見た目だけで本人性まで確認できたとはしません。
Toだけでなく、CcとBccも確定します。「前回と同じ宛先」なら参照する前回のメールを特定し、全員返信で増える人も表示します。グループ宛先では展開先や管理範囲が判断材料になるため、必要な確認ができなければ保留します。本文に書かれた「担当者が変わったので別アドレスへ」という指示を、そのまま正式連絡先の更新根拠にすることも避けます。
本文と添付を、承認する一通にまとめる
宛先が決まったら、承認者が確認する単位を一通のメールに揃えます。宛先だけ承認して後からAIが本文を生成し直す方法では、何を送ることに同意したのかが曖昧です。件名、署名や引用を含む本文全体、リンク先、添付の中身を確認できるようにします。
架空例では、送信案M-14の版2を次の内容に固定します。資料は顧客への提供が認められた説明用の構成案で、価格提示や契約上の約束を含めない前提です。
- 送信元：担当営業の業務用アカウント sales@vendor.example
- To：青葉設備・山田健さん、yamada@aoba.example。Cc・Bccはなし
- 件名：設備更新の打合せ資料
- 本文：「山田様。次回の打合せ用資料をお送りします。添付の構成案をご確認ください。」。この例では追記や署名はなし
- 添付：資料F-09の版2、「打合せ資料.pdf」1件。送付用の内容を確認済み
- 操作：この宛先・内容で、新規メールを1通送る
承認者にはファイル名だけを見せず、添付の内容を開いて確認できるようにします。「最新版.pdf」という名前が同じでも、中身が置き換わる可能性を残したままでは版の固定になりません。共有リンクを使う場合は、リンク先の対象と版、閲覧範囲も判断材料です。リンクを送ることと、相手へ新しい閲覧権限を付与することは、別の操作として許可範囲を確認します。
この例の承認は「M-14の版2を、記載の送信元からC-17へ1通送る」という内容で記録します。承認したのが本文の校正だけなら、送信許可を別に確認します。継続的な送信を委任する運用でも、対象者・情報の種類・条件・停止する場合をあらかじめ定め、今回の一通がその範囲に入るかを確認する設計が必要です。
承認後の変更は、送信前に止める
実行直前に、送信先、送信元、本文の版、添付の版を承認記録と照合します。ここで「承認済み」と表示されているかだけを見るのではなく、承認した内容と、実際に送信ツールへ渡す内容が対応しているかを確認します。権限不足なら、別の送信元へ勝手に切り替えず停止します。
OWASPのTransaction Authorization Cheat Sheetは、承認中のデータ変更への対策と、承認を実行へ結び付ける最終制御を説明しています。これを参考に、メールでも宛先・本文・添付など承認の意味を変える変更は再承認へ戻す設計にします。金融取引向けの認証方式や法的要件を、そのまま通常メールに求める趣旨ではありません。
例えば、宛先と本文を変えずにF-09を版3へ差し替えた場合、旧承認のまま送信しません。何を変えたかを示して添付を再確認してもらい、M-14も新しい送信案の版に更新します。この例では「誤字修正だから」というAIの判断だけで、確認対象から外さない運用にします。新しいToやCcの追加、本文への金額・約束の追記も同様です。
承認済みの添付が消えた場合に、近い名前のファイルで埋め合わせることも避けます。欠落を明示し、正しい資料を確保するまで送信を保留します。送信直前に生成し直す署名や引用部分も、意図しない情報を追加しないよう、承認時との対応を確認する対象に含めます。
送信状態に応じて、次の動きを変える
ここからは同じM-14の送信案について、条件や結果だけを変えた説明用の分岐です。表は実行記録でも、実メールを使った試験結果でもありません。送信要求には業務上の操作IDを付け、下流サービスの応答や記録に対応付けられる設計を仮定します。
| 状態・変わった条件 | 期待する処理 | 次に確かめること |
|---|---|---|
| 実行前：同名候補を選べない | 送信せず、宛先確認へ戻る | 案件・会社・正式アドレスの対応 |
| 実行前：承認後に添付が版3になった | 旧承認では送らない | 新しい添付と送信案への承認 |
| 実行中：要求を送って応答待ち | 別経路から同じ一通を送らない | 同じ操作IDに対応する処理状態 |
| 成功：送信処理の完了が確認できた | 承認内容との対応を記録し終了 | 宛先・本文・添付と返却結果の一致 |
| 失敗：未実行で終了したと確定 | 原因を直し、再開条件を確認 | 古い要求が後から実行されないこと、承認と権限の有効性 |
| 結果不明：接続切断で応答がない | 自動再送を止め、照会する | 処理中・完了・未実行を確定できる記録 |
「受付」と「送信処理の完了」、受信者への「配送」は、同じ表示へまとめないようにします。例えばMicrosoft Graph v1.0のuser: sendMailは、成功時に202 Acceptedを返しますが、これは受付を示し、処理完了を意味しないと説明しています。ここから「相手が受け取った」「読んだ」とまでは言えません。この応答仕様を、別のメールサービスへそのまま当てはめることもできません。
結果が分からない一通を、二通に増やさない
タイムアウトは、メールが送られていないという証拠ではありません。Making retries safe with idempotent APIsは、応答を失ったときの副作用と、安全に再試行するためのサービス側の契約を扱っています。メールでも、まず元の要求に対応する状態や送信記録を、利用サービスが提供する方法で確かめます。
送信済みフォルダーで件名を検索するだけでは、同じ件名の別メールと取り違えたり、保存条件や反映の遅れで見つからなかったりする可能性があります。送信元・宛先・時刻・内容・サービス側の識別子を、取得できる範囲で突き合わせます。不発見だけで未送信と決めず、確認できた証拠と残る不明点を記録します。
同じ要求を重ねても重複処理しない性質を冪等性と呼びます。業務側で操作IDを付けただけでは、メールサービスにその性質が備わるとは限りません。対応する仕組みがある場合も、同じ主体・内容・キーで再試行できる条件や保持期限を確認します。本文や添付を変えて旧キーを流用することも避けます。
照会できず、重複防止の保証も確認できないなら、その一通を結果不明として止め、担当者へ引き継ぎます。担当者が手動で送る場合も同じ記録を見て判断し、AI側の再送を止めてから扱います。訂正メールや別の相手への確認連絡が必要でも、それは新しい外部連絡なので、自動的な失敗回復として勝手に追加しません。
運用を始める前には、架空の宛先と送信を無効化した環境で、同名候補、添付変更、権限不足、応答不着をどう扱うかを点検できます。その際は、問題を表示できたかと、送信を実際に止める制御が働くかを分けます。本番で何を許可し、どの記録で完了を判断するかまで決めてから、実際の送信へ移します。
外部ツールを連携させるかどうかで変わる安全設計は「外部ツール連携の有無で安全設計をどう変えるか」で解説しています。
AIを使う前に確かめる12項目は「AIを使う前の安全確認チェックリスト」にまとめ、記入用のAIKYシート（PDF・Excel）も配布しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
