PQCとは？耐量子暗号を初心者にもわかりやすく解説

量子コンピュータ時代に備える、次世代セキュリティの基礎

インターネットで買い物をする。
銀行アプリにログインする。
会社のVPNに接続する。
電子契約に署名する。
クラウドに保存したファイルを安全にやり取りする。

私たちは毎日、意識しないところで「暗号」に守られています。

しかし、将来十分に強力な量子コンピュータが登場すると、現在広く使われているRSAや楕円曲線暗号、つまりECCのような公開鍵暗号が危険になる可能性があります。

そこで注目されているのが PQC です。

PQCとは Post-Quantum Cryptography の略で、日本語では 耐量子暗号 や ポスト量子暗号 と呼ばれます。
量子コンピュータが実用化された未来でも、情報を安全に守るための新しい暗号技術です。

この記事では、PQCとは何か、なぜ今必要なのか、NIST標準とは何か、企業やWebサービス運営者が何から準備すべきかを、初心者にもわかるように整理します。

PQCとは何か

PQCとは、量子コンピュータによる攻撃にも耐えられるように設計された暗号技術です。

ここで重要なのは、PQCは「量子コンピュータを使う暗号」ではないという点です。
PQCは、今のサーバ、PC、スマートフォン、クラウド、Webアプリでも動かせるソフトウェアベースの暗号です。

似た言葉に「量子暗号」や「QKD」があります。
QKDは量子力学の性質を使って鍵配送を行う技術で、専用装置や専用回線が必要になることがあります。

一方、PQCは既存のインターネットやWebシステムに組み込むことを前提にした暗号です。

簡単にいうと、違いはこうです。

PQCは、今あるインターネットの仕組みをすべて捨てるものではありません。
むしろ、現在のWeb、TLS、VPN、証明書、電子署名、ソフトウェア更新、クラウド基盤を、段階的に量子時代へ対応させるための現実的な選択肢です。

なぜPQCが必要なのか

現在のインターネットでは、公開鍵暗号が非常に重要な役割を持っています。

たとえば、WebサイトのHTTPS通信では、ブラウザとサーバが安全に共通鍵を共有するために公開鍵暗号を使います。
電子署名では、本人が署名したことや、データが改ざんされていないことを確認するために公開鍵暗号を使います。

問題は、RSAやECCの安全性が「今のコンピュータでは解くのが非常に難しい数学問題」に依存していることです。

ところが、十分に大規模な量子コンピュータが登場すると、これらの数学問題を効率よく解ける可能性があります。
つまり、今は安全とされている公開鍵暗号が、将来は安全ではなくなる可能性があります。

ここで多くの人が勘違いしやすいのは、「量子コンピュータが完成してから対策すればよい」という考え方です。

実は、それでは遅い場合があります。

Harvest Now, Decrypt Laterとは

PQCを考えるうえで必ず押さえたい言葉が Harvest Now, Decrypt Later です。
日本語では「今盗んで、後で復号する」と表現できます。

これは、攻撃者が今のうちに暗号化通信や暗号化データを大量に保存しておき、将来量子コンピュータが使えるようになったタイミングで復号しようとする考え方です。

たとえば、次のような情報は長期間守る必要があります。

• 医療情報
• 金融情報
• 国家・企業の機密情報
• 個人情報
• 研究開発データ
• 契約書
• 顧客データ
• 長期保存されるログ
• バックアップデータ

これらは、今日盗まれても、明日すぐに悪用されるとは限りません。
しかし、10年後、20年後にも価値がある情報なら、将来復号されるリスクがあります。

つまりPQCは、「未来の問題」ではなく、「長期間守るべきデータにとっては今の問題」です。

PQCで守るもの

PQCが特に関係するのは、公開鍵暗号が使われている領域です。

代表例は次の通りです。

特に注意したいのは、TLSだけ対応すれば終わりではないことです。

WebサイトのHTTPSは目立つため注目されやすいですが、実際には社内システム、API、VPN、SSH、証明書、コード署名、CI/CD、バックアップ、組み込み機器など、多くの場所で暗号が使われています。

PQC移行は、単なる「暗号ライブラリの差し替え」ではありません。
システム全体に埋め込まれた暗号の棚卸しと移行計画が必要です。

NISTのPQC標準とは

