HNDL攻撃とは？今盗んで後で解読する脅威と備え

HNDL攻撃（Harvest Now, Decrypt Later）は、今は読めない暗号化データをいま集めて保存し、将来の計算能力であとから解読する攻撃です。
社内向けのセキュリティ勉強会で「量子はまだ先でしょ？」という反応を聞いたとき、筆者も最初は同じ感覚でしたが、「読める日」ではなく「集める日」がもう始点なのだと考えた瞬間、この脅威の輪郭が一気に現実のものになりました。

この記事は、HNDLを1〜2文で説明できるようになりたい人と、PQC移行をなぜ今から考えるのか腹落ちさせたい実務担当者に向けた内容です。
焦点になるのは、将来まで価値が残るデータは今日の通信や保存時点で狙われうること、そして対策は量子計算機の到来待ちではなく、保護期間の長い情報を見極めながら暗号の棚卸しと移行準備を先に進めるべきだという点です。
（詳しくはHNDL攻撃とは何かセクションへ、実務向けの手順は棚卸しのやり方を参照）

HNDL攻撃とは何か——今盗んで後で解読するという発想

用語と構図の確認

HNDLはHarvest Now, Decrypt Laterの略で、日本語では「今収穫し、後で解読する」と表現されます。
名前の通り、攻撃の核心はいま読めるかどうかではなく、いま集めておく価値があるかどうかにあります。
通信の途中で抜き取った暗号化データや、侵害した環境から持ち出した暗号化済みファイルを保存しておき、将来の計算能力や新しい解読手法で中身を読む、という時間差のある脅威モデルです。

図にすると、頭の中ではこんな流れになります。
まず今日、攻撃者が暗号化された通信や保存データを集めます。
次に、その時点では読めなくても倉庫に寝かせるように保管します。
そこから数年後、量子計算機の実用化や数学的手法の進展、あるいは実装上の弱点発見が起きた時点で、保管していたデータに再挑戦する。
HNDLはこの「収集」と「読む」を時間で切り離す発想です。

ここで一度、短い想像実験をしてみてください。
今日の自分のブラウザが張ったTLSセッションの、あの暗号化された中身が、そのままUSBドライブに入って10年後の机に置かれている場面です。
いまの自分にはただの意味不明なビット列でも、10年後の計算能力から見ると、封筒の糊が乾くのを待っているだけの手紙かもしれません。
この情景を思い浮かべると、HNDLが「未来の話」ではなく「今日の取得行為から始まる話」だと腑に落ちます。

保管期間の想定は文献や業界資料で幅がありますが、実務上の目安としては3〜10年程度というレンジで議論されることが多く、必ずしも厳密な統計値ではありません（複数の解説・業界資料による整理）。
したがって「いま解けないので安全」と単純に結論づけることは妥当ではありません。

復号（decryption）と解読（cryptanalysis）の違い

この話題では、日本語の「読む」という一語で片づけると輪郭がぼやけます。復号と解読は、似て見えて役割が違います。

復号（decryption）は、正当な受信者や利用者が、正しい鍵を使って暗号文を平文に戻す操作です。
たとえばブラウザとサーバがTLSで通信するとき、双方は手順に従ってセッション鍵を共有し、その鍵で通信内容を読める状態に戻します。
これは鍵を持っている当事者の正規の動作です。

一方の解読（cryptanalysis）は、鍵を持たない第三者が、暗号方式の性質や計算能力、実装上の弱点を使って中身を読もうとする行為です。
HNDLで攻撃者が狙っているのはこちらです。
つまり「あとで復号する」のではなく、正確には「あとで解読できる条件がそろうのを待つ」です。
この違いは、言葉の選び分け以上に、脅威の理解そのものに関わります。

量子計算の文脈でよく出てくるShor’s algorithmは、この「解読」の側に立つ概念です。
1994年に提案されたこのアルゴリズムは、素因数分解や離散対数問題を多項式時間で解ける可能性を示し、RSAやECCの安全性の土台を揺らします。
TLSで広く使われてきたECDHEの鍵共有は楕円曲線離散対数問題に依存しているため、理論上は将来の量子計算で破られうる、という話はここにつながります。
金融分野の整理でも、HNDLはTLSの鍵共有に効きやすく、認証には同じ意味では効きにくいと切り分けられています。
攻撃対象が「TLS全部」なのではなく、「どの暗号機能に依存しているか」で影響範囲が変わるわけです。

共通鍵暗号は少し事情が違います。
こちらではGrover’s algorithmのように総当たり探索を平方根的に加速する議論が中心で、AES-256なら量子攻撃下でも古典計算のAES-128相当の強度を見込める、という整理になります。
つまりHNDLは「量子が来たら全暗号が一斉に消える」という話ではありません。
どの場面で公開鍵暗号が使われ、どこで共通鍵暗号が使われているかを分解して見ると、リスクの立体感が見えてきます。

証拠が見えにくい脅威モデルという性質

