TL

Cloud Service

Cloudflare Pages

Gitリポジトリと連携するだけでビルドとグローバル配信を自動化できる静的サイト/JAMstackホスティング。AWS Amplify Hostingに相当。

基礎パフォーマンス効率運用上の優秀性コスト最適化
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.GitHub/GitLab連携でプッシュ時に自動ビルド・自動デプロイされる静的サイトホスティング。
  • 2.プレビューデプロイとロールバックが標準機能で、本番リリースのリスクを抑えられる。
  • 3.Pages Functionsを併用するとサーバーサイド処理も同じプロジェクトで扱える。

解決する課題

  • Gitプッシュだけでビルドとデプロイが走り、サーバー管理やデプロイスクリプトが不要
  • ブランチ／プルリクエストごとのプレビューURLで、本番に影響を与えずレビューできる
  • エッジのCDNから配信されるため、追加設定なしで世界中に低遅延で届く
  • 静的ファイルに加えてPages Functionsでサーバーサイド処理（フォーム送信、API、認証など）も同居できる
  • 過去のデプロイへの即時ロールバックで、不具合発生時の切り戻しが容易

主要概念と用語

  • プロジェクト: リポジトリと1対1で紐づくPagesの管理単位。ビルド設定や環境変数を持つ
  • デプロイ: 1回のビルド成果物。本番ブランチへのデプロイと、それ以外のブランチによるプレビューデプロイがある
  • プレビューデプロイ: 本番ブランチ以外へのプッシュやプルリクエストごとに自動生成される、独立したURLを持つ確認用デプロイ
  • ビルド設定: ビルドコマンド、出力ディレクトリ、Node.jsバージョンなどプロジェクトごとの設定
  • Pages Functions: プロジェクト内の特定ディレクトリ配下に置くと、リクエストに応じてサーバーレス関数として実行される仕組み。Workersと同じ実行基盤で動く
  • カスタムドメイン: プロジェクトに独自ドメインを割り当て、本番デプロイをそのドメインで公開する機能
  • ロールバック: 過去の成功済みデプロイを、再ビルドなしでそのまま本番に戻す操作

仕様・制限・クォータ

  • 1プロジェクトあたりのファイル数やファイルサイズ、ビルド時間には上限があり、プランによって緩和される
  • ビルドは共有のビルド環境で実行され、同時実行数やビルド時間にも制限がある
  • デプロイ履歴は一定件数が保持され、任意の過去デプロイへロールバック可能
  • Pages Functionsは実質的にCloudflare Workersと同じ実行モデル・制限（CPU時間、リクエストサイズなど）に従う
  • 1アカウントで作成できるプロジェクト数にも上限があり、プランに応じて異なる

内部の仕組み

Pagesはリポジトリへのプッシュをトリガーに、隔離されたビルド環境でビルドコマンドを実行し、指定した出力ディレクトリの静的アセットをCloudflareのグローバルネットワークにアップロードします。以降のアクセスはオリジンサーバーを経由せず、最寄りのエッジから直接配信されます。

  • 静的アセットは各エッジのキャッシュ層に配置され、更新のたびに新しいアセットへ切り替わる
  • ルーティングパスに一致するPages Functionsがある場合、そのリクエストのみWorkersランタイム上で関数が実行され、それ以外は静的アセットがそのまま返る
  • ブランチごとにビルド成果物と発行URLが独立しているため、プレビューデプロイは本番のアセットに影響しない
  • ロールバックは新たなビルドを行わず、保持済みの過去アセットへ参照を切り替えるだけなので短時間で完了する
静的アセットとFunctionsの役割分担

HTML/CSS/JS/画像などのビルド成果物はエッジキャッシュから配信され、動的な処理が必要なパスだけPages Functionsが実行されます。静的で済む部分を増やすほど応答は速く安定します。

設計パターン / ベストプラクティス

  • フレームワークの静的書き出し（SSG）を優先し、動的処理が必要な箇所だけPages Functionsに寄せる
  • 本番ブランチを保護し、変更は必ずプルリクエスト経由でプレビューデプロイを確認してからマージする
  • 環境変数とシークレットを本番／プレビューで分離し、検証用の値が本番に混入しないようにする
  • ビルド時間短縮のため依存関係のキャッシュや不要なビルドステップの削減を行う
  • カスタムドメインは本番ブランチにのみ割り当て、プレビューは自動生成URLで運用する

運用・監視

  • デプロイ履歴からビルドログを確認し、失敗時は該当コミットとログを突き合わせて原因を特定する
  • Pages Functionsを使う場合はWorkersと同様の実行ログ・エラーモニタリングの仕組みを利用できる
  • 問題のあるデプロイを検知したら、再ビルドを待たずに直前の正常デプロイへロールバックして影響を最小化する
  • ドメインやDNSの設定変更はCloudflareのDNS管理画面と連携して確認する

コスト

静的アセットの配信自体は環境に依存しにくく、Pages Functionsを併用する場合はWorkersの実行と同様の考え方で費用が発生します。無料枠でも個人サイトや小規模プロジェクトを始めやすいのが特徴です。

コストの考え方

純粋な静的サイトはビルド頻度とファイル配信が中心でコストが読みやすい一方、Pages Functionsを多用するほどWorkersの実行課金の考え方に近づきます。動的処理の比重を意識して設計します。

セキュリティ

  • カスタムドメインには自動でTLS証明書が発行・更新され、常時HTTPSで配信される
  • プレビューデプロイのURLが推測されて意図せず公開情報が閲覧されないよう、機密性の高い内容はアクセス制御と組み合わせる
  • 環境変数に保存する認証情報はシークレットとして扱い、リポジトリやビルドログに平文で残さない
  • Pages Functionsを利用する場合は、Workersと同様に入力値の検証やアクセス制御をコード側でも実装する
プレビューURLの扱い

プレビューデプロイは既定で発行URLを知っていれば誰でもアクセスできます。本番前のデータや機密情報を含める場合はアクセス制御の追加を検討します。

関連サービス・比較

観点Cloudflare PagesCloudflare Workers
主な用途静的サイト/JAMstackのホスティング汎用サーバーレス実行環境
デプロイ方式Gitリポジトリ連携で自動ビルドwranglerでコードを直接デプロイ
プレビュー機能ブランチ/PRごとに自動生成環境やバージョン機能で代替
動的処理Pages Functionsとして部分的に対応リクエスト全体をコードで処理

ハンズオン / CLI例

# wranglerでPagesプロジェクトを作成
wrangler pages project create my-site

# ビルド済みの出力ディレクトリを手動でデプロイ
wrangler pages deploy ./dist --project-name=my-site

# プロジェクトのデプロイ一覧を確認
wrangler pages deployment list --project-name=my-site

Cloudflare Service

Cloudflare Pagesを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

コンピューティング

比較で見る軸

クラウド: Cloudflare / カテゴリ: コンピューティング / 難易度: basic

導入後に効く点

プレビューデプロイとロールバックが標準機能で、本番リリースのリスクを抑えられる。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Cloudflare
カテゴリ
コンピューティング
難易度
basic
関連資格
—
設計柱
performance / operational / cost

判断チェックリスト

  • 自社の用途が「コンピューティング / performance」に近いか確認する。
  • 強みである「GitHub/GitLab連携でプッシュ時に自動ビルド・自動デプロイされる静的サイトホスティング。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

コンピューティングperformanceoperationalcost
参考: 公式ドキュメント