1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@keitah(檜垣 慶太)

量子コンピュータが来る前に、エンジニアが今やること — 耐量子暗号（PQC）移行のいま、ぜんぶ解説

1
Posted at

はじめに

こんにちは、@keitah0322 です。

普段は Sysdig で Cloud Native Security / Runtime Security 周りを見ていて、TLS・証明書・コード署名といった「暗号が前提になっている仕組み」を毎日のように眺めています。

その中で、ここ 1〜2年で急に話題として出てくる回数が増えたのが 耐量子暗号（PQC: Post-Quantum Cryptography） です。ただ、この話題は「量子コンピュータ」という単語のインパクトが強すぎて、議論が噛み合っていないことがとても多い。

「量子コンピュータで暗号が全部破られる」→ 半分だけ正しい
「実用化は 2040年でしょ、今の話じゃない」→ 予測は正しいが、結論が間違っている
「うちは AES-256 使ってるから大丈夫」→ 論点がずれている

どれも「なんとなく聞いたことがある」のに、なぜそうなのかを説明できる人は少ない。そして厄介なのは、この 3つの誤解のどれを持っていても、やるべき対策の優先順位を間違えることです。

そこで、公開情報（NIST・EU・各社のブログ・論文）だけを使って、「今、何が起こっているのか」を仕組みのレベルから丁寧に整理してみました。そのうえで「じゃあエンジニアは明日から何をするのか」まで落とすのがこの記事のゴールです。

特定の製品の話は出てきません。数値・日付は執筆時点（2026年7月）のもので、この領域は動きが速いので、実際に判断に使うときは一次情報で最終確認してください。

この記事の読み方

長いので、目的別に入り口を書いておきます。

あなたの状況 どこから読むか
全体像を 3分で知りたい TL;DR だけ読んで、気になった項目から本文へ
「今なぜ騒がれているのか」を知りたい 第1部（今、何が起こっているのか）
「なぜ暗号が壊れるのか」を理解したい 第2部（仕組みの解説）。数式は使いません
上司・顧客に説明する材料が欲しい 第3部（SNDL）と 第6部（規制とタイムライン）
とにかく手を動かしたい 第7部（ハンズオン）。コピペで動きます
移行計画を書く役回りになった 第8部（移行計画の作り方）
用語が分からなくなった 末尾の 用語集

TL;DR

何が起こるのか

  • 壊れるのは公開鍵暗号（RSA / ECDSA / DH 系）。Shor のアルゴリズムで現実的な時間で解かれる。AES や SHA-2/3 は鍵長が足りていれば実用上セーフ。つまり問題の中心は「暗号化そのもの」ではなく 鍵交換と署名です。
  • 鍵長を増やして粘る、という逃げ道がない。RSA と楕円曲線暗号は、破られ方の構造そのものが変わるので、パラメータ調整では対処できません。アルゴリズムの入れ替えしかない。

なぜ今なのか

  • Store Now, Decrypt Later（今記録して、後で解読）。攻撃者が量子コンピュータを持っていない今日でも、今流れている TLS 通信が将来のリスクになる。今日守らなかった通信は、後から取り返せません。
  • 必要な量子コンピュータの規模の見積もりが、下がり続けている。 2019年の「2,000万量子ビット」が、2025年には「100万量子ビット未満」に。防御側にとっては悪いニュースです。

どこまで進んでいるのか

  • NIST は 2024年8月に FIPS 203 (ML-KEM) / 204 (ML-DSA) / 205 (SLH-DSA) を確定済み。もう「標準がないから待つ」フェーズではありません。
  • 鍵交換の移行はすでに実戦投入済み。 Chrome / Firefox / Cloudflare / OpenSSH / Signal / iMessage で、ハイブリッド方式が本番デフォルトで動いています。あなたが今日開いたサイトの一部は、もう耐量子な鍵交換で通信しています。
  • 一方で署名の移行はほぼ手つかず。署名サイズが既存の証明書インフラに載らないという未解決問題が残っています。

期限

  • 米 NSM-10 は 2035年、NIST IR 8547 は RSA/ECC を 2030年に非推奨・2035年に禁止の方向。EU ロードマップは 2026年末に移行開始 / 2030年末に重要インフラ完了 / 2035年末に可能な範囲で完全移行。
  • 最も準備が進んでいる Google / Cloudflare が 2029年完了を掲げている。これがそのまま「移行には 6〜7年かかる」という相場観です。

明日やること

  • 新しい暗号を実装することではなく、暗号インベントリを作ること。「どこで何の暗号を使っているか」を書き出せない組織は、移行計画も立てられません。
  • 新しく書くコードには 暗号アジリティ（アルゴリズムを差し替えられる構造）を入れる。次の移行は必ず来ます。

第1部：今、何が起こっているのか

まず「なぜ今この話題が急に増えたのか」から始めます。ここを押さえると、残りの話が全部つながります。

1-1. 2024年8月：号砲が鳴った

長いあいだ、この分野には便利な言い訳がありました。**「標準がまだ決まっていないから待つ」**です。実際これは正当な理由でした。標準化前のアルゴリズムを本番に入れると、後で仕様が変わって作り直しになる。実際に Kyber は標準化の過程で仕様が変わり、先行実装は入れ替えを余儀なくされています。

その言い訳が 2024年8月13日に消えました。 NIST が 3つの標準を確定させたからです。

2016年  NIST が公募開始（世界中から82件の応募）
  ↓     4ラウンドの選考・攻撃・脱落（実際に何本も破られた）
2022年  第1弾の選定発表（Kyber, Dilithium, SPHINCS+, FALCON）
  ↓     ドラフト公開 → パブリックコメント → 仕様確定
2024年8月13日  FIPS 203 / 204 / 205 確定 ★ここが号砲
  ↓
2025年3月  HQC を追加選定（格子以外のバックアップ）
2026年〜  各国の規制が「開始せよ」のフェーズへ

ここから起きたことは、規制側の一斉の動きです。標準が確定したので、規制文書に具体的なアルゴリズム名と年号を書けるようになった。これが 2024年後半〜2025年に各国のロードマップが一気に出てきた理由です。

つまり 2024年8月を境に、この話は「研究の話」から「移行プロジェクトの話」に変わりました。 今議論されているのは「どのアルゴリズムが安全か」ではなく、「誰がいつまでに何を入れ替えるか」です。

1-2. 2025年：見積もりが縮み、実装が入った

2025年に起きたことは 2つあります。両方とも重要です。

① 「必要な量子コンピュータの規模」の見積もりが大幅に下がった

これが個人的に一番インパクトのある変化だと思っています。

「RSA-2048 を破るには、どれくらいの量子コンピュータが必要か」という見積もりは、研究者が定期的に更新しています。その推移がこれです。

年 見積もり 所要時間
2019年（Gidney & Ekerå） 物理量子ビット 2,000万 8時間
2025年（Gidney） 物理量子ビット 100万未満 1週間未満

6年で約 20分の 1 になりました。

これは量子コンピュータのハードウェアが進歩したからではなく、アルゴリズムと誤り訂正の効率化が進んだからです。つまり、ハードウェアの進歩とは独立に、必要な規模のハードルが下がり続けている。

防御側にとってこれは悪い知らせです。「CRQC の登場は 2045年」という予測を立てても、その予測の前提になっている「必要な量子ビット数」が翌年に半分になる可能性がある。予測の不確実性が、楽観側だけでなく悲観側にも開いているということです。

② 主要なライブラリと OS に PQC が「入った」

2025年は、実装が一気に降りてきた年でもありました。

  • OpenSSL 3.5（2025年4月）— ML-KEM / ML-DSA / SLH-DSA をネイティブサポート。これが効いたのは、世界中の膨大な数のソフトウェアが OpenSSL 経由で暗号を使っているからです。ここに入ると、以降は「OpenSSL を上げれば使える」状態になる。
  • Go 1.24 — crypto/mlkem が標準ライブラリに。crypto/tls はハイブリッド鍵交換をデフォルト有効化。
  • OpenSSH 10.x — PQ ハイブリッド鍵交換をデフォルト側に。
  • Java (JDK 24) — ML-KEM / ML-DSA が標準 API に。

「ライブラリが対応していないから待つ」という言い訳も、これでほぼ消えました。

1-3. すでに静かに始まっている

ここが一番びっくりするところだと思うので、強調しておきます。

