量子コンピュータが暗号を破る——そんな未来の話だと思っていないでしょうか。実は、主要ブラウザやプログラミング言語ではすでに耐量子暗号（PQC: Post-Quantum Cryptography）がデフォルトで動いています。設定不要、意識すらしないうちに、通信の暗号方式が切り替わっていました。

この記事でわかること

  • PQCとは何か、なぜ今から必要なのか
  • NIST標準化で決まった3つのアルゴリズムの役割
  • Chrome・Firefox・Safari・Go言語での対応状況
  • Cloudflareのトラフィックデータが示す普及の実態
  • 開発者が今やるべきこと

なぜ「今の暗号」では足りないのか

https://www.nist.gov/pqcrypto

現在のHTTPS通信で広く使われているRSAやECDH（楕円曲線ディフィー・ヘルマン）は、特定の数学的問題の計算困難性に安全性を依存しています。RSAなら巨大な整数の素因数分解、ECDHなら楕円曲線上の離散対数問題です。古典コンピュータではどちらも現実的な時間で解けません。

ところが量子コンピュータは「Shorのアルゴリズム」を使うと、これらの問題を効率的に解けます。RSA-2048を破るにはエラー訂正済みの論理量子ビットで約4,000個が必要とされ、物理量子ビットに換算すると100万個規模です。2025年6月にCraig Gidney氏が発表した論文では、必要な量子ビット数が従来の推定（約2,000万個）から100万未満へと大幅に引き下げられました。Q-day（量子コンピュータが現行暗号を破る日）は、以前の予測より数年早まった可能性があります。

「今集めて後で解読」という現実の脅威

量子コンピュータの実用化を待たずに、対応を急ぐ理由があります。「Harvest Now, Decrypt Later（今収集して後で復号する）」と呼ばれる攻撃手法です。

暗号化された通信データを今の段階で大量に収集・保存しておき、将来の量子コンピュータで復号するという考え方です。外交・軍事通信、医療・金融記録、企業の知的財産など、長期間の秘密保持が必要なデータほどリスクが高くなります。

米国NSAはCNSA 2.0ガイドラインで2030〜2033年の完全移行を求めており、米国政府全体では2035年を期限としています。EUも2030〜2035年の移行ロードマップを公表済みです。日本でもCRYPTRECが暗号技術ガイドラインでPQCへの移行推奨を示しています。

NISTが標準化した3つのアルゴリズム

2024年8月14日、NIST（米国国立標準技術研究所）は8年がかりの標準化プロセスを経て、3つのFIPS標準を正式に公表しました。

FIPS 203「ML-KEM」は、旧名CRYSTALS-Kyberで、鍵カプセル化（鍵交換）に使います。格子問題の一種であるModule Learning With Errors（MLWE）を安全性の根拠としており、量子コンピュータでも効率的に解く方法は見つかっていません。

FIPS 204「ML-DSA」は、旧名CRYSTALS-Dilithiumで、デジタル署名に使います。FIPS 205「SLH-DSA」は、旧名SPHINCS+で、署名のバックアップとしてML-DSAとは異なる数学的基盤を持ちます。

2025年3月には符号理論ベースの「HQC」が第5の標準候補に選定され、ML-KEMに脆弱性が見つかった場合のバックアップとして位置づけられています。

ブラウザとGo言語はすでにPQCで動いている

標準化よりも先に、実装側の対応は進んでいました。TLS 1.3の鍵交換で使われる「X25519MLKEM768」は、従来のX25519（楕円曲線）とML-KEM-768（格子ベースPQC）を両方実行し、出力を組み合わせてセッション鍵を生成するハイブリッド方式です。どちらか一方が将来破られても安全という、保守的な移行戦略になっています。

主要クライアントの対応時期は以下のとおりです。Chrome Desktopは2024年3月から、Chrome Androidは2024年11月から、Firefox Desktopは2024年11月から、Safari（iOS / macOS）は2025年10月からデフォルト有効になっています。Go言語のhttp.Clientも、Go 1.24（2025年2月〜）からデフォルトでX25519MLKEM768を使います。

つまり、Go 1.24でHTTPSサーバーを動かしていれば、対応ブラウザからのアクセスは自動的にPQCで保護されます。TLS 1.3のネゴシエーションにより、クライアントが対応していない場合は従来のX25519にフォールバックするため、互換性の問題は発生しません。

トラフィックの半数がすでにPQC保護下

https://blog.cloudflare.com/pq-2025/

Cloudflareが公表したデータによると、2025年末時点でヒューマントラフィックの52%がPQC保護済みです。2025年初頭の29%から約2倍に増加しました。Safariの対応（2025年10月）から半年以上が経過しており、この比率はさらに上昇しているとみられます。

Cloudflare自身は2029年の完全PQC化を目標に掲げており、2026年中頃にはAPIフラグを「PQC only」に設定するフェーズ2への移行を計画しています。

ただし、これは鍵交換（暗号化）の話です。証明書に使うデジタル署名のPQC対応は遅れており、PQC証明書が広く普及するのは2027年以降と見込まれています。

開発者が確認すべきこと

Go 1.24以降を使っている場合、PQCはデフォルトで有効です。tls.ConfigのCurvePreferencesを明示的に指定していなければ、自動的にX25519MLKEM768が使われます。無効にしたい場合は環境変数GODEBUG=tlsmlkem=0で制御できます。

他の言語やフレームワークでも、TLSライブラリがML-KEMに対応していれば同様の動作になります。サーバー側の対応だけでは不十分で、クライアント（ブラウザ）側も対応していないとPQCのネゴシエーションは成立しません。現時点ではChrome・Firefox・Safariの最新版がすべて対応済みのため、一般的なWebサービスであれば大半のトラフィックがPQCで保護されています。

注意が必要なのは、古いブラウザやカスタムHTTPクライアントからのアクセスです。PQCのハンドシェイクでは鍵データが約1KB増加するため、パケットサイズに厳しい制約があるネットワーク環境では接続に影響が出る場合があります。

まとめ：研究から本番へ、移行はすでに始まっている

耐量子暗号は研究段階を終え、Webの標準インフラに組み込まれました。Chrome・Firefox・Safariのユーザーは、意識せずにPQCで保護された通信を使っています。Go 1.24でサーバーを動かしている開発者も同様です。

Q-dayがいつ来るかは誰にもわかりません。ただし、各国の規制当局が2030〜2035年の移行期限を設定していること、そしてHarvest Now, Decrypt Laterの脅威が現実に存在することを踏まえると、「まだ先の話」と放置するリスクは大きいです。サーバーやライブラリのバージョンを最新に保つことが、最も手軽で効果的なPQC対応の第一歩になります。