サブドメイン完全ガイド：DNS設定・SSL・SEO・運用のベストプラクティス
エバープレイ編集部サブドメインとは — 概念と基本
サブドメイン（subdomain）は、ドメイン名の階層構造における下位の名前を指します。ドメイン名はピリオドで区切られたラベルで構成され、右側ほど上位（より包括的）なレベルを表します。たとえば「blog.example.com」は「example.com」のサブドメインであり、さらに「example.com」はトップレベルドメイン（TLD）「.com」の下に位置します。
DNSにおけるサブドメインの取り扱い
DNS（Domain Name System）上では、サブドメインは独立したゾーンとして委任（delegation）することも、親ゾーンと同じDNSサーバーで管理することもできます。DNSレコード（A、AAAA、CNAME、MX、TXTなど）はサブドメイン単位で設定可能です。
- Aレコード：サブドメイン名をIPv4アドレスに紐づける。
- AAAAレコード：IPv6アドレスに紐づける。
- CNAMEレコード：別名（canonical name）として他のホスト名に紐づける（ただしCNAMEは他のレコードと共存できない）。
- MXレコード：メールの配送先指定はサブドメイン単位でも設定可能。
- TXTレコード：SPFやDKIMの設定、所有権確認などで使用。
サブドメインとサブディレクトリの違い（SEO・運用の観点）
サブドメイン（blog.example.com）とサブディレクトリ（example.com/blog）はURL構造が異なり、運用やSEO上の扱いも変わります。Googleは近年「サブドメインでもサブディレクトリでも使い分けは可能」としていますが、実務では次の点を考慮します。
- 独立したサービスやホスティング環境、異なる技術スタックを用いるならサブドメインが適している。
- 同一サイトの一部分でコンテンツやドメインパワーを集中させたいならサブディレクトリの方が簡単な場合がある。
- Search Consoleなどでの管理単位が分かれる（サブドメインは別プロパティとして扱うケースがある）。
実務での利用例
- サービス分離：api.example.com、static.example.com、cdn.example.com
- 環境分離：staging.example.com、dev.example.com
- 多言語・地域：en.example.com、jp.example.com
- マルチテナント：user1.example.com、user2.example.com（SaaSでよくあるパターン）
- ブランドや機能の分割：shop.example.com、blog.example.com
設定手順の概略（DNS側）
一般的なサブドメインの追加手順は以下の通りです。
- DNS管理画面で対象ホスト名（例：api）を作成。
- ホスト名に対してA/AAAA（IPを指す）またはCNAME（別ホスト名を指す）を設定。
- 必要に応じてMX/TXT（SPFや所有権確認）を設定。
- 設定後、TTLに従って伝播を待ち、nslookup/dig等で解決を確認する。
例：
A api.example.com. -> 203.0.113.5
CNAME www.example.com. -> example.com.ワイルドカード（*.example.com）の利用
ワイルドカードDNSレコードを用いると、指定したレベルのすべてのサブドメインを一括で解決できます。たとえば「*.example.com」で設定すれば、foo.example.com や bar.example.com が同じIPに解決されます。ただしワイルドカードは慎重に使うべきで、意図しないホスト名の解決や管理上の誤配につながることがあります。
SSL/TLS証明書とサブドメイン
HTTPS対応のため、サブドメインに対して証明書を用意する必要があります。選択肢としては：
- 個別証明書：api.example.com ごとに発行
- ワイルドカード証明書：*.example.com（ただし *.example.com は foo.example.com をカバーするが foo.bar.example.com はカバーしない）
- SAN（Subject Alternative Names）証明書：複数のホスト名を1枚でカバー
Let's Encrypt のワイルドカード発行は DNS-01 チャレンジが必要であり、HTTP-01 では不可です。ワイルドカードの範囲や制約（サブサブドメインの扱い等）も注意してください。
セキュリティと運用上の注意点
- Cookieのスコープ：Cookieの Domain 属性によってサブドメイン間で共有される。example.com に設定したCookieは通常サブドメインで利用可能だが、セキュリティを考えて必要最小限にする。
- CNAMEの制約：あるホスト名にCNAMEを設定すると、その名前に他のタイプのレコード（AやMX等）を共存させられないというルールがある（プロバイダによってALIASやANAMEという擬似CNAMEを用意する場合がある）。
- HSTS（HTTP Strict Transport Security）：includeSubDomains 指定を付けるとサブドメイン全体にHSTSが適用されるため、事前に全サブドメインがHTTPS対応済みであることを確認する必要がある。
- DNSの委任：サブドメインを別のDNSサーバーに委任する場合、適切にNSレコードを設定し、切り離し運用に伴う管理責任を整理する。
メールとサブドメイン
サブドメイン単位でMXレコードを持たせることができ、メール受信を分ける設計が可能です。ただし、送信側のSPF/DKIM/DMARCの整備や、送信元のリバースDNS設定などが必要となります。サブドメインを使ったメール運用では、ポリシー（例：DMARCの処理）やレポート先の設定を明確にすることが重要です。
WordPressやWebアプリでの利用—実例と注意点
WordPressではマルチサイト機能を使ってサブドメイン型ネットワーク（site1.example.com）を構築できます。これにはDNSでワイルドカード（*.example.com）や個別サブドメインを設定し、サーバー側で適切なVirtualHost設定（またはホスティングの分離）を行う必要があります。
注意点：
- ワイルドカード証明書やLet’s EncryptのDNS-01自動化を考慮する。
- Cookie/セッションのドメインスコープをどうするか設計する（ログイン共有が必要か）。
- Search ConsoleやAnalyticsのプロパティ分離、トラッキングの一貫性を保つ。
トラブルシューティングの基本手順
- DNS解決の確認：dig/nslookup で正しいレコードが返っているかを確認。
- プロパゲーションの確認：TTLが反映されるまで時間がかかるので、キャッシュを考慮する。
- 証明書エラー：サブドメインが証明書のカバー範囲内か確認（SAN/Wildcard）。
- CNAME衝突：既にAやMXが存在する名前にCNAMEを置いていないか確認。
設計ベストプラクティスまとめ
- 用途に応じてサブドメインとサブディレクトリを使い分ける。異なるサービスはサブドメイン、同一サイト内のコンテンツはサブディレクトリが原則の判断基準。
- 証明書・HSTS・Cookie 等の跨域影響を設計時に検討する。
- DNS設定の標準ルール（CNAMEの制約、NS委任の取り扱い）を守る。
- 運用負荷を減らすため、ワイルドカードの利用や自動化（ACME/DNS-01）を検討するが、影響範囲を明確にする。
- Search Consoleや解析ツールの設定を忘れずに。サブドメインはしばしば別プロパティとして扱う必要がある。
まとめ
サブドメインはドメイン名の階層を利用して機能分離や運用分離を行う強力な手段です。DNSや証明書、Cookieやセキュリティ設定など、多面的な影響があるため、用途に応じた設計と運用ルールの整備が重要です。正しく設定すれば、スケーラビリティや管理性の向上に大きく寄与します。
参考文献
- RFC 1034 — Domain Names — Concepts and Facilities (IETF)
- RFC 1035 — Domain Names — Implementation and Specification (IETF)
- Google Search Central: Subdomains & subdirectories
- Let's Encrypt: DNS-01 challenge and wildcard certificates
- MDN Web Docs: Cookies（CookieのDomain属性など）
- Cloudflare Docs: How CNAME records work（CNAMEの制約について）
- WordPress Documentation: Create a Network（マルチサイトとサブドメイン）
- OWASP: Secure Cookie Attribute（セキュアなCookie運用）
投稿者プロフィール
