til/…/web-hosting-github-pages-vs-cloudflare
web-hosting-github-pages-vs-cloudflare.mdupdated 2026-07-3112,207 chars

GitHub Pages と​ Cloudflare Pages — 違いと​ nikinakamura.com への​移行計画

この​ TIL は、​現在 niki-nakamura.github.io/til/ で​公開している​この​サイトを、すでに​保有している​ドメイン nikinakamura.com（自動更新は​ 2027-04-21）​へ移すべきかを​検討した​記録である。​前提と​して、​まずホスティング​（＝サイトの​ファイルを​置いて​公開する​ための​場所を​貸す仕組み）と​ CDN​（Content Delivery Network ＝ コンテンツ配信網。​世界各地の​拠点に​複製を​置き、​利用者に​近い​拠点から​配信する​仕組み）の​基礎を​押さえ、​GitHub Pages と​ Cloudflare Pages​（クラウドフレア・ページ​ズ）が​それぞれ実際に​何を​しているのか、​なぜ​無料なのかを​分解する。​そのうえで​具体的な​移行手順と​落とし穴を​書き出し、​最後に​結論と​して​「いまの​自分に​とって​最適な​もの」を​定める。

1. HTTP と​ウェブホスティングの​基礎

1.1 HTTP / HTTPS が​裏側で​行っている​こと

ブラウザに​ https://niki-nakamura.github.io/til/ と​入力した​とき、​通信は​次の​順序で​起こる。

  1. DNS 解決​（DNS resolution ＝ 名前を​住所に​変換する​処理）：niki-nakamura.github.io と​いう​名前が​ IP アドレスに​変換される。​問い​合わせは​ OS の​リゾルバ​（＝名前解決を​担う​ OS 側の​機能）​→ ISP​（＝インターネット接続事業者）の​ DNS キャッシュ → 権威 DNS サーバー​（＝​その​ドメインの​正解を​持つサーバー）の​順に​進む
  2. TCP 接続：解決した​ IP に​対し、​3 ウェイハンドシェイク​（SYN / SYN-ACK / ACK ＝ 3 往復の​合図で​接続を​確立する​手順）で​ TCP 接続を​確立する
  3. TLS ハンドシェイク：HTTPS なので​証明書を​交換し鍵を​共有する。​TLS 1.3 は​ 1-RTT​（RTT ＝ 往復に​かかる​時間）を​要し、​再接続時は​ 0-RTT で​済む
  4. HTTP リクエスト：GET /til/ HTTP/2 のような​要求が​送られる
  5. HTTP レスポンス：サーバーが​ステータスコード​（200 OK など）と​ HTML を​返す
  6. 追加リソース：HTML 内の​ <link>・<script>・<img> が​解析され、​同じことが​繰り返される

HTTP の​正式な​仕様は​ RFC 9110​（HTTP Semantics）と​ RFC 9112​（HTTP/1.1）に​定められている​（https://www.rfc-editor.org/rfc/rfc9110.html）。RFC​（＝インターネット技術の​公式仕様書）の​うち HTTP/2 は​ RFC 9113、​HTTP/3 は​ RFC 9114 であり、​HTTP/3 は​ TCP ではなく​ QUIC​（クイック ＝ UDP 上で​ TLS と​流量制御を​統合した​通信規約）を​使う。​実務的には、​HTTP/2 は​ヘッダ圧縮と​多重化​（＝同一接続で​複数の​リクエストを​並行して​送る​こと）を​もたらし、​HTTP/3 はヘッドオブラインブロッキング​（head-of-line blocking ＝ 先頭の​処理が​詰まると​後続も​待たされる​現象）の​解消を​もたらす。

1.2 DNS の​役割

