Microsoft Build of OpenJDK 2026年7月更新対象は？25.0.4・21.0.12・17.0.20・11.0.32を整理

Microsoft Build of OpenJDKの2026年7月セキュリティ更新で、更新先として確認すべきバージョンは、25.0.4、21.0.12、17.0.20、11.0.32です。現在利用しているメジャーバージョンを維持したまま、対応する最新パッチへ更新するのが基本です。たとえば、Java 21を利用しているシステムは21.0.12へ更新し、セキュリティ更新だけを目的にJava 25へ変更する必要はありません。(Microsoft for Developers)

今回の更新では、Windowsのプロセッサーグループを正しく列挙するための変更と、Windows ARM64向けの調整が含まれています。特に、論理プロセッサ数が多いWindows Serverや、ARM版WindowsでJavaを運用している場合は、通常の動作確認に加えてCPU認識数やJVMのスレッド設定も確認しておく必要があります。(Microsoft Learn)

Microsoft Build of OpenJDK 2026年7月更新、必要なJDKバージョン一覧

2026年7月の更新対象と、更新後に確認すべきバージョンは次のとおりです。

利用中のJDK系統	更新後のバージョン	直前バージョンからの更新例	Microsoft固有の主な変更
OpenJDK 25	25.0.4	25.0.3 → 25.0.4	全プロセッサーグループの列挙、Windows ARM64のスレッド取得処理最適化、Reserved Stack Areaの扱い変更
OpenJDK 21	21.0.12	21.0.11 → 21.0.12	全プロセッサーグループの列挙、Windows ARM64でReserved Stack Areaを非対応化
OpenJDK 17	17.0.20	17.0.19 → 17.0.20	全プロセッサーグループの列挙、Windows ARM64でReserved Stack Areaを非対応化
OpenJDK 11	11.0.32	11.0.31 → 11.0.32	全プロセッサーグループの列挙、Windows ARM64でReserved Stack Areaを非対応化

Microsoftのダウンロードページでは、この4系統がLTSリリースとして案内されています。Windows、Linux、macOS向けにx64およびARM64版が用意され、OpenJDK 17と11にはAlpine Linux向けのx64バイナリもあります。(Microsoft Learn)

更新先は同じメジャーバージョンの最新パッチを選ぶ

今回の更新は、Javaのメジャーバージョンを移行するためのものではありません。

現在の構成が次のようになっている場合は、原則として同じ行の右側へ更新します。

現在の構成	推奨する対応
Java 25を利用中	25.0.4へ更新
Java 21を利用中	21.0.12へ更新
Java 17を利用中	17.0.20へ更新
Java 11を利用中	11.0.32へ更新
Java 8を利用中	Microsoft Buildではなく、Eclipse Temurin 8の更新を確認
Oracle JDKや別ベンダーのOpenJDKを利用中	そのベンダーが公開する2026年7月更新を確認

たとえば、Spring BootアプリケーションをJava 17で運用している場合、まず17.0.20へ更新します。Java 21や25への移行は、フレームワーク、ライブラリ、ビルド設定、コンテナーベースイメージを含めた別の移行作業として計画するのが安全です。

2026年7月更新で変わるWindows関連のポイント

Windowsの全プロセッサーグループを列挙する変更

OpenJDK 25.0.4、21.0.12、17.0.20、11.0.32では、Windowsの「Processor Information」カウンターを利用し、すべてのプロセッサーグループに存在するプロセッサーを列挙する変更が加えられました。(Microsoft Learn)

Windowsでは、64個を超える論理プロセッサを扱うため、最大64論理プロセッサで構成される「プロセッサーグループ」という単位が使われます。64個以下の環境は通常Group 0だけですが、64個を超える大規模サーバーでは複数グループが作成されます。(Microsoft Learn)

また、「Processor Information」は、インストールされているCPUごとの情報を提供するWindowsのパフォーマンスカウンターです。今回の変更は、この情報を使って複数のプロセッサーグループを横断的に列挙するものです。(Microsoft Learn)

特に確認が必要な環境

次のような環境では、更新前後のCPU認識状況を比較してください。

