2026.09.26 プラットフォーム

Cloudflare Registrarの移管手順と料金｜.jp非対応・API登録の実装【2026年9月版】

Cloudflare Registrarの移管手順と料金｜.jp非対応・API登録の実装【2026年9月版】

Cloudflare Registrarは、ドメインをレジストリの卸値そのままで登録・更新できるCloudflareのレジストラ機能です。上乗せが無い代わりに、権威DNSはCloudflare固定で、日本の企業が使う.jpや.co.jpは扱っていません。この記事では2026年9月時点の公式ドキュメントをもとに、移管の前にRDAPで60日ルールとロック状態を確かめるコマンド、ダッシュボードでの移管手順、2026年4月にベータ公開されたRegistrar APIでの登録実装、更新と他社への移管し直しまでを、コピーして使える形で整理しました。

まとめ：Cloudflare Registrarを選ぶ条件と移管前に確かめる3つの制約

Cloudflare Registrarが向くのは、.comや.devなどの汎用ドメインを持ち、DNS・Pages・Workersを既にCloudflareへ寄せている構成です。更新のたびに上乗せ価格を払っている場合、移管すれば毎年の費用は卸値まで下がります。

移管を決める前に、3点を確かめてください。対象のドメインが対応TLDに入っているか（.jpは不可）。ネームサーバーをCloudflareから動かせなくなってよいか。登録または前回の移管から60日が過ぎているか。1つでも満たせないなら、レジストラは今のままにして、DNSだけをCloudflareへ向ける構成を選びます。

Cloudflare Registrarの料金の仕組みとネームサーバー固定の仕様

最初に、他のレジストラと何が違うのかを揃えておきます。違いは価格の決め方とDNSの縛りの2つです。

卸値そのままの料金体系とdomain-checkで実額を確かめる方法

公式FAQは、登録料を「レジストリとICANNの定価そのままで、上乗せは無い」と説明しています。価格はTLDごとにレジストリが決めるため、同じ.comでもレジストリが値上げすればCloudflareの価格も上がります。安さの理由は割引でなく、利益を乗せていないことです。

実額は、APIのdomain-checkで取るのが確実です。レジストリへ問い合わせた現在の状態と価格が返り、1回で20ドメインまで調べられます。

export ACCOUNT_ID="<アカウントID>"
export CLOUDFLARE_API_TOKEN="<Registrarの書き込み権限を持つトークン>"

curl --request POST \
  --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/registrar/domain-check" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{"domains": ["example-corp.dev", "example-corp.com"]}'

請求は米ドル建てです。2026年4月15日のCloudflareブログの応答例では、.devの登録費用が"currency": "USD"、"registration_cost": "10.11"で返っています。円での支払額は為替で毎年変わるので、予算は円の固定額でなくドル建てで持ってください。

権威DNSをCloudflareに固定するフルセットアップ必須の条件

見落とされやすいのがDNSの縛りです。移管手順のドキュメントは、Cloudflare Registrarのドメインは権威DNSにCloudflareを使うフルセットアップが前提だと明記しています。FAQでも、Cloudflare以外のネームサーバーへは変更できないと答えています。

つまり、Route 53や他社DNSでゾーンを持ち続けたまま、レジストラだけをCloudflareへ移すことはできません。CNAMEだけをCloudflareへ向けるパーシャルセットアップとも両立しません。ドメインの登録先とDNSの置き場所が一体になる点が、他のレジストラとの一番の違いです。DNSの置き場所として何を失うかは、Cloudflareの危険性は本当か？障害・SLA・情報漏えいの実態と対策で整理しています。

.jpと.co.jpが対象外になる対応TLDの範囲と2026年9月時点の状況

公式ドキュメントは400以上のTLDに対応するとしていますが、国別ドメインは限られます。TLDポリシーのページに載っている2文字のccTLDは、2026年9月26日時点で.ca、.cc、.co、.fm、.me、.mx、.nz、.tv、.uk、.usです。.jpは無く、.co.jpも登録・移管できません。

日本の企業サイトで多い.co.jpは、この時点で対象外です。コーポレートドメインは現在のレジストラに残し、Cloudflareへ移すのはサービス用の.comや.devなど汎用ドメインだけ、という分け方が現実的です。ダッシュボードの検索で候補に出ないTLDは、登録できないと判断して構いません。

移管前に現レジストラで済ませる準備とRDAPでの事前確認コマンド

移管が止まる原因の多くは、Cloudflare側ではなく現在のレジストラ側の状態にあります。ダッシュボードを開く前に、次の3つを片付けます。