あなたが今日ブラウザで開いたサイトの一部は、すでに耐量子な鍵交換で通信しています。

以下は、すでに本番のデフォルトで動いているものです（実験や opt-in ではなく、デフォルトです）。

プロダクト 何が入ったか 時期
Signal PQXDH（鍵合意にPQCを追加） 2023年
Chrome TLS でハイブリッド鍵交換をデフォルト有効 2024年
Apple iMessage PQ3（PQC ベースのプロトコルへ移行） 2024年
Firefox TLS でハイブリッド鍵交換に対応 2024年
Cloudflare 全ゾーンでハイブリッド鍵交換を受け入れ 2023年〜
OpenSSH ハイブリッド鍵交換がデフォルト 2022年〜（PQC標準版は2025年〜）

つまり、鍵交換の移行は「これから始まる」ものではなく、「もう終盤に入っている」。あなたのブラウザは、あなたが何もしなくても、すでに移行を済ませています。

これは第7部で実際にコマンドを叩いて確認できます。個人的に、この事実を知ったときに「遠い未来の話」という感覚が一気に消えました。

1-4. じゃあ何が残っているのか

では移行はほぼ終わりなのか。まったく違います。終わったのは一番簡単なところだけです。

なぜこう分かれたのか。理由は明確で、**鍵交換は「両端のソフトウェアを更新すれば済む」のに対し、署名は「エコシステム全体の合意が必要」**だからです。

鍵交換は、クライアントとサーバが「じゃあ ML-KEM 使いましょうか」と合意すれば、その場で完結します。第三者は関係ありません。だから Chrome と Cloudflare がそれぞれ実装すれば、それだけで動きます。

署名はそうはいきません。証明書に ML-DSA で署名するには、認証局（CA）が対応し、ブラウザがその署名を検証できるようになり、Certificate Transparency のログが受け入れ、中間機器が通し、そしてサイズが増えたぶんのパフォーマンス劣化を全員が受け入れる必要があります。関係者が多すぎるのです。

そして、そのサイズの問題が実際に未解決です（第5部で詳しく)。

ここまでのまとめ

  • 2024年8月 に NIST 標準が確定し、この話題は「研究」から「移行プロジェクト」に変わった
  • 必要な量子コンピュータの規模の見積もりは下がり続けている（6年で約1/20）
  • 鍵交換の移行はもう終盤。あなたのブラウザはすでに対応済み
  • 署名の移行はほぼ手つかずで、技術的に未解決の問題が残っている

第2部：なぜ壊れるのか（仕組みの解説）

ここは「そもそもなぜ量子コンピュータで暗号が破れるのか」を、数式なしで説明します。ここを理解しておくと、「AES は大丈夫なのに RSA はダメ」という一見不思議な非対称性が納得できるようになります。

急いでいる方は 2-4 の表だけ見て第3部に飛んでも大丈夫です。

2-1. そもそも公開鍵暗号は何をしているのか

まず前提の確認から。暗号には大きく 2種類あります。

共通鍵暗号（AES など） — 送る側と受け取る側が同じ鍵を持っている必要があります。速くて頑丈ですが、「じゃあその鍵をどうやって相手に渡すのか」という問題が残ります。初めて通信する相手に、安全な経路がない状態で鍵を渡せません。これを 鍵配送問題 と呼びます。

公開鍵暗号（RSA / 楕円曲線など） — この鍵配送問題を解くために発明されました。「誰でも使える公開鍵」と「本人だけが持つ秘密鍵」をペアにすることで、初対面の相手とも安全に鍵を共有できます。

公開鍵暗号は、実際には次の 2つの仕事に使われています。この区別がこの記事で一番大事なので、ここだけは覚えてください。

仕事 何をするか 使われる技術 破られると何が起きるか
鍵交換 初対面の相手と共通鍵を安全に共有する ECDH / X25519 / DH 通信の中身が読まれる（過去の通信も）
署名 相手が本物であることを証明する RSA署名 / ECDSA / EdDSA なりすまされる（偽サイト、偽アップデート）

そして重要なのは、共通鍵暗号（AES）は「鍵をどう渡すか」の部分を公開鍵暗号に依存していることです。だから「AES-256 を使っているから安全」とは言えません。AES 自体は無傷でも、その鍵を配るのに使った ECDH が破られれば、AES で守った中身は読まれます。 頑丈な金庫を用意しても、鍵の受け渡しを盗聴されていたら意味がない、ということです。

これが「AES-256 だから大丈夫」が論点をずらしている理由です。

2-2. 公開鍵暗号の安全性は「難しい計算」に乗っている

では公開鍵暗号は、何を根拠に「秘密鍵は割り出せない」と言っているのか。特定の計算が、正方向には簡単だが逆方向には絶望的に難しいという性質に乗っています。

  • RSA — 「2つの素数を掛ける」のは簡単。でも「巨大な数を素因数分解する」のは絶望的に難しい。
  • 楕円曲線（ECDSA / ECDH） — 「ある点を n 回足す」のは簡単。でも「結果から n を逆算する（離散対数問題）」のは絶望的に難しい。

「絶望的に難しい」は、古典コンピュータでは指数関数的な時間がかかる、という意味です。RSA-2048 を今のスーパーコンピュータで素因数分解しようとすると、宇宙の年齢を軽く超える時間がかかります。だから安全とされてきました。

この安全性は「数学的に絶対」ではなく、「今知られているアルゴリズムでは無理」という条件付きのものです。ここが重要なポイントです。より良いアルゴリズムが見つかれば、前提は崩れます。

2-3. Shor のアルゴリズムは何をするのか

1994年、Peter Shor が「量子コンピュータがあれば素因数分解と離散対数を効率的に解ける」ことを示しました。これが Shor のアルゴリズム です。

ここでよくある誤解を先に潰します。

❌ 誤解：「量子コンピュータは重ね合わせで全パターンを同時に試すから速い」

これは違います。全パターンを同時に計算しても、測定すればランダムな 1つが返ってくるだけで、意味がありません。量子コンピュータの本当の強みは別のところにあります。

✅ 実際：量子コンピュータは、答えの「周期性」を取り出すのが得意

Shor のアルゴリズムの核心は、素因数分解を 「周期を見つける問題」に変換することです。ざっくりした流れはこうです。

1. 素因数分解したい数 N がある
2. ある数の N による剰余を繰り返すと、必ず周期的なパターンが現れる
   （例: 2^1, 2^2, 2^3, ... を N で割った余りは、いつか繰り返しに入る）
3. その「周期」が分かると、N の素因数が計算で求まる（古典的な数論の結果）
4. 周期を見つける部分だけが古典コンピュータでは絶望的に重い
5. 量子フーリエ変換を使うと、この周期の抽出が効率的にできる ← ここが量子の出番

ポイントは、量子コンピュータが得意なのは「周期を取り出すこと」だけで、それ以外は古典計算だということ。そして偶然にも（というより悪いことに）、RSA と楕円曲線暗号の安全性は、まさにこの「周期構造を持った問題」の上に建っている。だから直撃します。

そしてこの直撃には、逃げ場がありません。

  • RSA-2048 が危ないなら RSA-4096 にすれば？ → Shor は多項式時間で解くので、鍵長を倍にしても計算量はほんの少ししか増えません。RSA-4096 も RSA-8192 も同じように破られます。
  • 楕円曲線を強いカーブに変えれば？ → 同じです。離散対数問題である限り、Shor の射程内です。

これが「鍵長を増やして粘る」が通用しない理由です。構造そのものが破られるので、別の数学的土台に引っ越すしかない。それが耐量子暗号です。

2-4. Grover のアルゴリズムはなぜ大したことないのか

一方、共通鍵暗号やハッシュ関数に対しては Grover のアルゴリズム が効きます。こちらは「総当たり探索」を高速化するもので、2^n 回の探索を 2^(n/2) 回にします。

数字で見ると派手に見えます。

  • AES-128 → 実効的に「64ビット相当」
  • AES-256 → 実効的に「128ビット相当」

