3行まとめ：Infrastructure Placement Policiesは、VM配置をテナント任せにしないための仕組み
このテーマをもう少し広げて見るなら、vDefend Lateral Security BlueprintsをVCF 9.1で使う前に確認する：SSP、管理ドメイン、DFW 1-2-3-4の実務ポイント と VCF 9.1でvSANネットワークを設計前に確認する：10GbE、VMkernel、MTU/vmkpingの実務ポイント も合わせて確認してください。配置ポリシーでワークロードの置き場所を決める前に、VCF 9.1側のセキュリティ境界とマイクロセグメンテーションの考え方を合わせて確認できます。
- 11. VM条件
Guest OS、ラベル、用途など、どのVMを対象にするかを決めます。
- 22. Policy種別
必ず守らせる条件はMandatory、選択肢として見せる条件はOptionalに分けます。
- 33. 適用範囲
Region QuotaとNamespaceで、どの組織やチームに効くかを決めます。
- 44. vSphere土台
Compute Policyとホストタグが実態と合っているかを確認します。
Infrastructure Placement Policiesは、セルフサービスの裏側で配置条件をそろえるための仕組みです。
VCF 9.1のInfrastructure Placement Policiesは、セルフサービスでVMやアプリを配るときに、Guest OSやラベルなどの条件に応じて配置先を制御するためのVCF Automation側のガバナンス機能です。 導入前に見るべき中心は、Mandatory PolicyとOptional Policyの違い、Region QuotaとNamespaceで効く範囲、そして裏側で参照されるvSphere Compute Policyとホストタグの整合です。 AI private cloudの文脈ではGPUだけでなく、Windowsライセンス、CPU世代、データ所在、規制対応、運用チームの責任分界を同じ配置条件として扱えるかが重要になります。
2026年6月11日に公開された公式VCF Breakroom Chats Episode 87では、VCF 9.1のInfrastructure Placement Policiesが、AI private cloudのVM配置を厳格に制御し、VCF Automationのガバナンス枠組みに組み込まれる機能として扱われました。派手な新UIの話ではなく、セルフサービス化したprivate cloudで「使う人が自由に選べる範囲」と「基盤側が必ず守らせる条件」を分けるための実務機能です。
Broadcom Watch JapanはBroadcom Inc.およびVMware by Broadcomとは非提携です。本記事は導入判断の整理を目的としたもので、製品の購入、契約、投資判断を推奨するものではありません。
Infrastructure Placement Policiesは、セルフサービスと配置ガバナンスの間に入る
VMやアプリを早く払い出し、必要なCPU、GPU、ネットワークへ届くことを重視します。
ライセンス、データ所在、規制、ホストタグの整合を崩さないことを重視します。
利用者の要求を受け、条件に合う配置先をvSphere側のCompute Policyへ渡します。
自由に使わせる範囲と、必ず守る条件を分けることが導入設計の出発点です。
VCF Automationは、アプリケーションチームがVM、コンテナ、VKSクラスタなどをセルフサービスで使えるようにする方向へ進んでいます。BroadcomのVCF 9.1公式発表でも、VCF 9.1はAIとKubernetes nativeなprivate cloud platformとして説明され、GPU/CPUの選択肢、セキュリティ、マルチテナント性、運用自動化が強調されています。
ただし、セルフサービス化が進むほど、配置先を利用者の選択や偶然に任せるリスクも増えます。たとえば次のような条件は、アプリ担当者だけでは判断しにくい領域です。
| 配置条件 | 利用者が見たいこと | 基盤側が守りたいこと |
|---|---|---|
| Windows VM | 早くVMを使いたい | ライセンス対象ホストに収めたい |
| Linux/AI推論VM | GPUやCPUに近い場所で動かしたい | 適切なホストタグ、クラスタ、ゾーンへ誘導したい |
| 規制対象データ | アプリ要件を満たしたい | 特定リージョン、特定ゾーン、特定ホスト群から出したくない |
| 高価なアクセラレータ | 使えるなら使いたい | GPU/CPUを必要なワークロードへ優先配分したい |
Infrastructure Placement Policiesは、この「利用者のセルフサービス」と「基盤側の配置制御」をつなぐ層です。公式技術ブログでは、VCF Automation側のInfrastructure Policyが、vCenter側のvSphere Compute Policyをクラウド消費モデルに包み、VM要求時にVCF AutomationからvCenterへ配置要件を渡す仕組みとして説明されています。
これは単なる分類ラベルではありません。VCF AutomationのポータルでVMを要求したときに、どのVMにどの配置ルールを適用するのか、どのゾーンやクラスタを候補にするのか、条件に合わない場合に失敗させるのかを決める設計要素です。
需要シグナルは「AI private cloudの配置」を理解したい読者にある
今回このテーマを選んだ理由は、2026年6月11日の公式Breakroom ChatsでInfrastructure Placement Policiesが取り上げられ、AI private cloudのガバナンス文脈で再度注目されたためです。直近のBroadcom Watch Japanでは、VCF 9.1の<a href="https://avgo-watch.blog.mo-gmo.com/avgo-49-vcf-91-vsan-storage-policy-stretch-ops-check/">vSANストレージ設計</a>、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-48-vcf-91-nvme-memory-tiering-esxcli-check/">NVMe Memory Tiering</a>、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-44-vcf-91-iac-sddc-manager-api-terraform-check/">IaCとSDDC Manager API</a>、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-43-vcf-private-ai-services-nsx-vds-supervisor-check/">Private AI Services</a>を扱ってきました。
一方で、AI基盤を本番化するときは、GPUやネットワークだけでなく「どのチームの、どのVMが、どのホスト群に置かれるのか」を運用ルールとして決める必要があります。Infrastructure Placement Policiesは、そのルールをVCF Automationのセルフサービス体験に持ち込むための機能として読むと理解しやすくなります。
何を自動化し、何を自動化しないかを先に決める
Infrastructure Placement Policiesは、手作業の配置判断を減らすための仕組みです。ただし、配置ルールそのものまで自動で正しく設計してくれるわけではありません。必要なのは、次の3つを先に決めることです。
- どのVM属性を条件にするか
- どのvSphere Compute Policyへつなぐか
- どのRegion QuotaとNamespaceで効かせるか
この順番を飛ばしてMandatory Policyだけを先に作ると、Namespace作成やVMデプロイの失敗が、利用者から見ると「なぜか使えないセルフサービス」に見えます。導入前の設計では、失敗時の責任分界まで含むガバナンス機能として扱うべきです。
Mandatory PolicyとOptional Policyは、厳しさではなく責任範囲で分ける
Mandatoryは止めてよい条件、Optionalは選ばせてよい条件として考えると整理しやすくなります。
公式技術ブログでは、Infrastructure Policiesを作成するときにMandatory PolicyとOptional Policyの違いを決める点が強調されています。ここを「強いポリシー」と「弱いポリシー」とだけ理解すると、導入判断を誤ります。
より実務的には、Mandatoryは基盤側が必ず守らせる条件、Optionalは組織管理者や利用者に選択余地を残す条件です。
| 種別 | 誰が主に責任を持つか | 向いている条件 | 注意点 |
|---|---|---|---|
| Mandatory Policy | Provider Administrator / 基盤運用 | ライセンス、規制、データ所在、専用ホスト、必須の分離要件 | 条件を満たすゾーンやホストタグが不足すると、Namespace作成やデプロイが止まる可能性がある |
| Optional Policy | Organization Administrator / アプリ・部門運用 | 性能優先、開発/検証の配置、特定ワークロードだけの最適化 | 利用者が選ばない場合でも問題ない設計にしておく必要がある |
Mandatory Policyは、利用者の判断に任せてはいけない条件に使います。たとえば、Windowsライセンス対象ホストにWindows VMを寄せる、規制対象アプリを特定ホスト群へ固定する、特定のAI推論VMを認定済みアクセラレータのあるクラスタへ置く、といった場面です。
Mandatoryに入れる前の判断
Mandatoryに入れる条件は、守れなかったときにデプロイを止めてもよいものに限ります。性能が少し良くなる、標準構成に寄せたい、という程度ならOptionalから始めるほうが安全です。ライセンス違反、規制違反、データ所在違反のように、後から修正するコストが大きい条件だけをMandatory候補にします。
Optional Policyは、使えば便利だが全員に強制するほどではない条件に向きます。たとえば、検証用のLinux VMを低コストゾーンへ寄せる、特定チームだけが性能優先ホスト群を選べるようにする、といった使い方です。
Mandatoryは「あとから外せない前提」になりやすい
公式技術ブログでは、Mandatory PolicyをRegion Quotaに割り当てると、新しいNamespaceに自動的に含まれ、Organization Administratorが削除できないものとして説明されています。また、Mandatory Policyは既存NamespaceのないRegion Quotaにだけ適用できる点も示されています。
この仕様は、導入時の便利さよりも設計順序に影響します。すでに部門やプロジェクトへNamespaceを配っている環境で、あとからMandatory Policyを足して全体に即時適用する、という進め方は前提にしないほうが安全です。
導入前には、少なくとも次の順序で考えます。
- Mandatoryにしたい配置条件を洗い出す
- 条件を満たすホストタグとvSphere Compute Policyを先に整える
- テスト用のRegion QuotaでNamespace作成を検証する
- 既存Namespaceへの影響を確認する
- 新規Region Quotaまたは新規Namespaceから段階的に適用する
Mandatory Policyは、基盤チームが「これは必ず守らせる」と宣言する場所です。便利だから選ぶのではなく、守れなければセルフサービスを止めてよい条件だけを入れるべきです。
Optionalは「使える選択肢」として説明できる必要がある
Optional Policyは、利用者や組織管理者に選択肢を残せる反面、名前や説明が曖昧だと使われません。たとえば「High Performance」とだけ書かれていても、どのアプリで使うべきか、追加コストや容量制約があるのか、利用者には判断できません。
Optionalで残すべき余地
Optionalは「任意だから重要ではない」という意味ではありません。アプリチームが状況に応じて選んでよい余地です。検証VM、期間限定の性能優先、部門別の実験環境のように、使うチームが説明を読んで選べる条件に向きます。
Optional Policyを作るなら、利用者向けには次のように説明できる粒度が必要です。
| 利用者に見せる説明 | 基盤側の実体 |
|---|---|
| GPU推論向け | GPU搭載ホストや認定クラスタに対応するCompute Policy |
| Windowsライセンス最適化 | Windows VMを対象ホスト群へ寄せるCompute Policy |
| データ所在固定 | 指定リージョン/ゾーン/ホスト群だけを候補にするCompute Policy |
| 低コスト検証 | 余裕のある標準ホスト群へ寄せるCompute Policy |
Optional Policyは、自由度を無制限に広げるものではなく、選択してよい範囲を明確にするためのものです。利用者が誤って選んでも重大な違反にならない条件から始めると、導入後の説明がしやすくなります。
Region QuotaとNamespaceで、ポリシーの効く範囲が決まる
- 1Provider
Infrastructure Policyを作成し、Region Quotaへ割り当てます。
- 2Region Quota
組織が使える容量と、適用できる配置ルールの入口になります。
- 3Namespace
チームやアプリ単位でOptional Policyを見せる範囲を決めます。
- 4Deployment
利用者のVM要求に対して、条件に合う配置先が評価されます。
容量の割り当てと配置ポリシーの割り当ては、同じ設計の中で確認します。
Infrastructure Placement Policiesは、単体で存在しても利用者のデプロイに効くわけではありません。Provider AdministratorがPolicyを作り、それをOrganizationのRegion Quotaへ割り当て、Organization AdministratorがNamespaceで使う、という段階があります。
公式技術ブログの流れに沿うと、責任分界は次のように整理できます。
| 役割 | 主な操作 | 導入前に確認すること |
|---|---|---|
| Infrastructure / Operations Admin | vCenterのタグ、カテゴリ、VM-Host affinity Compute Policyを整える | ホストタグが実態と一致しているか、Compute Policyが期待通りに働くか |
| Provider Administrator | VCF AutomationでInfrastructure Policyを作り、Criteria Builderで対象VMを決める | Mandatory/Optionalの選択、Region Quotaへの割り当て、既存Namespaceの有無 |
| Organization Administrator | NamespaceにOptional Policyを追加・削除する | どのProjectやチームにどの選択肢を見せるか |
| Organization User | VMやアプリのデプロイ時に条件を使う | 自動選択に任せる範囲、Optional Policyを選ぶ意味 |
Region Quotaは、組織が使えるリージョン側の枠です。Infrastructure Policiesをこの枠に割り当てることで、その組織のNamespaceに対して適用可能な配置ルールが決まります。Namespaceは、アプリやプロジェクト単位でリソースを使う実際の運用単位として見ればよいでしょう。
Region Quotaは容量だけでなく、配置ルールの入口になる
Region Quotaという名前だけを見ると、CPUやメモリの割り当て上限を管理する機能に見えます。しかし、Infrastructure Placement Policiesの文脈では、Region Quotaは配置ガバナンスを組織に渡す入口にもなります。
容量だけの設計にしない
Region Quotaを容量の箱としてだけ設計すると、後で配置条件が追いつかなくなります。特定ゾーンに十分なvCPUがあっても、Mandatory Policyを満たすホストタグがなければデプロイは成立しません。容量、ゾーン、ホストタグ、Compute Policyを同じ設計表で見る必要があります。
そのため、Region Quota設計では単に「どの組織に何vCPUを配るか」だけでは足りません。次の問いを一緒に見ます。
- その組織はどのゾーンを使えるのか
- Mandatory Policyを満たせるホスト群が、割り当て先ゾーンに存在するのか
- Optional Policyとして見せる配置ルールは、Namespaceごとに選ばせてよいのか
- 既存NamespaceがあるRegion QuotaへMandatoryを足そうとしていないか
- 将来、AI推論やWindows VMが増えたときに、同じRegion Quotaで制御できるのか
容量の枠と配置ルールの枠を別々に設計すると、後から「容量はあるのに置けない」「ポリシーはあるのに対象ゾーンにホストがない」という状態が起きます。Region Quotaは、消費できるリソースの箱であると同時に、どの配置ルールを適用できるかを決める箱でもあります。
Namespace設計は、チームの自由度を左右する
Organization Administratorは、Namespaceに対してOptional Policyを追加・削除できます。Mandatory Policyは自動的に含まれ、削除できないものとして扱われます。つまり、Namespaceはアプリチームがどの配置選択肢を使えるかを決める境界になります。
たとえば、同じ組織の中でも、開発チーム、AI推論チーム、基幹業務チームでは、見せるべきOptional Policyが違います。
| Namespaceの例 | 見せたいOptional Policy | 見せないほうがよいもの |
|---|---|---|
| 開発/検証 | 低コスト検証、標準Linux配置 | 高価なGPU専用配置 |
| AI推論 | GPU推論向け、データ所在固定 | ライセンス最適化だけのWindows配置 |
| 基幹業務 | 規制対応、可用性優先 | 実験用の低コスト配置 |
Namespaceを細かく分けすぎると運用が複雑になりますが、すべてを1つにまとめるとOptional Policyの意味が薄れます。まずは部門、用途、規制有無、アクセラレータ利用有無の4軸で分けると、過剰な分割を避けながら実務に近い境界を作れます。
vSphere Compute Policyとホストタグが、配置ガバナンスの土台になる
GPU、Windowsライセンス、規制対象ゾーンなど、物理的な意味とタグを一致させます。
VM-Host affinityなどの配置ルールが手動テストでも期待通り働くか確認します。
Guest OSやCustom Labelなどで、どのVMにルールを適用するかを線引きします。
VCF Automation側のPolicyは、vSphere側の正しいタグとCompute Policyがあって初めて意味を持ちます。
Infrastructure Placement PoliciesをVCF Automation側だけで完結する機能として見ると、最も大事な前提を落とします。公式技術ブログでは、Infrastructure Policyは大きく2つの要素で構成されると説明されています。
1つ目はMatching Criteriaです。これは、どのVMにポリシーを適用するかを決める条件です。Guest OS、Guest OS Family、Custom LabelなどのVM属性を使い、Criteria Builderで条件を作ります。
2つ目はCompute Policy Referenceです。これは、vCenter側に存在するVM-Host affinity compute policyへの参照です。つまり、VCF Automationでポリシー名を作るだけではなく、vSphere側にタグ、カテゴリ、ホストグループ、Compute Policyが整っていることが前提になります。
ホストタグが古いと、きれいなポリシー名でも配置は正しくならない
配置ポリシーは、ホストタグやカテゴリの正しさに強く依存します。たとえば、GPU搭載ホストに付けたタグが棚卸し後に更新されていない、Windowsライセンス対象ホストが移設されたのにタグが残っている、特定データ所在向けクラスタのタグ命名が環境ごとに違う、といった状態では、VCF Automation側のPolicyだけをきれいにしても意味がありません。
導入前には、次のような棚卸しが必要です。
- ホストタグの命名規則があるか
- タグが実際のホスト構成と一致しているか
- vSphere Compute Policyが手動デプロイでも期待通り働くか
- VCF Automationから参照するPolicy名が運用者に理解できるか
- 廃止したホスト、移設したホスト、ライセンス対象外ホストにタグが残っていないか
タグ更新を変更管理に入れる
ホスト交換、クラスタ拡張、GPU増設、ライセンス対象ホストの変更があるたびに、タグとCompute Policyも変更対象になります。Infrastructure Placement Policiesを導入した後は、タグ更新をインフラ作業の付随タスクではなく、配置ルールを変える変更として扱うほうが安全です。
Infrastructure Placement Policiesは、vSphere Compute Policyを上位のセルフサービス運用に接続する仕組みです。したがって、導入の起点はVCF Automationの画面ではなく、vSphere側のタグとCompute Policyの実態確認です。
Criteria Builderは「便利な条件式」ではなく、影響範囲の線引きに使う
Criteria Builderでは、VM属性を条件としてポリシー適用対象を絞ります。公式技術ブログでは、Guest OS FamilyがLinuxであるVMを対象にする例が示されています。
ここで重要なのは、条件を細かく作れることではなく、条件が広すぎないことです。たとえば「Guest OS Family = Linux」だけで全Linux VMをGPUホストへ寄せると、汎用Linux VMまで高価なホスト群を消費する可能性があります。一方で条件を細かくしすぎると、利用者が付けるラベルやイメージ属性の揺れでポリシーが効かなくなります。
現実的には、次のように段階を分けるのが安全です。
| 段階 | 条件の例 | 目的 |
|---|---|---|
| 低リスク検証 | Custom Labelで明示したテストVMのみ | ポリシー評価と配置先を確認する |
| 用途別展開 | AI推論、Windows、規制対象などの用途ラベル | 利用者に説明できる範囲で自動化する |
| 必須化 | ライセンス、規制、データ所在など違反できない条件 | 条件を満たさない場合に止める |
Criteria Builderは、見た目には条件式の道具ですが、実際には責任範囲を決める道具です。どのVMまで自動配置の対象にするのか、どのVMは従来通り手動確認を残すのかを決める場所として扱うべきです。
AI private cloudでは、GPUだけでなくCPU、ライセンス、データ所在も配置条件になる
AI基盤では、高価なGPUを置く場所だけでなく、守るべきデータとライセンスの場所も配置条件になります。
VCF 9.1の公式発表では、AI推論やagentic AI、Kubernetes、VMを同じprivate cloud基盤で扱う方向が示されています。AI基盤というとGPUの確保が最初に見えますが、Infrastructure Placement Policiesの実務価値はGPUに限られません。
AI private cloudでは、次の配置条件が同時に動きます。
| 条件 | 配置で守りたいこと | 関係する運用判断 |
|---|---|---|
| GPU/アクセラレータ | 推論VMやAIサービスを適切なホストへ置く | GPU枯渇時の優先順位、OptionalにするかMandatoryにするか |
| CPU世代/命令セット | agentic workflowや前処理を適したCPUへ置く | GPUだけでなくCPUリソースをどう分けるか |
| Windowsライセンス | Windows VMを対象ホスト群に寄せる | ライセンス違反を防ぐためMandatoryにするか |
| データ所在 | モデル、ログ、個人情報、規制対象データを指定範囲へ収める | リージョン/ゾーン/Namespace設計 |
| ネットワーク到達性 | VPC、Transit Gateway、既存VLANとの関係を保つ | <a href="https://avgo-watch.blog.mo-gmo.com/avgo-38-vcf-91-vpc-network-span-placement-check/">VPC Network Span</a>やDTGW設計との整合 |
このように見ると、Infrastructure Placement Policiesは「AI用の新機能」に閉じません。AI時代に、従来からあったライセンス、規制、データ所在、性能、容量の配置判断をセルフサービス基盤へ持ち込むための機能です。
Private AI ServicesやVKSと一緒に見ると、責任分界が見えやすい
VCF 9.1では、Private AI Services、VKS、VCF Automation、VCF Operationsなどが同じprivate cloud運用の中でつながります。Private AI Servicesを導入する場合、Supervisor、NSX/VDS、VCF Automationの関係は別途確認が必要です。この点は<a href="https://avgo-watch.blog.mo-gmo.com/avgo-43-vcf-private-ai-services-nsx-vds-supervisor-check/">Private AI Servicesの導入前チェック</a>でも扱いました。
Infrastructure Placement Policiesは、その上で「どのワークロードをどこに置くか」を補います。たとえば、AI推論サービスはGPUホストへ寄せる、管理系VMは標準ホストに残す、特定部門のデータを特定ゾーンに留める、といった境界を作る役割です。
ここで注意したいのは、ポリシーが増えすぎるとセルフサービス体験が悪くなることです。利用者に見えるOptional Policyは少なく、基盤側で守るMandatory Policyは明確にする。これが崩れると、アプリチームは「どのポリシーを選べばいいのか分からない」となり、結局チケット運用に戻ります。
IaCと組み合わせるなら、ポリシー名と条件をコードレビュー対象にする
VCF 9.1では、SDDC Manager API、VCF Automation、Terraformなどを使ったInfrastructure as Codeの関心も高まっています。<a href="https://avgo-watch.blog.mo-gmo.com/avgo-44-vcf-91-iac-sddc-manager-api-terraform-check/">VCF 9.1のIaC確認記事</a>で整理した通り、APIやTerraformを使う場合は、操作できることよりも、どこまで標準化するかが重要です。
Infrastructure Placement PoliciesをIaC運用に乗せるなら、ポリシー名、Criteria Builder相当の条件、Region Quotaへの割り当て、Namespaceで見せるOptional Policyをコードレビュー対象にする必要があります。
特に、次の変更は「ただの設定変更」ではなく、配置先を変える変更として扱うべきです。
- Mandatory Policy化する
- 対象VM条件を広げる
- 参照するvSphere Compute Policyを差し替える
- Region Quotaへの割り当てを変える
- NamespaceにOptional Policyを追加する
- ホストタグの意味を変える
これらは、VMの置き場所、ライセンス、コスト、可用性、規制対応に影響します。IaCにするほどレビューしやすくなりますが、レビュー項目を決めないまま自動化すると、影響範囲が見えにくくなります。
導入前チェックリストで、必須化する前に止まる
- 目的を一文化
何を守るためのポリシーかを、利用者にも分かる言葉で書きます。
- vSphereで検証
Compute Policy、ホストタグ、対象ホストの整合を手動配置で確認します。
- Criteriaを絞る
Custom Labelなどで対象を狭く始め、配置結果を確認してから広げます。
- 失敗時を説明
止まった理由、利用者が直せること、基盤側が直すことを分けます。
Mandatory Policyは、止まってよい条件だけに使うとセルフサービスの信頼を保ちやすくなります。
Infrastructure Placement Policiesは、導入するとすぐに価値が出る機能に見えます。ただ、Mandatory化する前に止まるポイントを作っておかないと、セルフサービスの使いやすさを落とす可能性があります。
導入前には、次のチェックリストで設計を止めるとよいでしょう。
1. 何を守るためのポリシーかを一文で説明できるか
ポリシー名だけでなく、目的を一文で説明します。
| 悪い例 | 良い例 |
|---|---|
| High Performance | AI推論VMをGPU搭載ホスト群へ配置する |
| Windows Policy | Windows Server VMをライセンス対象ホスト群へ配置する |
| Compliance | 個人情報を扱うVMを指定ゾーン内に配置する |
目的が曖昧なポリシーは、Optionalにしても使われにくく、Mandatoryにするとトラブルの原因になります。
2. vSphere側で手動配置テストが通っているか
VCF AutomationでPolicyを作る前に、vSphere Compute Policy、カテゴリ、タグ、対象ホストの整合を確認します。手動で条件を満たすVMを置いたときに期待通り働かないなら、VCF Automation側で包んでも改善しません。
確認する項目は次の通りです。
- 対象ホストに正しいタグが付いている
- 対象外ホストに古いタグが残っていない
- VM-Host affinity Compute Policyが期待通り評価される
- ホストメンテナンス、クラスタ拡張、ホスト交換時のタグ更新手順がある
- 例外対応の承認フローがある
3. Criteriaが広すぎないか
最初からGuest OS Familyだけで広く適用すると、対象外のVMまで巻き込む可能性があります。初期導入では、Custom Labelなどでテスト対象を明示し、ログや配置結果を確認してから条件を広げるほうが安全です。
たとえば、ai-inference=true のようなラベルを付けた検証VMだけを対象にして、実際にどのゾーンやホストへ置かれるかを見ます。その後、AI推論用の標準イメージやNamespaceと組み合わせて対象を広げると、影響を追いやすくなります。
最初の対象は限定する
初回は、本番全体ではなく、1つのテストNamespace、1つのRegion Quota、明示ラベルを付けた少数のVMから始めます。期待通りのホストに置かれること、条件を満たさない場合に失敗が説明できること、監視で変化を追えることを確認してから対象を広げます。
4. Mandatoryにしたときの失敗メッセージを説明できるか
Mandatory Policyは、条件を満たせない場合にデプロイやNamespace作成を止める可能性があります。利用者にとって重要なのは、止まること自体ではなく、なぜ止まったのかが分かることです。
導入前に、次の説明を用意しておきます。
- どの条件に合わなかったのか
- 利用者が直せる問題か、基盤チームが直す問題か
- 別のNamespace、別のイメージ、別のOptional Policyで回避できるのか
- 例外申請が必要な場合、どこに出すのか
この説明がないMandatory Policyは、ガバナンスではなく障害として受け止められます。
5. Day-2変更で配置が変わる前提を運用に入れているか
公式技術ブログでは、Optional PolicyをDay-2で変更した場合、VCF Automationが継続的に評価し、必要に応じて配置ルールに準拠するようにする説明があります。これは便利ですが、移動が起きる可能性を運用に入れておく必要があります。
たとえば、Optional Policyを追加した結果、VMが別ホストへ移る可能性があるなら、メンテナンス時間、性能影響、監視アラート、バックアップ/復旧手順も一緒に確認します。
「ポリシーを変えるだけ」と見なすのではなく、「配置条件を変える変更」として変更管理に入れるのが安全です。
6. 監視とコスト可視化の見方が決まっているか
配置ポリシーを入れると、特定ホスト群への負荷集中や高価なアクセラレータの利用率変化が起きます。VCF Operationsやコスト可視化と組み合わせて、次の指標を見られるようにしておきます。
- ポリシー別またはNamespace別のVM数
- GPU/CPU/メモリの利用率
- Windowsライセンス対象ホストの収容率
- 規制対象ゾーンの容量余力
- ポリシー変更後の移動・失敗・リトライの発生状況
配置ポリシーは、設定して終わりではありません。設定した結果、狙ったホスト群にどれだけ負荷が寄ったか、別のチームのリソースを圧迫していないかまで見て初めて、運用に乗ったと言えます。
まとめ：Infrastructure Placement Policiesは、自由に使わせるための制約である
- 1土台
vSphereのタグとCompute Policyを棚卸しします。
- 2責任範囲
MandatoryとOptionalを、誰が責任を持つ条件かで分けます。
- 3適用範囲
Region QuotaとNamespaceで、効かせる範囲を決めます。
- 4運用
Day-2変更、監視、失敗時説明まで含めて導入します。
配置ポリシーは制約ですが、正しく使うと利用者が安心してセルフサービスを使うための土台になります。
Infrastructure Placement Policiesは、利用者の自由を削るための機能ではありません。むしろ、基盤側が守るべき条件を明確にすることで、アプリケーションチームが安心してセルフサービスを使えるようにするための制約です。
導入判断では、次の順に見れば大きく外しにくくなります。
- まずvSphere側のタグとCompute Policyを棚卸しする
- 配置ルールをMandatoryとOptionalに分ける
- Region QuotaとNamespaceで効く範囲を決める
- Criteria Builderの条件を狭く始める
- Day-2変更、監視、失敗時説明まで運用に入れる
VCF 9.1はAI、Kubernetes、VMを同じprivate cloud基盤で扱う方向へ進んでいます。その中でInfrastructure Placement Policiesは、GPUやCPUの物理リソース、Windowsライセンス、データ所在、規制対応、組織別の責任分界を、セルフサービスの裏側で整える機能として見るのが実務的です。
Mandatoryにするほど強く、Optionalにするほど柔らかい。そう覚えるよりも、「誰が責任を持つ配置条件なのか」で分けるほうが、実際の運用に合います。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "VCF Breakroom Chats Episode 87 – Governing the AI Private Cloud: Deep Dive into VCF 9.1 Infrastructure Placement Policies"（確認日: 2026-06-14）
https://blogs.vmware.com/cloud-foundation/2026/06/11/vcf-breakroom-chats-episode-87-governing-the-ai-private-cloud-deep-dive-into-vcf-9-1-infrastructure-placement-policies/
- VMware Cloud Foundation Blog, "Mastering Infrastructure Policies in VMware Cloud Foundation Automation 9.1"（確認日: 2026-06-14）
https://blogs.vmware.com/cloud-foundation/2026/05/28/vcf-automation-infrastructure-policies/
- VMware Cloud Foundation Blog, "Accelerate, Streamline, and Control Your Self-Service Private Cloud with VMware Cloud Foundation 9.1"（確認日: 2026-06-14）
https://blogs.vmware.com/cloud-foundation/2026/05/05/accelerate-streamline-and-control-your-self-service-private-cloud-with-vcf-9-1/
- Broadcom News, "Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI"（確認日: 2026-06-14）
https://news.broadcom.com/releases/broadcom-announces-vmware-cloud-foundation-9-1
- VMware Cloud Foundation Automation product page（確認日: 2026-06-14）
https://www.vmware.com/products/cloud-infrastructure/vcf-automation