登録後60日ルールとロック状態をRDAPのstatusで確かめる手順

ICANNのTransfer Policyに基づき、登録または前回の移管から60日以内のドメインは移管できません。登録者の氏名・組織・メールアドレスを60日以内に変えた場合も同じです。登録日とロック状態は、WHOISの後継であるRDAPで確かめられます。.comと.netならVerisignのRDAPが使えます。

# 登録日・満了日・ロック状態を確認する（.comの例）
curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq '{status: .status, events: [.events[] | {(.eventAction): .eventDate}]}'

2026年9月26日にcloudflare.comを対象に実行すると、statusにclient transfer prohibitedが含まれ、eventsにregistration、expiration、last changedの日付が返りました。移管したいドメインでこのclient transfer prohibitedが出ている間は、現在のレジストラでロックを外すまで先へ進めません。server transfer prohibitedはレジストリ側のロックで、利用者の操作では外れないため、現在のレジストラへ問い合わせます。

DNSSECの無効化とDSレコードのTTL待ちで移管が止まる典型例

DNSSECを有効にしているドメインは、移管前に現在のレジストラで無効化します。移管トラブルのドキュメントは、無効化した後にDSレコードのTTLが切れるまで、通常24時間待つよう求めています。待たずにネームサーバーを切り替えると、古い署名を信じたリゾルバが名前解決に失敗し、サイトとメールが止まるのが典型的な事故です。

手順は「DSを外す、24時間待つ、ネームサーバーを切り替える、移管を終える、CloudflareでDNSSECを有効にし直す」の順です。DNSSECの仕組みそのものはDNSSECとは？DNSの安全性を守る仕組みと役割・導入手順で扱っています。

DNSレコードとMXの退避をdigとエクスポートAPIで取っておく手順

移管が終わると、元のレジストラのDNS設定画面には入れなくなることがあります。Cloudflareへゾーンを追加すると既存レコードを自動で読み取りますが、MXやTXT、サブドメインのレコードが漏れることがあるため、切り替え前に両側で突き合わせてください。Cloudflareへ取り込んだ後は、DNSレコードのエクスポートAPIでBIND形式の控えを残せます。

# 切り替え前：現在の権威DNSから主要レコードを控える
for t in A AAAA CNAME MX TXT; do dig +noall +answer example.com $t; done > before.txt

# 取り込み後：CloudflareのゾーンをBIND形式で保存する
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" > zone-backup.txt

特にメールのMXとSPF・DKIMのTXTは、漏れても気付くのが遅れます。digの読み方は名前解決とは？dig/nslookupでの確認方法を参照してください。

Cloudflareのダッシュボードで移管を完了させる7工程と所要日数の目安

準備が済めば、Cloudflare側の操作は30分ほどで終わります。時間がかかるのは、その後の旧レジストラの承認待ちです。

ゾーン追加からActive化・認可コード入力・承認までの7つの操作順

公式の移管手順は次の7工程です。順番を入れ替えると、認可コードの入力欄が表示されません。

  1. ドメインをCloudflareに追加し、現在のレジストラでネームサーバーをCloudflare指定の2つへ変える
  2. ゾーンのステータスがActiveになるまで待つ
  3. 現在のレジストラでドメインのロックを外す
  4. 現在のレジストラから認可コード（auth code）を取得する
  5. Cloudflareのダッシュボードで認可コードを入力し、支払いを確認する
  6. 登録者の連絡先情報を入力する
  7. 現在のレジストラから届く移管承認に応じる

つまずくのは2番目です。ゾーンがActiveになる前は、移管対象の一覧にドメインが出てきません。ネームサーバーの変更は反映まで時間がかかるため、1番目と3番目以降は日を分けるくらいの気持ちで進めてください。

移管で登録期間が1年延長される費用と10年上限で拒否されるケース

移管には1年分の登録料がかかり、そのぶん満了日が1年延びます（一部のccTLDは除く）。移管の費用は捨て金ではなく、次回更新の前払いと考えられます。

例外は、長期で登録しているドメインです。多くのTLDは登録期間の上限が10年、.coは5年で、移管で1年足すと上限を超える場合は拒否されます。満了日が9年以上先にあるドメインは、残り期間が減ってから移すしかありません。

3〜5営業日を過ぎても移管が進まないときに見るWHOISステータスと失敗原因

移管は通常3〜5営業日、TLDによっては最大10日かかります。それを過ぎても進まないときは、トラブルシューティングのドキュメントにある原因を上から疑います。

