ドメイン移管とは｜初心者でも失敗しない全手順と注意点まとめ

2025年1月6日2026年1月31日

「ドメイン移管」と聞くと、なんだか難しそうで不安になりますよね。
でも実は、移管そのものは“住所（ドメイン名）を変える”作業ではなく、管理会社（レジストラ）を変える手続きです。ポイントさえ押さえれば、初心者でも安全に進められます。

とはいえ、検索しているあなたはきっと、こんな疑問や悩みを抱えているはずです。

「ドメイン移管って結局なに？サーバー引っ越しと同じ？」
「移管中にサイトが止まったり、アクセスが落ちたりしない？」
「メール（info@〜）はそのまま使えるの？急に届かなくなったら困る…」
「AuthCodeって何？ロック解除ってどこでやるの？」
「JP（.jp/.co.jp）と.comで手順が違うって本当？」
「移管費用っていくら？ “更新1年が付く”ってどういうこと？」
「期限が近いけど、更新と移管はどっちが先？」
「承認メールが来ない・60日制限に引っかかる…って何それ？」

このあたりでつまずく原因は、ほとんどが共通しています。
準備不足（DNSの控え忘れ／受信できない連絡先メール／ロック未解除）か、移管中に余計な変更を重ねたことです。

この記事では、はじめて移管する方でも迷わないように、

ドメイン移管で「変わること／変わらないこと」
gTLD（.com等）とJP（.jp等）の手順の違い
DNS・メール・SSLへの影響を最小化する段取り
失敗しやすいポイントの回避策（AuthCode、ロック、60日制限、期限トラブル）
移管先選びで後悔しない評価軸（価格より大事な視点）
最後に、コピペで使えるチェックリスト

まで、全手順を一本にまとめて解説します。
読み終えるころには、「今の状況で何をすればいいか」が手元のメモに落ちる状態を目指します。

【おすすめドメインサービス↓】

お名前.com公式サイト
ムームードメイン公式サイト
XServerドメイン公式サイト
シンドメイン公式サイト
スタードメイン公式サイト

ラッコドメイン公式サイト

結論：ドメイン移管で「変わること／変わらないこと」

「ドメイン移管」は、ざっくり言うと “ドメインを管理する会社（レジストラ）を変更する手続き” です。
ここを押さえると、何が変わって何が変わらないかが一気にクリアになります。

まずは全体像を表で整理します。

スクロールできます

項目	移管で変わる？	変わらない？	補足（初心者がつまずきやすい点）
管理会社（レジストラ）	✅ 変わる	ー	管理画面・請求先・サポート窓口が変わる
支払い・更新方法	✅ 変わる	ー	自動更新や支払い方法を移管先で再確認
ドメイン名（例：example.com）	ー	✅ 変わらない	“名前そのもの”は同じ
URL（表示されるアドレス）	ー	✅ 変わらない	サイトを引っ越さない限り基本同じ
サイトの中身（記事・画像など）	ー	✅ 変わらない	これはサーバー側のデータ
DNS設定（どこへ繋ぐか）	△ 条件付き	△ 条件付き	“どこのDNSを使っているか”でリスクが変わる
メール（例：info@あなたのドメイン）	△ 条件付き	△ 条件付き	MX/SPF/DKIMなどDNS依存が多い
SSL（HTTPS）	△ 条件付き	△ 条件付き	証明書の出し元・更新方式で影響が出ることがある

移管で変わるのは“管理会社”と“支払い・管理画面”

移管で確実に変わるのは、「誰があなたのドメインを管理しているか」 です。
その結果として、次のような“運用面”が変わります。

ログインする管理画面（機能・UI・操作方法）
更新料金の請求元／支払い方法
自動更新の設定
サポート窓口（問い合わせ先・対応時間・品質）
セキュリティ設定（2段階認証、移管ロック、通知の種類など）

ここがポイントで、移管は「ドメインの所有が誰かに移る（譲渡）」とは別物です。
あくまで 管理会社が変わる だけ、という整理が大切です。

なお、移管の“可否”に関しては、登録者情報を変更した直後などに 一定期間（例：60日）移管できない ルールが絡むことがあります。これは「何が変わるか」というより “いつ移せるか” の話ですが、初心者が見落としやすいので頭の片隅に置いておくと安心です。 ICANN

基本的に変わらない：ドメイン名／URL／サイトの中身

移管で ドメイン名そのものは変わりません。
つまり、次のものは基本的にそのままです。

ドメイン名（例：example.com）
URL（記事ページやトップページのアドレス）
サイトのコンテンツ（記事、画像、データベース）
WordPressなどのCMS設定（サーバー側にあるため）

サイトの中身はサーバーに載っている ので、サーバー移行をしない限り、移管だけでコンテンツが消えることは通常ありません。

影響が出るのはここ：DNS・メール・証明書まわり（条件付き）

「移管でサイトが止まった／メールが届かなくなった」という話が出るのは、ほとんどが DNS周辺の扱い が原因です。

影響が出る典型パターンは次のとおりです。

移管元の“付属DNS（ネームサーバー）”を使っていた
- 移管を機に、そのDNSが使えなくなる／設定が引き継がれないケースがある
メールも同じ管理会社のサービスに依存していた
- MXレコードが変わる、SPF/DKIM/DMARCが欠ける…などで不達が起きる
無料SSLや自動更新が“移管元のサービス”前提だった
- 移管後、証明書の更新方式や設定を見直す必要が出ることがある

逆に言うと、次の条件を満たしていれば影響は小さくなります。

DNSを“独立したサービス”で運用している（例：Cloudflare など）
DNSレコード（A/CNAME/MX/TXTなど）を控えていて、いつでも再設定できる
メール運用があるなら、MX/SPF/DKIM/DMARCの状態を把握している

「移管＝サイト引っ越し」ではない理由

「移管」という言葉がややこしいのは、ドメインとサーバーが別物 だからです。

ドメイン：住所（どの名前でアクセスするか）
DNS：住所録（その住所がどこに繋がるか）
サーバー：家（サイトのデータが置かれている場所）

移管は、このうち “ドメインの管理会社”を変える行為。
家（サーバー）を引っ越す話ではありません。

ただし、住所録（DNS）を「管理会社の付属サービス」に任せていた場合だけ、引っ越しのような影響が出ることがあります。ここが混同の正体です。

「何もしなくても止まる？」に先回りして答える

結論から言うと、何もしなくても止まらないケースが多い です。
ただし、次の条件に当てはまると “止まる可能性” が上がります。

移管元のネームサーバーを使っている（付属DNS）
メールアドレス（@独自ドメイン）を運用している
DNSを移管先へ引き継ぐ手順が必要なのに未対応
承認メールが届かず手続きが止まっている（WHOISの受信先が古い等）
期限ギリギリで移管している（移管中に期限切れリスク）

止めないための最小アクションは、これだけ覚えておけばOKです。

今のネームサーバー（DNS）を確認して控える
DNSレコードを控える（特にA/CNAME/MX/TXT）
WHOISの受信メールが生きているか確認する
期限が十分ある時期に動く

DNSの考え方（反映のタイムラグや“伝搬”の話）は、公式の解説を一度読んでおくと理解が一気に楽になります。 JPRS

用語で迷わない：似た手続きとの違いを5分で整理

ドメイン周りは、似た言葉が多くて混乱しがちです。
ここでは「結局どれの話？」を最短で整理します。

まずは全体像を、ざっくり1枚で確認しましょう。

スクロールできます

手続き	何を変える？	目的の例	初心者が混同しやすい点
ドメイン移管	管理会社（レジストラ）	更新費用を見直す／管理を一本化	サーバー移行と混同しやすい
転入／転出	移管の“方向”	受け入れ側／出ていく側の呼び方	同じ移管でも用語が分かれる
サーバー移行	サーバー（データ置き場）	表示速度改善／乗り換え	DNS変更が絡み、移管と一緒に見える
ドメイン変更	URL（ドメイン名そのもの）	ブランド変更／別名へ統合	SEO影響が大きく、移管とは別次元
名義変更・譲渡	登録者（所有者）情報	会社名変更／売買／担当変更	“管理会社変更”ではない

ドメイン移管＝レジストラ（管理事業者）の変更

ドメイン移管は、ひと言でいうと 「管理する会社を替える」 手続きです。

変わるもの：管理画面／請求先／更新の手続き／サポート窓口
変わらないもの：ドメイン名、URL、サイトのデータ（※サーバーを変えない限り）

補足として、ドメインは大きく次の役割分担で成り立っています。

レジストリ：そのTLD（例：.jp など）を“元締め”として運用する組織
レジストラ：利用者にドメインを販売・管理画面を提供する会社
登録者（あなた）：そのドメインを使う人

移管で動くのは、このうち レジストラの部分 です。
（.jp の場合は「指定事業者」という言い方もよく出ます）

※記事内では以降、説明を簡単にするため「管理会社＝レジストラ（指定事業者）」として扱います。

転入／転出：移管を“移る側・受け入れる側”で呼び分け

「移管」と同じ話なのに、手続きページで 転入／転出 と書かれていて迷うことがあります。
これは単に、どちらの立場で説明しているか の違いです。

転出：今の管理会社から“出ていく”側の手続き
- 例）移管ロック解除、AuthCode（認証コード）発行、承認メール受信の準備など
転入：新しい管理会社へ“入ってくる”側の手続き
- 例）転入申請、AuthCode入力、支払い、承認手順など

✅ コツ：
あなたが見ているページが「今使っている会社」なら転出寄り、「これから使う会社」なら転入寄り、と思うと読みやすいです。

サーバー移行（サイト引っ越し）との違い

ここが最大の混同ポイントです。
結論から言うと、移管＝サーバー移行ではありません。

ドメイン移管：管理会社（レジストラ）を変える
サーバー移行：サイトのデータ（WordPressや画像など）を置く場所を変える

ただし、見た目が“引っ越しっぽく”なる理由があります。
それは DNS（どこに接続するか） が絡むからです。

サーバー移行では、ほぼ必ず DNSの向き先 を変えます
移管でも、次の条件だと DNS設定の見直しが必要 になることがあります
- 管理会社の“付属DNS”を使っていた
- メール設定（MX/SPF/DKIM/DMARC）がDNSに依存している

⚠️ つまり、止まるとしたら原因の多くは「移管そのもの」ではなく、DNSまわりの扱いです。

ドメイン変更（URLそのものを変える）との違い

ドメイン変更は、移管とは別物で、影響の大きさが段違いです。

移管：example.com は example.com のまま（管理会社だけ変わる）
ドメイン変更：example.com → example.jp のように URL自体が変わる

ドメイン変更が絡むと、次の対応が必要になることが多いです。

301リダイレクト（旧URL→新URLへの恒久転送）
サイト内リンク・外部リンクの評価移行
Search Console のアドレス変更やサイトマップ再送信（ケースによる）
メールアドレスの全面変更（info@旧ドメイン→info@新ドメイン）

✅ ざっくり判断：
「同じURLのまま運用を楽にしたい」なら移管、
「URL自体を変えたい」ならドメイン変更、です。

名義変更（登録者情報の変更）・譲渡との違い

名義変更・譲渡は、“誰のドメインか” を変える手続きです。
移管は “どこで管理するか” を変える手続きなので、軸が違います。

名義変更：登録者名、住所、組織名、担当者情報などを変更
譲渡：登録者（所有者）そのものを他人・他社へ移す

ここで重要なのが、登録者情報の変更には安全対策として制限がかかることがある点です。
例えば、登録者の変更直後は一定期間、移管が制限される運用が一般的です。

