Cloudflare Registrarへのドメイン移管：20個のドメイン維持費を削減した移行記録

個人開発の運用費におけるドメイン維持費の位置付け

しかし、ドメインはそう簡単に減らせない。

サービスを停止しない限り、ドメインは毎年更新する必要がある。開発中のサービス、公開中のWebアプリ、検証用のドメイン、メール専用のドメインなど、用途が残っている限り更新費用は発生し続ける。しかも、ドメインごとに更新日が異なるため、金額だけでなく管理の手間も増える。

筆者は20個のドメインを運用していた。取得時期がばらばらなので、更新通知は一年のどこかで継続的に届く。月初に通知が来たと思ったら、別のドメインが月末に更新を迎える。ドメインの数が増えるほど、更新作業そのものよりも、更新対象を把握し続けることが負担になっていった。

更新を忘れれば、サービスが突然表示できなくなる。メールをドメインに依存している場合は、受信や送信にも影響する。Whois情報公開代行の設定がドメインごとに違えば、不要なオプション費用まで見逃しやすい。

それでも移管を後回しにしていたのは、ドメイン維持費はどのレジストラを使っても大差ないと考えていたからだ。移管にはAuthCodeの取得やネームサーバーの確認が必要で、サービスを止める可能性もある。数百円、数千円の差のために作業するほどではない、と判断していた。

20個単位で見直すと、その考え方は変わる。1個あたりの差額が小さくても、毎年発生し、複数年にわたって積み重なる固定費なら、移管作業にかける時間を考慮しても検討する価値がある。

ドメイン維持費は一度見直せば、翌年以降も効き続ける。個人開発では、派手な節約よりこの種の固定費の整理が効く。

Cloudflare Registrarの料金構造が原価を実現する理由

卸売価格を基準にした料金体系

Cloudflare Registrarのメリットを理解するには、登録料金の安さだけでなく、料金がどのように決まっているかを見る必要がある。

一般的なレジストラでは、レジストリが定める卸売価格をもとに、レジストラ側の手数料やサービス維持費、オプション料金などが加わる。キャンペーンで初年度の取得費用が安くても、更新時には通常料金に戻るケースがある。取得時の価格だけを比較すると、長期的な所有コストを見誤りやすい。

Cloudflare Registrarは、公式にはレジストリの卸売価格に基づく料金でドメインを提供する方針を取っている。適用されるTLDでは、ICANN手数料として1ドメインあたり年額0.18米ドルが加算される。つまり、通常のレジストラのように、卸売価格へ大きな利益を上乗せして販売するモデルではない。

ここでいう安さは、期間限定の割引ではない。更新時だけ価格が上がるキャンペーン型の安さでもない。ドメインを保有している間の料金構造そのものが異なる。

TLDによって卸売価格は異なるため、すべてのドメインが同じ割合で安くなるわけではない。それでも、複数ドメインを長期間維持する場合は、登録時のキャンペーン価格よりも、更新時に何が請求されるかを比較したほうが実態に近い。

付帯機能を別料金で考えなくてよい

ドメインの費用比較では、更新料金だけに目が向きやすい。しかし、実際の請求額には付帯機能の料金も含まれる。

代表的なのがWhois情報公開代行だ。ドメイン所有者の情報を公開しないための機能だが、レジストラによっては有料オプションとして扱われる。1個では小さな金額でも、20個分になると無視しにくい。ドメインごとに設定状況を確認しなければならない点も面倒だ。

Cloudflare Registrarでは、対応するドメインについてWhois情報の保護が標準的に提供される。DNSSECも追加費用なしで利用できる。アカウントの2要素認証も別料金の機能ではなく、アカウント保護のために利用できる。

ただし、これらは「何もしなくても安全になる」という意味ではない。Cloudflareアカウントの認証が弱ければ、レジストラの料金が安くても管理全体のリスクは下がらない。2要素認証を有効化し、APIトークンを使う場合は権限を絞る必要がある。

円建ての請求と米ドル建ての請求

Cloudflare Registrarの料金は米ドルで表示・請求される。国内レジストラの円建て料金に慣れていると、ここは見落としやすい。

