「量子コンピュータが実用化されたら、今の暗号は全部破られる」——この言い方は、半分正しくて半分間違っています。正しいのは、RSAや楕円曲線暗号といった公開鍵暗号が原理的に危険にさらされるという点。間違っているのは「全部」という部分です。そして、この区別を曖昧にしたまま移行計画を立てると、優先順位を完全に取り違えます。
2024年8月にNISTが最初の3つの耐量子計算機暗号（PQC）標準を確定してから2年が経ちました。この2年で状況は大きく動いています。米国は2026年6月の大統領令で連邦システムの移行期限を2030年／2031年へ前倒しし、日本政府も2025年11月に「原則2035年まで」という方針を打ち出しました。CRYPTRECは2026年3月、電子政府推奨暗号リストに初めてPQCの表を新設しています。もはや「様子見」のフェーズではありません。
結論を先に書きます。いま着手すべきは、暗号インベントリの作成と、TLSの鍵交換のハイブリッド化です。署名と公開PKIは技術的にも制度的にもまだ動いている最中で、こちらを先に急ぐと手戻りします。以下、なぜそうなるのかを標準の現在地から順に見ていきます。
1. 量子コンピュータは何を壊し、何を壊さないのか
最初に誤解を潰しておきます。量子アルゴリズムが暗号に与える影響は、対象によって質が全く違います。
Shorのアルゴリズムは、素因数分解と離散対数を多項式時間で解きます。これはRSA、楕円曲線暗号、Diffie-Hellmanという、現在の公開鍵暗号のほぼ全てを直撃します。鍵長を伸ばして逃げることができない種類の破壊です。
一方Groverのアルゴリズムは、総当たり探索を平方根分だけ高速化するにとどまります。AESやハッシュ関数に対しては「鍵長や出力長を十分に取れば当面問題ない」という結論になります。CRYPTRECが2026年3月に新設したPQCリストにAES-192/256とSHA-384/512、SHA3-384/512が載っているのは、まさにこの理屈です。既存の共通鍵暗号・ハッシュ関数がそのままPQCリストに入っている。つまり「全部作り直し」ではありません。
もう一つ整理しておきたいのがPQCと量子暗号（QKD）の違いです。この二つは頻繁に混同されますが、別物です。
- PQC（耐量子計算機暗号）：計算量的安全性に基づく。古典コンピュータ上で動く普通のアルゴリズムで、既存のTLSやPKIにソフトウェア更新で組み込める。NISTが標準化しているのはこちら。
- QKD（量子鍵配送）：情報理論的安全性に基づく。専用の光ファイバや装置が必要で、距離と鍵生成レートに制約がある。汎用インターネットの代替にはならない。
日本政府の中間とりまとめも、PQCへの完全移行ではなく既存暗号との併用やQKDの導入を「視野に入れることも考えられる」という書き方をしており、両者は補完関係として扱われています。
では、量子コンピュータの実現時期はどうか。ここは正直に書きます。予測できません。内閣官房の中間とりまとめも「量子計算機により公開鍵暗号の安全性が低下・危殆化する時期を現時点で予測することは困難である」と明記しています。それでも移行を急ぐ理由がHNDL（Harvest Now, Decrypt Later）です。今の通信を記録して保管しておき、将来の量子コンピュータで復号する。保護期間が10年を超えるデータは、量子コンピュータが登場する前から既にリスクにさらされている、という理屈です。実現時期の不確実性は、移行を遅らせる理由にはなりません。
2. NIST標準の現在地——「出揃った」のは第1陣だけ
「NISTのPQC標準はもう確定した」という言い方をよく見ますが、正確には確定したのは3本で、残り2本はまだ途中です。ここを混同すると、まだ最終仕様が固まっていないアルゴリズムを本番実装してしまう事故につながります。
| 標準 | 名称（旧名） | 用途 | 数学的基盤 | 2026年9月時点の状況 |
|---|---|---|---|---|
| FIPS 203 | ML-KEM（CRYSTALS-Kyber） | 鍵カプセル化 | 格子（Module-LWE） | 2024年8月13日確定。実装・展開が最も進んでいる |
| FIPS 204 | ML-DSA（CRYSTALS-Dilithium） | デジタル署名 | 格子（Module-LWE/SIS） | 2024年8月13日確定。汎用署名の第一候補 |
| FIPS 205 | SLH-DSA（SPHINCS+） | デジタル署名 | ハッシュ関数のみ | 2024年8月13日確定。格子が破られた場合の保険 |
| FIPS 206 | FN-DSA（FALCON） | デジタル署名 | NTRU格子 | 2025年8月28日にNISTがドラフト標準を承認手続きに提出。最終版は未公開。業界の見通しは2026年末〜2027年初だが、NISTの手続き次第 |
| （未採番） | HQC | 鍵カプセル化 | 符号ベース | 2025年3月11日に第2のKEMとして選定。ドラフトは2026年頃、最終化は2027年頃の予定 |
FN-DSAがなぜ遅れているのかには技術的な理由があります。FALCONの署名生成は浮動小数点演算を使ったガウスサンプリングに依存しており、これを定数時間で安全に実装するのが難しい。サイドチャネル攻撃の温床になりかねないため、NISTは慎重に仕様を詰めています。NISTのpqc-forumでは、ドラフトがNISTと商務省の承認プロセスに入ったまま公開日が読めない状態が続いていると説明されていました。DigiCertのように「ML-DSA／SLH-DSAのドラフト版と最終版で名称やOIDの混乱が起きた経験から、FN-DSAは最終化まで本番環境に実装しない」と公言しているベンダーもあります。妥当な判断だと思います。
HQCの位置づけも誤解されがちです。これはML-KEMの置き換えではなく、数学的基盤の分散が目的です。ML-KEM・ML-DSA・FN-DSAはいずれも格子ベースで、格子問題に大きな突破口が見つかると同時に危うくなる。そこで全く異なる符号ベースの方式をバックアップとして用意しておく、という設計思想です。
この「基盤を分散させる」発想が単なる杞憂でないことは、2022年のSIKE崩壊が示しています。NISTの第4ラウンド候補だった同種写像ベースのSIKEは、古典コンピュータで多項式時間に解かれました。新しい数学的仮定への信頼は、ある日突然崩れることがある。だからこそ、特定アルゴリズムを固定実装せず差し替え可能にしておく「クリプト・アジリティ」が本質的に重要なのです。
3. サイズという現実的な制約
PQC移行で実装者が最初にぶつかるのはサイズです。以下は各方式の生のバイト数（raw値）で、X.509のDER符号化や証明書に格納した場合の実サイズとは異なる点に注意してください。
| 方式 | 公開鍵 | 暗号文／署名 | 備考 |
|---|---|---|---|
| X25519 | 32 B | 32 B | 比較の基準となる従来方式 |
| ECDSA P-256 | 65 B（非圧縮）／33 B（圧縮） | 署名 約64〜72 B | 署名長はDER符号化で変動。Ed25519の公開鍵は32 B |
| RSA-3072 | 法 n が384 B | 署名 384 B | SubjectPublicKeyInfo全体はこれより大きい |
| ML-KEM-768 | 1,184 B | 暗号文 1,088 B | 実運用の事実上の標準パラメータ |
| ML-KEM-1024 | 1,568 B | 暗号文 1,568 B | NSA CNSA 2.0が指定するパラメータ |
| ML-DSA-44 | 1,312 B | 署名 2,420 B | ECDSA署名の約35倍。証明書チェーンへの影響が大きい |
| ML-DSA-87 | 2,592 B | 署名 4,627 B | CNSA 2.0指定 |
| FN-DSA（Falcon-512） | 897 B | 署名 約0.7 KB（可変長） | PQC署名で最小級。圧縮署名は可変長で、正確な最大長はFIPS 206最終仕様による |
| SLH-DSA | 32〜64 B | 署名 約7.9 KB〜約49 KB | パラメータにより幅が大きい。公開鍵は極小だが署名が巨大 |
なお、ML-KEMは「重いから遅い」わけではありません。鍵生成・カプセル化・復号はいずれもマイクロ秒級で、演算そのものはむしろ高速です。問題になるのは計算量ではなくネットワークに乗るバイト数です。TLSのClientHelloが1パケットに収まらなくなる、ロードバランサやWAFが大きなハンドシェイクを想定していない、といったところで詰まります。
4. 主戦場はTLSの鍵交換——ここは既に勝負がついている
PQC移行の中で、鍵交換だけは別格に進んでいます。理由は単純で、HNDL対策として最も効果が高く、しかも証明書やPKIといった制度的な手続きを経由せずにクライアントとサーバの実装更新だけで完結するからです。
事実上の標準になったのがX25519MLKEM768です。従来のX25519とML-KEM-768を連結したハイブリッド方式で、両方の共有秘密をKDFに通して鍵を導出します。2026年8月にRFC 10024（Proposed Standard、全9ページ）として標準化されました。同RFCはX25519MLKEM768のほか、SecP256r1MLKEM768とSecP384r1MLKEM1024を定義しています。後者2つはNIST曲線を要求するコンプライアンス環境向けで、IETFとしての推奨（Recommended Y）が付いているのはX25519MLKEM768のみです。
ハイブリッドの安全性については、雑に「両方破らないと解読できない」と書かれることが多いのですが、もう少し正確には「適切なcombinerとダウングレード防止機構を備えた設計であれば、構成方式の少なくとも一方が安全である限り機密性が保たれることを目指す」というものです。設計次第では成り立たないので、自前で組み合わせを作るのは避けるべきです。
RFC 10024のClientHello側の鍵共有サイズはX25519MLKEM768で1,216バイト（ML-KEM部1,184＋X25519部32）、サーバ側が1,120バイトです。X25519単体の32バイトと比べれば劇的に大きいものの、実運用に耐える範囲に収まっています。
普及の速度は、正直なところ予想を超えています。Cloudflareの公開データによると、同社を経由する人間由来のHTTPSトラフィックのうちPQC鍵交換で保護された割合は、2025年初頭の29%から2025年12月初頭に52%へ倍増し、2026年4月時点で約67%に達しています。Chrome 131とFirefox 132が既定でX25519MLKEM768を提示するようになったことが効いています。
ただし、これは「クライアントからCDNまで」の話です。CloudflareがスキャンしたオリジンサーバのPQC対応率は約9〜10%にとどまります（2025年初頭は1%未満だったので10倍以上の伸びではあります）。エッジまではPQCで守られていても、そこから先の自社サーバまでの区間は従来暗号のまま、という構図が当たり前に存在している。自社のサーバ側TLS設定を確認するのが、実は一番手近な宿題です。
5. 署名と公開PKIが本当の難所
鍵交換が順調な一方、署名側は明確に遅れています。2026年9月時点で、ブラウザの信頼ストアに入った公開PKIのML-DSA証明書はまだ存在しません。
CA/Browser ForumのServer Certificate Working Groupでは、公開信頼TLSサーバ証明書でML-DSAを許可するballotが2026年5月時点でまだ議論中でした。証明書透明性（CT）ログへの影響や、そもそも従来型X.509証明書をPQC移行の器とすべきかという根本論点で意見が割れています。Microsoftは自社のML-DSA X.509証明書パイロットを進める意向を示しつつ、こうした証明書をCTログから除外することを提案していました。
一方で、動いている領域もあります。S/MIMEについては、Ballot SMC013により2025年8月22日にS/MIME Baseline Requirements v1.0.11が採択され、ML-DSAとML-KEMを使うPQC証明書が既に許容されています（ハイブリッドではない単一鍵方式）。また、プライベートPKI向けのML-DSAトラストアンカー対応はChrome 150で提供される予定とされています。
この状況から導かれる実務的な結論ははっきりしています。
- 内部PKI・社内mTLSは今すぐML-DSAを試せる。ブラウザの信頼ストアに依存しないため、制度待ちにならない。
- コード署名・ファームウェア署名は優先度が高い。2026年に署名したバイナリが10年以上動き続ける世界では、検証側の入れ替えに時間がかかることを見越して早く着手する必要がある。
- 公開WebのTLSリーフ証明書は、CA/Browser Forumのベースライン改定とブラウザのルートプログラム対応を待つしかない。ここを前倒ししようとしても空回りする。
なお署名PQCの実装例としては、Cloudflareが1.1.1.1のDNSSEC検証にML-DSA-44を導入しています。2,420バイトの署名をDNSでどう扱うかという、まさにサイズ問題と正面から向き合った事例です。
6. 各国ロードマップ——「2035年」は同じ言葉で中身が違う
主要国の期限は「2030年代前半に高優先度システム、2035年前後に全体移行」という点で似た形をしていますが、対象範囲も拘束力も、そもそも「非推奨」と「禁止」の定義も国ごとに違います。横並びの表で見ると同じに見えてしまうので、性格の違いを併記します。
| 主体 | 文書 | 主なマイルストーン | 性格 |
|---|---|---|---|
| NIST（米） | IR 8547（2024年11月、初期公開ドラフト） | 112ビット安全性（RSA-2048、P-256など）は2030年以降「非推奨」、2035年以降「使用不可」。128ビット以上も2035年以降は使用不可 | ドラフト。それ自体に法的拘束力はないが、後続の大統領令・OMB通達が参照 |
| 米大統領令 | EO 14412（2026年6月22日署名） | HVA（高価値資産）・高影響システムについて、鍵確立を2030年12月31日、署名を2031年12月31日までにPQC化。連邦調達業者も2030年末までにPQC FIPS準拠。NISTは自組織のパイロットを2027年12月31日までに完了 | 連邦民生機関への指令。国家安全保障システム（NSS）は対象外 |
| 米OMB | M-26-15（2026年6月24日） | 各機関はPQC移行責任者を2026年7月下旬までに指名し、移行計画を2026年10月22日までに提出。以降、棚卸し・計画（〜2027年）、試行（〜2028年）、鍵確立（〜2030年）、署名（2031年）、残存システム（〜2035年）の段階。TLS 1.3以降の対応を2030年1月2日までに要求 | EO 14412の実装通達。M-23-02を実質的に置き換え |
| NSA（米） | CNSA 2.0 | ML-KEM-1024／ML-DSA-87／AES-256／SHA-384・512を指定。ソフトウェア署名やネットワーク機器から段階的に排他利用へ移し、2035年にNSS全体の移行完了 | NSSを対象とするNSAの指針。カテゴリ別に期限が異なる |
| EU | 協調ロードマップ（2025年6月、NIS協力グループ） | 2026年に準備開始、2030年に高リスク用途、2035年に可能な限り全体移行 | リスクベースの勧告。加盟国ごとに実装が分かれる |
| 英NCSC | PQC移行タイムライン（2025年3月） | 2028年までに棚卸しと計画、2031年までに高優先度システム、2035年までに全体移行 | ガイダンス。ML-KEM-768、ML-DSA-65を基本線とする |
| 日本 | 中間とりまとめ（2025年11月20日、内閣官房国家サイバー統括室） | 政府機関等について原則2035年までの移行を目指す。2026年度に工程表を策定 | 方針表明。現時点で禁止規定や中間期限の設定はない |
この表で注目すべきは、米国だけが明確に前倒ししている点です。EO 14412以前の米国の姿勢は「2035年までにできる限り量子リスクを緩和する」という目標ベースでしたが、2026年6月の一連の文書で高価値資産については2030年／2031年という期限に置き換わりました。連邦調達業者にも2030年末の要件がかかるため、米国政府に納入するサプライチェーンには実質的な強制力が及びます。
また、EO 14412はNIST・CISAに対し、2027年3月までに連邦CBOM（Cryptography Bill of Materials、暗号部品表）の最小要素を定めるよう指示しています。SBOMの暗号版です。今後、政府向けベンダーには「自社製品がどの暗号アルゴリズムをどこで使っているか」を標準形式で提出することが求められるようになる可能性が高い。日本企業にとっても他人事ではありません。
7. 日本の現在地——リストは動いた、期限はこれから
日本の動きで最も実務に効くのは、2026年3月30日のCRYPTREC暗号リスト改定です。「電子政府における調達のために参照すべき暗号のリスト」（CRYPTREC LS-0001-2022R2）の電子政府推奨暗号リストに「表2 耐量子計算機暗号（PQC）リスト」が新設されました。内容は以下の通りです。
| 技術分類 | 名称 | パラメータセット |
|---|---|---|
| 公開鍵暗号 － 署名 | － | 該当なし |
| 公開鍵暗号 － 鍵共有 | ML-KEM | ML-KEM-768（Category 3）、ML-KEM-1024（Category 5） |
| 共通鍵暗号 | AES | AES-192（Category 3）、AES-256（Category 5） |
| ハッシュ関数 | SHA2 / SHA3 | SHA-384（Category 4）、SHA-512、SHA3-384（Category 4）、SHA3-512 |
読み取るべきポイントが3つあります。
第一に、掲載されたのはML-KEM-768と1024だけで、ML-KEM-512は入っていません。「新規案件ではML-KEMを既定に」と言うときは、日本政府向けならパラメータを768以上にする必要があります。
第二に、署名は「該当なし」です。ML-DSAもSLH-DSAも、NISTでは2024年に確定済みですが、CRYPTRECの推奨リストにはまだ載っていません。表の枠だけ用意して空欄にしてある、という状態です。CRYPTRECは2025年度報告書で、PQCリストへの追加を引き続き検討中としており、PQCに関するワーキンググループでガイドラインと研究動向調査報告書の2026年度版を作成する方針を示しています。
第三に、暗号強度要件の設定基準は当面この表2の公開鍵暗号には適用されません。従来の鍵長ベースの基準がPQCには噛み合わないためで、2026年度に設定基準そのものの改定を進めるとされています。
政府方針としては、内閣官房国家サイバー統括室（NCO）が2025年11月20日に「政府機関等における耐量子計算機暗号（PQC）への移行について（中間とりまとめ）」を公表しました。原則2035年までの移行を目指し、2026年度に工程表を策定するという内容です。同文書は移行の準備・開発コストと所要期間が膨大になりうることに触れ、クリプト・インベントリの構築（移行対象の詳細な把握）を検討の前提に置いています。加えて、PQC実装時のセキュリティ対策が現状では不十分であることを理由に、クリプト・アジリティの確保や既存暗号との併用、QKDの導入も選択肢として挙げています。
金融分野は比較的先行しています。金融庁は2024年7〜10月に「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会」を開催し、2024年11月26日に報告書を公表しました。3メガバンク、全銀協、地銀協、日銀金融研究所などが参加し、優先度の高いシステムを2030年代半ばまでにPQC利用可能な状態にすること、暗号利用箇所の棚卸しに早期着手することなどを求めています。
総じて日本の立ち位置を評価するなら、「方針とリストの整備は着実、期限の具体性と強制力は米国に比べて弱い」というところでしょう。中間とりまとめ自身が、諸外国に比べて移行が遅れれば安全保障上の支障が懸念されるという認識を示しています。2026年度の工程表がどこまで踏み込むかが次の焦点です。
8. ベンダー・製品の対応状況
| 製品・サービス | 鍵交換 | 署名・証明書 | 備考 |
|---|---|---|---|
| OpenSSL 3.5（2025年4月、LTS） | ML-KEMをネイティブ実装。既定でX25519MLKEM768を優先提示 | ML-DSA、SLH-DSAをネイティブ実装 | 最も影響範囲が広い。ただし本体での利用可能性とFIPS ProviderのCMVP検証状況は別問題 |
| Chrome / Firefox | Chrome 131（2024年11月）、Firefox 132（2024年10月）で既定化 | プライベートPKI向けML-DSAトラストアンカー対応がChrome 150で提供予定 | クライアント側の既定化が普及率を押し上げた主因 |
| AWS | KMS等へのハイブリッドPQ TLS対応 | AWS Private CAがML-DSA証明書に対応（2025年11月） | サービス側の対応と、利用者の通信が実際にPQC化されているかは別。SDK側で明示的に有効化が必要な構成がある |
| Microsoft | SymCryptにML-KEM。Windows／Linuxへ展開 | CNG／ADCSでML-DSA。ML-DSA X.509のパイロットを推進 | CA/Browser ForumのML-DSA ballotを支持する立場 |
| Cloudflare | エッジ・オリジン間でX25519MLKEM768を展開 | 1.1.1.1のDNSSEC検証にML-DSA-44を導入 | Radarで採用率を公開。オリジン対応率の可視化も提供 |
| Signal | PQXDH（2023年）に加え、SPQRを組み込んだTriple Ratchet（2025年10月2日） | － | ML-KEMを採用。初期鍵確立だけでなく会話中のラチェットまでPQC化した点が新しい |
| Apple | iMessage PQ3（2024年）。iOS 26／macOS TahoeでX25519MLKEM768に対応 | － | PQ3の「レベル3」はApple独自の分類であり、NISTやIETFの共通評価基準ではない |
この表を見て「主要ベンダーは対応済み」と結論づけるのは早すぎます。対応範囲、既定で有効かオプトインか、FIPS検証の有無、署名・証明書まで含むかは製品ごとにバラバラです。「PQC対応」という一言が何を指しているのかは、製品ドキュメントで個別に確認する必要があります。特にHSM、PKI製品、組込み機器は、ソフトウェアライブラリより一段遅れると考えておくのが安全です。
9. 何から手をつけるか
実務の順序としては、以下が妥当だと考えます。
- 暗号インベントリ／CBOMの整備。RSA・ECC・DHをどこで使っているかの棚卸し。TLS、VPN、コード署名、内部認証、証明書、HSM、アプリケーションコード。これがないと移行計画は立てられません。米国のCBOM標準化（2027年3月まで）も見据えて、機械可読な形式を意識しておくと後で効きます。
- 長期機密データの特定とHNDLリスク評価。保護期間が長いデータほど優先度が上がります。10年後に漏れても困らないデータと、30年後でも困るデータを分ける作業です。
- TLS・VPN等の鍵確立をハイブリッド化。標準・製品・認証要件が整っている環境では、X25519MLKEM768を優先候補に。日本政府向け調達を意識するならML-KEM-768以上。
- 経路上の機器の検証。MTU、ClientHelloのフラグメント、ロードバランサ、WAF、プロキシ、HSM。ここで詰まるケースが実際に報告されています。
- 内部PKI・コード署名でML-DSAを評価。公開Web PKIを待たずに始められる領域です。
- 公開Web PKIは制度の動きを待つ。CA/Browser Forumだけでなく、ブラウザのルートプログラム、TLS実装、証明書サイズ、失効基盤まで揃って初めて実用になります。
- クリプト・アジリティの確保。ML-KEMやML-DSAを固定実装せず、将来HQCやFN-DSAへ差し替えられる設計にしておく。OpenSSLのEVPのような抽象化層を経由させ、アルゴリズム選択を設定で変えられるようにするのが基本です。
判断を切り替える目安として、以下のイベントをウォッチしておくとよいと思います。
- CA/Browser ForumがTLSサーバ証明書でML-DSAを許可 → 公開証明書の移行計画を起動
- FIPS 206（FN-DSA）の最終化 → 帯域制約のある用途で署名方式を再評価
- CRYPTRECが署名アルゴリズムをPQCリストに追加 → 日本政府向け調達要件の更新
- 2026年度の政府工程表の公表 → 自組織の期限設定の根拠として参照
まとめ
耐量子暗号の移行は、「量子コンピュータが完成してから対応する」という選択肢が構造的に存在しない、珍しい種類の課題です。HNDLがある以上、脅威の実現時期を待つことは、その分だけ既に失われたデータを増やすことを意味します。
その上で、現実的な優先順位ははっきりしています。鍵交換は既に実用段階に入っており、標準（RFC 10024）も実装（OpenSSL 3.5、主要ブラウザ）も揃っています。Cloudflareの計測で人間由来トラフィックの3分の2がPQCで保護されている一方、オリジンサーバ側の対応が1割程度にとどまっているという非対称は、そのまま「自社サーバの設定を見直せ」というメッセージとして読めます。
対照的に、署名と公開PKIはまだ制度が動いている最中です。FIPS 206は未確定、CRYPTRECの署名欄は空欄、公開信頼のML-DSA証明書はゼロ。ここを焦っても手戻りするだけで、いま投資すべきは個別アルゴリズムの実装ではなく、何が使われているかを把握する仕組みと、後から差し替えられる設計です。
SIKEが2022年に崩壊したことを思い出せば、今日「安全」とされているアルゴリズムが10年後も安全である保証はどこにもありません。PQC移行の本質は、特定のアルゴリズムへの乗り換えではなく、アルゴリズムを乗り換えられる組織になることなのだと思います。
0 件のコメント:
コメントを投稿