追記: 2026年6月7日の最新情報
2026年6月5日に公開されたVCF 5.2.xから9.1への公式アップグレードガイドを踏まえると、API-first自動化は「APIがあるからすぐ本番変更へ使う」ではなく、アップグレード順序、検証条件、パッチ適用方針を確認したうえで読み取り中心から始めるのが安全です。特に既存VCF 5.2.x環境から9.1へ移る場合は、API仕様だけでなく移行手順と運用制約も同じ設計メモに入れてください。
- 公式ガイドは、Aria/Operationsの移行、SDDC Manager、VCF Management Services、NSX、vCenter、ESXi、NSX Edgeを含む8ステップの流れで9.1移行を説明しています。
- 事前確認では、vCenter rootパスワードの条件、小文字FQDN、TLS暗号化syslogの1514番ポート、vCLSの扱いなど、API呼び出し前に環境側で詰まる要素を見ます。
- VCF 9.1.0.xのPatch Releasesはコンポーネント単位で扱われ、全VCFコンポーネントが同期して更新される前提ではありません。自動化対象のバージョン差分を確認してから実行します。
実装へ進む前に、VCF 5.2.xから9.1への移行順序と、VCF 9.1 Express Patch 01の確認点を合わせて見て、読み取りAPI、変更API、パッチ適用、ロールバック判断を分けてください。
3行まとめ
このテーマをもう少し広げて見るなら、VCF 5.2.xから9.1へ移行前に確認する：8ステップ順序、VCF Management Services、NSX経路の実務ポイント と VCF 9.1 Express Patch 01を適用前に確認する：9.1.0.0100、5.2.1経路、vSAN/SDDC Manager注意点 も合わせて確認してください。API-first自動化を本番運用へ入れる前に、9.1移行順序と環境側の検証条件を確認できます。
Developer PortalでVCF API Specification v9.1と対象コンポーネントを先に確認します。
Real-Time Metrics APIとvCenter Utilization APIを、監視と棚卸しの入口として小さく試します。
契約、サポート条件、認証、権限、対応範囲は自社環境と最新ドキュメントで確認します。
API-first自動化は、いきなり本番変更へ進めず、読み取り中心の確認から始めると判断しやすくなります。
- VCF 9.1のAPI-first自動化は、いきなり本番変更へ進むより、Developer PortalでAPI仕様、Real-Time Metrics API、vCenter Utilization APIの範囲を確認するところから始めるのが安全です。
- Real-Time Metrics APIはPrometheus互換とPromQL、vCenter Utilization APIは接続利用状況と上限確認、SDK/PowerCLI/Terraformは運用自動化の入口として役割が分かれます。
- 2026年6月3日JST時点の一次情報では、VCF 9.1のAPI仕様、認証、権限、対応コンポーネントを確認できますが、導入可否、契約、サポート条件は自社のBroadcom契約と最新ドキュメントで最終確認が必要です。
VMware Cloud Foundation 9.1を読む時、「AI向けプライベートクラウド」「Kubernetes」「統合運用」という大きな言葉に目が行きがちです。ただ、導入担当者や運用自動化を持つチームにとって、次に効いてくるのはAPIです。どの情報をAPIで読めるのか。どこまでPrometheus/Grafana系の監視へ渡せるのか。既存のPowerCLIやTerraform運用とどう重ねるのか。ここを曖昧にしたまま本番自動化へ進むと、監視APIと変更API、読み取り権限と変更権限、製品仕様と自社契約が混ざります。
Broadcom/VMware公式ブログは2026年5月25日、VCF 9.1のprogrammable infrastructureに関する記事を公開し、VCF 9.1をAPI-firstのプライベートクラウド基盤として説明しました。この記事では、同ブログ、Broadcom Developer PortalのVCF API Specification v9.1、Real-Time Metrics API、vSphere Automation APIのvCenter Utilization Connections、VCF 9.1公式発表を確認し、利用者が導入前に見るべき順番へ落とします。
直近のVCF 9.1関連記事では、VCF 9.1のAPI-first、アップグレード計画、管理サービスIPや、VCF PowerCLI 9.1のOAuth 2.0認証を扱いました。今回はその続きとして、API仕様と読み取り系の検証から、実務でどこを確認するかに絞ります。
Broadcom Watch JapanはBroadcom Inc.およびVMware by Broadcomとは非提携の独立した情報整理サイトです。この記事は投資助言、契約判断、公式サポート回答ではありません。導入、アップグレード、契約、サポート条件は、必ずBroadcomの公式資料、サポート窓口、自社契約で確認してください。
API-first自動化を導入前チェックに落とす
アップグレード後の運用負荷、権限範囲、日常手順の削減余地を確認します。
メトリック取得、アラート、基準値、失敗時の再試行を読み取りAPIで検証します。
OpenAPI、WSDL、SDK、PowerCLI、Terraformの役割を分けて入口を選びます。
誰がどのAPIへアクセスしたか、資格情報とトークンをどう管理するかを確認します。
監視系と変更系を同じ検証に混ぜないことで、権限や影響範囲を説明しやすくなります。
VCF 9.1のprogrammable infrastructureを実務で読む時、最初の問いは「APIがあるか」では足りません。管理者、SRE、プラットフォームエンジニア、開発者、監査担当では、APIに期待するものが違います。
管理者は、アップグレード後の運用負荷を下げられるかを見ます。SREや監視担当は、秒単位のメトリック、既存Grafana、アラート設計、ログ連携に関心があります。プラットフォームエンジニアは、SDKやOpenAPI仕様から自社ツールへ取り込めるかを見ます。PowerCLIを使ってきた運用チームは、既存スクリプトをどこまで9.1へ移せるかを気にします。Terraformを使うチームは、変更管理、レビュー、ドリフト検知の対象が広がるのかを確認したくなります。
導入前チェックは、次の順番にすると迷いにくくなります。
- 公式発表でVCF 9.1全体の位置づけを確認する。
- Developer PortalでAPI仕様の対象コンポーネントを確認する。
- 読み取り専用に近い監視APIから検証する。
- vCenter接続数や上限のように、運用しきい値へつながるAPIを確認する。
- SDK、PowerCLI、Terraformのどれを自社の標準自動化に寄せるか決める。
- 変更系APIや大きな自動化は、権限、監査、ロールバック、サポート境界を固めてから扱う。
VCF 9.1の公式発表は、本番AIワークロード向けの安全でコスト効率の高いインフラ基盤、AI/Kubernetes nativeなプライベートクラウド、AMD/Intel/NVIDIAを含む混在コンピュート対応を前面に出しています。これは重要な背景ですが、現場で最初に必要なのは大きな製品メッセージをそのまま信じることではなく、自社環境で確認できるAPI、権限、レスポンス、運用手順へ分解することです。
管理者と開発者で最初の問いを分ける
評価基準：APIで早くなる判断を先に決める
管理者が最初に見るべき問いは「このAPIを使うと、どの運用判断を早く、正確にできるか」です。たとえば、vCenterの接続利用状況を定期的に見られるなら、上限に近づく兆候、想定外の接続元、サービス単位の偏りを説明しやすくなります。
開発者や自動化担当が最初に見るべき問いは「仕様から安全にクライアントを作れるか」です。OpenAPI、WSDL、SDK、PowerCLI、Terraformは同じものではありません。仕様を見てコードを生成するのか、Broadcom提供のSDKを使うのか、PowerShell運用に寄せるのか、Terraformの宣言的管理に寄せるのかで、テストの書き方も障害時の戻し方も変わります。
監査やセキュリティ担当が見るべき問いは「認証、権限、トークン、操作ログを説明できるか」です。Real-Time Metrics APIのような読み取り系でも、認証は省略できません。vCenter Utilization Connections APIも、公式ドキュメントではSystem.Readが必要とされています。読み取りだから軽い、という見方は危険です。
この記事で扱う範囲を絞る
この記事では、VCF 9.1のAPI全体を網羅しません。対象は、一次情報で確認でき、導入前の小さな検証に落としやすいものに絞ります。
- VCF API Specification v9.1で対象コンポーネントと仕様形式を確認する。
- Real-Time Metrics APIでPrometheus互換、PromQL、認証手順を確認する。
- vCenter Utilization Connections APIで接続利用状況、
services、ports、権限、レスポンス項目を確認する。 - SDK、PowerCLI、Terraformを、導入順と責任範囲に分けて見る。
- 監視系と変更系を同じ検証に混ぜない。
一方で、この記事だけでは、契約上の利用可否、ライセンス、サポート範囲、アップグレードパス、個別環境の互換性までは断定しません。VCF 9.1 FAQにも、ライセンス、VCF Operations、Advanced Services、Lifecycle Managementなど、契約や構成に関わる項目が並んでいます。APIが存在することと、自社環境で使えることは別の話です。
Developer PortalでAPI仕様の居場所を確認する
OpenAPI、WSDL、SDK、PowerCLIは同じものではないため、仕様形式と利用目的を分けて読みます。
API-firstの話を始めるなら、まずBroadcom Developer PortalのVCF API Specification v9.1を見ます。ここには、VCFを構成する複数コンポーネントのAPI仕様が整理されています。
2026年6月3日JST時点で確認したVCF API Specification v9.1では、対象コンポーネントとして、vSphere、NSX、SDDC Manager、VCF Installer、VCF Operations、vSAN Data Protection、SDDC Lifecycle、Fleet Lifecycleが挙げられています。仕様形式はコンポーネントによって異なり、vSphereはWSDLとOpenAPI、ほかの多くはOpenAPIとして整理されています。
ここで確認したいのは、「VCF 9.1では全部が同じAPI体系になった」という雑な理解ではありません。むしろ、対象コンポーネントごとに仕様形式、認証、バージョン、生成できるクライアント、使うSDKが異なることを先に受け入れる必要があります。
VCF API Specification v9.1で対象コンポーネントを探す
Developer PortalのVCF API Specificationページでは、vcf-api-specs-9.1.0.0-25372366.zipがv9.1向けのダウンロードとして示されています。サイズは39.36 MB、MD5も掲載されています。API仕様を社内の自動生成やレビューに使うなら、まずこのファイル名、バージョン、確認日を残しておくべきです。
特に、latest URLを使う場合は注意が必要です。latestは便利ですが、将来の更新で中身が変わる可能性があります。記事や社内設計書では、URLだけでなく「2026年6月3日にv9.1として確認」「ファイル名はvcf-api-specs-9.1.0.0-25372366.zip」のように、時点情報を残す方が安全です。
確認項目：仕様版と利用条件を表に残す
API仕様を確認する時は、次の列を作ると判断が早くなります。
| 確認項目 | 見る場所 | 実務上の意味 |
|---|---|---|
| 対象コンポーネント | VCF API Specification | 自動化対象をどこまで広げるかを決める |
| 仕様形式 | OpenAPI/WSDL | 生成ツール、レビュー方法、SDK選定が変わる |
| バージョン | v9.1/latest表記 | 将来の差分確認に使う |
| ダウンロード名 | vcf-api-specs-9.1.0.0-25372366.zip | 社内保管や生成ログに残す |
| ライセンス条件 | SDK License Agreement | 利用前に法務/契約確認へ回す |
この表は地味ですが、API-first導入ではよく効きます。自動化の失敗は、コードのバグだけで起きるものではありません。見ている仕様の版、生成したクライアントの版、実環境の製品版、契約上の利用条件がずれた時にも起きます。
OpenAPI、WSDL、SDK、PowerCLIを混同しない
OpenAPIやWSDLは仕様です。SDKは、その仕様や製品APIを使いやすくするためのライブラリです。PowerCLIはPowerShellベースの運用自動化ツールです。Terraformは宣言的な構成管理に向いたツールです。名前が並ぶと「どれも自動化」とまとめたくなりますが、導入判断では分けて扱う必要があります。
たとえば、OpenAPI仕様から社内標準言語のクライアントを生成する場合、型、例外処理、再試行、認証更新、互換性テストを自社で持つことになります。Broadcom提供のUnified SDKを使う場合は、提供側の更新に合わせて依存関係を管理します。PowerCLIを使う場合は、既存の運用スクリプト、認証方式、実行端末、資格情報管理を見直します。Terraformを使う場合は、状態ファイル、レビュー、適用権限、ドリフト検知、ロールバック方針が論点になります。
VCF 9.1のprogrammable infrastructureは、こうした複数の入口を用意していると読むのが実務的です。ひとつの正解を選ぶというより、読み取り監視、運用スクリプト、構成変更、開発者向けSDKの境界を分けることが大切です。
Real-Time Metrics APIを監視連携の入口として見る
- 1対象を絞る
2秒粒度が本当に必要な対象と、取得したい最小メトリックを決めます。
- 2PromQLを試す
既存ダッシュボードに合うメトリック名、ラベル、クエリを確認します。
- 3認証を分解する
JWT Bearer token、トークン保管、有効期限、失敗時の通知を確認します。
- 4連携先を選ぶ
Grafanaから直接見るのか、既存Prometheusへ取り込むのかを分けます。
- 5監査を残す
誰がどのメトリックへアクセスしたかを説明できる状態にします。
Prometheus互換は導入完了を意味しないため、認証、証明書、権限、ラベル設計を別々に確認します。
Real-Time Metrics APIは、VCF 9.1のAPI-first自動化を試すうえで扱いやすい入口です。公式ブログでは、Prometheus互換のEdge APIsとして紹介され、ESX、vCenter、vSAN、NSXを含む統合SDDCプラットフォームに対して、高粒度のリアルタイムメトリックを問い合わせられると説明されています。粒度は最大で2秒までとされています。
Broadcom Developer PortalのReal-Time Metrics APIページでは、このコンポーネントがVMware vCenter環境から収集されたリアルタイムメトリックを問い合わせるPrometheus互換APIを提供し、PromQLクエリの実行、メトリックメタデータ取得、vCenterメトリック設定管理を可能にすると説明されています。
Prometheus互換とPromQLを確認する
Prometheus互換という言葉は便利ですが、導入前には少し分解した方がよいです。確認すべきなのは、PromQLをそのまま利用できるか、メトリック名とラベル設計が既存ダッシュボードに合うか、Grafanaのデータソースとして扱う時に認証や証明書をどう管理するか、既存のPrometheusサーバーへ取り込むのか、Grafanaから直接見るのか、といった点です。
公式ブログは、Real-Time Metrics APIがGrafanaの直接データソースとして機能し、Essentials、Standard、Verboseという組み込みcollection profilesを使うことで設定を単純化できると説明しています。これは、既存のvStats APIや個別スクリプトをすべて即時置き換えるという意味ではなく、まず小さく検証できる候補が増えたと読む方が安全です。
注意点：Prometheus互換を導入完了と見なさない
導入前の確認表では、次のように分けると見落としが減ります。
| 確認項目 | 先に決めること |
|---|---|
| メトリック粒度 | 2秒粒度が本当に必要な対象だけに絞る |
| クエリ | PromQLで取得したい最小クエリを3つ作る |
| ダッシュボード | 既存Grafanaへ直結するか、別検証環境で見るか |
| 認証 | トークン取得と更新を誰が管理するか |
| 負荷 | 高頻度取得を全対象へ広げず、対象コンポーネントを限定する |
| 運用 | アラート化する前に、通常時の基準値を採取する |
認証はJWT Bearer tokenまで分解する
Real-Time Metrics APIの認証は、単に「トークンが必要」と書くだけでは不十分です。Developer Portalの説明では、APIリクエストにはAuthorizationヘッダーの有効なJWT Bearer tokenが必要で、認証ユーザーが参照または変更を許可されたリソースにアクセスが制限されるとされています。
ドキュメント上の流れは、まずVCF Operationsの認証APIでOpsTokenを取得し、integrations APIからReal-Time Metrics Service Keyを取得し、そのService Keyを使ってJWT Tokenへ交換する、という段階になっています。これを運用手順に落とす時は、最低でも次を決める必要があります。
- トークン取得に使うアカウントのロールと権限。
- トークンを保存する場所と有効期限管理。
- CI/CDや監視基盤から取得する場合の秘密情報管理。
- トークン交換に失敗した時のアラート。
- 監査ログ上、誰がどのメトリックへアクセスしたかを説明できるか。
ここまで分けると、Real-Time Metrics APIは「監視が楽になるAPI」ではなく、「監視を自動化するために認証と権限を設計するAPI」として見えてきます。VCF 9.1導入前の検証では、最初から本番Grafanaへつなぐより、検証環境でトークン取得、PromQL、メタデータ取得、collection profile変更の影響を小さく確かめる方が現実的です。
vCenter Utilization APIで接続利用状況を棚卸しする
アラームしきい値は推測で決めず、通常時の接続状況を採取してから設計します。
vCenter Utilization APIは、監視と容量計画の間にあるようなAPIです。公式ブログでは、vCenterの容量と利用状況メトリックをリアルタイムに監視し、許容上限に対するアクティブ接続数、接続エンドポイント、サービスリクエスト量を追跡すると説明されています。しきい値超過を知らせるUIアラームも追加され、Advanced Settingsで設定できるとされています。
Developer PortalのvSphere Automation APIページで確認できるVcenter Utilization Connections listは、vCenter Serverプロセスの接続利用状況を一覧化するAPIです。エンドポイントはGET https://{host}/api/vcenter/utilization/connectionsで、vSphere API 9.1.0.0で追加された操作とされています。実行にはSystem.Read権限が必要です。
接続利用状況APIで何を見るか
このAPIで見るのは、vCenterが「重いかどうか」の結論ではありません。レスポンスには、サービス、ポート、開いている接続、peerのアドレスやポート、TCP state、サービス単位のtotal_connections、connection_limitなどが含まれます。つまり、接続利用状況を説明するための材料です。
根拠：接続数と上限をレスポンスで確認する
導入前に見るべき問いは次の通りです。
- どのvCenterサービスに接続が集中しているか。
total_connectionsとconnection_limitの差分を定期的に見られるか。- 接続元のpeer情報が、想定した監視基盤、バックアップ、運用端末、連携製品と一致するか。
- 異常時だけでなく通常時の基準値を採取できるか。
- アラームしきい値を、思い込みではなく実測値から決められるか。
このAPIは、VCF 9.1の派手な新機能というより、運用現場にとって説明しやすいAPIです。障害が起きた後に「vCenterが混んでいたらしい」と言うだけでなく、どのサービスにどれだけ接続があり、上限に対してどこまで来ていたかを残せます。
servicesとportsで絞り込みを確認する
Vcenter Utilization Connections listでは、任意のquery parametersとしてservicesとportsが用意されています。servicesは対象サービスの絞り込み、portsはポート番号の絞り込みに使います。どちらも指定しない、null、空の場合は絞り込みなしになると説明されています。
この絞り込みは、検証段階で重要です。最初からすべてを監視対象にすると、ダッシュボードは作れても、何を判断するのかが曖昧になります。まずは、代表的なvCenterサービスとポートに絞り、通常時、バックアップ時、メンテナンス時、障害対応時の差を見ます。その後に対象を広げる方が、アラートの誤検知を減らせます。
また、unknown_criteriaがレスポンスに含まれる可能性にも注意が必要です。指定したサービスやポートが既知のプロパティに一致しない場合、どの条件が一致しなかったかを返すためです。これは検証では便利ですが、本番監視では「指定ミスに気づかず空振りする」リスクにもなります。監視ジョブでは、レスポンスが空かどうかだけでなく、未知条件が返っていないかも確認した方がよいでしょう。
アラーム設計には基準値の採取を挟む
接続数APIを見つけると、すぐアラートを作りたくなります。しかし、最初に必要なのは基準値です。平常時の接続数、業務ピーク時、バックアップ時、パッチ適用時、障害対応時で値は変わります。VCF 9.1のAPIを導入するなら、少なくとも数日から数週間、読み取り専用で採取し、どのタイミングで自然に増えるのかを見た方が安全です。
アラート設計では、connection_limitに対する割合、増加速度、特定サービスへの偏り、想定外peerの出現を分けます。単純な上限比率だけにすると、正常なメンテナンス作業で鳴り続けるかもしれません。逆に、上限に近づく前でも、想定外の接続元が急増するなら別の調査が必要です。
SDK、PowerCLI、Terraformを導入順に並べる
読み取り系APIで足場を固めてから、SDK、PowerCLI、Terraformの順に影響範囲を広げると整理しやすくなります。
VCF 9.1のprogrammable infrastructure記事は、APIだけでなく、Unified SDK、PowerCLI 9.1、vSphere Terraform Providerにも触れています。ここを一つの「自動化強化」として読むと、導入順を間違えやすくなります。
導入順としては、読み取り系API、SDKでのプロトタイプ、PowerCLIでの既存運用見直し、Terraformでの変更管理に分けると扱いやすくなります。自社の標準ツールによって順番は変わりますが、監視系と変更系を混ぜない、という原則は変わりません。
Unified SDKは開発者向け入口として見る
公式ブログは、VCF 9.0でOpenAPI仕様、Python/Java向けUnified VCF SDK、Terraform provider、PowerCLI SDKの改善が導入され、VCF 9.1ではUnified SDKとOpenAPI Specificationの対象範囲がさらに広がると説明しています。VCF 9.1でSDK coverageが広がった対象として、NSX、VCF Operations、Log Management、VCF Operations for Network、Fleet Lifecycle、SDDC Lifecycle Managementが挙げられています。
開発者向けには、これは大きな前進です。複数コンポーネントのクライアントや依存関係を別々に持つ負担が減る可能性があります。ただし、SDKを使う場合でも、どのAPIがどの権限を必要とし、どの操作が読み取りで、どの操作が変更を伴うかは別途確認が必要です。
確認項目：SDKを入れる前に運用責任を決める
社内ツールにSDKを入れるなら、最初の検証は小さくします。
- API仕様とSDKのバージョンを記録する。
- 読み取り専用APIで認証、例外処理、タイムアウト、再試行を確認する。
- エラー時に資格情報やトークンをログへ出さない。
- 生成コードやSDK依存を、社内の脆弱性管理に載せる。
- 製品アップグレード時にSDK更新を誰が追うか決める。
SDKは便利ですが、運用責任を消すものではありません。むしろ、社内ツールに組み込むほど、更新、テスト、権限、監査の責任ははっきりします。
PowerCLI 9.1は運用スクリプトと認証の確認に寄せる
PowerCLI 9.1は、既存のVMware運用チームにとって自然な入口です。公式ブログでは、CPU Topology Management、NVMe over TCP、vSAN関連cmdlet、VPC Networking、OAuth/Token系の認証強化などが紹介されています。
特に認証まわりは重要です。公式ブログでは、VMware.Vcf.SsoモジュールのNew-VcfOAuthSecurityContextにより、Connect-VIServer、Connect-NsxServer、Connect-VcfOpsServerへVcfOAuthSecurityContextまたは直接VcfApiTokenを渡せると説明されています。この点は、VCF PowerCLI 9.1のOAuth 2.0認証の記事で詳しく整理しました。
PowerCLIを導入前に見るべきなのは、新cmdletの数ではなく、既存スクリプトの前提です。
- どのスクリプトがユーザー名/パスワード前提か。
- どのスクリプトがvCenterだけを見ており、NSXやVCF Operationsと分かれているか。
- CI/CDから実行する時、トークンとロールをどう分けるか。
- PowerCLI更新で既存cmdletの挙動が変わらないか。
- 変更系スクリプトに事前確認、dry-run相当、承認フローを置けるか。
OAuthやAPI tokenを使えることは、セキュリティが自動的に良くなることを意味しません。長期トークンを雑に共有すれば、むしろリスクは増えます。PowerCLI 9.1は、認証方式を近代化する機会として扱うのがよいです。
Terraformは変更管理とドリフト管理の文脈に置く
公式ブログは、vSphere Terraform ProviderがVMware Terraform registryに組み込まれ、GitHub上のオープンソースプロジェクトは継続しつつ、Broadcom Global Support Services経由のサポートリクエストも可能になると説明しています。また、vSphere Terraform Provider v2.16.0がリリースされ、ネットワーク統合、VMカスタマイズ、クラスタスケーラビリティに焦点を当てているとしています。
Terraformは、APIやPowerCLIとは違う緊張感があります。状態ファイルを持ち、差分をレビューし、適用すると構成が変わります。便利な一方で、手動変更、緊急対応、GUI操作、別ツールでの変更と競合しやすい領域です。
導入前には、次を決めてから小さく始めるべきです。
- Terraform管理対象に入れるリソースと入れないリソース。
- 既存環境をimportする範囲。
- stateの保存場所、暗号化、アクセス権限。
planレビューの責任者。- 手動変更を検出した時の扱い。
- 緊急時にTerraform外で変更した後の復帰手順。
VCF 9.1のAPI-firstは、Terraformで何でも管理する合図ではありません。むしろ、宣言的に管理したい領域と、監視や一時操作に留める領域を分ける必要があります。
導入前の小さな検証シナリオを作る
- 1対象を1つに絞る
Real-Time Metrics APIかvCenter Utilization APIのどちらか一方から始めます。
- 2読み取りだけ試す
認証、権限、タイムアウト、レスポンス項目を読み取りAPIで確認します。
- 3限定ロールを使う
検証用アカウントの権限を最小限にし、資格情報の保管場所を決めます。
- 4基準値を採る
通常時のメトリックや接続利用状況を短い期間で記録します。
- 5判断を残す
本番利用に進める条件、保留する条件、追跡する公式情報を残します。
便利そうなAPIを全部つなぐ前に、小さな検証で認証、権限、監査を説明できる状態にします。
API-first自動化の導入で一番避けたいのは、「便利そうなAPIを全部つないだ検証」です。最初の検証は小さく、読み取り中心にし、失敗しても本番変更が起きない形にします。
検証条件：失敗しても本番変更が起きない形にする
おすすめの最初のシナリオは、次のような流れです。
- Developer PortalでVCF API Specification v9.1の対象コンポーネントと仕様版を記録する。
- Real-Time Metrics APIの認証手順を検証環境で確認する。
- PromQLで最小のメトリックを取得し、レスポンス時間、トークン処理、エラー時の挙動を見る。
- vCenter Utilization Connections APIを
System.Read権限で実行し、total_connectionsとconnection_limitを取得する。 servicesまたはportsで絞り込み、unknown criteriaが出ないかを見る。- PowerCLI 9.1の認証方式を、既存スクリプトとは別の検証スクリプトで確認する。
- Terraformは読み取りや小さな非本番リソースから始め、state管理とレビュー手順を先に固める。
この程度でも、導入前にかなりのことが分かります。トークン取得が複雑か、権限設計が足りないか、既存監視とメトリック名が合わないか、vCenter接続の通常値を取れていないか、PowerCLIの認証移行で詰まるか。小さな検証は、導入判断の解像度を上げてくれます。
最初は読み取り専用APIで始める
読み取り専用に近いAPIから始める理由は、失敗時の影響を抑えるためです。Real-Time Metrics APIやvCenter Utilization Connections APIでも、認証、権限、負荷、ログ、証明書、ネットワーク経路は確認できます。ここでつまずくなら、変更系APIへ進む前に直すべきです。
読み取りAPIの検証では、正常系だけでなく失敗系も見ます。認証情報が間違っている時、トークンが期限切れの時、権限が足りない時、対象サービス名が間違っている時、APIホストへ到達できない時、証明書検証に失敗した時。これらを試しておくと、本番監視へ組み込んだ後の障害対応がかなり楽になります。
監視系と変更系を同じ検証に混ぜない
監視系APIと変更系APIを同じ検証に混ぜると、レビューが難しくなります。監視系は「どの値をどの頻度で読み、どのしきい値で通知するか」が中心です。変更系は「誰が、何を、どの承認で変更し、どう戻すか」が中心です。必要な関係者も、失敗時の影響も違います。
たとえば、Real-Time Metrics APIのGrafana連携と、TerraformによるVPC関連設定変更を同じPoCに入れると、成功しても何が効いたのか分かりにくくなります。まず監視を小さく入れ、基準値を取り、次に変更管理を別テーマで扱う。地味ですが、この分け方が後で効きます。
既存環境の境界条件を先に洗う
VCF 9.1のAPI-firstを導入する前に、既存環境の境界条件も確認します。閉域網か、外部Grafanaへ出せるか、プロキシが必要か、証明書は社内CAか、監視基盤からVCF Operationsへ到達できるか、vCenterのAPI接続数に既存ツールがどれだけ乗っているか。APIの仕様だけを見ても、こうした環境条件は分かりません。
VCF Operationsで管理VMのリソース割り当てを確認する記事で扱ったように、管理VMのvCPU、メモリ、ディスク、サイト、管理ドメインの棚卸しも、API検証の前提になります。自動化は、現状を見えるようにした後の方がうまくいきます。
まだ断定しない点と次に追う公式情報
利用できる機能、Advanced Services、サポート条件を自社契約で確認します。
既存環境からの移行可否と手順は、Release NotesやFAQで再確認します。
Real-Time Metrics APIをどの対象に、どの間隔で使うかを本番前に決めます。
vCenter接続利用状況のアラーム基準は、実測値を見てから設定します。
IaCに含めるリソースと、手動運用に残す範囲を分けます。
機能の有無と導入可否は同じではないため、契約、サポート、既存環境の条件を最後に照合します。
2026年6月3日JST時点の一次情報で確認できるのは、VCF 9.1のAPI-first強化、Developer Portal上のAPI仕様、Real-Time Metrics API、vCenter Utilization Connections API、PowerCLI/Terraform関連の方向性です。一方で、次の点はこの記事だけで断定しません。
- 自社契約でどのVCF 9.1機能、Advanced Services、サポートが利用できるか。
- 既存VCF/VVF/vSphere環境からのアップグレード可否と順序。
- 本番環境でReal-Time Metrics APIをどの頻度、どの対象範囲で使うべきか。
- vCenter接続利用状況の安全なしきい値。
- Terraform管理対象へどのリソースを入れるべきか。
- PowerCLI認証移行で、既存スクリプトをどこまで修正すべきか。
次に見るべき公式情報は、VCF 9.1 Release Notes、VCF 9.1 FAQ、Developer PortalのAPI ChangeLog、PowerCLI ChangeLog、vSphere Terraform ProviderのChangeLog、Broadcom Knowledge Baseです。API仕様やlatest URLは更新される可能性があるため、導入判断では確認日と版を必ず残してください。
まとめ：VCF 9.1のAPI-firstは、小さな読み取り検証から始める
- 1仕様を探す
Developer Portalで対象コンポーネント、API仕様、バージョンを確認します。
- 2読み取りで試す
メトリック、接続利用状況、認証、権限を小さな検証で確認します。
- 3運用へ落とす
アラート、基準値、監査ログ、資格情報管理を運用ルールに入れます。
- 4変更系を分ける
SDK、PowerCLI、Terraformで扱う変更範囲を段階的に広げます。
VCF 9.1のAPI-firstは、開発者向けの強化であると同時に、運用担当者が監視と変更管理を見直す入口になります。
VCF 9.1のAPI-first自動化は、単なる開発者向け強化ではありません。運用担当者にとっては、メトリック、接続利用状況、アラーム、基準値、認証、監査を見直すきっかけです。開発者にとっては、OpenAPI、WSDL、SDK、PowerCLI、Terraformの入口を整理する機会です。
最初にやることは、大きな自動化ではありません。Developer PortalでVCF API Specification v9.1を確認し、Real-Time Metrics APIを小さく試し、vCenter Utilization Connections APIで通常値を取り、PowerCLIとTerraformを既存運用にどう入れるかを分けることです。
VCF 9.1の価値は、APIが増えたことだけでは測れません。APIを使って、誰が、どの判断を、どの証拠で、どの権限で行うかを説明できるようになることが重要です。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog「Unlocking the Full Potential of Programmable Infrastructure with VMware Cloud Foundation 9.1 – New Features and Capabilities」（2026年5月25日公開、2026年6月3日参照）
https://blogs.vmware.com/cloud-foundation/2026/05/25/unlocking-the-full-potential-of-programmable-infrastructure-with-vmware-cloud-foundation-9-1-new-features-and-capabilities/
- Broadcom Developer Portal「VCF API Specification」（v9.1/latest、2026年6月3日参照）
https://developer.broadcom.com/sdks/vcf-api-specification/latest
- Broadcom Developer Portal「Real-Time Metrics APIs」（2026年6月3日参照）
https://developer.broadcom.com/xapis/realtime-metrics-api/latest/
- Broadcom Developer Portal「Vcenter Utilization Connections list | vSphere Automation API 9.1」（2026年6月3日参照）
https://developer.broadcom.com/xapis/vsphere-automation-api/9.1/api/vcenter/utilization/connections/get/
- Broadcom News & Stories「Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI」（2026年5月5日公開、2026年6月3日参照）
https://news.broadcom.com/emea/releases/broadcom-announces-vmware-cloud-foundation-9-1
- VMware「VCF 9.1 Frequently Asked Questions」（May 28, 2026版、2026年6月3日参照）
https://www.vmware.com/docs/vmware-cloud-foundation-9-1-general-faqs