耐量子の鍵交換は、CDNの画面が無くても確かめられる ── Cloudflareが見える化した項目を、自社サイトの接続で確認する14項目（2026年10月時点）

01 何が起きたか — Cloudflareは2026年9月29日、接続ごとの鍵交換の方式を、分析画面とログで見えるようにした

発表の中身

Cloudflareのブログに、2026年9月29日の日付で、「Is your domain using post-quantum encryption? Now you can see for yourself」（訳: あなたのドメインは耐量子暗号を使っているか？ 自分で確かめられるようになった）という記事が載っている。著者はAndrew Depke、Sophie Park、Sharon Goldbergの3人である。2026年10月6日に、この記事を開いて読んだ。見える場所を述べた1文は、次のとおりである。

"You can now inspect and graph the adoption of post-quantum TLS 1.3 encryption for live traffic from directly within Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard."

（訳: 実際の通信について、耐量子のTLS 1.3の暗号がどれだけ使われているかを、Logpush、Log Explorer、HTTP Traffic Analyticsのダッシュボードの中で、そのまま調べて、グラフにできるようになった。）

ここでいう「鍵交換」は、HTTPSの接続を始めるときに、ブラウザとサーバーが、通信の暗号に使う鍵を取り決める手順のことである。記事は、その手順で選ばれた方式を、接続ごとに記録して見せるようにした、と説明している。

見える場所と、項目の名前

記事が挙げる場所は3つある。1つ目は、Cloudflareのダッシュボードの「Analytics」にある「HTTP Traffic」で、鍵交換のグループ専用のカードが加わった。2つ目は、ログの項目である。

"You can enable the new ClientTLSKeyExchangeGroup field, under the TLS category in the HTTP Requests dataset, to gain visibility into individual post-quantum key exchange in your Log Explorer and Logpush connection logs."

（訳: 新しいClientTLSKeyExchangeGroupの項目を、HTTP RequestsのデータセットのTLSの区分で有効にすると、Log ExplorerとLogpushの接続ログで、個々の耐量子の鍵交換が見えるようになる。）

3つ目は、CloudflareからオリジンのサーバーへのつなぎのためのOriginTLSKeyExchangeGroupである。記事は、この値は同じドメインへのすべての来訪で同じになるので、ダッシュボードのカードには出ない、と書いている。

Radarの2つの数字は、全体の集計である

記事は、Cloudflare全体の集計として、Cloudflare Radarの数字を挙げている。

"From Radar we can see that about 70% of browser-generated traffic hitting Cloudflare's network (on the visitor-to-Cloudflare connection) is protected with post-quantum encryption using hybrid ML-KEM (FIPS 203)."

（訳: Radarから、Cloudflareのネットワークに届くブラウザ由来の通信（訪問者からCloudflareへの接続）の約70%が、ハイブリッドのML-KEM（FIPS 203）による耐量子暗号で守られていることが分かる。）

"Meanwhile, we can see that today, just about 15% of origins that Cloudflare connects to use hybrid ML-KEM."

（訳: 一方、Cloudflareが接続するオリジンのうち、今日、ハイブリッドのML-KEMを使っているのは約15%にとどまる。）

記事は、この2つを、全体の合計だと断っている。自社サイトの割合は、この数字から分からない。それを自分で見られるようにしたのが、今回の変更である。

同じ時期のChrome 155ベータは、別の話

2026年9月16日付のChrome 155のベータの記事には、耐量子の暗号の名前が出てくる項目がある。

"Add support for multiple post-quantum cryptographic algorithms standardized by NIST to the Web Cryptography API:"

（訳: NISTが標準化した複数の耐量子の暗号方式を、Web Cryptography APIに加える。）

続けて、ML-KEM（768、1024）、ML-DSA（44、65、87）、ChaCha20-Poly1305、X-Wingの名前が並んでいる。これは、ウェブページのJavaScriptから使える暗号のAPIの話である。サイトへの接続の鍵交換とは別なので、この記事では混ぜない。Chrome Platform Statusの155のページは、安定版を2026年10月6日の予定と表示している。

