VCF 9.1のFOCUS/FinOpsを導入前に確認する：Cost Overview、Showback、AI/GPUコスト可視化の実務ポイント

このテーマをもう少し広げて見るなら、VCF Operationsでオンプレ本番運用を見直す：88.8%調査、Day 2、容量・コスト可視化の実務ポイント と VCF 9.1ライセンスを更新前に確認する：24時間自動送信、180日レポート、License Serverの実務ポイント も合わせて確認してください。Cost OverviewやShowbackを、Day 2運用、容量管理、オンプレ本番運用の効率化とつなげて確認できるため。

VMware Cloud Foundation 9.1をコスト削減の言葉だけで読むと、導入前に見るべき実務ポイントを取りこぼします。2026年6月3日のVMware Cloud Foundation Blogは、VCF 9.1をFinOps Open Cost & Usage Specification、つまりFOCUSと結び付け、VCF Operations上のCost Overview、Cost Projection、Cost Analysis、Showbackを通じて、プライベートクラウドのコストを比較しやすい形にそろえる方向を示しました。

この記事では、FOCUSが何を標準化する話なのか、VCF Operationsで最初に確認するデータは何か、AI/GPUワークロードのコストをどこまで見える化できるのかを、公式情報で確認できる範囲に絞って整理します。本稿はBroadcomおよびVMware by Broadcomとは非提携の読者向け確認記事であり、掲載内容は投資助言ではありません。

3行まとめ

運用画面

Cost Overview、Showback、Cost Projection、Cost Analysisを、誰が説明できる数字にするかを確認します。

FOCUS 1.3

契約コミットメント、共有コスト配賦、データ鮮度、Service ProviderとHost Providerの区別を確認します。

AI/GPU

GPU利用率だけでなく、Kubernetes、VM、モデル、配賦ルール、Advanced Servicesの扱いまでPoCで確認します。

最初に見るべきなのは、機能一覧ではなく、表示されたコストを説明できる前提がそろっているかです。

• VCF 9.1とFOCUS/FinOpsの論点は、単なる会計用語ではなく、VCF OperationsでCost Overview、Showback、Cost Projection、Cost Analysisを運用に載せる話として読む必要があります。
• FOCUS公式仕様の最新説明では、FOCUS 1.3が契約コミットメント、共有コスト配賦、データ鮮度と完全性、Service Provider/Host Providerの区別を扱います。VCF側で使う場合も、タグ、配賦ルール、契約単位、更新タイミングを先に決めることが重要です。
• AI/GPUコスト可視化では、GPU利用率やKubernetes/VMの監視だけでなく、誰に何を見せるか、Showbackを課金に近づけるか、Advanced Servicesやライセンス条件をどう扱うかをPoCで確認します。

VCF 9.1とFOCUS/FinOpsを同じ話として見る理由

FOCUS仕様

契約、共有費、データ鮮度、提供者の区別など、比較可能なコストデータに必要な考え方を確認します。

VCF Operations

Cost Overview、Showback、Cost Projection、Cost Analysisを通じて、FinOpsの会話に使う数字を確認します。

VCF 9.1発表

AI/Kubernetes、GPU利用率、AI観測性など、プライベートクラウドのコスト可視化に関わる論点を確認します。

FOCUS対応は安心材料ですが、表示項目、権利範囲、設定で扱える範囲は導入環境ごとに確認が必要です。

VCF 9.1のFOCUS対応を読むときは、まず「FOCUSがコストデータの表記をそろえる仕様」であり、「VCF Operationsがそのデータを運用判断に使う画面と分析の入口になる」という2層で分けると理解しやすくなります。

2026年6月3日のVMware Cloud Foundation Blogは、BroadcomがVCF 9.1をFOCUSに合わせ、プライベートクラウドで発生するコストや利用状況を比較しやすい形にする、と説明しています。記事中ではCost Overview、Cost Projection、Cost Analysis、Showbackの画面イメージが示され、VCF OperationsがFOCUSの標準FinOpsユースケースを100%カバーし、8つは標準で、4つは設定で扱えるとされています。