DNS は​「名前 → IP」を​引くだけでなく、​用途ごとに​複数の​レコード種別を​持つ。​ウェブホスティングで​主に​触るのは​次の​ 3 つである。

  • A レコード：名前を​ IPv4 アドレスに​対応づける​（例：nikinakamura.com → 185.199.108.153）
  • CNAME レコード：名前を​別の​名前に​対応づける​（www.nikinakamura.com → niki-nakamura.github.io.）。​ルートドメイン​（apex ＝ サブドメインを​付けない​ドメインその​もの）に​ CNAME を​置く​ことは​ RFC 上禁じられており、​代替と​して​ A レコード、​または​ ANAME / ALIAS と​呼ばれる​疑似レコードを​使う
  • NS​（ネームサーバー）​レコード：​その​ドメインの​権威 DNS サーバーを​指定する。nikinakamura.com を​ Cloudflare に​載せるとは、​レジストラ​（＝ドメインの​登録を​扱う​事業者）​側の​ NS レコードを​ Cloudflare の​ NS​（例：ns1.cloudflare.com）に​書き換える​ことを​意味する

ほかにも​ MX​（メール）、​TXT​（SPF / DKIM ＝ 送信元の​正当性を​示す仕組み、​および​所有権確認）、​CAA​（＝証明書の​発行を​許可する​認証局を​指定する​レコード）が​あり、​ネームサーバーを​移行する​際は​ MX レコードを​必ず​引き継が​なければならない​（詳細は​ §5.8）。

1.3 ​「ホスティング」の​層

ひとまとめに​「ウェブホスティング」と​呼んでいるが、​実際には​いく​つかの​層に​分かれる。

  • 静的サイトホスティング：HTML / CSS / JS / 画像を​そのまま​返すだけの​もの。​GitHub Pages、​Cloudflare Pages、​Netlify​（ネットリファイ）、​Vercel​（ヴァーセル）の​静的配信部分、​S3 + CloudFront など
  • サーバー実行型ホスティング：PHP / Node.js / Python などで、​リクエストごとに​サーバー上で​コードを​実行する​もの。​Heroku​（ヘロク）、​Render​（レンダー）、​AWS Elastic Beanstalk、​自前の​ VPS​（Virtual Private Server ＝ 仮想専用サーバー）など
  • オブジェクトストレージ：ファイルを​置くだけの​保管庫。​Amazon S3、​Cloudflare R2、​Google Cloud Storage。​単体でも​ HTTP 配信できるが、​通常は​前段に​ CDN を​置いて​使う
  • エッジホスティング：世界各地の​エッジ拠点​（＝利用者に​近い​配信拠点）で​コードを​実行する​もの。​Cloudflare Workers、​AWS Lambda@Edge、​Vercel Edge Functions、​Deno Deploy​（ディノ・デプロイ）

静的サイトは​エッジホスティングと​相性が​よく、​近年の​ Pages 系サービス​（Cloudflare Pages、​Vercel、​Netlify）は​「静的サイトホスティング ＋ エッジ実行」の​ハイブリッドに​なっている。

1.4 CDN と​エッジキャッシュ

CDN は、​コンテンツを​世界中の​ PoP​（Points of Presence ＝ 接続拠点）に​複製し、​利用者に​最も​近い​ PoP から​配信する​仕組みである。​Cloudflare の​解説​（https://www.cloudflare.com/learning/cdn/what-is-a-cdn/）に​よれば、​CDN が​サイトを​速く​する​理由は​次の​ 3 つに​集約される。

  1. 物理的な​距離の​短縮：東京の​利用者に​米国東部の​オリジンから​配信すると​往復 100ms 超かかるが、​東京の​ PoP に​キャッシュが​あれば​数 ms で​返る
  2. オリジン負荷の​低減：同じ​ファイルを​複数の​利用者に​返す場合、​キャッシュヒットすれば​オリジンへの​問い​合わせが​発生しない
  3. 接続の​効率化：PoP は​バックボーン​（＝事業者の​基幹回線）​経由で​オリジンへの​持続的接続を​維持しており、​TCP / TLS の​確立コストを​分散できる

「オリジン」とは​実ファイルが​置かれている​場所、​「エッジ」とは​世界各地の​ PoP を​指す。​エッジで​キャッシュミスが​起きた​ときに​のみ、​オリジンから​取得する。​静的サイトでは、​ビルド成果物​その​ものを​あらかじめ全 ​PoP に​事前配布する​方​式が​主流である。

2. GitHub Pages の​仕組み

2.1 push から​配信までに​起きる​こと