HNDLが厄介なのは、派手な被害画面が出ないことです。
ランサムウェアのようにファイルが突然開けなくなるわけでも、アカウント乗っ取りのようにその場で不審な操作が見えるわけでもありません。
攻撃者の理想形は、暗号化されたデータを静かに集め、静かに持ち帰り、静かに保存することです。
被害が表面化するとしても、それは何年も後、別の計算環境で読まれた時点かもしれません。

それでも、本件は脅威モデルとして軽視できません。
公開されている個別の公表事例が相対的に少ないのは、暗号化データの取得や保管が検出されにくいという観測上の難しさが背景にあると、複数の研究・報告が指摘しています（例: NIST/NCCoE、金融庁報告書など）。
実際の被害が統計上に現れにくいという構造があるのです。
複数の報告は、公開された個別の公表事例が相対的に少なく見える背景には、暗号化データの取得・保管が検出されにくいという観測上の難しさや業種ごとの報告差があると指摘しています（例: NIST/NCCoE、金融庁報告書）。
したがって「公表事例が少ない＝発生が少ない」と単純に結論するのは妥当ではありません。
読者が日々使うChromeやSafariで張るTLS通信も、見た目には南京錠のアイコンひとつです。
けれどHNDLの視点を通すと、その南京錠は「いま誰にも開けられない箱」ではなく、「いまは開かないが、保管しておく理由がある箱」に見えてきます。
脅威の本体は侵入の派手さではなく、時間を味方につけることにあります。
ここを理解すると、なぜ暗号の棚卸しやPQC移行が“量子計算機が完成してから”では遅いのか、その理由が具体的な風景として立ち上がってきます。

なぜ未来の脅威が、現在のリスクになるのか

長期秘匿データの具体例

HNDLの本質は、量子コンピュータが完成する瞬間そのものではありません。
焦点になるのは、長期秘匿が必要なデータが存在することと、そのデータが今から収集されうることの2点です。
ここを取り違えると、「実用的な量子機はまだ先だから、今は関係ない」という見方になってしまいます。
けれど現場で扱う情報を思い浮かべると、数年では価値が消えないものは驚くほど多くあります。

代表例は、医療情報、金融情報、知的財産、個人識別情報、国家機密です。
医療の世界では、診療録や検査結果だけでなく、CTやMRIの画像データまで長く残ります。
病院の保管庫やサーバ室を想像すると、ひとりの患者について積み上がる記録は、今日の診察メモだけで終わりません。
10年以上たっても、既往歴や遺伝的な傾向、治療履歴は本人に結びついたまま意味を持ち続けます。
いまは暗号化されていて読めなくても、将来それが読まれれば、保険の扱い、雇用での選別、見えにくい差別の材料へと姿を変える。
筆者はこの種のデータを考えるとき、流出直後の騒ぎより、時間がたってから静かに効いてくる後味の悪さのほうにむしろ怖さを覚えます。

企業では、研究開発データの長寿命ぶりが目立ちます。
仕様書、配合情報、設計図、試験結果、未発表特許のドラフト、取引先との共同研究メモ。
こうした文書は、発表前でも、製品化後でも価値を持ちます。
しかも厄介なのは、それらが特別な金庫の中だけにあるわけではないことです。
新材料の評価レポートを社外パートナーにメールで送る、試作品の仕様変更案を暗号化された添付ファイルで共有する、未公開の特許草案を法務と開発のあいだでやり取りする。
どれも珍しい場面ではありません。
今日の一通のメールはただの日常でも、数年後に競合へ読まれれば、先回りの開発や模倣の精度が上がり、積み上げてきた競争優位がじわじわ削られます。

攻撃者が暗号化データを数年単位（3〜10年程度）で保管するというのは、業界解説や実務的ガイドでしばしば示される実務上の目安です。
ここで示す年数はあくまで目安であり、用途や業界ごとに変わり得る点に留意してください。

収集チャネルと保存のリアリティ

では、その「今から収集されうる」は、どこで起きるのでしょうか。
ここも映画のような派手な侵入より、日常の延長線にある経路を思い浮かべたほうが実態に近づきます。
保管期間の想定については文献や業界資料で差があり、実務上は3〜10年程度を目安に議論されることが多い点を念頭に置いてください。
ひとつは、ネットワーク上を流れる暗号化通信です。
TLSで守られた通信は、今日のインターネットでは当たり前の風景ですが、HNDLの文脈ではこの暗号化トラフィック自体が保存対象になります。
とくに公開鍵暗号に依存する鍵共有の部分は将来の量子計算の影響を受けるため、セッションのやり取りを録音するように残しておく発想が成立します。
金融分野の整理でも、HNDLが効きやすいのはTLSの鍵共有です。
南京錠のアイコンは「安全に届いた」の印であると同時に、「価値のある暗号文が流れている」印でもあります。

