Aレコードはホスト名をIPv4アドレスに直接結びつけるレコード、CNAMEレコードはホスト名を「別のホスト名の別名」として定義するレコードです。自分で管理するサーバーのIPアドレスに向けるならA、CDNやSaaSなど相手側がIPアドレスを変える可能性のあるサービスに向けるならCNAME、というのが基本の使い分けです。ただしCNAMEには「ほかのレコードと同じ名前に置けない」「ドメインの頂点（example.com そのもの）には置けない」という制約があり、ここを知らないと設定画面で弾かれたり、メールが届かなくなったりします。この記事では、両者の仕組み、設定例、制約と回避策、反映の確認方法を説明します。
AレコードとCNAMEレコードの仕組み
ブラウザが www.example.com を開くとき、リゾルバ（プロバイダや社内のキャッシュDNS）は権威DNSサーバーにその名前を問い合わせます。
Aレコードが設定されていれば、答えはIPアドレスそのものです。
example.com. 3600 IN A 203.0.113.10CNAMEレコードが設定されていると、答えは「その名前は別の名前の別名です」という情報になります。リゾルバは続けて別名の先を問い合わせ、最終的にAレコード（IPv6ならAAAAレコード）にたどり着いたところでIPアドレスを返します。
www.example.com. 3600 IN CNAME example.com.
example.com. 3600 IN A 203.0.113.10この例では、www.example.com の問い合わせに対して 203.0.113.10 が返ります。example.com のAレコードを書き換えれば、www も自動的に同じ先へ向くので、IPアドレスを1か所で管理できるのがCNAMEの利点です。
一方で、CNAMEはリダイレクトではありません。ブラウザのアドレス欄は www.example.com のまま変わらず、サーバーには Host: www.example.com としてアクセスが届きます。そのため、Webサーバー側でその名前を受け付ける設定（バーチャルホストやサーバーブロック）と、その名前を含むSSL証明書が別に必要です。WordPressで www ありとなしを統一したい場合も、DNSではなくWebサーバーの301リダイレクトで行います。
AレコードとCNAMEの使い分け
Aレコードを使う場面
- 自分で契約しているVPSや専用サーバーにドメインを向けるとき。
- ドメインの頂点（
example.com）を向けるとき。後述のとおり、頂点にはCNAMEが置けません。 - メールサーバーのホスト名（
mail.example.com）など、MXレコードの向き先になる名前。
CNAMEを使う場面
- CDN、ホスティングサービス、SaaS（ECサイトやヘルプデスクなど）から「このホスト名にCNAMEを設定してください」と指示されたとき。相手側はIPアドレスを変更・分散することがあるため、IPアドレスでAレコードを書くと、ある日突然つながらなくなります。
wwwやblogなどのサブドメインを、同じサーバーを指す別の名前に揃えたいとき。
AとCNAMEで迷ったら、「向き先のIPアドレスを自分で管理しているか」で判断すると決めやすくなります。
CNAMEが設定できない場所
ほかのレコードと同じ名前には置けない
CNAMEを設定した名前には、ほかの種類のレコード（A、MX、TXTなど）を置けません。DNSの仕様（RFC 1034）で、CNAMEは「その名前のすべてのデータは別名の先にある」という意味を持つためです。
たとえば shop.example.com をSaaSに向けるためにCNAMEを設定すると、同じ shop.example.com にSPF用のTXTレコードやMXレコードを追加することはできません。多くのDNS管理画面は保存時にエラーを出しますが、ゾーンファイルを直接編集する環境では、エラーにならずに一部の問い合わせだけおかしな結果になることがあります。サブドメインでメールも受けたい場合は、そのサブドメインにはCNAMEではなくAレコードを使う設計にします。
ドメインの頂点（ゾーンエイペックス）には置けない
example.com そのもの（ゾーンの頂点）には、ゾーンの情報を表すSOAレコードと、権威DNSサーバーを表すNSレコードが必要です。上のルールにより、これらと同居できないCNAMEは頂点に置けません。頂点にはAレコード（とAAAAレコード）を設定します。
それでも頂点をCDNやSaaSのホスト名に向けたい場合のために、DNS事業者が独自の機能を提供しています。
- CNAMEフラットニング（Cloudflareなど）：設定上は頂点にCNAMEを書けますが、DNS事業者が裏で別名の先を解決し、外部にはAレコードとして返します。
- ALIASレコード / ANAMEレコード：事業者によって名前が違いますが、仕組みは同様です。
- エイリアスレコード（Amazon Route 53）：AWSのロードバランサーやCloudFrontなどを、頂点からAレコードとして指せます。
これらはDNSの標準のレコードではなく各事業者の機能なので、利用しているDNSサービスが対応しているかを確認してください（2026年10月現在、主要なクラウドDNSの多くは何らかの形で対応しています）。
MXやNSの向き先にCNAMEを使わない
MXレコードやNSレコードの向き先には、CNAMEではなくA/AAAAレコードを持つ名前を指定します（RFC 2181）。mail.example.com をCNAMEにしてMXから指すと、送信側のサーバーによっては配送に失敗します。
設定例
一般的なDNS管理画面では、「ホスト名」「種別」「値」「TTL」を入力します。頂点は空欄または @ で表すことが多く、ホスト名欄には www のようにドメイン部分を除いた名前だけを書く画面が一般的です。
ホスト名 種別 値 TTL
@ A 203.0.113.10 3600
www CNAME example.com. 3600
shop CNAME shops.example-saas.net. 3600
mail A 203.0.113.20 3600
@ MX 10 mail.example.com. 3600BINDなどのゾーンファイルで書く場合、末尾のドット（.）に注意が必要です。ドットで終わる名前は完全な名前として扱われ、ドットがないとゾーン名が後ろに付け足されます。www IN CNAME example.com とドットを付け忘れると、example.com.example.com. の別名になってしまいます。管理画面によっては自動でドットを補うものもあるので、保存後の表示を確認してください。
既存のサイトの向き先を変える作業では、事前にTTLを短く（たとえば300秒）しておくと、切り替え後に古い情報が残る時間を短くできます。また、レコードを削除・変更する前に、現在の設定を画面のスクリーンショットやエクスポートで控えておくと、問題が起きたときにすぐ戻せます。
設定が反映されたかを確認する
確認には dig を使います。Windowsでは nslookup または PowerShell の Resolve-DnsName が使えます。
# Aレコードの確認
dig example.com A +short
# CNAMEの確認（別名の先と、最終的なIPアドレスが表示される）
dig www.example.com +noall +answer
# キャッシュを通さず、権威DNSサーバーに直接問い合わせる
dig @ns1.example.net www.example.com +noall +answerResolve-DnsName www.example.com+noall +answer を付けると、回答部分だけが表示されます。CNAMEを設定した名前なら、1行目にCNAME、2行目以降に別名の先のAレコードが出ます。
権威DNSサーバーに直接聞いた結果が正しいのに、ふだんの環境で古い結果が返る場合は、リゾルバやOSのキャッシュがTTLの間残っているだけです。待つか、手元のDNSキャッシュを消去して確認します。権威DNSサーバーの結果がそもそも違う場合は、ドメインのNSレコードが別のDNSサービスを指している可能性があるので、dig example.com NS +short で、設定した管理画面のDNSサーバーが使われているかを確かめてください。
まとめ
- Aレコードはホスト名をIPアドレスに直接結びつけ、CNAMEは別のホスト名の別名にする。CNAMEはリダイレクトではないため、Webサーバーの設定とSSL証明書は別に用意する。
- 自分で管理するサーバーにはA、IPアドレスが変わりうるCDNやSaaSにはCNAMEが基本。
- CNAMEはほかのレコードと同じ名前に置けず、ドメインの頂点にも置けない。頂点を外部サービスに向けたいときは、CNAMEフラットニングやALIAS/ANAME、Route 53のエイリアスなど事業者の機能を使う。
- MXやNSの向き先はCNAMEではなくA/AAAAを持つ名前にする。
- ゾーンファイルでは末尾のドットに注意し、変更前にはTTLを短くして現在の設定を控える。
digで権威DNSサーバーとふだんのリゾルバの両方を確認する。