個人開発のメール送信サービス：ResendとSESの無料枠と到達率の検証結果

個人開発のメール送信サービスを無料枠で比較するなら、候補になりやすいのはResendとAmazon SESだ。Resendは月3,000通まで無料で、導入が軽い。Amazon SESは無料枠を過ぎた後の送信単価が非常に安く、大量配信では強い。一方で、最初から同じ使い勝手だと思って選ぶと、SESのサンドボックスという罠がある。

先に結論を言えば、認証メールや通知メールを少量送る個人アプリなら、まずResendを選ぶほうが運用は楽だ。送信量が増え、コストを1通単位で削りたい段階になったらSESが有力になる。ただし、到達率については「Resendなら届く」「SESなら迷惑メールに入る」と単純に決めつけられる話ではない。送信ドメインの設定、メール本文、ユーザーの携帯キャリア、バウンス処理まで含めて考える必要がある。

無料枠と料金だけなら、SESが圧倒的に安い

個人開発のメール配信で最初に気になるのは、結局いくらかかるのかという話だ。サービスの思想や管理画面の使いやすさも大切だが、収益化前のアプリでは月額費用がそのまま固定費になる。ユーザーが一人も増えていないのに、メール基盤だけが立派になっていく。個人開発では、これはあまり笑えない。

ResendとAmazon SESの料金構造を並べると、次のようになる。

Resendの無料プランは、月3,000通まで送信できる。ただし、月間の数字だけを見ていると、1日100通の制限を見落とす。認証メールを中心に送る小さなサービスなら問題になりにくいが、キャンペーン通知や定期レポートを同じ枠で送ると、月末ではなく特定の日に制限へ引っかかる可能性がある。

たとえば、一人のユーザーが登録時に認証メールを受け取り、パスワード再設定で1通、サービス通知で数通受け取る程度なら、3,000通はかなり余裕のある枠に見える。しかし、メールアドレスの入力ミスで再送を繰り返したり、バッチ処理が同じ通知を何度も送ったりすると、想定より早く消費する。メール送信は「1ユーザーにつき1通」とは限らない。失敗時の再送が、静かに通数を食べていく。

Amazon SESは、無料枠を過ぎた分について1,000通あたり0.10ドルという従量課金だ。送信数だけを考えれば、かなり安い。Resendの無料枠を超えたあと、月数千通から数万通へ伸びる段階では、SESの単価は魅力的に見える。

ただし、ここで古い情報に引っ張られるという罠がある。以前は、特定の条件でEC2経由の送信に大きな無料枠があるという説明が広く知られていた。しかし、2023年8月にAmazon SESの無料利用枠の条件は変更されている。現在の比較で、EC2を使えば恒久的に大量送信が無料になると考えるのは危険だ。

個人開発で必要なのは、最安値の料金表ではない。最初のユーザーを逃さず、実装と運用にかかる時間まで含めた総コストである。

SESは1通あたりの価格で勝つ。Resendは、開発者の時間を含めた総額で勝負している。

到達率はサービス名より、送信ドメインと運用で決まる

「到達率の高いメール送信サービス」を探すとき、サービス側の性能だけを比較したくなる。だが、ResendとSESのどちらを選んでも、送信したメールが必ず受信箱へ届くわけではない。到達率を100パーセントと断言できるサービスはないし、公式に同一条件で比較できる国内向けの到達率データも確認できない。

メールが届くまでには、送信サービス以外にも複数の判定がある。

• 送信元ドメインにSPF、DKIM、DMARCが設定されているか
• Fromアドレスのドメインと実際の送信経路に不自然な差がないか
• 過去の送信でバウンスや苦情が増えていないか
• 本文に迷惑メール判定を受けやすい表現やリンクがないか
• 受信側のメールサービスや携帯キャリアがどのように判定するか
• 認証メールを短時間に大量送信していないか

