VMware値上げ2026｜代替移行の費用と判断軸【中堅企業】

結論から先に述べる。Broadcomによる買収完了（2023年11月）以降、VMwareは永続ライセンスの新規販売を終了してサブスクリプションへ一本化し、製品ラインアップを4つの主要バンドルへ集約、課金もCPU1個あたり最低16コアを購入する方式へ変わった。この3点が重なった結果、更新のタイミングで届く見積もりが従来の数倍規模に膨らむ事例が国内外で報告されている。中堅企業（本記事では従業員300〜1,000名規模を想定）にとって2026年は、多くの契約満了が2026〜2027年に集中するため、「Broadcomのサブスクを飲むか、代替へ移すか」を先送りできず決めきる年になっている。

代替の現実解は、Nutanix AHV（HCI一体型）、Microsoft Hyper-V（Windows資産の活用）、Proxmox VE（OSS・低コスト）、Red Hat OpenShift Virtualization（コンテナとVMの統合）の4つに、Oracle DBを多く抱える企業ではOracle Linux KVM、ハード刷新を伴う企業ではHPEのVM Essentials（旧Morpheus）を加えた選択肢へ収斂する。ただし「どれが正解か」は製品比較表だけでは決まらない。自社の既存スタック、内製できる運用範囲、I/O特性、ロックインをどこまで許容するか——この4軸で自社の条件に当てはめて初めて答えが出る。本記事は、製品比較にとどまらず、経営・情シス・発注担当が発注前に判断ミスを避けるための「見積もりの読み方」「移行の失敗パターン」「発注前チェックリスト」まで踏み込んで整理する。

価格について：Broadcomは公式の定価表を公開しておらず、価格はパートナー／代理店経由の個別見積もりで確定する。本記事の金額は複数の公開報道・ベンダー資料から得た「方針としてのレンジ」であり、断定的な単価ではない。実際の調達では必ず最新の見積もりをベンダーから取得してほしい。

---

この記事を読むべき人

• VMware（vSphere／vSAN／NSX）を8〜20台規模で運用し、更新見積もりを見て「桁が違う」と感じた情シス・インフラ担当
• 代替候補の名前は聞くが、自社にどれが合うのか、費用がいくらかかるのかの判断軸が持てない経営者・事業責任者
• SIerから移行の提案・見積もりを受け取り、その金額が妥当か、何を確認すべきか第三者の視点が欲しい発注担当
• 「とりあえず一度Broadcomを更新して先送りする」判断が正しいのか迷っている決裁者

社内にIT判断の専任者が少なく、「大きな失敗を避けたい」層を主眼に置いて書いている。技術者向けのベンチマーク詳細ではなく、意思決定に必要な論点の順序と落とし穴に重心を置く。

---

目次

• VMware Broadcom ライセンス改定で何が変わったか
• 代替仮想化基盤の比較（4本柱＋2つの補助線）
• 中堅300-1,000名の代替選定マトリクス
• 移行費用の内訳と試算レンジ
• 移行見積もりの読み方（GXOの視点）
• 移行プロジェクトの失敗パターン
• 12-18ヶ月の段階移行ロードマップ
• バックアップ・DRの取り回し
• 発注前チェックリスト
• ベンダーに必ず聞くべき質問
• GXOに相談すべきタイミング
• FAQ
• 参考資料

---

VMware Broadcom ライセンス改定で何が変わったか

中堅企業の調達担当が押さえるべき変更点は次の5つに整理できる。順に見ていく。

1. 永続ライセンスの新規販売を終了、サブスクへ一本化

vSphere／vSAN／NSXなどの永続ライセンス（Perpetual License）の新規販売は買収後に終了し、新規購入・機能追加・拡張はすべてサブスクリプション契約が前提になった。手元の永続ライセンスをすぐ失うわけではないが、サポート更新や拡張の局面でサブスクへの切替を迫られる構造になっている。ここが「更新のたびにコストが跳ねる」体感の起点である。

