メール API：プログラムからメールを送信する完全ガイド（2026 年版）

メール API を使うと、アプリケーションは HTTP リクエストでメールを送信できます。

単純に聞こえますが、この選択は製品の信頼性、到達性、エンジニアリングのワークフロー、分析、法令順守、顧客体験、サポート運用にまで影響します。

このページの旧バージョンは構成こそ適切でしたが、深さが足りませんでした。API を比較し、Brevo の簡単な例を示し、API と SMTP の使い分けを説明していただけです。今回の更新ではその構成を保ちつつ、Brevo、SendGrid、Mailgun、Amazon SES、Postmark の最新のベンダードキュメントと料金ページ、そして Tajo 自身のメッセージング API ドキュメントに基づいて、完全な実装ガイドへと拡張しました。

要点まとめ

アプリケーション起点のメールが必要なときは、メール API を使いましょう。

• 新規登録の確認。
• パスワードの再設定。
• マジックリンクによるログイン。
• 注文確認。
• 発送通知。
• 請求書や領収書。
• 製品への招待。
• トライアルのオンボーディング。
• 利用状況のアラート。
• 決済失敗の通知。
• 更新のリマインド。
• 製品イベントに基づくライフサイクルの自動化。

送信側のシステムが SMTP の認証情報しか受け付けない場合や、レガシーなアプリ、プラグイン、サーバー、社内ツールのために標準化されたメール転送層が必要な場合は SMTP を使います。

最適なメール API は、技術スタックによって変わります。

表示価格だけで選んではいけません。メール API のコストには、エンジニアの工数、到達性への対応、データモデリング、監視、サポート、将来の移行リスクも含まれます。

メール API と SMTP の比較

API も SMTP もメールを送信できます。違いは、アプリケーションがメッセージを送信プラットフォームへ渡す方法にあります。

SMTP は長く使われてきたメール転送のプロトコルです。多くのツールで利用でき、ホスト、ポート、ユーザー名、パスワードの設定を前提とする製品では今でも有用です。

メール API は HTTP のインターフェースです。アプリケーションは、認証情報、受信者、本文、テンプレートのデータ、メタデータ、場合によっては送信予約や一括送信の情報を添えて、エンドポイントへリクエストを送ります。

実務上の原則はこうです。アプリケーションのコードを自分たちで持っているなら API から始めましょう。SMTP しか対応しないサードパーティのツールを設定するなら SMTP を使いましょう。

メール API の仕組み

基本的な送信フローは 7 つのステップで構成されます。

1. アプリケーションが user_signed_up や order_paid のようなイベントを生成します。
2. アプリケーションがメッセージの種類を選びます。
3. アプリケーションが受信者、送信者、テンプレート、パーソナライズ用のデータを読み込みます。
4. アプリケーションが認証付きの HTTP リクエストをメールプロバイダーへ送ります。
5. プロバイダーがリクエストを検証し、メッセージをキューに入れます。
6. プロバイダーが成功、エラー、またはメッセージ識別子を含むレスポンスを返します。
7. Webhook が配信、バウンス、クリック、苦情、配信停止のイベントをシステムへ返します。

API リクエストは全体の一部にすぎません。信頼できる実装には、冪等性、リトライ、ログ、除外リストの処理、アラート、データガバナンスも必要です。

クイックスタート：Brevo の API でメールを送る

Brevo のトランザクションメール API は、/v3/smtp/email エンドポイントへの認証付きリクエストを使います。SDK やフィールド名は変わる可能性があるため、実装時はベンダーの API リファレンスを正とみなしてください。

リクエストの例です。

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

本番のコードに API キーを直接書き込んではいけません。シークレットはシークレットマネージャーか環境変数に保管し、定期的に入れ替え、アクセスを制限し、フロントエンドのコードに露出させないでください。

本番環境でのメール API アーキテクチャ

本番のメール API 連携では、すべてのコントローラーやルートハンドラーから直接送信すべきではありません。

小さなメッセージ層を用意しましょう。

