先日、Amazon SES のサンドボックス解除（Production Access）申請を英語のケースで開いたところ、5 日間まったく一次返信が返ってこない状態にぶつかりました。
最終的には日本語で別ケースを立てて動かし、無事に本番アクセスが下りたのですが、その過程で「AWS のサポートケースは英語より日本語のほうが早いこともある」という現場の肌感覚が得られたので、共有します。
前提として、対象のアカウントは AWS サポートプラン の Basic （無料）契約です。Basic には返信時間の SLA が明示されていないため、そもそも返信タイミングは AWS 側のキュー状況に左右される側面があります。
起きたこと: 英語ケースが 5 日間ノーレスで止まった
やったことはシンプルで、Amazon SES 送信クォータの引き上げ の Production Access リクエストをそのまま英語のケースとして提出しました。
このとき、正直に言うと Production Access フォームの必須項目（Mail Type、Website URL、リージョン、リクエスト内容）だけを埋めて送ってしまいました。
2 時間後くらいに、AWS 側から「ユースケースをもう少し詳しく」というテンプレ返信が届き、そこで初めて以下のような補足情報を返しました。
- ユースケース（招待制の B2B アプリケーションのトランザクショナルメール、Cognito 由来の招待・パスワードリセット・確認コードのみ）
- 送信量の目安（通常 50 通/日 未満、セキュリティ診断中は数百通/日）
- 送信元ドメイン ID の検証状況（DKIM RSA 2048、SPF、カスタム MAIL FROM ドメインをすべて設定済み）
- Terraform で Route 53 に DNS レコードを管理していること
- バウンス・苦情の監視方法
そして、そこから 5 日間、まったく続報が来ませんでした。
途中でリマインドを投げても、既存ケースに反応する動きはなし。Basic プランなので SLA を盾に催促することもできず、宙ぶらりんの状態です。
反省点: 初回メッセージで情報を出し切っておくべきだった
先に反省点を書いておくと、5 日間の空白を招いた最大の要因は、初回リクエスト時にフォームの必須項目しか埋めなかったこと だったと今は思っています。
Production Access のような案件では、AWS 側はほぼ確実に一次審査でユースケースの詳細を追加要求してきます。ここで顧客側からの追加返信を挟むと、ケースのステータスが「顧客からの追加情報待ち」を経てから改めてキューに並ぶ動きになり、実質的に順番が後ろに下がっている可能性があります。もし最初から必要十分な情報を書き切っていれば、この往復自体が発生せず、そもそも 5 日間空白は生まれなかったかもしれません。
振り返ると、初回メッセージで書き切っておきたかった内容は以下です。
- ユースケース（B2B / B2C の別、招待制かオープンサインアップか、トランザクショナル・マーケティングの別、送信トリガー）
- 想定送信量（通常時のピーク、想定される最大バースト）
- 送信元ドメイン ID の検証状況（DKIM・SPF・カスタム MAIL FROM の設定と検証結果）
- 受信者リストの管理方法（管理者による招待のみか、公開サインアップかなど）
- バウンス・苦情の監視方法と、SES アカウントレベルサプレッションリストの運用方針
同じ Production Access を再度出す機会があれば、これらは初回 submit の時点でまとめて書くようにします。
打った手: 日本語で別ケースを立てて「元のケースが動いていない」ことを報告する
そこで打ったのは、元のケースを直接催促するのではなく、別ケースを日本語で新規に立てて、そこから元ケースが 5 日間放置されている旨を伝えるという動き方です。件名も「SES: Production Access のケースが 5 日間全く返信がない」のように率直な表現にしました。
別ケースを立てるときのポイントは以下です。
- 元ケースの Case ID を本文に明記し、AWS 側が該当ケースを一発で引き当てられるようにする
- 業務上の期限（例: 「本番リリース日が確定しているので、可能であれば翌営業日中に有効化してほしい」）を具体的に書く
- 妥協点を先に提示する（「最小の送信クォータでも構わない」「後で再申請する前提でも構わない」など、担当者が判断しやすくする材料を渡す）
この別ケースを立てたのが夜間で、翌朝には元の英語ケースのほうに Production Access 承認の通知が届きました。送信クォータ 50,000 通/日・14 通/秒でサンドボックスも解除、というフルスペックの回答でした。
現場での学び: 言語選択とサポートプランで動線が変わる
この一連の流れから、いくつか実務的な学びが得られました。
1. 英語ケースはグローバルチームに回りやすく、日本語ケースは日本のチームに寄りやすい
英語で書いたケースは、担当するオペレーションチームがグローバルに散らばる可能性が高くなります。タイムゾーンやキュー状況によっては、単純に日本のオフィスアワーに合わせて誰かがすぐ拾ってくれるとは限りません。
一方で日本語ケースは、担当が日本のチーム側に寄る傾向があるようで、社内のエスカレーションパスもそのぶん短く見えます。「英語のほうがどこか国際的に早そう」というイメージとは逆に、日本発のケースに関しては日本語で書いたほうが、体感的にはレスポンスが早いことがあります。
これはあくまで憶測ですが、英語ケースは全世界のユーザーからの問い合わせが乗ってくるため、単純に母集団が大きく待ち行列も長くなりがちです。それに対して日本語ケースは相対的に少数派で、キューの中では「早めにさばける案件」として扱われやすいのかもしれません。同じ AWS のサポート窓口でも、投げ込む言語を変えるだけで実質的な優先度が変わっている可能性は、Basic プランで運用していると意外と実感します。
2. 詰まったケースは「同じケースへの催促」より「別ケースからの参照」のほうが動きやすい
同じケースに追い返信を積んでも、ケース単位でのステータスが変わらないため、キューの並び順自体は変化しにくい印象です。それより、別ケースを新しく立てて「元ケースのステータスがおかしいので確認してほしい」という形にしたほうが、案件そのものが担当者の目に触れる確率が上がります。
このとき、日本語と英語の両方でケースを分けて上げておくと、たまたまタイミングが良い担当者に拾ってもらえる可能性があります。特に急ぎ度が高い案件では、この二枚立ては有効なリスクヘッジになります。
3. Business Support+ 以上は正式なエスカレーションパスを持つ
Basic では明示的な優先対応の窓口はありませんが、Business Support+ 以上 のプランに加入していると、Limit increase のような案件について、正式に優先対応をリクエストする内部パスが用意されています。
SES の Production Access に限らず、ec2 の vCPU 上限、ses の日次送信数、lambda の同時実行数など、「本番稼働の直前に急ぎで通したい」タイプの申請は、想定より時間がかかるケースがあります。
- 本番リリースに向けて限界枠の緩和を控えているプロジェクト
- 外部監査・セキュリティ診断のスケジュールが動かせないプロジェクト
- 顧客先環境の商用開始日が確定しているプロジェクト
このいずれかに該当するアカウントを Basic で運用しているなら、Business Support+ 以上への一時的なアップグレードは、体感の安心感がかなり違うはずです。個人・小規模チームで常時契約するのは負担が大きいですが、キックオフから本番稼働までの数か月だけプラン変更しておくのは、コストパフォーマンスの高い運用だと感じます。
Basic でも「言語」と「ケースの立て方」で粘れる
まとめると、Basic プランで AWS サポートに Production Access のような案件を投げるとき、現場でできることは大きく次のとおりです。
- 初回メッセージの時点で、ユースケース・想定送信量・ドメイン検証状況などを書き切り、AWS 側からの追加情報依頼を挟ませない
- それでも止まってしまった場合、元ケースが英語で開かれているなら、日本語で別ケースを新規に立てて、元ケースの状況を報告する
- 業務上の期限と妥協点をセットで書き、担当者が判断しやすい情報を先に渡す
- 本番リリースを控える案件では、Business Support+ 以上への一時的アップグレードも選択肢に入れる
「英語で書いたほうがちゃんと届きそう」という思い込みは、少なくとも日本のリージョン・日本のドメイン・日本の担当者と付き合うプロダクトに関しては、必ずしも正しくないのだと今回強く感じました。日本語で書けるケースは、素直に日本語で書いてよいのかもしれません。
以上、英語で 5 日間動かなかった SES Production Access のケースを日本語の別ケースから動かして解決した、現場からお送りしました。