2. 製品ラインアップの集約——4つの主要バンドルへ

買収前は160以上（かつては数千SKU）に及んだ製品群が、主要4バンドルへ集約された。2026年時点の骨格は次の通り（出典は二次情報を含むため後掲の参考資料で明記）。

かつて中堅が好んで使った「ESXi＋vCenterの最小構成」や小規模向けのEssentials Kitは整理・終息の方向にあり、付属機能込みのバンドル契約が事実上の標準になった。「使わない機能まで買わされる」という不満はここから来ている。バンドル名や内訳はバージョン更新（vSphere Foundation 9.0など）で変わり得るため、契約前に最新の製品構成をパートナーへ確認することを前提にしてほしい。

3. CPU1個あたり最低16コアの課金

課金はコア単位で、CPU（ソケット）1個あたり最低16コアの購入が必要になった。ここは誤解が多い。「ホストあたり16コア」ではなく「CPUあたり16コア」であり、8コアのCPUを2個載せたサーバでも実コア16に対して課金16なので損はないが、低コアのCPUを多ソケットで並べる構成や、コア数の少ない古いサーバを多数運用している環境ほど、実際に使っているコアより多く課金される「切り上げ」の影響を受ける。台数を絞って高コアCPUに寄せた構成のほうがコア課金上は有利になりやすい、という設計判断がここで効いてくる。

4. 値上げ倍率——「数倍」は方針として織り込む

具体的な倍率は契約条件・バンドル選択・既存割引の有無で大きく振れるため、断定は避けるべきだ。ただし方向性は明確で、複数の公開情報が「増加」を一致して報告している。TechTargetが引用した調査会社Omdiaの2025年の調査では、Broadcomのライセンス変更後にコスト増を実感した組織が72%に達したと報じられている（二次情報）。個別の値上げ倍率としては、平均で数倍、条件次第で二桁倍に達した事例も報道ベースで散見される。金額の絶対値を鵜呑みにするのではなく、「自社の見積もりを取り、それがなぜその金額なのかを分解する」という姿勢が正しい。

5. パートナープログラムの再編

VMware Partner Connectは終息し、Broadcom側のパートナープログラムへ統合された。長年付き合ってきた地場のSIer／販売代理店がパートナー資格や取扱いを失うケースもあり、調達ルートそのものの見直しを迫られる企業がある。「これまでの窓口に頼めば従来通り」が通用しない可能性を前提に置いておきたい。

判断の起点となるTCO比較

Broadcom残留と代替移行を比べる土台は、3年（または5年）のTCOで揃えることだ。ライセンスだけを比べると判断を誤る。

TCO = ライセンス + 保守 + 運用人件費 + ハード減価償却
（代替移行の場合は上記に「移行プロジェクトの一時費用」を加算して回収年数を判定）

代替移行は初年度に一時費用が集中してかさむため、単年度で比べると必ず割高に見える。3〜5年で均して初めて是非が判断できる。この視点の欠落が、後述する失敗パターンの入口になる。レガシー刷新・移行の進め方を体系立てて検討したい場合は、レガシー刷新・移行の進め方をまとめたDX・システム開発の考え方も判断材料になる。

---

代替仮想化基盤の比較（4本柱＋2つの補助線）

中堅が現実的に検討対象とすべき本命は4つ。加えて、条件が合う企業だけに効く補助線が2つある。まず本命4つを横比較する。金額はすべて「方針としてのレンジ」であり、構成・ベンダー・保守年数で変動する。

Nutanix AHV——運用の手離れを買う

Nutanixのハイパーバイザ「AHV」はKVMベースで、ライセンスに含まれ追加課金がない。単一管理画面（Prism）、ワンクリックのアップグレード、分散ストレージの一体運用が強みで、「情シスの人数が少なく運用の手離れを優先したい」中堅に合う。VMwareからの移行はエージェントレスのMoveツールが用意される。懸念は認定HCIアプライアンス前提でハード選択の自由度が下がる点と、ライセンス自体はVMwareほど安くはない点だ。安さではなく運用工数の圧縮を買う選択と理解するのが正しい。

