会員登録や問い合わせのフォームでメールアドレスを入力すると、「確認コードをお送りしました」と受信箱の確認を求められる——この一往復は、Webの本人確認で広く使われている手順です。2026年7月8日、Chromeの開発者向けブログで、この一往復そのものをなくす提案「Email Verification Protocol（EVP）」のオリジントライアル（origin trial。本番サイトで期間限定の実験に参加できるChromeの仕組み）の開始が発表されました。本記事では、Chrome公式ブログと仕様案、各ブラウザベンダーの公式見解を典拠として、EVPの概要、ユーザー体験がどう変わるのか、現在のブラウザの対応状況を整理し、現時点でこの技術を導入すべきかどうかを検討します（記載の状況はいずれも2026年7月12日に確認したものです）。

結論から — 本番導入は時期尚早、「注視」が妥当

先に判断を示します。現時点で、EVPを本番の認証フローとして導入すべき段階にはありません。理由は次のとおりです。

  1. 現在動くのはChromeデスクトップ版のオリジントライアルのみで、対象はChrome 150〜153。実験はおよそ2026年9月上旬までの期間限定です
  2. 仕様は策定途中で、後方互換性のない変更が公式に予告されています
  3. メールプロバイダ側の対応が必須の仕組みですが、参加を公表しているプロバイダはGmailのみです
  4. 他ブラウザは追随しておらず、Mozillaは「defer」（判断保留）、WebKit（Safari）は見解未表明です

一方で、EVPはトークンが来なければ従来の確認フローに戻るだけの「上乗せ（プログレッシブエンハンスメント）」として設計されており、試すこと自体のリスクは小さく抑えられています。確認コードでの離脱が課題になっているサービスが、フォールバックを維持したまま実験に参加することには合理性があります。以下、順に見ていきます。

Email Verification Protocol とは

Chrome公式ブログは、この提案を次のように説明しています。

The Email Verification API is a proposal that allows the browser to communicate directly with the email provider to verify that the user owns the email address. Users select an email from the browser’s autofill or autocomplete suggestion, submit the form, and the site verifies the email address with the provider without sending an email or interrupting the user’s flow.

（Email Verification APIは、ブラウザがメールプロバイダと直接通信して、ユーザーがそのメールアドレスを所有していることを検証できるようにする提案です。ユーザーはブラウザのオートフィルまたはオートコンプリートの候補からメールアドレスを選んでフォームを送信し、サイトはメールを送ることもユーザーの流れを中断することもなく、プロバイダとの間でそのアドレスを検証します）

つまり、これまで「確認メールの送信と受信箱での操作」で行っていた所有確認を、ブラウザ・メールプロバイダ間の暗号学的なやりとりに置き換える提案です。仕様は、W3CのTAG（技術諮問委員会）のフィードバックを受けて2部に分かれており、ブラウザ側のAPIはWICG（Web Incubator Community Group）で、プロバイダ側のプロトコルはIETFのInternet-Draftとして提案されています。

登場する3者

  • Verifier（検証者） — メールアドレスを収集し、検証したいサイト
  • Email Provider（メールプロバイダ） — そのアドレスのメールサービス（例: gmail.com）
  • Issuer（発行者） — そのメールのアカウントを管理するサービス（例: accounts.google.com）

検証の流れ

Email Verification Protocol のシーケンス図。Verifier site・Browser・Issuer の3者が並ぶ。ユーザーがIssuerにログインするとログイン状態がブラウザに通知される。ユーザーがVerifier siteを訪問し、メールアドレスとnonce入りのフォームでアドレスを選択すると、ブラウザがIssuerとの間でDNSによるissuer探索・アカウント確認・トークン発行を行い、完全なEVTを組み立てる。ユーザーがフォームを送信するとEVTがVerifier siteに渡り、検証が成功して「Email validated!」となる

図1: Email Verification Protocol の全体フロー（出典: Chrome for Developers ブログ、CC BY 4.0）

  1. ユーザーが、フォームのメール欄でオートフィル／オートコンプリートの候補から自分のアドレスを選択します。フォームには、サイトが用意した使い捨ての値（nonce）を持つ隠しフィールドが含まれています
  2. ブラウザが、アドレスのドメインのDNSレコード（_email-verification.<ドメイン> のTXTレコード）を引いてIssuerを特定し、Issuerがそのアドレスの有効なセッションを持っているか確認します
  3. Issuerがそのアドレスの Email Verification Token（EVT） を発行します。ブラウザはEVTに、サイトのオリジンとフォームのnonceを加えて鍵つきのJWT（SD-JWT+KB、RFC 9901）にまとめます
  4. フォーム送信時にこのトークンが隠しフィールドに入ってサイトに渡り、サイト側はアドレス・nonce・ブラウザとIssuerの署名などを検証します

