格子暗号とは？LWEとML-KEM/ML-DSAの核心

ブラウザでTLS 1.3の接続を開く場面を、薄い封筒で済んでいた書類にもう一冊の契約書を同封する感覚で眺めると、格子暗号への移行がぐっと具体的になります。
古典的なX25519にML-KEM-768を重ねるハイブリッド鍵共有では、最初の握手メッセージがひと回り大きくなりますが、そこで得られるのは「量子でも絶対安全」という神話ではなく、格子問題に対する既知の効率的量子攻撃がまだ見つかっていないという、実務で意味のある安全余地です。

本稿は、公開鍵暗号の更新を追うエンジニアや、PQCを表面的な流行語で終わらせたくない読者に向けて、格子暗号を直感から整理します。
Ajtaiの1996年、NTRUの1998年、RegevとLWEの2005年を経て、2024年のNIST標準FIPS 203FIPS 204でML-KEMML-DSAがどう定着したのかをたどり、LWEのしくみからTLS、IoT、そして移行設計までを一気通貫でつなげます。

格子暗号が注目される背景——なぜRSAやECCの次が必要なのか

量子計算の脅威とHNDL問題

RSAやECCが長く主役でいられたのは、素因数分解や離散対数が古典計算機では手強い問題だったからです。
ところが、量子計算機が実用規模に到達したとき、この前提は崩れます。
Shorのアルゴリズムは、素因数分解と離散対数を効率よく解ける理論を与えており、その射程にはRSAだけでなくDiffie-Hellman系や楕円曲線ベースの鍵共有・署名も入ります。
いま使っている公開鍵暗号が明日すぐ破られるという話ではありませんが、「現行の公開鍵基盤が、量子計算機の成熟によって土台から揺らぐ」という点は、すでに設計上の前提として扱う段階に入っています。

ここで見落とされがちなのがHNDL（Harvest Now, Decrypt Later）です。
いま盗聴した通信や保存データを解読できなくても、攻撃側はそのまま保管できます。
数年後、量子計算機や関連ツールが実用域に届いた時点で、過去の暗号化トラフィックをまとめて復号する、という発想です。
たとえば金融の取引記録、医療情報、政府調達や安全保障に関わる文書は、送信時点だけ守れれば足りる情報ではありません。
秘匿期間が長いほど、「いまは解けないから大丈夫」という判断が危うくなります。

筆者がこの問題を現実の運用に引き寄せて考えるとき、まず社内のデータ保管年限と突き合わせます。
契約関連ログ、監査証跡、顧客対応の証跡、研究開発文書の一部は、平気で10年以上残ります。
そうすると検討の軸は、「量子計算機が今年来るか」ではなく「10年以上秘匿したい情報を、量子脆弱な公開鍵で今日も包み続けてよいか」に変わります。
この小さな演習を一度やるだけで、暗号刷新を待ちではなく先行実装で捉える理由がはっきりします。
特に長期保管のバックアップやアーカイブ転送では、いま暗号化したデータが将来まとめて読まれる可能性を無視できません。

その代替候補として格子暗号が注目されるのは、格子問題、より具体的にはLWEやModule-LWEに基づく方式に対して、既知の効率的量子攻撃が見つかっていないからです。
ここが暗号の美しいところなのですが、「量子でも解けない」と神話化する必要はありません。
実務上のポイントは、古典公開鍵がShorで構造的に狙われる一方、格子ベース方式は別の計算困難性に立っており、移行先として合理的な候補を持てることです。
ML-KEMやML-DSAが採られた背景も、まさにこの「別の土台を用意する」という設計思想にあります。

なお、格子問題が小さな次元で研究対象になることと、実用パラメータの安全性は同じ話ではありません。
2016年には九州大学とKDDIの研究チームが60次元のLWE問題を約16日で解読していますが、これは実用格子暗号が直ちに危険だという意味ではなく、低次元の検証と高次元の実用設定を分けて見るべきだ、という理解につながります。
2次元や数十次元の図は導入としては便利でも、実際の安全性評価はもっと高次元の世界で行われています。

PQCとQKDは何が違うか

量子時代の防御策を語ると、PQCとQKDがしばしば混同されます。
両者は目的も導入方法も違います。
PQC（Post-Quantum Cryptography）は、量子計算機に対しても安全余地を持つ公開鍵暗号へ置き換える技術領域です。
既存のインターネット、既存のTLS、既存のPKIの延長で導入できることが中心にあります。
一方のQKDは量子力学の性質を使って鍵配送を行う別系統の仕組みで、専用回線や専用装置を前提にする場面が多く、インターネット上の公開鍵暗号をそのまま置き換える話ではありません。

この違いは、現場の導入像を思い浮かべると腹落ちします。
PQCは、たとえばVPNの終端装置やCDNのエッジで使うTLS 1.3の鍵共有を、既存のX25519単独からハイブリッド型へ更新していく発想です。
X25519MLKEM768のような方式なら、古典楕円曲線とML-KEM-768を組み合わせて段階移行できます。
クライアントの key_share は1,216バイトになり、初回の握手メッセージはひと回り厚くなりますが、実務で目立つコストは主にこの通信量の増加です。
TLS全体のハンドシェイク遅延はおおむね数ミリ秒台に収まり、鍵演算そのものが致命的な足かせになる構図ではありません。

筆者の感覚では、ここがPQCを“現実解”と呼びたくなる理由です。
QKDのように新しい装置群を敷設しなくても、既存の証明書運用、負荷分散、終端ポリシーの延長線で進められます。
社内VPNで拠点間トンネルを張る場面や、CDNで多数のクライアント接続をさばく場面では、装置を総入れ替えするより、暗号スイートとライブラリの更新で進められるほうが現実の計画に落とし込みやすいものです。
ハンドシェイクの封筒が少し厚くなる代わりに、ネットワーク全体の作法は保てる。
この性質が、移行案件としての通しやすさにつながります。

もちろん、PQCにも設計上の課題はあります。
鍵や署名、ハンドシェイクのメッセージが大きくなりやすく、実装品質の差がそのまま安全性に跳ね返ります。
だからこそ、格子暗号は数学的に有望というだけでなく、標準準拠の検証済み実装で扱う必要があります。
それでも、既存プロトコルを保ちながら段階導入できる点で、PQCは量子脅威への対策として最も広く展開しやすい領域です。

2016→2024：NIST標準化のタイムライン

格子暗号が研究テーマから実装計画へ移った転機は、標準化の進展です。
研究史を振り返ると、1996年にAjtaiが最悪時困難性に基づく初期構成を示し、1998年にNTRU、2005年にRegevがLWEとともに公開鍵暗号を提示しました。
理論の蓄積は長く続いていましたが、実運用の世界で空気が変わったのは、標準化機関が移行先を明確にし始めてからです。

年表として押さえると流れは明快です。

1. 2016年にNISTがPQC標準化プロジェクトを開始しました。ここで「量子脆弱な公開鍵暗号の次」を公募・比較・評価する枠組みが整いました。
2. 選考と絞り込みを経て、鍵共有の主力としてCRYSTALS-Kyber、署名の主力としてCRYSTALS-Dilithiumが中心候補になりました。標準化後の名称はそれぞれML-KEMとML-DSAです。
3. 2024年にFIPS 203としてML-KEM、FIPS 204としてML-DSA、そしてFIPS 205としてSLH-DSAが承認され、移行先が正式な連邦標準として定まりました。

この2024年の確定は、単に「候補が決まった」という話ではありません。
たとえばML-KEMはML-KEM-512ML-KEM-768ML-KEM-1024の3つのパラメータセットを持ち、ML-DSAも安全性レベルに応じて複数モードを備えています。
実装者はこれによって、鍵共有と署名をどの水準で置き換えるかを、標準化された名前と仕様で議論できるようになりました。
曖昧な研究コードではなく、相互接続と審査を前提にした設計へ進んだわけです。