64個を超える論理プロセッサを搭載したWindows Server
大規模なAzure VMやオンプレミスのマルチソケットサーバー
NUMA構成のWindowsサーバー
JavaのGCスレッド数やコンパイラスレッド数を自動設定に任せている環境
CPU数に応じてアプリケーション側のワーカースレッド数を決めているシステム
性能試験の基準値を厳密に管理しているシステム

一方、論理プロセッサ数が64個以下の一般的なPCや小規模サーバーでは、この変更による目立った動作差が発生する可能性は高くありません。ただし、セキュリティ更新自体は適用対象です。

JVMの自動設定が変わっていないか確認する

プロセッサの認識数は、GCスレッド数やJITコンパイラスレッド数などの自動設定に影響する場合があります。更新前後で次のコマンドを実行し、値を比較すると判断しやすくなります。

Windows PowerShellでは、次のように確認できます。

java -XX:+PrintFlagsFinal -version 2>&1 |
  Select-String 'ActiveProcessorCount|ParallelGCThreads|ConcGCThreads|CICompilerCount'

稼働中のJVMを確認できる場合は、jcmdも利用できます。

jcmd <PID> VM.version
jcmd <PID> VM.flags
jcmd <PID> VM.command_line

更新後にスレッド数が変わった場合でも、直ちに不具合とは限りません。CPU使用率、処理件数、GC時間、レスポンスタイムを合わせて比較してください。

なお、起動オプションで次のようにCPU数を固定している場合、JVMによる自動認識の変更が表面化しない可能性があります。

-XX:ActiveProcessorCount=8

今回の変更から、大規模Windows環境ではCPU数に連動するJVM設定が変化する可能性が考えられます。ただし、すべての環境で性能が向上することを保証する変更ではありません。

Windows ARM64ではReserved Stack Areaを非対応として扱う

4つの更新バージョンすべてで、Windows ARM64上のReserved Stack Areaが非対応として扱われるようになりました。これはWindows ARM64に限定された変更であり、Windows x64やLinux、macOSでReserved Stack Areaが一律に削除されるという意味ではありません。(Microsoft Learn)

Reserved Stack Areaは、スタックオーバーフローが発生した状況でも、ロック解除などの重要な処理を完了できるように、Javaスレッドのスタック領域を一部予約する仕組みです。(OpenJDK)

通常のWebアプリケーションや業務システムで、利用者がこの機能を直接設定しているケースは多くありません。ただし、次のような環境では回帰テストを実施してください。

深い再帰処理を使用するアプリケーション
StackOverflowError発生後の復旧処理をテストしているシステム
Javaエージェントやネイティブエージェントを利用している環境
JNIや独自ネイティブライブラリを組み込んでいるアプリケーション
JVM内部のスタック処理に依存する低レベルの検証ツール
Windows ARM64版のJDKを本番利用しているシステム

一般的なアプリケーションでは、この変更に対応するための新しいJVMオプションを追加する必要はありません。Windows ARM64環境で、スタックオーバーフロー周辺の挙動に依存している場合だけ、重点的に確認します。

OpenJDK 25だけにWindows ARM64向け最適化が追加

OpenJDK 25.0.4では、Windows ARM64向けのaarch64_get_thread_helper()が最適化されました。これはJVM内部でスレッド情報を取得するための実装レベルの変更であり、Javaアプリケーションが新しいAPIを呼び出したり、特別な設定を追加したりする必要はありません。(Microsoft Learn)

この変更はOpenJDK 25.0.4だけに記載されており、21.0.12、17.0.20、11.0.32には含まれていません。

実務上は、Windows ARM64でOpenJDK 25を利用している場合に、次の項目を確認すれば十分です。

アプリケーションが正常に起動するか
Javaエージェントが読み込まれるか
JNIを利用する機能が動作するか
高負荷時にクラッシュや異常終了が発生しないか
更新前後でスループットやCPU使用率に不自然な変化がないか

内部最適化であるため、アプリケーション全体が大幅に高速化すると断定することはできません。

