公開先にCloudflare Pagesを選んだ理由 — ホスティングの仕組みメモ

2026-11-07 / シリーズ「技術メモ」 第1回

このサイトの公開構成

流れは「原稿を書く → ブランチを切る → PR → main へマージ → Cloudflare が自動でビルドして公開」。工房と公開面を分けているのが、この構成の芯である。

なぜ Cloudflare Pages なのか

  1. プライベートリポジトリのまま無料で公開できる（後述のとおり、GitHub Pages の無料枠ではできない）
  2. 転送量が無制限で、アクセスが増えても課金されない
  3. ビルドは月500回まで無料。マージのたびに1回という運用では十分すぎる
  4. PRごとにプレビューURLが自動で発行される
  5. 将来、Functions（動的な処理）や Access（見られる人を限定する公開）に広げられる

仕組み：「置きに行く」のではなく「取りに来る」

昔のFTP方式は、自分のPCからサーバーへ、完成したHTMLファイルを「置きに行く」やり方だった。今の方式は向きが逆である。

  1. GitHub に原稿（Markdownなど「材料」）を push する
  2. GitHub が Cloudflare に「更新があった」と通知する
  3. Cloudflare が GitHub へ読みに来て、自社の環境でビルドし、世界中の配信拠点に配置する

ここでいうビルドとは、材料から完成品のHTML一式を生成する工程のこと。push のたびにサイト全体を組み立て直す（このサイトなら1分前後）。なお、ビルド回数と読者のアクセス数は別物で、アクセス（リクエスト数・転送量）は無料枠でも無制限である。

細かい制御も可能で、コミットメッセージの先頭に [CI Skip] と付けるとその回のビルドを飛ばせるし、「このフォルダの変更のときだけビルドする」という対象パスの設定もある。

GitHub Pages との違い

項目GitHub PagesCloudflare Pages
公開できるリポジトリ無料枠は公開リポジトリのみプライベートでも可
転送量月100GB程度が目安のソフト制限無制限
ビルドGitHub Actions（設定が必要）自動（月500回まで無料）
動的な機能静的サイトのみFunctions / Access が使える
PRプレビュー標準ではなし自動で発行

決定的なのは1行目で、このリポジトリはプライベートなので、GitHub Pages を使うなら「リポジトリを公開する」か「有料プランに入る」必要がある。

レンダリングとハイドレーション

このサイトはビルド時に全ページを生成し終える静的サイトで、Astro は原則として JavaScript を送らない。記事内のクイズや演習も、HTML に直接書いた素の JavaScript がそのまま動いているため、ハイドレーションという工程自体が存在しない。なお Astro には、ページの大半は静的のまま、検索窓のような部品だけを動かす「アイランド」という部分的なやり方もある。

ついでに：記事への画像とリンクの書き方

どちらも Markdown の標準記法で、ビルドすると <a> や <img> に変換されて表示される（実際にテスト記事でビルド確認済み）。

まとめ