Resend互換のメールAPI：互換性がカバーしない範囲

API互換性の本当の意味

For email developers, Resend-compatible mail APIs implement the same request and response schemas as the provider they replace. If you use a Resend-compatible API, you can change your base URL and API key in your environment variables and your POST /emails calls will still work. It covers the syntax of the payload, the HTTP status codes, and the structure of the JSON response. It does not cover your sender reputation, your DNS configuration, your IP warm up, or your billing structure.

インシデント対応を担うエンジニアとして、「互換性」があればワンクリックで移行できると思い込んでいるチームを見てきました。そうではありません。移行するのはインターフェースであって、インフラではないのです。

インターフェース：カバーされるもの

プロバイダーがResendとの互換性をうたう場合、通常はコアとなる送信エンドポイントを模倣しています。これにより、次のようなペイロードを送信できます。

{ "from": "onboarding@example.com", "to": "user@gmail.com", "subject": "Welcome to the App", "html": "<strong>Hello!</strong>" }

APIに互換性があれば、サーバーはメッセージIDとともに200 OKまたは201 Createdを返します。ここは「簡単な」部分です。連携ロジックを書き直したり、SDKを変更したりする必要がなくなります。AIエージェントを構築するチームにとって、この一貫性は不可欠です。エージェントがMCPサーバーやA2Aカード経由でメールを送信する場合、副作用（メールの送信）が実際に起きたことを確認するために、予測可能なスキーマに頼るからです。

インフラ：カバーされないもの

互換性はHTTPレイヤーで終わります。APIがリクエストを受け付けた後に起こることは、すべてプロバイダー固有です。

1. DNSとドメイン検証

APIキーにはドメインの認可は含まれていません。URLを切り替えるだけで、メールが認証されることを期待することはできません。新しいプロバイダーでドメインを再検証する必要があります。そのためには、新しいSPF、DKIM、DMARCレコードをDNSに追加します。

これらの更新を忘れると、新しいプロバイダーには代理で送信する権限がないため、メールは拒否されるか、迷惑メールとして判定される可能性が高くなります。切り替える前に、SendHQのメールDNSチェッカーを使って、レコードが正しく反映されていることを確認できます。

2. 送信者レピュテーションとIPのウォームアップ

レピュテーションは送信IPとドメインに結び付いています。あるプロバイダーから別のプロバイダーに移行すると、多くの場合、新しい共有IP群に移ることになります。ドメインのレピュテーションが非常に良好でも、新しいIPは「冷えた」状態かもしれませんし、さらに悪ければ、悪質な送信者と共有されているかもしれません。

プロバイダーによる受け付け（APIが「OK」と返すこと）は配信（受信側サーバーがメールを受け付けること）とは異なり、配信は受信トレイへの到達（メールがメインのフォルダに入ること）とも異なります。互換性がカバーするのはプロバイダーによる受け付けです。配信や受信トレイへの到達には何の効果もありません。

3. Webhookとイベントスキーマ

送信APIに互換性があっても、Webhookのイベント（delivered、bounced、complained）には互換性がないことがよくあります。配信イベントの追跡に基づいて後続のロジックを実行しているシステムでは、新しいプロバイダーのWebhookペイロードを監査する必要があります。あるシステムのbounceイベントが、別のシステムではhard_bounceかもしれません。

互換性のコスト：料金の実態

互換性があれば、全面的な書き直しのコストをかけずに、より良い料金を探せます。ただし、料金モデルは大きく異なります。2026年9月のデータに基づくと、次のとおりです。

• Amazon SES：最も攻めた料金です。à-la-carteでは1,000通あたり0.10 USDです（Amazon SESの料金）。2026年7月21日に導入された新しい料金プランには、Essentials（1,000通あたり0.16 USD）、Pro（1,000通あたり0.22 USDに加えてリージョンごとに月額105 USD）、Enterprise（1,000通あたり0.23 USDに加えて月額500 USD）があります。
• Resend：月3,000通（1日100通まで）の無料プランがあります。Proプランは月額20 USDで50,000通、超過分は1,000通あたり0.90 USDです（Resendの料金）。
• Postmark：月額15 USDで10,000通、超過分は1,000通あたり1.80〜1.20 USDです（Postmarkの料金）。
• Mailgun：月額15 USDで10,000通、超過分は1,000通あたり1.80〜1.10 USDです（Mailgunの料金）。
• SendGrid：無料プランは現在60日間のトライアルで、Essentialsは月額19.95 USDからです（SendGridの料金）。

具体的に言えば、50,000通の送信はSESのà-la-carteなら約5 USDですが、Postmarkのプランでは約66 USDです。API互換性があれば、1か月分のエンジニアリング作業をかけずにこうしたコスト最適化が可能になります。

信頼性とエージェントを考慮した設計

メールを外部への副作用として扱う場合、特にAIエージェントを使う場合は、失敗を考慮する必要があります。APIが200 OKを返しても、メールがユーザーに届いたことを意味するわけではありません。

冪等性

エージェントがタイムアウトによってリクエストを再試行すると、同じメールを2回送信するおそれがあります。これはユーザー体験を損ないます。ヘッダーで冪等キーを使用してください。これにより、同じリクエストが2回送られても、プロバイダーが送信するメールは1通だけになります。

承認ワークフロー

エージェントに送信クォータへの無制限のアクセスを与えるべきではありません。大量送信には承認レイヤーを導入してください。エージェント主導のメールのための簡単なチェックリストは次のとおりです。

1. スキーマの検証：ペイロードが互換APIの仕様に一致しているか。
2. レート制限：エージェントが1日あたりの上限（例：Resendの無料プランの1日100通）を超えていないか。
3. 冪等性：この特定のトランザクションに一意のキーがあるか。
4. ヒューマン・イン・ザ・ループ：このメールは、API呼び出しの前に手動での承認が必要か。

移行チェックリスト

Resend互換のプロバイダーに移行する場合は、配信の崩壊を避けるため、次の順序で進めてください。

• DNS設定：SPF、DKIM、DMARCを設定します。レコードの漏れがないことを確認するには、メール認証のガイドをお読みください。
• 検証：ツールを使用してDNSの反映を確認します。
• ウォームアップ：大量に送信する場合は、トラフィックを旧プロバイダーから新プロバイダーへ徐々に移行します。1時間でトラフィックの100%を移行しないでください。
• Webhookの監査：新しいプロバイダーのイベントタイプを内部データベーススキーマにマッピングします。
• エラー処理：新しいプロバイダーが無効なメールアドレスをどのように処理するかテストします。400を返しますか、それとも後続のバウンスイベントを伴う202を返しますか？

トレードオフのまとめ

項目 | 互換性でカバーされるか | 必要な対応

リクエストのペイロード | はい | なし（仕様が一致する場合）

レスポンスの形式 | はい | なし（仕様が一致する場合）

ドメイン認証 | いいえ | DNSレコードを更新

IPレピュテーション | いいえ | ウォームアップ期間

料金／クォータ | いいえ | 各社の料金ページを確認

Webhookイベント | いいえ | イベントリスナーを更新

互換性は機敏さのためのツールであり、到達率を魔法のように解決する杖ではありません。インターフェースとインフラを切り離すことで、単一ベンダーのエコシステムに縛られることなく、コストとパフォーマンスを最適化できます。

このインフラを簡素化する、プライバシーに配慮した最小限の設計でエージェントに対応したメールAPIについては、SendHQをご覧ください。