Passkeyでログインできず、復旧メールも届いたのにアカウントへ戻れません。
最短の確認方法は、Passkey認証とメール復旧を別々に実行し、受信・リンク処理・復旧後の状態を個別に合否判定することです。
開発者：自社製品でPasskey認証とメールによる復旧を実装している方が対象です。
QAエンジニア：受信、リンクの処理、アカウント状態を回帰確認する方に役立ちます。
セキュリティ担当者：復旧経路が製品の安全要件を満たすか確認する方も、証拠の残し方を確認できます。
最初に決めるのは、認証と復旧を別の合格条件にすることです
Passkeyログインは、登録済みの認証情報を使ってログインする経路です。メール復旧は、Passkeyが利用できない場合などに、製品が定めた別の手続きでアカウントへアクセスできる状態を取り戻す経路です。片方が成功しても、もう片方の確認にはなりません。
メールが届いたことも、復旧完了の証明ではありません。メール生成、送信サービスによる受け付け、テスト担当者が実際にメールを読めたこと、リンクを処理してアカウント状態が変わったことを、別々のチェック項目として扱います。
復旧手段は製品ごとに異なります。公式のPasskeyユーザージャーニー資料ではメールや電話による回復の選択肢が説明されていますが、これはすべての製品に同じメール復旧を義務づけたり、リンクの動作を定めたりするものではありません。自社の仕様と適用する技術資料を照らし合わせてください。
開発者：復旧入口と期待する状態を仕様に落とします
まず、自社製品でPasskeyが使えないときに利用者へ提示する入口を確認します。Passkeyの削除、認証情報が使えない状況、アカウントの回復など、実装上の条件ごとに復旧を開始できるか、開始後にどの確認を求めるかを記録します。他のサービスの画面や操作を、自社製品の標準動作とみなさないでください。
メールを使う場合は、次の方式を混同しないようにします。
- メール確認コード：受信したコードを入力して、製品が定めた確認を行います。
- ログインリンク：リンクを使ってログインする方式です。復旧を完了する手順とは限りません。
- アカウント復旧リンク：アカウントの回復を開始または完了するためのリンクです。開いた後に求める操作や状態の変化を仕様で定義します。
これらは用途も結果も同じではありません。実装に合わせて、開始条件、メールの種類、成功後の状態、失敗時に表示する案内をテスト項目にします。
QA：受信から復旧完了までを時系列で検証します
準備：対象のアカウントと復旧要求を結びつけます
自社製品のテスト環境で専用のテストアカウントを用意し、復旧要求を開始します。実行ごとにテストアカウント、要求の識別情報、開始した時刻を記録すると、前回のメールや別アカウント宛てのメールとの取り違えを防ぎやすくなります。
宛先が想定したアカウントのものか、本文の案内が自社の仕様と一致しているかも確認します。メール本文や記録に、実在する利用者の個人情報を使わない運用は、テスト環境のデータを整理するうえでも重要です。テスト用アカウントと受信先を分ける考え方は、登録メールを安全に扱うための確認事項も参考になります。
次の節目：生成・送信受付・実受信を切り分けます
アプリケーションが復旧メールを生成した記録、送信サービスが要求を受け付けた記録、受信側でメールを読めた事実を、別の証拠として残します。送信受付の記録だけでは、受信箱で内容を確認できたとはいえません。反対に、メールが見当たらない場合も、アプリ側で生成されなかったのか、送信後に届かなかったのかを分けて調べられます。
テストでは、受信したメールの宛先と本文を照合し、実行中の復旧要求に対応するものか確かめます。受信箱を後から確認する運用では、メールの保管期間や確認可能な範囲も先に把握してください。受信箱の有効期間を確認する視点を使うと、テストの途中でメールを確認できなくなるリスクを検討できます。
リンク処理：画面表示ではなく、操作結果まで追います
受信メールのリンクを開いたら、自社製品が要求する手順を最後まで実行します。そのうえで、復旧が成功した場合にアカウントの状態や、その後のログイン結果が期待どおりかを確かめます。ページが表示されただけ、または「完了」の表示が出ただけで終了せず、実際に目的の操作が成立したことを確認します。
失敗時やリンクの再使用時の扱いも、製品が定めた挙動と照合します。たとえば、無効なリンクを受け付けない仕様なら、その結果が利用者に分かる形で示され、アカウント状態が意図せず変化しないことを確かめます。リンクが有効な時間や再使用の可否は製品実装によるため、一律の期待値を設けないでください。
QA：復旧メールとリンクの証拠を安全に残します
復旧リンクには、操作に使える秘密情報が含まれる場合があります。リンク全体やトークンが不要なアプリケーションログ、画面共有、スクリーンショット、課題管理の記録へコピーされないかを確認します。証跡として必要なのは、テストの識別情報、確認したメールの種類、操作結果、状態の変化です。秘密の値そのものを保存する必要があるかは、テストの目的に照らして見直します。
アカウント復旧を扱うNISTのデジタルIDガイダンスも、復旧を独立したアカウント管理上の課題として確認する際の資料になります。そこに記載された指針を、個別製品の仕様や適用条件を確認せず、そのまま実装済み機能の保証として扱わないようにします。
セキュリティ担当者：メール復旧をPasskeyと同等と決めつけません
メール復旧は、製品が設けた代替の経路です。Passkeyの認証と同じ安全性を持つと、テスト結果だけから判断することはできません。復旧に使うメールアドレスがどのように確認されているか、誰が手続きを開始できるか、復旧完了後にどの操作が可能になるかを、製品の脅威モデルや要件に照らして確認します。
FIDOのPasskey作成・サインイン体験ガイドも、Passkeyのサインインとアカウント復旧の体験を検討する参考資料です。資料にある推奨と、自社製品で採用した仕様・テスト結果は区別して記録します。
チーム：証拠の揃い方で、再テストの範囲を決めます
リリース判定では、次の項目を個別に記録します。
- Passkey認証情報を使ったログイン結果
- 復旧要求に対するメール生成と送信受付の結果
- テスト担当者が対象のメールを受信・確認できた結果
- 復旧リンクを処理した結果と、その後のアカウント状態
- 今回確認した範囲、および未確認の範囲
自動テスト内でメール生成だけを検証したなら、実際の受信やリンク処理まで通ったとは記載しません。反対に、受信箱で確認できたメールも、アカウントの回復まで完了した証拠にはなりません。実際のメール配送経路を確認する必要がある製品では、テスト環境の設定に応じて、管理された受信先を使う外部受信確認を追加します。
判定ツール：該当する項目にチェックして、実施範囲を決めます
変更した箇所に応じて、該当する項目を選んで実施します。複数の項目に該当する場合は、それぞれのテストを行います。
- [ ] Passkey認証だけを変更した：Passkey認証情報でログインできるか確認します。メール復旧は今回の合格対象に含めず、未検証として記録します。
- [ ] 復旧メールの生成または送信設定を変更した：メール生成と送信受付に加え、テスト用受信先で実際にメールを読めるか確認します。リンク処理は別の確認項目として扱います。
- [ ] 復旧リンクの処理を変更した：対象メールを受信し、リンクを使った操作、成功・失敗時の結果、復旧後のアカウント状態まで確認します。
- [ ] 復旧後のログインや権限を変更した：復旧を完了した後、アカウント状態、その後のログイン可否、製品が定める権限を確認します。
- [ ] 実際の受信経路まで保証する必要がある：アプリケーションの送信記録だけで合格にせず、管理可能な受信先を使う外部受信確認を追加します。
Passkey認証だけを変更した場合は、最初の項目を選び、復旧メールを未検証として残します。復旧メールやリンクも変更した場合は、該当項目を追加で選びます。どの分岐でも、Passkeyログインの合格をメール復旧の合格として代用しないでください。
受信テストでは、主メールアドレスをテストデータに含めずに確認する方法もあります。たとえば、DewinBoxの一時受信箱は、自社製品のテスト用メールを管理された受信先で確認する選択肢の一つです。利用前に、DewinBoxで現在確認できる受信機能と、登録の要否・受信可能な範囲を確認してください。銀行、決済、行政など長期的な本人確認やアカウント復旧が必要な用途には、一時受信先を使わず、管理可能なメールアドレスを選びます。
よくある質問
Passkeyでログインできたら、メール復旧の確認も済んだことになりますか？
いいえ。Passkeyの検証で確認できるのは、対象の認証情報を使ったログイン経路です。復旧メールの生成や受信、リンクの有効性、復旧後のアカウント状態は別の証拠として確認してください。両方の経路を実装している製品では、それぞれ個別に合否を記録します。
復旧メールが今回のテストで送られたものか、どう見分けますか？
テスト用アカウントと復旧要求を対応づけ、要求を開始した時刻やテスト実行の識別情報を記録します。メールの宛先や本文に含まれるアカウント情報も照合し、過去のメールを誤って開いていないことを確認します。実行ログには秘密のリンクやトークンを残さないようにします。
復旧リンクを開いた後は、どの状態まで確かめるべきですか？
画面が表示されたことだけで終えず、製品が求める操作の完了、アカウント状態の変化、その後のログイン可否まで確認します。期限切れや再使用などの挙動は、製品の仕様に沿って検証します。リンクを開いた後に期待する変化が起きていなければ、復旧成功とは判定しません。
メールによるアカウント復旧は、すべてのPasskey製品で同じ動作ですか？
同じではありません。メールを回復手段として提示するかどうか、確認コード・ログインリンク・復旧リンクのどれを使うか、リンク処理後に何が変わるかは製品の実装によります。自社製品の仕様と適用する公式資料を基準にし、別製品の画面や手順をそのまま期待値にしないでください。
Passkeyのログイン試験とメール復旧試験を分け、実際に受信できることまで確認すると、アプリの記録だけでは分からない配送経路の問題も切り分けられます。主メールをテスト登録先に使いたくない場合は、DewinBoxの一時受信箱を候補にできます。登録不要で使えるかを含め、DewinBoxのページに記載された実際の機能を確かめてから、テスト環境に合う受信先として選んでください。
よくある質問
Passkeyでログインできたら、メール復旧の確認も済んだことになりますか？
いいえ。Passkeyの検証で確認できるのは、対象の認証情報を使ったログイン経路です。復旧メールの生成や受信、リンクの有効性、復旧後のアカウント状態は別の証拠として確認してください。両方の経路を実装している製品では、それぞれ個別に合否を記録します。
復旧メールが今回のテストで送られたものか、どう見分けますか？
テスト用アカウントと復旧要求を対応づけ、要求を開始した時刻やテスト実行の識別情報を記録します。メールの宛先や本文に含まれるアカウント情報も照合し、過去のメールを誤って開いていないことを確認します。実行ログには秘密のリンクやトークンを残さないようにします。
復旧リンクを開いた後は、どの状態まで確かめるべきですか？
画面が表示されたことだけで終えず、製品が求める操作の完了、アカウント状態の変化、その後のログイン可否まで確認します。期限切れや再使用などの挙動は、製品の仕様に沿って検証します。リンクを開いた後に期待する変化が起きていなければ、復旧成功とは判定しません。
メールによるアカウント復旧は、すべてのPasskey製品で同じ動作ですか？
同じではありません。メールを回復手段として提示するかどうか、確認コード・ログインリンク・復旧リンクのどれを使うか、リンク処理後に何が変わるかは製品の実装によります。自社製品の仕様と適用する公式資料を基準にし、別製品の画面や手順をそのまま期待値にしないでください。
受信経路をもう一度シンプルに整える
確認コードの受け取りには期限付きの受信箱を作成します。通知が長く続く場合は、一時停止できる長期転送エイリアスに切り替えましょう。