米ドル建てには為替変動のリスクがある。登録時には安く見えても、更新時の為替レートによって日本円での支払額は変わる。クレジットカード会社の換算レートや海外利用に関する条件も確認しておいたほうがよい。

一方で、国内レジストラの円建て料金が常に有利とは限らない。円建てで金額が固定されていても、卸売価格への上乗せや有料オプションが含まれている場合がある。比較するときは、表示通貨ではなく、TLDごとの更新費用と付帯費用を合わせて考えるべきだ。

Cloudflare Registrarが常に最安とは限らない。対象TLDかどうか、為替、現在の契約プラン、既存レジストラの割引条件によって結果は変わる。大切なのは、初年度の取得費用ではなく、更新を何度も繰り返した場合の所有コストを比較することだ。

移管前に把握すべき60日ルールとネームサーバーの制約

料金だけを見て移管を始めると、途中で止まる。Cloudflare Registrarへの移管には、ドメインそのものの制約と、DNS運用上の制約がある。

新規登録・移管後の60日制限

一般的なgTLDでは、新規登録直後や、前回のレジストラ移管から一定期間が経過していないドメインは、別のレジストラへ移管できない。代表的な制限が60日ルールである。これはCloudflare固有の制限ではなく、ICANNの移管ポリシーに関係する仕組みだ。

20個のドメインをまとめて移管する場合、すべてのドメインが同じ状態とは限らない。

• 最近取得したドメイン
• 最近別レジストラから移管したドメイン
• 登録者情報を変更したばかりのドメイン
• すでに移管ロックが設定されているドメイン
• TLD側のルールで移管条件が異なるドメイン

このため、作業前にドメインの一覧を作り、取得日、前回移管日、更新日、現在のレジストラ、TLD、移管ロックの状態を確認した。20個あると、記憶だけで判断するのは難しい。表計算ソフトでもよいので、ドメインごとの状態を一つの場所にまとめておくと、対象外のドメインを誤って処理せずに済む。

更新日が近いドメインは、移管の完了を待つか、先に更新するかも判断する必要がある。移管には時間がかかる場合があるため、失効直前に作業を始めるのは危険だ。

Cloudflare DNSへの移行が前提になる

Cloudflare Registrarを利用する場合、対象ドメインのネームサーバーはCloudflareが提供するものに設定する必要がある。レジストラだけCloudflareに移し、DNSはRoute 53や別のDNSサービスに残す、という構成は選べない。

ここは価格比較だけでは見えにくい、Cloudflare Registrarの大きな制約である。

すでにCloudflare DNSを利用している場合は問題になりにくい。CloudflareのCDNやWAFを利用しているサイトなら、ネームサーバーもCloudflareに向いているケースが多い。

一方で、AWS Route 53、NS1、DNS Made Easyなどを使っている場合は、DNSレコードをCloudflare DNSへ移す必要がある。DNSを移すだけなら簡単に見えるが、実際には次のような依存関係が隠れている。

• サブドメインごとのWebサーバー
• メールサービスのMXレコード
• SPF、DKIM、DMARCなどのメール認証
• 外部サービスの所有確認用TXTレコード
• APIや管理画面専用のサブドメイン
• DNSベースのヘルスチェックやフェイルオーバー
• CDN、WAF、ロードバランサーの名前解決

ネームサーバーを切り替えても、DNSレコードが正しく移行されていなければ、Webサイトやメールが止まる。ドメイン移管とDNS移行は別の作業だが、Cloudflare Registrarでは実質的に同時に設計しなければならない。

TLDごとの対応可否を先に確認する

Cloudflare Registrarは主要なgTLDに対応している一方、すべてのTLDを扱っているわけではない。特に日本で使われる「.jp」や「.co.jp」は、Cloudflare Registrarへの移管対象外である。

そのため、20個のドメインを持っていても、20個すべてをCloudflareへ集約できるとは限らない。.comや.netなどの移管可能なドメインだけをCloudflareに移し、.jpや.co.jpは別のレジストラに残す構成になることがある。