02 なぜ・背景 — 今の通信を、将来の計算機から守るために、鍵交換から先に置き換えている

「今のうちに」置き換える理由

記事は、鍵交換を先に置き換える理由を、次のように書いている。

"Post-quantum encryption is needed right now to stop harvest-now-decrypt-later attacks, where an adversary harvests data today and then decrypts it in the future once powerful quantum computers come online."

（訳: 耐量子暗号は、「今集めて、あとで解く」攻撃を止めるために、今すぐ必要である。この攻撃では、攻撃者が今日データを集め、強力な量子計算機が使えるようになった将来に、それを解読する。）

記事は、解読されても価値が残るデータを持つ分野として、公共、防衛、金融、通信、医療などを挙げ、そうした組織は、通信の耐量子化をすぐ考えるべきだと書いている。

期限の目安

記事は、Cloudflareが2029年に完全な耐量子を目指し、2024年にNISTが、RSAと楕円曲線暗号を2030年までに廃止すべきだと述べたと書いている。後者は記事の記述で、筆者はNISTの文書を確かめていない。

標準化の経過

• 2024年8月13日：NISTが、ML-KEMの標準FIPS 203を確定した（NISTのページの公開日）。
• 2025年4月8日：OpenSSL 3.5が公開され、新機能の1つに、ML-KEM・ML-DSA・SLH-DSAの対応が挙がった（OpenSSLの告知）。
• 2026年8月：IETFが、TLS 1.3の耐量子のハイブリッドの鍵交換を、RFC 10024（提案標準）として公開した（IETFのページ）。

RFC 10024の要旨は、次のとおりである。

"This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange."

（訳: この文書は、TLS 1.3のための3つのハイブリッドの鍵合意の方式（X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024）を定める。いずれも、耐量子のML-KEMと、ECDHEの交換を組み合わせる。）

鍵交換のグループの一覧

RFC 10024は、IANAの登録として、次の番号とRecommendedの欄を書いている。

Cloudflareの記事も、X25519MLKEM768を耐量子暗号として唯一の推奨と書き、ほとんどの主要なブラウザが優先すると書いている。

03 用語 — 鍵交換のグループ、ハイブリッド、攻撃の名前を分けて読む

鍵交換のグループ

ハイブリッド

「今集めて、あとで解く」攻撃

ML-KEMとML-DSA

04 型別 — 自社の接続がどの型で、何を、どの順で確かめるか

🅰 自社のサイトは、どの型か

見える場所は、サイトの前に何があるかで決まる。次の4つのうち、当てはまるものを選ぶ。

• Cloudflareの背後にあるサイト：画面とログで、全体の割合を見る（手順5・6）。
• ほかのCDNの背後にあるサイト：同じ項目があるかは、各社の文書で確かめる。筆者は、他社の画面を確かめていない。
• CDNがなく、自社のサーバーで直接TLSを終えるサイト：ブラウザで確かめる（手順2・3）。
• レンタルサーバーなど、提供元に任せているサイト：提供元の案内で、TLSの設定を変えられるかを確かめる。

🅱 公式文書が書いていないこと

次のことは、確かめた範囲の公式文書には書かれていない。この記事も、断定しない。

• Cloudflare以外のCDNが、同じ種類の項目を出すか。
• ウェブサーバーのアクセスログに、鍵交換の名前を残す標準の設定があるか。
• 耐量子の鍵交換が、検索の順位や表示の速さに影響するか。

この記事が確かめていないこと

筆者は、Cloudflareの分析画面とログの項目を、実際に開いていない。当サイトが、Cloudflareの背後にないためである。当サイトのサーバーの設定ファイルも読んでいない。書いたのは、Cloudflareの記事の記載と、手元から接続して確かめた内容である。

🅲 手順1 — CDNの背後にあるかを確かめる

自社のトップページの応答ヘッダーを取得し、Serverの行と、CF-RAYの行があるかを見る。curl -I https://自社のドメイン/で取れる。一般に、Cloudflareを通った応答には、CF-RAYが付く。ヘッダーは設定で変わりうるので、ネームサーバーもnslookup -type=NS 自社のドメインで並べて見る。取れた画面が目当てかは、題名で先に確かめる（外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた）。

