Cloudflare 19：Pages ― push したら公開される静的サイト置き場

一言でいうと：git に push すると公開される置き場

Pages を一言でいうと、「git のリポジトリにつないでおくと、push するたびにビルドして、世界中の拠点に配ってくれる静的サイトの置き場」です。

図の流れを左から見てください。

あなたがやるのは、最初に一度リポジトリをつなぐことと、あとは普段どおり push することだけです。サーバーも、証明書の更新も、CDN の設定もいりません。ファイルは00号で見た世界中の拠点から配られるので、どの国の利用者にも近くから届きます。

しかも、静的ファイルの配信は、リクエストの回数に制限なく無料です。アクセスが急に増えても、料金を心配する必要がありません。この点が、個人やスタートアップに Pages が広く使われてきた大きな理由です。

ビルドは Cloudflare の中で走る

最近の Web サイトは、書いたファイルをそのまま置くのではなく、ビルドしてから公開するのが普通です。React や Vue のコードをまとめて小さくしたり、Markdown から HTML を作ったりする段階です。

Pages では、このビルドを Cloudflare の中で実行します。あなたが教えるのは2つだけです。

push が届くと、Cloudflare はリポジトリを取ってきて、依存関係を入れ（npm ci など）、ビルドコマンドを実行し、出力ディレクトリの中身を世界中に配ります。ビルドの記録（ログ）は管理画面で見られるので、失敗したときも原因を追えます。

よく使われるフレームワーク（React・Vue・Svelte・Astro など）には雛形の設定が用意されていて、選ぶだけでビルドコマンドと出力ディレクトリが入ります。

手元のパソコンでビルドする必要がないので、「自分のパソコンでは動くのに」という問題も減ります。誰が push しても、同じ手順でビルドされるからです。

ブランチごとに、別の URL で確かめられる

Pages のいちばん便利な機能が、プレビューです。

git では、新しい機能を作るとき、main（本番）とは別のブランチで作業するのが普通です。Pages は、本番のブランチ（ふつうは main）に push されたときは本番のサイトを更新し、それ以外のブランチに push されたときは、別の URL にプレビューを作ります。

GitHub でプルリクエストを作ると、Cloudflare がプレビューの URL をコメントで書き込んでくれます。レビューする人は、そのリンクを開くだけで、本番とまったく同じ環境で変更後のサイトを確かめられます。デザイナーや企画の人など、コードを読まない人にも見てもらえるのが大きな利点です。

本番は、main にマージするまで一切変わりません。プレビューで問題が見つかっても、本番の利用者には影響がないのです。

もし本番で問題が起きたら、管理画面から過去の公開（デプロイ）を選んで、すぐに戻すこともできます。

Pages Functions：functions/ に置けば API になる

静的なサイトでも、少しだけサーバー側の処理が欲しくなることがあります。問い合わせフォームの受け取り、ログインの確認、外部 API の呼び出し（キーを隠したい）などです。

Pages では、リポジトリに functions/ というフォルダを作り、そこに JavaScript や TypeScript のファイルを置くと、それがサーバー側のコードとして動きます。これが Pages Functions です。

特徴は、ファイルの場所がそのまま URL の道になることです。

functions/ の道に当たらないリクエストには、今までどおり静的ファイルが返ります。

Pages Functions の中身は、Workers そのものです（18号）。同じ実行環境で動き、同じようにバインディングで KV（20号）・R2（22号）・D1（23号）などにつなげます。料金も、Workers のリクエストとして数えられます。つまり Pages は、「静的ファイルの配信」と「Workers」を、git 連携とファイル名の決まりで使いやすくまとめたもの、と考えられます。

導入：リポジトリをつなぎ、3つの値を入れる

Pages を始める手順です。Cloudflare のアカウントと、GitHub か GitLab のリポジトリがあれば始められます。ドメインは要りません。

3で入れる値は、図の表のとおりです。フレームワークを選ぶと、ビルドコマンドと出力ディレクトリは自動で入るので、多くの場合は確かめるだけで済みます。

環境変数は、本番とプレビューで別の値を入れられます。たとえば、プレビューではテスト用の API につなぐ、といった使い分けができます。

自分のドメインで公開したいときは、プロジェクトの「カスタムドメイン」で www.example.com などを追加します。ドメインが Cloudflare の DNS（01号）で管理されていれば、DNS の行も証明書（03号）も自動で用意されます。

git を使わずに、手元でビルドしたファイルを直接上げる方法（Direct Upload）もあります。

$ npx wrangler pages deploy dist --project-name my-site

ただし、あとから git 連携に切り替えることはできないので、どちらで運用するかは最初に決めておきましょう。

_redirects と _headers で、配り方を決める

普通の Web サーバーなら、リダイレクトやヘッダーは、サーバーの設定ファイルに書きます。Pages にはサーバーの設定ファイルがありません。代わりに、出力ディレクトリの一番上に、決まった名前のテキストファイルを置きます。

_redirects は、リダイレクトの規則です。1行に「元の道・行き先・状態コード」を書きます。