OpenJDK 8は今回のMicrosoft Build更新対象ではない

OpenJDK 8は、25.0.4、21.0.12、17.0.20、11.0.32と同じ「Microsoft Build of OpenJDK」の更新対象としては掲載されていません。

Microsoftは、Java 8が必要な利用者に対して、Eclipse Adoptiumプロジェクトが提供するEclipse TemurinのOpenJDK 8ビルドを案内しています。また、Microsoft Container Registryで提供されるOpenJDK 8イメージにも、Microsoft BuildではなくEclipse Temurinのバイナリが含まれます。(Microsoft for Developers)

項目	OpenJDK 11・17・21・25	OpenJDK 8
Javaバイナリ	Microsoft Build of OpenJDK	Eclipse Temurin
2026年7月の更新先	11.0.32、17.0.20、21.0.12、25.0.4	最新のTemurin 8を確認
単体バイナリの入手先	Microsoftのダウンロードページ	Eclipse Adoptium
MCRイメージ内のJDK	Microsoft Build	Eclipse Temurin
Microsoft Buildへの単純な置き換え	同じメジャー内で可能	Microsoft Build 8としては扱わない

Java 8を利用しているアプリケーションを、誤って11.0.32へ更新してはいけません。Java 8から11への変更はメジャーバージョン移行であり、ライブラリ、JVMオプション、モジュール、文字コード、TLS、GC設定などを含めた互換性検証が必要です。

OpenJDK 8で確認できるMCRタグ

2026年8月1日時点で、Microsoft Container Registryのタグ一覧から確認できるOpenJDK 8向けタグは次の3系統です。

タグ	用途・状態
`8-azurelinux`	Azure Linux 3.0ベースとして利用する標準候補
`8-distroless`	Azure Linux 3.0のDistrolessイメージ
`8-mariner`	現在は`8-azurelinux`をミラーするレガシー名称
`8-mariner-cm2`	EOLのCBL-Mariner 2.0ベース。新規利用は避ける

Microsoft Learnでは、OpenJDK 8のUbuntu 22.04向けタグは「N/A」とされており、MCRの実際のタグ一覧にも8-ubuntuは含まれていません。2026年7月の告知文ではUbuntuへの言及もありますが、Dockerfileへ記載する際は、実際に公開されているタグを基準にしてください。(Microsoft Learn)

したがって、次の記述を確認なしで使用するのは避けます。

FROM mcr.microsoft.com/openjdk/jdk:8-ubuntu

MicrosoftのレジストリからJava 8イメージを利用する場合は、次のいずれかを検討します。

FROM mcr.microsoft.com/openjdk/jdk:8-azurelinux

または、シェルやパッケージマネージャーを必要としない構成では次のタグを検討します。

FROM mcr.microsoft.com/openjdk/jdk:8-distroless

OpenJDK 8イメージのバージョン確認方法

Azure Linuxベースのイメージは、次のコマンドで取得して確認できます。

docker pull mcr.microsoft.com/openjdk/jdk:8-azurelinux

docker run --rm \
  mcr.microsoft.com/openjdk/jdk:8-azurelinux \
  java -version

Distrolessイメージでは、Javaがエントリーポイントとして設定されているため、次のように確認します。

docker pull mcr.microsoft.com/openjdk/jdk:8-distroless

docker run --rm \
  mcr.microsoft.com/openjdk/jdk:8-distroless \
  -version

Microsoftのコンテナーイメージでは、マイナーバージョンを指定したタグは提供されず、メジャーバージョンのタグがその時点の最新マイナーバージョンを指します。そのため、同じ8-azurelinuxや21-ubuntuでも、取得時期によってイメージのダイジェストやJDKのパッチバージョンが変わります。(Microsoft Learn)

再現性を重視する本番環境ではダイジェストを固定しつつ、セキュリティ更新時に新しいダイジェストへ計画的に更新する運用が適しています。

docker image inspect \
  --format='{{index .RepoDigests 0}}' \
  mcr.microsoft.com/openjdk/jdk:8-azurelinux

