2025/12/11

Vercel から Cloudflare Pages に移行した理由と検討ログ【前編】

Vercel から Cloudflare Pages に移行した理由と検討ログ【前編】

このブログ（DeskTechLab）は、しばらくの間 Astro + Vercel + お名前.com（DNS） という構成で運用してきました。

動いているだけであればこのままでも問題はなかったのですが、今後の運用を考えたときに、少し整理しておきたいと感じる場面が増えてきました。

その結果として、最終的に Vercel から Cloudflare Pages への移行 を決めたので、本記事ではその理由と検討プロセスを整理しておきます。

この記事の想定読者

• Vercel で静的サイト（Astro / Next.js の SSG 等）を運用している
• Cloudflare Pages が気になっているが、本当に移行すべきか迷っている
• お名前.com など、別サービスで DNS を管理していて少し煩雑に感じている

同じような環境・悩みを持つ人にとって、判断材料の一つになればと思います。

移行前の構成と、モヤモヤしていた点

まず、移行前の構成を整理します。

• フロントエンド: Astro
• ホスティング: Vercel
• ドメイン: desktechlab.com（お名前.com で取得）
• DNS: お名前.com のネームサーバー
• 本番URL: https://www.desktechlab.com/

特別大きなトラブルがあったわけではなく、日常の更新は問題なくできていました。
それでも、次のようなモヤモヤが少しずつ溜まってきました。

1. DNS とホスティングの管理が分かれている

• DNS とドメイン管理: お名前.com
• ホスティング: Vercel

という分離はよくある構成ですが、実際の運用では次のような手間が発生します。

• リダイレクト設定をどこでやるか一瞬迷う
  （DNS側か、ホスティング側か）
• TXT レコード等を追加したいときに毎回お名前.comにログインする
• 将来的にサブドメインや別サイトが増えたとき、設定の場所を覚えておく必要がある

小さなことの積み重ねですが、長く運用する前提で考えると、設定の窓口は少ない方が良いと感じるようになりました。

2. 今後 Cloudflare を使うケースが増えそう

このブログに限らず、Cloudflare はいずれどこかで使うことになると感じていました。

具体的には次のような用途です。

• CDN としてのキャッシュ
• DNS 管理の集約
• リダイレクトルールやHTTPS強制の一元管理
• 簡易的なセキュリティ（WAF・Bot対策）

どうせ Cloudflare を使うなら、ブログのホスティングも含めて早めに慣れておいた方が、今後の構成を考えやすくなります。
その意味で、Cloudflare Pages を本格的に試すタイミングとしてちょうど良いと判断しました。

移行先の候補として考えたパターン

いきなり「Vercel をやめる」と決めたわけではなく、いくつかの選択肢を並べて比較しました。

パターン1: Vercel 継続 + DNS だけ Cloudflare に移行

• お名前.com から Cloudflare にネームサーバーを変更
• A / CNAME は引き続き Vercel を向かせる
• ホスティング自体は Vercel のまま

このパターンのメリットは次の通りです。

• 既存のデプロイフロー（GitHub → Vercel）が崩れない
• DNS とルールだけ先に Cloudflare に寄せておける
• 本番環境の切り替えリスクが小さい

一方で、次のようなデメリットもあります。

• 結局、ホスティングは Vercel / DNS は Cloudflare と分かれたまま
• Cloudflare Pages そのものの評価や検証は先送りになる

「当面は無難に行くなら悪くない選択肢」ですが、今回は “インフラの整理” を優先したかった ので、最終的には見送りました。

パターン2: Vercel から Cloudflare Pages へフル移行

• ホスティングを Cloudflare Pages に変更
• DNS も Cloudflare に移行
• お名前.com は「ドメインを持っているだけ」の役割にする

このパターンのメリットは明確です。

• DNS〜ホスティング〜リダイレクトを Cloudflare に集約できる
• 今後の拡張（別サイト・別ドメイン）も同じ考え方で整理できる
• Astro 等の静的サイトであれば Pages との相性が良い

デメリットとしては、

• 一度、本番ドメインの切り替え作業が発生する
• Vercel に用意していた機能（プレビューURLなど）を Pages 側でどう扱うかを考える必要がある

といった部分がありますが、今回のブログ程度の規模であれば現実的な範囲だと判断しました。

パターン3: Netlify など別ホスティングへの移行

静的サイトのホスティングとしては、Netlify や他サービスも候補に上がります。

ただし今回は、

• どうせ DNS は Cloudflare に寄せたい
• 将来的にも Cloudflare を使う前提がほぼ確定している

という条件があったため、
「Cloudflare を使うのに、あえて別ホスティングに分散させる理由は少ない」と判断し、候補から外しました。

Cloudflare Pages を選んだ決め手

最終的に、次の理由から Cloudflare Pages への移行を決めました。

1. 静的サイト（Astro）との相性が良い

現在のブログは次のような構成です。

• Astro を使用
• npm run build で dist 以下に静的ファイルが出力される
• サーバーサイドの処理は使っていない

Cloudflare Pages は、まさにこのような 静的サイトを GitHub からビルドしてそのまま配信する 使い方に向いています。

実際に設定してみても、

• Framework preset: Astro
• Build command: npm run build
• Output directory: dist

というシンプルな設定で問題なく動作しました。

2. 管理画面と設定の窓口が減る

Cloudflare に寄せることで、次のような構成になります。

• DNS: Cloudflare
• ホスティング: Cloudflare Pages
• リダイレクト・HTTPS強制など: Cloudflare の Rules / SSL 設定

この結果、サイトの公開に関わる設定は基本的に Cloudflare のダッシュボードだけ見れば良い 状態になります。

• ネームサーバーをどこで管理しているか
• CNAME / A レコードがどこを向いているか
• HTTP → HTTPS へのリダイレクト
• desktechlab.com → www.desktechlab.com へのリダイレクト

などを一か所で把握できるのは、運用の負担を減らす意味で大きなメリットです。

今回の移行方針（ざっくり）

以上を踏まえて、今回は次の方針で進めることにしました。

• お名前.com のネームサーバーを Cloudflare に切り替える
• Cloudflare Pages で desk-tech-lab プロジェクトを作成し、GitHub から自動ビルドする
• https://desk-tech-lab.pages.dev/ が問題なく動くことを確認してから
• www.desktechlab.com の CNAME を Vercel → Cloudflare Pages に切り替える
• 問題なければ、Vercel 側からカスタムドメインとプロジェクトを削除して跡片付けする

後編では、この方針に沿って実際に行った作業内容と、途中でハマったポイントを具体的な画面イメージとともに整理していきます。