WordPressサイトをCloudflare経由に切り替える手順｜ConoHaを例にDNS移行時の確認ポイントを解説

☰

📑 INDEX

　

はじめに

サイトをCloudflare経由で公開すると、WAFやキャッシュなどの機能を利用でき、サイトの高速化やセキュリティの向上が見込めます。オリジンサーバーでWAFを実装している場合でも、Cloudflareで大量のBotを排除してくれるため、オリジンサーバーの負荷を下げることが出来ます。

一方で、ネームサーバーやDNSレコードの切り替えを伴うため、事前確認が不十分なままサイト切替を進めると、サイトの表示だけでなくメールや外部サービス連携にも影響が出る可能性があります。

本記事では、既存環境で公開しているWordPressサイトをCloudflare経由に切り替える際の基本的な流れを、ConoHaを例に整理します。

なお、画面例はConoHaのネームサーバを使用していますが、確認すべきポイント自体は他のレンタルサーバやDNS管理サービスでも大きくは変わりません

ConoHaは、レンタルサーバーや独自ドメイン管理を提供するホスティングサービスです。本記事ではその管理画面を例として使用しています。

今回は、切り替え前のバックアップから、Cloudflareへのドメイン追加、ネームサーバー切り替え後の疎通確認までを順番に紹介していきます。

本記事ではNS切り替え（Full Setup）でCloudflare経由に切り替えています。Cloudflare公式の手順はこちらにまとめられており、本記事もこの手順を参考にしています。

developers.cloudflare.com

前提条件

本記事は、以下のような前提でCloudflare移行を行うケースを想定しています。

• 既に自身のドメインでWebサイトを公開している
• Cloudflareは Full Setup（ネームサーバー切り替え） で利用する

本記事は切り替え完了までを説明します。SSL/TLSやキャッシュ除外、WAFなどの初期設定については、次回の記事で扱います。

本記事の流れ

本記事は、以下の流れで進めます。

• バックアップ
• Cloudflare へのドメイン追加
• DNS スキャン結果の確認
• ネームサーバーの切り替え
• 切り替え後の疎通確認

1. バックアップ

まずは切り戻しに必要な情報を確実にバックアップするところから進めます。 Cloudflare側の自動スキャンだけに頼らず、復元できる状態を作ってから進めることで、万が一の際も切り戻ししやすくなります。

1-1. 現在のネームサーバーを控える

ネームサーバーをCloudflareへ切り替える前に、現在どのネームサーバーを利用しているかを控えておきます。

移行後に問題が発生した場合、元の状態に切り戻す際の確認材料になるためです。

あわせて、現在のDNSレコード一覧もバックアップしておくことで、切り戻しの際に同じ構成を再現しやすくなります。

この段階で、少なくとも以下の2点を確認しておくと安心です。

1. 現在設定されているネームサーバー（NS）
2. 現在のDNSレコード一覧（A / CNAME / MX / TXT など）

確認手順（ConoHaで管理している場合の例）

今回はConoHaの画面を例に説明します。利用中のサービスによって画面名称は異なる場合がありますが、確認する内容自体は同じです。

1. ConoHaのコントロールパネルを開く
2. 「ドメイン管理」（または「ドメイン」）を選択する
3. 対象のドメインを開く
4. 「ネームサーバー設定」を表示する
5. 表示されているネームサーバーを控える

ネームサーバーは通常、2～3個など、複数表示されます。 後で見返せるように、ドメイン名が分かる状態でスクリーンショットを残しておくと確認しやすくなります。

この段階で残しておきたい情報

• 現在設定されているネームサーバー名
• 対象ドメイン名が分かるスクリーンショット

1-2. DNSレコードをバックアップする

Cloudflareへ移行する際は、現在利用しているDNSレコードを事前にバックアップしておきます。

ネームサーバーを切り替えると、以後はCloudflare側でDNSレコードを管理することになるため、移行前の内容を正確に把握しておくことが重要です。

特に、Web公開に必要なレコードだけでなく、メール利用や外部サービス連携に使っているレコードがある場合は注意が必要です。

移行時にこれらのレコードが不足すると、Webサイトは表示できても、メール送受信やドメイン認証に影響が出ることがあります。

前章と同じくConoHaの画面を例に説明しますが、他のサービスでも「現在のDNSレコード一覧を控える」という作業自体は同じです。

確認手順（ConoHaの例）

