この連載では、３０年以上の会員システム設計・運用経験をもとに、AI時代に求められる新しい会員システムの設計思想を探究しています。一つひとつの「当たり前」を問い直しながら、未来の会員システムを読者の皆さまと一緒に考えていきます。
前回は、メールアドレスを「属性（Attribute）」ではなく「状態（State）」として捉え直す必要があることを見てきました。
「存在すること」と「届くこと」は別の問題であり、大切なのは、そのメールアドレスが今も利用者とつながっている状態です。
その「つながる状態」は、誰がどのように管理しているのでしょうか。
前回、「メールアドレスにも寿命がある」という話をしました。メールアドレスの状態は、単に「存在する」「存在しない」の二択ではありません。
- 迷惑メールフォルダへ振り分けられる
- プロバイダ側から受信を拒否される
- 会社を退職して使えなくなる
- Yahoo!メールのように長期間利用されず停止される
つまり、メールアドレスには健康状態（Health）があるのです。では、その健康状態を、これからの会員システムはどう管理すればよいのでしょうか。今回は、世界のメール基盤が長年かけて築いてきた設計思想から、そのヒントを探ります。
私が紹介したいのは、メールサービスではありません。その「設計思想」です。
これから、Google・Microsoft・Apple・Yahoo!・AWSといった世界のメール基盤を取り上げます。けれども、目的は便利なメールサービスを紹介することではありません。学びたいのは、これらの基盤が30年以上かけて磨いてきた設計思想です。
世界のメール基盤に共通しているのは、メールアドレスという「文字列」ではなく、その状態（State）と、送信者への信頼（Trust）を管理しているという一点です。前回見たとおり、メールアドレスは属性（Attribute）ではなく状態（State）として捉えるべきものでした。世界は、すでに「状態」を管理する設計になっているのです。
だからこの記事は、メールインフラの解説ではありません。世界が育ててきた State と Trust の設計思想を、これからの会員システム設計へどう取り入れるか——それを考えるための回です。
1. 世界のメール基盤は「変化する」ことを前提に設計されている
Google、Microsoft、Apple、Yahoo!、AWS——。世界中のメールを支える巨大な基盤には、ある共通した前提があります。それは、「メールアドレスは変わる」ということです。利用者は転職し、サービスを乗り換え、アカウントを使わなくなり、ときに削除します。だからこれらの基盤は、メールアドレスを「決して変わらない固定ID」としてではなく、
変化し、ときに失われる「連絡先」
として設計されています。
会員システムの多くが「メールアドレスは変わらない」前提で止まっている一方で、メールを届ける側の世界は、もう何十年も前から「変わるもの」として向き合ってきました。
2. メールプロバイダ、それぞれの設計思想
同じ「メールを届ける」役割でも、各プロバイダが何を最優先に守っているかは異なります。しかし、どれも「メールアドレスという文字列」そのものを守っているわけではない、という点は共通しています。そして、それぞれの設計思想を会員システムへ置き換えると、どうなるか。各カードの下段に、その問いへの答えを添えました。
レピュテーション、利用者の反応、AIによる判定を組み合わせ、「この送信者は信頼に足るか」を継続的に評価します。認証が通っているだけでは、受信トレイは保証されません。
登録されたメールアドレスではなく、「今も連絡が取れる状態」を管理する。
SmartScreenや送信者評価で、企業の受信環境をマルウェア・なりすましから守ります。組織のメールを安全に保つことが最優先です。
会員と安心してつながり続けられる、信頼できる連絡環境を保つ。
「メールを非公開（Hide My Email）」やトラッキング防止に代表されるように、利用者が自分の連絡先を主導権を持って扱えるよう設計されています。
利用者が自分の連絡先を、主体的に管理できる設計を考える。
長い歴史を持つ受信基盤として、迷惑メール報告や長期未利用アカウントの停止を通じて、受け取る側の体験を保ち続けています。
会員一人ひとりが「受け取りやすく、つながり続けやすい」状態を設計する。
送信者ごとのレピュテーションを可視化し、バウンスや苦情の多い送信者には制限をかけます。一つの悪質な送信が、基盤全体の信頼を損なわないようにするためです。
メールを「配信」するのではなく、会員との「信頼」を維持する運用を考える。
送信者へ「迷惑メール報告」を返す Feedback Loop の仕組みをいち早く広めた存在。送信者と受信者が信頼を調整し合う土台を築きました。
会員からの反応を受け取り、関係を調整し続ける仕組みを持つ。
3. 日本独自の、キャリアメール文化
日本には、世界でも特殊な「キャリアメール」の文化があります。docomo・au・SoftBankが提供するメールは、迷惑メール対策のために独自の高度なフィルタや受信設定を備えてきました。SMTP通信の段階で受信を拒否することもあり、送信側からは配信エラーに見えても、実際にはアドレスが存在しているケースが少なくありません。
これは過剰に厳しいのではなく、利用者を迷惑メールや詐欺から守るための仕組みです。
キャリアメールが守っているのは、
利用者の安全です。
4. 「迷惑メールフォルダ」は、失敗ではない
送ったメールが迷惑メールフォルダに入ると、「失敗した」と感じます。しかし、各プロバイダにとって迷惑メールフォルダは、受信を全か無かで決めないための、洗練された「中間の置き場所」です。
- Google — 怪しいが断定はできないメールを隔離し、利用者の反応から学習する。
- Microsoft — 組織のポリシーと評価に基づき、危険性の高いものを分離する。
- Yahoo! — 利用者の報告を蓄積し、振り分けの精度を継続的に高める。
- Apple — 利用者の手元で選別できるよう、判断の余地を残す。
- キャリア — そもそも受信させない、より手前での防御を重視する。
つまり迷惑メールフォルダは、システムが「これは信頼しきれない」と判断した結果を、利用者に委ねるための仕組みなのです。
なぜ、認証だけでは足りないのか
SPF・DKIM・DMARC。すべてPASS。それでも、フィッシングメールは届きます。なぜでしょうか。それは、
認証できたことと、
信頼できることは、違うからです。
SPF・DKIM・DMARCが証明するのは「名乗っているドメインの本人か」ということ。なりすましでないことは分かりますが、その送信者が善良かどうかまでは分かりません。
- SPF
- DKIM
- DMARC
GoogleやMicrosoftが本当に見ているのはこちら。レピュテーション・利用者の反応・AI・送信履歴・苦情率まで含めて、「届けてよい相手か」を総合的に評価します。
- レピュテーション
- 利用者の反応
- AI
- 送信履歴
- 苦情率
メールの世界は、もう「認証」ではなく「信頼」を管理する時代なのです。
そして、この連載が最終的に育てたいのは、Trust（信頼）の先にある Relationship（関係性）です。Trust（信頼）は、Relationship（関係性）を維持するための、最も重要な要素です。認証から信頼へ、そして信頼から関係性へ——この流れこそ、会員システムが進むべき道だと考えています。
5. なぜ、メール配信サービスは大量配信できるのか
配配メール、MyASP、SendGrid、Amazon SES——。これらのサービスが何万通ものメールを届けられるのは、単に「たくさん送る力」があるからではありません。届かないメールを送り続けないための、緻密な仕組みを備えているからです。
- IP Reputation — 送信元IPの信頼度を常に監視する。
- Feedback Loop — 受信側からの迷惑メール報告を受け取り、配信を止める。
- ウォームアップ — 新しいIPから少しずつ送り、信頼を育てる。
- スロットリング — 受信側に合わせて送信速度を調整する。
- バウンス・苦情率の管理 — 不達や苦情が増えたら即座に対処する。
これは、大量配信できる技術ではありません。
信頼を維持する技術です。
6. すべてに共通していること
Google、Microsoft、Yahoo!、Apple、AWS、AOL、キャリアメール、配配メール、MyASP、SendGrid。守っているものも、得意なことも、すべて違います。しかし、管理しているものは同じです。
それは、メールアドレスの「状態」と、
送信者への「信頼」です。
Googleも、Microsoftも、Appleも、AWSも、実は管理しているのは State（状態） です。前回、メールアドレスを属性（Attribute）から状態（State）へ捉え直すという話をしましたが、世界は、すでに「状態」を管理する設計になっているのです。この事実こそ、会員システムが受け取るべき最大の学びだと考えています。
7. 会員システムだけが、昔のまま
これだけ世界が「状態」と「信頼」を管理しているのに、多くの会員システムは、今もメールアドレスを「登録された変わらない文字列」として扱い続けています。これは、思わぬ落とし穴につながります。
たとえばスパムトラップ。これは、かつて使われていたものの放棄されたメールアドレスを、プロバイダが「罠」として再利用し、そこへ送ってくる送信者を「古いリストへ無差別に送る悪質な送信者」と判定する仕組みです。
健康状態を確認せずに古いメールアドレスへ送り続けると、スパムトラップに当たり、送信ドメイン全体の評価が下がります。その結果、本来届けたい優良な会員へのメールまで届かなくなる——会員システムそのものが「悪質送信者」と見なされてしまうのです。
8. メールアドレス・ヘルスチェックという考え方
そこで必要になるのが、メールアドレスを「状態」で捉えることです。私たちは、メールアドレスを次のようなヘルス（健康状態）で管理することを提案しています。
大切なのは、これらの状態を一度きりで終わらせず、継続的に観測し、更新し続けることです。人間に定期的な健康診断があるように、メールアドレスにも健康診断が必要な時代になりました。
9. 本当に管理したいもの
世界のメール基盤は、メールアドレスを管理しているのではありません。信頼できる通信を管理しています。会員システムも、同じです。管理すべきものは、メールアドレスという文字列ではありません。
その人と、今もつながり続けられるか。
という、関係性です。
将来的には、SMS、LINE、プッシュ通知など、連絡手段はさらに増えていくでしょう。しかし、それらを支える中心には、今もなおメールアドレスがあります。メールアドレスは、これからも会員IDであり続けるでしょう。しかし、変わるべきなのは、メールアドレスとの付き合い方です。
最後に、この回でいちばんお伝えしたかったことを書きます。私が提案したいのは、メールアドレスやヘルスチェックという「仕組み」そのものではありません。世界のメール基盤が30年以上かけて育ててきた設計思想を、会員システムへ取り入れることです。
管理したいのは、メールアドレスではありません。その人と、今も信頼してつながり続けられる状態（State）です。その状態を継続的に観測し、そこから Relationship（関係性）を育てていく。State（状態）から Trust（信頼）へ、そして Trust（信頼）から Relationship（関係性）へ——。
メールアドレス・ヘルスチェックは、その設計思想を実践するための、最初の設計原則です。
私は、この考え方を「メールアドレス・ヘルスチェック」と呼んでいます。これは単なるメール管理ではありません。人との信頼関係を設計するための、新しい会員システム設計思想です。
連載ロードマップを見る
バウンス管理・スパムトラップ対策・メールアドレスのヘルス分類について、PayAI NEXTでは現在の会員データの状態をヒアリングし、「メールアドレス・ヘルスチェック」を前提とした会員システムの設計・運用プランをご提案しています。お気軽にご相談ください。
1997年よりインターネット業界に従事。2007年の創業以来、EC、メディア、SaaS、コミュニティサイトなど数多くの会員ビジネスの立ち上げと成長を支援。
30年近く会員システムの設計・運用に携わる中で、システムは「会員を管理するもの」から「人と人との関係（Relationship）を育てるもの」へ転換すべきだと確信。現在は、AI時代における次世代のシステム設計思想として「Relationship OS」を提唱しています。
また、自身も宿泊施設の運営で現場に立ち続け、『起きている時間はすべて仕事であり、システムへの探求』という圧倒的な熱量で、会員ビジネスの未来に向き合っています。
「人との関係は設計できるのか」という問いに、これからも人生をかけて愚直に向き合い続けていきます。