同時に、移行は一斉切り替えではなく段階導入で進みます。
TLS 1.3では、古典方式とML-KEMを合わせるハイブリッド鍵共有が先行しています。
候補として定義されているのはX25519MLKEM768SecP256r1MLKEM768SecP384r1MLKEM1024の3系統です。
これは「古典暗号を今日捨てる」ためではなく、既存互換性を保ちながら量子リスクを織り込むための橋渡しです。
証明書署名やPKI全体の完全移行は鍵共有より後ろに来るので、現実のロードマップはまずハイブリッド、その先に署名基盤の更新という順番になります。

移行計画の前提として見ておきたいのがNIST IR 8547です。
この文書では、量子脆弱な公開鍵方式を2035年までに非推奨から削除へ向かわせる考え方が示されています。
日付だけ切り取ると遠く見えますが、システム更新、証明書ライフサイクル、HSMやライブラリの更改、監査文書の改訂まで含めると、実務の時間軸ではむしろ近い部類です。
暗号移行はアルゴリズム名を差し替えれば終わる作業ではなく、接続先との相互運用、署名階層、アーカイブの再暗号化まで波及します。
格子暗号が注目される背景には、理論上の魅力だけでなく、「標準が固まり、撤収期限まで見え始めた」という制度面の圧力もあります。

そもそも格子とは何か——方眼紙から高次元空間へ

2次元格子の比喩

格子（lattice）という言葉は抽象的に聞こえますが、入口としては方眼紙を思い浮かべるのがいちばん自然です。
紙の上に横方向と縦方向の一定間隔の点を無限に並べたもの、と考えると直感が合います。
数学では、その点の並びを2本のベクトルの整数倍の足し算で作ります。
この2本が基底（basis）です。
たとえば、右に1、上に0進む矢印と、右に0、上に1進む矢印があれば、方眼紙の交点はその組み合わせで全部表せます。

ここが暗号の美しいところなのですが、格子は「点そのものの集合」であって、紙に最初に引いた2本の矢印そのものではありません。
つまり、同じ点の並びを別の2本の矢印で表すこともできます。
見た目には斜めに傾いた網目でも、数学的には同じ格子を記述していることがあるわけです。

筆者が初学者向けに説明するときは、実際に方眼紙に2本の基底ベクトルを描いてもらいます。
最初は直交に近い、見通しのよい2本を引きます。
そこから片方を少しずつ倒して、鋭角だったものを鈍角気味に変えていくと、同じ平面上の点を作っているはずなのに、どの点が近く、どの点が基準点なのかが急に追いにくくなります。
線路がまっすぐ見えていた地図を、斜めから無理に眺めるような感覚です。
格子暗号の説明で2次元図がよく使われるのは、この「見えていたものが見えなくなる」体験を一枚の図で伝えられるからです。

もちろん、実用の格子暗号が扱うのは2次元ではありません。
実際の本体はもっと高い次元にあります。
それでも、まずは方眼紙の世界で「点の無限アレイ」として格子をつかむと、後で高次元の話に進んだときに足場が残ります。
2次元はあくまで比喩ですが、その比喩がうまく働くと、抽象語だった格子が急に手触りのある対象になります。

良い基底と悪い基底

同じ格子でも、どんな基底（basis）で眺めるかによって、問題の見え方は大きく変わります。
直交に近く、長さもほどよくそろった2本のベクトルで表した基底は、いわば見通しのよい地図です。
どの方向に点が並んでいるかが把握しやすく、短いベクトルも目に入りやすい。
一方で、長くて斜めに寝たベクトル同士で表した基底は、同じ道を描いていても地図がゆがんだ状態に近く、近い点や短いベクトルが埋もれます。

この「良い基底」「悪い基底」という区別は、格子暗号の核心に触れる感覚です。
格子そのものは同じでも、良い基底なら構造が読み取りやすく、悪い基底なら構造が隠れます。
公開情報としては悪い基底だけを見せ、内部では良い基底に相当する情報を持つ、という発想が後でLWEやその周辺を理解するときの助走になります。

方眼紙ワークでこれを試すと、印象がはっきり変わります。
直交に近い2本なら、原点の近くにある短い矢印を目で拾えます。
ところが、一方を長くして角度をつぶすと、同じ点列なのに「どれが本当に短いのか」が途端に曖昧になります。
目の前の図は変わっていないのに、探索のコストだけが上がる。
この感覚は、計算機にとっても無関係ではありません。
高次元になると、人間の目で見える混乱が、そのまま計算上の難しさとして増幅されます。

直感に反するかもしれませんが、暗号では「点を作れること」自体は秘密ではありません。
難しさは、「その点の並びの中から都合のよい短い関係を見抜けるか」に移ります。
良い基底はその手がかりを与え、悪い基底は手がかりをぼかします。
この差が、格子をただの幾何学ではなく、暗号の材料に変えています。

SVP/CVPとは何か

格子の世界で繰り返し現れる代表的な問題が、最短ベクトル問題のSVP（Shortest Vector Problem）と、最近ベクトル問題のCVP（Closest Vector Problem）です。
名前だけ見ると身構えますが、図にすると発想は素朴です。

SVPは、その格子の中で原点からいちばん短い非ゼロのベクトルを探す問題です。
方眼紙なら、中心から見て最初に届く交点を見つける感覚に近いものです。
ただし、基底が悪くなると、どの方向に短いベクトルが潜んでいるのかが見えにくくなります。
2次元図では何とか目で追えても、次元が上がると候補が爆発的に増え、短さの比較そのものが急に手強くなります。

CVPは、格子点ではない任意の点が与えられたとき、その点に最も近い格子点を探す問題です。
こちらは「最寄り駅探し」に置き換えると腑に落ちます。
地図の上で自分が今いる場所が駅と駅の中間にあるとき、どの駅が最も近いかを選ぶ作業です。
駅が碁盤の目ならすぐ決まりますが、路線が斜めに入り組み、しかも地図がゆがんで見えると判断が鈍ります。
筆者はこの比喩を使うとき、まず整った街区の路線図を想像し、そのあと斜めに傾いた座標で同じ町を見てもらいます。
距離感の直感が途端に狂うので、「近い点を選ぶだけなのに、なぜ難しいのか」が腹落ちします。

暗号で効いてくるのは、この「少しずれた点」を元の格子点に戻す難しさです。
後で出てくるLWEでは、きれいな線形関係に小さなノイズが混ざります。
そのノイズ込みの点から、元の規則性を復元できるかが焦点になります。
図でいえば、格子点の近くに少しだけずれた印が打たれていて、その印から元の交点を当てるゲームに近いものです。
SVPは格子の中に潜む最短の関係を探す問題、CVPはずれた点をどの格子点に結びつけるかを決める問題、と並べておくと、次のLWEで何が「ノイズ」として効いているのかが見えやすくなります。

格子暗号の仕組み——LWEの少しだけ混ぜるノイズを体験する

LWEの基本構図

ここからは、格子暗号の代表的な考え方であるLWE（Learning With Errors）を、手で追える形に縮めて見ていきます。
日本語にすると「誤差つき学習」ですが、暗号としての直感はもっと素朴です。
秘密値に小さな誤差（ノイズ）を混ぜる。
この一手で、正しい持ち主には元の情報が読めるのに、外から見た人には逆算が急に苦しくなります。
ここが暗号の美しいところなのですが、混ぜるノイズは大きければよいわけではありません。
小さすぎると秘密が透け、大きすぎると正規の受信者まで読めなくなる。
その細い帯の上で設計するのがLWEです。

LWEは、2005年にRegevが提示した問題設定として広まりました。
基本形は、公開されたベクトル \(a\) と、秘密ベクトル \(s\) に対して、内積 \(a \cdot s\) に小さな誤差 \(e\) を足した値 \(b\) を並べていく、というものです。
式だけ書けば \(b = a \cdot s + e\) です。
もし誤差がなければ、十分な本数の式を集めることで、未知の \(s\) は連立方程式として狙われます。
ところが各式に少しずつノイズが混ざると、「どの式も少しだけずれている世界」になり、きれいな逆算が崩れます。

