Resendの使い方完全ガイド — 個人開発の最強メール配信【SendGrid徹底比較・2026年最新】

Resendとは？開発者ファーストのメール配信API完全解説

Resendの全体像 — 「開発者のためのメール配信」とは

Resendは、2023年に正式リリースされたモダンなメール配信API/プラットフォームです。 一言でいえば「開発者がドキュメントを5分読めば送信できるメールAPI」を目指して設計されています。 SendGridやMailgunが10年以上の機能追加で複雑化したのに対し、ResendはAPIスキーマをシンプルに保ち、Reactコンポーネントとしてメールテンプレートを書くReact Emailと完全統合している点が決定的に違います。

プロダクトの背後には、 GitHubで世界トップ20に入るほどのオープンソース貢献者として知られるZeno Rocha氏（CEO）の思想があります。 「メールはいまだに開発者にとって最悪のDX領域だ」という問題意識から、 APIの命名・ダッシュボードのUI・ドキュメントの構造のすべてを再設計したのがResendです。

なぜいま個人開発者にResendが選ばれているのか

Resendが2025〜2026年に急浮上している背景には、3つの追い風があります。

• SendGridが2025年5月に無料プランを廃止したことで、個人開発者の標準スタックから外れた
• Next.jsを中心にReactベースの個人開発が主流になり、 React Emailとの親和性が刺さった
• 無料枠が月3,000通と競合より大きく、有料も月20ドルで5万通と価格が分かりやすい

ShiftBの受講生でも、 2025年以降に新規プロジェクトでメール配信を実装するケースの大半がResendを選んでいます。 「Stripe決済の次に当たり前にResendを入れる」くらいの位置付けになりつつあるツールです。

Resendとエコシステムの位置付け

Resendは単独で完結するサービスではなく、 個人開発者が普段使うエコシステム全体と連携しやすいよう設計されています。 公式SDKはNode.js・Python・Ruby・Go・Elixir・PHPの6言語で提供され、 とくにNode.js SDKはNext.jsとReact Emailに最適化されています。 また、 Vercelのインテグレーションマーケットプレイスや、 Convex・Supabase Edge Functionsのようなバックエンドプラットフォームからもワンクリックで連携できます。

最近では公式のMCPサーバー（Model Context Protocol）も提供されており、 Claude CodeやCursorなどのAIエディタから 「Resendの過去ログを検索して」「テストメール送って」 といった操作を自然言語で行える環境が整いつつあります。 個人開発者にとって、 メール周りまでAI駆動開発のワークフローに統合できる数少ないサービスです。

Resendが提供する6つのコア機能

Resendは「ただメールを送るAPI」ではなく、 個人開発者から成長期スタートアップまでが必要とする周辺機能をひと通り備えています。

とくに最後のReact Email連携は、Resendを選ぶ最大の理由になります。 メールテンプレートを「コードとして」管理できるので、 デザイナーやマーケがダッシュボードでテンプレを編集して気付かないうちに崩れる、という事故が起きません。 PRでレビューでき、テストも書ける。これは他のメール配信サービスにはない決定的な優位点です。

Resendの料金プラン徹底比較【2026年最新】

4つの料金プラン詳細

Resendは2026年5月時点で、以下の4プランを提供しています。

個人開発者がまず触るのはFreeかProです。 Freeでも「1日100通・月3,000通」までは送れるので、 PMF前のプロダクトであれば無料で十分回ります。

個人開発で実際にいくらかかるか — 3パターンのシミュレーション

机上の料金表だけ見ても判断しにくいので、 ShiftBの受講生・自社プロダクトでよくある3パターンで実コストを試算しました。

この表からわかるとおり、個人開発の99%のフェーズはFree〜月20ドルで足りると考えてよいです。 SendGridのように「無料枠が60日で消える」「Essentialsで19.95 USD固定」と比較すると、 序盤キャッシュアウトがゼロで済むのは大きな差です。

隠れたコストと無料枠を最大化するコツ

料金で意外と見落としがちなのが、以下の3点です。

