TechQuant Blog

Cloudflare Pages で静的サイトを無料ホスティング — GitHub 連携から独自ドメインまで

6分で読める

3つのホスティングサービスを試して、最終的にCloudflare Pagesに落ち着いた。理由は単純で、無料枠の太さが段違いだったからだ。

先月、個人で開発者向けのWebツール集を公開した。JSON整形、Base64エンコーダー、QRコード生成——フレームワークは使わず素のHTML/CSS/JSで組んだ全10ページほどのサイトだ。こういう静的サイトをどこに置くかは毎回悩む。Vercel、Netlify、GitHub Pages、Cloudflare Pages。候補はだいたいこの4つに絞られる。

1ヶ月ほど Cloudflare Pages で運用してみた結果と、セットアップ手順、ハマりポイントを書いていく。

Cloudflare Pages の無料枠が強すぎる

まず数字を並べる。

サービス帯域（無料枠）ビルド上限備考
Cloudflare Pages無制限500回/月同時プロジェクト100個
Vercel100GB/月6,000分/月商用利用は有料プラン
Netlify100GB/月300分/月フォーム機能が強い
GitHub Pages100GB/月10回/時公開リポジトリ推奨

帯域無制限。ここが決め手だった。

趣味サイトがたまたまバズったときに帯域超過で課金される心配がないのは、精神衛生上かなり楽だ。Vercel や Netlify の100GBも普通は十分だが、画像の多いページだと意外と消費する。OGP画像をページごとに置いているサイトなんかは特に。

CDNもCloudflareの本業だけあって速い。日本にエッジサーバーがあるから、国内ユーザーへのレスポンスは体感でまったく問題ない。

GitHub 連携で自動デプロイする手順

セットアップは拍子抜けするほど簡単だった。

ダッシュボードから設定する場合

  1. Cloudflare ダッシュボードにログイン
  2. 左メニューの「Workers & Pages」→「Create」をクリック
  3. 「Pages」タブで「Connect to Git」を選択
  4. GitHubアカウントを連携し、対象リポジトリを選ぶ

ビルド設定は、静的サイトならほぼデフォルトでいける。

フレームワークプリセット: None
ビルドコマンド: （空欄）
ビルド出力ディレクトリ: public

自分のサイトはビルドステップが不要な純粋なHTMLだったので、ビルドコマンドは空欄にして出力ディレクトリだけ指定した。8秒でデプロイが完了。速い。

CLI（Wrangler）でデプロイする場合

GUIが苦手な人、あるいはCI/CDに組み込みたい場合はCLIの方がいい。

# Wrangler のインストール
npm install -g wrangler

# ログイン（ブラウザが開く）
wrangler login

# デプロイ
wrangler pages deploy ./public --project-name my-site

自分は以前書いたClaude Code の cron 自動実行の仕組みと組み合わせて、シェルスクリプトからデプロイしている。コンテンツ更新のたびに手動でダッシュボードを触る必要がないので楽だ。

#!/bin/bash
# deploy.sh — 静的サイトをCloudflare Pagesにデプロイ
cd ~/my-project

npx wrangler pages deploy public \
  --project-name my-site \
  --branch main \
  --commit-dirty=true

echo "デプロイ完了: $(date)"

GitHub連携を有効にしていると、pushのたびにCloudflare側でも自動ビルドが走る。CLIデプロイと二重になるが、ビルド不要の静的サイトならCLIの方が挙動をコントロールしやすいのでこっちをメインにしている。

独自ドメインの設定

デフォルトでは プロジェクト名.pages.dev というURLが割り当てられる。検証用にはこれで十分だが、SEOや見栄えを考えると独自ドメインを当てたい。

手順

  1. Cloudflareにドメインを追加し、ネームサーバーをCloudflareに向ける
  2. Pagesプロジェクトの「カスタムドメイン」タブでドメインを追加
  3. DNSレコードが自動設定される

SSL証明書も自動で発行・更新される。手動でLet's Encryptを設定する手間がないのは地味にありがたい。

ちなみに自分はドメインの取得にお名前.comを使っている。取得後にCloudflareへネームサーバーを変更するだけで、あとはCloudflare側が全部やってくれる。

一つ注意点。外部DNSのままCNAMEだけ向ける方法もあるが、Cloudflareのプロキシ（CDN最適化やWAF）をフルに使いたいならDNS管理ごと移すのが手っ取り早い。

1ヶ月運用して気づいたこと

良かった点

  • デプロイが速い——静的サイトなら5〜10秒で完了する。プレビューの確認まで含めても1分かからない
  • ブランチプレビューが自動——mainブランチ以外にpushすると、ブランチごとのプレビューURLが勝手に発行される。レビューや動作確認に使える
  • Web Analyticsが無料——PVとリファラーが見られる簡易アクセス解析。Google Analyticsほどの機能はないが、個人サイトには十分すぎる

ハマった点

  • _redirects の改行コード問題——リダイレクトルールを定義する _redirects ファイル、改行コードがCRLF（Windows形式）だとサイレントに無視される。Windowsで編集した人は要注意
  • キャッシュが強すぎる——CSSを更新してもブラウザに反映されないことがあった。ファイル名にハッシュを入れるか、ダッシュボードからキャッシュをパージする必要がある
  • Functionsの罠——Cloudflare Pages FunctionsというサーバーレスAPI機能があるが、functions/ ディレクトリに適当なJSファイルを置くと意図せずルーティングされることがある。静的サイトなら触らないのが正解

キャッシュの問題は、uv の記事で触れたようなビルドツールを使えばファイル名にハッシュを含められるので回避できる。素のHTMLサイトだとその仕組みがないので、クエリパラメータ（style.css?v=2）で対処した。ここは正直まだ試行錯誤中。

Vercel・Netlify との使い分け

3つとも実際に使ってみた上での整理。

ユースケース推奨サービス
Next.js / Nuxt のSSRアプリVercel（フレームワーク統合が強い）
フォーム・認証付きの静的サイトNetlify（Identity, Formsが便利）
純粋な静的サイトのホスティングCloudflare Pages
将来的にAPIも追加したいCloudflare Pages + Workers

個人プロジェクト規模なら正直どれでも困らない。ただ、「CDNとデプロイだけ確実にやってくれればいい」という用途なら、Cloudflare Pagesの割り切りが心地いい。余計な機能がない分、迷わない。

あ、もう一つ。Cloudflare Pages は KV（キーバリューストア）や R2（オブジェクトストレージ）と同じエコシステム上にあるので、あとからバックエンド機能を足しやすい。静的サイトで始めて、必要に応じて拡張する——という進め方ができるのは設計として良い。

セットアップ所要時間の目安

  • Cloudflareアカウント作成: 2分
  • GitHub連携 + 初回デプロイ: 5分
  • 独自ドメイン設定: 10分（DNS浸透待ち含む）
  • Web Analytics有効化: 1分

トータル20分もあれば、独自ドメイン付きの静的サイトが公開できる。開発者ツールやポートフォリオ、技術ブログなど、手軽にサイトを立ち上げたいなら十分選択肢に入る。自分の開発者向けツールサイトもこの構成で1ヶ月問題なく動いている。

関連記事