米Oracle（オラクル）は2026年9月15日、耐量子計算機暗号（PQC）規格「ML-KEM」を用いたハイブリッド鍵交換を標準搭載した「Java 27」を公開し、過去の長期サポート（LTS）版へのバックポート計画を発表した。日本の金融庁や重要インフラ各社が策定を進める耐量子暗号移行ガイドラインの実効性が、基幹システムのランタイム更新によって直近の運用計画に組み込まれる。
Javaエコシステムで進むML-KEM標準化と過去LTSへの遡行適用
米国立標準技術研究所（NIST）が2024年8月にFIPS 203（ML-KEM）を正式策定して以降、通信インフラのPQC対応は実験段階から本番環境の実装段階へ移行した。OracleはJava 27において、JEP 527に基づくTLS 1.3のハイブリッド鍵交換を一般公開（GA）した。この機能は、標準のjavax.net.ssl APIを用いる通信において、コードの再設計を伴わずに「X25519MLKEM768」などのハイブリッド方式を自動的に利用可能にする。
加えて、Oracleは2026年8月に公表したロードマップに沿い、エンタープライズの現場で稼働し続けている過去のLTS版に対するバックポートを順次実行する。Azul Systems（アズール・システムズ）などの独立系ディストリビューターも2026年7月時点でJava 25向けバックポートを先行提供しており、主要ディストリビューション全体で足並みが揃いつつある。
| 提供版（JDKバージョン） | 提供時期・ステータス | 実装される主な暗号機能 | 既存アプリケーション改修の要否 |
|---|---|---|---|
| Java 27（最新GA） | 2026年9月15日公開 | TLS 1.3ハイブリッド鍵交換（JEP 527）、ML-KEM / ML-DSA | 不要（標準API利用時） |
| JDK 25（LTS） | 2026年10月（CPU更新） | TLS 1.3ハイブリッド鍵交換（JDK 27同等機能） | 不要（ランタイム更新のみ） |
| JDK 21 / JDK 17（LTS） | 2027年上半期（H1）提供予定 | ML-KEMアルゴリズムおよびTLS 1.3ハイブリッド通信 | 不要（ランタイム更新のみ） |
| JDK 11 / JDK 8（LTS） | 2027年下半期（H2）提供予定 | 過去資産向けTLS 1.3ハイブリッド鍵交換バックポート | 不要（ランタイム更新のみ） |
米国家安全保障局（NSA）が定めるCNSA 2.0（商用国家安全保障アルゴリズムスイート 2.0）では、ネットワーク機器や通信プロトコルのPQC移行期限を2030年に設定している。Javaの基盤機能が過去バージョンを含めて更新されることで、企業は数千におよぶ業務システムのソースコードを書き換えることなく、インフラのパッチ適用と設定変更によって暗号移行の初期要件を満たせる体制が整った。
参考記事: 耐量子暗号（PQC）とは？CISOが急ぐべき暗号インベントリと2030年への移行ロードマップ
RFC 9954準拠のハイブリッド鍵交換とハンドシェイク肥大化の検証
Java 27における暗号実装の要点は、IETFがRFC 9954として標準化したTLS 1.3ハイブリッド鍵交換の採用にある。従来の楕円曲線暗号（X25519など）とモジュール格子暗号（ML-KEM-768）を組み合わせる方式であり、仮に将来ML-KEMに未知の脆弱性が発見された場合でも、従来の古典暗号強度が通信を保護する設計となっている。
[クライアント] [サーバー]
| |
| ----- ClientHello --------------------------------> |
| (Key Share: X25519 + ML-KEM-768 公開鍵) |
| ※ ハンドシェイクサイズが1,000バイト以上増加 |
| |
| |
| |
| |
この実装における技術的な前提条件は、暗号演算の正確性だけでなく、ネットワークレイヤーにおけるパケット断片化への耐性である。Red Sift（レッド・シフト）などの調査データによると、ML-KEMを用いたハイブリッド鍵交換では、TLSハンドシェイク時の公開鍵および暗号文のサイズが1回あたり1,000バイト以上増加する。
| 評価指標 | 従来の古典暗号（X25519単体） | ハイブリッド方式（X25519 + ML-KEM-768） | エンジニアリング上の影響 |
|---|---|---|---|
| 公開鍵・共有データサイズ | 約32バイト（極小） | 1,184バイト以上（大幅増） | MTU超過によるパケット断片化の発生率上昇 |
| 暗号強度（古典計算機） | 128ビット相当 | 128ビット以上を維持 | 二重の暗号強度によるフォールバック保護 |
| 暗号強度（量子計算機） | 解読可能（Shorのアルゴリズム） | 解読困難（格子問題に依存） | 事前傍受・将来解読（HNDL攻撃）への対抗 |
| Java実行時のコード変更 | – | 標準javax.net.ssl利用時は原則不要 |
システムプロパティでの有効化・無効化制御が可能 |
通信サイズが増加することにより、ネットワーク機器の最大伝送単位（MTU）サイズを超過し、IPフラグメンテーションが発生するケースが懸念される。レガシーなファイアウォールやロードバランサーが断片化パケットを破棄する環境では、通信タイムアウトや接続遅延が発生する。JavaランタイムがPQCに対応したとしても、経路上のネットワークインフラが大きなハンドシェイクパケットを正常に中継できるかが、実運用上の条件となる。
参考記事: 耐量子暗号（PQC）のハードウェア実装ロードマップ｜主要半導体ベンダーの対応と移行の技術的課題
日本企業のシステム維持と2027年デッドラインへの適合
OracleがJDK 8やJDK 11という10年以上前の設計基盤に対しても2027年下半期にバックポートを予定したことで、日本のエンタープライズシステムにおける暗号刷新の進め方は大きく変わる。金融機関の勘定系や決済基盤、製造業のSCADA連携基盤など、Java 8や11上で稼働し続けているレガシーシステムは国内に数多く存在する。これらを「Java 27以降への全面書き換え」なしに保護できる選択肢が生まれた。
一方で、暗号アジリティ（暗号方式を柔軟に切り替える能力）の獲得には、ランタイム更新だけでは完結しない障壁がある。
第一に、独自の実装を行っている通信モジュールへの対応である。標準のjavax.net.sslを介さず、古いサードパーティ製暗号ライブラリやJNI（Java Native Interface）経由のC言語ラッパーを使用している場合、ランタイムの更新恩恵を受けられない。これらは個別のコード監査と書き換えが必要になる。
第二に、国外規制への対応期限である。フランス国家情報システムセキュリティ庁（ANSSI）が2027年以降に量子耐性のない暗号製品の認証を停止する方針を掲げているほか、米国市場に展開するサプライチェーン企業に対してもCNSA 2.0適合の証明が求められ始める。日本国内で稼働するバックオフィスシステムであっても、グローバルなデータ連携ハブとして機能している場合は、2027年までに通信相手のPQC要件を満たさなければ接続を遮断されるリスクがある。
参考記事: [耐量子暗号（PQC）の移行はいつ？フランスANSSI2027年方針とWeb3・重要インフラが直面する3つの技術的課題](https://techshift.jp/2026/06/19/post-1493/
暗号資産の特定とパケット検証の着手手順
基幹システムのPQC対応を計画する組織は、以下の手順に沿って技術的検証を進めることが求められる。
- システム内で稼働するJavaランタイムのバージョンおよび暗号ライブラリの棚卸しを実施する
組織内のJava資産において、標準のjavax.net.sslを利用している箇所と、Bouncy Castle等の外部暗号プロバイダや独自実装に依存している通信モジュールを特定し、暗号インベントリとして一覧化する。
- ステージング環境におけるJDK 27または先行バックポート版の検証に着手する
テスト環境においてML-KEMハイブリッド鍵交換を有効化し、ハンドシェイクサイズの増大（1,000バイト超）が既存のロードバランサー、WAF、ファイアウォールでドロップや遅延を引き起こさないかパケットレベルで監視する。
- LTS版の更新スケジュールに合わせたパッチ適用計画を策定する
自社が使用しているバージョン（JDK 17/21は2027年上半期、JDK 8/11は2027年下半期）のバックポート公開時期を把握し、四半期ごとの保守ウィンドウにランタイム更新を組み込む。
出典: 日経クロステック
出典: Oracle
出典: DevOps.com
出典: Oracle Blogs
出典: OpenJDK
出典: IETF Datatracker
出典: Red Sift
