メール設計ガイドライン
Mail Design Guidelines
Skip to content
はじめに
電子メールは、SMTP（Simple Mail Transfer Protocol）プロトコルが1980年代初頭に標準化されて以来、半世紀近くにわたり利用されている。多くのサービスで 「認証」 「販売促進」 「トランザクションの証明」 などにメールが用いられており、ユーザー体験にも直結する。
しかし、その長い歴史ゆえに、古典的な技術知識だけでは対応しきれない到達性の低下や遅延などの課題を引き起こしやすい。これはクラウドプロバイダーが提供するEメール送信サービスを用いても起こりえるため、モダンな環境下でも無視はできない。
そのため、SMTPプロトコルの理解に加えて、クラウドベースのメール配信サービスの特性を理解し、要件に応じて設計する能力が求められる。特に大規模なシステムでは信頼性・費用・保守運用制などの非機能要件も求められる。本ガイドラインは、メール送信で考慮すべき設計事項と推奨案をまとめる。
免責事項
- 有志で作成したドキュメントである。フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである
- 相容れない部分があればその領域を書き換えて利用することを想定している。プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること。本ガイドラインに必ず従うことは求めておらず、設計案の提示と、それらの評価観点を利用者に提供することを主目的としている
- 掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとする。掲載している情報は予告なく変更する場合がある
適用範囲
- コンシューマ（一般ユーザー）向けのメール送信を対象とする
- ただし、同一用途で使われるLINEについては本ドキュメントでは触れない
- 電気通信事業法でいう「電気通信事業」に該当しない通信である、取引関係に伴う事務連絡や企業からユーザーへの広告宣伝を目的する
- システムからの自動送信メールを対象とする。手動送信でのメルマガ送信や営業メールは対象外とする
- 企業のシステム管理者向けのメール送信（例えば、障害通知など）については、参考にできる部分も多いと思われるが、強く意識していない
- ServiceNowやZendeskといったメールを含む問い合わせ管理のSaaSサービスの運用設計やサービス選定なども対象外とする
- 主要なクラウドサービス（AWS SES, Microsoft Azure Communication Services, Google Cloud, SendGridなど）を用いるとし、スクラッチやOSSなどでのSMTPサーバの構築や運用については、触れないとする
用語
| 用語 | 説明 |
|---|---|
| トランザクションメール | ログイン通知や注文完了通知といったユーザーのアクションや、サービスの重要な変更をきっかけに送信される企業にとって重要な通知。ユーザーとの信頼関係を構築し、アカウントのセキュリティを保つ上で重要である |
| マーケティングメール | メールマガジンなどの広告・宣伝に用いるメール。販売促進や顧客との関係構築に重要なツールであるが、一歩間違えると迷惑メールとして認識され、逆にブランドイメージを下げてしまう |
| キャリアメール | 国内携帯通信キャリア（docomo, au, Softbank, 楽天）を指す |
| ESP | メール配信サービス（Email Service Provider）のこと。SendGridやAmazon SESなどが存在する |
謝辞
このアーキテクチャガイドラインの作成には多くの方々にご協力いただいた。心より感謝申し上げる。
- 作成者: 真野隼記、藤井亮佑、前原応光、宮崎将太、澁川喜規
- レビュアー: 募集中
Articles
- 2025.10.03 メール設計ガイドラインを公開しました