【実験ログ】Cloudflare Pagesで4サイトを無料公開した手順とハマりポイント

Astro（Webサイトを作るための道具。表示が速いのが特徴）で作ったサイトを公開するとき、最初にぶつかるのが「どこに公開するか」という問題です。Vercel、Netlify、AWS Amplify、Cloudflare Pages（GitHubと連携してサイトを無料で公開できるサービス）、あるいはレンタルサーバー。選択肢はたくさんあります。

この実験ログでは、Cloudflare Pagesを使って4つのAstroサイトを完全無料で公開した全手順と、その途中で遭遇したハマりポイントを正直に記録します。結論から言うと、2サイト目以降は5分で完了するようになりました。でも初回は想像以上に罠が多かった。ここに書くことは、すべて自分が実際に踏んだ地雷です。

なぜCloudflare Pagesを選んだのか

公開先の選択肢を比べてみた

まず、主なサービスを並べて比較しました。個人が複数サイトを運用する前提で、コスト・帯域・使いやすさを重視しました。

比較してわかったのは、Vercelは帯域が100GBまでという制限があること。画像が多いメディアサイトを4つ運用すると、いつか引っかかる可能性があります。Netlifyも同じです。AWS Amplifyは設定が複雑で、個人サイトにはオーバースペック。エックスサーバーは月額がかかるうえに、Git（ファイルの変更履歴を管理する仕組み）との連携もありません。

決め手は3つありました。帯域が完全に無制限なこと、何サイト作っても完全無料なこと、そして**Cloudflareの世界規模CDN（世界中にコピーを置いて、近い場所から配信する仕組み。表示が速くなる）**が使えること。日本からアクセスしても、アメリカからアクセスしても、最寄りのサーバーからコンテンツが配信されます。静的サイトとの相性は抜群です。

もう一つ大きかったのは、Cloudflare Pagesには「そろそろ有料プランにしてね」というプレッシャーがほぼないこと。Vercelは商用利用でProプランを求めてくるし、Netlifyも無料枠を超えると課金が始まります。Cloudflare Pagesは無料枠の中で十分に使えて、「いつか課金されるかも」という不安がありません。

初回セットアップの全手順 ── 5ステップ

最初のサイト（trip-journal.net）を公開するまでの手順を、順番に書いていきます。結果的に約30分かかりましたが、そのうち半分以上はハマりポイントで消費した時間です。

Step 1: GitHubリポジトリの作成とpush

# Astroプロジェクトのフォルダで
git init
git add .
git commit -m "Initial commit"

# GitHubで新しいリポジトリを作成した後
git remote add origin https://github.com/ketyaso/trip-journal.git
git branch -M main
git push -u origin main

GitHub（Gitのデータを保存するクラウドサービス）でリポジトリを作るとき、READMEの自動生成はしないほうがいいです。ローカルですでにinitしているので、リモートとの競合が起きます。空のリポジトリを作って、ローカルからpushするのが一番スムーズです。

所要時間: 2分。

Step 2: Cloudflare Pagesに接続 ── ここが最初の落とし穴

Cloudflare Dashboardにログインして、左メニューから「Workers & Pages」を選択。「Create」ボタンを押します。

…するとWorkersの作成画面が出てきます。Pagesの画面じゃないんです。

正しい手順を整理するとこうなります。

ちなみに、Workersはサーバー上でプログラムを動かす環境で、PagesはGitHub連携でサイトを公開する仕組み。名前は似ていますが役割は全然違います。Cloudflareとしては将来的に統合したいみたいですが、今の時点ではPagesタブを意識して選ぶ必要があります。

所要時間: 3分（初回の「どこだ？」を含む）。

Step 3: ビルド設定

Pagesプロジェクトの作成画面で、フレームワークの設定をします。

Framework presetを「Astro」にすれば、Build commandとBuild output directoryは自動で入力されます。手で打つ必要はありません。