ここで注意したいのは、FOCUS対応がそのまま「全社の課金ルールが完成する」という意味ではないことです。FOCUSは、異なるクラウド、SaaS、プラットフォーム、データセンター支出を比較しやすくするための共通言語です。VCF Operationsは、VCF環境の容量、性能、コスト、利用状況をまとめて見る運用面の入口です。両者を合わせることで、プライベートクラウドの費用を部門、アプリケーション、プロジェクト、ワークロード単位で説明しやすくなる一方、どの属性を使って配賦するかは利用者側で決める必要があります。

FOCUSは「請求データの標準化」から入る

根拠

FOCUS公式ページは、FOCUSを「technology billing data」のためのオープンな技術仕様として説明しています。2026年6月7日時点で同ページが示す最新バージョンはFOCUS 1.3で、2025年12月に批准された仕様です。

FOCUS 1.3で特に導入前チェックに効くのは、次の4点です。

• 契約コミットメントを専用データセットとして扱い、開始日、終了日、残り単位、説明をコスト/利用行から分けて見られるようにすること。
• 共有リソースのコスト配賦について、データ生成側がどの方法で分割したかを示せるようにすること。
• データの鮮度と完全性を、最終更新や確定/未確定の状態として確認できるようにすること。
• Service ProviderとHost Providerを分け、購入元と実際の配置先を区別できるようにすること。

注意点

そのため、VCFでFOCUS/FinOpsを使う場合も、「どのダッシュボードが出るか」だけでは足りません。契約単位、部門単位、共有クラスタ、GPUプール、VKS namespace、VMタグ、アプリケーション所有者を、FOCUS側の考え方に近い粒度で整理できるかを先に見ます。

VCF Operationsは「運用判断の入口」になる

根拠

VCF Operationsの公式データシートは、VCF Operationsをプライベートクラウドの単一コンソールとして位置づけ、統合されたコンピュート、ストレージ、ネットワーク運用、フルスタック可視性、コストと容量管理を主要な成果として挙げています。May 2026のデータシートでは、VCF 9.1向けにリアルタイム/予測型の容量・コスト分析、継続的なパフォーマンス最適化、Kubernetesコンテナ、VM、AIワークロードの監視が示されています。

つまり、FOCUSはデータを比べやすくする軸で、VCF Operationsはそのデータを運用チーム、アプリケーションチーム、財務/FinOps担当が見に行く場所です。導入前のPoCでは、FOCUSの列や概念を全部暗記するより、VCF Operations上でどの単位の利用者に、どのコストを、どの頻度で説明するかを決めるほうが実務に近い確認になります。

VCF 9.1全体の導入条件を整理したい場合は、先に<a href="https://avgo-watch.blog.mo-gmo.com/avgo-13-vcf-91-upgrade-api-ip-check/" rel="noopener">VCF 9.1を導入前に確認する：API-first、アップグレード計画、管理サービスIPの実務ポイント</a>を見ておくと、管理サービスやアップグレードの前提を合わせやすくなります。

Cost OverviewとShowbackで最初に確認するデータ

1. 1対象を決める

   VM、クラスタ、namespace、アプリケーション、部門、プロジェクトの対応関係を確認します。

2. 2属性をそろえる

   所有者、利用目的、環境区分、GPUプール、共有ストレージなどをタグや命名規則で追えるようにします。

3. 3配賦を決める

   共通基盤、管理コンポーネント、監視、バックアップ、セキュリティの費用をどう扱うかを決めます。

4. 4説明に使う

   Cost OverviewとShowbackで、期間、金額、リソース量、共有費を分けて説明できるか確認します。

Showbackは合意形成のための見える化であり、Chargebackのような請求処理とは分けて評価します。

Cost OverviewとShowbackは、きれいな画面が出るかどうかより、誰がその数字を説明できるかで評価します。特にVCF環境では、共有クラスタ、共通ストレージ、ネットワーク、管理VM、GPU、Kubernetes namespaceが混在しやすく、単純な「VMごとの料金」だけでは利用者の納得感が出ません。

まず確認したいのは、VCF Operationsが見ている対象と、社内の配賦単位が一致しているかです。アプリケーション単位で見せたいのにタグが部門単位しかない、GPUプールを研究開発と本番推論で分けたいのに所有者属性がない、共有ストレージの配賦ルールが決まっていない。この状態でShowbackを始めると、画面は作れても説明のたびに手作業が戻ってきます。

入力データはタグと所有者から点検する

確認項目

VCF OperationsでCost OverviewやShowbackを使う前に、少なくとも次の属性を棚卸ししておきます。

