AWS顧客コミュニケーション本番運用｜SES×End User Messaging

1. この記事について

アウトバウンド配信——企業から顧客へのメール・SMS・プッシュ通知——は、SaaS・ECサイト・
モバイルアプリを問わず現代のWebサービスに不可欠なインフラです。パスワードリセット、
注文確認、配送通知、OTPによる本人確認、プロモーション配信など、ユーザーエンゲージメントと
サービス信頼の多くがアウトバウンド通知によって支えられています。

そのAWSのアウトバウンド配信基盤は、2024年から2026年にかけて大きく再編されています。
起点となるのはAmazon Pinpointのサポート終了です。

• 2024年Q3: Pinpointのチャネル機能（SMS/MMS/プッシュ/音声/WhatsApp）が「AWS End User Messaging」として独立・改称
• 2025年5月20日: Pinpointの新規アカウント受付停止
• 2026年10月30日: Pinpointのサポート完全終了（コンソール・API 一切利用不可）

現在Pinpointを使っているシステムは、この期限までに移行を完了させる必要があります。
これから新規構築する場合は、最初からPinpointではなく後継サービスを選んでください。

AWSのアウトバウンド配信サービスは現在、次の3つに整理されています。

1-1. 本記事のゴール

本記事を読み終えると、次の状態になることを目標にしています。

• Pinpointの各機能をSES / AWS End User Messaging / Amazon Connect Outboundのどれへ振り分けるべきか、自力で判断できる
• SESのサンドボックス解除からDKIM/DMARC設定まで、本番メール送信の前準備を自力で完了できる
• AWS End User MessagingのSMS（10DLC/Toll-free）とプッシュ通知（APNs/FCM）の基本設定を理解している
• バウンス率・苦情率の監視アラームを設計・実装できる
• 利用ユーザーの所在地に応じたコンプライアンス要件（TCPA・特定電子メール法・GDPR）を把握している

1-2. 読者像

Pinpointからの移行を迫られているエンジニア

既存システムでPinpointのメール送信やSMS機能を利用しており、AWSからのEOL通知を受けて
移行検討を始めた方。特に「使っているPinpoint機能はどの後継サービスへ移ればよいか」という
判断の軸を求めているエンジニアを想定しています。AWSの基本操作（マネジメントコンソール・CLI）
には慣れている前提です。

新規に通知基盤を構築するエンジニア

SaaSプロダクトやモバイルアプリでトランザクションメール・OTP SMS・プッシュ通知の配信基盤を
AWSで一から設計しようとしているバックエンドエンジニア。「AWSでSMSを送るには何を使えばいいか」
という入口から、本番環境に必要な到達性・コンプライアンス設計まで体系的に学びたい方が対象です。

1-3. なぜ今これを書くか

Amazon Pinpointのサポート終了は、AWS上でアウトバウンド通知基盤を持つ企業にとって
無視できない変化です。しかし2024年のサービス再編以降、AWSのドキュメントは
SES・End User Messaging・Amazon Connectに分散し、「どこに何が書いてあるか」が
非常に分かりにくくなっています。

移行期限（2026年10月30日）まで1年を切った今、正しいサービス理解と移行計画が急務です。
また「そもそもPinpointを知らない」エンジニアにとっても、AWSで通知基盤を構築するための
体系的な情報が整理されていないという課題があります。本記事は移行組・新規組の双方に対応します。

Pinpointは「廃止」ではなく「分散・強化」されています

「Pinpointが廃止される」という表現は誤解を招きます。正確には:
– SMSとプッシュ通知は「AWS End User Messaging」として別サービスに独立・継続しています
– メール送信はSESへ統合済み（すでにSESで可能になっています）
– 廃止されるのは「キャンペーン/ジャーニー/セグメント/分析ダッシュボード」というマーケティング自動化層です

この区別を正確に理解することが、移行計画の第一歩です。

1-4. 本記事の位置づけ——インバウンド編との違い

本シリーズ「AWS顧客コミュニケーション本番運用」は、アウトバウンドとインバウンドの2軸で構成されています。

本記事（Vol1）はアウトバウンド通知基盤に特化しています。
企業から顧客へのメール・SMS・プッシュ通知——一方向の配信設計・運用が対象です。

Amazon Connectを中心としたインバウンド編（顧客からの着信・問い合わせ受付）とは
設計の方向性・コンプライアンス要件・使用サービスがすべて異なります。
オムニチャネル戦略では両方を組み合わせる場面もありますが、本記事はアウトバウンド側に絞って解説します。

1-5. 本記事の構成

本記事は以下の流れで解説します。

前提知識: AWSの基本操作（IAM・CLI・マネジメントコンソール）に慣れていることを前提としています。
SESやEnd User Messagingの利用経験は不要ですが、DNS操作（CNAMEレコードの追加）ができることが必要です。

2. 前提・環境・準備

本番のメール・SMS・プッシュ通知を送信できる状態にするには、SESのサンドボックス解除と
AWS End User Messagingのアクティベーションという2つの申請ステップが必要です。
この章では前提環境の確認から各サービスの有効化、設定に必要な権限の設計まで順を追って解説します。

2-1. 前提環境

AWSアカウントの前提

本記事の手順を実行するには次の条件が満たされている必要があります。

• 管理者権限またはサービス管理権限を持つ操作主体（IAMユーザーまたはロール）が存在する
• 請求情報が有効で、本番移行申請が可能な状態である
• AWS Organizations配下の場合、SCPでSES/End User Messagingの操作が許可されている

推奨リージョン

東京リージョン（ap-northeast-1）でAmazon SES・AWS End User Messaging SMS・
AWS End User Messaging Pushのすべてが2025年時点で利用可能です。
SMSの送信可否と電話番号取得の可否は宛先国によって異なるため、送信先国をリージョン選択の前に確認してください。

AWS CLIのバージョン確認

aws --version
# aws-cli/2.x.x Python/3.x.x ...

本記事のコマンド例はAWS CLI v2を前提としています。aws sesv2 と aws pinpoint-sms-voice-v2 の
2つのサブコマンドを主に使用します。