個人アプリでは、メールの本文を後から変更できるようにしておくことも重要だ。最初は認証リンクだけだったものが、いつの間にか広告やおすすめ情報を足していく。受信者からすると、必要な認証メールなのか販促メールなのかが曖昧になる。メール送信サービスを変えても、本文の設計が雑なら状況は改善しない。

Resendは、開発者向けの導入体験と送信ログの確認を重視したサービスだ。ドメイン認証を済ませ、APIから送信し、送信結果を管理画面で見るまでの流れが短い。送信失敗の原因を調べるとき、まず管理画面を開けばよいというのは、地味だが大きい。

一方、Amazon SESは、メール送信の基盤としての自由度と価格に強みがある。大量送信を安く処理する用途では非常に合理的だが、到達率を上げるための設定を自動的に肩代わりしてくれるわけではない。設定画面を眺めているだけで、受信者側の事情まで解決するような都合のよい話ではない。

日本のキャリアメールではResendに工夫がある

日本の個人向けサービスでは、Gmailや企業ドメインだけを見ていると判断を誤る。携帯キャリアメールを登録するユーザーが残っているからだ。docomo、au、SoftBankなどのキャリアメールでは、送信元サーバーがTLSに対応していない場合に、メールの到達が不安定になることがある。

Resendはこの問題に対して、投機的TLSという仕組みを導入している。受信側のサーバーがTLSに対応していない場合、自動的に平文送信へ切り替えることで、キャリアメールへの到達率低下を防ぐ考え方だ。

ここで注意したいのは、投機的TLSがあるからすべてのキャリアメールに届く、という意味ではないことだ。迷惑メールフィルター、受信拒否設定、ドメイン評価、本文内容などは別の問題として残る。とはいえ、日本向けの個人アプリでキャリアメールを無視できないなら、Resendを検討する理由にはなる。

Amazon SESでも、SPFやDKIMなどの基本設定を正しく行えば、安定したメール送信基盤を構築できる。ただし、キャリアメール向けの細かな状況を自分で把握し、ログを見ながら調整する必要がある。ここを自動化や外部サービスなしで全部面倒を見るのは、個人開発者にとってかなり重い。

Resendは早く動かすための選択、SESは仕組みを持つための選択

Laravelからメールを送る場合、どちらもSMTPやAPIを経由して組み込める。Laravelの通知機能やメール機能を使えば、アプリ側の呼び出しは比較的きれいに保てる。送信サービスを後から差し替える可能性があるなら、メール送信部分をアプリの各所へ直接書き散らさないほうがよい。

たとえば、会員登録処理の中でいきなり特定サービスのAPIを呼び出す設計にすると、後からSESへ移行するときに認証処理、請求処理、管理画面の通知など複数箇所を掘り返すことになる。最初は数行で済んだ実装が、サービス成長後には小さな沼になる。個人開発のコードは、こういうところで静かに負債化する。

Resendの導入では、一般に次の作業で送信まで進められる。

1. 送信元に使うドメインを登録する

2. DNSに指定された認証用レコードを追加する

3. Laravel側にAPIキーや送信元アドレスを設定する

4. 認証メールや通知メールを送信する

5. 管理画面で送信ログ、失敗、バウンスを確認する

セットアップの目安は10〜15分程度だ。もちろん、DNSの反映待ちやLaravel側の設定ミスがなければ、という条件付きである。DNSは人間の都合で動いてくれないので、画面を何度更新してもすぐ反映されるとは限らない。この程度の待ち時間は、個人開発では仕様として受け入れたほうが精神衛生に良い。

SESでは、AWS側で送信元の検証、リージョンの選択、認証情報の管理、サンドボックス環境の確認などが必要になる。送信を始めるだけなら難解というほどではないが、Resendに比べると判断する項目が多い。

