## この記事でわかること

- apex（ルートドメイン）に CNAME を置けない技術的な理由
- なぜサブドメインなら CNAME を置けるのか
- ALIAS / ANAME / CNAME フラット化という代替手段の違い
- 主要 DNS プロバイダがどの方式に対応しているか

## 「apex に CNAME」が設定できない、という壁

CDN や SaaS の設定手順に「このホスト名を CNAME で指定してください」と書かれているのに、`example.co.jp` のような **apex（エイペックス、ルートドメイン。サブドメインの付かないドメインそのもの）** に CNAME を入れようとするとエラーになる—これは多くの Web 担当者がぶつかる壁です。

一方で `www.example.co.jp` のようなサブドメインなら同じ CNAME がすんなり通ります。「なぜ www は OK で apex はダメなのか」が分からないまま、とりあえず IP アドレスを直書きして済ませてしまうケースも少なくありません。

実はこれは設定ツールの不具合でも、特定サービスの制限でもなく、**DNS の標準仕様で決まっている制約**です。理由を理解すれば、正しい代替手段を選べるようになります。

## RFC 1034 の「CNAME は共存できない」制約

![apex に CNAME を置けない理由](/blog/cname-restrictions-apex/apex-cname-conflict.svg)

根拠は DNS の基本仕様を定めた **RFC 1034** にあります。ここでは「**CNAME レコードは、同じ名前の他のレコードタイプと共存できない**」と規定されています。CNAME（シーネーム、ある名前を別の名前の別名にするレコード）が存在する名前には、A や MX など他のレコードを一切置けない、というルールです。

ここで apex の事情が効いてきます。apex には DNS の仕組み上、**必ず SOA レコードと NS レコードが存在します**。

- **SOA レコード**: ゾーン（そのドメインの DNS 設定範囲）の管理情報を示す、必須のレコード
- **NS レコード**: そのドメインを管理するネームサーバーを示すレコード

apex には SOA と NS が必ずあるため、そこに CNAME を追加すると「CNAME と他レコードの共存」になり、RFC 1034 違反になります。だから apex には CNAME を置けないのです。

逆に `www.example.co.jp` のようなサブドメインには SOA も NS も付かないため、CNAME を単独で置けます。「www は OK、apex はダメ」の違いは、ここから生まれています。各レコードの役割は [DNS レコードの種類](/blog/dns-record-types) でも解説しています。

## 代替手段1: A / AAAA レコードを直書きする

最もシンプルな回避策は、apex に CNAME ではなく **A レコード（IPv4 アドレスを指すレコード）/ AAAA レコード（IPv6 用）を直接書く**ことです。これは標準仕様の範囲内なので、どの DNS プロバイダでも使えます。

ただし弱点があります。CDN や SaaS の宛先 IP アドレスは、提供側の都合で**予告なく変わることがある**点です。A レコードを直書きしていると、相手の IP が変わったときに自社側も手作業で書き換える必要があり、追随が遅れると到達不能になりかねません。固定 IP が保証されている場合に限り、現実的な選択肢です。

## 代替手段2: ALIAS / ANAME / CNAME フラット化

![apex 向け代替手段の比較](/blog/cname-restrictions-apex/apex-alternatives.svg)

IP の変動に自動で追随したい場合に使うのが、**ALIAS / ANAME / CNAME フラット化**と総称される仕組みです。呼び名はプロバイダごとに違いますが、考え方は共通しています。

これらは RFC で定義された標準レコードではなく、各 DNS プロバイダが提供する独自機能です。動作の要点は次のとおりです。

1. 管理画面では apex に「CNAME のように宛先ホスト名」を指定する
2. プロバイダの DNS サーバーが、その宛先ホスト名の A / AAAA を**自社サーバー側で解決**する
3. 解決した IP アドレスを、apex の A / AAAA として応答する

問い合わせる側（ブラウザや他のサーバー）から見ると apex には A レコードが返ってくるため、RFC 1034 の共存制約に触れません。宛先側の IP が変わっても、プロバイダが解決し直してくれるので、A レコード直書きのような手作業の追随が不要になります。

主要プロバイダの対応状況は次のとおりです。

| プロバイダ | 呼び名 | 主な特徴 |
|---|---|---|
| Cloudflare | CNAME フラット化 | プロキシ経由で自動適用。任意のホスト名を宛先にできる |
| AWS Route 53 | Alias レコード | AWS リソース（CloudFront / ELB 等）向けが中心 |
| Azure DNS | Alias レコード | Azure リソース向けが中心 |
| NS1 / DNSimple | ALIAS / ANAME | 任意のホスト名を宛先にできる |
| Google Cloud DNS | 非対応 | apex には A / AAAA を直書きする必要がある |

Cloudflare での具体的な設定手順や、使うべきケース / 避けるべきケースは [CNAME Flattening の仕組みと使いどころ](/blog/dns-cname-flattening-guide) で詳しく解説しているので、実際に設定する段になったらそちらを参照してください。

## どの手段を選ぶべきか

選び方の目安は次のとおりです。

- **宛先の IP が固定**: A / AAAA レコードの直書きで十分。プロバイダを問わず使える
- **宛先の IP が変わりうる（CDN / SaaS など）**: ALIAS / ANAME / CNAME フラット化に対応したプロバイダを使う
- **すでに Cloudflare / Route 53 を利用中**: それぞれのフラット化 / Alias 機能をそのまま活用できる

注意したいのは、ALIAS / ANAME / フラット化は**プロバイダ独自仕様**である点です。別の DNS プロバイダへ移行する際、これらの設定はそのままでは引き継げず、移行先の対応状況によっては A レコードへの変換などが必要になります。移行を見据えるなら、利用中の機能がどの方式かを把握しておきましょう。

## よくある質問

### なぜサブドメインには CNAME を置けて、apex には置けないのですか

apex には必ず SOA / NS レコードが存在し、RFC 1034 の「CNAME は他レコードと共存できない」制約に触れるためです。サブドメインには SOA / NS が付かないので、CNAME を単独で置けます。

### ALIAS と CNAME フラット化は別物ですか

呼び名が違うだけで、目的と動作はほぼ同じです。いずれも DNS サーバー側で宛先のホスト名を IP に解決し、apex に A / AAAA として応答することで CNAME の制約を回避します。

### A レコードを直書きするのは何が問題ですか

仕組み自体は標準的で問題ありません。ただし宛先の CDN / SaaS が IP を変更した場合に自社側も手作業で書き換える必要があり、追随が遅れると到達不能になるリスクがあります。固定 IP が保証されている場合に向きます。

### apex で CNAME 風の設定をすると、メール（MX）に影響しますか

ALIAS / フラット化は apex の A / AAAA を扱う仕組みで、MX レコードとは別管理です。ただし設定変更時に既存レコードを誤って消さないよう、変更前に現状のレコードを控えておくことをおすすめします。

## まずは現状を把握しましょう

自社のドメインがどの DNS プロバイダで、どんなレコード構成になっているかを把握しておくと、apex の設定で迷ったときにも判断しやすくなります。[無料ドメイン診断](/diagnose) で、ドメインまわりの設定状況をまとめて確認できます。

DNS の構成や移行で不安な点があれば、お気軽に [お問い合わせ](/contact) ください。専門家がわかりやすくサポートいたします。