Cloudflareにドメインを追加するときに変えるのは、ドメインのネームサーバーだけです。お名前.comやさくらのドメイン、.co.jpを扱う国内レジストラとの契約はそのままで、DNSの置き場所をCloudflareへ移せます。この記事では2026年9月時点の公式ドキュメントをもとに、ゾーンの追加とネームサーバーの取得をAPIで行うコマンド、切り替え前にCloudflare側のレコードをdigで答え合わせする手順、DNSSECを先に外す順番、Active化の確認と失敗時の対処までを、コピーして使える形でまとめました。
まとめ：レジストラを変えずにDNSだけCloudflareへ移す判断と作業の順番
多くのサイトに合うのは、ネームサーバーをCloudflareへ向けるフルセットアップです。無料のFreeプランで使え、ドメインの登録先は変わりません。レジストラごと移したい場合は別の作業で、.jpや.co.jpはCloudflare Registrarが扱っていないため、国内の企業ドメインは「DNSだけ移す」が実質の選択肢になります。
作業は次の順に進めます。事故が起きるのは、ほぼ3番と4番を飛ばしたときです。
- ゾーンを追加し、割り当てられた2つのネームサーバー名を控える
- 旧DNSのレコードを書き出し、Cloudflareへ取り込む
- 切り替え前に、Cloudflareのネームサーバーへ直接digで問い合わせて差分を潰す
- DNSSECが有効なら、レジストラでDSレコードを外してから切り替える
- レジストラでネームサーバーを書き換え、Active化とHTTPSの動作を確かめる
メールを止めたくない場合は、MXとSPF・DKIMのTXTを最初に照合してください。Webの表示は気付きやすく、メールの不達は気付くのが遅れます。
Cloudflareでドメインを扱う3つの方式とレジストラを変えない方式の位置付け
フルセットアップ・CNAMEセットアップ・Registrar移管の違いと対象プラン
「Cloudflareにドメインを入れる」には3つの意味があり、検索結果の記事はこれを混ぜて書いています。違いはDNSの権威をどこに置くかと、レジストラを変えるかです。
| 方式 | レジストラ | 権威DNS | 対象プラン | 向く場面 |
|---|---|---|---|---|
| フルセットアップ | 変えない | Cloudflare | Freeから | 多くのWebサイト |
| CNAMEセットアップ | 変えない | 既存のDNS | Business・Enterprise | DNSを動かせない大規模構成 |
| Registrar移管 | Cloudflareへ | Cloudflare固定 | Freeから | .comなど対応TLDを原価で持つ |
CNAMEセットアップのドキュメントは、この方式がBusinessとEnterpriseだけのもので、Cloudflare Registrarのドメインでは使えないと書いています。DNS基盤への攻撃に対するDDoS防御もフルセットアップだけの機能です。Freeプランで始めるなら、選択肢はフルセットアップ一択です。
.co.jpのままDNSだけ移せる理由とRegistrar移管との作業の分け方
フルセットアップの手順書が求めるのは、レジストラの管理画面でネームサーバーを書き換えることだけです。登録先をCloudflareへ移す工程はありません。そのため、Cloudflare Registrarが対応していない.jpや.co.jpでも、国内のレジストラに登録したままDNSをCloudflareへ向けられます。
ドメインの登録・移管・更新をCloudflareへまとめたい場合は、フルセットアップを済ませてから別作業として進めます。料金、60日ルール、APIでの登録はCloudflare Registrarの移管手順と料金｜.jp非対応・API登録の実装で扱っています。この記事で扱う範囲は、現在のレジストラとの契約を維持したまま、DNSの置き場所だけを変える側の作業です。
ダッシュボードとAPIでゾーンを追加しネームサーバー名を取り出す手順
ダッシュボードのOnboard a domainからプラン選択までの4つの操作
手順書（2026年7月29日更新）の画面操作は4つです。
- ダッシュボードで「Onboard a domain」を選ぶ
wwwを付けない頂点ドメイン（example.co.jp）を入力する- DNSレコードの取り込み方法を選ぶ（Quick scanか、ファイルのインポートか）
- プランを選ぶ
プランまで選ぶと、ゾーンは「Pending」になり、2つのネームサーバー名が表示されます。名前はCloudflareが自動で割り当て、利用者は選べません。bob.ns.cloudflare.comのような形式で、1文字でも違うと名前解決に失敗するため、手で打たずにコピーします。
Create Zone APIのゾーン作成とname_servers取得のcurl例
複数のドメインを移す案件では、画面操作よりAPIが確実です。Create ZoneのAPIリファレンスでは、POST /zonesにnameとtypeを渡します。typeはfull・partial・secondary・internalのいずれかで、フルセットアップはfullです。トークンには Zone:Edit か DNS:Edit のどちらかの権限が必要です。
export CLOUDFLARE_API_TOKEN="<Zone:Edit権限を持つトークン>"
export ACCOUNT_ID="<アカウントID>"
curl -s https://api.cloudflare.com/client/v4/zones \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"account\": {\"id\": \"$ACCOUNT_ID\"}, \"name\": \"example.co.jp\", \"type\": \"full\"}" \
| jq '{id: .result.id, status: .result.status, name_servers: .result.name_servers}'応答のname_serversが、レジストラへ登録する2つの名前です。idは以降のDNSレコード操作とActive化の確認で使うので、環境変数ZONE_IDに入れておきます。
Freeプランの200件上限とQuick scanで漏れるレコードの補い方
手順書は、Quick scanが既存のレコードをすべて見つけるとは限らないと明記しています。漏れたままActiveになると、訪問者にはDNS_PROBE_FINISHED_NXDOMAINが表示されます。旧DNSから書き出せるなら、BIND形式のファイルをインポートAPIで取り込む方が確実です。
# old-zone.txt：旧DNSの書き出しを整形したもの（$INCLUDEは使えない）
www.example.co.jp. 300 IN A 192.0.2.10 ; cf_tags=cf-proxied:false
example.co.jp. 300 IN MX 10 mail.example.co.jp.
example.co.jp. 300 IN TXT "v=spf1 include:_spf.example.net ~all"
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/import" \
--request POST \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--form "[email protected]"ファイルは256KiBまでです。レコード数にも上限があり、DNSレコードのドキュメントによると2024年9月1日以降に作ったFreeゾーンは200件、ProとBusinessは3,500件です。検証用のサブドメインを大量に持つゾーンは、取り込む前に件数を数えてください。
NS切り替え前のpending中のCloudflareへのdig照合手順
割り当てネームサーバーへ直接問い合わせて旧DNSとの差分を取るスクリプト
競合記事が触れていない点ですが、ゾーンステータスのドキュメントには「Pendingのゾーンにも、CloudflareはDNSの問い合わせに応答する」とあります。つまりネームサーバーを切り替える前に、Cloudflareが返す答えを旧DNSと突き合わせられます。
DOMAIN=example.co.jp
OLD_NS=$(dig +short NS $DOMAIN | head -1)
NEW_NS=bob.ns.cloudflare.com # 割り当てられた名前に置き換える
for name in $DOMAIN www.$DOMAIN; do
for t in A AAAA CNAME MX TXT; do
diff <(dig +short @$OLD_NS $name $t | sort) \
<(dig +short @$NEW_NS $name $t | sort) > /dev/null \
|| echo "差分あり: $name $t"
done
done「差分あり」が出たレコードだけ直せば、切り替えてよい状態です。サブドメインがほかにあるなら、nameの並びへ足してください。digの出力の読み方は名前解決とは？dig/nslookupでの確認方法で解説しています。
照合の間は、レコードのプロキシを切って（灰色雲）おきます。プロキシが有効なレコードはCloudflareのIPを返すので、正しく設定していても差分として出ます。
DNSSECが有効なドメインでDSレコードを先に外す順番とマルチサイナー移行
手順書は、DNSSECが有効なドメインではネームサーバーを変える前に無効化するよう求め、有効なまま変えるとドメインに到達できなくなる恐れがあると書いています。レジストラに登録されたDSレコードが旧DNSの鍵を指したままになり、署名を検証するリゾルバが応答を捨てるためです。
順番は「レジストラでDSを外す、DSのTTLが切れるまで待つ、ネームサーバーを切り替える、Active化の後にCloudflareでDNSSECを有効にし直す」です。署名が切れる時間を1秒も作れない金融系などでは、DNSSECを有効にしたまま移す手順があります。RFC 8901のマルチサイナー方式で両社の鍵を相互に登録するもので、旧DNS事業者がゾーン頂点にDNSKEYを追加できることが前提です。国内の共用DNSでは対応していないことが多く、多くの案件では一時的に外す方が現実的です。仕組みはDNSSECとは？DNSの安全性を守る仕組みと役割・導入手順を参照してください。
プロキシ有効化でTTLが300秒に固定される影響とMXが灰色雲のままの理由
プロキシ状態のドキュメントによると、プロキシできるのはA・AAAA・CNAMEだけで、MXやTXTは常にDNS onlyです。プロキシを有効にしたレコードのTTLはAuto（300秒）に固定され、変えられません。
実務で効くのは、プロキシを有効にするとオリジンの実IPが応答から消える点です。メールサーバーと同じIPのAレコードをプロキシすると、MXが指すホスト名までCloudflareのIPを返し、メールが届かなくなります。mailのようなメール用ホストはDNS onlyに残し、Webのレコードだけをプロキシしてください。
レジストラでネームサーバーを書き換えた後のActive化確認と失敗時の対処
dig nsとactivation_check APIのActive化確認と実行間隔
レジストラで既存のネームサーバーを消し、Cloudflareの2つを登録したら、反映を確かめます。手順書に記載された待ち時間は最大24時間で、ネームサーバーの反映を確認するコマンドはdig nsです。.jpの場合は、親の.jpサーバーに登録された委任も見ると、レジストラ側の反映とキャッシュ待ちを切り分けられます。
# キャッシュ込みの結果と、親（.jp）に登録された委任を並べて見る
dig +short NS example.co.jp @1.1.1.1
dig +norec +noall +authority NS example.co.jp @a.dns.jp
# 委任が変わっていれば、Cloudflareに再確認させる
curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/activation_check" \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID" \
-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" | jq -r '.result.status'再確認APIのリファレンスでは、呼べる間隔はFreeゾーンで1時間に1回、従量課金とEnterpriseで5分に1回です。Freeで何度も叩いても早まりません。statusがactiveになれば完了で、Cloudflareから通知メールも届きます。
pendingは28日・movedは7日で削除される期限と放置ゾーンの扱い
ゾーンステータスのドキュメントに数値で記載されているのは、Freeプランで各状態のゾーンが削除されるまでの期限です。ネームサーバーを切り替えないままのPendingは28日、プラン未選択のInitializingも28日で自動的に削除されます。Active化の後にネームサーバーが別の事業者へ戻り、確認に何度も失敗するとMovedになり、Freeでは7日で削除されます。
DeletedからさらにPurgedになると、Cloudflareは問い合わせに応答しなくなり、元に戻せません。レジストラの委任だけが残ったまま消えると、そのドメインは名前解決できなくなります。検証用に追加したゾーンを残して移行をやめる場合は、レジストラの設定を先に戻してから削除してください。
Flexibleのリダイレクトループ発生条件とFull (strict)への切り替え
Active化の直後に多い障害がリダイレクトループです。ERR_TOO_MANY_REDIRECTSのドキュメントによると、暗号化モードがFlexibleのときCloudflareはオリジンへHTTPで接続します。オリジンがすべてのHTTPをHTTPSへ転送していると、この往復が終わりません。
対処は、オリジンに証明書がある前提で、モードをFull以上にすることです。暗号化モードのドキュメントでは既定がAutomatic SSL/TLSで、オリジンに合うモードを自動で選びます。旧記事の手順に従ってFlexibleを手で選ぶのはやめ、オリジンの証明書まで検証するFull (strict)に揃えてください。
受託開発の現場でDNSをCloudflareへ寄せる構成を採用する条件と見送る場面
Pages・Workers・Tunnelを使う構成でフルセットアップを採用する基準
フルセットアップを採るのは、Cloudflareの機能を本番で使う予定がある構成です。Cloudflare Pagesの独自ドメイン設定や、Cloudflare Tunnelで社内のサーバーを公開する構成は、ゾーンがCloudflareにあると設定が1画面で済みます。DNSとWAF・キャッシュ・証明書を同じ場所で管理でき、変更の履歴もAPIで追えます。
逆に、サイトがAWS上にありCloudFrontとACMで配信が完結しているなら、DNSだけをCloudflareへ移しても得るものは多くありません。DNSを含めたクラウド構成の見直しは、一創のインフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。
Route 53や社内DNSに依存する構成でCNAMEセットアップも選ばない判断
見送るのは、DNSを別の仕組みと一体で運用している構成です。Amazon Route 53のエイリアスレコードやヘルスチェックで切り替えを組んでいる場合、Cloudflareへ移すとその設計を作り直すことになります。社内DNSと同じゾーンを共有するActive Directory環境も同じです。
この場合、Webの一部だけをCloudflareに通すCNAMEセットアップが候補に見えますが、Business以上の契約が要ります。プロキシしたいのが一部のサブドメインだけなら、先に検討する対象は、ゾーンを移さずに使うTunnelやWorkersのカスタムドメインで要件を満たせるかどうかです。1つのドメインのDNSを2社に分けて持つと、障害時に原因の切り分けが遅れます。Cloudflareへ寄せることのリスクはCloudflareの危険性は本当か？障害・SLA・情報漏えいの実態と対策で整理しています。
よくある質問
Cloudflareへのドメイン追加とネームサーバー変更について、検索の多い質問に答えます。
Cloudflareにドメインを追加するのに費用はかかりますか？
フルセットアップはFreeプランで使え、ゾーンの追加とDNSの利用に費用はかかりません。レジストラの年額費用は、これまでどおり今のレジストラへ払います。有料が必要になるのは、CNAMEセットアップ（Business以上）を選ぶ場合や、Freeの上限を超える場合です。2024年9月1日以降に作ったFreeゾーンのDNSレコードは200件までなので、レコードの多いゾーンはProの3,500件を検討します。
ネームサーバーの変更が反映されるまで何時間かかりますか？
公式の手順書は、レジストラ側の更新に最大24時間かかるとしています。実際の待ち時間を左右する要素は、レジストラが親のサーバーへ委任を反映する速さと、各地のリゾルバが古いNSレコードを保持する時間です。dig +norec NS example.co.jp @a.dns.jpのように親サーバーへ直接聞くと、レジストラ側が済んでいるかを確かめられます。Freeゾーンでは再確認APIを1時間に1回呼べます。
お名前.comで取得したドメインもCloudflareで使えますか？
使えます。フルセットアップで必要なのは、レジストラの管理画面でネームサーバーを書き換えることだけです。お名前.comやムームードメインに登録したまま、DNSだけをCloudflareへ移せます。レジストラごとCloudflareへ移管したい場合、.comなどは対応していますが、.jpと.co.jpはCloudflare Registrarが扱っていません。
DNSをCloudflareへ移すとメールは止まりますか？
MX、SPF・DKIM・DMARCのTXTが正しく取り込まれていれば止まりません。止まる原因の多くは、Quick scanでTXTやサブドメインのレコードが漏れることと、メールサーバーと同じホスト名のレコードをプロキシしてしまうことです。切り替え前に、Cloudflareの割り当てネームサーバーへdigでMXとTXTを問い合わせ、旧DNSと同じ答えが返るかを照合してください。
Cloudflareでドメインを新しく取得することはできますか？
Cloudflare Registrarで対応TLDのドメインを新規に取得できます。その場合、DNSは最初からCloudflareに置かれ、他社のネームサーバーへは変えられません。料金の仕組みや対応TLD、APIでの登録は、Cloudflare Registrarの解説記事にまとめています。国内の.co.jpを使うなら、国内レジストラで取得してから、この記事の手順でDNSを移します。
関連記事
- Cloudflare Registrarの移管手順と料金｜.jp非対応・API登録の実装【2026年9月版】：DNSを移した後、レジストラまでCloudflareへまとめる場合の手順です
- Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ：ゾーンを移した後に独自ドメインで動かせるサーバーレス実行環境です
- 名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法：切り替え前後の確認に使うdigの読み方です
- DNSSECとは？DNSの安全性を守る仕組みと役割・導入手順：切り替えで一度外して付け直すDNSSECの仕組みです
- Amazon Route 53とは：DNS・ドメイン登録・ルーティング設計とAWS CLI構築手順：AWS側にDNSを置く場合の比較先です
