Vercel Preview Deploymentsでは足りない認証・期限管理をどう補うか

できること

Vercel Preview DeploymentsはGitプッシュごとに自動でプレビューをビルド・デプロイします。エンジニアが手動でファイルをアップロードする手間なく、常に最新コードのプレビューが用意されます。CI/CDと組み合わせてテスト通過後のビルドだけをプレビューに出す設定も可能です。

TeamプランではDeployment Protectionが使えます。パスワード方式を選ぶと、共有パスワードを入力しないとプレビューが開けなくなります。Vercelアカウントへのログインを必要とする方式に比べ、社外レビュアーにとってハードルが低く実用的です。

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

できないこと

無料・Proプランではプレビューに対して認証を設定できません。URLが知られた時点で誰でもアクセスできる状態です。GitHubのPRコメントにプレビューURLが自動投稿される設定にしている場合、リポジトリをパブリックにしていると第三者が直接アクセスできます。

期限付きアクセスはVercelの機能としてどのプランにも存在しません。Teamプランのパスワード保護を使っていても、パスワードを削除するか手動でプレビューを削除しない限り、URLは有効なままです。レビュー完了後の確実な無効化には、Slackリマインダーや担当者への作業依頼が必要です。

認証と期限の違い

認証機能を補うには、プレビューデプロイとは別にビルド成果物を認証付きサービスにアップロードする方法が有効です。CI/CDのデプロイステップに「静的ファイルを認証付きサービスのAPIに送信する」ジョブを追加すれば、Gitプッシュと同時に認証付きプレビューが更新される運用を構築できます。APIが公開されているサービスを選ぶことが前提です。

期限管理を補う最も確実な方法は、認証付きHTML共有サービスで設定する公開終了日時機能です。CIのデプロイ時に終了日時を動的に設定するスクリプトを組めば、PRクローズの日時に合わせて自動停止させることも実現できます。手動管理に比べてヒューマンエラーを大幅に減らせます。

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

差し替え・レビュー運用

補完策として認証付きサービスを並走させる場合、Vercel Preview（開発・社内確認用）と認証付きサービスのURL（社外提出用）の二本立てで運用します。エンジニアはVercel Previewで開発確認し、クライアントへの提出バージョンが確定したら認証付きサービスを更新するという役割分担です。

二本立て運用の最大の落とし穴は「どちらが最新版か」の混乱です。認証付きサービスへの更新をエンジニアが忘れると、クライアントが古いバージョンを確認し続けます。更新のトリガーを「PRのレビュー承認後」や「特定のブランチへのマージ後」にワークフローで自動化することで、更新漏れを防げます。

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

向いているケース早見表

Vercel Preview単独で完結するケース：社内エンジニアチーム内の開発レビュー、Teamプランのパスワード保護で十分なアクセス制限が実現できている、コンテンツが公開情報のみ。この場合は追加サービスを導入するコストが不要です。

認証付きサービスで補完が必要なケース：社外クライアントへの正式提出、個人単位のアクセスログが必要、期限が来たら自動停止が必要、Gitを持たないデザイナーが差し替えを担当する場合。ツールの組み合わせ方をチームで合意しておけば、どちらの利便性も活かせます。