耐量子暗号とは何か：なぜ今移行準備が必要なのか

Posted at 2026-07-01

概要

ネットショッピングでクレジットカード情報を入力する。
スマホ決済で支払いをする。
ブラウザで銀行のWebサイトにアクセスする。
アプリをアップデートするときに、配布元が本物か確認される。

普段はあまり意識しませんが、こうした場面の裏側では、暗号技術がたくさん使われています。

たとえば、WebサイトのURLが https:// から始まっているとき、ブラウザとサーバーの間では、通信内容を盗み見られにくくしたり、途中で書き換えられていないか確認したり、本物のサーバーにつながっているか確かめたりしています。

ここで大切な役割を持つのが、公開鍵暗号やデジタル署名、鍵共有といった技術です。
これらは、インターネット上で初めて通信する相手と安全にやり取りするために欠かせない仕組みです。

しかし近年、この公開鍵暗号の一部について、将来の強力な量子コンピュータによる影響が注目されています。

もちろん、これは「明日からスマホ決済やHTTPSが全部危険になる」という話ではありません。
今すぐ日常のサービスが一斉に使えなくなる、という意味でもありません。

ただし、暗号技術は社会のかなり広い範囲に埋め込まれています。
Web通信、電子証明書、ソフトウェア署名、VPN、クラウド、金融システム、行政システム、IoT機器など、影響範囲はとても広いです。

そのため、将来のリスクが見えてから一気に置き換えるのでは間に合わない可能性があります。

この文脈で登場するのが、耐量子暗号です。

耐量子暗号は、ざっくり言うと、将来の強力な量子コンピュータでも破られにくいことを目指して設計された暗号技術です。
英語では Post-Quantum Cryptography と呼ばれ、よく PQC と略されます。

ここで少しややこしいのは、「耐量子暗号」は「量子コンピュータを使う暗号」ではないという点です。
量子コンピュータや量子通信装置を使うのではなく、基本的には現在のコンピュータ上で動かせる、新しい種類の暗号方式です。

💡 豆知識
「Post-Quantum」という言葉は、「量子コンピュータの後に使う」というよりも、「量子コンピュータによる攻撃も考えたうえで使えるようにする」という意味で捉えると分かりやすいです。
つまり、PQCは未来だけの話ではなく、現在のシステムを将来に備えさせるための技術です。

耐量子暗号への移行が重要なのは、量子コンピュータが完成してから考えればよい、という話ではないからです。

たとえば、今やり取りされている暗号化データの中には、数年後、十数年後にも秘密であるべき情報があります。
医療情報、研究開発情報、契約情報、行政情報、金融関連の情報などは、長い期間守る必要があります。

もし攻撃者が今のうちに暗号化された通信を保存しておき、将来十分に強力な量子コンピュータが使えるようになってから解読するとしたらどうでしょうか。

このような考え方は、Harvest Now, Decrypt Later と呼ばれます。
直訳すると「今収穫して、後で解読する」という意味です。

つまり、耐量子暗号の話は、まだ存在しない未来の攻撃だけを心配しているのではありません。
長期間守るべき情報については、「今」の通信や保存データが、将来のリスクとつながっている可能性があります。

また、暗号の移行は、ライブラリを1つ差し替えれば終わるような単純な作業ではありません。

どこでどの暗号方式を使っているのかを調べる。
証明書や鍵管理の仕組みを確認する。
外部サービスや古い機器が新しい方式に対応できるかを確認する。
通信サイズや処理速度への影響を検証する。
万が一、将来別の方式に変える必要が出たときに備えて、入れ替えやすい設計にしておく。

このように、実際にはかなり地道な準備が必要になります。

本記事では、耐量子暗号について、次の流れで整理します。

そもそも今の暗号技術はどこで使われているのか
量子コンピュータは現在の暗号にどのような影響を与えるのか
「量子コンピュータですべての暗号が危ない」はどこまで正しいのか
本当に意識したい Harvest Now, Decrypt Later とは何か
耐量子暗号は何を置き換える技術なのか
NIST標準化では何が決まっているのか
暗号アジリティやハイブリッド方式をどう考えるのか
耐量子暗号だけで安全になるわけではない理由

この記事のゴールは、耐量子暗号の数式や内部構造を細部まで理解することではありません。
まずは、耐量子暗号がなぜ必要とされているのか、そしてなぜ「今から準備する」という話になるのかを、全体像としてつかむことを目指します。

長い記事なので、すべてを一度に理解しようとしなくても大丈夫です。
最初は「量子コンピュータで何が変わるのか」「今から何を準備するのか」だけを追い、気になる章をあとから読み返すくらいの温度感で読んでみてください。

この記事で分かること

身近なサービスの裏側で、公開鍵暗号・証明書・鍵共有・デジタル署名がどのように使われているか
量子コンピュータが現在の暗号に与える影響
RSAや楕円曲線暗号など、公開鍵暗号が特に注目される理由
耐量子暗号が「量子コンピュータを使う暗号」ではない理由
NIST標準化で登場するML-KEM、ML-DSA、SLH-DSAの位置づけ
Harvest Now, Decrypt Later がなぜ移行準備と関係するのか
暗号アジリティやハイブリッド方式を、どのように考えればよいか

対象読者

この記事は、次のような人を想定しています。

情報セキュリティを学び始めた人
暗号技術の全体像を学んだうえで、耐量子暗号についてもう少し知りたい人
「量子コンピュータで暗号が危ない」と聞いたことはあるが、何が危ないのか整理したい人
RSA、楕円曲線暗号、TLS、証明書、デジタル署名などの言葉を、身近な例とつなげて理解したい人
実装に入る前に、PQC移行や暗号アジリティの考え方を整理したい人

本記事で扱わないこと

本記事は、耐量子暗号の全体像と移行準備の考え方を整理することを目的にしています。
そのため、次の内容は深く扱いません。

各PQCアルゴリズムの厳密な数式
格子暗号、符号ベース暗号、ハッシュベース署名などの内部構造の詳細
ML-KEM、ML-DSA、SLH-DSAの安全な実装手順
TLSやSSHにおけるPQC対応の実装コード
量子コンピュータそのものの物理的な仕組み
QKDなど、量子通信装置を使う技術の詳細

ただし、耐量子暗号は現在のTLS、証明書、ソフトウェア署名、鍵管理などと深く関係します。
そのため、本文では既存の暗号技術とつなげながら、どこに影響が出るのかを整理します。

また、本記事に出てくるコードは、考え方を理解するための学習用サンプルです。
実際のサービスでは、自作実装ではなく、利用している言語・フレームワーク・暗号ライブラリの公式ドキュメントや、組織で承認された仕様を確認してください。

コード・図表を見る場合の前提

本記事では、考え方を確認するためにPythonの短いコードやMermaid図を使います。
コードや図表を見るときは、次の前提で読んでください。

項目	内容
目的	耐量子暗号や移行準備の考え方を理解するための学習用
想定環境	Python 3.x系
主な標準ライブラリ	`math`、`hashlib`、`hmac`、`secrets`、`dataclasses` など
外部ライブラリ	この記事ではPQCライブラリの実装例は扱わない
注意点	実際の暗号処理やPQC実装へそのまま流用しない

この記事で示すRSAやKEM、署名、ハイブリッド鍵共有のコードは、すべておもちゃの例です。
実際の暗号として安全ではなく、ML-KEM、ML-DSA、SLH-DSAの実装例でもありません。

全体の流れ

この記事では、次の順番で話を進めます。

1. まず、今の暗号はどこで使われているのか

耐量子暗号の話に入る前に、まずは現在の暗号技術がどこで使われているのかを確認します。

耐量子暗号は、「突然出てきた別世界の技術」というよりも、今のインターネットを支えている暗号技術の一部を、将来に向けて置き換えていくための技術として見ると理解しやすいです。

スマホ決済、ネットショッピング、銀行サイトへのログイン、アプリのアップデート。
これらは別々のサービスに見えますが、裏側では共通して、暗号技術による「安全確認」が行われています。

ここでは、特に次の3つを中心に見ていきます。

通信を守る HTTPS / TLS
相手が本物か確認する 証明書
アプリやソフトウェアの改ざんを検知する デジタル署名

この章のゴールは、細かいアルゴリズムを覚えることではありません。
まずは、「私たちが普段使っているサービスは、思った以上に公開鍵暗号に支えられている」という感覚をつかむことを目指します。

1.1 ブラウザの `https://` の裏側

一番身近な例は、Webサイトにアクセスするときの https:// です。

ネットショッピングで住所や支払い情報を入力するとき、銀行のWebサイトにログインするとき、ブラウザとサーバーの間では TLS という仕組みが使われています。
TLSは、インターネット上でクライアントとサーバーが通信するときに、盗聴・改ざん・メッセージ偽造を防ぐことを目的としたプロトコルです。

参考: RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3

ここでいうプロトコルとは、「通信するときの約束ごと」のようなものです。
人と会話するときにも、最初にあいさつをして、相手を確認して、それから本題に入ります。TLSでも、いきなり重要な情報を送るのではなく、まず安全に通信するための準備を行います。

ざっくり図にすると、次のような流れです。

この中には、複数の暗号技術が組み合わさっています。

場面	何をしているか	関係する暗号技術
サーバー証明書の確認	接続先が本物のサイトか確認する	デジタル署名、公開鍵証明書
鍵共有	通信に使う秘密の鍵を安全に準備する	ECDHEなどの鍵共有方式
通信内容の保護	送受信データを盗み見・改ざんから守る	共通鍵暗号、認証付き暗号

押さえておきたいのは、HTTPSは「1つの暗号」ではないという点です。
実際には、証明書、署名、鍵共有、共通鍵暗号、メッセージ認証などを組み合わせて、安全な通信路を作っています。

1.2 証明書は「Webサイトの身分証明書」のようなもの

HTTPS通信では、ブラウザがサーバーに接続するとき、サーバーは証明書を提示します。
これは、身近な言葉でいうと「このWebサイトは本当にこのドメインの持ち主です」と示す身分証明書のようなものです。

ただし、Webサイトが自分で「私は本物です」と言うだけでは信用できません。
そこで、認証局と呼ばれる第三者が証明書に署名し、ブラウザはその署名をたどって信頼できるかを確認します。

インターネットで使われる公開鍵証明書の形式や検証の考え方は、RFC 5280でX.509証明書として整理されています。

参考: RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile

また、一般に信頼されるTLSサーバー証明書については、CA/Browser Forumが発行・管理に関するBaseline Requirementsを公開しています。

参考: CA/Browser Forum - Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates

ここで出てくる 公開鍵証明書 は、後で耐量子暗号の話と強くつながります。

なぜなら、証明書の中には公開鍵が含まれており、その公開鍵に対応する秘密鍵を持っている相手だけが正しく署名や認証を行える、という前提で成り立っているからです。
現在広く使われている証明書では、RSAや楕円曲線暗号に基づく署名方式が使われる場面があります。

💡 豆知識
ブラウザの鍵マークは、「通信相手との接続が暗号化されている」ことを示す重要なサインです。
ただし、それだけで「そのサイトの運営者が絶対に安全」「入力してよい内容がすべて安全」という意味になるわけではありません。
たとえば、見た目が本物そっくりのフィッシングサイトでも、攻撃者がそのドメイン用の証明書を取得していればHTTPSになる場合があります。
そのため、鍵マークだけで安心せず、URLやアクセス経路も確認する必要があります。

1.3 鍵共有は「その場限りの秘密の合言葉」を作る仕組み

TLSでは、通信内容を大量にやり取りするときには、主に共通鍵暗号が使われます。
共通鍵暗号は、同じ鍵を使って暗号化と復号を行う方式です。

共通鍵暗号は高速に処理しやすいため、Web通信の本文を守るのに向いています。
しかし、ここで問題があります。

まだ安全な通信路がない相手と、どうやって同じ秘密鍵を共有するのか？

これを解くために使われるのが、鍵共有の仕組みです。

イメージとしては、ブラウザとサーバーが、盗み見される可能性のある場所でやり取りしながら、最終的に2人だけが分かる「その場限りの秘密の合言葉」を作るようなものです。
TLS 1.3では、このようにして作った共有秘密をもとに、実際の通信を守るための鍵を導き出します。

この鍵共有にも、現在は楕円曲線暗号を利用した方式が広く使われます。
そのため、将来の量子コンピュータによる影響を考えるとき、鍵共有はとても重要な論点になります。

次章以降で扱う耐量子暗号の代表例である ML-KEM も、この「安全に共有秘密を作る」という役割に関係します。

1.4 アプリのアップデートにも署名が使われている

暗号技術は、Web通信だけでなく、アプリやソフトウェアの配布にも使われています。

たとえば、スマホアプリやPCソフトをアップデートするとき、利用者としては次のようなことを確認したいはずです。

本当に開発元が配布したものなのか
途中で改ざんされていないか
攻撃者が偽物の更新ファイルにすり替えていないか

この確認に使われる代表的な仕組みが、コード署名 や アプリ署名 です。

Androidでは、アプリに署名して公開する流れが公式ドキュメントで説明されています。
また、WindowsのAuthenticodeでは、デジタル署名と信頼された認証局の仕組みを使って、ソフトウェア発行者の身元とコードの完全性を確認する考え方が説明されています。

参考: Android Developers - Sign your app
参考: Microsoft Learn - Authenticode Digital Signatures

NISTのSecure Software Development Frameworkでも、ソフトウェアリリースの完全性を検証する仕組みとして、ソフトウェアにデジタル署名を行うことが挙げられています。

参考: NIST SP 800-218 - Secure Software Development Framework Version 1.1

つまり、デジタル署名は「契約書に電子署名する」ときだけのものではありません。
私たちが普段使うアプリやOSのアップデートにも、裏側では署名による確認が関わっています。

1.5 スマホ決済やネットショッピングでは、複数の暗号技術が重なっている

スマホ決済やネットショッピングでは、暗号技術が1つだけ使われているわけではありません。

たとえば、支払いアプリがサーバーと通信するときにはTLSが使われます。
ログインや認証では、パスワードそのものを安全に扱う仕組みや、多要素認証の仕組みが関係します。
決済処理では、通信経路の保護だけでなく、取引内容の改ざん防止、本人確認、ログの保全なども重要になります。

ここでは、細かい決済システムの仕様には踏み込みません。
大切なのは、身近なサービスほど、裏側では複数の暗号技術やセキュリティ対策が組み合わさっているという点です。

このように見ると、暗号技術はサービスの表に出てくる主役ではありません。
しかし、見えないところで「この通信は安全か」「この相手は本物か」「このデータは改ざんされていないか」を支えています。

1.6 耐量子暗号と特につながるのは「公開鍵暗号」

ここまで見てきたように、現在のインターネットではさまざまな暗号技術が使われています。

その中でも、耐量子暗号と特に関係が深いのが 公開鍵暗号 です。

公開鍵暗号は、ざっくり言うと、公開してよい鍵と、外に出してはいけない秘密鍵のペアを使う仕組みです。
公開鍵は名前の通り公開できますが、秘密鍵は本人だけが持ちます。

この仕組みによって、たとえば次のようなことが可能になります。

用途	公開鍵暗号が関わるポイント	身近な例
サーバー認証	証明書の署名を検証する	本物のWebサイトか確認する
鍵共有	通信用の秘密を安全に作る	HTTPS通信を始める
デジタル署名	秘密鍵で署名し、公開鍵で検証する	アプリ更新や電子文書の正しさを確認する
ソフトウェア配布	配布元と改ざん有無を確認する	OSやアプリのアップデート

この公開鍵暗号の多くは、現在のコンピュータでは解くのが難しい数学問題を土台にしています。
たとえば、RSAは大きな数の素因数分解、楕円曲線暗号は楕円曲線上の離散対数問題の難しさに基づいています。

しかし、将来十分に強力な量子コンピュータが実現すると、この前提が大きく変わる可能性があります。
これが、耐量子暗号が注目されている大きな理由です。

1.7 この章のまとめ

この章では、耐量子暗号に入る前に、現在の暗号技術が身近なサービスのどこで使われているのかを整理しました。

ポイントは次の4つです。

HTTPSは1つの暗号ではなく、証明書、鍵共有、共通鍵暗号、認証付き暗号などを組み合わせている
証明書は、接続先が本物かどうかを確認するための身分証明書のような役割を持つ
アプリやソフトウェアのアップデートにも、改ざん検知や配布元確認のためにデジタル署名が使われる
耐量子暗号と特につながるのは、鍵共有やデジタル署名を支える公開鍵暗号である

ここまで見ると、公開鍵暗号は研究室の中だけの技術ではなく、普段のWeb通信やアプリ配布にも深く入り込んでいることが分かります。

次の章では、この公開鍵暗号に対して、量子コンピュータがどのような影響を与えるのかを整理します。

2. 量子コンピュータは暗号に何を起こすのか

前の章では、HTTPS、証明書、鍵共有、アプリ署名など、私たちの身近なサービスの裏側に公開鍵暗号が深く関わっていることを見てきました。

ここで自然に出てくる疑問は、次のようなものだと思います。

量子コンピュータが出てくると、なぜ今の暗号が危なくなるのか？

この章では、その理由をざっくり整理します。

先に大事な点を言うと、量子コンピュータは「何でも一瞬で解ける魔法のコンピュータ」ではありません。
IETFのRFC 9958でも、量子コンピュータはすべての分野でCPUやGPUより高速というわけではなく、特定の種類の問題で強みを持つと説明されています。

参考: RFC 9958 - Post-Quantum Cryptography for Engineers

暗号にとって問題なのは、その「量子コンピュータが得意な問題」の中に、現在の公開鍵暗号を支えている数学問題が含まれていることです。

2.1 量子コンピュータは「何でも速いコンピュータ」ではない

量子コンピュータという名前を聞くと、普通のコンピュータのものすごく速い版を想像しがちです。

もちろん、量子コンピュータは特定の計算で大きな力を発揮する可能性があります。
しかし、Webページの表示、Excelの計算、ゲームの描画、普通のプログラム実行など、あらゆる処理が単純に速くなるわけではありません。