さらに、SESの新規アカウントはサンドボックス環境に制限されている。初期状態では、24時間あたり200通、1秒あたり1通までの制限があり、不特定多数への配信も自由には行えない。検証済みの宛先にしか送れない状態になるため、一般ユーザー向けサービスを公開する前には本番アクセスの申請が必要になる。

この申請と審査待ちが、SESを選んだ個人開発者が最初に遭遇する理不尽な仕様になりやすい。アプリは完成している。メール送信コードも動いている。それでも本番のユーザーには送れない。AWSからすれば当然のスパム対策だが、開発者からすれば公開直前に新しい作業が増えることになる。

Laravelでは送信処理と業務処理を分ける

Laravelで認証メールや通知メールを送る場合、ユーザー登録処理とメール送信を完全に同期させる必要はない。送信サービスの応答を待っている間、画面を固めてしまうと、外部APIの一時的な遅延がユーザー体験に直結する。

キューを使ってメール送信を非同期化すれば、登録処理と送信処理を分けられる。もちろん、キューを使えばすべて解決するわけではない。ワーカーが止まっていればメールは送られないし、失敗したジョブを無限に再試行すれば、同じメールを何通も送る危険がある。

最低限、次のような設計は用意しておきたい。

• 同じイベントから重複メールを送らないための識別子
• 一時的な失敗と恒久的な失敗を分けた再試行設定
• 送信済み、失敗、バウンスの状態を確認できるログ
• 認証リンクの有効期限と再送間隔
• 管理者向けの異常通知

ResendでもSESでも、このアプリ側の責任は変わらない。メール送信サービスを採用した瞬間に、配送の問題がすべて外部化されるわけではない。サービスに預けられるのは送信基盤であり、メールを送るべき条件や、失敗したときの扱いまでは自分で設計する必要がある。

管理画面の差は、障害対応の時間に効いてくる

メール送信の実装中は、APIキーの設定やDNSレコードばかり気になる。しかし、サービスを公開した後に何度も見るのは管理画面だ。メールが届かないと連絡を受けたとき、最初に知りたいのは「そもそも送信処理が走ったのか」「送信サービスが受け付けたのか」「受信側で拒否されたのか」である。

Resendは標準のダッシュボードで、送信ログや分析結果を確認できる。開封率やクリック率を追う場合も、最初から確認しやすい。個人開発では、専用の分析基盤を構築するより、まず一つの画面で状況を見られることのほうが重要になる。

対してSESは、送信基盤そのものは安価だが、開封率やクリック率を確認するための標準ダッシュボードが用意されているわけではない。Configuration Set、SNS、Webhookなどを組み合わせ、自分でイベントを収集する必要がある。

もちろん、SESでも実現はできる。ただ、そのためにデータを保存し、集計し、管理画面へ表示する実装が増える。個人開発者が本当に欲しいのは、メールマーケティングの巨大な分析基盤ではなく、昨日からバウンスが増えていないか確認できる程度の情報かもしれない。それなら、最初から見える形で提供されているResendのほうが合理的だ。

ここでも、SESが悪いという話ではない。自前で制御したい人にとっては、イベント設計を自由にできることが利点になる。ユーザーごとの送信履歴、通知種別、再送回数、アカウント状態まで一つのデータモデルで扱いたいなら、SESの低い単価とAWS連携は強い。

ただし、個人開発の初期段階でそこまで作り込む必要があるかは別問題だ。分析機能を作っているうちに、肝心のサービス機能が完成しない。これも個人開発では定番の罠である。

メールの障害対応では、送信単価より「どこで止まったかをすぐ見つけられるか」が効く。

サンドボックス解除を後回しにすると、公開日に詰まる

SESを使うなら、サンドボックス環境を開発初期から意識しておく必要がある。ローカル環境で自分のメールアドレスに送信できたからといって、本番ユーザーへ送信できるとは限らない。

サンドボックスでは、送信先が検証済みアドレスに限定される。テスト用アカウントをいくつか用意して動作確認する段階なら問題ないが、公開後に不特定多数のユーザーへ認証メールを送る用途では制限がそのまま壁になる。

