Webサービスを運営していると、説明の付きにくい価格差に出会います。たとえば、顧客が所有するドメインを自社SaaSへ接続できる「カスタムドメイン」機能です。
www.example.com のようなサブドメインなら比較的簡単です。ところが example.com そのもの、つまりapex (エイペックス)を使えるようにしようとすると、選択肢が減ったり、高価なプランが必要になったりします。同じWebサイトを表示するだけなのに、なぜこうなるのか。
原因を追うと、1980年代のDNSが前提としていた条件と、世界中のサーバーを動的に切り替える現代のクラウドやCDNが必要とする条件の違いに行き着きます。表面に見えているのはDNSレコードを1行書くかどうかの差です。その下には、そのIPアドレスを提供側と顧客のどちらが維持し続けるのか、という分担の問題があります。
名前からIPアドレスを引くDNSの役割
まずDNSを単純化して考えます。ブラウザーで https://www.example.com を開いたとき、コンピューターは最終的に通信先となるIPアドレスを知る必要があります。DNSには、その対応関係を記述するためのいくつかのレコードがあります。今回重要なのは A と CNAME です。
A レコードは、名前をIPv4アドレスへ直接対応させます。
example.com
↓ A
203.0.113.10
一方、CNAME はIPアドレスではなく、「別の名前を見てください」と指定します。
www.example.com
↓ CNAME
customer.example.cdn-provider.example
↓
CDNが現在適切なIPアドレスを返す
この違いは、現代のクラウドでは大きな意味を持ちます。
CDNがIPアドレスの固定を避ける理由
昔ながらのWebサーバーなら example.com → 203.0.113.10 という対応でも困りません。1台のサーバーを用意し、そのIPアドレスをDNSへ登録すればよいからです。
しかし、CloudflareやFastlyのような現代のCDNは違います。利用者が東京にいるなら東京付近、ロンドンならヨーロッパ付近というように、世界中の拠点から効率よくコンテンツを配信します。障害が起きれば別の経路へ切り替え、ネットワーク構成の変更にも追随します。
つまりCDN事業者としては、「このサービスのIPアドレスは永久に203.0.113.10です」とは約束したくありません。むしろ、次のように自社で管理する名前を指定してもらい、その名前の先を自分たちで変更できる方が運用しやすくなります。
www.example.com
↓
customer.example.fastly.net
この要求に合うのがCNAMEです。Fastly自身も、サブドメインではCNAMEを利用し、apexではA/AAAAレコードを利用する構成を案内しています。また、可能ならサブドメインを利用した方が、ルーティングの変更をFastly側で完結できると説明しています。
apexに普通のCNAMEを置けない理由
問題になるのが example.com です。このようなドメイン階層の一番上を zone apex、一般には単に apex と呼びます。
DNSの標準では、CNAMEが存在する名前には原則として別種類のDNSデータを共存させられません。一方、zone apexにはDNSゾーンそのものを成立させるための SOA や NS といったレコードが必要です。そのため、次の単純な設定は標準的なDNSでは成立しません。
example.com CNAME customer.example.fastly.net
これはCloudflareやFastlyが独自に設けた制限ではなく、DNSそのものが持つ制約です。DNSの基本仕様はRFC 1034/1035として1987年に公開され、その後RFC 2181などで挙動が明確化されてきました。現在のDNS用語を整理したRFC 9499でも、こうした古くからの設計を前提としてDNSが動いています。
ここで、現代クラウドとの衝突が起こります。
現代のCDN
「IPではなく、こちらが管理できるホスト名を指定してほしい」
↑
│ CNAMEを使いたい
│
DNS
「apexでは普通のCNAMEは使えない」
サブドメインなら問題にならなかったものが、apexでは急に難しくなる理由です。
Aレコードのまま世界規模で受けるためのAnycast
もっとも分かりやすい解決策は、CNAMEを諦めてAレコードを使うことです。
example.com
↓ A
192.0.2.10
↓
CDN
ただし、ここで新しい問題が生まれます。1台のサーバーのIPアドレスを指定してしまうと、そのサーバーが単一障害点になります。また、利用者から遠い場所に置かれていれば、通信距離も長くなります。
そこでCDNでは Anycast が使われます。Anycastでは、同じIPアドレスを世界中の複数拠点から広告します。ここでいう広告は、JPNICの用語集が「ルータが保持している経路情報を、他のルータに知らせること」と定義する経路広告です。
┌ 東京
example.com ── IP ─┼ シンガポール
├ ロンドン
└ ニューヨーク
利用者から見るとIPアドレスは1つです。しかしインターネットの経路制御によって、通常はネットワーク的に近い拠点へ通信が届きます。これならDNSには example.com A <Anycast 静的IPアドレス> と書いたまま、裏側では世界規模の分散配信ができます。
Fastlyがapex向けに提供しているのもこの方式です。公式ドキュメントでも、apexではCNAMEを利用できないためAnycast IPをAまたはAAAAレコードへ設定する方法が案内されています。
ここで重要なのは、固定IPとAnycastは同じ意味ではないことです。固定IPは単に「IPアドレスが変わらない」という性質で、Anycastは「同じIPアドレスを複数拠点から到達可能にする」というネットワーク技術です。現代的なCDNのapex入口として必要なのは、単なる固定IPではなくAnycast 静的IPアドレスです。この2つの性質を兼ねたアドレスを、Fastlyは anycast IP addresses、Amazon CloudFrontは Anycast Static IPs と呼んでいます。
Anycastの詳細は別の記事」で扱っています。
DNS事業者によるCNAMEのAレコード変換
もう1つの解決方法があります。DNSサーバー側でCNAMEの行き先を調べ、利用者には最終的なIPアドレスを返してしまう方法です。Cloudflareではこれを CNAME Flattening と呼んでいます。
設定上は、次のCNAME相当の関係を持たせます。
example.com
↓
service.example.net
しかし、DNS問い合わせに対して実際に返すときには、次のようにIPアドレスへ「平坦化」します。
example.com
↓
192.0.2.10
192.0.2.11
Cloudflareは現在、CNAME Flatteningによってzone apexにもCNAMEを設定できると公式に説明しています。これはDNS標準そのものを書き換えたのではなく、DNSプロバイダー側で問題を吸収する仕組みです。
この方式がDNSの仕様に反していない理由は、別の記事」で扱っています。RFC 1034が禁じている対象がどこまでかを確定させ、そこから順に導いています。
DNS標準
apex CNAMEは困る
↓
DNSプロバイダー
「ではこちらで名前を解決して、A/AAAAとして返します」
AWS Route 53のALIASや、一部DNSプロバイダーのANAMEも、「クエリ時にサーバー側で名前を解決して返す」という点では同じ発想です。ただしRoute 53のALIASには、指定できるターゲットの制約があります。ALIASが指せるターゲットは2種類です。CloudFront・ELB (ALB/NLB/CLB)・API Gateway・VPCエンドポイント・S3の静的サイト・Global Acceleratorといった特定のAWSリソースと、同一ホストゾーン内の別レコードです。customer.example.fastly.net のような任意の外部ホスト名は指定できません。
この違いは実務上の分岐点になります。顧客がRoute 53を使っていても、外部CDNのapexを受けるには結局AレコードでAnycast 静的IPアドレスを案内する必要が出てきます。CNAME Flatteningのように任意の外部ホスト名を指定できる機能は、DNS事業者側がそれを提供している場合に限られます。
「自分のDNSならできる」が「顧客のDNSでもできる」にならない理由
この差はSaaSを作るときに表面化します。自社サイトだけなら、example.com のDNSをCloudflareへ移してCNAME Flatteningを使う選択もあります。
しかし、SaaSのカスタムドメインでは話が違います。顧客AはRoute 53、顧客Bはお名前.com、顧客CはCloudflareというように、DNS事業者は顧客ごとに異なります。企業によってはDNSを変更すること自体が社内規定で禁止されている場合もあります。SaaS側から「Cloudflare DNSへ移行してください」とは簡単には言えません。
そこで最も互換性の高い設定が、次のAレコードです。
example.com A 192.0.2.10
Aレコードなら、ほぼすべてのDNSサービスで設定できます。この「どのDNS事業者を使っている顧客でもapexを接続できるようにしたい」という要件が、Anycast 静的IPアドレスを持つインフラの価値を生みます。
実際のサービスによるapexの案内
ここまでの選択肢は、実際のサービスの案内にそのまま現れます。代表的なものを並べると、立場が2つに分かれます。
GitHub Pagesは、apex向けに固定のIPアドレスを公開しています。
example.com A 185.199.108.153
example.com A 185.199.109.153
example.com A 185.199.110.153
example.com A 185.199.111.153
example.com AAAA 2606:50c0:8000::153
example.com AAAA 2606:50c0:8001::153
example.com AAAA 2606:50c0:8002::153
example.com AAAA 2606:50c0:8003::153
サブドメインは USERNAME.github.io へのCNAMEです。Vercelも同じ形で、apexはAレコード、サブドメインはプロジェクトごとに異なるCNAME (d1d4fc829fe7bc7c.vercel-dns-017.com のような値) を案内します。Fastlyも前述のとおりA/AAAAとCNAMEで分けています。いずれも、自分たちで入口のIPアドレスを持ち、それを顧客へ配る立場です。
一方、Herokuは正反対の立場を取ります。
Because Heroku uses dynamic IP addresses, it's necessary to use a CNAME-like record (often referred to as ALIAS or ANAME records) so that you can point your root domain to another domain.
HerokuはIPアドレスを動的に扱うため、ルートドメインを別のドメインへ向けるには、CNAME相当のレコード (ALIASやANAMEと呼ばれることが多い) を使う必要がある。
さらに、Aレコードでの接続を明示的に否定しています。
Some DNS providers only offer A records for root domains. Unfortunately, A records aren't sufficient for pointing your root domains to Heroku because they require a static IP.
一部のDNSプロバイダーは、ルートドメインに対してAレコードしか提供しない。しかしAレコードでは、ルートドメインをHerokuへ向けるには不十分である。静的IPを必要とするからだ。
そのうえで、DNSimple・DNS Made Easy・easyDNS・Cloudflareなど、ALIAS/ANAME/CNAME Flatteningに対応するDNS事業者を名指しで案内しています。
この対比が、前節の内容をそのまま裏づけます。
| 立場 | 例 | apexの案内 | 顧客への要求 |
|---|---|---|---|
| 入口のIPアドレスを持つ | GitHub Pages、Vercel、Fastly | A / AAAA | どのDNS事業者でもよい |
| 入口のIPアドレスを持たない | Heroku | ALIAS / ANAME / CNAME Flattening | 対応するDNS事業者へ移る必要がある |
どちらが優れているという話ではありません。入口のIPアドレスを持つ側は、そのアドレスを長期間維持する義務を引き受けます。持たない側は、その義務を負わない代わりに、顧客のDNS事業者を選ぶという条件を課します。apex対応のコストは消えません。提供者と顧客のどちらかが負担します。
apex対応の価格が上がる理由
ここまで理解すると、カスタムドメインサービスの料金体系も見えやすくなります。
サブドメインだけなら、SaaS事業者は顧客へこう案内できます。
www.customer.example
CNAME
customers.my-saas.example
あとは customers.my-saas.example の行き先を自社で管理できます。顧客のゾーンには自社の名前しか書かれていないので、その先は好きに動かせます。
しかしapexを受ける場合は、こう案内することになります。
customer.example
A
<Anycast 静的IPアドレス>
するとサービス提供側は、そのIPアドレスを長期間維持しながら、障害時にも止まらず、世界各地から高速にアクセスできる入口を用意することになります。
さらにHTTPSを提供するなら、次の仕組みも必要になります。
つまり利用者から見ると「Aレコードを1行追加するだけ」に見える機能の裏側に、大きな共有インフラが存在します。apex対応の値段が上がるのは、AレコードというDNSレコード自体が高価だからではありません。Aレコードの向こう側に、固定されたグローバル入口を維持しなければならないからです。
Amazon CloudFrontの場合
価格として表に出ている例を1つ挙げます。CloudFrontは通常、d111111abcdef8.cloudfront.net のような配布ドメインへCNAMEを向けて使います。この使い方でIPアドレスの料金は発生しません。
一方、apexをAレコードで受けるには、エニーキャスト静的IPをリクエストし、そのアドレスへAレコードを向けます。AWSが公開している価格表 (Price List APIのAmazonCloudFront、2025年7月1日版) には、次の課金項目が定義されています。
StaticIP-IPv4 $15000 per month per StaticIP-IPv4 list
StaticIP-IPv6 $5000 per month per StaticIP-IPv6 list
配信の従量課金とは別に、IPアドレスのリストを保持しているだけで発生する固定費です。同じCloudFrontで同じコンテンツを配信していても、CNAMEで受けるか、apexをAレコードで受けるかで、この固定費の有無が変わります。
ただし、この金額が必要になる条件は限定されます。顧客のDNSがRoute 53なら、CloudFrontへのALIASレコードを無料で使えるため、静的IPは要りません。静的IPが必要になるのは、DNS事業者を選べない場合です。前節の「自分のDNSならできる」と「顧客のDNSでもできる」の差が、そのまま価格差として現れます。
CDN自身がAnycast IPを持つFastlyの方式
Fastlyの場合は構造が単純です。
customer.example
↓ A
Fastly Anycast IP
↓
Fastly Edge
↓
Origin
Fastly自身がグローバルネットワークを持っているため、そのAnycast IPをapexの入口として利用できます。FastlyのTLS設定ドキュメントでも、apexにはAレコード、サブドメインにはCNAMEを利用する構成が示されています。
つまりFastlyは「CNAMEをapexで無理に使えるようにする」のではなく、「apexならAレコードで受けられるグローバルIPをこちらで用意する」という解決をしています。
入口だけをサービス化するApproximated
さらに興味深いのが Approximated のようなサービスです。ApproximatedはCDNそのものというより、SaaS向けのカスタムドメイン、TLS、リバースプロキシの入口をマネージドサービスとして提供します。
構成を単純化すると次のようになります。
customer.example
↓
Approximated
↓
自社SaaS / CDN / Cloudflare Worker
自社でAnycastや証明書の自動発行、ドメイン管理基盤を構築する代わりに、その部分を外部サービスへ任せます。Approximated自身も、カスタムドメインを安全にルーティングするためのサーバー、ネットワーク、ソフトウェアを自分で構築・維持しなくてよいことをサービスの価値として説明しています。
2026年8月時点の通常プランは、カスタムドメイン1件あたり月額0.20ドル、100ドメイン未満では最低月額20ドルです。月間400GBの帯域が含まれ、それを超える通信量は1GBあたり0.05ドルとされています。
料金の中身は「DNSレコード代」ではありません。入口のIPアドレス、TLS、ルーティング、カスタムドメイン管理をまとめて外部化する料金と考える方が適切です。
同じ「apexをAレコードで受ける」機能でも、価格の桁が違います。CloudFrontのエニーキャスト静的IPが月額15,000ドル、Approximatedが最低月額20ドルです。ただしCloudFrontの金額はAWSのPrice List API (2025年7月1日版) の値で、二次情報には月額3,000ドルとするものもあります。確定情報としては扱わないでください。両者の売っているものは同一ではありません。この差がどこから来るのかは、続編で扱います。
この位置に立つサービスはApproximatedだけではありません。SaaS Custom Domainsも同じ構成を提供します。apexは公式ドキュメントが示すとおり、2本のAレコードで受けます。2026年8月時点の公開ページでは、100ドメイン分で月額29ドル (1件あたり0.29ドル) から始まり、規模に応じて最大50%の割引が適用されるとされています。
料金の考え方に違いがあります。Approximatedが帯域を従量課金する一方、SaaS Custom DomainsはFAQで「No, we do not charge extra for bandwidth.」と述べ、帯域に課金しないとしています。
Approximated ドメイン単価 + 帯域 (400GB込み、超過は1GBあたり0.05ドル)
SaaS Custom Domains ドメイン単価のみ
この差が響くかどうかは、経路に何を通すかで決まります。入口を認証やルーティングだけに使い、実体の配信を別のCDNへ切り替える構成なら、通る量が少ないため差は出ません。一方、ページの中身をすべて経路に通す構成では、通信量そのものが料金を決めます。 HTMLだけでなく画像やJavaScriptも同じ経路を通るためです。
どちらを選ぶかは、入口をどこまで使うかで決まります。
自前で入口を構築する場合の構成
この入口を自社で構築する選択もあります。たとえばAWSには Global Accelerator があります。Global Acceleratorは、AWSエッジネットワークからanycastされる静的IPアドレスをグローバルな入口として提供し、AWSネットワークへトラフィックを引き込むサービスです。
その後ろにロードバランサーやリバースプロキシを置けば、次の構成を作れます。
customer.example
↓ A
AWS Global Accelerator
↓
Load Balancer
↓
自社リバースプロキシ
↓
CDN / Worker / Origin
Global Accelerator自体の固定料金は、2026年8月時点で1アクセラレーターあたり1時間0.025ドル、約18ドル/月です。ただし、これにデータ転送料、IPv4料金、ロードバランサーやコンピュートなどの費用が加わります。さらにSaaSとして使うなら、TLS証明書の発行、更新、テナント判定、監視、冗長化を自分たちで実装・運用します。
そのため、次の3種類の選択肢が見えてきます。
Fastlyなど
CDN自身に任せる
Approximatedなど
カスタムドメイン入口を専門サービスに任せる
AWSなど
固定入口だけ借りて残りを自分で作る
AかCNAMEかという見方の限界
ここまで、apexにはAレコード、サブドメインにはCNAME、という話をしてきました。しかし、レコード型の違いは表面に出ているものにすぎません。その下で本当に分かれているのは、別の一点です。
IPアドレスとルーティングを維持し続けるのが、提供側と顧客のどちらになるか。
CNAMEとAレコードの差は、その分担をどこで区切るかの差です。
CNAMEを書いた時点で、その先はすべてCDNの管理下に入ります。
www.example.com
↓ CNAME
CDNの名前
↓
CDNが自由に変更
顧客のゾーンに書かれているのはCDNの名前だけです。その先で拠点が増えても、IPアドレスが入れ替わっても、顧客は何もしません。
Aレコードを書いた時点では、管理が2つに分かれます。
customer.example
↓ A
198.51.100.20 ← 顧客のゾーンに書き込まれている
↓
この先はCDNが自由に変更できる
境界がIPアドレスの上に来るため、そのアドレスだけはCDN側から動かせません。しかも一度公開したIPアドレスは、世界中のリゾルバーにキャッシュされるだけでは済みません。顧客の運用手順書、監視設定、ファイアウォールの許可リストにも書き写されます。DNSのTTLが切れても、そちらは消えません。一度配ったIPアドレスは実質的に回収できない、という前提で設計することになります。
そのため、アドレスの背後にある構成は提供側がすべて引き受けることになります。Anycast、ロードバランサー、CDNエッジ、ヘルスチェック、フェイルオーバーが要るのは、アドレスを変えられないという制約を、アドレスを変えずに吸収するためです。
言い換えると、CNAMEは「場所ではなく管理主体を指定する」仕組みに近く、Aレコードは「入口そのものを指定する」仕組みに近い。apex対応が高くつくのは、この「入口そのもの」を顧客の数だけ、長期にわたって維持する必要があるからです。料金表の差は、レコード型の差ではなく、この分担の位置に対応しています。
HTTPS/SVCBによるDNS側の拡張
DNSが1980年代のまま何も変わっていないわけではありません。ALIAS、ANAME、CNAME FlatteningといったDNS事業者独自の仕組みが普及し、標準化の側でもHTTPS/SVCBレコードによって、apexを含めて従来より柔軟にサービスの接続先を表現できる仕組みが整備されています。
RFC 9460は、SVCBのAliasModeについて、CNAMEを置けないzone apexでCNAMEに相当する別名指定を可能にする用途を設計動機として挙げています。
ただし、既存のWeb、DNS事業者、ブラウザー、CDN、企業ネットワークとの互換性を考えれば、A/AAAAとCNAMEがすぐに消えるわけではありません。40年近く使われてきたDNSの仕組みを、インターネット全体で一斉に交換するのは不可能だからです。
DNSが古いから悪い、とは言えない理由
この話を「DNSが古くて駄目だから」とまとめるのは的を外しています。DNSが設計された1980年代に、次のものまで想定するのは無理があります。
- 世界中に数百拠点を持つCDN
- 数百万顧客を収容するマルチテナントSaaS
- 数分単位で増減するクラウドサーバー
- 自動発行されるTLS証明書
- Anycastによる世界規模のルーティング
一方、DNSは長期間にわたり、ほぼすべてのインターネットサービスの基盤として動き続けています。だから現代のクラウドサービスはDNSを置き換えるのではなく、その制約の外側にさまざまな仕組みを追加してきました。
1980年代のDNS
│
├ CNAME
├ A / AAAA
└ apexの制約
│
↓
現代の解決策
├ Anycast
├ CNAME Flattening
├ ALIAS / ANAME
├ Global Accelerator
├ Managed Custom Domains
└ HTTPS / SVCB
FastlyのAnycastも、CloudflareのCNAME Flatteningも、Approximatedのカスタムドメイン基盤も、一見するとまったく別のサービスです。しかし、その多くは同じ問題を違う場所で解決しています。古いDNSの名前解決モデルと、動的に変化する現代のクラウドをどう接続するかという問題です。
その背景が分かると、「apex対応」「Anycast 静的IPアドレス」「CNAME Flattening」といった一見無関係に見える用語がつながります。そして、www.example.com なら簡単なのに example.com になると料金表が変わる理由も、ベンダー都合ではなく、インターネットの設計上の事情として理解できるようになります。
残るのは、「ではDNSはなぜそう設計されたのか」という疑問です。apexにCNAMEを置けないという決まりは、いつ、どの文書が、何を考えて定めたものなのか。そこから先は、RFCそのものを読む話です。
参考情報
- RFC 1034 - Domain names - concepts and facilities
- RFC 1035 - Domain names - implementation and specification
- RFC 2181 - Clarifications to the DNS Specification
- RFC 4786 - Operation of Anycast Services
- JPNIC用語集 - ルーティング関連
- JPNIC用語集
- RFC 6066 - TLS Extensions: Extension Definitions (Server Name Indication)
- RFC 8555 - Automatic Certificate Management Environment (ACME)
- RFC 9460 - Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- RFC 9499 - DNS Terminology
- Cloudflare Docs - CNAME flattening
- Fastly Docs - Using Fastly with apex domains
- Fastly Docs - Serving HTTPS traffic using Fastly-managed certificates
- Amazon Route 53 - Choosing between alias and non-alias records
- AWS Global Accelerator - What is AWS Global Accelerator?
- AWS Global Accelerator - Pricing
- Approximated - Pricing
- SaaS Custom Domains
- SaaS Custom Domains - FAQ
- SaaS Custom Domains Docs - Custom domains guide