身近なたとえでいうと、量子コンピュータは「万能な高速道路」というより、特定の地形だけを一気に進める特殊な乗り物に近いです。

暗号の世界では、この「特定の数学問題」がとても重要です。
なぜなら、RSAや楕円曲線暗号などの公開鍵暗号は、現在のコンピュータでは解くのが非常に難しい数学問題を土台にしているからです。

💡 豆知識
量子コンピュータの強さは、よく「重ね合わせ」や「量子もつれ」といった言葉で説明されます。
ただし、「すべての答えを同時に試して、正解だけを簡単に取り出せる」という理解は少し雑です。
実際には、量子状態をうまく操作して、正しい答えが観測されやすくなるように設計する必要があります。

2.2 暗号で問題になるのはCRQC

耐量子暗号の文脈では、単に「量子コンピュータ」と言うだけでなく、CRQC という言葉が使われることがあります。

CRQCは Cryptographically Relevant Quantum Computer の略です。
日本語にすると、「暗号にとって現実的な脅威になる量子コンピュータ」という意味です。

つまり、量子コンピュータが研究室に存在するだけではなく、RSAや楕円曲線暗号のような現在の公開鍵暗号を、現実的な時間で破れるほど十分に強力な状態を指します。

RFC 9958では、CRQCはRSAやECCなどの従来の非対称暗号アルゴリズムを実用的な時間で破るのに十分な論理量子ビットを持つ量子コンピュータとして説明されています。

ここで重要なのは、そのようなCRQCがいつ実現するかは、まだ不確実だという点です。
そのため、「もう危険だから明日すべて置き換える」という話ではありません。

一方で、暗号の移行には長い時間がかかります。
そのため、「実現してから考える」のでは遅い可能性がある、というのが耐量子暗号の大きな背景です。

2.3 Shorのアルゴリズム：公開鍵暗号に大きな影響を与える

量子コンピュータが公開鍵暗号に与える影響を考えるとき、最も重要な名前の1つが Shorのアルゴリズム です。

Shorのアルゴリズムは、ざっくり言うと、十分に強力な量子コンピュータ上で、次のような問題を効率よく解くためのアルゴリズムです。

大きな整数の素因数分解
離散対数問題

この2つは、現在の公開鍵暗号の多くと深く関係しています。

数学問題	関係する代表的な暗号	何が困るか
素因数分解	RSA	公開情報から秘密鍵に関わる情報を求められる可能性がある
離散対数問題	Diffie-Hellman、楕円曲線暗号	鍵共有や署名の安全性が崩れる可能性がある

RFC 9958でも、ShorのアルゴリズムはRSAやDiffie-Hellman、楕円曲線暗号など、広く使われている公開鍵暗号に大きな影響を与えると整理されています。

ここで、まずはRSAの雰囲気をかなり小さな例で見てみます。

実際のRSAでは、非常に大きな素数を2つ選び、それらを掛け合わせた数を使います。
小さな例として、61 と 53 を掛けると、3233 になります。

コードは「なぜ素因数分解が関係するのか」を見るための小さなデモです。
暗号実装として使うものではないので、処理の流れだけ追ってください。

# 注意:
# これはRSAの仕組みを雰囲気で理解するための「おもちゃの例」です。
# 実際のRSAでは、このような小さな数は絶対に使いません。

p = 61
q = 53
n = p * q

print(n)  # 3233

出力:

3233 という数だけを見て、元の 61 と 53 を見つけることを考えます。
このくらい小さい数なら、普通のプログラムでもすぐに分解できます。

import math

def trial_division(n: int):
    """小さな整数 n を素朴に割り算して因数を探す関数。

    実際のRSAを破るためのコードではありません。
    小さな数なら簡単に因数分解できる、という説明用の例です。
    """
    # 2 から sqrt(n) まで順番に割ってみる
    for d in range(2, math.isqrt(n) + 1):
        if n % d == 0:
            # 割り切れたら、d と n // d が因数になる
            return d, n // d

    # 割り切れる数が見つからなければ、n は素数とみなす
    return None

print(trial_division(3233))

出力:

(53, 61)

この例ではすぐに分解できました。
しかし、実際のRSAでは、n が何百桁にもなるように設計されています。
普通のコンピュータで素朴に試していく方法では、とても現実的な時間では分解できません。

RSAは、この「大きな数の素因数分解が難しい」という性質を利用しています。

ところが、十分に強力な量子コンピュータでShorのアルゴリズムを動かせるようになると、この前提が大きく揺らぎます。

Shorのアルゴリズムの内部を本格的に説明するには、量子フーリエ変換や周期発見などの話が必要になります。
この記事では深く入りすぎないため、雰囲気だけを次のように整理します。

Shorのアルゴリズムのざっくりした流れ

1. 分解したい数 N を決める
2. N と互いに素な数 a を選ぶ
3. f(x) = a^x mod N という関数の「周期」を探す
4. その周期から、N の因数を取り出す

ポイントは、量子コンピュータが得意なのは、直接「素因数を当てる」ことではなく、周期を見つける部分だという点です。

その後、見つけた周期を使って、普通の計算で因数を取り出します。
たとえば、N = 15 という小さな例では、a = 2 とすると 2^x mod 15 の周期は 4 になります。

import math