正規の受信者がなぜ扱えるのかというと、秘密情報を持っているので、受け取った値から「本来あるはずの中心」を計算できるからです。
ノイズが小さければ、その値は中心の近くに落ちます。
そこで境界をまたいでいないかだけを判定すれば、元のビットを取り出せます。
攻撃者にはこの中心が見えません。
見えるのは、秘密値とノイズが混ざったサンプル列だけです。
少しのズレなら無視できそうに見えるのに、そのズレがあるせいで方程式はぴたりと閉じず、しかも高次元では候補の数が膨れ上がる。
この「正しい人には誤差つきでも読めるが、外からは誤差つきゆえに難しい」という非対称性がLWEの核です。

手を動かす玩具例

抽象語のままだと腹落ちしにくいので、2×2の行列でミニチュートリアルをやってみます。
実用方式とは桁違いに小さな設定ですが、動作の骨格は見えます。
法を 17 とし、秘密ベクトルを \(s=\begin{pmatrix}3\\5\end{pmatrix}\) とします。
公開用の行列は

\[ A= \begin{pmatrix} 2 & 7\\ 6 & 4 \end{pmatrix} \]

とします。まず送信前の準備として、送信者側は小さな誤差ベクトル \(e=\begin{pmatrix}1\\-1\end{pmatrix}\) を混ぜて

\[ b = A s + e \pmod{17} \]

を作ります。計算すると、

\[ As= \begin{pmatrix} 2\cdot3+7\cdot5\\ 6\cdot3+4\cdot5 \end{pmatrix} = \begin{pmatrix} 41\\38 \end{pmatrix} \equiv \begin{pmatrix} 7\\4 \end{pmatrix} \pmod{17} \]

なので、

\[ b= \begin{pmatrix} 7\\4 \end{pmatrix} + \begin{pmatrix} 1\\-1 \end{pmatrix} = \begin{pmatrix} 8\\3 \end{pmatrix} \pmod{17} \]

です。この \(A\) と \(b\) が、LWEらしい「秘密とノイズが混ざった公開情報」だと思ってください。

ここから1ビットのメッセージを埋め込む玩具的な暗号化を行います。
メッセージを \(m\in\{0,1\}\) とし、\(m=1\) なら法 17 の半分に近い値、つまり 8 を足して印を付ける、と考えます。
送信者は小さな選択ベクトル \(r=\begin{pmatrix}1\\1\end{pmatrix}\) を選び、暗号文を

\[ u = A^T r \pmod{17}, \quad v = b^T r + 8m \pmod{17} \]

で作ります。今回は \(m=1\) とします。

まず \(u\) です。

\[ A^T= \begin{pmatrix} 2 & 6\\ 7 & 4 \end{pmatrix} \]

なので、

\[ u=A^Tr= \begin{pmatrix} 2+6\\ 7+4 \end{pmatrix} = \begin{pmatrix} 8\\11 \end{pmatrix} \pmod{17} \]

です。次に \(v\) は

\[ b^Tr = 8+3 = 11 \]

なので、

\[ v = 11 + 8 = 19 \equiv 2 \pmod{17} \]

となります。暗号文は \((u,v)=\left(\begin{pmatrix}8\\11\end{pmatrix}, 2\right)\) です。

受信者は秘密 \(s\) を知っているので、\(v-u^Ts\) を計算します。ここが追体験してほしい場面です。まず

\[ u^Ts = 8\cdot3 + 11\cdot5 = 24 + 55 = 79 \equiv 11 \pmod{17} \]

です。したがって

\[ v-u^Ts = 2-11 = -9 \equiv 8 \pmod{17} \]

を得ます。8 は「半分に近い側」なので、受信者は \(m=1\) と読めます。

なぜこれで読めるのかを、式の中身まで一段だけ開くと見通しが良くなります。
\(b=As+e\) なので、受信者が見る値は\(As\)に小さなノイズ\(e\)が加わったものになり、このノイズが十分に小さければ元のメッセージや秘密ベクトルを復元できます。

\[ v = b^Tr + 8m = (As+e)^Tr + 8m = r^TA s + e^Tr + 8m \]

です。一方で \(u=A^Tr\) だから

\[ u^Ts = r^TAs \]

になり、差を取ると

\[ v-u^Ts = e^Tr + 8m \]

だけが残ります。
つまり、秘密 \(s\) を持つ受信者は大きな本体 \(r^TAs\) をきれいに消し去れて、ノイズとメッセージの印だけを取り出せるわけです。
今回のノイズ項は

\[ e^Tr = 1 + (-1) = 0 \]

なので、ちょうど 8 がそのまま出ました。

筆者がこの玩具例を紙で計算するとき、LWEの感覚がいちばん立ち上がるのは次の瞬間です。
手順の中でノイズの大きさだけを少し変えると、復号の成否に境目があることが見えてきます。
たとえば誤差を \(e=\begin{pmatrix}2\\1\end{pmatrix}\) に変えると、\(e^Tr=3\) なので受信者が見る値は \(8+3=11\) です。
17 を法とする円の上で見ると、11 はまだ「8 側」の塊に入っているため \(m=1\) と読めます。
ところが誤差を \(e=\begin{pmatrix}4\\2\end{pmatrix}\) にすると \(e^Tr=6\) で受信者が見る値は \(8+6=14\) になります。
14 は 0 側に回り込んだ値として扱いたくなる位置にあり、境界判定が怪しくなります。
ここで、ノイズは小さければ隠れ方が弱く、大きくすると今度は自分で自分の印を壊す、という閾値感覚が手に残ります。

攻撃者の立場から見ると、\(A\)、\(b\)、\(u\)、\(v\) は見えています。
しかし秘密 \(s\) は見えません。
もし誤差 \(e\) がゼロなら、\(b=As\) なので \(s\) を連立方程式として詰める道筋が立ちます。
ところが実際には「少しだけずれている」ので、見かけの関係式がぴたりと一致しません。
しかも攻撃者は、そのずれがメッセージ由来なのか、ノイズ由来なのか、あるいは秘密との組み合わせなのかを切り分けられません。
2×2 では遊べる計算でも、実用ではこれが高次元・多サンプルになり、逆算は一気に格子問題の顔つきになります。

Module-LWE/RLWEへの橋渡し

ただし、ここまでの素朴なLWEをそのまま大きくしていくと、鍵サイズや計算量の面で扱いにくくなります。
そこで実用方式では、同じ発想を多項式環の上に載せ替えたRing-LWE、さらにその中間で柔軟性と効率のバランスを取るModule-LWEが使われます。
考え方の芯は変わりません。
秘密にノイズを混ぜ、正規の受信者だけがそれを打ち消せるようにする、という構図はそのままです。
違うのは、整数ベクトルや行列の代わりに、多項式をまとめて一度に扱える形へ整理している点です。

多項式環を使う理由は明快で、計算を規則正しく並べ替えられるからです。
長いベクトル計算を、巡回的な構造を持つ多項式演算として処理できるので、実装では高速化の余地が生まれます。
通信量や鍵サイズとの折り合いも付けやすくなり、現実のプロトコルに載せやすくなります。
現行の標準KEMであるML-KEMがModule-LWE系に立っているのは、この実用上の理由が大きいわけです。
NIST FIPS 203（ML-KEM）で定義されるパラメータも、この流れの延長線上にあります。

ここで「環」や「モジュール」という言葉に身構える必要はありません。
整数の2×2行列で見たチュートリアルを、もっと大きく、もっと規則正しく、計算機が回しやすい形に畳み直したものだと捉えると筋が通ります。
筆者は実装を見るとき、まず玩具LWEの \(v-u^Ts\) を頭に置きます。
実用方式は見た目こそ多項式だらけですが、起きていることの中心は同じです。
ノイズを足す、秘密で本体を消す、残った値が境界のどちら側かを読む。
この骨格が見えていると、RLWEやModule-LWEの式も「難しい新世界」ではなく、「LWEを工学向けに整えた姿」として読めるようになります。

歴史と系譜——Ajtai、NTRU、RegevからML-KEM/ML-DSAへ

1996：Ajtaiの還元とDworkとの仕事

