Broadcomが2026年6月11日に公開したVMware Cloud Foundation Blogは、VCFでInfrastructure as Codeを扱う具体例として、TerraformからSDDC Manager APIを呼び出す流れを紹介している。この記事で重要なのは、「Terraform対応」という一語ではなく、VCF 9.1のどのAPI面を、どの権限で、どこまで自動化するのかを先に分けることだ。
VCF 9.1では、SDDC Manager、VCF Automation、VCF Operations、PowerCLI、Developer PortalのAPIリファレンスなど、確認すべき入口が増えている。便利になった一方で、読み取りだけの棚卸し、Day 2変更、CatalogからのDeployment、組織/プロジェクトのガードレールを一つのIaCコードに押し込むと、失敗時の責任範囲が見えにくくなる。
Broadcom Watch JapanはBroadcomおよびVMware by Broadcomと非提携の独立メディアであり、本記事は導入判断の確認観点を整理するものだ。投資助言、購入推奨、公式サポート手順の代替ではない。確認日は2026年6月12日JST。
3行まとめ
このテーマをもう少し広げて見るなら、VCF 9.1 Infrastructure Placement Policiesを導入前に確認する：必須/任意ポリシー、Region Quota、vSphere Compute Policyの実務ポイント と VCF 9.xでDell PowerFlexを使う前に確認する：SDC、NVMe/TCP、グリーンフィールド制約の実務ポイント も合わせて確認してください。SDDC Manager APIやTerraformで自動化する前に、配置ポリシーとクォータでどこを止めるかを合わせて確認できます。
最初のPoCは、SDDC Manager APIの到達性、権限、レスポンスを確認する読み取り用途に限定する。
plan、レビュー、変更履歴を生かしつつ、runtime remediationや緊急判断まで単独で抱え込ませない。
organization、project、role、quota、policyを決めてから、APIやTerraformの利用範囲を決める。
ツール名より先に、対象API、権限、承認、停止条件を決めることが導入リスクを下げる。
- VCF 9.1でIaCを始めるなら、最初のPoCは書き込み自動化ではなく、SDDC Manager APIの読み取り確認から始めたい。
- Terraformは差分確認や変更承認を見える化する道具として有効だが、runtime remediationやホスト追加判断まで単独で抱え込ませるのは危うい。
- VCF Automationの組織、プロジェクト、ロール、クォータ、ポリシーを決めずにAPIだけを触ると、あとから運用ガードレールを足すことになる。
VCF 9.1のIaC需要を「Terraform対応」ではなくAPI境界で読む
Terraform、Ansible、bash、Python、PowerCLIよりも、標準化されたREST API endpointへの需要シグナルとして見る。
VCF domain、cluster、host、taskなど、管理対象の現在状態を外部ツールから確認する入口になる。
organization、project、Blueprint、Catalog、Deployment、Policyを扱うセルフサービス側の境界を確認する。
TerraformやPowerCLIはAPIを呼ぶ手段であり、どの変更まで許すかは権限と運用設計で決める。
VCF Fleet、SDDC Manager、VCF Automationを一つの操作面として混ぜず、対象と権限を分けて読む。
2026年6月11日の公式ブログ「Modern Automation with VMware Cloud Foundation Part 2: Modern Infrastructure as Code with VCF」は、直近72時間のVCF公式フィードの中でも、導入企業の運用設計に直結する記事だった。同じ日のフィードにはPrivate AI ServicesやInfrastructure Placement Policiesの話題も並んでいるが、今回の焦点はAI機能や配置ポリシーそのものではなく、VCFを外部ツールからどう扱うかにある。
公式ブログは、Terraform、Ansible、bash、Python、PowerCLIといったツール選択よりも、VCFが標準化されたREST API endpointを提供する点を前に出している。ここを読み落とすと、「TerraformでVCFを全部管理できるか」という雑な問いになりやすい。実務では、Terraformを使うかどうかより、どのAPIを呼び、どの権限で、どの変更まで許すかが先に決まる。
公式ブログはIaCの需要シグナルとして読む
公式ブログの例では、Terraformを使ってSDDC Manager APIに問い合わせ、VCF domainの容量情報を見て、メモリ容量が一定の条件を下回るかを確認する流れが示されている。ここでの読みどころは、Terraformそのものの構文ではない。VCFの管理面がAPI経由で扱えるため、既存のクラウドネイティブな運用ツールからVCFを確認できる、という点だ。
根拠
Broadcom/VMwareの公式ブログは、VCF 9.1におけるAPI endpoint、VCF Fleet、統一されたポリシーとガードレール、SDDC Manager APIへのアクセス例を説明している。Developer PortalにもSDDC Manager API 9.1のリファレンスが公開されており、確認日は2026年6月12日だ。
注意点
公式ブログ自身も、Terraformがruntime remediationに常に最適とは限らない、という趣旨の注意を入れている。容量が少ないから自動でホストを足す、という読み方をすると危ない。実運用では、監視、承認、メンテナンス時間、非同期タスク、失敗時の戻し方まで含めて設計する必要がある。
VCF Fleet、SDDC Manager、VCF Automationを一つに混ぜない
VCF 9.1の自動化で最初に分けたいのは、操作対象だ。SDDC Manager APIはインフラ管理面の棚卸しやDay 2操作に近い。一方、VCF Automation APIは、組織、プロジェクト、Blueprint、Catalog、Deployment、Policy、Requestなど、利用者向けセルフサービスの管理面に寄る。
| 見る対象 | 主な入口 | 最初に確認すること |
|---|---|---|
| VCF Fleet/SDDC Manager | SDDC Manager API、VCF API、ローカルSwagger | domain、cluster、host、task、credential、認証権限 |
| VCF Automation | Blueprint API、Deployment API、Organization Management | organization、project、role、quota、catalog、policy |
| 運用スクリプト | PowerCLI、SDK、Python、Ansible、Terraform | 変更履歴、secret管理、実行場所、監査ログ |
評価基準
「どのツールを使うか」だけで会話している場合は、まだ設計が粗い。最初に決めるべきなのは、対象API、操作の種類、実行者、承認者、失敗時に見るログだ。ここが決まっていれば、Terraform、PowerCLI、Pythonのどれを使っても運用設計は崩れにくい。
既存のVCF 9.1記事との棲み分け
Private AI ServicesのSupervisor設計は、すでにVCF 9.1 Private AI Servicesの記事で扱った。VPC Network Spanは配置制御の記事で整理している。この記事ではそれらの機能詳細には踏み込まず、IaCから触る前のAPI境界と運用責任に絞る。
条件
IaCの記事として読む価値があるのは、VCF 9.1の新機能を全部なぞる時ではない。Platform Engineeringチームが、既存のCI/CD、Git、レビュー、承認、監査の流れにVCFをどう載せるかを考える時だ。
SDDC Manager APIは読み取り専用の棚卸しから始める
- 1Inventory
domain、cluster、hostの最小情報を取得し、API到達性とレスポンス形式を確認する。
- 2Capacity
容量情報を読み取り、stateやログに残してよい値と残してはいけない値を分ける。
- 3Task
task ID、完了判定、エラー時の再試行や調査方法を読み取り段階で確認する。
- 4Change
変更APIに進む前に、対象domainやcluster、影響範囲、失敗時の扱いを明記する。
- 5Approval
運用チケット、承認者、メンテナンス時間、変更後確認をAPI実行と結びつける。
読み取りAPIでも、ホスト名、IP、capacity、credential関連の情報をstateやCIログに残さない設計が必要になる。
最初のPoCは、変更を起こさない読み取りAPIに限定したほうがよい。SDDC Manager APIの到達性、認証、権限、レスポンス形式、エラー時の扱いを確認するだけでも、IaC化に向く部分と、まだ人間の判断を残すべき部分が見えてくる。
読み取りの棚卸しであれば、Terraformのexternal data、Python、PowerCLI、Ansibleのいずれでも始められる。重要なのは、取得した値をその場の判断に使うのか、stateに残すのか、監視基盤へ渡すのかを分けることだ。
最初に見るのはDomains、Clusters、Hosts、Tasks
Developer PortalのSDDC Manager API 9.1には、SDDC Managerの管理対象を扱うAPI群が並ぶ。PoCの入口としては、domain、cluster、host、taskのような、現在状態を読む領域が扱いやすい。書き込みを含む操作に進む前に、読み取りだけで権限とレスポンスの安定性を確認したい。
確認項目
| 項目 | 確認する理由 | 最初の扱い |
|---|---|---|
| API endpoint | CI/CD runnerや運用端末から到達できるかを見る | 手元と自動実行環境で分ける |
| 認証方式 | tokenやSSOの権限範囲を確認する | 最小権限のサービスアカウントを検討する |
| domain/cluster/host | 対象範囲を誤らないようにする | 読み取り専用でIDと名前を照合する |
| task | 変更APIへ進む前に非同期処理の見方を確認する | 完了判定と失敗時ログを決める |
| audit/log | 実行者と操作内容を追えるかを見る | PoC段階で保存先を決める |
注意点
読み取りAPIでも、取得した値の扱いを誤ると運用情報が漏れる。domain名、ホスト名、IP、capacity情報、credential関連のレスポンスは、Terraform state、CIログ、チャット通知へそのまま残さない設計が必要だ。
Terraformのexternal dataは便利だが、state管理とは分けて考える
公式ブログの例は、Terraformから外部スクリプトやAPI呼び出しを使ってVCF状態を読む発想を示している。これはPoCとしては分かりやすい。ただし、Terraform stateは差分管理のための記録であり、あらゆるAPIレスポンスを保管する場所ではない。
下振れ
APIレスポンスの形式が変わる、認証tokenの期限が切れる、権限不足で一部項目が返らない、ネットワーク遅延でplanが失敗する。こうした失敗は、実インフラが壊れていなくてもIaCの実行を止める。Terraformで外部データを読むなら、失敗時に「変更しない」で止める条件を明文化しておきたい。
評価基準
PoCの成功条件は、単にplanが通ることではない。読み取り対象、レスポンスの最小項目、エラー時の終了コード、ログのマスク、stateに残る値、再実行条件まで確認できて初めて、次の段階へ進める。
書き込みAPIは非同期タスクと承認フローまで含めて検証する
Day 2操作や構成変更に進むと、API呼び出しは単発の成功/失敗では終わらない。タスクID、進捗、完了判定、部分失敗、手動復旧、変更承認、メンテナンス時間帯が関わる。Terraformでapplyが成功したように見えても、VCF側のタスクが失敗していれば運用上は未完了だ。
条件
書き込みAPIへ進む前に、少なくとも次の三段階を分ける。
| 段階 | 目的 | 止める条件 |
|---|---|---|
| 読み取りPoC | 到達性、認証、対象ID、レスポンス確認 | stateやログに機微情報が残る |
| ステージング変更 | 非同期タスク、失敗時ログ、再実行条件確認 | task完了判定が曖昧 |
| 本番変更 | 承認、メンテナンス時間、戻し手順、監査確認 | 手動復旧手順がない |
Terraformに任せる範囲と任せない範囲を決める
Terraformの成功を、VCF側のtask完了、Request承認、監査ログ確認まで含む運用完了と同じ意味で扱わない。
Terraformは、差分をレビューし、変更の意図をコードとして残すための道具として強い。一方で、状況に応じて判断が変わる運用復旧、容量不足時の緊急対応、部分失敗後の調整まで、すべてをTerraformに任せると複雑になる。
VCF 9.1のIaC設計では、Terraformを「VCFの全操作を自動化する魔法の入口」と見ないほうがよい。SDDC Manager APIを読む、条件を評価する、変更候補をレビューする、承認後に限定された操作を実行する。この分解ができているかが大事だ。
Terraformは差分と承認の見える化に寄せる
Terraformの利点は、plan、コードレビュー、変更履歴、stateを使って、何を変えようとしているかを説明しやすいことだ。VCFの標準REST APIと組み合わせる場合も、この強みは生きる。Platform Engineeringチームがレビューし、運用チームが影響範囲を確認し、承認者が変更理由を追える。
上振れ
API問い合わせを小さなmoduleに分け、対象domainやclusterを明示し、plan結果を承認フローに載せられれば、手作業のチェックリストよりも再現性が上がる。変更履歴が残るため、監査やトラブル時の説明もしやすい。
注意点
VCF側の実行結果は、Terraformだけでは完結しない。非同期タスク、VCF AutomationのRequest、承認ポリシー、監査ログ、運用チケットと突き合わせる必要がある。Terraformの成功を、VCF側の運用完了と同じ意味で扱わない。
runtime remediationをTerraformだけで抱え込まない
公式ブログは、容量が一定条件を下回る場合にホスト追加を検討する例を使っている。ただし、容量不足への対応は、実運用では判断材料が多い。アプリケーション影響、メンテナンス時間、ライセンス、ハードウェア在庫、ネットワーク設計、vSANやNSXの状態を見ずに、閾値だけで変更を走らせるのは危ない。
下振れ
自動修復に見える仕組みほど、部分失敗時の後始末が重い。applyの再実行、外部スクリプトの副作用、手動変更とのドリフト、APIタイムアウト、承認前の変更実行などが起きると、IaCのはずが運用負債になる。
確認項目
- 監視アラートとTerraform実行を直接つなげていないか。
- 閾値を超えた時に、人間が確認する材料を残しているか。
- 変更APIの実行前に、VCF側のTaskと運用チケットを関連付けられるか。
- 失敗時に、次のapplyを禁止する条件を決めているか。
- 変更後のcapacity、health、task履歴を確認する担当が決まっているか。
tfvars、backend、secretをPoC段階で軽視しない
IaCのPoCでは、手元のtfvarsや環境変数にendpointやtokenを置いて動かしがちだ。しかし、VCFの管理面を扱うなら、PoC段階からsecretの置き場所とstate backendを分けておくべきだ。後から直すより、最初から漏れて困る値を残さないほうが楽になる。
評価基準
| 分類 | Gitに置けるか | 置き場所の例 | 注意点 |
|---|---|---|---|
| moduleコード | 置ける | Git repository | 実環境名やtokenを混ぜない |
| domain/clusterの論理名 | 条件付きで置ける | 変数ファイル、環境別設定 | 実ホスト名やIPの扱いを決める |
| token/secret | 置かない | CI/CD secret、vault、運用管理基盤 | ローテーションと監査を決める |
| state | 公開しない | remote backend、暗号化済み保管先 | APIレスポンスの残り方を確認する |
| 実行ログ | マスクして残す | CI/CDログ、監査ログ | レスポンス本文の出しすぎを避ける |
組織、プロジェクト、ポリシーをIaCのガードレールにする
- 1Provider administrator
organizationを作成し、利用できるサービスや上位の管理範囲を定義する。
- 2Organization
テナントや事業部門に相当する境界として、ユーザー、権限、リソース制限を管理する。
- 3Project
IaC実行者がどのリソースへ何を作れるかを、project単位の許可操作として列挙する。
- 4BlueprintとCatalog
Blueprint作成者、Catalog公開者、Deployment実行者を分け、再利用と公開の責任を明確にする。
- 5PolicyとRequest
承認が必要な操作、完全に禁止する操作、quota超過時の扱いを先に合意する。
API tokenやサービスアカウントに広すぎる権限を渡すと、organizationやprojectで分けた意味が薄れる。
VCF Automationを使う場合、IaCの設計はコードだけで決まらない。TechDocsのOrganization Managementでは、VCF Automationのorganizationをテナントや事業部門に相当する上位エンティティとして扱い、組織内でproject、ユーザー、権限、リソース制限を管理する流れが示されている。
つまり、TerraformやAPIクライアントを整える前に、誰がどのorganizationで何を作れるか、どのprojectにどのリソースを割り当てるか、どの操作に承認が必要かを決める必要がある。コードがガードレールを代替するのではなく、VCF Automation側のロール、クォータ、ポリシーをコードの前提にする。
組織とプロジェクトはAPI利用者の境界になる
VCF Automationでは、provider administratorがorganizationを作成し、organization administratorやapplication teamが割り当てられたサービスやリソースを利用する。TechDocsでは、All Apps organizationとVM Apps organizationという種類にも触れている。記事執筆時点の確認では、All Apps organizationはより包括的なbuilt-in cloud servicesを使う前提、VM Apps organizationはVMベースのアプリケーションに寄る説明になっている。
確認項目
| 誰が決めるか | 決める対象 | IaCでの影響 |
|---|---|---|
| Provider administrator | organization、提供リソース、上位ポリシー | どのチームがAPIを使えるかを制限する |
| Organization administrator | project、user/group、resource limit | CatalogやDeploymentの利用範囲を決める |
| Platform Engineering | Blueprint、module、pipeline、review | 再利用できる構成と変更承認を整える |
| Application team | request、deployment、日常操作 | セルフサービスの入口を使う |
注意点
API tokenやサービスアカウントに広すぎる権限を渡すと、organizationやprojectで分けた意味が薄れる。IaCの実行者は、便利な管理者権限ではなく、操作目的に合わせた権限で始めたい。
Blueprint APIとDeployment APIを分けて読む
Developer Portalでは、VCF Automation APIが機能領域ごとに分かれている。Blueprint APIはBlueprint、Terraform Integrations、Property Groups、Validationなど、定義や再利用に近い領域を扱う。一方、Deployment APIはCatalog Items、Deployments、Policies、Requests、Resourcesなど、実行後の管理や申請に近い領域を扱う。
条件
Blueprint APIを触る人と、CatalogからDeploymentを実行する人は同じとは限らない。Blueprintの作成、検証、公開、Requestの承認、Deployment後の変更を一つのpipelineにまとめる前に、それぞれの責任者を分けておく。
評価基準
Blueprintをコードで管理するなら、validationの失敗条件、reviewの担当、Catalog公開の承認を決める。Deploymentを自動化するなら、request ID、policy適用、resourceの追跡、失敗時の削除/再実行条件を決める。両者を混ぜると、どこで止まったのかが分かりにくい。
ガードレールはコード化の前に合意する
IaCコードは、合意済みの運用ルールを実行しやすくする道具だ。未合意のままコード化すると、誰がどのprojectに何を作れるか、どのquotaを超えたら止めるか、どのpolicyに引っかかったら承認へ回すかが、実装者の判断に閉じ込められる。
確認項目
- Project単位で許可する操作を列挙したか。
- 承認が必要な操作と、完全に禁止する操作を分けたか。
- quotaを超えた時に、requestを止めるのか、承認へ回すのかを決めたか。
- Blueprint作成者、Catalog公開者、Deployment実行者を分けたか。
- IaC実行者の権限が、日常運用の権限より広くなっていないか。
API認証、SDK/CLI、ローカルSwaggerの確認順をそろえる
- 1Developer Portal
公開リファレンスとしてAPIカテゴリ、概要、operation indexを確認する。
- 2TechDocs
SDK、API、PowerCLI、organization管理、認証まわりの公式説明を確認する。
- 3ローカルSwagger
自分の環境に入っているコンポーネント、バージョン、認証設定に近い挙動を確認する。
- 4PowerCLIとSDK
Terraformの代替ではなく、調査、自動化、認証確認の補助線として使い分ける。
- 5CI/CD runner
VCF管理面への到達経路、tokenの保管、ログのマスク、実行者の追跡を確認する。
Developer Portalのlatestと自社環境の実バージョンは、2026年6月12日時点の確認情報として分けて扱う。
VCF 9.1の自動化では、Developer Portal、TechDocs、ローカルSwagger、PowerCLI、SDK、CI/CD runnerがそれぞれ別の役割を持つ。どれか一つだけ見て「動く」と判断すると、環境固有の差分や認証の制約を見落とす。
特にDeveloper Portalのlatest URLは、確認時点の最新版を示す入口だ。この記事では2026年6月12日に確認した内容を前提にしている。将来のAPIリファレンスやTechDocsの更新で、項目名や説明が変わる可能性は残る。
Developer PortalとローカルSwaggerの役割を分ける
Developer Portalは、公開リファレンスとしてAPIのカテゴリ、概要、operation indexを確認する入口になる。ローカルSwaggerは、自分の環境に入っているコンポーネント、バージョン、認証設定に近い確認材料になる。どちらか一方だけでは足りない。
根拠
TechDocsのAdministration SDKs, APIs, and CLIページは、VCF SDK、VCF APIs、VCF PowerCLIを使ってインフラの展開や管理をプログラムから自動化する文脈を示している。公式ブログも、VCFの各コンポーネントにAPI reference docsがあること、ローカルSwaggerを確認できることに触れている。
注意点
本番環境で使う前に、公開リファレンスのlatestと、対象環境の実バージョンを照合する。記事やサンプルのURLだけで、自社環境のAPI挙動を断定しない。
PowerCLIやSDKはTerraformの代替ではなく補助線にする
PowerCLI、SDK、Terraformは競合だけではない。調査はPowerCLI、差分管理はTerraform、アプリケーション化はSDK、手順の小さな検証はPythonやbash、という分け方もできる。既存の運用スクリプトを全部Terraformへ置き換える必要はない。
条件
認証やtokenの扱いは、VCF PowerCLI 9.1のOAuth 2.0認証の記事も合わせて確認したい。API token、SSO、PowerCLI接続の基本が整理できていない状態でTerraformへ進むと、問題がツール固有なのか認証設計なのか判別しにくい。
評価基準
| 用途 | 向く入口 | 理由 |
|---|---|---|
| 読み取り棚卸し | PowerCLI、Python、Terraform external data | 小さく始めやすい |
| 差分レビュー | Terraform | planとコードレビューを使いやすい |
| 定型手順 | Ansible、PowerCLI、スクリプト | 手続きの順序を表現しやすい |
| アプリ化 | SDK、REST API | UIや業務フローに組み込みやすい |
| セルフサービス | VCF Automation Catalog/Deployment API | project、policy、requestとつなげやすい |
API tokenとサービスアカウントの扱いを本文で曖昧にしない
IaCの実行者は、人間の管理者アカウントではなく、目的ごとに権限を絞ったサービスアカウントに寄せたい。tokenの有効期限、ローテーション、保管場所、監査ログ、失効手順が決まっていないなら、本番変更の自動化にはまだ早い。
確認項目
- tokenを誰が発行し、誰が失効できるか。
- tokenの有効期限とローテーション周期は決まっているか。
- CI/CD runnerからVCF管理面への到達経路は制限されているか。
- state、ログ、plan結果にtokenやホスト名が残らないか。
- 退職、異動、委託先変更時にサービスアカウントを棚卸しできるか。
最小PoCは「読み取り、検証、変更」の三段階で設計する
SDDC Manager APIの棚卸しと、VCF AutomationのBlueprint/Deployment検証を同じpipelineで試さない。
VCF 9.1のIaC導入は、いきなり本番変更から始めない。読み取り、検証、変更の三段階に分けると、失敗しても止めやすい。特にSDDC Manager API側の棚卸しと、VCF AutomationのBlueprint/Deployment側のセルフサービス検証は、別のPoCにしたほうがよい。
最初の成果物は、完成した自動化pipelineではなく、止める条件が明記された確認表で十分だ。API到達性、認証、対象範囲、ログ、state、承認のどこで問題が出るかを見つけることが、PoCの価値になる。
読み取りPoCでAPI到達性と権限を確認する
読み取りPoCでは、SDDC Manager APIへ到達できるか、認証できるか、domain/cluster/host/taskの最小情報を取得できるかを確認する。ここでは、変更APIを呼ばない。成功条件も「情報が取れた」だけではなく、ログがマスクされ、stateに不要な情報が残らず、監査ログで実行者を追えるところまで含める。
評価基準
| 観点 | 成功条件 | 次へ進まない条件 |
|---|---|---|
| 到達性 | 手元とrunnerの両方で疎通できる | runnerが過剰に広いネットワーク権限を持つ |
| 認証 | 最小権限で読み取りできる | 管理者tokenでしか動かない |
| 対象範囲 | domain/cluster/hostを明示できる | ID指定が曖昧で全体へ広がる |
| ログ | tokenと機微情報がマスクされる | APIレスポンス本文を丸ごと保存する |
| state | 残る値を把握している | secretや詳細レスポンスが残る |
Blueprint/Deployment側のPoCは別枠で切る
VCF Automation APIのPoCでは、Blueprintの定義、検証、Catalog公開、Request、Deployment、Policy適用を扱う。これはSDDC Manager APIの読み取り棚卸しとは目的が違う。インフラ管理面とセルフサービス面を同じpipelineで試すと、失敗時にどちらの設計が悪かったのか分からなくなる。
条件
VCF Automation 9.1のNamespace Blueprintの記事で扱ったように、BlueprintやCatalogはアプリケーションチームの使い方に直結する。IaCのPoCで触る場合も、Project、Content Library、Catalog公開、Policyを別枠で確認する。
注意点
「SDDC Manager APIが読めた」ことは、「VCF AutomationのDeploymentを安全に自動化できる」ことを意味しない。認証、ロール、request、policy、resource trackingが別の層で効くため、検証表も分ける。
本番化前に残す運用メモを決める
PoCの最後に残すべきなのは、手順の成功談ではなく、誰が見ても同じ判断ができる運用メモだ。実行者、承認者、実行場所、対象範囲、止める条件、ログ保存、失敗時の連絡先、手動復旧手順を残す。
下振れ
PoCで成功しても、本番ではネットワーク経路、権限、APIバージョン、メンテナンス時間、対象domainの状態が変わる。PoC結果をそのまま本番保証として扱わず、本番化前にもう一度、対象環境で読み取り確認からやり直す。
導入判断
読み取りAPIのPoCが通り、token、secret、state、ログの保管先が分かれ、projectとpolicyの所有者が決まっている。
組織やprojectの所有者が未定、サービスアカウントが管理者権限、API version照合がない場合はガードレールを先に作る。
Terraformのplan結果、VCF側のtaskやrequest、運用チケット、監査ログを照合できる状態にする。
失敗時に止める条件と手動復旧手順がなければ、本番変更へ進む前に設計を戻す。
Terraform導入を遅らせる判断は、あとで戻れない自動化を避けるための運用設計になる。
VCF 9.1でIaCを始めてよいのは、ツールが決まった時ではない。読み取りAPIのPoCが通り、認証とsecret管理が分離され、organization/project/policyの境界が合意され、Terraform stateやログの扱いが決まった時だ。
逆に、組織やprojectの所有者が未定、サービスアカウントが管理者権限のまま、latest APIと自社環境のバージョン照合がない、手動変更が多すぎてドリフトを説明できない環境では、先にガードレールを作るべきだ。Terraform導入を遅らせるというより、あとで戻れない自動化を避ける判断になる。
まず始めてよい環境
始めやすいのは、read-only probeから入れる環境だ。SDDC Manager APIでdomain、cluster、host、taskを読み、ログをマスクし、stateに残る値を確認し、CI/CD runnerの権限を絞れるなら、次に小さなステージング変更へ進める。
評価基準
- 読み取りAPIのPoCが手元とrunnerの両方で成功している。
- token、secret、state、ログの保管先が分かれている。
- organization、project、role、quota、policyの所有者が決まっている。
- Terraformのplan結果をレビューし、VCF側のtaskやrequestと照合できる。
- 失敗時に止める条件と手動復旧手順がある。
まだ待つべき環境
まだ待つべきなのは、Terraformを否定するためではない。権限や責任の境界が曖昧なまま自動化を始めると、便利なはずのIaCが、誰も止められない変更経路になるからだ。
注意点
特に、管理者tokenをCIに置く、Terraform stateの中身を確認しない、API versionを確認しない、運用チケットとtask IDを結びつけない、Blueprint公開とDeployment実行を同じ権限で動かす、といった状態なら、先に設計を戻したほうがよい。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog「Modern Automation with VMware Cloud Foundation Part 2: Modern Infrastructure as Code with VCF」（2026年6月11日公開、2026年6月12日確認）
https://blogs.vmware.com/cloud-foundation/2026/06/11/modern-automation-with-vmware-cloud-foundation-part-2-modern-infrastructure-as-code-with-vcf/
- Broadcom TechDocs「Organization Management / VMware Cloud Foundation 9.1」（2026年6月12日確認）
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management.html
- Broadcom TechDocs「Administration SDKs, APIs, and CLI / VMware Cloud Foundation 9.1」（2026年6月12日確認）
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/administration-sdks-cli-and-tools.html
- Broadcom Developer Portal「SDDC Manager API Reference Guide 9.1 Latest」（2026年6月12日確認）
https://developer.broadcom.com/xapis/sddc-manager-api/latest/
- Broadcom Developer Portal「VCF Automation API | VM Apps Org – Blueprint 9.1 Latest」（2026年6月12日確認）
https://developer.broadcom.com/xapis/vm-apps-org-blueprint/latest/
- Broadcom Developer Portal「VCF Automation API | VM Apps Org – Deployment 9.1 Latest」（2026年6月12日確認）
https://developer.broadcom.com/xapis/vm-apps-org-deployment/latest/
- Broadcom TechDocs「VMware Cloud Foundation 9.1 Release Notes」（2026年6月12日確認）
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-0-0-release-notes.html