はじめに
皆様こんにちは！Broadcom VCF TAM の久松です。
AIの進化とともに、脆弱性が発見されるスピードは加速しています。実際、国内でもランサムウェアや不正アクセスの被害が連日報道されている状況です。
ベンダー各社もこれに対応し、発見された脆弱性を修正すべくリリースの頻度を上げています。VMware® 製品も例外ではなく、脆弱性に対応するパッチが短い間隔で提供されるようになりました。
ここ最近では、セキュアブート証明書期限切れに関する対応や、VMSA-2026-0006 の対応で、仮想基盤のアップグレードを検討されているお客様も多いのではないでしょうか。
そこで無視できなくなるのが、VMware 製品の「バックインタイム(back-in-time)」という制約です。ひとことで言えば、現在のバージョンより前にリリースされたバージョンにはアップグレードできない という制約となります。
本記事では、バックインタイムについて具体例を交えて分かりやすく解説いたします。
目次
・バックインタイムとは何か
・注意すべき点
・どこで確認するか
・まとめ
■バックインタイムとは何か
弊社のKBでは、バックインタイムは「コードおよびセキュリティ修正を意図的に退行させるアップグレードパス」と定義しています。
参考：KB312157 vCenter Server Back-in-time release upgrade restriction
参考：KB312160 vSphere ESXi Back-in-time release upgrade restriction
かみ砕いて言えば、過去の不具合/脆弱性の修正が消えてしまうバージョンへのアップグレードはできない という制約です。
通常、後にリリースされたバージョンには、それ以前に対応した修正が全て取り込まれています。そのため実務上は、リリース日が現在のバージョンより前のバージョンには上げられない という認識で問題ありません。ただし、いくつかの注意点がございますのでその点については後述します。
まずは概要について、具体例で説明させていただきます。
例1 )
・VMware vSphere® (以下、vSphere) 8.0 U3k リリース日：2026年7月29日
・VMware Cloud Foundation® (以下、VCF) 9.1.0 リリース日：2026年5月12日
上記の例で考えると、VCF 9.1.0 に比べ、vSphere 8.0 U3k の方が後の日付でリリースされているため、vSphere 8.0 U3k から VCF 9.1.0 へアップグレードは、バックインタイムの制約によりできないということになります。実際、8.0 U3k のリリースノートにも、9.1.0 および 9.1.0 をベースとする任意のパッチへのアップグレードはサポートされない、と明記されています。
例2 )
・vSphere 8.0 U3h リリース日：2025年12月15日
・VCF 9.0.1 リリース日：2025年9月29日
・VCF 9.0.2 リリース日：2026年1月20日
上記の例で考えると、vSphere 8.0 U3h のリリース日から見て、VCF 9.0.1 のリリース日は過去の日付になっているためアップグレード不可です。VCF 9.0.2 のリリース日は、vSphere 8.0 U3h のリリース日より後になっているため、アップグレード可能です。
なお、VCF ではこのルールがライフサイクル管理に実装されており、抵触するとプリチェックの段階で失敗します。UI 上では対象コンポーネントのアップグレード選択肢がグレーアウトし、互換性がない旨のエラーが表示されます。
■注意すべき点
バックインタイムを考慮する際に注意すべき点が、2 点ほどあります。
※公式ドキュメントで明言されておらず、執筆時点の製品の実態をベースにまとめております。今後のアップデート等で変更される可能性がありますので、ご注意ください。
1. Express Patch (以下、EP) はバックインタイムの解消にならない
EP は、セキュリティ修正などを緊急に届けるために、コンポーネントごとに必要に応じて提供されるパッチです。例えば、VCF 9.1.0 に対する EP であれば、「9.1.0.0100」、「9.1.0.0200」等が、EP に相当します。VCF 9 のバージョン表記の詳細は、こちらの Link を確認ください。
ここで重要なのは、バックインタイム判定の基準が Maintenance Release (3番目の数字) 以上のバージョンであるという点です。つまり、EPのリリース日がアップグレード元より後ろであっても、9.1.0 に上げられない環境は、9.1.0.0100 にも 9.1.0.0200 にも上げられません。
具体例で説明させていただきます。
・VMware vCenter® (以下、vCenter) 8.0 U3j リリース日：2026年5月27日
・vCenter 9.1.0(GA) リリース日：2026年5月12日
・vCenter 9.1.0.0300 リリース日：2026年7月29日
上記の例で日付だけを見ると、vCenter 8.0 U3j から 9.1.0.0300 へのアップグレードは可能なように見受けられますが、判定の基準になるのは、9.1.0 の Maintenance Release 以降のバージョンであるため、9.1.0.0300 の場合はバックインタイムに該当し、アップグレードすることはできません。実際、vCenter 8.0 U3j のリリースノートにも、9.1.0 およびそれをベースとするパッチは対象外と明記されています。
2. コンポーネント単位の確認が必要
本記事は vCenter を例に挙げておりますが、VCF は複数のコンポーネントが含まれております。コンポーネントごとに独立したリリース日を持っているため、バックインタイムはコンポーネントごとに確認していただくようお願いいたします。
■どこで確認するか
ここまでバックインタイムとは何か、確認する際の注意すべき点について説明させていただきました。
リリース日とバージョンを1つずつ確認していけば、バックインタイムの判定そのものは可能です。しかしながら、コンポーネントごとに1つずつ全て調べるのは手間がかかります。では、効率的に確認できる方法は何か。答えは Interoperability Matrix の Upgrade Path での確認 です。
Interoperability Matrix はこちらから開けます。
https://interopmatrix.broadcom.com/Upgrade
Upgrade Path を確認する際は、「Hide Patch Releases」のチェックを外してご確認ください。初期状態ではパッチリリースが非表示になっており、8.0 U3k や 9.1.0.0200 のような個別パッチが一覧に出てきません。バックインタイムはパッチ単位で発生するため、チェックを外さないと肝心の行が見えないままになりますので、ご注意ください。
従来、Upgrade Path がないバージョンは空欄として表示され、未確認なのか不可なのか判別できませんでした。現在はこの表記が見直され、明示的に「✕」が表示され、カーソルを合わせると何故アップグレード出来ないのか理由が表示されます。
■まとめ
バックインタイムとは、現在のバージョンより前にリリースされたバージョンにはアップグレードできない という制約です。
リリース日とバージョン情報を1つずつ確認していくことでも判定は可能ですが、非常に手間がかかりますし、細かいバージョン番号を見間違えてしまうリスクもあります。Interoperability Matrix を使用すれば、対象の Upgrade Path を一目で効率よく確認できますので、ぜひご活用ください。
もし、不具合/脆弱性対応等で、現行環境を最新バージョンにアップグレードした場合は、次回の Maintenance Release を待つことになりますので、アップグレードの際は将来のスケジュールについてもご考慮いただけますと幸いでございます。
なお、本記事は vSphere 8.0 から VCF 9.x へのアップグレードを中心に解説しています。vSphere 7.0 から 8.0 へのアップグレードについては、表記もルールも少々異なります。こちらの KB が参考となりますが、最終的な可否は Interoperability Matrix で確認お願いします。
弊社 TAM サービスでは、お客様の VCF 環境におけるライフサイクルの策定/管理の支援も行っておりますので、本 Blog 記事を含めて確認/相談事項がございましたら、是非担当 TAM までご連絡ください。