• 専用IP：Scale/Enterpriseで月額追加。 ただし後述するとおり、ほとんどの個人開発では不要
• レートリミット：デフォルトで2リクエスト/秒。 一斉送信を素朴にforループで回すと429エラーになる
• ログ保持期間：Freeは3日分のみ。 トラブル調査が必要ならProで延長されたログを使う

特にレートリミットは、 「ニュースレターを購読者全員に送ろう」と素朴に書くと簡単に踏むため、 後述のBatch APIかキューイングを使う設計にしておくべきです。

SendGrid vs Resend — 個人開発者が選ぶべきはどっち？

料金とプランの違い — SendGrid無料プラン廃止のインパクト

まず数字から並べてみます。

2025年5月のSendGrid無料プラン廃止は、 個人開発コミュニティに大きなインパクトを与えました。 これまで「とりあえずSendGridで100通/日の無料枠」が標準だったのが、 60日トライアル後は強制的に20ドル課金が必要になったためです。 結果として、新規プロジェクトの第一選択がResendに移行しています。

開発体験（DX）の決定的な差

料金以上に大きな差が開発体験です。 同じ「メール1通を送る」コードを比較すると、思想の違いがはっきり見えます。

Resendの送信コード：

import { Resend } from "resend";
import { WelcomeEmail } from "@/emails/welcome";

const resend = new Resend(process.env.RESEND_API_KEY);

await resend.emails.send({
  from: "ShiftB <noreply@shiftb.dev>",
  to: ["user@example.com"],
  subject: "ようこそShiftBへ",
  react: <WelcomeEmail name="鈴木さん" />,
});

SendGridの送信コード（同等の処理）：

import sgMail from "@sendgrid/mail";

sgMail.setApiKey(process.env.SENDGRID_API_KEY!);

await sgMail.send({
  from: "noreply@shiftb.dev",
  to: "user@example.com",
  subject: "ようこそShiftBへ",
  html: renderToStaticMarkup(<WelcomeEmail name="鈴木さん" />),
});

わずか数行の差ですが、Resendはreactプロパティに直接Reactコンポーネントを渡せます。 SendGridでは事前にHTMLにレンダリングする処理を自前で持つ必要があり、 メールクライアント互換のためのインライン化なども自分で面倒を見ないといけません。

さらに大きいのはダッシュボードの違いです。 Resendのダッシュボードは「ログ」「ドメイン」「APIキー」「Audiences」「Webhooks」「Broadcasts」とほぼフラットな構成。 一方、SendGridは10年以上の機能追加でナビゲーションが深く、 「設定がどこにあるか分からなくなる」という声が受講生からよく上がります。

用途別の選び分け早見表

ぶべがShiftBで受講生に伝えている選び分けは以下のとおりです。

個人開発の文脈では、「迷ったらResend」で問題ありません。 もし将来的に大規模配信や非エンジニア向けGUIが必要になった場合のみSendGridを再検討する、という順番で十分です。

Resendの始め方 — アカウント作成からドメイン認証まで

ステップ1: アカウント作成とAPIキー発行

まずは公式サイトのSign upからGitHubもしくはメールでアカウントを作成します。 ログイン後、 サイドバーのAPI Keysから「Create API Key」を押し、 用途に応じて権限とドメインスコープを選びます。 個人開発の最初のキーはFull accessで問題ありませんが、 本番運用時はサービスごと・環境ごとに分けるのがおすすめです。

作成されたAPIキーはre_xxxxxxxxxxxxの形式で、 表示は1回限りです。 必ず安全な場所（環境変数管理ツール・Vercel/Netlifyの環境変数）に保存してください。 クライアントサイドの環境変数（例：Next.jsのNEXT_PUBLIC_*）には絶対に入れないこと。 漏洩すると第三者がそのドメインからメールを送れてしまいます。

ステップ2: 独自ドメインの追加（onresend.devでも送れる）

Resendは認証ドメインを設定しなくても、onresend.devサブドメインから送信できます。 動作確認用ならこれで十分ですが、 本番では必ず独自ドメインを追加してください。 ユーザーから見たときの差出人ドメインがあなたのプロダクト名になり、 信頼性と到達率が大幅に上がります。