格子暗号の歴史を一本の線として見るなら、出発点のひとつは1996年のMiklós Ajtaiです。
ここが暗号の美しいところなのですが、Ajtaiが示した意義は、単に「格子を使った暗号が作れた」という点だけではありません。
最悪時から平均時への還元、つまり「ある格子問題のいちばん難しい場合が解けるなら、暗号で日常的に遭遇するランダムな实例も解けてしまう」という橋を架けたことにあります。

従来の公開鍵暗号では、設計そのものは明快でも、「実際に配る公開鍵がどれほど典型的に難しいのか」を厳密に言い切るのは簡単ではありませんでした。
Ajtaiの仕事は、その不安を理論の側から押し返しました。
最悪ケースの困難性を、平均的に生成されるインスタンスへ結びつける見取り図を与えたからです。
暗号として眺めると、これは「たまたま難しい問題を引いたから安全」ではなく、「構成の背後にある難問のクラス全体が支えている」と読めます。

AjtaiとCynthia Dworkは、格子に基づく公開鍵暗号が証明可能安全性を伴って立ち上がることを示し、後の研究者に「格子は直感的なおもしろさだけでなく、理論暗号として本格的に育つ土台になる」と納得させました。
今日の実用方式とは見た目が違っていても、そこで得られた「平均的な公開鍵の安全性を、最悪ケース格子問題の難しさから説明する」という発想は、その後の系譜全体に流れ込みます。

筆者は1990年代末から2000年代にかけての論文年表を一枚の系譜地図として眺めることがあります。
Ajtaiの点から線を引くと、「まず理論の足場を置く」という太い流れが見え、その先で設計思想が枝分かれしていきます。
この時点ではまだ実装の都合よりも、なぜ安全と言えるのかをどう数学で言い切るかが中心にあります。
格子暗号の歴史は、まず理論が地盤を作り、その上に実用品が建っていく順序で進んだと捉えると見通しが立ちます。

1998：NTRUの登場

その地図の上で、1998年に現れるのがNTRUです。
提案者はJeffrey HoffsteinJill PipherJoseph H. Silvermanで、格子暗号を「理論的に興味深い対象」から「実装可能な公開鍵方式」へ一気に引き寄せた存在でした。
NTRUは多項式環を使う構成を前面に押し出し、計算効率や鍵生成・復号の現実性を強く意識していました。
後年のRing-LWEやModule-LWEを知ったあとで振り返ると、格子系の実装志向が早い段階からはっきり表れていた方式だとわかります。

ただし、NTRUと後のLWE系は同じ「格子暗号」の箱に入れて終わりではありません。
両者の違いは、設計思想と安全性根拠の置き方にあります。
NTRUは代数的に整った多項式演算を中核に据え、効率のよい暗号方式として強い魅力を持ちました。
その安全性は「LWEのような標準的な学術問題にきれいに還元される」という形ではなく、NTRU固有の構造に対する長年の解析と攻撃研究の積み重ねで評価されてきました。

この対比は、後から系譜地図を眺めるとよく見えます。
ひとつの枝はNTRU系で、実用へ向かう設計の鋭さが光ります。
もうひとつの枝は、のちにLWEへつながる「還元に基づく安全性」を太く育てる流れです。
どちらも格子を使いますが、前者は“うまく動く構造を磨く”色合いが濃く、後者は“なぜ壊れにくいかを標準問題へ結びつける”色合いが濃い。
この分岐を意識すると、同じ格子暗号でも論文の書き方や評価軸が違って見えてきます。

直感に反するかもしれませんが、歴史の早い段階では「いちばん実用的に見える方式」が、そのまま標準の中心になるとは限りません。
暗号標準では、性能だけでなく、学術コミュニティが安全性をどう共有できるかが効いてきます。
NTRUはその後も強い存在感を保ち続け、実用候補として高く評価されましたが、主流の標準化の中心線は、より一般化されたLWE系へ伸びていきました。

2005：RegevとLWE

2005年のOded RegevによるLWE（Learning With Errors）の提案は、その中心線を決定づけた節目です。
LWEの核は、線形代数のきれいな関係式に少しだけ誤差を混ぜることで、正規利用者には解けるが攻撃者には解きにくい問題を作る、という発想です。
前のセクションで手計算した「ノイズがあるのに、秘密を持つ側だけは本体を消せる」という感覚が、そのまま理論の本流にあります。

Regevの大きさは、LWEを「暗号に使えそうな新問題」として出しただけでなく、格子問題との還元関係を整え、研究者がその上に多数の構成を積める共通基盤にしたことです。
これによって、鍵共有、公開鍵暗号、IDベース暗号、準同型暗号など、さまざまな方向へ派生が広がりました。
格子暗号の論文史が2000年代後半から一気に厚くなるのは、LWEが共通語になったからです。

その後、純粋なLWEは理論的には強力でも、鍵サイズや計算量の面で扱いにくいという課題に向き合います。
そこでRing-LWE、さらにModule-LWEへと整理され、理論と実装の折り合いが付けられていきました。
この流れの先にCRYSTALS-Kyberがあり、署名側ではFiat-Shamir with Abortsやモジュール格子の技法を洗練させたCRYSTALS-Dilithiumがあります。
学術論文で磨かれた抽象概念が、実装可能な定数時間コード、相互接続試験、TLS統合へと降りてくる過程は、格子暗号史の中でも見応えのある部分です。

筆者がこの系譜を追うとき、AjtaiからRegevへ線を引き、そこからKyberとDilithiumへ伸びるルートを太線でなぞります。
別の色でNTRUの枝を引くと、同じ格子でも家系が違うことが視覚的に腑に落ちます。
研究史を単なる年表として読むと「新方式が次々出た」に見えますが、系譜地図として見ると、「安全性還元を軸に伸びたLWE系」と「独自構造で実用を切り開いたNTRU系」という二つの設計文化が並走していたことが見えてきます。
この眺め方を一度掴むと、現在の標準化文書の名前の違いまで一気につながります。

2024：Kyber/DilithiumのFIPS化と名称変更

その本流が実用標準として結実したのが、2024年のNIST標準化です。
CRYSTALS-Kyberは ML-KEM としてFIPS 203に入りました。
CRYSTALS-Dilithiumは ML-DSA としてFIPS 204に入りました。
ここで見逃せないのが名称変更です。
研究コミュニティや実装の世界では長くKyberDilithiumの名で流通してきましたが、標準文書ではそれぞれModule-Lattice-Based Key-Encapsulation MechanismとModule-Lattice-Based Digital Signature Algorithmの略称に置き換えられています。

この改名は表札を掛け替えただけではありません。
KyberやDilithiumが、コンペティションの候補や実装名から、政府調達や製品認証にそのまま載る正式な標準名へ移ったことを意味します。
名前が一般名詞的になることで、特定チームの提案方式から、運用と監査の対象となる規格へ立場が変わったわけです。
研究者が読む論文では旧名が自然でも、調達文書やライブラリのFIPS対応欄ではML-KEMML-DSAと書かれる。
このズレを知らないと、同じ方式を別物だと勘違いしやすくなります。

実務上も、この標準化で流れが一段変わりました。
鍵共有の主力としてはML-KEMが位置づけられ、パラメータは3種類に整理されています。
TLSの移行でも、単独導入ではなく既存楕円曲線と組み合わせるハイブリッド構成が前進しており、X25519MLKEM768SecP256r1MLKEM768SecP384r1MLKEM1024のような名前が現れます。
研究室のホワイトボードにあった格子の式が、ブラウザの接続処理やライブラリ設定名にそのまま降りてきた感覚があります。

歴史の線をここまで引くと、Ajtaiの還元、NTRUの実装志向、RegevのLWE、そしてML-KEMML-DSAという標準名への収束が一本につながります。
格子暗号は「量子時代に備える新顔」ではなく、1990年代から積み上がった理論と設計文化が、2024年に公的標準として定着した分野です。
名前が変わっても血統はそのままで、KyberはML-KEMになり、DilithiumはML-DSAになった。
その読み替えができると、学術史と実装史を同じ地図の上で追えるようになります。

安全性の根拠と限界——最悪時困難性はなぜ魅力的なのか

“最悪時から平均時”の還元とは

