AuthCode（EPP コード、移管認証鍵とも呼ばれます）は、ドメインを今管理しているレジストラ（.jp の場合は指定事業者）が発行します。取得の手順そのものは「管理画面で移管ロックを外し、AuthCode を表示または発行する」と短いのですが、実際につまずくのは、誰に請求すればよいのか分からない、登録者が自分ではない、登録メールが受け取れない、といった手前の部分です。この記事では、まず請求先と登録者を特定する方法を説明し、そのうえで契約の形ごとの取得ルートと、取得できないときの進め方を整理します。
手順1：ドメインを管理しているレジストラを特定する
AuthCode を発行できるのは、そのドメインを現在管理しているレジストラだけです。移管先のレジストラや、DNS を管理しているサービスには発行できません。まず照会して、管理元を確かめます。
# RDAP で管理元のレジストラ名を確認する
curl -sL https://rdap.org/domain/example.com \
| jq -r '.entities[]? | select(.roles | index("registrar")) | .vcardArray[1][] | select(.[0] == "fn") | .[3]'
# WHOIS が使える TLD ではこちらでも確認できる
whois example.com | grep -i 'registrar:'ここに出てくる名前が、自分の契約先と同じとは限りません。レンタルサーバーの会社や制作会社が、別のレジストラの再販（リセラー）としてドメインを提供していることがあり、その場合は照会結果には卸元のレジストラ名が表示されます。自分がログインできる管理画面がどこなのか、契約時のメールや請求書から確認します。
手順2：登録者が誰になっているかを確認する
AuthCode を受け取って移管すると、ドメインは登録者のものとして移管先に移ります。登録者が自分（自社）以外の名義になっていると、移管しても管理の権限は名義人に残ります。管理画面の登録者情報を開き、氏名や組織名を確認します。WHOIS代理公開を使っている場合、外部からの照会では代行業者の情報しか見えないため、管理画面で確認する必要があります。
登録者が制作会社や元担当者の個人名だった場合は、AuthCode の取得より先に、登録者を自社に変更する手続きを相談します。gTLD では、登録者の氏名・組織名・メールアドレスを大きく変えると、変更後の一定期間は移管できなくなることがあるため、移管の日程はこの期間を見込んで決めます。
契約の形別の取得ルート
レジストラと直接契約している場合
もっとも単純な形です。レジストラの管理画面にログインし、対象ドメインの移管ロックを外したうえで、AuthCode の項目から表示または発行します。項目名は「AuthCode」「認証コード」「EPP コード」「移管用コード」など各社で異なり、画面も変わることがあるため、ドメインの詳細や移管に関するメニューから探します。画面に表示される方式のほか、登録者のメールアドレスに送られる方式もあります。
レンタルサーバーとセットで契約している場合
サーバーの申し込み時にドメインを一緒に取得した場合や、サーバー契約の特典としてドメインを取得した場合は、サーバー会社の管理画面からドメインを操作します。AuthCode の項目が利用者の画面にない場合は、サポートへの依頼で発行する方式のことがあります。特典で取得したドメインは、サーバー契約との組み合わせが条件になっていることがあり、移管する際に更新料の支払いなどの条件が付く場合があるため、規約を先に確認します。
制作会社や元担当者が管理している場合
管理画面のアカウントを持っている人に、AuthCode の発行を依頼します。このとき、アカウントのパスワードを教えてもらって自分でログインするのは避け、発行された AuthCode だけを受け取る形にします。あわせて、登録者の名義と、登録メールアドレスが誰のものかを確認しておきます。
管理している人と連絡が取れない場合は、レジストラの窓口に、登録者本人であることを示して手続きできるかを相談します。必要な書類や手順はレジストラによって異なり、法人であれば登記に関する書類、個人であれば本人確認の書類を求められるのが一般的です。
登録メールアドレスが受け取れない場合
AuthCode がメールで送られる方式だと、登録メールアドレスが使えないと受け取れません。そのドメイン自身のメールアドレスを登録していて、ドメインが止まっているために受信できない、というケースもあります。管理画面にログインできるなら、先に登録メールアドレスを受信できるものに変更し、確認メールに応答してから AuthCode を請求します。ログインもできない場合は、上と同じくレジストラの本人確認の手続きを相談します。
.jp ドメインの場合
.jp ドメインでも、指定事業者を変更する際に AuthCode が使われ、発行は現在の指定事業者が行います。co.jp などの属性型ドメインは登録できる組織の条件があり、手続きの確認事項も汎用JPドメインと異なる部分があるため、移管先の指定事業者の案内とあわせて進めます。
請求する前に確認すること
AuthCode が手に入っても、次の状態だと移管は通りません。請求の前に確認しておくと、二度手間を防げます。
- 移管ロックが解除できる状態か（ステータスに
clientTransferProhibitedが残っていないか） - 新規登録や前回の移管から60日以上たっているか（gTLD で多くのレジストラが採用している制限）
- 有効期限までに余裕があるか
- 未払いや係争などで手続きが止められていないか
ICANN では移管ポリシーの改定が進められており、AuthCode の名称（Transfer Authorization Code）や有効期限、発行の方法、各種の制限の日数が見直される方向です。適用の時期と内容は、ICANN と契約先のレジストラの最新の案内を確認してください（2026年10月現在）。
受け取った AuthCode を使う
AuthCode は大文字・小文字や記号を区別するため、手で書き写さず、コピーして移管先の申込画面に直接貼り付けます。前後に空白や改行が入らないようにします。発行から時間がたつと使えなくなるレジストラもあるので、取得したら早めに移管を申し込みます。
AuthCode は、知っている人が移管を申請できる値です。チャットのグループや共有ドキュメント、問い合わせフォームの本文などに貼らないようにします。作業を他人に任せた場合や、移管を取りやめた場合は、AuthCode を再発行して古い値を使えないようにし、移管ロックも有効に戻します。
問い合わせるときに用意するもの
管理画面で取得できず、レジストラやサーバー会社に問い合わせる場合は、次の情報をそろえておくと話が早く進みます。
- ドメイン名と、契約時の会員番号などの識別情報
- 登録者の名義（氏名・組織名）と登録メールアドレス
- AuthCode が必要な理由（他社への移管など）と、移管先のレジストラ名
- 管理画面で試したことと、表示されたメッセージ
アカウントのパスワードや、移管先で発行された情報は、問い合わせの文面に書く必要はありません。
まとめ
- AuthCode を発行できるのは、ドメインを現在管理しているレジストラ（.jp では指定事業者）だけです。
- 照会結果のレジストラ名と自分の契約先が違うことがあるため、契約時の情報で管理画面の場所を確かめます。
- 登録者が自分以外の名義なら、取得より先に登録者の変更を相談します。
- 制作会社などに管理を任せている場合は、パスワードではなく AuthCode だけを受け取ります。
- 取得したら早めに移管を申し込み、取りやめた場合は再発行して移管ロックを戻します。