3行まとめ
このテーマをもう少し広げて見るなら、VCF 5.2.xから9.1へ移行前に確認する：8ステップ順序、VCF Management Services、NSX経路の実務ポイント と VCF Operationsでオンプレ本番運用を見直す：88.8%調査、Day 2、容量・コスト可視化の実務ポイント も合わせて確認してください。License Serverを含むVCF Management Servicesの位置付けを、移行順序の中で確認できるため。
VCF Operations、VCF Business Services console、VCF License Server、vCenterの役割を分けて見る。
ライセンス使用量データの24時間ごとの送信と、ライセンスファイルの自動取得を確認する。
180日ごとの手動レポート、送信記録、取得ファイル、インポート結果を運用に組み込む。
導入企業、VCSP、運用担当、監査担当、契約担当が同じ前提で話せる形にする。
ライセンス更新は費用だけでなく、運用方式、権限、証跡、公式資料への戻り方をセットで確認する。
VMware Cloud Foundation 9.1では、ライセンス運用をVCF Operations、VCF Business Services console、ローカルのVCF License Server、vCenterへの割り当てという流れで確認する必要があります。
Connected Modeではライセンス使用量データの24時間ごとの送信とライセンスファイルの自動取得が中心になり、Disconnected Modeでは180日ごとの手動レポート運用を忘れない設計が重要です。
この記事は価格交渉や投資判断ではなく、導入企業、VCSP、運用担当、監査担当が更新前に同じ前提で話すための確認表です。
本記事はBroadcom、VMware、関係会社とは非提携の確認メモです。製品の提供条件、契約、価格、サポート、ライセンス権利は、必ず公式資料、Broadcom Support Portal、販売パートナー、契約書で確認してください。確認日は2026年6月8日です。
VCF 9.1のライセンス更新でまず見る全体像
- 1権利とSite ID
VCF 9以上を利用できる権利と、対象Site IDでライセンス作業を行える権限を確認する。
- 2Business Services console
登録、テナント別管理、ライセンス共有、ロール管理の入口として位置づける。
- 3VCF Operations
ライセンス容量、使用容量、空き容量、ライセンス上の問題を日常運用で確認する。
- 4License Server
保護されたローカルアプライアンスとして、ライセンス管理ロジックと保存を担う。
- 5vCenter割り当て
vCenterへの割り当て後、ESX、NSX、VCF Automationなど関連コンポーネントを確認する。
価格や割引条件は公式資料、販売パートナー、契約書で確認し、この記事では運用前提を整理する。
VCF 9.1のライセンスを読む時に、最初に分けたいのは「いくらになるか」ではありません。もちろん費用は大きな論点ですが、公開情報だけで個別契約や割引条件を断定するのは危険です。更新前にまずそろえるべきなのは、ライセンス運用がどこで管理され、どのデータがいつ送られ、誰が承認し、どのvCenterへ割り当てるのかという実務の地図です。
2026年6月初旬のVMware利用者コミュニティでは、更新費用、NSX 9.1周辺のライセンス運用、VCF 9.1の要件に関する質問が続いています。この記事では、そうした投稿を需要シグナルとしてだけ扱います。仕様、送信サイクル、License Server、ロール、SPDの確認は、BroadcomとVMwareの公式資料に戻して整理します。
VCF 9.1関連の公開済み更新は、2026年6月の重要トピックまとめでも追っています。ライセンスだけを孤立して見るのではなく、VCF 9.1への移行、VCF Operations、FinOps、API-first運用と並べて見ると、更新前の確認漏れを減らせます。
25文字キーではなくライセンスファイルを中心に見る
Broadcom KB 437242は、VCF 9.0以降のライセンスについて、VCF OperationsインスタンスとVCF Business Services consoleを使う形を説明しています。従来の25文字のライセンスキーを中心に考えるのではなく、サブスクリプションベースのライセンスファイルを取得し、VCF OperationsからvCenterへ割り当てる流れとして見るのが出発点です。
旧キーを無理に変換する話にしない
同KBは、以前のライセンスキーをアップグレードする必要はない、と説明しています。ここを読み違えると、既存のキーをすぐに変換しなければならないように社内へ伝えてしまいます。実際には、VCF 9.xを導入またはアップグレードする環境、既存バージョンを維持する環境、複数バージョンが混在する環境を分けて、どの環境が新しいライセンス方式の対象になるかを確認します。
VCF OperationsとBusiness Services consoleの役割を分ける
VCF Operationsは、ライセンスを管理し、vCenterへ割り当てる運用側の入口です。Business Services consoleは、Broadcom側のライセンス登録、割り当て、ロール管理に関わる入口として見ます。
どちらに権限が必要かを先に洗う
更新作業では、製品管理者だけでなく、契約担当、Broadcom Support PortalのSite IDを扱える担当者、監査担当が関わります。VCF Operationsの管理者が強い権限を持っていても、Business Services console側でライセンスを扱う権限がなければ作業は進みません。逆に、契約担当がポータル側の権限を持っていても、vCenterへの割り当てや運用確認はVCF Operations側の作業になります。
License Serverは単独の手作業コンポーネントとして見ない
VMware Cloud Foundation BlogのVCF 9.1 licensing記事は、VCF 9.1でローカルのVCF License Serverが導入されると説明しています。重要なのは、このLicense Serverを、管理者が個別に入れて個別に更新する独立製品のように見ないことです。
公式ブログでは、License ServerはVCF Operationsのインストール時に自動導入され、VCF Operationsの新バージョンへの更新時に自動アップグレードされると説明されています。つまり、運用担当が通常見るべき管理面は引き続きVCF Operationsです。License Serverは、ライセンスデータをローカルに集約する基盤として理解します。
Connected Modeの24時間自動送信を受け入れられるか
- 使用量収集
VCF環境のライセンス使用量データを、運用上どこで確認するかを決める。
- 24時間ごとの送信
Broadcomへの自動送信について、データ送信承認、外部接続ポリシー、プロキシを確認する。
- ライセンスファイル取得
ライセンスファイルの自動取得が、変更管理や監査ログにどう残るかを確認する。
- 自動適用と記録
処理結果、通信経路、例外時の連絡先を、次回更新でも再現できる形に残す。
Connected Modeを選べるかは接続可否だけではなく、送信承認、ログ保存、監査説明まで含めて判断する。
Connected Modeは、単に「インターネットにつながる環境」という意味だけではありません。公式ブログは、VCF 9.1のConnected Modeでは、ライセンス使用量データがBroadcomへ24時間ごとに送信され、更新されたライセンスファイルが自動的にダウンロードされて適用される、と説明しています。
これは運用負荷を下げる一方で、社内のデータ送信承認、プロキシ、監査、ログ保存、外部接続ポリシーの確認を先に済ませる必要があります。更新前の会議では、「Connected Modeにできるか」ではなく、「24時間ごとの自動送信と自動適用を承認できるか」と聞いた方が具体的です。
自動送信・自動適用で減る作業
VCF 9.1のConnected Modeでは、従来のように180日ごとの手動確認サイクルを管理者が繰り返す負担を減らせます。使用量データ送信、ライセンスファイル取得、適用が自動化されるため、担当者の異動、休日、繁忙期、更新作業の先送りによる抜け漏れを減らしやすくなります。
作業が消えるのではなく、監査設計に移る
自動化されるからといって、担当者が何もしなくてよいわけではありません。自動送信が動いているか、ライセンス容量や使用容量に異常がないか、社内のセキュリティ承認と整合しているかを確認する仕事は残ります。手作業が減る分、監査証跡、例外時の連絡先、障害時の切り戻し判断を明確にしておく必要があります。
送信データの中身を誤解しない
VCF 9.1 FAQは、License Usage Fileについて、Personal DataやCustomer Dataを収集しないと説明しています。記録されるデータとしては、使用量生成のタイムスタンプ、VCF 9および以前のライセンスの利用詳細、VCF OperationsインスタンスID、レポート識別子、未使用のVCF 9ライセンス、検出された使用量異常などが挙げられています。
社内説明では「何を送らないか」も残す
監査部門やセキュリティ部門に説明する時は、「ライセンス使用量データを送る」だけでは足りません。公式FAQに基づいて、送信ファイルが何を含み、何を含まないと説明されているかを残します。ただし、実際の承認は自社のポリシー、契約、規制要件に依存します。公式FAQの一文だけで全社承認が済むわけではありません。
Connected Modeを選びにくいケース
インターネット分離、厳格な変更審査、送信前レビュー、特定国や業界の規制、契約部門の確認待ちがある場合、Connected Modeをそのまま選びにくいことがあります。そうした組織では、Disconnected Modeで180日ごとの手動運用を組み込む方が現実的な場合もあります。
ここで大切なのは、Connected Modeを「便利」、Disconnected Modeを「安全」と単純化しないことです。Connected Modeは自動化によって運用忘れを減らせます。Disconnected Modeは送信前レビューを入れやすい一方で、期限管理を失敗すると別のリスクが生まれます。
Disconnected Modeの180日レポートを運用で回せるか
- Day 0
Disconnected Modeの選択理由、担当者、代理者、Broadcom Support Portalのアクセス権限を確認する。
- Day 150
ライセンス使用量ファイルの作成手順、承認ルート、提出予定日を前倒しで確認する。
- Day 170
送信記録、取得するライセンスファイル、インポート担当、失敗時の連絡先を点検する。
- Day 180
ライセンス使用量ファイルを提出し、取得ファイル、インポート結果、監査用メモを保存する。
180日は単なる期限ではなく、契約管理、監査、変更管理と結びつけて運用する周期である。
Disconnected Modeを選ぶ場合、記事で見るべき数字は180日です。公式ブログは、ライセンスファイルを更新する前に確認したい顧客はDisconnected Modeを構成し、180日ごとにライセンス使用量ファイルを手動で送信できると説明しています。VCF SPD May 2026も、VCF 9以上の利用に関するコンプライアンスレポートを、登録から180日後、その後も180日ごとに提出する趣旨を記載しています。
これは単なる期限ではありません。更新作業の担当者、承認者、代理者、証跡の保存場所、Broadcom Support Portalへのアクセス権限を含む運用プロセスです。手動運用を選ぶなら、180日サイクルを契約管理や監査カレンダーに入れておきます。
180日サイクルで忘れてはいけない作業
Disconnected Modeでは、レポート作成、送信、ライセンスファイル取得、VCF Operationsへのインポート、vCenter割り当て後の確認が必要になります。担当者が一人しかいない環境では、休職、異動、退職、権限失効だけで期限管理が崩れます。
Day 150から動く
実務上は、Day 180当日に作業を始めるのでは遅いです。Day 150で担当者と権限を確認し、Day 170でレポート作成と送信の準備を行い、Day 180までに処理結果と証跡を残す、といった余裕を持たせます。契約更新日、四半期レビュー、監査報告月とずれる場合は、どちらを基準に社内カレンダーを作るかも決めておきます。
SPDを読む場面を分ける
VCF SPD May 2026には、ソフトウェアバージョン9以上でのコンプライアンスレポート、報告が遅れた場合の管理プレーン機能やサポート権利への影響、per Coreのライセンス指標、プロセッサあたりの最小コア要件、ライセンスポータビリティなど、本文だけで軽く扱うには重い条件が含まれています。
記事本文で契約判断を代替しない
この記事では、SPDの個別条項を契約助言として解釈しません。導入企業やVCSPが見るべきポイントは、公式SPDの最新版、取引文書、契約書、Broadcom担当者または販売パートナーの回答が一致しているかです。特にVCSP、マルチテナント、クラウドサービス、ライセンスポータビリティに関わる場合、公式ブログだけで判断しない方がよいです。
手動運用が向く組織
Disconnected Modeは、送信前レビューが必要な組織、インターネット接続を許可しない環境、セキュリティ審査が厳しい環境、契約部門がレポート提出の証跡を持ちたい組織に向きます。ただし、選んだ瞬間に運用責任も増えます。自動送信を避ける代わりに、手動送信を忘れない仕組みを作らなければなりません。
License Serverはどこで管理し、何を任せるのか
VCF 9.1で導入されたローカルのアプライアンスとして、ライセンスデータを保護して保存する。
管理者が日常的に見る入口はVCF Operationsであり、容量、使用量、空き容量、問題を確認する。
VCF Operationsのインストール時に導入され、新バージョンで自動的にアップグレードされる前提で計画する。
細かな復旧手順は公式ドキュメント、サポート窓口、保守手順に戻れる状態を作る。
License Serverの有無だけでなく、VCF Operations上の表示、確認者、ログ、証跡のつながりを決めておく。
VCF 9.1のLicense Serverは、ライセンス運用の記事で誤解が起きやすい部分です。公式FAQは、VCF License Serverを、VCF 9.1で導入されたヘッドレスのアプライアンスであり、VCF Operationsから一部のライセンス管理ロジックと保存を担うものとして説明しています。ローカル環境内でライセンス管理を集中化し、保護されたアプライアンス上にライセンスデータを置くという位置づけです。
ただし、管理者が見る日常の入口はVCF Operationsです。License Serverという名前だけを見ると、独立した管理画面や手動保守を想像しがちですが、公式ブログはVCF Operationsとの連動を強調しています。
導入とアップグレードはVCF Operationsと結びつく
公式ブログでは、License ServerのインストールはVCF Operationsのインストール時に自動で行われ、VCF Operationsの新バージョンで自動的にアップグレードされると説明されています。これは、更新前の作業計画にとって大きな意味を持ちます。
License Server単体の作業手順を探す前に、VCF Operationsの計画を見る
License Serverに関する作業を洗い出す時は、まずVCF Operationsのインストール、アップグレード、バックアップ、権限、監視の計画を確認します。VCF 9.1の運用基盤全体を確認したい場合は、VCF Operationsで管理VMのリソース割り当てを確認する記事も合わせて読むと、vCenterやNSXを含む管理面の見方を整理しやすくなります。
障害・監査時に見るもの
公式ブログは、VCF Operationsでライセンス容量、使用容量、空き容量、ライセンス上の問題を見られると説明しています。障害や監査の場面では、License Serverの存在だけでなく、VCF Operations上でどのように表示され、誰が確認し、どのログや証跡と結びつけるかを決めます。
単体障害を公開情報だけで断定しない
License Serverに障害が起きた時の細かな挙動、復旧手順、影響範囲は、環境やバージョン、サポート資料に依存します。公開ブログの範囲を超えて「こうすれば直る」と断定しない方が安全です。更新前チェックでは、Broadcomの公式ドキュメント、サポート窓口、保守手順に戻れる状態を作っておきます。
登録からvCenter割り当てまでの実務フロー
- 11. 権利を確認
VCF 9以上を利用できるサブスクリプション権利があるかを確認する。
- 22. Site ID権限
対象Site IDでライセンス作業を実行できる担当者を確認する。
- 33. VCF Operations準備
VCF Operationsの導入またはアップグレードと、Business Services consoleを操作できる状態を確認する。
- 44. 登録方式を選ぶ
Connected ModeまたはDisconnected Modeを選び、ライセンスファイルの取得方法を決める。
- 55. vCenterへ割り当て
vCenterへライセンスを割り当て、関連コンポーネントのライセンス状態を確認する。
技術的な準備ができていても、Site IDやポータル権限が未整理だと登録作業で止まる。
Broadcom KB 437242の実務的な価値は、ライセンス管理の入口を順番に示している点です。更新前の会議では、製品名を並べるより、次の流れで担当者を割り当てる方が話が進みます。
まず、VCF 9以上を利用できるサブスクリプション権利があるかを確認します。次に、対象Site IDでライセンス作業を実行できる権限を確認します。その後、VCF Operationsを導入またはアップグレードし、Business Services consoleで登録し、Connected ModeまたはDisconnected Modeの手順でライセンスファイルを取得します。最後に、VCF OperationsからvCenterへライセンスを割り当てます。
事前条件を確認する
KBは、9以上を利用できるentitlementと、Site IDでlicensingを行う権限を前提にしています。ここは技術担当だけでは解決しにくい部分です。契約担当、ポータル管理者、Broadcom Support Portalにアクセスできる担当者を早めに巻き込みます。
権限の棚卸しを更新作業より前に済ませる
更新作業の当日に「誰がポータルに入れるか」「誰がSite IDを持っているか」「誰がBusiness Services consoleを操作できるか」を確認すると、技術的には準備できているのにライセンス登録で止まります。権限棚卸しは、アップグレード手順書の付録ではなく、最初のタスクに置くべきです。
登録方式を選び、ライセンスファイルを取得する
Connected Modeでは、登録後にactivation codeを受け取り、それをVCF Operationsへ貼り付けることでライセンスファイルのダウンロードが始まるとKBは説明しています。Disconnected Modeでは、登録後に受け取ったライセンスファイルをVCF Operationsへインポートします。
方式ごとの証跡を決める
Connected Modeでは、自動取得と自動適用のログ、外部接続承認、通信経路を残します。Disconnected Modeでは、ライセンス使用量ファイル、送信記録、取得したライセンスファイル、インポート結果を残します。どちらも「処理できた」で終わらせず、次回の更新や監査で再現できる形にします。
vCenterへ割り当てて関連コンポーネントを確認する
KBは、vCenterへライセンスを割り当てると、ESX、NSX、VCF Automationなどの関連コンポーネントが自動的にライセンスされると説明しています。この表現は便利ですが、すべての製品、すべてのアドオン、すべての契約条件に広げて読まない方がよいです。
Advanced servicesは別扱いの可能性を見る
VCF 9.1 FAQは、VCF 9 licensingがvCenter、ESX、vSAN、NSX、HCX、VCF Operations、VCF Automation、VKS、VCF Private AI Servicesなどに関わると説明する一方で、AVI Load Balancer、vDefend Firewall、VMware Live RecoveryなどのAdvanced servicesは別にライセンスされるとしています。更新前のチェックでは、自社が使っているアドオンやAdvanced servicesを一覧化し、VCF本体のライセンス割り当てだけで済むのかを確認します。
VCF 5.2.xから9.1へ移る場合は、VCF 5.2.xから9.1へのアップグレード前チェックも合わせて確認すると、ライセンスだけでなく移行順序、VCF Management Services、NSX経路の論点を分けやすくなります。
大企業・VCSP・マルチテナントで確認する権限とレポート
マルチテナント環境では、便利な機能ほど権限、契約、顧客説明、監査証跡を分けて扱う必要がある。
VCF 9.1 licensing記事は、大企業やサービスプロバイダーに関わる要素として、Business Services consoleの粒度の細かいロール、テナント別ライセンス管理、ライセンス共有、マルチテナント対応を説明しています。ここは、単一の社内vCenterを管理する場合よりも慎重に読む必要があります。
特にVCSPやマルチテナント環境では、技術的にできること、契約上許されること、顧客へ説明すべきことが分かれます。公式ブログで確認できる機能説明と、SPDや個別契約で確認すべき権利条件を混ぜないようにします。
3つのロールを誰に渡すか
公式ブログは、License Refresh Role、Tenant License Manager、Read-Only Roleという3つの新しいライセンス関連ロールを挙げています。License Refresh Roleは特定のライセンス操作を実行するためのロール、Tenant License Managerは単一テナントのライセンス管理、Read-Only Roleは監査やレポート向けの閲覧に向いたロールとして見られます。
最小権限で始める
更新作業のために全員へ広い管理者権限を渡すと、監査時に説明しにくくなります。中央管理者、部門管理者、テナント管理者、監査担当、契約担当を分け、誰が更新し、誰が割り当て、誰が閲覧し、誰が承認するかを表にします。Read-Only Roleは、監査担当やコンプライアンス担当に有効な選択肢になります。
テナント別管理とライセンス共有の確認
公式ブログは、Business Services consoleがtenant-specific licensingやlicense sharingをサポートすると説明しています。大企業では部門別、地域別、子会社別の管理に使える可能性があります。サービスプロバイダーでは、テナント単位の分離や権限委譲に関わります。
VCSPはSPDと契約条件へ戻す
VCSPの読者がここを読む時は、ブログの機能説明だけで契約上の提供可否を判断しないでください。VCF SPD May 2026には、Cloud Services、Certified Cloud Services、License Portability、Hosting Rights and Restrictionsなど、サービス提供形態に関わる用語と制限が含まれています。自社がどのプログラム、どの取引文書、どの提供形態に該当するかは、契約窓口とBroadcom公式資料で確認する必要があります。
報告・監査で残すべき論点
監査で残すべきなのは、ライセンスファイルそのものだけではありません。接続方式、送信サイクル、送信前レビューの有無、Business Services consoleのロール、VCF Operations上の割り当て結果、vCenterごとの適用状態、Advanced servicesの別ライセンス確認、SPD確認日を残します。
公式資料の確認日を記録する
SPD、FAQ、KBは更新される可能性があります。記事作成時点では、Broadcom SupportのVCF SPD通知ページでMay 2026版のSPDが示され、ページのLast Updatedは2026年5月29日でした。社内資料に使う場合も、同じように確認日と参照URLを記録します。古いPDFを社内Wikiに貼ったままにすると、更新後の条件確認で混乱します。
更新前チェックリスト
更新前チェックは、作業を終えるためだけでなく、次回更新や監査で説明できる状態を作るために使う。
ここまでを実務のチェックリストにすると、VCF 9.1のライセンス更新は次の順で確認できます。
| 確認項目 | Connected Modeで見ること | Disconnected Modeで見ること | 主担当 |
|---|---|---|---|
| 権利と契約 | 9以上を使えるentitlement、対象Site ID、契約条件 | 同左 | 契約担当、ポータル管理者 |
| 接続方式 | 24時間ごとの自動送信、自動取得、自動適用の承認 | 180日ごとの手動送信、ファイル管理、代理者 | 運用担当、セキュリティ担当 |
| VCF Operations | 登録、ライセンス状態、vCenter割り当て | 登録、インポート、vCenter割り当て | VCF管理者 |
| License Server | VCF Operationsとの自動導入・自動更新の前提 | 同左 | VCF管理者 |
| Business Services console | ロール、テナント管理、ライセンス割り当て | ロール、テナント管理、ライセンスファイル取得 | 契約担当、ライセンス管理者 |
| vCenterと関連製品 | ESX、NSX、VCF Automationなどの適用確認 | 同左 | 仮想化基盤担当 |
| Advanced services | 別ライセンス対象の有無 | 同左 | 製品担当、契約担当 |
| 監査証跡 | 自動送信ログ、容量表示、異常表示 | レポート、送信記録、インポート結果 | 監査担当 |
迷った時の確認順
迷った時は、コミュニティ投稿や二次情報からではなく、次の順に戻るのが安全です。まず公式ブログでVCF 9.1の変更点を確認します。次にKB 437242で登録と割り当ての手順を確認します。FAQでLicense Usage File、Advanced services、License Serverの説明を確認します。最後に、SPDと契約文書で権利、制限、報告条件を確認します。
価格だけを先に読まない
更新費用への関心が高い場合でも、ライセンス運用を理解しないまま価格だけを見ると、比較軸が崩れます。Connected Modeを許可できるのか、Disconnected Modeの180日運用を回せるのか、Advanced servicesが別ライセンスか、VCF Operationsの運用負荷を誰が持つのかを整理した上で、契約担当と費用を確認します。
コスト可視化やShowbackをあわせて見たい場合は、VCF 9.1のFOCUS/FinOps確認記事が補助になります。ライセンス更新の費用感と、社内で誰にどのコストを説明するかは別の論点として扱うと、会議が進みやすくなります。
この記事で断定しないこと
この記事は、VCF 9.1の公式資料から読み取れるライセンス運用の確認メモです。個別契約の価格、割引、SKU、更新条件、VCSPの提供可否、クラウドサービスへのポータビリティ、サポート権利の最終判断は断定しません。投資助言でも、契約助言でもありません。
一方で、更新前に確認すべき会話の順序は明確です。接続方式、権限、License Server、vCenter割り当て、Advanced services、180日レポート、SPD確認日をそろえれば、少なくとも「何を誰が確認していないのか」は見えます。VCF 9.1のライセンス更新では、この可視化が最初の実務ポイントです。
読了後のメモ
Broadcomの公式発表、KB、FAQ、TechDocs、SPD、契約書を確認先として残す。
誰が、いつ、どの資料で、どの条件を確認したかを更新前メモに残す。
運用担当、監査担当、契約担当、販売パートナーへ確認事項を分けて共有する。
ライセンス変更や公式資料の更新を追うため、更新通知や資料一覧を使う。
契約や提供条件に関わる判断は、記事本文ではなく一次情報と契約確認に戻して扱う。
Broadcom Watch Japanでは、Broadcomの公式発表、VMware Cloud Foundation、VCF Operations、AIネットワーキング、セキュリティ更新、ライセンス変更を一次情報ベースで追っています。更新通知を受け取りたい場合は、ニュースレターから登録できます。
公式資料だけをたどりたい読者向けには、資料・確認ログも用意しています。ライセンスや契約に関わる記事では、本文よりも先に一次情報のURLを確認する方が安全です。
次に読むなら
参照した主な情報源
- https://blogs.vmware.com/cloud-foundation/2026/05/18/vcf-9-1-licensing-programmatic-centralized-and-built-to-scale/
- https://knowledge.broadcom.com/external/article/437242/getting-started-with-vmware-cloud-founda.html
- https://www.vmware.com/docs/vmware-cloud-foundation-9-1-general-faqs
- https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/LegalNotices/VMware-Cloud-Foundation–VCF–SPD/24359
- https://ftpdocs.broadcom.com/cadocs/0/VCF_SPD_May2026.pdf
更新履歴
- 2026年6月8日
VCF 9.1のライセンス運用、Connected Mode、Disconnected Mode、License Server、vCenter割り当ての確認メモとして整理。
- 公式資料更新時
Broadcom公式ブログ、KB、FAQ、SPD、TechDocsの更新内容を確認する。
- 契約確認時
価格、提供条件、サポート、ライセンス権利は、契約書、販売パートナー、公式窓口で確認する。
確認日は2026年6月8日。公開情報で断定できない条件は、公式資料と契約確認に戻す。
- 2026年6月8日: Broadcom/VMware公式ブログ、Broadcom KB 437242、VCF 9.1 FAQ、Broadcom SupportのVCF SPD通知ページ、VCF SPD May 2026を確認し、VCF 9.1のライセンス運用確認記事として作成しました。