公開先を並べて比べる——レンタルサーバー・Vercel・Netlify・Cloudflare Pages

公開先を選ぶとき、私は機能表を眺める前に3つだけ確認します。更新するのは誰か、サーバー側で動く処理があるか、公開後に問題が出たらどう戻すか、です。この3つが決まると、候補はかなり絞れます。ここではレンタルサーバー・Vercel・Netlify・Cloudflare Pagesを、この3軸で並べます。料金や無料枠は変わりやすいので、この記事では扱いません。契約前に各社の公式ページで確認してください。

3軸で並べた比較表

公開先	更新の担当者	動的処理	戻し方
レンタルサーバー	ファイルを置ける人、管理画面を触れる人	プランによってPHPやデータベースが使える	バックアップや手元のファイルから戻す（方法は事業者ごと）
Vercel	Gitに反映できる人	Vercel Functions	Instant Rollbackで以前の本番デプロイへ
Netlify	Gitに反映できる人	Netlify Functions	以前のデプロイを公開し直す
Cloudflare Pages	Gitに反映できる人	Pages Functions	Rollbacksで以前の本番デプロイへ

表の並びは順位ではありません。どれが合うかは案件の条件で変わります。

軸1：更新するのは誰か

いちばん差が出るのはここです。Vercel・Netlify・Cloudflare Pagesは、Gitのリポジトリと連携してビルドとデプロイを進める使い方が基本になります。更新する人がGitを使える、あるいはGitの裏側を意識せずに済むCMSを組み合わせる、のどちらかが前提です。

一方、WordPressのように管理画面から記事を更新する運用なら、PHPとデータベースが動く環境が要ります。この場合はレンタルサーバーが候補に残ります。私が最初のヒアリングで「公開後、誰がどの画面で更新しますか」と聞くのは、ここで公開先の系統が分かれるからです。

軸2：サーバー側の処理があるか

問い合わせフォームの送信や、外部APIからのデータ取得など、サーバー側で動かす処理があるかどうかも確認します。3つのサービスはいずれもサーバーレスの関数を用意していて、VercelはVercel Functions、NetlifyはNetlify Functionsとして、サイトと一緒にデプロイする形を案内しています。

ただし、処理の実行時間や使える言語、制限値はサービスごとに異なり、変更もあります。私は「この処理はどこで動くのか」を要件定義の段階で1行書いておき、実装前に該当する公式ドキュメントの制限ページを読むようにしています。

Cloudflareについては補足があります。Cloudflare Pagesの公式ドキュメントの冒頭には、WorkersがPagesの多くの用途に対応し、新しいプロジェクトはWorkersで始めるよう案内する記述があります。移行手順はMigrate from Pagesにまとまっています。これから新しく作る案件なら、PagesとWorkersのどちらで始めるかを先に確認しておくと、後の作り直しを避けやすくなります。

軸3：問題が出たときにどう戻すか

公開後の戻しやすさは、クライアントへの説明でも重要です。

• Vercel：Instant Rollbackで、以前の本番デプロイにドメインを向け直せます。ロールバック後は本番ドメインの自動割り当てが止まるため、次のpushが自動で本番に出ない点は覚えておきます。どこまで遡れるかはプランによって異なります
• Netlify：デプロイ一覧から以前のデプロイを選んで公開し直す形で、公式ドキュメントでは新しいビルドを走らせずに切り替えるとされています
• Cloudflare Pages：Rollbacksで、ビルドに成功した以前の本番デプロイへ戻せます。プレビューデプロイは対象外です
• レンタルサーバー：戻し方は事業者のバックアップ機能や、自分で取っておいたファイルに左右されます。契約前に「どの時点に、誰が、どう戻せるか」を確認します

どの方式でも、戻るのはデプロイしたファイルです。データベースの中身や外部サービスの状態までは戻らないと考えて、手順書を書いています。戻す判断の基準はリリース前チェックリストにまとめました。

明日から試せる一手

担当している案件について、表の3列をそのまま埋めてみてください。「更新するのは誰か」「サーバー側の処理は何か」「戻すときの手順は誰が知っているか」。埋まらない欄があれば、そこが公開先を決める前に確認すべき項目です。