Vercel・Cloudflare Pages・Netlifyの選び分け。ブログをCloudflare Pagesで実運用している立場から

このブログ（clvr.lol）はCloudflare Pagesでホストしている。Astro 5の静的サイトで、記事は180本を超えたが、いまだに無料枠のままだ。だからこの記事は3サービスを横並びでスペック表にする話ではなく、「Cloudflare Pagesを実際に運用している人間が、VercelとNetlifyをどういう時に選ぶか」という視点で書く。

先に正直に言っておくと、VercelとNetlifyは触ったことはあるが、本番サイトを長期運用した経験があるのはCloudflare Pagesだけだ。なので他の2つについては、実測値を並べるようなことはせず、構造的に変わりにくい差だけを判断材料にする。細かい料金や制限値は改定が頻繁なので、最終確認は各社の料金ページでやってほしい。

Cloudflare Pagesを選んだ理由は、突き詰めると「帯域無制限」

3サービスの無料枠で一番大きな構造的差は帯域だ。VercelとNetlifyの無料枠は転送量に上限があり、超えそうになったら課金かサイト停止かの判断を迫られる。Cloudflare Pagesは静的アセットの配信帯域が無制限で、この差は料金改定でひっくり返る類いのものではない。Cloudflareは自社のグローバルネットワークに乗せているだけなので、配信量を売る理由がそもそもない。

個人ブログの現実的なトラフィックなら、どのサービスでも無料枠に収まる可能性は高い。それでも自分がCloudflare Pagesにしたのは、「バズって転送量が跳ねた月に何も考えなくていい」という保険の意味が大きい。無料枠の上限を気にしてヒヤヒヤするくらいなら、最初から上限がない方を選ぶ、という消極的だが実用的な理由だ。

ちなみに転送量を減らす努力もしていて、記事に載せる画像は事前に圧縮してから置いている。そのために作った画像圧縮ツールはブラウザ内で完結する（サーバーに画像を送らない）ので、スクショをそのまま突っ込んで縮めている。帯域無制限だからといって重い画像を垂れ流すとLCPが悪化するので、そこは別問題として対処が要る。

実際に引っかかる制限は「ビルド500回/月」の方

Cloudflare Pagesの無料枠で運用上意識するのは、帯域ではなくビルド回数の上限（500回/月）だ。うちは記事の自動生成が毎朝動いていて、デプロイが1日1〜2回走るが、それでも月に数十回。個人サイトなら普通は問題にならない。

ただし、GitHubのリポジトリを接続してプッシュのたびに自動ビルドさせる運用で、細かいコミットを頻繁にプッシュする人や、PRごとのプレビュービルドが大量に走るチームだと、500回は現実的な壁になり得る。自分はGitHub連携の自動ビルドではなく、ローカル（VPS）でnpm run buildしてからwrangler pages deployで成果物だけ上げる方式にしている。この方式だとビルド回数の消費が自分のデプロイ実行回数と一致するので、管理が楽だ。

# うちの実際のデプロイ（package.jsonのdeployスクリプト）
# .envのCLOUDFLARE_API_TOKENを読んでビルド→アップロード
npm run deploy

wranglerでのデプロイにはひとつ落とし穴があって、Pagesプロジェクトには「本番ブランチ」の概念がある。デプロイ時のブランチが本番ブランチと一致しないと、本番URLではなくプレビューURLに反映される。最初にここを理解していなくて、「デプロイは成功しているのにサイトが更新されない」で少し悩んだ。CLIデプロイ派は本番ブランチ名の指定だけ最初に確認しておくといい。

それでもVercelを選ぶべき場面: Next.js

構造的に動かない事実として、VercelはNext.jsの開発元だ。ISRやImage Optimization、Middlewareといった機能は、Vercel上で動かすことを前提に一番手厚く実装されている。Next.jsのアプリを作るなら、少なくとも最初のデプロイ先としてVercel以外を選ぶ理由はあまりないと思う。他のプラットフォームでもNext.jsは動くが、「全機能がドキュメント通りに動くか」を自分で検証するコストを払うことになる。

逆に言うと、これはロックインの話でもある。Vercel前提の機能に寄せるほど、後から他へ移すコストは上がる。静的サイトジェネレータ（AstroやHugo）で作ったサイトはその点どこへでも持っていけるので、うちのブログがCloudflare Pagesを選べたのも「Astroの静的出力だからどこでも動く」という前提があってのことだ。

Netlifyを選ぶべき場面: バックエンドを書きたくないフォーム

Netlifyの独自性はFormsやIdentityのような「バックエンドなしで済ませる」系の機能にある。問い合わせフォームひとつのためにサーバーレス関数やAPIを書きたくない、という案件では今でも合理的な選択肢だと思う。

ただ、うちのケースではこの手の機能はVPS側に自前実装している（後述）ので、Netlify固有の機能に頼る場面がなかった。無料枠のビルド時間もCloudflareやVercelと比べて少なめの傾向が続いているので、選ぶなら「Forms等の固有機能が刺さるか」で判断するのがいいと思う。

PaaSか自前VPSか、という比較軸もある

自分はもうひとつサイトを持っていて、そちら（cleverlab.lol）はPaaSではなく自前VPSのnginxで静的配信している。両方を並行運用してみての使い分けははっきりしていて、

• 静的サイト単体なら PaaS（Cloudflare Pages）が楽。 SSL、CDN、デプロイの仕組みを全部持ってくれて、無料。VPSでやると nginx の設定と証明書の更新が自分の仕事になる。
• 常駐プロセスが要るならVPS。 うちのブラウザゲームのスコア保存APIのようなものは、PaaSの関数モデルに載せるより、VPSでNode.jsのプロセスを常駐させる方が素直だった。データをローカルのファイルにそのまま書けるので、外部ストレージサービスを契約せずに済んでいる。

つまり「Vercel vs Cloudflare vs Netlify」の3択の前に、「そもそもPaaSでいいのか」の分岐がある。静的サイト＋ちょっとしたAPIくらいなら3サービスどれでも収まるが、DBや常駐処理が本格的に要るなら、フロントはPaaS・バックエンドはVPSという分担が個人開発では一番現実的だと感じている。

自分の結論

• 静的サイト（Astro・Hugo等）→ Cloudflare Pages。帯域無制限で無料、移行も容易。うちのブログはこれで困っていない。
• Next.js → Vercel。開発元の土俵で戦うのが一番手間が少ない。
• バックエンドなしでフォームや認証を済ませたい → Netlifyの固有機能を検討。
• 常駐プロセスやDBが要る → PaaSに無理に載せず、その部分だけVPSへ。

3つとも無料で始められて、静的サイトなら移行コストはほぼゼロに近い。だから最初の選択で悩みすぎる必要はなくて、構造的な差（帯域・フレームワークとの距離・固有機能）だけ押さえて選び、合わなければ移ればいい。うちは記事が180本を超えた今も無料のままで、Cloudflare Pagesから移る理由がまだ見つかっていない。

このブログ自体の構築の話はClaude CodeでWebサイトを丸ごと作って運用してわかったことに書いたので、Astro＋Cloudflare Pagesの組み合わせを考えている人はそちらも参考になると思う。