「量子」で暗号が無力化する前に：PQC移行は“技術の問題”ではなく“棚卸し＋契約＋運用設計”の問題です

山崎行政書士事務所
24 分前
読了時間: 7分

（最終更新：2026年3月1日）

日経の記事では、量子コンピューターの進展により 既存の公開鍵暗号（RSA/ECC等）が2030年代に危殆化し、各国が「耐量子計算機暗号（PQC）」へ移行を急いでいる、という論点が整理されていました。このテーマは、セキュリティ担当だけの話ではありません。調達（ベンダー管理）・BCP・監査対応・取引先説明まで一気に波及します。

本記事では、SEの実装目線で「Microsoft公式（日本語）」の情報を軸にしつつ、“今やるべき準備”を運用設計に落としてまとめます。

1. 2035は遠くない：国も“期限”を置き始めた

量子時代の暗号移行は、すでに「いつか」ではなく「計画期限」が設定され始めています。

米国（NIST）：NIST IR 8547（ドラフト）では、2035年をPQC移行完了の主要ターゲットとして言及されています。また、NIST側の資料では 2030でdeprecated、2035でdisallowed といった移行タイムライン整理も示されています。
英国NCSC：移行のマイルストーン（例：2028 / 2031 / 2035）を提示し、段階移行を勧告しています。
日本（内閣官房／国家サイバー統括室NCO）：政府機関等について 原則2035年を目処、さらに 2026年度中に工程表（ロードマップ）策定予定とする中間とりまとめが公表されています。

経営に刺さる言い方に直すと：「暗号の移行は“5年で終わる更改”ではなく、“調達と運用が絡む全社プロジェクト”」 です。

2. “今すぐ”が必要な理由：Harvest Now, Decrypt Later（今盗んで、後で解く）

量子の脅威は「量子コンピューターが完成してから」では遅いケースがあります。なぜなら攻撃者は、いま暗号化通信や暗号化データを収集・保管し、量子計算が成熟した段階で復号する（HNDL）可能性があるからです。

Microsoftもこの HNDL（Harvest Now, Decrypt Later） を明確に挙げ、TLS 1.3 やハイブリッド鍵交換など、量子安全性に向けた取り組みを説明しています。

ここが重要で、守るべきものが次のタイプだと「今日から準備」が合理的です。

秘匿期間が長いデータ（設計図、レシピ、研究、M&A、重要顧客情報等）
寿命が長い機器・システム（製造設備、IoT、認証基盤、VPN装置）
証明書・署名が絡む領域（コード署名、ファーム更新、ゼロトラスト認証）

3. Microsoftは何を進めているか：PQCは“絵空事”ではなく、基盤に入り始めている

(1) “暗号アジリティ（crypto-agility）”を前提にしている

Microsoftは「量子安全なセキュリティ」の文脈で、PQC移行は一括切替ではなく段階移行であり、**暗号アジリティ（アルゴリズムを柔軟に変更できる設計）**が重要だと述べています。

(2) ネットワークは「TLS 1.3 へ移行し、PQC統合に備える」

Microsoftのゼロトラスト実装ガイダンスでは、RSA/ECCが将来の量子に脆弱である点に触れつつ、TLS 1.3への移行を開始し、標準の成熟に合わせてPQC統合に備える方針が示されています。

(3) エンドポイント／アプリ側でもPQCサポートが進む

.NET 10：Windowsの暗号API（CNG）におけるPQCサポートや、PQC系APIの整備が記載されています（※一部は試験的扱いの整理もあります）。
Microsoft Edge：TLSでのポスト量子鍵合意を提供するかどうかを制御するポリシーがドキュメント化されています（互換性・ネットワーク機器の挙動にも注意が必要、という整理もあります）。

(4) “鍵管理”は先に整える価値が高い（PQC以前に、運用事故が起きる）

Azure Key Vaultのキーに関する説明では、「量子耐性／量子セーフ／ポスト量子」の用語整理や、Managed HSMにおける AES 256ビット鍵が量子耐性である旨に触れています。つまり実務では、PQCの前にまず 鍵・証明書・シークレット運用を事故らせないことが先決になります。

4. 企業がやるべき手順：PQC移行は「暗号インベントリ（CBOM的発想）」から始まる

日経記事のポイントでもある通り、PQC準備の第一歩は 「暗号がどこで使われているかの棚卸し」です。ここを “技術台帳” と “調達台帳” を一体で作ります。

Step 1：暗号インベントリ（暗号の棚卸し）を作る

最低限、次を「一覧＋重要度」で出します。

通信：TLS終端（ロードバランサ、AP、API、SaaS連携）、VPN（IPsec/SSL）、SSH
認証：PKI（社内CA、AD CS、端末証明書）、S/MIME、クライアント証明書
署名：コード署名、ドライバ署名、ファームウェア署名、電子署名基盤
データ：DB暗号化、ファイル暗号化、バックアップ暗号化、鍵の保管場所
依存：アプリが使う暗号ライブラリ（OpenSSL等）とバージョン、OS暗号スタック

