2026 Firebase Auth メール確認テスト：ローカルのリンクをどう確認する？

確認リンクがターミナルに出たのに、実際の受信箱にはメールが見当たらない。
【判定】ローカルと自動テストはFirebase Authentication Emulatorを使ってください。実メールの配送確認は、ステージング環境で専用のテスト用メールアドレスを使う必要があります。

Firebase Authで登録後のメール確認を実装している開発者は、ローカル検証と実配送の境界を確認できます。
確認リンクを自動処理したいQA担当者や、公開前の受け入れ確認を進める個人開発者にも役立つ内容です。

ローカルのリンク確認と実メール確認は、証明できる範囲が違います

Firebase Authentication Emulatorはメール確認の操作をローカルで検証するための手段です。公式ガイドでは、エミュレーターが確認リンクをターミナルに出力すると説明されています。したがって、ローカル検証のために外部の受信箱を用意する必要はありません。ただし、この結果だけで実際のメール配送まで確認できたとは判断できません。Firebase Auth Emulatorの公式ガイドで、現在の動作を確認してください。

この切り分けをしないと、エミュレーターでは通るのにステージングではメールが届かない問題を見逃します。反対に、ローカルテストのたびに実メールを使うと、テスト用アカウントや不要な受信メールが増え、確認の手間もかかります。

ブラウザーでの手動確認は、リンクとアプリ状態を分けて見る

第一段階：登録から確認リンクの取得まで

Firebase Auth Emulatorを接続した状態でアプリからテストユーザーを登録し、メール確認を要求します。エミュレーターのターミナルに表示されたリンクを開きます。確認メールの送信処理が走ったのにリンクが見つからない場合は、アプリがエミュレーターへ接続しているか、エミュレーターのログを出力しているプロセスを見ているかを確認してください。

リンクを開いた画面に「確認済み」と表示されても、それだけでアプリが持つユーザー情報まで更新されたとは限りません。リンクの処理結果と、アプリ上でのユーザー状態は別々に検証します。

第二段階：アプリに戻り、確認済みの状態を再取得する

確認リンクを処理した後、アプリへ戻ってユーザー情報を再読み込みし、emailVerifiedを確認します。Firebase JS SDKにはユーザー情報を再取得するreloadと、確認コードを適用するapplyActionCodeがあります。実装に応じた使い分けはFirebase JS Auth APIのリファレンスで確認できます。

確認リンクが開けることと、アプリが確認済みとして扱うことは別の合格条件です。登録フローのテスト用アドレスを選ぶ際は、プライバシーを考慮したメールアドレスの使い分けも確認し、実ユーザーの個人情報を検証データに使わないようにしてください。

自動テストでは、今回のユーザーに対応する操作コードを使う

確認メールを送るたびに受信箱を手で開く代わりに、Firebase Authentication Emulator専用のREST APIから未処理のOOBコードを取得し、テストで確認処理へ渡す方法があります。公式RESTリファレンスには、エミュレーターで使うコードの取得方法が記載されています。APIのパスや応答フィールドは変更される可能性があるため、実装時にはFirebase Auth REST APIの公式リファレンスに照らして確認してください。

実行の流れは次のとおりです。

1. テスト対象のプロジェクト設定でAuth Emulatorを起動し、アプリから接続します。
2. テスト内でユーザーを作成し、そのユーザーにメール確認を要求します。
3. エミュレーターのOOBコード取得用REST APIから未処理コードを読み取ります。
4. 応答に含まれるメールアドレスや要求種別などを使い、今回作成したユーザーに対応するコードを選びます。
5. アプリの確認処理にコードを渡し、ユーザー情報を再読み込みしてemailVerifiedを検証します。
6. テスト終了後、エミュレーター内のテストユーザーを整理します。

未処理コードが複数ある状態で、応答の先頭を無条件に採用するのは避けてください。並行実行や前のテストの残りがあると、別ユーザーのコードを拾うおそれがあります。ユーザー識別情報と要求種別を照合し、処理済みのコードやテストデータを次の実行に持ち越さない設計にします。

独自のメール処理ページでは、成功・失敗・続行先を検証する

