これまで多くの運営者は IPv6 を「そのうちやる」ことと捉えてきました。しかし IPv4 の賃借と購入の費用が上がり続けるなか、専用の IPv4 はますます個別に費用を払う希少な資源のようになり、IPv6 のアドレスはほぼその制約を受けません。2026 年、IPv6 への対応を真面目に整えることは、技術的な潔癖さではなく、実際の費用と到達性の問題になりました。

なぜ今動く価値があるのか

  • 費用の構造が変わっている：IPv4 が高くなるほど、「専用 IPv4 を何個も紐づける」という古いやり方は割に合わなくなります。IPv6 のアドレスは潤沢です。
  • 利用者側はとうに準備できている：主要な移動体通信と家庭向け回線は IPv6 を大量に配っており、IPv6 のみ、あるいは IPv6 優先の端末の割合は年々上がっています。
  • 到達性と体感：IPv6 を有効にしている利用者にとって、デュアルスタックは通信事業者級の NAT を一段減らせることが多く、経路がより直接になります。

勧められる進め方：切り替えではなくデュアルスタック

現時点で最も堅実な方針はデュアルスタックです。IPv4 と IPv6 を同時に残し、どちらからも到達できるようにします。IPv6 のみの配置は費用面では魅力的ですが、「IPv4 しかない第三者 API を呼べない」「一部の古い網の利用者が到達できない」といった現実の問題にすぐぶつかり、通常は変換用の入口を別に用意して補う必要があります。ほとんどの用途では、デュアルスタックが利益と危険の釣り合いが最も取れた選択です。

実際の手順

  • サーバーに IPv6 が割り当てられ、設定されているか確認する：ネットワーク機器がグローバルユニキャストのアドレスを得ているか、既定の経路が正しいか、外部の IPv6 アドレスへ ping が通るかを見ます。
  • DNS の AAAA レコードを補う：最も見落とされやすい一歩です。A レコードだけでは、IPv6 の利用者も結局 IPv4 を通ります。
  • サービスに本当に IPv6 を待ち受けさせる：Nginx には listen [::]:443 ssl; を明示的に加える必要があります。多くのアプリは既定で 0.0.0.0 にしか結び付かないため、デュアルスタックの待ち受けに変えて初めて有効になります。
  • ファイアウォールの規則を同期させる：これは最もよくあり、最も危険な落とし穴です。iptables の規則は自動的に IPv6 に適用されません。ip6tables を同時に設定する（あるいは nftables や ufw のデュアルスタック規則を使う）必要があり、さもないと丹念に整えた防御は IPv6 側では実質無いのと同じになります。
  • アプリケーション層の処理を点検する：IP の許可一覧、頻度制限、ログ分析、地理判定など、IP を基に動く機能はすべて、IPv6 形式のアドレスを正しく解釈できるか確認してください。

検証は自分の回線だけに頼らない

手元での確認が通っても、外から到達できるとは限りません。第三者のオンラインツールで IPv6 の接続性を確かめ、AAAA の解決、TLS の握手、ページの読み込みが IPv6 のみの環境で正常に動くことを確認してから公開してください。

SharkCloud の各地域のインスタンスは標準的なネットワーク設定と専用 IP の割り当てに対応しており、上記の手順でデュアルスタックを立ち上げられます。IPv4 の費用が上がる局面でも、事業の到達性と柔軟さを保てます。