Cloudflare Pagesから一時共有URLへ切り替えるタイミング

できること

Cloudflare Pagesは、GitHubやGitLabのリポジトリと連携してプッシュのたびに自動デプロイします。開発チーム内でのレビューや、エンジニア同士のコードレビューに付随するビジュアル確認には非常に適しており、CI/CDの一環として組み込みやすい点が強みです。

また、Cloudflare Pagesはビルドログやデプロイ履歴をダッシュボードで管理できるため、「いつ誰がどのコミットをデプロイしたか」を追跡できます。社内の品質管理フローに組み込むことで、デプロイ状況の可視化が容易になります。

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

できないこと

Cloudflare Pagesの標準デプロイURLには、有効期限を設定する機能がありません。プロジェクトが終了してもURLが生き続け、古い案を誤って参照されるリスクがあります。クライアントの承認後に「もう見られないようにしてほしい」と求められると、手動での対応が必要です。

さらに、Cloudflare Pagesはアクセス者を追跡するログ機能を標準で持ちません。「誰がいつプレビューを確認したか」を把握したい場合、Cloudflare Analyticsやサードパーティのアクセス解析を別途導入する必要があり、セットアップに手間がかかります。

認証と期限の違い

開発フェーズと承認フェーズでは、URLに求められる要件が変わります。開発中はすばやくURLを共有して意見をもらう速度が優先されますが、承認フェーズでは「誰が見たか」「いつ承認したか」の記録と、承認後のアクセス遮断が求められます。Cloudflare Pagesは前者に向いており、後者には追加設定が必要です。

一時共有URLサービスは、URLごとに期限・認証方式・アクセスログを設定できます。期限を3日に設定した場合、72時間後は自動でアクセス不可になります。承認記録としてアクセスログをCSVエクスポートできるサービスもあり、稟議書や作業報告書に添付する証跡として使えます。

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

差し替え・レビュー運用

Cloudflare Pagesでは、mainブランチへのマージが本番デプロイ、feature/プレビューブランチへのプッシュがプレビューデプロイとなるよう設定するのが一般的です。この運用ではブランチごとにURLが変わるため、クライアントに送るURLを毎回更新しなければなりません。

一時共有URLへの切り替えタイミングとして推奨されるのは、「社内レビューが完了してクライアントへ正式に提出するとき」です。それまではCloudflare Pagesのプレビューで開発チームが確認し、提出直前にZIPをエクスポートして認証付きURLを発行します。この分業により、開発速度と情報管理を両立できます。

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

向いているケース早見表

「Cloudflare Pagesのままでよいケース」は、社内エンジニアだけが確認するステージング・オープンベータのパブリックプレビュー・ドキュメントサイトの草稿確認など、公開しても問題ない内容の共有です。認証コストより速度を優先できる場面ではPages単体が最適です。

「一時共有URLへ切り替えるべきケース」は、競合秘匿が必要なデザイン案の提出・NDA締結中のプロジェクトの中間確認・期間限定キャンペーンのプレオープン確認などです。ギガサイト便ではHTMLまたはZIPをドラッグ＆ドロップし、パスワードと有効期限を設定するだけで3秒以内にURLが発行されます。