Let’s Encrypt（レッツ エンクリプト）が2026年6月3日に発表したロードマップは、単なる証明書の規格変更ではなく、迫り来る量子コンピュータの脅威に対するWebPKI（公開鍵基盤）全体の構造改革である。
- 引用元URL: https://letsencrypt.org/2026/06/03/pq-certs
- 公開年月日: 2026年6月3日
NISTや欧州による規制方針、さらにGoogleやCloudflareによる自社サービスの移行コミットメントの前倒しを受け、認証局として具体的な実装に踏み切った背景がある。
ポスト量子暗号化と認証のタイムライン差
これまでポスト量子暗号（PQC）への移行において、優先されていたのは「暗号化（鍵交換）」であった。
- 暗号化（過去のデータの保護）： 攻撃者が現在の暗号化通信をキャプチャして保存しておき、将来強力な量子コンピュータ（CRQC）が完成した時点で遡って解読する「Harvest Now, Decrypt Later」のリスクがあるため、対応の緊急度が高かった。
- 認証（リアルタイムの偽装防止）： 認証（サーバーが本物証明書を持っているかの検証）を破るには、量子コンピュータを用いてリアルタイムで署名を偽造する必要がある。そのため「CRQCの実用化までは猶予がある」とされてきた。
なぜ認証の移行を今始めなければならないのか
この認識は変わりつつある。第一に、ルート証明書（Root CA）やコード署名、アイデンティティシステムなどの「長寿命の鍵（Long-lived keys）」は、長期にわたり信頼の起点となるため、現在すでに極めて価値の高い標的となっている。第二に、新しい暗号インフラがブラウザ、ライブラリ、クライアントへ広く普及し、実用的な安定性を得るには数年単位の歳月が必要となる。CRQCの到来が予測される一歩手前で動いたのでは間に合わないため、今から着手する必要がある。
現在のグローバルな動向は以下の通りである。
- 米国（CNSA 2.0）： 国家安全保障システム（NSS）に対し、2030〜2035年のスケジュールでPQCへの移行を義務化。
- 米国（NIST）： 移行ガイダンスにおいて、2030年以降にRSA-2048やP-256を推奨から外し、2035年には禁止する方針。
- 欧州（EU）： ロードマップにおいて、2030年までに高リスクシステム、2035年までに広範な移行を目標として設定。
- 民間（Google / Cloudflare）： GoogleはCRQCの到来予測の引き締まりを受け、自社サービスを2029年までに移行する目標を自主的に発表。Cloudflareもこれに追従。
これら政府機関の義務化や主要ベンダーの目標はパブリックWeb PKIを直接法的に拘束するものではないが、業界のデファクトスタンダードを動かす決定的なタイムラインとなっている。
なぜ従来の「X.509」では破綻するのか
ポスト量子認証において、最大の障害となるのがデータサイズ（オーバーヘッド）である。
現在WebPKIの標準であるX.509証明書に、NIST標準のポスト量子署名アルゴリズムであるML-DSAをそのまま適用しようとすると、以下の問題が発生する。
| 項目 | 従来のECDSA (P-256) | 従来のRSA (2048-bit) | ポスト量子暗号 (ML-DSA-44) |
| 署名サイズ | 64バイト | 256バイト | 2,420バイト |
| 公開鍵サイズ | 64バイト | 256バイト | 1,312バイト |
通常のTLSハンドシェイクでは、ルート証明書から中間証明書、エンドエンティティ証明書に至るまで、平均して5つの署名と2つの公開鍵がやり取りされる。
これをすべてML-DSAに置き換えた場合、1回のTLSハンドシェイクのデータ量は10キロバイトを超える。Cloudflareの実証実験によると、この規模のパケットサイズになると、既存のリアルワールドのネットワークにおいてフラグメンテーション（パケット分割）やパケットロスが多発し、接続の遅延だけでなく、無視できない割合で接続自体が失敗（ドロップ）することが判明している。つまり、X.509の「個々の証明書に独立した署名を付与する」という構造のままでは、デフォルトのセキュア通信として運用することは実用上不可能に近い。
MTC（Merkle Tree Certificates）による構造転換
このサイズ肥大化問題を根本から解決するために提案されたのが、MTC（Merkle Tree Certificates）である。
X.509が「認証局が個々の証明書に対して都度署名を行う」のに対し、MTCは「大量の証明書をハッシュツリー（マークルツリー）に集約し、ツリーのルート（根）に対してのみポスト量子署名を行う」アプローチを取る。
- ランドマーク（Landmark）： 認証局が定期的に発行する、マークルツリー全体のポスト量子署名。ブラウザ（クライアント）はTLSハンドシェイクとは別のタイミング（非同期）でこのランドマークを事前取得、またはバックグラウンドで更新しておく。
- 包含証明（Inclusion Proof）： サーバーが提示する「自身の証明書が、ブラウザが保持しているランドマーク（ツリー）の中に確実に含まれている」というハッシュの経路情報。
MTCを採用することで、通常のTLSハンドシェイク時に通信経路を流れるデータは「1つの署名、1つの公開鍵、1つの包含証明」に削減される。結果として、ポスト量子暗号を導入しているにもかかわらず、ハンドシェイクのデータサイズは現行のWebPKI（X.509）よりも小さくなる。
なお、クライアント側の保持するランドマークが古い（最新のツリーを反映していない）場合のフォールバックとして、ハンドシェイクサイズはやや大きくなるものの、単体で検証を完結させる「スタンドアロン形式」も仕様として定義されている。
透過的検証（Certificate Transparency）のネイティブ化
X.509では、不正発行を監視する「Certificate Transparency（CT）」のログ登録は、発行後に外部のログサーバーへ送信し、SCT（Signed Certificate Timestamp）を証明書に埋め込むという「後付け」の運用が必要だった。
MTCでは、証明書が発行される条件そのものが「マークルツリー（公開ログ構造）への組み込み」であるため、CTの仕組みが最初から発行プロセスに内蔵（subsume）されている。 別途SCTをハンドシェイクに添付する必要もなくなり、さらなるサイズ削減とセキュリティ向上が実現する。
Let’s Encryptの具体的実装ロードマップ
Let’s Encryptを運営するISRGは、すでに2019年から大規模なCTログ（append-onlyなマークルツリー）を運用しており、このデータ構造のプロダクション運用に関するノウハウを持っている。これをベースに、以下のスケジュールで実装を進める。
- 2026後半（ターゲット）： MTCを発行するステージング（テスト）環境の提供。
- 2027年： プロダクション（本番）環境でのMTC運用開始。
実装に向けた技術的課題とエコシステムの動向
この移行は認証局側だけで完結しない。エコシステム全体における以下のプロトコル・ツールのアップデートが並行して進められている。
- 暗号標準・プロトコルの策定： X.509証明書におけるML-DSAの利用を定義するRFC 9881や、TLSにおけるML-DSAの仕様（draft-ietf-tls-mldsa）の標準化。
- MTC標準化とACME拡張： PLANTS（PKI, Logs, And Tree Signatures）ワーキンググループを中心にMTCのアーキテクチャ標準化が進められており、その中にはMTCプロビジョニングのためのACME（RFC 8555）拡張仕様の策定も含まれる（必要に応じてACME WGとも連携）。
- エコシステム・クライアント側の対応： CertbotをはじめとするACMEクライアントにおけるMTC対応、およびWebブラウザ（Chrome等はすでにMTCを推奨経路として表明）や暗号ライブラリ（Go 1.27でのML-DSA標準ライブラリ化など）の普及。
サイト管理者やACMEクライアントのメンテナーは、IETFのPLANTSワーキンググループの動向、およびChromiumのメーリングリスト（mtcs@chromium.org）の議論を追跡し、クライアント側の対応準備を始めるフェーズに入っている。