Cloudflareの対応TLD一覧は変更される可能性がある。移管前には、Cloudflareの公式ドキュメントと、移管画面で表示される対応状況を確認したほうがよい。ドメイン名の末尾だけで判断せず、登録・更新・移管のそれぞれに対応しているかを見るのが安全だ。

Cloudflare Registrarへの移管は、レジストラの引っ越しだけではない。ネームサーバーの移行を受け入れられるかが、最初の分岐点になる。

移行プロセスをスムーズに進めるための事前準備

移管申請でつまずく原因は、複雑な技術処理よりも、既存レジストラ側の設定にあることが多い。作業を始める前に、ドメイン単位で状態をそろえる必要がある。

ドメインロックを解除する

移管対象のドメインには、他社への移管を防ぐロックが設定されていることが多い。レジストラの管理画面では、ドメインロック、移管ロック、Transfer Lockなどの名称で表示される。

このロックを解除しないままAuthCodeを入力しても、移管申請が進まない。解除後すぐに反映されるレジストラもあれば、管理画面上の表示が変わるまで時間がかかる場合もある。

20個を一度に処理するなら、すべてのドメインについて解除状態を記録しておくとよい。画面上で解除済みに見えても、移管申請側からロック中と判定されることがあるため、申請前に再確認する。

Whois情報公開代行の扱いを確認する

Whois情報公開代行は、移管の前後で扱いが変わることがある。レジストラによっては、移管前に公開代行を解除する必要がある。解除すると登録者情報が公開される可能性があるため、手続きのために必要な期間と、移管完了後の保護状態を確認しておく。

登録者メールアドレスも重要だ。移管承認の通知は、現在の登録者情報に設定されているメールアドレスへ送信される。古いメールアドレスや、普段確認していない転送先になっている場合、承認メールを見落とす。

Whois情報を変更した直後は、移管に関する制限が発生することもある。メールアドレスの変更と移管を同じ日に行うのではなく、登録者情報が正しいことを先に確認したほうが安全だ。

AuthCodeを取得する

AuthCodeは、ドメインを現在のレジストラから移管するための認証コードだ。レジストラによっては、管理画面ですぐ表示される。別のレジストラでは、メール送信やサポートへの依頼が必要になる。

コードを取得したら、対象ドメインとの対応を間違えないように管理する。20個分をまとめてコピーすると、ドメイン名とコードの組み合わせを取り違えやすい。パスワード管理ツールやアクセス制限されたメモに、ドメインごとに記録しておくと扱いやすい。

AuthCodeには有効期限が設定されている場合がある。取得してから長期間放置するのではなく、ドメインロック解除や登録者メールアドレスの確認を終えてから、移管申請に使うのがよい。

移管前の準備は、次の順番にすると作業が分断されにくい。

1. TLDがCloudflare Registrarの対象か確認する。

2. 60日ルールや登録者情報変更による制限がないか確認する。

3. 現在のDNSレコードを保存する。

4. Cloudflare DNSに同じレコードを作成する。

5. 移管ロックとWhois情報公開代行の状態を確認する。

6. 登録者メールアドレスが受信可能か確認する。

7. AuthCodeを取得する。

8. Cloudflare側から移管申請を行う。

この順番なら、移管申請を先に出したあとでDNSレコードの不足に気づく事態を避けやすい。

移管申請から完了までの流れ

Cloudflare側で移管申請を行うと、既存レジストラとの間で手続きが進む。一般的な流れは次のとおりだ。

1. Cloudflareの管理画面で移管対象のドメインを選ぶ。

2. AuthCodeを入力して申請する。

3. 現在のレジストラから承認メールが送信される。

4. 登録者が承認手続きを行う。

5. レジストリとレジストラ間で移管処理が行われる。

6. Cloudflare Registrar側で管理可能になる。

承認メールを見落とすと、処理が止まったままになる。メールの差出人や件名はレジストラによって異なるため、申請前に迷惑メールフォルダやGmailのフィルタ設定を確認しておく。

移管申請後は、ドメインを利用しているサービスに異常がないかを見る。移管そのものはDNSレコードを自動的に完全移行する作業ではない。ネームサーバーが変わる場合は、移管状態とは別に、名前解決の状況も確認しなければならない。

