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

結論：Cloudflare PagesはGitHub連携の自動デプロイで、独自ドメイン・無料SSLも商用無料で使えます

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

なぜなら、Cloudflare Pagesは静的サイト（HTML・CSS・JavaScript）の配信に特化しており、サーバー管理やSSL証明書の更新といった「面倒な運用」を自動でやってくれるからです。実際に私たち株式会社curveも、運営するAI情報メディア「AIテックベース」を、WordPress＋レンタルサーバーからCloudflare Pagesへ運用方法を変更し、非エンジニアのWeb担当者がClaude Code（AIコーディング支援）と一緒に運用できる体制を作りました。

Cloudflare Pagesとは何か

結論として、Cloudflare PagesはCloudflare社が提供する、静的サイト向けの無料ホスティングサービスです。世界中に分散したCDN（配信網）からサイトを届けるため、表示が速いのが特長です。

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

レンタルサーバーとの主な違い

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

結論として、必要な作業は大きく4つです。順番にやれば、非エンジニアでも進められます。

• ステップ1：サイトのコードをGitHubのリポジトリに置く
• ステップ2：Cloudflare PagesとGitHubを連携し、ビルド設定をする
• ステップ3：独自ドメインを接続する（ネームサーバー変更）
• ステップ4：無料SSLとwww→非wwwの転送を設定する

ステップ1：GitHubにコードを置く

まずサイトのソースコードを、GitHubのリポジトリ（コードの保管場所）に保存します。会社のサイトであれば、外部から中身が見えない「プライベートリポジトリ」を選ぶのが安全です。

私たちの場合、フロントはAstro（静的サイトを生成するツール）、CMSはmicroCMS（日本製のヘッドレスCMS）という構成にし、ソースをGitHubのプライベートリポジトリで管理しています。

ステップ2：CloudflareとGitHubを連携して自動デプロイ

結論として、Cloudflareダッシュボードの「Workers & Pages」から「Create application」→「Pages」→「Connect to Git」と進み、GitHubアカウントと連携してリポジトリを指定するだけで連携できます。ビルドコマンド（例：Astroならnpm run build）と出力フォルダ（例：dist）を設定すれば準備完了です。

以降は、GitHubにコードを更新（プッシュ）するたびに、Cloudflareが自動でビルドし直して公開してくれます。これが「自動デプロイ」です。手作業でファイルを上げる必要は一切ありません。

ステップ3：独自ドメインを接続する（ネームサーバー変更）

結論として、独自ドメインの接続は、ネームサーバーをCloudflareに変更する方法が基本ですが、DNSを他社のままCNAMEレコードで接続する方法も用意されています。ネームサーバーとは、「このドメインはどのサーバーを見ればいいか」を案内する、いわば住所案内係です。

手順はシンプルです。

• Cloudflareにドメインを追加すると、専用のネームサーバー2つが提示される
• そのネームサーバーを、ドメインを買った会社（お名前.com、さくら、ムームードメイン等）の管理画面で設定する
• 反映には数十分から最大48時間ほどかかる場合がある

反映が完了すると、独自ドメインでサイトが表示されるようになります。

ステップ4：無料SSLとwww→非wwwの転送

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

また、www付きとwwwなしのURLを片方に統一する転送（リダイレクト）も設定できます。これはSEO上も重要で、同じ内容のページが2つのURLで存在する「重複」を避けられます。Cloudflareの「リダイレクトルール」機能で、例えば「www.example.com → example.com」へ301転送するルールを1つ作るだけです。

商用でも無料プランで問題ない理由

結論として、Cloudflare Pagesは商用サイトでも無料プランで運用できます。なぜなら、無料プランでも独自ドメイン・無料SSL・自動デプロイ・CDN配信がすべて含まれているからです。

無料プランには「1か月あたりのビルド回数」などの上限はありますが、通常の企業サイトやメディア運用で超えることはまれです。実際に私たちのメディア運用でも、無料プランの範囲で十分動いています。

実体験：なぜWordPress＋レンタルサーバーから運用方法を変更したのか

結論として、私たちはレンタルサーバーへの「海外からの自動アップロード」がどうしても通らず、Cloudflare Pagesへ切り替えました。これが結果的に、速度・安全性・運用のしやすさをすべて改善しました。

具体的には、もともとさくらのレンタルサーバー（スタンダード）でWordPressでの構築を検討しつつ、FTPで運用していました。そこでGitHub Actionsから自動でFTPアップロードを試みたところ、すべて失敗しました（lftpは「max-retries exceeded」、curlは「exit code 56」）。ログイン自体は通るのに、データ転送だけが失敗するという不可解な症状でした。

真の原因は、さくらの「国外IPアドレスフィルタ」でした。これは初期設定で有効になっており、FTP・SSH・管理画面といった「管理系の入口」だけを海外IPから遮断する機能です。GitHub Actionsは海外（既定では米国）のサーバーで動くため、ここで弾かれていたのです。なお、このフィルタはサイト閲覧（HTTP）や広告審査には影響しません。

非エンジニアとしての一番の学びは、「原因らしきものを片っ端から試す」のではなく、先に環境の仕様（対応する転送方式・正しいホスト名・セキュリティ設定）を確定し、エラーの意味を1つずつ調べて原因を特定してから直すことの大切さでした。推測でFTPホスト名を決めて失敗したこともありました。

最終的にCloudflare Pagesへ移したことで、レンタルサーバーへ海外からアクセスする必要そのものがなくなりました。結果として、国外IPフィルタを「有効」のまま（=高セキュリティのまま）自動デプロイと運用ができるようになりました。さらに静的サイトは、攻撃の的になりやすい管理画面・プラグイン・データベースを公開側に持たないため、守るべき範囲が小さくなります。WordPressも適切な設定と更新を続ければ安全に運用できますが、私たちの体制では「そもそも守る対象を減らす」構成が合っていました。

記事の自動公開もできる

結論として、Cloudflare Pagesは「デプロイフック」という仕組みを使えば、外部のきっかけで再ビルドを走らせられます。私たちはmicroCMSのWebhook（更新通知）とCloudflareのデプロイフックをつなぎ、記事を公開すると自動でサイトが再ビルドされて反映される仕組みにしています。担当者はCMSで記事を公開するだけで済みます。

まとめ

• Cloudflare Pagesは、GitHub連携で自動デプロイできる無料の静的サイトホスティング
• 独自ドメインはネームサーバーをCloudflareに変更するだけで接続できる
• 無料SSL（https化）は自動で有効になり、更新も不要
• www→非wwwの転送もリダイレクトルールで簡単に統一できる
• 商用でも無料プランで運用でき、企業サイトにも十分使える
• レンタルサーバーへの海外からの自動アップロードに悩んだら、ホスティングごとCloudflareへ移すのが有効。国外IPフィルタは有効のまま運用できる
• microCMSのWebhookとデプロイフックを組み合わせれば、記事公開→自動反映まで実現できる

このシリーズでは、WordPressを使わない判断、microCMSの使い方、さくらの国外IPフィルタ、問い合わせフォームの作り方、Webhook連携、AIとのサイト制作、移行時のSEO、作業の確認フローなど、関連トピックも順次解説しています。あわせてご覧ください。