GitHub PagesからCloudflare Pagesに移行する方法【デプロイ方法そのまま】

概要

今回はブログのホスティングをGitHub PagesからCloudflare Pagesに移行する方法を紹介します。

しかも基本的には現在のリリース方法と同じで大丈夫な方法になります!

Cloudflare Pagesは無料プランでも帯域幅が無制限、グローバルCDN配信、自動SSL、DDoS保護が使えるので、GitHub Pagesからの移行先としてかなり優秀です。

同じように移行を検討している方の参考になれば嬉しいです。
それではやっていきましょう!

目次

なぜCloudflare Pagesに移行するのか?

GitHub Pagesも無料で使える優秀なサービスですが、Cloudflare Pagesには以下のような優位性があります。

  • パフォーマンス
    • 世界330箇所以上のデータセンターからCDN配信(GitHub Pagesは単一リージョン)
    • HTTP/3・QUICに対応しており、表示速度が高速
    • インターネット接続人口の約95%が50ms以内にアクセス可能
  • 無料プランの充実度
    • 帯域幅が無制限(GitHub Pagesは月100GBまで)
    • 月500ビルドまで無料
    • カスタムドメイン100個まで設定可能
    • 商用利用も初日からOK
  • セキュリティ
    • SSL証明書の自動プロビジョニング
    • DDoS保護が標準搭載
    • WAFやセキュリティルールとの統合が容易
  • 機能面
    • プレビューデプロイ(ブランチごとに一時URLが自動生成される)
    • ビルトイン分析機能
    • セキュリティヘッダーのカスタマイズ(_headersファイル)

特に帯域幅の無制限は大きいです。
GitHub Pagesの月100GB制限は、画像の多いブログだと意外とすぐ到達する可能性があります。

GitHub Pages vs Cloudflare Pages 比較表

項目 GitHub Pages Cloudflare Pages
帯域幅 月100GB 無制限
CDN拠点 単一リージョン 330箇所以上
HTTP/3 非対応 対応
ビルド回数 制限あり 月500回(無料)
カスタムドメイン 1つ 100個まで
プレビューデプロイ なし 自動生成
DDoS保護 なし 標準搭載
分析機能 なし ビルトイン
ヘッダーカスタマイズ 不可 _headersで可能
料金 無料 無料

前提環境

今回の移行で前提となる環境は以下のとおりです。

  • デプロイ方法
    • GitHubリポジトリにpush
  • 移行元
    • GitHub Pages
  • 移行先
    • Cloudflare Pages
  • ドメイン管理
    • お名前.com(ネームサーバはCloudflareに設定済み)
  • DNS管理
    • Cloudflare(セキュリティルール等で既に使用中)

<移行前のデプロイフロー>
GitHubリポジトリにpush → GitHub Pagesが配信

<移行後のデプロイフロー>
GitHubリポジトリにpush → Cloudflare Pagesが自動検知して配信

つまり、デプロイ方法は変わらず同じGitHubリポジトリにpushするだけ。
配信する側だけがCloudflare Pagesに替わるイメージです。

移行手順

ステップ1:_headers ファイルを作成する

Cloudflare Pagesでは、セキュリティヘッダーやキャッシュ設定を _headers ファイルで制御できます。

サイトのルートディレクトリに _headers ファイルを作成します。GitHubリポジトリにpushされるファイル群のルートに配置してください。

