Broadcom VCFの拡張、AI、セキュリティ、リカバリーを単一プラットフォームに統合
Broadcomは11月4日、プライベートAIインフラ、セキュリティ、リカバリーの変更を、小規模な仮想化製品群とともに統合する最新のポートフォリオ拡張を発表した。Broadcom VCFの拡張により、より多くの企業向け責務が、同社のプライベートクラウドソフトウェアプラットフォームであるVMware Cloud Foundationに取り込まれる。ただし、この発表には既存機能、将来のリリース、個別の高度サービスが含まれる。顧客が導入可能なものと、なお別途購入する必要があるものを判断するうえで、こうした違いは重要だ。
中心的なトレードオフは運用の統合にある。インフラを共有すれば重複する管理を減らせる一方、アクセス、保守、リカバリーに関する意思決定も集中する。企業の購入担当者は、より幅広いプラットフォームが実際の運用環境を簡素化するかを評価しなければならない。機能一覧が長くなるだけでは、その問いには答えられない。
Nutanixは、インフラとエンタープライズAI管理を組み合わせている点で、有用な競合比較の対象となる。したがってBroadcomの発表は、既存アプリケーションと並行して企業がAIをどのように運用するかをめぐる、より広い競争の一部に位置付けられる。インフラ責任者にとって当面の判断は、共有プラットフォーム内にどこまで責務を集約するかにある。
Broadcom VCFの拡張で実際に変わること
今回の発表は、製品提供、将来の開発、ポートフォリオのパッケージ化を組み合わせており、それぞれ異なる導入判断を必要とする。
Broadcomのプライベートクラウドに関するアップデートでは、すでに提供済みの機能と、2027年度第1四半期に予定される追加機能が区別されている。マルチテナントのモデル共有はVCF 9.1.1で導入され、コンフィデンシャルコンピューティングはVCF 9.1で登場した。コンフィデンシャルコンピューティングは、対応ハードウェアを通じて処理中のデータを保護する。
予定される追加機能には、AI Infrastructure Quickstart、ネイティブのS3互換オブジェクトストレージ、インフラコンプライアンス管理、ポリシーベースの接続性、ネイティブのディザスタリカバリーが含まれる。Quickstartは、AIインフラの初期セットアップを自動化することを目的としている。S3互換性とは、ファイルやモデルアーティファクトなどのオブジェクトを保存・取得するためのインターフェースを指す。
Broadcomはまた、高度サービスのポートフォリオ内にHyperArmor、Live Recovery、ワークロードコンプライアンス管理を位置付けている。これらの提供内容は、ネイティブなインフラ機能とは目的が異なる。購入者は自社の契約に実際にどの機能が含まれるかを確認する必要があるため、その位置付けは重要だ。
実務上の帰結として、今回の発表は見出しから想像される以上に複雑なリリース評価を必要とする。インフラ管理者は、発表されたすべての機能を直ちに利用可能と扱うことはできない。また、セキュリティチームも、高度サービスが自動的に自社の導入環境の一部になると想定すべきではない。
有用な評価では、提供状況とアーキテクチャ上の関連性を分けて考える。ある機能が企業のニーズに関連していても、現在の導入スケジュールには適さない場合がある。逆に、利用可能な機能であっても、ハードウェアの変更、スタッフの準備、追加の検証を要する可能性がある。
この区別は、チームが調達期限を軸にプロジェクトを編成する場合に特に重要になる。発表はベンダーの方向性を示す。リリース文書は管理者がインストールできるものを示し、契約文言は組織が利用できるものを定める。
Broadcom VCFの拡張は、インフラ自動化と、そのインフラを統制するためのコントロールも組み合わせている。両者は関連する投資だが、解決する問題は異なる。迅速な導入はチームによる環境構築を支援し、ガバナンスは環境が存在した後に安全に何ができるかを決める。
たとえば、クラスタセットアップを自動化しても、どの部門が機密文書にアクセスできるかは決まらない。ストレージを提供しても、保持ポリシーは確立されない。リカバリーのオーケストレーションを追加しても、インシデント後にどのアプリケーションを最初に復旧させるべきかは決まらない。
これらは、発表によって明らかになった欠点ではなく、分析上の区別である。Broadcomの追加機能はそうした意思決定を支援できるが、顧客に代わって決定するものではない。企業には依然として、技術機能と事業要件を結び付ける運用モデルが必要だ。
その運用モデルは、このアップデートを評価するための適切な枠組みとなる。問うべきは、追加機能が特定の作業を削減するのか、強制可能なコントロールを改善するのか、あるいは文書化されたリカバリー上の欠落を埋めるのかという点である。そのつながりがなければ、ポートフォリオの拡張を運用上の価値に置き換えることは難しい。
共有AIインフラがプラットフォームチームに圧力をかける
AIモデルを一元化すると、アクセス、容量、サービス継続性を管理するチームへ責務が移る。
Broadcomによれば、共有モデルインフラは、個別のセキュリティ境界とプライベートなコンテキストを維持しながら、複数の社内部門にサービスを提供できる。提案される利点は、部門間の重複を減らせることだ。ただし、これは特定の顧客環境におけるコスト削減の独立した証拠ではなく、アーキテクチャの利点に関するベンダーの主張である。
根底にある仕組みは理解しやすい。異なる部門が異なる情報を扱いながら、類似したモデル機能へのアクセスを求めることがある。中央サービスは、すべての部門データを意図的に共有することなく、モデルの導入環境を共有する手段を提供する。
しかし、共有によってプラットフォームチームは可用性以上の責務を負うことになる。誰にアクセスを付与するか、競合する要求にどのようにリソースを配分するか、どの変更に承認が必要かを定義しなければならない。プロビジョニングが容易になっても、これらの責務は残る。
法務、エンジニアリング、カスタマーサポート向けのアシスタントを持つ仮想的な組織を考えてみよう。各アシスタントは共有モデルサービスを利用するが、異なるリポジトリから情報を取得する。インフラは共通にできる一方、許可される文書、ユーザー、アクションは異なるままである。
この構成は、具体的なガバナンス上の課題を生む。従業員にモデル利用の権利があるからといって、接続されたすべての文書を取得する権限があるとは限らない。同様に、文書を読む権限があっても、別の業務システムを変更する権限があるとは限らない。
ここでVMware private AIは組織上の意思決定となる。インフラ管理者、アプリケーション所有者、セキュリティチームは、互換性のあるアクセス定義を持つ必要がある。そうでなければ、各グループが別のグループがコントロールを所有していると考え、結果として誰も実装していない状況になり得る。
容量管理も別の圧力をもたらす。共有サービスは、あるワークロードが利用可能なリソースをすべて消費することなく、異なる事業上の優先順位に対応しなければならない。適切なポリシーは、プラットフォームのデフォルト設定ではなく、事業ニーズに左右される。
開発実験と顧客向けアプリケーションでは、遅延に対する許容度が大きく異なる場合がある。基盤となるインフラを共有しても、その違いは消えない。プラットフォーム所有者には、競合や保守の際にもこうした優先順位を維持する手段が必要だ。
同じ問題は変更にも当てはまる。中央で導入されたモデルを更新すると、それに依存する複数のアプリケーションに影響を及ぼす可能性がある。そのためアプリケーションチームには、共有アップデートが本番環境に到達する前に変更後の挙動を評価するプロセスが必要となる。
この分析は、Broadcomのモデル共有が受け入れがたいリスクを生むと結論付けるものではない。統合に伴う責務を特定している。関連する比較は、部門ごとに重複する作業と、共通サービスを運用するために必要な規律との間で行うべきだ。
企業知識についても、関連する区別がある。インフラコントロールはアシスタントが稼働する環境を定め、情報コントロールはアシスタントが取得できる内容を定める。ナレッジベースの違いは、導入場所だけではアクセスポリシーを決められない理由を説明するのに役立つ。
圧力が最も直接的にかかるのは、別の孤立した運用環境を生み出すことなくAIを支援するよう求められるインフラ責任者だ。彼らは、一元化によってサービス提供が改善されることを示す必要がある。そのためには、ワークロードの挙動、管理負荷、権限適用に関する証拠が求められる。
開発者にとっての利点は、共有プラットフォームが何を予測可能にするかに左右される。一貫したリクエストプロセス、文書化された制限、明確な所有権は、初期導入の速度と同じくらい重要になり得る。これらが、利用可能なインフラを使える社内サービスに変える条件である。
統合は運用上の選択肢と競合する
Broadcomの統合戦略は、エンタープライズAIインフラを構築・統制する別の方法と競合する。
NutanixのエンタープライズAIコントロールは、関連する比較対象となる。同社のEnterprise AI 2.8リリースでは、きめ細かな権限、制御されたモデル共有、切断環境向けの導入オプションが説明されている。このリリースも一般提供機能とプレビューを区別しており、購入者はベンダーを比較する際にその区別を維持すべきだ。
この比較が示すのは、全体的な勝者ではなく、重なり合う優先事項である。どちらのアプローチも、エンタープライズインフラ内におけるAIリソースへのアクセスを扱う。どちらのベンダーの機能一覧も、それだけで特定の組織にどのプラットフォームが適しているかを決めるものではない。
Broadcomの顧客は、自社の管理者がすでに理解している環境を拡張する価値を見いだすかもしれない。新しい機能が既存の責務に適合するなら、慣れた手順によって移行作業の一部を減らせる可能性がある。この利点は顧客の出発点に依存するため、普遍的に想定すべきではない。
別の組織は、インフラ、モデルサービス、セキュリティツールをそれぞれ独立して置き換えられることを優先するかもしれない。このアプローチは選択肢を維持できる一方、チームにはコンポーネント間の接続を維持することが求められる。柔軟性には、それ自体の運用上の義務が伴う。
したがって主な緊張関係は、統合された運用と独立したコントロールの間にある。統合プラットフォームは、一部のワークフローをより容易に調整できる可能性がある。組み合わせた環境は、コンポーネントを変更する自由度を高められる一方、より多くの統合作業を必要とする。
これらはアーキテクチャ上のトレードオフであり、いずれかの選択肢が本質的に優れていると考える理由ではない。適切な選択は、スタッフのスキル、アプリケーションの依存関係、ハードウェア要件、組織の変化に対する許容度に左右される。購入者はこうした条件を直接テストする必要がある。
公正な比較では、候補環境全体で同じ代表的なワークロードを使用するべきだ。導入、アクセス制限、保守、復旧を検証する必要がある。初期セットアップだけを比較すれば、最初のデモを最も容易に実現できる製品が有利になる。
また、そのワークロードは依存関係を明らかにできるほど本番環境に近いものであるべきだ。承認済みの社内文書に接続されたアシスタントは、孤立したチャットボットのデモよりも多くの情報を提供する。その挙動は、権限、検索、モデルの可用性、アプリケーション構成に同時に依存する。
文書化にも、その評価において注意を払う必要があります。チームはポリシーの所在と、管理者がそれらをどのように確認できるかを理解する必要があります。技術的に存在するコントロールであっても、その挙動が不明瞭なままであれば、運用は困難になり得ます。
トラブルシューティングも有用な比較材料となります。アプリケーションに障害が発生した場合、管理者は問題がインフラ、アイデンティティ、ストレージ、またはアプリケーションの挙動のいずれに関係するのかを特定しなければなりません。統合は、調整作業を減らしてこうした不確実性の解消に役立つ場合に価値をもたらします。
Broadcomのサービスエコシステムも、実装の重要性を反映しています。Kyndrylのプライベートクラウドアライアンスは、VCFを中心としたコンサルティング、モダナイゼーション、スキルへの投資を説明しています。商業パートナーであるKyndrylは、成果に対する独立した評価ではなく、支援的な見解を提示しています。
とはいえ、その関与は実務上の重要な点を浮き彫りにしています。ソフトウェアの機能には、アーキテクチャと運用面での準備が必要です。顧客は依然として、ベンダーのポートフォリオを実際に機能するポリシー、責任分担、手順へと落とし込まなければなりません。この作業は、導入に要する労力と併せて評価に含めるべきです。
BroadcomによるVCFの拡張は、より多くの責任をVMwareインフラ内に統合するという主張を強めます。顧客がその主張を受け入れるかどうかは、運用上の摩擦が実証可能な形で低減されるかにかかっています。購入者は同じビジネス要件を満たす異なる方法を比較できるため、競合製品も依然として重要です。
ハイパーバイザー保護はアプリケーションセキュリティを完結させない
仮想化レイヤーの保護は重要なリスクに対処する一方、アプリケーションと情報に関するコントロールは別個の責任として残ります。
Broadcomのハイパーバイザー保護に関する発表では、HyperArmorを、仮想マシンを実行するソフトウェアレイヤーであるESX向けの予防的防御として説明しています。同社によれば、ホストレベルの仮想パッチ、許可された挙動のコントロール、管理者ログイン経路における追加認証を組み合わせています。
仮想パッチは、脆弱なソフトウェアを最初に置き換えることなく、悪用を阻止しようとするものです。Broadcomはこのアプローチを、露出期間中の保護として位置付けています。顧客はこの主張と、あらゆる脆弱性や攻撃経路に対する保証とを区別すべきです。
発表には、ハイパーバイザーレイヤーにおける予防的コントロールについて、IDCアナリストのStephen Elliotによる支援的な評価が含まれています。彼の見解は、このレイヤーのアーキテクチャ上の重要性を裏付けます。ただし、HyperArmorのすべての機能に対する独立した検証を確立するものではありません。
購入者にとって、懐疑的に問うべきなのは適用範囲です。インフラ防御はホストに対する攻撃に対処できても、AIアプリケーションが機密情報を適切に扱うかどうかを決めるものではありません。これらのコントロールはシステムの異なるレベルで機能します。
権限を持つ従業員が、受け取るべきではない文書を要約するよう社内アシスタントに依頼する場面を想定してください。そのやり取りの間、ホストは侵害されないままであり得ます。障害は、仮想化ソフトウェアへの攻撃成功ではなく、情報アクセスまたはアプリケーションの挙動に関するものです。
同様に、業務ツールに接続されたモデルには、許可されるアクションを規定するルールが必要です。未承認のホストコマンドを防止しても、アシスタントがメッセージを送信できるか、レコードを変更できるかが自動的に決まるわけではありません。アプリケーションの所有者は、そうした境界を定めなければなりません。
この区別が重要なのは、セキュリティに関する表現が調達の議論を経るなかで、しばしばより広い意味へと拡大するためです。あるレイヤー向けに設計された製品が、環境全体を保護するための略称になり得ます。購入者は、技術的な主張を承認文書に置き換える際にも、元の適用範囲を保持すべきです。
コンフィデンシャルコンピューティングにも同様の注意が必要です。処理中のデータを保護することは、特定の種類の露出に対処します。しかし、すべてのユーザー要求が適切であること、取得されたすべての文書にアクセス権があること、生成されたすべての回答が正確であることを保証するものではありません。
適切な結論は、責任をレイヤー化することです。インフラのコントロール、アイデンティティポリシー、アプリケーションの制限、情報ガバナンスは、相互に支え合う必要があります。あるレイヤーを強化したからといって、文書化された理由なく他のレイヤーのコントロールを取り除くことは正当化されません。
管理手順も評価が必要です。チームは、認可された緊急アクセスがどのように機能するか、アイデンティティへの依存関係に障害が起きた際にどのように復旧するかを理解すべきです。追加認証が有用なのは、管理者が想定される条件下でそれを確実に運用できる場合に限られます。
これらの問いは、Broadcomのセキュリティの方向性を退ける必要があることを意味しません。ホスト侵害の防止と特権アクセスの悪用の抑制は、意義のある目標です。注意すべきなのは、利用可能な証拠が裏付けない主張へと、これらの目標を拡張することです。
したがって、本番環境の評価では、広範なセキュリティラベルではなく、具体的な挙動をテストすべきです。想定する管理者は承認されたタスクを実行できるか。システムは禁じられたアクションをブロックし、チームはその結果を説明できるか。
AI関連の脅威に関する主張も、同じ規律に従うべきです。購入者は、コントロールを評価するために攻撃者についての包括的な物語を受け入れる必要はありません。対処する脅威、提供される保護、残存する露出を特定する必要があります。
復旧は信頼できるサービスを復元しなければならない
VMwareの復旧機能は、インフラの再起動が成功したかどうかを超えて、アプリケーションレベルで評価する価値があります。
ポートフォリオの可用性に関する詳細では、ネイティブのディザスタリカバリと、より広範な高度サービスのポートフォリオを区別しています。Network Worldは、vSphere Expressが最大128コアの小規模環境向けに直ちに利用可能であると報じています。復旧および接続機能を含む複数のVCF追加機能は、Broadcomの2027年度第1四半期に予定されています。
この区別は、ディザスタリカバリとサイバーリカバリが異なる問いに答えるため重要です。ディザスタリカバリは、障害後に運用を復元することに関わります。サイバーリカバリでは、攻撃後に復元された環境が再接続に適しているという確信も求められます。
AIアプリケーションの場合、コンピューティングの復元は作業の一部に過ぎません。サービスは、モデルファイル、文書、権限、アプリケーション設定、他システムへの接続に依存することがあります。復旧計画では、こうした依存関係をまとめて考慮する必要があります。
セキュリティインシデント後に復元された、仮想的な社内エンジニアリングアシスタントを考えてみましょう。仮想マシンは正常に起動し、そのインターフェースはリクエストを受け付けます。しかし、文書インデックスには古い権限が反映されており、アプリケーション設定は変更済みのモデルを指しています。
インフラの復元は成功しても、サービスが通常利用に適さないままということがあります。この例は、復旧検証にアプリケーションの所有責任が必要である理由を示しています。管理者はインフラが稼働していることを確認できますが、ビジネスオーナーはサービスが許容可能に動作することの確認に協力しなければなりません。
したがって、VMwareの復旧機能は、定義された復旧目標に照らして判断すべきです。その目標は、最新のアクセスルールと検証済みのソース資料を備えた承認済みアプリケーションの復元に関するものであり得ます。組織は、オーケストレーション機能を評価する前に、その成果を明確にする必要があります。
復旧済みシステムを調査するための隔離環境であるクリーンルームは、そのプロセスを支援できます。隔離により、チームは本番の依存関係を再接続する前に調査する余地を得られます。ただし、復元されたすべての成果物や設定が自動的に信頼できることを確立するものではありません。
評価では、復旧に関する判断がどのように承認されるかも考慮すべきです。セキュリティ担当者、インフラ管理者、アプリケーションオーナーでは、必要とする証拠が異なる場合があります。文書化されたプロセスは、インシデント時にそうした違いを発見する事態を避けるのに役立ちます。
復元の順序は、別の実務上の依存関係を生みます。アプリケーションは、利用可能になる前にアイデンティティサービス、ストレージ、またはネットワーク接続を必要とする場合があります。オーケストレーションが重要なのは、その順序を反映し、チームが各依存関係を検証するのに役立つ場合です。
これは、共有AIインフラにとって特に重要です。集中化により、共通サービスは複数の部門にとって価値あるものになり得るため、長期的な中断の影響も大きくなります。復旧計画には、それらの依存アプリケーションの重要性を反映すべきです。
購入者は、機能デモと復旧演習も区別すべきです。デモは、選ばれた条件下でワークフローが動作し得ることを示します。演習では、顧客の人員、依存関係、手順が必要な成果を達成できるかを検証します。
最も強い証拠は、復旧の自動化を文書化されたアプリケーション検証に結び付けるものです。チームは、何が復帰し、どの確認が通過し、誰が再接続を承認したかを把握すべきです。これは、インフラのステータスインジケーターだけよりも、信頼のための明確な根拠を提供します。
VMwareプライベートAIの導入において、運用上の問いは明快です。組織は、信頼してよいと考えるサービスを復元できるのか。その答えは、ソフトウェア機能と、それを取り巻く準備の両方に依存します。
次のリリースまでに購入者が注視すべきこと
次に必要な証拠は、提供の実績、実務的な統合の利点、代表的な条件下での復旧挙動を確立するものです。
最初の指標は、発表された範囲に対するリリースの提供状況です。顧客は、計画されたインフラ、ストレージ、接続性、コンプライアンス、復旧機能の追加を網羅する最終ドキュメントを注視すべきです。Broadcomの会計四半期に関する表現は、想定された暦上の期限と区別したままにすべきです。
関連する証拠には、サポート対象の構成、既知の制限事項、ネイティブ機能と高度サービスの関係が含まれます。これらの詳細により、発表された機能が既存環境に適合するかが決まります。また、導入前に顧客が必要とする準備も明らかになります。
文書化された顧客要件に沿った提供は、Broadcomの統合に関する主張を強めるでしょう。機能の不足、限定的なサポート、可用性の変更は、影響を受ける導入においてその主張を弱めます。評価は、発表の全体的な広がりではなく、実際の要件に従うべきです。
2つ目の指標は、代表的な共有モデル導入から得られる証拠です。購入者は、ワークロードの特性、アクセス境界、サービスの挙動、管理上の労力を説明する結果を求めるべきです。リソース効率に関する見出しだけでは、それらの条件がなければ評価が困難です。
有用な証拠は、部門が情報とワークロードに対する適切なコントロールを維持しながらインフラを共有できるかを示すものです。また、更新、競合、トラブルシューティングの際にプラットフォーム担当者が何を行う必要があるかも説明すべきです。これにより、統合が作業を削減するのか、それとも再配分するのかが明らかになります。
ベンダーのデモは当然ながら有利な条件を選ぶため、独立した顧客事例は特に価値があります。制限事項を率直に説明する詳細な事例も有用です。購入者は、説明のない改善の主張よりも、説明可能な成果を重視すべきです。
3つ目の指標は、完全なアプリケーションを含む復旧検証です。顧客は、復元されたインフラを権限、ソース情報、アプリケーションの挙動へと結び付ける演習を注視すべきです。そうした証拠は、運用レジリエンスに関する主張をより具体的なものにします。
演習が、必要な検証を維持しつつ調整作業を減らせることを示せば、統合型リカバリーの有効性をさらに裏付けることになるでしょう。未解決の依存関係が明らかになれば、なお必要な作業を特定できます。いずれの結果も、統合によって即座に準備が整うと仮定するより有益です。
これらのシグナルを総合すれば、Broadcom VCFの拡張を評価するための焦点を絞った方法が得られます。提供内容は、何が存在するかを示します。導入の証拠は、それがどのように運用されるかを示し、リカバリー検証は、障害時に組織がそれに依存できるかどうかを明らかにします。
今後予定されているアーキテクチャレビューでは、代表的なアプリケーションを選び、そのアクセス要件、依存関係、保守プロセス、リカバリー基準を文書化してください。各要件を、利用可能な機能、計画中の追加機能、または運用手順に対応付けるよう、プラットフォームチームに依頼します。その評価では、ネイティブ機能と高度なサービスを明確に区別してください。同じアプリケーションを、同等の条件および受け入れ基準を用いて、信頼できる代替案と比較してください。Broadcom VCFの拡張では、管理作業の削減、強制可能な情報境界、そして許容可能な形で復旧するサービスを示す証拠を優先してください。本番ワークロードを確定する前に、アプリケーション所有者が評価できる導入およびリカバリー演習を求めてください。チームではどの責任を統合し、その結果得られるサービスがニーズを満たすことを、どのような証拠で確認しますか？
