結論(おすすめ1つ)
Resend に乗り換えることを勧める。
Mailchimp Transactional(旧 Mandrill)はマーケティング機能とバンドルされた価格体系に依存しており、トランザクションメール単体で使うには過剰な構成になりがちだ。Resend は REST API 設計がシンプルで公式 SDK の品質が高く、ドメイン認証から初回送信まで30分以内に完了できる。Next.js・Remix・Node.js といった現代的なスタックとの統合コストが最も低い。
比較表(料金/無料枠/移行コスト/対応言語)
| サービス | 無料枠 | 有料料金 | 移行コスト | 主要 SDK |
|---|---|---|---|---|
| Resend | あり(公式の料金ページで要確認) | 公式の料金ページで要確認 | 低:API キー1本 + SDK | Node/Python/Go/Ruby/PHP/Rust |
| SendGrid | あり(公式の料金ページで要確認) | 公式の料金ページで要確認 | 中:SMTP ラッパーまたは HTTP API | Node/Python/Go/Ruby/PHP/Java/C# |
| Postmark | サンドボックスのみ(本番送信は有料) | 公式の料金ページで要確認 | 低:Mandrill 構文と近い | Node/Python/Go/Ruby/PHP/.NET |
| AWS SES | あり(EC2 内からの送信条件あり) | 公式の料金ページで要確認 | 高:IAM/DKIM/設定セット設定が必要 | AWS SDK 全言語 |
| Mailgun | トライアル期間あり(制限あり) | 公式の料金ページで要確認 | 中:SMTP または HTTP API | Node/Python/Go/Ruby/PHP/Java |
注意: 無料枠の上限・料金単価はサービスが頻繁に変更する。必ず各社の公式料金ページで最新情報を確認すること。
移行手順
1. Resend アカウント作成とドメイン認証
Resend のダッシュボードでドメインを追加し、表示される DNS レコード(SPF・DKIM・DMARC)を自社ドメインの DNS に登録する。反映には最大48時間かかる場合がある。
2. SDK インストール
# Node.js
npm install resend
# Python
pip install resend
# Go
go get github.com/resend/resend-go/v2
3. 環境変数の設定
# .env または CI/CD シークレット
RESEND_API_KEY=re_xxxxxxxxxxxxxxxxxxxxxxxx
4. 既存の Mailchimp Transactional 呼び出しを置き換える
Before(Mailchimp Transactional / Mandrill)
// 旧実装イメージ
const mandrill = require('mandrill-api/mandrill');
const client = new mandrill.Mandrill(process.env.MANDRILL_API_KEY);
client.messages.send({
message: {
to: [{ email: 'user@example.com', type: 'to' }],
from_email: 'noreply@yourdomain.com',
subject: '注文確認',
html: '<p>ご注文ありがとうございます</p>',
},
});
After(Resend)
import { Resend } from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);
await resend.emails.send({
from: 'noreply@yourdomain.com',
to: ['user@example.com'],
subject: '注文確認',
html: '<p>ご注文ありがとうございます</p>',
});
5. 送信ログ・Webhook の再設定
Resend ダッシュボードの「Webhooks」から email.delivered / email.bounced / email.complained イベントを既存のエンドポイントに向け直す。Mandrill の Webhook ペイロード構造とは異なるため、受信側のパース処理も変更が必要。
// Webhook 受信例(Express)
app.post('/webhook/resend', express.json(), (req, res) => {
const { type, data } = req.body;
if (type === 'email.bounced') {
// バウンス処理
}
res.sendStatus(200);
});
6. 動作確認
# curl で直接テスト
curl -X POST https://api.resend.com/emails \
-H "Authorization: Bearer $RESEND_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "test@yourdomain.com",
"to": ["you@example.com"],
"subject": "移行テスト",
"html": "<p>動作確認</p>"
}'
向き不向き
Resend が向くケース
- Next.js / Remix / SvelteKit などモダンフレームワーク中心のチーム
- 開発者が自分でトランザクションメールをコードで管理したいスタートアップ・小規模チーム
- テンプレートを React コンポーネント(React Email)で管理したい場合
- Mailchimp の営業・マーケ機能を一切使っておらず、API 送信だけが目的の場合
SendGrid が向くケース
- 送信量が大規模でスケールの実績が必要な場合
- Java / C# / .NET が主要言語のエンタープライズ環境
- マーケティングキャンペーンとトランザクションを同一プラットフォームで管理したい場合
Postmark が向くケース
- 到達率・スピードを最優先する SaaS(パスワードリセット・認証コード等)
- Mandrill から最小差分で移行したいチーム
AWS SES が向くケース
- すでに AWS インフラに深く統合されており、コスト最小化が最優先の場合
- 送信量が非常に多く、単価の低さが収益に直結するケース
避けるべきケース
- Resend: 送信量が大規模になったときの上限コストは公式で必ず確認すること。大量送信用途での実績がまだ SendGrid ほど豊富ではない
- AWS SES: インフラ管理リソースが少ないチームや、プロダクション前に素早く動かしたい場合は初期設定の複雑さがボトルネックになる
- どのサービスも: ドメイン認証(SPF・DKIM・DMARC)を省略したままにすると到達率が低下するため、移行時に必ず設定を完遂すること
Top comments (0)