ドメイン戦略 | Knowledge Garden

概要

複数のウェブサイトやサービスを1台のサーバーで運用する際、ドメイン構成の設計は重要な意思決定となる。サブドメイン、サブディレクトリ、別ドメインの3つの選択肢があり、それぞれにメリット・デメリットがある。

3つの選択肢

1. サブドメイン方式

https://blog.example.com
https://api.example.com
https://docs.example.com
https://shop.example.com

2. サブディレクトリ方式

https://example.com/blog
https://example.com/api
https://example.com/docs
https://example.com/shop

3. 別ドメイン方式

https://example-blog.com
https://example-api.com
https://example-docs.com
https://example-shop.com

比較表

観点	サブドメイン	サブディレクトリ	別ドメイン
独立性	○ 高い	× 低い	◎ 最も高い
SEO効果	△ 分散	◎ 集約	× 別サイト扱い
SSL証明書	個別 or ワイルドカード	1つで済む	各ドメインで必要
技術的分離	容易	やや複雑	完全分離
ブランディング	独立感あり	統一感あり	完全独立
管理コスト	中	低	高

サブドメイン方式

特徴

各サービスを service.example.com の形式で公開する方式。

メリット

技術的な独立性
- 各サービスを独立したサーバー/コンテナで運用可能
- 異なる技術スタック（React、Vue、静的サイトなど）を混在可能
- デプロイを個別に実行可能
リバースプロキシとの相性
- Traefik や Nginx でホストベースのルーティングが簡単
- Docker ラベルで自動設定可能
```
labels:
  - traefik.http.routers.blog.rule=Host(`blog.example.com`)
```
スケーラビリティ
- 将来的にサービスを別サーバーに分離しやすい
- DNS 変更だけで移行可能
Cookie の分離
- サブドメインごとに Cookie を分離可能
- セキュリティ向上（XSS の影響範囲限定）

デメリット

SEO の分散
- 検索エンジンは別サイトとして扱う傾向
- ドメインパワーが分散する可能性
DNS 設定の手間
- 各サブドメインの A/AAAA レコードが必要
- またはワイルドカード DNS（*.example.com）
SSL 証明書
- 個別証明書 or ワイルドカード証明書が必要
- Let’s Encrypt では DNS-01 チャレンジが便利

設定例（Traefik + Docker）

# blog サービス
services:
  blog:
    image: blog:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.blog.rule=Host(`blog.example.com`)
      - traefik.http.routers.blog.tls=true
      - traefik.http.routers.blog.tls.certresolver=le

# API サービス
  api:
    image: api:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.api.rule=Host(`api.example.com`)
      - traefik.http.routers.api.tls=true
      - traefik.http.routers.api.tls.certresolver=le

DNS 設定

# 個別設定
blog.example.com.   A     203.0.113.10
api.example.com.    A     203.0.113.10
docs.example.com.   A     203.0.113.10

# または ワイルドカード
*.example.com.      A     203.0.113.10

サブディレクトリ方式

特徴

各サービスを example.com/service の形式で公開する方式。

メリット

SEO の集約
- すべてのコンテンツが1つのドメインに集約
- ドメインパワーを最大化
- Google は公式にどちらも対応と言及しているが、実務上は集約効果がある傾向
SSL 証明書の簡素化
- 1つのドメインに1つの証明書で済む
- 管理が簡単
統一されたブランディング
- ユーザーにとって「1つのサイト」として認識される

デメリット

技術的な複雑さ
- パスベースのルーティング設定が必要
- ベースパスの調整（相対パス vs 絶対パス問題）
- CORS 設定などが複雑になりがち
デプロイの依存関係
- 1つのサービスの問題が全体に影響する可能性
- パス衝突のリスク
Cookie 共有のリスク
- 同一ドメインで Cookie が共有される
- セキュリティ設計に注意が必要

設定例（Traefik + Docker）

services:
  main:
    image: main:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.main.rule=Host(`example.com`) && PathPrefix(`/`)
      - traefik.http.routers.main.priority=1

  blog:
    image: blog:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.blog.rule=Host(`example.com`) && PathPrefix(`/blog`)
      - traefik.http.routers.blog.priority=10
      - traefik.http.middlewares.blog-strip.stripprefix.prefixes=/blog
      - traefik.http.routers.blog.middlewares=blog-strip

  api:
    image: api:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.api.rule=Host(`example.com`) && PathPrefix(`/api`)
      - traefik.http.routers.api.priority=10

フレームワーク側の設定