ファイル:_headers

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/*
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

/css/*
Cache-Control: public, max-age=31536000, immutable

/js/*
Cache-Control: public, max-age=31536000, immutable

/images/*
Cache-Control: public, max-age=2592000

全ページにセキュリティヘッダーが付与され、CSS・JS・画像には長期キャッシュが設定されます。

ステップ2:wrangler設定ファイルを作成する

ここが最大のハマりポイントです。(自分は沼りました)

Cloudflare Pagesの新しいデプロイ方式はWrangler(Workers)ベースで動作します。
リポジトリをクローンした後 npx wrangler deploy が実行されるのですが、デフォルトではリポジトリの .git ディレクトリもアセットとしてアップロードしようとします。

そして.git 内のpackファイルが25MBを超えるとこのようにエラーになります。

ビルド失敗:.gitのpackファイルが25MB制限を超えてエラー
Cloudflare Pagesビルド失敗画面 Asset too largeエラー

解決策として、wrangler.jsonc をソースに含めて、アセットディレクトリを分離します。

ファイル:wrangler.jsonc(リポジトリのルートに配置)

1
2
3
4
5
6
7
{
"name": "your-project-name",
"compatibility_date": "2026-04-14",
"assets": {
"directory": "./_site"
}
}

assets.directory./_site に設定することで、wranglerは .git を含むリポジトリルートではなく、_site ディレクトリだけをアセットとして扱います。

後のステップで、Cloudflare Pagesのビルドコマンドで静的ファイルだけを _site/ に移動する設定を行います。

ステップ3:Cloudflare Pagesプロジェクトを作成する

Cloudflareダッシュボードでプロジェクトを作成します。

「Workers & Pages」→「アプリケーションを作成する」を選択します。

Workers & Pages の初期画面
Cloudflare Workers & Pages ダッシュボード初期画面

「Continue with GitHub」を選択してGitHubと連携します。

GitHubを選択してリポジトリを接続
Cloudflare Pages メソッド選択画面 Continue with GitHub

リポジトリを選択し、プロジェクトの設定を行います。

ビルドコマンドは空欄のまま、デプロイコマンドは npx wrangler deploy のままにしておきます。

リポジトリ選択とプロジェクト設定(プロジェクト名・ビルドコマンド・デプロイコマンド)
Cloudflare Pages プロジェクト設定画面 リポジトリ選択・ビルドコマンド設定

下にスクロールすると、パスやAPIトークン、環境変数の設定があります。
今回は特に設定不要なので、そのまま「デプロイ」を押してOKです。

パス・APIトークン・環境変数の設定(今回はデフォルトでOK)
Cloudflare Pages プロジェクト設定画面 パス・APIトークン設定

ステップ4:ビルドコマンドを設定する

初回デプロイはステップ2で説明した .git のエラーで失敗します。

ここで、プロジェクトの「設定」→「ビルド構成」からビルドコマンドを設定します。

以下のコマンドを設定してください。

1
mkdir _site && find . -maxdepth 1 ! -name . ! -name .git ! -name _site ! -name node_modules ! -name wrangler.jsonc -exec mv {} _site/ \;
ビルド構成にビルドコマンドを設定した状態
Cloudflare Pages ビルド構成画面 ビルドコマンド設定

このコマンドは .gitwrangler.jsonc 以外の全ファイルを _site/ に移動します。これにより、wranglerは _site/ だけをアセットとしてデプロイし、巨大な .git ディレクトリを回避できます。

設定後、「新しいデプロイ」から再デプロイすれば成功するはずです。

デプロイ成功後、設定画面でドメインやルートが確認できるようになります。

デプロイ成功後のプロジェクト設定画面(ドメインとルート)
Cloudflare Pages プロジェクト設定画面 ドメインとルート確認

ステップ5:カスタムドメインを設定する

*.workers.dev のURLでサイトが正常に表示されることを確認したら、カスタムドメインを設定します。

まず、既存のGitHub Pages向けDNSレコードを削除する必要があります。

移行前のDNS設定はこのようにGitHub PagesのAレコード(185.199.xxx.xxx)が並んでいます。

移行前のDNSレコード(GitHub Pages向けAレコード4つ)
Cloudflare DNSレコード画面 GitHub Pages向けAレコード

GitHub Pages向けのAレコード(185.199.xxx.xxx 系)を4つとも削除します。

Aレコードを削除した後のDNS設定
Cloudflare DNSレコード画面 Aレコード削除後

Aレコードを削除したら、プロジェクトの「設定」→「ドメインとルート」→「追加」からカスタムドメインを追加します。

Cloudflareが自動でDNSレコードを追加し、HTTPS用の証明書を発行してくれます。

カスタムドメインの追加確認画面
Cloudflare Pages カスタムドメイン追加画面 DNSレコード追加の確認

追加後、サイトにアクセスして正常に表示されることを確認します。

カスタムドメインでサイトが正常に表示されていることを確認
shinpinoshi blog トップページ表示確認

DNS設定も確認しておきましょう。WorkerタイプのレコードでCloudflare Pagesに接続されていればOKです。

カスタムドメイン追加後のDNSレコード
Cloudflare DNSレコード画面 Worker レコード追加後

ステップ6:GitHub Pagesを無効化する

Cloudflare Pagesでの動作確認が完了してから実施してください。先にGitHub Pagesを無効化すると、切り替え完了までの間サイトにアクセスできなくなります。

GitHubリポジトリの「Settings」→「Pages」を開きます。

GitHub Pages設定画面(無効化前)
GitHub Pages設定画面 無効化前の状態

Sourceを「None」に変更し、カスタムドメインの設定も削除します。

GitHub Pages設定画面(無効化後)
GitHub Pages設定画面 無効化後の状態

ステップ7:不要なDNSレコードを整理する

移行完了後、GitHub Pages向けの不要なレコードが残っている場合は削除しておきましょう。

  • 削除対象の例
    • GitHub Pagesの www CNAME(xxx.github.io を向いているもの)
    • GitHub Pages用のAレコード(185.199.xxx.xxx 系)

最終的なDNSレコードはこのようにスッキリした状態になります。

移行完了後の最終的なDNSレコード
Cloudflare DNSレコード画面 移行完了後の最終状態

デプロイの動作確認

移行が完了したら、実際にデプロイが正常に動作するか確認します。

普段どおりGitHubリポジトリにpushしてみましょう。

push後、Cloudflare Pagesのダッシュボードで新しいデプロイが自動的に開始されることを確認してください。

カスタムドメインもプロジェクトの設定画面から正しく紐づいていることが確認できます。

移行完了後のCloudflare Pages設定画面(カスタムドメイン設定済み)
Cloudflare Pages 設定画面 カスタムドメイン設定完了

既存のワークフローと全く同じ方法でデプロイできるので、移行後も普段の運用は何も変わりません。

移行時のハマりポイントまとめ

移行時に実際にハマったポイントをまとめておきます。

.git ディレクトリの25MB制限

最大のハマりポイントです。Cloudflare PagesのWorkerデプロイでは、アセットファイルの上限が25MBです。リポジトリの .git/objects/pack/ 内のpackファイルがこの制限を超えるとデプロイが失敗します。

本記事で紹介した wrangler.jsonc + ビルドコマンドによるアセットディレクトリ分離で解決できます。

.git を削除するとデプロイパイプラインが壊れる

ビルドコマンドで rm -rf .git とすると、wranglerのデプロイコマンド自体がエラーで動かなくなります。.git は削除せず、アセットディレクトリを分けるアプローチが正解です。

静的サイトジェネレーターで _headers が出力されない場合

Hexoなど一部の静的サイトジェネレーターは _(アンダースコア)で始まるファイルをデフォルトでスキップします。ビルドツールの設定で _headers が出力対象に含まれるよう調整してください。(例:Hexoの場合は _config.ymlinclude"_headers" を追加)

カスタムドメイン追加時のエラー

既存のGitHub Pages向けDNSレコード(Aレコード)が競合してエラーになります。先にAレコードを削除してからカスタムドメインを追加してください。

締め

こんな感じでGitHub PagesからCloudflare Pagesへの移行ができました。

一番嬉しいのは、普段のデプロイワークフロー(GitHubリポジトリへのpush)が全く変わらないことですね。中身だけ上位互換に替わった感じです。

無料で帯域幅無制限・グローバルCDN・DDoS保護が手に入るので、GitHub Pagesからの移行を検討している方にはかなりおすすめです。

以上となります。
移行したことにより安心して画像を上げられます良かった(^^!
お疲れさまでした!