1. ConoHa 管理画面を開く
2. 左メニューの「DNS」（または「DNS設定」）を選択する
3. 対象ドメインを選択する
4. 表示されているDNSレコード一覧を確認する

バックアップは、スクリーンショットで全体を残す方法と、復元しやすいようにテキストで整理する方法の両方を用意しておくと安心です。

方法1：スクリーンショットで残す

まずはDNSレコード一覧の画面をそのままスクリーンショットで保存します。

レコード数が多い場合は、表全体が分かるように複数枚に分けて残します。

少なくとも、以下の情報が確認できる状態にしておくと後で見返しやすくなります。

• ホスト名（Name）
• レコード種別（Type）：A / CNAME / MX / TXT / AAAA / SRV など
• 値（Value / Content）
• TTL
• MXレコードの優先度（設定されている場合）

方法2：復元用のメモを作成する

スクリーンショットだけでも最低限の確認は可能ですが、入力の際に目で確認して手作業で入力するとミスが起きやすいです。

そのため、主要なレコードはコピーしてテキストでも整理しておくと、Cloudflare側へ手動登録する際に作業しやすくなります。

たとえば、以下のような形式で控えておくと分かりやすくなります。

タイプ	名称	値
A	@	xxx.xxx.xxx.xxx（TTL: 3600）
A	mail	xxx.xxx.xxx.xxx（TTL: 3600）
CNAME	www	dummy.jp（TTL: 3600）
MX	mail	mail.example.com（優先度: 10）
NS	@	example1.jp
NS	@	example2.jp
TXT	@	"v=spf1 ..."
TXT	selector1._domainkey	"..."（DKIMがある場合）
AAAA	@	xxxx:...（IPv6がある場合）

移行前に、少なくとも以下のレコードがあるかを確認しておきます。

• ルートドメイン（@）のAレコードまたはCNAME
• www のCNAMEまたはAレコード
• MXレコード
• TXTレコード
• AAAAレコード（IPv6を利用している場合）

特に、メールを利用している場合は、MX / SPF / DKIM / DMARC などの関連レコードを必ず確認してください。

この段階で残しておきたい情報

• DNSレコード一覧のスクリーンショット
• 主要レコードの復元用メモ

1-3. メールや外部サービスで使っているレコードを確認する

Cloudflareへの移行前に、メールや外部サービスで利用しているDNSレコードがどれかを確認しておきます。

Webサイトの表示に関係するAレコードやCNAMEだけを見て移行すると、メール送受信や各種認証、外部サービス連携に必要なレコードを見落とすことがあります。

確認しておきたい主な項目

以下のようなサービスを利用している場合は、関連するDNSレコードが存在する可能性があります。

• 独自ドメインのメールを利用している
  • 例：Google Workspace、さくらのメール、独自メールサーバなど
• Google Search Console 等の外部サービスに、所有権確認を行っている
• メール送信サービスを利用している
  • 例：SendGrid など
• 独自サブドメインを利用している
  • 例：img. api. cdn. など

確認したいレコードの種類

こうした用途では、主に以下のレコードが使われます。

• A
• AAAA
• MX
• TXT
• CNAME

たとえば、メール利用では **MX 、TXT（SPF / DKIM / DMARC）**関連のレコードが設定されていることがあります。

また、所有権確認や外部サービス連携では、TXTレコードやCNAMEレコードが使われている場合があります。

利用中サービスの棚卸しも兼ねて、一度整理しておくことをおすすめします。

---

2. Cloudflareにドメインを追加する

事前のバックアップができたら、次にCloudflare側へ対象ドメインを追加します。

この時点では、まだネームサーバーの切り替えは行わないため、既存サイトへの影響は発生しません。

Cloudflareへドメインを追加すると、現在のDNSレコードをもとに自動スキャンが実行され、初期状態のDNS設定候補が作成されます。

以降は、この内容を確認しながら移行準備を進めます。

2-1. Cloudflareアカウントを用意する

Cloudflareのホームページへアクセスし、画面右上の[ログイン]をクリックします。

「Sign Up」をクリックするか、Google等の外部サービスのアカウントでログインする等して、アカウントを作成します。

2-2. ドメインを追加する

アカウントを作成し、ダッシュボードに移動したら、ダッシュボード右上の[＋Add] から、「Connect a domain」を選択。

入力欄には、www 等を含まない ルートドメイン を入力します。