もうひとつは、クラウドや社内ストレージに置かれた暗号化済みデータです。
Amazon S3のようなオブジェクトストレージを連想してもいいですし、社内のファイルサーバやバックアップアプライアンスでも構いません。
侵害された環境から暗号化ファイルをごっそり持ち出す手口は、HNDLでもそのまま通用します。
攻撃者に必要なのは、その場で読めることではなく、あとで再挑戦できる形で保管することだからです。
平文の窃取より発見が遅れやすい場面もあり、ここが時間差攻撃と相性よく噛み合います。

メールも見逃せません。
Microsoft 365やGoogle Workspaceのような業務基盤では、添付ファイルや本文のやり取りが長く残ります。
開発部門が社外へ送る仕様書、病院間で共有される紹介状や画像、法律事務所と企業のあいだを往復するドラフト。
送信時はTLSで保護され、保存時も暗号化されていても、通信の取得と保存データの持ち出しの両方が視野に入ります。
HNDLはひとつの穴から入るというより、通信、保存、バックアップの複数の経路で「収穫」できるものを少しずつ集めるイメージで捉えると、輪郭がはっきりします。

見えない被害という時間差

HNDLが厄介なのは、攻撃の成否が今日の画面に現れないことです。
攻撃者の仕事は、収穫して保存した時点で半分以上終わっています。
そこから先の解読は、数年後でも、十数年後でも成立しうる。
この時間差があるため、被害は今は見えにくくなります。

通常の情報漏えいなら、流出直後に不正送金、不審ログイン、公開サイトでの暴露といった形で兆候が出ます。
HNDLではそこが空白になりえます。
今日抜かれたTLSセッションの記録も、今日持ち出された暗号化バックアップも、その時点では「読まれていない」ため、事故の重みが過小評価されがちです。
けれど数年後、過去の医療データが個人の属性推定に使われたり、昔の研究資料が競争相手の開発を後押ししたりしても、被害の起点はもう見えません。
まるで時限式の漏えいです。
爆発音は未来に鳴るのに、仕掛けは今日置かれています。

この時間差のせいで、組織は「今起きている事故」として認識しにくくなります。
盗まれたのが暗号文である以上、担当者の心理としてはどこかで一度安心してしまうからです。
筆者も最初はそこに引っかかりました。
封が閉じている手紙なら、持っていかれてもまだ読まれていない、と考えたくなるのです。
ただHNDLでは、その封筒が何年も保管される前提で話が進みます。
しかも、封を切る道具は相手の未来にあります。
現在の安全確認だけでは測れない理由はここです。

だからこそ、未来の脅威が現在のリスクになります。
問題の中心は「量子計算機がいつ完成するか」ではなく、「完成まで秘密であり続けなければならないデータを、今も大量に扱っている」という事実です。
保護期間が長いデータを今日送っている、今日保存している、今日バックアップしている。
その時点で、HNDLはもう現在進行形のリスクとして成立しています。

どの暗号が危うく、どこは比較的残るのか

公開鍵暗号（RSA/ECC）が直撃を受ける理由

量子時代の暗号リスクを整理するとき、まず軸になるのはRSAやECCのような公開鍵暗号が主な懸念対象だという点です。
ここを取り違えると、「量子コンピュータが来たら暗号は全部一斉に無効になる」という雑な理解に流れてしまいます。
実際には、同じ暗号でも受ける打撃の質が違います。

RSAは整数の素因数分解の難しさ、ECCは楕円曲線上の離散対数問題の難しさに安全性を置いています。
ところが、1994年にPeter W. Shorが示したShor's algorithmは、こうした問題を量子計算で多項式時間に持ち込める道筋を与えました。
平たくいえば、古典計算機では「気が遠くなる探索」が必要だった問題に、量子計算機は別ルートの近道を作ってしまう、ということです。

この影響が大きいのは、公開鍵暗号がインターネットの入口と出口を握っているからです。
TLSの鍵共有、サーバー証明書、コード署名、メール署名、JWTやSAMLの署名検証、社内PKIの証明書運用まで、現代の認証基盤は公開鍵暗号の上に立っています。
HNDLの文脈でとくに神経を使うのは、あとから解ける可能性がある形で記録が残る部分です。
前のセクションで見た「今集めて、後で読む」がそのままはまり込むのが、まさにこの層です。

筆者が読者にいちばん勧めたい小さなハンズオンは、ブラウザで実際に証明書情報を開いてみることです。
ChromeやEdgeで鍵アイコンまわりから証明書をたどると、「署名アルゴリズム」が見えますし、開発者ツールや接続情報を追うと、どの鍵共有方式が使われているかも見えてきます。
ここで「署名アルゴリズム」と「鍵交換方式」を見比べると、同じTLSの中でも役割が違うことが手触りとしてつかめます。
暗号はひとまとめの黒箱ではなく、玄関の鍵、身分証、部屋の内鍵が別々に動いているような構造だ、と自分の目で確かめられます。

共通鍵暗号（AES等）の影響は鍵長見直しで緩和可能

