【戦略】PQC（耐量子計算機暗号）の実装状況と焦点 ～通信先行で進む企業の耐量子化～

　量子コンピュータ研究が進展する中、既存のセキュリティに対する懸念が高まっている。こうした中で新たな技術として導入が進みつつあるのが、PQC（耐量子計算機暗号）だ。PQCとは、将来、実用的な量子コンピュータが登場した場合でも破られにくいよう設計された公開鍵暗号アルゴリズム群を指す。

　現在のインターネットの安全性は、RSA暗号や楕円曲線暗号（ECC）等、公開鍵暗号に大きく依存している。これらは、従来のコンピュータが大きな数の素因数分解や離散対数問題を解くのに膨大な時間を要するという数学的前提の上に成り立ってきた。

　しかし量子コンピュータでは、データの1ビットが0と1の状態を同時に保持できる量子力学的な性質等を利用することで、従来のコンピュータでは極めて難しい計算を効率的に行える可能性がある。そのため、量子コンピュータが実用段階に達した場合、現在広く使われている公開鍵暗号が脆弱化することが懸念されている。

　このリスクに備えるため、量子計算でも効率的に解くことが難しいと考えられる数学問題に基づく新たな暗号方式の研究と標準化が進められている。PQCでは、従来の素因数分解や離散対数問題に代わり、格子問題やハッシュ問題等を基盤とする方式が採用されている。米国立標準技術研究所（NIST）は、この分野の標準化を進めており、すでに一部アルゴリズムが標準として公表されている。

耐量子化は「通信」と「証明書・署名」に分けて考える

　PQCへの移行は、一括で進めるものではない。実務上は、まず通信の耐量子化と証明書・署名の耐量子化に大きく分けて考える必要がある。米国立標準技術研究所（NIST）も、現代のネットワーク・セキュリティ・プロトコルでは、通信を確立する際に「鍵確立」と「証明書・署名」のために別々の非対称鍵を用いることが多く、PQC移行もこの2領域を分けて進めることが可能だとしている。

　通信の耐量子化は、主に機密性の保護が目的だ。特に問題となるのが、「Harvest Now, Decrypt Later（今収集して後で解読）」の脅威である。これは、現時点では解読できない暗号化通信を第三者が保存しておき、将来、量子コンピュータが実用化された段階でまとめて解読するというリスクを指す。政府データ、医療データ、長期契約、知的財産、国家機密等、長期間にわたって価値を持つ情報では、この脅威が現実的な問題となる。そのため、通信の耐量子化はとりわけ優先度が高く、早めの対応が求められている。

　一方、証明書・署名の耐量子化は、相手が本物かを確認する仕組みを量子時代にも維持することが目的となる。こちらは通信の機密性そのものを守る仕組みではないため、過去の暗号化通信が後から読まれるという意味での「Harvest Now, Decrypt Later」の脅威は直接は生じない。例えば、量子コンピュータで認証システムを破って、他人に成りすましても、通信の暗号化が破られていなければ、過去のデータは暗号化されたままで解読できないということだ。したがって、証明書・署名の耐量子化では、強力な量子コンピュータが実用化する前までに、公開鍵基盤（PKI）や証明書、署名検証機能、関連システムの更新を終え、旧式アルゴリズムを停止できる状態を整えることが重要になる。この違いから、現在は一般に、通信の耐量子化の方が先行し、証明書・署名の耐量子化はそれに続く形で進んでいる。

通信の耐量子化はどこまで進んでいるか

鍵共有の置換えが中核

　通信の耐量子化で中心になるのは、通信の機密性を守るために使われる鍵共有（鍵確立）スキームを、量子コンピュータの攻撃に耐え得る新たなアルゴリズムへ移行することだ。現時点で先行している実装の多くは、米国立標準技術研究所（NIST）が標準化した耐量子アルゴリズム「ML-KEM（FIPS 203）」に直ちに全面移行するのではなく、従来の公開鍵暗号方式と組み合わせたハイブリッド方式を採用し、段階移行が中心となっている。