「AES-128 が 64ビットになるなら大変じゃないか」と思うところですが、実務的には次の理由で、これはかなり悲観寄りの読み方とされています。

  1. Grover は並列化の効きが極端に悪い。 古典的な総当たりなら、マシンを1000台並べれば1000倍速くなります。Grover は違って、1000台並べても √1000 ≈ 32倍程度しか速くなりません。「時間をかければ解ける」を「マシンを増やして時間短縮」に変換できないのです。
  2. 必要な量子回路が長すぎる。 Grover を回しきるには、量子状態を極めて長時間維持し続ける必要があります。これは誤り訂正のコストとして跳ね返り、現実的なマシンでは非現実的な期間が必要になります。
  3. Shor と違って、鍵長で対処できる。 心配なら鍵を倍にすればいい。AES-256 なら「128ビット相当」で、これは十分すぎる安全域です。

同じことがハッシュ関数にも言えます。SHA-256 の衝突耐性や原像計算に対する量子的な優位は限定的で、出力長が十分なら追加対応は必要ありません。

つまり Shor と Grover は、影響の「質」がまったく違います。

  • Shor = 構造を突く攻撃。パラメータ調整では逃げられない → アルゴリズム入れ替えが必須
  • Grover = 総当たりの高速化。鍵長で対処できる → AES-256 / SHA-256 以上なら実質そのまま

2-5. 何が壊れて、何が壊れないのか（一覧）

以上をまとめた表がこれです。この記事で一番実用的な表だと思います。

対象 効くアルゴリズム 影響 対応
RSA 署名 / RSA 暗号 Shor 致命的 ML-DSA / SLH-DSA へ置換
ECDSA / EdDSA（署名） Shor 致命的 ML-DSA / SLH-DSA へ置換
DH / ECDH / X25519（鍵交換） Shor 致命的 ML-KEM へ置換（現状はハイブリッド）
AES-128（共通鍵） Grover 限定的 できれば AES-256 へ
AES-256（共通鍵） Grover 実用上なし そのまま
SHA-256 / SHA-3（ハッシュ） Grover 限定的 そのまま（十分な出力長）
HMAC / KDF / TOTP — ほぼなし そのまま
ChaCha20-Poly1305 Grover 実用上なし そのまま

結論：これは「暗号化が破れる」話ではなく、「相手が本物だと確認する仕組み（署名）」と「鍵を安全に共有する仕組み（鍵交換）」が破れる話です。

2-6. で、量子コンピュータは今どこまで来ているのか

仕組みが分かったところで、ハードウェアの現在地を見ておきます。ここは「新聞の見出しに騙されない」ためのセクションです。

物理量子ビットと論理量子ビットは全然違う

ニュースで「〇〇社が 1000量子ビットを達成」と聞くことがありますが、これは 物理量子ビット の数です。物理量子ビットは非常に脆く、環境のノイズですぐ壊れます。計算に使えるようにするには、たくさんの物理量子ビットを束ねて 1つの「論理量子ビット」を作り、誤りを訂正しながら動かす必要があります。

そして、その変換比率が厳しい。

論理量子ビット 1個 ≒ 物理量子ビット 1,000個以上（誤り訂正方式・品質によって変動）

RSA-2048 を Shor で破るには、おおまかに 数千個の論理量子ビット が必要とされています。掛け算すると、必要な物理量子ビットは数百万個のオーダーになります。

今のマシンは物理量子ビットで数百〜千のオーダー。桁が 3〜4つ足りません。 これが「まだ大丈夫」の実体です。

では何が進歩しているのか

ここで見るべきは量子ビットの「数」ではなく、誤り訂正が機能し始めたかどうかです。

2024年末、Google が発表した Willow というチップで、**「誤り訂正の符号を大きくすると、エラー率が下がる」**という状態（below-threshold）が示されました。これは地味ですが極めて重要な節目です。

なぜ重要か。それまでは、量子ビットを増やすとノイズも増えて、誤り訂正のコストが利得を食いつぶしていました。つまり「増やしても良くならない」。それが「増やせば良くなる」に切り替わったということです。スケールさせる意味がある段階に入った、と言い換えられます。

さらに、IBM は 2029年に誤り耐性を持つマシン（数百の論理量子ビット規模）を実現するというロードマップを公表しています。

ここで、第6部で出てくる話と符合します。Google と Cloudflare が「2029年に耐量子対応完了」を目標にしていることと、IBM が「2029年に誤り耐性マシン」を掲げていること。この一致は偶然ではないと私は読んでいますが、これは公式に説明されたものではないので、あくまで一つの見方として受け取ってください。

まとめると

  • 今日の脅威ではない。 桁が 3〜4つ足りない。パニックは不要です。
  • でも進歩の質が変わった。 「増やしても無駄」から「増やせば良くなる」へ。
  • そして必要な規模の見積もりは下がり続けている。 6年で約1/20（1-2参照）。
  • 予測は当てにならない。 だからこそ、予測に依存しない判断基準（次の第3部）が必要になります。

ここまでのまとめ

  • 公開鍵暗号の仕事は 鍵交換 と 署名 の2つ。AES はその「鍵の受け渡し」を公開鍵暗号に依存している
  • Shor は「周期を取り出す」のが得意で、RSA / 楕円曲線はまさにその構造の上にある → 鍵長では逃げられない
  • Grover は総当たりの高速化にすぎず、並列化も効かない → AES-256 / SHA-256 はそのままで良い
  • ハードウェアは桁が 3〜4つ足りないが、誤り訂正が機能し始めたという質的な変化が起きている

第3部：なぜ「今」なのか — Store Now, Decrypt Later

第2部で「まだ桁が足りない」と書きました。ではなぜ今動く必要があるのか。ここが本題です。

3-1. 「量子コンピュータまだ無いのに騒ぐな」への答え

この話題を持ち出すと、だいたい最初にこう返ってきます。

「実用的な量子コンピュータなんて 2040年でしょ。今やる話じゃない」

見立て自体は間違っていません。実際に脅威になる量子コンピュータ（CRQC: Cryptographically Relevant Quantum Computer = 暗号的に意味のある量子コンピュータ）の登場時期は諸説あり、早い予測で 2030年ごろ、遅い予測で 2050年ごろまで散らばっています。誰も確定的なことは言えません。

それでも今動く必要がある理由は、Mosca の不等式として知られる、とても素朴な引き算で説明できます。

X（守りたいデータの秘密保持期間） + Y（移行に必要な期間） > Z（CRQC が登場するまでの期間）
        ↑ この不等式が成り立ってしまう時点で、すでに手遅れ

言葉にするとこうです。「移行を終える前に CRQC が来てしまうなら、それまでに流したデータは守れない」。

たとえば、こう当てはめてみます。

変数 例 値
X 医療記録・契約・個人情報を秘密に保ちたい年数 20年
Y 全社の暗号を棚卸しして入れ替えるのに要する年数 7年
Z CRQC 登場までの年数（仮に楽観側で） 15年

20 + 7 = 27 > 15。すでに間に合っていません。

ここが Mosca の不等式の賢いところです。Z（いつ来るか）を当てる必要がない。 X と Y が十分に大きければ、Z が 2040年でも 2050年でも、結論は「今始めろ」になります。逆に X が数か月しかないデータ（例：明日の会議のリンク）なら、慌てる必要はありません。

つまりこれは「量子コンピュータがいつ来るか」の予測ゲームではなく、自分の X と Y を測る作業です。そして多くの組織は、そもそも X も Y も測ったことがありません。まずやるべきなのは、この 2つを測ることです。

3-2. Store Now, Decrypt Later とは何か

X が効いてくる具体的な攻撃シナリオが SNDL（Store Now, Decrypt Later / HNDL: Harvest Now, Decrypt Later とも呼ばれます）です。

流れを言葉で追うと、こうです。

  1. 攻撃者は今日、TLS で暗号化された通信を丸ごと記録する。中身は読めないが、それでいい。
  2. 記録にはハンドシェイクも含まれる。ここに ECDH の公開鍵が平文で入っている。
  3. ひたすら保存する。ストレージは安い。ペタバイト級でも国家予算なら誤差です。
  4. 数年〜数十年後、CRQC が手に入る。
  5. 保存したハンドシェイクから ECDH の秘密鍵を Shor で復元。
  6. 復元した鍵で AES セッション鍵を導出し、保存した通信をまとめて平文化。

ポイントは、攻撃者が今日この瞬間に量子コンピュータを持っている必要がないことです。必要なのはストレージだけ。国家レベルのアクターがバックボーンのトラフィックを収集・保管しているという前提は、業界では現実的なものとして扱われています。