💡実務のコツ：
「譲渡（名義変更）も移管もしたい」場合、どちらを先にやるべきかはドメイン種別や事業者の運用で変わります。
トラブルを避けるなら、手続きを始める前に “今の管理会社”の案内で順番を確認しておくのが安全です。

初心者が混同しやすい3パターン（図解用の章立て）

記事内で図解するなら、次の3パターンに分けると理解が一気に進みます。

移管だけ（管理会社だけ替える）
- 目的：更新費用の見直し／管理の一本化
- 注意点：DNSやメールが“付属サービス依存”だと確認が必要
サーバー移行だけ（データ置き場を替える）
- 目的：速度改善／サーバーの乗り換え
- 注意点：DNS切替が必須になりやすい（表示やメールに影響が出やすい）
ドメイン変更（URL自体を替える）
- 目的：ブランド変更／別ドメインへ統合
- 注意点：SEO・リダイレクト・各種設定の総入れ替えになりがち

移管を検討すべきタイミング・しなくていいケース

ドメイン移管は「必ずやるべき手続き」ではありません。
ただし、今の運用で困っていることがあるなら、移管は“効く”選択肢になります。

ここでは初心者でも判断しやすいように、移管が向いている場面と見送った方がいい場面を具体的に整理します。

更新費用や長期コストを見直したい

ドメインは毎年（または数年ごとに）更新が発生するため、差が出るのは「更新料金」と「更新し忘れリスク」です。

移管を考えてよいサインは、たとえば次のような状況です。

更新料金が思ったより高い（毎年じわじわ効いてくる）
初年度は安いのに、更新が高いプランだった
1〜2個ならともかく、複数ドメインで合計が重い
支払いが分散していて、管理が面倒になってきた

見直しのコツは、単年の安さだけで決めないこと。

「移管費用」だけでなく、更新料金（2〜3年先）まで見る
自動更新の設定や通知など、更新漏れを防ぐ仕組みも確認する
gTLD（.comなど）の移管は、完了すると登録期間が1年延長される扱いが一般的（上限あり）なので、“更新を兼ねる”感覚で計算すると分かりやすいです

ドメインとサーバーを一括管理して運用を楽にしたい

初心者が一番ラクになるのは、実はここです。
「サーバー会社」と「ドメイン会社」が別々だと、困ったときに原因の切り分けが難しくなりがちです。

一括管理が向く例：

WordPress初心者で、DNSやメール設定に自信がない
トラブル時に「どこへ問い合わせるべきか」を迷いたくない
更新や請求の管理を1つの画面にまとめたい

ただし、一括管理にも注意点があります。

付属DNSやメール機能に強く依存すると、将来の乗り換え時に手間が増えることがある
サーバー移行の予定が近いなら、移管のタイミングは整理した方が安全

現実的なおすすめはこの2択です。

とにかく迷いを減らしたい → ドメインもサーバーも同じ会社に寄せる
将来の拡張性も欲しい → ドメインは移管しても、DNSは独立運用（例：外部DNS）にする

DNS機能やセキュリティ（2段階認証など）を強化したい

ドメインは、サイトよりも先に狙われます。
なぜなら、ドメインを取られると「サイトの向き先」も「メール」もまとめて支配されやすいからです。

移管を検討したいセキュリティ面のサイン：

管理画面が2段階認証に対応していない
ログイン通知や操作履歴が弱い（不正アクセスに気づきにくい）
移管ロックの設定が分かりにくい／解除が簡単すぎる
サポートが弱く、復旧フローが不安

最低限チェックしたい機能（初心者向け）：

2段階認証（必須）
移管ロック（Transfer Lock）
重要操作の通知（メール・アプリなど）
アカウント復旧が現実的か（本人確認、復旧手順の明確さ）

「価格はそこそこでも、守りが強い」管理会社に寄せるのは、長期的に合理的です。

複数ドメインをまとめて管理し、更新漏れを防ぎたい

ドメインが増えるほど怖いのが、更新漏れです。
更新漏れは、SEOや売上以前に “事業停止級の事故” になり得ます。

移管してまとめるメリットは、主に次の3つです。

更新日・支払い方法・通知を統一できる
管理画面が一本化され、棚卸しがしやすい
サポート窓口が一本化され、緊急時の動きが早い

複数ドメイン運用でおすすめの運用ルール：

自動更新をONにする（可能なら）
通知先メールを「必ず見られるアドレス」にする
年1回だけでも棚卸し（使っていないドメインの整理）
重要ドメインは、権限や復旧手段も含めて“守り”を強化

とくに、メール通知が届かないケースは多いので、登録者メール（WHOIS / RDAPで確認できる範囲）や管理アカウントのメールは、運用中に必ず整備しておくと安心です。

移管しない方が安全なケース（例：期限が近い／要件未確認）

移管は便利ですが、「今やると事故りやすいタイミング」があります。
初心者は、以下に当てはまるなら一旦ストップして、条件を整えるのが安全です。

期限・手続き面のリスク

ドメインの期限が近い（更新と移管の兼ね合いが複雑になる）
取得したばかり／最近移管したばかりで、一定期間の制限があり得る
登録者情報（名義・メール等）を直近で変更しており、移管ロックの対象になり得る
移管ロックが解除できるか不明

運用面のリスク

独自ドメインメールを業務で使っている（不達が致命傷）
DNS設定が把握できていない（A/CNAME/MX/TXTが分からない）
認証コード（AuthCode）の取得手順が分からない
承認メールを受け取れる状態ではない（メールが古い／迷惑メール対策が強すぎる）

迷ったら結論はこれです。
「期限に余裕を作る」「DNSとメールを把握する」「承認メールを受け取れる状態にする」
この3点が揃ってから移管すると、失敗率が一気に下がります。

判断フローチャート：あなたは移管が必要？

以下の順番でYES/NOしていくと、初心者でも判断しやすいです。

今の管理で困っている（費用・管理の手間・セキュリティ）
- NO → 今は移管しなくてOK（定期的に見直すだけで十分）
- YES → 次へ
ドメインの期限に十分余裕がある
- NO → 先に更新して余裕を作る（または時期をずらす）
- YES → 次へ
AuthCode取得・移管ロック解除・承認メール受信ができる
- NO → 条件を整えてから（ここを曖昧にすると詰みやすい）
- YES → 次へ
メール運用（@独自ドメイン）や複雑なDNSがある
- YES → DNS控え・メール設定の確認をしてから移管（事故防止）
- NO → 移管の実行に進みやすい

最後にひとこと。
移管は「やる／やらない」より、“いつやるか”が成功率を決めます。
慌てて動くより、条件を整えて確実に進めるのが一番の近道です。

公式ルールと各社手続きの関係

ドメイン移管は「どの会社でも同じ手順でOK」というより、公式ルール（共通の土台）＋各社の運用（上乗せ）で成り立っています。

初心者が迷いやすいのは、次のズレが起きるからです。

公式ルール：最低限ここは守る（共通ルール）
各社の案内：公式ルールに沿いつつ、自社の画面・本人確認・受付条件に合わせて説明している

この見方ができると、手順が違って見えても落ち着いて判断できます。

gTLD：ICANNのTransfer Policyが“最低ライン”になる

.com / .net / .org などの gTLD の移管は、ICANNのポリシーが「共通の土台」です。
ここで言う土台とは、ざっくり次の3つです。

1) “本人の意思確認”が必須（承認フローがある）
移管は「勝手に移される」事故を防ぐため、承認（メールや管理画面での確認）を挟む仕組みが基本です。
そのため、移管ではしばしば以下が重要になります。

承認メールを受け取れる（登録者メールが有効）
迷惑メール対策で弾かれない
承認期限がある（放置すると失効）

2) “移管できない条件”がポリシーとして決まっている（例：一定期間の制限）
代表例が 登録者情報を変更した直後の移管制限（いわゆるロック） です。
ただし、これは一律ではなく、

原則ロックがかかる
一部のレジストラは、事前の手続きでロックを回避できる場合がある

というように、公式ルールの枠内で「各社の運用差」が出やすいポイントです。

3) “各社は、公式ルールより厳しくできる領域がある”
ICANNのポリシーは最低ラインなので、レジストラ側はセキュリティやサポート上の理由で追加条件を設けることがあります。例：

追加の本人確認（書類・2段階認証の必須化など）
管理画面上でのロック解除手順の差
サポート対応時間・反映タイミングの差

✅ ここがコツ
「ICANNのルールに反していない範囲で、各社が“安全側”に寄せている」と捉えると、違いが理解しやすいです。

JP：JPRSのルール（指定事業者変更・認証コード等）を軸に考える

JPドメイン（.jp / 属性型・地域型など）は、基本的に JPRSのルールを中心に組み立てられています。
gTLDと同じ感覚で探すと混乱しやすいので、JPはこう理解するとスムーズです。

JPの移管は「指定事業者変更」という枠組みで動く
つまり、ドメインを管理する窓口（指定事業者）を切り替える手続きです。

初心者が押さえるべき要点は次の通りです。

認証コード（AuthCode）が関係する（変更元で確認する）
登録者メールの確認が重要（承認案内が届く）
JPRSから登録者へ意思確認（承認）を求める流れがある
承認には期限がある（放置すると手続きが進まない）
指定事業者変更ロックを設定していると、変更できない（解除が必要）

さらに、JP特有の注意として、属性型・地域型JPでは担当者情報（JPNICハンドル）周りの取り扱いが関係するケースがあります。
このあたりは「ドメイン種別（汎用JPか、属性型・地域型か）」で必要な準備が変わるので、移管前に必ず確認したいポイントです。

✅ JPで失敗を減らす最短ルート

「ドメイン種別を確認」→「AuthCodeと登録者メールの確認」→「ロック有無の確認」
この順番にすると、手戻りが激減します。

同じ“移管”でもTLDや事業者で手順・制限が変わる理由

同じ「移管」という言葉でも、手順が微妙に違うのは自然です。理由は大きく3つあります。

理由1：TLDごとに、元締め（レジストリ）とルールの前提が違う

gTLD：ICANNのポリシーを土台に、レジストリ／レジストラが運用
JP：JPRSのルール（指定事業者変更など）を土台に運用

理由2：セキュリティ要件が“上乗せ”されるから
移管はアカウント乗っ取りの被害に直結するため、各社が次のような安全策を追加しがちです。

ロック解除の導線をあえて複雑にする
2段階認証を必須にする
重要操作の通知や確認を増やす

結果として、同じ移管でも「やることが多い会社／少ない会社」が生まれます。

理由3：ユーザーの状況で“影響範囲”が変わるから
手順そのものより、実務上の注意点が変わりやすいのがここです。

独自ドメインメールを使っている（DNSの確認が重要）
付属DNSを使っている（DNS移行や引き継ぎ確認が重要）
法人管理で権限が分散している（承認者・登録メールの管理が重要）

✅ 結論（初心者向け）
「公式ルール＝共通の骨格、各社手続き＝画面と運用の違い」
この2層構造で見ると、移管の全体像がブレません。

移管前チェックリスト（まずここを潰せば失敗が激減）

ドメイン移管でつまずく原因は、だいたい 「条件を満たしていないのに申請してしまう」 ことです。
逆に言うと、移管前にここをチェックしておけば、失敗率はグッと下がります。

この章は、“確認→OKなら次へ” の順で進められるように作っています。

ドメインの種類を確認（.com/.net など／.jp／.co.jp など）

まず最初にやるべきは 「そのドメインが何者か」 の判定です。
ここがズレると、必要な手続き（認証コード、ロック解除、承認方法）が噛み合いません。

ざっくり、初心者は次の表でOKです。

スクロールできます

