Google Cloudが2029年までに耐量子暗号へ完全移行。PQCロードマップの全容と企業が取るべき3ステップ
Google Cloudが2026年8月11日、2029年までに耐量子暗号（PQC / Post-Quantum Cryptography）へ完全移行するためのロードマップを公開した。量子コンピュータによる将来の暗号解読リスクに備え、APIエンドポイントやロードバランサーの対応はすでに始まっている。
今回の発表では、移行戦略の3つの重点領域、2026年に完了した基盤整備、2027年から2028年にかけてのドメイン別計画が示された。企業が今すぐ着手すべき3つのステップも提示されている。
量子コンピュータが実用化されれば、現在広く使われているRSAやECDSAなどの公開鍵暗号は解読可能になる。その影響はクラウドサービス全体に及ぶ。本記事では、Google CloudのPQCロードマップの全容と、企業に求められる対応を整理する。
PQC移行の全体像と2029年目標
Google CloudのPQC移行戦略は「セキュアバイデザイン」を基本方針とする。設計段階から量子安全を組み込むアプローチであり、単なる後付けの対策ではない。Google Quantum Threat Modelという独自の脅威モデルを土台に、3つの重点領域で保護を進める。
SNDLリスクとは何か
SNDL（Store Now, Decrypt Later）は「今保存して後で復号する」攻撃だ。攻撃者が現在の暗号化通信を傍受してデータを蓄積しておき、量子コンピュータが実用化された時点で一括して復号する。今日の暗号化データが将来の量子コンピュータで解読されるリスクは、すでに現実のものとなっている。
これがPQC移行を急ぐ最大の理由だ。機密データの保存期間が数十年に及ぶ場合、現在の暗号化方式のままでは将来の解読リスクを抱え続けることになる。特に金融機関や政府機関、医療機関では、このリスクへの対応が喫緊の課題だ。
このデモはSNDL攻撃のリスクとPQCによる防御の違いを示している。攻撃者がどれだけデータを蓄積しても、量子安全な鍵交換を使っていれば将来の解読は不可能になる。
Googleが定める3つの重点領域
Google CloudがPQC移行戦略で優先するのは、以下の3領域である。
- SNDLリスクの緩和。現在の暗号化データが将来の量子コンピュータで解読されることを防ぐ。
- 偽造に対する完全性の確保。デジタル署名を強化し、データやIDの偽造を防ぐ。
- 暗号アジリティの基盤強化。暗号標準の進化に合わせて、新しい方式を最小限の工数で採用できる柔軟なシステムを構築する。
3番目の「暗号アジリティ」は特に重要だ。暗号標準は今後も進化し続ける。特定のアルゴリズムに依存せず、新しい標準が出たら容易に切り替えられる仕組みがあれば、将来の移行コストを大幅に抑えられる。Googleはこの基盤への投資を戦略の中核に置く。
Google Cloudは規制期限を待たずに、内部インフラと顧客向けサービスのPQC移行を前倒しで進めている。2029年の完全対応を目標に、Sovereign Cloudの取り組み（Google Cloud DedicatedやGoogle Distributed Cloud）にもPQCソリューションを展開中だ。
2026年に完了した基盤整備
2026年時点で、すでに複数の基盤的マイルストーンが達成されている。これらは顧客に対して即座の保護を提供するものだ。
APIエンドポイントとロードバランサーの対応
Google CloudのAPIエンドポイントは、量子安全な鍵交換に対応した。google.comと*.googleapis.comの両方が、NIST標準化済みのML-KEM（FIPS 203）をハイブリッドモードで実装している。ハイブリッドモードとは、従来の暗号とPQCを併用する方式だ。互換性を保ちながら量子安全性を確保できる。
アプリケーションロードバランサーとプロキシロードバランサーも、TLS 1.3における量子安全ハイブリッド鍵交換（X25519MLKEM768）をサポートする。当初はオプトイン方式で提供され、顧客は既存アプリケーションへの影響を最小限に抑えながら検証を進められる。
さらに、ChromeとCloudflareが進めるMerkle Tree Certificatesの実験にも参画している。PQC署名をWebPKIに適用する際の課題（署名サイズの肥大化など）に対処する取り組みだ。
Cloud KMSのPQCアルゴリズム一般提供
Cloud KMSでは、NIST標準化済みのPQCアルゴリズム（ML-KEM、ML-DSA、SLH-DSA）が一般提供（GA）に達した。暗号化鍵と署名鍵の両方で量子安全なアルゴリズムを利用できる。
これは企業にとって大きな意味を持つ。既存のCloud KMS利用者は、新しいPQCアルゴリズムを試すために特別な準備をする必要がない。すでに一般提供されているため、本番環境での利用も可能だ。
ドメイン別ロードマップ（2027〜2028年）
Google Cloudは2029年の完全対応に向けて、リスクベースのアプローチで3つのドメインを定義した。各ドメインには目標完了時期が設定されている。サービスによって個別のタイムラインは調整される可能性があるが、大多数のサービスは目標時期に合わせて移行を完了する見込みだ。
このタイムラインは、Google CloudのPQC移行が段階的に進むことを示している。2026年の基盤整備から始まり、2027年には通信経路の保護、2028年には署名と鍵管理、2029年に全体の収束を目指す。
ドメイン1 SNDL対策（2027年目標）
ドメイン1は非対称暗号の脆弱性に対処する。将来の量子コンピュータが今日の暗号化データを復号するリスクを防ぐのが目的だ。対象となるのは以下の3つの経路である。
- 顧客ワークロードの保護。Google Cloudサービスとロードバランサーに量子機密TLS 1.3ハンドシェイクを提供する。
- 管理者・開発者フローの保護。Cloud VPNやInterconnectを含む管理者経路をSNDLから守る。開発者向けにはクライアントライブラリ、SDK、オープンソース暗号ライブラリのTinkを対応させる。
- データパイプラインの保護。分析・ストレージプラットフォームのデータ転送を保護し、機密情報が傍受・蓄積されても将来復号されないようにする。
このドメインの特徴は、通信経路の保護に焦点を当てている点だ。特にTinkの対応は重要である。TinkはGoogleが開発したオープンソース暗号ライブラリで、多くの開発者が利用している。TinkがPQCに対応することで、開発者はアプリケーションレベルで量子安全な暗号を容易に導入できる。
ドメイン2 完全性と否認防止（2028年目標）
ドメイン2はデジタル署名と証明の量子対応を扱う。量子コンピュータによる偽造攻撃からデータの完全性と信頼性を守る。3つの主要分野がある。
1つ目はソフトウェアサプライチェーンの保護だ。Binary Authorization、Cloud Build、Assured Open Source Softwareなどのサービスで、量子耐性のある証明（アテステーション）を導入する。信頼できる変更されていないイメージだけが本番環境で実行されることを保証する。
2つ目は量子安全な証明書の発行だ。内部および外部の認証局（CA）をML-DSA証明書に対応させる。状況に応じてSLH-DSA証明書もサポートする。IETF（Internet Engineering Task Force）の標準化に積極的に貢献しており、大規模な署名サイズ問題にはMerkle Tree Certificatesなどの新しいアプローチを検証中だ。
3つ目はIDとアクセスの保護である。サービスアカウントキーやトークン（JWT / OAuth）を量子偽造に対して耐性のある方式に移行する。
ドメイン3 基盤と鍵管理（2028年目標）
ドメイン3はPQC移行の土台となる暗号アジリティを扱う。ここでの投資が、ドメイン1と2の実現を支える。
基盤となる鍵管理とライブラリでは、Cloud KMSとBoringSSL、Tinkを通じてNIST承認アルゴリズムを有効にする。Cloud KMSはすでにML-KEM、ML-DSA、SLH-DSAの一般提供を開始しており、量子安全な鍵のインポートも準備中だ。
ハードウェアが関わる部分では、Confidential ComputingとCloud HSMにPQCを組み込む。量子的なルートオブトラストを確立し、物理的な基盤を保護する。OpenTitanやCaliptra v2.1、TPM 2.0 v185などのオープンソースシリコン基盤もPQC対応を進めている。
Google Workspaceのクライアントサイド暗号化（CSE）と外部鍵マネージャー（EKM）にもPQCオーケストレーションを導入する。オンプレミスの鍵プロバイダーとの連携も進める計画だ。
量子安全における共有責任モデル
量子安全はGoogle Cloudと顧客の共同作業である。クラウドセキュリティの共有責任モデルがPQCにもそのまま適用される。
この図は責任の境界を明確にしている。重要なのは、Google Cloud側のPQC対応が完了しても、顧客がクライアントソフトウェアを更新しなければ量子安全な接続は確立しない点だ。
Google側の責任範囲
Googleはサーバー、ネットワーク、転送中の暗号化、グローバルフロントエンド、ALTSプロトコルのPQC移行を一括して管理する。ハードウェアの移行は、積極的な交換と自然な機器更新サイクルを組み合わせて段階的に進める。物理コンポーネントの中には2029年を超えて移行が続くものもあるが、安定性を優先したフェーズドアプローチを取る。
顧客側の責任範囲
顧客は自社アプリケーションの管理に責任を持つ。クライアントソフトウェアをPQCハンドシェイク対応に更新すること、非対称鍵のライフサイクル管理、Google Cloudサービスの設定変更が含まれる。
ここが最も見落とされやすいポイントだ。インフラ側がPQC対応しても、クライアント側が古い暗号方式で接続すれば、量子安全性は確保されない。企業のセキュリティチームは、自社のクライアントソフトウェアがPQC対応済みかどうかを確認する必要がある。
企業が今すぐ着手すべき3つのステップ
Google CloudはPQC移行の第一歩として、企業が即座に着手できる3つのステップを提示している。どれも実務に直結する具体的なアクションだ。
- 棚卸し（Inventory）。Cloud Asset InventoryやWizなどのツールを使って、鍵や証明書などの暗号資産を特定する。組織全体の暗号リソースをマッピングし、移行バックログの優先順位を定義する。
- 更新（Update）。開発チームとSREチームが使うソフトウェアが、BoringSSL、Chrome、SDKなどPQCアルゴリズムに対応していることを確認する。エッジで量子安全接続が有効化された際に、社内ワークフローが準備できている状態を作る。
- 検証（Validate）。Google Cloudの量子安全APIとロードバランサーを使って既存アプリケーションの挙動をテストする。本番環境に影響が出る前に、アーキテクチャ上のボトルネックを特定できる。
この3ステップは、PQC移行を「待つ」のではなく「準備する」アプローチだ。特に検証は重要である。量子安全なTLS接続は従来よりオーバーヘッドが大きい場合があり、アプリケーションのパフォーマンスに影響を与える可能性がある。事前のテストで課題を洗い出しておけば、本番移行時のリスクを大幅に減らせる。
この記事のポイント
- Google Cloudは2029年までにPQC完全対応を目指し、ロードマップを公開した
- SNDLリスク（今保存して後で復号）は企業にとって喫緊の課題である
- 2026年時点でAPIエンドポイント、ロードバランサー、Cloud KMSのPQC対応が完了している
- 3つのドメイン（SNDL対策、完全性確保、鍵管理基盤）で2027〜2028年に移行を進める
- 企業は棚卸し、更新、検証の3ステップで今すぐ準備を開始できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare IPsecが耐量子暗号に対応、2029年完全移行へ前進
Cloudflareは、同社のIPsecサービスに耐量子計算機暗号（PQC）を導入し、一般提供を開始した。ハイブリッドML-KEM（FIPS 203準拠）を採用し、CiscoやFortinetといった主要ベンダーの機器との相互接続を確認済みだ。これにより、量子コンピュータによる将来の解読リスクに備えた広域ネットワーク（WAN）の保護を、既存のハードウェアで開始できる。
同社はかねてから目標としていたシステム全体の完全なPQC対応の期限を2029年に前倒ししている。今回のIPsec対応は、TLSトラフィックの3分の2以上がすでにPQCで保護されている状況にネットワーク層が追いつくための、重要なマイルストーンとなる。
耐量子暗号IPsecが一般提供開始となる背景
インターネット上の通信の多くは、現在のコンピュータでは解読が困難な公開鍵暗号によって保護されている。しかし、大規模な量子コンピュータが実用化されれば、これらの暗号は簡単に破られてしまう。これが「Q-Day」と呼ばれる転換点であり、想定よりも早く訪れる可能性が指摘されている。
ここで警戒すべきなのが「Harvest-now-decrypt-later（今収集し、後で解読する）」攻撃だ。攻撃者は今日の暗号化された通信データを大量に収集・保存し、将来の量子コンピュータで解読する。サイト間のVPNでよく使われるIPsec通信もこの脅威にさらされてきた。
Webブラウジングの通信を暗号化するTLSでは、すでに2022年からハイブリッドPQCの導入が急速に進んだ。実際、Cloudflareのネットワークに到達するユーザー由来のTLSトラフィックの3分の2以上が、耐量子暗号で保護されている。一方で、企業の拠点間を結ぶIPsecの世界では、相互運用性の確保や標準化の遅れが壁となり、導入が4年ほど遅れていた。
ハイブリッドML-KEMが実現する耐量子暗号
ML-KEMとは何か
今回採用されたML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism）は、量子コンピュータによる攻撃が理論的に困難とされる数学的問題（格子暗号）に基づくアルゴリズムだ。これは、通信の両端が持つ特殊なハードウェアや専用の物理回線を必要としない。標準的なプロセッサ上でソフトウェアとして動作するように設計されている点が、実用上の大きな利点である。
「ハイブリッド」方式の重要性
Cloudflareが実装したのは、IETFのドラフト「draft-ietf-ipsecme-ikev2-mlkem」で規定されるハイブリッド方式である。ハイブリッド方式とは、既存の安全性が十分に検証された古典的なDiffie-Hellman鍵交換と、新しいML-KEMを組み合わせる手法だ。
具体的なハンドシェイクの流れは次のとおりだ。まず、従来のDiffie-Hellman鍵交換を実行して共有鍵を生成する。次に、その鍵を使ってML-KEMの鍵交換を暗号化して実行する。最後に、両方の出力を混合して、実際のデータ通信を保護するセッション鍵を作成する。この二重構造により、仮に将来ML-KEMに未知の脆弱性が見つかったとしても、古典暗号の層が安全性を下支えする。
相互運用性の確立と課題
Cisco、Fortinetとの相互接続に成功
PQCの実装において最大の障壁は、異なるベンダー間での相互運用性の確保だ。Cloudflareの発表によると、今回の一般提供開始に先立ち、以下のネットワーク機器との相互接続テストを完了している。
- Cisco: バージョン26.1.1以降のCisco 8000シリーズセキュアルーター
- Fortinet: FortiOS 7.6.6以降を搭載したブランチコネクタ
これらの機器を拠点側に設置することで、Cloudflareのグローバルネットワークとの間に、耐量子暗号で保護されたIPsecトンネルを確立できる。これにより、特別なハードウェアを新たに調達することなく、既存の投資を活かしてセキュリティを強化できる道が開かれた。
標準化の遅れとciphersuite乱立問題
TLSに比べてIPsecでの標準化が遅れた背景には、鍵配送の代替技術としてのQKD（量子鍵配送）への関心が業界の一部にあったことが挙げられる。RFC 8784で規定されたQKDは、量子力学の原理を用いて盗聴を検知するが、専用のハードウェアと物理的な光ファイバー回線が必須だ。これはインターネット規模での展開には根本的に不向きであり、米国NSAや英国NCSCもQKDへの単独依存に警鐘を鳴らしている。
一方で、PQCのソフトウェアベースのアプローチにはこの制約がない。Cloudflareは、インターネットのオープン性と相互運用性を維持するために、PQCの標準化が不可欠であると主張する。
標準化を巡る混乱も導入を遅らせた一因だ。2023年に公開されたRFC 9370は、IPsecで複数の鍵交換を並行実行する枠組みを提供したが、使用すべき暗号スイートを明確に指定しなかった。この隙間を埋めるように、一部のベンダーは「draft-ietf-ipsecme-ikev2-mlkem」が策定される前に独自の暗号スイートを実装して市場に投入した。NIST SP 800-52r2が警告する「暗号スイートの肥大化」が現実のものとなり、結果として相互運用性に支障が生じている。具体的には、Palo Alto NetworksのRFC 9370ベースの実装とは、現時点で相互接続が確立できていないという。Cloudflareは、業界全体が新たなドラフト標準に集約されることで、この問題が解決されることを期待している。
耐量子インターネットに向けたロードマップ
Cloudflareは、2029年までの完全なPQC対応を目標に掲げている。今回のIPsecへのPQC導入は、そのマイルストーンの一つだ。同社は、この機能を顧客に追加コストなしで提供し、特殊なハードウェアを必要とせずに誰もが耐量子セキュリティを利用できる環境を目指している。
しかし、完全な耐量子環境の実現には、まだ解決すべき課題が残る。現在のdraft-ietf-ipsecme-ikev2-mlkemは「通信の暗号化」のための鍵交換を規定しているが、「通信相手の認証」のためのPQC標準はまだ存在しない。認証部分が古典暗号のままであれば、Q-Day以降に攻撃者が他人になりすましてシステムに侵入する「アクティブ攻撃」を防げない。迫る期限を前に、認証のPQC標準化が次の焦点となることは確実だ。
この記事のポイント
- Cloudflare IPsecがハイブリッドML-KEMによる耐量子暗号（PQC）の一般提供を開始し、2029年の完全移行に向けた一歩を踏み出した。
- CiscoやFortinetの既存ルーターとの相互運用性を確保し、追加のハードウェア投資なしでHarvest-now-decrypt-later攻撃への対策が可能になる。
- RFC標準の不在やベンダー間の実装差異によりIPsecのPQC対応はTLSより4年遅れたが、「draft-ietf-ipsecme-ikev2-mlkem」によって相互運用性の基盤が整いつつある。
- 今後の課題は「通信の認証」をPQCに対応させることであり、真の耐量子セキュリティ実現には標準化コミュニティの継続的な協調が不可欠である。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験