Issuer側の探索やアカウント確認には、既存のFedCM（Federated Credential Management）APIの基盤——.well-known/web-identity、accountsエンドポイント、Login Status API——が再利用されています。

プライバシーの設計

途中のやりとりで各者が知る情報は限定されています。公式ブログは次のように述べています。

These requests don’t reveal any additional information about the user. The verifier site does not receive information during this step. The issuer only sees a request to verify the user exists; it does not see which site initiated the request.

（これらのリクエストがユーザーに関する追加情報を明かすことはありません。この段階で検証者サイトは何も受け取りません。発行者に見えるのはユーザーが存在するかどうかの確認リクエストだけで、どのサイトがそのリクエストを開始したかは見えません）

また、あるアドレスを初めて検証に使うときには許可プロンプトが1回だけ表示され、検証済みアドレスはChromeの設定（chrome://settings/contactInfo）から管理できます。

何を保証し、何を保証しないか

注意が必要なのは、EVPが確認するのは「ユーザーがそのアドレスのプロバイダに有効なセッションを持っていること」であって、メールの到達性ではない点です。

Email verification confirms that the user has an active session with the provider of their email address. It does not verify that your email reached the user.

（メール検証が確認するのは、ユーザーが自分のメールアドレスのプロバイダとの間に有効なセッションを持っていることです。あなたのメールがユーザーに届いたことを検証するものではありません）

ウェルカムメールやその後の通知が届くかどうかは別問題であり、必要ならこれまでどおり送信して確認することになります。

ユーザー体験はどう変わるか

従来のメール確認は、おおむね次の手順です。

  1. フォームにメールアドレスを入力して送信する
  2. サイトが確認メールを送る
  3. ユーザーがサイトを離れ、受信箱を開く（別アプリ・別タブへの切り替え。迷惑メールフォルダの捜索が必要なことも）
  4. 確認コード（OTP）を転記するか、リンク（マジックリンク）をクリックする
  5. 元のサイトに戻って続きを行う

公式ブログはこの手順の問題を、サイトからの離脱リスクとして説明しています。

Existing verification methods, like one-time passwords (OTPs) or email verification links (magic links), require the user to navigate away from your site. This disruptive process can increase the risk of the user, whether a human or an agent, abandoning their session entirely and never completing their authentication process.

（ワンタイムパスワード（OTP）や確認リンク（マジックリンク）といった既存の検証手段は、ユーザーにサイトを離れることを要求します。この流れを断ち切るプロセスは、人間かエージェントかを問わず、ユーザーがセッションを完全に放棄し、認証を最後まで終えなくなるリスクを高めかねません）

EVPが機能する環境では、この5手順が次の2手順になります。

  1. フォームでオートフィル候補から自分のメールアドレスを選ぶ（そのアドレスを初めて使うときだけ、許可プロンプトに1回応答する）
  2. フォームを送信する。送信後、「プロバイダがアドレスを検証した」旨の小さな通知が表示される

ユーザーはサイトを一度も離れず、確認メールも送られません。受信箱を開く・コードを転記する・迷惑メールフォルダを探すという工程が体験から消えることになります。

ただし、この体験には前提条件があります。

  • 同じブラウザプロファイルでメールプロバイダ（Issuer）にログイン済みであること。Gmailなら、そのGoogleアカウントにログインしている必要があります
  • アドレスをオートフィル／オートコンプリートの候補から選ぶこと。手入力されたアドレスへの対応は将来のリリースで予定されているとされ、現時点では対象外です

サイト実装側から見ると、入口はHTMLの2行です。

<input name="email-address" type="email" autocomplete="email">
<input type="hidden" name="token" nonce="rAnD0m-VaLuE"
       autocomplete="email-verification-token">

対応ブラウザ・対応プロバイダ・ログイン状態がそろったときだけ隠しフィールドにトークンが入り、入らなければサイトは従来どおり確認メールを送ります。機能検出（feature detection）のAPIは用意されておらず、「トークンが来たら検証し、来なければフォールバックする」という扱いが公式に案内されています。既存フローを壊さずに上乗せできる設計です。

なお、公開デモ（記事著者による検証側デモと模擬プロバイダのデモ）が案内されており、オリジントライアル参加前に流れを体験できます。GmailアドレスでもGoogleアカウントにログインしていれば試せるとされています。

現在の対応状況（2026年7月12日時点）

対象状況
Chromeオリジントライアル実施中。対象はChrome 150〜153（予定）、デスクトップのみ
メールプロバイダGmailが参加。他に参加を公表しているプロバイダは公式ブログでは確認できず
Firefox（Mozilla）公式見解は「defer」（判断保留、2026年1月）
Safari（WebKit）公式見解は未表明（見解要請のissueはオープンのまま）
標準化WICGの提案＋IETFのInternet-Draft。W3C勧告・RFCのいずれでもない