種類	例	移管の呼ばれ方	先に意識するポイント
gTLD	.com / .net / .org など	“移管（transfer）”	AuthCode（EPPコード）が基本必須、EPPステータスの影響が出やすい
JP（汎用）	.jp	“指定事業者変更”	JPRSのルールに沿う、AuthCodeの有効期限がある
JP（属性型など）	.co.jp / .or.jp など	“指定事業者変更（＋情報の要件）”	担当者情報など追加条件が絡むことがある

💡ポイント
「移管できるかどうか」より先に「どの手順で移管するドメインか」を確定させるのがコツです。

有効期限は十分ある？（受付期限・推奨タイミングの考え方）

移管は“即日完了”とは限りません。承認待ち・処理待ちが入るため、期限ギリギリは危険です。

目安としては以下で考えると安全です。

推奨：有効期限まで1〜2か月以上の余裕
最低でも 2〜3週間 は余裕がほしい（承認が遅れると詰むため）

注意したいのはここ👇

移管手続きの途中で期限が切れると、移管が完了できないことがある
期限が近いドメインは、管理会社側が“受付制限”を設けている場合もある

✅おすすめの進め方（安全ルート）

期限を確認
期限が近いなら 先に更新して余裕を作る
余裕ができてから移管申請へ

移管ロック（Transfer Lock）が解除できる状態か

移管ロックは、いわば 「勝手に移されないための鍵」 です。
移管するなら、基本的にこの鍵を外せる状態が必要です。

よくあるロックのかかり方は2系統です。

管理会社が設定するロック（例：移管ロック／Transfer Lock）
ドメイン状態（EPPステータス）としてのロック
- 例：clientTransferProhibited など

やることはシンプルで、

管理画面で「移管ロック：ON/OFF」を探す
ロックがONなら、移管の直前にOFFにする
- （早く外しすぎると防御力が落ちるので、“直前”が基本）

※JPドメインも、移管（指定事業者変更）を止めるためのロック機能があります。該当する場合は解除が必要です。

AuthCode（オースコード/EPPコード）を取得できるか・期限はいつか

AuthCodeは、ひとことで言うと 移管用のパスワードです。
これがない（または期限切れ）だと、移管申請が前に進みません。

gTLD（.comなど）

多くのケースで AuthCode が必要
入手方法は管理会社によって違う（管理画面に表示／メール送付／サポート対応など）

JP（指定事業者変更）

AuthCodeが必要で、有効期限があります
期限を過ぎると、取得からやり直しになります
さらに、指定事業者変更が承認された場合、そのAuthCodeは使い回せません

✅安全な取り扱いルール

AuthCodeは SNSやチャットに貼らない（流出＝乗っ取りリスク）
“取得した日”と“期限”をメモ
申請の直前に取得（長く寝かせない）

WHOISの登録者メールは“確実に受信できる状態”か

ここは初心者が最も見落としやすいのに、詰みポイントになりやすいところです。

移管では承認のためにメールが飛ぶことがあり、受け取れないと止まります。

チェックすべきことは次の3つです。

現在の登録者メール（WHOIS相当の連絡先）が 実際に受信できる
迷惑メールに入らない（フィルタが強い法人メールは要注意）
退職者メール／昔のプロバイダメールなど、もう触れないアドレスになっていない

⚠️ここで重要な注意
登録者情報（特にメールアドレス）を変更すると、一定期間、移管できなくなるルールが適用されることがあります。

だからこそ、理想はこうです。

移管したいなら、登録者メールの受信可否は“最初に”確認する
もし受信できないなら、移管計画を立て直す（変更→待機が必要になる可能性があるため）

取得直後／前回移管直後の制限（60日ルールなど）に当たらないか

移管はセキュリティ上、いつでも自由にできるわけではありません。
代表的なのが「60日」関連の制限です。

初心者がまず意識すべきはこの3つです。

新規取得から間もない（例：60日以内）
直近で他社から移管してきたばかり（例：60日以内）
登録者情報の“実質的な変更”をした直後（例：60日ロック）

全部覚えなくてOKで、要するに、

「最近そのドメインで大きな変更をしていないか？」

を確認すれば十分です。

名義変更（登録者情報変更）を直近でしていないか

「名義変更」と「移管」は別手続きですが、連続してやると制限に引っかかることがあります。

直近でやっていたら要注意な変更例：

登録者の氏名・組織名の変更（表記修正ではなく“実質変更”）
登録者メールの変更
住所や電話番号の大きな変更

✅実務で安全な考え方

先に移管したい → 名義変更は後回しにした方が安全なケースが多い
先に名義変更が必要 → ロック期間を見込んでスケジュールを組む

※最適な順番は管理会社の運用にも左右されるので、迷ったら“先にサポートに確認”が最短です。

ドメインステータス（ok/active 等）が移管可能な状態か

移管可否のヒントは、ドメインの状態（ステータス）に出ます。
難しく見えますが、初心者はまずこの感覚でOKです。

ok / active：基本的に“通常状態”
inactive：ネームサーバー未設定などで、名前解決しない状態（サイトが表示されない原因にも）
clientTransferProhibited：移管が禁止（多くはロックがON）
pendingDelete / redemptionPeriod：削除・復旧プロセス中で危険（移管どころではない）

見方は2パターンあります。

管理会社の管理画面（初心者向けで分かりやすい）
WHOIS情報（管理会社が表示してくれる場合も）

紛争・差押え・未払い・不正検知などの制限がないか

移管できない“重めの理由”は、ここに集約されます。

例としては、

紛争手続き中（ドメインの争い）
裁判所命令などで凍結されている
不正アクセスの疑いで保護措置がかかっている
移管トラブル（直前の移管に関する争い）が解決していない

この手の制限は、管理画面に警告が出たり、サポート対応が必要になったりします。
見慣れない表示が出たら、自己判断で進めずサポートに状況確認が安全です。

DNS設定の現状（A/AAAA/CNAME/MX/TXT）を把握できているか

移管そのものは「管理会社の変更」ですが、事故が起きるのはたいていDNS周りです。
特に以下を使っている人は、DNSの控えが必須です。

独自ドメインメール（例：info@〜）
サブドメイン運用（blog. / mail. / shop. など）
外部サービス連携（Google、Microsoft、SNS認証、計測タグなど）

最低限、控えるべきレコードはこの4つです。

A / AAAA：どのサーバーに接続するか
CNAME：別名設定（www などで多い）
MX：メールの宛先（これが壊れるとメール不達）
TXT：認証系（SPF / DKIM / DMARC / 各種所有確認）

✅おすすめのやり方

管理画面のDNSレコード一覧を スクショ＋テキストでメモ
可能ならエクスポート（CSV等）があるか確認

“ここだけは必ず”の最重要3点

全部完璧にやろうとすると疲れるので、最初はこの3つだけ死守してください。
（ここを外すと、移管が止まる確率が一気に上がります）

AuthCodeを取得できる（期限内） 🔑
移管ロックを解除できる 🔓
承認メールを確実に受け取れる（登録者メールが生きている） 📩

この3点が揃ったら、移管の“土台”は完成です。

チェック項目テンプレ（コピペ用）

そのままメモ帳やNotionに貼って、✅を付けてください。

【ドメイン移管 前チェック】

■基本情報
- 対象ドメイン：
- ドメイン種別： gTLD / .jp（汎用） / .co.jp（属性型） / その他（　　　）
- 現在の管理会社（移管元）：
- 移管先候補：

■期限・制限
- 有効期限：YYYY/MM/DD（残り　日）
- 新規取得・直近移管・名義変更が60日以内にない：はい / いいえ / 不明
- 期限切れリスクがない時期で進める：はい / いいえ

■ロック・認証コード
- 移管ロック解除が可能：はい / いいえ（解除手順：　　　　　）
- AuthCode（EPPコード）取得可能：はい / いいえ
- AuthCodeの期限（ある場合）：YYYY/MM/DD（または発行から○日）

■承認・連絡先
- WHOIS（登録者）メールが受信できる：はい / いいえ
- 迷惑メール対策・受信許可（必要なら）：済 / 未
- 名義変更（登録者情報変更）を直近でしていない：はい / いいえ

■ドメイン状態
- ステータス確認：ok/active / inactive / transfer禁止 / その他（　　　　）
- 紛争・凍結・未払い等の警告がない：はい / いいえ / 不明

■DNS（控え）
- DNSをどこで管理？：移管元の付属DNS / 外部DNS / 不明
- A/AAAA控え：済 / 未
- CNAME控え：済 / 未
- MX控え：済 / 未（独自ドメインメール利用：あり / なし）
- TXT控え：済 / 未（SPF/DKIM/DMARC・所有確認など）

移管前の準備：サイトやメールを止めない段取り

この章のゴールはシンプルです。
「移管はする。でも、サイト表示とメール送受信は絶対に止めない」。

停止リスクは、だいたい次の3つに集約されます。

DNS（どこへ接続するか）
メール（MX/SPF/DKIM/DMARCなどDNS依存が強い）
承認メール（手続きが途中で止まる）

ここからは、初心者でも手順通りにやれば事故が起きにくい段取りで解説します。

DNSゾーンを控える（スクショ／エクスポート／メモ）

移管で一番の保険になるのが、DNSレコードの控えです。
これさえあれば、万一どこかで設定が崩れても“元に戻せる”確率が上がります。

最低限控えるべきレコード（使っていなくても一覧として保存がおすすめ）

A / AAAA：サイトの行き先（IPアドレス）
CNAME：www やサブドメインの別名設定
MX：メールの行き先（これが壊れるとメール不達）
TXT：所有確認、SPF/DKIM/DMARCなど認証系
NS：ネームサーバー（どのDNSで管理しているか）

控え方のおすすめ（強い順）

エクスポート（CSV等）があるなら最優先
エクスポートが無ければ DNS一覧画面をスクショ（全レコードが見える形で）
重要レコード（A/MX/TXT）は テキストでメモ（コピペできる形）

メモに残しておくと後で助かる項目

レコードの「名前（ホスト名）」と「値」
TTL（後で調整するため）
使っているサブドメイン（www / mail / blog など）

迷ったら「DNS設定の画面を“全部保存する”】【重要レコードはテキスト化】
これだけで、移管の安心感が段違いです。

メール利用中なら必須：MX・SPF・DKIM・DMARCの確認

独自ドメインメール（例：info@あなたのドメイン）を使っている場合、移管の事故で一番痛いのが メール不達です。
なので、移管前に「メールがDNSにどう依存しているか」を必ず確認します。

まず押さえる4つ（超ざっくり理解でOK）

MX：受信メールの配達先
SPF：このドメインから送信していいサーバーの宣言（送信の信頼性）
DKIM：送信メールに“署名”を付ける（改ざん防止・信頼性）
DMARC：SPF/DKIMの結果を踏まえて、失敗時の扱い方針＋レポート

チェック手順（初心者向けの安全ルート）

メール提供元を特定する
- 例：Google Workspace / Microsoft 365 / レンタルサーバー付属メールなど
DNSの控えから MX / TXT（SPF・DKIM・DMARC） を洗い出す
「送信元が複数」になっていないか確認
- 例：Googleで送る＋フォーム通知は別サービス＋営業ツールも送る、など
移管後も同じDNSを維持できるかを確認
- “管理会社の付属DNS”に依存している場合は特に要注意

ありがちな落とし穴

SPFが 複数行に分裂している（SPFは基本“1つのTXT”にまとめるのが原則）
DKIMが「設定したつもり」でも、鍵が古い／反映されてない
DMARCのレポート先が無く、異常に気づけない
受信はOKでも、送信が迷惑メールに入りやすくなる

独自ドメインメールを使っている人は、移管前に一度だけテスト推奨です。