ただしNode.jsのバージョンには注意が必要です。Cloudflare Pagesの初期設定だとNodeのバージョンが古くて、Astroのビルドが謎のエラーで失敗することがあります。環境変数にNODE_VERSION=18を設定しておくと確実です。

所要時間: 1分。

Step 4: 独自ドメインの設定

ここが一番時間がかかるステップです。まずドメインを取得して、Cloudflareにドメインを追加して、ネームサーバー（「このドメインはどこのサーバーを使ってるか」を教える設定）を変更して、DNS（ドメイン名とサーバーの住所を紐づける電話帳のようなもの）反映を待って、最後にPagesプロジェクトにCustom domainを追加します。

ドメインの取得にはエックスサーバードメインを使いました。キャンペーンで.comや.netが初年度1円で取得できます。

ドメイン4つ合計で約204円。2年目以降は更新費がかかりますが、初年度はほぼ無料で始められます。

Cloudflareにドメインを追加する手順:

1. Cloudflare Dashboardの「Add a site」からドメインを入力
2. Freeプランを選択（迷わずFreeでOK）
3. Cloudflareがネームサーバーの変更を指示してくる ── 2つのアドレスが表示される
4. エックスサーバードメインの管理画面でネームサーバーを変更

ネームサーバーの変更が反映されると、Cloudflareのダッシュボードでドメインのステータスが「Active」に変わります。この状態になったら、PagesプロジェクトのCustom domainsタブから独自ドメインを追加できます。

Pages Project → Custom domains → Set up a custom domain
→ ドメイン名を入力 → Activate domain

これだけです。 DNSレコードを手動で追加する必要はありません。Pages側のCustom domains機能に任せれば、必要な設定が自動的に行われます。

所要時間: 15〜30分（DNS反映の待ち時間を含む）。

Step 5: 動作確認

https://your-domain.com にアクセスして、サイトが正常に表示されることを確認します。SSL証明書（通信を暗号化するための仕組み）も自動で発行されるので、HTTPSでのアクセスが最初から可能です。面倒なSSL設定は一切不要です。

ここまでの合計所要時間: 約30分（初回のUI迷子 + DNS反映待ちを含む）。

4つの最大のハマりポイント

4サイトを設定する過程で遭遇した問題を、影響度の大きい順にまとめます。これらを事前に知っていれば、初回でも15分で完了できたはずです。

罠1: Workers vs Pages の画面を間違える

Cloudflareの公式ドキュメントも、Workers向けとPages向けで分かれているのに、ダッシュボード上のURLは統合されています。このねじれが混乱の原因です。今後改善されるかもしれませんが、今は「Pagesタブを探す」と覚えておくしかないです。

罠2: ネームサーバーはドメインごとにバラバラ

2サイト目を設定するとき、「同じアカウントなんだから、ネームサーバーも同じだろう」と思い込んで1サイト目の値をコピペしました。結果、30分待っても有効にならず、設定を見直してようやく気づきました。かんたんに言うと、「住所を間違えてるから荷物が届かない」のと同じ状態だったということです。

罠3: DNS反映は待つしかない

最初のドメインのとき、15分待っても「Pending」が消えないので不安になり、ネームサーバーを別の値に変えたり戻したりを3回繰り返しました。結局、最初の設定で合っていたんです。ただ反映に時間がかかっていただけでした。

罠4: GitHubリポジトリの権限を追加し忘れる

セキュリティのために「全部のリポジトリを許可」ではなく「選んだものだけ許可」にするのは正しい判断ですが、新しいプロジェクトを追加するたびにこの手順が必要になります。4サイト目あたりでは体が覚えていました。

ドメイン購入: エックスサーバードメインの活用

ドメインの購入先にはエックスサーバードメインを選びました。理由はシンプルで、初年度1円キャンペーンがあるからです。

.comや.netが1円で取得でき、Whois代行（ドメインの持ち主情報を非公開にするサービス）も無料。2年目以降の更新費は.comが約1,600円/年、.netが約1,800円/年ですが、初年度はほぼ無料で複数ドメインを試せます。サイトの方向性が決まってから本格運用を判断できるので、実験段階にはぴったりです。