main ブランチに​ push した後、​内部では​次の​流れが​走る。

  1. GitHub Actions​（＝GitHub 上で​自動処理を​走らせる​仕組み）が​自動的に​起動する​（ワークフローを​明示的に​書かなくても、​Pages の​設定を​有効に​すると​裏で​ pages-build-deployment と​いう​ Action が​動く）
  2. リポジトリ直下の​ _config.yml を​読み、Jekyll​（ジキル ＝ Ruby 製の​静的サイトジェネレーター。​原稿から​ HTML を​生成する​道具）が​ bundle exec jekyll build 相当の​ビルドを​実行し、​成果物を​ _site/ に​出力する
  3. その​成果物が​ GitHub の​静的配信基盤に​転送され、​Fastly​（ファストリー ＝ CDN 事業者）​ベースの​ CDN に​配置される
  4. <user>.github.io/<repo>/ と​いう​ URL で​配信が​始まる

GitHub Pages の​ CDN は​ Fastly である、と​いうのが​通説であり、niki-nakamura.github.io に​ curl -I を​打った​ときに​返る​ server: GitHub.com ヘッダや、​過去の​障害報告​（status.github.com）から​繰り返し確認されている。ただし GitHub の​公式ドキュメントは​「CDN を​使用している」としか​書いておらず、​Fastly と​明記した​箇所は​見つけられなかったため、​公式には​確認できなかった​事実と​して​記録しておく。

2.2 URL 構造と​ baseurl

GitHub Pages には​ 2 つの​ URL 構造が​ある​（https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages）。

  • ユーザー / Organization サイト：<user>.github.io（アカウントごとに​ 1 サイト）
  • プロジェクトサイト：<user>.github.io/<repo>（リポジトリごとに​ 1 サイト）

この​リポジトリは​プロジェクトサイトなので​ niki-nakamura.github.io/til/ と​いう​サブパス​（＝ドメインの​下の​階層）に​置かれており、​Jekyll の​ _config.yml で​ baseurl: /til を​設定して​内部リンクを​補正している。​ルートドメイン​（nikinakamura.com）に​配信する​場合、​この​ baseurl を​空文字に​変更しないかぎり、​CSS の​パスが​ /til/assets/... のままと​なり 404​（＝ページが​見つからない​エラー）に​なる。

2.3 なぜ​無料なのか

GitHub Pages は​保存容量・帯域・ビルドの​いずれも​無料で、​商用利用も​許可されている。​これが​成立する​事業上の​背景は​次のように​まとめられる​（推測を​含む）。

  • GitHub は​ Microsoft 傘下に​あり、​開発者を​ GitHub プラットフォームに​囲い込むためのロスリーダー​（loss leader ＝ 集客の​ために​採算を​度外視して​提供する​商品）と​して​位置づけられている
  • Pages 自体の​収益化ではなく、​Actions の​有料利用・Copilot・Enterprise 契約で​収益を​回収する​設計に​なっている
  • ハードリミット​（＝厳密な​上限値）を​緩く​設定する​ことで、​用途を​「個人サイト＋ドキュメント」に​限定し、​大規模な​商用配信を​事実上不可能に​している

2.4 ハードリミット​（公式の​数値）

GitHub 公式の​制限ページ​（https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits）に​書かれている​制限は​おおむね次の​とおり。

  • 公開サイトの​最大サイズ：1 GB
  • 帯域：ソフトリミット​（＝目安と​しての​上限）​100 GB / 月
  • ビルド頻度：ソフトリミット 10 回 / 時​（GitHub Actions の​カスタムワークフローで​ビルドする​場合は​非適用）
  • ビルドの​タイムアウト：10 分で​デプロイ失敗
  • 配信：静的のみ。​サーバーサイドの​コード実行は​不可

加えて、​Jekyll のプラグイン許可リスト​（allowlist）が​ある。_config.yml の​ plugins: に​列挙できる​ gem​（＝Ruby の​ライブラリ配布単位）は​ GitHub が​許可した​ものに​限られ、pages-gem の​依存関係​一覧​（https://pages.github.com/versions/）に​載る​既定の​およそ​ 9 個と、​追加で​許可された​プラグインしか​使えない。​未承認の​プラグインを​足すと​ Pages 側の​ビルドが​通らず、​ローカルで​ jekyll build した​成果物を​ push するか、​GitHub Actions で​任意の​ビルドを​走らせて​成果物を​デプロイするか、​いずれかの​回避策が​必要に​なる。

