はじめに
オッス ワイ、GMOコネクトでCTOな菅野 哲（かんの さとる）です。
よろしくお願いします！
シリーズ最終回となる第3部では、実際にPQC移行をやろうとしたときに何が大変なのかを現場目線で解説します！
- 第1部: 概要とLATICEフレームワーク
- 第2部: NIST標準と国際動向
第1部・第2部では「なぜやるのか」「何を使うのか」を解説しましたが、今回は「どうやるのか」「何でハマるのか」という実践的な内容です。
ワイも実際にPQCの検証をやってきた中で、「うわ、これは想定外だった」ってことが結構あったんですよねwww そういう生々しい話も含めてお届けしますので、最後までお付き合いください！
📌 この記事でわかること
- 技術的課題（計算オーバーヘッド、鍵サイズ、相互運用性）の具体的な数値
- 組織的課題（暗号資産の可視化、レガシーシステム、スキルギャップ）のリアルな実態
- 短期・中期・長期の具体的なアクションプラン
技術的課題：「理論と現実のギャップ」
ASD/ACSCが推奨するNIST標準準拠のPQCアルゴリズム（ML-KEM、ML-DSA、SLH-DSA）を実装する際、いくつかの技術的課題に直面します。ワイが実際に検証してきた中で「これはキツい」と感じたポイントを正直にお伝えしますね。
1. 計算オーバーヘッド：意外と速いところと遅いところ
「PQCは遅い」ってよく聞きますよね？でも実際に測ってみると、思ったより複雑な結果になるんです。
まず鍵生成の話からすると、RSA-2048が約100msかかるのに対して、ML-KEM-768は約0.1ms、ML-DSA-65は約0.5msで完了します。なんと1000倍から200倍も高速なんですよ！おっ、意外と速い！って思いましたよねwww
ところが署名になると話が変わります。ECDSA P-256の署名生成が約0.5msなのに対し、ML-DSA-65は約1.5ms（3倍遅い）、SLH-DSA-128sに至っては約5ms（10倍遅い）かかります。一方で鍵交換はML-KEM-768がECDH P-256の2倍速いという結果。
（※ デスクトップクラスのCPU、liboqs実装の場合。Apple Silicon、Intel Core i7、AMD Ryzen等で同等の性能です。もちろん、実際の数値は環境によって大きく変動するよ）
ワイの見解としては、鍵生成と鍵交換はむしろ速くなるケースが多いんですが、署名がボトルネックになります。特にSLH-DSAは遅いので、大量の署名を生成する用途（コード署名サーバーとか、タイムスタンプサーバーとか）では要注意ですね。
実際にWebサーバーでベンチマークを取ってみたんですが、従来型TLS 1.3（ECDHE + ECDSA）で45,000 req/secだったのが、PQC対応TLS 1.3（ML-KEM + ML-DSA）では42,000 req/secに。約7%の低下でレイテンシは0.6ms増加という結果でした。
正直、7%の低下は多くの場合許容範囲内だと思います。ただ、金融系の超低レイテンシが求められるシステムとか、ゲームのリアルタイム通信とかだと話は別ですね。シビアなレイテンシ要件がある場合は事前検証必須です。
対策としては、AVX2やAVX-512命令セットを活用したハードウェアアクセラレーションが効果的です。あとはliboqsのような最適化されたライブラリを使うこと、TLSセッション再利用などのキャッシング戦略も重要になってきます。
// 例: liboqsの使用
#include <oqs/oqs.h>
OQS_SIG *sig = OQS_SIG_new(OQS_SIG_alg_ml_dsa_65);
// 最適化された実装を自動選択
OQS_SIG_keypair(sig, public_key, secret_key);
📊 ベンチマーク数値について
上記の数値は代表的な実装（liboqs、OpenSSL 3.x等）とデスクトップクラスのCPU（Intel Core i7/AMD Ryzen等）での参考値だよっ
実際の性能は以下の要因で大きく変動します：
- CPU世代とアーキテクチャ（AVX2/AVX-512サポート等）
- 実装ライブラリ（liboqs、BoringSSL、wolfSSL等）
- OS とカーネルバージョン
- コンパイラ最適化オプション
本番環境での採用前に、必ず実環境でベンチマークを取得してくださいね！ 約束だぞっ！
2. 鍵サイズと帯域幅：これが一番インパクトでかい
これがね、一番インパクトが大きい課題だとワイは思ってます。計算速度は案外なんとかなるんですが、サイズはどうしようもないですからね。
具体的な数字を見てください。ECDSA P-256だと公開鍵64バイト、署名64バイトなんですが、ML-DSA-65になると公開鍵1,952バイト、署名3,293バイト。公開鍵が約30倍、署名が約50倍のサイズですよ！
| アルゴリズム | 公開鍵 | 署名/暗号文 |
|---|---|---|
| ECDSA P-256 | 64 B | 64 B |
| ML-KEM-768 | 1,184 B | 1,088 B |
| ML-DSA-65 | 1,952 B | 3,293 B |
| SLH-DSA-128s | 32 B | 7,856 B |
これがX.509証明書になるとさらに効いてきます。従来型（RSA-2048 + ECDSA P-256）の証明書が約1.5KBなのに対し、PQC（ML-KEM-768 + ML-DSA-65）だと約5KB。証明書チェーン3段だと4.5KBが15KBになって、約3.3倍の増加です。
TLSハンドシェイク全体では従来型の約5KBから約17KBへ、約3.5倍の増加になります。
ワイが実際に検証したとき、「え、ClientHelloがこんなにデカくなるの！？」ってビックリしましたwww パケットキャプチャ見て二度見しましたからね。
帯域幅制約のある環境（モバイル回線とか、衛星通信とか）では、RFC 8879のTLS Certificate Compressionを活用したり、OCSP Staplingで証明書キャッシングしたりする対策が必要です。過渡期にはRoot CAはTraditional、Intermediate CAはHybrid、End EntityはPQCという段階的なアプローチも有効ですね。
3. メモリ消費：IoTは本当にキツい
組込みデバイスやIoTでは、メモリ消費が致命的な問題になることがあります。
RSA-2048の実装がスタック使用量約8KB、総使用量約10KBなのに対し、ML-DSA-65は約20KB/約26KBで2.6倍のメモリを食います。
Cortex-M0クラス（RAM 16-64KB）だとPQC対応は正直困難、Cortex-M4クラス（RAM 256KB）でようやく可能、1MB以上のRAMがある高性能クラスなら余裕という感じです。
つまり、古いIoTデバイスは物理的にPQC対応が困難なケースがあるんですよ。これは後で話す「レガシーシステム」問題にもつながってきます。
4. 相互運用性：ハマりポイントの宝庫
2025年現在のプロトコルサポート状況ですが、TLS 1.3はOpenSSL 3.2以降でML-KEMとML-DSAに対応、BoringSSLは実験的サポート、wolfSSLは商用版で対応しています。SSHはOpenSSH 9.xで実験的実装、IPsecはStrongSwanで実験的サポートという状況です。
よくある問題として、まずレガシークライアントがPQC証明書を認識できないというのがあります。これはデュアルスタック証明書で対応可能。もう一つがミドルボックスの問題で、DPI機器やロードバランサー、WAFが大きなTLSメッセージを処理できないことがあります。
ワイの知人の話ですが、検証中に「なんでTLSハンドシェイクが通らないんだ！？」って3時間ハマったことがあって、原因がロードバランサーの設定だったことがあるって聞いたことがあります。MTU調整とファームウェア更新で解決しましたが、こういうのは事前に想定しにくいですよね。
5. 標準化の遅れ：TLS以外はまだまだ
TLS 1.3のPQC拡張はIETF TLS WGで2025年中にDraftが固まる見込みですが、IKEv2（IPSECME WG）は2026年、DNSSECは2027年の予定です。
SSHについては、SSHM WG（Secure Shell Maintenance） が設立されており、ここで暗号アルゴリズムの更新・新アルゴリズム選定が進められています。2024年12月にはsntrup761-x25519（PQCハイブリッド鍵交換）のdraft採用呼びかけが行われました。OpenSSH、wolfSSH、AWS Transfer FamilyなどはすでにPQC対応の実装を進めています。
つまりTLS以外はまだ標準化が完了していないものが多いんです。過渡期にはベンダー独自拡張を使うか、実験的実装でテストするか、Open Quantum Safe（OQS）プロジェクトを活用するかという選択になります。
組織的課題：「技術だけでは解決できない問題」
技術的な課題もさることながら、実は組織的な課題のほうが厄介だったりします。技術は時間をかければ解決できますが、人と組織の問題は一筋縄ではいきませんからね。
1. 暗号資産の可視化：見えない暗号が多すぎる
Webサーバーの証明書やVPN接続、データベース暗号化みたいな「見える暗号」は把握しやすいんですが、問題は「見えにくい暗号」のほうです。マイクロサービス間のmTLS、IoTデバイスのファームウェア署名、バックアップシステムの暗号化、組込みデバイスのセキュアブート、モバイルアプリのコード署名、サードパーティライブラリ内の暗号処理…こういうのが厄介なんですよね。
発見ツールとしては、nmapでネットワークスキャンして証明書を発見したり、findコマンドでファイルシステムをスキャンしたり、lsofで暗号ライブラリの使用状況を確認したりできます。
# ネットワークスキャンによる証明書発見
nmap --script ssl-cert -p 443 192.168.1.0/24
# ファイルシステムスキャン
find / -type f \( -name "*.pem" -o -name "*.crt" \
-o -name "*.key" -o -name "*.p12" \) 2>/dev/null
# プロセスの暗号ライブラリ使用状況
lsof | grep -E "libssl|libcrypto"
ワイのお勧めは、CBOM（Cryptographic Bill of Materials）を早い段階で作り始めることです。後になればなるほど大変になりますからね！SBOMがソフトウェア部品表なら、CBOMは暗号部品表。これがないと移行計画は絵に描いた餅になります。
2. レガシーシステム：一番頭が痛い問題
これが一番頭が痛い問題かもしれません。レガシーシステムは大きく3つに分類できます。
「更新可能」なのは最近のネットワーク機器やモダンIoTで、ベンダーサポートがあって計算リソースも十分なもの。「部分的に更新可能」なのは中古ネットワーク機器や一部の医療機器で、ベンダーサポートが限定的でカスタム対応が必要なもの。そして「更新困難」なのが旧型ATM、衛星システム、古い産業制御システムで、ベンダーサポート終了済みでハードウェア制約も厳しいもの。
更新困難なシステムへの対応としては、ゲートウェイアプローチが現実的です。レガシーデバイスとPQCゲートウェイの間は従来型暗号で、ゲートウェイと外部ネットワークの間はPQCで通信するという構成ですね。デバイス自体は変更不要で集中管理も可能ですが、ゲートウェイが単一障害点になるリスクは考慮が必要です。
どうしても更新できないシステムには、ネットワーク分離、追加の認証層、厳格なアクセス制御に加えて、リスク受容の正式承認を経営層から取っておくことが重要です。「分かった上で残している」という記録を残さないと、後で問題になりますからね。
3. スキルギャップ：人材がいない
PQCの移行には、暗号学の基礎（公開鍵暗号の原理、量子計算機の脅威理解、PQCアルゴリズムの特性）、実装スキル（TLS/PKIの深い理解、暗号ライブラリの使用経験、セキュアコーディング）、運用スキル（鍵管理、証明書ライフサイクル管理、インシデント対応）が必要になります。
現実問題として、PQCの実務経験がある人材は非常に少ないです。対策としては、外部専門家の活用（コンサルティング）、段階的なスキルアップ（トレーニング）、コミュニティへの参加（IETF、学会等）が考えられます。
ワイも最初は手探りでしたが、実際にコードを書いて、動かして、ハマって…というサイクルを回すのが一番の近道だと思います！教科書読むより手を動かせ、です。
4. コストと優先順位付け：予算をどう取るか
コスト要素としては、専門人材の確保やトレーニングの人件費、暗号資産発見ツールやテスト環境のツール費、ハードウェア更新やライセンスのインフラ費、外部専門家のコンサルティング費、そして他プロジェクトの遅延という機会費用があります。
予算確保のコツとしては、リスクベースの説明が効果的です。「Harvest Now, Decrypt Later攻撃で、今暗号化しているデータが将来解読されますよ」というシナリオを経営層に説明すると、「それは困る」となりやすい。規制対応の観点（将来的な義務化の可能性）や、段階的な投資計画（一度に全部ではなく年次で分割）という切り口も有効ですね。
推奨事項：段階的アプローチ
短期的アクション（2025-2026）
ASDが求める「2026年末までに計画を策定」を達成するためのアクションです。
まず暗号インベントリの作成から始めましょう。ネットワークスキャンで証明書を発見し、ファイルシステムで鍵ファイルを探索します。
# Step 1: ネットワークスキャン
nmap --script ssl-cert -p 443,8443 10.0.0.0/8
# Step 2: 証明書の詳細確認
for cert in $(find /etc -name "*.crt" 2>/dev/null); do
echo "=== $cert ==="
openssl x509 -in "$cert" -text -noout | grep -E "Algorithm|Subject:"
done
次にリスク評価と優先順位付けです。データの機密性が高くて寿命が長い（5年以上）ものが最優先、機密性が高くて中期（1-5年）、または機密性が中程度で長期のものが高優先度、という感じで分類していきます。
そしてベンダーとの対話。主要ベンダーにPQC対応ロードマップ、対応予定アルゴリズム、移行に必要なアクションを問い合わせましょう。対応が遅いベンダーは早めに分かったほうがいいですからね。
最後にパイロットプロジェクトの選定。非本番環境から始めて、影響範囲が限定的なシステムで、技術チームの学習機会として活用するのがベストです。
中期的アクション（2027-2028）
ASDが求める「2028年末までに重要システムで実装開始」を達成するためのアクションです。
パイロット実装では、PQC対応TLSサーバーの設定などを実際に動かしてみます。ハイブリッドモード（X25519MLKEM768など）から始めるのが安全ですね。
# 例: PQC対応TLSサーバーの設定（疑似コード）
import ssl
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.set_ciphers('TLS_AES_256_GCM_SHA384')
# 注意: 以下は疑似コードなので雰囲気を示しています。
# Python標準ライブラリの ssl モジュールでは、ハイブリッドPQC-KEMの
# 直接設定はサポートされていません（2025年11月時点）
#
# 実際の実装には以下が必要：
# - OpenSSL 3.5+ + oqs-provider: 環境変数やconfigで設定
# - AWS-LC: aws-lc-pythonライブラリ使用
# - カスタムビルド: ctypes経由で拡張API呼び出し
#
# ssl_context.set_groups(['X25519MLKEM768', 'X25519']) # 疑似コード
段階的ロールアウトは、開発環境（1-2ヶ月）→テスト環境（2-3ヶ月）→ステージング環境（1-2ヶ月）→本番環境・限定（2-3ヶ月）→本番環境・全面（3-6ヶ月）という流れで。焦らないことが大事です。
並行してモニタリング体制の構築も進めます。パフォーマンス監視、エラー率監視、互換性問題の検出ができる体制を整えておかないと、問題が起きたときに原因究明できませんからね。
長期的アクション（2029-2030以降）
ASDが求める「2030年末までの完全移行」を達成するためのアクションです。
完全移行の達成に向けた最終チェックリストとしては、すべてのシステムがML-KEM/ML-DSA/SLH-DSAを使用していること、従来の非対称暗号（RSA、ECDSA、DH/ECDH）を完全撤廃していること、ハイブリッドモードから純粋PQCへの移行が完了していること、などを確認します。
継続的監視では、非PQC接続の検出を継続的にチェックし、暗号脆弱性のスキャンを週次で実施、TLSハンドシェイクレイテンシが閾値（100msなど）を超えていないか監視します。
そして標準への適応。新しいNIST/IETF標準が出たら、影響評価（2週間）→意思決定（1週間）→実装計画策定（2週間）→実装とテスト（4-8週間）→モニタリングと最適化（継続）というサイクルを回します。
まとめ：5つの鍵
長い記事になりましたが、PQC移行成功のための5つの鍵をまとめます。
-
1つ目は「早期開始」
- 2024-2025年に計画着手すべき。今すぐできることとして、暗号インベントリの開始、ステークホルダー教育の開始、ベンダーへの問い合わせ、パイロットプロジェクトの計画があります。
-
2つ目は「段階的アプローチ」
- 高価値資産から優先して、Wave 1で長期機密データ（医療、金融等）、Wave 2で重要インフラ（VPN、TLS、PKI）、Wave 3でミッションクリティカルシステム、Wave 4で一般システムとレガシーシステムという順番で進めます。
-
3つ目は「ベンダーとの緊密な連携」
- PQCロードマップの確認、SLA更新とPQC要件追加、早期アクセスプログラムの活用、定期的な進捗レビューが重要です。
-
4つ目は「継続的な監視と適応」
- セキュリティ監視（脆弱性追跡）、パフォーマンス監視（レイテンシ、スループット）、コンプライアンス監視（ASD/ACSC要件）、標準更新への対応（NIST、IETF等）を継続的に行います。
-
5つ目は「国際標準への準拠」
- 相互運用性の確保、ベンダーサポートの充実、コミュニティからの支援、将来の更新への対応力という価値が得られます。
行動を起こすために
今すぐできること（次の30日間） として、組織内の暗号使用箇所の調査開始、経営層へのPQCプレゼンテーション実施、主要ベンダーへのPQCロードマップ問い合わせ、パイロットプロジェクトのスコープ定義があります。
3ヶ月以内に、完全な暗号インベントリ（CBOM）の完成、リスク評価と優先順位付けの完了、2025年度予算へのPQC移行費用計上、詳細な移行計画（3-5年）の策定を目指しましょう。
1年以内には、非本番環境でのパイロットプロジェクト実施、主要ベンダーとの契約更新（PQC要件を含む）、技術チームのトレーニング完了、最初のシステム移行完了（開発環境等）まで到達したいところです。
最後に
長いシリーズ記事を最後まで読んでいただき、ありがとうございました！
量子計算機の脅威は確実に迫っています。
専門家の多くは、2030年代にはCRQCが実用化される可能性があると予測しています。そして、「Harvest Now, Decrypt Later」攻撃を考えると、実用化を待つ余裕はありません。今日暗号化したデータが、10年後に解読されるかもしれないんです。
ASD/ACSCのガイダンスは、この重要な移行を成功させるための強固な基盤を提供しています。明確な目標（2030年完全移行）、実証済みのフレームワーク（LATICE）、信頼できる標準（NIST FIPS 203/204/205）が揃っています。
今日から行動を開始しましょう！
明日延ばすことは、攻撃者に1日分のアドバンテージを与えることになります。2030年は遠い未来ではありません。今すぐ始める時です！
議論しましょう！
この記事を読んで、気になったことはありますか？
「うちもこういう課題がある」「実際にやってみたらこうだった」「この部分をもっと詳しく知りたい」など、ぜひコメント欄で教えてください！
ワイもPQC移行の検証を続けていくので、新しい発見があればまた記事にしますね！
いいね・ストックもお待ちしています 🙏
参考資料
公式ガイダンス
- Australian Cyber Security Centre: Planning for Post-Quantum Cryptography
- NIST Post-Quantum Cryptography
- CISA Quantum-Readiness
技術リソース
実装ガイド
シリーズ記事
- 【2030年問題】オーストラリア政府が突きつけた"暗号全取替え"の衝撃 ― LATICEフレームワーク完全解説
- 【徹底比較】NIST標準ML-KEM/ML-DSA/SLH-DSAと各国のPQC動向を追う
- 【実践編】PQC移行で絶対ハマるポイントと対策を現場目線で解説（本記事）
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。