静的サイトは、アップロードした瞬間に公開 Web へ出してよいとは限りません。
クライアント向けプレビューには仮文言が残っているかもしれません。ポートフォリオのケーススタディは、特定の採用担当者だけに見せたい場合があります。社内ドキュメントはチームには必要でも、検索結果に出るべきではないことがあります。公開前のランディングページは、ドメインを共有する前に関係者確認が必要です。
こういう場面でパスワード保護が役に立ちます。これは完全な ID 管理システムではありません。静的コンテンツを見る前に、共有パスワードで一段だけ止めるための仕組みです。
パスワード保護が向いている場面
静的サイトには、公開前の限定共有フェーズがよくあります。サイトは完成している。ファイルもある。リンクも開ける。ただし、見る人はまだ限定したい。
| 用途 | パスワードが役立つ理由 |
|---|---|
| クライアントレビュー | 公開前に実際の URL で関係者が確認できる。 |
| 社内ドキュメント | チーム用のノート、ハンドブック、プロジェクトページを不用意に公開せず共有できる。 |
| 非公開ポートフォリオ | 選んだケーススタディだけを採用担当者、クライアント、面接官に送れる。 |
| 学生・チームプロジェクト | 何を公開し続けるか決める前に、評価者だけが確認できる。 |
| キャンペーン準備 | 文言、計測リンク、素材、モバイル表示を告知前に確認できる。 |
| PDF や資料の束 | ドキュメント、ファイル、参考資料を 1 つの静的ページで限定共有できる。 |
目的は、狙って攻撃してくる相手を止めることではありません。レビュー、修正、承認の途中で、意図せず広く出回ることを避けるためです。
パスワード、noindex、完全な認証の違い
これらは別の道具です。同じものとして扱うと期待値を間違えます。
| 方式 | できること | できないこと |
|---|---|---|
| パスワード保護 | サイト配信前に共有パスワードでカジュアルなアクセスを止める。 | ユーザーアカウント、権限、監査ログ、SSO は作らない。 |
noindex | 検索エンジンに、そのページを検索結果へ出さないよう伝える。 | URL を知っている人がページを開くことは止めない。 |
robots.txt | クローラー向けにパスの指示を公開する。 | 公開ファイルなので、保護として扱うべきではない。 |
| 完全なアプリ認証 | ユーザー、セッション、権限、ID フローを管理する。 | 静的ホスティングだけではなく、アプリ側のロジックが必要。 |
| ネットワークアクセス制御 | IdP、端末、IP、組織ポリシーでアクセスを制限する。 | 多くのクライアントプレビューには重すぎる。 |
Google は noindex をインデックス制御として説明しています。検索結果に出したくないページには有効ですが、アクセス保護ではありません。Cloudflare Access や Vercel Deployment Protection は、アプリケーションやデプロイ向けのより強いアクセス制御です。シンプルなパスワードゲートはその中間にあります。
ホームだけでなく静的サイト全体を守る
静的サイトは index.html だけではありません。
ホームだけが保護されていても、画像、スクリプト、PDF、深いリンクが公開されたままだと、プレビューは漏れる可能性があります。実用的な保護は、ページを構成するファイルも含めて、公開体験の前に置かれるべきです。
保護リンクを送る前に確認したい場所:
| パスの種類 | 確認すること |
|---|---|
| ホーム | 最初の訪問でパスワード画面が出る。 |
| 深いリンク | プロジェクトページ、docs、キャンペーン下層ページもアクセスを要求する。 |
| アセット | 画像、PDF、スクリプト、ダウンロードが分かりやすい直リンクで露出していない。 |
| フォーム | フォームがある場合、アクセス後に正しく動作する。 |
| エラーページ | 404 や fallback が機密文言やファイル名を見せない。 |
これはポートフォリオやクライアント案件で特に重要です。ホームを伏せても、未公開スクリーンショットが /assets/client-redesign-final.png で開けるなら意味が薄くなります。
パスワード運用を決める
共有パスワードは運用が簡単です。ただし、雑に扱うべきではありません。
| 状況 | 実務上の扱い |
|---|---|
| 短いレビュー 1 回 | 強い共有パスワードを使い、レビュー後に変更する。 |
| 複数のクライアントチーム | 見る人を分けたい場合は、プロジェクトやレビューリンクを分ける。 |
| リンクが広く転送された | パスワードを変更し、必要な人だけに新しいものを送る。 |
| プロジェクトを公開する | 最終承認とドメイン公開後に保護を外す。 |
| 仕事が引き続き機密 | 公開ページは伏せた内容にし、詳細は承認済みの人だけに見せる。 |
クライアントレビューに、推測しやすい冗談のようなパスワードを使うのは避けましょう。十分に長いものを使い、案件の機密度に合う経路で共有します。
パスワード保護だけでは足りない場面
パスワード保護は軽いから便利です。そして、その軽さが限界でもあります。
次のような要件がある場合は、アプリ側の認証設計が必要です。
- 個別のユーザーアカウントや招待。
- ユーザーごとに異なる権限。
- Google Workspace、Microsoft Entra、Okta などによる SSO。
- 誰が何を見たかを示す監査ログ。
- 法務、契約、コンプライアンス上のアクセス要件。
- 全員のパスワードを変えずに 1 人だけ失効させること。
- 顧客データ、決済情報、医療情報、規制対象データ。
静的プレビューには共有パスワードがちょうどよいことが多いです。顧客ポータル、社内システム、規制対象のワークフローには不十分です。
保護された静的プレビューでよくあるミス
大きな問題というより、小さな運用ミスが多いです。
| ミス | よりよい対応 |
|---|---|
| 保護を有効にする前にリンクを送る | 先にゲートを有効化し、プライベートウィンドウで確認する。 |
| 深いリンクを確認しない | プロジェクトページ、docs、アセット、PDF を直接開く。 |
| 同じパスワードを使い続ける | レビュー、公開、誤転送の後に変更する。 |
noindex をプライバシー扱いする | noindex は検索制御であり、アクセス制御ではない。 |
| 機密情報をそのまま公開する | 名前、数値、スクリーンショット、内部パスをアップロード前に伏せる。 |
| 公開後も保護を外し忘れる | 最終サイトを公開、保護、分割のどれにするか決める。 |
保護されたプレビューでも、公開サイトと同じ内容確認が必要です。パスワードは偶発的な露出を減らしますが、雑な公開を安全にはしません。
静的デプロイの流れに組み込む
パスワード保護は、デプロイ後に慌てて足すより、公開フローの一部にしたほうが扱いやすくなります。
実務的な流れ:
- 静的サイトを build または export する。
- フォルダ、ZIP、HTML 出力、フレームワーク build、ポートフォリオ、PDF 付きページをアップロードする。
- プレビュー共有前にパスワード保護を有効にする。
- レビュー担当者へリンクとパスワードを送る。
- 文言、ファイル、モバイル表示、アセットを修正する。
- 見る人が変わったらパスワードを変更する。
- 最終判断時に、保護を外すか残すか決める。
レビューは実際のサイトに近い状態で行えます。担当者は、後で公開されるのと同じルート、アセット、レスポンシブ挙動を確認できます。
DeployPages での扱い
DeployPages は静的公開を前提にしているため、パスワード保護も静的プレビューと限定共有のための機能です。バックエンド認証の代わりではありません。
静的フォルダ、ZIP、HTML プロジェクト、ポートフォリオ、docs export、AI 生成サイト、PDF アセットを含むページを公開し、ワークスペースのプランに含まれていればプロジェクト設定からパスワード保護を有効化できます。訪問者は公開サイトを見る前にプロジェクトパスワードを入力します。同じプロジェクトで アクセス解析、独自ドメイン、即時ロールバック、CLI デプロイ も使えます。
流れはシンプルです。サイトをアップロードし、レビュー中は保護し、最終版を非公開のままにするか公開ドメインへ移すか決めます。
共有前チェックリスト
パスワード保護付き静的サイトを送る前に:
- プライベートウィンドウでリンクを開き、パスワード画面が出ることを確認する。
- ホームだけでなく、深いリンクをテストする。
- 重要な PDF、画像、スクリプト、ダウンロードへの直リンクを試す。
- 機密名、内部数値、社内コメント、仮パスを削除する。
- 強い共有パスワードを使い、チームが変更できる場所で管理する。
- 仕事がセンシティブなら、リンクとパスワードを別経路で共有する。
- いつ保護を外すか、変更するか、残すか決める。
- レビュー済み版を置き換える前にロールバック手段を残す。
パスワード保護は静的サイトを複雑にするためのものではありません。作品が評価され、修正され、承認されるまでの非公開フェーズを少し安全にするためのものです。