Microsoft Hyper-V——既存スキルが最大の武器

Hyper-VはWindows Serverに標準搭載され、Datacenterエディションなら物理ホスト上のVM数が実質無制限になる。すでにActive Directory／Microsoft 365／Windows Serverを運用している企業なら、追加のハイパーバイザ費用と学習コストを最小化できる。既存SANをそのまま流用できる点も、SAN残価が大きい企業には効く。弱点はLinuxゲストの統合が他系統よりやや劣ること、そしてMicrosoftがHCI用途をAzure Stack HCIへ誘導する傾向があり、純粋なオンプレHyper-Vの将来像を自社で見極める必要があることだ。

Proxmox VE——安いが「運用を自社で持てるか」が全て

Proxmox VEはKVM＋LXCベースのOSSで、Proxmox社が商用サブスクリプション（ソケット単位）を提供する。Ceph統合によるHCI、専用のバックアップサーバ、Web UI／API管理が揃い、ライセンスコストはVMware比で大幅に下がる。国内でも日本語サポート付きの導入を扱うSIerが増えている。ただし最大の論点はコストではなく体制だ。「障害の一次切り分けを社内でできるか、それともすべてベンダーに投げたいか」——後者を望むなら、安さだけでProxmoxを選ぶと運用で詰まる。内製エンジニアがLinux／KVM／Cephを扱える企業向けの選択である。

OpenShift Virtualization——長期のコンテナ化を見据える企業向け

OpenShift VirtualizationはKubeVirtベースで、Kubernetes上でVMとコンテナを同一基盤に載せる。すでにKubernetes／OpenShiftを採用している、あるいは新規アプリのコンテナ化を進めている企業にとって、VMを段階的にコンテナへ寄せる長期戦略と噛み合う。裏を返すと、「単純にVMをそのまま動かしたいだけ」の用途では学習・構築コストが重く、他の3つに分がある。短期のVMware代替というより、5年スパンの基盤戦略として評価すべき選択肢だ。

補助線1：Oracle DBが多いならOracle Linux KVM

Oracle Databaseを多数のVMで動かしている企業では、仮想化基盤の選択がDBライセンスコストを大きく左右する。Oracleのコア課金は仮想化のパーティショニング方式の扱いで課金コア数が変わり、ハードパーティショニングが認められる基盤ではDBライセンスの対象コアを絞れる可能性がある。国内競合の比較記事でも、この「Oracleライセンス削減」を最大の判断材料に据える論調がある。DB周りのライセンスは金額インパクトが大きいので、仮想化基盤とDBライセンスは必ずセットで再交渉すべきだ。ただし認定条件はベンダーのポリシーに依存するため、必ずOracleの最新方針を確認すること。

補助線2：ハード刷新を伴うならHPEなどのVM基盤も候補

大量のVMを抱える企業がハード刷新とセットで移行する例では、HPEのVM Essentials（旧Morpheus由来のVM管理基盤）へ2,500VM規模を移した事例も報じられている（二次情報）。ハードとセットで基盤を一新する前提なら、サーバベンダー系のVM基盤も比較の土俵に乗る。中堅の多くは本命4つで足りるが、大量VM＋ハード更新が重なる企業は視野に入れておきたい。

---

中堅300-1,000名の代替選定マトリクス

4択（＋補助線）から自社向けを絞り込むための4軸を示す。順に自社を当てはめると、候補が2つ程度に絞れる。

軸1：既存スタック

軸2：内製できる運用範囲

• 内製エンジニアが複数名いてLinux／KVM／Ansible等の運用経験がある → Proxmox VE／OpenShift Virtualizationが射程に入る
• 情シスが少人数でSI依存が前提 → Nutanix AHVまたはHyper-V
• 運用を完全外注し、ベンダーマネジメント中心 → Nutanix AHV（HCI一体で外注範囲が読みやすい）

