ライブネットにおける PQC 利用状況の調査

概要

量子計算機の実用化が近づく中，既存の公開鍵暗号に代わるポスト量子暗号（PQC）への移行が世界的に進められています．本稿では，NICT のライブネット（職員が業務で利用する機構内ネットワーク）のトラフィックを対象に，2025 年 9 月 8 日のアウトバウンド通信における PQC の利用状況を調査しました．

調査の結果，PQC 利用率は約 12%，PQC 提案率は約 43% でした．利用されている鍵交換方式は全て標準化審査中のハイブリッド方式であるX25519MLKEM768でした．PQC 対応サーバの傾向としては，Google 系サービスや広告・マーケティング系業界が先行している一方で，政府・教育系や金融系の導入は比較的遅れていることがわかりました．

PQC とは

ある程度の規模をもつ素因数分解問題や離散対数問題は，我々が日常的に用いている電子回路型計算機では現実的な時間内に解くことが極めて困難です．公開鍵暗号はこの計算困難性を安全性の基盤として利用し，秘密鍵を漏らすことなく安全に鍵交換や電子署名を実現しています．攻撃者が公開された情報から秘密鍵を推測するためには膨大な計算量が必要となるため，現実的な攻撃は不可能であると考えられてきました．

しかし，Shor の量子アルゴリズム¹の登場により，量子計算機上ではこれらの問題が効率的に解けてしまうことが明らかとなりました．量子計算機が十分な規模で実用化された場合，素因数分解や離散対数に依存する RSA や楕円曲線暗号（ECC）は安全性の前提が崩れ，根本的に破られる可能性があります．

こうした背景から，量子計算機に対しても高速に解かれない新たな計算問題を基礎とする暗号技術の研究・標準化が世界的に進められています．量子計算機でも現実的な時間で解けない計算困難性に基づく暗号方式は，PQC（Post-Quantum Cryptography：ポスト量子暗号） と呼ばれています．

英国 NCSC は，既存の公開鍵暗号が 2035 年頃までに危殆化する可能性を指摘しており²，世界中のインフラが PQC への大規模移行を迫られる「2035 年問題」として問題提起を行っています．また，米国 NSA の移行ガイドライン CNSA 2.0³ でも，長期の安全性が求められるデータについては 2030 年代半ばまでに PQC への移行を完了すべきと明確に示されています．

量子計算機が既存の暗号方式を現実的に解読できるようになるまでには，一般的に「あと十年程度」と予測されています．しかしその前段階から，すでに ハーヴェスト攻撃（harvest now, decrypt later 攻撃） の脅威が懸念されています．これは，量子計算機が実用化される前に暗号化通信を盗聴・収集しておき，将来量子計算機が利用可能になった時点で蓄積したデータを解読する攻撃手法です．

特に，国家機密や知的財産のように長期間にわたり価値を保持するデータは，この攻撃モデルの主要なターゲットとなり得ます．そのため，データの保存期間や保護要求を踏まえた上で，早期に移行計画を策定し，PQC への段階的な切り替えを進めることが不可欠です．

標準化の動向

米国 NIST は，米国政府機関として暗号標準を策定しています．PQC においても 2016 年から公開，応募，審査，選定プロセスにより標準化を目指しています． 2025 年 12 月現在，第 4 ラウンドを経て 3 つの FIPS 標準を発行しています．今後さらにいくつかの FIPS 標準を策定予定です．⁴

• FIPS 203: ML-KEM (CRYSTALS-Kyber)
• FIPS 204: ML-DSA (CRYSTALS-Dilithium)
• FIPS 205: SLH-DSA (SPHINCS+)

また，IETF では既存プロトコルに PQC を組み込むためのワーキンググループを設置し，TLS 関連で多数のドラフトが存在しています．SSH, IPsec におけるハイブリッド鍵交換方式のドラフト等も審査中のステータスです．

国内においては，政府機関・研究機関・産業界が連携し，PQC への移行に向けた評価・指針策定が進められています．特に NICT が事務局を務める CRYPTREC（暗号技術評価委員会） は，電子政府で利用すべき暗号技術を検討・評価する組織として，近年 PQC を重点的な調査対象に位置付けています．CRYPTREC では「耐量子計算機暗号ワーキンググループ」を設置し，PQC アルゴリズムの安全性評価，実装面での課題整理，国内利用に向けた運用指針の検討を継続的に実施しています．また，毎年度の「耐量子計算機暗号の研究動向調査報告書」や「暗号技術ガイドライン」において，量子計算機の脅威，NIST 標準化動向，海外の移行ロードマップ，国内のシステムが直面する技術課題を体系的にまとめています．⁵