公開鍵暗号に比べると、AESのような共通鍵暗号は事情が異なります。
こちらに関係するのはGrover's algorithmで、未構造探索を平方根ぶんだけ速める性質があります。
暗号の話に置き換えると、鍵長がkビットなら総当たり探索の計算量は古典計算で 2^k、量子計算ではおおむね 2^(k/2) に近づきます。
よく「鍵長が半分になる」と表現されるのはこのためです。

ただし、ここでのポイントはShor型の崩れ方とは別物だという点です。
RSAやECCでは、前提にしていた数学的な難しさそのものが崩されます。
AESでは「総当たり探索が速くなる」方向の影響で、構造ごとひっくり返るわけではありません。
だから「量子コンピュータが来たらAESも全部終わり」という話にはなりません。

体感でつかむなら、AES-256は量子攻撃下で古典計算のAES-128相当の探索コストに近づく、と考えると整理しやすくなります。
逆にいえば、共通鍵暗号の側は鍵長の見直しで守りを立て直せる余地があるということです。
長期秘匿を前提にするデータでAESを使うなら、鍵長の選択がそのまま量子時代の保険になります。
ここが公開鍵暗号との大きな違いです。

映画の金庫にたとえるなら、公開鍵暗号は「錠前の仕組み自体が研究され、正規の手順を飛ばして開けられる」タイプの危機です。
共通鍵暗号は「総当たりで回すダイヤルの回転が速くなる」タイプです。
どちらも脅威ではありますが、対処の発想は同じではありません。
前者は方式の置き換えが中心になり、後者は鍵長や運用条件の再設計が主役になります。

TLSでの鍵共有と認証の影響差

HNDLを考えるうえで見落とされがちなのが、TLSの中でも鍵共有と認証では量子的な影響の出方が違うことです。
金融庁が2024年11月26日に公表した報告書でも、HNDLはTLSの鍵共有に特に効く一方、認証への影響は相対的に小さい、という整理が置かれています。
この差を雑に読むと混乱しますが、意味を分解すると筋が通ります。

TLS 1.3の主流では、セッション鍵の共有にECDHEが使われます。
これは楕円曲線離散対数問題に依存するため、Shorの影響を正面から受けます。
攻撃者が今日のハンドシェイクを保存しておき、将来、量子計算でその鍵共有部分を解けるようになれば、当時の通信内容をあとから復元できる可能性が出ます。
HNDLが「通信の録音」と相性がいいのはここです。

一方、サーバー証明書の署名は認証の役目です。
これは「この公開鍵はこのサーバーのものだ」と結び付けるための仕組みで、通信内容そのものを暗号化するセッション鍵とは役割が違います。
だから、過去に保存されたTLS通信をあとで読むという観点では、まず問題になるのはECDHEのほうです。
証明書の署名がすぐ過去の通信の平文化に直結するわけではありません。
この点が「認証への影響は比較的小さい」と表現される背景です。

もちろん、認証側が無傷という意味ではありません。
将来、量子耐性のない署名方式に依存し続ければ、証明書発行やソフトウェア署名、組織内の信頼連鎖そのものに移行課題が生じます。
ただ、HNDLの文脈では「録音済み通信の後日解読」という現象に直結するのは鍵共有で、署名は別の時間軸で問題化する、と切り分けるほうが正確です。

実際に証明書情報を見るハンズオンでも、この違いはよく見えます。
画面に出てくる「署名アルゴリズム」は証明書の信頼性に関わる表示です。
いっぽう、接続で使われる鍵共有はTLSのネゴシエーションの中にあり、同じ“暗号”でも働く場所が違います。
筆者はこの2つを見比べたとき、量子リスクの説明が急に立体的になりました。
南京錠のアイコンひとつの裏に、鍵共有と認証という別々の部品が入っているとわかるからです。

この先の実務では、移行先としてのPQCが中心に入ってきます。
鍵共有や署名を耐量子方式へ置き換える流れはすでに始まっており、いきなり全面切替ではなく、従来方式とPQCを組み合わせるハイブリッド導入も現実的な選択肢です。
NISTがPQC標準化を始めたのは2016年で、今見えているのは「いつか考えるテーマ」ではなく「段階的に差し替える設計」の話です。
次の対策の話では、この移行をどう現場の順番に落とすかが焦点になります。

HNDL攻撃の流れを具体例で追う

ステップ1：収集

HNDL攻撃をいちばん直感的に見るなら、今日のTLS 1.3通信を一本の時系列ドラマとして追うのが早いです。
たとえば、ある社員が自宅から社内ポータルに接続し、人事データや契約書を閲覧したとします。
画面の鍵アイコンが点灯しているので、その瞬間のやり取りは外から読めません。
ところが攻撃者の狙いは、その場で中身を理解することではありません。
まずやるのは、通信の断片を静かに集めることです。

ここで集められるのは、メール本文のような完成品だけではありません。
TLSのハンドシェイク情報、暗号化されたアプリケーションデータ、関連するメタデータも含めて、あとで開けるかもしれない「封印済みの荷物」として持ち帰られます。
公開鍵暗号が担っている鍵共有の部分が将来崩れるなら、いま読めない記録でも保存する意味が生まれるわけです。

