Chromeのメールアドレス確認は、いまオリジントライアルの段階 ── 会員登録の画面で、確認メールを残したまま確かめる13項目（2026年10月時点）

目次

1. 01 何が起きたか — Chromeのメールアドレス確認は、まだオリジントライアル（試験）の段階にある
   1. Chromeの開発者向けブログが、2026年10月5日に更新を知らせた
   2. 注意の文: 検証する側にも、メール提供元にも、互換性のない変更がある
   3. ブログが挙げる更新は、5つある
   4. 仕組みの流れ。確認できないときは、いまの確認メールに戻る
2. 02 なぜ・背景 — 確認メールで利用者が離れる場面を減らす狙い
   1. 公式が挙げる、いまの確認方法の弱点
   2. 確認メールの代わりではなく、上乗せの仕組みとして作られている
   3. 提案の段階で、他のブラウザの立場はまだ分かれている
3. 03 用語 — ドキュメントに出てくる言葉を先にそろえる
   1. オリジントライアル
   2. 検証する側・メール提供元・発行元
   3. トークンとnonce
   4. ワンタイムコードと、確認リンク
   5. Sec-Fetch-Dest
4. 04 型別 — 自社がどれに当たり、誰に何を聞くか
   1. 🅰 型A — 会員登録やログインで、メールアドレスを集めて確認するサイト
   2. 🅱 型B — 外部のID連携の部品や、ログインの部品を埋め込んでいるサイト
   3. 🅲 型C — 自社でメールのアカウントを提供している会社
   4. 🅳 型D — メールアドレスを集めないサイト
   5. 開発者に聞くときの順番
5. 05 会員登録の画面で確認するチェックリスト
6. 06 代替・他の選択肢 — 確認メールを残すか、試験に参加するか
   1. 確認の方法を、並べて見る
   2. 何もしない、という選択
   3. 試験に参加する場合の条件
   4. 自社の画面を、確かめるときの道具
7. 07 当サイトで確かめたこと
   1. 公開されている3つの画面の、メールアドレスの入力欄を調べた
   2. 公式の条件とは、違っていた
   3. 言えることと、言えないこと
8. 08 このテーマの、これまで — 2026年6月の試験開始から、10月の更新まで
   1. 日付の記録
   2. 当サイトの、関連する過去の記事
   3. ブログで書いた、確かめ方の注意
9. 09 この記事のまとめ

01 何が起きたか — Chromeのメールアドレス確認は、まだオリジントライアル（試験）の段階にある

Chromeの開発者向けブログが、2026年10月5日に更新を知らせた

Chromeの開発者向けのサイト（Chrome for Developers）のブログに、「Email verification updates, October 2026」（訳: メールアドレス確認の更新、2026年10月）という記事がある。この記事を、2026年10月14日に開いて読んだ。ページには「Published: October 5, 2026」と書かれ、書き手はRowan Merewoodである。

まず、はっきりさせておく。この仕組みは、まだ試験中（オリジントライアル）であり、Chromeの標準の機能になったわけではない。ブログの冒頭は、次のように始まる。

"As the Email Verification origin trial continues, we have made further updates based on your feedback."

（訳: メールアドレス確認のオリジントライアルが続くなかで、寄せられた意見をもとに、さらに更新を加えた。）

続く文で、ブログは、出荷（一般への提供）に向けた準備にも触れている。

"We don't anticipate further breaking changes and are preparing to ship the feature."

（訳: これ以上の、互換性を壊す変更は見込んでおらず、この機能を出荷する準備を進めている。）

この文は「準備している」と書いているだけで、出荷の日付は書いていない。この記事も、日付を書かない。

注意の文: 検証する側にも、メール提供元にも、互換性のない変更がある

ブログは、すぐ後に、注意を置いている。

"Important: There are multiple backwards-incompatible changes for both verifiers and providers with the latest changes."

（訳: 重要: 最新の変更には、検証する側とメール提供元の両方にとって、以前の版と互換性のない変更が複数ある。）

「検証する側」は、メールアドレスを集めて、確認したいサイトである。会員登録の画面を持つサイトは、ここに当たる。この記事は、検証する側の目線で書く。

ブログが挙げる更新は、5つある

