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

できること

GitHub Pages単体の機能範囲では、カスタムドメインの設定・HTTPSの自動適用・404ページのカスタマイズ・Jekyll等の静的サイトジェネレーターとの連携が可能です。Gitのブランチ管理と連動するため、バージョン管理と公開状態を同期させながら運用できます。

GitHub Actionsを使えば、特定ブランチへのプッシュ時だけデプロイをトリガーするなど、公開タイミングを細かく制御できます。マージ前にレビュー担当者の承認を必須にするブランチ保護ルールとも組み合わせ可能です。

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

できないこと

GitHub Pagesにはアクセスを特定のユーザーやグループに制限する機能がありません。GitHubのプライベートリポジトリ設定でもPages URLへのアクセスは制御できないため、URLを知っている人は誰でも閲覧可能です。これはGitHub Pagesの設計上の特性であり、追加設定で回避しようとすると必ず外部サービスが必要になります。

公開期限の自動設定もありません。案件ごとにブランチを作ってPages公開している場合、終了した案件のブランチを削除し忘れると、古いプレビューURLが数ヶ月・数年単位で有効なまま残ります。複数案件を並行運用するチームでは、定期的なブランチ棚卸しが必要です。

認証と期限の違い

GitHub Pagesに認証を追加する方法として最も現実的なのは、Cloudflareのリバースプロキシ経由でCloudflare Accessを適用することです。この場合、GitHubのリポジトリはそのままで、Cloudflare側でメール認証やOTP認証のポリシーを設定します。設定の習得コストはあるものの、一度構築すれば複数プロジェクトに流用できます。

期限管理については、Cloudflare Accessのポリシーに有効期間を設けることは可能ですが、「URLが期限切れになった」とアクセス者に明示するページをカスタマイズするには追加の設定が必要です。一時共有URLサービスは期限切れを自動でハンドリングし、専用の「公開終了ページ」を表示するため、エンドユーザー体験が整っています。

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

差し替え・レビュー運用

Cloudflare Access + GitHub Pagesの構成は、一度設定すれば同じプロジェクトを継続的に保護できる点で優れています。反面、案件ごとに新しいAccessアプリケーションを作成するのは手間であり、短期プロジェクトや単発のレビュー共有には向いていません。

単発の社外レビューには、ビルド済みのHTMLファイルをZIP化してギガサイト便などにアップロードする方が圧倒的に速いです。会社ドメイン認証・パスワード認証・メール認証を選んでURLを発行するだけで完了し、差し替えも同じURLに再アップロードするだけです。GitHub Pagesは本番インフラとして存続させ、レビュー共有は専用ツールに任せる役割分担が最もシンプルです。

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

向いているケース早見表

GitHub Pages + Cloudflare Accessの構成が向くのは、同一プロジェクトを継続的に保護したい・社内スタッフや固定のパートナーが定期的にアクセスするステージング環境・GitHubとCloudflareの両方をすでに有料プランで契約している組織です。

一時共有URLサービスへの切り出しが向くのは、案件ごとにURLを使い捨てにしたい・デザイナーやプロデューサーがGitやCloudflareを操作せずに共有を完結させたい・期限の自動管理でガバナンスを担保したい、というケースです。特に制作会社・代理店では後者のパターンがコスト削減に直結しやすいです。