外部アドレス（Gmailなど）へ送信 → 迷惑メール扱いにならないか
外部アドレスから自ドメインへ送信 → 正常に届くか

（テスト自体は無料でできます。移管直前にやると安心です）

TTL調整の考え方（いつ下げて、いつ戻す？）

TTLは、DNSが「どれくらいの時間キャッシュされるか」を決める値です。
ざっくり言うと TTLが長いほど、変更が反映されるまで時間がかかる 可能性があります。

TTLを下げる目的

万一DNSを変更する必要が出たときに、反映待ちの“足かせ”を短くするため

いつ下げる？

移管当日ではなく、移管の前段階で下げるのが基本です
（下げたTTLが全体に行き渡っていないと、意味が薄くなるため）

いつ戻す？

移管が完了し、サイト表示とメール送受信が安定してから
“短いTTLのまま”でも致命的ではありませんが、運用が落ち着いたら戻しておくと管理しやすいです

注意点（初心者が安心するための整理）

移管そのものではDNSを変えないことも多い
ただし「ネームサーバーの切り替え」や「DNS事業者の切り替え」を伴うなら、TTL調整は価値が高い

迷ったら、TTLは「必要になったときの保険」。
DNSに手を入れる可能性があるなら準備しておく、でOKです。

承認メール対策：受信用アドレスの二重化・迷惑メール対策

移管は途中で 承認メール（確認メール） が挟まることがあります。
ここでメールが受け取れないと、手続きが止まります。

事前にやること（実務で効く順）

登録者メール（連絡先メール）が 今も受信できることを確認
迷惑メールフォルダ確認＋フィルタの緩和（移管期間だけでも）
可能なら、受信アドレスに 別の復旧手段を用意
- 例：別メールに転送、チーム共有の受信箱、運用担当のサブアドレスを追加など
「移管元」「移管先」両方から届く可能性を想定して、ドメインの受信許可（ホワイトリスト）を整える

ここでやりがちなNG

受信できないからといって、直前に登録者メールを変える
- 変更直後は移管に制限がかかる場合があり、かえって詰むことがあります

“受信できる状態の確認”は、移管手続きに入る前が鉄則です。

移管中にやらないこと（DNS変更・名義変更・解約など）

移管中は、ドメインが“手続き中の状態”になります。
この期間に別の変更を重ねると、原因切り分けが難しくなり、トラブルが増えます。

移管中は、基本的にこれを避けてください。

DNSの大きな変更（ネームサーバー変更、レコードの大幅編集）
名義変更（登録者情報の変更）
移管元サービスの解約（「もう移るから」と先に解約しない）
セキュリティ設定の過剰変更（2FA無効化など）
メール運用の切り替え（プロバイダ変更）を同時進行

✅安全な進め方（おすすめ）

移管の前：控えを取る／受信確認／必要ならTTL調整
移管中：変更を増やさない（承認と完了を待つ）
移管後：疎通確認→落ち着いてから最適化（DNS整理、名義変更など）

「名義変更→移管」の順番で詰む典型例

よくある“詰みパターン”を、具体例でイメージしてみます。

状況

担当者が退職し、登録者メールが古い
先に登録者情報（メール）を変更しようとする

起きがちなこと

登録者情報の変更がトリガーになり、一定期間、他社への移管ができない状態になる
その間に「期限が近い」「急いで移したい」が重なって焦る
結果として、更新・手続き・確認が同時多発し、事故率が上がる

回避策（現実的）

まずは「受信できる状態」の確保を、変更ではなく運用で解決できないか検討
- 例：転送設定、受信復旧、社内共有化
変更が必要なら、移管の計画にロック期間を織り込む
レジストラによっては例外対応や選択肢がある場合もあるので、最短で進めたいなら 事前にサポートへ確認が確実

重要なのは「名義変更が悪い」ではなく、
“移管と同時にやると詰みやすい変更”があるという点です。

gTLD（.com/.netなど）の移管手順

ここでは、.com / .net / .org などの gTLD（一般的な海外TLDを含む）の移管手順を、初心者でも迷いにくい「4ステップ」にまとめます。
ポイントは、移管中にサイトやメールを止めないために “申請する前の準備”を先に済ませることです。

Step1：移管元でやること（ロック解除／AuthCode入手／連絡先確認）

移管元（今の管理会社）でやることは、だいたいこの3本柱です。

1) 移管ロックを解除できる状態にする（直前に解除がおすすめ）

管理画面で「Transfer Lock / Domain Lock」が ON になっていることが多いです
移管するなら、申請直前に OFF にします
- 早く外しすぎると、防御が弱くなります

2) AuthCode（AuthInfo / EPPコード）を取得する

これは移管用の“合言葉”で、移管先に入力します
発行したら、第三者に見られない場所に保存（チャット貼り付け等は避ける）
なお、移管の承認に使うフォーム（FOA）は、発行から一定期間で期限切れになる設計があります（目安：60日）
- なので AuthCodeも「早すぎる取得」は避け、申請直前が安全です

3) 連絡先（登録者メール）を“確実に受信できる状態”にする
移管では、承認メールが届かないと止まります。最低限これを確認します。

管理画面に登録されているメールアドレスが 現役か
迷惑メールに入らないように、移管期間だけでもフィルタを弱める
法人運用なら、担当者不在でも確認できるように（共有受信箱・転送など）

補足：移管できない典型条件の最終チェック（当てはまると申請が弾かれやすい）

取得したばかり／前回の移管直後（一定期間の制限）
未払い・チャージバック・不正検知などがある
ドメインステータスが移管禁止（例：clientTransferProhibited）になっている
→ ここに当たる場合は、まず移管元の画面やサポートで解除・解決が必要です。

Step2：移管先でやること（転入申請／AuthCode入力／支払い）

移管先（これから管理したい会社）で行うのは「申請の作成」と「支払い」です。

1) 移管申請を作成する

移管したいドメイン名を入力
AuthCode（EPPコード）を入力
アカウント作成や本人確認が必要な場合はここで対応

2) 支払い（多くは“1年分”がセット）

gTLDの移管では、手続きが完了すると 有効期限が1年延長される扱いが一般的です（ただし上限あり）
そのため、移管費用が実質「更新1年分」に近い形になるケースが多いです

3) （重要）ネームサーバーの扱いを確認する
移管そのものは「管理会社の変更」ですが、移管先の画面で次を必ず確認します。

ネームサーバー（NS）が 現状維持になっているか
もし自動で移管先DNSに切り替わる設計なら、事前にDNSレコードを移し替える準備が必須

Step3：承認フロー（メール承認・最終確定）

移管が進むと、承認（確認）が挟まります。ここが“止まりやすい場所”です。

承認は大きく2段構えになりやすい

移管先（転入側）から「移管してよいか」の承認
移管元（転出側）から「本当に移管するか」の確認

この承認は、メールで届くこともあれば、管理画面で「承認」ボタンを押す形式のこともあります。
形は違っても、やっていることは同じです。

待ち時間の目安

移管元が拒否しなければ、一定期間経過で自動承認される設計が一般的（代表例：5日）
早く終わらせたいなら、届いた承認を すぐ実行するのが最短です

移管が拒否される（止まる）代表例
初心者が遭遇しやすいのは、次のタイプです。

取得直後や移管直後で、制限期間に当たっている
移管元に未払いがある（過去分も含む）
本人確認（登録者の同一性）に疑義がある
不正・紛争・裁判所命令などの“強制停止”がある

Step4：完了後に必ず確認（自動更新／WHOIS／期限年数／セキュリティ）

「移管完了」の表示が出たら、最後に“事故防止の確認”をします。ここを飛ばすと、あとで地味に困ります。

1) 自動更新がONになっているか

移管前はONでも、移管後にOFFになっていることがあります
支払い方法の再登録が必要なケースもあるのでチェック

2) 有効期限（更新年数）が想定通りか

移管完了で「1年延長」される扱いが一般的
ただし、登録期間は 上限（最大10年）があるため、すでに上限に近いと延長がフルに乗らない場合があります

3) WHOIS（RDDS/RDAP）の登録情報が最新か

連絡先メールが古いままだと、次回の更新・トラブル時に詰みやすい
ただし、直後の情報変更は制限（ロック）に影響することがあるため、移管直後に触る前に移管先の注意事項を確認

4) セキュリティを強化して“移管後乗っ取り”を防ぐ

2段階認証（2FA）を有効化
移管ロック（Transfer Lock）を ONに戻す
重要操作の通知（ログイン通知など）をON

5) サイト・メールの疎通確認（最低限の動作チェック）

サイトが表示されるか（トップページ＋主要ページ）
独自ドメインメールが送受信できるか（使っている場合）

承認メールが届かないときの切り分け

「待っても来ない」場合、焦って再申請すると余計に混乱します。次の順に潰すのが確実です。

1) まず“どの箱”を探すべきかを決める

登録者メール（連絡先メール）宛のことが多い
ただし、管理会社によっては 管理画面内通知のみのこともあります

2) 迷惑メール・隔離・フィルタを確認

法人メール（セキュリティ強め）ほど、隔離されがちです
移管元／移管先の送信ドメインを一時的に許可するのも有効

3) 申請が“承認待ち”まで進んでいるか確認

移管先の管理画面でステータスを確認
AuthCode誤りだと、承認以前に止まることがあります

4) 登録者メールが古い／触れない場合はサポートへ

ここを自己流でいじると、情報変更ロック等で遠回りになる可能性があります
最短は、移管元に「承認メールの再送」や「連絡先の扱い」を確認することです

“どのメール”が必要か（登録者／管理者／事業者通知）

承認関連のメールは、役割が違います。混同しないために整理します。

登録者（Registered Name Holder）向け
- 「本当に移管しますか？」という承認の本丸
- 届かないと移管が進まない原因になりやすい
管理者（Administrative Contact）向け（古い運用で残ることあり）
- 追加の確認として飛ぶことがある
- ただし近年は登録データの扱いが変化しており、運用差が出ます
事業者通知（移管元／移管先の“お知らせ”）
- 「申請を受け付けました」「処理中です」などの進捗通知
- なくても移管が進む場合がある（承認メールとは重要度が別）

✅ 結論：初心者が最優先で守るべきは、登録者メールを確実に受信できることです。

JPドメイン（.jp/.co.jpなど）の移管手順

JPは基本「指定事業者変更」として理解する

JPドメインの「移管」は、ざっくり言うと 管理をお願いする会社（指定事業者）を替える手続きです。
つまり、JPでは「移管＝指定事業者変更」と捉えると迷いが減ります。日本レジストリサービス（JPRS）が定めた流れに沿って、移管元（今の会社）と移管先（これからの会社）が手続きを進めます。

初心者が安心できるポイントを先にまとめます。

ドメイン名そのもの（文字列）は基本そのまま
サイトが止まるかどうかは、主に DNS運用しだい
gTLD（.comなど）と違い、移管しただけで“契約年数が自動で伸びる”とは限らない（期限が引き継がれる運用が一般的）

認証コード（AuthCode）入手→移管先へ申請→移管元で承認の流れ

JPの移管は、全体像をつかむと一気に簡単になります。大筋はこの通りです。

流れ（初心者向けの理解）

移管元にAuthCodeの発行を依頼
AuthCodeを受け取る（メールや管理画面など。方式は会社ごとに違います）
移管先へ「指定事業者変更」を申し込む（AuthCodeを入力するケースが多い）
移管元側で「本当に移管するか」の意思確認（承認）が来る
承認が通ると、指定事業者変更が完了

ここで押さえるべき“公式ルール”が2つあります。

