☁️
Cloudflare Pagesでブランチごとの確認環境を用意する

2026/01/21に公開
 背景GitHub上のリポジトリを静的サイトとして公開したい場合、最も手軽なのはGitHub Pagesです。しかしGitHub Pagesでは一つのブランチしか公開できず、開発中の複数のブランチを公開することができません。この課題を解決するために、Cloudflare Pagesを利用しました。Cloudflare Pagesではブランチを更新するごとに静的サイトを公開することができます。これにより、開発中のサイトの確認環境を複数同時に簡単に用意することができます。
設定もシンプルなのですが、実際に設定する際はつまづいた点がいくつかあり、注意する点も多いと感じたため、手順をまとめておきます。

 要件手順をまとめる前に、今回の要件を整理しておきます。

今回は、LPなどの静的サイトのデザイン確認用の環境といった用途を想定します。このため以下のような要件を満たせると嬉しいです。Cloudflare Pagesでは以下の要件を満たす環境を無料で構築することができます。
複数のサイトや状態を確認できるようにブランチごとに別のURLを用意し同時に確認できる
エンジニアを介さずGit操作（GitHubでのPull Requestを含む）で環境を用意できる
各URLにはアクセス制限がかけられる。できればユーザー登録などアカウント管理は行いたくない

 実施した手順それでは実際の手順を記載していきます。

大きくはGitHubとの連携（Pagesの作成）、アクセスポリシーの設定の2つのステップです。

キャプチャを元に手順を記載していきますが、画面は2026年1月時点のもののため、変更があった場合は適宜読み替えてください。

 事前準備https://www.cloudflare.com/ja-jp/
まずはCloudflareのアカウントを作成します。Cloudflareは日本語に対応しているので、アカウントを作成したら、右上のプロフィールアイコンから言語設定を変更しておきましょう。


 GitHubとの連携（Pagesの作成）GitHubと連携して、Pagesを作成します。

 Pagesの作成画面に遷移左メニューから「コンピューティングとAI」>「Workers & Pages」を選択します。
右上の「アプリケーションを作成する」ボタンを押します。

表示された画面下部の「Pagesを導入しようとお考えですか？」と書かれた右にある「始める」リンクを押します。表示された画面はWorkerの作成画面のため今回は不要です。分かりづらいですが、Pagesの作成画面には下部のリンクから遷移できます。

Pagesの作成画面では、「既存のGitリポジトリをインポートする」の方の「始める」ボタンを押します。


 リポジトリの選択リポジトリの選択画面ではGitHubと連携して、Pagesで公開するリポジトリを選択します。画面に沿って連携を進めていきます。


注意点として、この連携作業はGitHub側のOwner権限が必要です。Orgに所属している場合は、OrgのOwner権限が必要です。 リポジトリのAdmin Roleでは足りません。権限がない場合は以下のような画面になります。Owner権限は非常に強い権限のため、権限をもらうよりも、権限のある方をCloudflare側に招待して作業を実施してもらった方が良いかもしれません。

うまく連携できたらリポジトリの選択画面に遷移します。Pagesを作成するリポジトリを選択して、「セットアップの開始」ボタンを押します。



 ブランチの選択とデプロイ最後にビルドの設定を行います。シンプルに静的サイトをデプロイするだけであれば、特に変更は必要ありません。
ただし、ここで「保存してデプロイする」と、その後すぐにデプロイが開始され、指定したブランチのサイトが公開されるという点には注意が必要です。公開されても問題ない場合はそのまま進めて問題ありませんが、一時的にでも公開されると問題がある場合は、内容を空にしたブランチをプロダクションブランチに設定するなどの対応が必要です。
一度公開されてしまうと、Pagesそのものを削除するか、GitHubとの連携などの設定を残したければ空のファイルで上書きするなど、公開を取り消すのがかなり面倒です。

デプロイが成功すると以下のような完了画面が表示されます。表示されたURLにアクセスするとデプロイされたサイトが確認できます。


 アクセスポリシーの設定ここまでで、GitHubとの連携、Pagesの作成が完了しました。ブランチを作成し、GitHub上にプッシュすることでブランチごとのサイトが自動で作成されます。

しかし、このままではすべてのサイトが誰でもアクセスできる状態で公開されてしまいます。そこで、アクセスポリシーを設定してアクセスを制限します。
実際に行う手順は以下の3つです。
アクセスポリシーを有効化する
特定ドメインのメールアドレスを持つ人だけがアクセスできるようにする
メインのドメインのアクセス制限を追加する
なお、ここからの手順は、Cloudflare上でレガシー扱いとなっています。