移管の進行状況がすぐ変わらなくても、ただちに失敗とは限らない。承認メールの状態、移管ロック、AuthCodeの有効性を順番に確認する。何度も申請をやり直すより、現在どの段階で止まっているかを確認したほうが早い。

移管作業で最も起こりやすい事故は、難しい設定ミスではなく、承認メールの見落としとDNSレコードの移行漏れである。

移管手数料と更新期間の考え方

一般的なgTLDの移管では、移管料金の支払いによって登録期間が延長される形になる。単純な作業手数料だけを支払って終わるわけではなく、ドメインの有効期間に1年分が加算される扱いが基本だ。

そのため、Cloudflare Registrarへの移管は実質的に更新タイミングの調整も兼ねる。現在の有効期限、移管料金、移管後の更新料金を確認し、移管直後に再度更新が必要にならないように計画する。

ただし、TLDによってルールは異なる。移管による期間加算の扱いや、移管できる時期、更新期限との関係が一律とは限らない。画面に表示された料金と有効期限を確認し、一般的なgTLDのルールをそのまますべてのドメインへ適用しないことが大切だ。

DNS設定移行時の技術的注意点

移管前にDNSレコードを棚卸しする

DNSレコードは、普段は意識しないまま運用されている。Webサイトが表示されているからといって、必要な設定をすべて把握できているとは限らない。

移管前には、既存DNSサービスのゾーン情報をエクスポートする。エクスポート機能がなければ、レコードの一覧を手元に保存する。確認対象は次のとおりだ。

• Aレコード、AAAAレコード
• wwwなどのCNAMEレコード
• MXレコード
• SPFに使うTXTレコード
• DKIMのTXTレコードまたはCNAMEレコード
• DMARCのTXTレコード
• 外部サービスの所有確認に使うTXTレコード
• 開発環境や管理画面用のサブドメイン
• Microsoft 365やGoogle Workspaceなど、メールサービスが指定するレコード
• 認証局の証明書発行に使うCAAやCNAMEレコード

特に見落としやすいのが、普段アクセスしないサブドメインとTXTレコードだ。Webサイトだけを確認して移管を完了したつもりでも、メール配信、SSL証明書の更新、外部サービスとの連携が後から壊れることがある。

Cloudflare DNSへレコードを作成するときは、Cloudflareプロキシを有効にするかどうかも確認する。WebサイトのHTTP通信ではプロキシを利用できても、メール用のMXレコードや、特定のポートを使うサービスでは同じ扱いにできない。移管の機会に設定を変えすぎると、原因の切り分けが難しくなるため、まずは既存構成を忠実に再現するほうが安全だ。

TTLを短くする意味と限界

ネームサーバーを切り替える予定がある場合、主要なDNSレコードのTTLを事前に短くしておく方法がある。たとえば300秒、つまり5分程度に設定しておけば、キャッシュの有効期間を短くできる。

ただし、TTLを短くすればすべての環境で即座に切り替わるわけではない。すでにキャッシュされている情報、リゾルバー側の挙動、ネームサーバー委任の伝播など、複数の要素が関係する。TTL短縮は切り替え時間を抑えるための施策であり、ダウンタイムを完全になくす保証ではない。

変更は移管直前だけでなく、余裕を持って行う。切り替え後に問題があった場合、元の値へ戻す時間も必要になる。長いTTLのまま作業を進めるより、事前に短縮しておいたほうが復旧しやすい。

メールをWebサイトより優先して確認する

Webサイトはブラウザで表示すれば確認できるが、メールは送信元や受信先によって挙動が異なる。DNS移行では、メールの確認を後回しにしないほうがよい。

移管前に、実際に利用しているメールアドレスへテストメールを送信し、外部のメールアドレスから返信を受け取れる状態を確認する。移管後も同じ確認を行う。

確認するのは受信だけではない。

• 自分のドメインから外部宛てに送信できるか
• 外部から自分のドメイン宛てに送信できるか
• 迷惑メール扱いになっていないか
• SPF、DKIM、DMARCの認証結果に異常がないか
• メールサービスの管理画面に警告が出ていないか