格子暗号の安全性を語るとき、いちばん魅力的な言葉は「最悪時から平均時への還元」です。
少し平たく言えば、ごく都合の悪い難問だけがたまたま解けないのではなく、ランダムに生成した暗号インスタンスの解読が、格子上の本質的に難しい問題とつながっている、という見取り図です。
ここが暗号の美しいところなのですが、特定の“当たり外れ”に頼りにくい設計思想になっています。

普通の直感では、「ランダムに選んだ問題のほうが、最悪の問題より易しそうだ」と感じるかもしれません。
ところがLWE系では、もし平均的に与えられるインスタンスを効率よく解けるなら、格子の最悪事例にも手が届いてしまう、という方向の理論が整っています。
つまり「たまたま生成された弱い鍵に依存している」のではなく、「平均的な鍵生成そのものが、難しい計算問題の上に乗っている」と説明できるわけです。

筆者はこの話を説明するとき、攻撃難度を調整するスライダーを思い浮かべます。
次元を右へ、ノイズ幅を少し動かすだけで、解読側の景色が連続的に険しくなる感触があります。
2次元や3次元の図では点の並びを目で追えますが、高次元に入るとその直感は急速に役に立たなくなります。
しかもLWEは、単に次元が大きいだけでなく、そこへ「少しだけ混ぜた誤差」が推測を鈍らせます。
この「少しだけ」が暗号としては効いていて、攻撃者には座標をぴたりと合わせる作業を一段ずつ崩していく役割を持ちます。

この還元が魅力的なのは、暗号の安全性を「今のところこの具体例は解けていない」という経験則だけに置かず、計算量理論と格子問題の難しさに接続できるからです。
もちろん、それで何もかも片付くわけではありません。
それでも、ランダムに生成される実用鍵が、単なる経験的な幸運ではなく、理論的な背骨を持っているという点は、RSAやECCの安全性説明とはまた違う種類の説得力を持っています。

実用パラメータへの適用にある留保

ただし、この話をそのまま「だから実用のML-KEMは数学的に丸ごと保証済みです」と言い換えるのは正確ではありません。
理論上のLWEと、現実に使われるModule-LWEやRing-LWE、そして標準化された実装上の制約は同じ地図の上にありつつも、構造的な仮定やパラメータ選定が異なり、理論的な証明がそのまま実装の安全性に等しく適用できるわけではないからです。

実用方式では、鍵サイズや通信量、CPU効率、定数時間実装、メモリ使用量といった条件を満たすために、構造化された問題設定を使います。
ML-KEMが採るのはその代表例で、純粋なLWEをそのまま巨大な行列で回すのではなく、モジュール構造を導入して実装可能な形へ落とし込んでいます。
この工夫があるから標準化まで進んだのですが、同時に、教科書的な「最悪時から平均時」のイメージを一文でそのまま貼り付けると粗くなります。

ここで必要なのは、強みと留保を同じ文の中で扱う姿勢です。
筆者は運用判断の場では、「絶対安全」という言い方を避けて、「既知の攻撃では実用上の危殆化が見えていない」と言い換えるようにしています。
似た表現に見えて、意味はだいぶ違います。
前者は未来の発見まで封じる響きを持ちますが、後者は現時点の公開知見に基づく判断だと明示します。
暗号の現場では、この言葉づかいの差がそのまま説明責任の差になります。

実装面の論点も同じです。
理論的に堅い問題設定でも、サイドチャネル、乱数、デコーダの扱い、プロトコル統合のまずさが入れば、数学の強さだけでは守れません。
格子暗号を高く評価するなら、最悪時困難性の話と同時に、実用パラメータと実装品質の層をきちんと分けて眺める必要があります。

量子アルゴリズムの現状と表現の作法

量子計算機との関係では、格子暗号が注目される理由は比較的はっきりしています。
RSAやECCはShor型の量子アルゴリズムの射程に入る一方、LWEや主要な格子問題に対して、既知の効率的量子アルゴリズムで決定打といえるものは見つかっていません。
この点が、移行先候補として格子暗号が先頭集団にいる理由です。

ただし、ここでも表現には作法があります。
「量子攻撃に強い」という短い言い方は便利ですが、厳密には「現在知られている量子アルゴリズムでは、RSA/ECCに対するShorのような飛躍的な崩し方がLWE系で確立していない」と述べるほうが中身に忠実です。
未知のアルゴリズムが未来に出ない、と断言する根拠はありません。
暗号の安全性は、つねに数学・計算モデル・実装・公開研究の更新の上に乗っています。

省かないほうがよい部分です。
筆者自身、レビューや設計文書で「安全です」と書きたくなったときほど、「何に対して、どの範囲で、どの時点の知識で」と言い換える癖をつけています。
格子暗号についても同じで、適切なのは「絶対安全」ではなく、「既知の量子攻撃研究を踏まえると、有力な実用候補に位置づけられている」という表現です。
断定を弱めるためではなく、読者が誤読しないように輪郭を揃えるためです。

評価事例：60次元LWEと実用への距離

安全性評価の事例としてよく引かれるのが、九州大学とKDDIによる60次元LWEの解読です。
約16日で解けた、という数字だけを見ると驚きがありますし、「LWEはもう危ないのでは」と感じる読者も自然に出てきます。
ただ、この結果の読み方には文脈が必要です。

まず、低次元のLWEが解けること自体は、理論と実験の橋渡しとして価値があります。
攻撃アルゴリズムがどこまで届くか、どのパラメータで急に難度が跳ね上がるかを観測できるからです。
研究としてはむしろ健全で、こうした到達点の積み上げが安全性見積もりを洗練させます。

60次元という設定は、実用標準の世界とそのまま並べて読める数字ではありません。
格子問題は、前述のスライダーの比喩でいえば、少し動かしただけで攻撃計算量の見え方が一変する領域があります。
低次元では探索や格子基底簡約が届く範囲でも、次元やノイズ、構造の違いが入ると、同じ延長線では語れなくなります。
2次元の格子図を眺めて「見えている」と思えたものが、高次元ではその感覚ごと失われるのに少し似ています。

したがって、この60次元の成果は「LWEは解ける場合がある」と「だから実用のML-KEMが直ちに危殆化した」は同義ではない、という整理で受け止めるのが妥当です。
研究者が低次元や簡略化モデルを攻めるのは、実用暗号の安全余裕を測るためでもあります。
危険信号として無視するのでも、煽って一般化するのでもなく、評価の物差しが一段細かくなったと読むのがしっくりきます。

安全性レベルとML-KEM-512/768/1024

実務の選定では、抽象的な「強そう」より、標準化された安全性レベルを見るほうが話が早く進みます。
NIST系の整理では安全性レベル1・3・5が使われ、目安としてそれぞれAES-128AES-192AES-256相当の強度に対応します。
格子暗号の鍵共有標準であるML-KEMも、この枠に合わせて3つのパラメータを持ちます。

ML-KEM-512はレベル1、ML-KEM-768はレベル3、ML-KEM-1024はレベル5です。
サイズも順に増え、公開鍵は800バイト、1,184バイト、1,568バイト、秘密鍵は1,632バイト、2,400バイト、3,168バイト、暗号文は768バイト、1,088バイト、1,568バイトです。
強度を上げるほど、通信量と保持サイズの負担も増えるという、暗号ではおなじみのトレードオフがここでも見えます。

この差は、プロトコルに入れた瞬間に体感へ落ちてきます。
たとえばTLSハイブリッドのX25519MLKEM768では、クライアントのkey share部分だけで1,216バイトになります。
ML-KEM-768の公開鍵1,184バイトにX25519の32バイトが載るからです。
薄い封筒にもう一冊書類を差し込む、というこの記事の冒頭の感覚は、ここで数字になります。
CPU時間だけを見ると極端な差が出ない場面でも、通信の最初の一往復で荷物が増える、という現象は確かにあります。