ダッシュボードのDomains → Add Domainでexample.comを追加すると、 必要なDNSレコード（SPF用TXT・DKIM用CNAME、必要ならMX）が表示されます。 これらをドメインのDNS管理画面（Route 53、Cloudflare、お名前.comなど）に追加し、 ResendダッシュボードでVerifyを押せば数分〜数時間で認証完了です。

ShiftBの受講生でよくあるハマりポイントは、 「sendサブドメイン」を切らずにルートドメインで認証してしまうケースです。 メインドメインのレピュテーションを汚さないよう、send.example.comやmail.example.comのような送信専用サブドメインで認証しておくのが安全な構成です。

ステップ3: SPF/DKIM/DMARCの設定で配信到達性を確保

メールが迷惑フォルダに入る最大の原因は、認証設定の不備です。 Resendが自動で作るSPFとDKIMだけでもかなり強いですが、 さらにDMARCを自分で追加しておくのが2026年の標準です。

• SPF：そのドメインから送ってよいIPの一覧（Resendが自動で発行するTXTを追加）
• DKIM：送信メールに電子署名を付ける（CNAME経由でResendの鍵を参照）
• DMARC：SPF/DKIMが失敗したときの取り扱いを宣言（自分でTXTを追加）

DMARCの最初の設定例は、緩めから始めて段階的に強める方法がおすすめです。

# まずは集計だけ受け取る（quarantine/rejectは様子を見てから）
_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Gmail・Yahooの送信者ガイドラインが2024年以降厳格化したため、 「とりあえず動けばOK」では本番で迷惑判定される確率が上がっています。 ShiftBの受講生プロジェクトでも、 DMARC未設定で本番リリースし「サインアップ確認メールが届かない」というトラブルが定期的に発生します。 ここはローンチ前に必ず仕込んでおく工程です。

Next.js × React Email × Resendで実装する完全チュートリアル

必要なパッケージとプロジェクト構成

Next.js（App Router）でResendとReact Emailを使うときの最小構成は3パッケージです。

npm install resend @react-email/components react-email

ディレクトリ構成は次のようにすると、 メールテンプレートだけ独立してnpm run emailでローカルプレビューでき、 PRレビューもしやすくなります。

app/
  api/
    send/
      route.ts          # 送信API
emails/
  welcome.tsx           # サインアップ歓迎メール
  reset-password.tsx    # パスワードリセット
  invoice.tsx           # 請求関連
package.json
.env.local              # RESEND_API_KEY=re_xxxx

React Emailでテンプレートを作る

メールテンプレートは普通のReactコンポーネントとして書きます。 Tailwind対応コンポーネントもあるので、 Webと同じ感覚でスタイリングできます。

// emails/welcome.tsx
import {
  Body, Container, Head, Heading, Html, Link, Preview, Tailwind, Text,
} from "@react-email/components";

type Props = { name: string };

export function WelcomeEmail({ name }: Props) {
  return (
    <Html>
      <Head />
      <Preview>{name}さん、ShiftBへようこそ</Preview>
      <Tailwind>
        <Body className="bg-white font-sans">
          <Container className="mx-auto max-w-xl p-6">
            <Heading className="text-2xl font-bold">
              {name}さん、ようこそ
            </Heading>
            <Text className="text-base leading-7">
              ShiftBに登録いただきありがとうございます。
              まずは下記のボタンからメールアドレスをご確認ください。
            </Text>
            <Link
              href="https://shiftb.dev/verify"
              className="inline-block rounded-md bg-blue-600 px-5 py-3 text-white"
            >
              メールアドレスを確認する
            </Link>
          </Container>
        </Body>
      </Tailwind>
    </Html>
  );
}

重要なのは、 このコンポーネントが「Webアプリ用のReactコンポーネント」とまったく同じ書き味で動くことです。 デザイントークンや文言の変更がGitで履歴管理でき、 Pull Requestで「このメール文面どう？」と相談できる。 これがResendを使う最大のメリットです。

API Route から送信する（コード例）

Next.jsのRoute Handlerから送信する最小実装は次のとおりです。

// app/api/send/route.ts
import { Resend } from "resend";
import { WelcomeEmail } from "@/emails/welcome";

const resend = new Resend(process.env.RESEND_API_KEY);