軸3：データ量・I/O特性

• 基幹ERP／DBなど低レイテンシI/Oが要る系統が多い → Nutanix AHV（ローカルNVMe）またはHyper-V＋既存SAN
• 汎用Web／アプリサーバ中心でI/Oが中庸 → Proxmox VE＋Cephで十分なことが多い
• 大容量データとコンテナが混在 → OpenShift Data Foundation

軸4：ベンダーロックイン許容度

• 管理工数の最小化を最優先しロックインを許容 → Nutanix AHV
• 既存Microsoft資産の範囲なら許容 → Hyper-V
• ロックインを避けOSSを優先 → Proxmox VE
• 長期でクラウドネイティブ化を狙う → OpenShift Virtualization

典型的な着地の傾向

一般論として、Microsoft資産の厚い製造・物流・地場流通系はHyper-VかNutanix AHVに落ち着きやすく、ITサービス・SaaS寄りの企業はNutanix AHVやOpenShift Virtualizationが増える。コストを最優先し内製運用力がある企業ではProxmox VEの採用が近年伸びている。ただしこれは傾向であって、実際の最適解は4軸の掛け合わせで決まる。自社の条件で機械的に絞り込むことが、雰囲気やベンダーの推しで決める判断ミスを防ぐ。

---

移行費用の内訳と試算レンジ

移行費用は「ハード」「ライセンス」「プロフェッショナルサービス（設計・構築）」「データ移行」「並行稼働コスト」「教育」の6項目に分解できる。ここを丸めて「一式いくら」で受け取ると、後述する失敗の温床になる。10ホスト／200VM／200TBという中堅の典型構成で、方針としてのレンジを2ケース示す（実額は構成で変動する）。

ケースA：VMware → Nutanix AHV

Nutanixは運用の手離れが良い一方、ハードとライセンスの比重が大きい。「運用人件費の圧縮」を回収の主軸に置いて3〜5年で判定する。

ケースB：VMware → Hyper-V（既存SAN流用）

Hyper-Vは既存SAN・既存スキルを流用できるほど一時費用が下がる。既存資産の残価が大きい企業ほど有利になりやすい。

Proxmox VE／OpenShift Virtualizationの位置づけ

• Proxmox VE：ハード＋サブスク＋プロサービスの合計が最も低くなりやすいが、運用を内製で吸収する前提。運用力がなければ「安物買い」になる。
• OpenShift Virtualization：購読とプロサービスが重く一時費用は高め。短期の代替ではなく長期のコンテナ化投資として回収を設計する。

中堅の妥当な着地は、内製運用のProxmox最安ケースから、Nutanix／Hyper-Vの中位ケースまで、おおむね数百万円台〜数千万円規模のレンジに収まることが多い。重要なのは総額の一点ではなく、6項目のどこにいくら乗っているかを分解して見ることだ。移行の全体設計を第三者と整理したい場合は、システム移行・再構築の相談窓口で論点の切り分けから始めるとよい。

---

移行見積もりの読み方（GXOの視点）

SIerから届く移行見積もりは、総額の大小ではなく「内訳の根拠」で評価する。ここは競合の製品比較記事がほとんど踏み込まない領域であり、発注前の判断ミスが最も起きやすい。以下の観点で分解してほしい。