AuthCodeには有効期限がある
- JPRSが生成した翌日を1日目として、35日後の23:59:59まで
一度「承認」されて完了したAuthCodeは再利用できない
- もう一度移管するなら、AuthCodeの取り直しが必要

現場でのコツ

AuthCodeは「早く取れば安心」ではなく、申請に近いタイミングで取得が安全
承認依頼が来たら、放置せず当日中に対応（期限は会社側の運用で変わるため）

汎用JP：ドメイン単位で動かす方法と、登録者番号単位の方法

汎用JP（例：example.jp）や都道府県型JPは、移管の“単位”が2パターンあります。これを知らないと、意図せず複数ドメインがまとめて動くことがあります。

1) 登録者番号単位（REG-）で動かす：指定事業者変更

REG-で始まる 登録者番号にひも付いたドメインが、まとめて移管される方式
複数ドメインを一括で移したいときに向いています

注意点

「1つだけ移したい」のにこの方式を選ぶと、REG-ID配下のドメインが全部対象になってしまう場合があります。

2) ドメイン単位で動かす：移転（ドメイン名移転）

“特定の1ドメインだけ”を動かしたいときに使われる考え方
事業者によっては「移転」という別メニューで案内されます

初心者の判断基準（迷ったらこれ）

全部まとめて移したい → 登録者番号単位の「指定事業者変更」
このドメインだけ移したい → ドメイン単位の「移転（移管先の案内を確認）」

実務での最重要チェック（1分でOK）

「今の管理会社で、対象ドメインはREG-IDに何件ぶら下がっているか？」
- ここが不明なら、移管元サポートに確認するのが最短です。

属性型・地域型：担当者情報（JPNICハンドル）などの注意点

.co.jp / or.jp / ac.jp / ed.jp / go.jp などの 属性型JPや、地域型JPでは、汎用JPよりも「連絡担当者情報」の扱いが重要になります。

特に重要なのが 担当者情報（JPNICハンドル）です。JPNIC

押さえるべきポイント

属性型・地域型JPの指定事業者変更では、移管先で担当者情報（JPNICハンドル）を新規作成する扱いになる点に注意が必要です。
- 移管元で使っていた担当者情報を、移管後もそのまま継続利用できない前提で準備します。
また、担当者情報（JPNICハンドル）は、原則として複数の指定事業者で共用できないと案内されています（例外の経緯はあります）。

初心者が詰まりやすい場面

「移管はできたのに、担当者情報の差し替えで追加対応が発生した」
「移管先が求める担当者情報（担当者名・連絡先）の提出が間に合わない」

対策（先回り）

移管先の申請画面で、担当者情報として何が必要かを事前に確認
会社運用なら、担当者の個人アドレスではなく 引き継ぎやすい連絡先を用意
既に別手続き（名義変更など）を動かしている場合は、順番をサポートに確認（同時進行は事故りやすい）

受付期限を逃さないためのカレンダー設計

JP移管で一番もったいない失敗は、「期限が近くて受付不可になった」「AuthCodeが期限切れになった」です。
これを避けるには、先に“締切から逆算”で予定を置くのが正解です。

更新月・締切・承認待ちを逆算する

まず、あなたのドメインについて次の3つを確定します。

ドメインの有効期限日
移管先が定める受付期限（会社ごとの締切）
- 例として「有効期限月の10日まで」など、独自の締切を設けているケースがあります
AuthCodeの有効期限（発行翌日を1日目として35日後まで）

そして、逆算でこう置きます（目安の“設計図”です。実際は各社の案内に合わせて調整してください）。

締切の2〜3週間前：移管先へ申し込み完了（入力・支払い・必要情報提出まで）
締切の3〜5週間前：移管元へAuthCode発行依頼（発行後35日で失効するため）
締切の1〜2か月前：連絡先メール受信確認／移管対象の整理（REG-ID配下の確認など）

もし遅れそうなときの安全策

期限が迫っているなら、先に移管元で更新して“余裕”を作ってから移管する方が安全な場合があります（焦って動くほど事故率が上がるため）。

費用と期間の目安：何にお金がかかり、どれくらい待つ？

ドメイン移管の「費用」と「待ち時間」は、ややこしく見えてもポイントはシンプルです。
お金が発生する場所と、待ち時間が伸びる原因を分けて押さえると、迷いが激減します。

移管費用の内訳（移管手数料／更新延長／オプション）

ドメイン移管で発生しうる費用は、大きく3つです。

スクロールできます

区分	何のための費用？	具体例（よくあるパターン）
1. 移管の基本費用	「移管先」に払うメインの費用	移管手数料（実態は“更新1年分相当”の価格設定が多い）
2. オプション費用	安全性や運用を上げる追加	WHOIS公開代行、DNS追加機能、メール関連、セキュリティ強化など
3. 例外的な追加費用	“状態が悪い”と発生	期限切れ復旧、保留・制限解除対応、事業者側の作業費など

コツ：見積もりは「移管先の移管価格＋必要オプション」だけ先に確定させると早いです。
（移管元に払う費用は、基本的には“未払いがある／オプション解約が必要”などの例外で発生します）

「移管＝更新1年が付く」ケースと例外

ここが初心者が一番つまずくポイントです。

多くのgTLD（.com / .net など）は「移管完了で期限が1年伸びる」ことが多い

gTLDの移管は、ルール上「登録期間が1年延長される」仕組みになっています。
ただし、登録期間には上限（一般に“最大10年”）があるため、すでに上限付近だと“見た目上は1年増えない”ことがあります。

例外1：すでに上限年数近い（または上限到達）ケース

期限が最大年数に近いと、移管費用は発生しても期限が増えない（増えにくい）ことがあります。
これは「料金が無駄」ではなく、ルール上の上限による表示上の問題になりがちです。

例外2：JPドメインは“移管＝更新1年付与”とは限らない

JPは考え方が違い、「指定事業者変更（管理会社の変更）」が軸です。
移管手数料・更新費用の扱いは、移管先（指定事業者）の料金体系に依存します。

例外3：ccTLD（国別ドメイン）はルールが別物なことがある

gTLDの常識（1年延長・5日…）がそのまま通用しないことがあります。
“そのTLDの公式ルール”と“移管先の案内”を必ず確認するのが安全です。

完了までの典型スケジュール（最短・通常・遅延パターン）

「移管に何日かかる？」は、移管対象（gTLDかJPか）と、承認がどれだけ早く進むかでほぼ決まります。

gTLD（.com/.net など）の目安

最短：数十分〜当日
- 移管元の承認が早い／メール承認を即対応／ロック解除やAuthInfoが即出る場合
通常：1〜7日程度（体感は“だいたい数日”）
- 移管元が承認しない（or 見落とす）と、規定の待ち時間で進行しやすい
遅延：1週間以上
- 承認メールが届かない、AuthInfoが無効、手続き途中で設定変更、期限がギリギリ、など

ポイントはここです：

移管元（現在の管理会社）が一定期間応答しないと“自動で承認扱い”になって進む設計があり、これが「5日待ち」になりやすい原因です。
逆に言えば、移管元で“手動承認”できるなら、その瞬間に短縮できます。

JP（.jp/.co.jp など）の目安

最短：1〜数日
通常：数日〜10日程度
JPでは、申請に対する管理側の反応がない場合でも、一定期間の経過で処理が進む（または結果が確定する）ような運用が説明されています。
そのため「最大10日くらい」と案内されることが多いです。

目安を一発で把握する早見表

スクロールできます

種類	だいたいの所要日数	長引きやすい原因
gTLD	当日〜7日	承認メール未対応、移管元の承認待ち（自動進行待ち）、AuthInfo不備
JP	数日〜10日	指定事業者側の承認待ち、期限が近い、ロックや情報不備

急ぎたいときに効く3つのコツ

「スピード勝負」のときは、作業を増やすよりも待ち時間の原因を潰すのが最短です。

承認が必要な連絡（メール／管理画面通知）を“その日のうちに処理”する
- 迷惑メールに入ると致命的なので、事前に受信設定も確認しておくと安心です。
移管元で先に“移管できる状態”を完成させる（ロック解除・AuthInfo準備）
- ここが遅いと、移管先で手続きしても止まります。
- 「AuthInfoが取れない」「ロック解除できない」は最優先で解消。
「触ると止まるもの」を移管中に触らない（名義情報・DNS・解約など）
- 途中で条件が変わると、承認フローが振り出しに戻ったり、追加確認が発生しがちです。
- “移管が完了してから設定をいじる”が安全。

SEO・アクセス・メールへの影響を最小化する

ドメイン移管で怖いのは「移管そのもの」ではなく、移管の前後で起きがちな停止・設定ミスです。
この章では、検索順位・アクセス・メールを守るための“実務チェック”に絞って解説します。

順位が変わるのは“移管”ではなく“停止や設定ミス”

ドメイン移管は、基本的に 「ドメイン管理会社（レジストラ）が変わるだけ」なので、正常に運用できていればSEOへの直接影響は小さいです。

順位が動きやすいのは、たとえばこんなときです。

サイトが一時的に 表示不能（DNSミス、サーバー停止、CDN設定ミス）
Googlebotがアクセスすると エラー（5xx相当）になる
- DNSエラーやネットワークタイムアウトも、Googleからは“5xxに近い扱い”でクロールが落ちやすい
HTTPSが壊れる（証明書エラー、HTTPS強制の不整合）
重要ページが 404/403 になっている（WAFやアクセス制限も含む）
robots.txt / noindex が意図せず有効化される（移行・復元作業の副作用）

結論：移管でやるべきことは「SEO対策」ではなく、止めない・壊さない運用です。

サイトが表示されない／メールが届かない主因はDNS

移管後トラブルの多くはDNSが原因です。特に危険なのは、移管をきっかけに ネームサーバー（NS）やDNS管理場所が変わるケース。

まず安全策：NSを変えない

いちばん事故が少ないのは、移管後もNSを現状維持することです。
DNSの管理場所が変わらないなら、サイトやメールは止まりにくいです。

NSを変えるなら：DNSを“完全コピー”する

NS変更（DNS移行）を伴う場合は、DNSゾーンを丸ごと再現します。最低限、以下が揃っているかを確認してください。

サイト：A / AAAA / CNAME（wwwなど）
メール：MX / SPF（TXT）/ DKIM（TXT）/ DMARC（TXT）
外部連携：所有確認のTXT、サブドメイン、API連携用レコードなど

特にメールは、MXだけ合っていても不達・迷惑判定が増えることがあります。
送信元が複数ある人（フォーム通知、営業ツール、Gmail送信など）は SPFの統合が必要になりがちです。

体感トラブルの典型パターン

「サイトは表示されるのに、メールだけ死んだ」
→ MX/TXTの入れ忘れ、DNSが“メールだけ旧設定”になっている、など
「自分の環境では表示されるのに、他人は見れない」
→ 端末やISPごとのキャッシュ差（DNS反映のズレ）
「一部のサブドメインだけ不調」
→ CNAMEやAレコードの漏れ

SSL（HTTPS）・CDN・サブドメイン運用の注意

HTTPSまわりは、DNSよりさらに“症状が重い”ことがあります（ブラウザ警告、インデックス低下など）。

SSLでやるべきこと

証明書が移管後も自動更新されるか（Let’s Encryptなど）
CDN利用時は、CDN側とオリジン側のHTTPSが噛み合っているか
- 例：CDNがHTTPSでも、オリジンが証明書失効だとエラーになる構成がある
CAAレコードを入れている場合、証明書の発行・更新が止まることがある
- DNS移行時にCAAだけ残って、許可CAの記述が不足するケースもあるので要注意

HSTSを使っている場合の注意