症状 主な原因
一覧に出ない ゾーンがActiveでない
コードを拒否 認可コードの期限切れ
旧側で拒否 ロックや保護機能が残る
移管不可の表示 clientHoldなどの状態
保留になる 15日以内のメール未確認

最後の行は見落としやすい項目です。ICANNの要件で、登録者メールの確認を15日以内に済ませないとドメインが保留されます。連絡先のメールアドレスは、退職者の個人アドレスでなく、部署で受けられるアドレスにしておいてください。

Registrar APIでドメインを検索・登録する実装とベータ版の制約

2026年4月から、ダッシュボードを開かずにAPIでドメインを取れるようになりました。案件ごとにドメインを取る開発会社や、検証環境を多数立てるチームに向く機能です。

domain-searchで候補を出し価格を並べるリクエスト例

Registrar APIのドキュメントによると、流れは「検索、可用性の確認、登録」の3段階です。domain-searchはキーワードから候補を作るエンドポイントで、キャッシュを引くため速い反面、最新とは限りません。登録の直前には、前述のdomain-checkで必ず取り直してください。

curl -s --request GET \
  --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/registrar/domain-search?q=acme%20corp&limit=3" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  | jq -r '.result.domains[] | [.name, .registrable, .pricing.registration_cost] | @tsv'

APIトークンには、Registrarの書き込み権限が要ります。ベータの時点では、ダッシュボードで扱えるTLDの一部しかAPIに出ておらず、非対応のTLDはextension_not_supported_via_apiが返ります。

registrationsの非同期応答と登録状態のポーリング実装

登録はregistrationsへのPOSTで始まります。既定では最大10秒待ち、その間に終われば201 Created、終わらなければ202 Acceptedが返る仕様です。Prefer: respond-asyncを付けると、待たずにすぐ返ります。

# 登録を開始する（既定の支払い方法に即時課金され、返金されない）
curl -s --request POST \
  --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/registrar/registrations" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Prefer: respond-async" \
  --data '{"domain_name": "example-corp.dev"}'