• 「一式」の粒度を疑う：ハード・ライセンス・構築・データ移行・並行稼働・教育が1行にまとまっていたら、必ず分解を求める。分解できない見積もりは、後から追加費用が発生しやすい。
• データ移行の単価根拠：VM1台あたりいくらか、停止許容の有無で単価がどう変わるか、検証（移行後の動作確認）工数が含まれるかを確認する。「移行するだけ」で検証が別費用というケースは珍しくない。
• 並行稼働費が計上されているか：旧VMware環境を数ヶ月維持する費用が抜けている見積もりは、実行段階で膨らむ。並行稼働はロールバックの保険であり、削るとリスクが跳ね上がる。
• 教育・運用移管の費用：基盤を変えれば運用手順が変わる。研修と運用ドキュメント整備が入っているかを見る。ここが抜けると本番後に運用が回らない。
• 保守年数と更新条件：ハード・ライセンスの保守が何年か、更新時にどう上がるか。初期だけ安く見せて更新で回収する構造でないかを確認する。
• 前提条件の明記：VM台数・容量・ネットワーク構成など、見積もりの前提が書かれているか。前提が曖昧なほど、実測で数量が増えて追加請求になりやすい。

見積もりを比較する際は、複数ベンダーで前提（VM数・容量・保守年数・並行稼働期間）を揃えて出させることが鉄則だ。前提が揃っていない見積もりを金額だけで比べると、安く見えるほうが実は多くを削っていた、という判断ミスに直結する。第三者の視点で見積もりを検証してから発注に進みたい場合は、移行前の第三者診断（AI導入可否アセスメントの壁打ち）のように、発注前に論点を整理する場を挟む選択肢もある。

---

移行プロジェクトの失敗パターン

VMware移行は「製品を選んで終わり」ではなく、プロジェクトとして失敗する典型がある。GXOが重視する失敗パターンを、原因と回避策のセットで挙げる。

• PoCを飛ばして本番一斉移行に走る：見積もりの安さや納期の都合でPoCを省くと、性能不足や運用手順の不備が本番で露呈する。基幹DBのI/Oは必ず小規模PoCで実測する。
• 並行稼働期間を短縮する：予算圧縮のために並行稼働を切り詰めると、問題が出たときの戻り先が消える。並行稼働はコストではなく保険と考える。
• DR・バックアップを後付けにする：基盤を変えるとバックアップ製品やDR構成の対応可否が変わる。移行の後半でDRを設計し始めると、データ整合性の破綻リスクが出る。DRはPoC段階で検証する。
• Oracle等のDBライセンスを見落とす：仮想化基盤の変更でDBライセンスのコア課金が変わることがある。基盤だけ最適化してDBライセンスが跳ねれば、総額では損をする。
• Broadcomの解約・更新の通告期限を逃す：更新の自動継続や解約の事前通告期限（数十日前など）を見落とすと、不要な更新を1年分背負う。契約書の通告条項を移行計画の最初に確認する。
• SIの「言い値」見積もりを分解せず丸呑みする：前述の見積もりの読み方を経ずに総額で承認すると、追加費用と手戻りの温床になる。
• 業務部門の繁忙期に移行を重ねる：年度末や月末の繁忙期に本番移行を当てると、障害時の業務影響が最大化する。移行の集中期は業務カレンダーから逆算して避ける。
• 特定ベンダーの推し基盤で意思決定してしまう：付き合いのあるベンダーが扱える製品に引っ張られ、自社の4軸に合わない基盤を選ぶ。中立の立場で選定を検証する仕組みを持つ。

これらはいずれも、技術の問題というより意思決定と段取りの問題だ。だからこそ、経営・現場・情シス・外部パートナーの役割を早い段階で分け、誰が何を判断するかを決めておくことが効く。

---

12-18ヶ月の段階移行ロードマップ

中堅が現実的に回せるスケジュールは5フェーズで構成される。VMwareの契約満了日から逆算し、余裕を持って着手するのが要点だ。

Phase 0：棚卸し・要件定義（1-2ヶ月）

現vSphereクラスタの全VMを棚卸し（CPU／メモリ／ストレージ／I/O／依存関係）し、アプリ別のSLA・RTO／RPOを整理する。ライセンス満了日を確認し、Broadcomの更新見積もりを比較対象として取得。代替候補へRFIを出し、経営会議でTCO比較とGO／NO-GOを判断する。この段階でラック・電力・DC契約の満了日も併せて棚卸ししておく。