1. 製品側でイベントが発生します。
2. アプリケーションがイベントをキュー、ジョブ、またはイベントバスへ書き込みます。
3. メールサービスがイベントをテンプレートに対応づけます。
4. メールサービスが受信者の同意状況と除外ルールを検証します。
5. メールサービスがプロバイダーの API を呼び出します。
6. メールサービスがプロバイダーのメッセージ ID を記録します。
7. Webhook が後からメッセージのステータスを更新します。

こうすることで製品側のコードが整理され、メールの障害を切り分けやすくなります。

内部で持つとよいフィールドです。

• event_id。
• message_type。
• recipient_id。
• recipient_email。
• template_id。
• locale。
• provider。
• provider_message_id。
• idempotency_key。
• status。
• error_code。
• created_at。
• sent_at。
• delivered_at。

重要なメッセージには冪等キーを使いましょう。プロバイダーが最初のメッセージを受理した後にネットワークがタイムアウトしたからといって、リトライでパスワード再設定メールが 3 通届いてはいけません。

主要なメール API の比較

Brevo

Brevo は、トランザクションメールがより広い顧客コミュニケーションの一部である場合に役立ちます。

次の場合に Brevo を選びましょう。

• トランザクションメールに加えて、キャンペーン、CRM、自動化、SMS、WhatsApp が必要である。
• EC のデータでライフサイクルメッセージをトリガーしたい。
• マーケティングと製品のメッセージで連絡先プロフィールを共有したい。
• 開発者以外の担当者もテンプレートとレポートにアクセスする必要がある。
• チャネルごとに個別のツールを持つのではなく、1 つのプラットフォームにまとめたい。

注意すべき点です。

• マーケティングメールとトランザクションメールで設定が異なること。
• テンプレートの管理をエンジニアリングとマーケティングのどちらが持つか。
• レート制限とプランごとの制約。
• 連絡先データの同期方法。
• メッセージの種類ごとに、配信停止と除外のルールがどう適用されるか。

Brevo のドキュメントは、トランザクション送信、一括送信、サンドボックスモード、SMTP リレー、Webhook、SDK、API リファレンスを網羅しています。実装の詳細はそれらのドキュメントを参照してください。

SendGrid

SendGrid は、多くの言語とプラットフォームに対応した成熟した開発者向けメール API を求めるチームによく選ばれます。

次の場合に SendGrid を選びましょう。

• 開発者が使い慣れたメール API と SDK のエコシステムを求めている。
• 同じベンダーからトランザクションメールとマーケティングメールの両方を送りたい。
• すでに Twilio の基盤を利用している。
• イベント Webhook と細かな送信制御が必要である。

注意すべき点です。

• 選んだプランにどの到達性機能とサポート機能が含まれるか。
• 環境をまたいでテンプレートをどう管理するか。
• マーケティングメールとトランザクションメールで同じアカウント構成を共有すべきか。

Mailgun

Mailgun は、開発者主導の送信と API を中心としたワークフローを前提に作られています。

次の場合に Mailgun を選びましょう。

• エンジニアリングがメール基盤を所有している。
• HTTP 送信、SMTP のフォールバック、ログ、受信ルート、検証ツールが必要である。
• 到達性の運用について明確に語るプロバイダーを求めている。

注意すべき点です。

• 検証、分析、到達性の機能がどこまで含まれるか。
• データの保持期間とログへのアクセス。
• 移行時とウォームアップ時に期待できるサポート。

Amazon SES

Amazon SES はインフラ寄りのサービスです。

次の場合に Amazon SES を選びましょう。

• アプリケーションがすでに AWS 上で大きく動いている。
• 設定作業をより多く自前で担うエンジニアリングのリソースがある。
• 大量送信を従量課金で行いたい。
• IAM、CloudWatch、SNS、Lambda など AWS のサービスと密に統合したい。

注意すべき点です。

• サンドボックス解除と本番アクセスの申請。
• ドメイン ID の設定。
• バウンスと苦情の処理。
• 専用 IP を使うかどうかの判断。
• 監視とアラート。
• 他のプロバイダーが製品の画面で提供している機能を、自前で作るためのエンジニアリングコスト。

SES は大規模になるほど優れた選択になり得ますが、どのチームにとっても最も手間が少ない選択肢というわけではありません。