2-2. 使用するAWSサービスとAPIバージョン

aws pinpoint-sms-voice-v2 はAWS End User Messagingに改称されましたが、
CLIサブコマンド名はv2 APIのまま維持されています。
新規実装では aws pinpoint-sms-voice-v2 を使い、旧 aws pinpoint の使用は最小限にしてください。

2-3. Amazon SES 本番モード移行（サンドボックス解除）

新規アカウントのAmazon SESはサンドボックスモードで起動します。
サンドボックスモードでは検証済みメールアドレスへの送信しかできず、
1日あたり200通・最大1通/秒という制限があります。本番サービスには必ず解除が必要です。

本番移行の申請手順

1. AWSマネジメントコンソールで「Amazon Simple Email Service」を開く
2. 左ペインの「Getting started」→「Request production access」をクリック
3. 申請フォームに以下を記入する:
4. メールタイプ: Transactional（注文確認・パスワードリセット等）またはMarketing
5. 想定送信量: 1日あたりの送信通数と最大送信レート
6. オプトイン管理方法: ユーザーが明示的に同意した方法を具体的に記述
7. バウンス・苦情処理方法: 高いバウンス率・苦情率への対策

8. ユースケースの詳細: 誰に・何の目的で・どのようなコンテンツを送信するか

9. 申請後、通常1〜2営業日以内にAWSからメールで回答が届く

申請時に「バウンス率を5%未満に維持する」「DKIM認証を設定済み」「オプトアウトリンクを全メールに含める」
といった具体的な運用方針を記述すると承認されやすくなります。

申請が拒否された場合の対応

申請拒否の主な原因と対処法は次のとおりです。

拒否後は改善内容を明記したうえで Support Center から再申請します。
同様の申請内容では再拒否されるため、AWS側のフィードバックを必ず確認してください。

ドメイン認証（本番移行前に推奨）

本番移行申請と並行して、送信元ドメインのDKIM認証を行います。
未認証ドメインからの送信は到達率に悪影響を与えます。

aws sesv2 create-email-identity--email-identity example.com--dkim-signing-attributes SigningAttributesOrigin=AWS_SES

コマンド実行後に表示されるCNAMEレコードをDNSに追加します。
反映後（通常数分〜数時間）、SESのコンソールで「Verified」と表示されれば認証完了です。

2-4. AWS End User Messaging の有効化

SMS機能の開始

AWS End User Messaging（SMS）は東京リージョンで標準で利用可能です。
ただし米国宛てのSMS送信には電話番号の取得が必要です。

電話番号の種類と特徴は次のとおりです。

最初の電話番号取得にはToll-free番号が月額費用が安く国際SMS対応も広いため推奨です。

# 利用可能な電話番号を確認
aws pinpoint-sms-voice-v2 describe-phone-numbers--region us-east-1

プッシュ通知の有効化

各プラットフォームの認証情報を End User Messaging に登録します。

iOS APNsはトークン方式（.p8）が有効期限管理不要で運用しやすく推奨されます。
認証情報はEnd User Messagingコンソールの「Mobile Push Channels」から登録します。

主要国のSMS送信可否と電話番号要件（2025年時点）

各国のSMS規制は頻繁に変更されます。End User Messagingコンソールの
「Supported countries and regions」ページで最新情報を確認してください。

2-5. 設定に必要な操作権限の設計

本記事の手順を実行するための権限設計の考え方を示します。
最小権限の原則に基づき、SESとEnd User Messagingの操作を目的別に分けることを推奨します。

メール送信用の操作スコープ

アプリケーションサーバーがメールを送信するために最低限必要な操作は、
ses:SendEmail・ses:SendRawEmail・ses:SendBulkEmail の3つです。
送信元アドレスの条件付き制限（ses:FromAddress 条件キー）を組み合わせると、
指定アドレス以外からの送信を防ぐことができます。

SES管理操作用のスコープ

Configuration Setの管理やドメイン認証といった管理操作には別途権限が必要です。
ses:CreateConfigurationSet・ses:CreateEmailIdentity・
ses:PutEmailIdentityDkimSigningAttributes などが該当します。
アプリケーション実行環境とは別のロールに分離してください。

SMS送信用の操作スコープ

AWS End User MessagingのSMS送信には sms-voice:SendTextMessage・
sms-voice:SendMediaMessage の操作が必要です。
電話番号の取得や設定変更など管理操作は送信用と分離したロールで行います。

設定変更はAWSマネジメントコンソールまたはCLI経由で行ってください。
ConoHaなどのWAFを通じたWebサービス経由でのポリシー変更操作は
セキュリティキーワードの密度によって誤検知されることがあります。

EC2/ECSからSES/End User Messagingを呼び出す場合のロール設計指針

アプリケーションをEC2やECSで動かしている場合は、インスタンスプロファイルまたは
タスクロールに必要な操作スコープを付与するのが標準的な設計です。
ローカル開発環境ではIAMユーザーの認証情報をAWS CLIの認証情報ファイルに設定して使用しますが、
本番環境では認証情報ファイルではなくインスタンスプロファイルを必ず使用してください。
認証情報の平文保存はセキュリティインシデントの原因になります。

Lambdaから呼び出す場合も同様で、Lambda実行ロールに必要な操作スコープを追加します。
CICDパイプライン（GitHub Actions等）からインフラ設定を変更する場合は
OpenID Connect（OIDC）フェデレーションを使ったロール連携を推奨します。

2-6. この章のゴール確認

次の章に進む前に以下の状態を確認してください。

• SESのサンドボックスが解除され、任意の宛先へのメール送信が可能
• 送信ドメインのDKIM認証が完了（SESコンソールで「Verified」表示）
• AWS End User MessagingのSMS用電話番号が取得済み（またはSender IDが設定済み）
• プッシュ通知対象プラットフォーム（APNs/FCM）の認証情報が登録済み
• SES送信用とSMS送信用の操作スコープが最小権限で設定済み

この状態が整えば、次の章でサービス再編の全体像とPinpointからの移行マッピングを詳しく確認します。

3. サービス再編の全体像 — Pinpoint をどこへ移すか