サブディレクトリで動作させるには、フレームワーク側でベースパスの設定が必要。

Astro:

// astro.config.mjs
export default defineConfig({
  site: 'https://example.com',
  base: '/blog',
});

Next.js:

// next.config.js
module.exports = {
  basePath: '/blog',
  assetPrefix: '/blog/',
};

Vite / React:

// vite.config.js
export default {
  base: '/blog/',
};

別ドメイン方式

特徴

各サービスを完全に異なるドメインで公開する方式。

メリット

完全な独立性
- 技術・運用・ブランディングすべてが独立
- 将来的な売却や分離が容易
セキュリティの分離
- CORS、Cookie、CSP などが完全に分離
- 1サイトの脆弱性が他に影響しにくい
ブランド戦略
- 各サービスを独立したブランドとして展開可能

デメリット

コスト増
- 複数ドメインの維持費
- 各ドメインの SSL 証明書
SEO の分散
- 相互リンクしても別サイト扱い
- ドメインパワーは完全に別々
ユーザー体験
- サイト間の移動でドメインが変わる
- 統一感の欠如

適したケース

完全に異なるターゲット層
将来的に分社化や売却の可能性
ブランド戦略上、独立させたい場合

選定の指針

ユースケース別の推奨

ユースケース	推奨方式	理由
会社サイト + 各種サービス	サブドメイン	独立性と拡張性
ブログ + ドキュメント（SEO重視）	サブディレクトリ	ドメインパワー集約
技術ブログ + ポートフォリオ	サブドメイン	管理の独立性
複数の独立したプロダクト	別ドメイン	ブランド独立性
API + フロントエンド	サブドメイン	CORS 設定が明確
EC サイト + ブログ	サブドメイン	セキュリティ分離

判断フローチャート

SEO を最優先したい？
├─ Yes → サブディレクトリ方式
└─ No
    ↓
  各サービスを独立して管理したい？
  ├─ Yes
  │   ↓
  │   完全に別のブランドとして展開？
  │   ├─ Yes → 別ドメイン方式
  │   └─ No → サブドメイン方式
  └─ No → サブディレクトリ方式

技術的な判断基準

異なる技術スタックを使う → サブドメイン推奨
静的サイトジェネレータのみ → どちらでも可（サブディレクトリがSEO有利）
Docker + リバースプロキシ構成 → サブドメインが設定簡単
同一フレームワークで統一 → サブディレクトリも容易

SSL 証明書の考慮

サブドメイン方式の場合

選択肢 1: 個別証明書

各サブドメインで個別に Let’s Encrypt を取得
HTTP-01 チャレンジで簡単に設定可能

選択肢 2: ワイルドカード証明書

*.example.com で全サブドメインをカバー
DNS-01 チャレンジが必要（DNS API が必要）

# Traefik でワイルドカード証明書
command:
  - --certificatesresolvers.le.acme.dnschallenge=true
  - --certificatesresolvers.le.acme.dnschallenge.provider=cloudflare

サブディレクトリ方式の場合

1つのドメインに1つの証明書
HTTP-01 チャレンジで簡単

移行時の注意点

サブディレクトリ → サブドメイン

新しいサブドメインを設定
コンテンツを移行
301 リダイレクトを設定
Search Console で変更を通知

# example.com/blog → blog.example.com
location /blog {
    return 301 https://blog.example.com$request_uri;
}

サブドメイン → サブディレクトリ

ベースパスの設定を追加
内部リンクをすべて修正
301 リダイレクトを設定
Search Console で変更を通知

ベストプラクティス

初期設計で決める: 後から変更は SEO 影響が大きい
リダイレクト計画: 変更時は必ず 301 リダイレクト
Analytics の分離: 各サービスを個別にトラッキング
ドキュメント化: ドメイン構成の意思決定を ADR に記録

概要

3つの選択肢

1. サブドメイン方式

2. サブディレクトリ方式

3. 別ドメイン方式

比較表

サブドメイン方式

特徴

メリット

デメリット

設定例（Traefik + Docker）

DNS 設定

サブディレクトリ方式

特徴

メリット

デメリット

設定例（Traefik + Docker）

フレームワーク側の設定

別ドメイン方式

特徴

メリット

デメリット

適したケース

選定の指針

ユースケース別の推奨

判断フローチャート

技術的な判断基準

SSL 証明書の考慮

サブドメイン方式の場合

サブディレクトリ方式の場合

移行時の注意点

サブディレクトリ → サブドメイン

サブドメイン → サブディレクトリ

ベストプラクティス

関連トピック