/old-page    /new-page      301
/blog/*      /news/:splat   301

2行目の * と :splat は、「/blog/ 以下の残りの部分をそのまま引き継ぐ」という意味です。サイトの構成を変えたとき、古いリンクを壊さずに済みます。

_headers は、応答に付けるヘッダーの規則です。道の行の下に、字下げしてヘッダーを書きます。

/assets/*
  Cache-Control: public, max-age=31536000, immutable
/*
  X-Frame-Options: DENY

1つ目は「ファイル名に版が入っている画像や JS は、ブラウザに長く覚えさせる」、2つ目は「他のサイトの枠（iframe）の中に表示させない」という設定です。

どちらも、public/ のように「ビルドのときそのまま出力にコピーされるフォルダ」に置いておけば、ビルドのたびに出力ディレクトリの一番上に入ります。もっと複雑な判断が要るときは、Functions（前のページ）や、ドメイン全体のルール（09号）を使います。

Functions の書き方：onRequest を export する

Pages Functions のファイルでは、onRequest という名前の関数を export します。GET だけに応えたいときは onRequestGet、POST なら onRequestPost のように、メソッドの名前を付けます。

// functions/api/users/[id].ts
interface Env {
  KV: KVNamespace;
}

export const onRequestGet: PagesFunction<Env> = async (context) => {
  const id = context.params.id;                  // URL の [id] の部分
  const user = await context.env.KV.get(`user:${id}`);
  if (!user) {
    return new Response("not found", { status: 404 });
  }
  return new Response(user, {
    headers: { "content-type": "application/json" },
  });
};

引数の context には、次のものが入っています。

Workers の fetch(request, env, ctx) と比べると、入っているものはほぼ同じです。書き方が少し違うだけで、中で動いているのは Workers です。

バインディングは、管理画面のプロジェクトの設定か、wrangler.toml（または wrangler.jsonc）に書きます。手元で試すときは npx wrangler pages dev dist を使います。

Pages と Workers、いまはどちらを選ぶか

ここまで読んで、「Workers（18号）と何が違うの？」と思った人もいるでしょう。実は、その疑問はもっともで、Cloudflare 自身が、この2つを1つにまとめる方向に進んでいます。

以前は、「静的ファイルは Pages、コードは Workers」と役割が分かれていました。ところが、Workers に静的アセット（18号）が加わり、Workers だけで静的ファイルを無料で配れるようになりました。さらに、Workers にも git 連携（Workers Builds）と、ブランチごとのプレビュー URL が入りました。Pages にしかなかった便利さが、Workers でもほぼ手に入るようになったのです。

そのうえで、2026年9月時点の Cloudflare の公式のすすめは、次のとおりです。

Workers を選ぶ理由は、Durable Objects（21号）、Cron Triggers（25号）、Queues の受け取り（24号）など、Pages Functions では使えない、または使いにくい機能を、1つのプロジェクトの中で自由に組み合わせられることです。新しい機能も Workers 側に先に入っています。

移行は、多くの場合「作り直し」ではなく「設定の書き換え」で済みます。wrangler の設定に assets を書き、バインディングと環境変数を移し、カスタムドメインを付け替える、という作業です。

料金と制限：配信は無料、数えるのはビルドと Functions

Pages の料金の考え方は単純です。静的ファイルの配信は無料で、数えるのは「ビルド」と「Functions」です。2026年9月時点の主な数字は次のとおりです。料金・上限は変わるので、必ず公式の Pricing と Limits のページで確かめてください。

ビルドの回数は、本番とプレビューを合わせて数えます。小さなコミットを何度も push するチームや、いくつものブランチを同時に動かすチームでは、月500回に意外と早く届くことがあります。プレビューを作るブランチを絞る設定もあります。

Functions は Workers と同じ扱いなので、Free なら1日10万回、1回あたりの CPU 時間は短く、という Workers の制限（18号）がそのまま当てはまります。静的なページだけのサイトなら、Functions は1回も動かないので、この制限は関係ありません。

ファイル1つの大きさにも上限があります。大きな動画や、大量の画像を配りたいときは、R2（22号）に置いて配るほうが向いています。

よくある落とし穴

Pages でよくつまずく点をまとめます。

いちばん多い事故は、1つ目と5つ目です。「プレビューだから」「ビルドの中だから」と油断すると、見せてはいけないものが公開されてしまいます。

特に5つ目は勘違いしやすい点です。Vite の VITE_ で始まる環境変数のように、ビルドのときにフロントのコードへ埋め込まれる値は、完成したファイルに文字として残ります。API キーのような秘密は、Functions（サーバー側）の環境変数にだけ入れ、ブラウザには渡さないようにしましょう。

他の号とのつながり

Pages は、いくつもの号とつながっています。

上の段（18・20・22・23）は、Pages Functions からバインディングでつなぐものです。下の段は、Pages を公開し、守り、管理するためのものです。

とくに 16号の Access との組み合わせは覚えておくと便利です。社内向けのドキュメントサイトを Pages で作り、Access で「会社のメールアドレスでログインした人だけ」に見せる、という使い方がよくあります。