2.5 カスタムドメインを​向ける​標準手順

公式の​手順は​次の​とおり​（https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site）。

  1. リポジトリの​ Pages 設定の​ Custom domain に​ nikinakamura.com を​入力する​ → リポジトリに​ CNAME ファイルが​自動で​コミットされる
  2. レジストラ​（または​ DNS 事業者）​側で​次の​レコードを​設定する​：
    • apex：GitHub の​ 4 つの​ IP に​対する​ A レコード​（185.199.108.153 / .109.153 / .110.153 / .111.153）
    • www：niki-nakamura.github.io. への​ CNAME
  3. GitHub 側で​ DNS チェックが​通ったら​ Enforce HTTPS を​有効化する。Let's Encrypt​（レッツ・エンクリプト ＝ 無料で​ SSL 証明書を​発行する​認証局）の​証明書が​自動で​発行される

3. Cloudflare Pages の​仕組み

3.1 push から​配信までに​起きる​こと

Cloudflare Pages は​ GitHub の​ Pages とは​別物であり、​Cloudflare 自前の​ビルド基盤と​ CDN を​使う​（https://pages.cloudflare.com）。

  1. Git 連携に​よって​ push を​検知する
  2. Cloudflare の​ビルド環境​（コンテナ ＝ 隔離された​実行環境）で、​任意の​ SSG​（Static Site Generator ＝ 静的サイトジェネレーター）​や​フレームワークを​実行する。​Jekyll、​Hugo​（ヒューゴ）、​Astro​（アストロ）、​Next.js、​Remix​（リミックス）、​SvelteKit​（スベルトキット）、​Nuxt​（ナクスト）と​いった​主要フレームワークが​プリセットと​して​用意されている
  3. 成果物を​ Cloudflare の​グローバル CDN に​配布する。​Cloudflare の​ネットワークは​ 337 都市・100 か​国以上に​及ぶ​（https://www.cloudflare.com/network/）
  4. 全 ​PoP からの​エッジ配信

GitHub Pages との​最大の​構造的な​違いは、​ビルド成果物を​ CDN の​オリジンと​して​配信するのではなく、CDN 自体に​事前配布する点に​ある。​エッジが​本体なのである。

3.2 DNS と​ SSL

nikinakamura.com を​ Cloudflare で​運用するには、​レジストラ側のネームサーバーを​ Cloudflare の​もの​（例：bob.ns.cloudflare.com / lara.ns.cloudflare.com）に​切り替える。​これに​より​ Cloudflare の​ DNS が​権威サーバーに​なる。

  • HTTPS 証明書​（Universal SSL）は​自動で​発行・​更新される。​バックエンドに​ Let's Encrypt と​ Google Trust Services を​持つ
  • HTTP/3、​TLS 1.3、​IPv6 が​既定で​有効
  • DNS 設定画面では、​レコードごとに​「Proxied​（オレンジ色の​雲）」か​「DNS only​（灰色の​雲）」を​選べる。​Proxied に​すると​ Cloudflare の​ CDN / WAF​（Web Application Firewall ＝ ウェブアプリを​狙う​攻撃を​遮る​防御） / DDoS 防御​（＝大量アクセスで​サービスを​止める​攻撃への​対策）を​経由する

3.3 なぜ​無料なのか​（重要）