標準化後の現実を見ると、汎用の既定値としてはML-KEM-768が扱いやすい落としどころになりやすく、より高い安全余裕を求める場面ではML-KEM-1024が視野に入ります。
反対に、帯域やサイズ制約を優先する文脈ではML-KEM-512の意義も残ります。
ここでも「どれが最強か」ではなく、必要な安全性レベルと払うコストを対応づけるのが基本です。
格子暗号の強みは確かに魅力的ですが、選定の言葉はつねに「絶対」ではなく「既知の攻撃研究と標準パラメータの範囲で、どの余裕を買うか」に置いておくのが実務的です。

実装と運用の現実——TLS、IoT、サイドチャネル

TLS 1.3ハイブリッド鍵共有の現状

理論の話を実際の通信に落とすと、いま最も現実味がある入り口はTLS 1.3のハイブリッド鍵共有です。
現在の実装・相互接続で中心にあるのは、楕円曲線の鍵共有とML-KEMを並べて使う形で、候補としてX25519MLKEM768SecP256r1MLKEM768SecP384r1MLKEM1024が整理されています。
ここで押さえたいのは、これはすでに広く検証が進んでいる一方で、規格上はまだIETFのドラフト段階だという点です。
現場で触れる機会が増えていても、名前や符号化の細部が将来固定されるまでは、実装追従の余地が残っています。

ハイブリッドと呼ぶ理由は単純で、従来の楕円曲線だけに賭けるのでも、ML-KEMだけに振り切るのでもなく、両方の共有秘密を組み合わせるからです。
移行期の設計として筋がよく、既存の運用資産を活かしながら量子計算機への備えを混ぜ込めます。
前のセクションで見た安全性レベルの話が、ここでは「どのグループ名を有効にするか」という設定値に変わります。

筆者が最初にこの変化を実感したのは、パケットキャプチャでClientHelloを眺めたときでした。
従来のトレースでは先頭の握手メッセージが比較的すっきり見えるのに、ハイブリッド鍵共有を入れると、その最初の一通が目に見えて太くなります。
画面上ではほんの少し行が増えるだけなのですが、Wireshark の詳細ペインで key_share を開いた瞬間、薄い封筒にもう一束書類を差し込んだような印象になります。
X25519MLKEM768ではクライアント側の share だけで 1,216 バイトになり、ここに他の拡張が重なるので、実装者の感覚としては「鍵交換アルゴリズムを替えた」より「最初の挨拶が一段ふくらんだ」が近いです。

KEMと署名の層を区別する

PQC の運用議論で混線しやすいのが、鍵共有と署名をひとまとめに見てしまうことです。
しかしTLS 1.3では、この二つは別レイヤです。
接続ごとに前方秘匿性を持つ共有秘密を作る層と、証明書で相手の正当性を示す層は役割が違います。
ここを分けておかないと、「ML-KEM を入れたから証明書も耐量子化された」といった誤読が起きます。

図にすると、頭の中は次のように整理できます。

[TLS 1.3 ハンドシェイク]

鍵共有の層
  クライアント <---- ハイブリッド key_share ----> サーバ
  例: X25519 + ML-KEM-768
  役割: セッション鍵の材料を作る

認証の層
  サーバ証明書 ---- 署名アルゴリズム ----> クライアントが検証
  例: ECDSA / RSA / ML-DSA
  役割: この公開鍵の持ち主が本当にその相手かを示す

この整理に従うと、ハイブリッド鍵共有で使うのは KEM、つまりML-KEMです。
一方、証明書やコード署名の文脈で出てくるのは DSA、つまりML-DSAです。
名前が似ているので一緒に見えますが、交換するデータも、呼ばれるタイミングも、最適化の勘所も違います。
実務では「TLS の PQC 対応」と言ったとき、まず鍵共有だけをハイブリッド化し、証明書署名は従来方式のまま維持する段階がありえます。
反対に、証明書側だけをML-DSAへ寄せても、セッション鍵共有が古典方式だけなら、そこは別の話です。

ML-DSAのサイズ感もこの層分離を理解すると読みやすくなります。
たとえばML-DSA-44の公開鍵は 1,312 バイト、署名は 2,420 バイト、ML-DSA-65では公開鍵 1,952 バイト、署名 3,293 バイトです。
証明書チェーンや署名付きオブジェクトに載るデータが増える、という意味でのコストであり、ハイブリッド key_share が太る話とは別の場所で効いてきます。

通信量増加とレイテンシのトレードオフ

運用で最初に効いてくるコストは、CPU というより通信量です。
ここが直感に反するかもしれませんが、鍵演算そのものは近年の実装でよく詰められていて、TLS 全体のハンドシェイク時間ではアルゴリズム差が支配的にならない場面が多くなっています。
むしろ支配的なのは、最初のメッセージが太ることによる送受信コストです。
とくにClientHelloは接続の入口なので、ここで荷物が増えると、パケット分割や再送制御や無線区間の都合まで含めて、じわじわ効いてきます。

ハイブリッド鍵共有の代表例であるX25519MLKEM768では、key_share の中身だけで 1,216 バイトです。
従来のX25519単独と比べると、「少し増える」ではなく、目で見てわかる単位の増分です。
実際のハンドシェイク全体では、構成によっては増分がさらに積み上がります。
サーバやクライアントの CPU が苦しむというより、ネットワークの細い部分、パケット境界、モバイル回線の立ち上がりで負担が見えやすい構図です。

この傾向は、CDN や大規模トラフィックを扱う事業者の現場感覚とも一致しています。
PQC 化したときに「計算が重くて回らない」より先に、「ハンドシェイクが太って帯域と往復の印象が変わる」が問題になります。
人間が触る Web では、サーバ CPU の数ミリ秒より、最初の数キロバイトがどう運ばれるかのほうが体感に近いからです。
ブラウザでページを開く場面では、計算コアの中より、電波や回線と会話する部分が待ち時間を作ります。

もちろん、通信量が増えること自体は欠点だけではありません。
移行期に古典方式と耐量子方式を重ねて守る以上、どこかで二重化のコストを払う必要があります。
そのコストが、現時点では計算時間より通信量として現れやすい、というだけです。
サーバ集約型の環境では CPU 余力で吸収できても、細い無線区間や高遅延リンクでは、増えたバイト数がそのまま存在感を持ちます。

IoT/組み込みでの性能傾向と注意点

IoTや組み込みでは、このトレードオフがもっと露骨に見えます。
小さな MCU では計算も通信も電力に直結するので、アルゴリズム選定が仕様書の一行では済みません。
鍵共有の層では、Kyber由来のML-KEM系が高効率な主力です。
既存の Cortex-M 系向け最適化でも、この系統は実装が進んでいて、接続確立に使う KEM として扱いやすい位置にいます。
署名の層では、署名サイズだけを見るとFalconが小さい傾向で、Falcon-512は公開鍵 897 バイト、署名 690 バイト、Falcon-1024でも署名 1,330 バイトに収まります。
署名サイズだけ比べると、ML-DSAより送信データを抑えやすい構図がはっきり出ます。

ただし、ここで「IoT なら Falcon 一択」とはなりません。
署名サイズが小さいことと、実装や検証が楽なことは別です。
Falconは小さな署名を実現する代わりに、実装面では気を遣う点が多く、浮動小数点や数値処理の扱いも設計に入ってきます。
反対にML-DSAは署名が大きくなるぶん、汎用的な署名候補として整理しやすい。
どちらが得かは、送る回数、受ける回数、保存期間、通信方式まで含めて決まります。

筆者が設計レビューで現実味を感じるのは、低消費電力デバイスが「送るより受ける」側に回る場面です。
たとえばセンサーやメータのような機器が、たまに更新パッケージの署名を検証するだけなら、署名生成の速さより検証時の処理と通信量が効きます。
逆に、電池で長く持たせたい端末が何度も大きな署名付きメッセージを受け取る設計だと、検証時間そのものに加えて無線を起こしている時間が積み重なり、残量表示の減り方に現実感が出ます。
机上では「数キロバイトの差」でも、スリープから起きて受信し、検証して、また眠る流れに置くと、その差は急に装置の性格になります。

