株式会社renue
内製化支援
内製化支援で、この記事のテーマを実務に落とし込めます
renueが社内で運用しているシステムをサービス化したものです。何ができるか、どう動くかをサービスページでご覧ください。
耐量子暗号（PQC：Post-Quantum Cryptography）は、将来の量子コンピューターによる攻撃も考慮して設計する暗号技術です。企業の準備では、アルゴリズムの名前だけでなく、どの通信・署名・製品に暗号が使われ、誰と調整して変更するかを把握します。2026年10月26日に確認した公式の発表・解説を基に、標準化の段階、期限の適用範囲、移行の五段階と業種別の確認点を整理します。
PQCの必要性とHNDLリスクを、守る情報から考える
PQCは、従来型と量子型の計算機による攻撃を考慮した数学的な暗号方式です。量子の物理的性質を使う量子暗号とは区別します。NISTのPQC解説は、十分な能力を持つ量子コンピューターが現在の暗号を脅かす可能性と、その実現時期は分からないことを説明しています。「特定の年に必ず解読される」「量子コンピューターでも絶対に解読できない」という確約には置き換えません。
準備を始める理由の一つが、Harvest Now, Decrypt Later（HNDL）です。現在は解読できない暗号化データを集め、将来の解読を狙う考え方で、同解説も長期間価値が残る秘密との関係を扱っています。いま漏えいしていないことと、将来まで秘密を守れることは別の評価になります。顧客情報、研究・設計情報、契約等について、秘密を維持したい期間と、収集され得る経路を確認します。
ただし、保存期間が長いという理由だけで、すべてのデータ・方式・製品を同じ緊急度にする必要はありません。公開情報と機密情報、外部へ流れる通信と閉じた処理、鍵を確立する仕組みと署名による検証を分けます。何を守っているか不明なまま暗号名だけを置換すると、更新の必要な箇所や接続先への影響を見落とすおそれがあります。
NISTのPQC案内は、脆弱になり得るアルゴリズムの利用箇所を特定し、製品・サービス・プロトコルの更新を計画するよう促しています。企業内では、利用部門、アプリ担当、ネットワーク担当、調達先がそれぞれ情報を持っている場合があります。所有者と提供元が分からない資産も、その事実を記録して確認を依頼します。未回答を「対応済み」と扱わないことが出発点です。
本記事で提案する管理単位は、「守る情報・必要な期間」「利用する通信や署名」「関連する製品と版」「変更を判断する担当」の組合せです。例えば、同じシステムでも外部APIとの通信、端末からの接続、ソフトウェアの署名確認は別に追います。一つの製品がPQC対応を発表しても、全経路・全用途が同時に移行した証拠にはしません。対応の発表、契約で使える機能、実際の設定と接続試験を分けて確認します。
市場規模の成長予測や量子計算機の登場予測は、自社の移行順序をそのまま決める数値ではありません。まず長期に保護する情報と更新に時間がかかる依存関係を見つけ、必要な調査・調達・検証を計画します。対策の予算は、予測上の市場成長率より、自社の対象と作業、残るリスクを説明できる形で組み立てましょう。
NISTの標準化と、国・分野ごとの移行方針を読み分ける
NISTの2024年8月13日の発表は、最初の三つの最終標準と、採択された方式からの名称変更を説明しています。下表はその発表とHQCの選定発表の要点です。鍵の確立とデジタル署名を同じ用途として扱わず、候補名と標準に記載する方式名も対応させます。
| 方式・標準 | 整理する用途・段階 |
|---|---|
| ML-KEM／FIPS 203 | CRYSTALS-Kyberに基づく方式。鍵カプセル化を扱う、2024年の最終標準 |
| ML-DSA／FIPS 204 | CRYSTALS-Dilithiumに基づくデジタル署名。2024年の最終標準 |
| SLH-DSA／FIPS 205 | SPHINCS+に基づく、異なる数学的構成のデジタル署名。2024年の最終標準 |
| HQC | 2025年3月11日に標準化へ向けた選定を発表。選定の発表と最終標準の公表を区別する |
HQCの2025年の発表は、ML-KEMを置き換える目的ではなく、異なる数学的構成による備えと説明しています。同発表の2027年最終化という見通しは、当時の予定です。予定年に到達することを完了の根拠にせず、調達時には対象となる最終仕様と製品の対応版を確認します。ここで仕様全文の実装条件や個別製品の認証を確認したわけではありません。
移行期限は、国、組織、システム、契約上の位置付けをそろえて読みます。NSAの2026年10月1日の発表は、米国の国家安全保障システム（NSS）について、2027年からの新規商用NSSの対応能力と、対応できない旧システムの2030年までの段階的な廃止を説明しています。全世界の民間企業の全システムへ同じ期限が直接適用される、という説明にはしません。
金融分野では、金融庁の2026年1月15日の案内で、G7サイバー・エキスパート・グループが1月12日に協調的な移行ロードマップに関するステートメントを公表したことを確認できます。これは金融分野で関係者との計画の調整が論点になる例です。この案内だけから、全金融機関の一律の法定期限や、特定サービスへの切替義務までは導きません。
自社の管理表には、発行者、資料の日付・版、草案か最終版か、対象システム、求められる作業、期限の根拠を残します。海外の方針、国内の政府機関向け目標、民間の契約条件は別欄にします。「2030年にRSA-2048がすべて禁止」「全企業は2035年までに移行」といった一律の理解で判断せず、適用される条件を調達・法務・担当部署で確かめる進め方が適切です。
企業の移行は、棚卸しから更新後の運用まで五段階で進める
NCCoEの移行プロジェクト案内は、暗号の利用箇所を発見する取り組みと、相互運用性の試験を分けています。以下はこの観点を企業の作業に対応させた本記事の進め方です。全社共通の所要年数や認証取得の手順を示すものではなく、対象と依存関係に応じて順序と範囲を調整します。
1．暗号を使う資産と依存先を棚卸しする
アプリ、通信機器、クラウドサービス、証明書、ライブラリ、端末等について、用途、方式、製品・版、所有者、保守・更新の可否を記録します。自社で設定できる部分と提供元の更新が必要な部分を分け、確認日と証拠、未確認事項を残します。自動検出結果だけで完了とせず、対象外の環境や見つからない利用箇所について担当者・提供元に確認します。
2．保護期間と変更の難しさから優先順位を決める
情報の機密性、必要な保護期間、外部接点、業務停止の影響と更新の難しさを並べます。長期利用する機器や他社との接続は調整の担当も決めます。重要というラベルだけで全件を同時に始めず、先に調査する対象、製品更新を待つ対象、契約で対応計画を確認する対象へ作業を分けます。
3．対象プロトコルと製品が支える移行方式を選ぶ
従来方式とPQCを組み合わせるハイブリッド構成を検討する場合も、採用する仕様、接続する双方の製品・版、設定と切替条件を確認します。「併用すれば必ず安全」「既存環境と自動的に互換」とは判断しません。独自に方式を連結して安全性を推定するのではなく、対象用途の仕様と提供元の実装・サポートを確認し、必要な専門家の評価を受けます。
4．試行環境で互換性と性能・復旧を検証する
正常時の接続だけでなく、接続相手の未対応、混在する版、証明書や設定の更新、障害時の切り戻しを確認します。性能は同じ機器・通信条件で、応答、処理量、メモリ、通信量等を測ります。異なるパラメーターの公開鍵・署名・通信全体のサイズを一つの数値として比べず、何を測った値かを残します。業務上の合格条件と未確認の組合せも明示します。
5．段階的に展開し、変更を続けられる運用にする
対象と担当、承認、作業時間、切り戻し条件を決めて切り替えます。展開後は実際の通信・検証結果と台帳を照合し、旧設定を残す場合の理由と見直し時期を記録します。暗号方式や実装を更新しやすい状態を保つクリプトアジリティでは、名前だけを掲げず、変更箇所、試験、調達先との連絡、運用記録を維持します。移行後の新しい接続や製品更新も再評価の対象です。
ネットワーク更新と合わせて進める場合は、SASE・SD-WANの移行と運用の確認点も参照できます。接続・権限を整理する設計と、暗号方式の移行は関連しますが、同じ作業ではありません。ネットワーク製品の導入完了だけでPQC対応まで完了とせず、接続先、証明書と対象通信の検証を対応させます。
業種別の確認点、費用・安全性の評価と相談先
業種ごとの検討では、特定企業の実証を自社の導入済み性能へ読み替えないことが大切です。以下は導入事例の実績や各業界の義務を示すものではなく、本記事の確認例です。業界名だけで方式を選ばず、守る情報と利用する機器・サービス、接続相手を具体化して検討します。
| 分野 | 自社で具体化する確認例 |
|---|---|
| 金融 | 顧客・取引情報、外部接続、委託先・接続先の移行計画、署名の検証と業務継続 |
| 通信 | 端末からサービスまでの経路、機器・ソフトウェアの更新、混在環境の接続と性能 |
| 製造・IoT | 長く使う機器の保守、利用資源、更新や署名確認、停止できる時間と提供元の対応 |
| 公共 | 適用する調達・運用方針の対象と版、長期保管する情報、関連組織との責任分担 |
費用は、棚卸し、製品・ライセンス、設計・改修、接続先との調整、試験環境、並行運用、教育・保守に分けて見積もります。社内工数と外注費、更新時に通常発生する費用とPQC対応による追加費用も分けます。小規模企業なら必ず安い、全社移行は必ず数年という共通の結論は置かず、対象数だけでなく依存関係と変更の可否を確認します。
技術面の注意点は、性能、互換性、安全性の継続評価です。最終標準が公表されたことと、自社が使う実装・設定・鍵管理まで適切であることは同じではありません。提供元の対応表、更新情報、検証した版を対応させ、後から対象が変わった場合にも再試験できるようにします。方式の長期的な評価や実装の問題が見つかった場合の連絡先と更新手順も必要です。
調達前には、対応する用途と仕様、利用条件、試験可能な環境、対応しない相手との接続、保守・更新の扱いを質問します。「PQC対応」の一語を完成の証拠にせず、どこまで確認したかを記録します。実証、限定提供、一般提供の発表と自社の契約で利用できる機能も分け、提供予定を使って既存システムの対策を終了させないようにしましょう。
既存アプリの外部接続、認証・権限、保守や刷新の課題も整理したい場合は、renueのAI脆弱性診断・システム刷新支援へ相談できます。公開案内の対象は、合意した環境でのコード分析・侵入テスト、改善点の報告、別途範囲を合意した改修・移行・運用の整備です。暗号アルゴリズムの専門評価やPQCの認証取得を一律に提供するという案内ではないため、対象技術と専門家の関与を含めて支援範囲を確認します。
相談時には、対象システム、守る情報と保護期間、接続先、所有者・提供元、現在の版と更新可否、試せる環境を用意すると整理が進みます。不明な箇所は不明のまま示し、調査の担当と期限を決めます。PQCへの準備は、一度の製品購入で終える作業ではなく、情報・資産・責任と検証結果を更新し続ける取り組みとして進めましょう。
