Cloudflare Pagesでは足りない認証・期限管理をどう補うか

できること

Cloudflare Pagesそのものには認証機能がありませんが、同じCloudflareエコシステムにあるZero Trust（旧Cloudflare Access）を組み合わせることで認証を追加できます。ダッシュボードでアプリケーションを登録し、許可するメールアドレスやドメインをポリシーに設定すると、対象URLへのアクセス時にOTP認証やSSO認証が要求されます。

OTP認証を選んだ場合、相手のメールアドレスに6桁のコードが送られ、入力すると閲覧できます。GitHubアカウントやGoogleアカウントを使ったSSOも設定でき、社内スタッフへの公開には特に便利です。Zero TrustのFreeプランは最大50ユーザーまで無料で利用できます。

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

できないこと

Cloudflare Accessを使っても、URLごとに「○月○日まで有効」という期限を設定する機能はありません。ポリシーを手動で無効化すれば閉じることはできますが、事前にスケジュールして自動で期限切れにする仕組みは標準では提供されていません。複数の案件を並行管理する場合、ポリシーの棚卸しを定期的に行わないと古い共有が残り続けます。

また、Cloudflare Accessのアクセスログは管理者向けの監査ログとして存在しますが、「クライアントが確認しました」という承認記録をそのままPDF化してクライアントに提出する機能はありません。承認証跡を求めるプロジェクトでは、別途スクリーンショットやメールでの確認を取る必要があります。

認証と期限の違い

認証は「誰が見てよいか」を制御し、期限は「いつまで見てよいか」を制御します。Cloudflare Accessは前者（認証）を担えますが、後者（期限）は自動化できません。一時共有URLサービスは両方を1つのUIで設定でき、たとえば「パスワード認証 + 7日間有効」を選んで発行ボタンを押すだけで完結します。

期限が自動切れになるメリットは、管理漏れを防げることです。Cloudflare Accessでポリシーを手動管理していると、担当者が異動・退職した際に古いアクセス許可が残るリスクがあります。URLそのものが期限付きになっていれば、ポリシーの棚卸し作業自体が不要になります。

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

差し替え・レビュー運用

Cloudflare Access + Pagesの構成で認証を補完する場合、修正のたびにGitへプッシュしてデプロイを待つ必要があります。ビルドに1〜3分かかるプロジェクトでは、細かい修正のたびに待ち時間が発生します。一時共有サービスへのアップロードはビルド済みファイルのZIPをドラッグするだけなので、デプロイ待ちがありません。

差し替え頻度が高い修正フェーズはCloudflare Pages＋社内Accessで回し、クライアントへの正式提出には一時共有URLを発行する、という役割分担が現実的です。社内・外部でツールを分けることで、Pagesのデプロイ履歴が社外に漏れるリスクもなくなります。

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

向いているケース早見表

Cloudflare Access補完が向くのは、すでにCloudflareの有料プランを契約している組織・社内スタッフや決まったパートナー企業だけが継続的にアクセスするステージング環境・GitベースのCI/CDワークフローに組み込みたいケースです。

認証付き一時共有サービスへの切り出しが向くのは、案件ごとにURLを使い捨てにしたい・期限管理を自動化したい・Cloudflareアカウントを持たない外部デザイン会社や印刷会社などにファイルを見せたいケースです。ギガサイト便のようなサービスはCloudflareアカウントとは完全に独立して動くため、相互の設定が干渉しません。