CDNが案内するIPアドレスが世界中の拠点へ届くAnycastの仕組み

Last updated at 2026-08-24Posted at 2026-08-17

CDNやホスティングを使うとき、ドメインの設定として「このIPアドレスをAレコードに入れてください」と案内されます。

たとえば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

Fastlyの場合は、契約時にアドレスの一覧が渡されます。

We'll provide you with a list of anycast IP addresses, which you then enter into your DNS records.

anycast IPアドレスの一覧をこちらから提供するので、それをDNSレコードへ入力する。

同じページは、渡されたアドレスをすべて登録するよう求めています。

Be sure to enter all of them to ensure maximum availability and reliability.

可用性と信頼性を最大にするため、必ずすべてを入力すること。

そのとおりに設定すると、サイトは世界中から見えるようになります。日本、アメリカ、ヨーロッパのどこから開いても表示され、しかも速く表示されます。

ここで疑問が出てきます。設定したIPアドレスは、多くても数個です。CDNのサーバーは世界中にあるはずなのに、なぜこれだけで足りるのか。遠い国からアクセスしても遅くならないのはなぜか。

その答えがAnycastです。Fastlyの案内文にもこの語が出ています。Anycastは、同じIPアドレスを世界中の複数の場所から使う仕組みです。設定するIPアドレスが1つでも、その先には東京・ロンドン・ニューヨークといった拠点がいくつもあります。どの拠点へ届くかは、インターネットの経路制御が決めます。

Anycastとよく一緒に出てくるのが固定IPです。こちらは「IPアドレスが変わらない」という意味で、Anycastとは別の話をしています。片方はアドレスが変わるかどうか、もう片方はそのアドレスを何拠点で使うかという話で、そもそも見ている対象が違います。どちらも「IPアドレスの話」に見えるので混ざりやすくなっています。

この2つを分けて理解すると、CloudflareやFastlyのようなCDN、AWS Global Accelerator、apexドメイン向けのAレコードといった話が1つにつながります。まずはIPアドレスと固定IPから順に見ます。

IPアドレスとDNSの対応付け

インターネット上でコンピューター同士が通信するには、相手の場所を示す番号が必要です。その番号がIPアドレスです。たとえばWebサーバーに 203.0.113.10 というIPv4アドレスが割り当てられているとします。

DNSは、ドメイン名とIPアドレスの対応付けを担います。この対応付けに使う代表的なDNSレコードがAレコードです。

example.com  A  203.0.113.10

ブラウザーはDNSからIPアドレスを受け取り、そのIPアドレスへ接続します。ここまでは昔ながらのWebサーバーでも現代のクラウドでも変わりません。

固定IPの定義

固定IPは、一定期間変わらないIPアドレスです。サーバーAに 203.0.113.10 を割り当て、再起動しても翌日になってもこのアドレスが変わらなければ固定IPと呼べます。会社の代表電話番号に近く、担当者が変わっても番号は変わりません。

Webサービス
  ↓
203.0.113.10

安定した入口を用意するのが固定IPです。ただし、固定IPであることと、サーバーが世界中に分散していることは別の話です。

固定IPだけでは解決しない遅延と単一障害点

東京に1台だけサーバーを置き、固定IPとして 203.0.113.10 を割り当てたとします。日本の利用者から見れば問題ありません。しかしニューヨークの利用者もロンドンの利用者も、同じ東京のサーバーまで通信します。

東京の利用者 ──────┐
                   │
ロンドンの利用者 ──┼→ 東京のサーバー
                   │
NYの利用者 ────────┘

距離が遠ければ、そのぶん通信の遅延も大きくなります。さらに、この東京サーバーや東京のネットワークに障害が起きれば、世界中の利用者がアクセスできなくなります。固定IPには「住所が変わらない」という利点はありますが、「最寄りのサーバーへ案内する」機能はありません。そこで使われるのがAnycastです。

Anycastの定義

Anycastでは、同じIPアドレスを世界中の複数拠点からインターネットへ知らせます。たとえば 203.0.113.10 という同じIPアドレスを、東京、シンガポール、ロンドン、ニューヨークの各拠点から知らせます。

この「知らせる」動作を、ネットワークの分野では経路広告と呼びます。英語の advertise の訳語で、宣伝という意味ではありません。JPNICの用語集は次のように定義しています。

ルータが保持している経路情報を、他のルータに知らせることをいいます。

以降でも、この意味で「広告する」を使います。

                  東京
                   ↑
                   │