MXレコードが正しくても、SPFやDKIMのTXTレコードが欠けると、送信メールの信頼性に影響する。Cloudflare DNSのレコード一覧だけでなく、利用中のメールサービス側の診断情報も確認する。

.jpドメインを含む場合の管理戦略

20個のドメインの中に「.jp」や「.co.jp」が含まれている場合、Cloudflare Registrarだけで管理を完結できない。対応しているgTLDをCloudflareへ移し、日本のccTLDは別のレジストラに残す運用が現実的だ。

「.jp」や「.co.jp」は、単に安いかどうかだけで判断しにくい。法人名やサービス名に結びついている場合、ドメインを手放すことでブランド保護の範囲が狭くなる。将来使う可能性があるドメインなら、更新費用を保険料として残す判断もある。

一方、開発時に試しに取得しただけで、アクセスもメールも使っていないドメインなら、移管先を探す前に更新をやめる選択肢もある。Cloudflare Registrarへ移せないドメインを無理に維持し続けるのではなく、用途、アクセス、メール利用、ブランド上の必要性を個別に見直すべきだ。

管理レジストラが分かれること自体は、必ずしも悪いことではない。重要なのは、どのドメインがどこで管理され、いつ更新され、誰が請求を確認するのかが分かる状態を作ることだ。

移管後の運用工数とAPI自動化

Cloudflare Registrarへ移管したあと、作業は終わりではない。むしろ、20個のドメインを一つの管理方針で運用できるようになったかを確認する段階に入る。

まず、Cloudflareの管理画面で次の状態を確認する。

• ドメインの有効期限
• 自動更新の設定
• 移管ロックの状態
• ネームサーバーの委任状態
• DNSSECの状態
• 登録者情報と連絡先メールアドレス
• 支払い方法と請求先情報

自動更新は便利だが、使っていないドメインまで更新してしまう可能性がある。自動更新を有効にするドメインと、期限前に判断するドメインを分ける運用も考えられる。重要なサービス用ドメインは自動更新、検証用や停止予定のドメインは手動確認というように、用途で方針を変えると管理しやすい。

APIを使う場合の権限管理

ドメイン数が増えると、管理画面を開いて一つずつ期限を確認する方法は負担になる。Cloudflare APIを使えば、アカウント内のドメイン情報を取得し、更新期限の監視や通知に利用できる。

たとえば、定期実行する処理でドメインの有効期限を確認し、一定期間を切ったものだけ通知する仕組みを作れる。Slackやメールへ通知すれば、更新日をカレンダーだけに頼らずに済む。Cloudflare Workers、AWS Lambda、既存の監視基盤など、手元の環境に合わせて構成すればよい。

自動化できる対象には次のようなものがある。

• ドメイン有効期限の定期取得
• 更新期限が近いドメインの通知
• 移管処理中のドメインの状態確認
• DNSレコードの変更履歴の保存
• Cloudflare DNSと管理台帳の差分確認
• 管理対象外になったドメインの検出

ただし、APIで書き込み操作まで自動化する場合は慎重にする。ドメイン更新やDNS変更は、誤操作の影響が大きい。最初は読み取り専用のトークンで期限の取得と通知だけを行い、書き込みが必要になった段階で権限を追加するほうがよい。

APIトークンは、ソースコードへ直接書かない。環境変数やシークレット管理機能を利用し、リポジトリに登録しない。権限は対象アカウントや対象ゾーンに限定し、読み取りと変更用のトークンを分ける。2要素認証を有効にしていても、APIトークンが漏洩すれば別の経路から設定を変更される可能性がある。

20個のドメインを移管して分かったトレードオフ

Cloudflare Registrarへの移管は、ドメイン維持費の削減という目的には向いている。ただし、安くなる代わりに、運用上の選択肢が狭くなる部分がある。

まず、DNSサービスをCloudflareに統一する必要がある。CloudflareのDNSやCDNを普段から利用しているなら、むしろ構成は分かりやすくなる。逆に、AWSのDNS機能や別のDNSプロバイダを中心に設計している場合は、移管前に依存関係を洗い出さなければならない。