そして残酷なのは、この攻撃には後追いの対策が存在しないことです。今日の通信を今日守らなければ、それはもう終わりです。来年 PQC を導入しても、今年流した通信は救えません。「後で直す」が原理的にできない、珍しい種類のセキュリティ課題です。

3-3. 鍵交換と署名で、緊急度が違う

SNDL からは、実務上とても重要な帰結が 2つ出ます。

帰結①：鍵交換の移行は「今」の話。
SNDL でやられるのは「過去の通信の機密性」、つまり鍵交換です。今日守らなかった分は取り返せないので、猶予がゼロです。だから業界はまずここに手を打った(第1部)。

帰結②：署名の危機は CRQC 登場と同時。ただし準備に一番時間がかかる。
偽の証明書やコード署名を作る攻撃は「リアルタイム」でしか成立しません。CRQC が存在しない今日、誰もあなたのサイトの偽証明書を作れない。だから緊急度は鍵交換より低い。

……ですが、準備に一番時間がかかるのも署名です。エコシステム全体の合意が必要で、技術的にも未解決（第5部）。しかもファームウェア署名のように「出荷したら鍵を替えられない」ものは、今日の設計判断が 10年先を縛ります。

整理するとこうなります。

鍵交換 署名
危機が来るタイミング すでに来ている（SNDL） CRQC 登場と同時
後追い対策 不可能 可能（間に合えば）
移行の難易度 低〜中（両端の合意で済む） 高（エコシステム全体の合意）
技術的な未解決問題 ほぼない ある（サイズ問題）
業界の進捗 終盤 ほぼ手つかず
やるべきこと 今すぐ有効化する 今から計画を立てる

この表が、この記事で伝えたいことのほぼすべてです。鍵交換は「今すぐスイッチを入れる」タスク、署名は「今から数年かけて計画を回す」タスク。 種類が違うので、同じ「PQC 対応」という言葉でまとめると計画を間違えます。

ここまでのまとめ

  • Mosca の不等式：X（秘密保持期間）+ Y（移行期間）> Z（CRQC 登場）なら手遅れ。Z を当てる必要はない
  • SNDL には後追い対策が存在しない。今日守らなかった通信は永久に救えない
  • 鍵交換＝今すぐ有効化、署名＝今から計画。 緊急度も難易度も別物

第4部：新しい暗号は何をしているのか

移行先のアルゴリズムがどういうものかを見ておきます。中身を知らなくても移行はできますが、**「なぜサイズが大きいのか」「なぜハイブリッドにするのか」**を理解するには少し役に立ちます。

4-1. 新しい土台：格子問題

Shor が突くのは「周期構造を持つ問題」でした。したがって耐量子暗号に求められるのは、周期構造を持たない、別の難しい問題です。

本命として選ばれたのが 格子（lattice）問題 です。その中核にある LWE（Learning With Errors） を、雰囲気だけ説明します。

中学校で習った連立方程式を思い出してください。

3x + 5y +  2z = 24
 x + 7y +  4z = 31
6x + 2y + 11z = 47

これは簡単に解けます。ではこうだったらどうでしょう。

3x + 5y +  2z ≈ 24  （±ちょっとのノイズ）
 x + 7y +  4z ≈ 31  （±ちょっとのノイズ）
6x + 2y + 11z ≈ 47  （±ちょっとのノイズ）

各式の右辺に、小さなランダムなノイズが混ぜてある。 これだけで、問題の性質が激変します。ノイズがあると通常の消去法が使えず、候補が爆発的に広がる。次元を数百に増やすと、古典コンピュータでも量子コンピュータでも効率的な解法が知られていない問題になります。

これが LWE です。ML-KEM と ML-DSA は、この構造（正確には効率化した Module-LWE）の上に建っています。

なぜサイズが大きくなるのかも、これで分かります。安全性の根拠が「たくさんの変数を持つノイズ付き方程式系」なので、公開鍵は本質的に「その方程式系の係数」に相当するデータになります。RSA なら「巨大な数 1つ」で済んだものが、格子では「行列」になる。だから 32バイトが 1,184バイトになります。サイズの増加は実装の稚拙さではなく、安全性の根拠そのものから来ているわけです。

4-2. 標準はもう出ている — FIPS 203 / 204 / 205

NIST が 2024年8月13日に確定させた 3本立てが、移行先の本命です。

標準 アルゴリズム 旧称 用途 数学的基盤
FIPS 203 ML-KEM CRYSTALS-Kyber 鍵交換・鍵カプセル化 格子（Module-LWE）
FIPS 204 ML-DSA CRYSTALS-Dilithium 署名（第一選択） 格子（Module-LWE）
FIPS 205 SLH-DSA SPHINCS+ 署名（バックアップ） ハッシュベース

名前が変わっているので混乱しやすいですが、Kyber = ML-KEM、Dilithium = ML-DSA、SPHINCS+ = SLH-DSA と読み替えてください。古いブログ記事や実装は旧名で書かれています。

なぜ署名だけ 2本あるのか

ここには「卵を1つのカゴに盛らない」という設計思想があります。

ML-DSA と ML-KEM は、どちらも格子問題という同じ土台に乗っています。もし将来この土台に致命的な数学的欠陥が見つかったら、両方が同時に倒れます。署名も鍵交換も一気に失う、という最悪のシナリオです。

SLH-DSA は、まったく別の前提（ハッシュ関数の安全性のみ）に立つ保険です。ハッシュベースの署名は理論的な信頼度が非常に高い（前提が少ない）代わりに、署名がとても大きく、生成が遅いというトレードオフを持ちます。だから第一選択にはならないけれど、押さえておく価値がある。

同じ理由で、鍵交換側のバックアップとして格子ではない HQC（符号ベース）が 2025年3月に追加選定されています。こちらは標準化文書がまだ後追いのフェーズです。また、格子ベースで署名サイズが小さい FN-DSA（旧 FALCON）も標準化が進められています。

この「2系統を用意する」設計は、そのまま移行計画にも活きます。 自分のシステムを ML-DSA 一本に固く結びつけないほうがいい、ということです（→ 第8部の暗号アジリティ）。

4-3. サイズの現実

移行の技術的な痛みは、ほぼすべてここに由来します。表を見てください。

アルゴリズム 公開鍵 署名 / 暗号文
X25519（鍵交換） 32 B 32 B
ML-KEM-768（鍵交換） 1,184 B 1,088 B
ECDSA P-256（署名） 64 B 64 B
RSA-2048（署名） 256 B 256 B
ML-DSA-44（署名） 1,312 B 2,420 B
ML-DSA-65（署名） 1,952 B 3,309 B
ML-DSA-87（署名） 2,592 B 4,627 B
SLH-DSA-128s（署名） 32 B 7,856 B
SLH-DSA-128f（署名・高速版） 32 B 17,088 B

鍵交換の 1KB 増は、TLS ハンドシェイクなら概ね飲み込めます。だからこそ先に移行が進んだわけです。

問題は署名側で、ECDSA の 64バイトが ML-DSA-44 で 2,420バイト、約 38倍になります。SLH-DSA なら 100倍を超えます。そして署名は、証明書チェーンの中で何度も掛け算されます(第5部)。

なお、計算速度そのものは実は悪くありません。ML-KEM も ML-DSA も、多くのケースで RSA より速いくらいです（格子演算は素因数分解ベースの重い演算より軽い）。**ボトルネックは CPU ではなく、ほぼ一貫して「サイズ」**です。ここは直感に反するので覚えておくと役に立ちます。

4-4. なぜ「ハイブリッド」なのか

今の実装は、ほぼすべて ハイブリッド方式 を採用しています。TLS で使われる X25519MLKEM768 という名前が示すとおり、従来の X25519 と新しい ML-KEM-768 の両方を同時に走らせ、両方の結果を混ぜて 1つの鍵を作る方式です。

共有鍵 = KDF( X25519 の結果 ‖ ML-KEM の結果 )

こうすると、どちらか一方が安全なら、全体が安全になります。

なぜこんな二度手間をするのか。理由は 2つあります。

  1. ML-KEM はまだ歴史が浅い。 標準化されたとはいえ、RSA が受けてきた 40年以上の攻撃の試練を経ていません。実装バグや、まだ知られていない古典的な攻撃が見つかる可能性が残っています。もしそれが起きても、X25519 側が守ってくれる。
  2. X25519 は量子コンピュータに弱いが、古典的には極めて堅い。 CRQC が来るまでは、X25519 単体でも実用上安全です。

