はじめに
最近「PQC（Post-Quantum Cryptography）」という言葉を見かけるようになりました。
PQCとは、将来の量子コンピュータによる攻撃に備えた「耐量子計算機暗号」のことです。
2024年8月には米国のNISTがPQCの標準規格を公開し、2026年にはCloudflareがTLS・DNSSEC・IPsec VPNなどでPQCへの対応を進めています。
そこで気になったのが、PQCの導入によって、今までのネットワークは具体的に何が変わるのか？ という点です。
今回は、PQCの基本から、ネットワークへの影響、運用で考慮すべきポイントまで整理してみます。
※本記事は2026年10月時点の公開情報をもとにしています。
1. PQCとは？なぜ今から対応が必要なのか
量子コンピュータで現在の暗号は使えなくなる？
現在のインターネットでは、RSAや楕円曲線暗号などの公開鍵暗号が広く利用されています。
しかし、十分な性能を持つ量子コンピュータが実現すると、これらの暗号方式の安全性が脅かされると考えられています。
そこで登場するのがPQCです。
PQCは、従来のコンピュータだけでなく、将来の量子コンピュータによる攻撃にも耐えられるように設計されています。
ただし、すべての暗号方式が使えなくなるわけではありません。AESなどの共通鍵暗号は影響の受け方が異なり、PQCへの移行では特に公開鍵暗号への対応が重要になります。
なぜ今から準備する必要がある？
理由の一つが「Harvest Now, Decrypt Later（HNDL）」という攻撃です。
これは、現在の暗号化通信を保存しておき、将来、量子コンピュータで解読を試みるというものです。
企業の機密情報など、長期間保護する必要があるデータでは、将来解読されることもリスクになります。
そのため、量子コンピュータが実用化される前から対策を進める必要があります。
NISTが標準化したPQC
2024年8月、NISTは次の3つのPQC標準を公開しました。
| 標準 | アルゴリズム | 主な用途 |
|---|---|---|
| FIPS 203 | ML-KEM | 鍵共有 |
| FIPS 204 | ML-DSA | 電子署名 |
| FIPS 205 | SLH-DSA | 電子署名 |
ここで押さえておきたいのは、PQCにも鍵共有と電子署名という異なる役割があることです。
鍵共有は暗号化通信に必要な秘密情報を安全に確立する仕組み、電子署名は通信相手やデータの正当性を確認するための仕組みです。
この違いが、ネットワークへの影響にも関係してきます。
参考：NIST：PQC標準化
2. PQCの導入でネットワークはどう変わる？
2-1. TLS：通信開始時の処理が変わる
HTTPSで利用されるTLSでは、通信開始時に鍵共有や認証を行います。
PQCへの移行では、従来の暗号方式とPQCを組み合わせた「ハイブリッド方式」などが利用されます。
ただし、PQCでは鍵共有に必要なデータが大きくなる場合があり、通信開始時のデータ量や処理負荷に影響する可能性があります。
2026年9月、Cloudflareは「Automatic Key Exchange」を発表しました。
これは、接続先サーバーの対応状況に応じて適切な鍵共有方式を選択する仕組みです。
では、PQCに対応できなかった場合はどうなるのでしょうか？
双方が従来の暗号方式にも対応していれば、従来方式で接続できる場合があります。
一方、PQCを必須にした環境で接続先が未対応の場合、TLS接続が失敗する可能性があります。
つまり、運用ではPQCへの対応状況だけでなく、既存環境との互換性も重要になります。
参考：Cloudflare：Automatic Key Exchange
2-2. DNSSEC：DNS応答のサイズが大きくなる
DNSSECは、DNS応答が改ざんされていないかを電子署名によって検証する仕組みです。
2026年9月、CloudflareはパブリックDNSリゾルバ「1.1.1.1」で、PQCを利用したDNSSEC署名の検証に対応したと発表しました。
ここで注目したいのが、署名サイズの違いです。
| 署名方式 | 署名サイズ |
|---|---|
| ECDSA P-256 | 64バイト |
| ML-DSA-44 | 2,420バイト |
PQCの署名は従来方式より大きくなる場合があり、DNS応答全体のサイズにも影響します。
DNSではUDPが広く利用されていますが、応答が大きくなるとTCPによる再問い合わせが必要になることがあります。
例えば、ファイアウォールでUDPの53番ポートだけを許可し、TCPの53番ポートを遮断している場合、大きなDNS応答を取得できず、名前解決に失敗する可能性があります。
また、応答サイズが大きくなることで、MTU（ネットワークで一度に転送できるパケットサイズの上限）にも注意が必要です。
つまり、PQCへの対応がDNSの通信方式やファイアウォール設定にも影響する可能性があるということです。
ただし、すべてのDNS通信で問題が起きるわけではなく、応答サイズやネットワーク構成によって影響は異なります。
参考：Cloudflare：Post-quantum DNSSEC
2-3. IPsec VPN：機器間の互換性が重要になる
IPsec VPNでは、IKE（Internet Key Exchange）という仕組みを利用して鍵情報などを確立します。
2026年4月、Cloudflareは耐量子IPsecの一般提供を発表し、CiscoやFortinetの機器との相互接続試験にも言及しています。
ここで問題になるのが、接続する機器同士の互換性です。
例えば、本社側のVPN機器をPQC対応に更新しても、支社側の機器が未対応の場合、そのPQC方式を利用した接続はできません。
従来方式への切り替えが可能なら通信を継続できる場合もありますが、PQCのみを許可する設定ではVPN接続自体が失敗する可能性があります。
そのため、機器更新時には対向機器の対応状況やファームウェア、利用できる鍵共有方式を確認する必要があります。
参考：Cloudflare：Post-quantum IPsec
3. ネットワーク運用では何を考慮すべきか？
ここまでの内容を整理すると、PQCへの移行による影響はプロトコルごとに異なります。
| 技術 | 主な変化 | 未対応・設定不備の場合 |
|---|---|---|
| TLS | 鍵共有方式や通信量の変化 | 従来方式への切り替え、または接続失敗 |
| DNSSEC | 署名サイズの増大 | DNS応答の取得・検証に問題が生じる可能性 |
| IPsec VPN | IKEの鍵共有方式の変更 | 従来方式で接続、またはVPN接続失敗 |
※未対応時の動作は、プロトコルの仕様や設定によって異なります。DNSSECでも、未知の署名方式が必ず検証エラーになるわけではありません。
実務では何から始める？
PQCへの移行を考える場合、いきなり機器を交換するのではなく、まずは現在の環境を把握することが重要だと思います。
具体的には、以下の4点です。
- 暗号方式の把握：TLSやVPNなどで現在利用している暗号方式を確認する
- 対応状況の確認：ネットワーク機器やソフトウェアがPQCに対応しているか調べる
- 影響範囲の整理：通信量、性能、接続先との互換性を確認する
- 移行計画の検討：障害時の切り戻しも考慮し、段階的に移行する
特に注意したいのは、「通信できること」と「PQCで保護されていること」は別という点です。
従来方式へ切り替われば通信は継続できても、PQCによる鍵共有の保護は得られない場合があります。
一方、PQCを必須にすれば、非対応機器との通信ができなくなる可能性があります。
このため、可用性とセキュリティの両方を考えて移行する必要があります。
まとめ
今回は、PQCの基本と、TLS・DNSSEC・IPsec VPNへの影響について整理してみました。
最初は暗号方式が変わるだけだと思っていましたが、実際には通信開始時の処理やDNS応答サイズ、ネットワーク機器の互換性などにも関係することが分かりました。
特に、PQCに対応できなかった場合の動作は、ネットワーク運用で重要なポイントだと感じました。
2026年のCloudflareの発表を見ると、PQCは将来に向けた研究だけではなく、実際のネットワークで導入が進み始めている技術です。
今すぐすべての機器を交換する必要があるわけではありませんが、今後の機器更新やネットワーク構成の見直しでは、PQCへの対応状況も確認していく必要がありそうです。