ブログは、Chrome 154からの更新を、Android対応、第三者のオリジントライアル、トークンの検証の中の鍵の扱い、メール提供元向けの見出しの更新に分けて書いている。ほかに、Chrome 156から始まる変更が1つ書かれている。内容を、誰に関わるかで並べ直すと、次の表になる。表の分け方は、この記事の整理である。

更新の内容	始まる版	関わる人
Chrome for Androidで、メール確認が使えるようになる	Chrome 154	利用者。ブログは、検証する側とメール提供元に変更は要らないと書いている
埋め込みのスクリプトやID連携の部品の提供元が、サイトごとのトークン登録なしで試せる（第三者のオリジントライアル）	Chrome 154	部品の提供元。部品を埋め込むサイトは、別にトークンを登録しなくてよい
トークンの検証で、鍵の識別子（kid）が付かないことがある。付かないときは、鍵を順に試す	版の指定なし	検証する側（サイトのサーバー）
トークンのメールアドレスが、フォームに入れた文字のまま返る	Chrome 156	検証する側（比較のしかた）と、メール提供元（より厳しい条件）
発行を求める要求の見出し「Sec-Fetch-Dest」の値が、email-verificationになる	Chrome 154	メール提供元

5つのうち、会員登録の画面を持つサイトの担当者が気にするのは、3つ目と4つ目の、検証する側に関わる2つである。1つ目は、利用者側の変更で、サイトの作業は発生しない。2つ目は、部品の提供元の作業である。5つ目は、メール提供元の作業である。

仕組みの流れ。確認できないときは、いまの確認メールに戻る

公式のドキュメントは、仕組みを次のように説明している。サイトのフォームに、メールアドレスの入力欄と、見えないトークンの欄を置く。利用者が入力欄にメールアドレスを入れると、ブラウザが裏で、そのメールの提供元に問い合わせる。利用者がメール提供元にログインしていれば、提供元が署名つきのトークンを出し、フォームの送信のときに、ブラウザがトークンを見えない欄に入れる。サイトのサーバーが、そのトークンを検証する。トークンが無い、または検証に失敗したときは、サイトは、いまの確認メールの手順に戻る。

02 なぜ・背景 — 確認メールで利用者が離れる場面を減らす狙い

公式が挙げる、いまの確認方法の弱点

会員登録・ログイン・購入・ニュースレターの登録・アカウントの回復で、サイトは、メールアドレスを入れた人が、そのアドレスの持ち主かを確かめたい。そのために、確認メールのリンクや、ワンタイムコードを使うサイトが多い。公式のドキュメントは、この方法の弱点を、次のように書いている。

"Existing verification methods require users to leave your site, switch apps to check their inbox, copy an OTP, or click a verification link. This disruption increases drop-off and session abandonment for both human users and automated agents."

（訳: 既存の確認方法は、利用者にサイトを離れさせ、アプリを切り替えて受信箱を確かめさせ、ワンタイムコードをコピーさせ、確認用のリンクを押させる。この中断は、人間の利用者にも自動化されたエージェントにも、離脱とセッションの放棄を増やす。）

「OTP」は、一度だけ使えるコードのことである。この引用の「離脱を増やす」は、ドキュメントの主張であり、この記事では、離脱の数字を確かめていない。自社の離脱がどれだけ起きているかは、自社の記録で数える必要がある。

確認メールの代わりではなく、上乗せの仕組みとして作られている

ドキュメントは、この仕組みを、いまの手順への上乗せと説明している。ブラウザやメール提供元が対応していない場合や、確認に失敗した場合は、サイトは、いまの確認メールの手順に戻る。機能を使えるかを、サイト側で先に調べる必要もない。トークンが届いていれば処理し、届いていなければ従来どおり進める、という作りである。

確認できるのは、何かも限られている。

"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."

（訳: メール確認が確かめるのは、利用者が、自分のメールアドレスの提供元との間で、有効なセッションを持っていることである。こちらのメールが利用者に届いたことは、確かめない。）

つまり、確認できたことと、メールが届くことは、別の話である。ドキュメントは、この点を受けて、従来の歓迎メールなどを送り続けたほうがよい場合もあると書いている。

提案の段階で、他のブラウザの立場はまだ分かれている

ドキュメントは、冒頭で、この仕組みを次のように位置づけている。

"The Email Verification API is a proposal that enables the browser to communicate directly with the email provider to verify that the user owns the email address."

