先に要点
生成AIに「アプリからメールを送りたい」「Next.jsで確認メールを送りたい」「Laravelのパスワードリセットを外部サービスで送りたい」と聞くと、Resend が候補に出ることがあります。
昔なら SendGrid、Mailgun、Amazon SES、Postmark あたりがよく出てきましたが、最近の開発者向け回答では Resend もかなり見かけます。
Resendは、普通のメールソフトの代わりではありません。
人がメールを書くためのサービスというより、アプリケーションが自動でメールを送るための送信基盤です。登録確認、ワンタイムリンク、パスワードリセット、請求通知、管理者向けアラートのようなメールで使われます。
この記事では、2026年4月18日時点で Resend公式サイト、公式ドキュメント、料金ページ、Laravel SDKの公式リポジトリを確認しながら、Resendとは何か、AIがなぜ勧めやすいのか、実務でそのまま採用してよいのかを整理します。
Resendとは何か
Resendは、開発者向けのメール送信サービスです。
公式サイトでは、トランザクションメールとマーケティングメールを送るためのサービスとして紹介されており、Node.js、Python、PHP、Go、Java、REST、SMTPなど複数の連携方法が示されています。
アプリ側から見ると、Resendは次のような役割を持ちます。
- メール送信用のAPIを提供する
- SMTP Relayとして既存のメール送信設定から使える
- 送信ドメインの認証設定を管理する
- 送信結果やイベントをログで見やすくする
- Webhookで配信、開封、クリック、バウンスなどを通知する
- React Emailのような開発者向けメールテンプレートと組み合わせやすい
つまり、Resendは メールアカウント ではなく アプリのメール送信基盤 と考えると分かりやすいです。
AIがResendを勧めやすい理由
AIがResendを勧めるのは、単に流行っているからだけではありません。
生成AIの回答として、説明しやすい性質がいくつかあります。
1. コード例が短く書ける
Resend公式のAPIドキュメントでは、from、to、subject、html のような分かりやすいパラメータでメール送信例が示されています。
AIにとっても、短いコード例として回答しやすいです。
たとえば、概念としては次のような形です。
const { data, error } = await resend.emails.send({
from: 'Acme <onboarding@example.com>',
to: ['user@example.com'],
subject: 'Welcome',
html: '<p>Thanks for signing up.</p>',
});
これは読みやすい反面、AIの回答では重要な前提が省略されがちです。
実際には、送信元ドメインの認証、APIキー管理、環境変数、エラー処理、再送、ログ確認、利用規約、料金上限を見なければなりません。
2. Next.jsやReact Emailとの相性を説明しやすい
ResendはReact Emailとの関係が強く、公式サイトでもReactでメールテンプレートを書く流れが紹介されています。
Next.js、Vercel、Reactまわりの相談をAIに投げると、Resendが自然に候補へ入りやすいです。
これはAIの文脈ではかなり大きいです。
AIは「Next.jsでフォーム送信したい」「サーバーアクションでメールを送りたい」のような質問に対して、コード例まで出しやすいサービスを選びがちです。
3. 自前SMTPより話を単純にしやすい
VPSから直接メールを送る場合、SPF、DKIM、DMARC、逆引きDNS、IPレピュテーション、ブラックリスト、バウンス管理などを見なければなりません。
AIが初心者向けに答えると、このあたりを全部説明するより、ResendのようなメールAPIを勧めた方が回答がすっきりします。
ただし、ここが落とし穴でもあります。
Resendを使っても、メール配信の現実が消えるわけではありません。自前SMTPの重い運用を避けやすくなるだけで、送信ドメインの信頼性やメール本文の品質は引き続き重要です。
何に使うサービスなのか
Resendが向いているのは、アプリが自動で送るメールです。
このようなメールは、まとめてトランザクションメールと呼ばれることがあります。
| 用途 | Resendとの相性 | 見るポイント |
|---|---|---|
| 登録確認メール | 相性がよい | 到達率、再送、リンク期限、ログ |
| パスワードリセット | 相性がよい | 重要メールなのでエラー検知が必要 |
| 問い合わせ通知 | 小規模なら候補 | 共有SMTPでも十分な場合がある |
| 請求・決済通知 | 相性がよい | 送信ログ、再送、監査性 |
| ニュースレター | 要件次第 | 配信停止、同意、リスト管理、料金 |
| 普段の会社メール | 別サービスの方が自然 | Google WorkspaceやMicrosoft 365の領域 |
Resendを使うべきか迷ったら、人が送るメールか、アプリが自動で送るメールか をまず分けると判断しやすいです。
Resendが強いのは後者です。
APIとSMTPの違い
ResendはAPIでもSMTPでも使えます。
公式のSMTPドキュメントでは、ホストに smtp.resend.com を使い、ユーザー名に resend、パスワードにAPIキーを使う形が案内されています。
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| API | 新規アプリ、送信結果やエラーを細かく扱いたい場合 | SDKやHTTPクライアントの実装が必要 |
| SMTP | 既存フレームワークのメール設定へ載せたい場合 | SMTPサーバーログの見え方やデバッグ範囲を確認する |
どちらが常に正解というわけではありません。
Laravelの標準メール機能に乗せたい、既存実装をあまり変えたくない、という場合はSMTPの方が始めやすいことがあります。一方で、送信結果をアプリ側で扱いたい、イベントやテンプレート管理まで寄せたいならAPIが向きます。
Laravelで使いやすいのか
LaravelでもResendは使えます。
公式の resend-laravel リポジトリでは、Laravel mailerとして使える構成が案内されており、MAIL_MAILER=resend を設定する例も示されています。
Laravelアプリで考えるなら、最初の候補は次の2つです。
- LaravelのMailerに乗せて、既存のMailableや通知処理に寄せる
- ResendのAPIを直接呼び、送信結果やエラーをアプリ側で管理する
実務では、まずLaravelのメール機能に寄せる方が移行しやすいことが多いです。
ただし、ログや再送、Webhook連携まで設計するなら、Resend側のイベントとアプリ側の送信履歴をどう対応させるかも決めておく必要があります。
料金と無料枠を見るときの注意
2026年4月18日時点のResend公式料金ページでは、Freeプランに月3,000通、1日100通、1ドメインの枠が示されています。
Proは月50,000通で月額20ドル、Scaleは月100,000通で月額90ドルとして掲載されています。
ただし、料金は変わりやすい情報です。
記事を読んだ時点では必ず公式料金ページを確認してください。
料金を見るときは、月額だけでなく次も確認します。
小規模なら無料枠で試せることがありますが、本番の認証メールが止まると困る場合は、無料枠前提のまま運用しない方が安全です。
Resendを使う前に確認すること
AIに「Resendを使えばいい」と言われても、次の確認は省略しない方がよいです。
1. 送信ドメインを分けるか
普段の会社メールとアプリ送信用メールを同じドメインで扱うか、サブドメインで分けるかを決めます。
たとえば、会社メールは example.com、アプリ送信は mail.example.com や notify.example.com のように分けることがあります。
分けると設定は少し増えますが、運用や評判の影響範囲を分けやすくなります。
2. SPF、DKIM、DMARCを設定できるか
メール送信サービスを使っても、DNS設定は必要です。
SPF、DKIM、DMARCは、送信元の正当性やなりすまし対策に関わります。
DNSを触れない、ドメイン管理者が別にいる、既に別サービスのメール設定が複雑、という場合は、Resendの導入自体よりDNS調整で詰まることがあります。
3. エラー時の扱いを決めているか
メール送信は失敗します。
宛先が間違っている、受信側に拒否される、API制限に引っかかる、テンプレート変数が足りない、APIキーが無効になる、といったケースがあります。
本番では、次を決めておきます。
4. マーケティング配信と混ぜないか
パスワードリセットのような重要メールと、キャンペーンメールを同じ感覚で送るのは危険です。
配信停止、同意、送信頻度、苦情率が絡むため、用途ごとに分けて考えた方が安全です。
Resendはマーケティングメールにも対応していますが、初心者がまず見るべきなのは アプリの重要メールを確実に送るための基盤 としての使い方です。
AIにResend設定を聞くときの聞き方
AIに相談するなら、次のように前提を渡すと事故が減ります。
Laravelアプリから登録確認メールとパスワードリセットメールを送りたいです。
メール送信サービスとしてResendを検討しています。
ドメインは example.com で、アプリ送信用に mail.example.com を使う想定です。
LaravelのMailerに寄せたいので、SMTPではなく公式Laravel SDKまたはmail transportの使い方を知りたいです。
DNS設定、SPF/DKIM/DMARC、.env、送信失敗時のログ、Webhookで見るべきイベントも含めて整理してください。
雑に「Resendの使い方を教えて」だけだと、AIはコード例だけを返しがちです。
本番で必要なのは、コードよりも、ドメイン認証、秘密情報管理、失敗時の扱い、ログ、料金上限まで含めた設計です。
よくある誤解
Resendを使えば必ず迷惑メールに入らない
入りにくくするための仕組みはありますが、保証ではありません。
送信ドメインの認証、本文、宛先リスト、送信頻度、受信側の評価が絡みます。
Gmailや会社メールの代わりになる
Resendは、普段のメールボックスとして使うものではありません。
アプリからメールを送るための基盤として見る方が自然です。
無料枠ならずっと無料で本番運用できる
小規模なら試せますが、送信数や日次上限にぶつかる可能性があります。
認証メールや決済通知のような重要メールでは、上限到達時の影響も考える必要があります。
AIが勧めたから標準解だと思ってよい
AIは、説明しやすく、コード例が出しやすく、最近の開発者文脈に合うサービスを勧めがちです。
それは候補として有用ですが、自社のメール量、既存ドメイン、運用体制、サポート要件に合うかは別問題です。
まとめ
Resendは、アプリからメールを送るための開発者向けメールAPIです。
登録確認、パスワードリセット、通知メールのようなトランザクションメールと相性がよく、API、SMTP、公式SDK、Webhook、React Email連携などがそろっています。
AIがResendを勧めやすいのは、コード例が短く、Next.jsやLaravelなどの開発文脈に乗せやすく、自前SMTPよりも説明を単純にしやすいからです。
ただし、Resendを使えばメール運用の問題が全部消えるわけではありません。
本番で使うなら、送信ドメイン、SPF、DKIM、DMARC、ログ、Webhook、再送、料金上限、用途分離まで見ます。
Resendは便利な候補ですが、AIの提案をそのまま採用するのではなく、アプリの重要メールをどう安全に運用するか という視点で判断するのが大事です。
参考リンク
- Resend公式: Email for developers
- Resend Docs: Send Email API
- Resend Docs: Send emails with SMTP
- Resend: Pricing
- GitHub: resend/resend-laravel
- Resend: Open Source / Official SDKs