イメージをプルしただけでは、既存のコンテナーやPodは新しいJDKに切り替わりません。アプリケーションイメージを再ビルドし、新しいイメージまたはダイジェストで再デプロイしてください。

なお、Microsoftが提供するOpenJDKコンテナーイメージはLinuxベースです。Windowsベースのコンテナーイメージは提供されていません。Windows ARM64向けの変更は、Windows ARM64用のネイティブJDKパッケージを利用する環境の話であり、Linux ARM64コンテナーとは分けて考える必要があります。(Microsoft Learn)

自分の環境が更新対象か確認する方法

Javaの更新で最も多い失敗は、コマンドプロンプトで表示されるJavaだけを更新し、実際のサービスが別のJDKを使い続けることです。

次の対象を分けて棚卸ししてください。

確認対象	見落としやすいポイント
WindowsのPATH	最初に見つかった`java.exe`しか確認できない
`JAVA_HOME`	PATHと異なるJDKを指している場合がある
Windowsサービス	サービスラッパー内にJDKパスが設定されている場合がある
Tomcatやアプリケーションサーバー	独自の起動スクリプトでJDKを指定している場合がある
Maven・Gradle	ビルド時のJDKと実行時のJDKが異なる場合がある
IDE	IntelliJ IDEAやEclipseのプロジェクトJDKが別管理の場合がある
CI/CD	JenkinsエージェントやGitHub Actionsのコンテナーが古い場合がある
製品同梱JRE	製品フォルダー内のJavaを直接起動している場合がある
Docker・Kubernetes	Dockerfileのタグと実際のイメージダイジェストが異なる場合がある

WindowsでJavaの場所とバージョンを確認する

PowerShellで次のコマンドを実行します。

Get-Command java -All

java -XshowSettings:properties -version 2>&1 |
  Select-String 'java.home|java.vendor|java.version'

確認するのは、バージョン番号だけではありません。

java.versionが対象のパッチバージョンか
java.vendorが想定するベンダーか
java.homeが実際に更新したフォルダーか
複数のjava.exeがPATH上に残っていないか

Windowsサービスの実行パスを補助的に確認するには、次のコマンドを使用できます。

Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -match 'java|jdk|jre' } |
  Select-Object Name, State, PathName

ただし、Apache Commons Daemon、WinSW、独自サービスラッパーなどを利用している場合、PathNameにJavaのパスが直接表示されないことがあります。サービスの設定ファイルやレジストリも確認してください。

稼働中のJavaプロセスは、次のように調べられます。

Get-CimInstance Win32_Process -Filter "Name='java.exe'" |
  Select-Object ProcessId, ExecutablePath, CommandLine

MavenとGradleが使用するJDKも確認する

ビルド環境では、ターミナル上のJavaとMaven・Gradleが利用するJavaが異なる場合があります。

mvn -version
gradle -version

出力に表示されるJava versionとJVMのパスを確認してください。

ローカル開発環境だけを更新しても、CIサーバーやビルドコンテナーが古いJDKのままでは、生成物やテスト結果が一致しません。

コンテナー内の実際のJDKを確認する

まず、稼働中のコンテナーとイメージ名を確認します。

docker ps --format 'table {{.Names}}\t{{.Image}}'

続いて、実際のコンテナー内でJavaのバージョンを確認します。

docker exec <コンテナー名> java -version

イメージ名に21-ubuntuと書かれているだけでは、現在のコンテナーが21.0.12を使っているとは限りません。コンテナーが作成された時点の古いイメージを使い続けている可能性があるため、実行中のJVMで確認することが重要です。

Microsoft Build of OpenJDKを安全に更新する手順

更新前の情報を記録する

最初に、現在の状態を記録します。

java -version

java -XshowSettings:properties -version 2>&1 |
  Select-String 'java.home|java.vendor|java.version'

あわせて、次の項目を保存してください。

Javaのインストール先
現在のインストーラーまたはパッケージ形式
JAVA_HOME
PATHの設定
JVM起動オプション
サービスの起動アカウント
アプリケーションの設定ファイル
コンテナーの場合はイメージダイジェスト
更新前のCPU使用率、メモリ使用量、GCログ

