本物のプロダクトは、その性質上たいていマルチユーザーです — チーム、ワークスペース、権限、招待機能。こうしたフローを正しくテストするには、同時に使える独立した受信箱がいくつも必要になります。使い捨てメールは、気づけばテスターの道具箱の中でもかなり頼れる存在になります。しかもそれは迷惑メールを避けるためではまったくありません。

受信箱がひとつでは足りない理由

自分自身のメールアドレスはすでにシステムに登録されているため、まったく新規のユーザーを再現することはできません。ましてや三人分の新規ユーザーを同時に、となるとなおさらです。多くのチームはプラスアドレス方式（[email protected] のような形）のQA共有Gmailアカウントに頼りがちです。ただ、これはうまくいくときはいいのですが、いつも通用するわけではありません。多くのアプリは「+」タグを削除したり拒否したりしますし、たとえ受け付けられたとしても、結局すべてのメールは同じ受信箱に届くため、どの「ユーザー」が何を受け取ったのかを後から解きほぐす作業が必要になります。

使い捨てメールを使ったワークフロー

temp-email.ai/temp-mailのタブはそれぞれが完全に独立した受信箱で、固有のアドレスを持っています。タブをいくつか開くだけで、送受信できる本物のユーザーが複数人分手に入ります。アカウント作成も不要、後片付けが必要な共有受信箱もありません。すべて1時間で自動削除されるので、個人のメールアドレスに紐づいたテストアカウントの山が残ることもありません。

テストする価値があるシナリオ

• チーム・ワークスペース招待: それぞれの招待メールが正しいアドレスに届き、リンクが正常に機能するか。承諾した際に、正しいワークスペースに正しい権限で参加できるか。
• 権限とロール: オーナー、管理者、閲覧のみのメンバーをそれぞれ別のユーザーとして登録し、各ロールが許可された範囲だけを正しく見えて（そして見えないように）いるか確認する（OWASP Authorization Cheat Sheetが参考になる）。
• 重複アカウントの処理: 異なるアドレスで2つのアカウントを登録し、その後どちらかを再利用しようとしたときにアプリがどう反応するか確認する。大文字・小文字だけが異なる同一アドレスのケースも含めて。
• 紹介・招待報酬フロー: 紹介した側への報酬は、紹介された側がサインアップして認証を完了した時点でのみ付与されるべき。両方が発火する様子を確認するには、稼働中の受信箱が2つ必要になる。
• マルチテナントの分離: 2つの異なる組織でアカウントを作成し、一方のテナントのデータがもう一方のメールや通知に絶対に現れないことを確認する（この種のリスクはNISTのマルチテナントに関するセキュリティガイダンスでも扱われている）。
• 同時サインアップ: 複数のユーザーを同じ秒内に登録し、トークン生成における競合状態（レースコンディション）や、他より大幅に遅れて届く認証メールがないか確認する。

メールが届いたら確認すべきこと

• 正しい宛先: 招待メールは意図した宛先だけに届いたか。
• 正しいリンク: 承諾・認証用URLは正しい環境を指しており、正しいワークスペースとロールのコンテキストを持っているか。本番環境へのハードコードされたリンクになっていないか。
• 正しい結果状態: 承諾後、ユーザーは正しい組織に、ロール通りの権限だけを持った状態で入っているか。
• 表示と分離: メールは正しくレンダリングされているか（ボタンがクリック可能で、名前が正しく入力されているか）。誤って他のユーザーのデータを参照していないか。

この方法が特に効果を発揮するのは、探索的テストとリリース前の手動リグレッションチェックだ。ものの数分で、小規模だが現実的な顔ぶれのユーザーを用意し、実際のチームがするようにプロダクトを一通り確認できる。正直に言っておきたい点が二つある。一部のアプリは既知の使い捨てメールドメインをサインアップ時にブロックするが、これは単にそのアプリ側のポリシーによるものだ。また、配信まわりの細かな挙動は本物のメールプロバイダでしか現れないため、リリース前にはGmailのような実際の受信箱でも最終確認をしておく価値がある。このように使えば、使い捨てメールは実際のユーザーがバグに遭遇する前に、マルチユーザーのフローをしっかりテストするためのシンプルで正直な方法になる。