目次

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

SoftwareResearchBlogMigrationCloudflareVercelAstro

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 側からカスタムドメインとプロジェクトを削除して跡片付けする

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

← 一覧に戻る