注意点として、取得したドメインのネームサーバーは初期状態でエックスサーバーのものが設定されています。Cloudflare Pagesを使う場合は、これをCloudflare指定のネームサーバーに変更する必要があります。エックスサーバーのレンタルサーバーを使わないのに、エックスサーバードメインでドメインだけ買う、というのは全く問題ありません。

2サイト目以降: 5分で完了するフロー

初回セットアップでCloudflareアカウント、GitHub連携、ネームサーバーの仕組みを理解していれば、2サイト目以降はびっくりするほど速いです。

初回の30分がウソのように、2サイト目以降は5分で終わります。フローが同じだからです。唯一忘れがちなのがStep 2のGitHubリポジトリ権限の追加。「なぜリポジトリが出てこないんだ」と毎回30秒ほど考えてから思い出します。

環境変数の設定: ビルド時だけ使われる

Cloudflare Pagesで環境変数（APIキーなどの秘密情報を安全に保存する場所）を設定するのは、Settings → Environment variablesから。ここで大事なのは、AstroのSSG（サイトを事前にHTMLファイルとして作っておく方式。表示が速い）では環境変数はビルド時にだけ使われるという点です。

つまり、公開後のHTMLにはAPIキー（サービスを使うための鍵のようなもの）は含まれません。ビルドサーバー上でAPIを呼び出して、その結果だけがHTMLに埋め込まれます。公開されたサイトのソースコードを見ても、APIキーは一切見えません。セキュリティ面で安心です。

環境変数は「Production」と「Preview」で分けて設定できます。普通はProductionにだけ設定すれば十分ですが、プレビュー版でもAPIを使いたい場合はPreviewにも同じ値を設定します。

Cloudflare Pagesの便利な機能

セットアップが終わって、実際に使ってみて「これは便利だな」と感じた機能を書いておきます。

Preview Deployments（プレビューデプロイ）

mainブランチ以外にpushしたり、Pull Requestを作ったりすると、自動的にプレビューURLが生成されます。abc123.project.pages.devのような一時URLで変更を確認でき、本番サイトに影響を与えずにレビューできます。

かんたんに言うと、「本番に出す前に、テスト版のURLで確認できる」ということです。CSSの変更やレイアウトの調整を確認するときに特に役立ちます。

Web Analytics

Cloudflare Dashboardから、無料でアクセス解析ができます。Google Analyticsのような追跡タグをサイトに埋め込む必要がありません。ページビュー、訪問者数、国別アクセス、どこから来たかなどが確認できます。

Google Analyticsほど詳しくはないですが、「サイトが見られているかどうか」を確認するには十分です。何より、追跡用のJavaScriptを入れなくて済むので、サイトの表示速度に影響しません。

ロールバック

過去の状態に一瞬で戻せます。ビルドが壊れたときに、前の正常なバージョンに数クリックで戻せるんです。つまり、「壊れても元に戻せる」という安心感があるので、大胆な変更にも挑戦しやすくなります。

自動HTTPS

Custom domainを設定すると、SSL証明書が自動的に発行されます。面倒な設定や更新作業は一切不要。レンタルサーバーで手動でSSL設定をした経験がある人なら、この自動化のありがたみがわかるはずです。

コスト実績 ── 4サイト x 1ヶ月

もしVercelのProプランを使っていたら月額$80（4サイト分）、年間で約$960。Cloudflare Pagesならその全額が浮きます。個人でサイトを運営する人にとって、この差は大きいです。

教訓まとめ ── 5つの学び

Cloudflare Pagesを使い始めて約1ヶ月。4サイトを運用して、一度もダウンタイムを経験していません。ビルドも安定しているし、CDNのおかげでページ表示も速い。何より「月額ゼロ」という気持ちの軽さがいいです。サイトの運営費を気にせず、コンテンツに集中できる環境。それがCloudflare Pagesの一番の価値だと感じています。