Postmark

Postmark はトランザクションメールに特化しています。

次の場合に Postmark を選びましょう。

• 万能なマーケティング機能の幅よりも、トランザクションの信頼性と分かりやすさが重要である。
• メールの種類を分けるメッセージストリームを使いたい。
• テンプレート、受信メール、配信イベントを分かりやすい製品で扱いたい。

注意すべき点です。

• 自社の送信量における料金プラン。
• イベントとメッセージをどれくらいの期間保持する必要があるか。
• 一括のマーケティング配信を別のストリームやプラットフォームに分けるべきか。

Tajo

Tajo は、メール送信が EC、顧客イベント、Brevo と連携した自動化に結びついている場合に有効です。

次の場合に Tajo を使いましょう。

• 製品と EC のイベントを Brevo へ流し込む必要がある。
• Shopify などのコマースデータでカゴ落ち、注文、ライフサイクルのメッセージをトリガーしたい。
• 顧客、注文、商品、イベントのデータをまとめる 1 つの連携レイヤーが欲しい。
• 広い顧客データモデルと接続された、ドキュメント化されたトランザクションメッセージングの経路が必要である。

Tajo はプロバイダー自身の API リファレンスを置き換えるものではありません。適切な顧客データとイベントデータをメッセージングの仕組みに取り込むための作業を減らすためのものです。

メール API を使う場面

トランザクションメール

トランザクションメールは、ユーザーの操作やシステムのイベントによってトリガーされます。

例を挙げます。

• アカウントの確認。
• マジックリンクによるログイン。
• パスワードの再設定。
• 二要素認証。
• 製品への招待。
• 注文確認。
• 支払いの領収書。
• 発送確認。
• 配送状況の更新。
• 返金の通知。
• サブスクリプションの更新。
• 決済失敗のアラート。
• セキュリティの通知。

トランザクションメールには高い信頼性が期待されます。ログインリンク、注文の領収書、パスワード再設定のメールが届かなければ、ユーザーはすぐに気づきます。

あわせてご覧ください。注文確認メールとトランザクションメールの例。

製品ライフサイクルのメール

ライフサイクルメールは、トランザクションとマーケティングの中間に位置します。

例を挙げます。

• トライアルのオンボーディング。
• 機能の有効化。
• 利用のマイルストーン。
• アップグレードの案内。
• 休眠アカウントへのリマインド。
• カスタマーサクセスからの状況確認。
• 更新に向けたシーケンス。
• 掘り起こしのメッセージ。

これらのメールは、一律のカレンダーではなく製品データによってトリガーされるときに最も効果を発揮します。

EC のメール

EC のチームは、トランザクションとマーケティング起点の両方のメールを必要とすることが多くあります。

• ウェルカムオファー。
• カゴ落ち。
• 閲覧離脱。
• 再入荷。
• 値下げ。
• 商品のおすすめ。
• 買い替えのリマインド。
• ロイヤルティの更新情報。
• レビュー依頼。
• VIP 向けの先行アクセス。

Shopify と Brevo を使うチームであれば、Tajo が注文、顧客、同意、商品、カートのデータを接続し、実際の購買行動でこれらのメッセージをトリガーできるようにします。

API 経由のマーケティングメール

マーケティングメールを、一括配信のニュースレター処理だけだと考えてはいけません。

API でトリガーするマーケティングは、次のような施策を支えられます。

• イベントに基づくセグメント化。
• パーソナライズされたキャンペーン。
• トリガー型のドリップシーケンス。
• 製品主導のオンボーディング。
• アカウント単位のライフサイクル設計。
• 顧客の行動と結びついたメールの自動化。

法令順守の基準は変わりません。マーケティングのメッセージには、適切な同意、オプトアウトの処理、除外ルールが必要です。

確認すべき主要な API 機能

認証とキー管理

本格的なメール API は、安全な API キーと明確な認証ドキュメントを備えているべきです。

運用上の要件です。

• 環境ごとにキーを分ける。
• 本番キーへのアクセスを制限する。
• キーを定期的に入れ替える。
• キーをコードの外に保管する。
• キーの値そのものを記録せずに利用状況を記録する。
• 失敗したリクエストのダンプからキーを取り除く。