• VM、クラスタ、namespace、アプリケーション、部門、プロジェクトの対応関係。
• CPU、メモリ、ストレージ、ネットワーク、GPUなど、どのリソースを費用説明に含めるか。
• 共通基盤、管理コンポーネント、バックアップ、監視、セキュリティなど、直接利用者に配賦しにくい費用をどう扱うか。
• 開発、検証、本番、AI実験、推論サービスなど、利用目的の違いをタグや命名規則で追えるか。
• コストを月次で見るのか、日次で見るのか、プロジェクト終了時に精算するのか。

FOCUS 1.3が共有コスト配賦の透明性やデータの鮮度/完全性を重視している点を踏まえると、タグの欠落は単なる運用ミスではなく、コスト説明の信頼性を下げる要因です。特に共有GPUや高価なストレージを複数部門で使う場合、配賦ルールを後から決めると、削減施策より先に数字合わせが始まります。

Showbackは請求ではなく説明から始める

注意点

Showbackは、利用部門に対して「あなたの利用状況と推定コストはこう見えている」と示すための運用です。Chargebackのように実際の請求や内部振替へ進む前に、数字の粒度、期間、単価、共有費、例外処理を合意する段階として使うと失敗しにくくなります。

VCF Operationsデータシートの機能比較では、Chargeback、Tenant Operations and MeteringはVMware Cloud Foundation EdgeとVMware Cloud Foundationで利用できる一方、vSphere Foundationでは対象外として整理されています。vSphere Kubernetes Service CostingやNVMe Memory Tiering Recommendationsは表上で各列にYesと示されており、どのエディション/構成で何が使えるかを必ず自社の契約・構成で確認する必要があります。

Showbackを導入する最初の単位は、1つの本番アプリケーション、1つのAI推論基盤、1つのVKSクラスタなど、責任者がはっきりしている範囲が向いています。全社一斉に始めるより、対象を絞って「この数字は納得できるか」「誰がタグを直すか」「共有費はどこまで見せるか」を確認するほうが、あとでChargebackに進めるかどうかを判断しやすくなります。

VCF Operationsで管理VMやNSX/vCenterのリソース配分を先に確認したい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-15-vcf-operations-vcenter-nsx-resource-allocation/" rel="noopener">VCF Operationsで管理VMのリソース割り当てを確認する</a>も補助線になります。Cost Overviewの前に、管理側のリソース消費を把握しておくと、利用者向けコストとの切り分けがしやすくなります。

Cost ProjectionとCost Analysisを容量計画につなげる

項目	内容	見方
増加要因		1か月後、3か月後、四半期末で、CPU、メモリ、ストレージ、ネットワーク、GPUのどれが主因になるかを確認します。
予測外れ		タグ欠落、利用急増、単価変更、クラスタ追加、ワークロード移動のどれに分類できるかを確認します。
削減候補		Rightsizing、Reclamation、統合、移設、GPU再配分を、所有者が判断できる形で説明します。
承認条件		SLO、メンテナンス可能時間、権限、承認者を決めてから容量変更や削減施策へ進めます。

Cost ProjectionとCost Analysisは、費用予測だけでなく、容量追加、契約見直し、削減施策を選ぶ入口として使います。

Cost ProjectionとCost Analysisは、単に今月の利用額を見る機能としてではなく、容量計画と削減施策をつなぐ入口として読みます。VCF Operationsのデータシートは、リアルタイム/予測型の容量・コスト分析、What-If分析、TCO、Potential Savings、Rightsizing、Reclamationを確認軸として示しています。

この領域で大切なのは、「削減できそうな金額」を出すことではなく、どの変更ならサービス品質を落とさずに実行できるかです。メモリを減らす、ストレージを移す、クラスタを統合する、GPUを別プロジェクトに回す、Kubernetesクラスタを縮小する。どの施策も、アプリケーションのSLO、メンテナンス可能時間、権限、承認者が決まっていないと、ダッシュボード上の推奨だけで終わります。

予測値は「行動できる粒度」で見る

評価基準

Cost Projectionで確認する粒度は、組織の意思決定単位に合わせます。部門が予算を持つなら部門単位、アプリケーションチームが自律的にリソースを調整するならアプリ単位、AI基盤チームがGPUプールを運用するならGPUプール単位が候補になります。