HSTS（常時HTTPS強制）はセキュリティ的に強い反面、HTTPSが壊れると復旧が面倒になります。

移管前後の不確実な期間は、HSTSの運用を“強くしすぎない”
特に preload（プリロード）級の設定は、構成が完全に安定してから

サブドメイン運用は“漏れ”が致命傷

mail. www. blog. shop. など、サブドメインごとのDNS・証明書・リダイレクトを確認
サブドメインで別サービス（EC、予約、フォーム）を使っていると、DNSの抜け漏れが起きやすいです

Google Search Console / アナリティクスでやるべき確認

移管後の確認は「順位を見て一喜一憂」より、異常の早期検知が重要です。

Search Consoleで見る場所（優先順）

クロール統計情報：クロール数の急落、応答の失敗、タイムアウト増加がないか
ページのインデックス登録（Page Indexing / Pages）：重要URLに404/5xx/ブロックが増えていないか
HTTPSレポート：証明書エラーなど“サイト全体のHTTPS問題”が出ていないか
URL検査：トップと重要ページを数本だけ「ライブテスト」で確認（表示取得できるか）

補足：ドメイン移管だけなら、基本的に「アドレス変更（Change of Address）」のような移転ツールは不要です。
URL（ドメイン名）を変えていないからです。

Search Consoleの“所有権”が消えないようにする

Search Consoleのドメインプロパティは、DNSのTXTで所有権確認していることが多いです。
DNSを移行するときに 確認用TXTレコードを消すと、後で所有権が維持できなくなる場合があります。

DNS移行の前に「Search Console確認用TXT」を控える
DNS移行後に、同じTXTが存在するか確認

GA4で見る場所（優先順）

リアルタイム：移管直後にアクセスが計測されているか（タグが生きているか）
計測ID（Measurement ID）：サイト側に入っているIDが正しいか
タグ確認ツール（Tag Assistant等）：ページごとに発火しているか

※移管そのものではGAは壊れませんが、CDN/HTTPS/キャッシュ設定変更が入ると、タグが読み込まれない（または二重計測）などが起きることがあります。

移管後チェック（疎通・証明書・メール送受信）

最後に、移管完了〜24時間でやると安心なチェックをまとめます。
（“1回で全部”より、重要度の高い順に潰すのがコツです）

1) サイト疎通

トップページ／主要カテゴリ／お問い合わせなど3〜5ページを開く
表示速度やエラー（403/5xx）がないか

2) HTTPS

ブラウザで警告が出ない
証明書の有効期限が極端に短くない（自動更新が生きているか）

3) DNS

NSが意図通りか
A/AAAA/CNAME/TXTの主要レコードが抜けていないか

4) メール（使っている場合は最優先）

外部Gmail等 → 自ドメインへ送信：届くか
自ドメイン → 外部Gmail等へ送信：迷惑メールに入らないか
SPF/DKIM/DMARCのTXTがDNSに存在するか

5) Search Console / GA

クロール統計で急落・エラー増がない
GA4リアルタイムで計測される

よくある失敗・トラブルシューティング

ドメイン移管のトラブルは、原因がだいたい決まっています。
この章では、初心者でも迷わないように 「症状 → 原因 → 直し方」 の順でまとめます。

AuthCodeが違う／期限切れ／発行できない

よくある症状

移管先で「AuthCodeが無効」「コードが違う」と表示される
何度入れても弾かれる
そもそも移管元の管理画面にAuthCodeが見当たらない

原因になりやすいこと

コピペのミス（前後に空白、全角混入、改行が入る）
古いAuthCodeを使っている（再発行後に前のコードを入力している）
事業者側で AuthCodeの有効期限がある（JP系の移管では特に期限が明確）
移管元が 本人確認（追加認証） を要求しており、発行が保留になっている

対処（最短ルート）

手入力は避けてコピペ（ただし前後に空白が入っていないか確認）
可能なら AuthCodeを再発行して、最新のものだけ使う
申請側（移管先）でドメイン名の入力ミスがないか確認（example.com と example.co など）
それでもダメなら、移管元へ「発行できない理由」を確認（本人確認・制限・保留の可能性）

予防策

AuthCodeは 申請の直前に取得して、寝かせない
「どのドメインのAuthCodeか」をメモして取り違えを防ぐ

ロック解除できていない（ステータスが噛み合わない）

よくある症状

「Domain is locked」「transfer prohibited」「clientTransferProhibited」などが出る
管理画面でロックをOFFにしたのに、移管先ではまだロック扱い

原因になりやすいこと

移管ロック（Transfer Lock） がONのまま
EPPステータスが 移管拒否状態（例：clientTransferProhibited）
ロック解除に 反映時間が必要（すぐにステータス更新されないことがある）
（JPの場合）指定事業者変更ロックが有効になっている

対処（チェック順）

移管元でロック設定を再確認（OFFになっているか）
ロック解除後 10〜30分ほど待って再申請（反映待ち）
WHOIS/RDAPでステータス確認（clientTransferProhibited が残っていないか）
JPの場合は、移管元の管理画面で 「移管ロック／指定事業者変更ロック」 を解除

予防策

ロックは 申請直前に解除し、完了後すぐ 再ロックが安全
「ロック解除できる権限のアカウントか」を事前に確認（法人運用で詰まりがち）

承認メールが届かない（WHOISメール不達・迷惑メール）

よくある症状

「承認が必要です」と出ているのに、メールが来ない
迷惑メールにもない
法人メールで隔離されている可能性がある

原因になりやすいこと

登録者メール（連絡先メール）が 古い／使えない
迷惑メール・隔離・フィルタで ブロック
承認はメールではなく 管理画面上で行うタイプなのに、メールを待っている
転送設定の不備（転送先が容量不足など）

対処（切り分けの順番が重要）

移管先・移管元の管理画面で「承認ボタン／承認リンク」がないか確認
迷惑メールだけでなく 隔離（quarantine） や管理者側のセキュリティログを確認（法人メール）
登録者メールが現役か確認（受信テストできるなら一番早い）
再送が可能なら、承認メールの再送を試す
どうしても受け取れないなら、移管元サポートへ「連絡先メールの扱い」を相談
- ただし、連絡先変更が移管制限に関係する場合があるため、自己流で直前変更しないのが安全です

予防策

移管に入る前に、登録者メールが “確実に受信できる” 状態か確認
重要メールを見落とさないよう、移管期間だけでも通知設定を強める

60日制限に引っかかる（取得直後・名義変更直後・移管直後）

よくある症状

「60 days」「within 60 days」「transfer not allowed」などが表示される
ロック解除もAuthCodeも正しいのに進まない

引っかかりやすい3パターン

新規取得から60日以内
前回の他社移管から60日以内
名義変更（登録者情報変更）直後の60日ロック（※オプトアウトしていない場合）

対処（現実的な結論）

基本は待つが最短です（解除できる種類の制限ではないことが多い）
名義変更が原因のロックは、手続き時に ロックを外す選択（オプトアウト） が用意される場合があります
- ただし、既に完了後なら遡って外せないことが多いので、移管元へ確認

予防策

「名義変更」と「移管」を 同時進行しない
予定があるなら、先にスケジュールを引いて
（名義変更 → ロック期間）→ 移管 の順で計画する

期限が近すぎる／失効している／更新と移管の順序ミス

よくある症状

「expires before transfer completes（完了前に期限切れ）」と言われる
期限切れ後に移管しようとして弾かれる
更新したつもりが反映されず、移管も止まる

まず知っておくと安心なこと

移管は“即時完了”ではないため、期限ギリギリは失敗率が上がります
期限切れ後は状態によって、更新だけで戻る場合と、復旧（追加手続き・追加費用）が必要な場合があります

対処（安全な順番）

有効期限を確認し、余裕がないなら 先に更新して延命（移管より更新を優先）
すでに失効しているなら、移管ではなく 復旧・更新の手順を移管元で確認
更新後、管理画面に新しい期限が反映されてから移管に進む

予防策

目安として 1〜2か月前から準備すると事故が減ります
「期限」「承認待ち」「AuthCode期限」をカレンダーに入れて逆算

移管できないドメイン種別・状態（紛争・差押え・上限年数など）

よくある症状

「transfer denied: fraud」「identity dispute」「court order」などの文言
「pendingDelete」「redemptionPeriod」等のステータスが出る
移管費用を払ったのに期限が伸びない（上限が原因のことも）

代表的な“移管できない／されにくい”理由

不正疑い・本人性の争い（fraud / identity dispute）
支払いトラブル（チャージバック、未払い）による保留
法的な制限（差押え、命令、紛争手続き）
削除プロセス中（復旧が先）
登録期間の上限に近く、更新年数が増えない（※移管可否とは別に、期待とズレやすいポイント）

対処

このタイプは、テクニックで解決しにくいので
「移管元に“拒否理由を明確化”してもらう」→「必要条件を解消」 が基本です

エラー文言別：原因と対処を1対1で対応させる

下の表は、実際に出やすい“エラーの型”を、原因と対処で対応づけたものです。
（表の文言と完全一致しなくても、近い表現なら同じ原因のことが多いです）

スクロールできます

エラーの型（例）	原因の本命	まずやること	次の一手
invalid auth code / wrong EPP / AuthInfo invalid	AuthCode違い・古い・コピペミス	前後の空白除去・再入力	再発行して最新だけ使う
domain is locked / clientTransferProhibited	ロックON・ステータス移管禁止	移管元でロックOFF	反映待ち→再申請
transfer prohibited within 60 days	60日制限（取得/移管/名義変更）	日付を確認	原則待機、例外は移管元へ
registrant/admin email invalid / cannot contact	登録者メールが死んでいる・不達	管理画面で連絡先確認	受信復旧 or サポート相談
domain expired / expires before completion	期限が近い・失効済み	先に更新	失効なら復旧手順へ
transfer denied: fraud / identity dispute	不正・本人性の争い	理由の開示依頼	本人確認・解除対応
pendingDelete / redemptionPeriod（等）	削除・復旧フェーズ	移管は一旦止める	復旧（restore）→安定後に移管

問い合わせテンプレ（現状・ステータス・希望内容）

移管が止まったら、サポートに丸投げするより 情報を揃えて送ると一気に早くなります。
以下をそのままコピペして使ってください。

【ドメイン移管の問い合わせ】

■対象ドメイン：
■TLD種別：gTLD（.com等）／JP（.jp/.co.jp等）／その他（        ）
■移管元（現在の管理会社）：
■移管先（予定の管理会社）：

■現在の状況：
- 移管申請：未／済（申請日：YYYY/MM/DD）
- エラー表示の文言：（可能ならそのまま貼付）
- 移管元ロック状態：ON／OFF／不明
- AuthCode：取得済（取得日：YYYY/MM/DD）／未取得／発行できない
- 有効期限：YYYY/MM/DD
- 直近の変更：新規取得／前回移管／名義変更（あれば日付：YYYY/MM/DD）
- WHOIS/RDAPのステータス（分かれば）：例）clientTransferProhibited など

■希望：
- できるだけ早く移管したい／期限までに確実に完了したい
- 可能なら、移管が止まっている“具体的な理由”と解除方法を教えてほしい

■添付（可能なら）：
- エラー画面のスクショ
- DNSレコード控え（メール運用ありの場合はMX/SPF/DKIM/DMARC）

移管先（レジストラ）の選び方：価格より大事な評価軸

移管先を選ぶとき、つい「移管料金が安い」「初年度が安い」で決めたくなりますが、実務で差が出るのは “運用しやすさ” と “事故りにくさ” です。

特に、複数ドメインを持つ人・メール運用がある人・法人/チーム運用の人ほど、月々の手間（＝将来コスト） が効いてきます。