筆者は合法的な検証環境で社内ネットワークのパケットキャプチャを眺めたとき、この感覚を強く持ちました。
Wiresharkで保存したpcapは、その場ではただの暗号化された通信の束に見えます。
けれど、時間がたつほど見え方が変わります。
あれは単なるログではなく、未来の計算能力しだいで再生方法が変わるタイムカプセルです。
今日の会話が、封を切れないまま箱に入れられている。
その箱を誰かが倉庫に積み上げていくイメージを持つと、HNDLの「Harvest」の意味が急に生々しくなります。

しかも標的はリアルタイム通信だけではありません。
保存済みのバックアップ、メールアーカイブ、クラウド上の暗号化データも同じ発想で集められます。
いまは読めなくても、長く価値が残るデータなら、盗んでおく理由があるからです。
機密保持の目安が3〜5年以上に及ぶ情報では、この時間差攻撃と相性が悪くなります。

ステップ2：保管

収集したデータは、そこで攻撃が終わるわけではありません。
HNDLの中盤はむしろ地味で、だからこそ見落とされます。
持ち去られた通信記録や暗号化ファイルは、攻撃者の側でそのまま保管されます。
読めない資料を積んでおくなんて無意味に思えますが、HNDLではこの「寝かせる時間」こそが攻撃の芯です。

現場感覚でいえば、これは犯行というより倉庫業に近い動きです。
盗聴や窃取の直後にシステム障害が起きるわけではなく、利用者の画面にも異常は出ません。
通信はいつも通り成功し、メールも届き、VPNもつながります。
被害の手触りがないまま、暗号化データだけが静かに保存されていく。
この段階ではインシデントとして表面化しないことが多く、気づいたときには「何年分持っていかれたのか」が問題になります。

HNDLの保管期間としては3〜10年という見方が現実的です。
攻撃者にとっては、いますぐ換金できる情報だけが価値ではありません。
M&A関連文書、医療記録、設計図、長期契約、外交・行政文書のように、数年後でも意味を失わないデータは十分に標的になります。
クラウドストレージの暗号化バックアップや、退職者を含むメールアーカイブもここに含まれます。
保管媒体が最新である必要すらなく、古いストレージに残っている暗号化データも立派な獲物です。

この「すぐ使わないのに持っていく」という感覚は、ふつうのサイバー攻撃のイメージと少し違います。
身代金要求のように即日で表に出る事件とは別の時間軸で動いているからです。
だから運用側では、侵害の兆候が薄いこと自体が安心材料になりません。
静かなまま進行することが、むしろHNDLらしい振る舞いです。

ステップ3：将来の解読

物語の終盤で起きるのが、保管していた暗号化データの解読です。
ここで典型例になるのが、今日のTLS通信をあとから読むシナリオです。
たとえば、攻撃者が数年前に保存しておいたTLSセッションの記録を持っているとします。
保存当時は暗号文の山でしかなかったものが、将来、公開鍵の前提を崩せる計算能力に到達した時点で意味を持ち始めます。
ハンドシェイクで使われた鍵共有の部分が解ければ、そのセッションでやり取りされたデータを復元できる道が開きます。

この瞬間が恐いのは、「その通信は昔のものだからもう終わった話」と言えない点です。
契約交渉の文面、認証トークンを含むAPI通信、個人情報を扱った画面遷移、機密メールの添付ファイルは、数年後に読めても十分に痛い情報です。
攻撃の被害が通信当日ではなく、何年もあとに現れるので、事故の原因と結果が頭の中で結びつきにくくなります。

筆者がこの現実味を強く感じたのは、古い外付けHDDの整理をしていたときのことを思い浮かべた場面です。
ラベルの薄れたドライブを開くと、昔使っていたメールアーカイブの暗号化ファイルが出てくる。
作成した当時は「暗号化してあるから大丈夫」という感覚だったはずなのに、時間軸をHNDLに合わせると景色が変わります。
いまは閉じた箱でも、未来の解読手段が増えれば、中には当時のやり取りがそのまま残っています。
古いHDDの中身が急に現在形のリスクへ戻ってくる感覚です。

この三段階を一枚絵にすると、まず盗聴や窃取で箱を集め、次に倉庫へ積み、将来その箱をまとめて開封する流れになります。
しかも厄介なのは、最初の段階で誰も悲鳴を上げないことです。
即時被害が見えないので、担当者の画面にも経営会議の資料にも危機が映りにくい。
けれど、あとから解読された時点では、収集そのものを取り消せません。
HNDLが運用上むずかしいのは、攻撃の本体が「未来の出来事」に見える一方で、勝負はもう今日の通信と保存データの扱いで始まっているからです。

対策はPQCだけではない——いま始めるべき準備

棚卸しのやり方