PQCで最も重要な動きが、NISTによる標準化です。
NISTは米国国立標準技術研究所で、暗号技術やセキュリティ標準に大きな影響力を持つ機関です。

NISTは長い評価プロセスを経て、2024年に最初のPQC標準を公開しました。

代表的な標準は次の3つです。

ML-KEMとは

ML-KEMは、鍵交換のためのPQCアルゴリズムです。
以前はKyberと呼ばれていた方式をもとにしています。

Web通信では、ブラウザとサーバが安全に共通鍵を作る必要があります。
そのために使われるのが鍵交換です。

現在はECDHなどがよく使われていますが、将来的にはML-KEMのような耐量子方式が重要になります。

ML-DSAとは

ML-DSAは、デジタル署名のためのPQCアルゴリズムです。
以前はDilithiumと呼ばれていた方式をもとにしています。

デジタル署名は、次のような場面で使われます。

• 電子契約
• 証明書
• ソフトウェア更新
• コード署名
• API署名
• 改ざん検知

PQCでは、通信の暗号化だけでなく、署名の移行も重要です。

SLH-DSAとは

SLH-DSAは、ハッシュベースのデジタル署名方式です。
以前はSPHINCS+と呼ばれていた方式をもとにしています。

ML-DSAとは異なる数学的な考え方に基づいており、バックアップ的な選択肢として重要です。

暗号の世界では、1つの方式だけに依存しすぎるのは危険です。
将来、特定の方式に弱点が見つかる可能性を考えると、異なる仕組みを持つ選択肢を用意することが重要です。

HQCとFALCONも知っておきたい

NISTは、最初の3標準だけで終わりではありません。

2025年には、ML-KEMのバックアップとなる鍵カプセル化方式として HQC を選定しました。
HQCはML-KEMとは異なる数学的背景を持つ方式で、将来ML-KEMに弱点が見つかった場合の備えになります。

また、FALCONはデジタル署名系の方式として標準化が進められています。
FALCONはNIST標準ではFN-DSAという名称になる流れがあります。

ここで重要なのは、PQC移行は「ML-KEMだけ入れれば完了」ではないということです。

鍵交換、署名、証明書、プロトコル、ライブラリ、運用、ログ、監査、ベンダー対応まで含めた長期的な移行が必要です。

PQCとハイブリッド方式

現在の現実的な移行方法として重要なのが ハイブリッド方式 です。

ハイブリッド方式とは、従来の暗号とPQCを組み合わせる方法です。

たとえばTLSでは、従来のX25519のような鍵交換と、ML-KEMを組み合わせる構成があります。

なぜ最初からPQCだけにしないのでしょうか。

理由は、移行期には次のような不確実性があるためです。

• PQC実装がまだ新しい
• 古い端末やブラウザが対応していない
• プロトコル側の標準化が進行中
• パフォーマンスや通信サイズの影響がある
• 運用監視や障害対応の知見がまだ少ない

そのため、従来方式とPQCを組み合わせることで、既存の安全性を保ちながら、量子時代への耐性も高める設計が使われます。

ざっくり言うと、ハイブリッド方式は「今の安全性を捨てずに、未来への備えを足す」移行方法です。

PQCは何を置き換えるのか

PQCが主に置き換えるのは、公開鍵暗号の部分です。

よくある誤解として、「PQCになったらAESも全部不要になるのか」というものがあります。
基本的には、PQC移行の中心はRSA、Diffie-Hellman、ECCなどの公開鍵暗号です。

AESのような共通鍵暗号や、SHA-2/SHA-3のようなハッシュ関数は、量子コンピュータの影響を受けないわけではありませんが、公開鍵暗号ほど直接的に崩れるわけではありません。

ただし、セキュリティポリシーによっては、より大きな鍵長を選ぶ、古い方式を廃止する、暗号設定を見直すといった対応が必要になります。

つまり、PQC移行では次のように考えるとわかりやすいです。

企業が今すぐやるべきこと

PQC対応で最初にやるべきことは、いきなり暗号を入れ替えることではありません。

まずは、どこで暗号を使っているかを把握することです。

これを 暗号資産の棚卸し と呼びます。

1. 暗号資産を棚卸しする

次のような情報を洗い出します。