Cloudflare Pages の​無料プランには帯域無制限・リクエスト無制限・サイト数無制限が​含まれる​（https://pages.cloudflare.com）。​これが​事業と​して​成立する​理由は、​彼ら​自身が​複数の​ブログ記事で​説明している。​要点は​次の​ 4 つ。

  1. コスト構造：Cloudflare は​自前の​グローバル CDN​（337 都市、​世界人口の​ 95% から​ 50ms 以内）を​保有しており、​固定費中心の​ビジネスモデルである。​ユーザーを​ 1 人増やす限界費用​（＝追加 1 単位あたりの​費用）は​ほぼゼロ
  2. 規模の​経済：無料ユーザーは​ Cloudflare の​通信量を​押し上げる。​営業資料で​「世界の​トラフィックの​ X% を​扱っている」と​言える​ほど、​商用顧客に​対する​価格交渉力が​高まる
  3. アップセル​（＝上位・周辺商品への​誘導）：Pages 自体は​無料に​保ちつつ、​周辺製品——Workers​（サーバーレス実行 ＝ サーバー管理なしで​コードを​走らせる​仕組み）、​R2​（オブジェクトストレージ）、​D1​（SQLite）、​KV​（＝キーと​値の​保管庫）、​Durable Objects、​Images、​Stream、​Zero Trust など​——で​課金する。​Pages を​入口と​して​開発者を​引き込む設計である
  4. 競合​（Vercel / Netlify）との​差別化：Vercel と​ Netlify の​無料プランは​帯域を​ 100 GB / 月で​頭打ちにし、​それを​超えると​即座に​停止するか​課金する。​Cloudflare は​ここを帯域無制限で​差別化し、​開発者の​流入を​奪っている

確認できなかった​事実：今回の​ WebFetch​（＝ウェブページ取得）では、​Cloudflare が​「Pages を​ Workers の​ロスリーダーと​位置づけている」と​明示的に​書いた​ブログ記事を​特定できなかった​（blog.cloudflare.com/cloudflare-pages-goes-full-stack/ は​別の​話題だった）。​アップセル戦略と​いう​解釈は​推測である。

3.4 ハードリミット​（公式の​数値）

Free プランの​制限​（https://developers.cloudflare.com/pages/platform/limits/）。

  • ビルド回数：500 回 / 月
  • 同時ビルド数：1
  • 1 回あたりの​最大ビルド時間：20 分
  • 1 サイトあたりの​ファイル数：20,000
  • 1 ファイルの​最大サイズ：25 MiB​（＝2 の​ 20 乗バイト単位。​約 26.2 MB）
  • 1 プロジェクトあたりの​カスタムドメイン数：100
  • 帯域：無制限
  • リクエスト数：無制限

別途、​Workers を​併用する​場合に​かぎり Workers 側の​制限​（無料プランで​ 1 日 100,000 リクエスト）が​適用される。​純粋な​静的配信のみであれば​ Workers の​制限は​無関係である。

3.5 カスタムドメインの​手順

  1. レジストラで​ネームサーバーを​ Cloudflare の​ものに​切り替える​（DNS の​伝播に​数分〜24 時間）
  2. Cloudflare Dashboard → Workers & Pages → 対象プロジェクト → Custom Domains → nikinakamura.com と​ www.nikinakamura.com を​追加
  3. Cloudflare が​ DNS レコードと​ SSL 証明書を​自動で​設定する

4. 直接比較表

項目GitHub PagesCloudflare Pages
ホスティング基盤GitHub の​静的配信＋第三者の​ CDNCloudflare 自前の​グローバル CDN
エッジ PoP 数非​公開337 都市 / 100 か​国以上
無料の​帯域ソフトリミット 100 GB / 月無制限
ビルド時間の​上限10 分20 分
ビルド回数10 回 / 時​（ソフト）500 回 / 月
同時ビルド数11
公開サイトの​最大サイズ1 GB20,000 ファイル / 各 25 MiB
フレームワークの​自由度Jekyll が​一級市民。​他は​ Actions に​よる​回避策で​対応プリセット​多数：Jekyll / Hugo / Astro / Next.js など
カスタムドメイン1 / リポジトリ​（1 サイト）100 / プロジェクト
SSLLet's Encrypt、​自動Universal SSL、​自動
エッジ実行​（サーバーレス）なし​（純粋な​静的のみ）Pages Functions / Workers と​統合
画像最適化なしCloudflare Images​（有料）
現構成の​惰性すでに​稼働中 / 移行コスト 0新規セットアップが​必要
プラットフォームロックイン​（＝特定基盤への​依存）低い​（Jekyll は​ CMS 非依存）中程度​（Workers / D1 / R2 を​使うと​依存が​高まる）

5. nikinakamura.com への​移行計画

前提は、​ドメインを​すでに​保有しており、​ホスト先と​して​無料の​ Cloudflare Pages を​検討していると​いう​状況である。​手順は​時系列で​書く。

