AとAAAAレコードの違い｜IPv6だけサイトが開かないときの確認手順

先に答え：AAAAは「IPv6でも到達できる」と確認してから公開する

Aレコードはホスト名をIPv4アドレスへ、AAAAレコードはIPv6アドレスへ対応させます。同じ example.com に両方を設定する構成は一般的ですが、AAAAを置くなら、そのIPv6アドレスでWebサーバー・ファイアウォール・HTTPS証明書まで正常に応答できる必要があります。

「IPv6対応と書いてあったから」と未確認のアドレスをAAAAへ入れると、IPv6を使う回線だけ接続できない、読み込み開始が遅い、といった偏った障害が起こり得ます。Aが正しくてもAAAAの誤りは打ち消されません。

画像を拡大 ↗

AレコードとAAAAレコードの値と確認範囲を比較した図。閉じる ×

IPv6未対応の宛先へAAAAを公開しません。

上のアドレスは文書用の架空例です。実際の設定値はホスティング、CDN、ロードバランサー等の公式画面・資料から取得します。

Aが正しくても、AAAAの誤りで一部だけ失敗する

IPv4とIPv6の両方が利用できる端末は、名前解決結果と接続状態から到達方法を選びます。RFC 8305のHappy Eyeballsは、一方の経路が壊れているときの待ち時間を小さくするため、IPv6とIPv4の接続を適切な時間差で試す考え方です。ただし、すべてのOS・アプリ・ネットワークが同じ動きとは限らず、誤ったAAAAをAが必ず救うとは断定できません。

画像を拡大 ↗

利用端末がAAAAのIPv6候補とAのIPv4候補を使って接続する概念図。閉じる ×

Happy EyeballsがあってもAAAAの誤りを放置しません。

典型的な見え方は次のとおりです。

• 自宅Wi-Fiでは開くが、携帯回線では開かない。
• あるブラウザーでは開くが、監視やAPIクライアントが失敗する。
• 接続開始まで長く待ってから表示される。
• curl -4 は成功するが curl -6 は失敗する。
• トップは開くが、IPv6設定が違うサブドメインだけ失敗する。

まずDNSと接続を別々に確認する

DNSで返ることと、そのアドレスへ接続できることは別です。最初に現在の応答を記録し、次に各経路を分けて試します。

dig example.com A +short
dig example.com AAAA +short
curl -4 -I https://example.com/
curl -6 -I https://example.com/

dig や curl がない環境では、サーバー担当者またはホスティングの診断機能へ同じ確認を依頼します。curl -6 が失敗しても、利用している検査端末・ネットワーク自体にIPv6接続がなければサイト側の故障とは限りません。IPv6が使える別回線、サーバー側ログ、外部監視を組み合わせます。

画像を拡大 ↗

AとAAAAの障害をDNS、ネットワーク、HTTPS、アプリに分ける表。閉じる ×

DNSが返っても接続できるとは限りません。

1. 対象ホスト名のA・AAAAが何を返すか確認する。
2. その値が現在のサービスから指定された値と一致するか照合する。
3. IPv4とIPv6を分け、TCP 443へ到達できるか確認する。
4. HTTPSの証明書が対象ホスト名で有効か確認する。
5. WebサーバーまたはプロキシがIPv6でも待ち受けているか確認する。
6. IPv6側のファイアウォールやセキュリティグループを確認する。

AAAAを追加する前の条件

AAAAは「IPv6対応予定」を表す予約メモではありません。公開DNSに追加した時点で、利用者がそのIPv6アドレスへ接続し得ます。

画像を拡大 ↗

AAAA追加前にIPv6値、到達性、HTTPS、戻し方を確認する表。閉じる ×

AAAAは将来対応の予約メモではありません。

• サービス側が対象ホストのIPv6値を正式に案内している。
• IPv6アドレスが外部から到達可能で、必要なポートを待ち受けている。
• IPv6側にもA側と同じ公開内容が出る。
• HTTPS証明書がホスト名に対して有効で、更新も継続する。
• IPv6用のファイアウォール規則が確認できている。
• CDNやプロキシ利用時は、DNS画面に入れる値とプロキシ状態がサービス仕様どおりである。
• 障害時にAAAAを戻す手順と、変更前の値を保存している。

DNS事業者のプロキシ機能を有効にすると、公開DNSには事業者側のアドレスが返り、オリジンサーバーのアドレスと一致しないことがあります。Cloudflareの資料もA/AAAA作成時のIP値とは別に、proxied がプロキシ状態へ影響すると説明しています。見えているIPだけで誤設定と決めず、プロキシの有無を確認します。

切り替え・修正の手順

1. 現在のA・AAAA・CNAME、TTL、プロキシ状態を保存する。
2. 対象サービスの公式値と照合する。
3. IPv6到達性、HTTPS、主要ページ、フォームを事前確認する。
4. 必要なら変更前にTTLを短くする計画を立て、元のTTL期間を待つ。
5. AAAAを追加または修正する。
6. 権威DNSと複数の回線で新しい応答を確認する。
7. -4 と -6 を分け、HTTP状態・証明書・本文の接続先を確認する。
8. 問題がなければ監視を継続し、TTLを運用値へ戻す。

画像を拡大 ↗

DNSの控え、IPv6事前確認、AAAA変更、IPv4・IPv6別確認の順序。閉じる ×

プロキシ利用時は公開IPとオリジンIPを混同しません。

失敗したときの分岐

「とりあえずAAAAを削除」は、サービスがIPv4でも正式に提供されることを確認したうえでの一時切り分けです。IPv6専用サービスやプロキシ固有の構成では適切でないため、契約先の仕様を優先します。

そのまま使える調査依頼文

対象ホスト：https://example.com/
発生条件：携帯回線／Wi-Fi／特定地域／常時
発生日時（UTC）：2026-10-12 19:20
A応答：＿＿＿＿
AAAA応答：＿＿＿＿
権威ネームサーバー：＿＿＿＿
DNSプロキシ：なし／あり／不明
IPv4確認：HTTP状態＿＿＿／証明書＿＿＿
IPv6確認：HTTP状態＿＿＿／証明書＿＿＿
サーバーのIPv6対応根拠：管理画面／公式資料＿＿＿＿
直前の変更：＿＿＿＿
戻す値：＿＿＿＿

AとAAAAは「新旧の優先順位」ではなく、別々の到達経路です。どちらを公開する場合も、DNS、ネットワーク、TLS、アプリの全区間がその経路で動くことを確認します。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後の変更や障害確認をどこまで依頼できるかを先に確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。DNS、サーバー、WordPressの定期処理、HTTPヘッダー等は通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝え、対応範囲を確認してください。

関連記事

[DNSレコードの種類](/articles/dns-record-types-practical)・[DNSのTTLと切り替え準備](/articles/dns-ttl-before-server-move)・[HTTPS警告の見分け方](/articles/https-certificate-warning-check)