シンガポール ← 203.0.113.10 → ニューヨーク
                   │
                   ↓
                ロンドン

利用者から見ると、接続先はどこからでも 203.0.113.10 で同じです。しかし実際の通信は、ネットワーク上で選ばれた拠点へ届きます。東京の利用者は東京へ、ヨーロッパの利用者はロンドンへ、という構成が可能になります。

同じIPアドレスが別の拠点へ届く仕組み

通常は「1つのIPアドレス = 1つの場所」と考えたくなります。しかしインターネットでは、IPアドレスそのものに緯度・経度が記録されているわけではありません。インターネット上のルーターは「このIPアドレスへ行くには、どの方向へパケットを送ればよいか」という経路情報を持っています。この経路情報をネットワーク同士で交換する代表的な仕組みがBGPです。

Anycastでは、東京・ロンドン・ニューヨークといった複数の拠点が、同時に次の内容を広告します。

203.0.113.10 は、こちらから到達できます

するとインターネット上のルーターが、BGPの経路選択に従って経路を決めます。重要なのは、必ずしも物理的に最も近い拠点が選ばれるわけではないことです。Anycastはよく「最寄りの拠点へ接続される」と説明されますが、より正確にはBGP上で選ばれた経路の拠点へ接続されると考える必要があります。地理的距離だけでなく、ネットワーク事業者同士の接続関係やBGPポリシーによっても経路は変わります。

固定IPとAnycastが指している対象の違い

ここまで来ると、「固定IPとAnycastのどちらを使うか」という二者択一ではないことが分かります。固定IPは「そのIPアドレスが変わるか」という話で、Anycastは「そのIPアドレスを何拠点から広告するか」という話です。したがって、次の組み合わせが成立します。

構成	固定IP	Anycast
1台のサーバーに固定IP	あり	なし
クラウドVMの動的IP	なし	なし
CDNのAnycast 静的IPアドレス	あり	あり

Cloudflare、Fastly、AWS Global Acceleratorなどの文脈で重要なのは、3番目のAnycast 静的IPアドレスです。利用者から見ればIPアドレスは変わりませんが、そのIPアドレスの裏側には複数の拠点があります。

この組み合わせの呼び方は事業者ごとに違います。Fastlyは単に anycast IP addresses と呼びます。AWS Global Acceleratorは「静的IPアドレス」と呼んだうえで、それがAWSエッジネットワークからanycastされると説明します。Amazon CloudFrontは Anycast Static IPs (日本語版では「エニーキャスト静的 IP」) という機能名を持っています。本記事では、3社に共通する性質を指す語としてAnycast 静的IPアドレスを使います。

Unicastとの違い

一般的なIP通信はUnicastです。Unicastでは、1つのIPアドレスが1つの宛先に対応します。

203.0.113.10
    ↓
東京のサーバー

一方、Anycastでは同じIPアドレスが複数の拠点に対応します。

203.0.113.10
    ├→ 東京
    ├→ シンガポール
    ├→ ロンドン
    └→ ニューヨーク

どちらも利用者は同じようにIPアドレスへアクセスします。違うのはネットワーク側の経路制御です。

CDNでAnycastが使われる理由

CDNは世界中の利用者へ高速かつ安定してコンテンツを配信するため、Anycastと相性がよい仕組みです。CloudflareやFastlyも、この構成を前提にしています。たとえばCDNが 198.51.100.20 というAnycast 静的IPアドレスを提供しているとします。顧客はDNSに次の1行を設定します。

example.com A 198.51.100.20

利用者は全員同じIPアドレスへアクセスしますが、実際の接続先は地域ごとに分散します。

日本の利用者
    ↓
東京Edge

ヨーロッパの利用者
    ↓
欧州Edge

米国の利用者
    ↓
米国Edge

DNS設定を地域ごとに変える必要はありません。これは運用上の大きな利点です。

経路広告の停止によるフェイルオーバー

Anycastは高速化だけでなく、可用性にも役立ちます。たとえば東京と大阪の両方から同じIPアドレスを広告しているとします。通常は東京へ通信が流れていたとしても、東京側がその経路の広告を停止すれば、別の経路が選ばれるように構成できます。

通常                障害時

利用者              利用者
  ↓                   ↓
東京                大阪
  ↓                   ↓
203.0.113.10        203.0.113.10

DNSのAレコードは変更していません。利用者が接続するIPアドレスも同じです。ネットワークの経路だけが変わっています。この性質が、CDNやグローバルロードバランサーでAnycastが使われる理由の1つです。

