Broadcomが2026年6月11日に公開したVMware Cloud Foundation Blogは、VCF Private AI ServicesをNSXあり、またはNSXなしのVDS構成で動かす時のSupervisor設計を説明している。この記事で重要なのは、AIモデルの機能紹介より先に、vSphere Supervisorのネットワーク構成を決める必要がある点だ。
VCF Private AI Servicesは、Model Gallery、Model Runtime、Agent Builder、Data Indexing、RAG、API Gateway、MCP Tools Registryなどを含むAIアプリケーション基盤として説明されている。ただし、利用者がセルフサービスで使えるか、管理者が手動で支えるか、後からNSXへ広げる時にどれだけ手戻りが出るかは、SupervisorをNSX-backedにするかVDS-backedにするかで大きく変わる。
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.1のvSANストレージを見直す前に確認する：Storage Policy、Stretch Cluster、VCF Operationsの実務ポイント も合わせて確認してください。Private AI Servicesの利用者を増やす前に、AI private cloudの配置ガードレールをどう置くかを確認できます。
Private AI ServicesはvSphere Supervisorの上で動くため、最初の分岐はNSX-backedかVDS-backedかです。
VCF Automation、multi-tenancy、GPU quota、guided wizardを使う前提なら、NSX VPCへの依存を確認します。
VDS-backedで始めてNSX-backedへ移る場合は、単純な設定変更ではなくSupervisor再展開を含めて見積もります。
PoCを速く始める判断と、本番AI基盤として広げる判断を分けると、後の手戻りを見積もりやすくなります。
- VCF Private AI ServicesはvSphere Supervisorの上で動くため、導入前の最初の分岐はAI機能ではなくSupervisorのネットワーク構成になる。
- VCF Automationでセルフサービス、multi-tenancy、GPU quota、guided wizardを使う前提なら、公式BlogはNSX VPCへの依存を明示している。NSXなしのVDSモデルでは、インフラ層の有効化やendpoint展開を管理者がCLI、YAML、kubectlで支える前提になる。
- VDS-backed SupervisorはPoCを速く始める選択肢になり得るが、後からNSX-backedへ移る場合は単純な設定変更ではなく、Supervisor再展開を含む計画変更として見積もる必要がある。
まず決めるのはAI機能ではなくSupervisorのネットワーク
- 1Supervisorとnamespace
vSphere Supervisorを有効化し、AIプロジェクトごとのvSphere NamespaceとKubernetes configurationを用意します。
- 2ネットワークとload balancer
NSX-backedならVPCやNSX Edge、VDS-backedなら外部load balancerを含めて入口を決めます。
- 3VKS workerとGPU
model endpointはVKS worker VM上のpodとして動き、ESXiホストの物理GPUに接続します。
- 4AI機能と外部DB
Model Runtime、Data Indexing、RAG、Agent Builderを使う前に、External Postgres DBなどの外部前提も確認します。
AI画面でできることだけを見ると、namespace、GPU、network、load balancer、databaseの前提条件を見落としやすくなります。
VCF Private AI Servicesの記事を読むと、Model Gallery、Model Runtime、Agent Builder、Data Indexing、RAG、API Gateway、MCP Tools RegistryといったAI側の機能に目が行きやすい。導入担当者にとっては魅力的な名前が並ぶが、最初に止めるべき論点はそこではない。公式Blogは、VCF Private AI Servicesの土台をvSphere Supervisorと説明し、Supervisorを有効化することでAPIとリソース管理レイヤーが用意されると整理している。
つまり、AI利用者がモデルendpointやknowledge baseを触る前に、基盤側ではSupervisor、namespace、load balancer、GPU付きVKS worker、外部データベースなどの前提が動いている。ここを曖昧にしたまま「Private AIのPoCを始める」と、後でセルフサービス化や部門別分離に進む段階で、ネットワーク構成から見直すことになりやすい。
Private AI ServicesはSupervisorの上で動く
根拠
公式Blogは、Private AI Servicesが宣言的なKubernetesモデルで動くと説明している。大きく分けると、Supervisorレベルに置かれるPrivate AI ServicesのOperatorと、namespaceレベルで適用されるKubernetes configurationがある。管理者はvSphere Namespaceを用意し、そこにAIプロジェクトごとの構成を与える。Operatorはその構成を見て、API pod、UI backend pod、data indexing workersなどの基礎コンポーネントを展開する。
注意点
AI推論の実行面では、model endpointがVKS worker VM上のpodとして動き、ESXiホストの物理GPUに安全に接続する構成として説明されている。ここで大事なのは、AIサービスが単独のSaaS画面として完結するわけではないことだ。Supervisor、VKS、GPU、namespace、ネットワーク、ロードバランサが揃って、初めて利用者向けのAI体験が成立する。
確認項目
さらに、公式BlogはExternal Postgres DBの扱いにも触れている。RAG workloads向けのvector databaseに接続するが、そのdatabase自体はPrivate AI ServicesのOperatorが自動で作るものではなく、外部前提として用意される。これも導入チェックに入れるべきだ。AI画面でできることだけを見ていると、基盤側の前提条件を見落とす。
NSX/VDSの選択は利用者体験まで変える
根拠
VCF 9では、SupervisorにNSX-backed modelとVDS-backed modelの2つのネットワーク構成がある。NSX-backedはsoftware-defined overlay networkingを使い、segments、Virtual Private Clouds、distributed firewalling、NSX Edge clustersによるload balancingを扱う。VDS-backedは既存のvSphere Distributed Switchを使い、Kubernetes APIやworkload trafficのingress/egressに外部load balancerを組み合わせる。
評価基準
この違いは、単なるネットワーク部品の違いではない。NSX-backedを選ぶと、VCF AutomationとNSX VPCを軸に、利用者へself-service catalogやguided wizardを出しやすくなる。VDS-backedを選ぶと、既存VLAN運用に寄せて速く始められる一方、VCF Automationのmulti-tenant consumption layerを使わない前提になり、管理者の手動作業が増える。
確認項目
導入レビューでは、次のように問いを変えると判断しやすい。
| 判断項目 | 先に決めること |
|---|---|
| 利用目的 | PoCを速く回すのか、本番のAI基盤を作るのか |
| 利用者数 | 1チーム限定か、複数部門やtenantに広げるのか |
| セルフサービス | data scientistが自分でAI Kubernetes clusterやmodel endpointを出すのか |
| 統制 | CPU、memory、GPU quota、approval、auditをどこで見るのか |
| ネットワーク | NSX VPCやmicro-segmentationが必要か、既存VLANで足りるか |
| 将来変更 | VDSからNSXへ進む時のSupervisor再展開を許容できるか |
VCF 9.1のAI機能を評価するなら、まずこの表を関係者で埋めた方がいい。モデルの精度や応答速度は大切だが、誰が環境を作り、誰が権限とGPU quotaを管理し、どこまで自動化するかが決まっていないと、PoCの結果を本番設計へつなげにくい。
NSX-backed SupervisorはセルフサービスAI基盤を狙う構成
部門、project、データ機密度ごとにnamespaceとVPCをどう分けるかを確認します。
高価なGPU資源を誰が割り当て、部門別やproject別の上限をどう説明するかを決めます。
Deep Learning VM、AI Kubernetes cluster、LLM model endpointを利用者がどこまで要求できるかを分けます。
endpoint作成、model変更、knowledge base更新のログをどこで追うかを設計します。
NSX、VCF Automation、Private AI Services UIの担当を分け、障害時の切り分け先を明確にします。
NSX-backedを選ぶ理由は高機能だからではなく、VCF Automationを含む消費、分離、統制の運用モデルを作りやすい点にあります。
NSX-backed Supervisorを選ぶ理由は、「NSXの方が高機能だから」という言い方では足りない。公式Blogが強調しているのは、VCF Automationを使ったconsumption layer、multi-tenancy、governance、workflow automationだ。Data scientistやMLOpsが自分でDeep Learning VM、AI Kubernetes cluster、LLM model endpointを展開するような利用者体験を作りたいなら、NSX-backedを中心に設計する理由が強くなる。
BroadcomのVCF 9.1発表でも、production AI、multi-tenant infrastructure、security boundaries、GPU/CPU resource utilizationといった文脈が出てくる。Private AI Servicesを単発PoCではなく、部門横断のAI基盤として扱うなら、ネットワークの選択は開発者体験と統制の選択でもある。
VCF Automationを使うならNSX依存を前提にする
根拠
公式Blogは、VCF AutomationがNSXに厳密に依存し、multi-tenant self-service experienceのためにNSX Virtual Private Cloudsを使うと説明している。NSXがない場合はVPCを作成できず、そのためVCF Automationを使えない、という整理だ。
条件
ここは導入判断に直結する。VCF Automationを使うと、IT側はtenantごとに分離されたvSphere Namespaceを割り当て、CPU、memory、GPU quotaなどのguardrailsを適用できる。利用者側はself-service catalogからDeep Learning VMやAI Kubernetes clusterを要求し、Build & Deploy tabのguided wizardでLLM model endpointを展開できる。
この流れを前提にするなら、NSX-backed Supervisorを第一候補に置くべきだ。特に、複数部門でGPUを共有する、AI endpointを利用者にオンデマンド提供する、approvalやquotaを運用に入れる、といった要件がある場合は、VDS-backedで始めて後から考えるより、最初からVCF Automationを使う前提で設計した方が手戻りを減らせる。
関連確認
VCF Automation側の設計は、既存記事のVCF Automation 9.1のNamespace Blueprint確認ともつながる。Private AI Servicesだけを見ず、namespace、blueprint、catalog、policyを同じ設計レビューに載せたい。
マルチテナントとgovernanceはネットワーク機能だけで語らない
注意点
NSX-backedにすれば自動的に本番品質になるわけではない。NSX VPC、distributed firewalling、Edge cluster、overlay networkingは強力だが、それぞれ設計と運用が必要になる。特に、stateful routingやVCF Automationを支えるNSX Edge clusterには、サイズ、可用性、監視、障害時の責任分界がある。
評価基準
本番AI基盤で見るべき観点は、次のようにネットワークの外側まで広がる。
| 観点 | 確認すること |
|---|---|
| tenant分離 | 部門、プロジェクト、データ機密度ごとにnamespaceとVPCをどう切るか |
| GPU quota | 高価なGPU資源を誰が割り当て、上限をどう説明するか |
| self-service | 利用者が申請なしで作れる範囲と、承認が必要な範囲を分けるか |
| audit | endpoint作成、model変更、knowledge base更新のログをどこで追うか |
| セキュリティ | モデル、prompt、RAGの入力データ、監査ログをどの境界で守るか |
| 運用習熟 | NSX、VCF Automation、Private AI Services UIの担当を分けるか |
VCF 9.1のVPC Network Span確認記事で扱ったように、VPCやTransit Gatewayの範囲はworkload placementや外部接続にも影響する。Private AI ServicesでNSX-backedを選ぶなら、AI endpointだけでなく、VPC、TGW、routing、policy、tenant境界まで同じ設計図に入れる必要がある。
本番AI基盤では将来の利用者数から逆算する
条件
PoCでは、1つのモデルendpointが動けば成功に見える。しかし、本番では利用者数、tenant数、namespace数、GPU pool、model endpoint数、外部PostgreSQL、ログ/監査の所在が増える。ここで最初のSupervisor構成が効いてくる。
例えば、最初は1部門のRAGだけでも、半年後に複数部門がAgent Builderを使い、model endpointを増やし、GPU quotaの調整を求めるかもしれない。その時にVCF Automationがない構成だと、管理者が申請受付、namespace作成、YAML適用、endpoint展開、ログ確認を手でつなぐことになる。運用担当が少ないほど、この負担は早く限界に来る。
注意点
NSX-backedは、将来のself-service AI cloudを狙う構成として読むとわかりやすい。一方で、NSX Edge、overlay networking、VCF Automationの設計負荷も受け入れる必要がある。単純な機能比較ではなく、「今のPoCを速くすること」と「半年後の本番化を速くすること」を別々に評価したい。
VDS-backed Supervisorは速く始める代わりに運用境界を明確にする
Private AI Servicesを試す対象がPoCか本番か、PoCの終了条件は何かを先に決めます。
シンプルなSupervisor立ち上げの入口として見つつ、scaleやservicesの制約はPoCで検証します。
本番寄りのAI endpoint traffic、監視、LB policyが必要になった時の選択肢として確認します。
VCF Automationなしで、namespace、endpoint、GPU、networkを誰が支えるかを明記します。
NSX-backedへ進む判断基準とSupervisor再展開の影響を、PoC開始時点から残します。
VDS-backedは価値が低い構成ではありません。速く始める選択肢として使うなら、管理者依存の範囲を隠さないことが条件です。
VDS-backed Supervisorは、NSXを使わないから価値が低い、という話ではない。公式Blogも、VDS modelを既存のvSphere Distributed Switchに基づく正規の選択肢として説明している。すでにVLAN運用が整っていて、まずPrivate AI Servicesのmodel endpointやRAGの流れをPoCしたい場合、VDS-backedは現実的な入口になり得る。
ただし、速く始められることと、本番のself-service基盤として十分であることは別だ。VDS-backedを選ぶなら、Foundation Load BalancerまたはAvi Load Balancerをどう使うか、VCF Automationなしの運用を誰が支えるか、将来NSXに移る時の再展開をどう扱うかを最初に決めておく必要がある。
Foundation Load BalancerはPoCの入口として見る
根拠
公式Blogは、VDS-backed Supervisorで使うload balancerの選択肢としてFoundation Load BalancerとVMware Avi Load Balancerを挙げている。Foundation Load BalancerはVCF 9で導入されたnative lightweight Layer-4 load balancerで、platformに同梱され、1台または2台VMのactive/passive高可用性構成で展開できると説明されている。
注意点
この説明から読むべきことは、FLBは「PoCやシンプルなSupervisor立ち上げを軽くする部品」だということだ。外部アプライアンスを用意せずに始めやすい一方、公式Blogはscaleとservicesに制約があるとも述べている。したがって、全社本番のAI endpointや高負荷RAG APIの入口として万能視しない方がいい。
確認項目
導入レビューでは、FLBを選ぶ前に次を確認したい。
- Private AI Servicesを試す対象はPoCか、本番か。
- model endpointへのアクセスは少数利用者か、多数のアプリケーションか。
- 高可用性の要件はactive/passiveで足りるか。
- 障害時に誰がFLB、Supervisor、VKS、Private AI Services UIを切り分けるか。
- 本番化時にAviやNSX Edgeへ進む判断基準を先に置くか。
この段階では、未確認の性能値を作らないことが大切だ。公式資料に規模上限や性能保証が確認できないなら、「検証項目」としてPoCで測る。数字を先に決めると、後で公式サポート条件とずれる。
Avi Load Balancerはscale要件が見えた時の選択肢にする
条件
VDS-backedでより重いAI endpoint trafficやenterprise networking requirementsがある場合、公式BlogはVMware Avi Load Balancerをpremium optionとして説明している。AviはController ClusterとService Engineを持つため、FLBより構成は重くなるが、より大きなscaleや複雑な要件に向く。
注意点
ここでも大事なのは、Aviを入れればPrivate AI Servicesの全課題が解けるわけではないことだ。Aviはload balancingの選択肢であり、VCF Automationのmulti-tenant consumption layerを補うものではない。VDS-backedのままでは、NSX VPCに依存するVCF Automationを使う前提にはならない。
評価基準
したがって、Aviを検討する時は、次の2つを分けて考える。
| 問い | 見る場所 |
|---|---|
| AI endpoint trafficをどう受けるか | Avi Controller、Service Engine、LB policy、監視 |
| 利用者がself-serviceでendpointを作るか | VCF Automation、NSX VPC、namespace、quota |
本番AI基盤では、この2つを混同しない方がいい。Aviは通信入口の設計を強くする。一方、利用者体験と統制をどう提供するかは、VCF AutomationとNSX-backed Supervisorの領域になる。
VDSモデルでは管理者の手動作業を隠さない
根拠
公式Blogは、VCF AutomationなしのVDS modelでは、overarching multi-tenant consumption layerがなくなると説明している。Private AI Servicesをnamespaceで有効化し、model endpointを展開するインフラ層の作業は、管理者がVCF consumption CLI、YAML manifests、kubectlで手動実施する前提になる。
注意点
この手動運用は、PoCではむしろ都合がよいこともある。管理者が構成を直接見ながら、GPU割り当て、network reachability、model endpoint、RAG indexing、Agent Builderの流れを短く試せるからだ。しかし、利用者が増えた瞬間に、同じ手順はボトルネックになる。申請が増え、namespaceが増え、endpointが増え、YAML変更のレビューと切り戻しが必要になる。
VDS-backedを選ぶなら、記事の結論は「VDSでよい」ではなく、「どこまでをVDSで支え、どこからNSX-backedとVCF Automationに進むか」になる。特に、Private AI ServicesをAI基盤の標準サービスとして出す予定があるなら、PoC開始時点で移行条件を書いておきたい。
関連確認
Private AI ServicesのVKS workerやAI Kubernetes clusterの設計は、VKS on VCF 9.1の3ゾーン/VPC/VDS/Antrea/LB確認とも重なる。VDS-backedのPoCでKubernetes側を深掘りする場合は、SupervisorだけでなくVKS側のzone、network、load balancerも併せて見るべきだ。
Private AI Services UIとVCF Automationを混同しない
UIがあることと、AI基盤の払い出しがセルフサービスになることは別です。前段のインフラ消費をどこで統制するかを分けて見ます。
Private AI Servicesで特に誤解しやすいのが、VCF AutomationとPrivate AI Services UIの役割分担だ。公式Blogは、VCF Automationがprivate cloudのconsumption layerであり、multi-tenancy、governance、workflow automationを提供すると説明している。一方、Private AI Services UIは、model endpointが動いた後のapplication layerで使う画面として説明されている。
この違いを混同すると、「VDSでもPrivate AI Services UIがあるなら、同じセルフサービス体験になる」と読んでしまう。しかし、公式Blogの整理ではそうではない。VCF Automationがない場合でも、model endpoint稼働後にknowledge baseへdocumentを追加し、data indexing jobsを動かし、Agent Builderでagentを作るUIは使える。一方、endpointを作るインフラ層のself-serviceやtenant分離は別の話だ。
VCF Automationは消費と統制の入口になる
評価基準
VCF Automation側で見るべき役割は、利用者がインフラをどう消費するかだ。namespace assignment、resource guardrails、CPU/memory/GPU quota、self-service catalog、guided wizard、workflow automationがここに含まれる。Private AI Servicesを本番のAI基盤として出すなら、この層がないと運用は管理者依存になりやすい。
特にGPUは高価で不足しやすい。利用者が増えるほど、「誰が何個使っているのか」「どの部門のendpointを優先するのか」「停止時の責任は誰か」が問題になる。VCF Automationを使う構成では、こうした消費と統制をplatform側に寄せやすい。VDS-backedで手動運用を続ける場合は、同じ統制を別の手段で補う必要がある。
Private AI Services UIはendpoint稼働後のアプリケーション層で使う
条件
Private AI Services UIは、AI利用者に近い画面だ。model endpointが動いた後、knowledge baseへのdocument追加、data indexing job、Agent Builderなどを扱う。TechDocsのoverviewでも、Model Gallery、Model Runtime、Data Indexing、Agent Builderなどのモジュールが示されている。
注意点
ただし、UIがあることと、AI基盤の払い出しがセルフサービスになることは別だ。利用者がAgent Builderを触れるようにするには、その前にendpoint、namespace、GPU、network、database、権限が揃っていなければならない。VDS-backedでは、その前段を管理者が支える範囲が大きくなる。
確認項目
役割分担は次のように切ると整理しやすい。
| 役割 | 主に見るもの | 間違えやすい点 |
|---|---|---|
| Platform admin | Supervisor、namespace、VCF Automation、quota | AI UIだけ見て基盤前提を省略する |
| Network admin | NSX/VDS、VPC、FLB、Avi、Edge、routing | LBの選択とself-serviceの可否を混同する |
| MLOps | Model Gallery、Model Runtime、endpoint、runtime更新 | endpointを作る権限とmodelを使う権限を混同する |
| Data scientist | knowledge base、data indexing、Agent Builder | modelが動く前のnamespace/GPU準備を見落とす |
この表を事前に合意しておくと、PoCの評価も変わる。単にagentを作れたかではなく、誰がendpointを作り、誰がGPUを割り当て、誰がログを見たかまで記録できる。
利用者向けに見せる機能と管理者が裏で作るものを分ける
注意点
AI基盤の記事では、利用者画面の話だけが前に出やすい。しかし導入企業にとっては、裏側で作るものの方が失敗原因になりやすい。Supervisor control plane VMのsizing、namespace設計、load balancer、外部PostgreSQL、GPU pool、監視、ログ、証明書、identity、security reviewが揃っていなければ、Private AI Services UIだけでは本番運用に届かない。
公式Blogには、Supervisor control plane VMはSmall、Medium、Largeでsizeを選び、scale upはできるがscale downはできないという注意もある。この点はPoCでも軽く扱わない方がいい。小さく始めることは大切だが、後から下げられない前提なら、PoC用の最小構成と本番想定の構成を分けて記録する必要がある。
後から変える前提なら再展開コストを先に見積もる
- 移行条件を決める
利用者が増えた時、GPU quotaが部門別になった時、approvalが必要になった時など、移行の合図を明文化します。
- Supervisor再展開を見積もる
VDSとNSXはnetworking fabricが異なるため、planned redeploymentの影響を確認します。
- namespaceとendpointを見直す
既存namespace、権限、model endpoint、利用者アプリケーションの接続先変更を整理します。
- 外部DBとGPUをそろえる
knowledge base、External Postgres DB、GPU割り当て、VKS workerの再構成を確認します。
- 停止影響と切り戻し
DNS、証明書、load balancer、routing、利用者に許容される停止時間を見積もります。
PoCの速さと本番化の速さは別です。VDS-backedで始めるなら、本番化へ進む条件と再展開時の作業を先に書いておきます。
VDS-backedで始めて、後からNSX-backedへ移る。この流れ自体は自然だ。PoCの段階では既存VLANで素早く試し、利用者が増えたらNSX VPC、VCF Automation、self-service catalogへ進む判断はあり得る。ただし、公式Blogはこの移行を単純な設定変更とは扱っていない。
VDSとNSXは、physical VLAN-backed port groupsとsoftware-defined overlay segmentsという根本的に異なるnetworking fabricsを使う。そのため、VDS modelからNSXへ進む場合は、Supervisorのplanned redeploymentを伴うと説明されている。ここを軽く見ると、PoC環境をそのまま本番化できると誤解する。
VDSとNSXは同じSupervisor設定の差分ではない
根拠
導入前レビューでは、「あとでNSXにすればよい」という表現を避けたい。正確には、あとでNSX-backedにするなら、Supervisor再展開、namespace再設計、model endpoint再作成、利用者移行、停止影響、切り戻しを見積もる必要がある。
確認項目
再展開時に問題になりやすいのは、次の項目だ。
- 既存namespaceと権限の移し方。
- model endpointの再作成と利用者アプリケーションの接続先変更。
- knowledge baseと外部PostgreSQLの整合性。
- GPU割り当てとVKS workerの再構成。
- DNS、証明書、load balancer、routingの変更。
- 利用者に許容される停止時間。
- PoCで作ったYAMLや運用手順を本番テンプレートにできるか。
これらは製品の欠点というより、設計変更の現実だ。VDS-backedで始めるなら、移行条件を先に書いておけばよい。「利用者が3部門を超えたら」「GPU quotaが部門別になったら」「approvalが必要になったら」「model endpointをセルフサービス化したくなったら」など、NSX-backedへ進む合図を決めておく。
PoCの速さと本番化の速さは別に評価する
評価基準
PoCを速く始めることは価値がある。Private AI ServicesでRAGやAgent Builderの流れを試し、AI利用者がどの機能を必要とするかを短期間で確認できるからだ。VDS-backedとFLBは、その入口として合うことがある。
一方、本番化の速さは別の指標だ。本番化では、tenant isolation、GPU quota、security review、audit、self-service catalog、endpoint lifecycle、monitoring、cost visibilityが必要になる。PoCでこれらを測らずに「モデルが動いたから成功」とすると、本番化直前で設計が止まる。
確認項目
PoCでは、次のような記録を残したい。
| PoCで測ること | なぜ必要か |
|---|---|
| endpoint展開手順 | 管理者手動か、利用者self-serviceかを分けるため |
| namespace作成時間 | 利用者申請から利用開始までのlead timeを見るため |
| GPU割り当て | quota、優先度、空き容量の会話に進めるため |
| LB経由の到達性 | FLB/Avi/NSX Edgeのどこが必要か見るため |
| Private AI Services UI操作 | 利用者がAgent BuilderやData Indexingを扱えるか見るため |
| ログ追跡 | 障害時にplatform admin、network admin、MLOpsが切り分けられるか見るため |
モデル応答速度だけを測るPoCは、Private AI Servicesの導入判断としては浅い。運用者がどこまで手で支えたか、どの手順をself-serviceにしたいかまで残すべきだ。
最初の設計レビューで決めることを明文化する
確認項目
最初の設計レビューでは、次の項目を決めてから構築へ進むとよい。
- NSX-backed Supervisorか、VDS-backed Supervisorか。
- VCF Automationを使うか。
- self-service catalogを出すか。
- Foundation Load Balancerで始めるか、Aviを使うか。
- NSX Edge clusterの運用準備があるか。
- namespaceとtenantの単位をどう切るか。
- GPU quotaの責任者は誰か。
- 外部PostgreSQLなどの前提を誰が用意するか。
- Private AI Services UIの利用者と管理者をどう分けるか。
- 監視ログとaudit logをどこで見るか。
- VDSからNSXへ進む条件と停止許容時間をどう定義するか。
- 公式TechDocsとRelease Notesの更新確認を誰が担当するか。
このリストは、AI基盤の設計レビューを「ネットワーク担当だけの話」や「AIチームだけの話」にしないためのものだ。Private AI ServicesはAIアプリケーション層と基盤運用層をまたぐため、最初から複数ロールで見た方がよい。
導入前チェックリストに落とす
Yesが多いからNSXという単純な足し算ではなく、AI基盤をサービスとして提供するかどうかで見ます。
ここまでの内容を、導入前チェックリストに落とす。目的は、NSX-backedとVDS-backedのどちらが優れているかを機械的に決めることではない。VCF Automation、multi-tenancy、self-service、将来の再展開コストを見たうえで、今の組織がどちらを運用できるかを判断することだ。
| 判断項目 | NSX-backedなら見ること | VDS-backedなら見ること | 未決時の担当 |
|---|---|---|---|
| 本番AI基盤かPoCか | 本番ならtenant、quota、auditを設計する | PoCの範囲と終了条件を決める | Platform owner |
| VCF Automation | NSX VPCとcatalog設計を確認する | 使わない前提の手動運用を明記する | Platform admin |
| self-service catalog | Deep Learning VM、AI Kubernetes cluster、endpointの払い出し範囲を決める | 管理者がどこまで作るかを決める | MLOps |
| tenant isolation | VPC、namespace、policyを分ける | VLAN、namespace、運用手順で補う範囲を見る | Network admin |
| GPU quota | 部門別、project別の上限を設定する | 手動割り当てと申請ルールを作る | Platform admin |
| NSX Edge | sizing、冗長化、監視、障害対応を決める | 原則不要だが将来移行条件を残す | Network admin |
| Foundation Load Balancer | 通常は中心ではない | PoCや小規模入口として検証する | Network admin |
| Avi Load Balancer | NSX構成との関係を確認する | 大きなtrafficやenterprise要件で検討する | Network admin |
| CLI/YAML/kubectl運用 | 例外運用に留めるか決める | 標準手順として責任者を置く | Platform admin |
| Supervisor sizing | 本番想定で上げすぎ/下げられない前提を見る | PoC構成と本番構成を分ける | Infrastructure admin |
| 外部PostgreSQL | RAG workloadsの前提として運用責任を置く | PoCでもデータ保護とbackupを見る | Data platform owner |
| 将来移行 | NSX前提なら初期から構成を固める | NSXへ進む条件と再展開計画を置く | Architecture board |
この表で特に重みを置きたいのは、VCF Automation、multi-tenancy、self-service、将来移行コストの4つだ。Yesが多いからNSXという単純な足し算ではなく、利用者にAI基盤をサービスとして提供するかどうかで見る。
PoCで止めずに本番化へつなぐ確認項目
確認項目
PoCをするなら、model endpointが動いたかだけで終わらせない。次の項目をPoCログに残すと、本番化判断に使いやすい。
- 誰がnamespaceを作ったか。
- 誰がPrivate AI Servicesを有効化したか。
- 誰がmodel endpointを展開したか。
- どの操作がVCF Automationで、どの操作がPrivate AI Services UIか。
- GPU割り当ては誰が承認したか。
- endpoint停止時にどのログを見たか。
- FLBまたはAviでどこまで到達性を確認したか。
- RAG用の外部PostgreSQLを誰が運用するか。
- Agent Builderを使う利用者にどの権限を渡したか。
- 本番化時にNSX-backedへ移る必要があるか。
この記録がないPoCは、デモとしては成功しても、導入判断には弱い。Private AI ServicesはAI利用者とplatform運用者の境界にあるため、運用者が支えた部分を見える化することが重要になる。
本番化前に止まるケース
条件
次の状態なら、本番化を急がない方がいい。
- VCF Automationが必要なのにVDS-backedを選んでいる。
- tenant分離の単位が曖昧なままGPUを共有しようとしている。
- GPU quotaの責任者が決まっていない。
- FLB、Avi、NSX Edgeのどれを使うかが通信要件と結び付いていない。
- Private AI Services UIとVCF Automation UIの担当が混ざっている。
- 外部PostgreSQLやRAGデータのbackup、削除、監査が決まっていない。
- VDSからNSXへ移る時のSupervisor再展開を誰も見積もっていない。
- TechDocsやRelease Notesの更新確認を誰も担当していない。
特に、未確認のscaleや性能値を社内資料に入れるのは避けたい。公式資料で確認できない数値は、期待値ではなく検証項目として扱う。Broadcomの発表やBlogは方向性を知る入口であり、自社環境の設計値を保証するものではない。
この記事の結論
PoCを速く始める選択肢です。管理者がCLI、YAML、kubectlで支える範囲を隠さないことが条件です。
本番のmulti-tenant AI基盤、self-service catalog、governanceを重視する時に軸になりやすい構成です。
利用者のself-service体験、GPU quota、approval、catalog設計を考える時に確認する入口です。
VKS、Namespace Blueprint、VPC Network Span、FinOpsをつなげて、Kubernetes、network、costの確認に進みます。
「VDSはだめ」「NSXなら安全」といった単純な結論ではなく、PoCと本番運用で求める体験と統制を分けて読みます。
VCF Private AI Servicesを導入する時、最初に決めるべきことは「どのAI機能を試すか」だけではない。SupervisorをNSX-backedにするか、VDS-backedにするかで、VCF Automationの可否、利用者のself-service体験、GPU quotaの管理、将来の再展開コストが変わる。
PoCを速く始めたいなら、VDS-backed SupervisorとFoundation Load BalancerまたはAvi Load Balancerは現実的な入口になり得る。ただし、管理者がCLI、YAML、kubectlで支える範囲を隠さないことが条件だ。本番のmulti-tenant AI基盤、self-service catalog、governanceを重視するなら、NSX-backed SupervisorとVCF Automationを軸に設計する方が筋が通る。
「VDSはだめ」「NSXなら安全」といった単純な結論にはしない。VDSは速く始めるための選択肢であり、NSXは本番の消費と統制を作りやすい選択肢だ。違いは優劣ではなく、運用モデルの違いとして読んだ方がよい。
Broadcom Watch Japanでは、VCF 9.1、Private AI、AI networking、VMware by Broadcomの公式発表を一次情報ベースで追っています。更新通知はニュースレターで受け取れます。
次に読むなら
参照した主な情報源
- https://blogs.vmware.com/cloud-foundation/2026/06/11/deploying-vmware-cloud-foundation-private-ai-services-navigating-supervisor-architectures-with-and-without-nsx/
- https://techdocs.broadcom.com/us/en/vmware-cis/private-ai/foundation-with-nvidia/9-0/private-ai-foundation-9-x/what-is-private-ai-services.html
- https://techdocs.broadcom.com/us/en/vmware-cis/private-ai/foundation-with-nvidia/9-0/private-ai-release-notes/vmware-private-ai-services-release-notes.html
- https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere-supervisor/8-0/vsphere-supervisor-concepts-and-planning/supervisor-architecture-and-components/supervisor-networking.html
- https://news.broadcom.com/releases/broadcom-announces-vmware-cloud-foundation-9-1