（訳: Email Verification APIは、利用者がそのメールアドレスを持っていることを確かめるために、ブラウザがメール提供元と直接やり取りできるようにする、提案である。）

Chrome Platform Status（Chromeの機能の記録ページ）には、「Email Verification Protocol」の項目がある。2026年10月14日に取得すると、項目の状態は「Proposed」（訳: 提案）で、更新日は2026年10月9日だった。他のブラウザの立場として、Firefoxが「Neutral」（訳: 中立）、Safariが「No signal」（訳: 表明なし）と記録されていた。Chromeの外では、この仕組みが使えるとは言えない。サイトは、どのブラウザでも確認メールが動くことを、前提にしておく必要がある。

03 用語 — ドキュメントに出てくる言葉を先にそろえる

オリジントライアル

検証する側・メール提供元・発行元

トークンとnonce

ワンタイムコードと、確認リンク

Sec-Fetch-Dest

04 型別 — 自社がどれに当たり、誰に何を聞くか

🅰 型A — 会員登録やログインで、メールアドレスを集めて確認するサイト

ドキュメントは、対象の場面として、登録（sign-up）、ログイン（sign-in）、購入（checkout）、ニュースレターの登録、アカウントの回復を挙げている。この記事が主に扱うのは、これらの画面を持つサイトである。ディレクターの仕事は、自社がどの画面でメールアドレスを集め、どの方法で確認しているかを、開発者に聞いて書き出すことである。

🅱 型B — 外部のID連携の部品や、ログインの部品を埋め込んでいるサイト

認証の部品を、外部のサービスから埋め込んでいるサイトは、部品の提供元が、第三者のオリジントライアルに登録できる。ブログは、埋め込みのスクリプトやID連携のSDKを提供している場合、第三者のトライアルのトークンに登録し、部品を置くページに入れられる、と書いている。部品を埋め込むサイトが、別にトークンを登録する必要はない。ただし、登録した元のドメインと、発行元のドメインが、同じサイトでなければならないという条件が付いている。サイトの担当者が聞くのは、「部品の提供元は、このトライアルに登録するのか」である。

🅲 型C — 自社でメールのアカウントを提供している会社

ブログは、メール提供元向けの条件を、より厳しいものとして書いている。

"From the provider side, this requirement is more strict: if the provider does not return the email exactly as provided, Chrome will reject the token."

（訳: 提供元の側からは、この条件はより厳しい。提供元が、メールアドレスを渡されたとおりに返さなければ、Chromeはトークンを拒否する。）

理由として、ブログは、「確認メールを送れば明らかになる以上のデータを、さらすことを避ける」と書いている。自社のドメインでメールのアカウントを提供している会社は、実装を担当する人に、この条件を渡す。多くの読者の会社は、これに当たらない。

🅳 型D — メールアドレスを集めないサイト

メールアドレスを集める画面が1つもないサイトは、この記事の対象外である。ただし、お問い合わせフォームに、返信用のメールアドレスの欄があるサイトは多い。そのフォームでメールアドレスの確認をしていなければ、確認する対象ではない。まず、画面の一覧を作ってから、対象かを決める。

開発者に聞くときの順番

聞く順番は、3つで足りる。1つ目は、メールアドレスを集める画面の一覧。2つ目は、各画面での確認の方法（確認メール、ワンタイムコード、外部のID連携のどれか）。3つ目は、この試験に参加する予定があるかである。参加の判断は、サイトを変えるかどうかの判断になるので、ディレクターが答えを出せる問いではない。開発者と、サイトの責任者の間で決めてもらう。

05 会員登録の画面で確認するチェックリスト