ただし、この切り替えが変えるのは新しく発生する接続の到達先です。切り替え時点で東京側と確立済みだったTCPコネクションは、拠点間でセッション状態が共有されない限り、経路が変わった時点で継続できません。Anycastは新規接続の到達先を切り替える仕組みであり、確立済みのセッションを別拠点へ引き継ぐ仕組みではありません。WebSocketや大きなファイルのダウンロードのように接続が長時間続く通信では、この点が問題になります。

DNSによる地理的振り分けとの違い

世界中のサーバーへ振り分けるだけなら、DNSでも実現できます。たとえば日本から問い合わせると 203.0.113.10 を返し、米国から問い合わせると 198.51.100.20 を返す方法です。これも有効な仕組みですが、Anycastとは振り分ける場所が違います。

DNS方式

DNS問い合わせ
    ↓
利用するIPを決める
    ↓
そのIPへ接続

Anycast

同じIPへ接続
    ↓
インターネットの経路制御で拠点が決まる

Anycastでは、DNSから見ると全世界で同じIPアドレスを返す構成も可能です。

Anycastが最短経路を保証しない理由

Anycastを使えば必ず一番近いサーバーへつながる、と考えるのは誤りです。BGPがWebサイトの応答速度を直接測定して経路を選んでいるわけではないからです。ネットワークの経路ポリシーによっては、東京の利用者なのに大阪へ届いたり、地理的には近くない別の地域へ届いたりします。

そのため大規模CDN事業者は、Anycast IPを用意するだけでなく、世界中のISPとの接続、ピアリング、トランジット、BGP設計を含めてネットワークを最適化しています。Anycastは、それ自体で完結する技術ではなく、大規模なネットワーク運用の上に成り立っています。

Anycast 静的IPアドレスの価値

固定IPには「同じ住所を使い続けられる」という利点があり、Anycastには「同じ住所を世界中に配置できる」という利点があります。Anycast 静的IPアドレスは、この2つを同時に実現します。

変わらない1つのIPアドレス
        +
世界中の複数拠点

この組み合わせが必要になるのは、DNSでAレコードを指定しなければならない場合です。

example.com
    ↓ A
Anycast 静的IPアドレス
    ↓
世界中のEdge

顧客はAレコードを一度設定すればよく、その裏側のサーバー構成や障害対策、拠点追加はサービス提供者側で変更できます。

AWS Global Acceleratorの位置づけ

AWS Global Acceleratorも、Anycastの観点で見ると構造は単純です。既定では、独立した2つのネットワークゾーンから1つずつ、合計2つの静的IPアドレスが割り当てられ、これがAWSエッジネットワークからanycastされます。

そのIPアドレスはAWSのグローバルネットワーク上の複数拠点から到達でき、そこからAWSのネットワークを通ってALB、EC2、ECSなどのリソースへ転送されます。

利用者
  ↓
AWSのAnycast 静的IPアドレス
  ↓
AWSのグローバルネットワーク
  ↓
ALB / EC2 / ECS など

Global Acceleratorの役割の1つは、変わらないグローバルな入口を提供することです。CDNそのものではありませんが、ネットワーク入口という観点ではCDNのAnycast IPと共通する部分があります。

apexでAレコードしか使えない理由

Anycastが必要になる理由は、DNSの仕様から順に導けます。ここでは3つの仕様を前提として置き、そこから一歩ずつ進みます。

前提1: RFC 1034の3.6.2節は、CNAMEがある名前に他のデータを置けないと定めています。

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

あるノードにCNAME RRが存在する場合、他のデータを置くべきではない。これにより、canonical nameとその別名でデータが異なる事態を防げる。

前提2: RFC 2181の6.1節は、SOAとNSがすべてのゾーンで必須であり、それらがゾーンのorigin (= apex) に置かれると定めています。

前提3: DNSのAレコードが保持するのは、IPアドレスの値そのものです。名前ではありません。

ここから導きます。

前提1と前提2より、
apexにはSOAとNSがあるため、CNAMEを置けない。
        ↓
apexで使えるのはAレコードだけになる。
        ↓
前提3より、apexのゾーンにはIPアドレスの値が直接書かれる。
        ↓
そのゾーンを書き換えられるのは顧客だけである。
        ↓
CDN事業者は、いったん顧客へ渡したIPアドレスを変更できない。

