メール送信の承認を、宛先・本文・添付の版に結び付ける

メール送信を承認制にするとき、承認済みという状態だけでは、何を送ってよいのかを表現できません。宛先、CC、本文、添付のどれかが変われば、承認者が確認した内容とは異なる送信になります。

2026年8月、自分で開発している運用ツールで、これらの項目をメールの版に結び付けました。この記事は、その実装記録から承認の境界を整理したものです。外部サービスの脆弱性報告ではありません。

承認対象に宛先とCCも含める

実装では、メールの版の内容ハッシュに宛先とCCを含めました。本文だけが同じでも、受信者が変われば同じ承認対象としては扱いません。添付の変更も同様です。

守りたい条件は、「承認された版と、送信しようとしている版が一致すること」です。内容ハッシュはその一致を判断する材料であり、承認する権限を持つ人の確認を代わりに行うものではありません。

宛先、CC、本文、添付の変更時には、古い承認を失効させます。ここで未送信のキューを残すと、画面上では再承認待ちでも、以前に予約した処理が別に進む可能性があります。そのため、旧承認と未送信キューを一緒に失効させる形にしました。

操作と扱いを整理すると、次のようになります。

一度届いたメールを取り消す仕組みではありません。対象は、送信前に内容を変更した場合の承認と待機中の処理です。

複数のメールアドレスを含む依頼では、先頭を宛先、残りをCCとして扱うようにしました。「前回と同じCC」という依頼も、無関係なメールから受信者を拾わないよう、引き継ぎ元を制限しています。

CCは最大10件とし、重複や不正なヘッダー入力はサーバー側で拒否します。これらは、このツールで選んだ仕様です。メール全般の上限や、あらゆるAIツールに共通する規則ではありません。

自然言語で操作できるようにしても、何を送れるかの条件まで自然言語の指示に任せる必要はありません。受信者の検証、レビューする版、変更時の失効を、アプリケーション側の状態として扱いました。

当時の変更ではCI、76件のテスト、ESLint、本番向けビルドを通し、デプロイのReadyを確認しています。ただし、この記録だけから、すべての同時実行や障害時の振る舞いまで検証済みとは言えません。

追加のレビューでは、編集と送信処理が同時に進む場合、再試行が入る場合、キューを実行する直前に版が変わった場合を確認対象にします。これは今後の確認観点であり、今回の記事を書くために実環境で再試験した結果ではありません。

承認ボタンの有無より、承認が指している内容と、その内容が有効である期間を実装で保てるか。その二点を明示するための変更でした。