HNDL対策というとPQCのアルゴリズム名に目が向きがちですが、実務ではその前にやることがあります。
どこで暗号が使われているかを把握しないまま移行の話を始めると、地図なしで配線図を書き直すようなものです。
最初の一歩は、暗号資産の棚卸し、つまり cryptographic inventory です。
対象は「証明書の台帳」だけでは足りません。
RSAECCがどこで使われているか、ECDHEで鍵共有している通信はどこか、署名はJWTSAMLコード署名文書署名のどこにあるか、どのライブラリとバージョンに依存しているかまで掘り下げてはじめて、移行の輪郭が見えます。

筆者が現場整理用に作った「暗号棚卸しのカンペ」は、凝った表ではなく、まずは一行一資産で埋める素朴な形にしています。
項目は、資産名、システム名、用途、公開鍵方式、鍵共有方式、署名方式、証明書の発行元と有効期限、使用ライブラリ、鍵保管場所、通信相手、保存データの保護期間、停止時影響、優先度ラベルの12点です。
優先度ラベルはP1: 長期秘匿かつ外部通信ありP2: 認証基盤または署名基盤P3: 内部限定だが置換に時間がかかるP4: 影響軽微の4段階にしてあります。
この形だと、読者の組織でもそのままスプレッドシートに移せます。
最初から完璧な台帳を狙うより、「どの列が空欄のまま残るか」を見るほうが、盲点の発見につながります。

棚卸しで見落としやすい場所も、あらかじめ決め打ちで洗うと進みます。たとえば次の観点です。

• 外向きWeb、API、VPN、メール、SFTPで使っているTLSの証明書と鍵共有方式
• ロードバランサ、CDN、WAF、APIゲートウェイ、サービスメッシュの終端設定
• JWTSAMLOIDCの署名アルゴリズム
• 社内PKI、端末証明書、クライアント証明書、コード署名、文書署名
• データベース接続、バックアップ暗号化、オブジェクトストレージ暗号化の実装箇所
• アプリケーションコードが呼び出す暗号ライブラリとそのバージョン
• OpenSSL系ライブラリ、JDK、各言語の暗号モジュール、HSM、KMSの利用状況
• ベンダー製品の「中で使っている暗号」の確認項目。製品名だけで安心せず、管理画面・設定ファイル・通信キャプチャまで含める
• 退職者メールアーカイブ、法定保存文書、設計図、医療・金融関連データなど長期保存対象

この作業は、暗号を「設定項目」ではなく「依存関係」として見ると進みます。
アプリ本体より、認証基盤、証明書更新ジョブ、ロードバランサ終端、ライブラリの固定バージョンのほうが移行の足かせになることがあるからです。
NCCoEのMigration to PQCでも、暗号の発見、重要度付け、優先順位付け、移行計画化という流れが前提になっています。
先に在庫を数え、そのあとで置き換える。
量子時代の話に見えて、やっていることは驚くほど在庫管理に近いです。

保護期間での優先順位付け

棚卸しができたら、次は「どこから手を付けるか」です。
ここで効くのが、データの保護期間で切る整理です。
暗号の強さだけを見ると議論が散りますが、「その情報は何年守る必要があるか」で分けると、着手順が決まります。
実務では 3年、5年、10年以上の3区分で置くと、会話が前に進きます。

3年区分には、短命な業務データや運用ログ、一定期間後に価値が下がる情報が入ります。
ここは即時の全面刷新より、まず通信経路と証明書運用の把握、将来切替できる設計への寄せが中心になります。
5年区分には、契約情報、顧客対応履歴、設計文書、重要な社内文書など、HNDLで寝かせる意味があるデータが並びます。
この層から、公開鍵暗号に依存する通信や保存系を優先対象に上げるのが自然です。
10年以上の区分になると、医療記録、金融情報、長期研究データ、知財、行政・法務関連文書のように、時間がたっても価値が落ちにくいものが主役です。
ここは「いま読めないから安全」という発想がもっとも通用しません。

筆者が実際に仕分けを考えるときは、「盗まれた当日ではなく、5年後に読まれたら困るか」で見るようにしています。
この問いに変えるだけで、優先順位が逆転する場面があります。
たとえばリアルタイム性の高い一時データより、静かに保管されるメールアーカイブやバックアップのほうが前に出てきます。
HNDLは派手な侵入シーンより、倉庫に積まれるデータの寿命が勝負だからです。

公開鍵暗号が関わるのは通信だけではありません。
署名も同じ土俵にあります。
ログイン連携、電子契約、社内承認、ソフトウェア配布、ファームウェア更新のように、署名の真正性が後年まで意味を持つ仕組みは、保護期間の長いデータと一緒に扱う必要があります。
システム単位ではなく、「長く守るべきデータ」と「それを守る暗号の経路」を対で見ると、HNDLリスクの高い順番が自然に浮かび上がります。

Crypto agility設計とハイブリッド導入

ここでようやくPQCの出番ですが、焦点はアルゴリズム名そのものではなく、切替可能な設計にあります。
crypto agility は、将来アルゴリズムを入れ替えても業務を止めずに回せる構造のことです。
量子対策の文脈で語られますが、本質は「暗号を固定値にしない設計原則」です。
APIでアルゴリズム名をベタ書きしない、証明書更新を手作業前提にしない、鍵ライフサイクルを運用で追えるようにする。
この3つだけでも、移行の難度は大きく変わります。

