メール確認コードやマジックリンクは、受信箱への移動や遅延によって登録を中断させます。Email Verification Protocol（EVP）は、確認メールを送信せず、同じブラウザプロファイル上の発行者セッションを使ってメール所有を暗号的に証明する手法です。inbox 到達は証明しません。
📑目次
いま公式に使える範囲は、desktop Chrome のオリジントライアル（マイルストーン 150〜156）です。公式デモで verifier と issuer を1本通し、既存 OTP / マジックリンクを残したまま対象フォーム1つだけに origin trial を足すのが次の一手です。inbox 到達や同意証明が主目的なら OT は見送り、DOI / OTP を維持してください。
EVPが証明することと、証明しないこと
採用判断の前に、EVP が返すトークンが具体的に何を証明するのかを明確に固定しておく必要があります。ここで証明範囲を曖昧にすると、確認メールの廃止や到達確認の省略を誤って判断してしまいます。
証明する範囲
EVP が返すのは、「同じブラウザプロファイルで発行者にログインした利用者が、autofill で選んだアドレスを所有している」という暗号証明です。確認メールは送信しません。サイト側が送った案内が受信トレイに届いたことや、存在確認（bounce）の成功、ダブルオプトイン（DOI）の同意クリックは証明しません。
この明確な切り分けが、実装条件を決める出発点となります。所有証明だけを目的とするなら確認メールを省略できますが、到達確認や同意は別のチェックとして残しておく必要があります。次に、なぜ到達が証明対象から外れるのかを三者モデルで説明します。
三者モデルと前提
理由は三者モデルにあります。
- ブラウザが発行者（メールプロバイダ）とやりとりし、発行者には依拠当事者（RP）のオリジンを見せません。
- 発行者は「そのメールアドレスで検証要求があった」こと自体は知り得ますが、どのサイト向けかは知りません。
- 利用者は初回だけ、アドレス単位の許可プロンプトを見ます。
- 手入力したアドレスは現行フローの対象外です。
- トークンは任意入力として扱い、未対応ブラウザは従来フローへ戻します。
公式ソースが揃える限界
- Chrome for Developers（Rowan Merewood、2026-07-08）は、利用者が autofill アドレスを選び、ページを離れずに所有を検証する origin trial を説明しています。
- MediaPost（2026-07-29）も、確認対象は発行者のアクティブセッションであり、サイト送信メールの到達ではない、と公式の限界を再掲しています。
- Validity（2026-07-29）は、EVP を bounce 検証とも DOI の同意証跡とも別物だと整理しています。
到達確認そのものは、メール未達を「仕方ない」にしない｜Gmail・Yahoo・Outlook送信者要件の診断チェック 側の問題です。
運用上の含意は単純です。登録完了率を上げたい場合は、所有証明をブラウザ内に寄せることができます。一方、ウェルカムメールや法的同意が主目的の場合は、EVP の成功だけで省略してはいけません。
verifierサイトが足すフォームと検証5手順
フォームに足す最小セット
verifier（依拠サイト）が足す最小セットは、表示用の autocomplete="email"、隠しフィールドの autocomplete="email-verification-token"、ページ描画ごとに一意の nonce です。同じページに origin trial トークンを置きます。トークンはレスポンス単位で出せるので、A/B やベータ集団だけに限定できます。
ブラウザ側の流れ
WICG Email Verification API（2026-06-26 の CG Draft）では、autofill 選択後の流れは次のとおりです。
- UA が DNS で発行者を探す。
- 許可プロンプトのあと EVT を取得する。
- 文書オリジンと nonce に束縛した KB-JWT を隠しフィールドへ注入する。
- nonce が空なら中断する。
- 提出時にメール欄が選択アドレスと一致しなければ注入しない。
- トークンが無い提出はそのまま通り、従来フローへ戻せる。
フィーチャー検出 API はありません。
サーバ側の検証5手順
サーバ側の検証は、公式解説に沿うと次の5点です。
- EVT と KB-JWT を
~で分割する（SD-JWT+KB）。 emailの一致、email_verified=true、nonceの一致、audが自オリジン、新しいiatを確認する。cnfの鍵で KB-JWT とsd_hash（evtJwt + "~"）を検証する。- DNS TXT
_email-verification.<domain>で発行者を確認する。Gmail の例はiss=accounts.google.comです。 /.well-known/email-verificationの JWKS で署名を検証する。
公式例の EVT は exp と iat の差が 300 秒です。いずれかが欠ける、署名が合わない、トークンが来ない、のいずれでも既存 OTP / マジックリンクへ戻してください。
デモは verifier が rowan.fyi/made/email-verification、issuer が rowan.fyi/made/email-provider です。
OT 登録は Chrome Origin Trials です。
発行者・DNS・Gmail参加のテクノロジー条件
発行者が満たす条件
発行者は OT 登録が不要です。必要なのは次の項目です。
- DNS TXT
- well-known メタデータ
- Login Status（
Set-Loginまたはnavigator.login.setStatus）
Gmail の well-known は https://accounts.google.com/.well-known/email-verification、issuance 例は https://accounts.google.com/gsi/email-verification/issue です。OT 中の @gmail.com は追加セットアップなしで試せます。
ブラウザ範囲と仕様の位置づけ
- ブラウザ範囲は desktop Chrome OT 150〜156 です。Chrome Status（feature 5205725253074944）に Android / iOS / WebView の OT 開始・終了は載っていません。
- IETF draft-hardt-email-verification-01（2026-07-04、更新 2026-07-07）は Gmail 発行者を記録しています。
- 同じ I-D に Edge の origin trial も載っています。
- この I-D は個人提出で、IETF 合意の標準ではありません。有効期限は 2027-01-05 です。
相互運用と運用制約
相互運用は未決着です。Mozilla は Defer（standards-positions#1316）、WebKit は No signal（#578）です。非公式コメントでは WebOTP / one-time-code の拡張が好まれています。
issuer API と Chrome UX は後方互換なしの変更があり得ます。OT トラフィックには上限があります。出荷日としては扱わないでください。
GIGAZINE（2026-07-10）は、手入力非対応、許可はアドレス単位、到達は保証しない、Gmail は OT 参加済み、という運用制約を独立報道しています。@gmail.com 以外は、そのドメインの発行者が DNS / well-known / Login Status を実装した場合だけ使えます。
OTP・WebOTP・DOIとの比較で採用を決める
採用判断は「離脱を減らすか」「届いたことを残すか」「同意の記録が必要か」で分かれます。EVP と WebOTP は排他的ではありません。Chrome Status も両者が共存し得ると記載しています。
比較表
| 方式 | ユーザーがサイトを離れるか | 証明するもの | いまの実装前提 |
|---|---|---|---|
| EVP | 原則不要（autofill 選択 + 許可） | 発行者セッション上の所有 | Chrome desktop OT 150–156、発行者参加 |
| OTP / マジックリンク | 必要 | その時点で受信箱を読めたこと | 既存。遅延・迷惑メールのリスク |
| WebOTP / one-time-code | 受信は必要、入力は補助 | 届いたコード | WebKit 側が選好する既存線 |
| DOI クリック | 必要 | 所有 + しばしば同意の記録 | EU 等で同意証跡として使われる |
出典:
離脱試算と採用判断
Validity は DOI 確認ステップの離脱を平均 20〜35%（中点 27.5%、購読者 LTV 約 53 ドル）と試算しています。これは Validity / DMA のモデルであり、Chrome の実測ではありません。
登録完了率を上げたいサイトは、既存フローに OT を追加する価値があります。到達確認や法的同意が主目的の場合は、DOI / OTP を外さずに維持してください。
確認メールを装う攻撃面は、二段階式フィッシングメールの手口と見抜き方【2026年最新】 の前提とも重なります。EVP は確認メールを減らす一方で、許可プロンプトと発行者セッションという別の信頼境界を導入します。
採用前チェックリスト
本番の全ユーザーに対して展開する前に、次の項目をすべて満たしているか確認してください。満たせない項目がある場合は、見送るかコホート限定に留めてください。
- 既存 OTP / マジックリンクを残し、EVT を任意入力として扱う設計か
- OT トークンを対象ページだけに出し、失敗時のフォールバックをログできるか
- nonce を描画ごとに更新し、email / aud / iat / DNS / JWKS の5点をサーバで検証するか
- 対象アドレスの発行者（まず Gmail）が Login Status と DNS を満たすか。手入力ユーザーを除外してよいか
- ウェルカムメールや同意取得を EVP 成功で省略しないか。inbox 到達と同意は別チェックか
- OT 終了（desktop 156）と API 破壊的変更を前提に、本番依存を避けているか
次の一手は、公式デモで verifier と issuer を1本通し、既存の OTP / マジックリンクを残したまま、対象フォーム1つだけに origin trial を追加することです。inbox 到達や同意証明が主目的の場合は OT を見送り、DOI / OTP を維持してください。このテクノロジーはまだ実験段階です。
よくある質問
確認メールと本番公開
ブラウザと対象アドレス
関連記事:
- JA: GPT-Transcribeの使い分け｜テクノロジー現場のコンテキスト指定
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
まとめ
EVP は「所有のブラウザ内証明」であり、「届いた証明」ではありません。
verifier の最小セットとボトルネックは次のとおりです。
- hidden token と nonce
- サーバ側の5段階検証
- 失敗時の OTP 復帰
- 発行者参加と Chrome / Edge の OT 範囲がボトルネック
- 相互運用は未決着
公式デモで verifier と issuer を1本通し、既存 OTP / マジックリンクを残したまま対象フォーム1つだけに origin trial を足してください。
inbox 到達や同意証明が主目的なら OT は見送り、DOI / OTP を維持してください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す