5.1 準備：DNS を​ Cloudflare へ移す

  • Cloudflare アカウントを​作成 → nikinakamura.com を​ Add a Site で​追加
  • Cloudflare が​既存の​ DNS レコードを​スキャンして​候補を​提示するので、​レコードが​正しいか​確認する​（特に​ MX、​TXT、​CAA）
  • レジストラ側で​ネームサーバーを​ Cloudflare の​もの​（指示された​ 2 つの​ NS）に​変更する
  • 伝播を​待つ​（数分〜24 時間）。dig NS nikinakamura.com（dig ＝ DNS レコードを​問い合わせる​コマンド）で​確認できる

5.2 Pages プロジェクトの​作成

Cloudflare Dashboard → Workers & Pages → Create → Pages → Connect to Git → niki-nakamura/til を​選択。

ビルド設定：

Framework preset:    Jekyll
Build command:       bundle exec jekyll build
Build output dir:    _site
Root directory:      /
Environment:         RUBY_VERSION = 3.x（_config.yml と整合）

5.3 ビルドの​検証

Cloudflare は​プレビュー URL​（<branch>.<project>.pages.dev）を​自動で​発行する。​ここで​動作を​検証する。​注意点：

  • ルートドメインで​公開する​場合、_config.yml の​ Jekyll の​ baseurl: /til を空文字 ""に​変更する​必要が​ある。​さも​ないと​ CSS / リンクが​すべて​ 404 に​なる
  • url: も​ https://nikinakamura.com に​書き換える
  • GitHub Pages と​並行運用する​間は、baseurl を​環境変数で​切り​替えるか、​ブランチを​分ける​ほうが​安全である

5.4 カスタムドメイン

Pages プロジェクト → Custom Domains → nikinakamura.com と​ www.nikinakamura.com の​両方を​追加する。​Cloudflare が​必要な​ CNAME を​ DNS に​自動挿入し、​Universal SSL 証明書を​発行する。

5.5 GitHub Pages からの​リダイレクト

30 日以上の​並行運用を​推奨する。​GitHub Pages 側に​ niki-nakamura.github.io/til/ から​ nikinakamura.com への​ 301 リダイレクト​（301 ＝ 恒久的な​転送を​表す HTTP ステータス）を​設定する。

ただし、GitHub Pages は​本物の​ 301 ステータスを​返せない（純粋な​静的配信であり、​HTTP ヘッダを​動的に​出力できないため）。​代替は​ 2 つある。

  1. jekyll-redirect-from プラグイン（Pages の​許可リストに​載っている）が、​各ページに​リダイレクトページを​生成する。​生成される​ HTML は​ <meta http-equiv="refresh">（＝HTML の​タグで​自動転送する​方​法）と​ window.location.replace() を​併用する。​Google の​ John Mueller​（ジョン・ミューラー ＝ Google の​検索担当者）は、​これが​ SEO 上 301 と​同等に​扱われると​公式に​述べているが、​本物の​ 301 より​効力は​弱い
  2. トップの​ index.html だけを​手書きする方​法：meta refresh ＋ canonical link rel​（＝正規 URL を​検索エンジンに​伝える​タグ）​＋ JS リダイレクトを​組み合わせる

実務上は、​1 の​方法で​済ませるのが​現実的な​選択である。

5.6 SEO の​引き継ぎ

  • Google Search Console​（＝Google の​検索結果での​状況を​確認・管理する​ツール）で​新しい​プロパティ https://nikinakamura.com/ を​追加し、​所有権を​確認する​（Cloudflare DNS なら​ TXT レコード 1 本で​済む）
  • 新サイトの​ sitemap.xml​（＝サイト内 URL の​一覧ファイル）を​送信する
  • 旧プロパティ niki-nakamura.github.io/til/ は残す。​リダイレクトが​どう​認識され、​リンクが​どう​引き継がれるかを​確認する​ために​必要である
  • アドレス変更ツール​（Change of Address）は​使えない。​これは​「ドメイン全体の​移行」を​対象と​しており、example.github.io/til/ のような​サブパスからの​移行は​カバーしない​（https://support.google.com/webmasters/answer/9370220）
  • 結局の​ところ meta refresh / JS リダイレクト ＋ 新サイトの​送信 ＋ 旧サイトの​維持に​帰着し、​自然な​入れ替わりまで​ 3〜6 か​月​待つことに​なる