Amazon Pinpoint は 2024年Q3 に大規模なサービス再編を経て、機能ごとに異なるサービスへ引き継がれました。「Pinpoint を使っていたから問題ない」という認識は危険で、廃止される機能・継続する機能・移行が必要な機能の 3 区分を正確に把握したうえで設計判断する必要があります。

3-1. 機能別の移行マッピング

3-2. 継続チャネル: AWS End User Messaging の現行アーキテクチャ

2024年Q3 に改称された AWS End User Messaging は、Pinpoint の SMS・プッシュ・音声チャネルをそのまま引き継いだサービスです。主要 API の互換性は維持されていますが、新機能（OTP 送信・10DLC キャンペーン管理）は SMS and Voice v2 API でのみ提供されます。

提供チャネルと対応 API の一覧

3-3. 移行が必要: メール送信 → Amazon SES

Pinpoint Email API（email.pinpoint.<region>.amazonaws.com）はすでに廃止されています。メール送信は Amazon SES v2 API へ移行します。

移行ポイント

既存コードが Pinpoint Email API を使用している場合は、SES v2 SDK へ切り替えるだけで大部分は動作します。ConfigurationSetName の指定方法と Destination パラメータの構造が変わる点に注意してください。

3-4. 廃止・移行: キャンペーン / ジャーニー → Amazon Connect Outbound Campaigns

マーケティング向けのキャンペーン・ジャーニー機能は Amazon Connect Outbound Campaigns へ移行します。

機能対応表

4. Amazon SES 本番設計 — VDM・Configuration Set・バウンス処理

4-1. Configuration Set の設計原則

Configuration Set は「メール送信の論理グループ」です。送信種別やドメインごとに分離して設計すると、バウンス率・苦情率を用途別に管理できるうえ、インシデント発生時の影響範囲を最小化できます。

分離軸と設計例

Configuration Set を送信 API 呼び出しごとに明示することで、どのメールがどの設定グループか追跡できます。

aws sesv2 send-email \
  --from-email-address "noreply@mail.example.com" \
  --destination "ToAddresses=user@example.net" \
  --content '{"Simple":{"Subject":{"Data":"ご注文確認"},"Body":{"Text":{"Data":"本文"}}}}' \
  --configuration-set-name "transactional-prod"

イベント宛先の設定

Configuration Set に「イベント宛先」を設定することで、送信・配信・バウンス・苦情・開封・クリックを各サービスへルーティングできます。

4-2. VDM（Virtual Deliverability Manager）の設定と活用

VDM は Configuration Set 単位またはアカウントレベルで有効化できる到達性監視・改善サービスです。送信・配信・バウンス・苦情・開封・クリックの詳細ダッシュボードを提供し、問題のある送信パターンを自動検出します。

有効化方法（アカウントレベルとセット単位の二層構造）

VDM はアカウントレベルで有効化し、特定の Configuration Set だけ設定を上書きする二層構造で管理します。未指定のセットにはアカウントレベルの設定が自動適用されます。

# アカウントレベルで VDM を有効化
aws sesv2 put-account-vdm-attributes \
  --vdm-attributes '{
 "VdmEnabled":"ENABLED",
 "DashboardAttributes":{"EngagementMetrics":"ENABLED"},
 "GuardianAttributes":{"OptimizedSharedDelivery":"ENABLED"}
  }'

# Configuration Set 単位で上書き（マーケティング用を明示的に有効化）
aws sesv2 put-configuration-set-vdm-options \
  --configuration-set-name "marketing-prod" \
  --vdm-options '{
 "DashboardOptions":{"EngagementMetrics":"ENABLED"},
 "GuardianOptions":{"OptimizedSharedDelivery":"ENABLED"}
  }'

DashboardOptions — 開封率・クリック率の可視化

EngagementMetrics を ENABLED にすると、VDM ダッシュボードで開封率・クリック率が可視化されます。ただし、トラッキングピクセルとリダイレクトリンクがメール本文に埋め込まれます。プライバシーポリシー上問題がある場合は DISABLED を明示してください。

GuardianOptions — 共有 IP の自動最適化

OptimizedSharedDelivery を有効化すると、SES が共有 IP プールから評判の低い IP を自動的に回避して送信します。専用 IP を使用している Configuration Set では効果は限定的です。

CloudWatch メトリクスの自動発行

VDM を有効化すると、バウンス・苦情のメトリクスが AWS/SES 名前空間へ自動発行されます。追加設定なしで CloudWatch アラームを構成できます。

4-3. バウンス処理 — ソフトとハードの対処法

バウンスは「ソフトバウンス（一時的な配信失敗）」と「ハードバウンス（恒久的な配信不能）」の 2 種類に分類されます。

バウンス種別と対処法

SNS → Lambda → DynamoDB でのサプレッション管理

SES Configuration Set の SNS イベント宛先でバウンス通知を受け取り、Lambda でサプレッションリストを管理するのが標準パターンです。

import json
import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('ses-suppression-list')

def lambda_handler(event, context):
 for record in event['Records']:
  message = json.loads(record['Sns']['Message'])

  if message['notificationType'] == 'Bounce':
bounce = message['bounce']
if bounce['bounceType'] == 'Permanent':
 for recipient in bounce['bouncedRecipients']:
  table.put_item(Item={
'email': recipient['emailAddress'],
'type': 'hard_bounce',
'timestamp': message['mail']['timestamp']
  })

アカウントレベルのサプレッションリスト

SES にはアカウント全体で参照するサプレッションリストが組み込まれています。put-account-suppression-attributes で SuppressedReasons に BOUNCES と COMPLAINTS を設定すると、ハードバウンス・苦情アドレスへの再送を自動防止できます。

aws sesv2 put-account-suppression-attributes \
  --suppressed-reasons BOUNCES COMPLAINTS

4-4. 苦情（Complaint）処理

苦情は受信者が「迷惑メール」とマークした際に ISP のフィードバックループ（FBL）経由で SES へ通知されます。苦情率が 0.1% を超えるとドメインレピュテーションへ深刻な影響が出ます。

苦情処理フロー

