この記事のポイント
- 子会社ドメイン管理は『会社一覧』ではなく『外から見える公開面一覧』で回した方が、責任者不明を減らしやすくなります。
- M&A 後の domain 引き継ぎでは、DNS 権限、証明書、委託先導線、古い login page の継続理由を期限付きで確認する必要があります。
- グループ会社の統制は discovery だけで終わらず、owner・approver・reviewer を公開面単位で戻し、月次で空欄と不要資産を潰す運用が重要です。
まず無料で確認する
無料でASM診断を開始
子会社 ドメイン 管理で触れている論点は、自社ドメインを実際に診断すると優先順位が掴みやすくなります。まずは外部公開資産を無料で可視化してください。
子会社ドメイン管理とは何を管理する話なのか
子会社ドメイン管理で見るべき対象は、会社名の一覧ではなく、外から見える domain、login page、API、staging、委託先導線の束です。
管理対象は『法人』ではなく『公開面』でそろえる方が実務に効きます
子会社ドメイン管理という言葉から、グループ会社の法人一覧や whois 情報の管理を想像する人は少なくありません。しかし実際に事故の起点になるのは、法人名そのものではなく、外から見える domain、login page、サポート窓口画面、公開 API、古い staging、ブランド用 subdomain のような公開面です。つまり子会社ドメイン管理の本質は、会社を並べることではなく、公開面を責任付きで並べ直すことにあります。
たとえば親会社の情報システム部が「子会社 A は把握している」と言っていても、その子会社名義の採用 site、古い VPN login、M&A 前から残っているブランド domain、委託先が運営している campaign landing page が一覧から漏れていれば、統制は成立していません。既存のサブドメイン棚卸しのやり方が discovery の型を扱うのに対し、本記事で扱うのは discovery 後の governance です。見つけた公開面を誰が引き取るのか、どこまで残すのか、廃止を誰が承認するのかを決めるところまで含めて、子会社ドメイン管理と考える必要があります。
CISA の asset management best practicesでも、資産管理は inventory の保有だけでなく、責任と更新が結び付いていることが重視されています。グループ会社の公開資産でも同じで、domain の存在を知っているだけでは不十分です。何のために残っているのか、誰が説明できるのか、いつ見直すのかが曖昧なら、事故が起きたときに止める判断が遅れます。
ブランド、委託先、M&A 後の残置資産が一番こぼれやすいです
子会社ドメイン管理が難しい理由は、親会社と子会社の二階層だけで終わらないからです。実務では、ブランドサイト、委託先経由の support 導線、短期 campaign 用 domain、閉じたはずの brand microsite、M&A 前の legacy host が混在します。これらは公式組織図に載りにくく、かつ対外的には今も見え続けるため、統制の穴になりやすいです。
とくに M&A 後は、「とりあえず止めずに残す」という判断が増えます。DNS を止めると業務影響が怖い、証明書更新だけは続けている、委託先が触っているので社内は深く把握していない、といった状態が積み上がると、残置資産は年単位で残ります。だから子会社ドメイン管理では、残す理由を説明できない公開面は、将来の事故候補として扱うくらいの姿勢が必要です。
既存の 外部接続点は見えているか? や 外部公開資産台帳テンプレート と合わせて考えると、見えている接点を列挙するだけでなく、グループ会社をまたいで ownership を戻す必要性が分かりやすくなります。子会社ドメイン管理は、domain 管理部門だけの仕事ではなく、親会社側の governance 設計そのものです。
なぜグループ会社の外部公開資産は統制が崩れやすいのか
統制が崩れる一番の理由は、公開面の責任ルートと法人の責任ルートが一致しないことです。親会社が予算を持ち、子会社が運用し、委託先が制作し、さらにブランド担当が継続判断を持つ、といった多層構造では、domain 一つに複数の当事者が関わります。この状態で「子会社 A の domain は誰が見るのか」とだけ聞いても、実際の公開面単位では owner が戻りません。
ここで重要なのは、公開面の owner を「詳しい人」ではなく最初に説明責任を持てる人で決めることです。詳しいベンダー担当者や制作会社だけに依存すると、その人が変わった瞬間に ownership は空洞化します。社内 owner、承認者、レビュー担当、外部窓口を同じ型で管理すると、法人をまたいでも責任の流れが切れにくくなります。
さらに、グループ会社の統制では「残す前提」の資産が多いことも難しさです。ERP 連携、ブランド移行中の landing page、取引先向け portal など、止めたいがすぐ止められない公開面が必ず存在します。だからこそ、単なる inventory ではなく、継続理由、停止条件、次回見直し日を一緒に持つ必要があります。ここがないと、子会社ドメイン管理はただの一覧表で終わります。
法人単位ではなく公開面単位で owner を戻す
子会社名だけ管理しても、実際の login page、API、古いサブドメインの責任者不明は解消しません。
M&A 後 90 日以内にドメイン台帳と DNS 権限を棚卸しする
引き継ぎが曖昧なまま放置すると、失効忘れや古い委託先導線が残りやすくなります。
廃止予定資産にも approver と期限を持たせる
止める前提の資産ほど『あとで整理する』のまま残りやすく、例外承認が常態化しやすいためです。
委託先・ブランド別の管理を同じ台帳へ戻す
別表管理にすると、incident 時に責任と停止判断の流れが切れやすくなります。
月次レビューで空欄 owner と不要ドメインを潰す
子会社やグループ会社の公開資産は、人の異動と契約変更で急速に古くなるためです。
owner・approver・reviewer を同じ書式で持つと運用が安定します
管理書式を会社ごとに変えると、比較と引き継ぎが難しくなります。親会社、子会社、買収直後の法人、委託先管理のブランド site が、それぞれ別の台帳と粒度で管理されていると、incident のたびにどの表を見ればよいか分からなくなります。したがって、最初から同じ項目でそろえることが重要です。
最低限そろえたいのは、公開面、owner、approver、reviewer、委託先窓口、継続理由、停止条件、最終確認日です。これを子会社別ではなく公開面別に持つと、「同じ法人内でも公開面ごとに責任の流れが違う」現実を表現できます。子会社ドメイン管理を組織論だけで片付けないためには、公開面単位の責任データを持つ必要があります。
M&A 後に何を引き継ぐべきか
M&A 後のドメイン統合で最も危険なのは、「優先度が高いのは事業統合なので、公開資産は後回しでよい」という空気です。実際には逆で、公開資産は外から触られるため、統合直後からリスクが顕在化します。だから M&A 後 90 日くらいまでの間に、最低限の外部公開資産棚卸しを終える運用が必要です。
具体的に引き継ぐべき対象は、root domain と subdomain の一覧だけではありません。DNS のレジストラ情報、ゾーン編集権限、証明書、CDN・WAF、login page、API host、staging、採用サイト、旧ブランド向け redirect、委託先の連絡先まで含めるべきです。どれか一つでも抜けると、「名前だけ引き継いだが運用権限は旧体制に残っている」状態になります。
ICANN の DNS security guidance や NIST CSF 2.0 の asset / governance の考え方を踏まえると、M&A 後に重要なのは完全な統合ではなく、誰が今の公開面を説明できるかを早く作ることです。完璧な整理を待ってから統制するのではなく、まず owner と見直し期限を置き、あとから精度を上げる方が、実務では安全に寄せやすくなります。
『止める』『残す』『移す』を分けて判断してください
M&A 後の公開資産は、すべて統合する必要はありません。重要なのは、止める、残す、移す、の三つを明示することです。止める資産は停止計画と影響確認を、残す資産は継続理由と owner を、移す資産は移管期限と移管先を持つ必要があります。この区別が曖昧だと、全部が「とりあえず残す」へ流れてしまいます。
特にブランド移行期は、「今月は残すが来期には畳む」資産が多くなります。そのときに approver がいないと、例外承認が無期限化します。公開資産の統制で一番避けたいのは、期限のない例外です。子会社ドメイン管理では、期限付きの継続理由を持てない公開面は高リスクと考えてください。
法人一覧ではなく公開面一覧を起点にする
親会社、子会社、ブランド、委託先をまたいで、domain、login page、API、staging、support 導線を一つの一覧へ戻します。
公開面一覧owner・approver・reviewer を同じ型で付ける
会社ごとに書式を変えず、公開面単位で owner、承認者、月次レビュー担当、委託先窓口を付けます。
責任ルートM&A 後の引き継ぎ対象を期限付きで整理する
DNS 権限、証明書、委託先、廃止予定の host、ブランド用 domain の継続理由を期限付きで確認します。
引き継ぎ backlog監視・是正・廃止の定例運用へ載せる
棚卸しで終わらせず、月次の差分確認、owner 空欄の解消、期限超過資産の停止判断まで回します。
継続運用ルール複数法人の監視・owner 管理・廃止判断をどう回すか
複数法人をまたぐ管理では、発見、owner 付与、是正、廃止、月次レビューの 5 つを分けて設計した方が運用しやすくなります。発見は外から見える接点を洗い出す工程、owner 付与は責任ルートを戻す工程、是正は直す工程、廃止は止める工程、月次レビューは空欄や期限超過を潰す工程です。これらを全部「ドメイン管理チームが見る」に寄せるとすぐ詰まります。
たとえば親会社のセキュリティ部門は発見とレビュー、各事業会社は owner、IT統括は approver、委託先管理部門は vendor liaison を持つ、と分けると流れが安定します。重要なのは、役割分担を法人ではなく公開面のライフサイクルへ結び付けることです。公開面が残る限り、その面に owner と approver が必要です。
既存の 外部公開資産のオーナー管理とは? や 公開資産の是正 SLA とは? と合わせて読むと、誰が持つかと、いつまでに直すかを同時に設計しやすくなります。子会社ドメイン管理は単体では完結せず、ownership と remediation governance の両輪で回す方が強いです。
また、監視対象の差分が毎月出ることも前提にしてください。新しい子会社の採用サイト、買収したブランドの問い合わせフォーム、委託先が追加したサポート用公開ホストなど、公開面は増減します。そのため、管理の成熟度は「一度そろえたか」ではなく、差分が出たときに owner を戻せるかで測るべきです。月次 review を通じて、空欄 owner、期限切れ例外、用途不明 host を削っていく運用が最終的に効きます。
子会社やブランドの公開面を見直すなら ASM診断 PRO