下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• 公式ブログ「Email verification updates, October 2026」を開き、公開日の表記と、「Important」で始まる注意の文を、そのまま書き写す
• 自社のサイトで、メールアドレスを集める画面を、会員登録・ログイン・購入・ニュースレター・パスワード再設定の順に、1画面1行で書き出す
• 項目2の各画面で、メールアドレスの入力欄を右クリックして「検証」を開き、typeとautocompleteの値を、画面ごとに書き写す
• 項目3の結果から、typeが「email」でない欄の数と、autocompleteが「email」でない欄の数を、別々に数えて書く
• 各画面のページのソースを開き、「email-verification-token」を検索して、見つかった件数を、画面ごとに書く
• 会員登録を実際に1回行い、確認メールのリンクを押すまでに、画面とメールの間を行き来した回数を、数えて書く
• 会員登録を、パソコンとスマホで1回ずつ行い、確認メールが届くまでの時間を、秒で書く
• 開発者に、メールアドレスの確認に使っている仕組みが、自前の確認メール・外部のID連携・その他のどれかを聞いて、名前を書く
• 外部のID連携の部品を使っているなら、提供元に、Email Verificationのオリジントライアルに登録するかを問い合わせる1通を送り、送った日を書く
• この試験に参加するかを、開発者とサイトの責任者に聞いて、「する」「しない」「決めていない」のどれかで書く
• 参加する場合に備え、トークンが届かないときに、いまの確認メールへ戻る手順が仕様書に書かれているかを確かめ、「ある」か「ない」で書く
• 開発者に、メールアドレスの比較で、大文字と小文字を区別しているかを聞いて、「区別する」「しない」「分からない」のどれかで書く
• 30日後の日付に、公式ブログと公式ドキュメントの「Last updated」の日付を見直す予定を、カレンダーに入れる

時間が限られているときは、項目2・3・4・8の4つだけでも、概要は分かる。メールアドレスを集める画面がなければ、項目2で、そのことを書いて終わりである。

06 代替・他の選択肢 — 確認メールを残すか、試験に参加するか

確認の方法を、並べて見る

メールアドレスの確認の方法は、1つではない。ドキュメントが挙げる情報だけで、並べると、次のとおりである。表は、この記事の整理である。

方法	利用者の手間	サイトの作業	状態
確認メール（リンク・コード）	サイトを離れて受信箱を開く（ドキュメントの説明）	いまのまま	すでに使われている方法
Chromeのメール確認	裏で確認される。初回は許可の画面が出る	入力欄の属性の変更と、サーバーでのトークンの検証	オリジントライアル（試験中）
Androidアプリ向けの確認	下から出る画面で同意する	アプリの開発（別の仕組み）	Android 9以上などの条件がある

3つ目は、アプリ向けの、別の仕組みである。Chromeのドキュメントは、これがChromeのメール確認とは別のものだと注記している。Android Developersのドキュメントは、対象を「Android 9（API level 28）以上」と書いている。会員登録の画面がウェブのサイトの場合は、この記事の対象は、2行目までである。

何もしない、という選択

公式の手順は、サイトが入力欄を足すことから始まる。足さないサイトで、何が起きるかは、開いたドキュメントには書かれていない。この記事の読みでは、試験中の機能なので、今は何もしないという選択は、ふつうにありえる。その場合も、項目2・3・4で、自社の画面の現状を書き出しておくと、出荷の知らせが出たときに、すぐ判断できる。

試験に参加する場合の条件

参加する場合は、オリジントライアルへの登録と、フォームの入力欄の変更、サーバーでのトークンの検証が要る。ドキュメントは、試験について、次の点も書いている。

• 互換性のない変更が、急に入ることがある。
• 試験には、利用量の上限がある。上限の理由は、出荷の前に、サイトがこの機能に頼りすぎないようにするためだと、書かれている。
• 試験の機能は、レスポンスごとにトークンを付けることで、一部の利用者にだけ有効にできる。

実装の手順は、Chromeの検証する側向けのガイドにある。参加を決める場合の相手は、開発者である。

自社の画面を、確かめるときの道具

入力欄の属性は、ブラウザの開発者ツールで見られる。画面そのものを、パソコンとスマホで並べて見たいときは、当サイトの無料ツール🔧 WEBページのスクリーンショット、表示デバイスの比較ツールが使える。ページの基本情報を、一覧で見たいときは、🔧 WEBサイト総合分析・レポートツールが手がかりになる。どちらも、入力欄のtypeやautocompleteを判定するツールではない。

07 当サイトで確かめたこと

公開されている3つの画面の、メールアドレスの入力欄を調べた

2026年10月14日の14時台に、当サイトの会員登録・サインイン・パスワード再設定の3つの画面を取得し、HTMLに書かれたメールアドレスの入力欄を調べた。コメントの中は除いた。取得できたのは、画面を開く前の、ブラウザに渡されるHTMLまでである。ページを開いたあとにJavaScriptが組み立てる欄は、見ていない。