# 状態が in_progress の間だけ10秒おきに確認する
while :; do
  state=$(curl -s "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/registrar/registrations/example-corp.dev/registration-status" \
    --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" | jq -r '.result.state')
  echo "$state"; [ "$state" != "in_progress" ] && break; sleep 10
done

状態はin_progress、succeeded、failed、action_required、blockedの5つです。action_requiredとblockedは人の対応が要るので、ループを抜けたら通知へ回します。APIで取ったドメインはauto_renewが既定でfalseです。ダッシュボードの既定（自動更新が有効）と逆なので、登録後に必ず確認してください。

更新・移管・連絡先変更がAPI未対応のベータ版で自動化を止める範囲

ベータのAPIでできるのは、検索・可用性の確認・新規登録までです。更新、移管、連絡先の変更は未実装で、今後対応するとされています。既存ドメインの移管を一括で自動化したい場合、2026年9月時点ではダッシュボード操作が残ります。

ブログでは、Cloudflare MCPを通じてCursorやClaude CodeなどのAIエージェントから同じ機能を呼べると案内しています。ただし登録は即時課金で返金が無いため、エージェントに登録まで任せる運用は勧めません。検索と価格確認までをエージェントに任せ、登録のPOSTは人が確認してから流す分担が安全です。

移管後の更新・WHOIS非公開・他社への移管し直しで運用中に押さえる仕様

移管した後に困るのは、更新の失敗と、将来ほかへ移したくなったときです。どちらも手順は決まっています。

満了30日前の自動更新と3回の再試行・支払い失敗時の30日猶予期間

更新のドキュメントによると、自動更新は満了日の30日前に実行されます。失敗するとメールが届き、さらに3回まで再試行される仕組みです。それでも失敗した場合は手動更新が必要で、満了後は30日間のRedemption Grace Period（RGP）に入り、追加費用を払えば取り戻せます。

手動更新は最大10年まで選べます。更新はすべて確定扱いで返金されません。法人カードの有効期限切れで自動更新が落ちる事故が多いので、支払い方法の期限と、通知メールの宛先を年1回は見直してください。

無料のWHOIS非公開を有効にしても登録者の都道府県と国は公開される範囲

WHOIS情報の非公開は、レジストリが許す範囲で無料で有効になります。ただしWHOIS非公開のドキュメントのとおり、登録者の都道府県と国はICANNのポリシーにより公開されたままです。ネームサーバー、ロック状態、登録日などの日付も見えます。

個人名義で取ったドメインを移す場合、住所の都道府県までは出ると理解しておいてください。法人で管理するなら、登録者を会社名義にしておくほうが扱いやすくなります。

Cloudflareから他社へ移管し直すときのロック解除と5日目の自動承認

出口の手順も公式に用意されています。他社への移管のドキュメントでは、ダッシュボードのManage Domainsから対象を選び、Configurationでロックを外すと認可コードが表示される流れです。移管先でそのコードを入力すると、手動で承認しなくても5日目に自動で承認されます。

移管してから60日以内は、ここでも動かせません。ネームサーバーを他社へ戻したいときは、先に移管先でDNSを用意してから移管を始め、完了後にネームサーバーを切り替える順にしてください。移管が終わるとドメインはCloudflareのアカウントから消えます。

受託開発の現場でCloudflare Registrarを採用する条件と見送る場面

ここからは判断です。料金だけを見れば移さない理由は少ないものの、構成によっては移管が負債になります。

DNS・Pages・Workersを既にCloudflareへ寄せている構成の採用基準

採用してよいのは、権威DNSを既にCloudflareで持ち、サイトをCloudflare PagesやCloudflare Workersで配信している構成です。この場合、フルセットアップ必須という縛りは既に受け入れているので、失うものは実質ありません。レジストラとDNSの管理画面が1つになり、更新忘れの確認先も1か所で済みます。

汎用ドメインを10本以上持ち、それぞれに上乗せ価格を払っている会社も採用候補です。新規取得はAPIで自動化でき、案件ごとにドメインを取る運用とも噛み合います。

.co.jpの企業ドメインやRoute 53前提の構成で見送る判断

見送るのは3つの場面です。第一に、移したいのが.co.jpや.jpの場合で、そもそも対象外となります。第二に、DNSをAmazon Route 53で持ち、ALBやCloudFrontへのエイリアスレコードで構成している場合です。エイリアスはAWS独自の仕組みなので、Cloudflareへ移すとCNAMEで組み直すことになり、1ドメインあたりの上乗せ分を節約するより、移行の工数のほうが高く付きます。

第三に、将来CDNやWAFを他社へ替える計画がある場合です。ネームサーバーを動かせない以上、DNSの乗り換えはレジストラの移管し直しとセットになり、60日ルールの待ちも発生します。DNSとクラウドの構成をどこに寄せるかは、ドメインの年額より先に決めるべき設計です。AWSとCloudflareのどちらにDNSを置くかを含めた構成の見直しは、インフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。

よくある質問

Cloudflare Registrarの移管と運用で、検索の多い5点に公式ドキュメントの記載をもとに答えます。

Cloudflare Registrarでドメインを新規取得する方法はありますか？

はい、取得可能です。ダッシュボードのドメイン登録画面で検索して登録するか、前述のRegistrar APIでregistrationsへPOSTします。どちらも事前に、アカウントへ有効な支払い方法と既定の登録者連絡先を設定しておく必要があります。登録完了と同時に課金され、返金はありません。APIで取った場合は自動更新が既定で無効なので、登録後に有効化してください。

Cloudflare Registrarは.jpドメインに対応していますか？

2026年9月26日時点で対応していません。TLDポリシーのページに載っている国別ドメインは.ca、.cc、.co、.fm、.me、.mx、.nz、.tv、.uk、.usで、.jpと.co.jpは含まれません。.co.jpのDNSだけをCloudflareで運用することは可能で、その場合はレジストラを現在の事業者に残し、ネームサーバーだけをCloudflareへ向けます。

移管するとサイトやメールは止まりますか？

手順どおりなら止まりません。止まる原因はほぼ2つで、ゾーン追加時にMXやTXTなどのレコードが漏れることと、DNSSECを外してからDSのTTLが切れる前にネームサーバーを切り替えることです。切り替え前にdigで主要レコードを控え、DNSSECは24時間待ってから進めてください。移管そのものはDNSの応答に影響しません。

移管にかかる日数と費用はどれくらいですか？

Cloudflare側の操作は30分ほどで、完了までは通常3〜5営業日、TLDによっては最大10日です。費用は1年分の登録料で、満了日がそのぶん1年延びます。価格はTLDごとの卸値で、domain-checkのAPIか、ダッシュボードの移管画面で実額を確認可能です。請求は米ドル建てなので、円の支払額は為替で変わります。

Cloudflare Registrarと他のレジストラの違いは何ですか？

大きな違いは、上乗せの無い卸値であることと、ネームサーバーがCloudflareに固定されることの2点です。多くのレジストラは初年度を安くして更新料を上げますが、Cloudflareは登録と更新で価格の決め方が同じです。その代わり、DNSを他社で持つ構成は選べません。Route 53でのドメイン登録との比較は、Route 53の解説記事で扱っています。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る