導入前PoCでは、次の問いを実データで試すと、Projectionの使いどころが見えやすくなります。

• 1か月後、3か月後、四半期末で、どのリソースが費用増の主因になるか。
• 予測値が外れたとき、原因をタグ欠落、利用急増、単価変更、クラスタ追加、ワークロード移動のどれに分類できるか。
• 削減候補として出たリソースを、アプリケーション所有者が確認できる形で説明できるか。
• AI/GPUやKubernetesの短期実験利用を、通常のVM運用と同じ周期で評価してよいか。
• コスト削減と性能劣化のトレードオフを、誰が承認するか。

Cost Projectionは、予測が当たるか外れるかだけではなく、予測が外れた理由を説明できるかが重要です。FOCUS 1.3がデータ鮮度と完全性を扱う理由もここにあります。未確定データや更新遅れを知らずに意思決定へ使うと、削減施策の優先順位が逆転することがあります。

Cost AnalysisはRightsizingとReclamationへつなげる

実行条件

Cost Analysisは、どのリソースが高いかを見るだけではなく、どのリソースを戻せるか、どのリソースを別の用途へ回せるかを見るために使います。VCF Operationsデータシートが示すRightsizing、Reclamation、Workload Optimization、What-If分析は、FinOpsの運用と相性が良い領域です。

ただし、rightsizingを自動化に寄せすぎると、アプリケーションチームの納得を得にくくなります。まずは、過去30日や90日の利用状況、ピーク時の性能、バックアップやバッチの時間帯、GPUジョブの予約状況を見て、削減候補の根拠を説明できる形にします。Cost Analysisは「削る理由」を出すだけでなく、「削らない理由」を記録する場所としても使うべきです。

VCF 9.1の決算・製品文脈を合わせて読みたい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-23-q2-2026-ai-vmware-product-check/" rel="noopener">Broadcom Q2 FY2026決算後チェック：AI半導体とVMware Cloud Foundationで導入前に見るポイント</a>で、AI半導体とVCFの位置づけを確認できます。ただし本稿の主役は市場反応ではなく、VCF Operations上のコスト可視化と運用判断です。

AI/GPUワークロードのコスト可視化で外せない確認

GPU利用

GPU利用率、vGPU、GPUメモリ、ジョブ待ち、推論リクエストの関係を確認します。

AI品質指標

time to first tokenやtoken throughputなど、利用者体験に近い指標と費用の関係を確認します。

ワークロード単位

VKS namespace、VM、モデル、API、プロジェクト、部門を対応付けられるか確認します。

共通費

ストレージ、ネットワーク、ログ、監視、セキュリティをAIプロジェクトへどう配賦するか決めます。

CPU側の負荷

GPUを使わないagentic workflowや周辺処理が、総コストにどの程度影響するか確認します。

AI/GPUでは、GPU利用率だけではなく、モデル、API、プロジェクト、共通基盤まで含めた説明単位が重要です。

Broadcomの2026年5月5日のVCF 9.1発表は、VCF 9.1を本番AIワークロード向けの安全でコスト効率の高いインフラ基盤として紹介し、AMD、Intel、NVIDIAを含む混在コンピュート、AI/Kubernetesネイティブ、GPU利用率、time to first token、token throughputなどのAI観測性に触れています。

FOCUS/FinOpsの観点では、このAI文脈が重要です。AI/GPUワークロードは、通常のVMより費用差が大きく、利用者が増えると共有GPU、推論API、Kubernetesクラスタ、ストレージ、ネットワーク転送、モデル管理、セキュリティが一体で膨らみます。Cost Overviewが見えるだけでは、どのチームが何を使い、何を削減できるかまでは決まりません。

GPU利用率だけでは十分ではない

確認項目

GPU利用率は重要ですが、それだけでコストの妥当性は判断できません。推論サービスでは、GPU利用率が低くてもレイテンシ要件のために余裕を持たせる必要があります。バッチ推論や学習では、時間帯によって利用率が大きく変わることがあります。Kubernetes上でGPUを使う場合は、namespace、ジョブ、モデル、チーム単位の対応関係も必要になります。

導入前には、少なくとも次の単位で見えるかを確認します。