つまり 「新しい暗号が明日破られても、古い暗号が守る」「古い暗号が量子で破られても、新しい暗号が守る」 という二重の保険です。これは移行期の合理的な選択として業界の合意になっています。

コストは、公開鍵と暗号文がそれぞれ 32バイト増えるだけ。ML-KEM の 1,184バイトに対して 32バイトなので、ほぼ無料の保険です。

ここまでのまとめ

  • 新しい土台は 格子問題（LWE） = 「ノイズ入りの連立方程式」。周期構造がないので Shor が効かない
  • サイズが大きいのは安全性の根拠そのものから来ている。実装で削れる話ではない
  • 署名だけ 2本（ML-DSA / SLH-DSA）あるのは、格子が倒れたときの保険
  • 計算速度は問題ない。ボトルネックは一貫してサイズ
  • ハイブリッドはほぼ無料の二重保険。移行期の標準的な選択

第5部：TLS の中で実際に何が変わるのか

もう少し具体に降ります。「PQC 対応」と言われたとき、プロトコルの中で実際に何が起きているのかを見ます。

5-1. 鍵交換：もう動いている（そして意外と平和）

TLS 1.3 のハンドシェイクは、クライアントが最初のメッセージ（ClientHello）で自分の鍵の材料を送り込むところから始まります。

従来（X25519）

ClientHello  → key_share: X25519 公開鍵（32 B）
ServerHello  ← key_share: X25519 公開鍵（32 B）
両者が同じ共有鍵を計算 → 以降 AES で暗号化

ハイブリッド（X25519MLKEM768）

ClientHello  → key_share: X25519 公開鍵（32 B）+ ML-KEM 公開鍵（1,184 B）= 1,216 B
ServerHello  ← key_share: X25519 公開鍵（32 B）+ ML-KEM 暗号文（1,088 B）= 1,120 B
両者の結果を混ぜて共有鍵を計算 → 以降 AES で暗号化

増えるのは往復で約 2.2KB。ラウンドトリップの回数は増えません。 ここが決定的で、だから移行がスムーズに進みました。

ただし、まったく無痛ではありませんでした。ClientHello が 1パケット（約1.5KB）を超えて分割されるようになった結果、古い中間機器やファイアウォールが「見たことのない形」に驚いて接続を壊すという問題が実際に起きています。これは業界で プロトコル硬化（protocol ossification） と呼ばれる現象で、「仕様上は許されているが誰も使っていなかったパターン」が実装で潰れている、というものです。

もし自社サービスで PQC を有効にして一部のクライアントだけ繋がらなくなったら、まずこの線を疑ってください。原因はたいてい暗号ではなく、経路上の機器です。

5-2. 署名：ここが未解決

一方、署名側は構造的な壁にぶつかっています。

典型的な TLS ハンドシェイクで飛んでくるものを分解すると、署名がたくさん入っています。

中身 何が入っているか
リーフ証明書 サーバの公開鍵 + CA による署名
中間証明書 中間 CA の公開鍵 + ルート CA による署名
SCT（Certificate Transparency） ログサーバによる署名（通常 2つ以上）
CertificateVerify サーバ自身による署名
（OCSP stapling を使う場合） CA による署名

ECDSA なら、チェーン全体でだいたい 2〜4KB。これを ML-DSA に素朴に置き換えると、公開鍵と署名が各所で数KBずつ増えて、合計 10〜15KB を軽く超えます。

なぜそれが問題なのか

TCP には 初期輻輳ウィンドウ（initcwnd） という仕組みがあります。接続開始直後は、まだ経路の帯域が分からないので、サーバは控えめな量しか送りません。この初期値は一般に 10パケット ≒ 約14KB です。

つまり、

  • 証明書チェーンが 4KB → 1往復で送り終わる
  • 証明書チェーンが 15KB → 14KB を超えるので、クライアントの ACK を待ってから残りを送る＝1往復増える

1往復増えるのがどれくらい痛いか。国内サーバなら数ミリ秒〜数十ミリ秒ですが、モバイル回線や国際経路では 100ms を超えることもあります。しかも証明書は接続ごとに毎回飛ぶので、大規模サービスでは帯域コストにも直接効きます。Cloudflare や Google のようなトラフィック量の事業者にとって、これは無視できないコストです。

「動くけど遅い」は、Web の世界では「採用されない」とほぼ同義です。だからここは、力技ではなく設計で解く必要があります。

どう解こうとしているのか

いくつかのアプローチが議論されています。

  1. Merkle Tree Certificates — 一般的なケースでは署名そのものを送らず、Merkle ツリーへの包含証明で置き換える。ツリーのルートをクライアントが事前に持っていれば、証明のサイズは対数的にしか増えません。大幅な削減が期待できます。
  2. Trust anchor negotiation — クライアントが「自分はこのルート CA を持っている」と伝えることで、中間証明書の送信を省略する。
  3. Abridged certificates / 圧縮 — よく使われる中間証明書を辞書として共有し、参照だけ送る。

いずれも方向性は有望ですが、すべてまだドラフト段階で、標準化もクライアント実装も完了していません。

これが「署名の移行はまだスタートラインにいる」の正体です。そして、あなたのサービスがこの問題を自力で解くことはできません。 ブラウザ・CA・IETF の合意が必要な話なので、待つしかない領域です。

だからこそ、待っている間にできること——コード署名やファームウェア署名、社内 PKI のように自分でコントロールできる署名の棚卸しと計画——を進めるのが合理的です。

ここまでのまとめ

  • 鍵交換は ラウンドトリップが増えないので移行できた。ただし古い中間機器が壊れる問題は実在する
  • 署名は証明書チェーン全体で 10〜15KB に膨らみ、TCP 初期輻輳ウィンドウ（約14KB）を超えて 1往復増える
  • Merkle Tree Certificates などの解法はまだドラフト。自社では解けない
  • だから今は、自分でコントロールできる署名（コード署名・社内PKI）から着手する

第6部：期限は現実に引かれている

技術の話から、締切の話に移ります。ここは上司や顧客に説明するときに一番使えるセクションです。

6-1. 規制のタイムライン

「いつか対応する」で済まなくなっているのは、規制側が具体的な年を書き始めたからです。

主体 内容 期限
米 NSM-10（2022年） 政府機関の耐量子暗号移行を義務化 2035年
NIST IR 8547（移行ガイダンス） RSA / ECC を 2030年に非推奨、2035年に使用禁止の方向性 2030 / 2035年
NSA CNSA 2.0 国家安全保障システム向け。ML-KEM-1024 / ML-DSA-87 を要求。ソフトウェア・ファームウェア署名は最優先で早期移行 2030〜2033年
EU ロードマップ（2025年） 移行開始 2026年末
重要インフラの移行完了 2030年末
可能な範囲で完全移行 2035年末

いくつか読み方のコツを書いておきます。

「2035年」は終わりではなく、後ろの壁です。 NIST IR 8547 が示している 2030年の「非推奨」のほうが実務的には重要で、これは「新規システムで RSA/ECC を選ぶな」というシグナルです。今から作るシステムには、もう影響します。

CNSA 2.0 がファームウェア署名を最優先にしているのは示唆的です。 政府機関が「まずここから」と言っているものは、たいてい一番リードタイムが長いものです。デバイスを出荷したら鍵を替えられないので、設計段階でしか手を打てない。同じ理由で、あなたの組織でもファームウェア署名とルート CA が最優先候補になります。

そして民間規格が追随します。 PCI DSS、SOC 2 のような規格は、こうした政府ガイダンスを後追いする形で要件を取り込んでいくのが通例です。「監査で聞かれるようになってから考える」だと、Y（移行期間）が足りません。 監査要件になった時点で、猶予は 1〜2年しかないのが普通です。

6-2. 大手の動きから読める「相場観」

  • Google / Cloudflare — 耐量子対応の完了目標を 2029年 に設定。両社はすでにハイブリッド鍵交換を本番のデフォルトで動かしていて、この目標年は「残りの署名・内部システムまで含めた完了」を指します。
  • IBM — 移行計画を公表済み（明確な期日は示していない）。一方で、量子コンピュータ側では 2029年に誤り耐性マシンというロードマップを掲げています。

ここで注目すべきは、最も準備が進んでいる会社が「あと 6〜7年かかる」と言っていることです。

