追記: 2026年6月12日の最新情報
2026年6月8日のKubeCon India 2026告知後に、Broadcom/VMwareからVKSとVCF Private AI Servicesの設計判断に関わる公式情報が追加されています。イベントで見るポイントは「AI on Kubernetesのデモ」だけでなく、VKS on VCFの3ゾーン、VPC/VDS、Antrea、ロードバランサ設計と、VCF Private AI ServicesをNSX構成で使うか、VDS＋ロードバランサ構成で始めるかまで広げて確認するのがよさそうです。
- VKS設計では、VCF 9.1の3-Zone Deployment Model、vSphere Zonesをまたぐノードプール、Antreaを既定CNIとして使う場合の運用可視性を確認します。
- ネットワークは、VCF 9.1以降のVKSでVDS networkingとNSX-VPCsが主要な確認軸になります。VDSで始める場合も、Foundation Load BalancerやAvi Load Balancerの適用範囲を分けて見ます。
- Private AI Servicesは、NSX-backed SupervisorならVCF Automationによるマルチテナント、ガバナンス、セルフサービスに進めます。一方、VDS-backed Supervisorでは管理者によるCLI/YAML運用が中心になるため、PoCの簡便さと将来の自動化を分けて判断します。
そのため、会場や録画で質問するなら「Harbor/Veleroでモデルをどう保護するか」に加えて、「自社はNSX/VPC/VCF Automationを前提にするのか、VDS＋ロードバランサで小さく始めるのか」を先に切り分けておくと、KubeConのデモを導入判断に変換しやすくなります。
このテーマをもう少し広げて見るなら、VKS on VCF 9.1を設計前に確認する：3ゾーン、VPC/VDS、Antrea、LBの実務ポイント と VCF 9.1のArista/AMD連携を導入前に確認する：EVPN/VXLAN、MI350、AI基盤設計の実務ポイント も合わせて確認してください。KubeConのVKS/AIデモを、自社のSupervisor、ゾーン、CNI、ロードバランサ設計に落とすための後続確認先。
3行まとめ
VKS Community Day、Booth #P2、Cloud Native AIセッションを分けて、追うべき公式情報を整理します。
クラスタ管理、GPU運用、モデル管理、namespace復旧、VCF 9.1移行を自社PoCの質問に変換します。
イベント表現を仕様断定にせず、公式ページ、API Reference、リリースノート、PoCで確認します。
この記事は2026年6月9日 JST時点の公式情報をもとにした確認メモです。イベント内容や登録条件は変更される可能性があります。
Broadcomは、2026年6月18日から19日にMumbaiで開催されるKubeCon + CloudNativeCon India 2026で、VMware vSphere Kubernetes Service、AI on Kubernetes、VCF Private AI servicesを前面に出す公式ブログを2026年6月8日に公開しました。
日本のVCF/VKS導入担当者が見るべき点は、海外イベントそのものよりも、VKS Community Day、Booth #P2、Cloud Native AIセッションから、クラスタ管理、GPU運用、モデル管理、namespace復旧、VCF 9.1移行の質問を作ることです。
この記事は2026年6月9日 JST時点の公式情報に基づく非提携の確認メモです。Broadcom、VMware、CNCF、Linux Foundationとは関係なく、投資助言ではありません。イベント時刻、セッション、登録条件は変わる可能性があるため、参加や社内共有の前に公式ページで再確認してください。
BroadcomのKubeCon India 2026出展を導入目線で読む
2026年6月18日から19日にMumbaiで開催される本編で、公式スケジュールと録画公開予定を確認します。
2026年6月17日の別登録イベントとして、VKS、VCF 9.1、AI-ready platformの説明範囲を確認します。
VKS、KubeVM、lifecycle management、VCF Private AI servicesのデモを、運用責任の質問に変換します。
HarborとVeleroを使うモデル管理とnamespace復旧を、AI workloadの運用設計として確認します。
「AI-ready」「Enterprise Grade」「Smooth Upgrades」は導入判断の入口であり、製品仕様やサポート範囲の断定には公式ドキュメントの確認が必要です。
今回の需要シグナルは、VMware Cloud Foundation Blogが2026年6月8日に公開した「Scaling AI on Kubernetes: Join Broadcom at KubeCon India 2026」です。BroadcomがKubeCon + CloudNativeCon India 2026に参加するというイベント情報ですが、Broadcom Watch Japanで読むなら、単なる出展告知では終わらせない方が役に立ちます。
読みどころは、VCF 9.1以降のKubernetes基盤を、Broadcomがどの実装面から見せようとしているかです。公式ブログでは、VKS、KubeVM、VKS lifecycle management、VCF Private AI services、Harbor、Velero、GPU estate、internal developer platformが並びます。つまり、Kubernetesクラスタを作る話だけでなく、AIモデルの保管、バックアップ、復旧、チーム分離、既存VMとの混在運用までを同じ流れで見せる構成です。
公式情報で確認できる主な入口は次の通りです。
| 確認先 | 公式情報で見えること | 導入担当者が持ち帰る問い |
|---|---|---|
| KubeCon + CloudNativeCon India 2026本編 | 2026年6月18日から19日、Mumbai開催 | どのセッションや録画を追えば、VKS/AI基盤の設計に使えるか |
| VKS Community Day | 6月17日12:30開始、AI-ready platformがテーマ | VKS、GPU、IDP、セキュア基盤をどのPoC項目へ落とすか |
| VMware Booth #P2 | VKS/KubeVM、VKS lifecycle、VCF Private AI servicesのデモ | 会場デモで聞くべき運用質問は何か |
| Cloud Native AIセッション | HarborとVeleroによるモデル管理とnamespace保護 | AIモデルとKubernetes復旧をどう分けて設計するか |
| VKS API Reference | VCF Private Cloud内でKubernetesクラスタを宣言的に作成、構成、管理するAPI | 自社環境で使えるVKS API、権限、バージョン、変更管理をどう確認するか |
需要シグナルは公式ブログと公式イベントページ
公式ブログは、BroadcomがKubeCon India 2026にPlatinum Sponsorとして参加し、VMwareとKubernetesの話題をBooth #P2で扱うと案内しています。KubeCon公式ページとスケジュールページも、イベント本体が2026年6月18日から19日、Mumbaiで開催されること、公式スケジュールがIndia Standard Timeで表示されること、セッション録画がCNCF YouTubeに公開される予定であることを示しています。
このため、現地参加しない読者でも追える情報があります。公式ブログ、公式スケジュール、イベント後の録画、Broadcom側のフォローアップ、VKS API Reference、VCF 9.1の公式発表を並べると、社内PoCの問いを作れます。
イベント告知を仕様断定に広げない
一方で、出展ブログにある「AI-ready」「Enterprise Grade」「Smooth Upgrades」のような表現は、導入判断の入口です。製品仕様、サポート範囲、対応バージョン、ライセンス条件を断定する根拠ではありません。
公式情報として確認できること
確認できるのは、Broadcomがどのテーマを会場で扱うか、KubeCon India 2026の公式日程、VKS Community DayやBooth #P2の案内、Cloud Native AIセッションの概要、VKS API Reference上の説明です。これらは質問票を作る材料になります。
自社PoCに残すこと
本文では、会場で見たいこと、公式資料で確認済みのこと、自社PoCで測ることを分けます。たとえば、Booth #P2でVKS lifecycle managementのデモがあるとしても、自社の既存VCF環境、NSX設計、ストレージポリシー、バックアップ製品、証明書運用、OIDC/RBACまで同じように動くとは限りません。イベント情報は、試す順番と質問票を作る材料として読むのが安全です。
VKS Community Dayで見るべきAI-ready Platformの範囲
AI-ready platformは一語で判断せず、GPU、IDP、モデル管理、データ保護、監査を別々の確認項目に分けます。
Broadcomの公式ブログでは、KubeCon本編の前日である2026年6月17日12:30から、Novotel Mumbai International AirportでVKS Community Dayを開くと案内されています。テーマは、AI-ready platformをクラウドネイティブな形で作ることです。公式ブログ上では別登録が必要なオフサイトイベントとして扱われているため、KubeCon本編の通常セッションと混同しない方がよいでしょう。
ここで見るべきなのは、「VKSがAI対応になった」という短い結論ではありません。VKSをVCF Private Cloud内のKubernetes基盤として使うとき、どの責任をプラットフォームチームが持ち、どこからアプリチームやAIチームに渡すのかです。
VKSとVCF 9.1を同じ文脈で見る
公式ブログは、VKS Community Dayで最新のVKS in VCF、VCF 9.1、VKS updates、ライブデモ、顧客セッション、maintainerとの会話を扱うと説明しています。VKS単体のKubernetesランタイムを見るのではなく、VCFのプライベートクラウド上で、Kubernetesクラスタをどう作り、どう増やし、どう更新し、どう守るかを見る場です。
会場や録画で聞く質問
導入担当者は、次のような質問に変換しておくと実務に使いやすくなります。
- VKSのクラスタ作成は、どの権限と申請フローで実行するのか。
- node pool、VM class、storage policy、networking settingsを、どのチームが決めるのか。
- クラスタのアップグレードは、全社標準、事業部別、環境別のどれで管理するのか。
- AI workload用のGPUやネットワーク分離は、既存のvSphere/NSX設計と衝突しないか。
- GitOps、Argo CD、Harbor、Veleroなどの周辺運用を、VKSの責任範囲にどこまで含めるのか。
先に読んでおく関連論点
このあたりは、既に公開済みの<a href="https://avgo-watch.blog.mo-gmo.com/avgo-26-vks-argocd-gitops-platform-check/" rel="noopener">VKSでArgo CD GitOpsを始める前の確認記事</a>ともつながります。KubeConの出展内容を見る前に、VKSで何を宣言管理するのかを整理しておくと、デモを見た時の質問が具体的になります。
GPU estateとIDPは運用責任で分ける
AI-ready platformという言葉は便利ですが、導入判断では少し大きすぎます。GPUが使えるか、AIアプリが動くか、モデルを置けるか、開発者がセルフサービスで使えるか、データ保護と監査が通るかは、別々の確認項目です。
VKS Community DayでGPU estateやinternal developer platformの話が出るなら、日本の導入担当者は次のように分けて聞くとよいでしょう。
| 観点 | 会場や録画で見たいこと | 自社PoCで測ること |
|---|---|---|
| GPU割り当て | GPUをどの単位で見せ、どのチームへ割り当てるか | GPUサーバー、ドライバ、使用率、チーム分離、予約制御 |
| IDP | 開発者がどこまでセルフサービスで環境を作れるか | 申請、承認、テンプレート、監査ログ、コスト配賦 |
| code to production | コードから本番までの経路をどう短くするか | GitOps、イメージ管理、脆弱性確認、リリース承認 |
| secure infrastructure | セキュリティ境界をどう見せるか | RBAC、OIDC、namespace分離、ネットワークポリシー、秘密情報管理 |
| VCF 9.1更新 | VKSやPrivate AIがどのVCF機能とつながるか | 自社のVCF/VKSバージョン、互換性、ライセンス、サポート条件 |
ここで大切なのは、VKS Community Dayの説明を「採用すべき理由」ではなく「PoCで潰すべき問い」に変えることです。特にGPU、AIモデル、IDPは、既存のMLOpsやクラウド利用方針と重なることが多いため、導入前に責任境界を置かないと、検証が広がりすぎます。
Booth #P2のデモでVKS運用に聞くこと
Boothのデモは機能名よりも、既存のITIL運用、監査、ネットワーク、バックアップと接続できるかで見るとPoCに落としやすくなります。
公式ブログでは、Solution ShowcaseのBooth #P2で、VMwareとKubernetesに関するデモを見る場所として案内しています。ここで扱われる見どころは大きく三つあります。ひとつ目は、containersとKubeVMを同じプラットフォームで扱う流れ。ふたつ目は、VKS lifecycle management。三つ目は、VCF Private AI servicesを使ったAI workloadのend-to-end flowです。
この章では、デモを見た時にそのまま社内へ持ち帰るのではなく、どの質問に変換すべきかを整理します。
ContainersとKubeVMを同じ運用モデルで見られるか
公式ブログは、VKS and KubeVM service capabilitiesとして、コンテナ化ワークロードと従来VMを単一の統合プラットフォームで管理するデモに触れています。BYO RHEL Licenseのデモにも言及しているため、既存VMを抱えた企業にとっては見逃しにくいテーマです。
ただし、見るべき点は「VMもコンテナも同じ画面で動くか」だけではありません。実務では、次のような境界が問題になります。
- VMテンプレートやOSライセンスを誰が管理するのか。
- コンテナとVMで、監視、バックアップ、脆弱性対応、変更承認を合わせられるのか。
- ネットワーク分離、ロードバランサ、DNS、証明書の設計をどう合わせるのか。
- 開発者がセルフサービスで使える範囲と、基盤チームが承認する範囲をどこで分けるのか。
- 既存VMの運用手順を、KubeVMの利用でどこまで変えるのか。
コンテナとVMを同じ場所で扱う話は便利に見えますが、既存のITIL運用、監査、バックアップ、ライセンス管理に触れます。Booth #P2で質問するなら、機能名よりも責任分界を確認した方が、PoC計画に落としやすくなります。
Lifecycle managementは作成、拡張、アップグレードで分ける
公式ブログは、Updated VKS Lifecycle Managementのデモとして、on-demand deployment、scaling、cluster versions、upgrades、multi-cluster management、policy enforcementを挙げています。これはVKSの見せ場になりやすい一方で、自社環境では最も詰まりやすい領域でもあります。
たとえば、クラスタ作成が数分でできるとしても、本番ではネットワーク、IP、ストレージ、権限、監視、バックアップ、イメージレジストリ、証明書、セキュリティ審査が絡みます。アップグレードも、画面上で実行できるかより、どのクラスタをいつ止められるか、誰が差し戻すか、失敗時のログをどこで見るかが重要です。
PoCで分ける三段階
PoCでは、次の三段階に分けるのが現実的です。
- まず、標準テンプレートでVKSクラスタを作れるかを見る。
- 次に、node pool、networking settings、storage policyを変えた時の差分管理を見る。
- 最後に、アップグレード、ポリシー適用、複数クラスタ管理、障害時の切り戻しを小さく試す。
ネットワーク設計との接点
VKSのネットワーク設計を掘るなら、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-21-vcf-91-vks-multi-network-check/" rel="noopener">VKSマルチネットワーク対応の記事</a>も先に読んでおくと、Booth #P2のデモで聞くべき論点がはっきりします。
VCF Private AI servicesのデモは全体フローとして見る
公式ブログは、VCF Private AI servicesを使ったAI workloadのデモについて、model onboarding、governance、deployment、data indexing、agent builderまでのend-to-end flowに触れています。ここは、AIアプリの実行画面だけで判断しない方がよい部分です。
AI workloadを本番で扱う場合、モデル、データ、権限、監査、復旧が必ず絡みます。モデルをどこから持ち込むのか、誰が承認するのか、どのデータにアクセスするのか、どのnamespaceで動かすのか、ログと監査証跡をどう残すのかを分けないと、デモで見えた流れをそのまま本番に移せません。
既に別のMLOps基盤、モデルレジストリ、データ基盤、クラウドAIサービスを使っている組織は、VCF Private AI servicesを全面採用するかどうかよりも、どこが重複し、どこが補完になるのかを見ます。KubeConで得られる情報は、既存基盤を置き換える判断というより、プライベートクラウド側へ戻したいAI workloadを選ぶ材料として使うのが自然です。
Cloud Native AIセッションはHarborとVeleroから読む
- 1Model onboarding
モデルのサイズ、承認、更新頻度、保管場所を推論サーバーのコードと分けて考えます。
- 2Harbor registry
AI model registryとして、モデルの保管、配布、タグ、アクセス権限、ロールバックを確認します。
- 3Deployment
推論サーバー、モデル、設定、GPU割り当てを別々のライフサイクルとして管理できるかを見ます。
- 4Namespace protection
AI workloadのnamespaceに含まれる設定、シークレット、権限、永続データを保護対象として整理します。
- 5Velero backup
バックアップ対象、復旧順序、除外対象、失敗時の再実行を運用手順に落とします。
- 6Restore and audit
復旧後にモデル、推論、権限、監査ログが期待通り戻るかを確認します。
Harborはモデルを保管し配布する入口、Veleroはnamespaceを復旧する手順として読み、利用可否は自社のバージョン、権限、サポート条件で確認します。
公式ブログで「Must-Attend Demo Session」として案内されているのが、「Cloud Native AI: Model Management with Harbor & Velero」です。日時は2026年6月18日15:30から15:50、場所は205、Level 2とされています。イベント時刻は変更される可能性があるため、公式スケジュールで再確認してください。
このセッションの読みどころは、HarborとVeleroという既存のクラウドネイティブ領域の名前を、AI workloadの運用課題へどう接続しているかです。
LLMをコンテナイメージに焼き込む問題を先に理解する
公式ブログは、multi-gigabyteのAIモデルをコンテナイメージに直接含めると、CI/CD、ストレージ、モデルライフサイクル、推論サーバーコードとの結合で問題が出ると説明しています。これは、AI on Kubernetesを扱う時のかなり実務的な出発点です。
従来のアプリなら、コンテナイメージにコードと依存関係を入れて配る設計で済むことがあります。ところが、LLMや大きなAIモデルでは、モデルのサイズ、更新頻度、承認フロー、ロールバック、脆弱性確認、保管場所が別問題になります。モデルをコードと一緒に焼き込むと、アプリを少し直しただけで巨大なイメージを再配布することになり、モデルだけを差し替えたい時にも推論サーバー側のライフサイクルと絡みます。
モデル管理の質問に変換する
セッションを見る時は、次の問いを持っておくと、HarborとVeleroの位置づけを理解しやすくなります。
| 問い | 見るべきポイント |
|---|---|
| モデルはどこに置くのか | HarborがAI model registryとしてどこまで扱われるか |
| モデルとコードを分けられるか | 推論サーバー、モデル、設定、データ参照の更新単位 |
| 誰がモデルを承認するのか | アクセス制御、署名、スキャン、監査ログ |
| 失敗時に戻せるか | モデル、namespace、PVC、設定、Secretの復旧範囲 |
| 既存MLOpsとつながるか | 既存モデルレジストリ、CI/CD、データ基盤との重複や連携 |
HarborはAI model registryとして見る
Harborはコンテナイメージレジストリとして知られていますが、このセッションではAI model registryとしての見方が示されます。Broadcomのブログでは、Cloud Native AI specへの言及もあります。ただし、この記事ではCNAI specの詳細解説には踏み込みません。ここで大切なのは、Harborを「モデルを保管し、配布し、管理する場所」として使う時、何を確認するかです。
Harborを使えばモデルガバナンスが自動で完成する、という話ではありません。導入担当者が見るべきなのは、モデルへのアクセス制御、署名、スキャン、複製、保管期限、承認フロー、既存MLOpsとの接続です。AIモデルはアプリよりもサイズが大きく、変更頻度や承認責任も違います。Harborがどの範囲を担うのか、既存のセキュリティ製品やレジストリ運用とどう分けるのかを確認する必要があります。
VeleroはAI namespaceの復旧手順として読む
VeleroはKubernetesのバックアップと復旧で使われるツールです。公式ブログは、AI namespaceをバックアップし、復元するDay 2運用の文脈でVeleroを扱っています。AI workloadでは、namespaceを戻せば終わりとは限りません。
確認したいのは、どの時点へ戻すのか、モデルとデータの整合性が保てるのか、復旧後に推論結果を説明できるのか、監査上の説明ができるのかです。Secret、PVC、ConfigMap、モデル参照、推論サーバー、データインデックスが別々に動く環境では、復旧対象と復旧順序を明示しないと、バックアップはあっても業務として戻せない可能性があります。
この点は、AI基盤をプライベートクラウドに置く意味とも関係します。Broadcom JapanのVCF 9.1発表は、AIおよびKubernetesにネイティブ対応したプライベートクラウド、セキュリティ、ハードウェア選択肢、推論型およびエージェント型AIの文脈を示しています。KubeConのHarbor/Veleroセッションは、その大きなメッセージをDay 2運用へ落とす入口として読めます。
VCF 9.1とVKS APIで自社環境に落とす
VKS API Referenceのlatest表示は、自社環境で同じAPIを使えることを意味しません。VCF/VKSのバージョン、Supervisor、ライセンス、権限、ネットワーク、サポート条件を確認します。
KubeConのイベント情報を実務へ戻すには、VKSの公式APIとVCF 9.1の公式発表へ戻る必要があります。Broadcom DeveloperのVKS API Referenceは、VKSをVCF Private Cloud内でKubernetesクラスタを宣言的に作成、構成、管理するものとして説明しています。cluster topology、node pools、VM classes、storage policies、networking settingsを定義し、provisioning、scaling、upgrading、cluster health managementを自動化する文脈も確認できます。
これは、VKSを「Kubernetesを動かすだけのランタイム」として見ないための大事な根拠です。導入判断では、APIがあること自体より、誰がAPIを使い、どの変更を記録し、どの承認フローと接続するかを見ます。
VKS APIは宣言的なクラスタ管理の根拠に使う
VKS API Referenceでは、latestとして3.6.0が表示されています。ただし、latest表示は読者の自社環境で同じAPIを使えることを意味しません。実際の利用可否は、VCF/VKSのバージョン、Supervisor、ライセンス、権限、ネットワーク、サポート条件で変わります。
自社環境へ落とす確認表
自社環境へ落とす時は、次のように確認します。
| VKS APIで見える対象 | 導入前に決める担当 | PoCで確認すること |
|---|---|---|
| cluster topology | プラットフォームチーム | 標準構成、環境別構成、例外構成 |
| node pools | 基盤チームとアプリチーム | CPU/GPU、サイズ、スケール、アップグレード単位 |
| VM classes | 基盤チーム | テンプレート、権限、リソース上限 |
| storage policies | ストレージ担当 | 性能、可用性、バックアップ、復旧 |
| networking settings | ネットワーク担当 | NSX/VDS、IP、分離、セキュリティポリシー |
| provisioning/scaling/upgrading | 運用チーム | 承認、実行者、ログ、切り戻し |
| health management | SRE/運用チーム | 監視連携、通知、障害対応手順 |
この表は、KubeConで聞く質問にも使えます。たとえばBooth #P2でVKS lifecycle managementを見たら、どのAPIや設定が変更され、どのログに残り、失敗した時にどこまで戻せるのかを聞く。これでイベントデモがPoC項目になります。
VCF 9.1のAI/Kubernetes文脈は日本語発表で補強する
Broadcom JapanのVCF 9.1発表は、VCF 9.1をAIおよびKubernetesにネイティブ対応したプライベートクラウドプラットフォームとして説明しています。AMD、Intel、NVIDIAなどの多様なコンピューティングインフラをサポートし、推論型およびエージェント型AIアプリケーションを導入する文脈も示されています。
日本の導入担当者が社内で説明する時は、この日本語発表が役に立ちます。ただし、発表に含まれるコスト削減やスケールに関する表現は、Broadcomの前提や注記に依存します。KubeConのデモやVCF 9.1の発表を合わせて「自社でも同じ効果が出る」とは書けません。PoCでは、サーバー世代、GPU構成、NVMe、ネットワーク、運用体制、既存クラウド利用状況、ライセンス条件を分けて測る必要があります。
VCF 9.1全体の導入前チェックを広く見るなら、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-13-vcf-91-upgrade-api-ip-check/" rel="noopener">VCF 9.1を導入前に確認する記事</a>と、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-22-vcf-91-hands-on-labs-poc-check/" rel="noopener">VCF 9.1 Hands-on Labsの記事</a>を合わせると、イベント情報をPoCの順番に落としやすくなります。
既存環境との接続は関連記事へつなぐ
この記事は、KubeCon India 2026のBroadcom出展から、VKS、AI on Kubernetes、Harbor、Velero、VCF 9.1の確認項目を作るための記事です。CPU互換性、ネットワーク、GitOps、Operations、FinOps、ライセンス、アップグレード経路をすべて詳細に掘ると、焦点が散ります。
そのため、既存環境との接続は次のように分けて確認するのが現実的です。
- VKSのネットワーク分離は、VKSマルチネットワークの記事へ。
- GitOpsやArgo CDは、VKS GitOpsの記事へ。
- VCF 9.1のPoC入口は、Hands-on Labsの記事へ。
- AI/GPUコストの可視化は、FOCUS/FinOpsの記事へ。
- ライセンスや互換性は、ライセンス確認記事とCPU/サーバー互換性記事へ。
KubeConのデモは、これらを一気に解決する魔法の材料ではありません。むしろ、どの記事や公式資料へ戻るべきかを決めるための入口です。
KubeCon後に社内PoCへ持ち帰るメモを作る
VCF 9.1評価環境があり、VKSクラスタ作成、アップグレード、Harbor、Velero、監査ログの担当者が決まっている状態です。
Supervisor、NSX/VDS、ストレージポリシー、GPUサーバー、OIDC/RBAC、ライセンス条件を先に整理します。
セッション録画、スライド、Broadcom公式ブログのフォローアップ、VKS API Reference、VCF 9.1 release notesを追います。
最初のPoCは、VKSクラスタ作成、node pool、networking settings、Harborによるモデル保管、Veleroによるnamespace復旧、監査ログ確認の順に小さく分けます。
イベント後に重要になるのは、感想ではなくメモです。現地参加、録画視聴、公式ブログのフォローアップのどれであっても、社内PoCに持ち帰る時は「すぐ試す」「条件付きで試す」「情報収集を続ける」に分けると、関係者が動きやすくなります。
すぐPoCに進みやすいケース
すぐPoCに進みやすいのは、VCF 9.1の評価環境を用意でき、VKSのクラスタ作成とアップグレードを試せる組織です。加えて、Harbor、Velero、GitOps、バックアップ、監査ログの運用責任者が決まっている場合は、Cloud Native AIセッションの内容を小さく試せます。
最初のPoCは、広げすぎない方がよいでしょう。VKSクラスタ作成、node pool、networking settings、Harborによるモデル保管、Veleroによるnamespace復旧、監査ログ確認の順に分けます。GPU運用、IDP、Private AI services、agent builderまで一度に試すと、どこで失敗したのか切り分けにくくなります。
条件付きでPoCに回すケース
条件付きでPoCに回すべきなのは、興味はあるが基盤条件が未整理のケースです。Supervisor、NSX/VDS、ストレージポリシー、GPUサーバー、イメージレジストリ、バックアップ製品、OIDC/RBAC、ライセンス条件が曖昧なら、イベント情報だけでPoCへ進むのは危険です。
PoC前に止める条件
この場合は、KubeConの録画やスライドを見た後に、社内で次の確認を先に行います。
| 先に確認すること | 理由 |
|---|---|
| VCF/VKSの利用可能バージョン | VKS API Referenceのlatestと自社環境が一致するとは限らない |
| GPUサーバーとネットワーク | AI workloadのPoCではハードウェアと通信設計が先に詰まりやすい |
| Harbor/Veleroの既存利用 | 既に使っている場合、VCF/VKS上での責任範囲を再定義する必要がある |
| バックアップと復旧目標 | AI namespaceは戻せても、モデルとデータ整合性が問題になる |
| OIDC/RBACと監査 | IDPやセルフサービスを広げる時の承認境界になる |
公開後も追うべき更新
KubeCon India 2026は、この記事の確認日である2026年6月9日から見ると、まだ開催前です。イベント後には、セッション録画、スライド、Broadcom公式ブログのフォローアップ、VKS API Reference、Harbor/Velero関連のCNCF資料、VCF 9.1 release notesを追う必要があります。
特に、Cloud Native AIセッションの内容は、録画やスライドで具体化される可能性があります。公式ブログで触れられたCNAI spec、HarborのAI model registry、VeleroのAI namespace復旧が、どの範囲までデモされるのかは、イベント後に再確認したい点です。
更新履歴
- 2026年6月9日 JST初版作成
VMware Cloud Foundation Blog、KubeCon + CloudNativeCon India公式ページ、公式スケジュール、Broadcom JapanのVCF 9.1発表、Broadcom DeveloperのVKS API Referenceを確認しました。
- 非提携メモ立場の確認
Broadcom、VMware、CNCF、Linux Foundationとは非提携で、製品、サービス、ソリューション、導入判断を扱います。
- 次の更新イベント後確認
セッション録画、スライド、Broadcom側のフォローアップ、VKS API Reference、VCF 9.1 release notesの更新を確認します。
イベント後の資料更新は、確認した日付、変更点、導入判断への影響を分けて追うと判断履歴が残ります。
- 2026年6月9日 JST: VMware Cloud Foundation Blog、KubeCon + CloudNativeCon India公式ページ、公式スケジュール、Broadcom JapanのVCF 9.1発表、Broadcom DeveloperのVKS API Referenceを確認し、記事を作成しました。
- この記事はBroadcom、VMware、CNCF、Linux Foundationとは非提携です。商標は各社に帰属します。
- 記事の中心は製品、サービス、ソリューション、導入判断です。AVGO株価、目標株価、売買判断を扱う投資助言ではありません。
読了後の控えめなCTA
Broadcomの公式発表、VCF/VKS更新、AI on Kubernetes、月次まとめの更新を続けて追いたい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>で更新通知を受け取れます。イベント後の録画や追加資料が出た時も、製品目線の確認メモとして追いやすくなります。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, Scaling AI on Kubernetes: Join Broadcom at KubeCon India 2026, 2026年6月8日
https://blogs.vmware.com/cloud-foundation/2026/06/08/scaling-ai-on-kubernetes-join-broadcom-at-kubecon-india-2026/
- KubeCon + CloudNativeCon India 2026公式ページ
https://events.linuxfoundation.org/kubecon-cloudnativecon-india/
- KubeCon + CloudNativeCon India 2026公式スケジュール
https://events.linuxfoundation.org/kubecon-cloudnativecon-india/program/schedule/
- Sponsor-hosted Co-located Schedule, KubeCon + CloudNativeCon India 2026
https://events.linuxfoundation.org/kubecon-cloudnativecon-india/co-located-events/sponsor-hosted-co-located-schedule/
- Broadcom Japan, Broadcom、本番環境でのAI活用に向けたセキュアでコスト効率に優れたインフラを実現するVMware Cloud Foundation 9.1を発表
https://news.broadcom.com/jp/releases/broadcom-announces-vmware-cloud-foundation-9-1-japan
- Broadcom Developer, VMware vSphere Kubernetes Service API Documentation
https://developer.broadcom.com/xapis/vmware-vsphere-kubernetes-service/latest/