• GPU利用率、vGPU、GPUメモリ、ジョブ待ち、推論リクエストの関係。
• time to first tokenやtoken throughputなど、AIサービス品質に近い指標。
• VKS namespace、VM、モデル、API、プロジェクト、部門の対応関係。
• GPUを使わないCPU中心のagentic workflowが、どの程度コストに効いているか。
• ストレージ、ネットワーク、ログ、監視、セキュリティの共通費をAIプロジェクトへどう配賦するか。

Broadcomの発表は、VCF 9.1が本番AIやagentic AIを対象にすることを強く打ち出しています。だからこそ、PoCでは「AIワークロードが動くか」だけではなく、「AIワークロードの費用を説明できるか」を同時に確認する価値があります。

Kubernetes、VM、AIの境界をそろえる

注意点

VCF Operationsデータシートは、Kubernetesコンテナ、VM、AIワークロードの監視を機能として挙げています。一方で、実際の費用説明では、KubernetesとVMを別の運用単位として扱っている組織も多いはずです。VKSで動くアプリケーション、従来VM、AI推論サービス、GPUノードを、同じCost Overviewの言葉で説明できるかが重要になります。

ここでFOCUS 1.3のService Provider/Host Providerの考え方が効きます。たとえば、サービスとして利用者に提供しているのは社内AI基盤チームでも、実際にリソースが置かれているのは特定のVCFクラスタかもしれません。購入元、提供元、実行場所、利用部門がずれる場合、どの名前でShowbackに出すかを決めておかないと、利用者は数字を自分ごととして受け取りにくくなります。

運用に載せる前のチェックリスト

項目	内容	見方
画面機能		Cost Overview、Showback、Cost Projection、Cost Analysisで、自社が説明したい切り口を作れるか確認します。
データ品質		タグ、所有者、共有費、更新タイミング、未確定データ、欠損データを区別できるか確認します。
組織ルール		FinOps担当、インフラ担当、アプリ担当、監査担当の閲覧権限と承認手順を決めます。
契約と権利範囲		VCF Operations、Advanced Services、Business Operations相当機能、アドオンの扱いを確認します。
段階導入		既存タグ棚卸し、小規模Showback、AI/GPU限定PoC、月次レビューの順で広げます。

最初から全社Chargebackへ進めるのではなく、Showbackで合意形成できる範囲から始めると判断しやすくなります。

VCF 9.1とFOCUS/FinOpsを導入前に見るなら、チェックリストは画面機能、データ品質、組織ルール、契約/ライセンスに分けると抜け漏れが減ります。

画面機能で確認すること

確認項目

• Cost Overviewで、部門、プロジェクト、アプリケーション、クラスタ、namespaceなど、自社が説明したい切り口を作れるか。
• Showbackで、利用者に見せる期間、単位、金額、リソース量、共有費を分けて説明できるか。
• Cost Projectionで、増加傾向の原因をリソース別、アプリ別、チーム別に追えるか。
• Cost Analysisで、Rightsizing、Reclamation、What-If分析につなげられるか。
• AI/GPUワークロードの指標と、通常VM/Kubernetesの指標を同じ会議で扱えるか。

画面はPoCで確認しやすい反面、画面だけを合格にすると運用が残ります。実際には、誰がデータを直し、誰が部門へ説明し、誰が削減施策を承認するかまでセットで決めます。

データ品質で確認すること

確認項目

• タグ、命名規則、所有者、プロジェクトコードが欠落していないか。
• 共有クラスタ、共通ストレージ、管理コンポーネント、セキュリティ、バックアップの費用をどう扱うか。
• FOCUS 1.3で重視されるデータ鮮度、完全性、共有コスト配賦、契約コミットメントに相当する確認を、VCF側の運用でどこまで持てるか。
• 未確定データを利用者向けレポートに含める場合、その状態を表示または注記できるか。
• 単価や契約条件が変わったとき、過去レポートとの比較が崩れないか。

FinOpsの失敗は、ダッシュボード不足よりもデータ整備不足から起きやすい領域です。特にVCFのような共通基盤では、費用が高いリソースほど共有されやすく、共有されるほど配賦ルールが難しくなります。

契約、ライセンス、Advanced Servicesで確認すること

根拠

VCF 9.1 FAQでは、VCF 9.1がvSphere、vSAN、NSX、VKS、VCF Operations、VCF Automation、HCX、VCF Private AI servicesなどを含む主要コンポーネントとして説明されています。また、Advanced Servicesは別購入で、Business Operations、Data Services、Network Observabilityなどが列挙されています。

