3行まとめ
このテーマをもう少し広げて見るなら、VCF 9.1のFOCUS/FinOpsを導入前に確認する：Cost Overview、Showback、AI/GPUコスト可視化の実務ポイント と Broadcom Private Cloud Outlook 2026を読む：AI推論をPrivate Cloud/VCFで動かす前の確認ポイント も合わせて確認してください。Day 2運用の棚卸しから、容量・コスト可視化を具体的な確認項目へ落とせるため。
オンプレミス上の本番処理が大きな比重を持つなら、基盤を説明可能に運用できているかを確認します。
容量、性能、コスト、ライフサイクル、診断を分けて見て、単一の指標だけで判断しないようにします。
VCF Operationsで取得できる数字を、社内の改善アクションや定例レビューに結びつけられるかを見ます。
調査値は関心の入口であり、自社のオンプレ比率や移行方針をそのまま決める材料ではありません。
Broadcom傘下のVMware Cloud Foundation公式ブログは、2026年6月5日に「本番トランザクションの88.8%がオンプレミスで動く」という調査値を紹介し、Day 2以降の運用効率を問い直しました。
この記事では、その数字を移行判断や投資材料として短絡せず、VCF Operationsで容量、性能、コスト、ライフサイクル、診断をどう棚卸しするかに絞って整理します。
導入企業が最初に見るべきなのは、オンプレ回帰かクラウド離れかという大きな物語ではなく、監視対象、指標、期間、責任者、更新作業が同じ運用データで説明できるかです。
本記事はBroadcom、VMware、関係会社とは非提携の確認メモです。製品の提供条件、価格、契約、サポート範囲は、必ず公式資料、Broadcom Support Portal、販売パートナー、契約書で確認してください。
88.8%調査をオンプレ本番運用の棚卸しに変える
調査値、公開日、記事の文脈を確認し、オンプレ本番運用への関心が高い背景として扱います。
監視対象、タグ、所有者、コスト単位、更新手順、障害時の証跡がそろっているかを確認します。
自社のオンプレ比率、コスト削減率、クラウド移行の可否を、調査値だけで判断しません。
数字の大きさではなく、今の本番基盤をどの粒度で説明できるかが運用レビューの焦点です。
VMware Cloud Foundationの公式ブログは、2026年6月5日の記事で、企業インフラの複雑化とDay 2運用の重要性を取り上げました。記事タイトルにある「88.8%」は目を引きますが、ここで大事なのは数字の大きさそのものではありません。オンプレミス上の本番処理がまだ大きな比重を持つなら、その基盤をどれだけ説明可能に運用できているか、という問いです。
この読み方を間違えると、記事はすぐに「オンプレかクラウドか」という二択になります。Broadcom Watch Japanの読者にとって実用的なのは、そこではありません。既存のvSphere/VCF環境を持つ企業、VMware Cloud Foundation 9.1への移行を検討している企業、運用コストや更新作業の説明責任を抱えるチームが、今の状態をどう測るかです。
数字はトレンドの入口であって、自社環境の答えではない
88.8%という数値は、公式ブログがIDC Analyst Briefを参照して紹介している調査上の数字です。自社の業務システム、取引量、ピーク時間、規制要件、データ所在地、既存契約がそのまま同じ分布になるとは限りません。
確認日と対象範囲を残す
調査値を社内資料に使う場合は、確認日、参照した公式記事、調査値を使う目的、自社環境で確認した範囲を一緒に残します。数字だけを抜き出すと、オンプレ全体の比率なのか、自社の重要業務に当てはめた判断なのかが曖昧になります。
そのため、本文でこの数字を使うなら、「多くの重要処理がオンプレに残り得る」という確認の入口に留めるのが安全です。実際の判断では、対象ワークロードの一覧、VMやKubernetesクラスタの重要度、依存するストレージとネットワーク、障害時の復旧目標、更新停止を許容できる時間帯を洗い出す必要があります。
記事を読む側も、公式ブログの調査値を「自社もオンプレに寄せるべき」という結論に変換しない方がよいです。むしろ、自社で本当にオンプレに残している処理がどれか、そこに必要な運用証跡が足りているかを確認する材料として使います。
Day 0/Day 1ではなくDay 2以降を主語にする
VCFの導入検討では、どう構築するか、どのバージョンへ移行するか、どの機能が新しいかに目が向きがちです。ただし、公式ブログが強調するのは、構築後に安全に保守し続けるDay 2以降の運用です。
Day 2運用では、監視アラートを受けるだけでは足りません。容量がどのクラスタで詰まり始めているか、性能の上振れと下振れがどの時間帯に出ているか、証明書やパスワードの期限がどの順序で迫っているか、パッチ適用やアップグレードの前提チェックがどこで止まるかを、同じ場所から説明できる必要があります。
ここでVCF Operationsが候補になる理由は、単なるダッシュボード製品だからではありません。VCF全体の運用、可視化、コスト、診断、ライフサイクルの情報を束ね、日々の判断に使うための基盤として位置づけられているからです。
直近の需要シグナルは運用不安にある
2026年6月初旬のBroadcom関連の需要シグナルを見ると、Q2決算、AIネットワーキング、VCF 9.1の新機能が強く出ています。一方で、VMware利用者のコミュニティでは、価格、契約、既存環境の維持、サポート条件への不安も続いています。
この記事では、コミュニティの声を事実認定には使いません。価格や契約条件は個別契約に依存し、公開情報だけで断定できないためです。ただ、読者が何に困っているかを知る需要シグナルとしては有効です。運用チームが知りたいのは、「VCFに含まれる機能がある」だけではなく、「その機能で本当に自社の運用負荷を説明できるか」です。
だからこそ、この記事の主語はVCF Operationsの機能一覧ではなく、オンプレ本番運用の棚卸しです。数字、アラート、コスト、更新作業を同じ会議で扱えるようにする、という実務の形に落として読みます。
VCF Operationsで測る5つの運用軸
どれか一つの軸だけでは、オンプレ本番運用の効率やリスクを説明しきれません。
VMware Cloud Foundation Operationsの製品ページは、プライベートクラウドの構築、運用、保護を支える製品として、fleet-levelの管理、統合的な可視性、性能、FinOps、セキュリティを説明しています。公式ブログも、Day 0からDay Nまでのライフサイクルを支える柱としてBuild、Manage、Optimize、Protectを並べています。
この分類をそのまま覚えるより、自社の運用レビューでは5つの軸に言い換えると扱いやすくなります。容量、性能、コスト、ライフサイクル、診断です。どれか一つだけを見ると、現場の判断はぶれます。容量に余裕があっても性能劣化が起きることはありますし、コストが下がっても更新作業が属人化していれば、次の障害時に説明できません。
容量は「空きがあるか」ではなく「どこで詰まるか」を見る
容量管理では、CPU、メモリ、ストレージ、ネットワークの空きだけを見ても十分ではありません。重要業務VM、管理VM、Kubernetesクラスタ、バックアップやレプリケーションの処理、AI/GPU関連の一時的な負荷を分けて、どの範囲が先に詰まるかを見る必要があります。
たとえば、平均使用率が低いクラスタでも、特定時間帯にだけメモリ圧迫が出る場合があります。ストレージ容量は十分でも、I/O待ちやデータ保護の処理が重なる時間帯に性能が落ちることもあります。VCF Operationsを見るときは、総量、ピーク、傾向、しきい値、Top Nのリソースを分けて確認すると、会話が具体的になります。
容量の棚卸しは、アップグレード計画ともつながります。移行やパッチ適用の前に、対象コンポーネントが必要なリソースを持っているか、管理VMが過小構成になっていないか、既存記事の<a href="https://avgo-watch.blog.mo-gmo.com/avgo-15-vcf-operations-vcenter-nsx-resource-allocation/">VCF Operationsで管理VMのリソース割り当てを確認する</a>のように、まず基礎データをそろえると判断が早くなります。
性能は平均ではなく「業務に響く時間帯」を見る
性能レビューでは、平均値だけを出すと問題が隠れます。業務システムのピーク、バッチ処理、バックアップ、月末処理、セキュリティスキャン、vMotionやメンテナンスが重なる時間帯を切り出して見る必要があります。
Broadcom DeveloperのVCF Operations API 9.1では、Stats系のAPIがresourceId、statKey、begin、end、rollUpType、intervalTypeなどを使ってリソースの統計を取得できることを説明しています。これは、画面を見るだけでなく、同じ条件で定期的に数字を取り出す運用に向いています。
ただし、APIを使う場合も、いきなり自動化に飛ばない方がよいです。まず、どの業務を代表値にするのか、どのStatKeyを見るのか、期間を日次、週次、月次のどれにするのか、ピーク時と平常時をどう分けるのかを決めます。ここが曖昧だと、APIで取得した数字が会議資料にはなっても、運用判断にはつながりません。
コストは契約金額ではなく運用データとの対応を見る
VCF Operationsの文脈でコストを見るときは、契約金額や単価だけを追っても不十分です。どのクラスタ、どのテナント、どのアプリケーション、どのGPU/CPU/ストレージ利用がコスト説明に入るのかを、運用データと結びつける必要があります。
VCF 9.1では、FinOpsやFOCUSに関連する話題も出ています。詳細は<a href="https://avgo-watch.blog.mo-gmo.com/avgo-30-vcf-91-focus-finops-cost-visibility-check/">VCF 9.1のFOCUS/FinOpsを導入前に確認する</a>で扱っていますが、この記事では前段の準備に絞ります。コスト可視化の前に、リソースの所有者、タグ、部門、アプリケーション名、利用期間、除外ルールが整理されていないと、見える数字は説明できません。
ライフサイクルは「更新できるか」ではなく「更新を繰り返せるか」を見る
Day 2運用で最も見落とされやすいのは、パッチ、アップグレード、証明書、パスワード、コンポーネント互換性の反復作業です。一度だけ更新できても、次回以降も同じ品質で繰り返せなければ、運用の効率化とは言えません。
VCF 9.1の関連発表では、効率、アプリケーション性能、レジリエンスを改善する方向性が説明されています。実務では、これを「どの更新作業を、誰が、どの順序で、どの事前チェックを通して、どの戻し方で実行するか」に落とします。アップグレード全体の順序は、既存記事の<a href="https://avgo-watch.blog.mo-gmo.com/avgo-28-vcf-52x-to-91-upgrade-planner-check/">VCF 5.2.xから9.1へ移行前に確認する</a>も合わせて確認すると、運用レビューの粒度がそろいます。
診断は障害後の説明だけでなく予兆確認に使う
診断機能は、障害が起きた後に原因を探すためだけに使うものではありません。Findings、ログ、アラート、推奨事項、しきい値の変化を定期的に見て、次に問題になりそうな箇所を先に出すために使います。
特に古いvSphere/NSXコンポーネントを含む環境では、最新のVCF Operationsだけを見ても十分ではない場合があります。既存記事の<a href="https://avgo-watch.blog.mo-gmo.com/avgo-17-vcf-operations-91-diagnostics-old-components/">VCF Operations 9.1 Diagnosticsを旧vSphere/NSX環境で使う前に</a>で扱ったように、対象バージョン、Findingsの範囲、ログ連携、更新方式を分けて確認する必要があります。
容量と性能を測るときの最初の確認項目
- 1リソース選定
業務単位、クラスタ単位、管理VM単位のどれで見るかを決めます。
- 2StatKey選定
CPU、メモリ、ストレージ、ネットワーク、待ち時間のどれを判断材料にするかを決めます。
- 3期間とRollup
平常時、ピーク時、月末、メンテナンス時を分け、AVG、MAX、MIN、COUNTの使い方をそろえます。
- 4Top N確認
上位リソースの件数とgroupByの意味をそろえ、増設や調査の優先順位を出します。
- 5例外判定
業務イベント、バックアップ、バッチ、障害対応による外れ値を分けて改善アクションにつなげます。
管理VMの割り当て確認と業務VMの利用状況確認は、同じ表で混ぜずに分けて見ると判断しやすくなります。
VCF Operationsを使った容量・性能レビューは、最初から完璧なメトリクス一覧を作るより、運用上の質問から始める方がうまくいきます。「来月のピークを耐えられるか」「どのクラスタが最初に増設対象になるか」「重要業務VMの性能低下はどの時間帯に起きるか」「管理コンポーネントの割り当て不足はないか」といった質問です。
質問が決まると、見るべきリソースと指標が決まります。逆に、最初から取得可能な指標を並べると、見るものは増えても判断は遅くなります。
監視対象を業務単位に束ねる
最初に行うべきことは、監視対象を業務単位に束ねることです。単独のVM、ホスト、データストア、ネットワークだけを見るのではなく、業務システム、アプリケーション、テナント、部門、サービスレベルに紐づけます。
たとえば、決済系、社内基幹系、開発基盤、AI検証基盤、バックアップ基盤では、同じCPU使用率でも意味が違います。夜間バッチが中心のシステムで昼間の平均値を見ても判断になりませんし、常時低遅延が必要なシステムで月次平均を見てもリスクを隠します。
VCF Operationsの画面やAPIを見る前に、業務単位で「重要」「通常」「実験」「停止可能」のように分類しておくと、Top Nやアラートの読み方が変わります。重要業務の小さな劣化は、実験環境の大きな使用率より優先されることがあります。
API確認ではResource ID、StatKey、期間を固定する
Broadcom DeveloperのVCF Operations API 9.1では、統計取得にresourceId、statKey、begin、end、rollUpType、intervalTypeなどの条件を使います。多くのリソースを対象にする場合は、URL長の制限を避けるためにPOSTのquery系エンドポイントを使う案内もあります。
最初は再現できる条件だけを見る
初回レビューでは、対象リソース、指標、期間、ロールアップ、並び順を固定し、翌週に同じ条件で再取得できることを優先します。条件が毎回変わると、改善したのか、取得方法が変わっただけなのか判断できません。
実務で大事なのは、APIを動かすことそのものではなく、同じ条件で取り続けられることです。Resource IDが変わった場合の扱い、StatKeyの命名、取得期間、ロールアップ方法、タイムゾーン、欠損値、権限、トークン更新を決めておく必要があります。
確認用の最小セットは、次のように考えるとよいです。
| 確認対象 | 最初に決めること | 失敗しやすい点 |
|---|---|---|
| Resource ID | 業務単位、クラスタ単位、管理VM単位のどれで見るか | UUIDだけで一覧化し、業務名と結びつかない |
| StatKey | CPU、メモリ、ストレージ、ネットワーク、待ち時間のどれを見るか | 取得できる項目を全部並べて判断がぼける |
| 期間 | 平常時、ピーク時、月末、メンテナンス時を分けるか | 24時間平均だけで性能問題を判断する |
| Rollup | AVG、MAX、MIN、COUNTなどをどう使うか | 平均値だけで瞬間的な劣化を隠す |
| Top N | 上位リソースを何件出すか | groupByやTop N件数の意味を誤解する |
Top N APIでは、groupByをRESOURCEまたはSTATKEYで扱い、sortOrder、topN、resourceId、statKey、期間、rollUpTypeなどを指定できます。Top Nは便利ですが、1つのグループに複数指標が含まれると件数の数え方が直感とずれる場合があります。上位10件を出したつもりでも、業務単位では少数のグループしか見えていない、ということが起きます。
Dynamic ThresholdやcurrentOnlyは運用ルールとセットで見る
Stats APIには、動的しきい値に関わるdtや、現在値のある統計だけを返すcurrentOnlyのような条件もあります。これらは便利ですが、意味を運用ルールに落とさないと誤解を生みます。
Dynamic Thresholdを使うなら、通常の変動として許容する範囲と、業務影響として扱う範囲を分ける必要があります。currentOnlyを使うなら、値が返らないリソースを「問題なし」と見なしてよいのか、監視対象から外れているのかを確認しなければなりません。
APIの結果は、運用会議で使える言葉に変換して初めて価値があります。「CPUが高い」ではなく、「決済系クラスタで月末処理の2時間だけCPU待ちが増え、次回ピーク前にvMotion計画と追加容量の判断が必要」のように書けるかを見ます。
コスト可視化はFinOpsの前に運用データをそろえる
表示されたコストは、そのまま請求や削減判断に使うのではなく、まず配賦ルールの妥当性と説明粒度を確認します。
VCF 9.1の文脈では、FOCUSやFinOpsの話題が出やすくなっています。これは重要ですが、コスト可視化は、いきなり会計や請求の話にすると失敗します。まず、運用データがコスト説明に使える形でそろっているかを見ます。
コストを説明するには、リソースの所有者、利用目的、稼働期間、ピークと平常時、予約・コミットメント、共有リソースの配賦、除外する検証環境などが必要です。これらがそろっていない状態でダッシュボードだけを作ると、見た目は整っても、部門間の会話ではすぐに止まります。
Cost Overviewの前にタグと所有者を決める
Cost OverviewやShowbackのような画面を使う前に、タグと所有者のルールを決める必要があります。部門名、アプリケーション名、環境区分、本番/検証/開発、サービスオーナー、予算責任者、除外条件が決まっていないと、数字を見ても誰が何を変えるべきか分かりません。
配賦ルールは例外から決める
共有基盤、DR、監視、セキュリティ、検証用GPUのように、部門へ単純に割り当てにくいリソースを先に洗い出します。例外の扱いを決めておくと、Showbackの数字を見た後の議論が「誰の費用か」だけで止まりにくくなります。
特にオンプレ本番運用では、共有リソースの扱いが難しくなります。管理クラスタ、バックアップ、監視、セキュリティ、ネットワーク、DRのような共通基盤をどの部門に配賦するかは、技術だけでは決まりません。運用、財務、アプリ責任者の合意が必要です。
ここでVCF Operationsを使う意味は、請求書を置き換えることではなく、コストを発生させる運用状態を見えるようにすることです。過剰割り当て、アイドルVM、古いスナップショット、使われていないディスク、ピーク時だけ逼迫するクラスタを、次のアクションに変えるために使います。
GPUやAI基盤は利用率だけで説明しない
VCF 9.1では、AIやGPUの観測性にも関心が集まっています。ただし、AI基盤のコストをGPU利用率だけで説明すると危険です。モデルの種類、学習か推論か、KubernetesかVMか、データ転送、ストレージ、ネットワーク、ジョブ待ち時間、予約枠、運用担当者の作業まで含めて見る必要があります。
オンプレ本番運用のレビューでは、GPUを使っているかどうかより、どの業務がどの時間帯にどのリソースを占有し、その結果どの費用説明が必要になるかを確認します。もしAI検証基盤が本番基盤と同じ容量プールを使っているなら、ピーク時間帯の競合や将来増設の判断にも影響します。
契約・価格は本文で断定しない
VMware/Broadcomの価格やライセンス条件は、読者の関心が高い領域です。ただし、公開情報、契約形態、既存契約、パートナー経由の条件、地域、サポート範囲によって変わり得ます。この記事では価格を断定しません。
代わりに、導入企業が確認する項目を明確にします。どのエディションやサブスクリプションにVCF Operationsが含まれるのか、既存契約からの移行条件は何か、サポート対象バージョンはどこまでか、追加のAdvanced Servicesやネットワーク運用製品が必要か、契約期間と更新条件はどうなっているかです。
コスト可視化は、契約交渉の代替ではありません。社内で「どのリソースが本当に必要か」「どの運用改善で無駄が減るか」を説明するための土台です。その土台ができて初めて、価格や契約の話も現実的になります。
ライフサイクル運用をDay Nの定例作業に落とす
- 1対象
どのクラスタ、管理コンポーネント、ワークロードが影響を受けるかを確認します。
- 2順序
公式ドキュメントと自社手順で、更新や確認の順序が一致しているかを見ます。
- 3事前チェック
容量、互換性、証明書、バックアップ、権限、接続モードを変更前に確認します。
- 4変更時間
業務ピーク、バッチ、バックアップ、DR訓練と重ならない時間帯を選びます。
- 5戻し方
失敗時にどこまで戻せるか、判断者は誰か、証跡をどこに残すかを決めます。
証明書、パスワード、権限、古いコンポーネントは目立ちにくいものの、Day N運用では影響が大きくなります。
公式ブログがDay 2運用に触れている理由は、環境を作るより維持する方が長く続くからです。オンプレ本番基盤では、パッチ、アップグレード、証明書更新、パスワード更新、コンポーネント互換性、バックアップ、DR、監査対応が繰り返し発生します。
これらを個別作業として処理していると、運用チームはいつも後追いになります。VCF Operationsを導入前に評価するなら、単発の便利機能ではなく、Day Nの定例作業をどこまで標準化できるかを見ます。
パッチとアップグレードは「対象、順序、戻し方」を持つ
パッチやアップグレードのレビューでは、対象コンポーネント、適用順序、前提チェック、停止影響、戻し方、検証方法をそろえます。VCF 9.1への移行やExpress Patchのような作業では、SDDC Manager、vCenter、ESXi、NSX、vSAN、管理サービスの関係が重要になります。
運用レビューでは、次の質問を定例化します。
| 項目 | 確認する質問 |
|---|---|
| 対象 | どのクラスタ、どの管理コンポーネント、どのワークロードが影響を受けるか |
| 順序 | 公式ドキュメントと自社手順で順序が一致しているか |
| 事前チェック | 容量、互換性、証明書、バックアップ、権限を確認したか |
| 変更時間 | 業務ピーク、バッチ、バックアップ、DR訓練と重ならないか |
| 戻し方 | 失敗時にどこまで戻せるか、判断者は誰か |
| 記録 | 実施結果を次回の改善に使える形で残すか |
VCF Operationsの役割は、この表を全部自動で埋めることではありません。関連する状態を見えるようにし、次の変更作業のリスクを下げることです。
証明書、パスワード、権限は運用負債になりやすい
証明書やパスワードの更新は、トラブルが起きるまで軽く扱われがちです。しかし、オンプレ本番基盤では、期限切れや権限不足がアップグレード、監視、API連携、ログ収集、バックアップに影響します。
VCF Operations APIの概要では、REST APIが認証を必要とし、OpsTokenやBearer tokenが使われること、権限がない場合に401や403が返ることが説明されています。これは開発者向けの細部に見えますが、運用では重要です。APIで数字を取得する仕組みを作っても、トークン更新や権限設計が雑なら、監視やレポートが止まります。
定例作業では、証明書、パスワード、APIトークン、SSO連携、サービスアカウント、権限変更の履歴を確認します。誰が所有し、いつ更新し、失敗時に誰が判断するかを決めておくことが、運用効率の一部です。
古いコンポーネントを残す場合は診断範囲を明示する
VCF 9.1へ移行する途中、すべてのコンポーネントが同時に最新になるとは限りません。古いvSphere、NSX、管理コンポーネント、外部連携、バックアップ製品、監視製品が残る場合があります。
この状態でVCF Operationsを見るときは、診断できる範囲とできない範囲を明示します。アラートが出ないことは、問題がないことと同じではありません。ログが連携していない、対象バージョンが古い、認証に失敗している、監視対象から外れている、という理由で見えていない可能性があります。
Day Nの定例会では、Findingsやアラートの件数だけでなく、監視対象の欠落、古いコンポーネント、対応保留、例外承認も確認します。これを続けることで、VCF Operationsは障害後の説明ツールではなく、運用負債を減らす道具になります。
30日で始める運用レビュー手順
- 1週目
監視対象、重要業務VM、管理VM、クラスタ、VKS、タグ、所有者、レビュー参加者を決めます。
- 2週目
容量、性能、Top N、期間、除外条件、業務イベント、メンテナンス履歴を同じ粒度で残します。
- 3週目
コスト説明に使う所有者、利用目的、共有リソース、配賦ルール、例外環境をそろえます。
- 4週目
パッチ、アップグレード、証明書、バックアップ、DR、診断の定例表に落とし込みます。
初回の数値だけで結論を出さず、外れ値と継続傾向を分けて次のレビューにつなげます。
VCF Operationsを評価するなら、最初の30日で見る範囲を絞るのが現実的です。すべての機能を試すより、重要業務と管理基盤に絞って、同じ質問を毎週繰り返せるようにします。
ここでは、導入前またはPoC前のレビューとして、30日で始める手順を整理します。すでにVCF Operationsを使っている環境でも、棚卸しのやり直しに使えます。
1週目は対象と責任者を決める
最初の週は、対象範囲を決めます。全環境を一気に見るのではなく、本番クラスタ、管理クラスタ、重要業務VM、代表的なKubernetesクラスタ、バックアップ/DR関連のリソースに絞ります。
同時に、責任者を決めます。インフラ運用、アプリ担当、セキュリティ、財務、サービスオーナーの誰が、どの数字を判断するのかを明確にします。VCF Operationsのダッシュボードを見ても、判断者がいなければ、数字は増えるだけです。
1週目の成果物は、機能比較表ではありません。監視対象一覧、業務名、所有者、重要度、初回に見る指標、確認日、未確認のリスクです。
2週目は容量・性能・Top Nを固定する
2週目は、容量と性能の指標を固定します。CPU、メモリ、ストレージ、ネットワーク、待ち時間、アラート、Top Nのリソースを、業務単位で見ます。
APIを使う場合は、Resource ID、StatKey、期間、Rollup、Top Nの件数、groupBy、sortOrderを固定します。Broadcom DeveloperのAPIドキュメントでは、Stats取得やTop N取得の条件が説明されています。これを参考にしつつ、自社ではどの条件を定例化するかを決めます。
2週目で避けたいのは、取得できる数字を全部集めることです。最初は、業務影響を説明できる5から10個程度の指標に絞る方が、改善につながります。
3週目はコスト説明に使えるメタデータをそろえる
3週目は、コスト説明に使うメタデータをそろえます。タグ、所有者、部門、アプリケーション名、本番/検証/開発、除外ルール、共有基盤の配賦ルールを確認します。
この段階では、FinOpsの成熟度を高く見せる必要はありません。大事なのは、見えているリソースが誰のものかを説明できることです。所有者不明のVM、古いスナップショット、使われていないディスク、期限切れの検証環境があれば、まずそこを片付けます。
この作業は、契約や価格の議論にも役立ちます。実際に使っているもの、使っていないもの、増える見込みがあるものを分けられれば、購入や更新の会話が抽象論になりにくくなります。
4週目はDay Nの定例表に落とす
4週目は、レビューを定例表に落とします。月次で見る容量、週次で見るアラート、四半期で見るアップグレード計画、期限前に見る証明書/パスワード、変更前に見る事前チェックを決めます。
定例表には、数字だけでなく判断を書きます。「問題なし」ではなく、「次回ピークまでに追加容量の判断が必要」「証明書更新を次回メンテナンス前に実施」「古いNSXコンポーネントの診断範囲を再確認」「AI検証基盤のGPU予約ルールを変更」のように、次の行動に変えます。
30日の最後に確認するのは、VCF Operationsの全機能を使ったかではありません。運用チームが、同じデータを見て同じ会話を始められるようになったかです。
導入判断をどうまとめるか
- 1対象を絞る
本番処理、管理基盤、重要業務VMなど、最初に説明すべき対象を決めます。
- 2数字を選ぶ
容量、性能、コスト、ライフサイクル、診断のどの数字を社内判断に使うかを決めます。
- 3前提を分ける
契約、既存環境、移行計画、例外環境を分け、調査値と自社判断を混同しないようにします。
- 4改善アクションを持つ
増設、設定変更、タグ整備、手順化、診断対応など、次に動く項目へ変換します。
- 5VCF 9.1全体判断と分ける
VCF Operationsの評価と、VCF 9.1全体の導入・移行判断を別の議題として扱います。
VCF Operationsを使えば自動的に効率化できるのではなく、データの粒度と運用ルールがそろって初めて判断材料になります。
VCF Operationsの導入判断では、「機能が多い」「ダッシュボードがある」「APIがある」という説明だけでは不十分です。オンプレ本番運用に残る重要処理を、どの数字で守るかを説明する必要があります。
88.8%という調査値は、読者の関心を集める入口です。しかし、実務の結論は、自社の本番処理、運用チーム、契約、既存環境、移行計画によって変わります。ここを混同しないことが、この記事の最も大事な線引きです。
すぐ確認するなら5つに絞る
すぐに確認するなら、次の5つに絞ります。
- 本番業務、管理基盤、検証環境を分けた監視対象一覧があるか。
- 容量と性能を、平均値ではなくピークと業務時間帯で説明できるか。
- コスト可視化に必要なタグ、所有者、配賦ルールがそろっているか。
- パッチ、アップグレード、証明書、パスワード、権限の定例表があるか。
- APIやレポートの認証、権限、トークン更新、欠損値の扱いを決めているか。
この5つがそろっていない場合、VCF Operationsの機能を追加しても、運用会議の質はあまり変わりません。逆に、この5つがそろっていれば、画面、API、レポート、アラートの意味がはっきりします。
VCF 9.1全体の導入判断とは分ける
VCF Operationsのレビューは、VCF 9.1全体のアップグレード判断と重なりますが、同じではありません。VCF 9.1では、API-first、自動化、VKS、FinOps、Memory Tiering、Live Patching、Edge、Diagnosticsなど多くの論点があります。
今回の記事は、VCF Operationsを中心に、オンプレ本番運用の見える化を扱っています。VCF 9.1全体の導入前チェックは<a href="https://avgo-watch.blog.mo-gmo.com/avgo-13-vcf-91-upgrade-api-ip-check/">VCF 9.1を導入前に確認する</a>、月次の流れは<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>で追うと、情報が混ざりにくくなります。
読了後の控えめなCTA
Broadcom Watch Japanでは、Broadcomの公式発表、製品/サービス更新、噂確認、月次まとめの更新を継続的に追っています。VCF Operations、VCF 9.1、AIネットワーキング、Broadcomの公式発表をまとめて追いたい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>を控えめな更新通知として使ってください。
公式資料への戻り方や一次情報の確認方針は、<a href="https://avgo-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>にもまとめています。価格、契約、サポート条件のような変わりやすい情報は、記事だけで判断せず、必ず公式窓口と契約資料で確認してください。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, 88.8% of Production Transactions Run On-Premises. Are Your Private Cloud IT Operations Efficient?（2026年6月5日公開、2026年6月8日確認）
https://blogs.vmware.com/cloud-foundation/2026/06/05/88-8-of-production-transactions-run-on-premises-are-your-private-cloud-it-operations-efficient/
- VMware Cloud Foundation Operations product page（2026年6月8日確認）
https://www.vmware.com/products/cloud-infrastructure/vcf-operations
- Broadcom Developer, VMware Cloud Foundation Operations API 9.1（2026年6月8日確認）
https://developer.broadcom.com/xapis/vcf-operations-api/latest/
- Broadcom Developer, Get Stats Of Resources | VCF Operations API（2026年6月8日確認）
https://developer.broadcom.com/xapis/vcf-operations-api/latest/suite-api/api/resources/stats/get/
- Broadcom Developer, Get Top N Stats Of Resources | VCF Operations API（2026年6月8日確認）
https://developer.broadcom.com/xapis/vcf-operations-api/latest/suite-api/api/resources/stats/topn/get/
- VMware Cloud Foundation Blog, Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience（2026年5月5日公開、2026年6月8日確認）
https://blogs.vmware.com/cloud-foundation/2026/05/05/announcing-vcf-9-1-modern-private-cloud-built-for-efficiency-and-resilience/
更新履歴
- 2026年6月8日: 初版。2026年6月5日のVCF公式ブログ、VCF Operations製品ページ、Broadcom DeveloperのVCF Operations API 9.1を確認し、オンプレ本番運用の棚卸し観点で整理しました。