彼らは暗号の専門家を大量に抱え、自社でライブラリを書き、インフラを完全にコントロールできる立場にいます。その条件で 6〜7年。 これはそのまま Y（移行期間）の現実的な見積もりとして使えます。

自社の Y が 3年だと思っているなら、たぶん楽観しすぎです。 そして Y が長いほど、Mosca の不等式は不利になります。

6-3. 日本の状況

日本では CRYPTREC（暗号技術評価委員会）が耐量子計算機暗号に関する調査・ガイドラインを継続的に公開しており、政府機関の調達で参照される暗号リストの整備も進められています。金融分野や重要インフラ分野でも、各所管でこのテーマの検討が進んでいる状況です。

ここは制度の更新が速く、私も一次情報を追いきれていない部分があるので、具体的な要件や期限は必ず最新の一次情報で確認してください。実務的には、「グローバル基準（NIST / EU）で計画を立てておけば、国内要件はその部分集合になることが多い」と考えておくのが安全だと思います。

ここまでのまとめ

  • 実務的に重要なのは 2035年ではなく 2030年の「非推奨」。新規システムの選択に今すぐ影響する
  • 政府が最優先に挙げるのはファームウェア署名。リードタイムが最長だから
  • 最も進んでいる企業が 6〜7年。これが Y の相場観
  • 民間規格は後追いする。監査要件になってからでは間に合わない

第7部：手を動かす（ハンズオン）

ここからは実践です。全部コピペで動きます。このセクションを試すと、「遠い未来の話」という感覚が消えます。 個人的にはここが一番おすすめです。

この記事のコマンドとコードは、以下の環境で実際に動作を確認しています。
OpenSSL 3.6.3 / OpenSSH 10.2p1 / Go 1.25.4（macOS arm64）
オプション名やアルゴリズム指定の表記はバージョンで変わることがあるので、動かないときは openssl list -kem-algorithms や --help で確認してください。

7-1. 自分の通信がすでに PQC で守られているか確認する

OpenSSL で TLS の鍵交換を見る

OpenSSL 3.5 以降なら、ネゴシエートされたグループがそのまま出ます。

openssl s_client -connect cloudflare.com:443 -tls1_3 </dev/null 2>/dev/null | grep -i "group"

手元（OpenSSL 3.6.3）で実行すると、こう返ってきます。

Negotiated TLS1.3 group: X25519MLKEM768

これが出れば、その接続の鍵交換はすでに耐量子です。 設定は何もしていません。OpenSSL とサーバが勝手に合意しました。この 1行が、「もう始まっている」の一番手軽な証拠だと思います。

手元の OpenSSL のバージョンと、PQC 対応状況はこれで確認できます。

openssl version && openssl list -kem-algorithms

macOS 標準の OpenSSL は LibreSSL だったり古いバージョンだったりするので、出てこない場合は Homebrew 版を試してください。

brew install openssl@3 && /opt/homebrew/opt/openssl@3/bin/openssl version

自分のサイトが対応しているか確認する

自社サービスのドメインに向けて同じことをやると、対応状況が分かります。

openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>&1 | grep -iE "group|alert|error"

ハイブリッドを明示的に要求して、握手が成立するかを見ています。失敗する場合、サーバ側（あるいは前段の CDN / ロードバランサ）が未対応です。

ブラウザから確認する

Cloudflare が確認用のエンドポイントを公開しています。

curl https://pq.cloudflareresearch.com/

ブラウザで開いても結果が見られます。手元のブラウザがすでに PQC を使っていることを目で確認できるので、人に説明するときのデモに便利です。

SSH も見ておく

ssh -Q kex | grep -iE "mlkem|sntrup"

手元（OpenSSH 10.2p1）だとこう出ます。

sntrup761x25519-sha512
sntrup761x25519-sha512@openssh.com
mlkem768x25519-sha256

mlkem768x25519-sha256 が出れば、標準化された PQC（ML-KEM）のハイブリッドに対応しています。sntrup761x25519-sha512 は標準化前から使われている別方式（NTRU Prime）のハイブリッドで、こちらも耐量子性はあります。OpenSSH は 2022年からこの sntrup 版を default にしていたので、SSH は実は Web より先に耐量子化していました。

実際の接続でどれが使われたかを見るには、verbose で繋いでみます。

ssh -v git@github.com 2>&1 | grep -i "kex:"

7-2. ML-KEM の鍵を作ってみる

OpenSSL 3.5 以降なら、標準コマンドで PQC の鍵が作れます。まず鍵交換用の ML-KEM。

openssl genpkey -algorithm ML-KEM-768 -out mlkem768-priv.pem
openssl pkey -in mlkem768-priv.pem -pubout -out mlkem768-pub.pem
ls -l mlkem768-priv.pem mlkem768-pub.pem

X25519 と並べてサイズを比べると、体感できます。

openssl genpkey -algorithm X25519 -out x25519-priv.pem
openssl pkey -in x25519-priv.pem -pubout -out x25519-pub.pem
wc -c x25519-pub.pem mlkem768-pub.pem

7-3. ML-DSA で証明書を作って、サイズ問題を体感する

ここが一番おすすめのハンズオンです。第5部で説明した「署名サイズの壁」を、実際の数字で見られます。

まず従来の ECDSA で自己署名証明書を作ります。

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 \
  -keyout ec-key.pem -out ec-cert.pem \
  -days 365 -nodes -subj "/CN=classic-test"

次に ML-DSA-44 で同じものを作ります。

openssl req -x509 -newkey ml-dsa-44 \
  -keyout mldsa-key.pem -out mldsa-cert.pem \
  -days 365 -nodes -subj "/CN=pqc-test"

そして DER（実際にネットワークを流れる形式）に変換して、バイト数を比べます。

openssl x509 -in ec-cert.pem    -outform DER -out ec-cert.der
openssl x509 -in mldsa-cert.pem -outform DER -out mldsa-cert.der
ls -l ec-cert.der mldsa-cert.der

手元（OpenSSL 3.6.3）で実際に測った結果がこれです。

-rw-r-----  1 user  staff   381  ec-cert.der     ← ECDSA P-256
-rw-r-----  1 user  staff  3979  mldsa-cert.der  ← ML-DSA-44

証明書 1枚で 381 → 3,979 バイト、約 10.4倍。 実際の TLS ではリーフ + 中間 + SCT と積み上がるので、この差が何倍にもなります。第5部の「10〜15KB」が、ここで実感に変わると思います。

自己署名なので署名は 1つだけですが、それでもこの差です。「サイズが問題」という抽象的な話が、ls -l の数字になる瞬間が、このハンズオンの価値だと思っています。

中身も覗いてみてください。署名アルゴリズムの欄が変わっているのが見えます。

openssl x509 -in mldsa-cert.der -inform DER -noout -text | head -20

7-4. Go で ML-KEM の鍵カプセル化をやってみる

Go 1.24 以降なら、標準ライブラリだけで ML-KEM が使えます。「鍵カプセル化（KEM）」という概念が最初は掴みにくいので、動かすのが一番早いです。

package main

import (
	"crypto/mlkem"
	"fmt"
)

func main() {
	// ── 受信側（サーバ）──────────────────────────────
	// 復号鍵を生成する。ここから公開鍵（カプセル化鍵）を取り出して相手に送る。
	dk, err := mlkem.GenerateKey768()
	if err != nil {
		panic(err)
	}
	pub := dk.EncapsulationKey().Bytes()
	fmt.Printf("公開鍵サイズ: %d バイト\n", len(pub)) // 1184

	// ── 送信側（クライアント）────────────────────────
	// 受け取った公開鍵で「共有秘密」と「暗号文」を同時に生成する。
	// 共有秘密は自分の手元に残し、暗号文だけを相手に送る。
	ek, err := mlkem.NewEncapsulationKey768(pub)
	if err != nil {
		panic(err)
	}
	sharedClient, ciphertext := ek.Encapsulate()
	fmt.Printf("暗号文サイズ: %d バイト\n", len(ciphertext)) // 1088
	fmt.Printf("共有秘密サイズ: %d バイト\n", len(sharedClient)) // 32

	// ── 受信側（サーバ）──────────────────────────────
	// 暗号文を復号鍵で開くと、まったく同じ共有秘密が得られる。
	sharedServer, err := dk.Decapsulate(ciphertext)
	if err != nil {
		panic(err)
	}

	fmt.Printf("両者の共有秘密は一致するか: %v\n",
		string(sharedClient) == string(sharedServer))
}

