2026 Chrome Email Verification APIは登録確認メールを代替できる？開発者向けテスト方法

「登録画面では検証成功なのに、確認メールが受信箱に届いた証拠がない」——この状態はAPIだけでは判定できません。
2026年10月23日時点の結論は、Chrome Email Verification APIは登録確認メールを完全には代替できない、です。今週はAPIの成功経路と従来メールのフォールバックを別々にテストしてください。

対象読者： 自社の登録・アカウント復旧にAPIを導入する開発者は、トークンで証明できる範囲を確認できます。
登録フローを受け入れテストするQA担当者は、APIとメールのテストを分ける基準を得られます。
導入可否を評価するプロダクトエンジニアは、適用条件と受信の証拠を照らし合わせられます。

まず分けるべき証拠は3種類です

Chrome Email Verification APIが扱うのは、条件を満たしたユーザーがメールアカウントを管理できることの確認です。メールを送信したこと、メールが受信側に受け入れられたこと、ユーザーが受信箱で読めたことは、それぞれ別の事実です。ChromeのAPI公式説明も、APIによる確認はメールの到達を証明しないとしています。

「メールアドレスを確認済み」にする条件も、アプリ側で決める必要があります。アカウントの管理権限が確認できた時点で登録を完了するのか、歓迎メールや通知メールも必ず送るのかを整理してください。後者なら、APIが成功してもメール送信と受信のテストは残ります。

Email Verification Tokenはサーバーで検証します

ブラウザーが返した値を受け取っただけでは、検証完了として扱えません。Chromeのサーバー実装ガイドを参照し、トークンの署名と宣言を検証します。メールアドレス、サイトのオリジン、フォームに結び付けたnonceが自社の期待値と一致することも確認します。

具体的な署名検証や宣言の扱いは、公開時点の公式ガイドと仕様に従って実装してください。WICGのAPI草案は仕様案であり、確立済みのWeb標準として扱うものではありません。APIの成功をアプリの登録完了と同一視せず、サーバーが検証した結果を登録状態に反映させます。

成功経路はブラウザーとアカウントの条件に左右されます

APIが動くかどうかは、利用者の操作だけでは決まりません。対象ブラウザー、メール提供元の参加状況、該当アカウントへのログイン、認証や許可の操作など、複数の条件が関係します。Chromeの公式ドキュメントとChrome Platform Statusへの案内で、公開時点の試験段階と適用範囲を確認してください。

Origin Trialの状態、対象範囲、試験用トークンの期限は変わる可能性があります。2026年10月の案内を含む公式資料をリリース前にも見直し、プロトタイプの対応範囲を安定したクロスブラウザー対応と誤認しないでください。試験状態やプロトコルの更新は、IETFのメール検証プロトコル草案も含めて確認できますが、草案は確定仕様ではありません。

最終更新：2026年10月23日。 Chrome公式API文書、サーバー実装ガイド、Chromeの更新案内、WICGおよびIETFの草案を根拠に整理しています。試験段階と適用範囲は公開前に各公式ページで再確認してください。

登録メールの回退は受信まで別に検証します

登録メールの回退テストでは、APIが使えない場合だけでなく、トークン欠落やサーバー検証失敗でも、既存のメール確認へ正しく移れるかを見ます。Chromeの公式資料が示す回退動作を確認しつつ、自社アプリの実装でも同じ分岐になることを確かめてください。送信ログが成功していても、それだけでは受信箱で読めたとは言えません。

QAでは、次の項目を自社のテスト環境または許可を得た環境で確認します。

• [ ] APIを利用できる条件と、対象ブラウザー・アカウントの試験条件を公式資料で確認する
• [ ] メールアドレス、オリジン、nonceを含む有効なトークンをサーバーで検証する
• [ ] トークンの欠落、改変、期限切れ、nonce不一致をそれぞれ拒否できることを確認する
• [ ] APIが利用できない場合に既存のメール確認へ回ることを確認する
• [ ] テスト用受信箱で本文を読み、リンクまたはコードから登録を完了する
• [ ] APIの検証結果、メール送信記録、実際の受信結果を別々に記録する

メールを確認する経路では、受信できた本文、リンクやコードの動作、登録状態の更新までをひと続きで確認します。テスト用アドレスを扱う際は、実在する利用者の個人情報を持ち込まない設計も必要です。テスト環境での合成アカウントやアドレスの扱いは、プライバシーに関するガイドも参考にできます。また、受信結果の見方はメール到達テストの案内で確認できます。

よくある確認事項

APIの成功は、確認メールが届いた証明になりますか？

いいえ。APIが示すのは、条件を満たしたユーザーがメールアカウントを管理できることです。送信処理の成功や受信箱への到達は別に確認してください。確認メールや通知メールを機能として提供する場合は、メール経路のテストを省略できません。

どのようなときに従来のメール確認へ回りますか？

対象ブラウザーやメール提供元が条件を満たさない場合、ユーザーが必要な認証操作を完了しない場合、トークンを取得できない場合などです。トークンの検証に失敗したときの動作はアプリ側でも明示し、画面表示と回退の両方をテストしてください。

Email Verification Tokenのサーバー検証はどうテストしますか？

公式のサーバー実装ガイドに沿って署名と宣言を検証し、アドレス、オリジン、nonce、有効期限が期待値に合うかを確認します。正常なトークンに加え、値の改変や欠落、不一致も試します。異常値で登録が許可されないことと、適切な代替経路へ進むことが確認ポイントです。

API導入後も受信箱を確認する必要がありますか？

必要です。APIはメールが実際に届いたことを示さず、従来の確認メールに回る経路も残ります。テスト用受信箱で本文を確認し、リンクまたはコードから登録が完了するまでを別の受け入れ条件にしてください。これにより認証経路とメール配送経路を切り分けられます。

自社の登録フローで従来メールへの回退を試すなら、テスト用アドレスで受信内容を確かめる方法も選択肢になります。ResendBoxの一時受信機能を使う場合も、実際に確認できるのはそのテストで受信したメールまでであり、Chrome Email Verification APIの対応範囲や本番環境の到達を保証するものではありません。利用前にResendBoxの日本語ページで現在の機能を確認し、APIの検証結果とメールの実受信を別々に記録してください。

よくある質問