更新料金・移管料金だけでなく“将来の運用コスト”を見る

価格比較は、次の3層に分けると判断がブレません。

1) 表面の価格（移管料金・更新料金）

移管料金（＝実質「移管に必要な支払い」）
更新料金（2年目以降に毎年かかる）
複数年更新の割引があるか

2) 見落としがちな“追加コスト”

WHOIS公開代行（プライバシー保護）が有料か無料か
DNSの高度機能が有料か（DNSSEC、API、レコード数上限など）
メール転送やドメイン付属メールの有無・料金
更新忘れ防止機能（自動更新、期限通知）が十分か

3) “手間”が生むコスト（時間・リスク）

管理画面が分かりにくく、設定のたびに迷う
サポートが遅く、止まった時の復旧に時間がかかる
権限管理が弱く、チーム運用で事故りやすい

✅ 実務向けの見積もりテンプレ（考え方）

年間コスト＝更新料金
＋（必要なら）WHOIS公開代行
＋（必要なら）DNS高度機能
＋（あなたの運用に必要な）メール関連
＋（見えないが重要）トラブル時の復旧しやすさ

「年間で数百円安い」より、「止まったときに即復旧できる」方が、結果的に安いことが多いです。

DNSの自由度（TXT複数、API、DNSSECなど）

ドメイン移管で“止まる原因”はDNSが中心なので、移管先選びでもDNSは最重要です。

最低限チェックしたいDNS機能

レコード種類が一通り揃っている
- A / AAAA / CNAME / MX / TXT は当然として、CAA / SRV なども扱えると安心
TXTレコードを複数置ける（上限が小さすぎない）
- SPF、DKIM、DMARC、所有権確認などでTXTは増えがちです
TTLを柔軟に変更できる（短くできる／戻せる）
レコード編集が快適
- 一括編集、検索、履歴、インポート/エクスポート（移管・移行時に効きます）

自動化したい人は「API」が効く

DNS APIがあると、証明書更新の自動化（DNS-01）や大量ドメイン運用が楽になります
逆に、APIがない・制限が厳しいと、手作業が増えます

DNSSECは“使う予定”があるなら最初に確認

DNSSECは、DNS応答の改ざん等を防ぐための仕組みで、対応する場合はDNS側とレジストラ側の両方が関係します。

DNSサービス側でDNSSECを有効化
その上で、レジストラ側にDSレコード登録などの手続きが必要になることがあります（＝レジストラがDNSSEC運用に対応しているかが重要）

✅ 結論：DNSは「今使うか」より「将来必要になったとき、詰まないか」で選ぶと安全です。

セキュリティ（2FA、通知、ロック機能、復旧フロー）

レジストラ選びで一番“取り返しがつかない差”が出るのがセキュリティです。
ドメインは乗っ取られると、サイトもメールも全部持っていかれます。

最低限ほしいセキュリティ機能

2FA（2段階認証）対応
- できれば「ログインだけ」ではなく、移管ロック解除・連絡先変更など重要操作にも追加認証が入る
重要操作の通知（メール・アプリ通知）
移管ロック（Transfer Lock）の扱いが明確
- ON/OFFが分かりやすい
- ロック解除に本人確認が必要など“安全側”の設計だと安心
アカウント復旧フローが堅い
- 本人確認が丁寧（＝乗っ取り耐性）
- ただし緊急時に詰まないよう、復旧手順が分かりやすい

チーム/法人運用なら追加で見たい

権限分離（閲覧のみ／DNS編集のみ／請求のみなど）
監査ログ（誰がいつ何を変えたか）
複数担当者の連絡先・通知先を設定できる

✅ 目安：セキュリティが強いほど、移管手続きは少し面倒になります。
でもその“面倒”は、事故を減らすためのコストです。

サポート（日本語対応、対応時間、手続きの分かりやすさ）

サポートは、平常時は軽視されがちですが、「承認メールが来ない」「ロックが外れない」「期限が近い」 のような時に真価が出ます。

初心者が見ておくべきポイント

日本語で、手順が具体的（画面名・項目名まで書いてある）
問い合わせ窓口が複数ある（チケット/チャット/電話など）
対応時間が明確（夜間・休日の対応が必要な人は特に）
“移管元で何をするか”まで説明がある
- 移管は相手側も絡むので、片側だけの説明だと迷いやすいです

事前にできる小さなテスト

公式ヘルプで「AuthCode」「移管ロック」「DNSSEC」「WHOIS」などで検索して、説明が分かりやすいか見る
問い合わせの返答速度の評判も参考になります（緊急時はここが効きます）

「サーバー一体型」vs「ドメイン専業」比較チェック

レジストラは大きく「サーバー一体型」と「ドメイン専業」に分かれます。
どちらが正解というより、あなたの運用に合うかで決めるのがコツです。

スクロールできます

観点	サーバー一体型	ドメイン専業
こんな人向き	1サイトをシンプルに運用したい	複数ドメインを体系的に管理したい
強み	まとめて管理しやすい（初心者向き）	DNSやセキュリティ機能が充実しやすい
落とし穴	付属DNSに依存して移管時にDNS移行が必要になりやすい	設定項目が多く最初は戸惑うことがある
メール運用	付属メールが便利な場合あり	外部メール連携前提で自由度が高い場合あり
中長期	“便利”が将来の移行コストになることも	“最初の学習コスト”が将来の運用コストを下げやすい

迷ったときの決め方

ドメインが 1〜2個、メール運用がシンプル → 一体型で十分なことが多い
ドメインが 増える予定、メール認証（SPF/DKIM/DMARC）やDNSSECも触りそう → 専業寄りが安心
法人/チーム運用 → 権限管理・監査ログ・復旧フロー重視で選ぶ

安全運用のための最低限セキュリティ（乗っ取り対策）

ドメインは「Webサイトの住所」であると同時に、メール・ログイン・各種連携の起点です。
一度奪われると、復旧に時間も信用も持っていかれがちなので、“面倒でも効く3点セット”だけは最初に固めておくのが得策です。

ドメイン乗っ取りが起きる典型ルート

初心者でも起きやすい“入口”は、ほぼ次のパターンに集約されます。

レジストラのログイン情報が盗まれる（フィッシング／使い回し／端末感染）
いちばん多い王道ルートです。偽ログイン画面でID・パスワードを抜かれ、本人の気づかないうちに操作されます。JPCERT/CCがフィッシング起点の乗っ取り事例を解説しています。
承認メールを受け取る“連絡先メール”が乗っ取られる
レジストラ側のパスワードリセット、移管承認、設定変更通知などが全部ここに来るため、メールが落ちると一気に不利になります。
DNS管理（DNSホスティング）のアカウントが侵害される
ドメイン移管をしていなくても、DNSを書き換えられるだけでサイトが偽ページへ誘導されたり、メールが別サーバーに流されたりします。
「移管ロック解除」や「AuthCode取得」を狙われる
ロック解除の隙、AuthCodeの扱いミス（共有チャットに貼る等）があると、第三者移管が成立しやすくなります。
権限が曖昧なチーム運用（共有ID／退職者の権限放置）
“悪意”でなくても、誤操作・漏えいの確率が上がります。

起きる被害は、サイトの乗っ取りだけではありません。

サイトが偽サイトへ誘導される（広告・マルウェア・詐欺）
メールが盗み見られる／送信なりすましが増える
サービスのログインリセットが次々突破される（ドメインが起点のため）

守るべき3点：アカウント／メール／ロック

ここだけ守れば、難しいセキュリティを全部やらなくても“実害”はかなり減らせます。

1) アカウント（レジストラ／DNS）の守り方

パスワードは使い回さない（パスワード管理ツール推奨）
2FA（2段階認証）を必ず有効化
できればSMSより「認証アプリ」や「セキュリティキー」が安全寄り
共有IDをやめる
人ごとにアカウントを分け、必要なら権限を分離（DNSだけ触れる等）
変更通知・ログ（履歴）をON
“いつ誰が何を変えたか”が追えると、初動が速くなります

2) メール（承認・復旧の要）の守り方

メールは「ドメイン運用の親アカウント」です。ここが弱いと全部弱くなります。

連絡先メールは“確実に受け取れる箱”にする
ドメインのメール（例：info@あなたのドメイン）を連絡先にすると、DNS事故時に自分で自分の首を絞めやすいです
→ 連絡先は、影響を受けにくい外部メールに寄せるのが無難
メール側にも2FA＋復旧手段を設定（復旧メール・電話番号など）
迷惑メール隔離に注意（法人メールは隔離されやすい）
移管・更新時期だけでも通知を強めておくと安心です

3) ロック（不正移管・不正変更の“最後の壁”）

ロックは「突破されにくくする」だけでなく、突破されたときに“時間を稼ぐ”意味でも重要です。

Transfer Lock（移管ロック）は通常ON
移管のときだけOFFにして、完了したらすぐ戻す
ICANNも、移管ロックを追加防御として紹介しています。
より強い保護が必要なら Registry Lock を検討
（提供の有無・料金・解除手順は会社ごとに違う）
政府系の注意喚起では「Client Lock / Registry Lock」のような強いロック層を推奨しています。UK National Cyber Security Centre
DNSSECは“必要性があるなら”早めに方針決定
途中から入れるのも可能ですが、DNS運用とレジストラ側設定の両方が絡むので、運用設計が大事です

更新漏れを仕組みで防ぐ（自動更新・通知・支払い管理）

「乗っ取り」と同じくらい致命的なのが、更新漏れ（期限切れ）です。
期限切れは、サイト停止・メール停止・各種ログイン不能につながり、復旧も手間が増えます。

初心者向けに“堅い型”を作るなら、これだけで十分です。

最低限の運用セット

自動更新：ON
通知先：複数（可能なら）
例：担当者＋共有メール／チームの配布先
支払い：失効しにくい方法
- カード更新月を意識（カード更新で自動更新が落ちるのがあるある）
- 法人なら“ドメイン専用の支払い手段”を分けると管理が楽
リマインド：3点打ち
- 60日前／30日前／7日前（カレンダーで自動化）
重要ドメインは複数年更新も検討
ただし上限年数があるTLDもあるので、更新年数の扱いは管理画面で確認

もし異変が起きたときの初動（連絡先・ログ確認）

異変が起きたときは、焦って手当たり次第に触るより、順番が大事です。
下の手順に沿うと、復旧と原因特定が速くなります。

まず“本当に障害か”を確認
- 自分の回線だけの問題か切り分け（スマホ回線／別端末／別ネットワーク）
証拠を残す（後で揉めたときに効く）
- いつから／何が起きたか（スクショ・時刻）
- 現在のDNSレコード、ネームサーバー、WHOIS/RDAPの表示
アカウント防御を最優先で固める
- レジストラ／DNS／メールのパスワード変更
- 2FA強制、ログイン中セッションの破棄（機能があれば）
- 復旧メール・電話番号が改ざんされていないか確認
変更履歴（ログ）を確認して、差分を戻す
- DNSが書き換えられているなら、直前の正しい値へ戻す
- メール転送・フィルタ・ルールが追加されていないか確認
レジストラに緊急連絡（“何をしてほしいか”まで伝える）
- 「不正移管が進行中か」「ロックを強化できるか」「変更の差し戻しが可能か」
- 重要ドメインは Registry Lock の導入相談も検討
復旧後の監視を強める（再発防止）
- 変更通知の強化、権限の棚卸し、DNSのバックアップ（エクスポート）
- 可能ならDNS変更の監視・アラートを設定

FAQ：検索されやすい疑問に先回り

移管中にサイトは止まる？