• 会員登録: メールの入力欄は2つ（メールアドレスと、確認用メールアドレス）。typeはtext、autocompleteはoff。
• サインイン: メールの入力欄は1つ。typeはtext、autocompleteはoff。
• パスワード再設定: メールの入力欄は2つ（メールアドレスと、確認用メールアドレス）。typeはtext、autocompleteは書かれていない。

公式の条件とは、違っていた

Chromeのドキュメントは、検証する側のフォームに、次の2つを求めている。メールの入力欄はtype="email"とautocomplete="email"にする。見えないトークンの欄は、autocomplete="email-verification-token"とnonceを付ける。当サイトの3つの画面の入力欄は、どれもtypeがtextで、autocompleteは、offか、書かれていなかった。「email-verification-token」は、3つの画面とも、0件だった。オリジントライアルの印（HTTPの応答の見出しと、ページの中の指定）も、3つの画面とも、見つからなかった。

つまり、当サイトの3つの画面は、公式が書く条件に、いまのところ当たらない。当サイトが、この試験に参加するかは、この記事の時点では決めていない。画面に確認用のメールアドレス欄があるのは、入力の間違いを防ぐ作りだと読めるが、これは画面の文言から読んだ推測である。確認メールの送信の流れは、この記事では確かめていない。

言えることと、言えないこと

言えるのは、取得したHTMLの範囲で、当サイトの3つの画面の入力欄が、公式の条件と違う、ということである。言えないことは、3つある。実際のChromeで開いて、この仕組みが働くかを、確かめていない。確認メールの送信の流れは、確かめていない。ほかの画面（お問い合わせなど）の入力欄は、調べていない。「0件」は、調べた3画面のHTMLで見つからなかった、という意味である。

08 このテーマの、これまで — 2026年6月の試験開始から、10月の更新まで

日付の記録

日付は、Chromium Dashboardの予定表（2026年10月14日に取得）、ブログ、Chrome Platform Statusの項目から集めた。Chrome 156の安定版の日は、予定である。

日付	出来事
2025年9月5日	Chrome Platform Statusに、「Email Verification Protocol」の項目が作られた（項目の作成日・協定世界時の表示）
2026年6月30日	Chrome 150の安定版の日（予定表）。オリジントライアルは、このChrome 150から、デスクトップで始まったとブログが書いている
2026年9月22日	Chrome 154の安定版の日（予定表）。Android対応、第三者のオリジントライアル、Sec-Fetch-Destの値の変更が、154からと、ブログが書いている
2026年10月5日	ブログ「Email verification updates, October 2026」の公開日。公式ドキュメントも、同じ日に更新された
2026年10月20日	Chrome 156の安定版の日（予定表の予定）。トークンのメールアドレスが、渡された文字のまま返るのは、156からと、ブログが書いている

ブログの更新と、公式ドキュメントの更新が、同じ日（2026年10月5日）であることは、ドキュメントの「Last updated 2026-10-05 UTC」の表記で確かめた。

当サイトの、関連する過去の記事

Chromeの新しい動きを、サイトの確認に結びつけた記事は、これまでにもある。Chromeの安定版が2週間ごとに出る話は「Chromeは153から、安定版が2週間ごとに出る。年末年始だけ間隔がのびる予定 ── 表示確認・計測・納品後の確認の予定を組み直して確認する13項目（2026年10月時点）」に、HTTPのページを開く前の確認の話は「Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）」に、広告やクッキーに関わるAPIの廃止予定は「Chrome 153のリリースノートで、広告とクッキーに関わるAPI 5つが「廃止予定」になった ── 自社のタグと埋め込みの提供元に確認する14項目（2026年10月時点）」に、埋め込みの提供元に頼むものの切り分けは「Chrome 154で、iframeの高さを中身に合わせる指定が入った。ただし親のCSSと子のmetaの2か所が要る ── 自社の埋め込みを「両側を持つもの」と「提供元に頼むもの」に分ける13項目（2026年10月時点）」にある。

ブログで書いた、確かめ方の注意

自社の画面を数えるときの注意は、ブログにも書いた。調べた範囲を書かないと「0件」の意味が決まらない話は「「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直した」に、外から取った画面が目当ての画面とは限らない話は「外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた」にある。自分のサイトに、記事のチェック項目を当てた記録は、「記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.69を、記事を公開したその日に上げるまで」と「記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった」にある。自動の画面の写しが、読者の画面と違うことは「「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数）」にまとめた。