Akamaiで実現するPQC検証の最前線：国内金融機関
はじめに
2024 年以降、国内の金融機関において ポスト量子暗号（PQC）への移行検討が急速に加速しています。
背景には、米国大統領令（National Security Memorandum 10） による PQC 移行ロードマップの提示やNSA の CNSA2.0（Commercial National Security Algorithm Suite 2.0） による 2030 年前後の PQC 完全移行方針、金融庁「耐量子計算機暗号に関する検討会」 による国内金融機関への問題提起や HNDL（Harvest Now, Decrypt Later）攻撃 への危機意識の増大など様々な要因が考えられます。
これらを受け、経営層やセキュリティ責任者の間で「量子コンピュータによる将来的なデータ解読リスクは重大な経営リスクである」という認識が浸透し、現場レベルでもベンダーとの動作検証が始まっています。
本記事では、Akamai プラットフォームにおける PQC 活用に向けて、実際に検証を始めるためのステップ と 事前に考慮すべきポイント をまとめました。なお、本稿の考え方は Akamai だけでなく、TLS 復号を伴うリバースプロキシ型クラウドサービス全般に共通する内容です。
Akamai の PQC サポート状況
Akamai は、Client-Akamai 間および Akamai-Origin 間の双方においてPQC をサポートしており、国国立標準技術研究所（NIST）のFIPS 203 標準に基づく TLSバージョン1.3 ハイブリッド鍵グループ X25519MLKEM768（X25519 + ML-KEM-768） を選択できます。
ハイブリッド方式は、従来鍵交換（X25519）との併用で後方互換性を確保するものであり、クライアントやオリジンが PQC をサポートしていない場合、自動的に従来鍵交換へフォールバックすることが可能です。これはクリプトアジリティ観点で非常に重要な考え方です。
また、PQC の有効化はFQDN単位で可能であり、開発やテスト系のアプリケーションから最小構成で検証を行うことが可能です。
PQC の有効化は Client-Origin 間のエンドツーエンドで実施する必要があり、つまりAkamai が世界中に展開する地球規模のプラットフォームにおける内部通信（Akamai-Akamai 間）も対応する必要があります。Akamai では、2026年3月までを目処に全面対応予定となります。
それでは、具体的な検証ステップと考慮事項について、Client-Akamai 間、Akamai-Origin 間それぞれの区間でご紹介していきます。
Akamai Platform におけるPQC サポート区間
検証ステップと考慮事項：Client-Akamai 間
この構成では、TLSハンドシェイクにおけるClientHelloでクライアントからのPQCアルゴリズムの提案し、Akamai がServerHello で採用するアルゴリズムを決定します。検証を開始するまでのステップは非常にシンプルです。
Step.1 PQC 有効化対象の選定
先ずは開発系やテスト系を選定してAkamai にご連絡ください。
Step.2 PQC の有効化
CPコード単位でバックエンド側で利用可能な状態にします。この時点では実通信への影響はありません。
Step.3 PQC の設定
CPコードに紐づくプロパティで設定をOn にして展開します。
留意事項
・送信元クライアントのPQC 対応状況の確認
検証時はお客様拠点など特定の送信元クライアントからのみリクエストを受け付けるのが一般的です。送信元クライアントで使用するブラウザがPQC に対応しているかをご確認ください。
例えば、Google Chrome は 2024年9月リリースのVer.131 降、標準化されたML-KEM のサポートを開始しており、デフォルトで有効化されています。最新のサポート状況は各ベンダーサイトをご参照ください。
・中間装置にSSL復号化機構があるか
例えばお客様拠点の出口にインターネットFW やプロキシが存在していて、それらがSSL復号化処理を行っている場合、該当の装置がPQC に対応している必要があります。
検証ステップと考慮事項：Akamai-Origin 間
この構成では、Client-Akamai 間とは逆に、Akamaiからオリジンに対してPQC アルゴリズムの提案（ClientHello）が可能となります。検証を開始するまでのステップは以下の通りです。
Step.1 オリジン側のPQC対応
AkamaiがTLS セッションを構成する対向装置（SSL アクセラレーター、サーバー等）でTLS1.3 およびML-KEM を含むハイブリッド鍵交換のサポートをしているかご確認ください。
多くの金融機関ではこのステップに時間を要しており、検証着手が遅れる傾向があります。検証が具体化する前に早めに確認しておきたいポイントとなります。
以降のステップは Client-Akamai 間と同様となります。
留意事項
・ハンドシェイクサイズ増加への対応
PQC は従来の鍵交換と比べてメッセージサイズが大きくなり、ClientHello や ServerHello のペイロードが従来比で 10 倍以上になる場合もあります。従って、ロードバランサーやファイアウォールなどの中間装置において、メッセージサイズの制限やバッファ不足によるTLS ハンドシェイクの失敗やパフォーマンス低下などの問題を引き起こす可能性があります。
場合によってはハードウェアの入れ替えが必要になることも考えられるため、これらの問題に対応可能かどうかは提供ベンダーへ早めに確認しておくことをお勧めします。
さいごに
本記事では、Akamai における PQC 検証のステップと考慮ポイントをご紹介しました。既に主要金融機関では Client-Akamai 間のPQC 検証が開始している状況です。もしまだ検討が着手されていない場合、今後具体化する移行タイムラインに対して大きな遅れをとるリスクが存在します。
特に Akamai–Origin 間はハードウェア依存の考慮点が多いため、早期着手が重要です。Akamai は既存環境への影響を抑えながら段階的な検証が可能です。是非、お客様の Akamai 担当者にご相談ください。