1. 受信者がメールを「迷惑メール」とマーク
2. ISP の FBL → SES へ苦情通知
3. SES が Configuration Set のイベント宛先（SNS）へ通知
4. Lambda でアドレスをサプレッションリスト（DynamoDB）へ登録
5. 次回送信前にサプレッションリストを参照し、該当アドレスへは送信しない

  elif message['notificationType'] == 'Complaint':
complaint = message['complaint']
for recipient in complaint['complainedRecipients']:
 table.put_item(Item={
  'email': recipient['emailAddress'],
  'type': 'complaint',
  'timestamp': message['mail']['timestamp']
 })

4-5. Reputation Dashboard とアラーム設計

Reputation Dashboard は SES コンソールで確認できる、アカウントおよびドメインのレピュテーション可視化ツールです。VDM が有効化されていれば Reputation.BounceRate と Reputation.ComplaintRate が CloudWatch に自動発行されます。

監視指標と閾値の目安

# バウンス率が 5% を超えた場合に SNS へアラーム通知
aws cloudwatch put-metric-alarm \
  --alarm-name "ses-bounce-rate-high" \
  --metric-name "Reputation.BounceRate" \
  --namespace "AWS/SES" \
  --dimensions Name=ConfigurationSetName,Value=transactional-prod \
  --statistic Average \
  --period 3600 \
  --threshold 0.05 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:ses-alerts"

バウンス率・苦情率のアラームは「SES の評判が悪化する前に気づく」ための最重要監視項目です。VDM 未有効化の場合は、SNS イベント宛先 + Lambda でカスタムメトリクスとして CloudWatch へ発行する必要があります。

5. AWS End User Messaging — SMS・2-way・プッシュ

5-1. 配信基盤の統合アーキテクチャ

顧客へのアウトバウンド通知を一元管理するには、チャネル選択ロジックを Lambda に集約し、上流は EventBridge でイベント駆動にする構成が定石だ。SES（メール）と End User Messaging（SMS/プッシュ）という異なる API を単一のオーケストレーション層で扱えるため、チャネル追加時の改修範囲が最小化される。

graph LR
 EB["EventBridge<br/>スケジュール・アプリイベント"] --> SQS_IN["SQS<br/>入力キュー"]
 SQS_IN --> L["Lambda<br/>チャネルルーティング<br/>テンプレート解決"]
 L --> SES["Amazon SES<br/>メール配信"]
 L --> EUM_S["End User Messaging<br/>SMS"]
 L --> EUM_P["End User Messaging<br/>プッシュ通知"]
 L --> DLQ["SQS DLQ<br/>失敗キュー"]
 DLQ --> L

処理フローの設計指針

1. EventBridge → SQS（入力キュー）: 上流アプリが直接 Lambda を呼ぶ代わりに SQS を経由させることで、Lambda のスロットリング（同時実行数上限）に対するバッファを確保する。
2. Lambda（ルーティング/テンプレート処理）: 受信メッセージの channel フィールドに応じて SES / End User Messaging SMS / プッシュを振り分ける。ユーザーの opt-in 状態確認、テンプレート解決、重複排除チェックもこのレイヤーで行う。
3. SQS DLQ（Dead Letter Queue）: 送信失敗（API エラー、レート制限、一時的な疎通不能）をキャッチし、可視性タイムアウト + 最大受信回数を設定して再送する。ハードバウンスやサプレッションリスト拒否は再送しない。

5-2. テンプレート管理: SES テンプレート vs Lambda 動的生成

選択基準: 変数の組み合わせで表現できる定型メールは SES テンプレート API を使う。顧客ごとに HTML 構造が変わる場合や多言語切り替えを Lambda 側で制御したい場合のみ Lambda 動的生成へ格上げするハイブリッド戦略が保守しやすい。SES テンプレートは create-email-template で登録し、送信時の Template パラメータで指定する。

5-3. SMS オリジネータ ID の選択基準

米国宛てトランザクション SMS は 10DLC + Campaign Registry 登録を選択する。国際 SMS は US Toll-free 番号を使うと 150 カ国以上をカバーできる。日本宛てではアルファベット Sender ID（キャリア事前承認が必要）か短縮コードを利用する。

5-4. 2-way SMS

2-way SMS（双方向）は米国・カナダ宛てのみ対応しており、その他の国は一方向送信のみとなる。End User Messaging は STOP / HELP キーワードを自動認識し、オプトアウト管理と応答返送を自動処理する。

def handle_inbound_sms(event, context):
 keyword = event.get("messageBody", "").strip().upper()
 if keyword in ("STOP", "CANCEL", "UNSUBSCRIBE", "QUIT", "END"):
  # SDK が自動オプトアウト処理を行うが、DB フラグも更新する
  update_opt_out_flag(event["destinationNumber"])
 elif keyword == "HELP":
  send_help_message(event["originationNumber"])

STOP 受信後に同じ番号へ SMS を送信すると End User Messaging が自動で送信をブロックする。オプトイン再登録は START キーワード受信で解除される。

5-5. プッシュ通知: マルチプラットフォーム対応

End User Messaging はプッシュ通知を単一 API（SendMessages / SendBulkMessages）で以下のプラットフォームへ配信する。

iOS APNs は証明書方式（.p12）よりもトークン方式（.p8）が有効期限管理不要で推奨される。各プラットフォームの認証情報は End User Messaging コンソールの Mobile Push Channels から登録する。

5-6. スロットリング対策と再送・冪等性設計

送信レート上限の目安（2026年時点）

冪等性の確保

• SES: ClientToken パラメータで同一トークンの重複送信を防ぐ（24 時間有効）。
• End User Messaging: MessageId を DynamoDB に記録し、再送前に重複チェックを行う。

SQS DLQ の設定例

{
  "maxReceiveCount": 3,
  "deadLetterTargetArn": "arn:aws:sqs:ap-northeast-1:123456789012:messaging-dlq"
}

可視性タイムアウトは Lambda の最大実行時間より長く設定すること。再送回数が上限に達したメッセージは DLQ へ移動し、CloudWatch Alarm でオペレーターへ通知する。

6. コンプライアンスと到達性 — TCPA・特定電子メール法・認証