• TLS証明書
• VPN設定
• SSH鍵
• API認証
• 電子署名
• コード署名
• S/MIME
• PGP
• DB暗号化
• バックアップ暗号化
• ライブラリ
• HSM / KMS
• ロードバランサ
• CDN
• WAF
• IoT機器
• 組み込み機器
• CI/CDの署名・鍵管理

棚卸しで重要なのは、「どの暗号方式を使っているか」だけではありません。

次の情報も必要です。

• どのシステムで使われているか
• どのデータを守っているか
• そのデータは何年守る必要があるか
• 誰が管理しているか
• ベンダー製品か自社実装か
• 交換できるか
• 移行時に止められるか
• 影響範囲はどこまでか

PQC移行の難しさは、暗号そのものよりも「どこで使われているかわからない」ことにあります。

2. 長期保護が必要なデータを優先する

すべてを一気に移行するのは現実的ではありません。
そのため、優先順位を決めます。

優先度が高いのは、長期間秘密にすべき情報です。

たとえば、

• 個人情報
• 医療情報
• 金融情報
• 契約書
• 研究開発データ
• 認証情報
• 顧客データ
• 法的保存が必要な文書
• バックアップ
• アーカイブ

これらは、Harvest Now, Decrypt Laterの影響を受けやすい領域です。

逆に、短期間で価値がなくなる一時データは、優先度が下がる場合があります。

PQC移行は、リスクベースで進めることが重要です。

3. ベンダーにPQC対応状況を確認する

多くの企業では、暗号処理の多くを自社で直接実装しているわけではありません。

実際には、次のような製品やサービスに依存しています。

• クラウド
• CDN
• WAF
• ロードバランサ
• VPN機器
• ファイアウォール
• HSM
• KMS
• DB
• メールサーバ
• IDaaS
• EDR
• SIEM
• CI/CD
• ライブラリ
• フレームワーク

そのため、ベンダーに次のような確認が必要です。

• PQC対応予定はあるか
• どのアルゴリズムに対応するか
• ハイブリッドTLSに対応するか
• 証明書はどう扱うか
• 鍵管理はどう変わるか
• 古い端末との互換性はあるか
• 監査ログは残せるか
• パフォーマンス影響はどれくらいか
• いつ本番利用できるか

PQC対応は、自社だけで完結しません。
サプライチェーン全体で進める必要があります。

4. Crypto-agilityを高める

PQC時代に非常に重要な考え方が Crypto-agility です。
日本語では「暗号アジリティ」と呼ばれます。

これは、暗号方式、鍵長、ライブラリ、証明書、プロトコルを、必要に応じて素早く入れ替えられる設計のことです。

今後、PQCアルゴリズムや推奨設定は変わる可能性があります。
もし暗号方式がコードのあちこちにベタ書きされていると、移行は非常に大変です。

たとえば、次のような設計は危険です。

アプリのあちこちに RSA-2048 前提の処理が直接書かれている
証明書更新手順が手作業しかない
古いTLS設定がどこにあるか不明
鍵管理が担当者の記憶に依存している
暗号ライブラリの更新テストがない

一方、Crypto-agilityがある設計はこうです。

暗号設定を設定ファイルやポリシーで管理できる
鍵管理をKMSやHSMに寄せている
証明書更新を自動化している
暗号ライブラリのバージョンを把握している
古い暗号方式を検知できる
テスト環境で新方式を試せる
ロールバック手順がある

PQC対応は、一度きりの作業ではありません。
今後も暗号の推奨は変わります。

だからこそ、特定のアルゴリズムだけを見るのではなく、暗号を入れ替えやすい仕組みを作ることが重要です。

5. CBOMで暗号を見える化する

最近は、SBOMだけでなく CBOM という考え方も重要になっています。

SBOMは、ソフトウェアに含まれるライブラリやコンポーネントの一覧です。
CBOMは、Cryptography Bill of Materialsの略で、ソフトウェアやシステムで使われている暗号要素を一覧化する考え方です。

CBOMで管理したい情報は次の通りです。

• 使用している暗号アルゴリズム
• 鍵長
• 証明書
• プロトコル
• 暗号ライブラリ
• 鍵の保存場所
• 有効期限
• 署名方式
• 量子脆弱性の有無
• 移行優先度

PQC移行では、「どこにRSAやECCが残っているか」を見つける必要があります。
そのため、CBOMは非常に有効な考え方です。

Webサービス運営者向けのPQC対策

