認証コードを再送した後、
先に届いたメールは必ず使える？

メールの並び順ではなく、3つの時刻を記録する

2026年の登録フローでは、コード発行の処理がキューに入ることがよくあります。画面にリクエストを受け付けたと表示され、バックエンドで認証コードが生成され、その後メールサービスが配信を試みます。ユーザーが見る「送信済み」は、処理が作成されたことを示すだけの場合があり、メールが受信サーバーに届いた証拠にはなりません。2回目のリクエストがより速いキューを通ると、新しいコードが先に届き、古いコードが後から届くこともあります。

テストでは、少なくとも送信をクリックした現地時刻、受信トレイにメールが初めて表示された時刻、認証コードを送信した時刻を記録します。サーバーログを確認できる場合は、認証コードの発行時刻とメールタスクIDも記録します。メール本文の日付やDateヘッダーを受信時刻として扱わないでください。通常、これらは送信側が設定するものです。

ブラウザーのポーリングで分かるのは「ページが初めてメールを検知した時刻」です。精度はポーリング間隔、ネットワーク、ページが前面に表示されていたかどうかに左右されます。分単位の配信順の乱れを調べるには使えますが、ミリ秒単位の配信監視には向きません。厳密なサービスレベル指標を算出する場合は、スクリーンショットから時刻を推測せず、送信ログと受信側のログを使用してください。

1回だけ送信して、再現可能な受信基準を作る

まずテスト用受信メールボックスを開き、現在のアドレスをコピーして、残りの有効期間で今回のテストを完了できることを確認します。このアドレスは、操作する権限のあるテスト環境でのみ使用してください。資産、実運用アカウント、長期的な本人確認に使うIDの登録には、一時メールアドレスを使用しないでください。アドレスの有効期限と認証コードの有効期限は別々に管理されており、前者を延長しても後者は延長されません。

1. 未使用のテストアカウントを用意し、テスト環境、ページのバージョン、現地のタイムゾーンを記録します。
2. 送信は1回だけクリックします。リクエストが成功したか記録し、「メールを早く届かせる」ために連続でクリックしないでください。
3. 受信ページを開いたまま実際にメールが届くのを待ち、宛先、件名、本文の用途を確認します。
4. 表示された有効期限内に認証コードを送信し、検証結果を記録します。その後、同じコードをもう一度試して、使用済みになっているか確認します。

同じコードを2回目に送信したとき失敗すべきかどうかは、製品仕様によります。ワンタイムログイン用の認証コードは、正常に使われた後に無効になるのが一般的ですが、すべての製品がそうだと決めつけてはいけません。認証を担当するチームに、有効期間は発行時と送信時のどちらから始まるのか、検証成功後すぐに使用済みになるのか、同じアドレスで有効なコードを1つだけ保持するのかを確認してください。

ここですでにメールを受信できない場合は、登録テスト用ワークベンチに戻って、トリガーと配信を確認してください。すぐに再送テストへ進まないでください。正常な基準がないと、「古いコードが無効になった」ことと「そもそもコードが送信されていない」ことを混同しやすくなります。

再送は2回に分けてテストし、1回の試行で結論を歪めない

クールダウンが終わってからBをリクエストし、AとBをそれぞれ1回目、2回目として記録します。2通のコードが同じでも、数値だけを根拠に重複配信と判断しないでください。有効期間内は同じコードを再送するシステムもあれば、送信のたびに新しいコードを発行するシステムもあります。タスクID、送信ログ、製品仕様を照合して判断してください。

「再送すると旧コードは直ちに無効になる」と仕様で明示されている場合は、互いに独立した2回のテストを行えます。1回目はAをリクエストしてからBをリクエストし、Aを先に送信して拒否された結果を記録します。2回目は新しいセッションでAとBをリクエストし、Bだけを送信して検証が完了することを確認します。先にBを使い、その後Aが失敗したことから再送の仕組みが正しいと結論づけないでください。チャレンジ全体が終了したためにAが拒否された可能性もあります。

• 新しいコードの発行後も旧コードが通る：メールキューだけでなく、有効なチャレンジの保存と無効化のロジックを確認します。
• 新しいコードも失敗する：チャレンジID、セッション、テストアドレス、時刻を確認してから、有効期限を調べます。
• メールが届いた時点ですでに期限切れ：発行から配信までの時間差を、メール担当チームと認証担当チームで調査します。
• 再送がレート制限された：クールダウンの案内を記録し、許可された間隔でテストしてください。レート制限を回避してはいけません。

有効期限の境界も、別々のサンプルを使ってテストします。有効期間内、期限直前、期限切れ後にそれぞれ送信し、同じコードを何度も試してロックがかからないようにしてください。クライアント側のカウントダウンは目安であり、最終的な判定はサーバーが行います。ユーザー端末の時計のずれによって認証コードの成否が左右されるべきではありません。

複数タブの競合と、メールの重複受信を切り分ける

一方のタブでAをリクエストし、別のタブでBをリクエストすると、ページごとに異なるチャレンジやセッションが保持されることがあります。Bを最初のタブに入力して失敗しても、それだけでメールの配信順に問題があるとは限りません。まず1つのタブで再現し、次に複数タブでテストして、それぞれのページで行った操作と期待する結果を記録してください。

「同じメールを2通受け取った」場合は、少なくとも3つのケースを区別します。ページからのリクエストが2回送信された、バックエンドの再試行で重複配信された、受信画面に同じメールが重複表示された、のいずれかです。元のメールヘッダーを確認できる場合はMessage-IDを比較し、メールタスクのログと照合します。ただし、これは手がかりの1つであり、決定的な証拠ではありません。転送やメールプロバイダーの処理によって、関連フィールドが書き換えられることもあります。

メールを1通しか受信しなかったからといって、システムに冪等性の保護があるとは限りません。2つ目のタスクがまだ実行されていない場合や、メールプロバイダーが統合した場合もあります。重複防止の仕組みを検証するには、テスト対象システムのリクエストIDとタスク記録を確認してください。一時受信トレイで確認できるのは最終的に観測された内容であり、バックエンドの動作監査の代わりにはなりません。

ほかの人が再現できるテスト記録を残す

有効なレポートには、環境のバージョン、匿名化したアカウントID、アドレスの有効期限、コードをリクエストした時刻、メールを確認した時刻、コードを送信した時刻、画面の結果を含めます。実際の認証コードはA、Bに置き換えてください。ログと照合するときはタスクIDを記載し、有効な認証コードを公開チケットに貼らないでください。スクリーンショットに認証リンクが写っている場合は、共有前にトークンも隠してください。

結論はできるだけ具体的に絞ります。「2回目のリクエスト後、最初の認証コードが同じセッションで受け付けられた」は「認証コードに問題がある」よりも対応につながりやすい表現です。「受信ページで12秒後にメールが確認された」は「メールサービスに12秒の遅延があった」より正確です。中間のすべての処理を計測したわけではないからです。

時系列のテストが終わったら、メールの内容も確認しましょう。件名から用途が分かるか、有効期限が本文に記載されているか、スマートフォンで似た数字を見分けやすいか。次は通知メールの内容とプレーンテキストを確認するを読み、「メールが届いたこと」と「ユーザーが正しく使えること」を分けて検証してください。用語が分からない場合は、受信メール用語集をご確認ください。