シリーズ③Cloudflare® Pagesの始め方｜独自ドメイン接続・無料SSL・自動デプロイを非エンジニア解説

結論：Cloudflare Pagesは、「GitHubにコードを置く → 自動でビルド・公開 → 独自ドメインと無料のSSLを接続」という流れを、無料プランで完結できる公開サービスです。商用のサイトでも追加料金は不要で、会社のサイトやメディアサイトにそのまま使えます。

株式会社curveも、運営するAI情報メディア「AIテックベース」を、WordPress＋レンタルサーバーの検討からCloudflare Pagesでの運用に切り替え、非エンジニアのWeb担当者がClaude Code（AIコーディング支援）と一緒に運用できる体制を作りました。この記事では、実際の手順と、途中でつまずいた点、運用して分かった注意点をあわせて紹介します。

1. Cloudflare Pagesとは何か

Cloudflare Pagesは、Cloudflare社が提供する、静的なサイト向けの公開サービスです。世界中に分散した配信網（CDN）からサイトを届けるため、表示が速いのが特長です。

従来のレンタルサーバーのように「サーバーにファイルをアップロードする」のではなく、「GitHubのコードを見て、Cloudflareが自動でビルド・公開する」という考え方で動きます。人の手作業によるアップロードのミスがなくなります。

2. 始め方の全体像（4ステップ）

1. サイトのコードをGitHubのリポジトリに置く
2. Cloudflare PagesとGitHubを連携し、ビルドの設定をする
3. 独自ドメインを接続する
4. 無料のSSLと、wwwあり・なしの転送を設定する

3. ステップ1・2：GitHubにコードを置き、連携する

まず、サイトのコードをGitHubのリポジトリ（コードの保管場所）に保存します。会社のサイトなら、外から中身が見えない「プライベートリポジトリ」を選ぶのが安全です。AIテックベースでは、表側をAstro（静的なサイトを作るツール）、記事の管理をmicroCMS（日本製のヘッドレスCMS）にして、コードをプライベートリポジトリで管理しています。

次に、Cloudflareの管理画面の「Workers & Pages」から、Pagesのプロジェクトを作り、GitHubと連携して対象のリポジトリを選びます。ビルドのコマンド（Astroなら「npm run build」）と、出来上がったファイルの置き場所（Astroなら「dist」）を設定すれば準備完了です。以後は、GitHubに変更を送るたびに、Cloudflareが自動でビルドし直して公開します。

連携の際、GitHubの画面でCloudflareのアプリにどのリポジトリを見せるかを選べます。公式ドキュメントでも勧められているとおり、「すべてのリポジトリ」ではなく、Pagesで使うリポジトリだけに絞っておくと安全です。また、GitHubで変更の提案（プルリクエスト）を作るたびに、確認用のURLが自動で発行されます。社内の確認や取引先への事前の共有に使えます。

注意したいのは、プロジェクトの作り方です。Pagesには、GitHubと連携する方法のほかに、出来上がったファイルを画面からアップロードする方法（Direct Upload）もあります。ただし、アップロードの方法で作ったプロジェクトは、後からGitHubとの連携に切り替えられません。自動で公開したいなら、最初からGitHubと連携する方法で作りましょう。

記事の管理にCMSを使う場合、CMSのAPIキーのような秘密の情報は、コードに書き込まず、Cloudflareの管理画面の「環境変数」に登録して、ビルドのときに読み込ませます。こうすれば、GitHubに秘密の情報が残りません。

4. ステップ3：独自ドメインを接続する

独自ドメインの接続方法は、ドメインの種類で変わります。

サブドメインをCNAMEでつなぐ場合は、先にPagesの管理画面で独自ドメインを追加し、その後でCNAMEを設定します。順番が逆だと、ページが表示されません（522というエラーになります）。CNAMEの向け先は、プロジェクトに割り当てられた「〇〇.pages.dev」のアドレスです。

ネームサーバーとは、「このドメインはどこを見ればいいか」を案内する住所案内係です。Cloudflareにドメインを追加すると、専用のネームサーバーが2つ示されるので、ドメインを買った会社（お名前.com、さくら、ムームードメインなど）の管理画面で書き換えます。反映には、通常数十分から最大24時間ほどかかります（確認に使うツールによっては、さらに遅れて見えることもあります）。そのうえで、Pagesのプロジェクトの設定画面から、独自ドメインを追加します。

注意したいのは、会社のメールアドレスが同じドメインを使っている場合です。ネームサーバーを移すと、メールの配送先を示す設定（MXレコード）なども、Cloudflare側で引き継ぐ必要があります。Cloudflareは既存の設定を自動で読み込もうとしますが、公式ドキュメントでも、すべての設定を見つけられるとは限らないと注意されています。漏れがあるとメールが届かなくなります。切り替えの前に、今の設定を必ず一覧で控え、Cloudflare側と見比べてから切り替えましょう。

5. ステップ4：無料のSSLと、wwwの転送

Cloudflareにドメインを接続すると、無料のSSL（https化）が自動で有効になります。証明書の購入も、期限切れの心配も不要です。

また、「www.example.com」と「example.com」のように、同じ内容が2つのURLで見られる状態は、検索エンジンから見ると重複になります。Cloudflareの「一括リダイレクト（Bulk Redirects）」などで、「www.example.com → example.com」へ恒久的な転送（301）を設定し、どちらか一方にそろえましょう。転送元のwww用のDNSの設定（プロキシを有効にしたもの）も必要です。公式の手順では、「www」という名前のAレコードを、例示用のアドレス「192.0.2.1」で作り、プロキシを有効にします。実際のサーバーは要らず、Cloudflareが転送を受け持つためです。転送の設定では、URLの後ろの部分（パス）や「?」以降を引き継ぐ項目も有効にしておくと、古いページへのリンクも正しい行き先に届きます。

