2026年、Chrome Email Verification APIの試用トークンは11月17日失効、メールへのフォールバックはどうテストする？

2026年10月27日時点で、Chromeの公式案内は、試用期間の延長前に登録された既存トークンが2026年11月17日に失効するとしています。Email Verificationの公式案内を確認し、自サイトのトークンが対象なら更新して再デプロイしてください。

適している場合： 自サイトの試用トークンとメール回帰経路を管理する開発者・QA向けです。
適していない場合： 他者のサイトでトークンを試したり、許可されていない環境で検証したりする用途には使えません。

自サイトでOrigin Trialに参加している開発者は、トークンの状態と配信環境を確認してください。
登録やアカウント復旧を担当するQAは、API経由と確認メール経由の両方を検証します。
プレビュー環境を保守する独立開発者は、メールの実受信とアカウントの完了状態を別々に記録してください。

最終更新：2026年10月27日。Chrome for DevelopersのEmail Verification、Origin Trials、Origin Trialのトラブルシューティングに基づいて確認しています。試用状況や公式手順が変わった場合は、実行前に公式ページを再確認してください。

まず対象のトークンと環境を照合する

失効日の対象は、試用期間が延長される前に登録された既存トークンです。公式案内はEmail Verificationが引き続きOrigin Trialであることも示していますが、すべての参加サイトのトークンが同じ日に失効するとは述べていません。試用の状態と対象トークンに関する公式情報を根拠に、登録記録と現在の配信内容を突き合わせます。

次の情報を、環境ごとに確認してください。

[ ] Origin Trialの登録時期と、登録対象のオリジンを記録する
[ ] 本番、ステージング、開発環境のどこでトークンを配信しているか確認する
[ ] ページのレスポンスに含まれるトークンを、登録情報と照合する
[ ] どのページやユーザーで試用機能が有効になるか記録する
[ ] 従来のメール確認が起動する条件と、成功時のアカウント状態を記録する

環境間で設定を使い回すと、更新したつもりのトークンが実際には対象ページへ配信されていないことがあります。トークンの登録状態とメール送信設定は別の管理項目です。片方の更新を、もう片方の修正や検証の代わりにしないでください。

更新を決める前にメール経路の基準を残す

更新に着手する前に、従来の確認メールがどの条件で送られるかを整理します。たとえば、APIが使えない場合、検証が失敗した場合、対象外のブラウザーやメール提供元だった場合に、メール経路へ移る設計かをコードと設定で確かめます。

次に、通常経路での基準結果を残します。確認メールを要求した時点、受信先、メール内リンクの接続先、操作後のアカウント状態を記録してください。テストデータに実在する個人情報を使う必要はありません。自分が管理するテストアカウントと受信先を利用し、ログや画面キャプチャに不要な個人情報を残さないようにします。

更新後は新しい値が配信されるところまで確認する

対象トークンの更新手順は、Chromeの公式案内に従ってください。試用資格や有効期間を独自に推定せず、登録ページに表示される条件を確認します。ChromeのOrigin Trialsに関する公式ガイドも、登録と利用条件の確認に使えます。

更新したら、対象環境を再デプロイします。管理画面上の値だけで完了とせず、実際に対象ページが返すレスポンスを確認してください。トークンが意図したオリジンとページに含まれていること、古い値が残っていないことを確認し、実利用者と同じ環境条件で再試験します。

配信されない、検証エラーになるなどの問題があれば、設定値だけを何度も差し替える前に原因を切り分けます。Origin Trialの公式トラブルシューティングを参照し、登録対象のオリジン、配信先、レスポンスの状態を順に調べてください。

API経由とメール経由を別々に回帰テストする

Chrome Email Verification APIのテストでは、APIによる検証と、既存の確認メールのテストを混同しないことが重要です。前者はメールアドレスの確認に関する結果であり、メールがアプリから送信され、受信箱に届いたことの証明ではありません。検証側の実装は公式のVerifier向けドキュメントを参照してください。

自サイトの許可された環境で、次の順に確認します。

トークンが利用できる条件で検証を実行し、アプリが最終的に設定するアカウント状態を記録する
トークンがない条件を作り、従来の確認メール処理へ移ることを確認する
ブラウザーやメール提供元が対応しない場合の処理を確かめる
APIでの検証が失敗した場合にも、設計どおりメール経路が起動するか試す
メール内リンクが意図した環境を指し、操作後にアカウント状態が変化するか確認する

メール回退テストでは証拠を分ける

受信先には、管理下にあるテスト用メールアドレスを使います。メールが実際に受信箱へ届いたか、リンクがステージングなど想定した環境を指しているか、操作後のアカウントが確認済み状態になったかをそれぞれ記録してください。画面に「確認メールを送信しました」と表示されたことだけでは、受信の確認にはなりません。

経路	実行条件	残す証拠	合格とする判断
API検証	有効なトークンを配信する	トークンの配信状態とアプリの最終状態	アプリが意図した状態を設定する
メールへのフォールバック	トークンなし、非対応、または検証失敗	メールの実受信、リンク先、操作後の状態	受信とアカウントの完了が両方確認できる
受信後の操作	テスト用受信先でリンクを開く	リンク先の環境と状態変更	意図した環境でアカウントが更新される

テスト用受信先を準備する際は、利用サービスのアドレス仕様やメールの保管条件を事前に確認してください。EmailSawを使う場合も、自サイトの管理下にある検証で利用できるか、必要な受信条件を確認してから選択してください。受信先を用意することは、APIの検証を置き換えるものでも、メール到達を保証するものでもありません。

公開前に経路ごとの証拠をそろえる

最後に、更新後のトークン、対象環境、フォールバックの起動条件、テストメールの実受信、リンク操作後のアカウント状態を別々に記録します。API経由のテストが通っても、確認メールが届いたことにはなりません。逆にメールが届いても、API用トークンの状態が正しい証拠にはなりません。

公開直前には公式ページの試用状況と自サイトのデプロイ設定を再確認してください。トークンや試用方針が変わった場合は、該当する経路を再テストします。単に成功・失敗だけを残すのではなく、実行環境と成立した証拠を結び付ければ、次の障害調査でも経路を取り違えずに済みます。

よくある質問

今回の失効日が適用される試用トークンはどれですか？

Chromeの公式案内では、試用期間の延長前に登録された既存トークンが対象とされています。参加サイトのトークンがすべて同日に失効するとは限りません。Origin Trialの登録時期と、現在の環境に配信しているトークンを照合してから対応を決めてください。

トークンを更新した後もデプロイ作業が必要ですか？

公式案内は、対象トークンの更新後に再デプロイするよう求めています。更新画面で手続きを終えただけでは、サイトが新しい値を配信している証拠になりません。デプロイ後、対象ユーザーと同じ環境のレスポンスに更新後のトークンが含まれるか確認してください。

トークンがない場合のメールフォールバックはどう確かめますか？

自サイトの許可されたテスト環境で、トークンがない状態や検証が失敗する状態を作り、従来の確認メール処理が実行されるか確認します。画面の案内だけで判定せず、テスト用受信先にメールが届いたことと、リンク操作後にアカウント状態が変化したことを別々に記録してください。

APIでメールアドレスの検証に成功しても、確認メールを試す必要はありますか？

必要です。APIによる検証結果は、従来の確認メールが実際に送信され、受信されたことを示すものではありません。メール送信の処理、リンクの接続先、操作後のアカウント状態は、別の経路としてテストし、証拠も分けて残してください。