🅲 手順2 — ブラウザで、鍵交換の名前を見る

Chromeの開発者ツールを開き、「Privacy and security」パネルの「Security」で、接続の詳細を開く。Chromeの公式の案内は、セキュリティの項目のエントリをクリックすると、接続と証明書の情報が見られると書いている（Privacy and security panel・最終更新2025年2月27日）。Cloudflareの記事も、Chromeで、右クリックの「検証」から「Security」のタブを見る方法を書いている。名前がX25519MLKEM768なら、耐量子のハイブリッドである。X25519やP-256なら、古典の楕円曲線の鍵交換で、記事はこれを「classical ECDHE」と呼んでいる。

🅲 手順3 — TLS 1.3で接続できているかを見る

耐量子の鍵交換は、TLS 1.3の話である。Cloudflareの記事は、次のように書いている。

"post-quantum encryption is not available in TLS 1.2 or any earlier version of TLS."

（訳: 耐量子暗号は、TLS 1.2と、それより前のどの版のTLSでも使えない。）

記事は、X25519MLKEM768が1件も見つからないドメインについて、TLS 1.3が有効かを確かめるよう勧めている。Cloudflareでは、ドメインの「SSL/TLS」の「Edge Certificates」にTLS 1.3のスイッチがあり、次の1文が添えられている。

"There is no separate post-quantum setting: when TLS 1.3 is enabled and a visitor supports X25519MLKEM768, Cloudflare negotiates it automatically."

（訳: 耐量子のための別の設定はない。TLS 1.3が有効で、訪問者がX25519MLKEM768に対応していれば、Cloudflareが自動でそれを選ぶ。）

🅲 手順4 — 手元のopensslの版と、-groupsを確かめる

opensslのs_clientには、使うグループを指定する-groupsのオプションがある（OpenSSL 3.5のs_clientの案内）。ただし、ML-KEMに対応したのは3.5からで、手元の版が古いと、グループを設定できない。openssl versionで、版を見る。OpenSSLの告知は、古いほうの長期サポート版について、次のように書いている。

"The previous LTS (OpenSSL 3.0) will continue to be fully supported until September 7, 2025, and receive security fixes until September 7, 2026."

（訳: 前の長期サポート版（OpenSSL 3.0）は、2025年9月7日まで完全にサポートされ、2026年9月7日まで、セキュリティの修正を受け取る。）

2026年10月6日の時点で、この日付は過ぎている。ただし、配布元が独自に修正を取り込む場合があり、期限が過ぎたことと、そのサーバーが危険なことは同じ意味ではない。サーバーの版は、提供元の案内で確かめる。

🅲 手順5 — CDNの画面とログで、割合を見る

Cloudflareを使っているなら、ダッシュボードの「Analytics」の「HTTP Traffic」を開き、鍵交換のグループのカードを見る。鍵交換のグループは絞り込みの条件にもなり、X25519MLKEM768を使っていない通信だけを見られる。ログで1件ずつ見るなら、ClientTLSKeyExchangeGroupを有効にする。CloudflareからオリジンへのつなぎはOriginTLSKeyExchangeGroupで見る。古いオリジンのサーバーには、Cloudflare Tunnelの後ろに置く方法を挙げている。ログの保存や費用は、CloudflareのLogpushが、Free・Pro・Businessでも従量課金で使えるようになった ── 自社サイトのアクセスの記録が手元に残る形かを確認する13項目（2026年10月時点）で扱った。

🅲 手順6 — 割合の読み方を決める

記事が見せたテスト用ドメインの例では、ほとんどの来訪はX25519MLKEM768で、一部はX25519かP-256だった。「None」は、TLS 1.2以下のRSAの鍵交換か、TLSを使わない接続である。割合が古典に偏っているときは、来訪の多くが、ブラウザ以外のクライアントで、X25519MLKEM768かTLS 1.3に対応していないことが原因かもしれない、と記事は書いている。ボットが多いサイトでは、この点が効く。人とボットの割合はボットが世界の57%を占めた日 — AIクローラー時代のアクセスログ、WEBディレクターが今知るべき数字、条件のそろっていない数字を並べた失敗は同じ条件で測っていなかった ── robots.txtは「24時間キャッシュ」のはずが、測ったら1日13.9件と152.3件。3サイトの数字を並べる前に確認すべきだったことに書いた。Radarの約70%と自社の割合を並べる前に、条件を確かめる。