同FAQは、VCF 9.0以降のライセンス管理について、VCF OperationsとVCF Business Services consoleを使う形を説明し、VCF Operationsがライセンス割り当てと管理に関わることを示しています。Cost OverviewやShowbackの議論をする前に、自社がどのVCF構成で、どのAdvanced Servicesを含み、どの契約単位で利用しているのかを確認しておくべきです。

ここを曖昧にすると、FinOpsの数字が「技術的な利用量」と「契約上の費用」のどちらを示しているのかが混ざります。FOCUS 1.3の契約コミットメントの論点は、この混乱を避けるためにも重要です。

導入判断をどうまとめるか

1. 1対象を選ぶ

   本番に近いアプリケーションまたはAI/GPUワークロードを1つ以上選びます。

2. 2Showbackを説明する

   Cost OverviewとShowbackを、責任者が納得できる単位と期間で説明します。

3. 3配賦を文書化する

   共有費、管理コンポーネント、GPUプール、Kubernetes namespaceの配賦ルールを残します。

4. 4増加要因を分類する

   Cost Projectionの増加要因を、Rightsizing、Reclamation、容量追加、契約見直しへ振り分けます。

5. 5継続条件を決める

   未確定データ、更新遅れ、タグ欠落を区別し、月次更新で再現できるかを確認します。

導入判断では、公式の効果数値をそのまま期待値にせず、自社環境で説明できるコストデータに落とせるかを見ます。

VCF 9.1のFOCUS/FinOps対応は、プライベートクラウドの費用を公開クラウドやSaaSと比較しやすくし、アプリケーションチームに説明しやすくする方向の動きです。公式ブログが示すCost Overview、Cost Projection、Cost Analysis、Showbackは、VCF OperationsをFinOpsの会話に乗せる材料になります。

一方で、導入判断では「VCFがFOCUSに対応するから安心」とまとめないほうがよいです。実務では、タグ、所有者、配賦ルール、契約条件、AI/GPU指標、データ鮮度、Advanced Servicesの境界がそろって初めて、コスト可視化が意思決定に使える形になります。

PoCの合格条件は、次のように置くと現実的です。

• 1つ以上の本番に近いアプリケーションまたはAI/GPUワークロードで、Cost OverviewとShowbackを責任者に説明できる。
• 共有費、管理コンポーネント、GPUプール、Kubernetes namespaceの配賦ルールを文書化できる。
• Cost Projectionが示す増加要因を、Rightsizing、Reclamation、容量追加、契約見直しのいずれかに分類できる。
• 未確定データ、更新遅れ、タグ欠落をレポート上で区別できる。
• Chargebackへ進む前に、Showbackで利用部門との合意形成ができる。

VCF 9.1をすでに評価している企業にとって、FOCUS/FinOpsは後付けの会計機能ではありません。AI/GPU、Kubernetes、VM、共有基盤の費用を、技術チームと財務/事業部門が同じ言葉で話すための運用設計です。最初の導入範囲を小さく取り、Showbackで数字の納得感を作り、その後にChargebackや契約コミットメント管理へ広げるのが、現時点では堅い進め方です。

---

次に読むなら

参照した主な情報源

• VMware Cloud Foundation Blog, "Unified Cloud Value: Accelerating Cloud Fin-Ops with VCF 9.1 and FOCUS"（2026年6月3日公開、2026年6月7日確認） https://blogs.vmware.com/cloud-foundation/2026/06/03/unified-cloud-value-accelerating-cloud-fin-ops-with-vcf-9-1-and-focus/
• Broadcom Investor Relations PDF, "Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI"（2026年5月5日公開、2026年6月7日確認） https://investors.broadcom.com/node/64326/pdf
• VMware Cloud Foundation Operations Datasheet（May 2026、2026年6月7日確認） https://www.vmware.com/docs/vmw-vcf-operations-datasheet
• VMware Cloud Foundation 9.1 Frequently Asked Questions（May 28, 2026、2026年6月7日確認） https://www.vmware.com/docs/vmware-cloud-foundation-9-1-general-faqs
• FOCUS Specification（FOCUS 1.3、2026年6月7日確認） https://focus.finops.org/focus-specification/