ここでの要点は、組み込みでは 鍵共有と署名で最適解が分かれる ことです。
鍵共有にはML-KEM系、署名には用途に応じてML-DSAかFalconを検討する、という分離がまず効きます。
さらに、同じデバイスでも、ファーム更新の署名検証、クラウド接続の TLS、ローカル無線の認証では求める性質が違います。
消費者向け IoT の研究でも、PQC の実行時間はアルゴリズムと接続方式の組み合わせで最大 12 倍ほど振れるので、「PQC は重い」「この方式が速い」と一語で片付けると設計判断を外します。

サイドチャネル対策と乱数品質

運用へ移すとき、もう一つ切り分けておきたいのがサイドチャネルです。
格子暗号が数学的に有力であることと、実装がタイミング漏えい・電磁漏えい・キャッシュ観測に耐えることは別問題です。
ここは古典暗号でも同じでしたが、PQC では新しい実装が増えるぶん、なおさら分離して考える必要があります。
アルゴリズム名だけ見て安心してしまうと、守るべき場所を外します。

とくに KEM の復号や署名処理では、分岐、メモリアクセス、失敗時の扱いが観測差になりえます。
乱数品質も同様で、方式の安全性証明がきれいでも、生成される乱数が弱ければ話が崩れます。
ML-KEMやML-DSAを選んだから乱数設計まで自動的に正しくなるわけではありません。
暗号の美しいところは、数学と実装が噛み合って初めて全体が成立する点にありますが、裏を返すと、片方だけ整っても不足します。

現場の指針としては、標準準拠で、検証の積み重ねがある実装を使うことに尽きます。
自作最適化や未検証の移植版は、速度の数字がよく見えても、サイドチャネル耐性や例外処理で落とし穴を抱えがちです。
とくに組み込みでは、メモリ節約のために入れた小さな変更が、分岐やアクセスパターンの差として漏れます。
乱数源も、OS 任せにできるサーバと違い、デバイス起動直後のエントロピー確保まで設計対象になります。

この観点では、PQC 移行は「RSA を ML-KEM に置き換える」だけの話ではありません。
鍵共有、署名、証明書、実装検証、乱数、サイドチャネルを層ごとに分けて見たときに、初めて運用の輪郭が揃います。
理論から現場へ降りてくる瞬間の難しさはここにありますし、同時に、暗号技術が単なる数式で終わらない面白さもここにあります。

今後の見通し——格子暗号は本命だが唯一の答えではない

バックアップKEMの位置づけ

現時点での主力が格子系であることは動きません。
鍵共有ではML-KEM、署名ではML-DSAが軸になり、実装・検証・相互接続の蓄積もこの流れに沿って進んでいます。
ただ、ここで「格子暗号が標準化されたのだから、他方式は脇役で終わり」と読むと全体像を外します。
耐量子暗号の運用は、単一方式への一点集中より、主力と代替をどう並走させるかで安定性が決まるからです。

その意味で押さえておきたいのが、非格子系 KEM のバックアップ方策です。
HQCはその代表で、2025年に追加の標準化対象として選ばれました。
位置づけは「格子の代わりに今すぐ全面切替する新しい本命」というより、KEM の選択肢を一系統に閉じないための保険と見るほうが実務に沿います。
安全性の土台が異なる方式を手元に持っておくことには、理論面でも運用面でも意味があります。
ある系統に解析上の懸念や実装上の癖が見つかったとき、設計全体を止めずに次の手を打てるからです。

署名側でも同じ発想が成り立ちます。
格子系のML-DSAが汎用署名の中心である一方、ハッシュベース署名のSLH-DSA（FIPS 205）は、前提とする安全性が異なる別軸として価値があります。
署名サイズや運用上の取り回しは軽くありませんが、長期保存や制度要件が絡む場面では、こうした「性質の違う方式」を併走させる意味がはっきりします。
ここが暗号の美しいところなのですが、強い方式を一つ決めて終わるのではなく、異なる困難性に分散させること自体が防御層になるのです。

ハイブリッド移行と暗号アジリティ

移行の実務では、純粋な耐量子方式へ一足飛びに移るより、古典方式と P QC を重ねるハイブリッドが当面の現実路線です。
TLS 1.3でもX25519MLKEM768SecP256r1MLKEM768SecP384r1MLKEM1024のような組み合わせが整理され、既存インフラを活かしながら段階的に置き換える道筋が見えています。
前述の通り、ここで目立つコストは計算より通信側に出やすく、設計上は「どこで二重化し、どこで単独化するか」の線引きが要になります。

筆者が設計レビューでよくやるのは、証明書の有効期限を起点にした小さな移行演習です。
たとえば有効期限を2年で回している PKI なら、次回更新の時点でハイブリッド証明書やハイブリッド鍵共有にどこまで対応できるかを、CA、終端装置、ライブラリ、監視系まで並べて見ます。
すると「アルゴリズムは入れられるが、中継機器が新しい拡張を落とす」「サーバは対応できても、証明書配布の運用手順が追いつかない」といった、本当に詰まりやすい場所が早い段階で見えてきます。
机上では一行の“PQC 対応”でも、更新周期に沿って書き出すと、次回更新でハイブリッド、次々回で単独方式を視野に入れる、といったロードマップに自然に分解されます。

このとき鍵になるのが、暗号アジリティです。
要するに、アルゴリズムを固定値として埋め込まず、差し替え可能な前提でシステムを組む姿勢です。
KEM と署名を層ごとに入れ替えられること、証明書や鍵交換の候補を複数持てること、失効や更新の運用が特定方式に縛られないことが、移行の摩擦を下げます。
NISTの移行計画でも、2030年から2035年にかけて量子脆弱な公開鍵暗号を段階的に外していく方向が見えている以上、「今選ぶ方式が永遠に固定」と考える設計は持ちません。
むしろ、今は主力の格子系を採りつつ、将来の差し替え余地を残すほうが長持ちします。

ユースケース別の選択指針

方式選定は、結局のところ用途で決まります。
Web/TLSでは、鍵共有の主軸はML-KEM系で、移行期はハイブリッドが基本線になります。
人間が操作する通常の Web 接続では、実測上もハンドシェイク全体の遅延差は大きくなく、通信量の増分をどう扱うかが論点になります。
実運用ではML-KEM-768級を中心に見ておくと、互換性と安全性のバランスを取りやすい場面が多い、という整理になります。
クラウドや CDN でもこの方向が先行しており、2025年時点ではCloudflareが人間起点トラフィックの過半を P QC 保護下に置いた段階まで来ています。

メールは少し性格が違います。
配送経路の TLS だけでなく、保存時の暗号化や署名の寿命が絡むからです。
短期の配送保護なら Web と同じくハイブリッド移行が馴染みますが、あとから解読されると困る情報を長く持つ用途では、鍵共有と署名を分けて考えたほうが整理できます。
KEM はML-KEM系、署名はML-DSAを中心にしつつ、長期検証を意識する場面ではSLH-DSAのようなハッシュベース署名を候補に残す、という構えです。

長期アーカイブでは、その考え方がさらに濃くなります。
今この瞬間の性能より、何年後に検証可能性をどう維持するかが支配的です。
ここでは格子系だけで閉じない設計が効きます。
暗号方式そのものの冗長化に加え、再署名や再暗号化を前提にした運用を組み合わせることで、「一度選んだ方式に未来を賭けきらない」構図が作れます。
格子暗号が本命であっても、長期保存では唯一解として扱わないほうが筋が通ります。

IoTでは、鍵共有と署名の最適点がもっと分かれます。
接続確立にはML-KEMが有力でも、署名は通信回数と保存量で見え方が変わります。
たとえば更新パッケージをたまに検証する機器なら、ML-DSAの汎用性が勝ちやすい。
帯域が細く署名を何度も運ぶ設計では、Falconの小さな署名が魅力になります。
ここに非格子バックアップをどう残すか、どこまでハイブリッドを続けるかを重ねて考えると、同じ「PQC 対応デバイス」でも中身はずいぶん違ってきます。
消費者向け IoT の研究で、PQC の実行時間がアルゴリズムと接続方式の組み合わせで最大12倍ほど動くという結果が示す通り、用途別の切り分けを怠ると設計全体が鈍くなります。

