同じ50,000通のメールが$5にも$66にもなる理由

料金差の理由

料金差はビジネスモデルの違い、つまりインフラかプラットフォームかに帰着します。Amazon SESは素のコンピューティングと帯域（インフラ）を販売しているのに対し、PostmarkやMailgunなどのプロバイダーは、より優れたUI、専門的なサポート、厳選されたIPプールを含むマネージドな体験（プラットフォーム）を販売しています。50,000通の場合、SESの従量課金では約$5ですが、Postmarkのプランでは$66に達することもあります。支払っているのは、運用負荷の軽減と、APIを取り巻くツールの品質に対してです。

単純計算：50,000通の場合

インシデントキューや毎月のクラウド請求書を見ていると、メール料金の格差は最も目を引く項目の一つです。その理由を理解するために、2026年9月時点の市場価格を見てみましょう。

インフラ型のアプローチ：Amazon SES

Amazon SESはコストの基準となる存在です。料金ページによると、従量課金での送信は1,000通あたり$0.10です。

• 計算：(50,000 / 1,000) * $0.10 = $5.00。

ただし、AWSは2026年7月21日に新しい段階的なプランを導入しました。Essentialsプランに移行すると、コストは1,000通あたり$0.16です。Proプランは1,000通あたり$0.22に加え、リージョンごとに月額$105の固定料金がかかります。Enterpriseプランは1,000通あたり$0.23に加え、月額$500です。小規模なプロダクトチームにとっては従量課金モデルが最も安価ですが、設定の負担はすべてエンジニアにかかります。

プラットフォーム型のアプローチ：PostmarkとMailgun

PostmarkやMailgunのようなプロバイダーは、開発者体験を重視しています。Postmarkの料金によると、基本プランは10,000通で月額$15です。超過料金は1,000通あたり$1.80〜$1.20です。

• 計算（Postmark）：$15（最初の1万通）+（40,000 / 1,000 * $1.20）= $15 + $48 = $63。（プランによっては$66に達します。）

同様に、Mailgunの料金は10,000通で月額$15からで、超過料金は1,000通あたり$1.80〜$1.10です。これらのプロバイダーはホスト型テンプレートやより直感的な分析機能を提供しており、独自のモニタリングダッシュボードを構築したくないチームにとっては、割高な料金に見合う価値があります。

現代的な中間層：Resend

Resendは現代的なプロダクトスタックをターゲットにしています。料金ページには、月3,000通（1日100通まで）の無料プランが記載されています。Proプランは50,000通で月額$20、超過料金は1,000通あたり$0.90です。

• 計算（Resend）：最初の50,000通まで定額$20。

受け付け、配信、受信トレイへの到達：決定的な違い

エンジニアリングドキュメントでよく見かける間違いの一つが、これら3つの用語を同じ意味で使うことです。これらは同じではなく、最後の段階を保証できるAPIは存在しません。

1. 受け付け：これはAPIのレスポンスです。エンドポイントにペイロードをPOSTすると、プロバイダーは202 Acceptedまたは200 OKを返します。これはプロバイダーがリクエストを受け取り、基本的なバリデーションを通過したことを意味するにすぎません。メールが外部に送り出されたことを意味するわけではありません。
2. 配信：これはSMTPのハンドシェイクです。プロバイダーは受信者側の受信サーバーにメッセージを引き渡そうとします。「配信済み」イベントは、受信サーバーが「これを受け取ります」と応答したことを意味します。
3. 受信トレイへの到達：これが最終的な行き先です。受信サーバー（Gmail、Outlookなど）が、メールを受信トレイ、プロモーションタブ、迷惑メールフォルダのどこに振り分けるかを決定します。これは受信者側の内部フィルター、送信者レピュテーション、認証レコードによって決まります。

配信の可能性を高めるには、DNSを正しく設定する必要があります。DNSチェッカーを使って、レコードが反映されていることを確認することをおすすめします。また、DKIM、SPF、DMARCのガイドにしっかり従い、自分が名乗るとおりの送信者であることを証明しましょう。