テンプレート

テンプレートはトランザクションメールの一貫性を保ちます。

次を確認しましょう。

• バージョン管理。
• テスト送信。
• 変数。
• 代替値。
• 多言語対応。
• プレビュー表示。
• 承認のワークフロー。
• ステージングと本番でテンプレートを分けられること。

テンプレートは単なるデザイン素材ではありません。製品の約束の一部です。パスワード再設定、注文確認、請求書のテンプレートは、アプリケーションの UI と同じ真剣さでレビューすべきです。

Webhook

Webhook は、送信をフィードバックのループへと変えます。

追跡する内容です。

• 処理済み。
• 保留。
• 配信済み。
• 開封（慎重に扱う）。
• クリック（慎重に扱う）。
• バウンス。
• 送信取りやめ。
• 苦情。
• 配信停止。

プロバイダーのメッセージ ID を保存しておくと、Webhook のイベントを社内のユーザーやイベントと突き合わせられます。

除外リストの管理

除外リストの処理は、到達性と法令順守を守ります。

システムは次を扱えるべきです。

• ハードバウンス。
• 苦情。
• 配信停止。
• 手動でのブロック。
• 方針上除外する場合の役職名アドレス。
• 無効な連絡先。
• アカウント削除やプライバシーに関する要求。

製品側のコードがメール送信を単なるバックグラウンド処理としてしか見ていないために、恒久的に失敗するアドレスへ再送を繰り返す状態にしてはいけません。

レート制限とスループット

プロバイダーが次をどう扱うか確認しましょう。

• API リクエストの制限。
• メッセージのスループット。
• 一括送信のエンドポイント。
• 瞬間的な上限。
• 日次または月次のプラン上限。
• 新規アカウントのウォームアップ。
• 専用 IP のウォームアップ。

ピークに備えましょう。製品のローンチ、パスワード再設定が集中する事象、ブラックフライデーのセール、セキュリティ通知などでは、日々の平均をはるかに上回る送信量が発生することがあります。

分析とエクスポート

最低限必要なレポートです。

• 送信数。
• 配信数。
• バウンス数。
• 保留数。
• 苦情数。
• 配信停止数。
• テンプレートごとの成果。
• プロバイダーからのエラー応答。
• 関連する場合は収益やコンバージョンのイベント。

開封とクリックは慎重に扱ってください。プライバシー保護機能、画像のブロック、ボットの動作によってエンゲージメントの指標が歪むことがあります。トランザクションメールでは、開封率よりも配信の成否とユーザーの行動完了の方が重要な場合が多くあります。

受信メールの解析

受信メールの解析は、ユーザーが返信したり製品へコンテンツを送ったりする場合に重要になります。

活用例です。

• サポートへの返信。
• メールからのチケット作成。
• 返信によるコメント投稿。
• 承認のワークフロー。
• 転送された領収書。
• 受信メールからのリード獲得。

受信メールの解析をロードマップに入れているなら、ドキュメント、ルーティング、セキュリティ制御、添付ファイルの扱いが明確なプロバイダーを選びましょう。

メール API での到達性

API を導入しただけでは到達性の課題は解決しません。

次は依然として必要です。

• SPF。
• DKIM。
• DMARC。
• 認証済みの送信ドメイン。
• 一貫した送信者情報。
• 整備されたリスト。
• バウンスの処理。
• 苦情の処理。
• マーケティングメッセージにおける明確な配信停止手段。
• 内容の適合性。
• 無理のない送信頻度。
• 監視。

新しいドメインや IP では、段階的にウォームアップしましょう。リスクが低くエンゲージメントの高いメールから始め、評判が安定するにつれて送信量を増やします。

可能な限りメッセージの種類を分けましょう。

• 認証とセキュリティ。
• 領収書と注文の更新。
• 製品のライフサイクル。
• マーケティング。
• 大量のプロモーション。

攻めたプロモーションのキャンペーンが、パスワード再設定や領収書の配信を損なうようにしてはいけません。

エラー処理とリトライ

メール API の失敗は分類すべきです。

