SendGrid から Amazon SES への移行｜バウンス・サブドメイン・ウォームアップ
目次 クリックで開く
メール配信プラットフォームの選定は、サービスの成長フェーズやコスト構造に直結する重要な意思決定です。長らくSendGridを利用してきた企業において、配信通数の増加に伴うコスト増や、より柔軟なインフラ構成へのニーズからAmazon Simple Email Service (SES) への移行を検討するケースが増えています。
しかし、Amazon SESは「単にAPIを叩けば送れる」ツールではありません。適切なバウンス処理の実装や、レピュテーションを守るためのドメイン設計、そして段階的なウォームアップを怠ると、最悪の場合、配信停止の措置を受けるリスクがあります。
本記事では、IT実務担当者の視点で、SendGridからAmazon SESへの移行における技術的なハードルとその解決策、具体的な移行手順を徹底解説します。
SendGridからAmazon SESへ移行すべき理由と判断基準
移行の最大の動機は「コスト」と「AWSエコシステムへの統合」です。SendGridは機能が豊富でUIも洗練されていますが、通数ベースの従量課金が一定ラインを超えると、Amazon SESの方が圧倒的に安価になる傾向があります。
コスト構造の劇的な変化：10万通配信時の比較
以下の表は、一般的な中規模配信における月額コストの概算比較です。Amazon SESは、EC2等から送信する場合の無料枠や、一貫した低単価が特徴です。
| 比較項目 | SendGrid (Proプラン想定) | Amazon SES | |
|---|---|---|---|
| 基本料金 | $89.95/月〜（20万通まで含む） | 0（基本料金なし）\ | $0.10 |
| 10万通送信時の月額 | 約 14,000円〜 | 約 1,500円 | |
| 専用IPオプション | Proプラン以上に1つ付属 | $24.95/月（Managed IPは別） |
※2026年時点の公式ドキュメントおよび最新の価格改定を参考に算出。正確な料金は Amazon SES 料金ページ をご確認ください。
コスト削減は魅力的ですが、自社でインフラを管理する工数が増える点は注意が必要です。特に、退職者のアカウント管理や権限の適切な分離ができていない環境では、セキュリティリスクが伴います。こうしたガバナンスの課題については、SaaSアカウント削除漏れを防ぐ自動化アーキテクチャ の知見が、メール送信基盤（IAM）の管理にも応用できます。
移行前に設計すべき「サブドメイン」と「送信ドメイン認証」
Amazon SESへの移行において、最も失敗しやすいのがドメインの設計です。SendGridで使っていたメインドメインをそのままSESに紐付けるだけでは不十分です。
トランザクションとマーケティングでドメインを分離する理由
パスワードリセットなどの「トランザクションメール」と、キャンペーン告知などの「マーケティングメール」を同じドメイン（あるいは同じIP）で送ることは推奨されません。マーケティングメールが「迷惑メール」として報告されると、ドメイン全体のレピュテーションが下がり、重要な通知メールまで届かなくなるからです。
- トランザクション用:
https://www.google.com/search?q=noreply.example.com - マーケティング用:
https://www.google.com/search?q=news.example.com
このようにサブドメインを分けることで、ISP（Gmail等）からの評価を分散させることが可能になります。
Amazon SESでのDKIM（Easy DKIM）とSPF設定
Amazon SESでは「Easy DKIM」という機能が提供されており、AWSが生成したCNAMEレコードをDNSに追加するだけでDKIM設定が完了します。SPFについては、SESの送信サーバーを指定する include:amazonses.com を既存のSPFレコードに追加します。これにより、DMARC認証のパス率を高めることができます。
Amazon SES への移行ステップバイステップガイド
実務における移行手順を4つのステップで解説します。
ステップ1：AWSリージョンの選択とサンドボックス解除申請
まずは、システムのレイテンシーやデータ保存要件に基づきリージョンを選択します。東京リージョン（ap-northeast-1）が一般的です。初期状態のSESアカウントは「サンドボックス」環境にあり、検証済みの宛先にしかメールを送れません。AWSサポートに対し、「本番環境アクセスのリクエスト」を行い、ユースケースやバウンス対策の実装予定を説明して制限を解除してもらう必要があります。
ステップ2：ID（ドメイン/メールアドレス）の検証
AWSコンソールの「Verified identities」から、使用するドメインを登録します。前述のCNAMEレコードをDNS（Route 53やCloudflare等）に反映させると、ステータスが「Verified」に変わります。
ステップ3：SMTP認証またはAPIキーの発行
アプリケーションからSESを利用する方法は2つあります。
SMTPインターフェース: 既存のプログラムがSMTPプロトコルを使用している場合に適しています。
AWS SDK (API): パフォーマンスとエラーハンドリングの観点から、AWS SDK（Boto3, SDK for Go等）の利用が推奨されます。
この際、IAMポリシーは「SESの送信権限のみ」に絞り、最小権限の原則を徹底してください。インフラ全体のコスト最適化を検討している場合は、SaaSコストとオンプレ負債を断つためのアーキテクチャ設計と合わせて、メール送信基盤も集約・整理するのが効率的です。
ステップ4：アプリケーション側の接続先変更
SendGridのAPIキーをAmazon SESのIAM認証情報に書き換えます。この際、環境変数を利用して、不達時のリトライ処理やタイムアウト値を適切に設定します。
バウンス・苦情メール処理の自動化（SNS + SQS/Lambda）
SendGridには標準でバウンス（不達）したアドレスを自動的にリスト除外する機能がありますが、Amazon SESではこれを開発者側で実装する必要があります。
SendGrid WebhookからAmazon SNSへの置き換え
Amazon SESでバウンスや苦情が発生した際、そのイベントを Amazon SNS (Simple Notification Service) へ通知するように設定します。
通知を受けた後は、以下のいずれかのフローで処理します。
- SNS → Lambda → DB: 配信停止フラグを自社データベースに書き込む。
- SNS → SQS → バッチ処理: 大規模配信時にキューイングして非同期で処理する。
これを怠ると、存在しないアドレスにメールを送り続けることになり、AWSから送信停止措置（Suspension）を受けるため、移行時の最優先事項です。データ連携を高度に自動化する手法については、SFA・CRM・MA・Webの違いとデータ連携の全体設計図 が参考になります。
失敗しないための「IPウォームアップ」実践計画
新しいIPアドレスやドメインから突然大量のメールを送ると、ISPのスパムフィルタにブロックされます。これを避けるのが「ウォームアップ」です。
共有IPと専用IP（Standard / Managed）の選び方
- 共有IP: 通数が少ない（月間数十万通以下）場合。他ユーザーの影響を受けるが、低コスト。
- 専用IP (Standard): 送信量が多く、自社で完全にレピュテーションをコントロールしたい場合。自分でウォームアップが必要。
- 専用IP (Managed): AWSが自動的にウォームアップとスケーリングを管理してくれるプラン。運用負荷を下げたい場合に適しています。
配信量を段階的に増やす「ウォームアップ・スケジュール」の例
専用IPを使用する場合、以下のようなスケジュールで日ごとの送信制限（Quota）を意識しながら配信量を増やします。
- 1日目：1,000通
- 2日目：2,000通
- 3日目：4,000通
- （以降、前日の2倍程度を目安に、不達率を見ながら拡大）
よくあるトラブルと解決策
移行後によく遭遇するエラーとその対策をまとめました。
「Sending limit exceeded」エラーへの対処
これは、秒間の送信レート（Sending Rate）または24時間あたりの送信上限（Daily Quota）を超えた場合に発生します。AWS Service Quotasから上限緩和申請を行うとともに、アプリケーション側で「Exponential Backoff（指数バックオフ）」によるリトライ処理を実装してください。
メールの遅延が発生する場合の確認項目
SES側での遅延よりも、宛先ISP側でのスロットリング（流量制限）が原因であることが多いです。バウンス率が上昇していないか、CloudWatch Metricsで「Bounce Rate」と「Complaint Rate」を常に監視してください。
まとめ：インフラとしてのメール配信基盤を最適化する
SendGridからAmazon SESへの移行は、単なるコスト削減に留まらず、AWS上の他リソース（Lambda, S3, CloudWatch）との親和性を高め、より堅牢な通知基盤を構築する絶好の機会です。
重要なのは、移行完了をゴールにせず、SNSを用いたバウンス処理の自動化や、CloudWatchによるレピュテーション監視を運用フローに組み込むことです。これにより、メール到達率を高い水準で維持し、サービス価値を最大化できるようになります。
もし既存のSaaS環境全体の見直しが必要であれば、メール送信基盤の移行と並行して、システム間のデータ連携を整理することをお勧めします。
実務担当者が運用前に確認すべき「SES移行チェックリスト」
Amazon SESへの移行後、SendGridのような「至れり尽くせり」のダッシュボードがなくなることで、運用がブラックボックス化しがちです。安定稼働のために、以下の技術・運用要件が満たされているか最終確認を行ってください。
SES運用の健全性を保つ3つの指標
AWSは送信ドメインのレピュテーション（信頼性）を厳格に管理しています。以下の基準を超えると、段階的に送信制限やアカウント停止の措置が取られるため、CloudWatchアラームの設定は必須です。
| 指標 | 警告（注意）レベル | 送信停止（リスク）レベル |
|---|---|---|
| バウンス率 (Bounce Rate) | 5% 以上 | 10% 以上 |
| 苦情率 (Complaint Rate) | 0.1% 以上 | 0.5% 以上 |
※数値は Amazon SES 公式ドキュメント（レピュテーション管理） を参照。特にバウンス率は「10%」が明確なデッドラインです。
よくある誤解：SendGridの「サプレッションリスト」は引き継がれない
最も注意が必要なのは、SendGrid側で蓄積された「過去のバウンスリスト（送信除外リスト）」です。これをSES側に移行（インポート）し、自社のDB等で事前に送信対象から除外する処理を実装しない限り、移行初日に大量のバウンスが発生し、即座にアカウントが停止するリスクがあります。
- SendGridから「Global Unsubscribes」や「Bounces」のリストをCSV出力する。
- SES移行後のアプリケーション側で、上記リストに含まれるアドレスには送信しないロジックを組む。
- または、Amazon SESの「アカウントレベルの抑制リスト」機能を活用する（要設定）。
インフラ構成の最適化とデータ連携の発展
メール配信基盤をAWSへ移行することは、バックオフィス全体のデータ連携を「API中心」に再構築する第一歩でもあります。例えば、送信後のログをBigQuery等のデータ基盤へ集約し、顧客の行動データと紐付けることで、より高度な施策が可能になります。
このようなデータ利活用や、肥大化したSaaSコストの最適化については、以下の関連記事も参考にしてください。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。