🅲 手順7 — 答えの一文を、測った条件つきで書く

取引先や顧客に、「このサイトは耐量子の暗号に対応していますか」と聞かれたときの答えは、測った日、ブラウザと版、TLSの版、鍵交換の名前を添えて書く。例を挙げる。2026年10月6日に、Chrome 154で、自社のトップページを開き、TLS 1.3とX25519MLKEM768を確認した。ほかのブラウザでは確認していない。

05 自分のサイトで確認するチェックリスト

下の14項目は、1項目5分ほどでできる作業である。項目1〜3が手順1、項目4〜6が手順2と3、項目7〜9が手順4、項目10〜13が手順5と6、項目14が手順7に対応している。サイトの前にCDNがないときは、項目10〜13を「該当なし」と書いて飛ばす。担当するサイトがまだ無い人も、項目4・5・7は、今日から使える。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• 自社のトップページの応答ヘッダーを取得し、Serverの行とCF-RAYの行があるかを、それぞれ「ある」か「ない」で書く
• 自社のドメインのネームサーバーを調べ、提供元の名前を1つ書く
• 担当しているサイトのうち、CDNの背後にあるものの本数を数えて書く
• Chromeで自社のトップページを開き、開発者ツールの接続の詳細から、TLSの版を書く
• 項目4と同じ画面で、鍵交換の名前を書き、X25519MLKEM768かどうかを「はい」か「いいえ」で書く
• 項目5を確かめたChromeの版の番号と、確かめた日を、項目5の隣に書く
• 手元のopensslで版を表示し、3.5以上かどうかを「はい」か「いいえ」で書く
• 項目7が「はい」なら、s_clientに-groupsを付けて自社に接続した結果を書き、「いいえ」なら「測れなかった」と書く
• サーバーを預けている提供元の案内ページで、TLSの設定やOpenSSLの版の記載を探し、見つかったかを「ある」か「ない」で書く
• Cloudflareを使っているサイトで、HTTP Trafficの鍵交換のグループのカードを開き、X25519MLKEM768の割合を書く
• 項目10のカードで、X25519MLKEM768以外のグループを、割合の多い順に2つ書く
• ログを使っているなら、ClientTLSKeyExchangeGroupの項目を有効にして、直近1件の値を書き、使っていなければ「使っていない」と書く
• OriginTLSKeyExchangeGroupの値を1件見て、オリジン側の鍵交換の名前を書き、見られなければ「見られない」と書く
• 取引先に渡す答えの一文を、測った日、ブラウザと版、TLSの版、鍵交換の名前を入れて、1つ書く

チェックリストの使い方

時間が限られているときは、項目1・5・6・14の4つだけでも、「CDNの背後か」「どの鍵交換で守られているか」「いつ・どの版で測ったか」「どう答えるか」が分かる。項目5は、CDNを使っていなくても、ブラウザだけで確かめられる。

06 代替・他の選択肢 — 鍵交換を確かめる方法は、5つある

確かめ方を、5つ比べる

"But post-quantum encryption is only the first part of the story; the second part is post-quantum authentication."

（訳: しかし、耐量子の暗号は、話の前半にすぎない。後半は、耐量子の認証である。）

Chrome 155のWeb Cryptoは、サイトの暗号化とは別である

Chrome 155のベータで加わるML-KEMとML-DSAは、ページのJavaScriptが使う暗号のAPIである。仕様は、Modern Algorithms in the Web Cryptography APIのドラフトにあり、2026年9月14日付だった。サイトへの接続の鍵交換は、サーバーとブラウザの間のTLSで決まるので、このAPIを使っても、接続の鍵交換は変わらない。