本番アクセスの申請では、どのようなメールを、誰に、どの程度送るのかを説明することになる。ここで曖昧な説明をすると、審査や追加確認に時間がかかる可能性がある。メールの用途を「登録確認」「パスワード再設定」「サービス内通知」のように分け、想定送信量と、バウンスや苦情への対応方針を整理しておくとよい。

送信量の見積もりも、単純な登録者数だけでは足りない。認証メールの再送、パスワード再設定、退会確認、管理者通知などを含める必要がある。さらに、メールが届かないユーザーへの再送導線を設けると、その操作が送信数を増やす。

たとえば、認証メールを1回送れば終わる設計ではなく、一定時間後に再送できるようにするなら、同一ユーザーが複数通を消費する前提で考えなければならない。送信上限を超えないように、再送ボタンへ待機時間を設けるのは、ユーザー体験のためだけではなく、コストと到達率を守るためでもある。

Resendの場合も、無料枠の1日100通という上限がある。SESのサンドボックスよりは扱いやすいが、無料だから無制限というわけではない。無料枠を選択理由にするなら、月3,000通と日次上限の両方をアプリの規模に当てはめるべきだ。

個人開発の規模ごとに選ぶなら

ResendとSESのどちらが優れているかを一つに決めるより、サービスの段階ごとに選ぶほうが現実的だ。

まず公開してユーザーの反応を見たい場合

この段階ではResendが扱いやすい。APIを組み込み、送信ログを確認し、エラーが出たら管理画面で追うという流れが短いからだ。個人開発では、メール送信基盤の構築そのものが目的ではない。ユーザー登録や課金、サービスの価値検証を進めるための部品である。

月3,000通、1日100通という制限に収まるなら、無料枠で始められる。初期のユーザー数が少ないサービスで、送信量より開発速度を優先するなら、料金差を気にしてSESへ寄せるメリットは大きくない。

AWSをすでに使っている場合

EC2やECS、CloudWatchなどをAWSで運用しているなら、SESを選ぶ理由は増える。請求をAWSにまとめられ、権限管理や監視も既存の仕組みに寄せやすい。大量送信を見越して、送信イベントを自前のデータ基盤へ集める設計なら、SESの自由度が生きてくる。

ただし、AWSを使っているからSESも簡単とは限らない。AWSの管理画面は、慣れている人には便利だが、初見では選択肢が多い。リージョンを間違え、検証したドメインと送信設定が別の場所にあり、権限エラーを追いかける。こういう作業に時間を使えるかどうかが分かれ目になる。

月数万通以上の送信が見えている場合

送信量が増えると、SESの従量課金が効いてくる。Resendの有料プランは月額20ドルで50,000通を含むが、メール送信の用途や分析機能まで必要かによって判断は変わる。

大量配信では、単価だけでなく、バウンスや苦情の管理も重要になる。送信量が増えるほど、無効なアドレスへ送り続ける問題や、受信者が不要なメールとして報告する問題が目立つ。SESを選んで料金を抑えても、送信制御と監視を作らなければ、別の場所で運用コストが膨らむ。

個人開発でありがちな失敗は、料金表の最安値だけを見て、運用の人件費をゼロとして計算することだ。自分の時間を無料扱いすると、ほとんどのサービスは安く見える。だが、障害対応の夜に管理画面がなく、ログを複数サービスから集めることになれば、その差額はすぐに消える。

キャリアメールを使うユーザーが多い場合

国内向けサービスでキャリアメールの利用者が無視できないなら、Resendの投機的TLSは検討材料になる。受信側のTLS対応状況に応じて送信方法を切り替える仕組みは、海外向けサービスだけを前提にした送信基盤とは違う視点だ。

