「届かない」を
具体的な段階まで特定
認証コードメールの問題は、たいてい「届かない」の一言で表されます。しかし実際には、リクエスト、生成、キュー投入、配信、受信、利用など複数の段階が関係しています。効果的な切り分けには、再送を繰り返すのではなく、各段階を同じタイムライン上で関連付けて記録することが重要です。
まず結論です。たまたま1回タイムアウトしたからといって、メールシステムが使えないとは限りません。送信ボタンを連打しても、問題が解消した証明にはなりません。2026年に信頼できる方法は、認証コードの発行を1つの短いトランザクションとして扱い、相関ID、各段階の時刻、明確な結果で記述することです。
1. まず5段階の配信モデルを作る
第1段階は、ユーザーがリクエストを実行することです。ページの送信が本当に成功したか、APIが受け入れ可能なステータスを返したか、フロントエンドが失敗を誤って成功と表示していないかを、ここで確認します。第2段階は、業務システムが認証コードを生成し、メールタスクを作成することです。テンプレートのレンダリングに失敗すると、メッセージは送信キューにすら入りません。
第3段階は、メールサービスがタスクを受け付け、配信を試みることです。第4段階では、宛先の受信システムがメールを受信して表示します。最後の段階は、ユーザーがメールを開いて認証コードを送信することです。経路を分けて記録すれば、「メールが届かない」は「タスクが14:03:21にキューへ入り、14:03:58に受信され、フロントエンドの一覧には14:04:20に表示された」と書き換えられます。後者なら、修正すべき場所を特定できます。
送信APIが成功を返しても、それはタスクが受け付けられたことを示すだけで、宛先のメールボックスに表示されたことまでは意味しません。テスト記録には「リクエスト成功」と「受信して表示された時刻」を分けて残してください。
2. 同じ時計で4つの時刻を記録する
各回では新しいアドレスを1つだけ使い、トリガー、APIレスポンス、メールの表示、認証コードの送信という4つの時刻を記録します。チームが複数のタイムゾーンで協業する場合は、時刻をUTCに統一し、画面キャプチャにはローカルタイムゾーンの説明も残します。通常は秒単位で十分で、ミリ秒単位のスクリーンショットまで求める必要はありません。
RelayTmpで短期テストを行う場合は、まず使い捨て受信トレイで現在のアドレスをコピーしてから、今回の登録を開始できます。テストの途中でアドレスを変更しないでください。変更後の新しい受信トレイに、以前のタスクのメールは移動されません。1つのケースが終わってから次のIDを作成すると、結果を対応付けやすくなります。
| 段階 | 記録内容 | 確認できること |
|---|---|---|
| トリガー | 操作、時刻、ケース番号 | ユーザーは本当にリクエストを開始したか |
| レスポンス | ステータス、相関ID、所要時間 | 業務側はタスクを受け付けたか |
| 表示 | 件名、送信者、到着時刻 | メールが受信ビューに入った時刻 |
| 利用 | 送信時刻、成功または失敗 | コードはまだ有効か |
3. 再送に説明可能な待機時間を設定する
待機時間は、テスト担当者の忍耐ではなく、プロダクトの目標から決めるべきです。チームで「認証コードの95%は60秒以内に表示される」と定めているなら、60秒時点で未着を記録し、120秒で最終判定を行います。待機中に受信トレイを手動更新しても構いませんが、送信を再度実行してはいけません。
再送ケースに進むのは、前の待機時間が終わってからです。再送時には、古いコードがすぐ無効になるのか、2つとも短時間有効なのか、最後の1つだけが有効なのかというシステムルールを明確にします。そのうえで、到着順に古いコードと新しいコードをそれぞれ送信し、画面のエラーメッセージとバックエンドのルールが一致することを確認します。複数のメールが順不同で届く場合、「最新の1通」だけをテストすると、本当のリスクを見落とします。
- 通常経路：最初のトリガー後、目標時間内に到着して正常に利用できる。
- 遅延経路：最初のメールが目標時間を過ぎてから到着した場合でも、コードに十分な有効期間が残っているか確認する。
- 再送経路：2通目の到着前後に1通目をそれぞれ送信し、無効化ルールを検証する。
- 連続クリック経路：フロントエンドにはクールダウンの表示が必要で、通知なしに複数のタスクを作成してはいけない。
4. 証跡を引き継ぎやすい小さなパッケージにまとめる
質の高い不具合報告に、長時間の画面録画は必要ありません。最小限の証跡パッケージには、環境、ケース番号、マスキング済みの受信アドレス、4つの時刻、表示された件名、期待結果と実際の結果を含めます。業務側の相関IDを取得できる場合は、テスト番号と一緒に記載すれば、エンジニアがログを横断して検索できます。
認証コードに紐づく実在アカウントの情報をコピーしないでください。また、メール本文全体を公開チケットに貼り付けないでください。スクリーンショットでは、関係のない個人情報を隠します。使い捨てメールは低リスクのテストを分離するのに適していますが、本番ユーザーのメールを扱うためのコンプライアンス上の近道ではありません。
不具合を報告する前のチェック
- 初回送信か再送かを説明できる。
- 時刻がすべて同じタイムゾーンで記録されている。
- 期待結果に明確な閾値があり、「速いはず」になっていない。
- アドレスとケースが1対1で対応し、古い受信トレイを再利用していない。
- 証跡が匿名化され、実在ユーザーの認証コードが含まれていない。
5. 2026年に注目すべき指標
平均所要時間だけではロングテールを見落とします。少なくとも、タスク作成からプロバイダー受付まで、プロバイダー受付から宛先システムの受信まで、受信からユーザー表示までの3つの遅延を観測し、p50、p95、p99で確認します。失敗率もテンプレート、言語、宛先ドメイン、送信チャネルごとに分けてください。そうしなければ、特定地域や特定テンプレートの障害が全体の数値に埋もれてしまいます。
同時に、再送率と「最初のコードが届いた時点ですでに無効だった」割合も記録します。再送率の上昇は、配信の遅延だけが原因とは限りません。ページに明確なカウントダウンが表示されていない可能性もあります。最初のコードが大量に無効になるなら、有効期間、配信遅延、再送戦略が互いに衝突している可能性があります。指標の役割は調査範囲を絞ることであり、実際のケースに取って代わることではありません。
6. 使い捨て受信トレイで確認できることを知る
使い捨て受信トレイでは、あるテストアドレスがメールを受信できるか、いつ表示されるか、本文やリンクが読めるかを確認できます。ただし、すべてのメールプロバイダーで同じ結果になることを証明するものではなく、送信側による一時ドメインの制限を回避することもできません。送信側が意図的に拒否した場合は、アドレスを何度も変えて回避を試みるのではなく、ポリシーによる結果として記録してください。
決済、医療、仕事用のメインアカウント、その他長期的な復旧が必要なIDには、使い捨てアドレスを紐付けないでください。数週間にわたって同じ公開IDで回帰テストを行う必要がある場合は、メール転送コンソールから管理可能なエイリアスを作成してください。使い捨て受信トレイは、数時間以内に終わる低リスクのテスト用に残しておきます。
専用アドレスを作成し、最初のタイムラインを記録する
開くだけでコピー可能な使い捨てメールアドレスを取得でき、同じページで実際のテストメールを更新・閲覧できます。