export async function POST(req: Request) {
  const { email, name } = await req.json();

  const { data, error } = await resend.emails.send({
    from: "ShiftB <noreply@send.shiftb.dev>",
    to: [email],
    subject: `${name}さん、ShiftBへようこそ`,
    react: <WelcomeEmail name={name} />,
  });

  if (error) {
    return Response.json({ error }, { status: 500 });
  }
  return Response.json({ id: data?.id });
}

APIキーは必ずサーバーサイドのみで参照すること。 Next.jsではNEXT_PUBLIC_プレフィックスを付けない環境変数は自動的にサーバー専用になります。 もしクライアントから直接Resendを叩こうとしているコードを見たら、 即座にAPI Route経由に作り替えてください。

ローカルテストの3つのテクニック

実際にメールを送ってしまうと送信枠を消費したり、 テストアドレスにスパムレポートを誤爆したりします。 本番リリース前のテストには、以下のテクニックを使い分けます。

• delivered@resend.devに送る：Resendが処理だけ行いログに残す。実配信されないので安全
• React Emailのプレビューサーバー：npm run emailでブラウザでテンプレートを確認。Hot Reload対応
• テスト専用ドメイン：test.example.comを別ドメインで認証しておき、 本番ドメインのレピュテーションを汚さない

特にdelivered@resend.devは便利で、 「サインアップ完了メールの送信処理が呼ばれているか」をE2Eテストで検証する用途に使えます。

Resendの応用機能 — Broadcasts・Webhooks・Inbound・Batch

Broadcasts/Segments — マーケメール配信

ResendのBroadcastsは、 トランザクションメールとは別の「マーケメール一斉配信」専用の仕組みです。 「Audience（最近Segmentsに名称変更）」に登録された購読者リスト全員にメールを送ったり、 セグメントを切って配信したりできます。

個人開発で典型的な使い方は次のとおりです。

• 新機能リリースのお知らせを購読者全員に送る
• 有料化キャンペーンの告知を「無料ユーザー」のセグメントに限定送信
• 未利用ユーザーへのリエンゲージメント配信

トランザクションとマーケを別系統で管理することで、 「お知らせメール拒否」を選んだユーザーにも「パスワードリセット」は届く、 という当たり前の動作を綺麗に実装できます。

Webhooks — 配信イベントを自前のDBに記録する

メールが送信成功・配信完了・開封・クリック・バウンス・スパム報告などの状態になるたびに、Webhookで通知を受け取れます。 これを使うと、自分のDBに配信ログを蓄積し、後述の自動オプトアウトやドリップ配信の停止判定に使えます。

// app/api/resend-webhook/route.ts
export async function POST(req: Request) {
  const event = await req.json();

  switch (event.type) {
    case "email.bounced":
    case "email.complained":
      // バウンス/スパム報告 → DBで送信停止フラグを立てる
      await markUserAsUnsendable(event.data.to);
      break;
    case "email.opened":
      await logEmailOpen(event.data.email_id);
      break;
  }
  return Response.json({ ok: true });
}

とくにemail.bouncedとemail.complainedは最重要です。 これらを無視して送り続けると、 ドメイン全体のレピュテーションが下がり、 普通のサインアップ確認メールまで届かなくなります。

Inbound Email — 受信メールをアプリで処理する

2025年に追加されたInbound Emailは、 自分のドメイン宛に届いたメールをHTTPSのWebhookとして自分のアプリに転送する機能です。 これがあると、 個人開発で次のような機能を素早く実装できます。

• ヘルプデスクの問い合わせメールをDBに保存し、 ダッシュボードから返信
• メール返信をそのままコメント追加として扱うNotion風機能
• 特定のアドレス宛のメールを自動でAI要約してSlack通知

ShiftBの自社プロダクトでも、 サポート問い合わせをInbound経由でDBに溜めて、 後続のCS対応の起点にする使い方をしています。

Batch送信とスケジュール送信、Idempotency Key

一斉配信で気をつけたいのがレートリミットです。 Resendはデフォルトで2リクエスト/秒なので、 ニュースレターを購読者1,000人に素朴に送ると確実に429エラーになります。

対策は次の3つを組み合わせます。