さらに，日本の事業者・公共機関においては，量子耐性を考慮した暗号資産の棚卸し（crypto inventory）や，中長期的な移行計画の策定が求められています．総務省・金融庁・国家サイバー統括室（NCO）などの機関でも，国の基盤となる情報システムが将来的に量子攻撃に耐えうるよう，鍵管理や通信基盤の更新を視野に入れた検討が進んでいます．^{6 7}

このように，PQC は国際標準化のフェーズから実運用への移行期に入りつつあり，米国 NIST や IETF の標準化動向を踏まえながら，日本国内でも安全な採用・移行を支援するための取り組みが本格化しています．

主要ブラウザにおける PQC 対応状況

主要ブラウザの PQC 対応状況をまとめました．2025 年 12 月現在，概ね主要ブラウザは PQC による鍵交換がデフォルトで有効化されていることを確認しました．

PQC 利用率の調査

それでは，世の中で実際に PQC を使った通信はどの程度発生しているのでしょうか． NICT のライブネット（職員が業務で利用する機構内ネットワーク）のトラフィックを対象にPQCを使った鍵交換の利用率を調査してみました．

PQC 通信の判定方法

PQC が使われているかどうかは，TLS handshake の ServerHello パケットの TLS ヘッダを確認することで判定することができます． TLS 拡張フィールドである Key Share Extension に PQC もしくは PQC ハイブリッドの鍵交換方式が指定されていることが確認できれば，PQC を使った TLS セッションが開始されたと判定できます． なお，TLS 1.3 未満には PQC に対応した標準技術がないため，TLS 1.3 未満の場合は PQC が使われていないと判定できます． HTTP/3 で使われる QUIC に関しては，Initial パケットもしくは Handshake パケットに含まれる TLS 1.3 ヘッダを確認することで，同様に判定することが可能です．

また，TLS handshake の ClientHello パケットからは，クライアントから提案された鍵交換方式のリストが確認できます． TLS 拡張フィールドである Supported Groups Extension に，クライアントがサポートしている鍵交換方式が提示されます．

つまり，ClientHello で PQC が指定されている場合は，PQC を提案したということであり，クライアントが潜在的に PQC 対応していることがわかります．さらに ServerHello で PQC が指定されている場合は，PQC を選択したということであり，両者が PQC 対応していることがわかります．

調査にあたり，pcap ファイルから PQC が含まれる通信を検出するツール「PQC-Detector」を開発しました．ソースコードは GitHub で公開しています．

PQC-Detector (GitHub)

Python3 で開発し，パケット分析ライブラリは pyshark を利用しています．Supported Groups Extension や Key Share Extension から拾う 16 進数値と Group Name のマッピングは，WireShark のライブラリをベースに自作しています．今後新たな Group Name が策定された場合はマッピングファイルに追記することで対応可能です．

調査対象

調査対象データは 2025 年 9 月 8 日（月）のライブネットトラフィックに含まれるアウトバウンド通信における TLS handshake パケットです．つまり，NICT 職員が業務で外部に行う TLS 通信の一部を調査対象としています． 調査対象に含まれる ServerHello パケットと ClientHello パケットの数は表の通りです．

調査結果

この調査結果では，PQC 利用率と PQC 提案率という言葉を使います．それぞれの定義は下記の通りです．

• PQC 利用率：PQC 鍵交換をした割合（クライアント・サーバ両者が PQC に対応）
• PQC 提案率：PQC 鍵交換を提案した割合（クライアントが潜在的に PQC に対応）

全ての ServerHello パケットのうち，PQC が選択された ServerHello パケットの割合により PQC 利用率を算出しました．PQC 利用率は 約 12% でした． 限定的ながら実環境で運用され始めていることがわかります．

一方で，ClientHello パケットのうち，PQC が提案された ClientHello パケットの割合により PQC 提案率を算出しました．PQC 提案率は 約 43% であり，半数近くのクライアントが PQC に対応していることがわかりました．また，PQC 利用率と PQC 提案率の間では約 3.6 倍の差が存在しています．

これはシンプルに考えると，PQC 対応のクライアントで様々なサーバにアクセスすると 36 回に 10 回の割合で PQC を使った鍵交換ができるということです．

ServerHello の調査

ServerHello パケットについて掘り下げてみます．

プロトコル別集計

PQC 通信で使われたプロトコルは TLS 1.3 が約 96%，QUIC が約 4% であり，僅かながら QUIC による PQC 通信が存在しました． また，TLS 1.3 の ServerHello のみに絞った時の PQC 利用率が約 15% であるのに対し，QUIC は約 57% と，高い水準で PQC に対応していることがわかりました．

ポート番号別集計

