複数ドメインは、ドメイン名ごとに「契約先・更新期限・用途・管理者」を一行にまとめると整理しやすくなります。数件なら表計算の一覧で十分です。DNSやWebサーバーの契約先が別なら、その対応関係も同じ行に添えておきます。

特に見落としやすいのは、Webページがないドメインです。メールや旧サイトからの転送に使っていることもあるため、表示されないという理由だけで解約しない方が良いです。以下の表を基に、手元の契約情報を整理できます。

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

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

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

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

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

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

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

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

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

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

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

自動更新が有効でも、登録カードの期限切れや請求失敗で更新できないことがあります。ICANNの更新・失効FAQでも、支払い情報と連絡先を最新に保ち、期限前に更新する必要が示されています。「自動更新あり」だけでなく、更新案内と決済結果が届く宛先も分かるようにしておくと安心です。

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

有効期限の月に初めて確認するのでは遅い場合があります。レジストラの変更、登録者情報の修正、社内承認には時間がかかります。更新案内に合わせて期限と支払い状態を確認し、担当者やカードが変わったときにも登録情報を見直すと、更新漏れを防ぎやすくなります。

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

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

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

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

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

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

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

権限を分けられるサービスなら、日常の確認とDNS変更、移管などの重要操作を分けると安心です。複数担当者の設定に対応しないサービスもあるため、契約前に機能を確認します。二要素認証と担当者不在時の復旧方法は、どの契約先でも大切になります。

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

「残す・まとめる・廃止する」の判断例

現行の会社サイトや業務メールに使うドメインは、継続管理が基本です。旧社名のドメインも、過去の取引先からメールが届いたり、アカウント復旧先に使われていたりすれば、転送用として残す意味があります。

同じ目的のドメインを複数持っている場合は、公開サイトを一つにまとめ、ほかを転送用にする方法があります。ただし、転送元のドメイン契約やHTTPS証明書も引き続き必要です。

廃止を検討しやすいのは、利用も保有目的もなく、メール・ログイン・外部サービスとの接続が残っていないドメインです。再取得した第三者が旧メール宛ての情報を受け取るリスクもあるため、年間費用だけでは判断しない方が良いかと思います。