実装面では、まずアプリケーションから暗号実装を直接呼び出す箇所を減らし、抽象化レイヤを1枚挟む発想が効きます。
証明書運用では、発行、配布、ローテーション、失効、切替確認までを一連のフローとして扱うべきです。
鍵管理も、KMSやHSMの格納先だけでなく、生成、更新、破棄、保持期間、責任者の情報まで含めて台帳化しておくと、将来のアルゴリズム更新が「改修プロジェクト」ではなく「運用変更」に近づきます。
NISTのCSWP 39が扱っているのも、まさにこの設計上の粘り強さです。

ハイブリッド導入は、その agility を試す実地訓練としてちょうどいい位置にあります。
典型例は、クラシックな鍵共有とPQC系の鍵共有を併用するハイブリッドTLSです。
筆者がテスト環境でKyber併用の設定を有効にしたとき、体感としていちばん印象に残ったのは「見た目はほとんど変わらないのに、中で起きている鍵共有だけが入れ替わる」感覚でした。
ブラウザの鍵マークが別物になるわけでもなく、証明書チェーンが総入れ替えになるわけでもありません。
サーバ証明書やチェーンの見え方はいつもの延長線上にあって、ハンドシェイクの鍵共有部分だけが新しい層をまとっている。
この感覚を一度つかむと、移行が「全部壊して作り直す話」ではなく「経路ごとに入れ替える話」だと腹落ちします。

ただし、検証で見るべき点は明確です。
相互運用性、性能、観測性、障害時切替の4つです。
相手のクライアントや中継装置が受け入れるか、接続確立にどんな差が出るか、監視で異常を追えるか、失敗時にクラシック構成へどう戻すか。
この評価が不足すると、ハイブリッド導入は「有効化しただけ」で止まります。
AWSが示している立場も、この温度感に近いものです。
現時点でRSAECCを破る量子機は存在していない一方で、準備を先送りする理由にもならない。
拙速に本番全面移行へ走るのでも、静観を決め込むのでもなく、まず検証を始める。
この中間地点が、いちばん実務的です。

公的ガイダンスに基づく移行ロードマップ

移行計画は、技術メモではなくロードマップに落とす段階で効き始めます。
軸として使いやすいのは、NCCoE Migration to PQCの作業分解です。
暗号の発見、分類、優先順位付け、検証、導入、運用更新という流れが揃っているので、社内計画にも写し取りやすい形になっています。
これにNIST CSWP 48のマッピングを重ねると、PQC移行を個別技術の話で終わらせず、リスク管理や統制の文脈に接続できます。
つまり「誰が責任を持つか」「どの統制項目にひも付くか」「どの監査証跡を残すか」が見えてきます。

さらに、PwC Japan が整理した解説では、政府機関等のPQC移行の目安として2035年が例示されています（出典: PwC Japan の整理）。
ただしこれは複数の報告で示される目安の一例であり、正式な政府命令ではない点に注意が必要です。
ロードマップを描くなら、段階は4つに分けると扱いやすくなります。
第1段階は暗号棚卸しと保護期間分類、第2段階はcrypto agilityを要件化した改修、第3段階はハイブリッドTLSやPQC署名の検証、第4段階は調達・更新時の標準化です。
新規導入や更改案件に「アルゴリズム交換可能」「証明書更新自動化」「鍵管理台帳への登録」を入れておけば、移行は特別プロジェクトだけの仕事ではなくなります。
量子対策は、未来の一斉切替ではなく、今日の設計書と運用票の書き方にじわじわ染み込ませるものです。
ここまで来ると、PQCはゴールではなく、準備を前に進めるための具体名として見えてきます。

HNDL攻撃が投げかける問い

HNDLが突きつけているのは、暗号を「今日破られるか」で判定する見方の限界です。
問いはもっと地味で、もっと実務的です。
そのデータは、必要な年数だけ秘密でいられるか。
（注）政府機関等のPQC移行の時期については整理・解説によって目安が異なります。
たとえば PwC Japan の整理では2035年が例示されていますが、これは解説上の「目安」の一例であり、公式の政府決定ではない点に注意してください。
筆者が部門横断の打ち合わせでいちばん空気が変わった瞬間は、会議室のホワイトボードに大きく「データは何年守る？」と書いたときでした。
情報システム、法務、事業、営業、保管担当が付箋を持って前に出ると、同じ「顧客情報」という言葉でも、契約書、サポート履歴、研究資料、認証ログでは期待される保護期間がまるで違うことが見えてきます。
暗号方式の名前を並べるより先に、この時間軸の合意を取るほうが、移行の優先順位はずっと鮮明になります。
HNDL攻撃は、技術の問題である前に、「何を、いつまで守るのか」を組織が言語化できているかを試す鏡でもあります。

時間軸で見る守るべきデータ