※この整理は、CRYPTRECでも「暗号の分類（共通鍵／公開鍵／署名／鍵共有）」を前提に体系化されています。

Step 2：ビジネス優先度を付ける（“データの秘匿期間”で並べ替える）

CRYPTRECの議論でも、暗号移行は「システム更改」よりも “データのライフサイクル”が本質、という指摘がされています。実務では以下で優先順位が決まります。

10年以上秘匿したい情報（HNDLの影響を受けやすい）
置換に年単位かかる設備・機器（製造／IoT／OT）
規制・契約で暗号要件がある領域（金融・医療・重要インフラ連携等）

Step 3：まず “TLS 1.3” と “証明書ライフサイクル” を整える

PQCへ向かう前提として、Microsoftのガイダンスでも TLS 1.3移行が明確に推奨されています。同時に、証明書運用が属人化していると、PQC移行以前に 更新事故（期限切れ）で業務停止します。

Step 4：暗号アジリティを“設計ルール”として採用する

Microsoftが強調する crypto-agility を、設計ルールに落とします。

暗号アルゴリズムをコードに直書きしない（設定化・抽象化）
鍵・証明書・シークレットは集中管理（Key Vault等）に寄せる
証明書の発行・更新・失効・ローテーションを自動化（運用手順を固定）
“ハイブリッド（既存＋PQC）” を許容できる経路設計（TLS終端など）

Step 5：SBOMを調達条件に入れる（CBOMの入口にもなる）

日経記事の文脈でもSBOM/CBOMの話が出ていますが、少なくとも SBOM（ソフトウェア部品表）は、Microsoft製品側でも運用に落とせる仕組みが増えています。

Defender for Cloud（DevOps Security）では、接続したコードリポジトリに対して SBOMを自動生成し、クエリ可能な形で扱える旨が整理されています。
Secure Future Initiative（SFI）の文脈でも、SBOMやコード署名などの要求を一貫適用して監査に耐える、という整理があります。

実務メモ：**CBOM（暗号部品表）**はまだ標準化が揺れているため、まずは「TLS終端の方式」「証明書アルゴリズム」「利用ライブラリ」「鍵管理方式」を“提出物”として契約に入れるのが現実的です。

Step 6：性能影響は「机上で語らず、検証環境で測る」

PQCは鍵や署名サイズが大きくなり、ハンドシェイクや検証コストに影響が出ます。Microsoft Edgeのポスト量子鍵合意ポリシーでも「メッセージが大きくなり、一部ネットワーク機器で問題が起こり得る」趣旨が説明されています。よって、優先度上位の経路から PoC→段階適用が必要です。

5. “契約と統制”で事故を防ぐ：PQC移行はベンダー任せだと詰む

PQC移行は、社内だけで完結しません。SaaS、SIer、保守ベンダー、機器メーカー、海外SOCなど、供給網のどこかが未対応だと 自社だけ移行できないからです。

ここで行政書士ができるのは、交渉代理ではなく、企業内の統制文書・調達条件・委託仕様・証跡要件を「技術前提で破綻しない形」に落とすことです。

調達・委託の条項に入れておきたい観点（ひな形）

SBOM提出（可能なら更新頻度も）
暗号利用の開示（TLS終端方式、証明書方式、鍵管理方式、暗号ライブラリ）
PQC移行方針（ロードマップ、対応予定、互換性）
アルゴリズム変更時の影響評価と検証（性能・互換性）
緊急時の切替（例：ハイブリッド→従来へ一時退避等）の手順と責任分界
監査ログ提供（誰が、いつ、何をしたか）
再委託時の統制（海外SOC/海外下請けを含む）

【広告】山崎行政書士事務所：PQC移行を「暗号棚卸し＋Key Vault運用＋委託統制」で“説明できる形”に整えます

山崎行政書士事務所では、クラウド法務×Azure/Entra の視点で、技術（設計・運用・証跡）と、統制（規程・契約・提出物）を同じ成果物セットに束ねる方針を掲げています。

Azure Key Vault運用設計：Secrets/Keys/Certificatesを、アクセス統制・ローテーション・監査ログ・例外運用・委託先統制まで含めて整理（※手順書代行ではなく“統制と成果物”重視）。
再委託（国外）×監督責任：海外SOC等が絡むときの責任分界・監督・証跡提出で揉めない整理。

「PQCはまだ先」と思っている間に、実務上は 証明書期限切れ・鍵管理の属人化・調達条件の未整備で先に事故が起きがちです。PQCを“未来の暗号”で終わらせず、今の運用と契約の穴から塞いでいきましょう。