サブドメインと比べると差がはっきりします。www.example.com であればCNAMEを使えます。

www.example.com
    ↓ CNAME
customer.example.cdn-provider.example
    ↓ A
198.51.100.20     ← この値はCDN事業者のゾーンにある

顧客のゾーンに書かれているのは名前だけです。IPアドレスの値はCDN事業者のゾーンにあるため、CDN事業者はいつでも変更できます。

apexではこれができません。

example.com
    ↓ A
198.51.100.20     ← この値は顧客のゾーンにある

値を固定したまま、指す先を変える仕組み

前節の導出は、次の状態で止まっています。

apexに書いたIPアドレスの値は、CDN事業者が変更できない。

ここで選択肢が2つに分かれます。

1つは、値そのものを問い合わせのたびに決め直す方向です。権威サーバー側で名前を解決し、その結果をAレコードとして返します。CloudflareのCNAME Flatteningがこれにあたります。ただしこの方法は、顧客のゾーンを自社の権威DNSで管理できる場合にしか使えません。名前を解決するのは、apexへの問い合わせを受ける権威サーバーだからです。

もう1つが、値は固定したまま、その値が指す先をネットワーク側で変える方向です。ここでAnycastが必要になります。

IPアドレスの値は変えられない。
        ↓
ならば、値を変える必要がない状態にすればよい。
        ↓
1つのIPアドレスが、世界中の複数拠点に対応していればよい。
        ↓
それがAnycastである。

Fastlyがapex向けに提供しているのはこの方式です。顧客のゾーンには、変わらない1つのIPアドレスが書かれます。

example.com
    ↓ A
Anycast 静的IPアドレス    ← 顧客のゾーンにある。変わらない
    ↓ BGPの経路選択
東京 / ロンドン / ニューヨーク ...   ← Fastly側が自由に増減できる

拠点を追加しても、拠点を撤去しても、障害時に経路広告を止めても、顧客のゾーンに書かれた値は1文字も変わりません。変更の自由度を、DNSの層からネットワークの層へ移したことになります。

CloudflareとFastlyの対処の比較

同じ制約に対する2つの対処を並べます。

	CloudflareのCNAME Flattening	FastlyのAnycast 静的IPアドレス
顧客のゾーンに書かれる値	問い合わせのたびに変わりうる	固定
変更の自由度がある層	DNS (応答の内容)	ネットワーク (経路制御)
必要な条件	顧客のDNSが自社であること	特になし
顧客のDNS事業者	選べる場合に限る	どこでもよい

前提1と前提2は、どちらの対処でも破っていません。CNAME Flatteningは応答にCNAMEを入れないことで、Anycastはそもそも普通のAレコードを使うことで、制約の内側に収まっています。

そして最後の行が、SaaSのカスタムドメインで問題になります。顧客のDNS事業者を選べない場合、選択肢はAnycast 静的IPアドレスの側だけになります。

まとめ

冒頭の疑問は、CDNが案内するわずかなIPアドレスで、なぜ世界中から速く届くのか、でした。

答えはAnycastです。1つのIPアドレスを世界中の拠点から経路広告し、どの拠点へ届くかをインターネットの経路制御に委ねます。利用者から見えるアドレスは変わらないまま、その先の拠点は増やせますし、障害時には経路広告を止めて別拠点へ寄せられます。

example.com
    ↓ A
1つのIPアドレス            ← 顧客のゾーンに書かれる。変わらない
    ↓ BGPの経路選択
東京 / ロンドン / ニューヨーク ...   ← CDN側が自由に増減できる

この性質が、apexドメインで必要になります。apexにはSOAとNSがあるためCNAMEを置けず、Aレコードしか使えません。Aレコードに書いた値は顧客のゾーンにあり、CDN事業者が書き換えられません。**値を変えられないなら、値を変える必要がない状態にすればよい。**その状態がAnycastです。

同じ制約に対して、CloudflareはDNSの応答内容を問い合わせのたびに決める方向へ進みました。FastlyはIPアドレスを固定したまま、ネットワークの経路制御で吸収する方向へ進みました。前者は顧客のDNSを自社で管理できる場合に限られ、後者は顧客のDNS事業者を問いません。

本記事では、apexでAレコードを使わざるをえない理由を前提1と前提2から導きました。もう1つの対処であるCNAME Flatteningが、なぜ仕様に反さず成立するのかは、応答の中身を規定する仕様まで踏み込むと分かります。次はそこを扱います。

参考情報

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up