Netlify Deploy Previewsから一時共有URLへ切り替えるタイミング

できること

Netlify Deploy Previewsは、GitのブランチやPRに連動してプレビュー環境が自動生成されます。コードを変更してコミットするたびに最新の状態がURLに反映されるため、頻繁に修正が入る開発初期のフィードバックサイクルでは非常に効率的です。

Netlifyのダッシュボードではデプロイ履歴が一覧表示され、任意の過去のデプロイのURLをロールバックして確認できます。「一つ前のバージョンと比べてほしい」というレビュー依頼に応じるとき、過去デプロイのURLを参照することで追加デプロイなしに対応できます。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

できないこと

Netlify Deploy Previewsには公開期限を自動設定する機能がありません。PRがマージされた後もプレビューURLは有効なため、「承認が完了したらURLを無効化したい」という要求に自動対応できません。PRのクローズ後に手動でデプロイを削除するワークフローを設けないと、旧版プレビューが長期間残ります。

個人単位のアクセス制御もできません。NetlifyのPassword Protectionはサイト単位のパスワード設定であり、特定のメールアドレスにだけアクセスを許可する、あるいは誰がいつアクセスしたかを記録するといった機能は提供されていません。

認証と期限の違い

切り替えタイミングを判断する最初の問いは「閲覧者の信頼レベル」です。同じ会社の同僚であれば情報管理のルールが共有されているためリスクは低く、社外の取引先はURLの転送先や情報の取り扱いを制御できないためリスクが高くなります。後者が関与する時点で切り替えを検討してください。

次の問いは「コンテンツの機密度」です。リリース前の製品ビジュアル・未発表の価格情報・ユーザーの個人情報を含むモックデータが含まれるなら、社内共有でも期限付き認証を設けることが理想です。「社内だから大丈夫」という判断は、メールやSlackの誤送信で情報が外部に渡るリスクを見落としています。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

差し替え・レビュー運用

切り替えの実際の手順として、「社外提出版」のブランチのビルド成果物を認証付きHTML共有サービスにアップロードします。以降の修正はVercel Previewではなく認証付きサービス上で上書きし、URLを変えずに更新します。この時点でNetlify Previewの社外転送を禁止するチームルールを設けてください。

切り替えのタイミングをプロジェクト計画に組み込んでおくと属人化を防げます。「設計レビューはNetlify Preview、クライアント提出は認証付きサービス」と明示的にフェーズで定義し、PRのチェックリストに「社外提出前に認証付きURLへ移行したか」の確認項目を追加すると、対応漏れが減ります。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける

向いているケース早見表

Netlify Deploy Previewsをそのまま使い続けてよい状況：フロントエンドエンジニアのみがレビューする社内確認フェーズ、コンテンツが公開情報のみ、Proプランでパスワード保護を設定済みかつ社外レビュアーが信頼できる範囲に限定されている。

認証付き一時共有URLへの切り替えが必要な状況：社外クライアントへの初回提出、未公開情報を含む承認者へのデモ、複数の社外関係者が関与するUXテスト、期限と同時にURLを自動無効化したい承認フロー。