　この背景には、PQCアルゴリズムの鍵やメッセージが従来方式より大きくなりやすく、通信量や実装負荷への影響があること、また移行初期から新たなアルゴリズム単独に全面依存することを避けたいという事情がある。そこで、量子脆弱な従来型アルゴリズムと量子耐性のあるPQCアルゴリズムを組み合わせ、少なくとも片方が安全であれば全体として安全性を維持できる移行策が現実的な選択肢となっている。

TLSが最も先行し、SSH・IPsecにも波及

　企業のPQC実装の中では、ネットワーク・セキュリティ・プロトコルへのアルゴリズムの組み込みが進んでいる。とりわけ、HTTPSやメール、API通信等で使われる暗号化プロトコル「TLS（Transport Layer Security）」は、企業にとって影響範囲が大きく、優先的に対応が進められている。

　インターネット技術の標準化を担うIETF（Internet Engineering Task Force）でも、TLS1.3向けのハイブリッド鍵共有について設計が進められているが、企業での実運用は正式標準（RFC）の確定を待つだけでなく、先行導入の段階に入りつつある。

　加えて、リモートログインや安全なファイル転送に使われる「SSH（Secure Shell）」や、VPN等でIP層の通信を保護する「IPsec（Internet Protocol Security）」でも、ハイブリッド型の耐量子鍵交換の導入が進み始めている。

　具体的な実装事例としては、グーグルが同社ブラウザ「Chrome」および自社サーバー群で、従来の楕円曲線鍵交換方式「X25519」とPQCアルゴリズムML-KEM（ML-KEM-768）を組み合わせたハイブリッド鍵交換方式を段階的に展開し、Chromeでは最終標準版ML-KEMへの移行も進めている。また企業向けブラウザ「Chrome Enterprise」では、企業管理者が耐量子鍵共有の有効・無効を制御できる。AWSも「AWS KMS」「ACM」「Secrets Manager」の各エンドポイントでML-KEMベースのハイブリッドTLSをサポート。クラウドフレアも「Cloudflare One」等でML-KEMを組み込んだハイブリッド型の耐量子鍵共有を展開している。

　SSHの分野では、AWSのファイル転送サービス「Transfer Family」が、SFTPで用いるSSH接続でML-KEMベースのハイブリッド鍵交換を提供。IPsecの分野でも、クラウドフレアが従来方式にML-KEMを追加するハイブリッド鍵交換の対応要件や推奨構成を公開している。このように通信の耐量子化は、研究・実験段階に留まらず、商用サービスの一部で実装段階に入りつつある。

証明書・署名の耐量子化はどこまで進んでいるか

通信より難しく、進捗は一段遅い

　証明書・署名の耐量子化では、現在広く用いられているRSAやECDSAによるデジタル署名を、NISTが標準化したML-DSAやSLH-DSAといった量子耐性のある署名アルゴリズムへ置き換えることが中核となる。しかし、この移行は単なるアルゴリズムの置き換えに留まらない。

【参考】【アメリカ】NIST、量子コンピューター時代のサイバー攻撃対策アルゴリズムで3標準規格決定。全てIBM（2024年8月25日）

　証明書・署名では、単にサーバ証明書だけではなく、認証局（CA）、公開鍵基盤（PKI）、証明書検証機能、コード署名、メール署名、ブラウザ、OS、アプリケーションまで含む広いエコシステム全体を更新しなければならない。しかも、署名する側だけがPQCに対応しても不十分で、署名する側と検証する側の両方が対応して初めて実運用が成立する。

　NISTの整理でも、証明書・署名の移行は、鍵共有の移行とは別の時間軸で考える必要があり、公開鍵基盤（PKI）等の支援インフラ更新も伴うため、通信の耐量子化、とりわけ鍵共有の移行に比べて複雑になりやすい。

まずはプライベート公開鍵基盤（PKI）や社内基盤から

　証明書・署名の耐量子化で先行しているのは、公開Web全体というより、内部の認証局（CA）を持つ中央集権的ネットワークや、管理統制の強い環境だ。これらの環境では、関係者間の調整や変更展開を進めやすいため、PQC署名アルゴリズムを比較的早く導入しやすい。

　例えばグーグルの「Google Cloud」では2025年2月、Cloud KMSで量子安全デジタル署名のプレビュー提供を開始した。これにより、既存APIを用いてML-DSAやSLH-DSAでの署名・検証を行い、既存ワークフローへの組み込みを検証できる段階に入っている。