ただし、キャリアメール対策はTLSだけで完了しない。ドメイン認証、送信元アドレス、本文のリンク、再送頻度、受信者側の個別設定まで影響する。サービス側で用意できるのは、届きやすい条件を整えるところまでだ。受信拒否設定をアプリ側から解除することはできない。

結局のところ、最初から移行前提で作ればよい

Resendを使い始めたあと、送信量や要件が変わってSESへ移行することはできる。逆も同じだ。最初から一生同じメール送信サービスを使うと決める必要はない。

移行しやすくするために、アプリ側では次のような線引きをしておくとよい。

• メールの内容はLaravelのMailableや通知クラスにまとめる
• 送信サービス固有のAPI呼び出しを業務ロジックに埋め込まない
• 送信元アドレスや返信先を環境変数で管理する
• メール送信の結果をアプリ側でも記録する
• 配信停止や無効アドレスを自分のユーザーデータと連携する
• 開発環境では本番ユーザーへ送らない仕組みを用意する

この設計なら、送信ドライバーを変えても、アプリの会員登録や通知処理まで書き直す必要はない。メール送信サービスを交換可能な部品として扱える。

一方で、完全な抽象化を目指して独自のメール基盤を作り込む必要もない。個人開発でありがちな「将来のための柔軟性」が、現在の実装を重くするという罠がある。ResendからSESへ移る可能性があるからといって、最初から巨大な送信管理システムを作る必要はない。

送信ログ、重複防止、再試行、バウンス処理。このあたりを押さえれば、移行の土台としては十分だ。細かい抽象化は、実際に困ってから追加すればよい。

選定の目安は、料金より先に運用負荷を見る

個人開発のメール送信サービスを選ぶとき、判断材料を整理するとこうなる。

1. 月3,000通、1日100通以内で収まるなら、Resendの無料枠が扱いやすい

認証メールや少量の通知メールを中心にするなら、導入時間と管理画面の見やすさが効いてくる。

2. 送信量が増え、単価を下げたいならSESが有力になる

無料枠を超えた分は1,000通あたり0.10ドルで、規模が大きくなるほど価格面の強みが出る。

3. 公開前にSESのサンドボックス解除を進める

24時間あたり200通、1秒あたり1通という初期制限は、一般公開後に気づくと手戻りになる。

4. 到達率をサービス名だけで判断しない

SPF、DKIM、DMARC、送信内容、バウンス、苦情、キャリアメール対策をまとめて見る必要がある。

5. 分析や障害対応を自分で作る余裕があるか考える

SESは自由度が高いが、開封やクリックの追跡にはConfiguration SetやSNS、Webhookなどの実装が必要になる。

6. Laravel側の送信処理を交換可能にしておく

サービス選びで悩み続けるより、切り替えられる構造を作って先に公開したほうが早い。

ResendとSESは、単純な上位互換と下位互換の関係ではない。Resendは開発者が早く使い始め、送信状態をすぐ確認するためのサービスだ。SESは、AWSの一部として大量送信を安く運用し、必要な仕組みを自分で組み立てるための基盤である。

個人開発の初期に必要なのは、最も安いメール配信ではなく、サービスを止めずに学習を続けられるメール配信だ。ユーザーが増え、送信量や分析要件が見えてきたら、その時点でSESへの移行を考えればよい。

結局のところ、コードで解決する部分と、運用でカバーする部分を分けることになる。SPFやDKIMの設定、再送制御、重複防止はコードと構成で固める。一方、受信者側のフィルターやキャリアメールの個別設定まで完全に支配しようとすると、個人開発の範囲を簡単に超える。

最初はResendで早く公開し、送信ログとバウンスを見ながら現実の利用状況を把握する。送信量が増え、コストと自前運用を引き受ける価値が出たらSESへ進む。この順番が、個人開発者にとっては一番泥臭く、そして失敗しにくい選び方だ。

Related reading: Cloudflare R2による個人開発アプリのDBバックアップ自動化とコスト削減.