go run main.go

ポイントは、やりとりされるのは公開鍵と暗号文だけで、32バイトの共有秘密そのものは一度もネットワークに出ていないことです。これで得た 32バイトを AES の鍵として使えば、以降は従来と同じように高速な共通鍵暗号で通信できます。これが TLS のハンドシェイクで起きていることの本質です。

ML-KEM は「鍵交換」ではなく正確には「鍵カプセル化」です。Diffie-Hellman のような対称的な鍵合意ではなく、片方が一方的に共有秘密を作って相手に届ける形になります。この違いが、既存プロトコルへの組み込みで地味に効いてきます。

7-5. Go の TLS がハイブリッドを使っているか確認する

package main

import (
	"crypto/tls"
	"fmt"
)

func main() {
	conn, err := tls.Dial("tcp", "cloudflare.com:443", &tls.Config{})
	if err != nil {
		panic(err)
	}
	defer conn.Close()

	st := conn.ConnectionState()
	fmt.Printf("TLS バージョン: 0x%04x\n", st.Version)
	fmt.Printf("暗号スイート: %s\n", tls.CipherSuiteName(st.CipherSuite))
	fmt.Printf("鍵交換に使われた曲線/グループ: %v\n", st.CurveID)
}

CurveID が 4588（0x11ec = X25519MLKEM768 のコードポイント）なら、ハイブリッド鍵交換が使われています。Go 1.24 以降なら、何も設定しなくてもこうなります。

第8部：移行計画の作り方

技術的な話は以上です。ここからは、組織として何をするかの話。実際に一番時間がかかるのはここです。

8-1. 最初の一歩は実装ではなく「暗号インベントリ」

移行計画のボトルネックは、新しいアルゴリズムの実装ではありません。「どこで何の暗号を使っているか誰も知らない」ことです。

これは大げさな話ではありません。10年以上運用されているシステムで、「TLS 証明書はどこに何枚あるか」「あのバッチが使っている RSA 鍵は誰が作ったか」「ベンダ製アプライアンスの中で何の暗号が動いているか」を即答できる組織は、ほとんどありません。

棚卸しできていないものは移行できません。 だからここが最初の一歩になります。

見落としがちなレイヤ

レイヤ 具体例 移行の難易度 なぜ
外向き TLS ALB / CDN / Ingress の証明書 低 ライブラリ・マネージドサービスの更新で追随できる
内部 mTLS サービスメッシュ、gRPC、社内 PKI 中 自前 CA の入れ替えが必要。証明書の発行フローも直す
VPN / IPsec 拠点間、リモートアクセス 中 アプライアンスのファームウェア更新待ちになりがち
保存データの鍵 KMS、HSM、エンベロープ暗号の鍵交換部分 中 HSM はファームウェア更新が必要でベンダ依存
トークン・認証 JWT の署名（RS256 / ES256）、SAML、OIDC 中 発行側と検証側の両方を同時に直す必要がある
コード署名 コンテナイメージ署名、パッケージ署名、リリース署名 高 検証側（本番環境・顧客環境）すべてを揃える必要がある
ファームウェア署名 デバイス、IoT、Secure Boot 最高 出荷後に鍵を替えられない。設計時が唯一の機会
長期保存文書 電子契約、タイムスタンプ、公文書 最高 10〜30年後に検証できる必要がある
ハードコードされた鍵 証明書ピンニング、ソース中の公開鍵 高 発見自体が難しい。grep で見つからないことも
ベンダ製品 SaaS、アプライアンス、組み込み機器 高 自分では直せない。 ベンダに聞くしかない

最後の 2つは特に厄介です。「自分で直せないもの」のリストを早めに作って、ベンダに問い合わせを始めるのが実務的に効きます。ベンダの回答が「未対応」だった場合、代替製品の検討にさらに時間がかかるからです。

CBOM という道具

インベントリを機械可読な形で持つための仕組みとして、CBOM（Cryptographic Bill of Materials） があります。SBOM（ソフトウェア部品表）の考え方を暗号に広げたもので、CycloneDX などの標準フォーマットが暗号資産の記述に対応しています。

「どのコンポーネントがどのアルゴリズム・鍵長・証明書を使っているか」を SBOM と同じパイプラインで継続的に収集できるので、一度きりの棚卸しを、継続的な可視化に変えられます。 すでに SBOM を生成している組織なら、その延長線上で始められるのが利点です。

8-2. 優先順位づけの原則は 2つだけ

インベントリができたら、順番を決めます。原則はシンプルです。

原則①：X が長いものを先に守る（秘密保持期間が長いデータ）

医療・金融・法務・個人情報・知的財産。SNDL の直撃対象です。「20年後に読まれても困らないデータ」なら急ぐ必要はありませんが、「20年後でも困る」なら今日の通信から守る必要があります。

具体的には、そういうデータが流れる経路の鍵交換を、今すぐハイブリッドに切り替える。これは第7部のとおり、多くの場合ライブラリ更新と設定だけで済みます。最もコストが低く、最も緊急度が高いアクションです。

原則②：後から替えられないものを先に設計する

出荷後に鍵を交換できないファームウェア署名や、10年〜20年有効なルート CA。ここは**「今の設計判断」が 10年先の負債になります**。

今日ルート CA を更新するなら、有効期限中に PQC 移行が来ることを前提に設計する。今日デバイスを設計するなら、署名検証の仕組みを差し替え可能にしておく。緊急ではないけれど、機会が今しかないタイプのタスクです。

この 2つの原則は、それぞれ「緊急だから今やる」「機会が今しかないから今やる」という別の理由で「今」を指しています。混ぜないほうが説明しやすいです。

8-3. 「暗号アジリティ」を設計に入れる

今回の移行で一番学びがあるのは、多くのシステムがアルゴリズムを差し替えられない構造になっているという事実です。よくあるパターンを挙げます。

  • アルゴリズム識別子がハードコードされている（if alg == "ES256" が散在している）
  • 鍵やバッファのサイズを固定長で仮定している（[32]byte、char key[32]、DB カラムの VARCHAR(64)）
  • 証明書やトークンのサイズ上限が決め打ちされている（HTTP ヘッダの上限、DB カラム長、プロトコルのフィールド幅）
  • 暗号処理がアプリ全体に散っていて、差し替え点が一箇所にない

ML-KEM の公開鍵は 1,184バイト、ML-DSA の署名は 2,420バイト。「鍵は 32バイト」「署名は 64バイト」という前提で書かれたコードは、そこで止まります。

とくに見落としやすいのがデータベースのカラム長とプロトコルのフィールド幅です。コードは直せても、テーブル定義の変更やプロトコルの互換性維持は、そこから別のプロジェクトになります。

今から新しく書くコードでは、次の 3つを意識するだけで、次の移行コストが桁で変わります。

  1. アルゴリズム名を設定値として外に出す。 コードに埋め込まない。
  2. サイズを可変として扱う。 固定長配列で受けない。上限は余裕を持つ。
  3. 暗号処理を薄いレイヤに閉じ込める。 差し替え点を 1箇所にする。

そして、次の移行は確実にあります。今回で終わりではなく、HQC が来て、FN-DSA が来て、その先も続きます。暗号アジリティは PQC のための一時的な作業ではなく、恒久的に持っておくべき性質です。

8-4. やってはいけないこと

最後に、この分野特有のアンチパターンを挙げておきます。

  • ❌ 自前で PQC を実装する。 格子暗号は、サイドチャネル攻撃への耐性を含めて正しく実装するのが極めて難しい。標準ライブラリを使ってください。 これは「車輪の再発明」以前に、危険です。
  • ❌ 標準化されていないアルゴリズムを本番に入れる。 選考過程で実際に何本も破られています。FIPS 203/204/205 と、その後継の標準に限るべきです。
  • ❌ ハイブリッドを飛ばして PQC 単独にする。 ML-KEM は歴史が浅い。移行期はハイブリッドが定石です。
  • ❌ 「PQC 対応」を謳うベンダの主張を検証せずに受け入れる。 どのアルゴリズムのどのパラメータか、ハイブリッドか、鍵交換だけか署名も含むかを必ず確認してください。「量子耐性」という言葉のマーケティング利用がすでに始まっています。
  • ❌ QKD（量子鍵配送）で解決しようとする。 詳細は次の第9部で。
  • ❌ 鍵交換の対応で満足する。 一番簡単なところが終わっただけです。

