「SendGridからResendへの移行はどう進めればいいのか」「ダウンタイムなしで切り替えできるのか」と悩んでいる方は多いはずです。株式会社Fyveでは、2026年6月に建設業のクライアントのコーポレートサイト（Next.js + Vercel構成）で、SendGridからResendへの移行を半日で完了させました。本記事では、実際の移行作業の全手順とハマりポイントを公開します。

2025年のSendGrid料金改定とその影響

これまで多くのコーポレートサイトのコンタクトフォームで標準的に使われてきたSendGridですが、2025年3月25日以降に新規作成されたアカウントは「永続無料プラン」が廃止され、60日間の無料トライアル（1日100通まで）に変更されました。

トライアル期間終了後は、Essentialsプランの月額$19.95（日本円で約¥3,000）からの有料プランへの移行が必要になります。これまで「無料の範囲で月数件の問い合わせを処理する」運用をしてきた中小企業のコーポレートサイトにとっては、無視できない料金負担です。

私たちが運用代行している建設業のクライアントでも、ちょうどこのタイミングで無料期間が終了することがわかり、有料プランへの移行か他サービスへの切り替えかを検討する必要が生じました。

クライアントに月¥3,000を負担させるべきか

クライアントに毎月¥3,000の追加コストを支払ってもらう選択肢もありましたが、ここで一旦立ち止まり、より良い選択肢がないか検討しました。判断のポイントは以下の3つです。

• コンタクトフォームの月間問い合わせ数は10件前後で、SendGridの100通/日制限を使い切ることはまずない
• クライアントは保守運用を私たちにお任せいただいているため、配信プロバイダの選定もこちら側で最適化したい
• 今後の運用標準を確立しておけば、他のクライアント案件にも横展開できる

結論として、Resendへの移行を選択しました。クライアントへの追加コスト負担はゼロにできる上に、Next.js + Vercelとの親和性も高いという判断です。

移行先としてResendを選んだ3つの理由

1. Next.js / Vercelとの親和性

ResendはNext.jsを開発するVercel社が公式に推奨しているメール配信サービスで、「次世代のSendGrid」と紹介されることもあります。Next.jsのAPI Routesから呼び出すコード例も豊富で、移行コストが最小限に抑えられます。

実際、移行のコード書き換え量は10行程度で済みました。SendGridとResendはAPIの設計思想が似ており、置換だけで動く部分が大半です。

2. 月3,000通の無料枠

Resendの無料プランは月3,000通まで送信可能（1日100通まで）です。中小企業のコーポレートサイトであれば、月の問い合わせ件数が3,000通を超えることはまずありません。私たちの担当するクライアントの場合、月10件前後の運用なので、無料枠の1%も使わない計算です。

3. 東京リージョン（ap-northeast-1）対応

Resendは内部でAWS SESを利用しており、東京リージョン（ap-northeast-1）でドメイン認証を行えます。日本国内のクライアント案件で送信レイテンシや認証の到達性を最適化したい場合、東京リージョンが選択できるのは大きなメリットです。

実案件で行った移行作業の全手順

ここからは、実際の移行作業の手順を順番に解説します。半日（実時間で約4時間）で完了できる作業です。

事前準備：コードベースとSendGrid実装箇所の特定

まずはコードベースを開き、SendGridを使っている箇所を特定します。多くのNext.jsプロジェクトでは、src/app/api/contact/route.ts のような API Route 内で @sendgrid/mail パッケージが呼び出されているはずです。

該当ファイルを開いて、以下の項目を確認しておきます。

• 使用しているパッケージ（@sendgrid/mail のバージョン）
• 環境変数の名前（SENDGRID_API_KEY 等）
• 送信メールの構造（受信通知メール、自動返信メールの有無）
• reCAPTCHA等の付随する認証処理

Resendアカウント開設とドメイン追加

Resendの公式サイトにアクセスして、Googleアカウントなどでサインアップします。クライアント案件の場合、クライアントから預かっているGoogleアカウントで開設することで、アカウントの所有関係を明確にしておくのがおすすめです。

サインアップ後、左サイドバーの「Domains」セクションから対象ドメインを追加します。リージョン選択では、日本国内のクライアント向けに「Tokyo (ap-northeast-1)」を選びました。