PQC を選択した ServerHello の送信元ポート番号はほぼ全てが 443 番ポートであり，PQC は主に HTTPS で利用されていることがわかります．

鍵交換方式

PQC 通信に使われた鍵交換方式は全てX25519MLKEM768でした．これは従来暗号である楕円曲線鍵交換（X25519）と PQC 鍵交換（ML-KEM）を組み合わせたハイブリッド鍵交換方式です．⁸ この鍵交換方式は IETF で審査中の標準ドラフトであり，まだ正式に標準化されたものではありませんが，多くのブラウザで既に実装されています．

ClientHello の調査

次に，ClientHello パケットについても掘り下げてみます．

プロトコル別集計

PQC を提案した通信で使われたプロトコルは TLS が約 99%，QUIC が約 1% であり，僅かながら QUIC による PQC 通信が存在しました．

プロトコル別の PQC 提案率に関しては興味深い結果が出ました．TLS の ClientHello のみに絞った時の PQC 提案率が約 45% であるのに対し，QUIC は約 9% と低く，ServerHello のプロトコル別 PQC 利用率と逆転しています． これは，サーバ側の PQC 対応に関しては QUIC が先行しているのに対し，クライアント側の PQC 対応は TLS が先行していることを意味しています．

ポート番号別集計

PQC を提案した ClientHello の宛先ポート番号はほぼ全てが 443 番ポートであり，PQC は主に HTTPS で提案されていることがわかります．

鍵交換方式

ClientHello で提案された PQC 鍵交換方式は，ServerHello 同様に全てX25519MLKEM768でした．

PQC 対応サーバの傾向

PQC に対応していたサーバについて傾向を分析してみました．PQC に対応していたサーバの FQDN の数は 23,673 件です．

主要テック企業別傾向

主要テック企業別に集計したところ，Google 系の FQDN が全体の 31% であり，Google 社のサービスが圧倒的に先行していることがわかりました．

業界別傾向

業界別に分析してみると，広告・マーケティング系が最多で約 42% を占めています． クラウド・CDN 系やメディア・コンテンツ系も比較的 PQC 対応が進んでいる業界であり，インフラレベルで PQC 対応が進んでいることがわかります． 一方で，コミュニケーション系，政府・教育系，金融系に関しては，通信の機密性やセキュリティ要件が高い業界ですが，PQC 対応サーバは比較的少ないようです． これらの業界は慎重な導入プロセスにより PQC 導入が遅れている可能性があります．

TLD 傾向

TLD で集計した結果を図 5 に示します． PQC 対応サーバの約 70% が.comドメインであり，3 位の.netと合わせると全体の 8 割を占めています．商業的なインターネットインフラが PQC を先行導入している可能性があります． 日本国内に住所をもつ組織・個人・団体のドメイン.jpは 2 位で約 12% を占めています．ただし，NICT の業務通信という調査対象データの特性上，国内サーバへの通信が多いという偏りが発生している可能性があることに留意ください． 4 位以降を見ると，.io，.ai，.app，.dev等，技術志向の組織が使う TLD が上位に多いことがわかります．

.jpドメインの特徴としては，汎用 jp ドメインが過半数を占めています．特定の組織種別に限定されず，幅広い組織で PQC 対応していることがわかります． 属性型 jp ドメインでは，国内で登記している企業のドメインco.jpが最多です．日本においてはセキュリティ要件の高い政府機関ドメインgo.jpも比較的進んでいるようです． ただし，これに関しても調査データの特性上，政府機関への通信が多いという偏りが発生している可能性があることに留意ください．

まとめ

NICT のライブネットトラフィックを対象に PQC 利用率を調査しました． PQC 利用率は 約 12% であり，限定的ながら実運用されつつある状況です． 利用されている鍵交換方式は，標準化にむけて審査中の PQC ハイブリッド鍵交換方式であるX25519MLKEM768です．

PQC 対応の傾向としては，PQC 提案率が約 43% ということから，クライアント側で先行し，サーバ側の対応が追いついていない状況であると考えられます． ただし，QUIC (HTTP/3) に関してはサーバ側の対応が先行しているようです．

PQC 対応サーバの傾向としては，Google 系サービスや広告・マーケティング系業界が圧倒的に先行していることがわかりました． 一方で，政府・教育系や金融系に関しては導入が遅れている可能性があります．

今後さらに PQC の利用率が上昇するかどうかは，サーバ側の対応次第であるところが大きいと考えられます．各種 OS の標準パッケージ対応や，各種サーバ製品の PQC ライブラリへの対応によって，さらに利用が加速する可能性があります． NICT では引き続き，PQC の利用状況を注視していく予定です．