ASM診断 PRO はグループ会社やブランドをまたいで外から見える host、管理画面、API、古い subdomain を棚卸しし、owner を戻す対象をそろえる起点として使いやすい構成です。
ASM診断 PRO は会社組織図や M&A 台帳を直接管理する製品ではありません。しかし、子会社ドメイン管理で最初に詰まるのは「何を owner 管理の対象にするのか」が曖昧なことです。親会社、子会社、ブランド、委託先で責任が分かれる環境では、外から見える host や login page をそろえないと、ownership の議論が抽象論で終わります。
ASM診断 PRO を起点にすると、外から見える subdomain、管理画面、公開 API、証明書、用途不明 host を一覧できるため、グループ会社をまたいだ公開面の棚卸しを始めやすくなります。これにより、「この資産はどの法人の owner に戻すか」「委託先窓口は誰か」「廃止予定なのに外から見えていないか」を一つずつ確認できます。つまり子会社ドメイン管理を前へ進めるには、組織論の前に、外から見える公開面を同じ土俵へ戻すことが重要です。
さらに、M&A 後やブランド再編の直後は、意図せず古い host が残りやすくなります。ASM診断 PRO で差分を見られると、新しい公開面の追加や、閉じたはずの host の再露出にも気づきやすくなります。既存の サブドメイン棚卸しのやり方 や 外部接続点は見えているか? と合わせると、発見と governance を同じ流れで回しやすくなります。
グループ会社統制で本当に欲しいのは、完璧な一覧表ではなく、責任者不明の公開面を毎月減らせることです。ASM診断 PRO はその最初の土台として、外から見える接点を整理し、owner・approver・reviewer を戻す起点を作りやすいです。子会社ドメイン管理を棚卸しだけで終わらせず、月次 review と停止判断へつなげたいなら、まずは公開面の実物をそろえてください。
次のアクション
グループ会社をまたぐ公開面を、まず外から棚卸ししてください
無料で外部公開資産を診断し、子会社、ブランド、委託先導線にまたがる host、login page、API、古い subdomain を洗い出して、owner と停止判断を戻す対象を明確にできます。
よくある質問(FAQ)
子会社ごとに別台帳で管理してもよいですか
可能ですが、incident 時に横断比較しづらくなります。最低でも公開面の共通項目は同じ型で持ち、親会社から横断で見られるようにした方が管理しやすくなります。
M&A 直後はどこまで引き継げば十分ですか
root domain と DNS 権限だけでは不十分です。証明書、公開 API、login page、staging、委託先窓口、継続理由、停止条件まで引き継ぐ必要があります。
委託先が運用するブランドサイトも社内 owner が必要ですか
必要です。委託先だけが状況を知っている構成だと、契約変更や incident 時に責任が切れます。社内 owner と approver は必ず持ってください。
どの記事と一緒に読むと理解しやすいですか
発見の型は サブドメイン棚卸しのやり方、責任の戻し方は 外部公開資産のオーナー管理、是正期限は 公開資産の是正 SLA がつながります。
子会社ドメイン管理を月次運用へ載せる最初の一歩は何ですか
まずは外から見える公開面一覧をそろえ、owner 空欄の項目を洗い出すことです。その一覧がなければ、どこから運用を直せばよいか判断できません。
まとめ
子会社ドメイン管理は discovery の一回限りではなく、owner 付与、継続判断、廃止、月次 review を循環させて維持する必要があります。
子会社ドメイン管理で重要なのは、法人名の一覧を整えることではありません。親会社、子会社、ブランド、委託先をまたいで、外から見える公開面を同じ型へ戻し、誰が説明し、誰が承認し、誰が見直すかを切らさないことが本質です。公開面が見えていても owner が空欄なら直せず、継続理由が曖昧なら停止判断も進みません。だからこそ、グループ統制は discovery と governance を一つの流れで回す必要があります。
特に M&A 後やブランド再編の時期は、古い domain、旧 login page、委託先管理のサポート用公開ホストが残りやすく、例外承認が増えます。このときに重要なのは、完璧な統合を待たず、まず公開面単位で owner と見直し期限を置くことです。root domain、証明書、DNS 権限、公開 API、staging、委託先窓口まで確認し、止める、残す、移す、を明示すると、無期限の例外を減らせます。
最後に、子会社ドメイン管理は単発の棚卸しで終わる仕事ではありません。月次で差分を確認し、owner 空欄を潰し、期限超過の公開面へ是正か停止かを戻す運用が必要です。公開面を見つけること、責任者を戻すこと、継続理由を残すこと、この三つが回り始めて初めて、グループ会社の internet-facing asset governance は実務として機能します。まずは外から見える接点をそろえ、責任者不明の公開面を一つずつ減らすところから始めてください。
次のアクション
読み終えたら、無料でASM診断を開始
外部公開資産の現状を無料で確認し、管理漏れや優先して見るべきリスクを洗い出してください。記事で読んだ内容を、そのまま自社の判断へつなげやすくなります。
参考にした一次ソース
重要論点の根拠として参照した一次ソースだけを掲載しています。
資産管理を inventory だけでなく責任と更新まで含めて考える観点を参照しました。
governance と asset management の考え方を参照しました。
継続的な資産管理と責任割り当ての観点を参照しました。
DNS 運用と domain 管理の基礎整理に参照しました。