次に、サポートの使い勝手が国内レジストラとは異なる。日本語の電話窓口や営業時間内の即時対応を重視するなら、Cloudflareのチケット中心のサポートは不便に感じる可能性がある。ドメインの料金が安くても、障害時に自分で状況を切り分けられないなら、削減できた金額以上の負担になることがある。

米ドル建ての支払いも、運用上の論点になる。毎月の固定費として円で予算を組んでいる場合、為替によって実際の支払額が動く。支払い方法の有効期限や、海外決済に関するカード会社の制限も確認しておきたい。

また、対応外TLDがあるため、管理先は完全には一本化できない。.jpや.co.jpを残す場合、ドメイン一覧、更新日、ログイン情報、請求情報を別のレジストラと合わせて管理する必要がある。レジストラを一つに集約できないからこそ、外部の管理台帳が重要になる。

移管対象を増やすほど、節約額は大きくなる可能性がある。しかし、移管できるかどうかだけで判断してはいけない。DNSをCloudflareへ寄せること、英語の管理画面やサポートを使うこと、米ドルで支払うこと、管理先が分かれることを受け入れられるかが前提になる。

個人開発者にとっての現実的な移行単位

20個すべてを一日で移管する必要はない。むしろ、稼働中のサービスをまとめて移管するより、影響の小さいドメインから始めたほうが安全だ。

最初の対象には、次のようなドメインが向いている。

• メール利用がない
• 外部サービスとの連携が少ない
• Cloudflare DNSへ移行しやすい
• 更新期限まで余裕がある
• 移管に失敗してもサービスへの影響が限定的

最初の移管で、Cloudflare DNSへのレコード登録、ネームサーバーの確認、承認メールの処理、移管完了後の検証という一連の手順を経験できる。その後、メールや決済など重要な機能を持つドメインへ広げればよい。

移管前後でDNSレコードを変更しないことも大切だ。ドメイン移管、DNSプロバイダ変更、メールサービス変更、Webサーバー変更を同時に行うと、障害が発生したときに原因を特定できない。コスト削減を目的にした作業なら、構成変更は最小限に抑えるべきだ。

移管後に問題が起きた場合の戻し方も、事前に確認しておく。ネームサーバーを元のDNSへ戻すのか、Cloudflare DNS上で修正するのか、Whois情報公開代行をどうするのかを決めておけば、焦って設定を変えずに済む。

結論：安さではなく所有コストの構造で選ぶ

Cloudflare Registrarへのドメイン移管のメリットは、単発のキャンペーン価格ではない。卸売価格を基準にした料金体系と、Whois情報保護やDNSSECなどの追加費用を抑えられる設計によって、ドメインを長く持つ場合の所有コストを下げやすい点にある。

20個のドメインを運用する個人開発者にとって、1個ごとの小さな差額は、毎年積み上がる固定費になる。さらに、管理画面や更新方針をそろえることで、更新漏れや不要なオプション費用を見つけやすくなる。cloudflare registrar ドメイン移管 メリットを考えるときは、料金表だけでなく、複数年の更新費用と管理工数まで含めて見るべきだ。

ただし、すべてのドメインを移管できるわけではない。60日ルール、AuthCode、移管ロック、登録者メールアドレス、Cloudflare DNSへの移行、対応外のTLDといった条件がある。特に「.jp」や「.co.jp」を含む場合は、Cloudflareへ移せるドメインと、国内レジストラに残すドメインを分けて考える必要がある。

移管を成功させる鍵は、安さを理由に急いで申請することではない。先にドメインの用途とDNS構成を棚卸しし、移管後もサービスとメールが動く状態を作ってから、対象を段階的に移すことだ。

ドメインは一度移管すれば、しばらく同じ場所で管理する固定資産に近い。だからこそ、取得時のキャンペーンではなく、更新費用、付帯料金、為替、サポート、DNSの制約を含めた所有コストで判断したい。個人開発の運用費を削減するなら、サーバーの細かな調整と同じくらい、ドメイン管理の構造を見直す価値がある。