概要
Cloudflare Pagesのブランチプレビューは、リポジトリと接続するだけで、ブランチやPRの更新をトリガーに"動くURL"を即時に用意します。非エンジニアを含む関係者が同じ画面を見ながら確認できるため、コミュニケーションの齟齬が減り、修正の往復も短くなります。本稿では、導入から運用の型づくり、Pages Functionsによる軽量ベーシック認証、よくある落とし穴までを一気通貫で整理します。
仕組み
- Git連携 GitHub/GitLabのリポジトリをPagesに接続すると、pushやPR作成をトリガーにビルドとデプロイが自動実行されます。
- 安定したプレビューURL 各ブランチ・各PRに固有のURLが払い出され、コミットを積むたびに同じURLで最新版へ更新されます。本番用URLとは独立しているため、未承認の変更が本番に影響することはありません。
- エッジ実行 静的アセットに加え、Pages Functionsがエッジで動作するため、ローカルとの差異やCDN配信時の挙動を早期に検証できます。
導入手順
- Cloudflare Pagesで新規プロジェクトを作成し、対象リポジトリを接続する。
- ビルドコマンドと出力ディレクトリを設定する。フレームワークを使っている場合はプリセットの選択でほぼ自動化できる。
- 初回の自動デプロイ後、任意のブランチでPRを作成し、プレビューURLが生成されることを確認する。
- PRテンプレートに「プレビューURL」「確認観点」「スクリーンショット貼付欄」を追加して、以降のレビュー運用を標準化する。
運用ルール
ブランチ命名とPRタイトル
feature/xxx、fix/yyyなど意図が即時に伝わる命名に統一する。- PRタイトルは「変更の要約＋ユーザー影響」を明確にする。
プレビューURLの提示
- PR本文の冒頭にプレビューURLを必ず記載する。
- 仕様変更やUI差分が分かる1枚のスクリーンショットを添える。
確認観点のテンプレート化
- レイアウト、フォーム送信、主要導線、主要ブラウザ、モバイル幅を定型のチェック項目にする。
- 変更の影響範囲（UX、SEO、パフォーマンス）も記入欄を設ける。
露出制御
- プレビュー環境は原則
noindex。共通レイアウトに<meta name="robots" content="noindex">を仕込み、環境変数でON/OFFを切り替える。 - 外部共有は必要最小限とし、PRクローズ後は共有を停止する。
Pages Functionsでの軽量ベーシック認証
プレビューを関係者に限定したい場合、Pages Functionsで簡易なベーシック認証を挟みます。本番ブランチは素通し、プレビューのみ認証を要求する構成が定着しています。
事前設定（Variables and Secrets）
BASIC_USER（Secret）BASIC_PASS（Secret）PRODUCTION_BRANCH（例：main） プレビューと本番で値を分けたい場合は、それぞれのスコープに設定します。
ミドルウェア例（TypeScript）
functions/_middleware.ts
export const onRequest = async (context) => {
const { request, env, next } = context;
// 本番ブランチは認証なし
if (env.CF_PAGES_BRANCH === env.PRODUCTION_BRANCH) {
return next();
}
// プレビューのみBasic認証
const auth = request.headers.get("Authorization") || "";
const [scheme, encoded] = auth.split(" ");
if (scheme !== "Basic" || !encoded) {
return new Response("Unauthorized", {
status: 401,
headers: { "WWW-Authenticate": 'Basic realm="Preview"' },
});
}
const [user, pass] = atob(encoded).split(":");
if (user !== env.BASIC_USER || pass !== env.BASIC_PASS) {
return new Response("Forbidden", { status: 403 });
}
return next();
};
ポイント
CF_PAGES_BRANCHはPagesが注入する環境変数。ブランチ単位で挙動を分岐できる。- ベーシック認証は簡易防御。重要情報を扱う場合は別途の認証方式を検討する。
現場で効く進め方
- 作業開始：
feature/xx-improve-listingのようにブランチを切る。 - push：Lint/FormatをCIで自動適用し、差分を明瞭に保つ。
- PR作成：冒頭にプレビューURL、確認観点チェック、スクショを貼る。
- レビュー：関係者全員がプレビューURLを触り、コメントはPRに集約。
- 修正→再push：同一URLで最新版へ即時反映。
- マージ：レビュー条件を満たしたら本番ラインへ。
- クローズ：PRを閉じ、関連Issueを自動Resolveするキーワードを活用する。
つまずきと対処
- URLが増えて追えない PRテンプレートの冒頭にプレビューURL固定欄を設け、週次でオープンPRを棚卸しする。
- プレビューでだけ機能しない Previewスコープの環境変数漏れ、外部APIのリダイレクトURLやCORS設定の固定化を点検する。
- 検索露出が不安
noindexをメタとレスポンスヘッダの両面で適用し、共有リンクは期限付きで管理する。
チェックリスト
- リポジトリ接続、ビルドコマンド、出力ディレクトリの明確化
- Branch build対象を主要ブランチ＋PRに限定
- PRテンプレートにプレビューURL、確認観点、影響範囲を追加
noindexの適用を環境変数で制御- 必要に応じてPages Functionsでベーシック認証を実装
- 週次でオープンPRの棚卸しとルール順守の振り返り
まとめ
Cloudflare Pagesのブランチプレビューは、PRごとに安定した"動くURL"を提供することで、レビュー速度と品質を同時に引き上げます。命名規約、PRテンプレート、noindex、軽量認証を整えるだけで、レビューは「説明」から「実体験」に置き換わり、意思疎通のコストが大きく下がります。まずは小さな変更でPRを立て、プレビュー→フィードバック→修正の短いループをチームの標準にしてください。