はじめに ── 「量子」は遠い話じゃない

「量子コンピューター」と聞くと、研究所の中だけの話に聞こえるかもしれません。しかし2026年現在、IBMはThe dawn of quantum advantageにて「2026年末までに量子コンピューターが古典コンピューターを補完し、一部のタスクで初めて優位性を示す」と予測しており、Amazon・Google・Microsoftなどの主要クラウドベンダーはすでに「ポスト量子暗号」の実装を本番サービスに組み込み始めています。

グーグル、耐量子暗号移行を2029年に設定というニュースもありましたね。

さらに、NISTという米国の標準化機関は2024年8月に新しい暗号の世界標準を確定させ、米国政府は2035年までの全システム移行を方針として示しました。

暗号の世代交代は、すでに始まっています。

この記事では、暗号の専門知識がないエンジニアでも「自分が何をすべきか」が具体的にわかるよう、できるだけシンプルに解説します。

まず知っておくべきこと ── 今の暗号が危ない理由

私たちが毎日使っている暗号

ブラウザのアドレスバーに表示される🔒マーク、SSHでサーバーにログインするとき、JWTトークンで認証するとき── これらすべてに暗号が使われています。特に広く使われているのが RSA と ECDSA という2つのアルゴリズムです。

これらは「非常に大きな数の素因数分解が難しい」「楕円曲線上の離散対数問題が難しい」という数学的事実を安全性の根拠にしています。現代のコンピューターでは、これを解くのに数十億年かかります。だから安全、というわけです。

量子コンピューターが変えること

ところが量子コンピューターには「ショアのアルゴリズム」という手法があり、これを使うと素因数分解や離散対数問題を現実的な時間で解けてしまいます。

つまり、十分に強力な量子コンピューターが完成すれば、今のHTTPS通信もSSH接続もすべて破られる可能性があるということです。

「でも量子コンピューターはまだ弱いんでしょ？」

そう、今現在はまだ暗号を破れるほどの量子コンピューターは存在しません。しかし、着々と用意はされています。

攻撃者は「Harvest Now, Decrypt Later（今収穫し、後で復号する）」という戦略を取っています。今のうちに暗号化された通信データを大量に収集・保存しておき、将来量子コンピューターが完成したときに一気に復号するのです。

政府の機密通信、金融取引の記録、企業の知的財産── 長期間にわたって秘匿が必要なデータは、量子コンピューターが完成する「前に」移行を始めなければなりません。

ポスト量子暗号（PQC）とは何か

PQC（Post-Quantum Cryptography / ポスト量子暗号） は、量子コンピューターでも破れないよう設計された新しい暗号技術の総称です。「ポスト量子」という名前の通り、量子コンピューター時代が来た「後」でも安全な暗号という意味です。

NISTは8年間の標準化プロセスを経て、2024年8月に以下の3つを正式標準として発表しました。

標準	旧称	用途	特徴
FIPS 203 — ML-KEM	CRYSTALS-Kyber	鍵カプセル化（鍵交換）	主力。格子暗号ベース
FIPS 204 — ML-DSA	CRYSTALS-Dilithium	デジタル署名	主力。格子暗号ベース
FIPS 205 — SLH-DSA	SPHINCS+	デジタル署名（バックアップ）	ハッシュベース。格子が破られた時の保険

格子暗号 というのは、多次元空間の「格子」（規則的に並んだ点の集合）上の問題を解くことの難しさを安全性の根拠にした暗号です。量子コンピューターでも効率よく解けないと考えられています。

「遅くなるんじゃないの？」という疑問

エンジニアが一番気になるのはパフォーマンスだと思います。結論から言うと、計算速度はむしろ有利な面もあります。ボトルネックは帯域幅（データサイズ）です。

出典: QRAMM Cryptographic Algorithms
Reference

鍵と署名のサイズが大きく増加するため、TLSハンドシェイク時に数KBの追加データが発生します。高速回線なら影響はほぼ感じられませんが、低速ネットワークではハンドシェイク時間が増加する可能性があります。ただしこれは接続確立時の一度きりのコストです。

エンジニアが具体的にやるべきこと ── 6ステップ

ステップ1：自分たちが使っている暗号を把握する（CBOM作成）

移行の第一歩は「どこで何の暗号を使っているか」の可視化です。これを CBOM（Cryptographic Bill of Materials / 暗号部品表） と呼びます。package.json のような「依存ライブラリ一覧」の暗号特化版だと思ってください。

以下の項目を洗い出します。

使用している暗号アルゴリズム（RSA-2048、ECDSA P-256、AES-256 など）
暗号が使われている場所（HTTPS通信、SSHログイン、JWT署名、データベース暗号化など）
依存している暗号ライブラリとバージョン（OpenSSL のバージョンは？）
SSL/TLS証明書の発行元と有効期限

全システムを一度に棚卸しする必要はありません。ビジネス上重要なシステムや、長期間データを保持するシステムから着手するのが現実的です。