Chrome — オリジントライアルという「期間限定の実験」

blink-devメーリングリストのIntent to Experiment（実験実施の正式提案）によれば、オリジントライアルの対象はChrome 150から153まで、まずデスクトップのみで、Androidは後続予定です（WebViewでの提供は未定とされています）。Chrome 153の安定版リリースは2026年9月8日の予定（Chromium Dash）なので、実験期間はおよそ2か月半です。

重要なのは、オリジントライアルが「リリース前の機能への依存を防ぐ」設計になっていることです。公式ブログ自身が、トラフィック制限があること、そしてIssuer側APIは開発中で後方互換性のない変更（リクエスト形式の application/json への移行、HTTP Message Signaturesへの切り替え、Chrome側UXの変更）を見込むべきことを明記しています。

Mozilla（Firefox）— 「defer」

Mozillaの標準化ポジションでは、2025年11月に見解要請が出され、2026年1月に「defer」（判断保留）として整理されました。担当者は、explainerが問題設定や他の解決策（OpenID ConnectやPasskey等）との比較の詳細を欠いており、質的な判断ができないことを理由に挙げています。これは反対表明ではありませんが、支持でもありません。Google側はその後explainerと仕様を更新し、再度のレビュー要請を予定しているとIntent to Experimentで述べています。

WebKit（Safari）— 見解未表明

WebKitの標準化ポジションのissueは2025年11月に開かれたままで、2026年7月12日時点でApple側からの公式見解は書き込まれていません。なお、GoogleのIntent to Experimentには、TPAC（W3Cの年次総会）でWebKit側から「メールプロバイダではなく、WebOTPの拡張やIMAPクライアントの活用を選好する」旨の非公式なフィードバックがあったと記されていますが、これはGoogle側の記述であり、WebKitの公式見解ではない点に注意が必要です。

標準化の段階

ブラウザAPI側はWICG（W3Cの正式な標準化の前段階にあたるインキュベーション組織）のドラフト、プロバイダ側プロトコルはIETFの個人名義のInternet-Draft（draft-hardt-email-verification-00）です。W3C TAGの早期レビューの結果は「ambivalent」（賛否を留保）だったとGoogle側は報告しています。いずれも、複数ブラウザが実装する標準として合意された段階にはありません。

現時点でこの技術を導入すべきか

以上を踏まえて判断します。採用判断で見るべきは「いま動くか」だけでなく、実験終了後も動き続けるか・仕様は安定しているか・複数の実装が見込めるかです。

本番の認証フローとしての導入（確認メールの廃止・削減を前提とした設計変更）は時期尚早です。理由は結論部で挙げたとおりですが、特に重いのは次の2点です。第一に、オリジントライアルは2026年9月上旬（Chrome 153）までの期限つきで、トラフィック制限も課された「依存させないための実験」であることです。第二に、機能する条件が現状かなり狭いことです。Chromeデスクトップ版で、Gmail（または対応プロバイダ）のアドレスで、そのアカウントにログイン済みで、かつオートフィルから選択した場合——という条件をすべて満たしたときだけ動作し、モバイルは対象外です。スマートフォン経由の利用が多い日本の一般向けサイトでは、恩恵を受けられるユーザーはさらに限られます。

一方、フォールバックを維持したままの「実験参加」は別の判断になります。EVPは従来フローへの上乗せとして設計されており、トークンが来なければ何も起きないため、導入して失うものはほとんどありません。会員登録や購入導線で確認コードによる離脱が実際に計測されているサービスであれば、オリジントライアルに登録し、A/Bテストの枠組みで効果を測ることには合理性があります（公式ブログもA/Bテスト基盤への組み込みを案内しています）。いまはフィードバックが仕様に反映される段階であり、実データを持つ事業者の参加が歓迎されています。

今後の動向は、公式の evp-announce メーリングリストとChrome Platform Statusで追跡できます。

まとめ

  • Email Verification Protocol（EVP）は、ブラウザがメールプロバイダと直接やりとりしてメールアドレスの所有を検証し、確認コード（OTP）やマジックリンクを不要にする提案です
  • ユーザーの操作は「オートフィルからアドレスを選んで送信する」だけになり、サイトを離れる必要がなくなります。ただし検証されるのは「プロバイダとの有効なセッション」であり、メールの到達性ではありません
  • 2026年7月12日時点で動作するのはChromeデスクトップ版のオリジントライアル（Chrome 150〜153予定）のみで、参加を公表しているプロバイダはGmailだけです。Mozillaは「defer」、WebKitは見解未表明で、仕様には後方互換性のない変更が予告されています
  • したがって、本番の認証フローとしての採用は時期尚早です。確認コードでの離脱が課題のサービスが、フォールバックを維持したまま実験に参加することは合理的です

参考