はじめに
「量子コンピュータってまだ先の話でしょ？」
その認識、今すぐアップデートしてください。
2024年8月、NISTは PQC の標準アルゴリズムを正式確定。
2026年3月、Googleは移行期限を 2029年 と宣言。
日本政府も 2035年 を期限として公式に動き始めています。
この記事では、「なぜ今日から動かないといけないのか」を4つの軸でわかりやすく解説します。
1. そもそも何が危ないのか
現在のインターネットを支える公開鍵暗号（RSA・ECDH・ECDSA）は、
素因数分解や離散対数問題の計算困難性 に依存しています。
古典コンピュータでは RSA-2048 の解読に数百万年かかりますが、
量子コンピュータ上の Shorのアルゴリズム を使えば、
理論上は数時間〜数日で解けてしまいます。
# Shorのアルゴリズム（概念的な疑似コード）
# 古典計算機 vs 量子計算機の計算量の差
def classical_factoring(n: int):
# 計算量 O(exp(n^(1/3))) → RSA-2048なら宇宙の年齢を超える時間
...
def shors_algorithm(n: int, quantum_computer):
# 計算量 O((log n)^3) → 多項式時間で素因数分解できる
# 量子位相推定 + 量子フーリエ変換を活用
...
NISTは2024年8月13日、耐量子計算機暗号の標準として以下を正式決定しました。
| FIPS番号 | アルゴリズム名 | 用途 | 格子問題ベース |
|---|---|---|---|
| FIPS 203 | ML-KEM（旧:Kyber） | 鍵カプセル化 | ✅ |
| FIPS 204 | ML-DSA（旧:Dilithium） | デジタル署名 | ✅ |
| FIPS 205 | SLH-DSA（旧:SPHINCS+） | デジタル署名 | ❌（ハッシュベース） |
FALCON（FN-DSA）について
FIPS 206 として標準化が進んでいますが、2026年4月時点でまだ最終確定していません。本番実装には FIPS 203/204/205 を使用してください。
2. なぜ「量子コンピュータが完成してから」では遅いのか
これが最重要ポイントです。
HNDL（Harvest Now, Decrypt Later）攻撃
[今日]
攻撃者 ──────> 暗号化通信を丸ごと盗聴・保存
（TLSセッション、APIレスポンス、認証トークン...）
[数年後、量子コンピュータ実用化]
攻撃者 ──────> 保存データを一気に解読 💥
医療記録・金融データ・機密通信が全部バレる
HNDL は「未来の脅威」ではなく「今日の脅威」です
国家レベルの攻撃者はすでにこの手法を実行している可能性があります。
「10年後も秘密でなければならないデータ」は、今日の時点で危険にさらされています。
さらに問題なのが、移行には何年もかかる という現実です。
SHA-1 廃止のとき、全システムの移行に10年以上かかりました。
PQC 移行はそれより遥かに影響範囲が広く、ステークホルダーも多い。
- TLS / SSH / JWT / コード署名 / PKI証明書 / ファームウェア すべてが対象
- 接続先システム・ベンダー・クライアント全員との協調が必要
- ML-KEM の公開鍵サイズは RSA-2048 の 約10〜30倍（帯域・ストレージへの影響あり）
3. 各国・各組織のタイムライン
🇺🇸 Google（2026年3月24日発表）
Google のセキュリティチームが 2029年 を PQC 移行目標として公式発表。
「量子ハードウェアの進展・量子誤り訂正・素因数分解リソース推定の進捗を踏まえた」と説明しており、
「2029年に量子コンピュータが完成する」ではなく「2029年までに移行を終える必要がある」 という意味です。
🏢 Microsoft
Quantum Safe Program で 2033年 完全移行を目標設定。
2026年にコアインフラ移行開始 → 2027年に Windows/Azure/M365 展開 → 2029年早期採用という段階的アプローチ。
🇯🇵 日本政府
2025年11月19日、内閣官房国家サイバー統括室が「政府機関等における PQC への移行について（中間とりまとめ）」を公表。
移行期限を 原則2035年 と設定し、情報の重要性・保護期間に応じて より早期の移行 を求めています。
2026年度中にロードマップ（工程表）を策定予定。
「2035年は余裕があるな」と思ったら危険
移行は期限ギリギリに始められるものではありません。
日本政府自身が「過去のSHA-1など危殆化対応において移行まで長期間を要した」と明示しており、
今すぐ準備を始めないと2035年に間に合わない可能性が高い です。
4. 今日から始める具体的なアクション
Step 1 ｜ 暗号インベントリ（CBOM）の作成
「自分のシステムがどこで何の暗号を使っているか」を可視化することが最初の一歩です。
# OpenSSL を使って接続先の暗号スイートを確認する例
$ openssl s_client -connect example.com:443 -showcerts 2>/dev/null \
| openssl x509 -noout -text \
| grep -E "Public Key Algorithm|Signature Algorithm|Public-Key"
# 出力例（現状）
# Signature Algorithm: sha256WithRSAEncryption
# Public-Key: (2048 bit)
# ↑ これが将来的に危殆化する暗号
# PQC 移行後に期待される出力
# Signature Algorithm: id-ML-DSA-65 ← FIPS 204
# Public-Key: ML-KEM-768 ← FIPS 203
Step 2 ｜ クリプトアジリティの設計
クリプトアジリティ とは、アルゴリズムを設定変更だけで切り替えられる設計のことです。
暗号アルゴリズムをハードコードしていると、移行コストが爆発します。
# ❌ 悪い例：アルゴリズムがハードコードされている
from cryptography.hazmat.primitives.asymmetric import rsa
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
# ✅ 良い例：アルゴリズムを設定から注入する（クリプトアジリティ）
import os
CRYPTO_ALGORITHM = os.getenv("CRYPTO_ALGORITHM", "ML-KEM-768") # 設定で切り替え
def generate_keypair(algorithm: str):
if algorithm == "ML-KEM-768":
# liboqs-python などの PQC ライブラリを使用
return pqc_keygen(algorithm)
elif algorithm == "RSA-2048":
return rsa_keygen(key_size=2048)
else:
raise ValueError(f"Unknown algorithm: {algorithm}")
Step 3 ｜ ハイブリッド PQC でリスクを分散する
いきなり PQC だけに切り替えるのはリスクが高い。
ハイブリッドアプローチ は既存暗号と PQC を組み合わせる方法で、
「どちらか一方でも安全なら通信全体が安全」という設計です。
TLS 1.3 では既にハイブリッド PQC のサポートが進んでいます（X25519MLKEM768 など）。
ロードマップ早見表
| フェーズ | 時期 | やること |
|---|---|---|
| 🔍 把握 | 今すぐ | CBOM作成・暗号の棚卸し |
| 🔧 設計 | 2026年 | クリプトアジリティ確保・ライブラリ評価 |
| 🧪 検証 | 2026〜2027年 | 非本番でのハイブリッドPQCテスト |
| 🚀 展開 | 2027〜2029年 | 外部公開APIから順次移行 |
| ✅ 完了 | 〜2035年 | 全システム完全移行・旧暗号廃止 |
おわりに
PQC 移行を「量子コンピュータが完成してから考える問題」と捉えている間に、
HNDL 攻撃であなたの今日のデータは盗まれているかもしれません。
「備えあれば憂いなし」ではなく、「備えなければ手遅れ」なのが PQC 移行です。
まず今日できること：自分のプロジェクトで openssl s_client を叩いて、
どの暗号が使われているか確認してみてください。それが第一歩です。