問題が発生した場合に戻せるよう、旧インストーラーや旧イメージのダイジェストも記録しておきます。

同じメジャーバージョンを更新する

WindowsでMicrosoft Build of OpenJDKを利用している場合は、現在と同じインストール方法を使うのが基本です。

Microsoftは、同じJDKメジャーバージョンに対してEXE、MSI、ZIPといった複数のインストール方法を混在させないよう案内しています。たとえば、MSIで導入したJava 21をEXEで更新する場合は、既存のMSI版を先にアンインストールする必要があります。(Microsoft Learn)

Windows Package Managerを利用している場合は、最初にパッケージを検索します。

winget search Microsoft.OpenJDK

Java 21のパッケージを更新する例は次のとおりです。

winget upgrade --id Microsoft.OpenJDK.21 --exact

利用中の系統に応じて、IDの末尾を11、17、21、25に変更します。

UbuntuやDebianでMicrosoftのリポジトリを設定済みの場合は、次のように同じメジャー系統のパッケージを更新します。

sudo apt update
sudo apt install msopenjdk-21

更新後は、既定のJavaが切り替わっているか確認します。

java -version

複数のJDKを併用している場合は、パッケージの更新だけでなく、サービスやビルドツールが参照するJDKパスも変更してください。

アプリケーションを再起動する

JDKをインストールしただけでは、すでに起動しているJavaプロセスには反映されません。Javaプロセスは起動時にJVMを読み込むため、アプリケーションやサービスの再起動が必要です。

再起動後に、稼働中のプロセスが新しいJDKを使用していることを確認します。

jcmd <PID> VM.version
jcmd <PID> VM.command_line

Windowsサービスの場合は、サービスの再起動前後でプロセスIDが変わっていることも確認してください。

更新後のテストを実施する

最低限、次のテストを実施します。

アプリケーションの起動と停止
ログインや主要画面の表示
データベース接続
HTTPSや外部APIへの接続
ファイル入出力
バッチ処理
スケジュールジョブ
Javaエージェントの読み込み
JNIやネイティブライブラリを利用する機能
メモリ使用量とGCの確認
CPU使用率とスレッド数の確認

今回の更新では、特に次の条件を追加してください。

環境	重点確認項目
64論理プロセッサ超のWindows	CPU認識数、GCスレッド数、処理性能
Windows ARM64	起動、Javaエージェント、JNI、スタック関連処理
OpenJDK 25＋Windows ARM64	高負荷時の安定性、スレッド関連処理
Java 8コンテナー	Temurinのバージョン、ベースOS、イメージダイジェスト
Kubernetes	新しいイメージがPodに反映されているか
CI/CD	ビルド用JDKとテスト用JDKが両方更新されているか

段階的に本番へ展開する

複数台でJavaアプリケーションを運用している場合は、一斉更新よりも段階的な展開が安全です。

最初に検証環境を更新し、その後、本番の一部ノードへ先行適用します。次の値に問題がなければ、残りのノードへ展開します。

エラー率
レスポンスタイム
CPU使用率
ヒープ使用量
GC停止時間
スレッド数
外部接続の失敗数
JVMクラッシュやhs_err_pidファイルの有無

特にプロセッサーグループの変更が関係する大規模Windows環境では、更新前の性能値を基準として残しておくことが重要です。

更新時によくある失敗

失敗例	問題点	対策
`java -version`だけを確認する	サービスが別のJDKを利用している可能性がある	稼働中プロセスの実行パスを確認する
Java 17から25へ一気に変更する	セキュリティ更新とメジャー移行が混在する	まず17.0.20へ更新する
Dockerイメージをプルするだけ	既存コンテナーには反映されない	再ビルドして再デプロイする
タグだけを記録する	同じタグが後日別のイメージを指す	ダイジェストも記録する
Java 8イメージをMicrosoft Build 8と思い込む	実際のバイナリはEclipse Temurin	`java.vendor`と`java.version`を確認する
`8-ubuntu`を前提にする	現在のMCRタグ一覧に存在しない	`8-azurelinux`など実在タグを確認する
Windows ARM64をx64と同じ試験だけで済ませる	ARM64固有変更を見落とす	JNI、エージェント、スタック処理を追加確認する
EXE、MSI、ZIPを混在させる	PATHやアンインストール情報が競合する	同じインストール方式を継続する
開発PCだけ更新する	CI/CDや本番サーバーが古いまま残る	実行環境ごとに棚卸しする