ここまでのまとめ

  • 最初の一歩は 暗号インベントリ。棚卸しできないものは移行できない
  • 見落としやすいのは HSM・ベンダ製品・ハードコードされた鍵・DB のカラム長
  • 優先順位は ①X が長いもの（緊急）②後から替えられないもの（機会が今だけ）
  • 暗号アジリティは一時的な作業ではなく恒久的に持つべき性質
  • 自前実装するな、標準以外を使うな、ハイブリッドを飛ばすな

第9部：よくある誤解の整理

「AES も危ないから鍵長を倍にしないと」
→ Grover は平方根の高速化にすぎず、並列化も効きにくい。AES-256 なら追加対応は不要です。ここに工数を使うより、署名と鍵交換に集中したほうがいい。ただし「AES を使っているから安全」も間違いで、その鍵を配る鍵交換が弱ければ意味がありません（第2部 2-1）。

「量子鍵配送（QKD）が必要になる」
→ 主要な政府機関のガイダンスは、QKD を実運用の一般解として推奨していません。理由は明確で、(1) 専用の光ファイバや衛星が必要でインターネット上では動かない、(2) 距離に厳しい制約がある、(3) 認証の問題が別途残る（QKD は盗聴を検知できるが、相手が本物かは証明できないので、結局そこに従来の署名が必要）、(4) 装置への物理攻撃という新しい攻撃面が増える。業界の答えは PQC（既存のネットワーク上でソフトウェア更新だけで動く数学的な解）です。

「ハイブリッドは二度手間じゃないか」
→ 保険です（第4部 4-4）。ML-KEM は歴史が浅く、実装バグや未知の古典的攻撃のリスクがまだ枯れていない。コストは 32バイト増だけ。ほぼ無料の保険を断る理由がありません。

「TLS ライブラリを上げれば終わり」
→ 終わるのは一番簡単な部分だけです。難所はコード署名・ファームウェア署名・自前 PKI・長期保存文書で、どれもライブラリ更新では解決しません（第8部 8-1）。

「2035年まであるから大丈夫」
→ Mosca の不等式に戻ります。加えて、実務的な壁は 2035年より前に 2つ来ます。2030年の「非推奨」（新規システムの選択に影響）と、民間規格の追随（監査で聞かれ始める）です。そして最も準備が進んでいる企業が「2029年完了」を掲げている事実が、Y の相場観です。

「量子コンピュータが来たら、その時に一斉に切り替えればいい」
→ 2点で無理があります。(1) SNDL のデータは遡って救えない。 (2) 移行には 6〜7年かかるので、「その時」には間に合わない。そして CRQC の登場が公表されるとも限りません。

「小さな会社には関係ない」
→ 直接の規制対象ではないかもしれませんが、サプライチェーン経由で来ます。大企業や政府に納品しているなら、調達要件として PQC 対応を問われるようになります。EU ロードマップの「2026年末に開始」は、そのままサプライヤへの質問票になって降りてきます。

「Shor は重ね合わせで全パターンを試すから速い」
→ 違います。量子コンピュータの強みは全探索ではなく、周期構造を取り出すことです（第2部 2-3）。この誤解を持っていると「じゃあ AES も総当たりで破られるじゃないか」という間違った結論に進みます。

「暗号が破られたらインターネットが終わる」
→ 終わりません。共通鍵暗号（AES）とハッシュ関数は無傷なので、暗号技術の土台の半分は残ります。壊れるのは公開鍵の部分で、そこは入れ替え可能です。**問題の本質は「暗号が存在しなくなること」ではなく、「入れ替えに何年もかかること」**です。だから技術の問題より、プロジェクト管理の問題に近い。

用語集

用語 意味
PQC Post-Quantum Cryptography。量子コンピュータでも破られない暗号。「耐量子暗号」「ポスト量子暗号」とも
CRQC Cryptographically Relevant Quantum Computer。実際に暗号を破れる規模の量子コンピュータ
SNDL / HNDL Store (Harvest) Now, Decrypt Later。今記録して将来解読する攻撃
Shor のアルゴリズム 素因数分解・離散対数を量子計算で効率的に解く。RSA / ECC を壊す
Grover のアルゴリズム 総当たり探索を平方根に高速化する。AES / ハッシュへの影響は限定的
ML-KEM FIPS 203。鍵カプセル化。旧 CRYSTALS-Kyber
ML-DSA FIPS 204。署名の第一選択。旧 CRYSTALS-Dilithium
SLH-DSA FIPS 205。ハッシュベース署名。旧 SPHINCS+。バックアップ
HQC 2025年に追加選定された符号ベースの KEM。格子が倒れたときの保険
FN-DSA 旧 FALCON。署名サイズが小さい格子ベース署名。標準化進行中
KEM Key Encapsulation Mechanism。共有秘密を作って相手に届ける仕組み。DH のような対称的な鍵合意とは形が違う
LWE Learning With Errors。「ノイズ入りの連立方程式」を解く難しさに基づく問題。格子暗号の土台
ハイブリッド 従来暗号と PQC を併用し、どちらか安全なら安全にする方式。例 X25519MLKEM768
暗号アジリティ アルゴリズムを容易に差し替えられる設計上の性質
CBOM Cryptographic Bill of Materials。暗号資産の部品表
論理量子ビット 誤り訂正された、計算に使える量子ビット。物理量子ビット1,000個以上で1個
初期輻輳ウィンドウ TCP が接続開始直後に送れる量。約14KB。証明書サイズ問題の元凶
Mosca の不等式 X（秘密保持期間）+ Y（移行期間）> Z（CRQC 登場）なら手遅れ、という判断基準

おわりに

長くなったので、要点をもう一度だけ。

耐量子暗号への移行は、「量子コンピュータがいつ来るか」を予測する話ではありません。自分たちのデータをどれだけ長く守る必要があるか（X）と、移行に何年かかるか（Y）を測る話です。

  • 壊れるのは公開鍵暗号 = 署名と鍵交換。AES / SHA は心配しなくていい。ただし「AES だから安全」も間違い
  • 鍵長では逃げられない。Shor は構造を突くので、アルゴリズム入れ替えしかない
  • SNDL があるので、鍵交換の対策は「今」の話。今日守らなかった通信は永久に取り返せない
  • 標準（FIPS 203/204/205）はもう出ている。待つ理由はなくなった
  • 鍵交換の移行は実戦投入済み。あなたのブラウザはもう対応している。まず確認してみてほしい
  • 署名は未解決。証明書サイズと輻輳ウィンドウの問題が残っていて、自社では解けない
  • 最初の一歩は実装ではなく 暗号インベントリ。棚卸しできないものは移行できない
  • 新しく書くコードには 暗号アジリティを入れておく。次の移行は必ず来る

個人的にこのテーマが面白いと思っているのは、**「10年後に効く設計判断を、今日下さなければならない」**という構造そのものです。

普段のエンジニアリングでは、だいたい間違えたら直せます。デプロイし直せばいい、マイグレーションを書けばいい。でも、出荷したデバイスのファームウェア署名の鍵や、20年秘密にしたいデータは、後から直せません。この分野は、ソフトウェアエンジニアリングが得意な「後で直す」という戦略が通用しない領域です。

こういうテーマに向き合うと、自分のシステムのどこが「柔らかく」できていて、どこが「固い」のかが見えてきます。そして固い部分こそが、本当の技術的負債です。 それは PQC に限らず役に立つ視点だと思います。

まずは手元で openssl s_client を叩いて、自分の接続がすでに X25519MLKEM768 を使っているかを見てみるところから始めてみてください。「まだ遠い未来の話」だと思っていたものが、すでに自分のブラウザで動いていることに気づけます。そこからは、ずっと現実的な話になります。

参考

標準・規格

規制・ロードマップ

実装・解説

量子コンピュータ側の見積もり

もし参考になったら、LGTM・ストックいただけると励みになります 🙏
記事が長くなったので、「ここが分かりにくい」「ここをもっと詳しく」があればコメントで教えてください。

X (Twitter): @keitah0322

関連記事：

  • Cloud Native Security シリーズ
  • Platform Engineering シリーズ
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?