はじめに
2024年5月にAWSから一般提供（GA）が開始された「SES Mail Manager」をご存知でしょうか？
従来のSES受信（Receipt Rules）よりも高度なルールエンジンやIngress Point（受信口となるエンドポイント）の管理機能が備わった、「企業グレードのメールゲートウェイ（E-mail Security Gateway）」としての機能をSESに追加するマネージドサービスです。
従来のSESが「プログラムからの送受信」に特化していたのに対し、Mail Managerは組織全体のメールトラフィックの統制、アーカイブ、ルーティングを担います。
今回は、このSES Mail Managerを使って「受信したメールをS3にアーカイブしつつ、VPC内のEC2で稼働するsmtp4dev（外部SMTPサーバー相当）にリレーする」という実験を行いました。
さらに、この検証環境全体の構築からトラブルシューティングまでを、Antigravity をはじめとする複数のAIを適材適所で活用しながら進めた過程をレポートします。
実験の目的と構成
今回のゴールは、「カスタムドメインを用意せず、AWSが提供する既存のドメイン（Ingress Endpoint）のみを使ってメール受信フローを検証する」 ことです。
主な構成要素
- AWS SES Mail Manager: 受信口（Ingress Point）、振り分けルール（Rule Set）、リレー設定（Relay）。
- S3バケット: 受信メールの生データ保存用。
- EC2 (Docker + smtp4dev): リレーされたメールをWeb GUIで確認するための仮想SMTPサーバー。
- Terraform 1.5+: インフラ全体のコード化（IaC）。
アーキテクチャ図（イメージ）
Terraformによる構築のポイント
1. Ingress Point の活用
SES Mail Managerでは「Ingress Point」という受信口を作成します。今回は検証を容易にするため、認証なしで受け入れ可能な OPEN タイプを使用しました。これにより、作成時に発行されるエンドポイント（vpce-xxx.open.mail-manager-smtp.ap-northeast-1.vpce.amazonaws.com）に対して直接メールを送ることができます。
2. Rule Set のアクション定義
受信したメールに対して何をするかを Rule Set で定義します。今回は一つのルールの中に「S3への書き込み」と「Relayを通じたEC2への転送」の2つのアクションを定義しました。
※ここで awscc プロバイダー特有のスキーマ（プロパティ名が s3 ではなく write_to_s3 である点など）に苦労しましたが、AIが即座に修正案を提示してくれました。
現場で遭遇したトラブルとAIによる解決
今回の検証では、いくつかの「ハマりポイント」がありました。Antigravityがどのようにサポートしてくれたかを併せて紹介します。
① TLSとHELO、そしてポート25の壁
EC2から swaks コマンドでテストメールを送信した際、SES側から接続を拒否されました。
- 原因:
- SESエンドポイントは STARTTLS を必須としており、かつ適切な HELO 文字列を求めていました。
- SES Mail ManagerからEC2への通信が、AWSの標準的な制限（OP25B等のスパム対策）に抵触していたようです。
- 解決:
swaksコマンドに--tlsと--helo [IP]を追加し、さらにEC2に必要なPerlモジュールをインストールするようuser_dataを修正。- 通信ポートを
25から1025などに変更して制限を回避しました。
【最終的なテストコマンド例】
swaks --to test@example.com --from test@example.com --server vpce-XXXXX.open.mail-manager-smtp.[region].vpce.amazonaws.com --port 1025 --helo localhost --tls
② セキュリティグループとリレー先の疎通
メールは受理されるものの、smtp4devに届かない問題が発生。
- 原因: EC2のSGでポート25をVPC内に絞っており、SESマネージドリレーからのパブリックアクセスが遮断されていました。
- 解決: SGのポート25を
0.0.0.0/0に公開（検証用）することで疎通を確認。また、リレー先でもSTARTTLSが有効であることを確認するため以下のコマンドでTLS応答テストも実施し、EC2のDockerポートマッピング等の見直しも行いました。
swaks --server [smtp4devのIP_ADDRESS] --port 25 --quit-after STARTTLS
③ SESのサンドボックス制限（検証済みID）
CloudWatch Logs上で調査すると、リレーアクション以前に送信自体が拒否される挙動も発見できました。
- 原因: AWSアカウント内のSESがサンドボックス制限下にあり、未検証の宛先への送信が弾かれていました。
- 解決: CloudWatch Logsの出力エラーを元に、Antigravityとは別のAIに解析を依頼したところ、サンドボックス制限が原因であると特定されました。これに従い、AWSコンソールの「検証済みID」にテスト送信で使うメールアドレスを登録して解決しました。
複数のAIを活用した検証のメリット
今回の検証において、AIは単なる「コード生成機」ではありませんでした。
- 得意分野の掛け合わせ: コード構築や全体進行はAntigravityに任せつつ、特定のエラーログ解析は別のAIに任せるなど、複数のAIを組み合わせることで解決までのリードタイムが大幅に短縮されました。
- 作業履歴の自動記録: 複雑なトラブルシューティングの過程を「履歴」としてマークダウンで残すよう指示することで、後からの振り返りやこの記事の執筆が非常にスムーズになりました。
- 最新リソースへの追従: まだ比較的新しい
awsccプロバイダーの独特な記述ミス（PascalCaseとcamelCaseの混在など）を即座にAIが指摘・修正してくれました。
まとめ
AWS SES Mail Managerは、非常に柔軟で強力なメール基盤です。カスタムドメインなしのIngress Point機能は、クローズドな環境やPoCにおいて非常に有用だと感じました。
また、インフラ構築におけるAIの活用は、単に「早い」だけでなく、「試行錯誤のプロセスを資産化する」という点において非常に強力な武器になります。
皆さんもぜひ、SES Mail ManagerとAIを活用したインフラ構築を試してみてください！
簡単30秒