2026年9月9日、Vercelは全デプロイを保護する設定と、デプロイ保護の例外に関する変更を公表しました（公式発表）。この変更があっても、保護を通過できることはメールの送信や到達を意味しません。まずPreviewへのアクセス権、リンクの宛先、実際の受信を別々に確かめてください。
この記事は、自社アプリのVercel Previewで登録・メール認証を確認する開発者とQAエンジニア向けです。
自動テストに保護されたPreviewを使う担当者や、公開前のDemo・MVPでメールの流れを確かめたい独立開発者にも役立ちます。
最終更新：2026年10月24日。Vercelの公式発表と現在のデプロイ保護ドキュメントを確認しています。保護設定や公式手順が変わった場合は、実際のPreview環境でも再確認してください。
01
Vercel Previewデプロイ保護下のメール認証リンクテストは、アクセスと到達を分けて判定
Vercel Deployment Protectionは、デプロイを開けるかどうかを制御します。メール送信処理や、受信側のメールボックスにメッセージが届いたかどうかは別の判定対象です。リンクを開いたときに保護画面が表示されるならアクセス条件を、アプリのログイン画面やエラー画面に戻るならリンク先や認証処理を先に調べます。
VercelのPreview環境の説明では、Previewは本番環境とは別のデプロイ環境として扱われています。したがって、メールのリンク先が本番ドメインになっている場合、保護を通過してもPreview上の動作確認にはなりません。
登録確認リンクが開かない場合、最初にどこを見ればよいですか？
ブラウザーに出た画面、メールに記載されたURL、アプリ側の送信記録を照合します。保護画面ならデプロイへのアクセス、URLのホスト名やパスが想定外ならアプリのリンク生成、送信記録がなければメール送信処理が主な確認対象です。
| 観測した状態 | 優先して調べる場所 | 判定の目安 |
|---|---|---|
| 保護画面が表示される | Previewの保護方式とアクセス条件 | メール到達ではなく、デプロイへのアクセスで止まっている可能性があります |
| アプリのエラーやログイン画面に戻る | URLのホスト名、パス、コールバック処理 | 保護とは別に、リンク先やアプリの検証処理を確認します |
| メールが見つからない | 送信処理、テスト用受信先、迷惑メール判定 | Previewへのアクセス可否だけでは、送信・受信を判定できません |
| 検証後もアカウント状態が変わらない | トークンの有効性、環境、アカウント状態 | ページ表示だけでなく、アプリ内の検証結果まで照合します |
02
アクセスの可否は、通常の閲覧と自動テストで分けて確認
手動で開ける担当者がいても、CIやE2Eテストの実行環境が同じ条件を満たすとは限りません。自家Previewで採用している保護方式を確認し、テスト実行がその方式に対応しているかを確かめます。Vercelは保護されたデプロイへのアクセス方法を案内しているため、許可された自動化テストでは現行の公式手順を参照してください。
自動化用の認証情報や保護回避用の値を、公開リンク、ブラウザー側のコード、リポジトリに含めるのは避けます。必要な場合はCIの機密情報として扱い、対象を自社または許可を得た環境に限定してください。手元の端末だけで動く設定をそのまま共有環境へ持ち込まず、Previewの保護状態を維持したままテストできる方法を選びます。
自家E2Eテストが保護されたPreviewへ到達できないときは、どう直せばよいですか？
まず実行環境に適用されている保護方式と公式の自動化アクセス手段を照合します。テスト用の機密情報はCI側で管理し、クライアントコードやメール本文へ埋め込まず、テスト後に設定が意図せず公開状態になっていないか確認します。
03
リンク先は、今回のPreviewと本番環境を取り違えない
アプリが生成した認証URLのホスト名、パス、コールバック用パラメーターを確認します。Preview上で登録操作をしたのに、メールが本番ドメインや別のPreviewを指すなら、デプロイ保護ではなく、アプリの環境変数やURL生成ロジックを調べる必要があります。
Vercelが提供するシステム環境変数にはデプロイ情報に関する値が含まれますが、それだけでアプリの認証リンクが必ず正しい環境を指すわけではありません。システム環境変数の資料を参照しつつ、アプリがどの値をリンク生成に使っているかを確認してください。環境ごとの変数管理については環境間で変数を管理する公式資料も確認できます。
認証リンクの宛先はPreviewと本番のどちらにすべきですか？
Preview上で行う登録の検証なら、原則として今回検証するPreviewに属する宛先を使い、リンクからの戻り先も同じ環境にそろえます。本番へ向ければ保護画面を避けられる、という理由で宛先を切り替えると、別環境のデータやアカウント状態を使うことになり、Previewの検証結果として扱えません。
| 確認項目 | Previewでの確認内容 | 本番へ切り替えてはいけない理由 |
|---|---|---|
| ホスト名 | 今回のデプロイに対応するURLか | 別環境への遷移を見逃すためです |
| パス | アプリの認証処理が受け付けるパスか | 保護画面とアプリ側のルーティング不備を混同するためです |
| コールバック | 検証後にPreviewへ戻る設計か | 本番側の画面遷移をPreviewの成功と誤認するためです |
| 環境変数 | Preview用の値が適用されているか | 本番用の値が混在すると、送信元やリンク先がずれる可能性があります |
Previewと本番で設定値を分けているかを点検する際は、テスト環境のデータと個人情報を分ける考え方も参考になります。
04
受信と検証の証拠は、アクセス成功とは別に残す
自動テストで保護を通過できれば、メールが届いた証拠にもなりますか？
なりません。保護されたPreviewへのアクセスが確認できるのは、デプロイへ到達できたことです。メールを送信した記録、受信箱での受信、リンクの検証完了、アカウント状態の変化は、それぞれ独立した証拠として記録します。
テスト結果には、送信を起こした操作、受信先で見つけたメッセージ、メール内リンクの宛先、検証後のアカウント状態を対応づけます。リンクをクリックした画面だけを成功条件にすると、別環境への遷移や画面表示だけの成功を見抜けないことがあります。受信先を本番アドレスと分ける運用を検討する場合は、登録メールを実際に受信できたか確かめる手順も確認できます。
テスト結果を残すチェックリスト
- [ ] 対象が自社または許可済みのPreviewデプロイであることを確認する
- [ ] 手動操作とCI実行のそれぞれで、Previewの保護条件を記録する
- [ ] 登録操作後にアプリ側で送信処理が実行されたことを確認する
- [ ] テスト用受信箱で該当メールを探し、リンクのホスト名とパスを記録する
- [ ] リンクを開いた後、アカウントの検証状態が変化したことを確認する
- [ ] テスト用の機密情報が公開リンクやクライアントコードへ含まれていないことを確認する
- [ ] 保護設定や例外を変更した場合、テスト終了後に公開範囲を再点検する
Vercel CLIでHTTPリクエストを扱う場合は、CLIのcurl関連ドキュメントを参照し、利用する方法が現行の保護設定に合っているか確認してください。コマンドが成功したことだけでは、受信やアカウント検証まで完了したとは判定できません。
保護を通過するテストと、実際のメール受信は別々に評価する必要があります。自家Previewの受信先を分けたい場合は、VoidAliasの日本語案内も選択肢の確認に使えます。登録の要否、受信データの扱い、転送や保持に関する条件を利用前に確かめ、長期利用や重要アカウントの復旧に使うアドレスとは分けてください。
次のサイトには新しいエイリアスを
入力欄はエイリアスのページに最初からあります。本物のメールを入れ、6桁のコードを受け取ってからアドレスを作ります。