暗号の寿命は、データの寿命と切り離せません。
数時間で価値が消える情報と、何年も秘密であるべき契約、設計、医療、個人情報では、同じ鍵交換を使っていても意味が変わります。
長期秘匿データは実務上、少なくとも3〜5年以上の保護が要るものから意識しておくべきで、攻撃側が暗号化通信を保管する期間も3〜10年を想定したほうが筋が通ります。
つまり、今日の盗聴が今日の事故として見えなくても、保護期間が長いデータでは将来の事故に育つ余地があるわけです。

この時間軸の発想を入れると、暗号評価の質問が変わります。
「いま安全か」ではなく、「必要な保護期間を走り切れるか」です。
公開鍵暗号がHNDLで真っ先に問題化するのは、TLSの鍵共有や署名の土台にいるからです。
過去の通信がいまは解読不能でも、将来Shorのアルゴリズムを実行できる量子計算機が現れれば、いま集められた暗号化データの意味が一変します。
共通鍵暗号は話が少し違い、Groverの影響を見越して鍵長を考える余地がありますが、HNDLの中心にあるのはまず公開鍵側の寿命です。

ここで見落としやすいのが、「保存データ」だけが長期秘匿ではないことです。
通信も、契約交渉、知財、M&A、認証情報のやり取りのように、後年まで意味を持つものがあります。
いま閲覧できないから漏えいではない、という感覚は、HNDLの前では通用しません。
未来に読めるなら、今の収集はすでに漏えいの前段階です。

組織全体で取り組む暗号移行

量子時代への移行は、暗号担当者だけの宿題ではありません。
法務は保持義務や契約上の責任を整理し、経営は予算と優先順位を決め、情報システムは棚卸しと更新計画を回し、データ保全の担当はバックアップやアーカイブの暗号寿命を見直す必要があります。
ここが噛み合わないと、ネットワークだけPQCを試し、肝心の長期保管データや署名フローが旧来の前提に残る、という半端な移行になりがちです。

実務でまず効くのは、暗号を「技術部門の実装項目」ではなく「組織の保護義務」として扱うことです。
たとえば金融分野のように長期保護と説明責任が重い業界では、TLSの鍵共有、認証基盤、文書署名、保管時暗号、委託先との接続方式まで、暗号の論点がばらばらに散っています。
これを一枚の地図にまとめる作業が、暗号棚卸しです。
アルゴリズム名、用途、鍵長、証明書、有効期限、保管場所、保持期間、使っているライブラリまで並べていくと、「どこを直せばよいか」より先に「どこが放置されていたか」が見えてきます。

Q-Dayという言葉は、つい単一の決戦日を想像させますが、現場の感覚はもっと連続的です。
既存システムの更改周期、証明書更新、ベンダー対応、調達要件の書き換え、検証環境の整備には時間がかかります。
政府機関等のPQC移行目標の目安として2035年が置かれているのも、未来を予言したいからではなく、移行に年単位の助走が要るからです。
時期を断定する材料はなくても、準備に時間がかかる事実だけは、もう十分にはっきりしています。

読むだけで終わらせないなら、着手点は3つに絞れます。
どれも派手ではありませんが、HNDL対策はここからしか始まりません。
（詳しい手順は棚卸しのやり方を参照してください）

1. 暗号資産の棚卸しを始める

まず把握するのは、「どこで暗号を使っているか」です。
TLS、VPN、証明書、JWTやSAML署名、データベース暗号化、バックアップ、KMS、HSM、利用ライブラリまで洗い出します。
台帳に最低限ほしいのは、用途、アルゴリズム、鍵長、保護対象、保持期間、責任者です。
これがないままでは、移行は検討ではなく当てずっぽうになります。

1. 長期秘匿データを特定する

すべてを同じ緊急度で扱う必要はありません。
何年守る必要があるかを軸に、顧客情報、契約文書、研究資料、認証関連データ、経営情報を分類します。
会議室のホワイトボードに「何年守るか」を書いて、部門ごとに付箋を貼るだけでも、優先順位は驚くほど具体化します。
暗号の議論が抽象論で止まる組織ほど、この作業で一気に前へ進みます。
（詳しい手順は棚卸しのやり方を参照）

1. PQCとハイブリッド構成の検証を小さく回す

いきなり全面移行ではなく、まずは検証環境でKyber系のハイブリッドTLSや、PQC署名の相互運用性を試す段階に入ることです。
見るべきは、つながるかどうかだけではありません。
証明書運用、監視、障害時の切替、既存クライアントとの整合まで含めて観察すると、移行に必要な社内の役割分担が見えてきます。
PQCは「未来の技術」ではなく、「今の構成管理に混ぜて評価する対象」になった瞬間から実務になります。

HNDL攻撃が投げかける問いは、結局ひとつです。
その秘密は、必要な未来まで秘密でいられるか。
ここに答えられないまま暗号を運用すると、今は読めない通信であっても、未来には漏えいとして数えられます。
だからこそ、量子時代の備えは“その日”の予想競争ではなく、今日どこから棚卸しを始めるかの勝負になります。