こちらの記事はSonarQubeとSonar-cryptographyプラグインを用いて、Javaソースコードから暗号を検出し、CBOMを生成する手順を紹介しています。
他にもGitHub Actionsに追加するだけのCBOMkit-actionや、コンテナイメージを直接スキャンするCBOMkit-theiaがあります。

ステップ2：「暗号を簡単に切り替えられる設計」にする（クリプトアジリティ）

クリプトアジリティ（Crypto-Agility / 暗号俊敏性） とは、暗号アルゴリズムをコード変更なしで切り替えられる設計のことです。

多くのシステムでは、暗号アルゴリズムがコードにハードコードされています。

# 悪い例：アルゴリズムがハードコードされている
from cryptography.hazmat.primitives.asymmetric import rsa
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)

# 良い例：アルゴリズムを設定で管理する
import os
CRYPTO_ALGORITHM = os.getenv("CRYPTO_ALGORITHM", "rsa")  # 設定で切り替え可能

def generate_key():
    if CRYPTO_ALGORITHM == "rsa":
        # RSA実装
    elif CRYPTO_ALGORITHM == "ml-dsa":
        # ML-DSA実装

クリプトアジリティが確保されていれば、PQCへの切り替えも将来の新しいアルゴリズムへの対応も、設定変更だけで済みます。これは移行の前提条件であり、最も重要なアーキテクチャ投資です。

ステップ3：いきなり全切り替えせず「ハイブリッド方式」から始める

PQCアルゴリズムはまだ比較的新しく、未知の脆弱性がゼロとは言い切れません。そこで推奨されているのが ハイブリッド方式 です。

ハイブリッド方式とは、従来の暗号とPQCを両方同時に使うアプローチです。「X25519（従来の鍵交換）+ ML-KEM（PQC）」のように2つの鍵交換を同時に行い、両方の結果を合成します。どちらか一方が破られても、もう一方が安全性を保ちます。

TLS 1.3のハイブリッド方式の組み合わせは以下の通りです。

名称	組み合わせ
X25519MLKEM768	X25519 + ML-KEM-768
SecP256r1MLKEM768	ECDH P-256 + ML-KEM-768
SecP384r1MLKEM1024	ECDH P-384 + ML-KEM-1024

ステップ4：ライブラリを試してみる

実際にコードでPQCを試すには、Open Quantum Safe（OQS）プロジェクト があります。NIST標準アルゴリズムのリファレンス実装をまとめたOSSエコシステムで、C言語の liboqs を中核に、各言語向けのバインディングやOpenSSL用プラグインを提供しています。

OpenSSL 3.x に PQC を追加する oqs-provider を使えば、既存の OpenSSL ベースのアプリケーションをほとんど書き換えずに PQC 対応できます。

# oqs-provider のセットアップ（概略）
git clone https://github.com/open-quantum-safe/oqs-provider.git
# liboqs 本体と合わせてビルドすると OpenSSL 3.x で PQC が使えるようになる

Python の場合：

https://github.com/open-quantum-safe/liboqs-python
こちらのインストール手順をこなして（macOS では先に brew install cmake してソースから liboqs をビルドする必要があります）

pip install liboqs-python

を実行します。

import oqs

# ML-KEMで鍵交換を試す
with oqs.KeyEncapsulation("ML-KEM-768") as client:
    with oqs.KeyEncapsulation("ML-KEM-768") as server:
        public_key = client.generate_keypair()
        ciphertext, shared_secret_server = server.encap_secret(public_key)
        shared_secret_client = client.decap_secret(ciphertext)
        assert shared_secret_server == shared_secret_client
        print("鍵交換成功！")

これを実行すると、鍵交換成功！と表示されます。

ステップ5：クラウドサービスのPQC対応を活用する

自前で全てを実装する必要はありません。主要クラウドプロバイダーはすでにPQCサポートを提供しています。

AWS（最も対応が進んでいる）

KMS、ACM、Secrets Manager、CloudFront、ALB/NLBがハイブリッドPQC TLSをサポート済みです。ALB（Application Load Balancer）の場合、セキュリティポリシーを変更するだけでアプリケーション側の修正なしにPQC TLSが有効になります。

Application Load Balancer のセキュリティポリシー

# AWSコンソールまたはCLIでALBのセキュリティポリシーを変更（執筆時点の最新は2025-09）
ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09     # 推奨（通常用途）
ELBSecurityPolicy-TLS13-1-2-FIPS-PQ-2025-09    # FIPS準拠が必要な場合

参考：

Google Cloud

Cloud KMSがML-KEMをGA提供、ML-DSA/SLH-DSAをプレビュー提供

Microsoft Azure

Azure Key Vaultでサポートされたという情報は見つからず。

Azure Key Vault: キーの種類、アルゴリズム

ステップ6：移行のタイムラインを理解して計画を立てる

PQC移行は一夜にして完了するものではなく、数年がかりのプロジェクトです。

