CNAMEレコードとAレコードの違い — SaaSに『CNAMEを設定してください』と言われたときDNS管理画面の何処に入れるか
TL;DR
SaaSの設定画面に書いてある値が「数字」（例: 203.0.113.10）ならAレコード、「ドメイン名」（例: cname.vercel-dns.com）ならCNAMEレコードに設定します。ルートドメイン（example.com）にはCNAMEを設定できないのが標準仕様で、Cloudflareのフラット化機能で回避できます。
SaaSの設定画面に「以下のCNAMEレコードを設定してください」と書いてある。DNS管理画面を開いたはいいが、左の欄に何を入れ、右の欄に何を入れれば良いのか分からない——そこから始めましょう。
まず結論を書きます。SaaSの設定画面に書いてある「設定の値（右辺）」を見てください。数字が並んでいればAレコード、文字列（英字のドメイン名）が書いてあればCNAMEレコードです。これだけ覚えれば、設定画面で迷わなくなります。
この記事では、SaaSのカスタムドメイン設定で詰まりやすいポイントを順に書きます。GitHub PagesとVercelの具体的な設定手順、ルートドメインでCNAMEがエラーになる理由と回避策、設定後の確認方法まで一通り書きます。
DNSレコード全体の役割についてはDNSレコードとは何かもあわせて参照してください。
AレコードとCNAMEレコードは何が違いますか？
Aレコードはドメインを「IPアドレス（数字）」に直接向けます。CNAMEレコードはドメインを「別のドメイン名（文字列）」に向けます。SaaSの設定値が数字ならA、ドメイン名ならCNAMEです。
1行で覚える定義
- Aレコード: ドメインをIPv4アドレス（
203.0.113.10のような数字4つ区切り）に向けるレコード - CNAMEレコード: ドメインを別のドメイン名（
cname.vercel-dns.comのような英字の文字列）に向けるレコード
| Aレコード | CNAMEレコード | |
|---|---|---|
| 右辺の値 | IPアドレス（数字） | ドメイン名（文字列） |
| 主な使い場面 | 自社サーバーのIPを直接指定 | 外部SaaSのドメイン名を指定 |
| ルートドメインへの設定 | できる | できない（標準仕様） |
| IP変更時の追従 | 手動でAレコードを更新する | 向け先のA/AAAAが変われば自動追従 |
「数字か文字列か」で迷わない
SaaSの設定画面には必ず「設定してほしいレコードの値」が書いてあります。その値を見て、次のルールを当てはめてください。
203.0.113.10のように数字とドットだけ → Aレコードに設定するcname.example-saas.comのように英字のドメイン名 → CNAMEレコードに設定する
SaaSがCNAMEを指定する理由は、接続先のIPアドレスが変わってもこちらの設定を変えずに済むからです。たとえばVercelがサーバーを増やしたり構成を変えたりしても、Vercel側のCNAMEターゲットが内部で更新されるため、あなたのDNS設定はそのままで追従できます。
SaaSに「CNAMEを設定してください」と言われました。DNS管理画面の何処に入れますか？
SaaSが指示する「ホスト名」をDNS管理画面の「NAME（またはHOST）」欄に、「ポインター先のドメイン名」を「VALUE（またはPOINTS TO）」欄に入力します。欄の名前はサービスによって異なりますが役割は同じです。
SaaS側の設定画面とDNS管理画面の対応
SaaSの設定画面には「以下のDNSレコードを追加してください」という形で、設定すべきレコードの情報が表示されます。典型的な表示例は次のとおりです。
Type: CNAME
Host: www
Value: cname.vercel-dns.comまたは:
Type: CNAME
Name: www.example.com
Points to: your-username.github.ioこの情報をDNS管理画面に入力するときの対応は次のとおりです。
| SaaS画面の項目名 | DNS管理画面の対応欄 | 入力する内容 |
|---|---|---|
| Host / Name / ホスト名 | NAME（またはHOST） | www（またはwww.example.com） |
| Value / Points to / 向き先 | VALUE（またはPOINTS TO / ANSWER） | cname.vercel-dns.com 等のドメイン名 |
| Type | Type | CNAME を選択 |
NAME欄の入力形式に注意
DNS管理画面のNAME欄に入力する形式は、サービスによって異なります。
wwwとだけ入れる形式（末尾にドメイン名を自動補完する）www.example.comと完全なドメイン名で入れる形式
SaaSの指示に書かれている形式に従ってください。「www」と書いてあれば「www」だけを入力します。「www.example.com」と書いてあれば完全な形で入力します。独自に短縮しないことが重要です。
GitHub Pagesのカスタムドメイン設定手順
GitHub Pagesでカスタムドメインを使う場合、サブドメイン（www.example.com）はCNAMEで設定します。
- GitHubの対象リポジトリを開き、「Settings」→「Pages」を開く
- 「Custom domain」欄に使いたいドメイン（
www.example.com）を入力して「Save」をクリックする - 画面に「Add a CNAME record…」という指示が表示される
- DNS管理画面を開き、次のCNAMEレコードを追加する
NAME（またはHOST）: www
VALUE（またはPOINTS TO）: your-username.github.io
TYPE: CNAMEyour-username の部分はGitHubのユーザー名（または Organization 名）に置き換えてください。
- DNS管理画面で保存する
- GitHubの設定画面に戻り、DNSの確認が完了するまで待つ（数分〜数時間かかる場合がある）
Vercelのカスタムドメイン設定手順
VercelでカスタムドメインのCNAMEを設定する手順は次のとおりです。
- Vercelのプロジェクト画面を開き、「Settings」→「Domains」を開く
- 使いたいドメイン（例:
www.example.com）を入力して「Add」をクリックする - 画面にCNAMEの設定情報が表示される（Vercelが指示する値はプロジェクトによって異なるため、必ず画面の指示を確認する）
- DNS管理画面を開き、指示に従ってCNAMEレコードを追加する
NAME: www
VALUE: cname.vercel-dns.com（Vercelが指示した値を入力）
TYPE: CNAME- DNS管理画面で保存する
- Vercelの画面でDNSの検証が完了するまで待つ
ルートドメイン（example.com）にCNAMEを設定しようとしたらエラーになりました。なぜですか？
ルートドメイン（zone apex）にはCNAMEを設定できないのがDNSの標準仕様です。ルートドメインには必ずNSレコードとSOAレコードがあり、CNAMEはこれらと共存できません。操作ミスではなく仕様です。
「wwwはできたのに」という状況について
www.example.com（サブドメイン）にはCNAMEを設定できたのに、example.com（ルートドメイン）では同じ操作がエラーになった——この状況は非常によくあります。操作を間違えたわけではなく、DNSの仕様としてルートドメインへのCNAMEが禁止されているためです。
ルートドメインには、そのドメインのDNSを管理するNSレコードとSOAレコードが必ず存在します。CNAMEは「このドメインのすべての情報を別名に委ねる」という意味のレコードであるため、NSやSOAと共存できません。このためDNSの仕様として、zone apex（ルートドメイン）へのCNAMEは設定できないと定められています。
解決策1: Aレコードで設定する
最も一般的な解決策は、ルートドメインにはCNAMEの代わりにAレコードを使うことです。
SaaSがIPアドレスを提供している場合:
NAME: @ （または空欄、または example.com そのまま）
VALUE: 203.0.113.10（SaaSが指示したIPアドレス）
TYPE: Aただし、SaaSのIPアドレスが変更されたとき、こちらのAレコードも更新する必要があります。SaaSによっては「ルートドメインにはAレコードでこのIPを設定してください」という指示を出しているケースがあります。SaaSの指示画面を必ず確認してください。
解決策2: CloudflareのCNAMEフラット化を使う
CloudflareのCNAMEフラット化を使えば、ルートドメインにもCNAMEのような設定ができますか？
Cloudflareのフラット化（CNAME Flattening）機能を使うと、ルートドメインにCNAMEを設定できます。Cloudflareが内部でCNAMEが指すIPアドレスを調べ、CNAMEの代わりにIPアドレスを返します。
Cloudflareをネームサーバーとして使っている場合、CNAME Flattening（CNAMEフラット化）という仕組みを利用できます。Cloudflareの管理画面でルートドメイン（@）にCNAMEレコードを追加するだけで、Cloudflareが内部でCNAMEが指すドメインのIPアドレスを解決し、外部にはIPアドレスとして返します。
設定手順:
- Cloudflareの管理画面を開き、対象ドメインのDNSレコード画面を開く
- 「レコードを追加」をクリックする
- タイプを「CNAME」に設定する
- 名前に
@（ルートドメインを意味する）を入力する - 「ターゲット」にSaaSが指示したCNAMEの値を入力する
- 保存する
CloudflareがルートドメインへのCNAMEを受け付け、内部でフラット化してIPアドレスとして返すため、zone apexへのCNAME制約を回避できます。
詳細はCloudflareの公式ドキュメントを参照してください: Cloudflare CNAME Flattening
AWSを使っている場合はRoute53の「Aliasレコード」が同等の機能を持ちます。
CNAMEを設定したのにサイトが表示されません。確認することは何ですか？
CNAMEの右辺（ポインター先）のドメインが正しく設定されているか、
nslookup -type=CNAME 自分のサブドメインで確認します。ターゲット先が存在しない（Dangling CNAME）場合、DNSは応答できません。
CNAMEを設定してもサイトが表示されない原因
CNAMEを設定した後にサイトが表示されない場合、原因は大きく3つに絞られます。
原因1: CNAMEの右辺（ターゲット）のドメイン名が間違っている SaaSが指示したCNAMEの値をコピーした際に誤字が混入した、またはドメイン名が古くなっているケースです。SaaSのダッシュボードに表示されているCNAMEの値を再確認してください。
原因2: ターゲット先のドメインが存在しない（Dangling CNAME） CNAMEが指している先のドメインが、SaaS側で削除または変更されている状態です。たとえば、SaaSのプロジェクトを削除・リセットした後、古いCNAMEターゲットが無効になるケースがあります。Dangling CNAME（宙ぶらりんのCNAME）と呼ばれ、DNSは問い合わせを受けてもIPアドレスを返せないため、サイトにアクセスできません。
原因3: TTLの待ち時間中 DNSの変更は即時には反映されません。TTL（キャッシュの有効期限）が切れるまで、各地のDNSサーバーが古い情報を返し続けます。後述のnslookupで確認して正しく返ってきていれば、TTLの待ち時間中と判断できます。
nslookupでCNAMEを確認する手順（Windows）
Windowsのコマンドプロンプトで次のコマンドを実行します。www.example.com の部分を確認したいサブドメインに置き換えてください。
nslookup -type=CNAME www.example.com出力パターン別の読み方:
CNAMEが正しく設定されている場合:
Server: dns.example.net
Address: 192.168.1.1
Non-authoritative answer:
www.example.com canonical name = your-username.github.iocanonical name = に続いてSaaSのドメインが表示されれば、CNAMEは正しく設定されています。サイトが表示されない場合はTTLの待ち時間中か、SaaS側の設定が未完了の可能性があります。
CNAMEが設定されていない場合（Aレコードのみ、またはレコードなし）:
Server: dns.example.net
Address: 192.168.1.1
www.example.com internet address = 203.0.113.10CNAMEではなくAレコードが返ってきている状態です。設定がCNAMEになっていない、またはCNAMEを設定したつもりがAレコードとして保存されているケースです。
Dangling CNAMEの場合（CNAMEは設定されているがターゲットが存在しない）:
Server: dns.example.net
Address: 192.168.1.1
Non-authoritative answer:
www.example.com canonical name = deleted-project.example-saas.com
*** dns.example.net can't find deleted-project.example-saas.com: Non-existent domainCNAMEの設定は正しいが、CNAMEが指している先のドメインが存在しない状態です。SaaSのダッシュボードに戻り、CNAMEターゲットの値が現在も有効かを確認してください。
設定ミスかTTL待ちかの切り分け
nslookupでCNAMEレコードが正しく返ってきている場合は、設定自体は正しく反映されています。サイトが表示されない場合は、SaaS側の設定（SaaSのダッシュボードでDNS検証が完了しているか）を確認してください。
nslookupでCNAMEが返ってこない場合は、まだDNSに変更が反映されていないか、設定に誤りがあります。TTLの仕組みと反映待ちの詳細はDNSのTTLと反映待ちを参照してください。
macOSやLinuxでは dig -t CNAME www.example.com で同じ情報を確認できます。
同じドメインでメールも使っている場合、メールの宛先を決めるのはCNAMEでもAでもなくMXレコードです。切り分けの対象が「サイトではなくメール」であれば、MXレコードの設定方法を参照してください。
まとめ
設定前の判断ルール:
- SaaSの設定値が数字（IPアドレス） → Aレコードに設定する
- SaaSの設定値がドメイン名（英字の文字列） → CNAMEレコードに設定する
- ルートドメイン（
example.com）にCNAMEを設定しようとしてエラーになった → Aレコードで代替するか、Cloudflareのフラット化機能を使う
設定後の確認:
nslookupで canonical name = が返ってくれば設定は反映されています。サイトが表示されなければSaaS側の設定（ダッシュボードのDNS検証ステータス）を確認してください。
CNAMEとAの区別は、技術の話に見えて、実は設定画面に書いてある値を読めるかどうかの話です。数字が書いてあればA、ドメイン名が書いてあればCNAME。それだけ分かれば、SaaSの設定ページの指示をそのままDNS管理画面に入れられます。zone apexのエラーも、Cloudflareを使っているなら回避策があります。知識が足りないのではなく、知っておくべきポイントが一つ抜けていただけです。
SaaSのカスタムドメイン設定やDNSまわりで詰まっているなら、メールでご相談ください。