例えば、www.example.com等ではなく、example.comルートドメインを入力するように注意が必要です。

他項目はデフォルトのままで問題ありません。

• Quick scan for DNS records（Recommended） 
  • 自動スキャンを利用し、その後に必要なレコードを手動で補う流れが分かりやすいです
• AI Botの設定は後から変更可能です
  • この設定は「AIクローラ」向けなので、通常のGoogle等のクロールやサイト表示とは別問題です

設定を確認したら[Continue] をクリックします。プラン選択の画面に移ります。

Cloudflareへドメインを追加しただけでは、まだ実際の名前解決は切り替わっていません。

そのため、この時点では既存環境への通信経路やサイト公開状態は変わりません。

プランを選択する

検証用途や小規模なサイト用途であれば、まずはFreeプランから始めても十分です。

今回の手順でも、ドメイン追加と基本的な移行確認はFreeプランで進められます。

---

3. DNSスキャン結果を確認する

ドメイン追加が完了すると、Cloudflareが現在のDNSレコードをもとに自動スキャンを行い、DNSレコード候補を表示します。

ただし、この内容が正しいとは限りません。移行前にバックアップしたDNSレコード一覧と突き合わせて、必要なレコードが揃っているかを必ず確認します。

特に、Webサイトの表示に必要なレコードだけでなく、メールや外部サービス連携で利用しているレコードも含めて確認することが重要です。

3-1. 必須レコードが揃っているか確認する

まずは、最低限以下のようなレコードが含まれているかを確認します。

• ルートドメイン（@）のAレコードまたはCNAME
• www のAレコードまたはCNAME
• MXレコード
• TXTレコード
• 必要に応じて AAAA レコードや独自サブドメインのレコード

特に、メールを利用している場合は、MXやSPF、DKIM、DMARCなどに関係するレコードが欠けていないかを注意して確認します。

自動スキャンだけでは必要なレコードが揃わない場合もあるため、漏れているものがあれば手動で追加します。

3-2. プロキシ設定を確認する

CloudflareのDNS画面では、レコードごとに Proxied と DNS only を選択できます。

移行直後は、まずWeb公開に必要なレコードのみをCloudflare経由にし、それ以外はそのまま名前解決だけを行う構成にしておくと分かりやすくなります。

一般的には、以下のような整理が無難です。

• @ → Proxied
• www → Proxied
• mail などメール用ホスト → DNS only
• MX / TXT → そのまま利用（プロキシ不可）

Webサイト本体はCloudflare経由にしつつ、メール関連はCloudflareを経由させない形です。

これにより、Web保護のメリットを活かしながら、メール系の影響を避けやすくなります。

3-3. NSレコードの扱いに注意する

今回のように Cloudflareを権威DNSとして利用する（Full setup） 場合、実際にどのネームサーバーを使うかは、ドメイン管理側で設定するネームサーバーで決まります。

今回の例では、ConoHa側からネームサーバーの向き先をCloudflareへ変更することで、Cloudflareが権威DNSとして使われる構成になります。 ※この変更は後ほど実施します。

そのため、CloudflareのDNS画面に表示されているNSレコードは、必ずしも「現在どのネームサーバーが使われているか」をそのまま示すものではありません。

多くの場合は、以下のように考えると整理しやすくなります。

• ルートドメインのNSレコードは、旧環境の情報で不要であれば削除を検討する
• サブドメインのNSレコードは、委任用途の可能性があるため削除せず確認する

ルートドメイン（@）に残っている旧環境のNSレコードは、今回のような構成では不要なことが多く、移行後の確認時に混乱の原因になることがあります。

一方で、サブドメインに設定されたNSレコードは、別のDNSサーバへ委任するために使われている場合があります。そのため、用途を確認せずに削除しないよう注意が必要です。

本記事の例では、NSレコードはルートドメイン（@）に設定された旧環境の情報だったため、CloudflareのDNS設定からは削除しています。

注意マーク⚠️が表示される場合

CloudflareのDNS画面で、一部のレコードに注意マーク⚠️が表示されることがあります。

これは、レコードの向き先や設定内容がCloudflareの推奨と一致しない場合などに表示されることがあります。

注意マーク⚠️がある場合は、まず以下を確認します。

• ルートドメインのAレコードの値が移行元と一致しているか
• www の向き先が想定どおりか
• 本来 DNS only にすべきレコードが Proxied になっていないか