　一方、公開Web PKIでは事情が異なる。グーグルは2026年2月、量子耐性暗号で増大するサイズが、Certificate Transparency（CT）を必要とするTLS接続で性能や帯域に課題をもたらすと説明し、従来型のX.509証明書にPQCを載せる方式をChrome Root Storeへ直ちに導入する予定はないとした。その代わり、量子安全なHTTPS証明書に向け、MTC（Merkle Tree Certificates） を軸とする新方式を公表し、IETFのワーキンググループ「PLANTS」で、短寿命証明書や大きなPQC署名に伴う証明書・ログ負荷を抑える仕組みを検討している。

PQC移行を支える技術基盤への適用はどこまで進んでいるか

ソフトウェア基盤

　PQC実装では、ソフトウェア内部で暗号処理を担う技術基盤の整備も必要となる。特に暗号ライブラリは中核的な要素であり、アプリケーションは一般に暗号機能を自前で実装するのではなく、OpenSSLやBoringSSL、NSS、AWS-LC等のライブラリやAPIを通じて利用する。

　NISTの文書でも、暗号APIはアプリケーション実装と暗号アルゴリズム実装を分離し、ライブラリ更新を円滑に行えることが重要だと説明されている。そのため、ML-KEMのような耐量子鍵共有アルゴリズムや、ML-DSA、SLH-DSAのような耐量子署名アルゴリズムを主要ライブラリで利用可能にすることは、通信・証明書・署名の実装普及に向けた重要な基盤条件となる。

　例えばTLS・証明書処理用途のオープンソース暗号ライブラリ「OpenSSL」の開発・運営を行うOpenSSLプロジェクトは、2025年4月公開のOpenSSL 3.5で、PQCアルゴリズムのML-KEM、ML-DSA、SLH-DSAのサポートを追加した。

　またグーグル・Chromium系の実運用基盤であるBoringSSLでは、TLS向けX25519MLKEM768を実装。Firefox系のNSSでもML-DSA鍵・機構、KEM関連機能の対応が進んでいる。AWS系のAWS-LCでは、AWS-LCでもML-KEMが統合され、TLS向けにX25519MLKEM768等のハイブリッド鍵共有が利用可能になっている。

　次に、OSが提供する暗号機能を呼び出すインターフェースのOS APIがある。こうした暗号APIでPQCアルゴリズムを扱えるようになると、アプリケーションは暗号処理を一から実装し直すのではなく、既存のOS・ランタイムの暗号基盤を通じて耐量子化へ移行しやすくなる。

　具体的な実装事例としては、マイクロソフトのWindowsのOS API「CNG（Cryptography API: Next Generation）」が、ML-KEMとML-DSAを追加し、開発者向けのサンプルも公開している。さらに証明書関連APIでもML-DSA証明書のインポート、エクスポートや証明書チェーン検証を試せるようにしている。

　アップルもiOS 26、iPadOS 26、macOS Tahoe 26、visionOS 26で「URLSession」やNetworkフレームワークにおけるTLSの耐量子化をデフォルトで有効化。同社は、これらのOSのTLS1.3接続時にX25519MLKEM768を自動広告すると明記している。また同社のOS API「CryptoKit」でも量子安全ワークフロー向けAPIを案内している。

　また、OS APIそのものではないが、周辺レイヤーでも部品は揃い始めている。マイクロソフトは.NET 10でML-KEM、ML-DSA、SLH-DSAのAPIを追加し、グーグルもGoogle Cloud KMSでML-DSAとSLH-DSAの署名を提供している。

　但し、これは公開インターネット全体の証明書配布・検証エコシステムまで完成したことを意味するわけではない。実際、Google Cloud KMSも、PQC署名と従来署名のハイブリッド化について、標準や業界の合意が未成熟として現時点ではAPI提供していない。