信頼性のためのエンジニアリング

メール送信は外部への副作用です。分散システムにおいて副作用は危険です。重複したり、気づかないうちに失敗したりする可能性があるからです。

冪等性の問題

メールAPIからのレスポンスを待っている間にアプリケーションサーバーがタイムアウトすると、メールが送信されたかどうかがわかりません。単純に再試行すれば、ユーザーには2通のメールが届きます。冪等キーが不可欠なのはこのためです。

冪等キーは、ヘッダーで送信される一意の識別子（通常はUUID）です。APIは同じキーを2回受け取ると、2通目のメールを送信する代わりに、最初に成功したリクエストのキャッシュ済みレスポンスを返します。

{ "idempotency_key": "req_8823_abc_123", "from": "notifications@example.com", "to": "user@gmail.com", "subject": "Your Order has Shipped", "body": "Your package is on the way!" }

エージェント主導の送信への対処

AIエージェントやMCPサーバーの普及に伴い、「エージェント間」（A2A）通信が増えています。エージェントに送信APIへの無制限のアクセスを与えるべきではありません。LLMがループに陥ると、50,000通のクォータを数分で使い果たし、送信者レピュテーションを台無しにしかねません。

エージェント向けに承認ワークフローを実装しましょう。

1. 下書き段階：エージェントがメールを生成し、pending_emailsテーブルに保存します。
2. ヒューマンインザループ：ユーザーまたは監督役のエージェントが内容をレビューします。
3. 実行：システムはstatus = 'approved'フラグが設定された後にのみAPIを呼び出します。

移行のための技術チェックリスト

高コストのプロバイダーから低コストのプロバイダーへ移行する場合（またはその逆の場合）、APIキーを差し替えるだけで済ませてはいけません。次のチェックリストを使いましょう。

• DNSの監査：SPFレコードを確認します。10回のルックアップ上限を超えていないことを確かめましょう。
• Webhookの対応付け：プロバイダーごとにイベント名は異なります。プロバイダーAのdeliveredをプロバイダーBのsentに対応付けます。
• サプレッションの同期：バウンスと苦情のリストをエクスポートします。新しいプロバイダーに50,000人のユーザーをインポートし、既知のバウンス先に送信すると、アカウントは即座に停止されます。
• レート制限への対処：429 Too Many Requestsエラーに対して指数バックオフを実装します。

エラー処理ロジックの例

async function sendWithRetry(payload, attempt = 1) { try { const response = await emailApi.send(payload); return response; } catch (error) { if (error.status === 429 && attempt <= 3) { const delay = Math.pow(2, attempt) * 1000; await new Promise(res => setTimeout(res, delay)); return sendWithRetry(payload, attempt + 1); } throw error; } }

適切なツールの選び方

プロトタイプを構築している個人開発者であれば、Resendの無料プランやSESの従量課金で十分です。重要度の高い複雑なトランザクションフロー（パスワードリセットや請求アラートなど）を管理するプロダクトチームであれば、プラットフォーム型プロバイダーの運用上の安全性には、$60の差額を払う価値があることが多いでしょう。

AIネイティブなアプリケーションを構築している場合、単なる送信経路以上のものが必要です。エージェントがコミュニケーション層とのやり取り方法を理解できるよう、MCPサーバーや構造化されたllms.txtファイルといったエージェント対応の仕組みが必要になります。ここで専門的なAPIは、単なるコストセンターではなく、戦力を何倍にも高める存在になります。

結局のところ、APIのコストは全体のごく一部にすぎません。本当のコストは、設定ミスのあるDNSレコードのデバッグや、サプレッション管理の不備が招いたレピュテーション危機の後始末に費やすエンジニアリング時間です。$5の道を選ぶにせよ$66の道を選ぶにせよ、メールを確実に届け続けるためのテレメトリとツールを優先しましょう。

開発者中心のメールインフラについて、詳しくはhttps://sendhq.ccをご覧ください。