追記: 2026年6月5日の最新情報
2026年6月2日に、VCF 9.1の導入前チェックで見ておきたい公式情報が追加されました。特に、VKS 3.6のマルチネットワーク対応と、VCF Automation 9.1のNamespace Blueprintは、API-firstやアップグレード計画だけでは見落としやすい確認軸です。
- VKSマルチネットワーク対応は、KubernetesノードにセカンダリNICを追加できる機能です。ただし、追加しただけでアプリケーション通信が自動的に切り替わるわけではありません。初期状態では通常通信はeth0を使うため、ストレージ、マルチキャスト、分離ネットワークなどの用途をPoCで分けて確認する必要があります。
- Namespace Blueprintは、vSphere Namespaceを再利用可能なBlueprintとして扱える機能です。一方で、VKS clusterやAVI load balancerを含むnamespaceは現時点でキャプチャできず、Identical captureはdedicated VPCに関連付いたnamespaceに限られます。
そのため、VCF 9.1を評価する場合は、管理サービスIP、Upgrade Planning Tool、API仕様に加えて、VKSのネットワーク分離、Namespace Blueprintの前提条件、未対応範囲もPoC前のチェックリストに入れておくのが現実的です。自サイト内では、VKSマルチネットワーク対応の確認記事とNamespace Blueprintの確認記事で、それぞれ導入前の見方を分けて整理しています。
このテーマをもう少し広げて見るなら、VCF PowerCLI 9.1のOAuth 2.0認証：APIトークンとSSO連携を導入前に確認する と VCF Automation 9.1のNamespace Blueprintを導入前に確認する：App Stack Formation、VM Group、Content Libraryの実務ポイント も合わせて確認してください。API-firstを運用へ落とす前に、認証方式とトークン管理を確認できるため。
3行まとめ
API、SDK、PowerCLI、SSO、token管理を既存運用への影響として見る。
現行環境、destination、phase、PDF exportを変更管理の前提として残す。
Management Network内の/28または/27、FQDN、DNS、証明書を先に確認する。
VCF Operations 9.xと旧vSphere/NSX環境で使える範囲を分けて読む。
core VCF、Advanced Services、License Server、subscriptionを契約上確認する。
この記事は2026年6月1日時点の公式資料をもとに、VCF 9.1導入前の確認順を整理する。
- VCF 9.1は、AI/Kubernetes native private cloud、API-firstの運用、VCF Management Services、Diagnostics、Advanced Servicesの境界を同時に確認する更新だ。新機能の見出しだけでなく、既存環境から進む前の設計作業が重要になる。
- 導入前に詰まりやすいのは、Upgrade Planning Toolの入力条件、Management Network内の/28または/27、FQDNの解決先、内部CIDRの衝突、VCF Operations/License Server、Advanced Servicesの別購入境界だ。
- 本記事は2026年6月1日（Asia/Tokyo）時点の公式資料を確認した導入判断ガイドであり、Broadcom Inc.および関係会社とは非提携だ。AVGOの売買推奨、目標株価、短期値動きの予測は行わない。
VMware Cloud Foundation（VCF）9.1は、Broadcomが2026年5月に発表したprivate cloud基盤の重要アップデートだ。公式発表では、AI workloads、Kubernetes、mixed compute infrastructure、security、hardware choiceが前面に出ている。VCF 9.1の話題はAI基盤として語られやすいが、導入企業にとって先に効くのは、アップグレード計画、管理サービス、DNS、IPレンジ、ライセンス、既存運用との接続である。
今回の需要シグナルは、VCF 9.1のGA後に、公式ブログ、TechDocs、KB、コミュニティ上の質問が近いタイミングで重なったことだ。特に2026年5月25日のProgrammable Infrastructureブログ、2026年5月28日のUpgrade Planning Toolブログ、同日のDiagnosticsブログ、2026年5月22日のBroadcom KB 440223は、読者が「VCF 9.1をどう導入するか」を考え始めているサインとして見られる。コミュニティ投稿は仕様の根拠ではなく、あくまで読者需要の手がかりとして扱う。
この記事では、製品・サービス・ソリューションの観点から、VCF 9.1を導入前チェックリストとして読む。発表そのものの追跡は公式発表・発表会が入口になるが、ここでは実務で止まりやすい点に寄せる。
VCF 9.1で導入判断が変わるところ
発表文は方向性の確認に使い、具体的な要件はFAQ、Release Notes、TechDocs、KBで確認する。
BroadcomはVCF 9.1を、production AI workloadsに向けたsecure and cost-effective infrastructure platformとして発表した。英語版の発表は2026年5月5日、日本語版リリースは2026年5月20日に確認できる。記事内では、発表日、公開日、TechDocs更新日を混同しない。
VCF 9.1を読むときは、機能名の多さよりも「導入前の作業に変換できるか」が大切になる。公式発表が示す方向性は、AI/Kubernetes native private cloud、mixed compute、security、hardware choice、private AI、TCO改善だ。一方で、実際の計画では、現行バージョン、既存vSphere/VCF/VVF構成、ネットワーク、DNS、ライセンス、Advanced Servicesの購入境界、バックアップとロールバックを別々に確認する必要がある。
GA発表で確認できること
公式発表で確認できるのは、VCF 9.1の製品としての位置づけ、主要な訴求点、対象ワークロード、エコシステムの方向性だ。AI基盤としてのメッセージは強いが、各社の既存環境で同じ効果が出るとは限らない。発表内の性能改善やコスト削減の表現は、脚注や前提条件つきで読む。
導入担当者にとっては、発表文の「何ができるようになったか」よりも、「それを使うためにどのコンポーネント、ネットワーク、ライセンス、運用手順が変わるか」が重要だ。たとえばPrivate AIやKubernetesを重視する場合でも、GPUやKubernetesクラスタの話だけでは足りない。VCF Operations、VCF Automation、VKS、NSX、vSAN、ライセンス、Advanced Servicesの境界まで確認したい。
根拠として見る資料
最初にBroadcomのVCF 9.1発表を読み、次にVCF 9.1 FAQとTechDocsへ降りる。公式ブログは文脈理解に使い、具体的な要件はRelease Notes、FQDN/IP、Management Services、KBで確認する。日本語リリースは日本語表現の補助として有用だが、日付や文言が英語版と完全に同じ前提では扱わない。
読み違えやすい点
「AI向け」「API-first」「self-service」「advanced」といった言葉は便利だが、導入条件を省略しやすい。特にAdvanced Services、Avi Load Balancer、vDefend、Advanced Cyber Complianceなどは、VCF coreに含まれると決めつけない。FAQや契約上のentitlementを確認するまで、利用可能範囲を断定しない。
リリースノートで導入前タスクへ変換する
VCF 9.1 Release NotesのWhat's Newでは、Enhanced NVMe Memory Tiering、Extended vSAN Deduplication and Compression、vSphere Elastic Provisioning、VCF Management Services、VKS and VM Fast-Deploy、Simplified Container-as-a-Service、Native Object Storage（Tech Preview）、Live Patching for ESX for TPM-enabled hosts、Continuous Compliance Enforcement、On-prem Ransomware Recoveryなどが並ぶ。
この記事では、それらをすべて同じ重さで扱わない。読者が導入前に判断しやすいよう、API-first、Upgrade Planning Tool、VCF Management ServicesのIP/FQDN、Diagnostics、Advanced Servicesとライセンス境界に絞る。全機能の網羅ではなく、既存環境で詰まる前に確認する順番を作るためだ。
API-firstとSDKは何を確認するか
APIが増えることと、自社環境の自動化がすぐ完成することは別である。
VCF 9.1のProgrammable Infrastructureは、単にAPIが増えたという話ではない。運用担当者にとっては、UIで確認していた情報をAPIで取得できるか、監視やレポートを自動化できるか、複数vCenterや複数VCF環境を一貫した形で扱えるか、認証と権限をどう管理するかが焦点になる。
2026年5月25日のVCF Blogでは、VCF 9.1がAPI-first consumption interfaceを強め、開発者やプラットフォームチームがインフラをプログラム可能な形で扱う方向を示している。TechDocs側では、VCF SDKs, APIs, and CLIsのページで具体的なAPIやSDK差分を確認できる。
API-firstを運用自動化の話として読む
API-firstは、開発者だけの話ではない。運用チームが見るべき項目は、Real-Time Metrics API、Utilization API、vCenter Group Federated API、Query API、Java SDK、Python SDK、PowerCLIだ。Real-Time Metrics APIはPrometheusやGrafanaとの接続文脈で語られ、Query APIはvSphere inventoryの取得、server-side filtering、pagination、property selectionなどと関係する。
既存運用でGrafana、Prometheus、社内レポート、構成管理DB、CI/CD、監査ログを使っている場合、VCF 9.1のAPI追加は運用の整理につながる可能性がある。反対に、APIを保守する担当者がいない、API tokenの保管ルールがない、権限管理が粗い、既存スクリプトが属人化している環境では、機能追加より先に運用負荷が出る。
確認項目
API利用前に確認したいのは、認証方式、API tokenの発行と保管、VCF SSO、ロール分離、監査ログ、プロキシ条件、既存PowerCLIスクリプトの変更範囲だ。TechDocsではPowerCLIの認証まわりとして、VcfOAuthSecurityContextやVcfApiTokenに関する記述も確認できる。名前だけを拾うのではなく、自社の接続処理に影響するかを見る。
上振れ・下振れの分かれ目
上振れとして読めるのは、既存の監視・棚卸し・レポート基盤がAPI連携前提で、VCF 9.1の追加APIをすぐに検証できる場合だ。下振れ要因は、権限設計やAPI token管理が未整備で、運用自動化よりも認証・監査の再設計が先に必要になる場合である。
SDKとPowerCLIを分けて見る
Java SDK、Python SDK、PowerCLIは、同じ「自動化」でも使うチームが違うことがある。開発チームはSDKを使い、運用チームはPowerCLIを使う。セキュリティチームはAPI tokenや監査ログを気にする。導入前には、誰がどの道具を使うのかを分ける。
社内の既存ジョブがPowerCLIでvCenterやNSXに接続しているなら、VCF SSOやAPI token対応が既存ジョブへ影響するかを確認する。新しくPython SDKやJava SDKを使うなら、認証、例外処理、APIバージョン、ログ、再試行、権限の最小化まで設計する。API-firstは便利だが、誰でも何でもできる状態にしてよいという意味ではない。
Upgrade Planning Toolはどこまで使えるか
- 11. 現在地を入力
現行のvSphereまたはVCFベース環境、製品、バージョン、導入済み機能を入れる。
- 22. destinationを選ぶ
適用可能な移行先を選び、入力条件と選択理由を記録する。
- 33. upgrade phasesを読む
全体のworkflowとphaseを、メンテナンスウィンドウや担当チームへ分解する。
- 44. リソースとネットワークを確認
Resource & Networking Requirements、証明書、depot、バックアップ条件を照合する。
- 55. PDF exportを残す
出力日、入力条件、destination、未確認項目をCABや作業者レビューで共有する。
- 66. 公式資料と照合
TechDocs、KB、Interoperability Matrix、サポート条件、ロールバック計画で再確認する。
Upgrade Planning Toolは計画の起点であり、変更作業の承認書そのものではない。
2026年5月28日のVCF Blogでは、VCF 9.1 Upgrade Planning Toolが紹介された。記事によれば、ユーザーは現在のvSphereまたはVCFベースの環境とバージョンを指定し、適用可能なdestinationを選ぶことで、環境に合わせたupgrade planを得られる。
これは、VCF 9.1への移行を考える読者にとって重要な需要シグナルだ。VCF 9.1は柔軟性が増した分、現行構成によってアップグレード順序、必要リソース、ネットワーク要件、運用手順が変わる。ツールは計画の起点になるが、変更作業の承認書そのものではない。
現行環境から逆算する
Upgrade Planning Toolの価値は、現在地から逆算できる点にある。既存のstandalone vSphere、VCF構成、vSAN、NSX、Aria Automation、VCF Operationsの有無によって、進み方は変わる。ブログでは、出力にoverall upgrade workflow、upgrade phases、Resource & Networking Requirements、Key considerations and potential pitfalls、関連ドキュメントへの参照が含まれると説明されている。PDF exportも可能だ。
実務では、ツールの入力条件を変更管理の前提として残す。いつ、誰が、どの現行バージョン、どのdestination、どの機能有無で出力した計画なのかを記録する。後から再生成したときに差分を比較できるようにするためだ。
確認項目
最初に棚卸しするのは、現行バージョン、vSAN/NSX/Aria Automationの有無、VCF Operationsの状態、SDDC Managerの状態、オンラインまたはオフラインdepot、ネットワーク要件、証明書、バックアップ、ロールバック条件である。ツールの出力に出てきたphaseを、社内のメンテナンスウィンドウ、承認プロセス、担当チームへ落とす。
注意点
Upgrade Planning Toolがあるからアップグレードが簡単になる、と書くのは危うい。ツールは、複雑な手順を見つけやすくするための入口だ。実作業では、TechDocs、KB、Interoperability Matrix、サポート、バックアップ検証、変更管理と照合する必要が残る。
PDF exportの使い道
PDF exportは、CAB、変更審査、オフライン環境、作業者レビューに向く。特に複数チームで作業する場合、ツール画面を見た人だけが前提を知っている状態は避けたい。PDFには出力日、入力条件、destination、参照資料、未確認項目をメモとして添えると、後で判断を追いやすい。
ただし、PDFは静的な計画メモであり、最新のTechDocsそのものではない。VCF 9.1関連のドキュメントやKBは更新される可能性がある。作業直前には、出力した計画と公式ドキュメントの更新日を再確認する。
VCF Management ServicesのIP/FQDNで詰まらないために
IPレンジ、FQDN、内部CIDRを同じ空きIP問題として扱うと、導入直前の手戻りにつながる。
VCF 9.1で特に実務的に重要なのが、VCF Management ServicesのIP/FQDN設計だ。Broadcom KB 440223は、「Not all addresses from the VCF Management Services IPv4 pool are part of the management network」というエラーを扱っている。これは単なるIP不足ではなく、指定したIPv4 poolが既存のManagement Networkに属していないことを示すサインとして読める。
この項目は、導入直前に初めて見ると手戻りが大きい。DNS、IP予約、証明書、管理ネットワーク、内部CIDR、License Server、identity brokerまで絡むため、VCF 9.1の技術評価と同じくらい早い段階で確認したい。
KB 440223を導入前チェックに変換する
KB 440223とTechDocsでは、VCF services runtime nodesに最小12 IPが必要で、/28 CIDR blockを割り当てる説明がある。将来のVCF management services componentsや既存コンポーネントのscale-outを見込む場合、合計30 IPまで追加・予約できるため、/27 CIDR blockの説明も出てくる。
ここで重要なのは、IPレンジが空いていればよいわけではない点だ。VCF Management Services用のIP rangeは、既存のVCF Management Network内にある必要がある。さらに、FQDNの解決先IPと、VCF services runtime IP rangeを混同しない。
/28と/27の見方
| 項目 | 公式資料での目安 | 導入前の見方 |
|---|---|---|
| 最小構成 | 12 IP、/28 CIDR block | 初期導入に必要な下限として見る |
| 拡張を見込む構成 | 最大30 IP、/27 CIDR block | 将来の管理サービス追加やscale-outを考える |
| 置く場所 | Management Network内 | 既存管理ネットワーク外の空きレンジでは足りない |
| 別論点 | 内部CIDR | 198.18.0.0/15などの内部利用レンジは別に確認する |
FQDNはruntime IP rangeの外に置く
TechDocsとKBでは、VCF services runtime、fleet component、instance component、identity broker、license serverのFQDNとIPを分けて扱う必要がある。FQDNはunique IPへ解決し、VCF services runtime IP rangeの外にあり、かつmanagement network内であることを確認する。forward DNSとreverse DNSも確認対象になる。
FQDNに大文字を使わない注意、証明書のFQDN、既存IP予約、DNS TTL、監視登録、license serverのIPv4条件も見落としやすい。VCF 9.1のアップグレードをネットワーク担当と分離して進めると、ここで止まりやすい。
確認項目
導入前に、Management NetworkのCIDR、VCF Management Services用IP range、FQDN解決先IP、forward/reverse DNS、証明書、License Server、identity broker、VCF Operations、SDDC Manager、バックアップ、監視登録を同じチェック表に置く。運用チームだけでなく、ネットワーク、DNS、証明書、セキュリティ担当も巻き込む。
内部CIDRの衝突も先に見る
VCF services runtimeは内部CIDRとして198.18.0.0/15を使う。TechDocsでは、このsubnetが既に使われている場合、240.0.0.0/15または250.0.0.0/15への変更が必要になる可能性が示されている。この内部CIDRは、Management Servicesに割り当てる/28や/27とは別の論点だ。
導入前の図では、外側にManagement Network、内側にVCF services runtime IP range、別枠にFQDN解決先IP、さらに内部CIDRを分けて描くと誤解が減る。ここを混ぜると、IPは足りているのにデプロイ時にエラーが出る、という形で手戻りが発生する。
Diagnosticsは旧コンポーネント環境でどう見るか
Diagnosticsはアップグレード可否を単独で決めるものではなく、互換性、既知問題、バックアップ、ライセンスと合わせて確認する。
2026年5月28日のDiagnosticsブログは、VCF 9.1をいきなり全コンポーネントのアップグレード完了後だけで考えないための材料になる。ブログでは、VCF Operations 9.xを利用しながら、vSphere 8.xやNSX 4.xを含む環境でもDiagnostics findingsが機能する旨が説明されている。
これは、既存環境を抱える導入企業にとって重要だ。VCF 9.1を検討しているが、すべてを同時に9.xへ上げられないケースでは、Diagnosticsをどの範囲で使えるか、どのルールやfindingsがどの経路で更新されるかを確認したい。
VCF Operations 9.xと旧コンポーネントの関係
Diagnosticsブログによれば、VCFとVMware vSphere Foundation（VVF）の顧客は、VCF Operations 9.xを使いながら、vSphere 8.xやNSX 4.xの環境に対するfindingsを得られる。8.x環境への構成変更や、9.xへのアップグレード推奨も得られると説明されている。
ただし、Diagnosticsはアップグレード可否を単独で決めるものではない。既知問題、互換性、バックアップ、Management ServicesのIP/FQDN、ライセンス、サポート条件は別途確認する。Diagnosticsは、旧環境の状態を見える化する補助線として扱うのがよい。
バージョン差分の見方
| Diagnosticsの世代 | ブログで示された特徴 | 導入前の読み方 |
|---|---|---|
| 8.18.x | 既存収集データを使うルール中心。property findingsとlog-based findingsが限定的 | 旧環境の現状把握に使うが、範囲を過大評価しない |
| 9.0.x | 独自データ収集、Skyline Advisor相当のルール、Log Assistの導入 | 旧Skyline運用の置き換え候補として確認する |
| 9.1.x | Diagnostics Content Packの分離、property/log-based findingsの拡充 | 更新経路と運用手順への反映を確認する |
findings数だけで判断しない
ブログでは、8.18.x、9.0.x、9.1.xのproperty-based findingsやlog-based findingsの数にも触れている。これは目安になるが、数だけで良し悪しを決めない。読者の環境で必要なのは、対象コンポーネント、ログ収集範囲、更新経路、findingsの確認間隔、運用手順書への反映である。
既存Skyline運用から移る場合は、どのVMSAルールを見ていたか、どのログを集めていたか、誰がfindingsをレビューしていたかも確認する。ツールの名前が変わっても、運用責任は消えない。
Advanced Servicesとライセンス境界を先に引く
Advanced Servicesやライセンスは単純な優劣ではなく、契約、entitlement、運用条件で扱いが変わる。
VCF 9.1の導入計画では、core VCFとAdvanced Servicesを混ぜないことが重要だ。VCF 9.1 FAQでは、Advanced Servicesがadd-onとして整理され、別購入であり、core VCF offeringsには含まれない旨が示されている。プレスリリース側にも、Advanced Service for VCFがsold separatelyである注記がある。
この境界を曖昧にしたまま見積もると、導入後に「使えると思っていた機能が別購入だった」「ライセンスサーバーや使用量レポートの運用が未準備だった」という問題が起きやすい。
core VCFとAdvanced Servicesを混ぜない
FAQでは、Advanced Cyber Compliance、Advanced Security、Load Balancing、Application Services、Data Services、Network Observability、Business Operations、Identity Security、vSAN Add-On CapacityなどがAdvanced Servicesとして扱われている。製品名やサービス名は更新される可能性があるため、契約前にはBroadcom担当者、パートナー、契約書、entitlementで確認する。
AIやsecurityの訴求が強いと、Advanced Servicesの一部をcoreに含まれるものとして読んでしまいやすい。記事ではその読み違いを避ける。特にAvi Load Balancer、vDefend、Advanced Cyber Complianceなどは、個別のライセンス・契約条件を確認するまで標準範囲と断定しない。
契約前の確認項目
| 項目 | coreとして扱えるか | 確認先 |
|---|---|---|
| VCF本体の主要コンポーネント | FAQと契約で確認 | FAQ、契約、entitlement |
| Private AI Services | VCF 9.1の範囲と提供条件を確認 | FAQ、製品資料、契約 |
| Advanced Security / ACC | 別購入の可能性を確認 | FAQ、発表脚注、契約 |
| Load Balancing / Avi | 標準搭載と決めつけない | FAQ、製品ページ、契約 |
| vDefend関連 | 個別条件を確認 | 製品資料、契約、サポート |
ライセンス運用はアップグレード作業の一部
VCF 9.xでは、subscription-based licensing、VCF License Server、VCF Operations、License Usage File、License Portabilityなどが関係する。技術アップグレードだけを見て、ライセンス運用を後回しにすると、作業直前に詰まりやすい。
FAQでは、perpetual licensesを持つ顧客がVCF 9へアップグレードする前にsubscription licensesへ切り替える必要がある旨も示されている。これは導入担当だけで判断できる話ではない。調達、契約、パートナー、社内資産管理、監査の担当を早めに入れるべき領域だ。
下振れ要因
導入計画が遅れる典型例は、Advanced Servicesを標準範囲と誤認する、License ServerのFQDN設計が後回し、旧ライセンスの扱いが未確認、オフラインdepotの準備が未計画、使用量レポートの運用責任者が決まっていない、というものだ。VCF 9.1では、技術と契約を分けて考えすぎないほうがよい。
導入前チェックリストとして読む
チェックリストは導入を急がせるためではなく、作業前に止める理由を見える化するために使う。
VCF 9.1を導入前チェックとして読むなら、最後は10項目に落とすと判断しやすい。ここで未完の項目が多い場合、実作業へ進むより、棚卸しと確認を先にするほうがよい。
まず確認する10項目
| 確認項目 | 完了条件 | 未完なら止める理由 |
|---|---|---|
| 現行バージョン | vSphere、VCF、VVF、NSX、vSAN、Aria、VCF Operationsを棚卸し済み | Upgrade Planning Toolの入力が曖昧になる |
| Upgrade Planning Tool | 入力条件、destination、出力日、PDFを保存済み | 手順の前提を後で追えない |
| VCF Operations | 9.x利用可否とDiagnostics範囲を確認済み | 旧環境の可視化範囲を誤る |
| SDDC Manager | VCF 9.1へのアップグレード条件を確認済み | Management ServicesやLicense Serverの前提が崩れる |
| Management Network | /28または/27をManagement Network内で確保済み | KB 440223のようなCIDRエラーにつながる |
| FQDN/DNS | unique IP、forward/reverse DNS、証明書を確認済み | runtime IP rangeとFQDN解決先を混同する |
| 内部CIDR | 198.18.0.0/15の利用有無を確認済み | 既存ネットワークとの衝突に気づけない |
| API/SSO/token | 権限、保管、監査、既存スクリプト影響を確認済み | API-first化で運用リスクが増える |
| Advanced Services | coreとadd-onの境界を契約上確認済み | 見積もりや利用範囲を誤る |
| バックアップ/ロールバック | 作業前後の復旧手順を確認済み | 変更失敗時の戻し方が曖昧になる |
実作業へ進まないほうがよい条件
IP/FQDN、ライセンス、バックアップ/ロールバック、現行構成の棚卸しが未完なら、導入作業へ進む判断は避けたい。VCF 9.1の新機能が魅力的でも、管理ネットワークやライセンスの前提が崩れると、作業途中で止まる可能性がある。
既存環境別の読み方
standalone vSphereから進む場合は、現行バージョン、VCF Operations、VKS、NSX、vSAN、ライセンスの扱いを先に見る。VCF 5.xや9.0から進む場合は、Upgrade Planning Tool、SDDC Manager、VCF Management Services、License Serverを重点的に見る。VVFから進む場合は、対象コンポーネントとentitlementを丁寧に確認する。オフラインまたはair-gapped環境では、depot、バイナリ取得、PDF出力、作業証跡、サポート手順も加える。
この記事は詳細手順書ではない。実作業は、TechDocs、Upgrade Planning Tool、Broadcomサポート、パートナー、社内変更管理へ接続する。ここでの目的は、導入前に何を確認すればよいかを見失わないことだ。
まとめ：VCF 9.1は機能より先に前提を固める
- 11. 現行環境
vSphere、VCF、VVF、NSX、vSAN、VCF Operations、SDDC Managerを棚卸しする。
- 22. アップグレード計画
Upgrade Planning Toolの出力を保存し、TechDocs、KB、変更管理と照合する。
- 33. IP/FQDN
Management Network内の/28または/27、FQDN解決先、内部CIDRを分けて確認する。
- 44. APIとDiagnostics
API token、SSO、PowerCLI、findings更新経路、旧環境での可視化範囲を見る。
- 55. ライセンスと契約
Advanced Services、License Server、subscription、entitlementを契約上確認する。
- 66. 復旧条件
バックアップ、ロールバック、作業証跡、サポート条件を作業前にそろえる。
ツールやAPIは計画と自動化の入口であり、公式ドキュメント、KB、契約、サポート条件の確認を置き換えるものではない。
VCF 9.1は、AI/Kubernetes native private cloud、API-first、Management Services、Diagnostics、Advanced Servicesという複数の更新が重なるリリースだ。新機能として読むだけなら魅力は分かりやすい。しかし導入前の実務では、現行環境、アップグレード順序、IP/FQDN、内部CIDR、ライセンス、Diagnostics、バックアップ/ロールバックを先にそろえる必要がある。
特にVCF Management Servicesは、後回しにすると手戻りが大きい。最小12 IPの/28、将来拡張を見込む/27、Management Network内の配置、FQDN解決先、内部CIDR 198.18.0.0/15の衝突確認は、早い段階でネットワーク/DNS担当と合わせて確認したい。
API-firstとUpgrade Planning Toolは、VCF 9.1の運用を進める強い材料になる。ただし、ツールやAPIは計画と自動化の入口であり、公式ドキュメント、KB、契約、entitlement、サポート条件の確認を置き換えるものではない。VCF 9.1を導入判断として読むなら、機能名より先に前提条件を固めるのが近道だ。
次に読むなら
Broadcomの公式発表、VCF 9.1関連のTechDocs更新、KBの追記を継続して追う場合は、月次まとめとニュースレターも補助導線になる。本文の確認を終えた後に使う案内であり、投資判断や契約判断を急がせるものではない。
更新履歴
本文では2026年6月1日時点の公式資料を確認したことを明記する。
Broadcom/VMware公式発表、FAQ、VCF Blog、TechDocs、Broadcom KBを分けて残す。
TechDocs、FAQ、KBに追記がある場合は、本文更新時に変更点を追う。
VCF 9.1関連の要件は更新される可能性があるため、作業直前にも公式資料の更新日を確認する。
- 2026-06-01: 初版公開。Broadcom/VMware公式発表、VCF 9.1 FAQ、VCF Blog、TechDocs、Broadcom KB 440223を確認し、API-first、Upgrade Planning Tool、VCF Management ServicesのIP/FQDN、Diagnostics、Advanced Servicesとライセンス境界を導入前チェックとして整理。
- 需要シグナルとして、2026年5月下旬の公式ブログ更新、TechDocs更新、KB更新、コミュニティ上のVCF 9.1 GA後の質問を確認。本文の仕様根拠には公式資料のみを使用。
次に読むなら
参照した主な情報源
- Broadcom Announces VMware Cloud Foundation 9.1（確認日: 2026-06-01）
- Broadcom、VMware Cloud Foundation 9.1を発表（確認日: 2026-06-01）
- VCF 9.1 Frequently Asked Questions: May 28, 2026（確認日: 2026-06-01）
- Unlocking the Full Potential of Programmable Infrastructure with VMware Cloud Foundation 9.1（確認日: 2026-06-01）
- Announcing the VMware Cloud Foundation 9.1 Upgrade Planning Tool（確認日: 2026-06-01）
- VMware Cloud Foundation 9.1 Release Notes: What's New（確認日: 2026-06-01）
- VCF SDKs, APIs, and CLIs（確認日: 2026-06-01）
- Not all addresses from the VCF Management Services IPv4 pool are part of the management network（確認日: 2026-06-01）
- VCF Components FQDNs and IP Addresses（確認日: 2026-06-01）
- Deploy VCF Management Services and License Server as Part of VCF Upgrade to 9.1（確認日: 2026-06-01）
- Diagnostics for VMware Cloud Foundation 9.1 with Old Versions of VCF Components（確認日: 2026-06-01）