　ソフトウェア基盤には、開発者がソフトウェアを作るためのツールセットであるSDK（Software Development Kit）もある。SDKも同様に、PQCそのものを独自実装するというより、下位のTLS実装や暗号ライブラリのPQC機能を利用・設定できることが重要になる。例えばAWSサービス向けでは、「AWS SDK for Java 2.x」や「AWS SDK for Rust」を利用することで、開発者は特別な暗号実装を行わなくても、設定を有効にするだけで、X25519MLKEM768を用いた耐量子鍵共有を利用できる。

ハードウェア基盤

　さらに、秘密鍵を安全に保管し、外部に出さずに利用するためのハードウェア基盤の中核コンポーネントとして、HSM（Hardware Security Module）等を整えることも必要だ。特に証明書・署名側では、署名鍵の保護や公開鍵基盤（PKI）との連携の観点からHSMの重要性が高い。NISTも、HSMはTLSサーバ証明書の秘密鍵や内部CAの署名鍵を安全に生成・保管・利用できるとしている。一方、通信側でもTLSサーバ証明書や鍵管理の保護用途で用いられるが、常に必須とされているわけではない。

　現状の企業の実装状況としては、Entrustが2025年9月、同社のハードウェア基盤「nShield HSM」でML-DSA、ML-KEM、SLH-DSAをネイティブ対応し、これらアルゴリズム実装がNISTの暗号アルゴリズム認証制度「CAVP」で検証されたと公表。Thalesも「Luna HSM 7.9」でML-KEMとML-DSAをファームウェアに統合している。

実装のボトルネックとなる製品・システム・機器

　もっとも、技術基盤が整ったからといって、直ちにすべての製品・システム・機器が耐量子化されるわけではない。実際の移行では、アプリケーション更新に加え、周辺機器やネットワーク構成要素、相互運用性の確認が大きな課題となる。

　通信では、ファイアウォール、プロキシ等のmiddleboxがボトルネックとなりやすい。例えばグーグルは、Chrome Enterpriseで耐量子鍵共有を有効化した際、鍵カプセル化データやTLSの接続開始メッセージ「ClientHello」関連の変更によりメッセージが大きくなり、中間機器の非対応によって接続失敗や通信断が起こり得ると指摘している。このため、単にライブラリを更新しただけでは不十分であり、ネットワーク機器や運用設定を含めた検証が不可欠となる。

　認証では、エコシステム全体の更新が課題だ。署名する側、証明書を発行する側、証明書を検証する側、信頼アンカーを管理する側、失効情報を扱う側等、多数の構成要素が連動しなければならない。そのため、通信のように比較的限定的な範囲から先行導入することが難しく、移行スピードも遅くなりやすい。

　さらに、製品・機器側、とりわけ組込みシステムにおける実装も重要なボトルネックとなる。サーバやクラウドと異なり、IoT機器や産業機器では、計算性能、メモリ容量、消費電力等の資源制約の中でPQCアルゴリズムを実装する必要がある。

　例えば、欧州の半導体メーカーのSTマイクロエレクトロニクスは、PQCアルゴリズムをマイクロコントローラ（MCU）等に統合するとともに、セキュアブートやファームウェア更新といったRoot of Trust（RoT）領域をPQCアルゴリズムで更新していく方向性を示している。

　また、インフィニオン・テクノロジーズは、ML-KEMやML-DSAを含むコモンクライテリア（CC）対応の暗号ライブラリを備えたセキュリティコントローラを提供しつつ、サイドチャネル攻撃やフォールト攻撃への耐性を備えたハードウェア基盤の重要性を打ち出している。これは、PQCではアルゴリズムの安全性に加え、実装上の副次的漏えい対策が重要な論点となることを示している。

　さらに、NXPセミコンダクターズは、組込み環境でのPQC移行において、メモリ制約等のデバイス特有の制約に加え、サイドチャネル攻撃やフォールト攻撃への耐性を確保する必要があると指摘。このように、製品・機器側では、単にアルゴリズムを置き換えるだけでなく、ハードウェア制約や実装上の安全性を踏まえた設計が求められ、クラウドやネットワークとは異なる観点での移行課題が存在する。

本格段階にはない旧アルゴリズムの無効化

　現在使用されている量子コンピュータに脆弱なアルゴリズムは、実用的な量子コンピュータが登場する前までに、認証システムを使用不可にし、無効化する必要がある。但し、現状の主要ガイダンスや実装は、全面的な旧方式停止よりも、ハイブリッド方式によるPQC導入と後方互換性の確保を前提としている。

