2026年8月26日
2026年8月26日
Transfer Lock(移管ロック)の解除と再設定の方法|「再発行」が必要なのはAuthCode
Transfer Lock(移管ロック、レジストラロック)は、ドメインに付いている「移管を受け付けない」という状態の設定で、パスワードのように再発行するものではありません。操作できるのは、レジストラの管理画面で解除する・有効に戻すの2つです。再発行(作り直し)ができるのは、移管のときに使う AuthCode のほうです。この記事では、ロックの種類の見分け方、解除から再設定までの手順、解除できないときの原因と確認方法を説明します。
「Transfer Lock の再発行」で起きている取り違え
「移管ロックを再発行したい」という相談は、たいてい次のどちらかです。
- ロックを掛け直したい: 移管をやめた、または移管が終わったので、外していたロックを元に戻したい
- AuthCode を作り直したい: 発行した AuthCode を他人に渡した、期限が切れた、どこかに貼ってしまったので、新しい値にしたい
前者はロックを有効にする操作、後者は AuthCode の再発行で、管理画面でも別々の項目になっていることが多いです。移管を中止したときや、AuthCode が漏れた疑いがあるときは、両方を行うのが基本です。
ロックの種類を見分ける
ドメインの状態は、EPP ステータスコードという共通の値で表されます。移管に関係する主な値は次のとおりです。
- clientTransferProhibited: レジストラが設定するロックで、いわゆる移管ロックです。登録者が管理画面から解除・有効化できます。
- serverTransferProhibited: レジストリが設定するロックです。レジストリロックのサービスを利用している場合のほか、係争中などの理由で付くことがあります。管理画面からは外せず、レジストラを通じた手続きが必要です。
- pendingTransfer: 移管の申請が出され、処理中の状態です。
まずは現在の状態を照会します。
# RDAP でステータスを確認する(rdap.org は適切な RDAP サーバーへ転送する公開サービス)
curl -sL https://rdap.org/domain/example.com | jq '.status'
# WHOIS が使える TLD ではこちらでも確認できる
whois example.com | grep -i 'status'
RDAP では client transfer prohibited のように、単語を空白で区切った小文字の表記で返ってきます。WHOIS では clientTransferProhibited の形です。意味は同じです。
このほか、ステータスには出ない制限もあります。gTLD では、ICANN の移管ポリシーにより、新規登録や前回の移管から60日以内はレジストラが移管を拒否できるとされ、多くのレジストラがこの期間の移管を受け付けません。登録者の氏名・組織名・メールアドレスを大きく変更したあとにも、60日間の移管制限が掛かる場合があります。ICANN では移管ポリシーの改定が進められており、これらの日数や扱いは見直される方向です。手続きの前に、ICANN とレジストラの最新の案内を確認してください(2026年10月現在)。
移管ロックを解除する手順
1. 移管の準備ができているか確認する
ロックを外すと、AuthCode を知っている人は移管を申請できる状態になります。外す前に、次の点を確認しておくと、解除している時間を短くできます。
- 移管先のレジストラと、申し込みの手順が決まっている
- ドメインの有効期限までに余裕がある
- 登録者のメールアドレスが受信できる(移管の確認や通知が届くため)
- DNS をどこで管理しているかを把握している(移管元の DNS サービスを使っている場合、移管後に使えなくなることがある)
2. 管理画面でロックを解除する
レジストラの管理画面で対象ドメインを開き、移管ロックの設定を解除します。項目名は「移管ロック」「レジストラロック」「ドメインロック」「Transfer Lock」などレジストラによって異なり、画面の構成も変わることがあるため、ドメインの詳細やセキュリティに関する項目の中から探します。解除の際に、二段階認証や登録メールアドレスでの確認を求められることもあります。
3. 解除が反映されたかを確認する
管理画面で解除しても、ステータスに反映されるまで時間が掛かることがあります。手順の冒頭のコマンドで再度照会し、clientTransferProhibited(client transfer prohibited)が消えたことを確かめてから、AuthCode の取得と移管の申し込みに進みます。
移管ロックを有効に戻す手順
移管が完了したとき
移管が終わると、ドメインの管理は移管先のレジストラに移ります。移管先で移管ロックが既定で有効になるかどうかはレジストラによって異なるため、移管完了後に移管先の管理画面で設定を確認し、無効なら有効にします。そのうえで、ステータスを照会して clientTransferProhibited が付いていることを確かめます。
移管をやめたとき
移管を中止した場合や、申し込みが失敗した場合は、移管元の管理画面でロックを有効に戻します。AuthCode を発行していた場合は、あわせて再発行し、古い値を使えないようにしておきます。制作会社などに AuthCode を渡していたときは、特に忘れないようにします。
ロックを解除できない・状態が変わらないとき
可能性の高い順に確認します。
- 登録や前回の移管から60日以内: 管理画面の登録日・移管日を確認します。期間が過ぎるまで待つのが一般的です。
- 登録者の変更による移管制限: 最近、登録者の氏名・組織名・メールアドレスを変えていないかを確認します。制限の期間や解除の可否はレジストラに問い合わせます。
- 期限切れ・未払い: 有効期限を過ぎて猶予期間に入っていると、解除や移管ができないことがあります。先に更新を済ませます。
- serverTransferProhibited が付いている: レジストリ側のロックです。レジストリロックを申し込んでいる場合は、その解除手続きを行います。心当たりがなければ、理由をレジストラに確認します。
- 反映待ち: 解除直後で照会結果が変わっていないだけの場合があります。時間をおいて照会し直します。
ドメインをレンタルサーバーの会社や制作会社が管理している場合、利用者の画面にはロックの項目が表示されないことがあります。その場合は、契約先にロックの解除を依頼します。
ロックを有効にしておく理由
移管ロックは、アカウントを知らない第三者が AuthCode を手に入れても、勝手に移管されないようにするための仕組みです。ドメインを奪われると、サイトの表示だけでなくメールも乗っ取られ、WordPress のパスワード再設定メールまで相手に届く状態になります。普段は有効にしておき、移管するときだけ短時間外す運用が安全です。
ただし、移管ロックはレジストラのアカウントに入られると管理画面から外されてしまいます。レジストラのアカウントには二段階認証を設定し、登録メールアドレスも保護しておきます。事業の中心になっているドメインでは、管理画面の操作だけでは外せないレジストリロックを検討する価値があります。
まとめ
- 移管ロックは状態の設定で、再発行するものではありません。作り直せるのは AuthCode です。
clientTransferProhibitedは管理画面で外せるロック、serverTransferProhibitedはレジストリ側のロックです。- 解除したらステータスの変化を照会で確かめてから、AuthCode の取得と移管に進みます。
- 移管が終わったら移管先で、移管をやめたら移管元で、ロックを有効に戻し、必要に応じて AuthCode を再発行します。
- 移管ロックに加えて、レジストラのアカウントの二段階認証も設定しておきます。