外からの点検に使える、当サイトのツール

外から自社のサイトを点検するツールとして、当サイトの無料ツール🔧 WEBサイトの 外からできるセキュリティ対策監査ツール（要ログイン）と、🔧 WEBサイト総合分析・レポートツールがある。どちらも、鍵交換のグループを表示するかは、筆者は確かめていない。

07 当サイトで確かめたこと

当サイトは、Cloudflareの背後にない

2026年10月6日に、当サイトのトップページの応答ヘッダーを取得した。応答は200で、Serverの行はApacheだった。CF-RAYの行は付いていなかった。ドメインのネームサーバーは、ns-a1・ns-a2・ns-a3のConoHaのものだった。当サイトは、Cloudflareの画面とログの項目を、使えない。

手元のopensslでは、測れなかった

手元のopensslは、OpenSSL 3.2.3だった。-groups X25519MLKEM768を付けて当サイトに接続しようとすると、「group 'X25519MLKEM768' cannot be set」（訳: グループX25519MLKEM768は設定できない）と出て、接続できなかった。この手順では、測れなかった。

Chrome 154で、鍵交換の名前を読んだ

手元のChrome（154.0.8037.97・Windows）を画面なしで起動し、開発者ツールの通信の記録から、接続の詳細（securityDetails）を読んだ。画面を操作して見たのではなく、プログラムから読んだ。

読み方が合っているかを確かめるため、比べる相手を2つ置いた。耐量子に対応していると記事が説明するCloudflareのトップページは、X25519MLKEM768と読めた。耐量子に対応しないOpenSSL 3.0.16で動かした手元のテスト用サーバーは、X25519と読めた。この読み方は、2つを区別できた。そのうえで、当サイトは、CDNを通さずに、直接X25519MLKEM768で接続された。

TLS 1.2までに限ると、古典の鍵交換だった

Node.js 24.5.0で、TLSの版を1.2までに限って当サイトに接続すると、TLS 1.2で成立し、鍵交換はX25519だった。Cloudflareの記事が書く、TLS 1.2以前では耐量子暗号が使えないという説明と、向きが合っている。

測れなかったこと・やっていないこと

• 当サイトのサーバーで、鍵交換を担当するソフトとその版は、確かめていない。サーバーの設定ファイルは読んでいない。
• 測ったのは、Windowsの手元のChromeの1台と、Node.jsの1台である。Edge・Firefox・Safari、スマートフォンのブラウザでは、測っていない。
• 1回ずつの接続である。来訪全体の割合は、集計していない。Chrome 155のベータでも、測っていない。

08 このテーマの、これまで

耐量子の鍵交換をめぐる、日付つきの記録

2024年のFIPS 203、2025年のOpenSSL 3.5、2026年8月のRFC 10024は、02章に書いた。それ以降の動きは、次のとおりである。

• 2026年9月14日：Web Cryptography APIの新しい方式のドラフトが、この日付で公開されていた。
• 2026年9月16日：Chrome 155がベータになり、Web CryptoにML-KEMとML-DSAが加わった。
• 2026年9月29日：Cloudflareが、鍵交換のグループを、分析画面とログに加えた。
• 2026年10月6日：Chrome 155の安定版の予定日。この記事のために、公式のページを取得し、手元のChromeで接続を確かめた。

この一覧に、自社のサイトの結果は入っていない。

当サイトの、関連する過去の記事

• ボットが世界の57%を占めた日 — AIクローラー時代のアクセスログ、WEBディレクターが今知るべき数字 — アクセスのうち、ボットが占める割合を、ログで数えた記録。
• 同じ条件で測っていなかった ── robots.txtは「24時間キャッシュ」のはずが、測ったら1日13.9件と152.3件。3サイトの数字を並べる前に確認すべきだったこと — 3つのサイトの数字を、同じ条件でそろえずに並べた失敗の記録。
• AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた — HTTPのログだけを見ていて、数を大きく取り違えた記録。
• 「測定中」と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた — 「測定中」と書いたまま、測らなかった記録。
• 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面が、目当ての画面とは限らなかった記録。