Phase 1：PoC（2-3ヶ月）

移行先1〜2候補で小規模PoC（2〜3ホスト／20〜30VM）を実施。基幹DBのI/OやWebのレイテンシをベンチマークし、バックアップ・リストア・ノード障害・アップグレードといった運用手順を検証する。ここでDR設計も必ず試す。並行してSIベンダーを選定・契約する。

Phase 2：本番並行稼働の開始（3-4ヶ月）

本番環境を構築し、まず開発・検証環境のVMを移行。バックアップ基盤の併用設定と監視の二重化を整える。ここで運用ドキュメントの初版を作る。

Phase 3：本番VMの順次移行（5-7ヶ月）

重要度の低いVMから高いVMへ、月30〜50台のペースで移行する。各移行は「平日夜間メンテ→翌営業日確認」のサイクルで回し、基幹ERPや決済系は並行稼働を1〜2ヶ月取って慎重に切り替える。月次で経営層・業務部門へ進捗を報告する。

Phase 4：旧VMware環境の撤去（1-2ヶ月）

全VMの移行完了を確認して旧環境をシャットダウン。VMwareサブスクを解約（更新前の通告期限を厳守）し、旧ハードの廃棄・流用を判定。プロジェクトを振り返り、運用へ引き継ぐ。

スケジュール上の勘所

契約満了日の18ヶ月前にはPhase 0へ着手するのが安全だ。並行稼働は最低でも数ヶ月を確保し、短縮しない。年度末・月末など業務部門の繁忙期に移行を集中させないことも、障害時の被害を抑えるうえで効く。

---

バックアップ・DRの取り回し

仮想化基盤を入れ替えるとき、バックアップ・DRも同時に見直しが必要になる。ここを後回しにすると、移行後に「バックアップが取れない」「DRが組めない」という事態を招く。

統合バックアップ製品のマルチ基盤対応

Veeamのような統合バックアップ製品は、vSphere／Hyper-V／Nutanix AHV／Proxmox VE／KubeVirt（OpenShift Virtualization）を横断して扱える点が中堅に効く。ライセンスをVM単位ではなくインスタンス単位で持てる形態なら、ハイパーバイザを跨いでもライセンスを流用しやすい。移行プロジェクトに合わせてバックアップ契約を見直すのが効率的だ。Commvault、Rubrik、HYCUなども対応範囲が広がっているが、Proxmox対応の可否や成熟度は製品ごとに差があるため、選んだ基盤との組み合わせで必ず対応状況を確認する。

DR（災害対策）の代替

VMwareのSite Recovery Manager（SRM）は上位バンドル前提の扱いになり、単独購入が難しくなった。基盤ごとのDRの受け皿は次の通り。

• Nutanix：Leap（DRaaS）＋Metro Availability
• Hyper-V：Hyper-V Replica＋Azure Site Recovery
• Proxmox VE：バックアップサーバ＋ZFS／Cephの非同期レプリケーション＋DR手順の整備
• OpenShift Virtualization：OpenShift API for Data Protection（OADP）＋Velero

DR設計は移行のPhase 1（PoC）段階で必ず検証する。後付けで設計するとデータ整合性の破綻リスクが高い。

---

発注前チェックリスト

VMware移行に固有の論点に絞ったチェックリスト。発注前にこの順で潰しておくと、判断ミスと追加費用の大半を避けられる。