注意マーク⚠️が表示されていても、内容によってはそのまま利用できる場合があります。

ただし、意味を確認せずに進めるのではなく、少なくとも移行元の設定と一致していることは確認しておくのが安心です。

確認が終わったら次に進む

DNSレコードの内容とプロキシ設定を確認できたら、Cloudflare側で管理するDNS設定の準備は完了です。

以下は、ここまでの確認内容をもとに、Cloudflare側のDNSレコードを手動で調整した後の画面例です。

この時点で設定しているのは、Cloudflare側で管理するDNSレコードの内容です。

まだネームサーバーの向き先は既存環境のままなので、実際の名前解決先は切り替わっておらず、既存サイトへの影響はありません。

---

4. ネームサーバーをCloudflare指定に変更する

ここまでの手順で、Cloudflare側のDNSレコードとプロキシ設定の準備は完了しました。

次に、ドメイン管理側のネームサーバー設定をCloudflare指定へ変更し、実際の名前解決先をCloudflareへ切り替えます。

この操作が、今回の移行作業における実際の切り替えポイントです。ここまでに行っていた作業は、あくまでCloudflare側で受け入れるための事前準備にあたります。

補足: 今回のようなNS切り替えでは、既存DNSレコードのTTL変更は必須ではありません。NSレコードのTTLを短くできる環境では、切り替え時の追従に有利な場合もありますが、即時反映を保証するものではありません。実際の切り替えは、レジストラ側でのネームサーバ更新も関わるため、TTL短縮だけで即時切替を保証できません。

ただし、「ついでにTXTレコードの内容を変更しておこう」と言った場合は、既存DNSレコードの該当するTTLを一時的に短くしておくことをおすすめします。

4-1. ネームサーバー設定を変更する

今回はConoHaの画面を例に説明します。

利用中のサービスによって画面名称は異なる場合がありますが、実施する内容は「現在のネームサーバー設定をCloudflareが指定したものへ変更する」ことです。

ネームサーバー設定 からCloudflareで指定されたネームサーバーへ変更します。

設定変更後は保存を行い、反映を待ちます。

• 変更前

• 変更後

Cloudflareのネームサーバーは通常2つです。既存のネームサーバーを全て削除し、Cloudflareが指定した2つのネームサーバーを追加する形となります。（ネームサーバ―に何を指定すればいいかはダッシュボードで確認出来ます）

ちなみに、Cloudflare側からは以下のような手順を案内されます。

しばらくして、ダッシュボード上で、「あなたのドメインはCloudflareによって保護されています」と表示されていれば完了です。

次の章では実際にCloudflare経由で応答しているかどうかを確認していきます。

切り替え後に起こること

ネームサーバー設定を変更すると、以後はそのドメインの問い合わせがCloudflare側の権威DNSへ向くようになります。

ただし、変更直後にすべての利用環境で一斉に切り替わるわけではありません。

DNSキャッシュや参照タイミングの違いによって、しばらくの間は以下のような状態が混在して起こることがあります。

• ある環境では新しい設定が見える
• 別の環境ではまだ旧設定が見える
• 切り替え直後に応答が安定しないように見える

そのため、変更直後は慌てて設定を再変更するのではなく、事象が収束するまでは様子を見ておき、事前に控えておいた内容を元に落ち着いて確認することが重要です。

切り戻しに備えておく

今回、最初に現在のネームサーバーとDNSレコードをバックアップしたのは、この切り替え時に備えるためです。

万が一、Cloudflare側のDNS設定に不足や誤りがあり、サイト表示やメール利用に問題が出た場合でも、元のネームサーバー設定へ戻せる状態にしておくことで復旧しやすくなります。

---

5. 切り替え後の疎通を確認する

ネームサーバー設定をCloudflare指定へ変更したら、実際にCloudflare経由で名前解決やHTTPレスポンスが行われているかを確認します。

ネームサーバーの切り替え直後は、利用しているDNSリゾルバやキャッシュの状況によって、旧設定と新設定がしばらく混在して見えることがあります。

そのため、単にブラウザで表示できるかだけでなく、DNS応答やHTTPレスポンスヘッダもあわせて確認しておくと状況を把握しやすくなります。

5-1. ネームサーバーの応答を確認する

まずは、対象ドメインのネームサーバーがCloudflare指定へ切り替わっているかを確認します。

