複数ドメインは、名前と更新日だけで管理しません。契約主体とDNSの管理先を同じ台帳へ整理します。現在使っている機能と停止時の影響も必要です。更新通知が届いても、誰の契約で何に使っているか分からなければ、安全に更新や廃止を判断できません。

最初に確認したいのは、会社が登録者になっているかです。社員や制作会社のアカウントで取得したドメインは、担当者交代や契約終了のときに管理権限を失う可能性があります。技術設定を調べる前に、誰が契約上の主体かを確かめます。

契約主体と管理画面へ入れる人を分けて確認する

ICANNの登録者向け案内では、登録者がレジストラと契約し、設定をレジストラ経由で管理すると説明されています。制作会社が日常の操作を代行していても、会社が登録者になっているとは限りません。契約書、請求、レジストラの登録情報を照合します。

法人のドメインは、会社の正式な法人名を登録者として管理するのが基本です。ICANNが示す法人ポートフォリオの実務でも、外部へ管理を委託する場合に法人自身を登録者としておく考え方が示されています。

社員個人や制作会社が登録者になっていたら、いきなりアカウントを削除しません。退職者名義の場合も同様です。現在の権限と移管制限を確認します。

認証方法と連絡先を整えてから、会社管理のアカウントへ引き継ぎます。登録者と、技術担当・請求担当として操作する人を分ければ、外部委託を続けながら所有関係を明確にできます。

一つの台帳で契約・DNS・用途を横断して見る

台帳は、契約一覧とサーバー一覧を別々に作るより、ドメインを一行にして関係を横へ並べた方が確認しやすいです。同じ項目で全ドメインを比較するため、次のような列を用意します。

項目記録する内容判断できること
ドメインと登録者正式名、法人名義、レジストラ誰の契約で、どこへ連絡するか
更新有効期限、自動更新、支払い方法、通知先期限前に更新できる状態か
DNSネームサーバー、DNS提供会社、管理者Web・メールの設定をどこで変えるか
利用先Web、メール、転送、外部サービス停止すると何へ影響するか
管理責任社内責任者、作業委託先、最終確認日誰が判断し、誰が操作するか
廃止条件継続理由、依存サービス、再確認日更新を続けるか終了するか

台帳へパスワードや認証コードを直接書く必要はありません。会社のパスワード管理ツールにある保管先や共有グループを記載します。資料を見られる人と、設定を変更できる人を同じ範囲にしない方が良い場合もあります。

取得目的も残します。公式サイトと採用サイトでは終了判断が異なります。短期のキャンペーン、ブランド保護、旧社名からの転送も目的を区別します。「未使用」だけでは、廃止してよいのか、将来利用のため保有しているのか分かりません。

更新日は支払える状態と通知経路まで管理する

自動更新が有効でも、登録カードの期限切れや請求失敗で更新できないことがあります。ICANNの更新・失効FAQでも、支払い情報と連絡先を最新に保ち、期限前に更新する必要が示されています。台帳では「自動更新あり」だけで終えません。次回請求日と支払い責任者を記録し、確認日も残します。

更新通知を、対象ドメインのメールアドレスだけへ送る構成にも注意が必要です。ドメインやメールに問題が起きたとき、復旧案内を受け取れません。会社が継続管理する別経路を用意し、個人の無料メールだけに依存しない方法を選びます。

有効期限の月に初めて確認するのでは遅い場合があります。レジストラの変更、登録者情報の修正、社内承認には時間がかかります。四半期ごとに期限が近いドメインを確認し、担当者交代やカード変更があった月にも台帳を見直します。

DNSの接続先から隠れた用途を見つける

Webページが表示されないドメインでも、使われていないとは限りません。MXが業務メールを受け、TXTが外部サービスの所有確認に使われ、CNAMEが配信や認証へ接続していることがあります。廃止候補は、ブラウザー表示だけで判断せずDNSレコードと契約サービスを確認します。

旧ブランドのドメインは、現行サイトへの転送だけでなく、古い名刺宛てのメールやサービスのログインIDに残りやすいです。アクセスが少ないという理由だけで失効させると、取引先からの連絡やアカウント復旧に影響する場合があります。利用部門へ期限を示して確認します。

反対に、目的不明のドメインを無期限に更新し続ける必要もありません。保有理由と年間費用を確認します。第三者取得時の影響と依存サービスも判断材料です。

そのうえで、責任者が継続・統合・廃止を決めます。判断日と次回見直し日を残せば、毎年同じ調査をやり直さずに済みます。

レジストラをまとめるかは権限と復旧性で決める

複数のレジストラを一社へまとめると、請求や更新日の確認は簡単になります。ただし、移管できない期間と対象ドメインの種類は確認が必要です。DNSSECや法人向け権限にも違いがあります。管理画面を一つにすること自体を目的にせず、サポートを含む現在の要件を満たすか確認します。

一社へ集約する場合も、全員が同じ管理者IDを共有しません。日常確認とDNS変更の権限を分けます。請求と移管の権限も必要な人だけへ付与し、二要素認証と復旧方法を会社で管理します。管理者が一人だけでは、その人が不在のときに更新や障害対応が止まります。

レジストラを分散すると一社の障害へ備えられる面はありますが、連絡先と支払いの維持作業は増えます。ドメイン数が少ない会社では、分散よりも法人名義を整える方が先になることが多いです。複数管理者と確実な更新確認も優先します。

棚卸しは用途不明の一件から始める

最初から完璧な台帳を作ろうとすると、情報が集まらず止まりやすくなります。レジストラの請求書と社内の契約一覧を照合します。現在のDNSも確認し、まず全ドメイン名と登録者だけを埋めます。次に、期限が近いものと用途不明のものから、DNSと利用部門を確認します。

最終的には、各行について「会社のものか」「どこで変更するか」「止まると何へ影響するか」を別の担当者が答えられる状態を目指します。今日一件だけ選ぶなら、更新通知は届くものの用途を説明できないドメインから確認してください。その調査が、複数ドメインを管理可能な状態へ戻す最短の一歩です。