2026年2月、GoogleのChrome Secure Web Networking Teamは、HTTPS証明書のあり方を根本から刷新する計画を発表した。
https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/
その中心にあるのが、耐量子計算機暗号（PQC）でありながら、現代のウェブと同等のパフォーマンスを維持する新しい証明書フォーマット「Merkle Tree Certificates（MTC）」である。
背景：なぜ今、証明書の再設計が必要なのか
膨れ上がる通信量と従来の構造の限界
TLS通信の土台を支える「X.509証明書」は、数十年にわたってインターネットセキュリティの基盤として機能してきた。しかし、量子コンピュータの台頭により、その前提が崩れようとしている。
NIST（米国標準技術研究所）が標準化を進める耐量子暗号アルゴリズムは、従来の暗号方式と比較して鍵サイズや署名サイズが大幅に膨れ上がる。現在のX.509証明書チェーンの構造にこれをそのまま適用すると、TLSハンドシェイクの通信量が爆発的に増加してしまう。Certificate Transparency（CT）ログとの組み合わせではさらに深刻である。
現状のPKI（公開鍵基盤）は「シリアルな署名チェーン」構造を持つ。ルートCAから中間CA、そしてサーバー証明書へと至る連鎖のそれぞれに署名が必要だが、耐量子暗号を使用すると、このチェーン全体のデータサイズが非現実的な水準に達する。そのためGoogleは、「Chrome Root StoreにPQC（耐量子暗号）を乗せた従来型X.509証明書を追加する予定はない」と明言し、代替としてMTCの開発を進めている。
MTC（Merkle Tree Certificates）の仕組みとは
個別署名からツリー構造への変革
MTCは、その名の通り「マークルツリー（Merkle Tree）」と呼ばれる暗号学的データ構造を証明書の発行と検証に応用する仕組みである。従来のX.509が「個別の証明書にCAが署名する」モデルであるのに対し、MTCは発想を逆転させている。
CAは数百万件の証明書を束ねたマークルツリーを構築し、その根元（Tree Head）に一度だけ署名を行う。サーバーからブラウザへ送られるのは証明書のフルボディではなく、「このツリーに自分が含まれている」ことを証明するマークルパス（わずか数十バイトの軽量なデータ）のみである。
ブラウザは、そのパスとTree Headのハッシュ値を照合するだけで検証が完了する。チェーン全体のシリアルな署名検証は不要となり、通信量を大幅に削減できる。
MTCにおける統合ログモデル
従来の公開鍵基盤（PKI）では、証明書を発行した後にCTログへ登録するという「後付け（Bolt-on）」のアプローチをとっていた。これは、発行機関（CA）とCTログの間の複数の通信ステップやオーバーヘッドを伴う。
一方、IETFのドラフトで定義されるMTCでは、発行プロセス自体にCTが統合されている。
CAによるログ構築
CA自身が、発行する証明書を含んだ一貫性のあるログ（マークルツリー）を直接作成する。
順序の一元化
従来のシステム（CT）では、世界中に複数の独立したログサーバーが存在しており、サーバーごとに証明書を受け付けて記録するため、後からサーバー同士で「どの順番で登録されたか」を確認し合い、データを同期させる手間やタイムラグが発生する。 これに対し、MTCでは発行と同時にツリー内での位置が確定し、あらかじめ順序が指定されるため、複数のログサーバー間で同期をとる処理が不要となる。
透明性の強制
MTC形式で発行された証明書は、必ずツリーの葉（Leaf Node）として組み込まれる。発行とツリーへの掲載が不可分であるため、記録漏れや秘密裏な発行ができない仕組みになっている。
署名なし証明書による通信量の削減
耐量子暗号（PQC）のアルゴリズムを導入する際、最大の課題は署名サイズの肥大化である。MTCはこの問題を解決するために、サイズ最適化の仕組みを提供する。
証明書全体の署名省略
クライアント（ブラウザ）は、CAの個別の署名検証を行わない。
Tree Headの利用
ルートCAや信頼できる機関から、定期的にハッシュの基準点となる「Tree Head（チェックポイント）」を入手する。
マークルパスの照合
サーバーからは「ツリーに自分が含まれているか」を示すマークルパス（数十バイト程度）のみを送信する。クライアントは、受信したデータがツリーのどこに属しているかを計算によって検証できるため、巨大な電子署名をやり取りする必要がなくなる。
クライアントが行う検証の3ステップ
- ツリーの基準点（Tree Head）の確認 クライアントは、あらかじめ信頼された機関から発行された、ツリー全体のハッシュ値であるTree Head（ツリーの頂点データ）を受け取る。これにはCAの電子署名が付与されており、データが改ざんされていないことが保証されている。
- マークルパスの受信 サーバーからは、証明書本体の代わりに以下のデータが送信される。
- 証明書データ（ツリーの葉に相当する部分）
- マークルパス（Tree Headにたどり着くために必要な、隣接するハッシュ値のリスト）
- ハッシュ計算と照合
- 自身の証明書のハッシュ値を計算する。
- ツリーを上に向かって計算する。受け取ったマークルパスと算出した値を組み合わせ、ハッシュ化を行い、さらに上の階層のハッシュ値を計算する。
- ツリーの頂点まで計算して得られた結果が、手順1で持っていたTree Headと完全に一致するかを照合する。
信頼と検証モデルの変革
MTCは、単にデータサイズを圧縮するだけでなく、以下のような仕組みによってセキュリティを補強している。
ミラー（Mirror）によるデータ検証
CAは証明書ツリーを作成し、それをミラーサイトなどに公開する。万が一、CAが不正な分岐を起こした場合でも、特定のビューに固定することで検証が可能である。
耐量子暗号との親和性
署名サイズが大きくなる耐量子暗号アルゴリズムであっても、MTCであれば通信量への悪影響を最小限に抑えることができる。
MTCが解く3つの課題＋1つの革新
MTCの導入により、以下の課題が解決され、新しいメリットが生まれる。
1. 帯域幅の最適化
PQC（耐量子暗号）を採用した場合でも、証明書のデータサイズを小さく抑えることが可能である。
2. 透明性の確保
発行と同時にログへ記録される仕組みが構造上必須となるため、高い透明性を実現する。
3. パフォーマンスの向上
TLSハンドシェイク時に発生するオーバーヘッドを最小限に抑えることができる。
4. 秘密裏な証明書の排除（隠蔽の防止）
現行のCTエコシステムでは、CTログへの記録はポリシーによる強制であり、技術的には記録なしの証明書発行が可能であった。しかしMTCでは、発行とツリーへの掲載が不可分であるため、構造的に秘密裏な証明書の発行ができない。透明性がデフォルトで組み込まれている点が大きな特徴である。
Chromeにおける展開ロードマップ
GoogleはすでにCloudflareと連携し、MTCの実トラフィックテストを開始している。ロードマップは以下の3つのフェーズに分かれている。
Phase 1：フィージビリティスタディ（現在進行中）
Cloudflareと連携し、既存のX.509証明書でバックアップを行いながらMTC接続のテストを実施している。ユーザーへのリスクをゼロにした状態で、実環境におけるパフォーマンス測定と信頼性の検証を行っている。
Phase 2：パブリックMTCの初期展開（2027年 Q1）
2026年2月1日以前からChromeのCTログを運営している組織を優先招待し、初期展開が始まる。高可用インフラと運営実績が参加条件となる。
Phase 3：CQRSの始動（2027年 Q3）
MTC専用のルートストアである「Chrome Quantum-resistant Root Store（CQRS）」が正式に立ち上がる。既存のChrome Root Programと並行稼働させ、段階的な移行が管理される。
既存X.509との共存戦略
MTCへの移行は突然の切り替えではなく、既存のChrome Root Programも引き続きサポートされるハイブリッドな共存戦略がとられる。また、プライベートPKI向けには、耐量子暗号を適用した従来型X.509証明書を2026年中にサポートする予定である。準備が整ったサイトから段階的にオプトイン形式でMTCへの移行を進めることが可能である。
総括：移行に向けた準備は今から
MTCは単なる「量子対応の証明書」にとどまらず、発行モデルや検証構造、エコシステムの参加要件に至るまで、HTTPS証明書の設計を根本から見直す野心的な取り組みである。
IETFのPLANTS WGやC2SPでの標準化作業と並行してChromeが実装を進めていることから、この計画が単なるコンセプトではなく、本番導入を前提としていることがわかる。2027年のCQRS立ち上げという節目に向けて、CAやCTログの運営者、ウェブサーバーの管理者などは、今のうちから移行の準備を進めていく必要がある。