結論から言うと、「移管＝サイト停止」ではありません。
ただし、移管の前後で DNSや契約まわりを誤ると止まることがあります。

基本的に止まらないパターン（安全）

ネームサーバー（NS）を変更しない
サイトのサーバー（レンタルサーバー／クラウド）をそのまま使う
移管中にDNSレコードを触らない（A/CNAME/MX/TXTなど）

止まりやすいパターン（要注意）

移管をきっかけに、NSが切り替わり DNSレコードが未移行のまま
旧サーバーや旧DNSを「もう不要」と思って解約・停止してしまう
SSLやCDNの設定がDNSに依存していて、レコード抜けが起きる

止めないための現実的なコツ（初心者向け）

✅ 可能なら「移管中はNS据え置き」→ 移管完了後にDNS整理が一番安全
✅ もしNS変更も同時にやるなら、事前にDNSゾーンを丸ごとコピー
- 特に MX / SPF / DKIM / DMARC を忘れない
✅ 重大ドメイン（売上・メール・決済）は、最初からまとめて動かさず
低リスクな1件でテスト→本番がおすすめ

ネームサーバー設定は勝手に変わる？

多くのケースでは、移管しただけでNSが自動変更されることはありません。
ただし、「移管先の申請画面の選択」や「サービス形態」によっては、意図せず切り替わることがあります。

“勝手に変わったように見える”代表例

移管申請時に「移管先のDNSを使う」を選んでいた
「サーバー一体型」の契約で、ドメイン側がサービスのDNSに寄る設計だった
移管完了後、管理画面で初期表示が“移管先DNS”になっており、気づかず保存した

チェックすべきポイント（ここだけ見ればOK）

移管申請の途中に「ネームサーバーの選択」があるか
移管完了後に、NSが想定どおりか（旧NSのままか／新NSに変えたか）

もしNSが変わってしまったら

⚠️ まず慌てず、元のNSに戻せるなら戻す（最短で復旧しやすい）
すでに新NS運用にするなら、DNSレコードの漏れを点検してから切り替える
- サイトは表示できても「メールだけ死ぬ」が非常に多いです

メールアドレスはそのまま使える？

原則として、ドメイン移管だけでメールアドレスが消えることはありません。
ただし、メールの実体は「どのメールサービスを使っているか」で決まるので、条件付きで止まります。

そのまま使える条件（よくある成功パターン）

メールサービス（例：Google Workspace／Microsoft 365／サーバー付属メール）が変わらない
DNSの MX/TXT（SPF/DKIM/DMARC） が維持されている
NSを変えない、もしくはDNSを完全にコピーしている

止まる／届かなくなる主因

NS変更で MXレコードが移っていない
送信ドメイン認証（SPF/DKIM/DMARC）が欠けて 迷惑メール扱いが増える
「サーバー付属メール」を使っているのに、旧サーバーを解約してしまう

最低限の安全確認（これだけで事故が激減）

✅ DNS：MX / SPF / DKIM / DMARC が揃っているか
✅ 送受信テスト：外部Gmail等から送る→受ける／自ドメインから送る→届く
✅ 重要運用なら、移管前にメールデータのバックアップやエクスポートも検討

名義変更（譲渡）と移管は同時にできる？おすすめ順序は？

同時にやると詰まりやすいので、基本方針はこれです。

同時進行は避ける（順番を決める）
“60日ロック”の影響を先に確認する

gTLD（.com/.net など）の大事な注意点

登録者情報（名義）を変更すると、その後60日間は他社移管できなくなる運用が原則として入ります
ただしレジストラによっては、名義変更の手続き時に 60日ロックを回避（オプトアウト）できる場合があります（提供は必須ではありません）

おすすめ順序（迷ったらこのどちらか）

移管を先にやる（安全寄り）
- 先にレジストラを移してから名義変更
- 余計な制限を踏みにくい
名義変更を先にやる必要がある場合
- そのレジストラが「60日ロックのオプトアウト」を提供しているか確認
- オプトアウト不可なら、名義変更後に60日待つ前提で計画する

JPドメインの場合

手続き体系がgTLDと違い、指定事業者変更が軸になります
とはいえ「同時進行で混乱しやすい」のは同じなので、
✅ 名義関連の手続きと移管を分けて進めるのが無難です

複数ドメインをまとめて移管する最適な進め方は？

複数ドメイン移管は、気合いで一気にやるより、“設計→小テスト→バッチ処理”が強いです。
初心者でも安全に進められる型を提示します。

1) まず棚卸し（これが8割）

ドメイン一覧を作り、最低限ここを埋めます。

ドメイン名 / TLD（gTLD or JP）
有効期限（近い順に危険）
DNSの管理場所（どこでレコード編集しているか）
メール利用の有無（MXがあるか）
重要度（売上・決済・主要サイト・問い合わせ用など）

2) ルールでグルーピングする

gTLDグループ：AuthCode・ロック解除・承認フロー中心
JPグループ：指定事業者変更（AuthCode期限35日を意識）
今は動かせないグループ：取得直後／名義変更直後／移管直後などの制限対象

3) “DNS方針”を決める（ここが事故を分ける）

方針A：NS据え置き（最も安全）
→ まず移管だけ済ませ、DNS移行は後日
方針B：NSも切り替える（難易度が上がる）
→ DNSゾーンの完全コピー、メール認証まで含めて移行

4) バッチで進める（おすすめ運用）

まず低重要度ドメインを 1〜2件だけ移管して手順を固める
次に5〜10件ずつ移管（メールなし → メールあり → 主要ドメインの順）
有効期限が近いものは、焦って移管するより
先に更新して余裕を作ってから移管が安全

5) 完了後の統一ルールを入れる（事故が減る）

✅ 2FA（レジストラ／メール）
✅ 移管ロックはONに戻す
✅ 自動更新ON＋通知先の複数化
✅ 変更履歴・通知を有効化（できる範囲で）

失敗しない最短ルート（チェックリスト付き）

ドメイン移管は、やること自体は難しくありません。
失敗のほとんどは 「準備不足」か「移管中に余計な変更を重ねた」のどちらかです。

ここでは、初心者でも最短で安全に終わらせるための“型”をチェックリストに落とし込みます。

最重要は「AuthCode・ロック・受信できるWHOISメール」

移管が止まる／事故る原因は、結局この3つに集約されます。

AuthCode（EPP/AuthInfo）
入力ミス・期限切れ・古いコードの使い回しが多発ポイント
移管ロック（Transfer Lock）
OFFにできていない、ステータスが移管禁止のまま
受信できるWHOISメール（登録者連絡先）
承認メールが受け取れないと、手続きが進まない

この3点が揃っていれば、移管は“進む”確率が一気に上がります。

gTLDとJPで手順が違う—まず種別判定から

手順を間違える最大の原因が「同じ移管だと思って同じように進める」ことです。

gTLD（.com / .net など）
「レジストラ移管（Transfer）」が基本。
AuthCode＋承認フロー（メール or 画面）＋移管ロック解除が中心。
JP（.jp / .co.jp など）
基本は「指定事業者変更」という考え方。
さらに、汎用JPは “登録者番号単位”で動く場合があり、複数ドメインがまとめて対象になることがあります。

✅ 最短ルートのコツ
最初に 「gTLDかJPか」「JPなら汎用JPか属性型か」を判定して、チェックリストを分岐させるのが一番早いです。

“DNSを控える→承認メール→完了後チェック”で事故を防ぐ

移管でサイトやメールが止まるのは、ほぼ例外なく DNSまわりが原因です。
なので、最短ルートは次の順で固定すると事故が激減します。

DNSを控える（バックアップ）
移管申請→承認メール（または承認操作）を即処理
完了後に必ず確認（自動更新・NS・DNS・メール・HTTPS）

特に初心者は、移管中にDNSや名義を触って“原因を増やす”のが一番危険です。
移管中は「承認をこなす」以外の変更を増やさないのが安全です。

コピペ用：失敗しない最短ルートチェックリスト

共通（gTLD/JPどちらでも最初にやる）

[ ] 対象ドメインの種別を確認（gTLD / JP / その他）
[ ] 有効期限を確認（期限が近い場合は、先に更新して余裕を作る）
[ ] 現在のDNSレコードを控える（A/AAAA/CNAME/MX/TXT を最低限）
[ ] WHOISの連絡先メールが“確実に受信できる”状態（迷惑メール・隔離も含めて確認）
[ ] 移管中にやらないことを決める（DNS変更／名義変更／解約は避ける）

gTLD（.com/.netなど）

移管元（いまの管理会社）

[ ] Transfer Lock をOFFにできる
[ ] AuthCode（EPP/AuthInfo）を取得できる（申請直前に取得）
[ ] ドメインステータスが移管可能（例：clientTransferProhibited が残っていない）

移管先（これからの管理会社）

[ ] 移管申請を作成し、AuthCodeを正確に入力（空白・改行なし）
[ ] 申請時にNS（ネームサーバー）が意図せず変わらない設定になっているか確認

承認・完了

[ ] 承認メール／管理画面の承認操作を即対応（放置しない）
[ ] 完了後：自動更新ON／支払い情報／WHOIS情報／移管ロックONに戻す
[ ] 完了後：サイト表示／HTTPS／メール送受信（使っている場合）をテスト

JP（.jp/.co.jpなど）

[ ] 「指定事業者変更」の手続きとして進める（移管先の案内に沿う）
[ ] AuthCodeを取得（有効期限があるため、取得日を控える）
[ ] 汎用JPの場合：対象が「ドメイン単位」か「登録者番号（REG-）単位」か確認
まとめて動いて困らないか、先に棚卸し
[ ] 属性型・地域型の場合：担当者情報など追加提出が必要か、移管先の要件を事前確認
[ ] 承認・完了の通知を見落とさない（移管元/移管先どちらの承認が必要か確認）
[ ] 完了後：自動更新／通知先／DNS（NSが変わっていないか）／メール送受信（使っている場合）を確認

まとめ

ドメイン移管は、正しく理解すると「怖い手続き」ではなく、運用をラクにし、コストや安全性を見直すための整備です。
ただし、失敗のダメージ（サイト停止・メール不達・機会損失）が大きいのも事実。だからこそ、最短ルートは“丁寧な準備”にあります。

失敗しない最短ルートを一言でまとめると、これです。

まず ドメイン種別を判定（gTLDかJPか）
次に 最重要3点を揃える（AuthCode／移管ロック／受信できる連絡先メール）
そして DNSを控える→承認→完了後チェックの順番を守る

特に覚えておきたいのは、SEOやアクセスが乱れるときの原因です。
順位が変わるのは“移管”そのものではなく、移管前後の DNSミスや一時停止、HTTPS・メール設定の崩れが引き金になります。ここを避ければ、必要以上に怖がる必要はありません。

最後に、この記事の要点を「やること」だけに圧縮したチェックリストを置きます。迷ったらここに戻ってください。

移管前
- ドメイン種別を確認（gTLD／JP）
- 有効期限を確認（ギリギリなら先に更新して余裕を作る）
- DNSを控える（A/AAAA/CNAME/MX/TXTを最低限）
- 移管ロック解除が可能か確認
- AuthCodeを“申請直前”に取得
- 連絡先メールが確実に受信できる状態か確認（迷惑メール・隔離も含む）
移管中
- 承認メール／承認操作を見落とさない（放置が遅延の最大原因）
- 余計な変更をしない（DNS変更・名義変更・解約は避ける）
移管後
- 自動更新ON／通知設定／支払い設定を確認
- ロックをONに戻す、2FAを有効化
- サイト表示／HTTPS／メール送受信をテスト
- Search Console・GAで異常がないか確認