• 現vSphereの全VMを棚卸しし、CPU／メモリ／ストレージ／I/O／依存関係を数値で把握しているか
• 各アプリのSLA・RTO／RPOを整理し、慎重に扱うべき基幹系を特定しているか
• VMwareの契約満了日と、解約・更新の事前通告期限を契約書で確認しているか
• Broadcomの更新見積もりを「比較の基準線」として取得しているか
• 代替4択（＋Oracle／HPE等の補助線）を、既存スタック・内製度・I/O・ロックインの4軸で自社に当てはめたか
• 既存SAN・既存Windowsライセンスなど、流用できる資産を洗い出したか
• Oracle等のDBライセンスが基盤変更でどう変わるか、DBベンダーへ確認したか
• 見積もりを6項目（ハード／ライセンス／構築／データ移行／並行稼働／教育）に分解して受け取っているか
• 複数ベンダーで見積もりの前提（VM数・容量・保守年数・並行稼働期間）を揃えているか
• PoCで基幹DBのI/OとDR手順を実測する計画があるか
• 並行稼働期間を数ヶ月確保し、ロールバックの余地を残しているか
• バックアップ・DRを移行前半で設計・検証する段取りになっているか
• 移行の集中期が業務部門の繁忙期と重なっていないか
• 経営・現場・情シス・外部パートナーの役割分担と、誰が何を判断するかを決めているか
• 初期費用だけでなく、3〜5年のTCOと更新時の値上がりまで見積もっているか

---

ベンダーに必ず聞くべき質問

SIerやベンダーの提案を受けるとき、次の質問への回答で提案の質が測れる。答えが曖昧なら、その提案は要注意だ。

• この見積もりの前提（VM数・容量・保守年数・並行稼働期間）は何か。前提が変わると総額はどう動くか。
• データ移行の単価はVM単位でいくらか。停止許容の有無で単価はどう変わり、検証工数は含まれるか。
• 並行稼働の期間と費用はどれだけ見込んでいるか。ロールバックの手順は用意されるか。
• 提案する基盤で、既存のバックアップ・DR製品はそのまま使えるか。使えない場合の代替と追加費用は。
• 障害時の一次切り分けは自社とベンダーのどちらが担うのか。夜間・休日の対応範囲は。
• 3〜5年後の更新時に、ライセンス・保守はどう上がる見込みか。
• 御社は特定ベンダーの代理店として推しているのか、中立に複数を比較したうえでの推奨か。

最後の質問は特に重要だ。付き合いのあるベンダーが扱える製品に引っ張られる構造こそ、中堅の意思決定が歪む最大の要因になる。

---

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、発注を決める前に第三者の視点を挟む価値がある。

• Broadcomの更新見積もりを見て「桁が違う」と感じたが、それが妥当なのか判断材料がない
• 代替候補の名前は分かるが、自社にどれが合うのか4軸で絞り込めない
• SIerから移行の提案・見積もりを受け取ったが、内訳の妥当性を自社で検証できない
• 「とりあえず1年更新して先送りする」判断が正しいのか迷っている
• 移行を任せられる中立のPMO（特定ベンダーの代理人でない立場）が欲しい

GXOは、現vSphere構成の読み取りから代替候補のTCO比較、移行PoCの設計、SIベンダー選定の支援、移行プロジェクトの中立PMOまで、発注前の論点整理を起点に伴走する。特定ベンダーの製品を売る立場ではなく、自社の条件に対して何が最適かを一緒に見極める役割だ。まずは論点の整理から始めたい場合は、レガシー刷新・移行の進め方の考え方に沿って、現状のヒアリングと構成読み取りに着手するとよい。

---

FAQ

Q1：結局どこが一番安いのか？

3年TCOで見ると、内製運用を前提にできるProxmox VEが最も低くなりやすく、既存SAN・Windowsスキルを流用できるHyper-Vが続く。Nutanix AHVは運用工数の圧縮を、OpenShift Virtualizationは長期のコンテナ化を回収軸に置く。ただし「安い＝正解」ではない。運用を全面外注したい企業がProxmoxを選ぶと運用で詰まるように、安さと自社の運用体制は必ずセットで判断する。

Q2：内製スキルがHyper-Vにしかない場合は？

素直にHyper-Vを第一候補にしてよい。Windows Server／AD／SCVMM／PowerShellのスキルがそのまま流用でき、研修コストも最小化できる。Linux VMが一定数あっても、Hyper-VのLinux統合は近年改善しており、主要ディストリビューションは本番運用に耐える水準にある。

