耐量子計算機暗号（PQC）への対応を、「量子コンピュータが実用化してから考える将来課題」にしていないでしょうか。 量子計算機が現在広く使われる公開鍵暗号へ実際に影響を与える時期には不確実性があります。一方で、暗号はTLS、VPN、 電子署名、証明書、ソフトウェア更新、クラウドサービス、組込み機器などに分散し、発見・交換・検証には長い時間がかかります。

2025年11月に公表された日本政府の中間とりまとめは、政府機関等について原則2035年までをPQC移行期限の目処としつつ、 情報の重要性や利用する暗号技術の期限を踏まえる方向性を示しました。これは民間企業へ一律に同じ期限を課すものではありませんが、 調達、委託、長期運用システムを含む移行準備を早く始める必要性を示す重要な政策動向です。

NISTは2024年にML-KEM、ML-DSA、SLH-DSAを定める最初の3つのPQC標準を公開しました。また、2026年6月更新の 暗号アジリティ文書では、セキュリティと業務継続を保ちながら、プロトコル、アプリケーション、ソフトウェア、ハードウェア、 ファームウェア、基盤の暗号アルゴリズムを交換・適応できる能力を整理しています。重要なのは、特定の新アルゴリズムを急いで入れることではなく、 自社が何に暗号を使い、何を先に変え、変更後をどう確かめるかを運用できる状態にすることです。

具体的な課題：暗号は「部品」ではなく依存関係として埋め込まれている

暗号は、情報システム部門が管理する証明書だけに存在するわけではありません。業務アプリのライブラリ、SaaSとの接続、 ID基盤、ネットワーク機器、バックアップ、コード署名、取引先とのファイル交換、製品ファームウェアなど、組織の境界を越えて使われます。 製品名や契約名だけの台帳では、どの機能がどの暗号方式に依存し、誰が交換判断を持つのか分かりません。

  • 利用箇所が見えない：設計書と実環境がずれ、古いライブラリや機器内の暗号を把握できない。
  • 守る期間が分からない：データの保存期間と、暗号が保護すべき期間を結び付けていない。
  • 委託先へ依存する：SaaS、通信、認証、機器ベンダーの更新計画を自社の計画へ反映できない。
  • 交換時の影響を試していない：鍵や署名のサイズ、処理時間、通信、HSM、証明書連鎖への影響が不明。
  • 期限だけが独り歩きする：公的機関向けの目標年を、自社のデータ寿命や更新周期を見ずに適用する。
PQC対応の最初の成果物は、新しい暗号の導入ではありません。「どこで、何を、なぜ守り、どう交換するか」が分かる暗号資産台帳です。

考え方：暗号資産台帳と暗号アジリティを一つの改善循環にする

NIST NCCoEは、暗号資産台帳を、システム、アプリケーション、サービス、機器、データフローで使われる暗号の記述的な記録と説明しています。 アルゴリズム、プロトコル、証明書、ライブラリ、依存システム、保護対象データ、責任者、更新期限などを扱いますが、 秘密鍵そのものを台帳へ保存するものではありません。

台帳を一度作って終わらせず、調達、変更、脆弱性管理、構成管理、証明書更新、製品廃止と結び付けます。 「発見する」「優先順位を決める」「交換可能性を確かめる」「変更する」「証跡を更新する」を回すことで、 PQCだけでなく将来の暗号危殆化や標準変更にも対応しやすくなります。

実践手順1：長く守る情報と止められない機能を選ぶ

全システムを同じ深さで棚卸しせず、まず対象を絞ります。長期間秘密にする必要がある情報、本人性や改ざん防止を長く担保する署名、 更新停止が事業や安全へ大きく影響する機能を候補にします。保護期間、保存期間、外部へ流れる範囲、停止時の影響、代替手段を業務側と確認します。

「今すぐ量子計算機で解読される」と断定するのではなく、現在収集された暗号化データが将来解読されるリスク、 製品更新に要する年数、契約更改の時期を組み合わせて判断します。経営者には技術名の一覧ではなく、守る事業価値と移行に使える時間を示します。

実践手順2：暗号の利用箇所と責任者を棚卸しする

構成管理情報、証明書管理、ソフトウェア部品表、ネットワーク観測、ソースコード・依存ライブラリの検査、クラウド設定、 ベンダー回答を組み合わせます。自動検出だけでは業務上の目的やオフライン機器を把握できず、聞き取りだけでは実装の抜けが生じるため、 複数の情報源を突き合わせます。

