🚀 3分でわかるこの記事のサマリー
- 何がやばい？： 量子コンピュータ実用化後に、RSAやECCで保護された過去の通信が解読される「Harvest Now, Decrypt Later」攻撃のリスクに対し、実用化後の対策では手遅れになる。
- どんな対策がある？： 量子コンピュータでも解読困難な数学的基盤を持つ「耐量子暗号（PQC）」への移行が進んでおり、米大統領令を起点に政府・連邦機関への移行義務付けが本格化している。
- エンジニアはどうすべき？： 世界標準はいずれ日本の要件（2035年頃を見据えたロードマップなど）になる。主要OSSの動向を追い、将来の切り替えを見据えた「暗号アジリティ（俊敏性）」を確保すべき。
はじめに
近年、量子コンピュータの技術発展に伴い、現在の公開鍵暗号方式（RSAや楕円曲線暗号：ECCなど）が突破されるリスクが現実味を帯びてきています。
先日も「政府機関の暗号が破られる懸念から、大統領令をベースに耐量子暗号（PQC）への移行を義務付け」というニュースが話題になりました。
「量子コンピュータなんてまだ実用化されてないし、対策は先でいいでしょ？」と思っていませんか？
実は、それでは遅すぎる明確な技術的理由があります。本記事では、その背景にある脅威と、現在急速に進んでいる耐量子暗号（PQC）の最新動向をまとめました。
1. 狙われる「過去のデータ」：Harvest Now, Decrypt Later
なぜ今すぐ対策が必要なのか。その最大の理由は**「Harvest Now, Decrypt Later（今、収穫して、後で解読する）」**と呼ばれる攻撃手法にあります。
【現在のタイムライン】
攻撃者：通信を盗聴 ──> 暗号化されたデータをそのまま保存（収穫）
│
▼ （数年後〜数十年後：ショアのアルゴリズムが実用化）
【未来のタイムライン】
攻撃者：高性能な量子コンピュータを調達 ──> 保存していた過去の公開鍵暗号データを爆速で解読
攻撃者は、今この瞬間も暗号化された通信パケットを盗聴し、ストレージにそのまま保存しています。現時点では解読できなくても問題ありません。数年後、あるいは数十年後に強力な量子コンピュータが誕生した瞬間、過去に遡ってすべての機密データが丸裸にされることになります。
※本記事では主に、量子コンピュータによって数理的に突破されるリスクがあるRSAやECCなどの「公開鍵暗号」への影響を扱います。
つまり、長期的に保護すべきデータ（医療情報、国家機密、企業の知的財産など）は、「今、暗号化して送っているから安全」とは言えないのです。
システムが完成してから慌てて暗号をアップデートしても、すでに盗まれて保存されている「過去のパケット」は救えません。だからこそ、実用化前の「今」このタイミングで移行へのロードマップが急がれているのです。
2. NISTによる「耐量子暗号（PQC）」の標準化
この脅威に対抗するため、NIST（米国標準技術研究所）は長年にわたり「耐量子暗号（PQC：Post-Quantum Cryptography）」の標準化を進めており、最初の正式規格（FIPS）が公開されています。
これらは主に「格子暗号」という、量子コンピュータでも解くのが困難な数学的理論をベースに作られています。
現在、デファクトスタンダードとして策定されている主要なアルゴリズムは以下の通りです。NISTの標準化に伴い、開発時のコードネームから正式な規格名へと名称が変更されています。
ML-KEM (旧称: Kyber) [FIPS 203]
- 用途: 鍵交換（主にWeb通信のTLSなどで利用）
- 特徴: 処理速度が非常に速く、鍵サイズも実用的。今後の通信暗号化の主役。
ML-DSA (旧称: Dilithium) [FIPS 204]
- 用途: デジタル署名（認証や証明書の検証）
- 特徴: 今後の電子署名のデファクトスタンダードとなる位置づけ。
SLH-DSA (旧称: SPHINCS+) [FIPS 205]
- 用途: デジタル署名
- 特徴: ハッシュ関数をベースにした署名方式。格子暗号に万が一の脆弱性が見つかった場合のバックアップとして標準化。
3. 主要プロトコル・ライブラリの対応状況（OpenSSL / OpenSSH）
「新しい暗号への移行」はすでに始まっており、私たちが普段使っているOSSでも実装が進んでいます。
ここで重要なキーワードが「ハイブリッド方式（Hybrid Cryptography）」です。まだ歴史の浅いPQCアルゴリズムに未知の脆弱性があるリスクを考慮し、「従来の安全な暗号（X25519など） ＋ 新しい耐量子暗号」を組み合わせて同時に使うアプローチが主流になっています。
- OpenSSH: すでにバージョン 9.0から、耐量子暗号を取り入れたハイブリッド鍵交換方式がデフォルトで有効になっています。1
-
OpenSSL: かつてはOQSプロジェクトの
oqs-providerを別途導入する必要がありましたが、OpenSSL 3.5以降では ML-KEM / ML-DSA / SLH-DSA がネイティブにサポートされ、標準機能としてPQCが利用可能になりました。 - Webブラウザ（Chromeなど）: Google ChromeやCloudflareなどでは、すでにX25519とML-KEMを組み合わせたハイブリッド鍵交換の実運用が進んでおり、日常の通信が足元でPQCによって保護され始めています。
4. 世界の動向はいずれ「日本の標準（義務）」になる
「米政府の動きなんて、日本の一般的な開発者には関係ないのでは？」と思うかもしれません。しかし、これまでの歴史（NISTのガイドラインや欧州のGDPRなど）が示す通り、海外の世界標準は数年遅れで必ず日本の政府基準や法令、各種ガイドラインに組み込まれ、事実上の要件となります。
現時点で、米政府はPQC移行方針を強力に推進しており、連邦機関向けに具体的な移行期限を設定、OMB（行政管理予算局）やNSA（国家安全保障局）が詳細なガイドラインを発行しています。
そして国内でも、すでに具体的なロードマップの検討が始まっています。
- 政府の方向性: 内閣官房は2025年11月に「政府機関等における耐量子計算機暗号（PQC）への移行について（中間とりまとめ）」を公表し、「我が国も2035年を目標としてPQCへの移行を進めていく」という方向性を明記しました。さらに同資料では、機微な情報や長期保護が必要な情報については「HNDL攻撃という現に直面しているリスクに留意し、より早期に移行することも含めて検討すべき」 とも言及されています。
- 国内暗号リストの動向: 総務省・経産省などが推進する「CRYPTREC」でも、電子政府推奨暗号リストの改定に向け、NIST標準（FIPS 203 / 204 / 205）を対象としたPQCの安全性評価・実装性能評価がすでに開始されています。
「外圧」によって国内のセキュリティ要件が書き換わるのは時間の問題です。ISMSや政府系案件、金融・インフラ系システムに関わるエンジニアにとって、PQCは「いつかやればいい技術」ではなく、「数年以内に対応を求められる可能性が高いシステム要件」なのです。
5. 今から現場でできること：暗号アジリティの確保
では、私たち現場のエンジニアは今から何から始めればよいでしょうか？
大げさな対策を始める必要はありません。まずは以下の3点を確認してみることからがスタートです。
- OpenSSLやOpenSSHのバージョン: レガシーな環境（OpenSSL 1.x系など）のまま放置され、PQCに対応できない状態になっていないか。
- TLS終端やVPN機器の更新計画: インフラ機器やミドルウェアのロードマップに、将来的なPQC（またはハイブリッド方式）のサポートが含まれているか。
- アプリケーションの依存度: 特定の暗号アルゴリズム（例: RSA 2048）をソースコードに直接ハードコードせず、設定変更で切り替えられる設計になっているか。
重要なのは、将来RSAやECCから別の方式へスムーズに切り替えられる「暗号アジリティ（Crypto-agility：暗号の俊敏性）」を意識したシステム設計・運用を始めておくことです。
まとめ
量子コンピュータによる暗号解読は、未来のSFではなく「現在のパケット盗聴」から始まっているリアルな脅威です。
主要国が政府機関への移行を促し、国内でも2035年頃を目安にした議論が進んでいるのは、このタイムリミットが迫っているからに他なりません。「まだ先の話」と片付けず、まずは自社システムが依存している暗号環境の確認から始めてみてはいかがでしょうか。
量子コンピュータの脅威は、「完成した瞬間」ではなく、「今盗まれているデータが、未来に解読されること」にあります。
だからこそ、PQCへの移行は"未来の課題"ではなく、すでに始まっている "現在進行形のセキュリティ課題" なのです。
-
バージョンによって採用されているPQCアルゴリズムは異なります（初期の
sntrup761x25519-sha512@openssh.comから、NIST標準化に伴うmlkem768x25519-sha256への移行など）。しかし、「現行暗号＋PQCのハイブリッドで守る」という設計思想は一貫しています。 ↩