現在はCloudflare Zero Trustという仕組みを利用することが推奨されているようです。無料プランもありますが、支払い情報の登録が必須となっています。今回は一旦支払い情報を登録せずに進めたいため、レガシー扱いとなっているポリシーの設定方法で進めます。将来的にはZero Trustへの移行も検討した方が良さそうです。

 アクセスポリシーを有効化する「Workers & Pages」メニューから作成したPagesのアプリケーションを選択し、「設定」タブから、「Accessポリシー」を有効化します。有効化すると、メインのドメイン以外のサブドメインに対してアクセス制限がかかります。初期状態では、ユーザー登録しているユーザーのみアクセス可能な状態になっています。

 特定ドメインのメールアドレスを持つ人だけがアクセスできるようにするアクセス制限の初期状態では、ユーザー登録したユーザーのみがアクセス可能な状態になっています。これを特定ドメインのメールアドレスを持つ人であれば、ユーザー登録せずにアクセスできるように変更します。
「Accessポリシー」を有効化すると、「有効にする」ボタンが「管理」ボタンに変わりますが、「管理」ボタンを押すと「そのページは見つかりませんでした。」と表示されます。ただし、左メニューがセキュリティのものに変わっているため、「Accessコントロール」から「ポリシー」を選択することで設定画面に辿り着けます。
続けて「レガシーポリシー」タブを選択すると、「Allow Members - Cloudflare Pages」ポリシーが設定されています。このポリシーがアクセスポリシーを有効化したことで設定されたポリシーになります。
ここからこのポリシーを編集していきます。ポリシーを選択後、「設定」ボタンから設定画面を開きます。設定画面内の「ルールを構成する」という箇所に「Emails」というセレクターに対して、ユーザー登録されているメールアドレスが追加されています。ここに特定ドメインのメールアドレスを許可するセレクターを追加していきます。
「+インクルードの追加」ボタンから「Emails ending in」セレクターを追加し、値として許可したいメールアドレスのドメイン（複数可）を追加します。
これで特定ドメインのメールアドレスを持つ人だけがアクセスできるようになります。

 メインのドメインのアクセス制限を追加するブランチの公開URLはサブドメインとなっているため、アクセスポリシーを有効化した時点でアクセス制限がかかります。一方でプロダクションに設定したブランチの公開URLはメインのドメインでアクセスが可能なため、まだアクセスができる状態になっています。ここではメインのドメインにもアクセス制限をかけていきます。
先ほどのポリシーの設定画面の上部に「←<メインのドメイン>に戻る」というリンクがあります。このリンクを押すと、アプリケーションの編集画面に遷移します。この画面のパブリック ホスト名の箇所にポリシーの対象ドメインが設定されています。初期状態ではサブドメインに*が入ったものが設定されています。ここにメインのドメインを追加します。下図のようにサブドメインだけ空にしたホストを追加します。
これでメインのドメインにもアクセス制限がかかります。
注意点としては、この画面へのアクセスです。上述したように、「←<メインのドメイン>に戻る」というリンクから辿りましたが、左メニューからも分かる通り、これはアプリケーションの設定画面です。しかし、左メニューからアプリケーションを選択しようとするとZero Trustのプラン選択へと誘導され、アプリケーションを選択することができません。プラン選択を行っていない場合は、設定画面にたどり着くのが難しくなっています。こういった点からもこの設定がレガシー扱いとなっていることがよく分かります。

 動作確認以上で設定は完了です。GitHub上にブランチを作成したり、更新したりすると、ブランチごとの環境が作成、更新されます。またそれぞれのURLはCloudflareの管理画面上からはもちろん確認できますが、Pull Requestを作成することで、GitHub上で確認できるようになります。実際の運用ではこちらを利用するのが良さそうです。
アクセス制限が機能している場合は、以下のようなメールアドレスを入力する画面が表示されます。ここに許可されているドメインのアドレスを入力すると、「Cloudflare Access login code for」で始まるタイトルのメールが届きます。このメールに記載されたアクセスコードを入力することでアクセスが可能になります。


 まとめCloudflare Pagesを使って、ブランチごとに異なるURLで確認できる環境を無料で構築できました。Pull Requestを作成するだけでプレビュー環境が自動で用意され、メールアドレスのドメインによるアクセス制限も設定できたため、当初の要件を満たすことができました。
設定自体はシンプルですが、画面遷移がやや複雑でつまづく点も多かったため、手順を記録しました。また、今回利用したPages上で直接設定できるアクセスポリシーはレガシー扱いとなっており、CloudflareはZero Trust Accessでの設定を推奨しています。運用していく中で、Zero Trust Accessへの移行も検討していきたいと思います。