6. 商用でも無料プランで使える理由と、上限

Cloudflare Pagesは、商用のサイトでも無料プランで運用できます。独自ドメイン、SSL、自動公開、配信網がすべて無料プランに含まれており、静的なファイルの配信には通信量の上限もありません。AIテックベースも、無料プランの範囲で運用しています。

ただし、無料プランにも上限はあります。

• ビルドは月500回まで：記事の公開や更新、サイトの改修のたびにビルドが走る。一度に大量の記事を直す日は回数を意識する
• 同時に動くビルドは1つまで：続けて変更を送ると、順番待ちになる
• サーバー側の処理は1日10万回まで（Workersと合算）：問い合わせフォームなどでサーバー側の処理を使う場合の上限
• ビルドは20分で打ち切り：20分を超えるビルドは止まる。記事数が非常に多いサイトでは、ビルドにかかる時間も見ておく
• ファイル数は2万個まで、1ファイル25MiBまで：大きな動画や資料は、サイトとは別の保存場所に置く

通常の会社のサイトやメディアなら、これらを超えることはまれです。

7. なぜレンタルサーバーから切り替えたのか

もともと、さくらのレンタルサーバー（スタンダード）でFTPを使って運用していました。GitHub Actionsから自動でFTPアップロードを試みたところ、ログインは通るのに、ファイルの転送だけがすべて失敗しました。

原因は、さくらの「国外IPアドレスフィルタ」でした。初期設定で有効になっている機能で、海外からのFTPやSSHなどの接続を制限します。GitHub Actionsは海外のサーバーで動くため、ここで止められていたのです。このフィルタは、普通のページの閲覧は止めません。

Cloudflare Pagesに移したことで、レンタルサーバーへ海外から接続する必要そのものがなくなり、フィルタを有効のまま（安全性を保ったまま）自動で公開できるようになりました。さらに静的なサイトは、攻撃の的になりやすい管理画面やプラグイン、データベースを公開の側に持たないため、守る範囲が小さくなります。記事の公開も、microCMSのWebhookとCloudflareのデプロイフックをつなぎ、CMSで公開するだけで1分ほどで反映される仕組みにしています。

デプロイフックは、決まったURLに合図を送るとビルドが始まる仕組みです。公式ドキュメントでは、このURLは追加の認証なしで使えるため、パスワードと同じように秘密に扱うよう案内されています。URLを知っている人なら誰でもビルドを始められるので、社外の人と共有しない、漏れた疑いがあれば削除して作り直す、という扱いにしておきましょう。

8. つまずきやすいポイントと、これから始めるなら

• ビルドは成功したのに画面が真っ白：ビルドのコマンドや、出来上がったファイルの置き場所の指定の誤りが多い。使っているフレームワークの公式の説明で正しい値を確認する
• ビルドが失敗した：管理画面のデプロイの一覧からビルドの記録（ログ）を開き、どの工程で止まったかを確認する。失敗しても、直前に成功した版が表示され続けるので、慌てなくてよい
• メールが届かなくなった：ネームサーバーを移した際のMXレコードの引き継ぎ漏れを疑う

なお、Cloudflareは2025年4月から、これから新しく作るサイトはPagesではなく「Workers」で始めるよう勧めています。Workersでも、静的なサイトの配信、GitHubとの連携、独自ドメイン、デプロイフックが使えます。既存のPagesのサイトはそのまま使え、移行の期限もありません。ただし、Workersは、ネームサーバーをCloudflareで管理していないドメインには対応していないため、「ネームサーバーは今の会社のまま、サブドメインだけCNAMEでつなぐ」という方法はPagesならではです。新しく始めるなら、制作会社とWorkersも含めて相談するとよいでしょう。考え方や手順の流れは、ほぼ同じです。

すでにレンタルサーバーで問題なく運用できているなら、無理に移る必要はありません。「表示が遅い」「プラグインの更新が負担」「担当者が変わるたびに引き継ぎで苦労する」といった悩みがあるなら、静的なサイトへの移行を検討する価値があります。一方で、会員機能や複雑な予約の仕組みなど、サーバー側の処理が多いサイトには向かない場合もあります。

9. まとめ

• Cloudflare Pagesは、GitHubと連携して自動で公開できる、静的なサイト向けの公開サービス。商用でも無料プランで使える
• ドメインそのものをつなぐならネームサーバーをCloudflareへ。サブドメインならCNAMEでもつなげる
• ネームサーバーを移す前に、メールの設定（MXレコード）を必ず控えて引き継ぐ
• SSLは自動。wwwあり・なしは転送でそろえる。CMSのAPIキーは環境変数へ
• 無料プランのビルドは月500回まで。新しく始めるならWorkersも選択肢に入れる

参考資料

• Cloudflare：Pages（公式ドキュメント・英語）
• Cloudflare：GitHub integration（GitHub連携・英語）
• Cloudflare：Direct Upload（英語）
• Cloudflare：Deploy an Astro site（Astroのビルド設定・英語）
• Cloudflare：Custom domains（独自ドメイン・英語）
• Cloudflare：Full setup（ネームサーバーの変更・英語）
• Cloudflare：Redirecting www to domain apex（wwwの転送・英語）
• Cloudflare：Pages Limits（無料プランの上限・英語）
• Cloudflare：Workers Pricing（Pages Functionsの料金・英語）
• Cloudflare：Deploy Hooks（英語）
• Cloudflare：Migrate from Pages to Workers（移行ガイド・英語）