Googleの計測でユーザーのIPv6利用率がついに50%を超えました。長らく緩やかだったIPv6移行が節目を迎えた今、Webエンジニアやインフラエンジニアが何を理解し、実務でどこに気を配るべきかを、現状データと技術ポイントの両面から整理します。

GoogleユーザーのIPv6利用率が50%を超えた

Googleは2008年から、検索・YouTube・Gmailといった自社サービスの利用者がIPv6でアクセスしている割合を継続的に計測してきました。その計測値が、2026年3月28日に初めて50%を突破し、約50.10%を記録しました。その後も水準は維持され、2026年6月13日には約50.29%に達しています。前年の2025年3月時点は約46.33%だったことを踏まえると、単月の変動はあるものの、長期的には安定して増加してきたことがわかります。

推移をおおまかに振り返ると、5%前後だったのが2014年頃、20%前後が2018年頃、30%前後が2020年頃です。18年ほどの時間をかけて、ついにネイティブなIPv6接続が多数派に届いたことになります。

ただし、IPv6利用率は計測手法によって数値が変わる点に注意が必要です。Cloudflare Radarの計測では約40.1%、APNICが世界全体を対象にした計測では約42%とされています。APNICはGoogle広告経由で測定スクリプトを配信し、母集団に重み付けをするなど、Googleとは異なる方法を採っています。どの数値も正しいものの、母集団と測定方法が違うため、比較する際は前提をそろえて読むことが大切です。

国別の温度差も大きく、フランス・ドイツ・インドなどはすでに過半がIPv6であるのに対し、米国・ブラジル・日本は約50%前後で推移しています。地域やISPの整備状況によって普及ペースが異なることが読み取れます。

なぜ今IPv6なのか、IPv4との違いを整理する

IPv6移行が進む根本の要因は、IPv4アドレスの枯渇です。IPv4はアドレス長が32ビットで、表現できるアドレスは約43億にとどまります。世界中の端末が常時ネットワークにつながる時代には、この数は明らかに足りません。一方でIPv6は128ビットあり、理論上のアドレス数は約3.4×10の38乗という桁違いの広さを持ちます。

IPv6のおもな特徴として、広大なアドレス空間のほか、NATを介さないエンドツーエンド通信、SLAACによるアドレスの自動設定、ヘッダの簡素化、IPsecを前提に据えた設計などが挙げられます。アドレスが潤沢なため、IPv4で一般的だったアドレス変換の仕組みに頼らずに済むのが大きな違いです。

注意すべきは、IPv4とIPv6には互換性がなく、両者が直接通信できないことです。IPv6だけの端末とIPv4だけの端末はそのままではつながりません。そのため移行期の基本形は、1台のホストやネットワークがIPv4とIPv6の両方を同時に扱うデュアルスタック構成になります。当面はどちらか一方に寄せるのではなく、両方を並べて動かす前提で考えることが現実的です。

日本国内のIPv6普及状況

日本国内も着実に普及が進んでいます。Googleの計測では、日本のIPv6利用率は2024年時点で50%を超えており、複数の報道でも2024年前半に50%台へ乗ったと伝えられています。アジア太平洋地域全体としても、2025年に50%へ到達したとされています。

国内で普及を後押ししてきた要素はいくつかあります。固定回線ではフレッツ光ネクストやNGNの整備が進み、IPoE方式によるIPv6接続が広がりました。モバイル回線でもIPv6での接続が一般化しています。加えて総務省もIPv6への移行を促進する立場を示しており、公的な後押しも普及を支えてきました。

経済的な動機も無視できません。クラウド事業者を中心にIPv4アドレスの利用が有料化される流れが2024年頃から強まり、限りあるIPv4アドレスをコストとして意識する場面が増えました。こうした費用面の圧力も、IPv6を選ぶ理由のひとつになっています。

国内の利用者の多くがIPv6で届くようになったということは、日本向けにサービスを提供する事業者にとっても、IPv6対応がすでに現実的な検討事項になっていることを意味します。家庭のインターネット回線やスマートフォンの回線が標準でIPv6を使う場面が増えたため、提供側が対応を後回しにすると、経路の品質や接続性の面で利用者体験に差が出る可能性があります。国内の普及が進んだ今こそ、自社サービスのIPv6対応状況をあらためて点検する好機だといえます。

