個人開発者のサイトを Cloudflare Pages で公開する手順
サイトをひととおり作り終えた個人開発者が、次にぶつかるのが「これ、どこに置いて公開するんだろう」です。レンタルサーバー、VPS、Vercel、Netlify、Cloudflare Pages、GitHub Pages、S3 + CloudFront ── 選択肢が並びすぎて、最初に手を動かす場所を決められないまま 1 週間が過ぎる、ということが起こります。
本記事では、その選択肢のうち Cloudflare Pages を選んだ場合の、最初の公開までを順に整理します。無料枠だけで個人サイトはほぼ何でも回り、git push だけで本番に反映され、世界中の CDN から配信される ── 静的サイトの公開先としては、個人開発者にとって最有力候補のひとつです。
このサイト（novelarena.jp）自体も Astro 5 静的 + Cloudflare Pages（Git 連携）+ Node 22 で運用しているので、画面構成・つまずきポイント・実体験はすべて一次情報として書いています。
なぜ Cloudflare Pages なのか
最初に、向き・不向きをはっきりさせます。
- 静的サイトに強い（Astro・Vite・Next.js の静的出力・Hugo・Jekyll など）。サーバー処理は別仕組み（Cloudflare Workers / Pages Functions）で足せます。
- 無料枠だけで個人サイトは完結する：500 ビルド/月、無制限のリクエスト、無制限の帯域、無制限のサイト数。
git pushでデプロイ：GitHub と連携しておけば、mainへの push が自動でビルドされて本番反映。手動のwrangler pages deployは不要（緊急時の保険として残せます）。- 世界中の CDN から配信される：Cloudflare のエッジネットワーク上に乗ります。日本からの体感も速い。
- 独自ドメインと SSL が無料・自動：Cloudflare 上のゾーンなら、ボタン 1 つで割り当て＋証明書発行。
逆に、向いていないのは「フルマネージドの DB を同居させたい」「特定リージョンで動かしたい」など。これらは Cloudflare Workers で最小の API を公開する手順 や、Workers と組み合わせる D1 / R2 / Hyperdrive など、別仕組みになります。
前提：手元に動く静的サイトがあること
ローカルで以下が成立している前提です。
- GitHub にプライベート / パブリックのリポジトリがある
- ローカルで
npm run build（または同等の出力コマンド）が成功する - 出力先ディレクトリ（Astro なら
dist/、Next.js 静的ならout/等）が分かる .nvmrcなどで Node のバージョンが固定されている
Git そのものが不安なら、先に 個人開発者が最初に覚える Git の基本コマンド を読んでおくと、この記事の前半が楽になります。
手順 1：Cloudflare Pages プロジェクトを作る
ブラウザで Cloudflare の管理画面（dash.cloudflare.com）にログインし、左メニューから 「Workers & Pages」 へ。
- 「Create application」→「Pages」→「Connect to Git」
- GitHub アカウントを連携（初回は GitHub 側で「Cloudflare Pages」アプリのインストール承認が要る）
- 公開したいリポジトリを選択
- プロジェクト名を決める（後で URL に出る
<project>.pages.devの<project>部分） - 本番ブランチを選ぶ（既定
main）
ここまでで、Cloudflare 側に「このリポジトリの main を見るプロジェクト」ができました。
手順 2：ビルド設定を整える
同じ画面の Build settings で、何を実行して何を配信するかを指定します。
| 項目 | 値（Astro の場合） |
|---|---|
| Framework preset | Astro（自動検出されることが多い） |
| Build command | npm run build |
| Build output directory | dist |
| Root directory | /（モノレポでなければそのまま） |
Node のバージョンは、画面の Environment variables で NODE_VERSION=22 を設定するか、リポジトリ直下に .nvmrc（中身は 22 の 1 行）を置いておくと固定されます。ローカルと CF のビルド側で Node が違うと、依存関係の解決が壊れることがあるので、最初に固定するのが安全です。
設定を保存すると、最初のビルドが走ります。Deployments タブから進行ログが見られます。
手順 3：初回デプロイを確認する
ビルドが緑になると、プレビュー URL（<project>.pages.dev）が払い出されます。
- 静的ページが期待どおり出ているか
- アセット（CSS / 画像）のパスが壊れていないか
- 404 にしたいパスが正しく 404 になっているか
このサブドメインは そのまま運用 URL としても使える（独自ドメインを当てない場合）。ここで動かないものは、独自ドメインを当てても直りません。先にここで完結させます。
手順 4：独自ドメインを当てる
プロジェクト画面の Custom domains から Add a domain で、独自ドメイン（例：novelarena.jp）を入力します。
- そのドメインの DNS ゾーンが Cloudflare にある場合（よくあるケース）：レコードは自動で書かれます。本人は確認するだけ。
- DNS が外（お名前.com / Route 53 等）にある場合：表示される CNAME 値を、外側の DNS に手で追加します。
ドメインを足すと、SSL 証明書（Let’s Encrypt / Google Trust Services）も自動で発行されます。発行完了まで数分〜数十分の幅があります。証明書が出る前に HTTPS で開いて「保護されていません」と出ても、慌てない。少し待ってから再度開きます。
apex ドメイン（novelarena.jp）と www サブドメイン（www.novelarena.jp）を両方当てたい場合は、それぞれ Add a domain で個別に追加するか、片方からもう片方へリダイレクトする設定にします（運用上どちらか一方を正にし、もう片方を 301 で寄せるのが楽です）。
手順 5：以後の運用
ここから先は、git push origin main だけ で本番が更新されます。
- ローカルで編集 →
git add -A && git commit -m "..." && git push origin main - Cloudflare が自動でビルド → 緑になったらエッジへ配信
- 失敗したら Deployments タブに赤い進行ログ。原因（依存解決・Node バージョン・型エラー等）はそこで読みます
ロールバックは強力です。Deployments タブの過去デプロイの 「⋯」メニュー → Rollback to this deployment で、ボタン 1 つで戻せます。本番で何かが壊れたら、まず戻して落ち着くのが定石。原因究明は、戻したあと別ブランチで進めます。
プレビュー URL は、main 以外のブランチに push すると自動で発行されます。デザインや構成の試行は feature/xxx などに切って push、URL を共有して確認、問題なければ main にマージ ── という流れが、何の追加設定もなしで成立します。
環境変数（必要なら）
ビルド時に参照したい値や、サーバーレスの Pages Functions / Workers で使いたい値は、Settings → Environment variables に登録します。
- Production と Preview で別に持てる（本番だけ API キーを変える、など）
- ビルド時に必要なら
NODE_VERSIONやPUBLIC_*系をここに置く - 秘密は値を Encrypt にする（ダッシュ画面で 2 度目以降の閲覧ができなくなる代わりに、ログ等への露出を抑える）
API キーは Git に置かない。.env をリポジトリにコミットすると、後から .gitignore に足しても履歴に残り続けます ── このあたりの落とし穴は Git の基本コマンド の 4 節にまとめています。
挫折ポイント
ここで多くの個人開発者が止まるので、先に書いておきます。
- Node のバージョン差でビルドが落ちる：ローカルが 22、CF 側が既定の 18 だと、新しい依存が解決できない。
.nvmrcを置くか、Environment variables にNODE_VERSION=22を入れる。 - 「フレームワークが検出できません」と言われる：
package.jsonのscripts.buildを確認し、Build command をnpm run buildに手で入れる。Build output directory もdist/out等を手で指定します。 - 独自ドメインを当てた直後に SSL エラーが出る：証明書発行待ち。数分〜数十分。再読み込みで様子を見ます。
- DNS の伝播待ち：外の DNS でレコードを足したら、反映に時間がかかります。
digやnslookup、もしくは「DNS Checker」系のサイトで世界中の伝播を見ながら待ちます。 .pages.devプレビュー URL がインデックスされる：プレビューも検索結果に出る場合があります。SEO 的に主は本番ドメインにしたいので、<meta name="robots" content="noindex">を<project>.pages.dev配信時だけ出す、_headersでX-Robots-Tag: noindexを付ける、などで対処します（Cloudflare 側にはサブドメイン丸ごと noindex のチェックボックスもあります）。- キャッシュで古いものが出続ける：エッジに乗ったあとは、ブラウザのスーパーリロード（
Cmd+Shift+R）か、Cloudflare ダッシュの Caching → Purge Cache で強制更新します。 wrangler pages deployと Git 連携の混在：手動でwrangler pages deployをしたあとにgit pushで別経路の自動デプロイが入ると、どちらが本番か分からなくなります。通常運用は Git 連携 1 本にして、wranglerは緊急時の保険にする のがおすすめです。
まとめ
最小構成で振り返ると、Cloudflare Pages で個人サイトを公開するのに必要なのは、次の 4 つだけです。
- GitHub に push 可能な静的サイト（
npm run buildでdist/等が出る） - Cloudflare Pages プロジェクトに Git 連携を設定
- Build command と Output directory（と
.nvmrc）を指定 - Custom domains で独自ドメインと SSL を当てる
ここまで通れば、以後は git push だけが「公開」の操作になります。ロールバックはボタン 1 つ。プレビュー URL はブランチごとに自動。サーバー管理はゼロ。個人開発の規模であれば、これより手軽な公開先は、いま現在ほぼ存在しません。
公開した直後にやることは 2 つだけ。動いている URL を友達 1 人に送る（一次情報の最初の読者）。そして、アクセス解析を入れる。
サイトを公開し終えた次の一歩としては、最初に追う数字を整理した 個人開発者が GA4 で最初に見る 3 つの数字 が参考になります。サイトに「サーバー側で動かしたい処理」（フォーム送信の中継、Webhook 受け、API キーを隠した外部 API 中継など）を足したくなったら、Cloudflare Workers で最小の API を公開する手順 が同じ Cloudflare 上での次の一歩になります。xxxx.pages.dev の仮ドメインを卒業して自分のドメインで配信したくなったら、Cloudflare に独自ドメインを設定する で SSL まで自動で付く手順をたどれます。そして、解析を開くたびに「数字は動いているのに、登録は伸びない」と感じるなら ── それは公開先の問題ではなく、トップページのコピーの問題です。その構造を掘った 個人開発者のサービスが「素通り」される、たったひとつの構造的な理由 を、続けてどうぞ。
サイトを公開してアクセス解析を入れたあと、読まれない / 登録に至らない の構造を WHY → HOW の順で 1 冊にまとめたのが、下記の本です。個人開発者・インディー Web 作者・動画作者向けに、LP・短文・メールの戦場別の書き方と、Claude を相棒にしたプロンプト連鎖の実演を含めて統合しています。