Windowsでは、コマンドプロンプトを開いて以下を実行します。

nslookup -type=ns example.com 1.1.1.1

ここで確認したいのは、ネームサーバー応答がCloudflareのネームサーバーになっているかどうかです。

この確認によって、少なくとも権威DNSの委任先がCloudflare側へ切り替わりつつあるかを把握できます。

5-2. Aレコード / CNAMEの応答を確認する

次に、example.com や www.example.com の応答先を確認します。

nslookup example.com 1.1.1.1

nslookup www.example.com 1.1.1.1

Cloudflareで Proxied にしている場合、ここで返ってくるIPアドレスは、オリジンサーバーのIPではなくCloudflare側のIPになります。

逆に、まだオリジンサーバーのIPが見えている場合は、以下のような可能性があります。

• ネームサーバー切り替え直後で、参照先がまだ安定していない
• CloudflareのDNSレコード設定で、 DNS only になっている
• 利用環境やDNSキャッシュの影響で旧情報が見えている

そのため、1回の確認結果だけで判断せず、時間を置いて再確認するのが無難です。

切り分けの一環として、ローカルのDNSキャッシュをクリアする場合は以下コマンドを実行します。
ipconfig /flushdns

5-3. ブラウザのレスポンスヘッダを確認する

ブラウザからも、Cloudflare経由で応答しているかを確認できます。

Chromeなどでシークレットウィンドウを開き、対象サイトへアクセスし、

「F12キーを押下」 → 「Network」タブで一番上のHTMLドキュメントを選択し、レスポンスヘッダに以下のような項目があるかを確認します。

• cf-ray
• cf-cache-status

これらのヘッダが確認できれば、少なくともそのHTTPリクエストはCloudflareを経由していると判断しやすくなります。

5-4. Cloudflareダッシュボードでも確認する

Cloudflareダッシュボード側でも、リクエストが到達しているかを確認できます。

たとえば以下の画面を確認すると、Cloudflare経由でのリクエストが発生しているかを把握しやすくなります。

• DNS → Analytics
• セキュリティ → Analytics → Events

ここにリクエストやイベントが表示されていれば、Cloudflare側でトラフィックを認識できている状態と考えられます。

5-5. 確認時のポイント

切り替え直後は、すべての確認結果が一度に揃うとは限りません。

そのため、以下のように段階的に見ていくと整理しやすくなります。

• ネームサーバー応答がCloudflareのものになっているか
• example.com / www.example.com がCloudflareのIPで応答しているか
• HTTPレスポンスヘッダにCloudflare由来のヘッダがあるか
• Cloudflareダッシュボードにリクエストが見えているか

これらを確認できれば、Cloudflare経由への切り替えが概ね完了したと判断しやすくなります。

---

おわりに

ここまでで、WordPressサイトをCloudflare経由で公開するための基本的な切り替え作業は完了です。

今回の手順では、いきなりネームサーバーを切り替えるのではなく、先に現在のネームサーバーやDNSレコードをバックアップし、Cloudflare側のDNS設定を確認したうえで切り替えを実施しました。

特に、メール関連のレコードや外部サービス連携用の設定を事前に確認しておくことは、移行時のトラブル防止に役立ちます。

また、Cloudflareを権威DNSとして利用する構成では、

• どのネームサーバーを使うか
• そこでどのDNSレコードを返すか

を分けて理解すると、移行時の確認ポイントが整理しやすくなります。

Cloudflare の Full Setup では、権威DNSの委任先についてはレジストラ側のネームサーバー設定で決まり、Cloudflare側で A / CNAME / MX / TXT などのDNSレコードを管理する形となります。

次回の記事では、Cloudflare導入後に確認しておきたい初期設定として、SSL/TLS、キャッシュ除外、WAF などの設定を整理して紹介します。

blogs.networld.co.jp

参考情報

• Cloudflare Docs: Primary setup (Full)
• Cloudflare Docs: Change your nameservers (Full setup)
• Cloudflare Docs: Onboard a domain
• Cloudflare Docs: Nameserver options
• Cloudflare Docs: Update nameservers
• Cloudflare Docs: DNS setups
• Cloudflare Docs: TTL
• Cloudflare Docs: CNAME setup (Partial)
• Cloudflare Docs: Set up a partial zone (CNAME setup)
• Cloudflare Docs: Delegate subdomains
• Microsoft Docs: ipconfig