DNSレコードの並走モード追加

ここが移行作業の最大のポイントです。SendGridとResendを「並走モード」で動かすことで、ダウンタイムを発生させずに移行できます。

Resendが提示する3つのDNSレコード（DKIM用TXT、bounce処理用MX、サブドメイン用SPF）を、既存のSendGrid関連レコードを残したまま追加します。これによって、本番切り替えまでの間も既存のメール送信は継続して動作します。

追加するレコードは以下の構成です。

• TXT: resend._domainkey にResendから発行されたDKIMキーを設定
• MX: send サブドメインに feedback-smtp.ap-northeast-1.amazonses.com（優先度10）を設定
• TXT: send サブドメインに v=spf1 include:amazonses.com ~all を設定

注目すべきは、ルートドメインのSPFレコードを編集する必要がないことです。Resendはbounce処理用に send. サブドメインを使う設計のため、既存のメール送信認証（独自ドメインメールやSendGridのSPF）に一切影響を与えません。

API Key発行とテスト送信

DNSの伝播確認後、Resendダッシュボードの「API keys」セクションで送信用のAPI Keyを発行します。権限は最小権限の原則に従い「Sending access」を選択しました。

API Key取得後、curlコマンドで簡易テスト送信を行い、SPF/DKIM/DMARCの全認証PASSを確認します。受信側はGmailなど主要メールプロバイダで実機確認するのが確実です。

Gmailであれば、受信メールの「メッセージのソースを表示」から「Authentication-Results」ヘッダを確認します。dkim=pass spf=pass dmarc=pass の3行が揃っていれば認証成功です。

アプリケーションコードの書き換え

SendGrid→Resendのコード書き換えは、思いのほかシンプルです。実際のコード差分は以下のような形になります。

• import sgMail from '@sendgrid/mail' → import { Resend } from 'resend'
• sgMail.setApiKey(API_KEY) → const resend = new Resend(API_KEY)
• sgMail.send(msg) → resend.emails.send(msg)

送信メッセージのオブジェクト構造（from, to, replyTo, subject, html, text）はそのまま使えるため、書き換えは数行で完了します。package.json から @sendgrid/mail を削除し、resend をインストールするだけです。

Vercel環境変数追加と本番デプロイ

本番デプロイの順序を間違えると、デプロイ直後にフォーム送信が落ちる事故が起こります。必ず先にVercel環境変数に RESEND_API_KEY を追加してから、コードのコミット&プッシュを行います。

順序を逆にすると、新しいコード（Resend要求）と古い環境変数（SendGrid API Keyのみ）のミスマッチで500エラーが発生します。手戻り防止のためにも、環境変数追加が先です。

本番フォームでの最終テスト

Vercelの自動デプロイ完了後、実際の本番フォームから送信テストを行います。確認すべき項目は3つです。

• コンタクトフォームから問い合わせメールが正常に送信される
• 受信通知メール（クライアントの受信箱）にメールが届く
• 自動返信メール（送信者のメールアドレス）にメールが届く

主要プロバイダ（Gmail、独自ドメインメール等）の複数アカウント宛にテスト送信して、迷惑メール判定されないこと、認証が全PASSすることを実機確認します。

移行で躓いた2つのハマりポイント

移行作業で実際に躓いたポイントを共有します。これから移行を考えている方は、事前に押さえておくと作業がスムーズです。

403エラー: APIキーのドメイン制限

テスト送信時、最初に試した送信元アドレスは noreply@send.example.com(サブドメイン送信)でした。しかし、これは 403 Forbidden: This API key is not authorized to send emails from send.example.com というエラーで弾かれました。

原因は、Resendのドメイン認証がルートドメイン送信前提になっていたためです。API Keyに紐付くドメインは認証したルートドメイン(例: example.com)のみで、send. サブドメインは別ドメイン扱いになります。

解決策は、送信元アドレスを noreply@example.com(ルートドメイン)に変更することでした。実は、Resendは「Return-Path(envelope-from)」にサブドメインを使い、「From: ヘッダ」にルートドメインを使うというハイブリッド設計を採用しています。これによって、認証PASS率を高く保ちながらルートドメインの評判を保護できる仕組みです。

サブドメイン送信 vs ルートドメイン送信の判断