2026年7月更新で今すぐ実施すべきこと

Microsoft Build of OpenJDKを利用している場合は、まずすべてのJava実行環境でjava -version、java.vendor、java.homeを確認してください。

更新先は次の4バージョンです。

OpenJDK 25は25.0.4
OpenJDK 21は21.0.12
OpenJDK 17は17.0.20
OpenJDK 11は11.0.32

Windowsで64個を超える論理プロセッサを扱う環境では、更新前後のCPU認識数とJVMスレッド設定を比較します。Windows ARM64では、Reserved Stack Areaの扱い、Javaエージェント、JNI、スタックオーバーフロー周辺の動作を重点的に確認してください。

Java 8は別扱いです。Microsoft Buildの更新対象ではなく、Eclipse Temurin 8の最新版を確認します。MCRを利用する場合は、8-azurelinuxまたは8-distrolessを候補とし、イメージを再取得するだけでなく、アプリケーションの再ビルドと再デプロイまで実施してください。

最後に、アプリケーションを再起動し、実際に稼働しているJVMが目的のバージョンへ切り替わったことを確認すれば、更新作業の完了です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Build of OpenJDK 2026年7月更新対象は？25.0.4・21.0.12・17.0.20・11.0.32を整理

Microsoft Build of OpenJDK 2026年7月更新、必要なJDKバージョン一覧

更新先は同じメジャーバージョンの最新パッチを選ぶ

2026年7月更新で変わるWindows関連のポイント

Windowsの全プロセッサーグループを列挙する変更

特に確認が必要な環境

JVMの自動設定が変わっていないか確認する

Windows ARM64ではReserved Stack Areaを非対応として扱う

OpenJDK 25だけにWindows ARM64向け最適化が追加

OpenJDK 8は今回のMicrosoft Build更新対象ではない

OpenJDK 8で確認できるMCRタグ

OpenJDK 8イメージのバージョン確認方法

自分の環境が更新対象か確認する方法

WindowsでJavaの場所とバージョンを確認する

MavenとGradleが使用するJDKも確認する

コンテナー内の実際のJDKを確認する

Microsoft Build of OpenJDKを安全に更新する手順

更新前の情報を記録する

同じメジャーバージョンを更新する

アプリケーションを再起動する

更新後のテストを実施する

段階的に本番へ展開する

更新時によくある失敗

2026年7月更新で今すぐ実施すべきこと

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft Build of OpenJDK 2026年7月更新対象は？25.0.4・21.0.12・17.0.20・11.0.32を整理

Microsoft Build of OpenJDK 2026年7月更新、必要なJDKバージョン一覧

更新先は同じメジャーバージョンの最新パッチを選ぶ

2026年7月更新で変わるWindows関連のポイント

Windowsの全プロセッサーグループを列挙する変更

特に確認が必要な環境

JVMの自動設定が変わっていないか確認する

Windows ARM64ではReserved Stack Areaを非対応として扱う

OpenJDK 25だけにWindows ARM64向け最適化が追加

OpenJDK 8は今回のMicrosoft Build更新対象ではない

OpenJDK 8で確認できるMCRタグ

OpenJDK 8イメージのバージョン確認方法

自分の環境が更新対象か確認する方法

WindowsでJavaの場所とバージョンを確認する

MavenとGradleが使用するJDKも確認する

コンテナー内の実際のJDKを確認する

Microsoft Build of OpenJDKを安全に更新する手順

更新前の情報を記録する

同じメジャーバージョンを更新する

アプリケーションを再起動する

更新後のテストを実施する

段階的に本番へ展開する

更新時によくある失敗

2026年7月更新で今すぐ実施すべきこと

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル