追記: 2026年6月7日の最新情報
2026年6月5日に公開されたVKS向けArgo CD GitOpsの公式記事を踏まえると、Namespace Blueprintは「Namespaceを捕捉して再利用しやすくする仕組み」、GitOpsは「継続的に望ましい状態へ近づける運用方式」と分けて読むのが安全です。Namespace Blueprintだけで、VKSクラスタ、Add-on、アプリケーション、承認フローまで一括で継続管理できると見なさないでください。
- Namespace Blueprintは、Self-Service Namespace、VM Group、Project Content Libraryを前提に、再利用できる環境定義やCatalog itemを作る用途で見ます。
- GitOps on VKSは、vSphere Supervisor経由でNamespace、VKSクラスタ定義、Add-on、VM Service、アプリケーションを宣言的に扱う設計として確認します。
- 既存の公式注意点どおり、VKS clusterやAVI load balancerを含むNamespaceはBlueprint captureの対象外として扱い、必要ならGitOpsや別手順へ分けます。
Blueprint化をPoCする場合は、まず「一度捕捉して再デプロイしたいもの」と「継続的にGitで管理したいもの」を分け、後者はVKSでArgo CD GitOpsを始める前の確認点も合わせて確認すると設計の混線を避けやすくなります。
3行まとめ
このテーマをもう少し広げて見るなら、VKSでArgo CD GitOpsを始める前に確認する：Supervisor Service、App of Apps、互換性の実務ポイント と VCF 5.2.xから9.1へ移行前に確認する：8ステップ順序、VCF Management Services、NSX経路の実務ポイント も合わせて確認してください。Namespace BlueprintとGitOpsの役割を分けて、継続管理の設計を確認できます。
vSphere Namespaceを捕捉し、BlueprintやCatalog itemとして再デプロイしやすくします。
Self-Service Namespace、VM Group、Project Content Libraryを先に確認します。
VKS clusterやAVI load balancerを含むNamespaceは、別手順として扱います。
Namespace Blueprintは標準化や再作成を助ける機能であり、無条件の完全コピーではありません。
- VCF Automation 9.1のNamespace Blueprintは、vSphere Namespaceを捕捉して再利用可能なBlueprintやCatalog itemとして扱うための機能です。導入前には、対象Namespace、VM Group、Project Content Libraryを先に整理する必要があります。
- 公式情報では、VM、Guest OS設定、ディスク状態、VPCトポロジー、サブネット、セキュリティグループ、NAT、PVC、Storage Class、起動順、権限などが確認対象になります。一方で、VKS clusterやAVI load balancerを含むNamespaceは現時点でcaptureできないとされています。
- 2026年6月4日JST時点の一次情報では、App Stack Formationは標準化、sandbox再作成、QA環境、構成ドリフト抑制に効く可能性があります。ただし、完全なバックアップ代替や無条件の本番移行手段として読むのは危険です。
Broadcom/VMwareは2026年6月2日、VMware Cloud Foundation Blogで「Capture a Namespace as a Blueprint in VMware Cloud Foundation」を公開しました。VCF Automation 9.1のApp Stack Formationに含まれる機能として、vSphere Namespaceを捕捉し、Catalog itemとして再デプロイできるBlueprintに変換する説明です。
ここを単なる「テンプレート作成機能」として読むと、期待値が少しずれます。公式記事は、VMの設定だけでなく、ネットワーク、ストレージ、Guest OS、起動順、権限などの関連情報を含めて扱うと説明しています。一方で、VKS clusterやAVI load balancerを含むNamespaceは現時点でcapture対象外とも明記しています。つまり、便利そうだから本番Namespaceをそのまま捕捉する、というより、captureできる構成に整えてから使う機能です。
直近では、VCF 9.1全体の導入前チェックや、VCF PowerCLI 9.1のOAuth 2.0認証も扱いました。今回はその続きとして、VCF Automation 9.1で「実行中のNamespaceを再利用可能な環境定義にする」前に、導入企業や運用チームが何を棚卸しするべきかに絞ります。
Broadcom Watch JapanはBroadcom Inc.およびVMware by Broadcomとは非提携の独立した情報整理サイトです。この記事は投資助言、契約判断、公式サポート回答ではありません。導入、アップグレード、サポート条件、ライセンス、対応範囲は、必ずBroadcomの公式資料、サポート窓口、自社契約で確認してください。
VCF Automation 9.1でNamespace Blueprintが意味すること
- 1vSphere Namespace
アプリケーション環境を構成するVM、ネットワーク、ストレージを含む単位です。
- 2VM Group
捕捉対象に含めるVMを絞り、不要なVMの混入を避けます。
- 3Blueprint Definition
Namespaceの構成をdeclarative YAMLとして扱う入口になります。
- 4Project Content Library
生成したBlueprintをProject単位で保管し、共有する場所です。
- 5Catalog item
利用者がSelf-Serviceで環境を再デプロイするための公開単位です。
バックアップではなく、同じような環境を作り直すための標準化された定義として読むのが安全です。
VCF Automation 9.1のNamespace Blueprintは、vSphere Namespaceを「あとで同じように作れる単位」に近づける機能です。公式ブログでは、Namespaceをcaptureし、その環境をCatalog itemとして再デプロイできると説明されています。ここで重要なのは、単一VMのテンプレート化ではなく、アプリケーション環境を構成する複数の要素をまとめて扱う点です。
App Stack FormationとCapture Namespaceの関係
App Stack Formationは、VCF 9.1のSelf-Service Private CloudやVCF Automationの文脈で出てくる新しいBlueprintingの考え方です。2026年5月5日のVCF Automation 9.1紹介記事では、実行中のトポロジー、つまりVM群、ネットワーク構成、ディスクなどを単一のBlueprintへ取り込む方向性が示されました。2026年5月26日のVCF Breakroom Chatsでも、実行中のsandbox environmentを再利用可能なBlueprintとして捕捉し、同一のApplication Stackを大規模に展開するユースケースが扱われています。
6月2日の記事は、その話をより実務寄りに分解しています。vSphere Namespaceを捕捉し、VM、ネットワーク、ストレージ、メタデータをまとめてBlueprint artifactにする。さらに、それをCatalog itemとして再利用する。導入側から見ると、これは「毎回手で作る検証環境」を「管理された再利用単位」へ寄せるための機能です。
根拠として読むべき一次情報
中心に置くべき一次情報は、2026年6月2日のVCF Blogです。5月5日の紹介記事や5月26日のBreakroom Chatsは、需要シグナルと全体文脈として役立ちますが、capture対象や制限事項を確認する時は6月2日の記事を優先するのが安全です。5月5日の記事にはリリース前の未来形で書かれた箇所もあるため、本文中の導入判断では、公開日と時制を分けて読む必要があります。
バックアップではなく再利用できる環境定義として読む
Namespace Blueprintは、バックアップ製品の代替として読むより、再デプロイ可能な環境定義として読むほうが実務に合います。公式記事でも、迅速な環境クローン、移行、復旧に触れていますが、同時にcaptureできない構成や専用条件もあります。すべての状態を無条件に復元できる、と読み替えてはいけません。
導入チームがまず決めるべきなのは、このBlueprintを何に使うかです。開発者向けsandboxを毎回作り直すのか。QA環境を標準化するのか。複数Projectに同じ構成を配るのか。別のVCF Automation instanceへOVAやYAMLで持ち出すのか。目的が違うと、同一性を守るべき項目も、再デプロイ時にカスタマイズすべき項目も変わります。
評価基準
「Captureできるか」だけでは不十分です。次の3つを分けて評価します。
| 評価軸 | 導入前に確認すること | 判断の目安 |
|---|---|---|
| 同じ環境を作り直す | MAC、IP、BIOS、Storage Class、Volumeなどを維持したいか | Dedicated VPC条件やIdentical captureの制約を見る |
| カスタマイズして配る | VM Class、Storage Class、hostname、password、bootstrapを変えたいか | Catalog利用者に何を選ばせるか決める |
| 他環境へ持ち出す | OVA/YAML export/importで共有したいか | 移送先のProject、Library、Network、権限を先にそろえる |
この段階で、Namespace Blueprintを「便利な複製ボタン」としてではなく、「管理された再利用アーティファクト」として扱う設計に切り替えると、後工程の失敗が減ります。
Capture前にProject単位で確認する3条件
capture元だけでなく、再デプロイ先のProject条件までそろっているかを見る必要があります。
6月2日の公式記事は、技術的な前提としてSelf-Service Namespaces、VM Group、Project Content Libraryを挙げています。この3つを曖昧にしたまま進めると、captureの可否だけでなく、再デプロイ後の利用者体験やガバナンスも崩れます。
Self-Service Namespaceが有効なProjectか
まず見るべきなのは、対象ProjectでSelf-Service Namespaceを作れる状態かどうかです。Namespace Blueprintは、単に管理者がVMをコピーする機能ではありません。Projectという境界の中で、resource quotaやsecurity policyに沿って、利用者がCatalogから環境を再作成できるかが重要になります。
Projectには、利用者、権限、Namespace Class、割り当てリソース、利用できるサービス、ポリシーが結びつきます。capture元だけ整っていても、再デプロイ先のProjectで同じ条件を満たせなければ、Blueprintは運用に乗りません。
確認項目
- 対象ProjectでSelf-Service Namespace creationが有効か。
- Namespace Class、quota、security policyがCatalog利用者の用途に合っているか。
- 再デプロイ先のProjectで、必要なNetwork、Storage Class、Content Libraryを参照できるか。
- Catalog itemを使うユーザーやグループに、必要最小限の権限があるか。
- 本番系、検証系、開発系のProjectを同じBlueprintで扱ってよいか。
ここで特に注意したいのは、権限の広げすぎです。Blueprintを配りやすくするためにProject権限を広げると、標準化のための機能が逆にガバナンスを崩すことがあります。
VM Groupで捕捉対象を絞れているか
VM Groupは、capture engineに対して「どのVMを中核として扱うか」を伝えるフィルターの役割を持ちます。Namespaceの中には、アプリケーション本体のVMだけでなく、検証用、踏み台、一時作業用、監視補助、過去の残骸が混ざることがあります。VM Groupを曖昧にしたままcaptureすると、不要なVMを含めるか、逆に必要なVMを落とす可能性があります。
たとえば三層アプリケーションを想定するなら、Web、App、DBを同じApplication Stackとして扱うのか、DBは別の復元手順に分けるのかを先に決めます。テスト補助VMや一時的な変換VMがNamespace内にある場合、それをBlueprintに含める意味があるかも確認します。
注意点
VM Groupは、運用の都合を反映します。公式記事の範囲を超えて「このVM構成なら必ず正しい」と言うことはできません。導入企業ごとに、アプリケーション責任者、Platform Engineer、運用管理者で、capture対象と対象外を確認する必要があります。
実務では、VM Groupを決める前に次のような短い棚卸し表を作ると判断しやすくなります。
| VM種別 | Blueprintに含めるか | 理由 |
|---|---|---|
| アプリケーション本体VM | 原則含める | 再デプロイ時の中心になる |
| 一時作業VM | 原則含めない | 再利用時に不要な設定を持ち込む可能性がある |
| 監視・運用補助VM | 用途次第 | 別Projectや共通基盤で管理している場合がある |
| データ保持VM | 慎重に判断 | データの扱い、容量、整合性、権限を別途確認する |
Project Content Libraryをどこに用意するか
公式記事では、Project-scoped Content Libraryが必須とされています。capture時にVMの特殊なexportが行われ、そのイメージがProjectのLibraryに保存されるためです。ここは、あとから「どこかのLibraryに置けばよい」と考えるより、Project設計の一部として先に決めるほうが安全です。
Content Libraryは、再デプロイ速度、利用者の見える範囲、権限、標準イメージ管理に影響します。Self-Service Private Cloud資料やVCF Automation datasheetでも、Content ManagementやBlueprints & IaCはVCF Automationの重要な機能領域として扱われています。Namespace Blueprintを使うなら、Libraryの命名、所有者、更新権限、削除ルールを決めておくべきです。
条件
Project Content Libraryを確認する時は、次の4点を見ます。
- capture元ProjectにProject-scoped Content Libraryがあるか。
- 再デプロイ先Projectから必要なLibraryを参照できるか。
- Project Admin、Project Advanced User、Org Adminの権限境界が整理されているか。
- OVAやYAMLをexport/importする場合、移送先にも対応するLibraryやNetwork、Storage Classがあるか。
Org-wideな標準Libraryと、Projectに閉じたLibraryを混同すると、利用者が見えるべきでないアーティファクトが見えたり、逆にCatalog itemから必要なイメージを参照できなかったりします。Namespace Blueprintは標準化のための機能ですが、Library設計が雑だと標準化の入口でつまずきます。
何が捕捉され、どこを再設定できるのか
Identical captureとCustomized captureでは、維持すべき値と入力させる値が変わります。
Namespace Blueprintの導入判断で最も大切なのは、capture対象を過不足なく理解することです。公式記事は、Namespace classに加えて、VM、Guest OS、Network、Stateful Storage、Application Metadataの要素を列挙しています。ただし、この列挙は「どんなNamespaceでも完全に移せる」という意味ではありません。制限事項とセットで読む必要があります。
VM、ネットワーク、ストレージ、メタデータの捕捉範囲
公式記事で示されているcapture対象は、実務上かなり広い範囲に見えます。VMではCPU、RAM、vNUMAなどのhardware configuration、power state、Guest OS settings、disk stateが対象として説明されています。NetworkではVPC topology、subnets、security groups、NAT rules、load balancer configurationsなどが挙げられています。StorageではPVCsとstorage classes、Application Metadataではstartup/shutdown sequencingやproject-level user permissionsが触れられています。
導入前には、この項目をそのまま写すのではなく、自社環境の確認表に変換します。
| 領域 | 公式情報で確認した要素 | 自社で確認すること |
|---|---|---|
| VM | CPU、RAM、vNUMA、power state、Guest OS、disk state | VM Group、起動順、依存関係、不要VMの混入 |
| Network | VPC、subnet、security group、NAT、load balancer configuration | 固定IP、NAT設計、セキュリティ境界、移送先のNetwork |
| Storage | PVC、Storage Class、Volume、disk capacity | データ容量、Storage Class差分、再デプロイ後の整合性 |
| Metadata | startup/shutdown sequencing、permissions | Catalog利用者、Project権限、承認、監査 |
根拠
本文で断定してよいのは、一次情報が明示した範囲です。「Kubernetesリソースがすべて無条件に移る」「既存の本番Namespaceをそのまま完全再現できる」といった言い方は避けるべきです。特にVKS clusterとAVI load balancerの制限は、capture対象の広さと一緒に説明しないと誤解されます。
Identical captureとCustomized captureを分ける
Namespace Blueprintには、同一コピーに近い使い方と、再デプロイ時に調整する使い方があります。公式記事では、Identical copiesはMAC、IP、BIOS、Guest OS settings、NIC properties、subnets、Storage Class、Volumes、disk capacity、volume provisioning modeなどを保持する方向で説明されています。
一方で、Customized captureでは、Catalog利用者がVM ClassやStorage Classを選んだり、Guest OS identity、hostname、password、bootstrap typeを設定したりできる方向で説明されています。運用上は、この2つを混ぜないことが大切です。同一性を重視する環境と、配布先に合わせて変える環境では、テスト観点も承認フローも異なります。
条件
公式記事は、Identical captureについて、Dedicated VPCに関連付けられたNamespaceでのみ使えるとしています。この条件は、導入前チェックで強く目立たせるべきです。Dedicated VPCに該当しないNamespaceを、同一コピーの前提で進めると、設計段階で期待値がずれます。
実務では、次のように分けて考えると整理しやすくなります。
- 同一captureを狙う場合: MAC、IP、subnet、Storage Class、Volume、Guest OS設定を維持する理由を明確にする。
- カスタムcaptureを狙う場合: VM Class、Storage Class、hostname、password、bootstrap scriptを誰が入力するかを決める。
- どちらも迷う場合: まず小さな検証Namespaceで両方の再デプロイ結果を比較する。
Guest OS設定とbootstrapをどう扱うか
Customized captureの実務ポイントは、Guest OS設定です。公式記事では、LinuxPrepのようなpost-deployment script、unique passwords、hostnamesなどに触れています。ここは便利な反面、セキュリティと運用標準に直結します。
たとえば、再デプロイ時にhostnameを自動生成するなら、命名規則、DNS、CMDB、監視登録、証明書、ログ収集と整合させる必要があります。パスワードを設定するなら、保管場所、ローテーション、利用者への引き渡し、監査ログを決めておく必要があります。bootstrap scriptを使うなら、何を初回起動で実行し、どこまでをBlueprintに含め、どこからを構成管理ツールに任せるかを分けます。
確認項目
- hostnameの命名規則と重複防止。
- passwordやsecretの扱い。
- LinuxPrepなどのbootstrap scriptの責任範囲。
- 初回起動後に実行する監視登録、CMDB更新、ログ転送。
- 再デプロイ後にアプリケーション所有者が確認する疎通項目。
Namespace Blueprintは、環境作成を速くする機能です。ただし、Guest OSの初期化や認証情報管理が雑なままだと、速く作れる分だけ不整合も速く増えます。
Pre-flight Checkと制限事項を先に潰す
制限事項は失敗理由ではなく、Catalog化に向く環境かどうかを見分ける材料になります。
公式記事は、capture処理をDiscovery、Resource Collection、Validationの流れとして説明しています。ここでPre-flight Checkが重要になります。capture前に問題を見つける仕組みを、単なるエラー処理ではなく、Catalog化に向く環境かどうかを判定する材料として使うべきです。
Discovery、Resource Collection、Validationの見方
Captureの流れは、Namespaceをクロールし、VM Service VMsと関連オブジェクト、依存関係を把握するところから始まります。Pre-flight Checkでは、hardware compatibility、storage accessibility、network consistencyなどが確認され、hard-coded IP addressやnode-affinity rulesのように、別Projectや別環境で同一コピーを難しくする要素も見つける方向で説明されています。
この段階で出てくる問題は、単に「captureできる、できない」だけの話ではありません。Catalog itemとして他チームへ渡した時に、利用者が同じように使えるか。別Projectへ移した時にNetworkやStorageの前提が崩れないか。再デプロイ後にアプリケーションが起動順どおりに立ち上がるか。そこまで含めて見る必要があります。
確認項目
Pre-flight Check前に、導入チームが自分たちで確認しておきたい項目は次のとおりです。
| 項目 | 見る理由 | 問題がある時の対応 |
|---|---|---|
| Hardware compatibility | VMの再デプロイ可否に関わる | VM ClassやHardware Versionを見直す |
| Storage accessibility | Volumeやdisk stateの扱いに関わる | Storage ClassとProject割り当てを確認する |
| Network consistency | VPC、subnet、NAT、security groupに関わる | 固定設定を減らし、移送先Networkを整理する |
| Hard-coded IP | 別Project配布で衝突しやすい | Customized captureや再設定手順を検討する |
| Node affinity | 移行性を落としやすい | 必要性を確認し、代替設計を残す |
VKS clusterとAVI load balancerを含むNamespaceは分けて考える
6月2日の公式記事で最も見落としたくないのは、VKS clustersやAVI load balancersを含むNamespaceは現時点ではcaptureできない、という注意です。ここを読み飛ばすと、アプリケーション環境全体をNamespace Blueprintで再現できると誤解しやすくなります。
同じ公式記事内にはload balancer configurationsという言葉も出ます。このため、読者には矛盾して見えるかもしれません。実務では、公式記事が列挙したcapture対象と、VKS/AVIを含むNamespaceの現時点の制限を分けて扱うのが安全です。特に、Avi Load Balancerを前提にしたアプリケーションや、VKS clusterを含む開発環境では、Namespace Blueprintだけで全体復元できる前提を置かないでください。
下振れ
VKSやAVIを使う環境では、次のような分解が必要になります。
- Namespace Blueprintでcaptureできる部分。
- VKS clusterやAVI load balancerのように別手順へ分ける部分。
- Network、DNS、証明書、外部依存先など、Project外で管理する部分。
- 再デプロイ後にアプリケーション所有者が手動または別自動化で確認する部分。
この分解を先にしておけば、「使えない」と切り捨てる必要はありません。対象外コンポーネントを別のテンプレート、ドキュメント、API自動化、運用Runbookに分ければ、Namespace Blueprintを部分的に活かせます。
固定IPや依存関係が移行性を落とす
Pre-flight Checkでhard-coded IPやnode affinityが問題として見つかる可能性があるという点は、かなり実務的です。固定IPは、同じProject内で同一環境を作り直す時には便利でも、別Projectや別VCF Automation instanceへ移す時には衝突や依存関係の原因になります。node affinityも、特定の基盤条件を強く前提にしている場合、再利用性を下げます。
ここでの判断は、再利用範囲によって変わります。同一Project内の短期sandbox再作成なら、固定設定をある程度許容できるかもしれません。複数ProjectへのGlobal Catalog配布なら、固定設定はなるべく減らす必要があります。別VCF Automation instanceへ持ち出すなら、Network、Storage、権限、命名規則まで移送先で再解決できる形に寄せるべきです。
評価基準
| 再利用範囲 | 許容しやすいもの | 注意すべきもの |
|---|---|---|
| 同一Project内 | 一部の固定設定、同一Storage Class | データ整合性、権限、不要VM |
| 別Project | Catalog入力で変えられる設定 | 固定IP、Project固有のLibrary、権限差分 |
| 別VCF Automation instance | YAML/OVAで持ち出せる定義 | Network/VPC差分、Storage Class差分、外部依存 |
Pre-flight Checkは、導入後に落ちるための検査ではなく、再利用設計を良くするための材料として使うのがよい読み方です。
OVA/YAML export/importとCatalog公開の確認点
- 1Blueprint Definition
Namespaceの構成をcodeとして扱い、差分確認やレビューの対象にします。
- 2YAML
命名規則、version、承認、保管場所を決めて管理します。
- 3OVA
持ち出す内容と、移送先で再設定が必要な項目を分けます。
- 4Project Content Library
所有者、更新権限、参照できるProjectを明確にします。
- 5Global Catalog
承認、lease、Day 2 action、削除責任を整理して公開します。
- 6別VCF Automation instance
Namespace Class、Network、Storage Classの差を確認してからimportします。
export/importは共有や保管に役立ちますが、DRや無条件移行として広げすぎないことが大切です。
公式記事では、生成されたBlueprintをOVAまたはYAMLとしてexport/importできる点にも触れています。これにより、VCF Automation instances間でNamespace contentを共有したり、バックアップ的に保管したりする使い方が想定されます。ただし、ここでも「完全なDR」や「何でも移せる」と広げすぎないことが大切です。
Blueprint DefinitionをYAMLとして管理する
Captureの最後には、Blueprint Definitionが生成されます。公式記事では、これはNamespaceをcodeで表現するdeclarative YAMLとして説明されています。導入企業にとっては、ここが変更管理の入口になります。
YAMLとして扱えるなら、命名規則、Version、レビュー、差分確認、承認、保管場所を決められます。Platform Engineerが標準Stackを更新する時、どの変更がNetworkに影響するのか、どの変更がGuest OS初期化に影響するのかをレビューしやすくなります。
注意点
YAMLがあるからといって、すべてをGitOpsで完全自動化できるとは限りません。公式情報で確認できるのは、Blueprint Definition、export/import、Catalog化の文脈です。Git管理、CI/CD、承認ワークフロー、セキュリティスキャンは、自社運用として別途設計する領域です。
OVA/YAML export/importで何を持ち出すか
OVAやYAMLでexport/importできることは、環境共有には便利です。たとえば、中央のPlatform Teamが作った標準app stackを、別のVCF Automation instanceへ移す。あるいは、重要なBlueprint Definitionをバックアップとして保持する。こうした使い方は考えられます。
ただし、移送先には移送先のProject、Content Library、Network、Storage Class、権限があります。Blueprint artifactだけを持っていても、移送先の前提が合わなければ再デプロイは詰まります。
確認項目
- exportする形式はOVAかYAMLか、それとも両方か。
- 移送先Projectに必要なNamespace Class、Network、Storage Classがあるか。
- 移送先で同じhostnameやIPを使ってよいか。
- Project Content Libraryの所有者と更新権限は誰か。
- Catalog公開後の承認、lease、Day 2 action、削除責任は誰が持つか。
- 失敗したimportや古いBlueprintをどう廃止するか。
Global CatalogとCross-Project Portability
Namespace Blueprintが効く場面のひとつは、Global CatalogやCross-Project Portabilityです。中央のアーキテクトチームが、硬化済みの多層アプリケーション環境を作り、それを複数Projectへ配る。QAチームが標準環境をすばやく再作成する。開発チームが壊れたsandboxを消して、既知の状態から作り直す。こうした運用は、手作業の環境差分を減らす可能性があります。
一方で、Catalogに載せた瞬間に運用責任が消えるわけではありません。むしろ、利用者に渡す説明文、入力項目、制限事項、サポート範囲を整える必要があります。特にVKS/AVI制限、Dedicated VPC条件、Guest OS初期化、権限境界は、Catalog itemの説明に残すべきです。
上振れ
うまく設計できれば、Namespace Blueprintは次のような効果を狙えます。
- 開発sandboxの再作成を速くする。
- QA環境を標準化し、回帰テストの前提差分を減らす。
- 多層アプリケーションの起動順や依存関係を明示する。
- Project間で標準Stackを共有する。
- 手作業による構成ドリフトを減らす。
ただし、これは自動的に得られる結果ではありません。VM Group、Content Library、Pre-flight Check、Catalog説明、権限設計をそろえた時に初めて近づく成果です。
導入前チェックリスト
Project Content Libraryがあり、VM Groupが明確で、VKS clusterやAVI load balancerを含まない小さなNamespaceです。
固定IP、hostname、password、bootstrap、外部依存先の扱いをまだ決めていないNamespaceです。
本番系、複雑な依存関係、Project外のnetworkやDNSに強く結びついたNamespaceです。
最初の目的は完璧な標準Stack作りではなく、captureから廃止までの流れを安全に通すことです。
Namespace Blueprintを試すなら、最初から複雑な本番相当環境を対象にしないほうがよいです。まずはcapture対象と対象外が明確で、Project条件がそろい、再デプロイ後の確認項目を短時間で見られるNamespaceを選びます。
まず小さく試せる環境
Pilot候補として向いているのは、次の条件を満たすNamespaceです。
- Dedicated VPCに関連付けられている、または同一captureを狙わない方針が明確である。
- Project Content Libraryが用意されている。
- VM Groupが明確で、不要VMが混ざっていない。
- VKS clusterやAVI load balancerを含まない。
- Guest OS customization、hostname、password、bootstrapの方針がある。
- 再デプロイ後に確認するアプリ疎通、起動順、権限、Storage Classが決まっている。
この条件を満たす小さなNamespaceであれば、機能検証と運用検証を分けやすくなります。最初の目的は、完璧な標準Stackを作ることではありません。capture、Blueprint生成、Catalog化、再デプロイ、確認、廃止までの一連の流れを安全に通すことです。
評価基準
Pilotの成功条件は、次のように具体化できます。
| 確認 | 成功の目安 |
|---|---|
| Capture | Pre-flight Checkの警告と失敗理由を説明できる |
| Catalog化 | 利用者が目的と制限を理解できる説明文がある |
| 再デプロイ | VM起動順、hostname、IP、Storage Classが期待どおり |
| アプリ確認 | アプリケーション所有者が疎通と初期状態を確認できる |
| 運用記録 | Source Namespace、Version、Capture日時、制限事項が残る |
先に棚卸しすべき環境
次のようなNamespaceは、いきなりcaptureするより先に棚卸しが必要です。
- VKS clusterやAVI load balancerを含む。
- 固定IPやnode affinityが多い。
- 多数の補助VMや一時VMが混ざっている。
- VM Groupの定義がない、または用途が曖昧。
- Project Content Libraryが未整備。
- Guest OSの初期化、password、hostnameの扱いが未定。
- Project権限やCatalog利用者が決まっていない。
- 移送先Projectや別VCF Automation instanceのNetwork/Storage条件が未確認。
ここに当てはまるからといって、Namespace Blueprintが使えないわけではありません。capture対象と対象外を分解すれば、使える部分は残ります。VKSやAVIを別手順に分ける、固定IPをカスタマイズ入力に逃がす、補助VMをVM Groupから外す、Project Libraryを新設する。そうした整理をしてから試すほうが、結果として早く進みます。
注意点
「まず試す」ことと「本番で使う」ことは別です。Pilotで成功しても、Catalog利用者が増えた時、Projectが増えた時、NetworkやStorage Classが異なる時、古いBlueprintをどう廃止するかは別問題として残ります。運用チームは、使い始める前にVersion管理と廃止ルールを決めておくべきです。
本番導入前に残す運用メモ
本番導入を検討する前に、少なくとも次の項目を運用メモとして残します。
- Blueprint名。
- Version。
- Source Namespace。
- Capture日時。
- 対象Project。
- Project Content Library。
- VPC、subnet、Storage Class。
- Identical captureかCustomized captureか。
- VKS/AVIなど対象外にした構成。
- Guest OS customizationとbootstrapの扱い。
- Catalog itemの利用者と承認者。
- 再デプロイ後の確認手順。
- 問い合わせ先と責任分界。
- 古いBlueprintの廃止条件。
このメモは、ドキュメントのためのドキュメントではありません。Catalog itemを使う人が増えた時に、誰が何を保証しているのかを説明するための最低限の材料です。
確認項目
本番導入前の最後の確認は、Go、要整理、保留の3つに分けると判断しやすくなります。
| 判定 | 条件 |
|---|---|
| Go | VM Group、Project Library、権限、再デプロイ確認、制限事項がそろっている |
| 要整理 | captureは可能だが、固定IP、Guest OS初期化、Catalog説明、廃止ルールが弱い |
| 保留 | VKS/AVI制限、Network差分、Storage差分、権限不明、データ整合性の問題が大きい |
まとめ：Namespace Blueprintは標準化の入口、万能な複製ではない
sandbox再作成、QA環境、標準化された多層アプリ検証に使いやすい候補です。
Blueprint Definitionを変更管理の入口にし、差分確認と承認を進めやすくします。
VKS cluster、AVI load balancer、外部依存先は別の設計として扱います。
Self-Service Namespace、VM Group、Content Library、Pre-flight Checkを導入前に見ます。
VCF Automation 9.1のNamespace Blueprintは、標準化の入口として使い、万能な複製手段として扱わないことが重要です。
VCF Automation 9.1のNamespace Blueprintは、App Stack Formationを実務に近づける重要な機能です。実行中のvSphere NamespaceをBlueprintとして扱い、Catalog itemとして再デプロイする流れは、sandbox再作成、QA環境、標準Stack配布、構成ドリフト抑制に役立つ可能性があります。
ただし、導入前に見るべき条件は多いです。Self-Service Namespace、VM Group、Project Content Libraryがそろっているか。何がcapture対象で、何が対象外か。Identical captureに必要なDedicated VPC条件を満たすか。Pre-flight Checkで固定IPやnode affinity、storage accessibility、network consistencyをどう見るか。OVA/YAML export/importを、どこまで共有やバックアップ的な用途に使うか。
結論として、最初の一歩は「小さくcaptureしてみる」ではなく、「小さく説明できるNamespaceを選ぶ」ことです。説明できる構成なら、検証で失敗しても原因を切り分けられます。説明できない構成をいきなりBlueprint化すると、便利な機能がブラックボックス化します。
BroadcomのVCF 9.1関連更新は、2026年6月に入ってからも続いています。月次で追いたい場合は、2026年6月の重要トピックまとめもあわせて確認してください。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog「Capture a Namespace as a Blueprint in VMware Cloud Foundation」（2026年6月2日公開、2026年6月4日参照）
https://blogs.vmware.com/cloud-foundation/2026/06/02/capture-a-namespace-as-a-blueprint-in-vmware-cloud-foundation/
- VMware Cloud Foundation Blog「Accelerate, Streamline, and Control Your Self-Service Private Cloud with VMware Cloud Foundation 9.1」（2026年5月5日公開、2026年6月4日参照）
https://blogs.vmware.com/cloud-foundation/2026/05/05/accelerate-streamline-and-control-your-self-service-private-cloud-with-vcf-9-1/
- VMware Cloud Foundation Blog「VCF Breakroom Chats Episode 85 – Cloning Success at Scale: Inside VCF 9.1's App Stack Formation」（2026年5月26日公開、2026年6月4日参照）
https://blogs.vmware.com/cloud-foundation/2026/05/26/vcf-breakroom-chats-episode-85-cloning-success-at-scale-inside-vcf-9-1s-app-stack-formation/
- VMware「Self-Service Private Cloud with VMware Cloud Foundation」（April 2026、2026年6月4日参照）
https://www.vmware.com/docs/vmware-self-service-private-cloud-with-vcf
- VMware「VCF Automation Datasheet」（May 2026、2026年6月4日参照）
https://www.vmware.com/docs/vcf-automation-datasheet
- Broadcom News & Stories「Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI」（2026年5月5日公開、2026年6月4日参照）
https://news.broadcom.com/releases/broadcom-announces-vmware-cloud-foundation-9-1