Webサービスを運営している場合、最初に見るべきはTLSです。

具体的には、次の順番で確認するとよいです。

1. TLS 1.3対応状況を確認する

まず、古いTLS設定を見直します。
TLS 1.0やTLS 1.1は使わない。
TLS 1.2も必要最小限にする。
TLS 1.3を優先する。

PQC以前に、古い暗号設定が残っていると、通常の攻撃にも弱くなります。

2. CDNやWAFのPQC対応を確認する

Cloudflare、CDN、WAF、ロードバランサを使っている場合、PQC対応はそれらのサービス側で進むことがあります。

そのため、まずは利用中のプロキシ、CDN、WAF、LBが、ハイブリッドPQCに対応しているか確認します。

3. オリジンとの通信も確認する

ユーザーとCDNの間だけ強くしても、CDNとオリジンサーバの間が古いままでは不十分です。

確認すべき通信は次の通りです。

• ブラウザ → CDN
• CDN → オリジン
• オリジン → DB
• アプリ → 外部API
• 管理者 → SSH / VPN
• CI/CD → 本番環境
• バックアップ転送

PQC対応は、外側だけではなく内側の通信も対象になります。

Djangoや業務システムでのPQC設計

Djangoや業務システムにPQCを組み込む場合、アプリケーションだけで完結させようとしない方が安全です。

暗号処理は、可能な限り標準ライブラリ、KMS、HSM、TLS終端、プロキシ、信頼できる暗号ライブラリに寄せるべきです。

Django側でやるべきことは、次のような管理・監査・制御です。

• どの通信がTLSで保護されているか記録する
• 証明書の期限を監視する
• 古い暗号設定を検知する
• SSH鍵やAPI鍵の棚卸しをする
• 秘密情報をDBに平文保存しない
• バックアップを暗号化する
• 鍵のローテーション履歴を残す
• 管理画面アクセスを強化する
• 重要操作に署名や承認フローを入れる
• 暗号設定の変更履歴を監査ログに残す

PQCそのものを自作するのは危険です。
作るべきなのは、PQCを安全に使うための管理基盤です。

PQCの注意点

PQCにはメリットだけでなく注意点もあります。

1. サイズが大きくなる場合がある

PQCアルゴリズムは、従来のRSAやECCよりも鍵、署名、通信メッセージのサイズが大きくなる場合があります。

そのため、次のような影響が出る可能性があります。

• TLSハンドシェイクのサイズ増加
• 証明書サイズの増加
• 通信帯域の増加
• IoTや組み込み機器での負荷増加
• 古いネットワーク機器との相性問題

2. 実装が新しい

NIST標準が公開されたとはいえ、実装、運用、監視、障害対応の知見はこれから成熟していきます。

そのため、いきなり全システムへ一括導入するのではなく、テスト環境、限定環境、重要データの優先領域から段階的に進めるべきです。

3. 互換性の問題がある

古いブラウザ、古いOS、古いVPN機器、古いライブラリでは、PQCに対応できない場合があります。

移行では、互換性確認が必須です。

4. 暗号だけ変えても安全にはならない

PQCは強力な技術ですが、セキュリティ全体の一部です。

パスワードが弱い。
MFAがない。
秘密鍵が漏れている。
サーバが侵害されている。
ログが残っていない。
バックアップが盗まれている。

このような状態では、PQCを入れても根本的な安全性は上がりません。

PQCは、ゼロトラスト、鍵管理、MFA、EDR、WAF、ログ監査、バックアップ保護と組み合わせて考える必要があります。

PQC移行ロードマップ

PQC対応は、次の流れで進めると現実的です。

フェーズ1：現状把握

• TLS設定を確認する
• 証明書を棚卸しする
• SSH鍵を棚卸しする
• VPN設定を確認する
• 暗号ライブラリを調べる
• KMS / HSMの利用状況を確認する
• RSA / ECC / DHの利用箇所を洗い出す

フェーズ2：リスク評価

• 長期保護が必要なデータを特定する
• 外部公開サービスを優先する
• 重要システムを優先する
• ベンダー依存箇所を確認する
• 古い機器やEOL製品を特定する

フェーズ3：設計

• ハイブリッド方式を検討する
• 鍵管理方式を見直す
• 証明書更新手順を整理する
• 暗号設定をポリシー化する
• ロールバック手順を用意する
• 監査ログ設計を行う