6-1. メール認証: SPF / DKIM / DMARC

到達性を確保するためのメール認証は以下の 3 層が標準だ。いずれか一つでも欠けると主要 ISP のフィルタリングや DMARC ポリシーによる拒否に遭う。

SPF（Sender Policy Framework）

送信ドメインの DNS に、SES が利用する送信元 IP アドレス範囲を公開する。SES の場合は以下を TXT レコードに追加する。

v=spf1 include:amazonses.com ~all

~all（ソフトフェイル）か -all（ハードフェイル）かは DMARC ポリシーと整合させて選択する。サンドボックス解除後は -all を推奨する。

DKIM（DomainKeys Identified Mail）

SES コンソールの Identity → DKIM → Easy DKIM または BYODKIM でドメイン検証を行う。SES が 2048-bit RSA 鍵を自動ローテーションするため、Easy DKIM が運用上は簡便だ。DNS に 3 件の CNAME レコードを追加するだけで有効化できる。

<selector1>._domainkey.example.com CNAME <selector1>.dkim.amazonses.com
<selector2>._domainkey.example.com CNAME <selector2>.dkim.amazonses.com
<selector3>._domainkey.example.com CNAME <selector3>.dkim.amazonses.com

DMARC（Domain-based Message Authentication, Reporting & Conformance）

SPF / DKIM の結果をポリシーで強制し、認証失敗メールの処理（none / quarantine / reject）を宣言する。

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com

導入初期は p=none でレポートのみ取得し、問題のない送信量を確認してから quarantine → reject へ段階的に引き上げる。RUA レポートはサードパーティのDMARCアナライザーに集約して可視化すると効率的だ。

6-2. バウンス率管理

バウンス種別と閾値

SES アカウントレベルのバウンス率閾値は 5%（警告）/ 10%（一時停止）だ。VDM のバウンスレートタブで日次・週次のトレンドを監視し、閾値に近づいたら CloudWatch アラームで通知する。

サプレッションリストの管理

SES はアカウントレベルのサプレッションリストを持ち、ハードバウンス / 苦情が発生したアドレスを自動登録する。誤って追加されたアドレスは以下のコマンドで削除できる。

aws sesv2 delete-suppressed-destination \
 --email-address user@example.com

苦情率（Complaint Rate）管理

苦情率の閾値は 0.08%（警告）/ 0.1%（一時停止）だ。Yahoo/Gmail 両社は苦情率の高い送信者を優先的にスパムフォルダへ振り分けるため、バウンス率と同様に CloudWatch アラームを設定する。

6-3. オプトアウト処理

メール（List-Unsubscribeヘッダー）

Google/Yahoo の 2024年2月送信者ガイドライン以降、大量送信者はワンクリック購読解除（RFC 8058）が必須となった。SES の設定セットに SubscriptionManagement を有効化するか、カスタムヘッダーを付与する。

List-Unsubscribe: <https://example.com/unsubscribe?token=ABC>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

SMS（STOP キーワード自動処理）

End User Messaging は STOP / CANCEL / UNSUBSCRIBE / QUIT / END を受信すると自動でオプトアウト登録し、以降の送信をブロックする。TCPA 準拠のためにアプリ側でも DB フラグを更新し、二重チェックを行うこと。オプトイン再登録は START キーワード受信で解除される。

6-4. コンプライアンス要件

米国 SMS: TCPA（Telephone Consumer Protection Act）

TCPA は米国でのオートダイヤル・SMS 送信に適用される連邦法だ。違反 1 通あたり 500〜1,500 ドルの損害賠償リスクがある。

日本: 特定電子メール法

トランザクションメール（注文確認・パスワードリセット等）は一般的に特定電子メールの対象外だが、マーケティング要素が混在すると対象になる。法務確認を怠らないこと。

EU: GDPR（一般データ保護規則）

GDPR 下でのメール送信は「同意」または「正当な利益」の法的根拠が必要だ。マーケティングメールは原則同意ベースであり、以下を遵守する。

• 同意の取得は自由意思・具体的・十分な情報に基づく明示的な行為
• 同意の撤回は同意と同様に簡単にできること
• データ主体からのアクセス・削除・ポータビリティ要求に 30 日以内に対応

6-5. レピュテーション管理と Warm-up 設計

ドメインレピュテーションのスコア監視

Google Postmaster Tools・Microsoft SNDS（Smart Network Data Services）でドメインレピュテーションを継続監視する。Bad 判定が続くと ISP 側でメールが自動フィルタリングされる。SES の VDM が提供する Guardian 機能は高バウンス率・高苦情率を自動検知し、送信を自動抑制する。

送信量の段階的増加（Warm-up）

新規ドメイン・新規送信元 IP アドレスから大量送信を開始すると ISP 側でスパム判定を受けやすい。最初の 4〜8 週間はランプアップスケジュールを組む。

段階的な送信増加と VDM Guardian の自動抑制を組み合わせることで、レピュテーション毀損リスクを最小化できる。バウンス率が 2% を超えたら即座に送信量を半減させ、原因調査（リスト品質・コンテンツフィルタ・ブラックリスト登録）を行う。

7. 運用・監視・コスト最適化

7-1. SES 送信メトリクスと CloudWatch 監視設計

Amazon SES は送信イベントを CloudWatch の AWS/SES 名前空間へ自動発行する。VDM（Virtual Deliverability Manager）を有効化すると Configuration Set 単位で次のメトリクスが計測される。

AWS が定める運用上の推奨閾値

• バウンス率: 5% 未満（2% 超で「要注意」、10% 超でアカウント送信一時停止リスク）
• 苦情率: 0.1% 未満（0.08% 超で「要注意」、0.5% 超で高リスク）

バウンス率・苦情率は Bounce/Send、Complaint/Send の比率で算出する。CloudWatch の Metric Math を使い、アラームを直接比率に設定できる。

# 苦情アラーム例（苦情件数 20件/時間 超で警告）
aws cloudwatch put-metric-alarm \
  --alarm-name ses-complaint-rate-high \
  --namespace AWS/SES \
  --metric-name Complaint \
  --statistic Sum \
  --period 3600 \
  --threshold 20 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --treat-missing-data notBreaching

