サブドメインは「用途ごとにサーバーやアプリを分けたい」ときに便利ですが、数が増えると証明書の更新漏れや、使わなくなったDNSレコードの放置が起きやすくなります。運用を楽にするコツは、作る前に「何のためのサブドメインか」「証明書をどう持つか」「DNSを誰が管理するか」を決めておくことです。この記事では、よくある用途別の構成パターンと、SSL証明書・DNS・セキュリティの面で気をつける点、増えたサブドメインを管理する方法を説明します。
サブドメインがよく使われる場面
実際の運用でよく見かけるのは、次のようなパターンです。
- 本番と検証の分離:
staging.example.comやdev.example.comに検証環境を置く。WordPressの更新やテーマ変更を本番の前に試す場所として使います。 - 別のアプリ・別のサーバー: 本体のサイトはWordPress、
shop.example.comはECシステム、app.example.comは自社の会員アプリ、というように中身が違うものを分けます。サーバーやデータベースを分けやすく、障害の影響範囲も分けられます。 - 外部サービスへの割り当て:
help.example.comをヘルプデスクのサービスに、news.example.comをメール配信サービスのページに向けるなど、CNAMEレコードで外部サービスに名前を貸す使い方です。 - WordPressマルチサイト（サブドメイン型）:
tokyo.example.com、osaka.example.comのように、1つのWordPressで複数のサイトを動かします。 - メールやAPIなどサイト以外の用途:
mail.example.comやapi.example.comのように、Webページ以外の入口として使います。
パターンによって、証明書の発行方法やDNSの管理者が変わります。外部サービスに向けるものは、証明書もそのサービス側が発行するのが一般的です。
サブディレクトリとどちらを選ぶか
ブログを blog.example.com にするか example.com/blog/ にするかで迷う場面も多いと思います。Googleの担当者は、検索の扱いとしてはどちらの構成でも大きな違いはないという趣旨の説明をしています。検索順位を理由に決めるより、運用の都合で選ぶほうが後悔が少なくなります。
- 中身が同じWordPressなら、サブディレクトリのほうが証明書もサーバーも1つで済みます。
- 別のシステムや別のサーバーで動かすなら、サブドメインのほうが構成が素直です。
- アクセス解析では、サブドメインをまたぐと設定が必要になる場合があります。導入前に、使っている解析ツールの説明を確認してください。
途中で構成を変えると、URLの変更と301リダイレクトが必要になります。最初に「この先も別システムとして育てるか」を考えておくと、移行の手間を避けられます。
SSL証明書の持ち方は3パターン
サブドメインの証明書は、大きく3つの持ち方があります。
| 持ち方 | 向いている場面 | 注意点 |
|---|---|---|
| サブドメインごとに個別の証明書 | 数が少ない、サーバーが別々 | 枚数分の更新管理が必要 |
| 複数の名前を1枚に入れる（SAN証明書） | 同じサーバーで決まった数を運用 | 名前を追加するたびに再発行 |
ワイルドカード証明書（*.example.com） |
サブドメインが頻繁に増える | 1階層のみ対象。Let's EncryptではDNS認証が必要 |
ワイルドカード証明書は便利ですが、*.example.com は a.b.example.com のような2階層下を含まず、ルートドメインの example.com も含みません。また、1枚の秘密鍵がすべてのサブドメインで使われるため、鍵が漏れたときの影響が大きくなります。外部サービスに預けるサブドメインにワイルドカード証明書の鍵を渡すのは避け、外部サービス側で個別に発行してもらうほうが安全です。
もう1つ知っておきたいのが、証明書の透明性（Certificate Transparency）です。公開の認証局が発行した証明書は公開ログに記録されるため、個別の証明書に入れたホスト名（staging.example.com など）は誰でも調べられます。検証環境の名前を見られて困るなら、名前を隠すことに頼らず、Basic認証やIP制限で守ってください。
さらに、公開の証明書の有効期間は業界のルール変更で段階的に短くなる予定です（2026年10月現在、2026年3月から上限の短縮が始まっています）。サブドメインが増えるほど手作業の更新は追いつかなくなるため、certbotなどによる自動更新を前提に構成してください。
DNSの管理パターン
DNSレコードの持ち方にもいくつかの選択肢があります。
- サブドメインごとにレコードを作る: どの名前が使われているかが一目で分かり、管理しやすい方法です。
- **ワイルドカードDNSレコード（
*.example.com）**: マルチサイトのようにサブドメインが自動的に増える場合に使います。ただし、存在しない名前もすべてサーバーに届くので、サーバー側で知らない名前をどう扱うかを決めておく必要があります。 - サブドメインを別のDNSに委任する:
dev.example.com以下を開発チームが別のDNSサービスで管理する、といった分け方です。NSレコードで委任すると、その下のレコードは親のDNSでは編集できなくなるので、担当者の間で共有しておきます。
TTL（キャッシュされる時間）は、移行や切り替えの予定があるサブドメインだけ事前に短くしておくと、切り替え後の反映待ちを短くできます。
セキュリティで気をつけること
サブドメインを増やすと、親ドメインと設定を共有する部分が出てきます。
Cookieの共有範囲: Cookieに Domain=example.com を付けると、すべてのサブドメインにそのCookieが送られます。外部サービスや第三者が管理するサブドメインがある場合、ログイン用のCookieをそちらに渡さないよう、Domain属性を付けない（そのホスト専用にする）設定が基本です。
HSTSのincludeSubDomains: 親ドメインでHSTSに includeSubDomains を付けると、すべてのサブドメインがHTTPSでしか開けなくなります。HTTPSに対応していない古いサブドメインが残っていると、そこが開けなくなるので、先に全サブドメインのHTTPS化を済ませてから有効にします。
放置されたCNAME（サブドメイン乗っ取り）: 外部サービスを解約したのに、そのサービスを指すCNAMEレコードが残っていると、第三者が同じサービスで同じ名前を登録して、あなたのサブドメインでページを公開できてしまうことがあります。サービスを解約するときは、DNSレコードの削除を手順に含めてください。
検証環境の公開範囲: 検証用のサブドメインが検索結果に出たり、本番と同じ内容が重複して見えたりしないよう、Basic認証やIP制限をかけておきます。noindexの設定だけでは、内容の閲覧は防げません。
台帳を作って定期的に確認する
サブドメインが10個を超えるあたりから、「これは何のために作ったのか」が分からなくなりがちです。次の項目を表計算ソフトなどで1行ずつ管理しておくと、更新漏れや放置を防げます。
- 名前、用途、担当者
- DNSレコードの種類と向き先
- 証明書の発行元と有効期限、更新方法（自動か手動か）
- 廃止予定日（期間限定のキャンペーン用など）
台帳に載っている名前について、DNSと証明書の状態をまとめて確かめるには、次のようなシェルスクリプトが使えます。名前の一覧は自分の環境に合わせて書き換えてください。
#!/bin/bash
# サブドメインごとに、DNSの向き先と証明書の有効期限を表示する
for host in www.example.com staging.example.com shop.example.com; do
echo "== ${host}"
dig +short "${host}"
echo | openssl s_client -connect "${host}:443" -servername "${host}" 2>/dev/null \
| openssl x509 -noout -enddate -subject
donedig で何も返らない名前は、レコードが消えているか、名前が間違っています。CNAMEの向き先だけが返り、その先のIPアドレスが返らない場合は、向き先のサービスが解約済みかもしれません。上で触れた乗っ取りの危険があるので、早めに確認してください。証明書の期限が近いものは、自動更新が止まっていないかを確認します。
まとめ
- サブドメインは、検証環境・別システム・外部サービス・マルチサイトなど、用途ごとに分けるときに向いています。同じWordPressの中身ならサブディレクトリのほうが運用は楽です。
- 証明書は個別・SAN・ワイルドカードの3パターン。数と増え方、鍵を共有してよいかで選び、自動更新を前提にします。
- Cookieの共有範囲、HSTSのincludeSubDomains、放置されたCNAMEは、サブドメイン特有の注意点です。
- 台帳を作り、DNSと証明書の状態を定期的に確かめると、更新漏れや乗っ取りを防ぎやすくなります。