確認用リンクから独自の処理ページを使う場合は、ページが操作コードを正しく読み取り、対応する確認処理を呼び出すことを確認します。Firebaseのカスタムメール処理ページのガイドを実装の基準にしてください。

成功時の表示だけでなく、無効または処理できないコードを受け取った場合のエラー表示もテストします。加えて、リンクに続行先の情報を持たせているなら、処理後に意図した場所へ戻れるか確認してください。メール操作で状態を引き継ぐ公式説明は、続行先を扱う実装を見直す際に参照できます。

ステージングでは、実際の受信からアプリの復帰まで確かめる

ステージング環境では、エミュレーターでは再現できない配送経路を確認します。専用のテスト用メールアドレスで登録し、メールを受信できるか、リンクが想定したドメインと処理ページを開くか、確認後にアプリの状態が変わるかを順に検証してください。重要な個人用アカウントのメールアドレスをテストに使う必要はありません。

公開前の確認では、次の順番で結果を記録すると、失敗箇所を切り分けやすくなります。

• メールが届いたか。届かない場合は、送信設定やステージング側のメール経路を確認します。
• リンク先が意図した処理ページか。別の環境へ遷移する場合は、ドメインや続行先の設定を見直します。
• 確認処理後にアプリへ戻れるか。復帰先や画面表示が想定と異なる場合は、続行先の扱いを調べます。
• アプリのユーザー状態が確認済みになったか。リンクページの表示と状態取得の両方を確認します。

テスト用アドレスにも、サービス側の受け入れ可否や保持期間など、運用上の条件があります。必要な条件は利用するメールサービスで確認し、重要アカウントの回復や継続的な受信が必要な用途には長期利用できるメールアドレスを選んでください。アドレスの使い分けを考える場合は、一時アドレスの扱い方と有効期間の考え方も参考になります。

よくある疑問

Firebase Authentication Emulatorから実際の受信箱に確認メールは届きますか？

ローカルのエミュレーター検証では、実際の受信箱に届くことを前提にしません。確認用リンクはエミュレーターの実行ターミナルに出力され、そこから検証できます。実メールの配送経路、受信箱への到達、実際のリンク遷移を確かめたい場合は、ステージング環境で専用のテスト用メールアドレスを使ってください。

Firebase Authのローカル確認リンクはどこで取得できますか？

Firebase Authentication Emulatorでユーザーを作成し、メール確認を要求すると、エミュレーターのターミナルに確認用リンクが出力されます。自動化では、エミュレーター専用のREST APIから未処理のOOBコードを取得する方法もあります。取得したリンクやコードは、そのテストで作成したユーザーに対応づけて扱ってください。

リンクを開いた後、メール確認済みかどうかはどう判定しますか？

リンク先に成功メッセージが表示されたことだけでは、アプリ側のユーザー状態まで確認できたとは限りません。アプリでユーザー情報を再読み込みし、emailVerifiedの値を確認します。自動テストでは、対象ユーザーが今回の操作で作成したアカウントであることも合わせて確かめると、別ユーザーの状態を誤って合格扱いするリスクを抑えられます。

公開前にFirebase Authの確認メールが届くことをどう確かめますか？

ステージング環境から専用のテスト用メールアドレスへ確認メールを送り、実際に受信できるか、リンクが意図したドメインと処理ページを開くか、確認後にアプリのユーザー状態が更新されるかを順に確認します。エミュレーターのテストだけでは、メール配信設定や実際の受信結果は検証できません。

実際の受信確認が必要なステージング工程では、Firebase Auth Emulatorの検証とは分けて、テスト用メールアドレスを用意してください。受信先を一時的に分けたい場合は、登録不要ですぐ使えるtmp10の一時受信箱も選択肢になります。確認メールだけを試す用途に限れば、主メールアドレスを入力せずに済み、テスト由来のメールが普段の受信箱に混ざるのを避けられます。

よくある質問

TMP10 プロダクト提案 · さっそく始める

コード用の受信箱は使い捨て、続くメールは転送で

一度きりの認証コードなら、一時受信箱を発行して期限とともに丸ごと消しましょう。今後もメールが届くアカウントには、プライバシー転送エイリアスで本物のアドレスを隠してください。

一時受信箱を作成プライバシー転送を利用