リトライすべきもの。

• タイムアウト。
• プロバイダー側の一時的なエラー。
• 待機後のレート制限。
• ネットワーク障害。
• 一時的なキューの問題。

いつまでもリトライしてはいけないもの。

• 無効な受信者アドレス。
• 認可されていない API キー。
• 無効なテンプレート ID。
• 必須フィールドの欠落。
• 除外済みの受信者。
• ポリシーや法令順守によるブロック。

指数バックオフを使い、リトライ後も失敗するメッセージにはデッドレターキューを用意しましょう。

重要なメールには、必ず運用上の経路を用意してください。

• サポートが再送できるか。
• ユーザーが自分で再送を要求できるか。
• エンジニアリングがイベントを追跡できるか。
• プロバイダーのレスポンスを確認できるか。
• プロバイダーに受理されたかどうかを証明できるか。

メール API 実装チェックリスト

公開前にこのチェックリストを使いましょう。

1. メッセージの種類と担当を決める。
2. API のプロバイダーとフォールバックの方針を選ぶ。
3. 送信ドメインを認証する。
4. SPF、DKIM、DMARC を設定する。
5. ステージングと本番の API キーを作成する。
6. シークレットを安全に保管する。
7. メッセージサービスまたはアダプターを構築する。
8. 冪等キーを追加する。
9. 構造化されたログを追加する。
10. リトライとデッドレターの挙動を作る。
11. テンプレートを作成する。
12. パーソナライズと代替値を検証する。
13. Webhook を設定する。
14. プロバイダーのメッセージ ID を保存する。
15. バウンス、苦情、配信停止を処理する。
16. 再送とステータス確認のためのサポート用ツールを用意する。
17. エラー率と配信率を監視する。
18. レート制限と障害対応の手順を文書化する。

プロバイダー選定のスコアカード

各ベンダーを 1 から 5 で採点しましょう。

多くのチームにとって、正解は「最も安いメール API」ではありません。顧客が頼りにしているメールについて、運用上のリスクを最も減らしてくれるプロバイダーです。

よくある失敗

次は避けましょう。

• アプリケーションのあちこちのコードから直接送信すること。
• API キーや個人情報を含むペイロード全体をログに残すこと。
• すべてのエラーを一時的なものとみなしてリトライすること。
• プロバイダーのメッセージ ID を無視すること。
• サポートから「メールは届いたのか」と聞かれるまで Webhook を後回しにすること。
• パスワード再設定と大量のマーケティングを同じ送信者評価の経路に混ぜること。
• すべての言語に 1 つのテンプレートを使い回すこと。
• テンプレート変数の代替値を省略すること。
• 開封を配信の証拠や顧客の成功と取り違えること。
• 明確な方針もないまま、マーケティングの配信停止ロジックで必須のアカウントセキュリティ通知まで止めてしまうこと。
• 無料プランだけでプロバイダーを比較すること。
• ウォームアップなしで大量送信を始めること。

はじめかた

新しく実装するなら、安全で最短の道を選びましょう。

1. パスワード再設定や注文確認など、トランザクションメールを 1 種類から始める。
2. 製品のコードを特定のベンダーに結びつけず、プロバイダー用のアダプターを作る。
3. ドメイン認証を追加する。
4. Webhook によるステータス追跡を追加する。
5. サポートから状況が見える仕組みを追加する。
6. テンプレートと多言語対応を追加する。
7. ライフサイクルと EC の自動化へ広げる。

すでにマーケティングと CRM に Brevo を使っているなら、Brevo のトランザクション API から始め、必要なイベントデータを対応づけましょう。製品に EC のデータを Brevo へ流し込む必要があるなら、ライフサイクルのメッセージを増やす前に、Tajo で顧客、同意、商品、カート、注文のイベントを接続してください。

SMTP での設定については、SMTP 完全ガイドと無料 SMTP サーバーガイドをご覧ください。

関連ガイド

• トランザクションメールサービスガイド
• トランザクションメールの例
• SMTP 完全ガイド
• SPF、DKIM、DMARC：メール認証完全ガイド
• メール自動化ガイド
• Brevo と Shopify の連携