2026年（今！）
  └── CBOMの作成と現状可視化
  └── クリプトアジリティのためのリファクタリング
  └── 非本番環境でのハイブリッドPQCテスト

2026〜2029年
  └── 外部公開サービス・APIへのハイブリッドPQC適用
  └── 高リスクデータを扱うシステムの移行
  └── 証明書・鍵管理インフラのPQC対応

2029〜2035年
  └── 全システムの完全移行
  └── レガシー暗号（RSA/ECDSA）の廃止

NISTは「2030年までに現行アルゴリズムの非推奨化、2035年までに完全移行」を推奨しています。米国政府機関には政策指針（NSM-10）として移行が求められていますが、日本企業でもグローバルな規制対応やセキュリティリスク管理の観点から、この期間を念頭に計画を立てることが推奨されます。

よくある疑問

Q: 小さなWebサービスを作っているエンジニアには関係ない話？

HTTPS通信を行うすべてのサービスに関係します。ただし、クラウドのロードバランサーやCDNを使っていれば、そのレイヤーでの対応が先に進むため、アプリケーション開発者として今すぐコードを書き換える必要はありません。まずは「自分のシステムがどこでTLS終端しているか」を確認することから始めましょう。

Q: AES（共通鍵暗号）はどうなるの？

AESは量子コンピューターに対しても一定の耐性があります（グローバーのアルゴリズムで攻撃できますが、鍵長を256ビットにすれば実用上問題ないと言われています）。PQC移行の主な対象は、公開鍵暗号（RSA、ECDSA）と鍵交換（ECDH） です。

ショアのアルゴリズムとの違い

ショア
- 対象: RSA・ECDSA（素因数分解・離散対数）
- 効果: 指数関数的に高速化 → 完全に破壊
グローバー
- 対象: AES・SHA（総当たり探索）
- 効果: 平方根分の1に短縮 → 弱体化するが対処可能

まとめ

ポスト量子暗号への移行は、遠い未来の話ではありません。標準は確定し、クラウドベンダーは実装済みで、移行のタイムラインも明確になっています。

「攻撃者はすでに今のデータを収集している」という事実を踏まえると、動き出すべき時期はまさに「今」です。

今すぐできる最初の一歩は「自分のシステムで暗号が使われている場所を把握すること」です。 そこから、クリプトアジリティの確保、ハイブリッド方式の試験、クラウドサービスの活用と、段階的に進めていきましょう。

参考資料

標準・仕様

NIST Post-Quantum Cryptography 公式サイト — FIPS 203/204/205の仕様書と最新情報
FIPS 203（ML-KEM）仕様書 — 鍵カプセル化メカニズムの正式仕様
NIST Releases First 3 Finalized Post-Quantum Encryption Standards — 2024年8月の公式発表
Migration to Post-Quantum Cryptography | NCCoE (NIST) — NIST公式移行ガイダンス
draft-ietf-tls-ecdhe-mlkem | IETF — TLS 1.3ハイブリッド鍵交換のIETFドラフト

移行ガイド

Post-Quantum Cryptography Authentication Migration Guide 2026 — エンタープライズ向け移行ガイド
Post Quantum Cryptography Migration | ISACA Journal 2026 — ISACAによるPQC移行解説
Crypto-Agility: Building Systems That Adapt | QRAMM — クリプトアジリティ設計ガイド
Cryptographic Algorithms Reference | QRAMM — 古典 vs PQCアルゴリズム性能比較表

ツール・ライブラリ

Open Quantum Safe プロジェクト — liboqs, oqs-providerなどのツール群
liboqs-python（GitHub） — Pythonバインディングとサンプルコード
oqs-provider（GitHub） — OpenSSL 3.x用PQCプロバイダー
CBOMkit（GitHub, PQCA） — CBOM自動生成ツール群（IBM→Linux Foundation寄贈）
Cryptography Bill of Materials (CBOM) | CycloneDX — CBOMの標準フォーマット仕様

クラウド各社の対応

AWS Post-Quantum Cryptography 移行計画 — AWSの実装ガイド
ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager — AWSサービスのPQC TLSサポート詳細
Application Load Balancer のセキュリティポリシー | AWS — ALBのPQC対応ポリシー一覧
Cloud KMS における耐量子鍵カプセル化メカニズムの発表 | Google Cloud — Google CloudのPQC対応
Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms — MicrosoftのPQC GA発表

言語・フレームワーク

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 — JavaのPQCサポート（JDK 27）
cloudflare/circl（GitHub） — Go言語向けPQC実装ライブラリ
IBM Developer: Developing with quantum-safe OpenSSL — OpenSSL + PQCのステップバイステップチュートリアル

日本語資料

SBOMだけじゃない？CBOM編 | Zenn (NTTデータ) — CBOMの日本語解説
量子時代の暗号技術：ポスト量子暗号(PQC)とは？ | Qiita — PQCの日本語入門記事