The Rockのバージョンが「7.15」から、いきりなり「10.1」へ— RELEASES.mdに刻まれていた次世代ナンバリングの証拠

発端は1本のnightly wheelだった

ことの始まりは、rocm.nightlies.amd.comのnightlyビルド一覧に並んでいた1本のファイル名だった。

amd_torch_device_gfx1201-2.11.0+rocm10.1.0a20260812-cp312-cp312-linux_x86_64.whl

rocm7.15系のビルドが7月27日ごろまで続いていたはずが、いつの間にかrocm10.1という見慣れない番号に切り替わっていた。8.0でも9.0でもなく、いきなり10.1。ROCmのバージョン履歴を追ってきた人間からすれば、まず疑うのは表記ミスか、単なるビルドシステムの不具合だろう。

業界メディアも「8.0になるはず」で足並みを揃えていた

AMDのROCmは2025年10月、TheRockという新しいビルドシステムを伴う技術プレビュー系列として「ROCm 7.9」を開始した。7.0〜7.8は既存の本番系列、7.9以降が新系列というねじれた番号付けだ。Phoronixはこの時点から一貫して「7.9+のプレビューはいずれROCm 8.0に収束するはず」と書き続けてきた。7.10、7.11、7.12、7.13とプレビューが進むたびに同じ予想が繰り返されている。

ところが2026年7月15日、AMDは7.9〜7.13のプレビュー列が完了したとして、7.14をそのまま新しい本番リリースとして発表した。8.0にはならなかった。Phoronix自身が「Quite the version numbering mess(かなりの番号付けの混乱だ)」と評したほどの番狂わせだった。

この経緯を踏まえれば、7.15の次に「7.16」ではなく忽然と現れた「10.1」も、AMDが得意とする「番号の意図的な不連続」の再演である可能性は高い。ただし、これはあくまで状況証拠からの推測にとどまっていた。ニュース検索でもGitHub Issueでも、「なぜ10なのか」を正面から説明する記事や投稿は見当たらなかった。

決定的な一次証拠:RELEASES.mdの中に

状況が動いたのは、TheRockリポジトリのRELEASES.mdを直接読み込んだときだ。GitHub上のレンダリング表示にはキャッシュの問題があり、しばらく古い版しか見えなかったのだが、raw.githubusercontent.com経由で最新のソースを取得すると、次の一文が存在した。

The plugin and PJRT package names embed the ROCm major version they were built against, so the name to install depends on the ROCm release: jax_rocm7_* for ROCm 7.x and jax_rocm10_* for ROCm 10.x.

JAXのROCmプラグインパッケージ名に、ビルド対象のROCmメジャーバージョンが埋め込まれる仕様になっており、「7.x向けはjax_rocm7_*、10.x向けはjax_rocm10_*」と明記されている。つまりAMDは、ROCm 10.xという系列の存在を公式ドキュメントの中で当然の前提として扱っている。これはもう「表記ミス」や「一時的なビルド番号の暴走」では説明がつかない。

さらに踏み込んだ手がかり:jaxlibが追いついていない

同じセクションには、もう一段踏み込んだ記述もあった。

On ROCm 10, a released jaxlib (0.10.0 through 0.11.0) does not know the jax_rocm10_plugin name, so the GPU kernel modules resolve to None and no FFI handlers are registered... Those versions predate the upstream fix (jax-ml/jax#39634); until a jaxlib carrying it ships, teach the installed copy about the new major.

現行のjaxlib(0.10.0〜0.11.0)はjax_rocm10_pluginという名前をまだ認識せず、GPUカーネルモジュールがNoneに解決されてFFIハンドラが登録されないというバグが起きる。これはJAX本体側(jax-ml/jax)のアップストリーム修正(PR #39634)がまだ取り込まれていないためで、回避策としてパッチスクリプトを当てる手順まで用意されている。

言い換えれば、「ROCm 10」という名前そのものが、周辺エコシステムの対応が追いつかないほどごく最近導入されたということだ。この一文だけで、7.15→10.1のジャンプがいつ頃起きたのか(7月末〜8月上旬)という状況証拠と、公式ドキュメント側の記述の新しさが符合する。

傍証:マルチアーチ版JAXも「Available」に昇格していた

余談だが、この調査の過程でもう一つ気づいたことがある。TheRockのマルチアーチリリース状況を示す一覧表で、JAX Python packagesの欄が以前確認した時点では「🟠 Planned(計画中)」だったのが、最新版では「✅ Available(利用可能)」に変わっていた。ROCm 10.x系への移行と、マルチアーチ方式でのJAX配布開始が、ほぼ同時期に進んでいることがうかがえる。

なぜ「10」なのかは依然として説明されていない

ここまでで確認できたのは「ROCm 10.xという系列が実在し、公式ドキュメントに明記されている」という事実そのものだ。一方で、なぜ8でも9でもなく10なのかを説明するAMD公式のブログ記事やアナウンスは、今回の調査時点(2026年8月13日)でもまだ見つかっていない。

時期的に近い出来事としては、7月17日にAMD Ryzen AI NPU向けの推論ランタイム「FastFlowLM」の開発チームがAMDにジョインし、ROCm傘下のプロジェクトとして再出発したことが挙げられる。NPUとGPUを横断する統一ランタイムを志向する動きと、ROCmのメジャーバージョンが大きく動いたタイミングが重なっているのは興味深いが、この2つを直接結びつける公式発表は見つかっていない。ここは推測の域を出ないことを明記しておく。

まとめ

rocm.nightlies.amd.comのnightlyビルドが7月末〜8月上旬にかけて「7.15」から「10.1」へと切り替わっていたことは、複数の配布サイト(AURパッケージ情報など)から確認できる。
この「ROCm 10.x」系列は、TheRockリポジトリのRELEASES.mdに公式かつ明示的に記載されている実在の系列であり、憶測ではない。
jaxlibの互換性バグへの言及から、この命名がごく最近(2026年7月末〜8月上旬ごろ)導入されたことが裏付けられる。
なぜ「8」でも「9」でもなく「10」なのかという理由は、依然として公式には説明されていない。

執筆時点で、Phoronixを含む主要な技術メディアがこの「ROCm 10」命名を正面から報じた記事は見当たらなかった。ソースコード上の記述からの確認という、いささか地味な裏取りではあるが、この点についてはひとまず先んじて記録しておきたい。

参考:GitHub ROCm/TheRock リポジトリ RELEASES.md(https://github.com/ROCm/TheRock/blob/main/RELEASES.md)