Configuration Set 単位でのメトリクス分離

transactional（注文確認・パスワードリセット）と marketing（プロモーション）は別の Configuration Set に分離する。バウンス率が marketing 側で上昇しても transactional の到達性へ影響しないよう、評判スコアを切り離すのが原則。

# 送信時に Configuration Set を指定
aws sesv2 send-email \
  --configuration-set-name prod-transactional \
  --from-email-address sender@example.com \
  --destination '{"ToAddresses":["user@example.com"]}' \
  --content '{"Simple":{"Subject":{"Data":"注文確認"},"Body":{"Text":{"Data":"ご注文を承りました"}}}}'

サプレッションリスト管理

ハードバウンスが発生したアドレスは SES が自動的にサプレッションリストへ追加する。以後の送信は SES レベルでブロックされ、アカウントのバウンス率カウントから除外される。

7-2. End User Messaging の SMS/プッシュ メトリクス

AWS End User Messaging (SMS and Voice v2 API) が CloudWatch に発行するメトリクスは AWS/SMSAndVoiceV2 名前空間に集まる。

SMS メトリクス（代表）

プッシュ通知メトリクス（代表）

SMS の配信失敗が増加した場合は FailureCode ディメンションで原因を絞り込める。CARRIER_REJECTED（キャリア拒否）と INVALID_NUMBER（番号無効）は異なる対処が必要になる。

CloudWatch Logs Insights による詳細分析

End User Messaging は CloudWatch Logs 宛てにイベントを送信する設定が可能。ログストリームを Insights でクエリすると、特定の番号帯や時間帯に絞った失敗分析ができる。

fields @timestamp, messageId, messageStatus, isoCountryCode, destinationPhoneNumber
| filter messageStatus = "FAILED"
| sort @timestamp desc
| limit 100

7-3. 配信ログの永続化と分析基盤

SES は Configuration Set の「イベント送信先（Event Destination）」として複数のログ基盤を同時設定できる。

S3 への配信ログ保存と Athena 分析

-- バウンス発生率の日次集計（Athena）
SELECT
  DATE(from_iso8601_timestamp(mail.timestamp)) AS send_date,
  COUNT_IF(eventType = 'Bounce') AS bounce_count,
  COUNT(*) AS total_count,
  ROUND(COUNT_IF(eventType = 'Bounce') * 100.0 / COUNT(*), 2) AS bounce_rate_pct
FROM ses_events
GROUP BY 1
ORDER BY 1 DESC;

SNS によるバウンス・苦情のリアルタイム処理

# イベント送信先に SNS トピックを追加
aws sesv2 create-configuration-set-event-destination \
  --configuration-set-name prod-transactional \
  --event-destination-name bounce-complaint-sns \
  --event-destination '{
 "Enabled": true,
 "MatchingEventTypes": ["BOUNCE", "COMPLAINT"],
 "SnsDestination": {
"TopicArn": "arn:aws:sns:us-east-1:123456789012:ses-bounce-alert"
 }
  }'

SNS トピックをイベント送信先に設定し、Lambda サブスクリプションでバウンスアドレスをデータベースへ自動登録する構成が広く採用されている。バウンス発生後の再送防止ロジックをアプリ側に実装する手間を省ける。

7-4. コスト最適化の勘所

Amazon SES の料金体系

SMS コスト：国とオリジネータ種別によるコスト差

日本向け SMS は Sender ID を使う場合 $0.1435 / 通 前後となり、米国宛の約 20 倍のコストになる。月間送信量が少ない場合は Toll-free Number の方が総コストを抑えられることが多い。

プッシュ通知：End User Messaging vs SNS 直接呼び出し

大量プッシュ（月 1,000 万通超）が主用途の場合、SNS 直接呼び出しの方がコストメリットが出る。ただし End User Messaging はオプトアウト管理・配信ログ・CloudWatch 統合が標準で含まれるため、小〜中規模は End User Messaging で一元管理する方が運用コスト（人件費）を含めたトータルで優位になるケースが多い。

コスト最適化ガイドライン

1. EC2 または Lambda からの送信で無料枠 62,000 通/月を活用
2. 大量メールは SES + Kinesis Firehose + S3 の組み合わせで分析基盤を安く構築
3. SMS はキャンペーン登録費の月額コストを試算してから 10DLC か TFN かを決定
4. プッシュは月 500 万通未満なら End User Messaging で一元管理、それ以上は SNS を検討

7-5. 詰まりポイント集 — 現場で実際に詰まる 8 箇所

詰まりポイント①: サンドボックス解除申請が通らない

SES の本番アクセス申請でよく却下される理由は「バウンス・苦情への対処方法の記載が不足」。申請フォームには「バウンスを SNS で通知し Lambda でサプレッションリストへ自動登録する」「苦情は 24 時間以内に手動確認する」など、具体的なフローを英語で記述すること。「テスト用です」「少量だけ送ります」では高確率で却下される。

詰まりポイント②: DKIM 設定後も DNS 伝播を待つ間の確認方法

DKIM レコードを追加後に SES コンソールの「検証」ステータスが「保留中」のまま 48 時間以上経過することがある。dig で直接 CNAME レコードを確認し、TTL の残り時間を把握する。コンソールの「保留中」はキャッシュ問題で遅延する場合がある。dig で CNAME が正しく返ってきていれば実際には機能しているケースが多い。

dig +short <selector>._domainkey.example.com CNAME

詰まりポイント③: SMS 10DLC キャンペーン登録が拒否される

10DLC キャンペーンが拒否される最多原因は「Use Case の説明が薄い」こと。再申請前に以下を見直す。

• Use Case カテゴリが実際の送信内容（OTP / マーケティング / カスタマーケア）と一致しているか
• サンプルメッセージに「Message and data rates may apply. Reply STOP to opt-out.」が含まれているか
• 登録したブランドの EIN（米国法人番号）または DUNS 番号が正確か

再申請は通常 5〜10 営業日かかる。緊急時は Toll-free Number に切り替えて運用を継続しつつバックグラウンドで 10DLC を再申請するアプローチが現実的。

詰まりポイント④: APNs プッシュ証明書の期限切れを事前に検知できていない

APNs の p8 キー（.p8）は有効期限なし。一方、p12 証明書（.p12）は 1 年間有効で期限切れになると突然プッシュ送信が全停止する。対策: 新規は .p8 キーを使う。既存の p12 を使っている場合は証明書の有効期限を管理シートで管理し、90 日前にアラートを出す仕組みを作る。

詰まりポイント⑤: バウンス率が突然上昇した際の診断手順

1. CloudWatch の Bounce メトリクスをソフト/ハードに分解（SES イベントの bounceType を確認）
2. ハードバウンス増加 → リスト品質の問題。過去 6 ヶ月以上反応のないアドレスを削除
3. ソフトバウンス増加 → 受信側サーバーの一時障害または送信レートが高すぎる。送信レートを下げてリトライ
4. 苦情率も同時に増加している場合 → スパムフィルタにかかっている可能性。件名・本文・From アドレスを見直す

詰まりポイント⑥: End User Messaging で NumberValidateException が発生する

SendTextMessage API が NumberValidateException を返す場合、送信先番号の形式が E.164 形式（+ + 国番号 + 番号）になっていないことが多い。日本の番号は 090-xxxx-xxxx → +819xxxxxxxx に変換が必要（先頭の 0 を削除し +81 を付与）。

def to_e164_jp(phone: str) -> str:
 digits = phone.replace("-", "").replace(" ", "")
 if digits.startswith("0"):
  digits = digits[1:]
 return "+81" + digits

詰まりポイント⑦: サプレッションリストに入ったアドレスへ再送できない

SES のサプレッションリストに登録されたアドレスへの送信は、そのメールが「正常」でも拒否される。メール変更・誤登録等で再送が必要な場合はコンソールまたは CLI でリストから削除する。

aws sesv2 delete-suppressed-destination \
  --email-address user@example.com

削除後も 24 時間は内部キャッシュが残る場合があるため、即時性が必要な場合はサポートへ問い合わせる。

詰まりポイント⑧: VDM の数値と CloudWatch の数値が一致しない

VDM ダッシュボードの「開封率」「クリック率」は VDM 独自のピクセルトラッキング・リンクトラッキングを通じた計測値。CloudWatch の Open / Click メトリクスと集計タイミング・サンプリングアルゴリズムが異なるため完全一致はしない。SLA 定義にはどちらを正とするかを事前に決めておく。

8. まとめと移行ロードマップ

8-1. アンチパターン → 正解パターン

現場でよく見かける誤った設計と、その正解パターンを整理する。

アンチパターン① NG: Pinpoint を使って新規 SMS/プッシュ基盤を構築する

2025年5月20日以降、Amazon Pinpoint への新規機能追加・新規受付は停止している。2026年10月30日でサポートが完全終了する。今から Pinpoint で実装を始めると移行コストが二重にかかる。

正解 ✅: AWS End User Messaging（SMS and Voice v2 API）を使う

新規実装は必ず End User Messaging の v2 API から始める。既存の Pinpoint SMS API（pinpoint:SendMessages）と End User Messaging の v2 API（pinpoint-sms-voice-v2:SendTextMessage）は別物だが機能的には同等以上。

import boto3

client = boto3.client("pinpoint-sms-voice-v2", region_name="us-east-1")

response = client.send_text_message(
 DestinationPhoneNumber="+819012345678",
 OriginationIdentity="arn:aws:sms-voice:us-east-1:123456789012:phone-number/abc123",
 MessageBody="ご注文を受け付けました。",
 MessageType="TRANSACTIONAL",
 ConfigurationSetName="my-config-set",
)

アンチパターン② NG: バウンス率 10% 超をそのまま放置する

「送信数が少ないからまあいいや」と放置すると SES の評判スコアが下落し、アカウント全体の送信一時停止措置を受けるリスクがある。一度停止されると AWS サポートとのやり取りが必要になり本番サービスに深刻な影響が出る。

正解 ✅: 閾値アラームを設定し、ハードバウンスを自動でサプレッションリストへ登録する

SNS + Lambda の組み合わせでバウンス通知を受け取り、ハードバウンスのアドレスを即座にデータベースのオプトアウトリストへ追加する。次回の送信ジョブ実行時にオプトアウトリストと突き合わせてスキップする仕組みを作る。アラームは「バウンス率 2% 超で警告」「5% 超で緊急」の 2 段階が理想。

アンチパターン③ NG: 全メールを同一 Configuration Set で送信する

プロモーションメールのバウンス率上昇が、パスワードリセットや注文確認などトランザクションメールの到達性に影響する。

正解 ✅: transactional と marketing は別の Configuration Set に分離する

評判スコアのリスクを用途別に切り離すことで、marketing 側の問題が transactional に波及しない構成を作る。

アンチパターン④ NG: SES イベントの通知設定なしで運用する

バウンスや苦情が発生しても気づかず、評判スコアが静かに悪化する。スパムフォルダ送りになっても検知できない。

正解 ✅: SNS トピック経由でバウンス・苦情を即時通知する構成を最初に設定する

SES を有効化したら最初に行うべき設定は「Configuration Set の作成」と「SNS へのイベント送信設定」。運用開始後ではなく設定時から必ず有効にする。バウンス通知を Lambda で受け取り DB のオプトアウトフラグを自動更新する構成にしておくと再送事故を防げる。

アンチパターン⑤ NG: SMS のオプトアウト管理を自前実装する

STOP キーワードの受信・記録・応答・再送防止をすべて自前で実装しようとすると、TCPA コンプライアンスの抜け漏れリスクが高まる。実装コストも高い。

正解 ✅: End User Messaging の組み込みオプトアウト管理を使う

End User Messaging はオプトアウトリストを組み込みで管理する。OptOut リストに番号が登録されると、その番号への送信は自動的にスキップされる。STOP キーワードへの自動応答も組み込み機能として提供される。

# オプトアウトリストの作成
aws pinpoint-sms-voice-v2 create-opt-out-list \
  --opt-out-list-name my-opt-out-list

# 送信プール作成時にオプトアウトリストを紐付け
aws pinpoint-sms-voice-v2 create-pool \
  --origination-identity +15005550001 \
  --iso-country-code US \
  --message-type TRANSACTIONAL \
  --opt-out-list-name my-opt-out-list

アンチパターン⑥ NG: SPF/DKIM を設定するが DMARC は後回しにする

SPF と DKIM が設定済みでも DMARC がなければ、ドメイン偽装メールを受信側サーバーが拒否しない。Google・Yahoo の送信者ガイドライン（2024年〜）では月 5,000 通以上の大量送信者に DMARC 設定が必須要件となっている。

正解 ✅: 最初から DMARC p=quarantine で始め、段階的に p=reject へ引き上げる

DNS に DMARC レコードを追加し、まず p=none（監視モード）でレポートを収集。正規の送信経路を確認した後 p=quarantine → p=reject と段階的に強化する。

# DNS TXT レコード例（_dmarc.example.com）
v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.com; pct=100

8-2. まとめ

本記事では Amazon SES・AWS End User Messaging・Amazon Pinpoint の 3 サービスの再編を整理し、本番運用に必要な設計要素を解説した。

要点は 4 つ。第一に、Pinpoint は 2026年10月30日にサポート終了するため、SMS/プッシュは End User Messaging の v2 API へ、メールは SES へ、キャンペーンは Connect Outbound へ移行計画を立てること。第二に、SES は Configuration Set の分離・VDM の有効化・SNS によるバウンス即時通知を最初に整備することが安定運用の前提になる。第三に、SMS は国・オリジネータ種別・法規制が複雑に絡み合うため、10DLC 登録や TCPA 要件の確認を早めに着手すること。第四に、監視とコストは用途ごとに分離して計測することで、問題の早期発見とコスト最適化の両立が図れる。

8-3. Pinpoint 移行ロードマップ

Amazon Pinpoint を現在利用している場合は 2026年10月30日のサポート終了前に移行を完了させる必要がある。以下のロードマップを参考に段階的に移行する。

フェーズ 0: 現状棚卸し（〜2026年7月）

まず Pinpoint で何を使っているかを把握する。

棚卸し結果をスプレッドシートに記録し、用途別に移行優先度を付ける。

フェーズ 1: SMS/プッシュの移行（〜2026年8月）

End User Messaging の v2 API へは、SDK クライアント名と API エンドポイントを変更するだけで動作するケースが多い。

SDK の変更（Python 例）

# 変更前（Pinpoint API）
pinpoint = boto3.client("pinpoint")
pinpoint.send_messages(
 ApplicationId="abc123",
 MessageRequest={
  "Addresses": {"+819012345678": {"ChannelType": "SMS"}},
  "MessageConfiguration": {
"SMSMessage": {"Body": "テストメッセージ", "MessageType": "TRANSACTIONAL"}
  }
 }
)

# 変更後（End User Messaging v2 API）
eum = boto3.client("pinpoint-sms-voice-v2")
eum.send_text_message(
 DestinationPhoneNumber="+819012345678",
 OriginationIdentity="arn:aws:sms-voice:us-east-1:123456789012:phone-number/xxx",
 MessageBody="テストメッセージ",
 MessageType="TRANSACTIONAL",
)

プッシュ通知は APNs/FCM 証明書を End User Messaging に再登録する必要がある。Pinpoint に登録した証明書は End User Messaging には引き継がれない。

並行稼働テスト（2026年8月〜9月）

Pinpoint と End User Messaging の両方を同時に稼働させ、A/B テスト形式で配信確認を行う。配信成功率・到達時間・コストを比較し問題がなければ End User Messaging に完全切り替える。

フェーズ 2: メール送信の確認・最適化（〜2026年9月）

メール送信が SES の Email Identity（ドメイン ID）経由で既に送信されている場合、Pinpoint のメールチャネルは SES を裏側で使っているため移行コストは低い。SES の Configuration Set・VDM・イベント送信先が直接設定されているか確認する。Pinpoint の Analytics ダッシュボードでメール指標を見ていた場合は SES の VDM ダッシュボードに切り替える。

フェーズ 3: キャンペーン・ジャーニーの移行（〜2026年10月）

エンドポイントデータを Customer Profiles へインポートするには S3 経由の一括インポートまたは API での個別登録を使う。

フェーズ 4: 最終確認と Pinpoint 停止（2026年10月30日まで）

移行完了の確認チェックリスト:

• [ ] Pinpoint の全キャンペーンが「停止済み」または「移行済み」
• [ ] Pinpoint のメールチャネルを無効化済み
• [ ] End User Messaging の SMS/プッシュが本番稼働中
• [ ] SES の VDM・Configuration Set・イベント送信先が設定済み
• [ ] Connect Outbound Campaign で旧キャンペーンが再現済み
• [ ] Pinpoint のエンドポイントデータを Customer Profiles へエクスポート済み
• [ ] モニタリング・アラームが新基盤（CloudWatch + VDM）で動作中
• [ ] コスト確認（新基盤の月額が想定範囲内か）

2026年10月30日以降は Pinpoint コンソール・リソースへのアクセスができなくなる。データのエクスポートは必ず10月30日より前に完了させること。

移行でよくある落とし穴

落とし穴①: Pinpoint の APNs 設定をそのまま使い回せると思っている

End User Messaging への APNs 証明書の再登録が必要。Pinpoint に登録した証明書は自動引き継ぎされない。

落とし穴②: エンドポイント ID が変わることに気づいていない

Pinpoint のエンドポイント ID（UUID）は End User Messaging や Customer Profiles では使えない。アドレス（電話番号・デバイストークン）を共通キーにしてデータを突き合わせる。

落とし穴③: SDK のリージョン設定

End User Messaging はリージョンサポート範囲が Pinpoint と一部異なる。東京リージョン（ap-northeast-1）で Pinpoint を使っていた場合でも End User Messaging の一部機能はバージニア北部（us-east-1）でのみ提供されるため、リージョン設計を事前に確認する。