おさらい
AWS 105万人 vs 量子エンジニア 1,300人：数字で見る“圧倒的格差”では、量子エンジニアが少ない理由として「技術成熟度の差・参入難易度の差・実行環境の差」という3つの要因で整理し、それら3要因が量子コンピュータをクラウドシステムに統合するにあたっての4つの壁につながることを書きました。
| 格差を生む3要因 | 量子×クラウドの4つの壁 |
|---|---|
| 技術成熟度の差 | 第1の壁：ハイブリッドアーキテクチャの複雑性 |
| 参入難易度の差 | 第2の壁：プログラミングモデルとAPIの分断 |
| 実行環境の差 |
第3の壁：量子時代のセキュリティ問題 第4の壁：量子クラウドの待ち行列問題 |
今回、取り上げるのは3つめの壁、 量子時代のセキュリティ問題 です。
4つの壁の中で、「実行環境の差」から生じる課題になります。
前述の記事では、「実行環境の差」として、量子コンピュータの計算リソースの性質に対して、下記の課題を挙げました。
- 量子プロセッサ(QPU)が物理的に希少
- 極低温に冷却する装置や制御装置が必要
- 実行にはクラウド越しの予約が必要
- QPUに投げた実ジョブは待ち行列に入る
- 実機はノイズの影響を受けるため、計算の再実行が複数回必要になることが多い
今回は、量子コンピュータの計算リソースの性質のうち 実行にはクラウド越しの予約が必要 であることを出発点に課題を整理します。
実行にはクラウド越しの予約が必要とは
クラウド越しの予約とは、クラウド上の量子コンピュータに送信したジョブの「実行待ち」を表しています。クラウド上の量子コンピュータに対して送信したジョブは、待ち行列に入ります。「待ち行列に入ってジョブ実行待ち」は、「ジョブ実行の予約」といえるため、ここでは「予約」と表現しています。
量子計算により破壊しうる暗号技術
新しい技術が出現すると、副作用の一つとして何かしらの新しい問題や脅威が出現し、それらへの対策が必要になることがあります。量子コンピュータ関連の技術にいたっては、技術進歩がクラウドコンピューティングの安全性に対する脅威の出現を促進する、という構図があります。
クラウドコンピューティングのセキュリティは、暗号技術に依存しています。現在(記事執筆時点)のクラウド上の仮想マシンやコンテナといったインスタンスに対しては、HTTPなどのアプリケーション層プロトコルにTLS(Transport Layer Security)と呼ばれるプロトコルを組み合わせて、通信を行なうのが一般的です。
TLSでは、何を守るかに応じて様々な暗号方式をセットにして使用します。TLSに使われる通信暗号の仕組みは、古典コンピュータで解くのに時間のかかる「難問」を元に考えられた暗号方式ですが、量子アルゴリズムによって高速に解かれることで、安全性が低下すると言われています。
下記にTLSにおける役割ごとの主な暗号方式に対して、量子コンピュータの進歩によってより短時間で復号可能になるといわれているものを「量子耐性が低い」として、表に整理します。
| 役割 | 用途 | 主な暗号方式 | 量子計算での解読手段 | 量子耐性 |
|---|---|---|---|---|
| 鍵交換 | 共通鍵を安全に共有する | RSA鍵交換（TLS1.2まで）, DH, ECDHE | Shorのアルゴリズム （素因数分解・離散対数問題を高速に解く） |
△ 量子耐性が低い |
| 認証 | 正しいサーバであることを確認 | RSA署名, ECDSA, EdDSA | Shorのアルゴリズム （公開鍵暗号・楕円曲線暗号を破る） |
△ 量子耐性が低い |
| データ暗号化 | 通信内容（HTTPデータ）の秘匿 | AES-128/256, ChaCha20 | Groverのアルゴリズム （総当たり探索を平方根高速化） |
◯ 比較的量子耐性が高い |
| 完全性検証 | 改ざん検出・認証 | AEAD（AES-GCM, ChaCha20-Poly1305） | Groverのアルゴリズム（影響は限定的） | ◯ 比較的量子耐性が高い |
| ハッシュ | 署名検証・鍵導出 | [SHA-256, SHA-384] | Groverのアルゴリズム（探索高速化のみ） | ◯ 比較的量子耐性が高い |
「量子耐性が低い」と言われているのは、鍵交換と認証に使われている暗号方式になります。
現在(記事執筆時点)での量子コンピュータには、ノイズ(誤り)が多く存在する世代です。暗号を解く過程で誤りなく継続して計算が必要になるため、理論的には可能であるものの、実際には解読完了に至っていないようにも感じられます。
しかし、量子コンピュータの技術進歩を見越して、今は解読が困難な暗号化データを保存しておき、量子計算機での暗号解読が可能となった後に復号・解読を行う HNDL(Harvest-Now Decrypt-Later)攻撃 という脅威が認識されはじめています。
この脅威は、国家安全保障のリスクになることから、量子耐性の高い暗号方式の標準化が進んでいます。
量子の高い暗号方式は、PQC(Post-Quantum Cryptography) や 耐量子計算機暗号 と呼ばれています。
米国立標準技術研究所（NIST）では、2022〜2024年にかけてPQCの標準アルゴリズムを決定しています。代表例は以下の通りです。
- 鍵交換方式
- 電子署名方式
標準名と実装名
上記はNISTが標準化したアルゴリズムの名称です。ここでは標準名に対応する実装名について触れませんが、暗号化ライブラリやプロトコルにおける実装名が必ずしも標準名と一致するとは限りません。
そして、2025/6/6に発行されたアメリカの行政命令では、PQC実装の前提となるTLSをVersion 1.3または後継バージョンを2030年1月2日までにサポートする要件を出す旨の命令が出ています。
By December 1, 2025, to prepare for transition to PQC, the Director of the National Security Agency with respect to National Security Systems (NSS), and the Director of
OMB with respect to non-NSS, shall each issue requirements for agencies to support, as soon as practicable, but not later than January 2, 2030, Transport Layer Security
protocol version 1.3 or a successor version.";
日本政府でもPQCへの移行に関して、2025年11月の中間とりまとめ結果が公表されています。
「政府機関等の耐量子計算機暗号(PQC)への移行に向けた工程表(ロードマップ)(骨子)」として、
４．耐量子計算機暗号（PQC）への移行期限及び暗号技術の利用に係る停止の時期
（１）耐量子計算機暗号（PQC）への移行期限
原則として、2035 年を目処に、耐量子計算機暗号（PQC）へ移行を行うこととする。
とあり、既に量子コンピュータの進歩により発生する新たな脅威への対策に向けた取り組みが国家レベルで着手に入っていることがわかります。
PQCの移行が必要な背景をもっと簡単に理解する
情報処理推進機構(IPA)より発行されている情報セキュリティ白書2025は、刊行物の性質上、平易な言葉遣いで丁寧に説明されており、わかりやすいです。
量子コンピュータをクラウドシステムに統合する際に発生するセキュリティ観点での問題
ここからが本題となります。量子コンピュータをクラウドシステムに統合するにあたって、セキュリティ観点での問題を考えみます。まず、システムのセキュリティ脅威は「点」ではなく「面」で防御することが一般的な捉え方です。そして「面」を何層にも重ねることによって、セキュリティを強化します。
「点」ではなく「面」で守る
たとえば「ファイアウォールを入れたから安全」「強いパスワードを設定したから大丈夫」と考えるのは、“点”で守っている状態です。しかし、許可された通信経路を悪用されたり、パスワードが盗まれたりすれば、その1つの対策は突破されてしまいます。
そのため、ファイアウォールに加えて二段階認証やアクセス制御、ログ監視など複数の対策を重ね、「面」として層状に構成し、「一つ破られても次で止める」構造にすることが重要です。このような考え方は「多層防御（Defense in Depth）」と呼ばれています。
- 参考:
- AWS（日本語）
- AWS Well-Architected フレームワーク – セキュリティの柱では、「すべての層にセキュリティを適用する 」とあります。
- Microsoft Azure（日本語）
- NIST（英語）
- AWS（日本語）
量子コンピュータでのプログラム実行にはクラウド越しの予約が必要になりますので、攻撃者から見れば、クラウドへの通信経路は攻撃可能な「面」と捉えることができます。
クラウド上の量子コンピュータへの通信内容として、
- QPU へ送るジョブ
- ジョブの実行結果(測定値)
- 回路情報
- 実機パラメータ
といったものがありますが、これらはセキュリティの観点から、TLSで暗号化して通信することとなります。従来の暗号方式で防御している「面」が量子コンピュータによって破られ、「面」に「穴」ができるとすれば、TLSで使用している従来の暗号方式を新しい暗号方式であるPQCに移行する必要性がでてきます。
この必要性がクラウドサービスの性質、クラウドの特徴的な使い方であるマルチクラウド、マルチリージョン、マルチベンダーにどのような影響があるか見てみましょう。
ポイント1. SaaS・WebAPIにおけるクラウドベンダーの対応待ちボトルネックの発生
クラウドサービスには、クラウドユーザーとクラウドベンダーの間に境界があります。ユーザーから見たクラウドベンダーのクラウド技術の実装は、ブラックボックスです。
特にクラウドサービスの下層をユーザーから隠蔽するようなSaaS・WebAPIにおいては、アプリケーション側で対応できないものについては、クラウドベンダーの対応を待たなければならず、対応待ちのボトルネックが発生します。
そしてとても厄介なのが、ベンダーの対応優先度は、ユーザー側でコントロールできないことです。
クラウドベンダー側としても、脅威の影響範囲を最小限の手間でできるだけ小さくするため、最も利用者が多く、人気のサービスから順に対応を進めると考えるのは、理にかなっており、ごく自然だといえます。
したがって、利用者の少ないマイナーなサービスの対応について、対応優先度が低くなるとすれば、対応完了まで、脅威にさらされる「面」と付き合わざるを得ない状態になります。
PQC対応への温度差
各クラウドベンダーのPQC対応については、積極的にGAをしていたり、Preview版をリリースする、対応ロードマップのみ公開、公開情報なしだったりと、対応方針に温度感の違いがあります。対応範囲についても、クラウドとの外部通信間はPQC対応、内部のService Meshとしてのサービス間通信はPQC未対応というように、各クラウドベンダーごとにばらつきがあるようです。共通しているのは、徐々に対応範囲を広げる点です。
ベンダーの対応を待っていられない！ということで、ボトルネックを解消するために、SaaSからIaaSへ移行して、PQC方式に対応した通信の暗号化や証明書の生成・管理を行なうツール・ライブラリをインストールして対応する方法も考えられます。
しかし、マネージドサービスに依存しているようなクラウドシステムでは、もともとマネージドであった部分の開発や運用の手間が増える、製品品質を再担保のため再帰試験が必要になることも考えられます。IaaSに移行することが万能解・最適解になるとは限りません。そのため、記事執筆時点では、PQC対応のためにSaaSからIaaSへの移行というのは、かなり勇気がいる判断になります。
ポイント2. 新旧暗号方式混在によるセキュリティの「面」への「穴」
対応待ちのボトルネックによって、PQC対応/非対応の通信経路やサービスが混在することになります。システム全体から見れば、PQC非対応の箇所が「穴」となり、システムのセキュリティとしての「面」が機能しなくなってしまいます。
Service Meshを例に挙げると、クラウド外部との通信(Service Meshの外側)がPQCに対応しているが、Service Mesh内部がPQC非対応のケースがあてはまります。Service Meshでは通常、サービス間通信をTLSで守るのですが、そのTLSが従来の暗号方式のみで、PQC未対応だった場合、内部通信が量子耐性を持たないことになります。
そして、システムに新旧暗号方式が混在していると、どこが対応済でどこが未対応であるかの「境界」を把握・管理することにコストがかかってきます。
クラウド技術のトレンドとして、マイクロサービス、コンテナといったクラウドネイティブ志向の技術があります。システムの構成要素を容易かつ短時間に複製できる点でとても便利です。
その一方で、複製の容易さは、管理の容易さとトレードオフの関係です。
例えば、「ビジネスの中断をできるだけ防ぐために、暗号方式はクライアントに応じてPQC適用を選択できるようにしておく」は、柔軟な設計である一方、意外と見落としがちな「穴」になることがあり、「どのコンテナ・どのサービスで量子耐性があるか？」について、管理と把握が必要になってきます。
上記に挙げた「通信経路やサービスにおける対応が不統一な状態」は、下記のマルチクラウド、マルチリージョン、マルチベンターといった使い方をするケースでも同様の問題があります。
ポイント2-1. マルチクラウドで起こる新旧暗号方式混在による運用コスト増
マルチクラウドで複数のクラウドベンダーを跨ぐようなシステムの場合だと、「ベンダーAは、PQC移行が完了している」、「ベンダーBは、まだPQCの移行が完了していない」という制約から、旧来の暗号方式とPQCをハイブリッドで運用する形態になる可能性もあります。
システム全体としてみると、PQCで守られていない箇所は「穴」となってしまい、脅威から防御する「面」としての機能が失われてしまいます。
ポイント2-2. マルチリージョンでも起こるクラウドベンダーの対応待ちボトルネックの発生
クラウドには「マルチリージョン構成でリソースを使用する」というケースがあります。
クラウドベンダーは、クラウドサービスを継続的に機能させるためのインフラやデータセンターを各国、各地に展開しています。マルチリージョン構成では、これら複数のリージョンを組み合わせてシステムを構築します。
例えば、A国で大規模障害が発生した場合、A国内のデータセンター上に構築したクラウドシステムが利用できなくなる可能性があります。こうした事態に備えてシステムの冗長性を高めるため、同じ構成のシステムをA国とB国のデータセンターに構築したり、A国では提供されていないもののB国で提供されているサービスを利用したりする、といった方法が取られます。
このようなマルチリージョン構成においても、クラウドベンダーの対応方針によっては、PQCへの移行が完了しているリージョンと未完了のリージョンが混在する可能性があります。そのため、クラウドベンダーの対応待ちというボトルネックに加え、マルチクラウドの場合と同様に、暗号方式をハイブリッドで運用する必要が生じる可能性があります。
ポイント2-3. マルチベンターにおけるシステム仕様の統一におけるボトルネックの発生
複数のクラウドシステムが接続されて、1つの大きなシステムを構成しているような形態についても考えてみます。
システムの役割に応じて、開発を担当するベンダーが異なるようなシステムが存在します。いわゆるマルチベンターのシステムです。
システムとシステムの間に、ベンダー間の境界がある形となるため、これらのシステムを接続するインターフェース仕様を整理しなければなりません。ここに「参入難易度の差」が入り込み、ベンダーごとに耐量子計算機暗号に対する実装ノウハウに差が出てくると、システム仕様の統一において、ボトルネックになる可能性がでてきます。
これが、実行環境の差として表れてきます。
ポイント3. PQC採用によって増加する通信オーバーヘッドによるコスト増
クラウド特有の使い方で発生する問題を見ていきましたが、ここではシステム性能面での影響を考えてみます。
一般に、PQCでは従来の暗号方式と比べて、鍵や署名のサイズが大きくなる傾向があります。従来は数十〜数百バイト程度であったものが、方式によってはキロバイト単位となる場合もあり、数倍から十倍程度のサイズ差が生じるケースもあります。
このサイズ増加は、ワークロードによっては通信オーバーヘッドとして無視できない影響を持つ可能性があります。例えば、次のような特性を持つシステムでは注意が必要です。
- 高頻度でTLS接続を確立するアプリケーション
- IoTシステム
- デバイスの移動により通信帯域や接続性が不安定
- バッテリや計算資源が限られたエッジデバイスを使用
TLSでは鍵交換は主にハンドシェイク時に実行されますが、短時間の接続を高頻度で繰り返す構成では、そのオーバーヘッドが積み重なる可能性があります。
また、鍵生成・署名・検証といった暗号処理に関しても、方式によっては従来より計算量が増加する場合があります。大量の同時接続を処理するサーバーではCPU負荷の増加要因となり得ますし、IoTのエッジデバイスでは、より大きな鍵や署名を保持・処理するためのメモリや計算資源の確保が必要になる場合があります。
クラウド環境においては、CPU使用時間や通信量が従量課金の対象となることが一般的です。そのため、ワークロードの特性によっては、PQC移行に伴うリソース使用量の増加がコストに影響する可能性があります。
例えば、IoTシステムでは、多数のセンサ（エッジデバイス）からクラウドへデータを集約し、ソフトウェア更新を配布するようなスター型やツリー型のトポロジが採用されることが多く見られます。このような構成では、クラウド側の通信量や処理負荷の増加に応じて、インスタンスのスケールアップやスケールアウトが必要となる場合があり、設計段階での検討が求められます。
さらに、PQCへの移行は一度に完了するものではなく、段階的に進められることが想定されます。その過程では、従来暗号とPQCを併用するハイブリッド運用が必要になる場面もあり、設定管理や検証作業の増加といった運用上の負荷が発生する可能性があります。
このように、PQCはセキュリティ強化の観点から重要な技術ですが、性能・リソース・運用・コストといった側面も含めて総合的に設計を見直す必要があります。
まとめ
量子×クラウドの“第3の壁”である 量子時代のセキュリティ問題では、
「実行環境の差」を起点として、量子コンピュータを統合したクラウドシステムのアーキテクチャを設計するにあたっては、以下のような課題が潜んでいると整理できます。
- クラウドコンピューティングは暗号通信に依存する箇所がある
- 暗号通信に適用されている従来の暗号が量子コンピュータによって解読される可能性がある
- PQCへの移行を見据えた場合
- SaaSやWebAPIではクラウドベンダー依存の「待ち」が発生する
- 「マルチ～」でクラウドシステムを使用する場合、ベンダーの対応スピードが「実行環境の差」を生み、そのままボトルネックになる可能性がある
- PQCにおける通信において「実行環境」がリソース、コスト面のボトルネックになりうる
"第3の壁"は、4つの壁の中で、国家レベルでHNDL攻撃の脅威が認識されており、脅威に対する計画の策定が進んでいることもあり、4つの壁の中では、もっとも解決が必要であることが伝わりやすいのではないでしょうか。
従来の暗号が解ける量子コンピュータの実用化と解読アルゴリズムがデプロイされる時期が不確実ではありますが、"第3の壁"は、優先して「壁」を超えることを見越して、将来の設計に反映する必要がありそうです。
既存のシステムについては、身の回りにある環境がPQCに対応しているか否か、絶対堅守が必要なデータの有無を調べるのが最初の一歩になりそうですね。
クラウドの基盤技術面でのPQC対応状況
主要なOSS関連コミュニティにおいて実装があり、PQCへ移行するための準備が進んでおります。
-
OpenSSL
- 2025/4リリースのVersion 3.5.0からPQCのサポートが始まっています。
-
OpenSSH
- 2022/4リリースのVersion 9.0からサポートが始まっています。
- Version 10.1からは、PQCによる鍵交換を適用していないサーバにSSH接続すると、接続がPQCで保護されておらず、サーバのアップグレードを促すメッセージが出力されるようになっています。
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
-
Redhat Linux 10
- PQCのサポートをTechnology Previewとして提供しています。
-
Open Quantum SafeプロジェクトのDockerイメージ
- Linux Foundation内でAWS、CISCO、Google、IBMがPremier MembersとなっているPost-Quantum Cryptography AllianceのOpen Quantum Safeプロジェクトでは、耐量子計算機暗号の実装をまとめたDockerイメージopenquantumsafe/oqs-ossl3を公開しています。このイメージでは、TLS 1.3のハンドシェイクを試すことができます。
Crypto Agility
従来の暗号アルゴリズムの陳腐化に備えてすばやく新方式の暗号アルゴリズムへ移行できる能力のことをCrypto Agility（暗号アジリティ）と言います。
- NISTでは、PQC暗号への移行に必要な要素としています。
- IETFでは、RFC 7696にて、「Cryptographic Algorithm Agility」として、移行のしやすい暗号アルゴリズム設計・実装内容をガイドラインとしてまとめています。OpenSSH 10.1の「移行を促す警告文を出力する仕様」は、2.6章でも言及があります。
次回予告
次回は、いよいよ最後の壁、「実行環境の差」を要因として発生する、第4の壁：量子クラウドの待ち行列問題について整理していきます。