• Batch API：1リクエストで最大100通まとめて送信。 1万通でも100リクエストで完了
• scheduled_at：個別送信に未来時刻を渡せる。 配信時間をずらすことで集中アクセスを避ける
• Idempotency Key：Batch APIで重複防止。 同じKeyで再送しても二重配信されない（24時間有効、最大256文字）

// Batch送信の例（最大100通/リクエスト）
await resend.batch.send(
  recipients.map((u) => ({
    from: "ShiftB <noreply@send.shiftb.dev>",
    to: u.email,
    subject: "今週のアップデート",
    react: <Newsletter user={u} />,
  })),
  { idempotencyKey: `newsletter-2026-05-04-${batchIndex}` },
);

Cloudflare QueuesやVercelのCron＋Queueと組み合わせれば、 数万通規模の配信でも安定して回せる構成になります。

配信到達性を最大化する5つの実装パターン

パターン1: トランザクションとマーケのドメインを分ける

本番運用では、トランザクションメール（認証・通知）とマーケメール（お知らせ・キャンペーン）を別サブドメインで送るのがセオリーです。 例えばsend.example.comをトランザクション専用、 news.example.comをマーケ専用にすると、 マーケで多少スパム判定されてもログイン認証メールには影響しません。

パターン2: バウンスとSpam報告をWebhookで自動オプトアウト

「バウンスしたメールアドレスに送り続ける」は、 ドメインレピュテーションを最も早く破壊する行為です。 前述のWebhookでemail.bouncedとemail.complainedを購読し、 該当アドレスを自分のDBで「送信停止」にしておきましょう。 送信前にこのフラグをチェックする1行を入れるだけで、 配信到達性が劇的に安定します。

パターン3: ウォームアップとレートリミット対策

新規ドメインから一気に大量送信すると、 メールクライアント側で「このドメイン怪しい」と判定されます。 最初の数週間は1日数百通から始めて段階的に増やすのが基本です。 Resendは共有IPを使う限り内部で吸収してくれますが、 Batch APIを使うときはscheduled_atで時間を分散させるのがおすすめです。

パターン4: 専用IPは「いつ」必要か（多くは不要）

専用IPは、 「月10万通以上を継続的に送る」「自社のレピュテーションを完全にコントロールしたい」 という規模になるまで不要です。 個人開発フェーズで専用IPを契約すると、 むしろ送信量が少なくてレピュテーションが立たず、 共有IPより配信到達性が下がる逆転現象も起きます。

Resend公式も「ほとんどの顧客には共有IPで十分」と明言しているので、 まずは共有IPで運用し、 月10万通を超えてから専用IPを検討する順序がおすすめです。

パターン5: 件名・差出人名・プリヘッダの細部を磨く

意外と効くのが、内容ではなく「最初に目に入る要素」のABテストです。

• 差出人名：「ShiftB公式」と「ShiftB｜ぶべ」では開封率が変わる
• 件名：絵文字あり/なし、長さ、数字の有無
• プリヘッダ（<Preview>コンポーネント）：受信箱のプレビューに表示される一行

ResendのBroadcastsとWebhooks（開封率トラッキング）を組み合わせれば、 シンプルなABテストはダッシュボード上で完結します。

個人開発でやりがちな3つの落とし穴

ShiftBの受講生プロジェクトでメール配信を実装したとき、 ほぼ毎回引っかかるのが次の3つです。 ここを最初に潰しておくだけで、 「届かない」「迷惑判定される」「料金が予想外に膨らむ」をまとめて回避できます。

• 本番ドメインで認証メールとマーケメールを混ぜて送ってしまう：マーケ側のスパム判定が認証側まで巻き込み、 ログインできないユーザーを生んでしまう。 必ずサブドメインを分ける
• WebhookのSignature検証を忘れる：Resendから来ているように見せかけた偽リクエストでDBを書き換えられるリスクがある。 公式ドキュメントどおりに署名検証を必ず実装する
• ループ送信でレートリミットを踏む：1,000人にforループで送ると確実に429エラー。 Batch APIかキューイング前提で設計する

どれも「分かっていれば数行で防げる」けれど、 知らないと本番リリース後に発覚して原因究明に半日溶ける、 というタイプのハマりどころです。 リリース前のチェックリストに必ず入れておきましょう。