フェーズ4：検証

• テスト環境でPQC対応を試す
• パフォーマンスを測る
• 通信サイズを測る
• 古い端末との互換性を見る
• 障害時の切り戻しを確認する

フェーズ5：段階導入

• 重要度の高い通信から導入する
• 外部公開サービスから始める
• 管理系通信を強化する
• バックアップ転送を強化する
• 証明書・署名領域を段階移行する

フェーズ6：継続運用

• 暗号資産を定期更新する
• 古い暗号方式を検知する
• ベンダー情報を追跡する
• 標準の更新に追従する
• 監査ログを確認する
• 移行状況をダッシュボード化する

よくある誤解

誤解1：量子コンピュータはまだ先だから関係ない

長期保存される機密情報は、今盗まれて将来復号される可能性があります。
そのため、守るべき期間が長い情報ほど、早めの対応が必要です。

誤解2：PQCを入れれば完全に安全になる

PQCは公開鍵暗号の量子リスクに備える技術です。
しかし、フィッシング、認証情報漏えい、サーバ侵害、設定ミス、マルウェア、内部不正までは防げません。

誤解3：TLSだけ対応すればよい

TLSは重要ですが、PQC対象はそれだけではありません。
VPN、SSH、電子署名、証明書、コード署名、CI/CD、バックアップ、IoT、API連携も対象です。

誤解4：暗号アルゴリズムを自作すればよい

暗号の自作は非常に危険です。
標準化された方式、信頼できるライブラリ、適切な運用設計を使うべきです。

誤解5：一度移行すれば終わり

PQC移行は一度きりではありません。
標準、実装、ベンダー対応、推奨設定は更新されます。
そのため、Crypto-agilityが重要です。

PQCはポートフォリオにも強いテーマ

PQCは、単なる流行語ではありません。
セキュリティ、クラウド、Web運用、金融、医療、公共、IoT、SaaS、DXのすべてに関わるテーマです。

ポートフォリオとして見せるなら、次のような機能が刺さります。

• TLS設定診断
• RSA / ECC利用箇所の棚卸し
• 証明書管理ダッシュボード
• SSH鍵の棚卸し
• 暗号資産台帳
• CBOM生成
• ベンダーPQC対応管理
• 鍵ローテーション管理
• バックアップ暗号化状況の可視化
• PQC移行ロードマップ管理
• Crypto-agilityスコア
• 古い暗号方式のアラート

特に、Django、PostgreSQL、Redis、Cloudflare、Nginx、WAF、SOCダッシュボードを組み合わせると、PQC移行管理ツールとして非常に実務的な価値があります。

単に「PQCを知っています」と言うよりも、
「どこに量子脆弱な暗号が残っているかを棚卸しし、優先順位を付け、移行状況を可視化できます」
と言える方が、実務では強いです。

まとめ

PQCとは、量子コンピュータ時代に備えるための耐量子暗号です。

現在広く使われているRSAやECCなどの公開鍵暗号は、将来十分に強力な量子コンピュータが登場すると危険になる可能性があります。
そのため、NISTはML-KEM、ML-DSA、SLH-DSAといったPQC標準を公開し、世界中で移行準備が進んでいます。

PQCで重要なのは、次の5つです。

1. PQCは量子コンピュータを使う暗号ではなく、量子時代に備える暗号
2. 主な移行対象はRSA、ECC、DHなどの公開鍵暗号
3. Harvest Now, Decrypt Laterにより、長期機密データは今から対策が必要
4. TLSだけでなく、VPN、SSH、電子署名、証明書、コード署名も対象
5. 最初にやるべきことは、暗号資産の棚卸しと移行ロードマップ作成

PQC移行は、ある日突然すべてを切り替える作業ではありません。
まずは、どこで暗号を使っているのかを知ること。
次に、長く守るべきデータを優先すること。
そして、将来暗号方式を入れ替えやすいCrypto-agilityを高めること。

これが、量子コンピュータ時代に向けた現実的な第一歩です。

用語と出典

最終確認日: 2026年7月22日。PQCは、将来の量子計算機による攻撃への耐性を意図して設計された暗号方式群です。 現在のRSAやECCが直ちに破られたことを意味するものではありません。 標準化状況はNISTのPQCプロジェクトを確認してください。