エンジニアが実務で押さえるべきポイント

利用者の半数がIPv6でアクセスしうる状況では、サービス提供側もIPv6を無視できません。ここでは実務で押さえておきたい要点を整理します。

デュアルスタックとDNSのA/AAAA

公開サービスをIPv6対応させる第一歩は、DNSにAAAAレコードを追加することです。DNSはIPv4向けのAレコードと、IPv6向けのAAAAレコードを両方返せます。デュアルスタックのクライアントはこの両方を受け取り、状況に応じてどちらの経路で接続するかを選びます。逆にAAAAだけ設定してサーバ側がIPv6を受けられない、といった不整合があると接続不良の原因になるため、DNSとサーバ設定は必ずそろえて確認します。

Happy Eyeballs v2の仕組み

デュアルスタック環境で、IPv6経路が壊れているときの待ち時間を減らす仕組みがHappy Eyeballs v2です。これはRFC 8305として2017年12月に標準化され、以前のRFC 6555を更新したものです。おおまかな流れとして、まずAレコードとAAAAレコードを非同期に問い合わせ、RFC 6724の規則でIPv6を優先するよう並べ替えます。次にIPv6の接続をわずかに先んじて試み、短い遅延の後にIPv4の接続も並行して試み、先に成功した方を採用します。目安として、名前解決を待つ遅延は約50ミリ秒、次のアドレスへ移る接続試行の遅延は約250ミリ秒とされています。

この並行接続とフォールバックのおかげで、壊れたIPv6経路に当たってもタイムアウトを長く待たされずに済みます。curl、Pythonのasyncio、Goのnetパッケージ、Node.jsなど、多くの実装にすでに取り込まれているため、クライアント側の挙動として押さえておくと不具合切り分けに役立ちます。

ネットワーク機器とアプリのIPv6対応

見落としやすいのが、アドレスを扱うあらゆる箇所のIPv6対応です。ファイアウォールやセキュリティグループでIPv6の通信を許可し、アクセス制御リストをv4とv6の両方に対応させる必要があります。ログや監視の基盤もIPv6アドレスを正しく記録・集計できるか確認します。アプリケーション側でも、コロン区切りのIPv6表記や、URLで用いる角括弧付きの表記を正しくパースできるか、IPアドレスの処理を見直す必要があります。CDNやロードバランサのIPv6対応、SLAACやプライバシー拡張によってアドレスが変わりうる点への配慮も忘れないようにします。

クラウドのIPv6対応

主要なクラウドでもIPv6対応は進んでいます。たとえばAWSでは、VPCへのIPv6割り当て、IPv6専用サブネット、ALBやNLBのデュアルスタック構成、外向き通信のみを許すegress-onlyインターネットゲートウェイなどが利用できます。前述のIPv4アドレス有料化とあわせて、新しい構成ではIPv6を積極的に取り入れる選択肢が現実味を増しています。

これからのIPv6移行にどう向き合うか

50%という数字は大きな節目ですが、あくまで通過点です。残る半数近くは依然としてIPv4を使っており、当面はIPv4とIPv6が共存し続けると考えるのが自然です。「IPv4がすぐに使えなくなる」といった話ではなく、両者を並行して運用する期間がしばらく続く、というのが現実的な見立てです。

そのうえでエンジニアが取れる方針は明確です。新規に設計するシステムは、はじめからIPv6を前提に据えておくと、後からの改修コストを抑えられます。既存システムについては、DNS・ファイアウォール・ログ・アプリのアドレス処理・クラウド構成といった観点で棚卸しを行い、影響範囲を把握したうえで段階的に移行していくのが安全です。

今できる準備として、まずは自分たちのサービスがIPv6でどこまで到達可能かを確認し、AAAAレコードの整備やデュアルスタックでの動作検証から着手するとよいでしょう。あわせて、監視やログの基盤がIPv6アドレスを正しく扱えるか、アクセス制御の設定に抜けがないかを一度洗い出しておくと、いざ本格的に対応する段階での手戻りを減らせます。半数の利用者がIPv6で届く時代に入った以上、IPv6を特別なものではなく標準の一部として扱う姿勢が、これからの運用を支える基盤になります。