この記事は PQC Advent Calendar 2025 向けのエントリです。
本記事の内容は筆者個人の見解であり、所属組織・企業の公式見解ではありません。また、本記事の原案は AI を用いて作成していますが、ここで整理した概念や考え方については筆者自身が確認しています。
NICTER BLOG の記事「ライブネットにおける PQC 利用状況の調査」を読んで、次の表を見ました。これを見たとき、もしかしたら「主要ブラウザがPQC対応なら、多くのウエブサイトもすでにPQCが有効なのでは？」と思ったのですが、調べてみると自分が想像していた意味とは違うことが分かりました。
表1. PQC が有効化されたブラウザのバージョン（NICTER BLOGより）
| ブラウザ | バージョン | リリース日 |
|---|---|---|
| Microsoft Edge | 120 | 2023年11月 |
| Google Chrome | 124 | 2024年4月 |
| Mozilla Firefox | 132 | 2024年10月 |
| Apple Safari | 26 | 2025年9月 |
結論
- ブラウザで「PQCが有効」と言うとき、多くの場合は TLSの「鍵交換（セッション鍵を作る部分）」にPQCが使えるという意味。
- TLS証明書の署名アルゴリズムがPQCに置き換わった、という話とは別。証明書は今のWebでは基本まだRSA/ECDSAが主流。
- NCSCの記事は「証明書の取得・更新・鍵管理」など運用の話で、PQC鍵交換の話とはレイヤが違う。
まず、HTTPSには“2つの役割”がある
壱、通信内容を暗号化する「一時的な秘密（セッション鍵）」
- ブラウザとWebサイトが接続のたびに作る「今回だけの秘密」
- これでページ内容やAPI通信が暗号化される
弐、相手が本物か確認する「身分証（TLS証明書）」
- 「このサイトは本当に example.com ですよ」を証明するIDカード
- CA（認証局）が署名して発行する
この2つが混ざると混乱します。
「ブラウザでPQCが有効」＝どっちの話？
基本は「壱、セッション鍵を作る部分（鍵交換）」の話です。
多くの実装ではハイブリッド（従来方式＋PQC方式）で鍵交換を行い、将来量子計算機が実用化した場合でも、通信の機密性を守れるように移行が進んでいます。
「片方（ブラウザ）だけ対応」だとどうなる？
鍵交換は「交渉（negotiation）」なので、
- ブラウザがPQC（ハイブリッド）に対応
- サーバ（またはCDN）がPQC（ハイブリッド）に対応
この 両方が揃って、実際にその方式が選ばれた時だけ、その接続はPQC（多くはハイブリッド）でセッション鍵を作れます。
片方だけだと、普通に従来方式にフォールバックします。
ちなみに、サーバ側は「Webサイト本体」ではなく「CDN」のことが多い
多くのWebサイトはCloudflareやAkamaiなどのCDNを経由しています。この場合、ブラウザが実際にTLS接続している「相手」はオリジンサーバではなくCDNのエッジです。
そのため、CDNがハイブリッドPQC鍵交換に対応していると、サイト運営者がオリジン側を大きく変えなくても（少なくともエッジ〜ブラウザ間は）PQCが使われるケースがあります。
「今収穫し、後で解読する」(Harvest now, decrypt later)
攻撃者がやりたいのはこれです：
- 現時点では解読できない暗号化された情報を収集・保存し
- 将来量子計算機などで、保存したハンドシェイク情報からセッション鍵を逆算して復号
そこでハイブリッド鍵交換を使うと、
- セッション鍵が「従来方式 + PQC方式」両方から作られる
- 将来、従来方式が破られてもPQC側が破られなければセッション鍵が再現できない
Web PKI（証明書運用）の話
ここまでの話（PQC＝主に鍵交換の話）とは別に、最近は「証明書のライフタイムが短くなる（最終的に47日へ）」という 証明書運用（Web PKI）の大きな変化も進んでいます。本日（2025/12/14）時点では TLS証明書の最大有効期間とドメイン検証情報（DCV）の再利用期間はいずれも最大398日ですが、2026/03/15以降は両方とも最大200日に短縮されます（その後も段階的に短縮され、最終的に証明書は47日・DCV再利用は10日へ）。なお、この「47日」は 証明書の有効期間の話で、セッション鍵（通信の“合言葉”）の更新頻度とは別物です。
上のように証明書の有効期間・検証情報の再利用期間が短くなっていく前提では、「証明書を止めずに回し続ける」ための設計が重要になります。NCSCのガイダンスが実務として強調しているのは、発行・更新を手作業にせず 自動化すること、どのドメイン／どのシステムでどの証明書を使っているかを インベントリとして把握すること、更新・配布の失敗や期限切れを前提に 監視とアラートを整えること、秘密鍵を安全な場所に置きアクセス権やローテーション方針を含めて 鍵保護を徹底すること、そして想定外発行や漏えい時に失効・差し替え・影響範囲特定を素早く回せる状態にしておくことです。