Q3：Proxmoxの商用サポートは実務で大丈夫か？

Proxmox社が提供する商用サブスクリプションは欧州で長年の実績があり、国内でも日本語サポート付きの導入を扱うSIerが増えている。ポイントは「一次切り分けを社内でできるか」だ。障害時にベンダーへ丸投げしたい体制ならNutanix AHVやHyper-Vが無難で、内製でLinux／Cephを扱えるならProxmoxのコストメリットが活きる。

Q4：VMwareを残してアプリだけ移すのは可能か？

技術的には可能だが、VMwareを残すこと自体がBroadcomの値上げを飲む選択なので、TCO的な意味は薄い。ただし「重要度の低いVMだけ先に代替へ逃がし、Broadcomサブスクを縮小契約に切り替える」段階的な縮退は有効だ。旧基盤と新基盤を1〜2年共存させながら移す企業も増えている。

Q5：データセンター・電力契約はどうなるか？

HCI化（Nutanix、Proxmox＋Ceph）で物理ホスト数が減れば、ラック・電力のコストが下がるケースが多い。一方、Hyper-V＋既存SAN継続なら物理構成はほぼ変わらず見直し余地は小さい。移行のPhase 0でラック・電力・DC契約の満了日も棚卸ししておくと、基盤刷新と契約見直しを同期できる。

Q6：既存のSANストレージは流用できるか？

Hyper-V／Proxmox VE／OpenShift Virtualizationは、iSCSI／FC／NFS等で既存SANを流用しやすい。一方Nutanix AHVはHCI前提のため、既存SANの流用は基本的に想定されない。SANの残価が大きい企業は、流用できる基盤を選ぶほど一時費用を圧縮できる。

Q7：基幹ERP（SAP／Oracle EBS等）が動いている場合は？

まず各ERPベンダーのサポートマトリクスで、移行先基盤が正式サポート対象かを確認する。特にOracle DBは仮想化基盤の選択でライセンスのコア課金が変わり得るため、基盤選定とDBライセンスの再交渉をセットで動くことが重要だ。基幹系は並行稼働を長めに取り、慎重に切り替える。

Q8：Broadcomに値上げの交渉余地はあるか？

大口顧客では個別交渉で一定の値引きを得た事例が報道ベースで見られるが、中堅規模では代理店経由の標準価格が適用され、交渉余地は限定的なことが多い。ただし「代替への移行を本気で検討している」という事実そのものが交渉のカードになる。代替検討を進めること自体が、残留する場合の交渉力にもつながる。

---

参考資料

• Broadcom公式：VMware by Broadcom Product Offerings（製品バンドル再編・サブスクリプション化）
• Broadcom公式：VMware vSphere Foundation／Cloud Foundation Licensing Guide（CPUあたり最低16コア規定）
• Omdia調査（TechTargetジャパン／Informa TechTargetによる報道、2025年）：ライセンス変更後にコスト増を実感した組織が72%（二次情報）
• Nutanix公式：Nutanix Move Documentation（VMware→AHVエージェントレス移行）
• Microsoft公式：Hyper-V on Windows Server／System Center Virtual Machine Manager
• Proxmox VE公式：Subscription Plans and Pricing（商用サブスクリプション）
• Red Hat公式：OpenShift Virtualization Reference Architecture
• Veeam公式：Veeam Universal License（マルチハイパーバイザ対応）
• 各種業界メディア（バンドル構成・価格倍率に関する記述は二次情報を含む。本記事の金額は「方針としてのレンジ」であり、実際の価格はパートナー経由の個別見積もりで確定する）

---

本記事は2026年7月16日時点の公開情報に基づく。Broadcom／各ベンダーのライセンス体系・価格・製品構成は変更される場合があるため、実際の調達時には最新の見積もりと公式情報を必ず確認してほしい。