はじめに
2023年、仮想化ソフトウェアの世界に大きな転換点が訪れました。長年にわたり企業ITインフラの標準として君臨してきたVMwareが、半導体大手Broadcomに約610億ドルで買収されたのです。
この買収を機に、ライセンス体系が大きく刷新されました。Broadcomによるライセンス体系変更を受け、多くの企業が仮想化基盤の見直しを進めています。国内メディアでも、更新費用の増加や移行検討の事例が相次いで報じられています。
この記事では「何がどう変わったのか」「企業はどう対応すべきか」を、技術的な背景も交えながら整理します。
VMwareとは何か、なぜ重要なのか
VMwareは、1台の物理サーバー上に複数の「仮想マシン（VM）」を動かすソフトウェアです。企業のデータセンターでは、数十〜数百台分のサーバーを少数の物理機器に集約するために使われており、現代のITインフラの基盤と言っても過言ではありません。
主要製品は以下の通りです。
| 製品名 | 役割 |
|---|---|
| vSphere（ESXi + vCenter） | 仮想マシンの作成・管理 |
| vSAN | 仮想化されたストレージ管理 |
| NSX | 仮想化されたネットワーク管理 |
これらを組み合わせることで、ハードウェアに依存しない柔軟なITインフラが実現できます。
何が変わったのか
永続ライセンスの廃止
以前は一度購入すれば使い続けられる「永続ライセンス」が選べました。Broadcom移行後はサブスクリプション（年間契約）のみとなり、使い続ける限りコストが発生し続けます。
製品体系の再編
Broadcom移行後は従来の細かな製品単位での購入が難しくなり、包括的なバンドル契約が中心のサブスクリプション体系へ移行しました。必要最低限の機能だけを使いたい企業でも、より広い機能セットを前提とした契約を検討する必要が出ています。
コアベース課金への移行
以前はCPUソケット単位の課金でしたが、CPUのコア数ベースの課金に変更されました。昨今のサーバーはコア数が多い（32〜64コア）ため、実質的に大幅な値上がりとなるケースが続出しています。
例：「CPUソケット2つで年間100万円」だったものが、「64コア×単価＝年間400万円超」になった、など。
企業が直面している3つの課題
課題1：コストの急増
単純な更新でも数倍のコスト増になりうる。
特に多くのサーバーを抱える大企業ほど影響が大きい。
課題2：移行の技術的難易度
VMwareは長年使われてきたため、社内システムが深く依存しているケースが多い。
仮想マシンのフォーマット（VMDKなど）や管理の仕組みが独自のため、他製品への移行は一筋縄ではいきません。
課題3：サポート・人材の問題
VMwareに精通したエンジニアは多いですが、代替製品のノウハウを持つ人材はまだ少ない。移行後の運用体制をどう整えるかも大きな課題です。
現場で実際に困るポイント
移行を検討する際に見落とされがちですが、現場レベルでは以下のような問題が発生します。
vMotion互換性
VMwareのライブマイグレーション機能「vMotion」。
移行先にも類似機能はあるものの、挙動や制約が異なることが多く、運用設計の見直しが必要になります。
共有ストレージの前提、CPU互換性要件、メモリ転送方式など、製品ごとにクセがあります。
バックアップ製品の対応
既存のバックアップ運用がVMwareのAPIやスナップショット連携を前提に設計されているケースが多く、移行先に合わせた再設計が必要になります。
Veeam・Commvaultなど主要製品は移行先への対応を進めていますが、設定の組み直しは避けられません。
監視設計の見直し
仮想基盤の監視項目や取得APIが変わるため、既存の監視設定・アラート設計の見直しが必要になります。
vCenter連携を前提としている場合は影響が大きく、API変更やexporterの組み替えが発生します。
運用Runbookの更新
スナップショット取得、ロールバック、障害対応など、日々の運用手順書がVMware前提で作られていることが多く、更新が必要になります。
HA障害対応やDR切替手順なども含めると、想定より作業量が増えるケースがあります。
契約・利用状況の棚卸し
新しいライセンス体系では契約内容と実使用状況の管理がより重要になります。
利用実態を正確に把握しておくことが、余分なコスト発生を防ぐ上で欠かせません。
主な移行先の選択肢と比較
| 製品 | 提供元 | 特徴 | 向いている企業 |
|---|---|---|---|
| Hyper-V | Microsoft | Windows Serverに標準搭載。追加コスト不要 | Windowsベースの環境が多い企業 |
| KVM / Proxmox VE | オープンソース | 無償。カスタマイズ性が高い | 技術力の高い社内チームがいる企業 |
| Nutanix AHV | Nutanix | HCI専用ハイパーバイザー。運用が簡素 | インフラを刷新したい企業 |
| Red Hat OpenShift Virtualization | Red Hat | KVMベース。コンテナとVMを統合管理 | コンテナ移行も視野に入れている企業 |
| Azure Local（旧Azure Stack HCI） | Microsoft | Azure連携が強い。ハイブリッドクラウド向け | Azureを中心に据えている企業 |
企業はどう動くべきか：意思決定フロー
Step 1: 現状把握
まずはVMwareのどの製品を、何コアで使っているか棚卸しする。
Step 2: コスト試算
新ライセンス体系での更新コストを試算する。あわせて既存ベンダーと交渉余地があるか確認する。
Step 3: 移行先の検討
社内環境・技術力・予算に合わせて候補を2〜3社に絞る。
Step 4: PoC（概念実証）の実施
実際の環境で動作検証。移行ツールの使い勝手も確認する。また、バックアップ・監視ツールとの連携も必ず検証すること。
Step 5: 移行計画の策定
業務影響を最小化するスケジュールで段階的に移行。その際、運用Runbookの更新・担当者トレーニングも計画に含める。
個人的な考察
技術的な整理を踏まえた上で、個人的な見解も述べておきます。
短期（〜1年）
既存VMware環境を維持しつつ、更新条件の見直しやライセンス交渉を試みるのが現実的です。特に大規模契約では、一定の交渉の余地があります。
中長期（1〜3年）
新規案件でVMwareを第一候補に置く判断は、以前より慎重になるべきでしょう。WindowsベースならHyper-V、ハイブリッドクラウドを視野に入れるならAzure Localなどの選択肢、技術力があるならKVM系も現実的です。
コンテナ基盤への移行も並行検討
OpenShift Virtualizationのように、既存VMを運用しながら段階的にコンテナ基盤へ寄せていくアプローチもあります。将来的なアプリケーションのコンテナ化を進める足掛かりにもなります。
今回の変化は「VMwareが終わった」という話ではありません。ただ、これまでのように「まずVMware」という前提は問い直されつつあります。自社にとって最適な基盤を改めて考える機会として捉えるのが建設的だと思います。
参考：ITmedia Enterprise（2026年4月）、各ベンダー公式ドキュメント