暗号の2030年問題の足音が聞こえてきそうな今日この頃ですね。
おはこんばんちは、GMOコネクトで執行役員CTO 菅野 哲（かんの さとる）です。
内閣官房からPQC移行に関する資料が公開されていたので解説してみます。
はじめに：量子計算機の脅威は「SF」から「スケジュール」へ
「量子計算機が完成したら今の暗号は破られる」——そんな話を聞いても、どこか他人事に感じている人が多いのではないでしょうか？
その認識、今すぐアップデートが必要です。
2025年11月、内閣官房より 「政府機関等におけるPQCへの移行について（中間とりまとめ）」 が公開されました。ここには曖昧な予測ではなく、明確な「期限」 が記されています。
重い腰をあげて日本が動き始めようとしているのです。
この記事では、この重要資料をエンジニア視点で噛み砕き、なぜ「今」動くべきなのかを解説します。
この記事でわかること（Takeaway）
- 政府が設定した 「2035年移行完了」 というデッドラインの意味
- なぜ資料は「CRQC（脅威）」ではなく 「FTQC（技術）」 を基準にしているのか
- 「HNDL攻撃」のリスクと、エンジニアが今すぐやるべき「暗号資産の棚卸し」
対象読者
- 「PQCって最近よく聞くけど、自分には関係ない」と思っているエンジニア
- セキュリティチームに所属していないが、暗号化処理を含むシステムを運用している方
- 経営層・マネジメント層への説明材料を探している方
1. 「2035年問題」の衝撃
資料における最大のポイントは、PQC（Post-Quantum Cryptography）への移行期限を原則として2035年と設定したことです。
なぜ2035年なのか？
これは日本独自の話ではありません。米国（NSM-10等）やEUなど、諸外国が2035年を移行ターゲットにしている国際的な動向に足並みを揃えたものです。
「うちは国内向けサービスだから関係ない」という認識は危険です。
- 国際的なデータ連携や外交・安全保障上の通信から締め出されるリスク
- グローバル企業との取引で「暗号化基準を満たしていない」と判断されるリスク
- 海外クラウドサービス（AWS, Azure, GCP）がPQC必須化した場合の対応遅れ
タイムライン
| 時期 | マイルストーン |
|---|---|
| 2025年11月 | 中間とりまとめ公開 ← 今ここ |
| 2026年度 | 正式な「工程表（ロードマップ）」策定 |
| 〜2030年 | 緊急度の高いシステムは移行完了（推奨） |
| 〜2035年 | 政府機関等は原則移行完了 |
あと10年しかありません。
RSA暗号の普及に20年かかったことを考えると、これは非常にタイトなスケジュールです。
2.【深掘り】なぜ「CRQC」ではなく「FTQC」なのか？
この資料を読み込むと、あることに気づきます。脅威の主体としてよく聞く「CRQC（暗号解読に有用な量子計算機）」ではなく、「FTQC（誤り耐性型量子計算機）」 という用語が使われているのです。
「脅威」ではなく「技術段階」に着目した理由
| 用語 | 定義 | フォーカス |
|---|---|---|
| CRQC (Cryptographically Relevant Quantum Computer) | 実際に暗号を解読できる能力を持ったマシン | 結果（脅威） |
| FTQC (Fault-Tolerant Quantum Computer) | ノイズ訂正機能を持ち、大規模・長時間計算が可能なマシン | 技術的マイルストーン |
「質（FTQC）」と「量（量子ビット）」の2つの壁
資料では、現在の公開鍵暗号（RSA-2048等）を現実的な時間で解く条件として、以下の2点を挙げています。
- FTQCの実現を前提とする（エラー訂正ができること）
- その上で、100万物理量子ビット以上が必要である
ここが重要です。「FTQC技術の確立」と「暗号解読（CRQC）」の間には、規模の壁（スケーリング）が存在します。
小規模なFTQCが完成しても、メモリ（量子ビット）が足りなければRSA-2048のような巨大な数は扱えません。
💡 エンジニア視点での解釈
政府資料があえてFTQCという言葉を使っているのは、予測困難な「いつ破られるか（CRQC）」という結果論よりも、観測可能な「いつ誤り訂正技術が確立するか（FTQC）」という技術的進捗をKPIにしているからだと読み取れます。
これは非常にエンジニアリング的で誠実な態度だと言えます。
3. 具体的に何が「危殆化」するのか？
公開鍵暗号（RSA, 楕円曲線暗号など）→ 移行必須
これらは移行のメイン対象です。Shorのアルゴリズムによって効率的に解読されるため、NIST標準のPQCアルゴリズムへの置き換えが必要です。
NIST標準化済みのPQCアルゴリズム（2024年8月〜）
| FIPS | アルゴリズム名 | 用途 | 旧名称 |
|---|---|---|---|
| FIPS 203 | ML-KEM | 鍵カプセル化 | CRYSTALS-Kyber |
| FIPS 204 | ML-DSA | デジタル署名 | CRYSTALS-Dilithium |
| FIPS 205 | SLH-DSA | デジタル署名（ハッシュベース） | SPHINCS+ |
| FIPS 206 | FN-DSA | デジタル署名（2025年追加） | FALCON |
共通鍵暗号・ハッシュ関数 → 鍵長の見直し
これらは「即死」ではありませんが、Groverのアルゴリズムで安全性が半減します。
- 対策: より長い鍵長への変更を検討（例：128ビット相当の安全性が必要な場合は256ビット鍵長へ）
- 注意: AES-128が「即座に危険」になるわけではありませんが、長期保存データには要注意
4.「まだ先だから大丈夫」ではない理由：HNDL攻撃
「2035年まであと10年あるから、次のリプレースで考えればいいか」。
そう思った方は要注意です。
HNDL攻撃とは？
HNDL = Harvest Now, Decrypt Later（今は収穫、後で復号）
[攻撃者の行動]
2025年：暗号化された通信を傍受・保存
↓
"今は解読できないけど、とりあえず取っておこう"
↓
203X年：量子計算機が完成
↓
保存しておいたデータを一気に復号！
HNDL攻撃のリスクが高いデータ
以下に該当するデータを扱っている場合、2035年を待たずに早期移行を検討すべきです。
- 🧬 個人の遺伝情報（一生変わらない）
- 🔐 国家機密・防衛関連情報
- 📄 長期契約情報（20年以上の機密保持が必要なもの）
- 🏥 医療記録（患者の生涯にわたる情報）
- 💰 金融機関の取引データ
⚠️ 現実を直視すると
あなたの今日の通信は、すでに「将来的に丸裸になるリスク」に晒されている可能性があります。
Trust Now, Forge Later (TNFL)攻撃
- TNFL攻撃は完全性と真正性を損なわせて、サプライチェーンにおける安全性と信頼性の脅威となると考えられています。
- HNDL攻撃のように広く認知されている攻撃の概念ではないため、利用には注意が必要であることに意識すること
5. エンジニアのアクションプラン
では、我々現場のエンジニアは何をすべきでしょうか？
① Cryptographic Inventory（暗号資産の棚卸し）の作成
まずは現状把握から。
自社システムで「どこで、どんな暗号技術を使っているか」を棚卸ししましょう。
⚠️ 注意
Cryptographic Inventoryはコマンド数発で完了するものではありません。以下はあくまで「第一歩」の例です。実際には設計書・構成管理資料の確認、開発者へのヒアリング、専用ツールの活用など、組織的な取り組みが必要です。
TLS設定の確認例（2段階で確認）
# Step 1: 設定ファイルからCiphersuiteのディレクティブを確認
grep -r "ssl_ciphers" /etc/nginx/
# 出力例: ssl_ciphers 'ECDHE+AESGCM:DHE+AESGCM:HIGH:!aNULL:!MD5';
# Step 2: ディレクティブの内容を渡して、実際に有効になるCiphersuiteを確認
openssl ciphers -v 'ECDHE+AESGCM:DHE+AESGCM:HIGH:!aNULL:!MD5'
# → RSA, ECDSA, ECDHE などが使われているかがわかる
稼働中サーバーへの接続確認
# 実際にサーバーに接続して、ネゴシエートされた暗号を確認
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null | grep -E "Protocol|Cipher"
# 出力例: Protocol: TLSv1.3 / Cipher: TLS_AES_256_GCM_SHA384
# ※ TLS 1.3の暗号スイート名には共通鍵暗号とハッシュのみ含まれる
# （鍵交換・認証アルゴリズムは別途ネゴシエートされる）
# 鍵交換アルゴリズムの確認（ECDHE, X25519 など）
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null | grep "Server Temp Key"
# 出力例: Server Temp Key: X25519, 253 bits
# → PQC移行では、ここがML-KEM等に変わる
# 証明書の公開鍵アルゴリズム・鍵長・署名アルゴリズムを確認
openssl s_client -connect example.com:443 < /dev/null 2>/dev/null | \
openssl x509 -noout -text | grep -E "Public Key Algorithm|Public-Key|Signature Algorithm"
# 出力例:
# Public Key Algorithm: rsaEncryption
# Public-Key: (2048 bit)
# Signature Algorithm: sha256WithRSAEncryption
# → PQC移行では、公開鍵がML-DSA等に、署名アルゴリズムも変わる
チェックリスト
- TLS Ciphtesuiteで使用している鍵交換・署名・暗号化アルゴリズム
- サーバー証明書の公開鍵アルゴリズムと鍵長（RSA-2048, ECDSA P-256 など）
- データベース暗号化で使用しているアルゴリズム
- ファイル暗号化・署名で使用しているアルゴリズム
- 外部API連携で使用している認証方式
- ハードコードされた暗号設定（要注意！）
🔍 あるある発見例
「ライブラリの奥底でハードコードされたRSA-1024」
「10年前に設定されたままのTLS 1.0」
「誰も把握していないレガシーシステムのSSH鍵」
② Crypto-agility（暗号の機敏性）の確保
PQCは従来の暗号と比べて鍵長や署名サイズが巨大になる傾向があります。
| アルゴリズム | 公開鍵サイズ | 署名サイズ |
|---|---|---|
| RSA-2048 | 256 bytes | 256 bytes |
| ML-DSA-65 | 1,952 bytes | 3,309 bytes |
| SLH-DSA-128f | 32 bytes | 17,088 bytes |
影響を受ける可能性のある箇所
- データベースのカラムサイズ
- パケットサイズ制限（MTU）
- タイムアウト設定
- ストレージ容量
- 帯域幅
Crypto-agilityの実装例（概念）
# 設定ファイルで暗号アルゴリズムを切り替え可能に
crypto:
key_exchange:
algorithm: "ML-KEM-768" # 将来的に変更可能
fallback: "X25519" # ハイブリッドモード対応
signature:
algorithm: "ML-DSA-65"
fallback: "ECDSA-P256"
システム改修なしで暗号アルゴリズムを設定変更で切り替えられる設計を、今から意識しておくことが重要です。
③ 情報収集と社内啓発
2026年度に詳細なロードマップが出ます。今のうちに以下をキャッチアップしておきましょう。
参考資料
おわりに
2035年という期限は、遠いようで、大規模システムのライフサイクルを考えると「すぐそこ」です。
量子計算機の脅威は、もはや「もしもの話」ではなく、「いつやるかのタスク」 になりました。
まずは今週中に、自分の担当システムで使われている暗号アルゴリズムを1つでも確認してみてください。
それが最初の一歩です。
📝 読者の皆さんへの質問
みなさんの現場では、すでにPQCへの対応や議論は始まっていますか？
- 「まだ全然」
- 「検討段階」
- 「すでに対応済み」
- 「何それ美味しいの？」
ぜひコメントで教えてください！
また、この記事が参考になったらストックしていただけると嬉しいです 🙏
参考資料
- 政府機関等における耐量子計算機暗号 (PQC) への移行について（中間とりまとめ）
- CRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）2024年度版
- NIST FIPS 203/204/205
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。