AAAAレコードを削除すると、そのホスト名はIPv6では到達できなくなり、利用者はIPv4（Aレコード）だけで接続するようになります。作業そのものは管理画面で1行消すだけですが、削除の前に「本当に消してよいか」「誰が自動で追加しているか」を確かめ、TTLを下げてから消すことで、切り替え中の不具合を最小限にできます。この記事では、削除の判断から、削除後に正しく消えたことを確かめるまでの手順を順に説明します。
AAAAレコードを削除するのはどんなときか
削除が検討されるのは、主に次のような場面です。
- サーバーのIPv6が正しく動いておらず、一部の利用者だけサイトが開けない、遅い
- サーバーを移転し、新しいサーバーにはIPv6アドレスが無い
- Let's Encrypt の証明書の更新が、IPv6側の不具合で失敗している
- 以前のサーバーのIPv6アドレスがAAAAに残ったままになっている
IPv6の不具合は気付きにくいのが特徴です。多くのブラウザは「Happy Eyeballs」と呼ばれる仕組みでIPv6とIPv4を並行して試し、つながる方を使うため、IPv6が壊れていても表示が少し遅くなるだけで済むことがあります。一方、APIを呼び出すプログラムや証明書の認証局、監視サービスなどはIPv6を優先して試し、失敗として扱うことがあります。Let's Encrypt はAAAAがある場合にIPv6で検証を試みるため、IPv6側の待ち受けが壊れていると更新に失敗する事例がよく報告されています。
ただし、IPv6が動かない原因がサーバー側の設定（ファイアウォールやWebサーバーの待ち受け設定）にあるなら、AAAAを消すより直す方が長期的には望ましい場合もあります。削除は「IPv6で提供しない」と決めたときの手段と考えてください。
手順1：今のAAAAと、その出どころを確かめる
まず、どの名前にAAAAがあるかを確認します。ドメインの頂点と www は別々のレコードなので、両方を見ます。
dig example.com AAAA +short
dig www.example.com AAAA +short
# 権威サーバーに直接問い合わせ、TTLも確認する
dig example.com NS +short
dig @ns1.your-dns.example example.com AAAA +norec次に、そのAAAAが自分で書いたものか、サービスが自動で返しているものかを見分けます。ここを取り違えると「消したのに残っている」状態になります。
- CDN（Cloudflare のプロキシなど）を経由している場合、DNSが返すAAAAはCDNのアドレスで、利用者とCDNの間をIPv6でつなぐかどうかはCDN側の設定で決まります。自分で書いた原本サーバー用のAAAAを消しても、CDNのAAAAは返り続けることがあります。CDN側でIPv6を止められるかどうか、どの画面で変えるかはサービスやプランによって異なるため、各サービスのドキュメントで確認してください。
- ALIAS・ANAME やCNAMEで外部のホスト名を参照している場合、AAAAは参照先が返しているものです。自分のゾーンに消すべきAAAAはありません。
- レンタルサーバーの中には、ドメインを追加するとAAAAを自動で作るものがあります。消しても管理画面の操作で再作成されることがあるので、IPv6の利用を止める設定が別にあるかを確認します。
手順2：ゾーンを控えてから、TTLを下げる
削除の前に、ゾーンのエクスポートか画面の控えを取っておきます。消したレコードを戻すときに、正確なアドレスとTTLが必要になるためです。
続いて、削除するAAAAのTTLを短く（たとえば300秒）します。キャッシュDNSは、レコードを受け取った時点のTTLの間はその値を使い続けます。TTLが86400秒（1日）のまま消すと、最長1日は古いAAAAを見て接続を試みる利用者が残ります。TTLを下げたら、元のTTLの時間が過ぎるまで待ってから削除に進みます。
すでにIPv6で障害が起きていて急ぐ場合は、TTLを下げる待ち時間を取らずに削除してもかまいません。その場合は、元のTTLの時間が過ぎるまで影響が残ることを前提に、手順4の確認を続けます。
手順3：AAAAレコードを削除する
管理画面で対象のAAAAを選んで削除します。頂点と www など、複数の名前にある場合はそれぞれ削除します。同じ名前に複数のAAAAがある場合は、消したいアドレスだけを選んでいるかを確認してください。
Amazon Route 53 をコマンドで操作する場合、削除（DELETE）は名前・タイプ・TTL・値がすべて現在のレコードと一致している必要があります。手順1で確認した値をそのまま使います。
{
"Changes": [{
"Action": "DELETE",
"ResourceRecordSet": {
"Name": "example.com.",
"Type": "AAAA",
"TTL": 300,
"ResourceRecords": [{ "Value": "2001:db8::10" }]
}
}]
}aws route53 change-resource-record-sets \
--hosted-zone-id ZXXXXXXXXXXXXX \
--change-batch file://delete-aaaa.jsonBIND などで自分でゾーンファイルを管理している場合は、該当行を削除し、SOAのシリアル番号を増やしてから構文を確かめ、読み込み直します。シリアルを増やし忘れると、セカンダリサーバーに変更が伝わりません。
named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com手順4：削除されたことを確かめる
まず権威サーバーに直接問い合わせ、AAAAが返らないことを確かめます。NSが複数ある場合は、すべてのサーバーで確認します。
for ns in $(dig example.com NS +short); do
echo "== $ns"; dig @$ns example.com AAAA +norec | grep -E "status:|^example\.com\..*AAAA"
done正しく削除されていれば、status: NOERROR で回答（ANSWER）が0件になります。これは「名前は存在するがAAAAは無い」という意味の正常な応答です。NXDOMAIN が返る場合は、名前そのものが無くなっているので、Aレコードまで消していないかを確認してください。
次に公開DNSで確認します。古いAAAAがキャッシュに残っている場合、TTLの値が少しずつ減っていく様子が見えます。0になれば新しい応答に切り替わります。
dig example.com AAAA @1.1.1.1
dig example.com AAAA @8.8.8.8なお、削除後に「AAAAは無い」という応答もキャッシュされます。この否定応答の保持時間はSOAレコードの値で決まるため、後でAAAAを追加し直す場合は、すぐには反映されないことがあります。
手順5：サーバー側とサービスの動作を確かめる
DNSからAAAAを消しても、サーバーのIPv6アドレスやWebサーバーのIPv6の待ち受けは残ったままです。すぐに止める必要はなく、古いキャッシュを持つ利用者のために、TTLの時間が過ぎるまでは残しておく方が安全です。その後、使わないと決めたらファイアウォールやWebサーバーの設定を整理します。
証明書は、削除後にテスト更新を実行して、IPv4で検証が通ることを確かめます。
sudo certbot renew --dry-runメールサーバーが同じホストにある場合は注意が必要です。AAAAを消しても、送信時にサーバーがIPv6を使う設定のままだと、IPv6の送信元アドレスで相手に接続し、逆引き（PTR）の不一致で受信を拒否されることがあります。Postfix であれば inet_protocols の設定で使うプロトコルを確認します。
WordPressでは、サイトヘルスのループバック接続の確認や WP-Cron が、サーバー自身から自分のサイトへHTTP接続します。サーバーのDNSキャッシュに古いAAAAが残っているとこの接続が失敗することがあるので、削除後にサイトヘルスの画面で問題が出ていないかを確認してください。
切り戻しが必要になったとき
削除後にIPv6でのアクセスが必要だと分かった場合は、控えておいたアドレスで同じ名前のAAAAを再登録します。前述の否定応答のキャッシュが切れるまでは、一部の利用者にAAAAが見えない時間が残ります。DNSサービスの画面やTTLの扱いは（2026年10月現在）サービスごとに異なるため、急ぐ作業の前には利用中のサービスの説明を確認しておくと落ち着いて対応できます。
まとめ
- AAAAの削除は「IPv6で提供しない」と決めたときの手段。IPv6の不具合はサーバー側を直す選択肢もある
- 消す前に、CDN・ALIAS・レンタルサーバーの自動設定など、AAAAの出どころを確かめる
- ゾーンを控え、TTLを下げて待ってから削除すると切り替え中の影響が小さい
- 削除後は全権威サーバーで
NOERRORかつ回答0件になることを確認し、公開DNSのTTLの減り方を見る - サーバーのIPv6はしばらく残し、証明書の更新・メール送信・WordPressのループバック接続を確かめる