Resendが提示するDNSレコードの構造(send サブドメインのMX/SPF + ルートのDKIM)を見ると、一見「サブドメイン送信モード」が前提のように見えます。しかし実態はルートドメイン送信モードがResendの標準です。

この設計を理解できれば、「ルートドメインのSPFを編集して include:_spf.resend.com を追加する必要があるのでは？」という誤解を回避できます。実際には、既存のルートSPFを一切変更せずにResendが動作します。

独自ドメインメール(業務用メール)が既に別プロバイダで動いている場合、ルートSPFを触らずに済むのは大きなメリットです。

クライアントへの透明性確保 — 完了報告メールの構造

移行作業が完了した後は、クライアントへの完了報告メールを送付します。私たちの場合、以下の構造で報告しました。

• 作業内容: 配信サービスをSendGridからResendへ移行した旨
• アカウント開設について: クライアントから預かっていたGoogleアカウントを使用したことを事後報告
• 動作確認状況: フォーム送信、受信、自動返信、認証PASS等の項目を箇条書きで明示
• クライアント側のご対応: 必須対応なし。念のため送受信確認をお願いする旨

特に重要なのは、預かっている認証情報(GoogleアカウントやFTP情報等)を業務上で使用した場合、事後でも必ず透明性のある報告を行うことです。これによってクライアントとの信頼関係を維持できます。

並走モードによるリスク対処

並走モードは、移行作業の最大の安全装置です。SendGrid関連のDNSレコードを残したままResendを稼働させることで、万一Resendに障害が発生してもVercelで前のデプロイにロールバックすればSendGrid送信が即復活する状態を保てます。

SendGrid関連DNSの最終処理

本記事の事例では、SendGrid関連のDNSレコード(CNAME×3 + ルートSPFの include:sendgrid.net)はそのまま放置する判断をしました。理由は以下の通りです。

• 機能的な影響はゼロ(誰も参照しないため)
• SPF lookups制限内(10回上限のうち5回程度)
• SendGridアカウント自体が停止中のため、悪用リスクなし
• 編集中の人為ミスで他の重要レコードを誤操作するリスクの方が大きい

このような判断ができるのは、移行作業全体の構造を把握しているからこそです。「とにかく整理する」より「リスクと効果を比較して放置する」という判断もメンテナンスの一形態と捉えています。

関連: Gmail配信の認証問題を実体験から解説

メール配信の認証(SPF/DKIM/DMARC)は、コンタクトフォームの送信プロバイダを変えるたびに気にかけるべき領域です。最近では「急にGmailに自動返信が届かなくなった」というご相談も増えています。配信プロバイダの選定と認証設定の関連は以下の記事でも詳しく解説しています。

HP制作急にGmailにメールが届かない？原因と対策を実務者が解説

コンタクトフォームを設置しているのに問い合わせがほぼ来ない、という状況の場合、メール配信そのものに不具合がある可能性もあります。問い合わせゼロの構造的な原因は別記事で整理しています。

HP制作ホームページを持っているのに問い合わせゼロ。よくある3つの原因

まとめ: Next.js + Vercel案件はResend移行を検討する価値あり

SendGrid料金改定を機にResendへの移行を検討している方向けに、実案件の移行手順とハマりポイントを解説しました。要点を整理します。

• SendGrid無料プランは2025年3月以降廃止、新規アカウントは60日トライアルのみ
• 有料プランは$19.95/月(約¥3,000)から。低ボリューム運用にはオーバースペック
• Resendは月3,000通まで無料、Next.js/Vercel公式推奨
• 移行作業は半日で完了。コード書き換えは10行程度
• 並走モード(既存DNSを残してResend追加)でダウンタイムゼロ移行が可能
• ハマりポイントは「ドメイン制限の403エラー」と「サブドメインvsルートドメイン送信の理解」の2つ

クライアント案件のメール配信プロバイダ選定は、目に見えにくいインフラ領域ですが、放置すると問い合わせ機会の損失に直結します。配信プロバイダの選定一つで、月額コストと運用負荷の両方に大きな差が生まれることを、今回の移行で改めて実感しました。

SendGrid料金改定をきっかけに同様の検討をされている方は、本記事の手順を参考に、自社案件でも並走モードでの安全な移行を検討してみてください。