よくある質問（FAQ）

Q1. Resendはどのくらいでセットアップできる？

サインアップから「最初の1通」を送るまでなら、 ドキュメントを読みながら15〜30分程度です。 独自ドメインの認証を含めるとDNSの伝搬待ちで数十分〜数時間。 Next.js + React Emailで本格的なテンプレートまで仕上げるなら、 半日見ておくと余裕があります。

Q2. Gmailアドレス（@gmail.com）から送信できる？

できません（厳密には推奨されません）。 SPF/DKIM/DMARCを自分でコントロールできないアドレスから送ると、 受信側で迷惑判定される確率が高くなります。 必ず独自ドメインを取得し、 そのドメインから送信してください。

Q3. 既存のSendGridからResendへ移行するのは大変？

SDKの呼び出しを差し替えるだけならコードは数時間で終わります。 ただし送信ドメインの認証DNSを再度Resend向けに設定し直す必要があり、 ダウンタイムなく切り替えるならSPFに両サービスを併記する移行期間を1〜2週間取るのが安全です。 移行の最大の落とし穴は、 「テンプレートをHTMLからReact Emailに書き直す手間」なので、 まずは1テンプレートから段階移行することをおすすめします。

Q4. 日本語ドメイン・日本語差出人名は使える？

差出人名は日本語でOKです（Punycodeの自動エンコードに対応）。 ドメイン自体はASCIIで取得しておくのが無難で、 受信箱で「ShiftB公式 <noreply@shiftb.dev>」のように表示されます。

Q5. 添付ファイルは送れる？

単発送信resend.emails.sendでは添付ファイルに対応しています。 一方、 Batch APIには添付ファイル未対応という制約があります。 領収書PDFなどを添付したい場合は単発送信を選ぶか、 リンク送付＋ダウンロード方式に変えるのがおすすめです。

Q6. 配信ログはいつまで残る？

Freeプランでは3日分のログ保持です。 トラブル調査に時間がかかるサービスを運営するなら、 Pro以上のプランで延長されたログを使うか、 自前でWebhookを受けてDBに保存する設計にしておくと安心です。

Q7. 個人開発でResend以外を選ぶ理由はある？

次のいずれかに当てはまるなら、他の選択肢も検討の余地があります。

• 月100万通以上の大量配信を予定している → SendGridやAmazon SES
• マーケ担当が独自に編集できるGUIエディタが必須 → SendGrid Marketing Campaigns
• AWS環境内で完結させたい → Amazon SES
• 高い到達率に特化したい中規模配信 → Postmark

逆にいうと、 これらに当てはまらなければResendを選ばない理由はほぼありません。

まとめ — 個人開発のメール配信はResendで決まり

最後にこの記事の要点を振り返ります。

• Resendは「開発者ファーストのモダンなメール配信API」。 React Email連携でテンプレートをコード管理できる
• 無料3,000通/月、有料20ドルで5万通の分かりやすい料金。 個人開発の99%はFree〜Proで足りる
• SendGridが2025年に無料プラン廃止したことで、 個人開発者の標準スタックがResendに移行している
• 独自ドメインを追加しSPF/DKIM/DMARCを必ず設定。 送信専用サブドメインで本番ドメインを保護する
• Webhookでバウンス・スパム報告を購読し、 自動オプトアウトを実装するとレピュテーションを守れる
• 一斉配信はBatch APIとIdempotency Keyを使い、 レートリミットに引っかからない設計に

ShiftBでは、 自社プロダクト（Vibely）でも受講生プロジェクトでも、 メール配信の第一選択をResendに統一しています。「メール周りで詰まる時間」をプロダクトの本質に振り向けられるのが、Resendを選ぶ最大の価値です。

この記事を読んで実装に詰まったら、 ShiftBのカリキュラムではStripe決済・認証・メール配信を含む個人開発の全工程を、 受講生のプロダクトに沿ってマンツーマンで伴走しています。 「自分のサービスに最短で組み込みたい」「設計に第三者の目が欲しい」 という方は、ぜひ無料の体験面談から相談してみてください。