def shor_postprocess_demo(n: int, a: int, r: int):
    """Shorのアルゴリズムの「後処理」だけを示すデモ。

    n: 因数分解したい数
    a: n と互いに素な数
    r: a^x mod n の周期

    注意:
    この関数はShorのアルゴリズムそのものではありません。
    実際に難しいのは、量子計算で周期 r を見つける部分です。
    ここでは、周期 r がすでに分かっている前提で、
    そこから因数を取り出す流れだけを確認します。
    """
    if r % 2 != 0:
        return None

    # a^(r/2) を n で割った余りを計算する
    x = pow(a, r // 2, n)

    # gcd(x - 1, n) と gcd(x + 1, n) から因数が得られることがある
    p = math.gcd(x - 1, n)
    q = math.gcd(x + 1, n)

    return p, q

print(shor_postprocess_demo(n=15, a=2, r=4))

出力:

(3, 5)

このコードは、あくまで「後処理」のイメージです。
実際のShorのアルゴリズムでは、周期 r を見つける部分に量子計算が使われます。

それでも、この例から分かることがあります。

RSAのような暗号は、「大きな数を素因数分解するのは難しい」という前提に立っています。
Shorのアルゴリズムは、その前提を量子コンピュータで崩す可能性があります。

2.4 Groverのアルゴリズム：共通鍵暗号やハッシュ関数への影響

もう1つ重要なのが、Groverのアルゴリズム です。

Groverのアルゴリズムは、ざっくり言うと「たくさんの候補の中から正解を探す」処理を、理論上おおよそ平方根の回数に短縮できる量子アルゴリズムです。

たとえば、N 個の候補があるとします。
普通に総当たりで探すと、おおざっぱには N 回くらい試す必要があります。
Groverのアルゴリズムでは、理論上はおおよそ √N 回程度の探索で済むと考えられます。

def grover_rough_cost_exponent(bits: int):
    """総当たり探索とGrover探索のざっくりした計算量を指数で比較する。

    bits は鍵空間のビット数を表します。
    たとえば 128 bit の鍵なら、候補数は 2^128 個です。

    Groverのアルゴリズムでは、理論上おおよそ平方根になるため、
    2^bits 個の候補に対して 2^(bits/2) 程度の探索と見なせます。

    注意:
    これは理解用の単純化です。
    実際の攻撃可能性は、量子回路の深さ、エラー訂正、並列化の難しさ、
    実装コストなどに強く依存します。
    """
    classical = f"2^{bits}"
    grover = f"2^{bits // 2}" if bits % 2 == 0 else f"2^{bits}/2 の平方根程度"
    return classical, grover

for bits in [64, 128, 192, 256]:
    classical, grover = grover_rough_cost_exponent(bits)
    print(f"{bits} bit: 古典的な総当たり ≒ {classical}, Grover ≒ {grover}")

出力例:

64 bit: 古典的な総当たり ≒ 2^64, Grover ≒ 2^32
128 bit: 古典的な総当たり ≒ 2^128, Grover ≒ 2^64
192 bit: 古典的な総当たり ≒ 2^192, Grover ≒ 2^96
256 bit: 古典的な総当たり ≒ 2^256, Grover ≒ 2^128

このように見ると、Groverのアルゴリズムもかなり強力に見えます。

ただし、Shorのアルゴリズムが公開鍵暗号に与える影響とは、少し性質が違います。
Groverのアルゴリズムは、主に総当たり探索を平方根程度に短縮するものです。
そのため、共通鍵暗号では鍵長を十分に長くすることで対策しやすいと考えられます。

RFC 9958でも、共通鍵暗号やハッシュ関数への影響は公開鍵暗号より小さく、リスクが当てはまる場合には鍵長やダイジェスト長を増やすことで緩和できると説明されています。

この点は、読者が誤解しやすいところです。

量子コンピュータが出てきたら、AESやSHAもRSAと同じように一気に終わる。
これは正確ではありません。

もちろん、共通鍵暗号やハッシュ関数も無関係ではありません。
しかし、公開鍵暗号とは影響の受け方が違います。

2.5 影響を整理すると、公開鍵暗号が特に大きい

ここまでの話を整理すると、次のようになります。

種類	代表例	量子コンピュータによる主な影響	対応の考え方
公開鍵暗号	RSA、Diffie-Hellman、楕円曲線暗号	Shorのアルゴリズムにより、安全性の前提が大きく崩れる可能性がある	耐量子暗号への置き換えが必要になる
共通鍵暗号	AESなど	Groverのアルゴリズムによる探索高速化の影響を受ける	十分な鍵長を使うことで対策しやすい
ハッシュ関数	SHA-2、SHA-3など	Groverのアルゴリズムにより探索系の安全性に影響が出る可能性がある	十分な出力長を使うことが重要になる

この章で一番伝えたいのは、次の点です。

量子コンピュータの影響は、すべての暗号に同じように及ぶわけではありません。
特に大きな影響を受けるのは、RSAや楕円曲線暗号などの公開鍵暗号です。

そして、1章で見たように、公開鍵暗号はHTTPS、証明書、鍵共有、アプリ署名など、今のインターネットの土台に広く使われています。

だからこそ、耐量子暗号への移行は、一部の研究者だけの話ではなく、Web、クラウド、金融、行政、IoT、ソフトウェア配布など、さまざまな領域に関わるテーマになります。

2.6 この章のまとめ

この章では、量子コンピュータが暗号に与える影響を、ShorのアルゴリズムとGroverのアルゴリズムに分けて整理しました。

ポイントは次の4つです。

量子コンピュータは、すべての計算を単純に速くする魔法のコンピュータではない
暗号で特に問題になるのは、RSAや楕円曲線暗号などを現実的な時間で破れるほど強力なCRQCである
Shorのアルゴリズムは、RSAやDiffie-Hellman、楕円曲線暗号などの公開鍵暗号に大きな影響を与える
Groverのアルゴリズムは共通鍵暗号やハッシュ関数にも関係するが、公開鍵暗号とは影響の受け方が異なる

ここで大切なのは、「量子コンピュータで暗号が全部同じように壊れる」と考えないことです。

次の章では、RSA、ECDH、ECDSA、AES、SHA-2 / SHA-3などを並べて、どの暗号がどのように影響を受けるのかをもう少し具体的に整理します。

3. 「量子コンピュータですべての暗号が危ない」は半分正しい

前の章では、量子コンピュータが暗号に与える影響として、ShorのアルゴリズムとGroverのアルゴリズムを見ました。

ここで、もう一度大事なポイントを確認します。

量子コンピュータの影響は、すべての暗号に同じように及ぶわけではありません。

「量子コンピュータが出てきたら暗号は全部終わる」と言われることがありますが、これはかなり大ざっぱな言い方です。
実際には、暗号の種類によって影響の受け方が違います。

特に大きな影響を受けるのは、RSA、Diffie-Hellman、楕円曲線暗号のような 公開鍵暗号 です。
一方で、AESのような 共通鍵暗号 や、SHA-2 / SHA-3のような ハッシュ関数 は、影響を受けるとしても性質が異なります。

この章では、暗号を大きく3つに分けて整理します。

参考: RFC 9958 - Post-Quantum Cryptography for Engineers

3.1 まずは全体像を見る

先に、影響の違いを表で見ておきます。

種類	代表例	主な用途	量子コンピュータによる影響	対応の考え方
公開鍵暗号	RSA	暗号化、署名、証明書など	Shorのアルゴリズムにより、素因数分解の難しさという前提が崩れる可能性がある	PQCの方式へ置き換える
鍵共有	Diffie-Hellman、ECDH	TLSなどで通信の共通鍵を作る	Shorのアルゴリズムにより、離散対数問題の難しさという前提が崩れる可能性がある	PQCのKEMへ置き換える
デジタル署名	RSA署名、ECDSA	証明書、ソフトウェア署名、電子文書の確認	署名に使う秘密鍵や署名の信頼性に影響する可能性がある	PQCの署名方式へ置き換える
共通鍵暗号	AES	通信本文や保存データの暗号化	Groverのアルゴリズムによる探索高速化の影響を考える	十分な鍵長を選ぶ
ハッシュ関数	SHA-2、SHA-3	データの指紋、署名の前処理、改ざん検知など	探索系の安全性に影響する可能性がある	十分な出力長を選ぶ

RFC 9958では、CRQC、つまり暗号にとって現実的な脅威となる量子コンピュータが登場した場合、RSAやECCのような広く使われる公開鍵暗号がShorのアルゴリズムによって破られる可能性がある一方、共通鍵暗号やハッシュ関数への影響はGroverのアルゴリズムによるもので、公開鍵暗号よりは小さいと整理されています。

ここで重要なのは、PQCの主な議論は 公開鍵暗号の置き換え だということです。
AESやSHAをすぐに「耐量子暗号」という名前の別物に置き換える、という話ではありません。

3.2 RSA：大きな数を分解しにくいことに支えられている

RSAは、公開鍵暗号の代表的な方式です。

RFC 8017では、RSAを使った公開鍵暗号の実装仕様として、暗号化方式、署名方式、鍵の表現などが整理されています。

参考: RFC 8017 - PKCS #1: RSA Cryptography Specifications Version 2.2

RSAの考え方をかなりざっくり言うと、次のようになります。

大きな素数を2つ用意する
それらを掛け合わせて、とても大きな数を作る
掛け算は簡単だが、結果から元の素数を見つけるのは難しい
その難しさを安全性の土台にする

前章でも小さな例を見ましたが、61 × 53 = 3233 のような小さい数なら、元の数を見つけるのは簡単です。
しかし、実際のRSAでは、はるかに大きな数を使います。

普通のコンピュータでは、この素因数分解がとても難しいため、RSAは長く使われてきました。

ただし、Shorのアルゴリズムは、この素因数分解を効率よく解ける可能性があります。
そのため、十分に強力な量子コンピュータが実現すると、RSAの安全性の前提が大きく揺らぎます。

ここで注意したいのは、RSAの鍵を少し長くすれば解決、という単純な話ではないことです。
RFC 9958では、Shorのアルゴリズムが対象とする数学問題に基づく公開鍵暗号については、鍵サイズを増やすだけでは現実的な解決にならず、別の数学的な難しさに基づく方式への置き換えが必要になると整理されています。

3.3 Diffie-Hellman / ECDH：安全な通信を始めるための鍵共有

HTTPS通信では、通信本文を守るために共通鍵暗号が使われます。
しかし、その共通鍵を最初にどうやって作るのかが問題になります。

ここで登場するのが、Diffie-HellmanやECDHのような鍵共有です。

かなり身近なたとえで言うと、鍵共有は次のような役割です。

まだ安全な会話ができない相手と、周りに聞かれても大丈夫なやり取りをしながら、最終的に2人だけが分かる合言葉を作る仕組み

TLS 1.3でも、鍵共有の仕組みを使って共有秘密を作り、そこから通信用の鍵を導きます。

参考: RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3

Diffie-Hellman系の方式は、離散対数問題の難しさを安全性の土台にしています。
ECDHは、この考え方を楕円曲線という数学的な構造の上で使う方式です。

ここで量子コンピュータが問題になります。
Shorのアルゴリズムは、素因数分解だけでなく、離散対数問題にも影響します。

そのため、RSAだけでなく、Diffie-HellmanやECDHも耐量子暗号への移行対象になります。

この話は、後で出てくる KEM とつながります。

KEMは Key Encapsulation Mechanism の略で、ざっくり言うと「安全に共有秘密を作るための仕組み」です。
NIST標準のML-KEMも、この鍵共有に近い役割を担う耐量子暗号として理解すると分かりやすいです。

3.4 ECDSAなどのデジタル署名：本物かどうかを確認する仕組み

デジタル署名は、データの送信者や作成者が本物であること、そしてデータが途中で改ざんされていないことを確認するための仕組みです。

NISTのFIPS 186-5でも、デジタル署名はデータの不正な変更を検出し、署名者の身元を認証するために使われると説明されています。

参考: NIST FIPS 186-5 - Digital Signature Standard

身近な例で考えると、デジタル署名は次のような場面で使われます。

Webサイト証明書が本物か確認する
アプリのアップデートが開発元から配布されたものか確認する
電子文書が途中で書き換えられていないか確認する
ソフトウェアの配布元を確認する

ECDSAは、楕円曲線暗号を使ったデジタル署名方式の1つです。
現在のWebやソフトウェア配布の仕組みでは、RSA署名やECDSAのような公開鍵署名が広く使われています。

ここでも、量子コンピュータの影響は無視できません。
署名方式の安全性も、秘密鍵を推測しにくいことや、署名を偽造しにくいことに支えられています。
しかし、その前提となる数学問題がShorのアルゴリズムで崩れると、署名の信頼性にも影響します。

つまり、耐量子暗号への移行では、鍵共有だけでなく、署名方式も重要です。

NISTが標準化した耐量子暗号でも、鍵共有・鍵確立に関わるML-KEMだけでなく、デジタル署名のためのML-DSAやSLH-DSAが用意されています。
この点は、後の章で詳しく整理します。

3.5 AES：共通鍵暗号は「同じように壊れる」わけではない

次に、AESのような共通鍵暗号を見てみます。

AESは、通信本文や保存データを暗号化するためによく使われる共通鍵暗号です。
NISTのFIPS 197では、AESは電子データを保護するために使える対称ブロック暗号として定義され、128 bit、192 bit、256 bitの鍵を使えると説明されています。

参考: NIST FIPS 197 - Advanced Encryption Standard (AES)

ここで大切なのは、AESはRSAやECDHとは安全性の土台が違うという点です。

RSAやECDHは、素因数分解や離散対数問題の難しさに大きく依存しています。
一方で、AESは同じ秘密鍵を持っている相手だけが暗号化・復号できる、という共通鍵暗号です。

量子コンピュータがAESに与える影響としては、主にGroverのアルゴリズムによる探索高速化が考えられます。
ただし、これはShorのアルゴリズムが公開鍵暗号に与える影響とは違います。

Groverのアルゴリズムでは、総当たり探索が理論上おおよそ平方根の回数に短縮されます。
そのため、鍵長を十分に長くすることで対策しやすいと整理されます。

たとえば、かなり単純化して考えると、次のようなイメージです。

鍵長	古典的な総当たりのざっくりした候補数	Groverを考えたときのざっくりした探索規模
128 bit	2^128	2^64程度
192 bit	2^192	2^96程度
256 bit	2^256	2^128程度

もちろん、これは理解のためのかなり単純化した表です。
実際の攻撃可能性は、量子コンピュータの規模、エラー訂正、量子回路の深さ、実装コストなどに大きく左右されます。

💡 豆知識
「耐量子暗号」という話になると、AESもまったく別の新方式に置き換える必要があるように感じるかもしれません。
しかし、PQCの中心は公開鍵暗号の置き換えです。
AESについては、方式そのものをPQCに置き換えるというより、十分な鍵長を選ぶことが主な考え方になります。

3.6 SHA-2 / SHA-3：ハッシュ関数も影響の受け方が違う

ハッシュ関数は、データから固定長の「指紋」のような値を作る関数です。

たとえば、SHA-256では、入力データが長くても短くても、256 bitのハッシュ値を出力します。
このハッシュ値は、データの改ざん検知、デジタル署名の前処理、パスワード保存、ブロックチェーンなど、さまざまな場面で使われています。

NISTのFIPS 180-4では、SHA-2を含むSecure Hash Standardが、メッセージのダイジェストを生成し、メッセージが変更されたかどうかを検出する用途で使われると説明されています。
また、FIPS 202ではSHA-3ファミリーが定義されています。

参考: NIST FIPS 180-4 - Secure Hash Standard
参考: NIST FIPS 202 - SHA-3 Standard

実際に、PythonでSHA-256を使って小さな入力の違いを見てみます。

import hashlib


def sha256_hex(message: str) -> str:
    """文字列からSHA-256のハッシュ値を計算する関数。

    hashlib.sha256() は、Python標準ライブラリで使えるSHA-256実装です。
    ここでは説明用に、文字列をUTF-8のバイト列に変換してから
    ハッシュ値を16進数文字列として表示しています。
    """
    return hashlib.sha256(message.encode("utf-8")).hexdigest()


message1 = "payment=1000"
message2 = "payment=1001"  # 1文字だけ変えた例

print(sha256_hex(message1))
print(sha256_hex(message2))

出力例:

40dc145a8be4c431ca406b836996ba05d91da09207eeebc9cc5587741a96a5c4
ca73da77b78a7e26dfbd714b429c5ad83d28347b9b62036e605be375c44ea01e

この例から分かるように、ハッシュ関数は「元のデータを隠す暗号化」ではなく、データの指紋を作る仕組みです。
そのため、ハッシュ関数への量子コンピュータの影響も、RSAやECDHとは違う見方が必要です。

ハッシュ関数では、主に次のような性質が重要になります。

性質	ざっくりした意味	例
原像計算困難性	ハッシュ値から元の入力を見つけにくい	ハッシュ値だけ見ても元データを戻せない
第二原像計算困難性	ある入力と同じハッシュ値になる別の入力を見つけにくい	正規ファイルと同じ指紋を持つ偽ファイルを作りにくい
衝突困難性	同じハッシュ値になる2つの異なる入力を見つけにくい	別々の文書で同じ指紋を作りにくい

Groverのアルゴリズムは、探索問題に影響します。
そのため、ハッシュ値から入力を探すような場面では、量子コンピュータによる探索高速化を考える必要があります。

ただし、ここでも公開鍵暗号のように「数学的な前提が一気に崩れる」というより、十分な出力長を選ぶことが重要になります。
実務では、利用目的に応じてSHA-256、SHA-384、SHA-512、SHA-3系などから適切に選ぶ必要があります。

3.7 「置き換えるもの」と「強度を見直すもの」を分けて考える

ここまでの話をまとめると、耐量子暗号への移行では、暗号技術を大きく2種類に分けて考えると分かりやすくなります。

1つ目は、方式そのものを置き換える必要があるものです。
RSA、Diffie-Hellman、ECDH、ECDSAなど、従来の公開鍵暗号がここに入ります。

2つ目は、方式そのものより、鍵長や出力長を見直すものです。
AESやSHA-2 / SHA-3などがここに入ります。

この区別はとても大事です。

なぜなら、耐量子暗号への移行を考えるときに、すべての暗号技術を同じ優先度で置き換えようとすると、話が必要以上に複雑になってしまうからです。

まず特に注目すべきなのは、公開鍵暗号です。
公開鍵暗号は、HTTPS、証明書、鍵共有、ソフトウェア署名など、システムの信頼の起点に近いところで使われています。

一方で、AESやSHA-2 / SHA-3については、量子コンピュータの影響を踏まえつつ、十分な鍵長や出力長を選ぶという整理になります。

3.8 この章のまとめ

この章では、量子コンピュータの影響を暗号の種類ごとに整理しました。

ポイントは次の通りです。

RSAは、素因数分解の難しさに支えられている
Diffie-HellmanやECDHは、離散対数問題の難しさに支えられている
ECDSAなどのデジタル署名も、公開鍵暗号の前提に依存している
これらの公開鍵暗号は、Shorのアルゴリズムによる影響が大きい
AESやSHA-2 / SHA-3は、Groverのアルゴリズムによる影響を考える
共通鍵暗号やハッシュ関数は、公開鍵暗号とは影響の受け方が異なる
耐量子暗号への移行では、まず公開鍵暗号の置き換えが大きなテーマになる

ここまでで、「量子コンピュータによって何が問題になるのか」が少し具体的になりました。

次の章では、この影響がなぜ「今から準備する」という話につながるのかを整理します。
特に、長期間守るべき情報と Harvest Now, Decrypt Later の考え方を見ていきます。

4. 本当に意識したいのは Harvest Now, Decrypt Later

ここまでで、次の流れを見てきました。

今のインターネットでは、RSAや楕円曲線暗号などの公開鍵暗号が広く使われている
将来、十分に強力な量子コンピュータが実現すると、それらの公開鍵暗号は大きな影響を受ける可能性がある
ただし、すべての暗号が同じように危なくなるわけではなく、影響範囲を分けて考える必要がある

ここで、次の疑問が出てきます。

まだ暗号を破れるほど強力な量子コンピュータが一般に使われているわけではないなら、なぜ今から準備する必要があるのか？

この章では、この疑問を整理します。

結論から言うと、理由は大きく2つあります。

1つ目は、今盗まれた暗号化データが、将来解読される可能性があるからです。
2つ目は、暗号の移行にはとても時間がかかるからです。

耐量子暗号への移行は、「明日すべての暗号が破られるから急ぐ」という話ではありません。
むしろ、「本当に危なくなってから始めると間に合わない可能性があるから、今から準備する」という話です。

4.1 「完成してから考える」では間に合わない

量子コンピュータの話では、つい次のように考えたくなります。

実用的な量子コンピュータができてから、暗号を置き換えればよいのでは？

日常の感覚では、この考え方も自然です。
たとえば、スマホのOSアップデートなら、通知が来てから更新しても間に合うことが多いです。

しかし、暗号技術の移行は、スマホアプリを1つ更新するような作業ではありません。

暗号は、システムのかなり深い部分に埋め込まれています。

Webアプリのソースコードだけではなく、TLSライブラリ、証明書、認証基盤、外部API、クラウドサービス、組み込み機器、社内システムなど、いろいろな場所に暗号が使われています。

そのため、移行では次のような確認が必要になります。

確認すること	具体例
どこで暗号を使っているか	TLS、VPN、SSH、電子証明書、署名、鍵管理、認証基盤
どの方式を使っているか	RSA、ECDSA、ECDH、DH、AES、SHA-2など
何を守っているか	個人情報、決済情報、契約情報、研究開発情報、ログ、証明書
どれくらい長く守る必要があるか	数日、数年、十年以上
置き換えやすいか	ライブラリ更新で済むのか、機器交換が必要なのか
関係者は誰か	自社、クラウド事業者、外部ベンダ、認証局、利用者

NIST NCCoEのPQC移行プロジェクトでも、移行にはハードウェア、ソフトウェア、サービスの中で量子に弱い公開鍵暗号がどこで使われているかを理解し、ロードマップを作って優先順位を決める必要があると説明されています。

参考: NIST NCCoE - Migration to Post-Quantum Cryptography

NISTの解説でも、新しい暗号アルゴリズムが標準化されてから実際の情報システムに完全に組み込まれるまでには長い時間がかかり、10〜20年かかることもあると説明されています。

参考: NIST - What Is Post-Quantum Cryptography?

これが、耐量子暗号で「今から準備」と言われる大きな理由です。

4.2 Harvest Now, Decrypt Later：今盗んで、後で読む

もう1つの重要な考え方が、Harvest Now, Decrypt Later です。

これは、直訳すると「今収穫して、後で解読する」という意味です。
暗号の文脈では、攻撃者が今のうちに暗号化された通信やデータを集めて保存しておき、将来、十分に強力な量子コンピュータが使えるようになった段階で解読しようとする攻撃を指します。

図にすると、次のようなイメージです。

ポイントは、攻撃者が「今すぐ暗号を破れる必要はない」ということです。

今は読めなくても、保存しておくことはできます。
そして将来、暗号を破れるだけの計算能力が使えるようになったときに、過去の暗号化データを解読できる可能性があります。

NISTも、長期間価値を持つ秘密情報について、攻撃者が暗号化データを今取得して保存し、将来量子コンピュータで解読する可能性を harvest now, decrypt later として説明しています。

参考: NIST - What Is Post-Quantum Cryptography?

💡 豆知識
Harvest Now, Decrypt Later は、よく HNDL と略されます。
似た表現として Store Now, Decrypt Later と呼ばれることもあります。
どちらも、「今は読めなくても、とりあえず保存しておき、将来読む」という考え方です。

4.3 長く守る情報ほど、早めの対策が必要になる

HNDLのリスクは、すべてのデータで同じ大きさになるわけではありません。

たとえば、今日だけ意味があるワンタイムパスワードと、10年後も秘密であるべき医療情報では、守るべき期間がまったく違います。

情報の例	長期間守る必要性	HNDLとの関係
一時的なセッション情報	低い	数分〜数時間で価値が下がることが多い
ECサイトの一時的な注文情報	中	内容によっては長期保存リスクもある
契約情報	高い	数年後も機密である可能性がある
医療情報	高い	長期間、個人のプライバシーに関わる
研究開発情報	高い	将来の競争力や知財に関わる
行政・安全保障関連情報	非常に高い	十年以上の保護が必要な場合がある

ここで大事なのは、「今の通信が今だけの問題とは限らない」という点です。

たとえば、ある研究開発情報が暗号化されて送信されていたとします。
今は解読されなくても、将来その内容が読まれると、企業の競争力や知的財産に影響するかもしれません。

医療情報や個人情報も同じです。
数年後、十数年後に漏えいしても、本人にとっては大きな問題になります。

そのため、耐量子暗号への移行では、単に「どの暗号方式を使っているか」だけではなく、その暗号が何を、どれくらいの期間守っているのかを考える必要があります。

4.4 移行準備は「暗号資産の棚卸し」から始まる

耐量子暗号への移行で最初に必要になるのは、いきなりML-KEMやML-DSAへ置き換えることではありません。

まず必要なのは、暗号資産の棚卸しです。

ここでいう暗号資産とは、暗号アルゴリズムそのものだけではなく、暗号を使っているシステム、ライブラリ、証明書、鍵、設定、運用手順などを含めたものです。

身近な例で言えば、引っ越し前に家の中の荷物を確認する作業に近いです。

どの部屋に何があるのか。
どれを先に運ぶべきか。
どれは買い替える必要があるのか。
どれは捨ててもよいのか。

それを確認しないまま引っ越しを始めると、途中で大事なものが見つからなかったり、運ぶ順番を間違えたりします。

暗号移行でも同じです。

NIST NCCoEのFAQでも、PQC移行の出発点として、システム内の暗号利用を発見し、棚卸しすることがよい開始点だと説明されています。

参考: NIST NCCoE - Frequently Asked Questions about Post-Quantum Cryptography

4.5 棚卸し結果を使って、優先順位を決める

暗号資産の棚卸しができたとしても、すべてを一度に置き換えるのは現実的ではありません。

そこで、守っている情報の重要度、外部からアクセスされるか、移行の難しさ、長期間の秘密保持が必要か、といった観点で優先順位を付けます。

たとえば、次のように考えられます。

優先度	例	理由
高	外部公開サービスのTLS、重要API、長期保管データを守る鍵共有	攻撃対象になりやすく、HNDLの影響も受けやすい
中	社内向けシステムの証明書、VPN、SSH	利用範囲や保護対象によって優先度が変わる
低	短期間で無効になる一時的な情報のみを扱う仕組み	長期的な解読リスクは相対的に小さい場合がある

もちろん、これは単純化した例です。
実際には、業界の規制、契約、利用者への影響、システム停止の許容度、ベンダ対応状況なども含めて判断する必要があります。

以下は、暗号資産の棚卸し結果を簡単に優先順位付けするイメージです。
実務でそのまま使える評価式ではありませんが、「どの観点で優先順位を考えるのか」をつかむための小さな例として見てください。

# 暗号資産の棚卸し結果を、簡易的に優先順位付けする例です。
# 実務では、組織のリスク基準・法令・業界標準・ベンダ情報などを含めて評価します。

assets = [
    {
        "name": "公開WebサイトのTLS鍵共有",
        "algorithm": "ECDH",
        "protects": "利用者のログイン通信",
        "secret_lifetime_years": 5,
        "internet_exposed": True,
        "replacement_difficulty": 3,
    },
    {
        "name": "社内管理画面のSSH",
        "algorithm": "RSA",
        "protects": "管理者ログイン",
        "secret_lifetime_years": 2,
        "internet_exposed": False,
        "replacement_difficulty": 2,
    },
    {
        "name": "研究開発データ送信用VPN",
        "algorithm": "ECDH",
        "protects": "研究開発情報",
        "secret_lifetime_years": 10,
        "internet_exposed": True,
        "replacement_difficulty": 4,
    },
    {
        "name": "短時間だけ使う一時トークン",
        "algorithm": "HMAC-SHA-256",
        "protects": "一時的なAPI認証",
        "secret_lifetime_years": 0,
        "internet_exposed": True,
        "replacement_difficulty": 1,
    },
]

# Shorのアルゴリズムの影響を強く受ける代表的な公開鍵暗号を簡易的に並べます。
# ここでは説明用に、RSA / DH / ECDH / ECDSA を量子影響が大きいものとして扱います。
quantum_vulnerable_public_key = {"RSA", "DH", "ECDH", "ECDSA"}


def calculate_priority(asset):
    """暗号資産の移行優先度を、説明用の点数として計算します。"""
    score = 0

    # 量子影響を受けやすい公開鍵暗号を使っている場合は、優先度を上げます。
    if asset["algorithm"] in quantum_vulnerable_public_key:
        score += 5

    # 長期間守る必要がある情報ほど、HNDLの影響を受けやすいので点数を加えます。
    score += min(asset["secret_lifetime_years"], 10)

    # インターネットから到達できる場所で使われている場合は、攻撃対象になりやすいので点数を加えます。
    if asset["internet_exposed"]:
        score += 3

    # 置き換えが難しいものほど、早めに検証を始める必要があるので点数を加えます。
    score += asset["replacement_difficulty"]

    return score


# 点数が高い順に並べることで、移行準備の優先候補を確認します。
ranked_assets = sorted(
    assets,
    key=calculate_priority,
    reverse=True,
)

for asset in ranked_assets:
    print(f"{calculate_priority(asset):2d}点: {asset['name']} / {asset['algorithm']} / {asset['protects']}")

実行すると、たとえば次のような順番になります。

22点: 研究開発データ送信用VPN / ECDH / 研究開発情報
16点: 公開WebサイトのTLS鍵共有 / ECDH / 利用者のログイン通信
 9点: 社内管理画面のSSH / RSA / 管理者ログイン
 4点: 短時間だけ使う一時トークン / HMAC-SHA-256 / 一時的なAPI認証

ここで伝えたいのは、点数そのものではありません。

重要なのは、PQC移行では、量子影響を受けやすい方式かどうかだけでなく、何を守っているのか、どれくらい長く守る必要があるのか、外部にさらされているのか、置き換えが難しいのかを合わせて考える必要があるという点です。

4.6 海外では政府レベルでも移行計画が進んでいる

耐量子暗号への移行は、研究者や暗号ライブラリ開発者だけの話ではありません。
政府レベルでも、段階的な移行計画が進められています。

たとえば米国では、2026年6月に公開された大統領令で、連邦情報システムをNIST承認のPQC標準へ移行する方針が示されています。
この大統領令では、高価値資産や高影響システムについて、鍵確立は2030年12月31日まで、デジタル署名は2031年12月31日までにPQCへ移行する方針が示されています。

参考: The White House - Securing the Nation Against Advanced Cryptographic Attacks

もちろん、これは米国連邦政府向けの方針であり、日本の一般企業や個人開発にそのまま適用されるものではありません。

それでも、ここから分かることがあります。

それは、PQC移行が「いつか考える話」ではなく、重要なシステムでは具体的な期限や担当者を決めて進める段階に入りつつある、ということです。

4.7 「今すぐ全部置き換える」ではなく「今から見える化する」

ここまで読むと、少し不安になるかもしれません。

では、今すぐ自分のシステムを全部PQCに置き換えないといけないのか？

答えは、基本的には いきなり全部置き換える話ではありません。

特に、一般的なWebサービスや学習用アプリであれば、まずは次のような準備から始めるのが現実的です。

段階	やること	目的
1	使っている暗号ライブラリを把握する	どこに依存しているかを知る
2	TLS、証明書、署名、鍵管理の利用箇所を確認する	公開鍵暗号の利用場所を見える化する
3	長期間守るデータを確認する	HNDLの影響を受けやすい情報を見つける
4	ベンダやクラウドのPQC対応状況を追う	自分だけで置き換えられない部分を確認する
5	検証環境でPQC対応を試す	性能・互換性・運用影響を確認する

このように、まずは 見える化 が重要です。

暗号は、普段は目立ちません。
うまく動いているときほど、意識されにくい技術です。

しかし、どこで何を使っているか分からない状態では、将来置き換えることもできません。

耐量子暗号への移行準備は、いきなり難しい数式を理解することから始まるのではなく、まず「自分たちのシステムのどこで暗号が使われているのか」を把握するところから始まります。

4.8 この章のまとめ

この章では、なぜ今から耐量子暗号への移行準備が必要なのかを整理しました。

ポイントは次の通りです。

量子コンピュータがいつ実用的な脅威になるかは、正確には分からない
しかし、暗号移行には長い時間がかかるため、完成してから考えるのでは遅い可能性がある
Harvest Now, Decrypt Laterでは、今盗まれた暗号化データが将来解読される可能性がある
長期間守る必要がある情報ほど、早めの対策が重要になる
PQC移行は、まず暗号資産の棚卸しから始める
量子影響、情報の重要度、保存期間、外部露出、移行難易度をもとに優先順位を決める
政府レベルでも、重要システムについて具体的な移行計画が進められている
今すぐ全部置き換えるのではなく、今から見える化し、段階的に準備することが大切である

ここまでで、「なぜ今から準備するのか」が見えてきました。

次の章では、ここまでの背景を踏まえて、この記事の中心である 耐量子暗号 そのものを整理します。
耐量子暗号は、どの部分を置き換えるための技術なのかを見ていきます。

5. 耐量子暗号は何を置き換えるのか

前の章では、なぜ量子コンピュータが完成してから考えるのでは遅い可能性があるのかを整理しました。

ここまでの内容を、暗号方式の置き換えという観点でまとめると、次のようになります。

特に大きな影響を受けるのは、RSAや楕円曲線暗号などの公開鍵暗号である。
その置き換え先として研究・標準化が進められているのが、耐量子暗号である。

ここからは、この記事のタイトルにも入っている 耐量子暗号 そのものを整理します。

ただし、最初に大事な注意点があります。

耐量子暗号は、名前に「量子」と入っていますが、量子コンピュータを使って暗号化する技術ではありません。
基本的には、今のコンピュータやサーバー、スマートフォンの上で動かすことを想定した暗号技術です。

NISTは、耐量子暗号を将来の量子コンピュータによる攻撃に備えるための防御策として説明しており、PQCのアルゴリズムは、古典コンピュータと量子コンピュータのどちらにとっても解くのが難しいと考えられる数学問題に基づく必要があると整理しています。

参考: NIST - What Is Post-Quantum Cryptography?

5.1 耐量子暗号は「量子コンピュータを使う暗号」ではない

まず、混同しやすい言葉を分けます。

用語	ざっくりした意味	使うもの	この記事での扱い
耐量子暗号 / PQC	量子コンピュータによる攻撃にも耐えることを目指す暗号	通常のコンピュータ上で動く暗号アルゴリズム	本記事の中心
量子暗号	量子力学の性質を利用する暗号技術の総称	量子物理・専用装置など	混同しないように触れる程度
QKD	Quantum Key Distribution。量子鍵配送	光子などを扱う専用の通信路・装置	PQCとは別のアプローチ

NISTも、PQCと量子暗号は名前が似ているが別物だと説明しています。
PQCは量子コンピュータからの攻撃に備えるための数学的な暗号方式であり、量子暗号は量子力学の性質を使う別の技術です。

ここは、初学者がつまずきやすいポイントです。

「耐量子暗号」と聞くと、量子コンピュータの中で動く暗号や、量子通信装置を使う暗号をイメージするかもしれません。
しかし、PQCはむしろ逆です。

量子コンピュータを持っていない普通のシステムでも、将来の量子コンピュータによる攻撃に備えられるようにする暗号技術

と考えると分かりやすいです。

💡 豆知識
「Post-Quantum Cryptography」の Post は、「量子コンピュータが完成した後だけに使う」という意味で捉えると少し誤解があります。
実際には、量子コンピュータによる将来の攻撃を見据えて、今のシステムを少しずつ移行していくための技術です。

5.2 PQCが置き換えようとしているもの

PQCが主に置き換えようとしているのは、現在広く使われている 公開鍵暗号 です。

1章で見たように、公開鍵暗号は次のような場所で使われます。

HTTPS通信を始めるときの鍵共有
Webサイト証明書の検証
アプリやソフトウェア更新ファイルの署名検証
電子文書や取引データの署名

PQCは、これらの役割を将来も安全に保つために、RSA、Diffie-Hellman、ECDH、ECDSAなどの代わりになる方式を用意しようとするものです。

ここで大切なのは、PQCが「暗号の全部を置き換える万能セット」ではないことです。

AESのような共通鍵暗号や、SHA-2 / SHA-3のようなハッシュ関数も量子コンピュータの影響を考える必要はあります。
しかし、PQCの中心テーマは、RSAや楕円曲線暗号のような 公開鍵暗号の置き換え です。

5.3 PQCの大きな役割は「KEM」と「デジタル署名」

PQCを理解するときは、いきなりアルゴリズム名から入るよりも、まず役割で分けると分かりやすいです。

現在の標準化で特に重要なのは、次の2つです。

役割	何をするか	従来の例	PQCでの代表例
KEM	通信用の共有秘密を作る	DH、ECDH	ML-KEM
デジタル署名	本物か、改ざんされていないかを確認する	RSA署名、ECDSA	ML-DSA、SLH-DSA

NISTは2024年8月に、最初の3つのPQC標準として、FIPS 203、FIPS 204、FIPS 205を公開しました。
FIPS 203はML-KEM、FIPS 204はML-DSA、FIPS 205はSLH-DSAを対象にしています。

参考: NIST - NIST Releases First 3 Finalized Post-Quantum Encryption Standards
参考: NIST CSRC - FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
参考: NIST CSRC - FIPS 204: Module-Lattice-Based Digital Signature Standard
参考: NIST CSRC - FIPS 205: Stateless Hash-Based Digital Signature Standard

KEMは「秘密の合言葉を小包で送る」イメージ

KEMは Key Encapsulation Mechanism の略です。
日本語では「鍵カプセル化メカニズム」と訳されることがあります。

少し名前が難しいですが、役割は次のように考えると分かりやすいです。

通信相手と、あとで共通鍵暗号に使うための共有秘密を安全に作る仕組み

NIST SP 800-227では、KEMは公開された通信路上で2者が共有秘密鍵を安全に確立するために使えるアルゴリズム集合として説明されています。

参考: NIST CSRC - Recommendations for Key-Encapsulation Mechanisms: NIST Publishes SP 800-227

KEMの流れは、かなり単純化すると次のようになります。

イメージとしては、送信側が「秘密の合言葉」を直接送るのではなく、公開鍵を使って安全な小包 ct に包んで送るようなものです。
受信側は、自分だけが持っている秘密鍵でその小包を開けて、同じ共有秘密を取り出します。

実際のPQCアルゴリズムを安全に実装するのは非常に難しいため、ここでは KEMのインターフェースだけ をおもちゃのコードで示します。

# 注意:
# これはKEMの「入出力の形」を理解するためのおもちゃの例です。
# 実際の暗号として安全ではありません。
# ML-KEMの実装例ではありません。

from dataclasses import dataclass
import hashlib
import secrets


@dataclass
class ToyKeyPair:
    """説明用の鍵ペア。

    public_key: 相手に公開してよい値
    secret_key: 自分だけが保持する値
    """
    public_key: bytes
    secret_key: bytes


def keygen() -> ToyKeyPair:
    """説明用の鍵ペアを生成する。

    実際のKEMでは、数学的な構造に基づいて公開鍵と秘密鍵を生成する。
    ここでは流れを見せるため、ランダムな値から擬似的に作っている。
    """
    secret_key = secrets.token_bytes(32)
    public_key = hashlib.sha256(secret_key).digest()
    return ToyKeyPair(public_key=public_key, secret_key=secret_key)


def encapsulate(public_key: bytes) -> tuple[bytes, bytes]:
    """公開鍵からカプセルと共有秘密を作る。

    戻り値:
    - capsule: 受信側に送るデータ
    - shared_secret: 送信側が得る共有秘密

    実際のKEMでは、公開鍵を使って安全にカプセルを作る。
    ここでは説明用に、ランダム値と公開鍵からハッシュを作っている。
    """
    random_value = secrets.token_bytes(32)
    capsule = random_value
    shared_secret = hashlib.sha256(public_key + random_value).digest()
    return capsule, shared_secret


def decapsulate(secret_key: bytes, capsule: bytes) -> bytes:
    """秘密鍵とカプセルから共有秘密を取り出す。

    実際のKEMでは、秘密鍵を使ってカプセルを復号・検証し、
    送信側と同じ共有秘密を導く。
    ここでは keygen() で作った public_key を再現してから、
    encapsulate() と同じ形のハッシュを計算している。
    """
    public_key = hashlib.sha256(secret_key).digest()
    shared_secret = hashlib.sha256(public_key + capsule).digest()
    return shared_secret


# 受信側が鍵ペアを作る
receiver_keys = keygen()

# 送信側が受信側の公開鍵を使って、カプセルと共有秘密を作る
capsule, sender_secret = encapsulate(receiver_keys.public_key)

# 受信側が秘密鍵とカプセルから、同じ共有秘密を取り出す
receiver_secret = decapsulate(receiver_keys.secret_key, capsule)

print(sender_secret == receiver_secret)  # True になれば、同じ共有秘密を持てている

出力例:

True

このコードで見てほしいのは、暗号の強さではなく、KEMの流れです。

受信側が公開鍵と秘密鍵を作る
送信側が公開鍵を使ってカプセルと共有秘密を作る
受信側が秘密鍵を使って同じ共有秘密を取り出す
その共有秘密をもとに、AESなどの共通鍵暗号で実際の通信を守る

実際のML-KEMは、Module Learning with Errorsという問題の難しさに安全性を関係づけています。
FIPS 203では、ML-KEMは公開チャネル上で2者が共有秘密鍵を確立するために使えるKEMとして定義され、ML-KEM-512、ML-KEM-768、ML-KEM-1024という3つのパラメータセットが示されています。

デジタル署名は「本物確認の印鑑」のようなもの

もう1つの大きな役割が、デジタル署名です。

デジタル署名は、データの作成者が本物であることや、データが途中で改ざんされていないことを確認するために使われます。

身近な例では、次のような場面です。

Webサイト証明書の検証
アプリやOSアップデートの確認
電子文書の署名
ソフトウェア配布元の確認

FIPS 204でも、デジタル署名はデータの不正な変更を検出し、署名者の身元を認証するために使われると説明されています。

署名の流れも、インターフェースだけ見るとシンプルです。

おもちゃのコードで、署名・検証の形だけを見ると次のようになります。

# 注意:
# これはデジタル署名の「使い方の形」を示すおもちゃの例です。
# 実際の署名方式として安全ではありません。
# ML-DSAやSLH-DSAの実装例ではありません。

import hashlib
import hmac
import secrets


def sign_keygen() -> bytes:
    """説明用の署名鍵を作る。

    本物のデジタル署名では、公開鍵と秘密鍵のペアを作る。
    ここでは説明を単純にするため、秘密の値だけを使っている。
    """
    return secrets.token_bytes(32)


def sign(secret_key: bytes, message: bytes) -> bytes:
    """メッセージに説明用の署名を付ける。

    hmac は本来、共通鍵を使うメッセージ認証コードであり、
    公開鍵署名ではない。
    ここでは「メッセージと鍵から検証用の値を作る」流れだけを見る。
    """
    return hmac.new(secret_key, message, hashlib.sha256).digest()


def verify(secret_key: bytes, message: bytes, signature: bytes) -> bool:
    """説明用の署名を検証する。

    実際の公開鍵署名では、検証には公開鍵を使う。
    この例では簡略化のため、同じ秘密鍵を使って再計算している。
    """
    expected = sign(secret_key, message)
    return hmac.compare_digest(expected, signature)


secret_key = sign_keygen()
message = b"app update version 1.2.3"

signature = sign(secret_key, message)

print(verify(secret_key, message, signature))
print(verify(secret_key, b"app update version 9.9.9", signature))

出力例:

True
False

2つ目が False になるのは、メッセージが変わると署名の検証に失敗するからです。
実際のデジタル署名では、署名者だけが秘密鍵で署名し、誰でも公開鍵で検証できます。

PQCの署名方式では、この役割を従来のRSA署名やECDSAではなく、量子コンピュータによる攻撃も考慮した方式で実現します。

NIST標準では、ML-DSAとSLH-DSAがデジタル署名のための方式として公開されています。
ML-DSAは格子ベースの署名方式、SLH-DSAはハッシュベースの署名方式として整理できます。

5.4 PQCにはいくつかの「数学の土台」がある

PQCと一口に言っても、1つの方式だけを指すわけではありません。
複数の数学的な土台を使った方式が研究されてきました。

代表的には、次のような分類があります。

分類	ざっくりしたイメージ	代表的な位置づけ
格子ベース暗号	高次元の格子の中で、近い点や隠れた構造を見つけるのが難しいことを使う	ML-KEM、ML-DSAなど
ハッシュベース署名	ハッシュ関数の性質を使って署名を作る	SLH-DSAなど
符号ベース暗号	誤り訂正符号に関する問題の難しさを使う	HQCなど、追加標準候補として扱われている方式
多変数多項式ベース	多くの変数を持つ方程式を解く難しさを使う	研究・候補方式として扱われてきた分類
同種写像ベース	楕円曲線の間の写像に関する問題を使う	研究されてきた分類だが、標準化状況には注意が必要

ENISAの調査資料でも、PQCアルゴリズムの主なファミリーとして、符号ベース、同種写像ベース、ハッシュベース、格子ベース、多変数多項式ベースが整理されています。

参考: ENISA - Post-Quantum Cryptography: Current state and quantum mitigation

現在のNIST標準として特に重要なのは、格子ベースの ML-KEM / ML-DSA と、ハッシュベースの SLH-DSA です。
ただし、これは「他の分類がすべて不要」という意味ではありません。
NISTは追加の標準やバックアップとなる方式の検討も続けています。

参考: NIST CSRC - Post-Quantum Cryptography PQC

💡 豆知識
「格子」と聞くと、方眼紙のマス目のような2次元の図を想像するかもしれません。
格子ベース暗号で出てくる格子は、もっと高い次元の空間を扱います。
2次元なら近い点を探すのは目で見てできそうですが、何百次元、何千次元のような世界になると、人間の直感ではかなり想像しにくくなります。
この「高次元になると難しくなる問題」を暗号の土台に使う、というのが格子ベース暗号のざっくりしたイメージです。

5.5 PQCは「新しいから絶対安全」ではない

ここまで読むと、PQCは量子コンピュータ時代の切り札のように見えるかもしれません。

しかし、注意点もあります。

PQCは、将来の量子コンピュータによる攻撃に備えるための重要な技術です。
一方で、「PQCにすればすべて安全」というわけではありません。

理由はいくつかあります。

アルゴリズム自体の安全性評価は、今後も続く
実装ミスやサイドチャネル攻撃のリスクは残る
鍵管理、乱数生成、証明書運用が弱ければ安全性は崩れる
既存システムとの互換性や性能面の検証が必要になる
将来、標準や推奨方式が更新される可能性がある

RFC 9958でも、PQCアルゴリズムや実装は従来方式ほど長く使い込まれていないため、移行期にはハイブリッド方式などを使って段階的に信頼を移す考え方が説明されています。

参考: RFC 9958 - Post-Quantum Cryptography for Engineers

つまり、PQCは「導入すれば終わり」の魔法の箱ではありません。

むしろ、PQCの導入は次のような広い取り組みの一部です。

ここは、情報セキュリティらしい重要な考え方です。

暗号技術は、アルゴリズム単体で安全性が決まるわけではありません。
どのように実装するか、どのように鍵を管理するか、どのように更新できる設計にしておくかまで含めて、はじめて安全性を考えることができます。

5.6 この章のまとめ

この章では、耐量子暗号そのものを整理しました。

ポイントは次の通りです。

耐量子暗号は、Post-Quantum Cryptography、PQCとも呼ばれる
PQCは、量子コンピュータを使う暗号ではない
通常のコンピュータ上で動き、将来の量子コンピュータによる攻撃にも備える暗号方式である
PQCの中心は、RSAや楕円曲線暗号などの公開鍵暗号を置き換えることにある
大きな役割として、KEMとデジタル署名がある
NIST標準では、ML-KEM、ML-DSA、SLH-DSAが重要である
格子ベース、ハッシュベース、符号ベースなど、複数の数学的な土台がある
PQCにすればすべて安全、というわけではなく、実装・運用・移行設計まで含めて考える必要がある

ここまでで、「耐量子暗号とは何か」の全体像が見えてきました。

次の章では、NIST標準化で具体的に何が決まったのかを、ML-KEM、ML-DSA、SLH-DSAの役割に分けて整理します。

6. NIST標準化で何が決まったのか

前の章では、耐量子暗号が主に KEM と デジタル署名 の役割で、現在の公開鍵暗号の一部を置き換えていく技術だと整理しました。

ここまでで、耐量子暗号が「量子コンピュータを使う暗号」ではなく、将来の量子コンピュータによる攻撃にも備えるための暗号方式であることが見えてきました。

では、実際にどの方式を使えばよいのでしょうか。

暗号技術では、この問いがとても重要です。
なぜなら、暗号方式は「なんとなく強そうだから」「新しいから」という理由で選ぶものではないからです。

安全性の評価、実装のしやすさ、通信プロトコルへの組み込みやすさ、他のシステムとの互換性などを踏まえて、標準化された方式を使うことが大切になります。

そこで中心になるのが、NIST による耐量子暗号の標準化です。

NISTは、National Institute of Standards and Technologyの略で、日本語では「米国国立標準技術研究所」と呼ばれます。
米国の機関ではありますが、暗号技術やセキュリティガイドラインの分野では国際的にも大きな影響力があります。

💡 豆知識
AESも、もともとはNISTの標準化プロセスを経て選ばれた暗号方式です。
現在では、Web通信、VPN、ストレージ暗号化など、さまざまな場所で使われています。
耐量子暗号の標準化も、「研究室の中だけの技術」を、実際の社会システムで使える形に近づけるための重要なステップと考えると分かりやすいです。

参考: NIST - NIST Releases First 3 Finalized Post-Quantum Encryption Standards

6.1 まず押さえたい3つの標準

NISTは2024年8月に、最初の3つの耐量子暗号標準を公開しました。

FIPS	方式名	主な役割	ざっくりした説明
FIPS 203	ML-KEM	KEM	通信相手と共有秘密を作るための方式
FIPS 204	ML-DSA	デジタル署名	データが本物で、改ざんされていないことを確認する方式
FIPS 205	SLH-DSA	デジタル署名	ハッシュ関数を土台にした、別系統の署名方式

参考: NIST CSRC - FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
参考: NIST CSRC - FIPS 204: Module-Lattice-Based Digital Signature Standard
参考: NIST CSRC - FIPS 205: Stateless Hash-Based Digital Signature Standard

補足
FIPS 203 / 204 / 205 は公開済みの標準ですが、NIST CSRCの各ページには補足資料やerrataが掲載される場合があります。
実装や調達で参照する場合は、本文だけでなく、NIST CSRCページ上の最新情報やerrataも確認する必要があります。

図にすると、次のような対応関係になります。

ここで大事なのは、ML-KEMだけではすべての役割を置き換えられない という点です。

通信のための共有秘密を作る役割と、データに署名して本物であることを確認する役割は別です。
そのため、PQCへの移行では、KEMとデジタル署名の両方を考える必要があります。

6.2 ML-KEM：通信のための共有秘密を作る方式

最初に見るのは ML-KEM です。

ML-KEMは、Module-Lattice-Based Key-Encapsulation Mechanismの略です。
日本語にすると「モジュール格子ベースの鍵カプセル化メカニズム」のようになります。

名前だけ見るとかなり難しいですが、役割は前の章で見たKEMです。

通信相手と、あとで共通鍵暗号に使うための共有秘密を作る方式

HTTPS通信を例にすると、実際のデータを暗号化する場面では、AESのような共通鍵暗号が使われます。
しかし、その共通鍵をどうやって安全に共有するかが問題になります。

従来は、ここでECDHのような楕円曲線暗号ベースの鍵共有が使われてきました。
しかし、量子コンピュータ時代を見据えると、この部分を耐量子な方式に置き換える必要があります。

そこで候補になるのがML-KEMです。

FIPS 203では、ML-KEMの安全性は Module Learning with Errors 問題の計算困難性に関係していると説明されています。
また、ML-KEMには次の3つのパラメータセットがあります。

パラメータセット	ざっくりした位置づけ	説明のイメージ
ML-KEM-512	軽め	処理性能を重視しやすい
ML-KEM-768	中間	バランスを取りやすい
ML-KEM-1024	強め	より高い安全強度を狙う

ただし、ここで「大きい数字なら常にそれを選べばよい」と考えるのは少し危険です。

安全強度が高い設定は、鍵サイズや処理コストなどの面で重くなることがあります。
そのため、実際には利用するシステムの要件、守るデータの重要度、性能への影響、利用する標準やガイドラインを踏まえて選ぶ必要があります。

FIPS 203でも、ML-KEM-512、ML-KEM-768、ML-KEM-1024は、セキュリティ強度が高くなる一方で性能面のトレードオフがあるものとして整理されています。

参考: NIST CSRC - FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard

💡 豆知識
ML-KEMは、標準化前には CRYSTALS-Kyber と呼ばれていました。
NIST標準として公開される際に、標準名としてML-KEMという名前が使われています。
そのため、少し前の記事やライブラリの説明では「Kyber」と書かれていることがあります。

6.3 ML-DSA：デジタル署名の中心的な標準

次に見るのは ML-DSA です。

ML-DSAは、Module-Lattice-Based Digital Signature Algorithmの略です。
役割は、デジタル署名です。

デジタル署名は、次のような確認に使われます。

このデータは本当に送信者が作ったものか
途中で改ざんされていないか
ソフトウェアの配布元は本物か
証明書を発行した認証局は信頼できるか

身近なイメージでいうと、デジタル署名は「電子的な印鑑」のようなものです。
ただし、単なる画像のハンコではなく、データが1文字でも変わると検証に失敗するような、数学的な仕組みです。

FIPS 204では、ML-DSAはデジタル署名の生成と検証に使えるアルゴリズム群として定義されています。

参考: NIST CSRC - FIPS 204: Module-Lattice-Based Digital Signature Standard

ML-DSAには、次の3つのパラメータセットがあります。

パラメータセット	ざっくりした位置づけ	説明のイメージ
ML-DSA-44	軽め	署名サイズや処理負荷を抑えやすい
ML-DSA-65	中間	バランスを取りやすい
ML-DSA-87	強め	より高い安全強度を狙う

デジタル署名は、通信の「最初の本人確認」だけでなく、ソフトウェア更新や文書の真正性確認にも関わります。

たとえば、アプリのアップデートファイルを配布するとき、攻撃者が偽物の更新ファイルを紛れ込ませると大きな問題になります。
そこで、配布元が秘密鍵で署名し、利用者側が公開鍵で検証することで、「これは本物の配布元が作ったファイルか」を確認します。

量子コンピュータ時代には、この署名部分もPQC対応が必要になります。
ML-KEMで通信の共有秘密を作れても、証明書やソフトウェア署名が従来のRSA署名やECDSAのままだと、別の場所に弱点が残る可能性があります。

💡 豆知識
ML-DSAは、標準化前には CRYSTALS-Dilithium と呼ばれていました。
「Kyber」と「Dilithium」は、研究段階やライブラリ名として今でも見かけることがあります。
標準名と旧名称の両方を知っておくと、資料を読むときに混乱しにくくなります。

6.4 SLH-DSA：ハッシュベースの署名方式

3つ目は SLH-DSA です。

SLH-DSAは、Stateless Hash-Based Digital Signature Algorithmの略です。
名前にある通り、ハッシュ関数を土台にしたデジタル署名方式です。

FIPS 205では、SLH-DSAは、データの不正な変更を検出し、署名者の身元を認証し、否認防止にも使えるデジタル署名方式として説明されています。

参考: NIST CSRC - FIPS 205: Stateless Hash-Based Digital Signature Standard

ここで注目したいのは、SLH-DSAがML-DSAとは異なる数学的な土台を持つことです。

方式	分類	ざっくりした特徴
ML-DSA	格子ベース署名	署名方式の中心的な標準として使いやすい位置づけ
SLH-DSA	ハッシュベース署名	格子とは異なる土台を持つ署名方式

暗号の世界では、1つの方式だけに完全に依存するのではなく、異なる数学的な土台を持つ方式を用意しておくことが重要になる場合があります。

これは、家の防犯でたとえると、玄関の鍵を新しくするだけでなく、窓や裏口の対策も考えるようなものです。
1つの仕組みに問題が見つかったとき、別の仕組みが選択肢として存在することは、長期的な安全性を考えるうえで大切です。

ただし、SLH-DSAはハッシュベースであることから、署名サイズや処理性能の面でML-DSAとは異なる特徴を持ちます。
そのため、どちらか一方が常に優れているというよりも、用途や制約に応じて選ぶものとして理解するのが自然です。

💡 豆知識
SLH-DSAは、標準化前には SPHINCS+ と呼ばれていました。
「stateless」という言葉は、署名のたびに過去の署名回数などの状態管理を必須にしない、という意味合いで使われています。
状態管理が必要な署名方式では、同じ状態を誤って再利用すると安全性に問題が出る場合があります。
その点で、statelessであることは運用上の分かりやすさにつながります。

6.5 旧名称と標準名の対応

PQCの資料を読んでいると、同じ方式なのに名前が違って見えることがあります。

これは、NIST標準化の過程で、研究・提案時の名前と標準としての名前が変わっているためです。

標準名	以前よく使われていた名前	役割
ML-KEM	CRYSTALS-Kyber	KEM
ML-DSA	CRYSTALS-Dilithium	デジタル署名
SLH-DSA	SPHINCS+	デジタル署名

参考: NIST - NIST Releases First 3 Finalized Post-Quantum Encryption Standards

初学者にとっては、ここが意外と混乱しやすいです。

たとえば、ある資料では「Kyberを使う」と書かれていて、別の資料では「ML-KEMを使う」と書かれている場合があります。
この2つはまったく別物というより、標準化前後の呼び方の違いとして理解すると読みやすくなります。

もちろん、厳密には標準化に伴って仕様が整理されているため、実装や運用では「標準として定義されたML-KEM」を参照することが重要です。

6.6 役割で見ると、標準化の意味が分かりやすい

ここまでの内容を、利用場面に対応させて整理します。

利用場面	従来よく使われる技術	PQCで関係する標準	見るべきポイント
HTTPS通信の鍵共有	ECDHなど	ML-KEM	通信用の共有秘密をどう作るか
Webサイト証明書	RSA署名、ECDSAなど	ML-DSA、SLH-DSA	証明書の署名をどう検証するか
ソフトウェア更新	RSA署名、ECDSAなど	ML-DSA、SLH-DSA	更新ファイルの本物確認をどう行うか
電子文書の署名	RSA署名、ECDSAなど	ML-DSA、SLH-DSA	文書の改ざん検出や署名者確認をどう行うか

この表から分かる通り、PQC移行では「鍵共有だけ変えれば終わり」ではありません。

たとえば、HTTPSの通信内容を守るためにML-KEMを導入したとしても、サーバー証明書の署名が従来方式のままであれば、認証の部分には別の課題が残ります。
逆に、署名だけPQCにしても、鍵共有が従来方式のままなら、通信の共有秘密を作る部分に課題が残ります。

つまり、PQCへの移行では、システム全体の中で どこにKEMがあり、どこに署名があるのか を見分けることが大切です。

6.7 標準化は「これで終わり」ではない

NISTが最初のPQC標準を公開したことは、大きな節目です。

しかし、標準化はそこで完全に終わったわけではありません。

NISTのPQC標準化プロジェクトでは、追加の方式についても検討が続いています。
たとえば、NISTは2025年3月に、ML-KEMのバックアップとなる追加の暗号化アルゴリズムとして HQC を選定したと発表しています。

参考: NIST - NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption
参考: NIST CSRC - PQC Standardization Process

ここで注意したいのは、HQCは「選定された」段階として紹介されており、FIPS 203 / 204 / 205のように最終版FIPSとして公開済みの3方式とは段階が異なることです。

このように、PQCは実用化に向けて大きく前進している一方で、標準化・実装・運用ノウハウは今後も更新されていく分野です。

そのため、記事やシステム設計でPQCを扱うときは、次のような姿勢が大切です。

いつ時点の情報なのかを明記する
公式標準と候補・検討中の方式を分けて書く
「今後変更される可能性がある」部分は断定しすぎない
実装時には最新の標準・ライブラリ・ガイドラインを確認する

本記事でも、検証日を明記し、一次情報を優先して参照する方針にしています。

6.8 日本国内ではCRYPTREC暗号リストも重要

ここまでNISTの話を中心に見てきましたが、日本国内で暗号技術を考えるときには CRYPTREC も重要です。

CRYPTREC暗号リストは、電子政府における調達のために参照すべき暗号のリストとして公開されています。
デジタル庁、総務省、経済産業省は、CRYPTRECの活動を通して電子政府で利用される暗号技術の評価を行っており、CRYPTREC暗号リストは電子政府推奨暗号リスト、推奨候補暗号リスト、運用監視暗号リストから構成されています。

参考: CRYPTREC - CRYPTREC暗号リスト

2026年3月30日の更新では、鍵共有 ML-KEM が電子政府推奨暗号リストに追加されています。

参考: CRYPTREC - 新着情報

これは、PQCへの移行が海外の標準化だけでなく、日本国内の公的な暗号利用方針の中でも扱われ始めていることを示しています。

ただし、CRYPTREC暗号リストにML-KEMが追加されたからといって、すべてのシステムがすぐにML-KEMへ完全移行するという意味ではありません。
実際の移行では、利用しているプロトコル、証明書、ライブラリ、機器、クラウドサービス、外部連携先などを確認しながら、段階的に進める必要があります。

6.9 この章のまとめ

この章では、NIST標準化で何が決まったのかを整理しました。

ポイントは次の通りです。

NISTは2024年8月に、最初の3つのPQC標準を公開した
FIPS 203はML-KEMを定義しており、KEMとして共有秘密の確立に使う
FIPS 204はML-DSAを定義しており、デジタル署名に使う
FIPS 205はSLH-DSAを定義しており、ハッシュベースのデジタル署名に使う
ML-KEMは、標準化前にはCRYSTALS-Kyberと呼ばれていた
ML-DSAは、標準化前にはCRYSTALS-Dilithiumと呼ばれていた
SLH-DSAは、標準化前にはSPHINCS+と呼ばれていた
PQC移行では、鍵共有と署名を分けて考える必要がある
NISTの標準化は進んでいるが、HQCなど追加方式の検討も続いている
日本国内では、CRYPTREC暗号リストに鍵共有ML-KEMが追加されている

ここまでで、「どのPQC方式が標準として扱われているのか」が見えてきました。

次の章では、標準化された方式を実際のシステムへ移行していくために必要な考え方として、暗号アジリティ を整理します。
暗号方式を知るだけでなく、あとから安全に入れ替えられる設計にしておくことが重要になります。

7. 移行準備には暗号アジリティが必要

前の章では、NIST標準化によってML-KEM、ML-DSA、SLH-DSAといった代表的な方式が整理されていることを見ました。

では、標準化された方式があるとして、システム側ではどのように移行しやすい状態を作ればよいのでしょうか。

このとき重要になるのが、暗号アジリティです。

暗号アジリティは、簡単に言うと、暗号方式を将来入れ替えやすくしておく力です。

もう少し具体的に言うと、現在使っている暗号方式が古くなったり、より安全な方式へ移行する必要が出たりしたときに、システム全体を作り直さなくても、設定やライブラリ、プロトコルの更新によって段階的に対応できるようにしておく考え方です。

NISTは、暗号アジリティを、プロトコル、アプリケーション、ソフトウェア、ハードウェア、ファームウェア、インフラの中で使われる暗号アルゴリズムを、セキュリティと継続運用を保ちながら置き換え・適応できる能力として説明しています。

参考: NIST CSRC - Considerations for Achieving Crypto Agility

7.1 暗号は「家電」よりも「配管」に近い

暗号方式の移行は、スマホアプリのアイコンを変えるような作業ではありません。

どちらかというと、建物の中に埋め込まれている配管や電気配線を見直す作業に近いです。

普段は見えません。
うまく動いているときは、意識することもほとんどありません。

しかし、いざ交換が必要になると、どこを通っているのか、どの部屋につながっているのか、他の設備に影響しないかを確認する必要があります。

暗号も同じです。

たとえば、あるシステムでRSA署名を使っているとしても、それがソースコードの1か所だけに書かれているとは限りません。

証明書の発行、ログイン処理、外部API連携、JWTの検証、ソフトウェア更新、監査ログの署名など、さまざまな場所に分散している可能性があります。

そのため、暗号アジリティでは、単に「新しい暗号方式を知っている」だけでは不十分です。

どこで暗号を使っているかを把握できること、そして必要になったときに安全に切り替えられる設計になっていることが重要になります。

7.2 暗号アジリティがないと何が困るのか

暗号アジリティが低いシステムでは、暗号方式を変更しようとしたときに、いろいろな場所で問題が起きます。

たとえば、次のような状態です。

状態	困ること
暗号方式がコード内に直接書かれている	変更箇所が多く、漏れが出やすい
古いライブラリに強く依存している	新しいPQC方式に対応できない可能性がある
証明書や鍵の管理方法が整理されていない	どの鍵を更新すべきか分からない
外部サービスとの依存関係が見えない	自分だけ更新しても通信できなくなる可能性がある
テスト環境がない	本番で切り替えるまで影響が分からない
ロールバック手順がない	問題が起きたときに戻せない

NISTのCSWP 39でも、暗号アルゴリズムの移行はコストがかかり、時間も必要で、相互運用性の問題や運用への影響が出ると整理されています。

参考: NIST CSRC - CSWP 39: Considerations for Achieving Cryptographic Agility

ここでいう相互運用性とは、「自分のシステムと相手のシステムが、同じ約束ごとで正しく通信できること」です。

たとえば、自分のサービスだけが新しい暗号方式に対応していても、通信相手のブラウザ、APIクライアント、認証局、クラウドサービス、古い端末が対応していなければ、通信は成立しないかもしれません。

暗号方式の移行では、自分だけが正しい方式を選べば終わりではありません。
周囲のシステムや利用者環境も含めて、段階的に移行できる形を考える必要があります。

7.3 暗号アジリティは「何でも自由に選べること」ではない

ここで注意したいのは、暗号アジリティは「好きな暗号方式を自由に選べるようにすること」ではない、という点です。

暗号方式を利用者や開発者が自由に選べるようにしすぎると、かえって危険になる場合があります。

たとえば、設定ミスで古い方式を使い続けてしまったり、安全性が確認されていない方式を選んでしまったりする可能性があります。

そのため、暗号アジリティでは、次の2つのバランスが大切です。

観点	説明
入れ替えやすさ	将来、安全な方式に移行できるようにする
統制	誰でも自由に危険な方式を選べる状態にしない

身近な例で言えば、会社のPC管理に少し似ています。

OSやアプリは更新できる必要があります。
しかし、利用者が勝手に怪しいソフトを入れられる状態は危険です。

暗号も同じで、更新できる余地は持たせるが、選べる方式は安全なポリシーで管理するという考え方が必要になります。

7.4 「設定で切り替えられる設計」にしておく

暗号アジリティを高めるための基本的な考え方の1つは、暗号方式をコードのあちこちに直接書かないことです。

もちろん、実際の暗号処理はOpenSSL、BoringSSL、libsodium、各クラウドKMS、言語標準ライブラリなど、信頼できるライブラリやサービスに任せるべきです。
自分で暗号アルゴリズムを実装するのは、学習目的を除けば基本的に避けるべきです。

ここで示すコードは、暗号アルゴリズムそのものを実装する例ではありません。
どの方式を使うかを、設定として一元管理する考え方を示すための簡単なイメージです。

まず、あまりよくない例です。

# 悪い例: 暗号方式の名前が、処理の中に直接埋め込まれているイメージです。
# 実際の暗号処理を行うコードではなく、設計上の問題を説明するための例です。

def create_connection_profile():
    return {
        "key_establishment": "ECDH",   # 将来ML-KEMへ変えたい場合、この文字列を探して修正する必要がある
        "signature": "ECDSA",          # 別の場所にも同じ指定があると、変更漏れが起きやすい
        "symmetric_cipher": "AES-256-GCM",
    }


def verify_update_package():
    return {
        "signature": "ECDSA",          # ここにも同じ方式名が直接書かれている
        "hash": "SHA-256",
    }

このような書き方では、将来、署名方式をML-DSAに切り替えたいと思ったときに、コードのあちこちを探して直す必要があります。

小さな学習用コードなら問題になりにくいですが、実際のシステムでは、変更漏れや設定の不一致が起きやすくなります。

次に、少し改善したイメージです。

from dataclasses import dataclass


@dataclass(frozen=True)
class CryptoPolicy:
    """システムで利用する暗号方式の方針をまとめるためのデータクラスです。"""

    key_establishment: str
    signature: str
    symmetric_cipher: str
    hash_function: str


# 暗号方式を処理の中に直接散らばらせず、ポリシーとして一元管理します。
# ここでは説明用に current と pqc_trial を分けています。
# 実務では、標準・規制・ライブラリ対応・検証結果に基づいて慎重に決めます。
POLICIES = {
    "current": CryptoPolicy(
        key_establishment="ECDH",
        signature="ECDSA",
        symmetric_cipher="AES-256-GCM",
        hash_function="SHA-256",
    ),
    "pqc_trial": CryptoPolicy(
        key_establishment="ML-KEM-768",
        signature="ML-DSA-65",
        symmetric_cipher="AES-256-GCM",
        hash_function="SHA-256",
    ),
}


def get_crypto_policy(mode: str) -> CryptoPolicy:
    """指定されたモードに対応する暗号ポリシーを返します。"""
    if mode not in POLICIES:
        # 想定外のモードが指定された場合は、危険な方式へ落ちないようにエラーにします。
        raise ValueError(f"unknown crypto policy mode: {mode}")

    return POLICIES[mode]


# たとえば検証環境では pqc_trial、本番環境では current を使う、といった切り替えができます。
# 実際には、設定ファイル、環境変数、構成管理ツールなどで管理することが多いです。
policy = get_crypto_policy("pqc_trial")

print(policy)

このコードで重要なのは、ML-KEMやML-DSAを自分で実装していることではありません。

重要なのは、暗号方式の選択を1か所にまとめ、将来の変更を追いやすくしていることです。

もちろん、実際のシステムでは、これだけで十分ではありません。
利用しているTLSライブラリや認証基盤がその方式に対応しているか、証明書の発行・検証ができるか、相手システムと通信できるか、性能に問題がないかを確認する必要があります。

ただ、設計の考え方としては、次のように整理できます。

悪い状態	よりよい状態
暗号方式がコード内に散らばっている	暗号ポリシーとして一元管理されている
変更箇所が分からない	変更すべき箇所を追跡しやすい
古い方式が残っていても気づきにくい	棚卸し・監査で確認しやすい
検証環境で試しにくい	段階的な検証を行いやすい

7.5 暗号アジリティを高めるための観点

暗号アジリティを高めるには、コードの書き方だけでなく、設計・運用・調達まで含めて考える必要があります。

NIST NCCoEのPQC移行プロジェクトでも、暗号利用の発見、リスク管理、優先順位付け、相互運用性テストが重要な作業として扱われています。

参考: NIST NCCoE - Migration to Post-Quantum Cryptography

整理すると、次のようになります。

観点	確認したいこと	具体例
ライブラリ	利用中の暗号ライブラリが更新可能か	OpenSSLなどのバージョン、PQC対応状況
設定	暗号方式を設定として管理できるか	TLS設定、署名方式、鍵長、証明書プロファイル
鍵管理	鍵の生成・保管・更新・廃棄が整理されているか	KMS、HSM、証明書更新、鍵ローテーション
証明書	新しい署名方式や鍵方式に対応できるか	CA、ブラウザ、クライアント、サーバーの対応
外部依存	自分以外のシステムが対応しているか	クラウド、外部API、取引先、認証基盤
テスト	本番前に互換性と性能を確認できるか	検証環境、段階リリース、ロールバック手順
監視	古い方式が残っていないか検出できるか	ログ、資産管理、脆弱性管理、構成管理

特にPQCでは、従来の方式より鍵や署名のサイズが大きくなる場合があります。
そのため、暗号方式を変えるだけでなく、通信サイズ、証明書サイズ、処理時間、古い機器との互換性なども確認する必要があります。

7.6 ベンダやクラウドに確認すべきこと

暗号アジリティは、自分のコードだけで完結しないことも多いです。

多くのシステムでは、クラウド、CDN、認証基盤、決済サービス、メール配信サービス、VPN製品、セキュリティ機器など、外部サービスやベンダ製品に依存しています。

そのため、PQC移行では、ベンダやクラウド事業者の対応状況を確認することも重要です。

CISA、NIST、NSAが2023年に公開した量子準備に関する資料でも、量子準備ロードマップの作成、技術ベンダとの対話、暗号システム・資産の棚卸し、重要資産を優先した移行計画の作成が推奨されています。

参考: NSA - Post-Quantum Cryptography: CISA, NIST, and NSA Recommend How to Prepare Now

ベンダに確認する観点としては、次のようなものがあります。

確認項目	質問例
PQC対応予定	ML-KEMやML-DSAへの対応ロードマップはあるか
ハイブリッド方式	従来方式とPQCを組み合わせた移行に対応する予定はあるか
証明書対応	PQC署名やPQC関連の証明書に対応する予定はあるか
互換性	古いクライアントや機器との互換性にどう対応するか
性能影響	通信サイズ、遅延、CPU使用率などの評価結果はあるか
ロールバック	問題発生時に従来方式へ戻せる設計になっているか
サポート期限	量子に弱い方式のサポート終了予定はあるか

このような確認は、すぐにPQCへ移行しない段階でも意味があります。

なぜなら、自分のシステムがどれだけ外部の対応状況に依存しているかを把握できるからです。

7.7 暗号アジリティは「移行の保険」になる

暗号アジリティは、耐量子暗号だけのための考え方ではありません。

過去にも、暗号方式やプロトコルは何度も見直されてきました。

たとえば、古いハッシュ関数や古いTLSバージョンは、安全性や運用上の理由から利用が推奨されなくなってきました。
今は安全だと考えられている方式でも、将来の研究や計算能力の向上によって、見直しが必要になる可能性があります。

つまり、暗号アジリティは、将来の変化に備えるための「保険」のようなものです。

ここで大切なのは、「いつでも簡単に入れ替えられるから、今は何でもよい」という意味ではないことです。

むしろ逆です。

きちんと管理された形で入れ替えられるようにするためには、暗号の利用状況、設定、鍵管理、テスト、監視、ベンダ対応を普段から整えておく必要があります。

7.8 個人開発・学習でも意識できること

暗号アジリティという言葉は、企業や政府の大規模システム向けに聞こえるかもしれません。

しかし、個人開発や学習用アプリでも、考え方自体は役立ちます。

たとえば、次のような小さな工夫があります。

場面	意識できること
Webアプリを作る	TLSや証明書管理をフレームワーク・クラウド任せにしすぎず、設定を把握する
JWTを使う	署名方式、鍵更新、失効方法をドキュメント化する
APIキーを扱う	鍵をコードに直書きせず、環境変数やシークレット管理を使う
ライブラリを使う	暗号ライブラリの更新状況やサポート期限を確認する
READMEを書く	どの暗号技術に依存しているかを簡単に記録する

もちろん、個人開発でNISTレベルの移行計画を作る必要はありません。

しかし、暗号をブラックボックスのままにしないことは大切です。

「このアプリはどこでTLSに依存しているのか」
「JWTの署名方式は何か」
「鍵はどこで管理しているのか」
「ライブラリを更新したら何が影響を受けるのか」

こうした点を少しずつ整理しておくことが、将来のセキュリティ対応につながります。

7.9 この章のまとめ

この章では、耐量子暗号への移行を支える考え方として、暗号アジリティを整理しました。

ポイントは次の通りです。

暗号アジリティとは、暗号方式を将来入れ替えやすくしておく力である
暗号はシステムの深い部分に埋め込まれているため、移行には設計・運用・外部依存の確認が必要になる
暗号方式をコード内に散らばらせず、ポリシーや設定として管理する考え方が重要である
ただし、誰でも自由に方式を選べるようにすることが暗号アジリティではない
ライブラリ、証明書、鍵管理、外部サービス、テスト、監視まで含めて考える必要がある
ベンダやクラウドのPQC対応ロードマップを確認することも重要である
暗号アジリティは、PQCだけでなく、将来の暗号移行全般に備える考え方である

ここまでで、PQC移行に向けて「入れ替えやすい設計にしておく」ことの重要性を見てきました。

次の章では、移行期の現実的な考え方として、従来の暗号と耐量子暗号を組み合わせる ハイブリッド方式 を整理します。

8. 耐量子暗号だけで安全になるわけではない

前の章では、耐量子暗号への移行を支える考え方として、暗号アジリティを整理しました。

暗号アジリティの大切なポイントは、暗号方式を「固定された部品」として扱うのではなく、将来の変化に合わせて安全に入れ替えられるようにしておくことでした。

では、実際の移行期には、従来のRSAや楕円曲線暗号を一気に捨てて、すべてをPQCだけに置き換えるのでしょうか。

現実には、そう単純ではありません。

新しい方式は、標準化されたあとも、実装、運用、相互接続、性能評価、既存システムとの互換性を確認しながら広がっていきます。
そのため、移行期には、従来の暗号方式と耐量子暗号を組み合わせる ハイブリッド方式 が使われることがあります。

この章では、ハイブリッド方式を「既存方式とPQCを2つ並べるだけ」と雑に捉えず、何を守るためのハイブリッドなのか、どこに注意が必要なのかを整理します。さらに、PQCやハイブリッド方式だけで安全性がすべて完結するわけではない点も確認します。

参考: RFC 9794 - Terminology for Post-Quantum Traditional Hybrid Schemes
参考: RFC 9958 - Post-Quantum Cryptography for Engineers

8.1 ハイブリッド方式は「二重ロック」のように考えると分かりやすい

ハイブリッド方式を身近なたとえで考えるなら、玄関に2種類の鍵を付けるようなイメージです。

1つ目の鍵は、これまで長く使われてきた実績のある鍵です。
2つ目の鍵は、新しい脅威に備えるために追加した鍵です。

どちらか片方だけに完全に頼るのではなく、移行期間中は両方を使って安全性を支えよう、という考え方です。

もう少し暗号の言葉で言うと、ハイブリッド方式では、従来の鍵共有とPQCのKEMを両方実行し、それぞれから得られた秘密情報を安全に組み合わせて、最終的な通信用の鍵を作ります。

たとえば、次のようなイメージです。

構成要素	例	期待する役割
従来方式	X25519、ECDHなど	現在広く使われている方式としての実績・互換性
耐量子方式	ML-KEMなど	将来の量子コンピュータによる攻撃への備え
組み合わせ処理	KDF、HKDFなど	2つの秘密から最終的な鍵を安全に導く

ここで重要なのは、ハイブリッド方式は「従来方式もPQCも両方試せるようにする」だけではないという点です。

本当に守りたいのは、通信に使う最終的な鍵です。
そのため、2つの方式で得た秘密を、プロトコルで決められた方法に従って安全に混ぜる必要があります。

💡 豆知識
IETFのRFC 9794では、従来方式とPQCを組み合わせる方式を PQ/T hybrid と呼んで整理しています。
PQ は Post-Quantum、T は Traditional、つまり「耐量子方式」と「従来方式」の組み合わせという意味です。

8.2 なぜ最初からPQCだけにしないのか

ここで、次のように感じるかもしれません。

量子コンピュータに備えるなら、最初からPQCだけにすればよいのでは？

考え方としては自然です。
しかし、移行期にはいくつかの理由から、ハイブリッド方式が現実的な選択肢になります。

まず、PQCは標準化が進んでいるとはいえ、RSAや楕円曲線暗号ほど長い期間、広い環境で使い込まれてきたわけではありません。
NIST標準としてML-KEM、ML-DSA、SLH-DSAが公開されたことは大きな節目ですが、今後も実装、運用、相互接続、性能評価の知見は積み上がっていきます。

また、既存システムとの互換性も重要です。

Webブラウザ、サーバー、TLSライブラリ、認証局、ロードバランサ、CDN、セキュリティ機器、古い端末など、通信に関わる部品はたくさんあります。
片方だけがPQCに対応していても、相手側が対応していなければ通信できない可能性があります。

そのため、移行期には次のような考え方が出てきます。

考え方	内容
従来方式だけ	互換性は高いが、将来の量子コンピュータへの備えが弱い
PQCだけ	将来への備えは進むが、既存環境との互換性や実装成熟度の確認が必要
ハイブリッド方式	従来方式の実績とPQCの将来耐性を組み合わせる

RFC 9794でも、PQCと従来方式を組み合わせる方式がハイブリッドと呼ばれ、鍵確立やデジタル署名の文脈で整理されています。
また、ハイブリッド方式の性質は、構成要素となるアルゴリズム、組み合わせ方、攻撃者の能力に依存すると説明されています。

参考: RFC 9794 - Terminology for Post-Quantum Traditional Hybrid Schemes

8.3 TLSでは「X25519 + ML-KEM」のような組み合わせが検討されている

ハイブリッド方式を具体的に考える例として、TLS 1.3があります。

TLS 1.3は、HTTPS通信などで使われるプロトコルです。
1章でも見たように、ブラウザとサーバーは、通信の最初に鍵共有を行い、その結果から共通鍵暗号に使う鍵を導きます。

この鍵共有部分を、従来の楕円曲線ベースの方式とPQCの方式を組み合わせる形にする、というのがTLSにおけるハイブリッド鍵共有の考え方です。

IETFのInternet-Draftでは、TLS 1.3向けに X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024 というハイブリッド鍵共有の仕組み案が示されています。
これは、ML-KEMとECDHEを組み合わせる方式です。

参考: IETF Internet-Draft - Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

ただし、ここで注意が必要です。
この文書は2026年6月30日時点では Internet-Draft として扱われており、RFCとして公開済みの最終文書とは区別して読む必要があります。

そのため、記事で紹介するときは、次のように書き分けるのが安全です。

NISTのFIPS 203 / 204 / 205は、公開済みのPQC標準である
TLSでの具体的なハイブリッド利用方法は、IETFで標準化作業が進められている部分がある
実装時には、利用するライブラリやプロトコル仕様の最新状況を確認する必要がある

このように、PQCでは「暗号アルゴリズムの標準化」と「プロトコルへの組み込み」を分けて見ることが大切です。

8.4 ハイブリッド方式のゴールは1つではない

ハイブリッド方式と言っても、目的は1つだけではありません。

RFC 9794では、PQ/Tハイブリッド方式の性質として、機密性、認証、相互運用性、後方互換性、前方互換性などが整理されています。

初学者向けにざっくり言うと、次のように分けられます。

観点	何を目指すか	身近な言い方
ハイブリッド機密性	少なくとも一方の方式が安全なら、通信内容を守れるようにする	どちらかの鍵が生きていれば中身を守る
ハイブリッド認証	少なくとも一方の署名方式が安全なら、相手確認を守れるようにする	どちらかの身分証明が生きていれば本物確認を支える
相互運用性	対応状況が異なる相手とも段階的に通信できるようにする	新旧の環境が混ざっていても動かす
後方互換性	従来方式しか使えない相手とも接続できるようにする	古い環境もすぐには切り捨てない
前方互換性	PQC対応環境ではPQCを使えるようにする	新しい環境では新方式へ進める

ここで少しややこしいのは、安全性のためのハイブリッド と 互換性のためのハイブリッド は、同じではないという点です。

たとえば、安全性を重視するなら、従来方式とPQCの両方を使って、その結果を組み合わせる必要があります。
一方、互換性を重視するなら、相手が対応している方式に合わせて通信できることが大切になります。

しかし、相手が対応している片方だけで通信できるようにすると、攻撃者が新しい方式を使わせないようにする ダウングレード攻撃 のリスクが出ます。

そのため、ハイブリッド方式では、単に「複数の方式に対応する」だけでなく、プロトコル全体でダウングレードを防ぐ設計が必要になります。

RFC 9794でも、PQ/Tハイブリッドの相互運用性と機密性は、ハイブリッド方式単体だけで同時に満たせるとは限らず、プロトコルレベルで適切なダウングレード保護が必要になると整理されています。

8.5 鍵共有のハイブリッドと署名のハイブリッドは分けて考える

ここで、もう1つ重要な注意点があります。

それは、鍵共有のハイブリッド と 署名のハイブリッド は別の話だという点です。

TLSのハイブリッド鍵共有では、主に通信内容の機密性を守るために、従来の鍵共有とPQCのKEMを組み合わせます。
しかし、サーバー証明書の署名や認証部分が従来方式のままであれば、認証の部分はまだ従来方式に依存していることになります。

RFC 9794でも、ハイブリッドTLSのような設計はハイブリッド機密性を提供しても、単一アルゴリズムのX.509証明書を使う場合には、認証は単一アルゴリズムで達成されると説明されています。

つまり、次のように分けて考える必要があります。

領域	何を守るか	ハイブリッドで考える対象
鍵共有	通信内容の秘密を守る	ECDH + ML-KEMなど
認証・署名	相手が本物か、データが改ざんされていないかを確認する	ECDSA + ML-DSA、従来証明書 + PQC証明書など

この違いを混同すると、次のような誤解が起きます。

鍵共有をPQCハイブリッドにしたから、証明書や署名もすべて量子安全になった。

これは正確ではありません。

通信内容を守る部分と、相手を認証する部分は役割が違います。
そのため、PQC移行では、鍵共有と署名の両方について、どこまで対応できているかを確認する必要があります。

8.6 2つを混ぜるときは「混ぜ方」が大事

ハイブリッド方式では、従来方式とPQCで得た秘密情報を組み合わせます。

ここで大切なのは、混ぜ方を自分で適当に決めないことです。

たとえば、2つの値を単純に文字列としてつなげるだけでは、利用するプロトコルや文脈によっては十分でない場合があります。
実際には、TLSなどのプロトコル仕様に従い、HKDFのような鍵導出関数を使って、文脈情報も含めて安全に鍵を導きます。

RFC 9958では、KEMをプロトコルに組み込むときの注意点として、暗号文、公開鍵、文脈情報などを適切に結び付ける binding の性質が説明されています。
これは、攻撃者が別のセッションのカプセルや公開鍵を差し替えても、同じ共有秘密として扱われないようにするために重要です。

参考: RFC 9958 - Post-Quantum Cryptography for Engineers

以下は、ハイブリッド鍵共有の「混ぜる」という考え方だけを示す説明用コードです。
実際の暗号実装ではありません。実務では、自作した組み合わせではなく、プロトコル仕様と信頼できる暗号ライブラリに従う必要があります。

# 注意:
# これはハイブリッド鍵共有の「秘密を組み合わせる」という考え方を示す説明用コードです。
# 実際のTLSやSSHの実装ではありません。
# 実務では、プロトコル仕様に従い、HKDFなどの標準的な鍵導出関数を使います。

import hashlib
import secrets


def length_prefixed(value: bytes) -> bytes:
    """値の長さを付けてから連結するための補助関数です。

    単純に a + b と連結すると、境界が曖昧になる場合があります。
    ここでは説明用に、2バイトの長さを先頭に付けています。
    """
    return len(value).to_bytes(2, "big") + value


def derive_demo_hybrid_secret(
    traditional_secret: bytes,
    pq_secret: bytes,
    transcript_hash: bytes,
) -> bytes:
    """従来方式の秘密とPQCの秘密から、説明用の最終秘密を作ります。

    traditional_secret:
        X25519やECDHなど、従来方式から得た秘密のイメージです。

    pq_secret:
        ML-KEMなど、PQCのKEMから得た共有秘密のイメージです。

    transcript_hash:
        どの通信セッションで作られた秘密なのかを結び付けるための文脈情報です。
        TLSでは、ハンドシェイク全体の記録が鍵導出に関係します。

    注意:
        これは学習用の単純化です。
        実際にはTLS 1.3の鍵スケジュールやHKDFなど、仕様に従った処理が必要です。
    """
    input_material = b"demo-hybrid-v1" + length_prefixed(transcript_hash)
    input_material += length_prefixed(traditional_secret)
    input_material += length_prefixed(pq_secret)

    # hashlib.sha256で説明用の固定長値に変換します。
    # 実務では、このような独自処理ではなく標準仕様に従います。
    return hashlib.sha256(input_material).digest()


# 従来方式とPQC方式から得られた秘密を、ここではランダム値で代用します。
traditional_secret = secrets.token_bytes(32)
pq_secret = secrets.token_bytes(32)

# 通信セッションの文脈情報を表す値です。
# 実際のTLSでは、ハンドシェイクメッセージのハッシュなどが関係します。
transcript_hash = hashlib.sha256(b"client_hello || server_hello").digest()

final_secret = derive_demo_hybrid_secret(
    traditional_secret=traditional_secret,
    pq_secret=pq_secret,
    transcript_hash=transcript_hash,
)

print(final_secret.hex())

このコードで見てほしいのは、次の3点です。

従来方式の秘密とPQCの秘密を、最終的な鍵導出の材料にしている
どの通信セッションの秘密なのかを示す文脈情報も一緒に入れている
実務では、独自実装ではなく、TLSやSSHなどの仕様とライブラリに従う必要がある

ハイブリッド方式は、2つの暗号を「足し算」するだけではありません。
プロトコル全体の中で、どの値を、どの順番で、どの関数に入れるかまで決める必要があります。

8.7 ハイブリッド方式の注意点

ハイブリッド方式は移行期に役立つ考え方ですが、万能ではありません。

特に注意したい点を整理します。

注意点	内容
実装が複雑になる	2つの方式を扱うため、メッセージ形式や鍵導出が複雑になる
通信サイズが大きくなる	PQCの公開鍵やカプセルは、従来の楕円曲線暗号より大きい場合がある
性能への影響がある	処理時間、メモリ、帯域、レイテンシを確認する必要がある
ダウングレード攻撃に注意	攻撃者がPQC部分を使わせないようにする可能性がある
鍵や乱数の再利用に注意	KEMでは公開鍵や乱数の扱いを仕様に従う必要がある
認証まで守れるとは限らない	鍵共有をハイブリッド化しても、証明書署名は別途考える必要がある
標準化状況を確認する必要がある	Internet-DraftとRFC、NIST標準、ライブラリ実装の段階を分けて見る

IETFのTLSハイブリッド鍵共有に関する文書でも、ハイブリッド鍵共有の主な目標は、構成要素のうち少なくとも1つが破られていない限り共有秘密を安全に保つことだと説明されています。
また、KEMの公開鍵再利用や乱数再利用に関する注意も記載されています。

参考: IETF Internet-Draft - Hybrid key exchange in TLS 1.3

ここでも大事なのは、ハイブリッド方式を「強そうだから入れる」ではなく、何を守りたいのかを明確にして設計することです。

8.8 SSHでもハイブリッド鍵共有の検討が進んでいる

ハイブリッド方式はTLSだけの話ではありません。

たとえば、SSHでもML-KEMと従来の楕円曲線Diffie-Hellmanを組み合わせるハイブリッド鍵共有のInternet-Draftが進められています。
この文書では、SSH Transport Layer Protocolで使うPQ/Tハイブリッド鍵共有方式として、ML-KEMと従来のECDHを組み合わせる方法が定義されています。

参考: IETF Internet-Draft - PQ/T Hybrid Key Exchange with ML-KEM in SSH

これも2026年6月30日時点では、RFCとして公開済みの最終文書ではなく、IETFでの標準化作業中の文書として扱う必要があります。

このように、PQCの移行は、単に「WebのHTTPSだけ」の話ではありません。
SSH、VPN、メール、証明書基盤、ソフトウェア署名など、公開鍵暗号を使うさまざまなプロトコルや仕組みに関係していきます。

8.9 段階的な移行のイメージ

ここまでの内容を踏まえると、移行期の流れは次のように考えると分かりやすいです。

この流れで大切なのは、ハイブリッド方式を最終ゴールとして固定しないことです。

ハイブリッド方式は、移行期に安全性と互換性のバランスを取るための手段です。
将来的にPQC方式が十分に普及し、実装や運用ノウハウが成熟し、周辺システムも対応した段階では、従来方式を段階的に廃止していくことも考えられます。

つまり、ハイブリッド方式は「ずっと二重にしておけば安心」というより、安全に橋を渡るための仮設の橋として捉えると分かりやすいです。

8.10 ハイブリッド方式のまとめ

ここまで、移行期の考え方としてハイブリッド方式を整理しました。

ポイントは次の通りです。

ハイブリッド方式は、従来方式とPQCを組み合わせる移行期の考え方である
身近なたとえでは、従来の鍵と新しい鍵を組み合わせる「二重ロック」のように考えられる
TLSでは、X25519 + ML-KEMのようなハイブリッド鍵共有の標準化作業が進められている
ただし、Internet-DraftとRFC、NIST標準は段階が異なるため、扱いを分ける必要がある
ハイブリッド方式の目的には、機密性、認証、相互運用性、後方互換性、前方互換性などがある
鍵共有をハイブリッド化しても、署名や証明書まで自動的に量子安全になるわけではない
2つの秘密を混ぜるときは、プロトコル仕様に従い、文脈情報やダウングレード対策を含めて設計する必要がある
ハイブリッド方式は万能ではなく、通信サイズ、性能、実装複雑性、運用、標準化状況を確認する必要がある
ハイブリッド方式は最終ゴールというより、段階的にPQCへ移行するための現実的な橋渡しと考えると分かりやすい

ここまでで、耐量子暗号への移行を進めるうえでの現実的な考え方が見えてきました。

ここまでで、移行期にハイブリッド方式が役立つ場面と注意点が見えてきました。

ただし、耐量子暗号やハイブリッド方式を導入すれば、それだけで安全性がすべて完結するわけではありません。
続いて、読者がつまずきやすい誤解を整理しながら、PQCを現実のシステムでどう位置づけるべきかを確認します。

8.11 よくある誤解も合わせて整理する

耐量子暗号は、名前に「量子」が入っているため、少し大げさに見えたり、逆に難しすぎて自分には関係ないように感じたりしやすい分野です。

しかし実際には、ポイントを分けて考えるとかなり見通しがよくなります。
ここでは、よくある誤解を1つずつほどいていきます。

ここまで、耐量子暗号の背景、影響を受けやすい暗号、NIST標準化、移行準備、暗号アジリティ、ハイブリッド方式を見てきました。

最後に、読者がつまずきやすいポイントを整理しておきます。
耐量子暗号は、名前に「量子」が入っているため、少し大げさに見えたり、逆に難しすぎて自分には関係ないように感じたりしやすい分野です。

しかし実際には、ポイントを分けて考えるとかなり見通しがよくなります。

この章では、よくある誤解を1つずつほどいていきます。

誤解1：量子コンピュータができたら、明日すべての暗号が終わる

まず一番よくあるのが、

量子コンピュータが実用化されたら、暗号は全部終わるのでは？

という誤解です。

たしかに、十分に強力な量子コンピュータ、つまりCRQC（Cryptographically Relevant Quantum Computer）が実現すると、現在広く使われている公開鍵暗号の一部には大きな影響があります。

特に、RSA、Diffie-Hellman、楕円曲線暗号（ECC）などは、Shorのアルゴリズムの影響を強く受けます。IETFのRFC 9958でも、Shorのアルゴリズムは整数の素因数分解問題や離散対数問題を効率よく解くため、RSA、Diffie-Hellman、ECCなどの公開鍵暗号はCRQCが実現した場合に置き換えが必要になると説明されています。

参考: RFC 9958 - Post-Quantum Cryptography for Engineers

ただし、ここで大切なのは、すべての暗号が同じように壊れるわけではない という点です。

たとえば、AESのような共通鍵暗号や、SHA-2 / SHA-3のようなハッシュ関数は、RSAやECCと同じ意味で一気に置き換えが必要になるわけではありません。Groverのアルゴリズムによる影響はありますが、公開鍵暗号に対するShorのアルゴリズムの影響とは性質が異なります。

ざっくり分けると、次のようになります。

暗号技術	量子コンピュータの影響	考え方
RSA	大きい	将来的にはPQCへの置き換え対象
Diffie-Hellman / ECDH	大きい	鍵共有の置き換え対象
ECDSAなどの署名	大きい	署名方式の置き換え対象
AES	影響はあるが性質が異なる	十分な鍵長を使う方向で考える
SHA-2 / SHA-3	影響はあるが性質が異なる	出力長や用途を考えて安全性を見積もる

つまり、正確には次のように言うのがよいです。

量子コンピュータが暗号全体を一瞬で終わらせる、という話ではない。
ただし、現在の公開鍵暗号の一部は、将来のCRQCに備えて置き換えが必要になる可能性が高い。

不安をあおるよりも、影響を受ける場所を正しく分けること が大切です。

誤解2：耐量子暗号は、量子コンピュータを使う暗号である

次によくあるのが、

耐量子暗号って、量子コンピュータを使って暗号化する技術なの？

という誤解です。

名前だけ見ると、そう感じるのも自然です。
しかし、耐量子暗号は基本的に 現在のコンピュータ上で動かす暗号方式 です。

NISTは、Post-Quantum Cryptographyを、将来の量子コンピュータによる攻撃に備えるための暗号技術として説明しています。また、IETFのRFC 9958でも、PQCは量子鍵配送（QKD）や量子鍵生成のような量子ハードウェアを使う技術とは別であり、従来の数学とソフトウェアに基づき、一般的なコンピュータ上で動かせるものだと整理されています。

参考: NIST - What Is Post-Quantum Cryptography?
参考: RFC 9958 - Post-Quantum Cryptography for Engineers

ここは、「耐量子暗号」と「量子暗号」を分けて考えると分かりやすいです。

用語	ざっくりした意味	使うもの
耐量子暗号 / PQC	量子コンピュータによる攻撃にも耐えることを目指す暗号方式	通常のコンピュータ、ソフトウェア、数学
量子暗号 / QKDなど	量子力学の性質を利用して鍵共有などを行う技術	量子通信装置、専用ハードウェアなど

💡 豆知識
「Post-Quantum Cryptography」の “Post” は、「量子コンピュータが完成した後だけに使う」という意味ではありません。
むしろ、「量子コンピュータによる攻撃も想定した暗号」と捉えると分かりやすいです。

そのため、PQCは現在のインターネットやソフトウェアの仕組みに組み込みやすい一方で、既存のプロトコルや証明書、ライブラリとの相性をきちんと検証する必要があります。

誤解3：RSAやECCは、鍵を長くすればそのまま使い続けられる

次の誤解は、

量子コンピュータが強いなら、RSAの鍵をもっと長くすればよいのでは？

というものです。

古典コンピュータによる攻撃を考える場合、鍵長を長くすることは重要な対策になります。
しかし、Shorのアルゴリズムの影響を受ける公開鍵暗号では、単純に鍵長を伸ばせば現実的に解決できる、という話ではありません。

RFC 9958では、公開鍵や署名のような構造を持つデータについては、CRQCが従来の公開鍵暗号で使われる数学的な難問を解けるようになるため、単に鍵ペアを大きくすることは安全な解決策にならず、アルゴリズム自体の置き換えが必要になると説明されています。

参考: RFC 9958 - Post-Quantum Cryptography for Engineers

身近なたとえで言うと、鍵穴の仕組みそのものが攻略される可能性があるときに、鍵を少し大きくするだけでは不十分、というイメージです。

そのため、耐量子暗号では、素因数分解や離散対数問題とは異なる数学的な問題を土台にした方式が検討・標準化されています。

誤解4：AESやSHAも、RSAと同じように破られる

3章でも触れましたが、AESやSHAについても誤解が起きやすいです。

RSAが危ないなら、AESやSHAも同じように危ないのでは？

という考え方です。

しかし、公開鍵暗号と共通鍵暗号・ハッシュ関数では、量子コンピュータから受ける影響の性質が異なります。

RFC 9958では、対称鍵暗号やハッシュ関数に対してはGroverのアルゴリズムによる影響があるものの、Shorのアルゴリズムが公開鍵暗号に与える影響と比べると小さく、通常は鍵長やダイジェスト長を考慮することで緩和できると整理されています。

参考: RFC 9958 - Post-Quantum Cryptography for Engineers

特に、AES-128については「量子コンピュータ時代には必ず鍵長を倍にしなければならない」と単純に言い切れるものではありません。RFC 9958では、Groverのアルゴリズムには並列化しにくい性質があり、一般的な専門家の見解としてAES-128は実用上安全と考えられている、と説明されています。

ただし、これは「何も考えなくてよい」という意味ではありません。
長期間守る必要がある情報や、高い安全性を求めるシステムでは、AES-256などの強度の高い設定を選ぶ判断もあります。

大事なのは、次のように分けて考えることです。

種類	代表例	量子計算の影響	主な対応イメージ
公開鍵暗号	RSA, ECDH, ECDSA	Shorのアルゴリズムの影響が大きい	PQCへ置き換える
共通鍵暗号	AES	Groverのアルゴリズムの影響を受ける	必要に応じて鍵長を見直す
ハッシュ関数	SHA-256, SHA-384, SHA-3	Groverのアルゴリズムの影響を受ける	出力長や用途を見直す

誤解5：PQCにすれば完全に安全になる

PQCは、将来の量子コンピュータに備えるうえで重要な技術です。
しかし、次のように考えるのは危険です。

PQCにすれば、もう完全に安全になる。

暗号方式は、数学的に強いだけでは十分ではありません。
実際のシステムでは、実装ミス、鍵管理の不備、乱数生成の問題、サイドチャネル攻撃、証明書運用のミス、古い設定の残存など、さまざまな要素が安全性に影響します。

NISTのPQC標準であるFIPS 203、FIPS 204、FIPS 205は、それぞれML-KEM、ML-DSA、SLH-DSAを標準として定義しています。ただし、標準化された方式を使う場合でも、仕様に沿った実装、適切なパラメータ選択、鍵管理、プロトコルへの安全な組み込みが必要です。

参考: FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism Standard
参考: FIPS 204 - Module-Lattice-Based Digital Signature Standard
参考: FIPS 205 - Stateless Hash-Based Digital Signature Standard

特にPQCは、従来方式より鍵サイズや署名サイズが大きくなる場合があります。
そのため、通信プロトコル、証明書、組み込み機器、ネットワーク機器、ログ、監視、性能などへの影響も確認する必要があります。

PQCは「魔法の盾」ではなく、システム全体の中で正しく使ってこそ意味があります。

誤解6：移行はライブラリを差し替えるだけで終わる

開発者目線では、

暗号ライブラリを新しいものに差し替えれば終わりでは？

と思うかもしれません。

小さな学習用プログラムであれば、それに近い場合もあります。
しかし、実際のシステムではそう単純ではありません。

NIST NCCoEのPQC移行プロジェクトでは、まず組織がハードウェア、ソフトウェア、サービスの中でどこに量子脆弱な公開鍵暗号が使われているかを把握し、移行ロードマップやリスク管理、優先順位付け、相互運用性テストを進めることが重要だと説明されています。

参考: NIST NCCoE - Migration to Post-Quantum Cryptography

たとえば、次のような場所を確認する必要があります。

確認する場所	見るべきポイント
Webサーバー	TLS設定、証明書、対応する鍵共有方式
アプリケーション	使用している暗号ライブラリ、署名検証処理
クラウドサービス	ベンダのPQC対応状況、証明書管理、API通信
VPN / リモートアクセス	鍵交換方式、認証方式、クライアント互換性
IoT / 組み込み機器	CPU、メモリ、ファームウェア更新可否
ログ・監査	どの暗号方式をいつ使ったか追跡できるか

つまり、PQC移行は「1つのライブラリ更新」ではなく、システム全体の暗号利用を見える化し、順番を決めて置き換える作業です。

これが、4章で扱った暗号資産の棚卸しや、7章で扱った暗号アジリティにつながります。

誤解7：ハイブリッド方式にすれば全部解決する

この章の前半では、従来方式とPQCを組み合わせるハイブリッド方式を紹介しました。

ハイブリッド方式は、移行期の現実的な選択肢になり得ます。
ただし、

ハイブリッド方式にすれば、何も考えなくても安全になる。

というわけではありません。

IETFのRFC 9794では、Post-Quantum and Traditional Hybrid Schemes、つまりPQ/Tハイブリッド方式について、用語と考え方が整理されています。またRFC 9958では、ハイブリッド方式の安全性は構成要素のアルゴリズム、組み合わせ方、攻撃者の能力、プロトコル上の扱いに依存することが説明されています。

参考: RFC 9794 - Terminology for Post-Quantum Traditional Hybrid Schemes
参考: RFC 9958 - Post-Quantum Cryptography for Engineers

たとえば、ハイブリッド鍵共有では、従来方式で得た秘密とPQCで得た秘密をどのように鍵導出に使うかが重要です。
また、攻撃者が片方の方式を取り除くようなダウングレード攻撃や、別の文脈で鍵を誤って再利用する問題にも注意が必要です。

ハイブリッド方式は、「とりあえず2つ並べれば安心」というものではありません。
標準仕様やプロトコルの設計に従って、正しく組み合わせる必要があります。

誤解8：自分の個人開発や学習には関係ない

最後に、少し現実的な誤解です。

企業や政府システムの話であって、個人開発や学習には関係ないのでは？

たしかに、個人開発でいきなり本番システムのPQC移行を担当することは少ないかもしれません。
しかし、学習段階でも意識できることはあります。

たとえば、次のような観点です。

暗号アルゴリズム名をコードに直接ベタ書きしすぎない
TLSや証明書の仕組みを「なんとなく動くもの」で終わらせない
暗号ライブラリを自作せず、信頼できる実装を使う
使用しているライブラリや設定を記録しておく
仕様・一次情報を確認する習慣をつける
「新しい暗号だから安全」と短絡的に判断しない

個人開発でも、暗号方式を入れ替えやすい設計や、設定を見える化する習慣は役立ちます。
これは、PQCだけでなく、将来別の脆弱性や標準変更が起きたときにも重要です。

💡 豆知識
暗号の世界では、「安全な方式を選ぶこと」と同じくらい、「古くなった方式を安全にやめられること」も大切です。
つまり、暗号技術は“導入”だけでなく、“卒業”まで考える必要があります。

8.12 この章のまとめ

ここまでの誤解を、短くまとめると次のようになります。

誤解	正しくは
量子コンピュータで明日すべての暗号が終わる	影響は暗号の種類によって異なる。特に公開鍵暗号が重要
PQCは量子コンピュータを使う暗号である	一般的なコンピュータ上で動く、量子攻撃に備えた暗号方式
RSAやECCは鍵を長くすればよい	Shorのアルゴリズムの影響を考えると、根本的な置き換えが必要
AESやSHAもRSAと同じように破られる	Groverの影響はあるが、公開鍵暗号とは影響の性質が異なる
PQCにすれば完全安全	実装、鍵管理、乱数、プロトコル、運用まで含めて安全性を見る必要がある
移行はライブラリ差し替えだけ	棚卸し、検証、互換性、運用設計が必要
ハイブリッド方式なら全部解決	組み合わせ方やダウングレード対策が重要
個人開発には関係ない	暗号アジリティや一次情報確認の習慣は学習段階でも役立つ

この章で伝えたいのは、耐量子暗号を過度に怖がる必要はない、ということです。
同時に、「まだ先の話だから何もしなくてよい」と考えるのも危険です。

重要なのは、次のバランスです。

耐量子暗号は、暗号技術を「一度決めたら終わり」ではなく、将来の脅威に合わせて更新していくものとして捉えるきっかけになります。

次の章では、ここまでの内容をまとめます。
派生元記事で整理した暗号技術の全体像ともつなげながら、「なぜ今、耐量子暗号を学ぶ意味があるのか」を振り返ります。

9. まとめ

ここまで、耐量子暗号について、身近なサービスの裏側から順番に見てきました。

最初に確認したように、スマホ決済、ネットショッピング、HTTPS通信、アプリのアップデートなど、私たちが普段使っている仕組みの裏側では、暗号技術が当たり前のように使われています。
特に、公開鍵暗号、鍵共有、デジタル署名は、「初めて通信する相手と安全にやり取りする」「相手や配布元が本物か確認する」という場面で重要な役割を持っています。

一方で、将来十分に強力な量子コンピュータが実現すると、RSAや楕円曲線暗号のような現在広く使われている公開鍵暗号の安全性が大きく変わる可能性があります。
そのため、NISTは耐量子暗号の標準化を進め、2024年にはML-KEM、ML-DSA、SLH-DSAに対応する最初の3つのFIPS標準を公開しました。

参考: NIST - NIST Releases First 3 Finalized Post-Quantum Encryption Standards

ただし、この記事で何度も確認したように、これは「明日からすべての暗号が破られる」という話ではありません。
暗号の種類によって、量子コンピュータから受ける影響は異なります。

暗号の種類	代表例	量子コンピュータによる影響の考え方
公開鍵暗号	RSA, Diffie-Hellman, ECDH, ECDSA	Shorのアルゴリズムの影響が大きく、PQCへの置き換えが重要になる
共通鍵暗号	AES	Groverのアルゴリズムの影響はあるが、鍵長を十分に取ることで対策しやすい
ハッシュ関数	SHA-256, SHA-384, SHA-3	用途や出力長を踏まえて安全性を考える必要がある

つまり、耐量子暗号を学ぶうえで大切なのは、必要以上に怖がることではなく、どの暗号が、どのような理由で、どの程度影響を受けるのかを分けて考えることです。

9.1 耐量子暗号は「未来の話」だけではない

耐量子暗号という言葉を見ると、どうしても遠い未来の話に感じるかもしれません。

しかし実際には、今から考えるべき理由があります。
その代表例が、4章で紹介した Harvest Now, Decrypt Later です。

これは、攻撃者が今のうちに暗号化された通信やデータを保存しておき、将来十分に強力な量子コンピュータが使えるようになってから解読する、という考え方です。

たとえば、今日送ったメッセージが明日だけ秘密であれば、将来解読されるリスクはあまり問題にならないかもしれません。
しかし、医療情報、行政情報、金融情報、研究開発情報、長期契約に関する情報のように、何年も秘密であるべきデータでは話が変わります。

このように、耐量子暗号は「量子コンピュータが完成した後に考えればよい技術」ではありません。
長期間守る必要がある情報については、現在の設計や運用も将来のリスクとつながっています。

参考: NIST - What Is Post-Quantum Cryptography?

9.2 移行で大切なのは、暗号方式を知ることだけではない

この記事では、ML-KEM、ML-DSA、SLH-DSAといったNIST標準の方式も紹介しました。

もちろん、これらの方式を知ることは重要です。
しかし、実際の移行で必要になるのは、アルゴリズム名を覚えることだけではありません。

むしろ最初に必要になるのは、次のような地道な確認です。

どこでRSAやECDSA、ECDHなどを使っているのか
どの通信やデータが長期間守る必要のあるものなのか
利用しているライブラリやクラウドサービスはPQCに対応できるのか
古い機器や組み込み機器は、新しい暗号方式に対応できるのか
証明書、鍵管理、監査ログ、運用手順まで含めて変更できるのか

NIST NCCoEも、PQC移行では、組織内のハードウェア、ソフトウェア、サービスで量子に弱い公開鍵暗号がどこに使われているかを把握し、ロードマップや優先順位を考える必要があると説明しています。

参考: NIST NCCoE - Migration to Post-Quantum Cryptography

ここで重要になるのが、7章で扱った 暗号アジリティ です。
これは、暗号方式を必要に応じて入れ替えられるようにしておく考え方です。

たとえるなら、暗号方式を建物のコンクリートに直接埋め込むのではなく、交換できる部品として設計しておくイメージです。

耐量子暗号への移行は、単に「新しい暗号を導入する作業」ではありません。
暗号技術を、将来の変化に合わせて更新できるようにする作業でもあります。

9.3 暗号技術は「一度決めたら終わり」ではない

派生元の記事では、情報セキュリティを支える暗号技術の全体像として、共通鍵暗号、公開鍵暗号、ハッシュ関数、MAC、デジタル署名、証明書、鍵共有などを整理しました。

今回の記事では、その中でも特に、将来の量子コンピュータによって影響を受けやすい公開鍵暗号と、その移行先として注目される耐量子暗号に焦点を当てました。

ここであらためて強調したいのは、暗号技術は「一度安全な方式を選んだら終わり」ではないということです。

昔は安全だと考えられていた方式でも、計算機性能の向上、攻撃手法の進歩、実装上の問題、標準の変更によって、少しずつ見直しが必要になります。
耐量子暗号は、その中でも特に大きな変化の1つです。

💡 豆知識
暗号技術では、「新しい方式を導入する力」だけでなく、「古くなった方式を安全にやめる力」も大切です。
これは、古い鍵をいつまで使うのか、古い証明書をどう更新するのか、古い機器をどう扱うのか、といった運用の話にもつながります。

この視点は、PQCに限らず、情報セキュリティ全体で重要です。
セキュリティ対策は、導入した瞬間に完成するものではなく、脅威や技術の変化に合わせて継続的に見直していくものだからです。

9.4 この記事のまとめ

最後に、この記事全体のポイントを整理します。

ポイント	内容
身近なサービスとの関係	HTTPS、スマホ決済、アプリ署名などの裏側で公開鍵暗号や署名が使われている
量子コンピュータの影響	特にRSAや楕円曲線暗号などの公開鍵暗号がShorのアルゴリズムの影響を受ける
すべてが同じように危険ではない	AESやSHA系はGroverの影響を考える必要があるが、公開鍵暗号とは影響の性質が異なる
PQCの役割	将来の量子コンピュータによる攻撃にも備えるための、通常のコンピュータ上で動く暗号方式
標準化の現状	NISTはML-KEM、ML-DSA、SLH-DSAをFIPS標準として公開している
今から準備する理由	Harvest Now, Decrypt Laterや移行作業の長さを考えると、早めの棚卸しと計画が必要
実務上の考え方	暗号資産の棚卸し、暗号アジリティ、ハイブリッド方式、互換性検証が重要

耐量子暗号は、難しい数式や専門用語が多く、最初はとっつきにくく感じる分野です。
しかし、見方を変えると、テーマはとても身近です。

それは、私たちが毎日使っている通信やサービスを、将来も安全に使い続けるための準備です。

この記事が、耐量子暗号を「なんとなく難しそうな言葉」から、「今の暗号技術の延長線上にある、将来に備えるための技術」として捉えるきっかけになれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

耐量子暗号とは何か：なぜ今移行準備が必要なのか

概要

この記事で分かること

対象読者

本記事で扱わないこと

コード・図表を見る場合の前提

全体の流れ

1. まず、今の暗号はどこで使われているのか

1.1 ブラウザの https:// の裏側

1.2 証明書は「Webサイトの身分証明書」のようなもの

1.3 鍵共有は「その場限りの秘密の合言葉」を作る仕組み

1.4 アプリのアップデートにも署名が使われている

1.5 スマホ決済やネットショッピングでは、複数の暗号技術が重なっている

1.6 耐量子暗号と特につながるのは「公開鍵暗号」

1.7 この章のまとめ

2. 量子コンピュータは暗号に何を起こすのか

2.1 量子コンピュータは「何でも速いコンピュータ」ではない

2.2 暗号で問題になるのはCRQC

2.3 Shorのアルゴリズム：公開鍵暗号に大きな影響を与える

2.4 Groverのアルゴリズム：共通鍵暗号やハッシュ関数への影響

2.5 影響を整理すると、公開鍵暗号が特に大きい

2.6 この章のまとめ

3. 「量子コンピュータですべての暗号が危ない」は半分正しい

3.1 まずは全体像を見る

3.2 RSA：大きな数を分解しにくいことに支えられている

3.3 Diffie-Hellman / ECDH：安全な通信を始めるための鍵共有

3.4 ECDSAなどのデジタル署名：本物かどうかを確認する仕組み

3.5 AES：共通鍵暗号は「同じように壊れる」わけではない

3.6 SHA-2 / SHA-3：ハッシュ関数も影響の受け方が違う

3.7 「置き換えるもの」と「強度を見直すもの」を分けて考える

3.8 この章のまとめ

4. 本当に意識したいのは Harvest Now, Decrypt Later

4.1 「完成してから考える」では間に合わない

4.2 Harvest Now, Decrypt Later：今盗んで、後で読む

4.3 長く守る情報ほど、早めの対策が必要になる

4.4 移行準備は「暗号資産の棚卸し」から始まる

4.5 棚卸し結果を使って、優先順位を決める

4.6 海外では政府レベルでも移行計画が進んでいる

4.7 「今すぐ全部置き換える」ではなく「今から見える化する」

4.8 この章のまとめ

5. 耐量子暗号は何を置き換えるのか

5.1 耐量子暗号は「量子コンピュータを使う暗号」ではない

5.2 PQCが置き換えようとしているもの

5.3 PQCの大きな役割は「KEM」と「デジタル署名」

KEMは「秘密の合言葉を小包で送る」イメージ

デジタル署名は「本物確認の印鑑」のようなもの

5.4 PQCにはいくつかの「数学の土台」がある

5.5 PQCは「新しいから絶対安全」ではない

5.6 この章のまとめ

6. NIST標準化で何が決まったのか

6.1 まず押さえたい3つの標準

6.2 ML-KEM：通信のための共有秘密を作る方式

6.3 ML-DSA：デジタル署名の中心的な標準

6.4 SLH-DSA：ハッシュベースの署名方式

6.5 旧名称と標準名の対応

6.6 役割で見ると、標準化の意味が分かりやすい

6.7 標準化は「これで終わり」ではない

6.8 日本国内ではCRYPTREC暗号リストも重要

6.9 この章のまとめ

7. 移行準備には暗号アジリティが必要

7.1 暗号は「家電」よりも「配管」に近い

7.2 暗号アジリティがないと何が困るのか

7.3 暗号アジリティは「何でも自由に選べること」ではない

7.4 「設定で切り替えられる設計」にしておく

7.5 暗号アジリティを高めるための観点

7.6 ベンダやクラウドに確認すべきこと

7.7 暗号アジリティは「移行の保険」になる

7.8 個人開発・学習でも意識できること

7.9 この章のまとめ

8. 耐量子暗号だけで安全になるわけではない

8.1 ハイブリッド方式は「二重ロック」のように考えると分かりやすい

8.2 なぜ最初からPQCだけにしないのか

8.3 TLSでは「X25519 + ML-KEM」のような組み合わせが検討されている

8.4 ハイブリッド方式のゴールは1つではない

8.5 鍵共有のハイブリッドと署名のハイブリッドは分けて考える

8.6 2つを混ぜるときは「混ぜ方」が大事

8.7 ハイブリッド方式の注意点

8.8 SSHでもハイブリッド鍵共有の検討が進んでいる

8.9 段階的な移行のイメージ

8.10 ハイブリッド方式のまとめ

1.1 ブラウザの `https://` の裏側