5.7 GA4 / 計測

GA4​（Google Analytics 4 ＝ アクセス解析ツール）は​測定 ID​（G-XXXXXXXXXX）で​動く​ため、​タグ自体は​そのまま​機能し続ける。​やる​ことは​次の​とおり。

  • GA4 プロパティの​ウェブストリーム URL を​ nikinakamura.com に​書き換える
  • 旧 URL からの​トラフィックも​同じ​プロパティに​流れ込み続ける​ため、​移行期間の​比較が​しやすい
  • 自己リダイレクト経由の​セッションが​分断されないよう、​参照元除外リスト​（Referrer exclusion list）に​ nikinakamura.github.io を​追加する

5.8 DNS の​落とし穴​（重要）

ネームサーバーを​ Cloudflare に​切り替えた​瞬間、​既存の​ DNS レコードは​ Cloudflare 側に​登録した​内容で完全に​置き換わる。​具体的には​：

  • MX レコード（メール）を​引き継ぎ忘れると、*@nikinakamura.com が​即座に​死ぬ
  • TXT​（SPF / DKIM / DMARC）や​ CAA も​同様に​消える​ことがある
  • Cloudflare の​サイト追加時に​スキャンされる​候補は​完全ではないため、dig で​ 1 レコードずつ​確認した​ほうが​よい

nikinakamura.com で​メールを​運用している​場合は、​切り​替え前に​次を​確認する​こと：

dig MX nikinakamura.com +short
dig TXT nikinakamura.com +short
dig CAA nikinakamura.com +short

これらを​先に​ Cloudflare DNS へ​手で​入力してから、​ネームサーバーを​切り​替える。

6. 結論​ — いま移行すべきか

正直に​言えば、現時点​（記事 13 本、​月間ページビューは​おそらく​数百程度）では​ Cloudflare Pages の​恩恵は​過剰である。​GitHub Pages の​ 100 GB / 月や​サイズ上限 1 GB に​当たるのは​当分先であり、​Jekyll の​プラグイン許可リストの​中で​困ってもいない。

推奨はハイブリッド構成である。

  1. まずドメインだけを​ Cloudflare DNS に​載せる：ネームサーバーを​ Cloudflare に​切り​替え、​DNS / WAF / DDoS 防御の​恩恵だけを​享受する
  2. ホスティングは​ GitHub Pages のまま​維持する：nikinakamura.com を​ GitHub Pages の​カスタムドメインと​して​設定する​（apex は​ GitHub の​ 4 つの​ A レコード、www は​ CNAME）
  3. Cloudflare 側で​ DNS only​（灰色の​雲）か​ Proxied​（オレンジ色の​雲）かを​選ぶ：Proxied に​すると​ Cloudflare の​ CDN を​経由し、​GitHub Pages の​オリジン帯域の​消費が​減ると​いう​副次的効果が​ある

これで​「nikinakamura.com で​自分の​サイトが​見える」が​最小コストで​実現する。

Cloudflare Pages への​完全移行は、​次の​いずれかが​生じた​ときに​検討する。

  1. コンテンツが​商業的に​重要に​なり、​エッジ最適化や​ A/B テスト​（＝2 つの​案を​出し分けて​成果を​比べる​検証）が​必要に​なった​とき
  2. メールアドレスの​収集、​リダイレクトの​ロジック、​認証、​エッジ側での​レンダリングの​ために​ Workers が​必要に​なった​とき
  3. GitHub Pages の​プラグイン許可リストや​ 10 分の​ビルド上限に​当たり、​ローカルビルドや​ Actions への​恒常的な​逃げ道が​煩わしくなった​とき

「無料の​罠」とは、必要に​なる​前に、​無料同士の​差別化要素​（帯域無制限、​Workers 統合）を​つか​むために​移行コストを​払う​ことである。​記事 13 本の​個人 TIL に​とって、​「Cloudflare の​ほうが​速い」は、​計測できる​差よりも​移行と​学習の​コストの​ほうが​高く​つく。

2026-05-18

参考文献

関連ノート

148 notestil