この先の見通しとして自然なのは、格子暗号が主力として広がり、非格子方式がバックアップと特定用途で存在感を保ち、現場ではハイブリッドと暗号アジリティがしばらく続く、という姿です。
一本化より多層化、即時置換より段階移行という流れで眺めると、今起きている標準化と実装の動きがきれいにつながります。

導入の実務チェックリスト

前提整理と影響範囲の棚卸し

導入の出発点は、「何を入れ替える話なのか」を狭く正確に捉えることです。
PQC への移行は暗号全体の総入れ替えではなく、中心になるのは公開鍵暗号の置き換えです。
TLS の鍵共有、証明書まわりの署名、社内 PKI、コード署名、端末登録、秘密情報のラップなど、公開鍵を使っている場所が主戦場になります。
対して、共通鍵暗号のAESやハッシュのSHAは、そのまま土台として残る部分が多く、設計レビューでも切り分けて考えたほうが混乱しません。

この切り分けを曖昧にすると、議論がすぐに「全部変えるのか」という誤解へ流れます。
実務では、まずML-KEMは鍵共有の役割、ML-DSAは署名の役割、と機能を二つに分けて見たほうが全体像が立ち上がります。
TLS なら前者はハンドシェイクの共有鍵確立、後者は証明書やソフトウェア配布の真正性確認に関わります。
名称を覚えること自体より、自組織のどの系統にその役割が埋め込まれているかを言語化することが先です。

筆者が現場で有効だと感じているのは、自社システムの“公開鍵マップ”を一枚の図に描く作業です。
外部公開されている系、長期秘匿が必要な系、更新が容易な系という三つの観点で色分けすると、着手順が急にはっきりします。
たとえば、インターネット向けのTLS終端は露出が高いので優先度が上がりますし、保存期間の長い契約文書や医療・研究データの保護は「今盗まれて後で解読される」前提で前倒しに入ります。
逆に、ファーム更新が年単位でしか回らない機器群は、影響は小さく見えても移行の手戻りコストが大きいので、早い段階で設計枠だけでも確保しておく価値があります。

この棚卸しでは、台帳を細かくするより「どこに公開鍵暗号が潜んでいるか」を漏らさず出すことが効きます。
典型的には、公開 Web、API ゲートウェイ、リバースプロキシ、メール配送、VPN、社内 CA、クライアント証明書、コード署名、デバイス証明書、HSM や KMS の鍵ラップ、バックアップ鍵のエスクローが対象です。
公開鍵は目に見えるTLSだけにあるわけではなく、認証基盤と鍵管理の裏側にも広く散っています。
ここが暗号の美しいところなのですが、表面は別々の仕組みに見えても、下では同じ種類の数学的前提に依存している場面が多いのです。

設計：ハイブリッドとアジリティ

設計段階では、移行初期から単独方式へ一直線に向かうより、ハイブリッド構成を前提に置くほうが筋が通ります。
現在の主流は、既存の楕円曲線鍵共有とML-KEMを併用し、両方の成分から共有秘密を組み立てる形です。
TLS 1.3ではX25519MLKEM768SecP256r1MLKEM768SecP384r1MLKEM1024のような組み合わせが整理されており、既存互換性と量子耐性を同時に扱える設計になっています。

このとき設計書で先に決めるべきなのは、「どの方式を採るか」だけではありません。
アルゴリズム名を設定値として扱えるか、証明書・鍵共有・署名の組み合わせを後から差し替えられるか、ロールバックと更新の運用が方式に縛られないか、という暗号アジリティの側が効いてきます。
方式そのものより、方式を交換可能な部品として扱える構造のほうが寿命が長いからです。

ML-KEMのパラメータは 3 種類あり、ML-KEM-512ML-KEM-768ML-KEM-1024で強度とコストの置き方が変わります。
安全性レベルの目安はそれぞれ 1、3、5 で、対称鍵にたとえるとAES-128AES-192AES-256相当の位置づけです。
公開鍵サイズは 800 B、1,184 B、1,568 B、暗号文サイズは 768 B、1,088 B、1,568 B と段階的に増えます。
したがって、境界装置や多数同時接続の系では、性能の議論は CPU より先に通信量とメモリ配置から始めたほうが現実的です。

筆者はレビュー時に、ハイブリッド導入後のClientHelloを紙に書き出して眺めることがあります。
X25519MLKEM768ではクライアント側の key_share だけで 1,216 B になり、従来の薄い封筒にもう一通差し込む感覚に近づきます。
CPU だけ見ていると変化が小さく見えても、ロードバランサ、WAF、ログ採取、可観測性基盤まで含めると、「どこでサイズ増分を受け止めるか」が設計課題として前面に出てきます。
短い RTT の環境では TLS 全体の遅延差は小さく収まる一方、先頭パケットの膨らみは装置構成の癖をあぶり出します。

実装：標準準拠・検証済みを使う

実装フェーズでは、標準準拠ライブラリと検証済み実装を採ることが前提になります。
ML-KEMとML-DSAは数学そのものが新しいだけでなく、符号化、乱数、エラー処理、定数時間化まで含めて成立する方式です。
ここを独自改変すると、アルゴリズム名は同じでも安全性の中身が別物になります。
とくに格子系は、サイドチャネル耐性と乱数品質が設計書の脚注では済まず、実装品質そのものに直結します。

ML-DSAは署名方式として標準化されており、用途に応じてML-DSA-44ML-DSA-65ML-DSA-87を選びます。
公開鍵サイズは 1,312 B、1,952 B、2,592 B、署名サイズは 2,420 B、3,293 B、4,595 B です。
数字だけ見ると「どれも数 KB だから同じ」と感じるかもしれませんが、コード署名、証明書チェーン、組み込み配信のように署名を何度も運ぶ系では、差がそのまま転送量と保存量に乗ります。
直感に反するかもしれませんが、実装の重さは演算時間だけではなく、バイト列として何をどれだけ配るかでも決まります。

ライブラリ選定では、FIPS 203FIPS 204に沿った実装であること、テストベクトルと相互接続の確認が取れていること、TLS や PKI の周辺部品まで含めて統合実績があることを軸に見るのが堅実です。
PoC では動いたのに本番で詰まる典型例は、鍵共有や署名本体ではなく、証明書のエンコーディング、鍵保管 API、監査ログ、ハードウェア境界との受け渡しで起きます。
実装の正しさは暗号ライブラリ一個の問題ではなく、周辺の「鍵をどう扱うか」という約束事まで含めた整合性で決まります。

独自最適化を入れたくなる場面もありますが、PQC の初期導入ではそこをぐっとこらえたほうが結果として速く進みます。
自前改造で得られる局所的な性能差より、検証済みコードをそのまま使って、ハードニング済みの乱数生成器、定数時間実装、既知の相互接続パターンを持ち込む利得のほうが大きいからです。
とくにIoTや組み込み系では、方式と接続の組み合わせで実行時間が大きく動くため、暗号本体の書き換えに踏み込むより先に、どこで鍵共有し、どこで署名し、何を毎回送るのかを設計で詰めるほうが歩留まりが高くなります。

まとめ

格子暗号は、ポスト量子暗号の中心にある有力候補です。
ただし受け止め方は「絶対安全」ではなく、いま分かっている範囲で効率的な量子攻撃が見つかっていないという前提に置くのが実務的です。
Ajtai からNTRU、LWE、そしてML-KEMML-DSAへ続く流れを、数学だけでなくTLSのハイブリッド移行、組み込み実装、サイドチャネル対策まで一本の線として眺めると、採用判断の解像度が上がります。

筆者自身、検討会では方式名の優劣を議論するだけでなく、試験環境でハイブリッドTLSを有効化し、往復遅延とハンドシェイクサイズを実際に測ってから腹落ちする場面を何度も見てきました。
自組織で次にやるべきことも同じで、まずは鍵・証明書・終端装置・更新経路の棚卸しを済ませ、検証環境でハイブリッド構成を動かし、遅延とサイズの増分を自分たちの系で確認することです。
そこで得た実測値が、移行を「話題」から「計画」に変えてくれます。