できること
Vercel Preview Deploymentsは、コードをプッシュするたびに自動でプレビュー環境が更新される仕組みを持ちます。開発初期のフィードバックサイクルが速い段階では、エンジニアが修正してプッシュするたびにチームが同じURLで最新状態を確認できるため、非常に効率的です。
VercelのSlackインテグレーションを使えば、プレビューURLがSlackに自動投稿されます。エンジニアが手動でURLを共有する手間なく、チームメンバーが即座に確認を開始できます。この自動化はチーム内の開発レビューにおける摩擦をゼロに近づけます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
できないこと
Vercel Preview Deploymentsでは、個々のレビュアーにアクセス期限を設定する機能がありません。「この案件のレビューは今週金曜まで」という期限を公開URLに紐づけて自動停止する方法が存在せず、期限管理はレビュアーへのリマインド連絡と手動削除に依存します。
Gitのコードと切り離したファイル差し替えもできません。「デザインだけ変えた最新版を確認してほしい」という場面で、コードベースに変更を加えずにビジュアルだけ更新したプレビューを出すことができず、デザイナーと開発者の間の分業に摩擦が生じることがあります。
認証と期限の違い
切り替えタイミングの第一の判断基準は「閲覧者がGit連携プロジェクトの外にいるかどうか」です。社内エンジニア・デザイナー間はVercel Previewで十分ですが、社外の意思決定者・クライアント担当者・外部UXテスター向けには認証と期限設定が必要になります。Teamプランのパスワード保護は最低限の対策ですが、個人単位のアクセスログがない点で限界があります。
「期限が必要か」という観点では、承認フローが明確に定義されたプロジェクトほど期限設定の価値が高まります。「◯月◯日までに承認いただけない場合はスケジュールが遅延します」という合意がある場合、URLが同じ日時に自動停止される設定を持つサービスを使うと、期限管理の証跡にもなります。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
差し替え・レビュー運用
切り替えの具体的なタイミングは「初回クライアント提出の前」が最も合理的です。それまではVercel Previewで内部イテレーションを重ね、提出版のビルド成果物(distフォルダまたはZIP)を認証付きHTML共有サービスにアップロードします。以降の修正は同サービスに上書き更新し、URLを変えずに最新版を届けます。
切り替え後にVercel PreviewのURLを社内Slackに貼り続けている場合、誰かが誤って社外に転送するリスクが残ります。切り替えを決めたら「社外向けURLはギガサイト便の〇〇」と明示的にドキュメントに記録し、古いVercel PreviewのURLを無効化または削除してください。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
向いているケース早見表
Vercel Preview Deploymentsをそのまま使い続けてよいケース:社内のエンジニア・デザイナーだけがレビューする段階、Teamプランでパスワード保護を設定済みで社外レビュアーが限定的、コンテンツが公開情報のみで情報漏洩リスクが低い。
認証付き一時共有URLへ切り替えるべきケース:初回クライアント提出・経営層承認・外部ユーザーテストなど社外が関わるフェーズに入った、未公開情報を含む、誰がいつアクセスしたかを追跡したい、期限を過ぎたら自動でURLを無効化したい。
よくある質問
Vercel Previewのビルド成果物をそのままHTMLファイル共有サービスにアップロードできますか?
Next.jsなどのフレームワークで静的エクスポート(next export)が可能なプロジェクトなら、distフォルダの内容をZIPにまとめてアップロードできます。サーバーサイドレンダリングを含むプロジェクトはサーバーが必要なため、静的HTMLのみの共有には変換作業が必要です。
切り替え後、Vercel Previewの自動更新URLはどう扱えばよいですか?
社外共有の正式URLが認証付きサービスに移ったあとも、Vercel PreviewのURLは社内の開発確認用として維持できます。ただし社外に誤送信しないよう、Slackや社内wikiで「社外共有禁止」と明記しておくことを推奨します。
切り替えのタイミングをチーム内でどのように合意すればよいですか?
プロジェクト開始時にデザインレビューポリシーとして「社内確認はVercel Preview、社外提出は認証付きサービス」とルールを文書化しておくのが最も効果的です。個人の判断に委ねると属人化が起き、ルールが形骸化します。