Netlify Deploy Previewsでは足りない認証・期限管理をどう補うか

できること

Netlify Deploy Previewsはプルリクエスト作成をトリガーにビルドとデプロイが自動で走ります。Netlifyが提供するビルドキャッシュを活用すると、依存パッケージの再インストールがスキップされビルド時間が短縮されます。頻繁なデプロイが必要な開発序盤のスプリントで時間を節約できます。

NetlifyはGatsby・Hugo・Jekyllなどの静的サイトジェネレーターとの相性が良く、ビルドコマンドをnetlify.tomlに記述すると毎回同じ設定でビルドされます。CI/CDの再現性が高く、「自分のPCではビルドできたがNetlifyではできない」という環境依存の問題が起きにくいです。

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

できないこと

無料プランではサイトレベルのPassword Protectionが使えず、URLを知っている全員がアクセスできます。GitHubのPRコメントに自動投稿されるプレビューURLは、パブリックリポジトリでは誰でも見つけられる状態になります。機密性のあるページを含む場合、無料プランのNetlify Previewは社外共有に使えません。

デプロイの公開期限を設定する機能もNetlifyには存在しません。PRのマージ後にプレビューデプロイを手動で削除するか、Netlifyのサイト設定でプレビューデプロイを無効化する設定変更が必要です。どちらも担当者の手作業に依存します。

認証と期限の違い

認証補完の現実的な方法として、ビルド成果物を認証付きHTML共有サービスに手動またはCIから自動アップロードする手法があります。NetlifyのBuild Pluginsを使ってビルド後のフックで外部APIにファイルを送るスクリプトを組むと、Gitプッシュと同時に認証付きプレビューが更新されます。

期限管理を補完するには、認証付きサービスの公開終了日設定をCI/CDパラメーターとして渡す方法が効果的です。たとえばPRにラベルを付けると終了日が自動設定されるGitHub Actionsのワークフローを作れば、人的ミスなしに期限管理を実現できます。設定の複雑さとチームの技術力に応じて自動化の度合いを調整してください。

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

差し替え・レビュー運用

Netlify Previewと認証付きサービスを並走させる場合、社内確認はNetlify Preview、社外提出は認証付きサービスと役割を明確に分けることが運用の安定につながります。同じコンテンツが2つのURLに存在する状態を管理するため、認証付きサービスの更新タイミングを「社外提出前の最終ビルド確定時」に統一してください。

デザイナーが直接差し替えを担当するフローでは、ビルド済みのZIPファイルを認証付きサービスにアップロードするだけで更新できる仕組みが最も摩擦が少ないです。Gitコマンドが不要なため、デザイナーがエンジニアの作業を待たずに最新版を提出できます。

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

向いているケース早見表

Netlify Preview単独で運用できるケース：社内技術チームのみがアクセスする開発確認フェーズ、Proプランでパスワード保護設定済みで社外レビュアーが信頼できる範囲、コンテンツがすべて公開情報。

認証付きサービスによる補完が必要なケース：無料プランで社外共有が必要、未公開コンテンツを含む、個人単位のアクセスログが必要、期限の自動管理が必要、Gitを使わないデザイナーが差し替えを担当。これらのいずれかが当てはまれば、最初から認証付きサービスを選択する方がトータルの工数が少なくなります。