会員登録フォームの数字を見ていると、必ず引っかかる段があります。メールアドレスを入力するところまでは進むのに、確認コードの入力画面で人が消える。
利用者に何をさせているかを分解すると、理由ははっきりしています。フォームにアドレスを入力し、メールアプリに切り替え、届くのを待ち、迷惑メールフォルダを探し、コードをコピーし、元のサイトに戻って貼り付ける。アカウントを作りたいだけの人に、アプリを2つ往復させているわけです。
この構造が問題だという認識は以前からありましたが、代わりの手段がありませんでした。所有していることを確かめる方法が、そのアドレス宛に何かを送る以外に無かったからです。ここに手を入れようという提案が、Email Verification Protocol（EVP）です。
確認の往復は、登録の入口を塞いでいる
WICG に提出された説明資料によれば、アクセス数の多い上位50サイトのうち95%がメールアドレスによるアカウント作成に対応しており、そのうち73%はメール確認が終わるまでアカウント作成を先へ進めさせません。
つまりメール確認は例外的な手続きではなく、Web でアカウントを作るときの既定の関門になっています。関門である以上、そこを通過できなかった人はサービスに到達しません。
現場での見え方はこうです。
- 送信したはずのメールが届かず、問い合わせが来る（迷惑メール判定、企業側のフィルタ）
- コードの有効期限が切れて再送を繰り返す
- 会社のアドレスで登録しようとしたが、そのメールは共有アカウントで開けない
- スマートフォンとパソコンをまたいでいて、そもそも同じ画面に戻れない
入力項目の削減や入力補助といった一般的なフォーム改善はEFO（入力フォーム最適化）で整理しましたが、確認コードの往復だけは、フォームの作りをどれだけ磨いても残ります。サイトの外へ利用者を出してしまう工程だからです。
EVP が変えるのは「証明の出どころ」
EVP は、メールを送らずにアドレスの所有を確かめる仕組みです。
流れとしては、利用者がサイトでアドレスを入力すると、ブラウザがそのメールプロバイダから署名済みのトークンを受け取り、サイトに提示します。サイトはトークンの署名を検証することで、そのアドレスの持ち主であることを確認できる。確認メールは発生せず、利用者がメールアプリを開く必要もありません。
証明を作る主体が、メールの受信箱からブラウザとメールプロバイダの間に移る、という整理になります。利用者から見れば「メールアドレスを選ぶ」操作に近く、体感としてはアカウント選択の画面に寄ります。
副次的に、フィッシングへの耐性が生まれる点も見逃せません。ブラウザが生成する所有証明には、そのとき開いているサイトの Origin が含まれます。偽サイトで取得された証明は、本物のサイトでは通らない。加えて、メールプロバイダ側から見れば「どこのサイトに対して証明が求められたか」が分かるため、不審な要求をその場で検知できる余地も出てきます。
パスワードを廃してデバイス側に鍵を持たせる流れとしては、パスキーへの移行と同じ方向の話です。ログインの認証はパスキー、登録時のアドレス確認は EVP、と別々の課題に別々の仕組みが当たっている、と捉えると位置づけが分かりやすくなります。
まだ「使える標準」ではない
ここが判断で最も重要な部分です。EVP は提案段階にあります。
2026年6月に IETF の Internet-Draft が公開され、2026年7月から Chrome でオリジントライアルが始まりました。Edge も同様に試験段階です。一方で Mozilla と WebKit は現時点で様子見の姿勢とされています。つまり Safari と Firefox の利用者には、当面届きません。
日本国内は iPhone の比率が高く、Safari を無視した設計はそのまま機会損失になります。ブラウザ横断で安心して使える機能かどうかを判断する考え方はBaseline を基準にしたコーポレートサイトの実装で扱ったとおりで、現時点の EVP はその基準を満たしていません。
したがって、いま作るサイトで「確認コードを廃止して EVP に置き換える」という選択は取れません。仕様側もそれを前提にしており、非対応のブラウザやメールアドレスでは、従来の確認コードやマジックリンクに戻せる設計が想定されています。
いま発注側が決めておけること
将来対応するかもしれない機能に費用をかける必要はありません。ただし、後から差し替えられる形にしておくかどうかは、いま決められます。
確認の工程を、独立した部品として切り出しておく。 登録処理の中に確認コードの生成・照合・再送・有効期限の判定が散らばっていると、方式を変えるときに登録処理そのものを触ることになります。「アドレスの所有を確認する」という役割で一箇所にまとめておけば、後から別の方式を足す作業で済みます。要件定義の段階で一文入れておくだけの話です。
離脱の計測を先に入れておく。 アドレス入力の完了数と、確認完了数を別々に取ります。この2つの差が、確認の往復で失っている人数です。数字が無い状態では、方式を変えても効果を説明できません。逆に数字があれば、改善の優先順位を感覚ではなく比較で決められます。
確認メールの到達率を先に確かめる。 新しい方式を待つ前に、いま送っているメールがそもそも届いているかを確認する価値があります。送信ドメインの認証設定が不十分なまま運用しているサイトは今でも多く、この場合は方式を変える以前の問題です。
登録直後にどこまで使わせるかを決める。 確認が終わるまで全機能を止めるのか、閲覧だけ許すのか。前述の73%という数字は「完全に止める」設計が多数派であることを示していますが、扱う情報の性質によっては緩められる場合もあります。ここは技術ではなく事業側の判断です。
次にやること
自社の会員登録フォームで、アドレスを入力した人のうち何%が確認を完了しているかを確認してください。この数字を持っていない事業者が大半です。数字が出た時点で、それが今後の判断すべての基準になります。
そのうえで、新しくフォームを作る予定があるなら、確認の工程を差し替え可能な形にしておくよう要件に入れてください。EVP が普及したときに乗り換える費用と、その時点で作り直す費用の差は、ここで決まります。
会員登録フローの設計、認証方式の選定、既存フォームの離脱改善については、グリームハブの開発・AI・自動化のご相談で承っています。扱う情報や利用者層によって適切な設計が変わるため、個別にご相談ください。お問い合わせからどうぞ。
