Anycast は「同じIPアドレスを複数の拠点から広告する」仕組みなので、通常のネットワークなら異常とされる状態を意図的に作っています。そのため、競合が起きたときは「意図した重複」と「意図しない衝突」を分けることが解消の近道です。この記事では、Anycast で起きる競合を、経路（BGP）の衝突、拠点内のIP重複（ARP）、拠点間の応答の不整合、セッションの途切れの4種類に分け、それぞれの確認方法と対処を説明します。
Anycast の競合とは何か
通常のユニキャストでは、1つのアドレスは1台の機器だけが持ちます。Anycast では、同じアドレス（多くは同じプレフィックス）を複数の拠点が BGP で広告し、利用者はネットワーク上で最も近い（経路の評価が最も良い）拠点に届きます。DNS のルートサーバーやパブリックDNS、CDN などで使われている方式です。
この仕組みでは「複数の場所に同じアドレスがある」こと自体は正常です。問題になるのは次のような状態です。
- 経路の衝突：想定していない AS からも同じプレフィックスが広告されている、または自分の拠点の広告が上流で無効と判定されている。
- 拠点内のIP重複：Anycast 用のアドレスを複数のサーバーに設定した結果、同じセグメント内で ARP の応答が競合している。
- 拠点間の不整合：拠点ごとに返す内容（DNS のゾーン、証明書、アプリのバージョン）が違い、利用者によって結果が変わる。
- 経路の切り替わりによる途切れ：経路が変わって通信の途中で別の拠点に届き、TCP のセッションが切れる。
症状を見て、どの種類に当たるかを先に判断します。
まず確認すること：どの拠点が応答しているか
Anycast のトラブルでは「自分のアクセスがどの拠点に届いているか」を知ることが出発点です。拠点ごとに識別できる情報を返す仕組みを用意しておくと、切り分けが格段に楽になります。
DNS の場合は、多くのサーバーソフトが対応している NSID や、id.server・hostname.bind といった問い合わせで、応答したサーバーを識別できます（応答するかどうかはサーバーの設定次第です）。
# NSID を要求して、応答したサーバーの識別子を見る
dig @192.0.2.53 example.com +nsid
# CHAOS クラスで識別子を問い合わせる
dig @192.0.2.53 id.server CH TXT
dig @192.0.2.53 hostname.bind CH TXTHTTP の場合は、各拠点のWebサーバーやロードバランサーで、拠点名をレスポンスヘッダーに付けておくと確認しやすくなります。
curl -sI https://example.com/ | grep -i x-served-byここでの x-served-by は自分で付ける独自ヘッダーの例です。Nginx なら add_header X-Served-By tokyo-1 always; のように拠点ごとに値を変えて設定します。自分の手元だけでなく、複数の地域から確認したい場合は、RIPE Atlas のような計測基盤や、通信事業者が公開している Looking Glass を使う方法があります。
競合1：経路の衝突（BGP・RPKI）
症状
特定の地域や事業者からだけ届かない、想定外の拠点に流れる、自分の管理していない場所に流れている疑いがある、といった症状です。
確認
まず、自分の拠点のルーターで、広告しているはずのプレフィックスが実際に送られているかを確認します。FRRouting を使っている場合の例です。
sudo vtysh -c "show bgp ipv4 unicast 198.51.100.0/24"
sudo vtysh -c "show bgp neighbors 203.0.113.1 advertised-routes"次に、外部からその経路がどう見えているかを確認します。公開されている BGP の観測サービスや Looking Glass で、プレフィックスを広告している 送信元 AS（オリジンAS） の一覧を見ます。自分の AS 以外がオリジンとして現れている場合は、設定ミスや経路のハイジャックの可能性があります。
RPKI を使っている場合は、ROA（どの AS がそのプレフィックスを広告してよいかの登録）と実際の広告が一致しているかが重要です。Routinator などの検証ソフトや、RIR の管理画面で、プレフィックスとオリジンAS、最大プレフィックス長の組み合わせを確認します。
対処
- 新しい拠点を別の AS から出したら届かない：ROA にその AS が含まれていないと、RPKI で検証している上流では「無効」として捨てられます。ROA にオリジンAS を追加してから広告を始めます。
- より細かいプレフィックスを広告したら届かない：ROA の最大プレフィックス長より細かい経路は無効になります。必要な長さに合わせて ROA を見直します。また /24 より細かい IPv4 経路（IPv6 では /48 より細かい経路）は、多くの事業者で受け付けられません。
- IRR の登録が古い：上流がIRR の情報で経路フィルターを作っている場合、route オブジェクトの登録漏れで受け付けられないことがあります。
- 他者が同じプレフィックスを広告している：自分の上流事業者に連絡し、状況を共有します。ROA を正しく登録しておくことが、RPKI で検証しているネットワークでの影響を抑える備えになります。
ROA や IRR の変更が世界中に反映されるまでには時間がかかります。広告の開始・変更は、登録を済ませて反映を待ってから行うのが安全です。
競合2：拠点内のIP重複（ARP の競合）
症状
同じ拠点の中で、複数のサーバーに Anycast 用のアドレスを持たせてロードバランサーや ECMP で振り分けている構成で、通信が特定のサーバーに偏る、断続的に切れる、といった症状です。
原因と確認
Anycast 用のアドレスを通常のインターフェース（eth0 など）に設定すると、同じセグメント内の複数のサーバーが「そのアドレスは自分です」と ARP に応答し、アドレス重複と同じ状態になります。ルーター側の ARP テーブルが応答のたびに書き換わり、通信先が揺れます。
# 同じアドレスに複数の MAC アドレスが応答していないか（重複検出モード）
sudo arping -D -I eth0 -c 3 198.51.100.10対処
Anycast 用のアドレスはループバックインターフェース（lo）に設定し、ARP に応答しないようにカーネルのパラメーターを調整するのが一般的な方法です。
# Anycast 用アドレスをループバックに付ける
sudo ip addr add 198.51.100.10/32 dev lo
# 自分の受信インターフェースに設定されたアドレス以外の ARP 要求に応答しない
sudo sysctl -w net.ipv4.conf.all.arp_ignore=1
# ARP 送信時に、送信インターフェースのアドレスを優先して使う
sudo sysctl -w net.ipv4.conf.all.arp_announce=2sysctl の値は再起動で元に戻るため、問題がないことを確認したら /etc/sysctl.d/ 配下の設定ファイルに書いて永続化します。設定を変える前に、現在の値を sysctl net.ipv4.conf.all.arp_ignore などで控えておき、遠隔のサーバーでは作業中に接続が切れても復旧できる手段（コンソール接続など）を確保してから行ってください。
競合3：拠点間の応答の不整合
症状
「ある人には新しいページが見え、別の人には古いページが見える」「一部の地域だけ DNS の応答が古い」など、利用者によって結果が変わる症状です。
確認と対処
前述の方法でどの拠点が応答したかを特定し、拠点ごとの状態を比べます。DNS なら、各拠点のゾーンのシリアル番号を確認します。
# ANSWER の SOA レコードのシリアル番号と、OPT 部分の NSID を見比べる
dig @192.0.2.53 example.com SOA +nsidシリアル番号が拠点によって違う場合は、ゾーン転送（AXFR/IXFR）や配布の仕組みが特定の拠点で止まっています。Web なら、デプロイの仕組みがすべての拠点に反映されたかを確認します。拠点ごとに証明書を置いている場合は、更新漏れがあると一部の地域だけ証明書エラーになるため、証明書の配布も同じ仕組みで管理します。
競合4：経路の切り替わりによるセッションの途切れ
Anycast では、経路の変化によって同じ利用者の通信が途中から別の拠点に届くことがあります。UDP で1往復が完結する DNS ではほぼ問題になりませんが、TCP で長く続く通信（大きなファイルのダウンロード、WebSocket など）では、別の拠点はそのセッションを知らないため接続が切れます。
対処としては、次のような考え方があります。
- 拠点のヘルスチェックが不安定で、広告の取り下げと再開を繰り返していないか（経路のフラップ）を確認し、判定の閾値や待ち時間を調整します。
- 長時間のセッションが必要な通信は、Anycast で入口だけを受け、その後はユニキャストのアドレスに誘導する設計を検討します。
- 拠点内で ECMP を使う場合は、同じ通信が同じサーバーに届くよう、ハッシュによる振り分けの設定を確認します。
作業前の備え
Anycast の設定変更は、影響が広い範囲に及びます。変更の前に、ルーター設定のバックアップ、変更前の経路の状態の記録、切り戻し手順の確認を済ませておきます。新しい拠点の追加は、まず小さな範囲（特定の上流だけ、あるいは経路の優先度を下げた状態）で広告し、応答する拠点と通信の状態を確認してから広げると、問題が起きたときの影響を抑えられます。RPKI や各事業者の経路フィルターの運用は変わっていくため、上流事業者の最新の案内も確認してください（2026年10月現在）。
まとめ
- Anycast では同じアドレスが複数拠点にあるのは正常で、問題は「意図しない衝突」です。症状から4種類に分けて考えます。
- まず NSID や独自ヘッダーで、どの拠点が応答しているかを特定します。
- 経路の衝突は、オリジンAS・ROA・最大プレフィックス長・IRR 登録の食い違いを確認します。
- 拠点内の IP 重複は、Anycast アドレスをループバックに置き、arp_ignore と arp_announce で ARP の応答を抑えます。
- 拠点間の不整合はゾーンのシリアルやデプロイの反映状況で、セッションの途切れは経路のフラップやヘルスチェックの設定で確認します。