メールAPI · 2026年9月21日
SendGridの無料プランが終了：30分でできる移行ガイド
SendGridの無料プランは60日間のトライアルに変わりました。ダウンタイムなしでトランザクションメールを持続可能な代替サービスへ移行するための、エンジニア向け技術ガイドです。
永久無料プランの終わり
小規模なサイドプロジェクトや新しいプロダクトでSendGridの無料プランを利用していた方は、変更に気づいているでしょう。無料プランは60日間のトライアルになりました。トライアル終了後は有料プランへの移行が必要で、Essentialsは月額19.95 USDからです（SendGridの料金）。移行するには、サプレッションのエクスポート、DNSレコードの更新、API連携の切り替えが必要です。テンプレートがシンプルであれば、この作業は30分ほどで完了します。
代替サービスの評価
乗り換え先を選ぶ際は、プロバイダーによる受け付け（APIがリクエストを受け付けること）、配信（受信サーバーがメールを受け取ること）、受信トレイへの到達（メールが迷惑メールフォルダを回避すること）を区別する必要があります。最後の受信トレイへの到達は送信者レピュテーションとコンテンツに左右されるため、どのプロバイダーも保証できません。
コストの状況（2026年9月）
少量のトランザクションメールでは、価格差は大きくなります。50,000通の送信は、Amazon SESの従量課金では約5 USDですが、Postmarkのプランでは約66 USDかかります。
- Amazon SES：従量課金で1,000通あたり0.10 USDです（AWS SESの料金）。2026年7月21日に導入された新しい段階的なプランには、Essentials（1,000通あたり0.16 USD）、Pro（1,000通あたり0.22 USDに加え、リージョンごとに月額105 USD）、Enterprise（1,000通あたり0.23 USDに加え、月額500 USD）があります。
- Resend：月3,000通（1日100通まで）の無料プランを提供しています。Proプランは50,000通で月額20 USD、超過料金は1,000通あたり0.90 USDです（Resendの料金）。
- Mailgun：10,000通で月額15 USDからで、超過料金は1,000通あたり1.80〜1.10 USDです（Mailgunの料金）。
- Postmark：10,000通で月額15 USDからで、超過料金は1,000通あたり1.80〜1.20 USDです（Postmarkの料金）。
- SendHQ：プロダクトチームとAIエージェント向けの現代的な選択肢で、EU内のみで扱うプライバシーに配慮した最小限のテレメトリと、ワークスペース単位のAPIキーを重視しています。
ステップ1：データのエクスポートとサプレッションリスト
サプレッションをエクスポートせずにリストを移行してはいけません。以前バウンスした、または配信停止したアドレスに送信すると、新しいプロバイダーでのレピュテーションを損なうおそれがあります。
SendGridでは、UIまたはAPIからサプレッションリストをエクスポートできます。連絡してはいけないメールアドレスのCSVが得られます。新しいプロバイダーにインポートする際は、GDPRやCAN-SPAMなどの法令を遵守するため、「理由」（バウンスか配信停止か）を正しく対応付けてください。
ステップ2：DNSと認証
ほとんどの移行はここで失敗します。APIキーを変更するだけでは済まず、新しいプロバイダーに対してドメインの所有権を証明する必要があります。
DKIM、SPF、DMARC
DNSプロバイダーに新しいCNAMEレコードまたはTXTレコードを追加する必要があります。SendHQに移行する場合は、変更を加える前にEmail DNS Checkerで現在の設定を確認できます。
- SPF：新しいプロバイダーを含めるようにSPFレコードを更新します。複数のプロバイダーを使う場合、SPFのTXTレコードを複数持つことはできない点に注意してください。1つにまとめる必要があります（例：
v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all）。詳しくは用語集のSPFをご覧ください。 - DKIM：新しいプロバイダーのダッシュボードで新しいDKIMキーを生成し、表示されたCNAMEレコードをDNSに追加します。これにより、受信サーバーはメールが転送中に改ざんされていないことを検証できます。
- DMARC：DMARCポリシーはドメインレベルのポリシーなので、プロバイダーが変わっても同じままです。ただし、メールが拒否されないよう、新しいプロバイダーがDMARCポリシーとアライメントしていることを確認してください。実装の詳細はDKIM、SPF、DMARCのガイドを参照してください。
ステップ3：コードの移行
ほとんどのプロバイダーはREST APIを採用しています。SendGridのダイナミックテンプレートを使っていた場合は、そのHTML/CSSレイアウトを新しいプロバイダーのテンプレートエンジンに移行する必要があります。
例：SendGridから一般的なREST APIへ
SendGridはpersonalizationsに独自のJSON構造を使います。SendHQを含む最近のAPIの多くは、読みやすさのためによりフラットな構造を採用しています。
SendGridのペイロード：
{
"personalizations": [
{
"to": [{"email": "user@example.com"}],
"dynamic_template_data": {
"first_name": "Alice"
}
}
],
"from": {"email": "noreply@yourdomain.com"},
"template_id": "d-12345"
}
最近のAPIのペイロード（例：SendHQ）：
{
"to": "user@example.com",
"from": "noreply@yourdomain.com",
"template_id": "welcome-email",
"variables": {
"first_name": "Alice"
}
}
コードでの移行の扱い
ダウンタイムを避けるには、ラッパーやストラテジーパターンを実装します。これにより、環境変数でプロバイダーを切り替えられるようになります。
interface EmailProvider {
send(payload: EmailPayload): Promise<void>;
}
class SendGridProvider implements EmailProvider {
async send(payload: EmailPayload) {
// SendGrid specific implementation
}
}
class SendHQProvider implements EmailProvider {
async send(payload: EmailPayload) {
// SendHQ specific implementation
}
}
const provider = process.env.EMAIL_PROVIDER === 'sendhq'
? new SendHQProvider()
: new SendGridProvider();
ステップ4：AIエージェントと冪等性
AIエージェントを使ってメールを送信している場合、特有のリスクがあります。エージェントがループに陥ったり、タイムアウトによってリクエストを何度も再試行したりして、ユーザーに同じメールが10通届く可能性があるのです。
メール送信は外部への副作用です。冪等性を実装する必要があります。冪等キーは、ヘッダーで送信される一意の識別子で、APIに「このキーをすでに受け取っている場合は、メールを再送せず、最初の成功レスポンスをそのまま返してください」と伝えます。
エージェント対応の実装：
{
"headers": {
"Idempotency-Key": "order_123_welcome_email"
},
"body": {
"to": "customer@example.com",
"template_id": "order-confirmation"
}
}
さらに、リスクの高いエージェントの操作（パスワードリセットや請求アラートの送信など）には、ヒューマンインザループの承認ステップや、ユーザーIDごとの厳格なレート制限を導入し、エージェントのハルシネーションによって顧客に大量のメールが送られるのを防ぎましょう。
ステップ5：テストと検証
環境変数を新しいプロバイダーに切り替える前に、次のチェックリストを確認してください。
- DNSの反映：
digやWebベースのチェッカーなどのツールを使い、新しいDKIMレコードとSPFレコードが有効になっていることを確認します。 - Webhookの検証：配信イベント（delivered、opened、clicked）を利用している場合は、Webhookのエンドポイントを更新します。SendGridのイベント形式は他のサービスと異なります。エンドポイントがクラッシュせずに新しいJSONスキーマを処理できることを確認してください。
- エラー処理：プロバイダー固有のエラーをアプリケーションがどう処理するかテストします。たとえば、429（Too Many Requests）ではバックオフ戦略を発動すべきですが、400（Bad Request）は通常、メールアドレスの形式が不正であることを示すため、データベース上でバウンスとして記録すべきです。
テストすべき主なエラーケース
- 不正なメールアドレス形式：APIが明確なエラーを返し、コードが無限に再試行しないことを確認します。
- レート制限：メールの集中送信をシミュレートし、キューがプロバイダーの上限に対応できるか確認します。
- 大きな添付ファイル：新しいプロバイダーのペイロードの最大サイズを確認します。10MBまでのプロバイダーもあれば、25MBまでのプロバイダーもあります。
移行のまとめチェックリスト
- サプレッションのエクスポート：SendGridからCSVをエクスポートします。
- DNSレコードの設定：SPF、DKIM、DMARCのアライメント。
- テンプレートの移行：HTML/CSSを新しい形式に変換します。
- APIロジックの更新：プロバイダーラッパーを実装します。
- 冪等性の追加：AIエージェントトリガーに不可欠です。
- Webhookのテスト：イベント配信と解析を検証します。
- トラフィックの切り替え：ENV変数を更新し、ログを監視します。
到達率についての最後に
プロバイダーの移行は、送信の習慣を見直す絶好の機会です。プロバイダーによる受け付けは最初のハードルにすぎないことを覚えておきましょう。配信は、受信側のISP（Gmail、Outlookなど）が接続を受け入れるかどうかに左右されます。受信トレイへの到達は最後のハードルで、ドメインの長期的なレピュテーションと受信者のエンゲージメント率によって決まります。
これらのAPIを一方的な一斉送信メールに使いたくなっても、やめておきましょう。多くの場合違法であるだけでなく、どのプロバイダーを選んでもアカウントが停止されることになります。健全な送信者スコアを維持するため、トランザクションメールと同意を得た連絡に限定しましょう。
AIネイティブなアプリケーションを構築するチームは、連携をスムーズにするMCPサーバーやllms.txtファイルなど、エージェント対応の機能を備えたプロバイダーを探しましょう。SendHQはまさにこのワークフローのために設計されており、現代のプロダクトチームに必要なインフラを提供します。
信頼性の高いメールシステムの構築について、詳しくはhttps://sendhq.ccをご覧ください。