セキュリティ

耐量子暗号（PQC）、実際に何を設定すればいいのか — Linux・クラウド・メッセージングアプリの現在地

2026/08/17

1. まず全体像

本誌の別記事「耐量子暗号（PQC）への移行状況」で見た通り、進捗はレイヤーごとに大きく異なる。ここでは、実際に手を動かす立場から「何を、どう設定すればいいのか」を具体的に見ていく。

2. 自分でLinuxサーバーを運用している場合

鍵となるのはOpenSSLのバージョンだ。ML-KEM（NIST標準FIPS 203）が外部パッチなしで標準搭載されたのはOpenSSL 3.5（2025年4月リリース）からで、それより前のバージョンでは鍵交換自体はハイブリッド対応できても、署名アルゴリズムまでは対応できない。

nginxがOpenSSL 3.5以上でビルドされていれば、設定ファイルに以下を1行加えるだけで有効化できる。

ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

X25519とprime256v1（従来型の楕円曲線）を併記しておくことで、PQC非対応のクライアントは自動的に従来方式へフォールバックする。

問題は、主要ディストリビューションの多くが、まだこのバージョンを標準搭載していないことだ。2026年時点でOpenSSL 3.5をネイティブに搭載しているのは、Debian 13・Alpine 3.22・RHEL 10.1・SLES 16などに限られる。Ubuntu 24.04 LTSのような広く使われているディストリビューションでも、手動でのビルド・アップグレードが必要になる。

Red Hat系ディストリビューションの状況

Red Hat系は状況が枝分かれしている。

RHEL 9.7：OpenSSL 3.5とNSSをバックポートする形で、先行的にPQC対応が入った。ただし既定では無効化されており、有効化には以下のコマンド1つで済む。
```
update-crypto-policies --set DEFAULT:PQ
```
これでmlkem768x25519などのハイブリッドML-KEMグループが、既存の暗号ポリシーの上に最優先で有効化される
RHEL 10.1：ネイティブに標準搭載（既定で対応済み）
Rocky Linux・AlmaLinux・CentOS Stream：RHELと同じcrypto-policiesの枠組みを共有しているが、RHEL 9.7の該当バックポートがそのまま反映されているかはディストリビューションごとに差がある。運用中のバージョンでopenssl versionとupdate-crypto-policies --showを実際に確認するのが確実だ
Fedora：上流の開発版という性質上、通常は主要ディストリビューションの中で最も早く新しいOpenSSLが入る

3. クラウド・サーバーレス（Fargate・Lambda等）の場合

FargateやLambdaそのものはTLSを終端しないことが多く、実際には手前のALB（Application Load Balancer）・API Gateway・CloudFrontがTLS終端を担う。したがって、PQC対応の実態はこれらのサービス側の設定に左右される。

CloudFront：既に自動的に対応済み。利用者側での設定は不要
ALB・NLB（Network Load Balancer）：2025年11月に対応が追加されたが、既存のリスナーは自動更新されない。PQ-TLS対応のセキュリティポリシーへ明示的に切り替える必要がある
API Gateway：CloudFrontやALBと同じ展開の一環として順次対応が進んでいる

つまり、FargateやLambdaを使っていても、ALBやAPI Gatewayのセキュリティポリシーを能動的に見直さない限り、PQC対応にはならない。

Vercelについて

正直に言うと、Vercelの耐量子暗号対応について、信頼できる一次情報は見つからなかった。Cloudflare・AWS・Akamaiほど積極的に公表していないようだ。利用している場合は、公式のセキュリティドキュメントかサポートへの直接確認をおすすめする。

参考：Akamai

Akamaiは2025年9月からハイブリッドML-KEM+X25519の展開を開始し、2026年2月からは全顧客へのデフォルト適用に移行している。

4. メッセージングアプリは、そもそもの前提が揺らいでいる

主要なメッセージングアプリの状況も確認しておく価値がある。ただし、ここでの実情は芳しくない。

Instagram：PQC以前の問題として、2026年5月8日付けでDMのエンドツーエンド暗号化機能そのものが廃止された。もともとオプトイン（任意設定）で利用者が少なかったことを理由にMetaが機能を取りやめたもので、EFFはこれを「約束の反故」として批判している。E2E暗号化自体が存在しない以上、PQC対応を論じる前提が失われた形だ
Facebook Messenger：2023年12月に1対1のチャットでデフォルトE2E暗号化を導入済み（Signal Protocolと、Meta独自の「Labyrinth」プロトコルの組み合わせ）。ただしPQC（ML-KEM等）を採用したことを確認できる一次情報は見当たらない。Signal本家は2023年にPQXDHへ移行済みだが、Messenger側が追随したという情報はない。グループチャットのE2E暗号化についても、Metaが約束していたにもかかわらず、いまだ未実装のままだ
LINE：独自のE2E暗号化機能「Letter Sealing」を持つが、鍵交換には従来型のECDH（楕円曲線ディフィー・ヘルマン鍵共有）を使っている。PQC対応の計画・実装は、公開情報からは確認できなかった

SignalとApple iMessageが先行する一方で、利用者数で見劣りしないはずの大手アプリの多くが後れを取っている、という構図が改めて見えてくる。

5. 実務上、まず何を確認すべきか

ここまでをまとめると、優先して確認すべき順序はおおよそ次のようになる。

自組織が運用するLinuxサーバーのOpenSSLバージョンを確認する（openssl version）。3.5未満なら、まずここが最初のボトルネックになる
クラウド上のTLS終端ポイント（ALB・API Gateway・CloudFront等）のセキュリティポリシー設定を確認する。多くの場合、対応機能自体は存在していても、既定では有効化されていない
社内外で使っているメッセージングアプリの暗号化方式を、「E2E暗号化があるか」「PQC対応かどうか」の2段階で確認する。前提のE2E自体が存在しない、あるいはオプトインのまま忘れられているケースも珍しくない

PQCへの移行は「対応しているサービスに乗り換える」だけでなく、「今使っているものが、実際にはどの設定になっているか」を一つずつ確認していく地道な作業だ。標準規格が整った今、残っている作業のほとんどは、こうした運用上の確認と設定変更に尽きる。