現状のPQCアルゴリズムは、性能、鍵長、セキュリティの面でそれぞれ一長一短がある。そうした中で2024年8月、米国立標準技術研究所（NIST）は、PQCアルゴリズムに関する初の連邦情報処理標準（FIPS）を最終決定した。この標準は、技術的な互換性を高め、PQCの導入を後押しすることを目的としている。

　調査分析企業Everest Groupでバイスプレジデントを務めるムケシュ・ランジャン氏は、大手クラウドベンダーの動向を次のように分析する。「TLS（Transport Layer Security）やVPN（仮想プライベートネットワーク）、鍵管理といった主要領域で、PQC準拠の暗号化を組み込んだサービスを提供し始めている。ただし2025年時点では、本格的な導入というよりは実験や準備という段階だ」

　クラウドサービスは、PQC移行に伴うリスクを安全な環境に分離したり、既存の暗号とPQCを組み合わせたハイブリッド暗号モデルをテストしたり、システム間の相互運用性を検証したりする上で大きな利点がある。特に、クラウドネイティブなシステムは一元管理されているため、PQCへの移行を比較的スムーズに進めやすい。ただしクラウドサービスでは場所やサービスごとに異なる暗号技術が使われていることがあり、移行作業は依然として複雑な調整が必要だ。

　ランジャン氏は、「クラウドサービスは企業システム全体に変更を加える前に、管理下で試験運用をするための最適な隔離環境になる」と説明する。

　一方でレガシーシステムやオンプレミスシステム、組み込みシステムへのPQCの導入では、企業はさらなるリスクと複雑さに直面する。ランジャン氏によると、オンプレミスシステム向けの支援は、ツールキットやドキュメントの提供に限られがちだ。組み込みシステムはさらに対処が遅れており、その対策は半導体メーカーやOEM（相手先ブランド製造）メーカーに委ねられているのが現状だ。

PQC移行における4つの課題

　PQCへの移行にはさまざまな課題が伴う。企業はこれらの課題解決に積極的に取り組むことで、量子コンピュータによって既存の暗号が脅かされる時代に向けたセキュリティを強化できる。

　企業が利用するシステムは、独自の暗号化を実装しており、中にはハードコーディング（ソースコードに直接値を書き込むこと）されたものや、文書化されていないものもある。「現代の企業は、メインフレームからクラウドサービス内の仮想マシン、コンテナ化されたマイクロサービスに至るまで、数十年にわたって蓄積された多様なインフラを運用している」。量子サイバーセキュリティベンダーQuSecureの共同創業者兼CEOであるレベッカ・クラウトハイマー氏は、そう指摘する。

　実装方法が標準化されていないことも課題だ。例えばネットワーク通信を保護する場面では、通信事業者によっては、通信時の鍵交換にPQCの仕組みを直接組み込む代わりに、より実装が簡単な方式「耐量子事前共有鍵」を使う場合がある。このように、具体的な実装方法はソフトウェア開発者に委ねられているのが現状だ。

　コンサルティング企業Accentureで量子技術のグローバルリードを務めるカール・デュカッツ氏は次のように語る。「どのPQCアルゴリズムを使うのかという点では世界的な合意が成されているものの、それをどう実装するのかについては、唯一の決まった方法はまだ存在しない」

　ギボンズ氏も、PQCへの移行の主な課題は、既存システムの運用上およびアーキテクチャ上の複雑さに根差していると分析する。特に課題となるのは、以下の分野だ。

1．レガシーシステム

　レガシーシステムは一般的に「暗号アジリティ」（暗号アルゴリズムを容易に切り替えられる能力）に欠けており、新しいPQCアルゴリズムを組み込むことが難しい。レガシーシステムは、ハードコーディングされた暗号化や、公式サポートが終了しているプロトコルを用いていることがしばしばだ。そのような技術は、PQCが要求する、より長い鍵長や新しい暗号化アルゴリズム構造を想定していないため、正常に処理できずシステムの誤作動を招く場合がある。

2．可視性と資産の棚卸し

　自社のシステム全体で、どこでどのように暗号技術が使われているのかを完全に把握できている企業はごくわずかだ。そうした「暗号資産の棚卸し」が不十分な状態では、PQCに移行するためにどの暗号技術やシステムを更新する必要があるのかを特定すること自体が大きな問題になる。

3．依存関係の管理

　レガシーなライブラリ（プログラム部品群）やソースコード非公開のベンダー製ソフトウェアの利用が、移行の障壁になることがある。PQCに準拠していないライブラリやHSM（ハードウェアセキュリティモジュール）、特定のAPI（アプリケーションプログラミングインタフェース）などを更新、置換するには、多大なコストと時間がかかる可能性がある。

4．システムへの組み込みと更新

　新しい暗号プリミティブ（暗号の基本要素）を導入するには、ファームウェアからAPI、アプリケーション層に至るまで、ソフトウェア全体にわたる更新が必要になる。特に、暗号技術がシステムの中心に深く組み込まれた密結合なシステムでは、PQC準拠の暗号技術を後から導入することは難しい。

　アプリケーション開発には、APIの使用やTLSへの準拠といった共通のアプローチが存在するものの、システム全体の構築には普遍的な設計パターンはない。つまり各システムにPQC準拠の暗号化を組み込む作業は、慎重に進める必要がある。

　「システムの多様性と、それぞれに施されたカスタマイズが、この移行を困難にしている」とデュカッツ氏は指摘する。クラウドサービスを使っている場合、企業が自身でシステムを更新しなくても、クラウドベンダーがサービスのアップグレードの一環として、PQC準拠の暗号化技術を扱えるようにする可能性がある。ただし自動更新の対象外であったり、更新そのものが不可能なシステムであったりする場合は、通信の暗号化といった直接的な対策以外の方法でシステムを保護する必要がある。

　デュカッツ氏は、「これらの更新を展開するには時間がかかる上に、展開における各段階で新技術の学習やテストが不可欠だ」と述べる。

　次回は、PQCに関するクラウドベンダーの動向と、企業がPQC移行を進める上での具体的な手順を解説する。