最小項目は、対象システム、利用目的、アルゴリズム・プロトコル、実装や提供者、証明書・鍵の管理方式、保護対象データ、 データの必要保護期間、システム所有者、技術責任者、契約・保守期限、交換候補、確認日です。鍵識別子や保管場所の参照は必要に応じて持ちますが、 秘密鍵や復旧用秘密情報を台帳へ複製しないでください。

実践手順3：データ寿命・事業影響・交換難度で優先順位を付ける

検出件数の多さではなく、三つの軸で分類します。第一は情報を秘密または真正に保つ必要がある期間、第二は漏えい・なりすまし・更新不能時の事業影響、 第三は交換に必要な時間と依存関係です。長期機密データ、ルート証明書、コード署名、組込み機器、複数社をまたぐ通信は、 利用件数が少なくても早い検討が必要になる場合があります。

「要対応」「監視」「当面維持」「廃止予定」のような状態、判断理由、責任者、次回確認日を記録します。 アルゴリズム名だけで危険度を自動決定せず、利用方法、パラメータ、実装、鍵管理、プロトコル、補完統制を含めて評価します。

実践手順4：調達要件を整え、非本番で交換可能性を試す

ベンダーへ「PQC対応予定ですか」とだけ聞くのではなく、対象機能、準拠予定の標準と版、対応する鍵確立・署名、更新方法、 現行方式との相互運用、ロールバック、ログ・監視、HSMや証明書基盤への影響、サポート期間を確認します。 製品ロードマップは変更され得るため、回答日と根拠資料も台帳に残します。

非本番環境で、接続可否だけでなく、遅延、CPU・メモリ、通信量、証明書や署名のサイズ、機器制約、障害時の切り戻し、 監視の見え方を確かめます。ハイブリッド方式を含む移行設計は、利用する製品・標準・相互運用要件を確認し、 専門家やベンダーと評価してください。独自暗号や独自の組合せを安易に作らないことが重要です。

実践手順5：更新ロードマップを通常の変更管理へ組み込む

優先対象ごとに、責任者、依存先、検証、契約更改、機器更新、データ移行、廃止、ロールバックを並べます。 一斉切替ではなく、観測可能で戻せる単位に分け、重要な通信や署名は相互運用期間を設けます。 完了条件は「設定を変更した」ではなく、想定した暗号が実際に使われ、旧方式が意図どおり縮退・停止し、業務影響が許容範囲であることです。

新規調達、構成変更、証明書更新、ライブラリ更新、脆弱性対応、サービス終了を台帳更新のトリガーにします。 半期や四半期など自社に合う周期で、未回答ベンダー、期限超過、例外、検証待ちをレビューし、経営課題として残る依存関係を可視化します。

注意点：標準化と実装準備を同じものと考えない

  • 量子脅威の時期を断定しない：予測には幅があるため、データ寿命と移行所要時間から備えを判断する。
  • 新方式へ無条件で即時置換しない：標準、実装品質、相互運用、性能、運用手順を確認し、段階的に検証する。
  • 台帳へ秘密情報を集約しない：鍵素材、パスワード、復旧コードは適切な秘密管理基盤で分離する。
  • ベンダーの「対応済み」だけで判断しない：対象機能、標準の版、設定、既定値、更新経路、検証結果を確認する。
  • 2035年を自社の一律期限にしない：日本政府の方向性を参考にしつつ、自社の対象、契約、データ寿命から工程を定める。
  • 暗号アジリティを独自実装の口実にしない：標準化された方式と保守される製品を前提に、交換可能な設計・契約・運用を整える。

まとめ：PQC導入より先に、暗号を交換できる組織能力を作る

耐量子時代への備えは、すべての暗号を一度に置き換えるプロジェクトではありません。長く守る情報と重要機能を選び、 暗号の利用箇所と責任者を棚卸しし、データ寿命・事業影響・交換難度で優先順位を付け、非本番で検証し、 通常の調達と変更管理へ組み込む継続的な取り組みです。

最初の一歩として、長期保存する重要情報を一つ選び、それを守る通信、証明書、署名、ライブラリ、機器、委託先を一枚に整理してください。 アルゴリズム名よりも、所有者、保護期間、交換方法、次回確認日が埋まるかを確かめると、将来課題だった暗号移行を今日の実務へ変えられます。

参考にした公式資料

本記事は公式資料をもとに、一般的な暗号移行とセキュリティ管理の考え方を整理したものです。 特定の暗号方式、製品、期限を個別組織へ推奨するものではなく、法令適合性その他の法律上・専門上の助言を行うものではありません。 公式資料は2026年8月25日時点で確認しています。実際の移行では、自社の情報、システム、契約、規制、リスク許容度を踏まえ、 暗号・法務・調達・業務の関係者および必要な専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る