　当面は、旧アルゴリズムから移行期にあるため、実務上はハイブリッド方式でPQCを導入しつつ、相互運用性を確認しながら、段階的に旧方式を縮退させていく流れとみるのが妥当だ。

企業がまず取り組むべきことと今後の展望

　PQC実装に向けては、まず自社が提供・利用する製品・サービスにおける暗号利用箇所の棚卸しを行い、脆弱なアルゴリズム利用箇所を特定することから始める必要がある。NISTもインベントリ整備、リスク評価、優先順位付けが移行の出発点として位置付けている。アップルがPQC鍵共有を端末側で自動で広告することを明言し、互換性問題を具体化した以上、通信事業者や大企業ネットワークのTLS終端装置・プロキシは後追い対応を迫られる可能性が高い。

　また、PQC移行期にハイブリッド方式が現実的な移行手段であることは先行実装から確認できる一方、個別設計の安全性評価には差がある。実際「ETSI TS 103 744」初期版には、研究者から安全性主張や構成法に対する批判が提起され、その後ETSI側でも改訂が進められている。したがって、経営視点では、標準や主要実装に寄せ、監査可能な根拠を残し、自社独自ハイブリッドを安易に作らないことが望ましい。

　政府の動向を見ると、米国ではトランプ政権が2025年6月の大統領令で、連邦機関にPQC対応製品が広く利用可能な製品カテゴリの整理・定期更新を指示した。加えて、PQC移行の準備として、国家安全保障システム（NSS）については国家安全保障局（NSA）長官が、NSS以外については行政管理予算局（OMB）長官が、各機関にTLS 1.3または後継版を遅くとも2030年1月2日までにサポートさせるための要件を定めるとしている。

【参考】【アメリカ】トランプ大統領、セイバーセキュリティ強化大統領令署名。ポスト量子暗号も（2025年6月10日）

　日本でも金融庁の2024年報告書が、暗号棚卸し（クリプト・インベントリ）、リスク評価、適用対象の特定、サプライチェーン対応、導入前テスト等の必要性を整理している。さらに2026年1月には、G7サイバー・エキスパート・グループ（CEG）が、金融セクター向けにPQC移行ロードマップを公表し、リスク認識・準備、発見・棚卸し、リスク評価・計画策定、移行実行、移行テスト、検証・監視の6段階を提示した。全体としては2035年を移行の目安としつつ、特に重要なシステムは優先的に対応することでリスクの早期顕在化を抑制する考え方も示している。

【参考】【国際】G7サイバー専門家グループ、金融機関にポスト量子暗号への移行計画策定推奨（2026年1月13日）

　こうした動向を踏まえると、PQC移行は単なる技術更新ではなく、経営・規制・業界協調を伴う中長期の基盤整備として、前倒しで準備を進める局面に入っていると言える。

【参照ページ】Transition to Post-Quantum Cryptography Standards 【参照ページ】Module-Lattice-Based Key-Encapsulation Mechanism Standard 【参照ページ】Module-Lattice-Based Digital Signature Standard 【参照ページ】FIPS 205 Stateless Hash-Based Digital Signature Standard 【参照ページ】Hybrid key exchange in TLS 1.3 draft-ietf-tls-hybrid-design-16 【参照ページ】Cultivating a robust and efficient quantum-safe HTTPS 【参照ページ】ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager 【参照ページ】Using hybrid post-quantum key exchange with AWS Transfer Family 【参照ページ】Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms 【参照ページ】預金取扱金融機関の耐量子計算機暗号への対応に関する検討会報告書 【参照ページ】G7サイバー・エキスパート・グループによる金融セクターにおける耐量子計算機暗号への移行に向けた協調的なロードマップの推進に関するステートメントの公表について

菊池尚人

チーフコンサルタント 兼 事業開発室長

2016年新卒から10年コンサルティング業界に従事。2019年より現職。 大手企業・金融機関向けESG戦略・投資アドバイザリーのリードに加え、 サステナビリティ経営に関する研修講師、Sustainable Japan編集も務める。