はじめに
2026年9月8日開催のNutanixのイベント「.NEXT On Tour Tokyo 2026」に参加してきました。
Nutanixが単なる「HCI／仮想化基盤」のベンダーから、
アプリケーションをオンプレミス、エッジ、パブリッククラウドのどこでも一貫して動かすためのプラットフォーム
へと、より明確に軸足を広げていることを強く感じるイベントでした。
実際、2026年の.NEXT On Tourでは「Run Anything Anywhere」が大きなテーマとして掲げられ、Infrastructure Modernization、Application Flexibility、Agentic AIなどが主要テーマとして扱われています。
特に興味を持ったのが、Nutanix Cloud Clusters（NC2）on Google Cloud
NC2自体はAWSやAzureでも提供されてきましたが、2025年12月にGoogle Cloudでも一般提供が開始されております。。
本記事ではイベント参加を通して感じたポイントとあわせて、NC2 on Google Cloudについて、持ち帰りで調べた内容を整理します。
そもそもNC2とは
NC2は Nutanix Cloud Clusters の略称で、パブリッククラウド上のBare Metal InfrastructureにNutanix Cloud Platformを展開する仕組みです。
Nutanixのオンプレミス環境では一般的に、
- AOS
- AHV
- Prism
- Flow
などからなるNutanix Cloud Platformを利用します。
NC2では、このNutanixのSoftware StackをAWS、Azure、Google CloudなどのPublic Cloud Infrastructure上でも動かします。
Nutanix公式は現在、NC2をAWS、Azure、Google Cloudに対応するHybrid Cloud Platformとして位置付けています。
イメージすると次のようになります。
つまりNC2のポイントは、VMをGoogle CloudのVMへ変換して移行する ことだけではありません。
オンプレミスで使用しているNutanixのOperating ModelそのものをGoogle Cloud側にも持っていくことで、
On-Premises Nutanix
↓
NC2 on Google Cloud
という形で環境を拡張できます。
NC2 on Google Cloudとは
Google Cloud版のNC2では、Google Compute EngineのBare Metal Instance上でNutanix Cloud Platformが直接動作します。
Google CloudとNutanixは2025年12月9日にNC2 on Google Cloudの一般提供を発表しました。Googleは、既存ワークロードをリファクタリングせず、Google Cloud上でNutanix Hybrid Cloudを実行できることを特徴として挙げています。
構成を単純化すると、次のようになります。
NC2はGoogle Cloudの外側にある専用Nutanix環境ではなく、ユーザーのGoogle Cloud環境／VPCと組み合わせて利用できるところがポイントです。
Nutanix公式でも、NC2がGoogle CloudのBare Metal Infrastructureを利用し、ユーザーのVPC内へNutanix Clusterを展開できると説明されています。
「NutanixをGoogle Cloud VM上で動かしている」わけではない
NC2では、
Google Cloud VM
└ AHV
└ VM
というNested Virtualizationのような構造ではありません。
Google Cloudが提供するBare Metal InstanceへNutanix Software Stackを直接展開します。
Google Cloud側も、Bare Metal Machine TypeをHypervisorなど、CPUやMemoryへ直接アクセスする必要のあるWorkload向けとして提供しています。
したがって概念的には、
という構造で、ここが、Google Compute Engineへ通常のVMとしてWorkloadを移行する場合との大きな違いです。
Google Cloud上でもAHVを使える
オンプレミスのNutanixを利用している人にとって、NC2の大きなメリットの一つがここです。Google Cloudへ移行するからといって、
AHV VM
↓
Compute Engine VM
へ必ずしも変換する必要はありません。NC2ではGoogle Cloud上にもAHV環境を構築できます。
そのため、
オンプレミス
Nutanix + AHV
↓
移行
↓
Google Cloud
NC2 + AHV
という移行パターンが成立します。
Google Cloudへの移行に際してアプリケーションをすぐに作り直す必要がないことを、GoogleとNutanixの双方がNC2の特徴として説明しています。これは既存VMが大量に存在する環境ではありがたいですよね。
Nutanix Moveによる移行
Workload MigrationにはNutanix Moveを利用できます。例えば、
という形です。
NutanixはNC2 on Google Cloudについて、既存ApplicationやDataをリファクタリングせずに移行する用途を大きなユースケースとして挙げています。「Cloud Migration」と「Application Modernization」を同時にやらなくてもよいのは嬉しいですね。
「移行」と「モダナイズ」を分離できる
Cloud Migrationを考えると、
① Infrastructure移行
② OS変更
③ Middleware変更
④ Application改修
⑤ Cloud Native化
を全部一度に実施しようとしてしまうことがあります。
当然、変更量が増えればRiskも増えます。NC2では、
という段階的なアプローチを取りやすくなります。
Nutanix自身も、既存ApplicationをNC2へ移行した後、BigQueryやVertex AIなどのGoogle Cloud Native Serviceと接続してモダナイゼーションを進めるシナリオを紹介しています。
Google Cloud Native Serviceも使える
もちろんGoogle Cloud上にNC2を配置するだけでは、単にデータセンターの場所が変わっただけになってしまいます。NC2 on Google Cloudのもう一つのポイントは、NC2上のApplicationからGoogle Cloud Serviceへ接続できることです。
Nutanixが例として挙げているのは、
- BigQuery
- Cloud Storage
- Vertex AI
- Cloud SQL
- Google Kubernetes Engine
などです。例えば、
といったアーキが考えられます。この構成こそNC2 on Google Cloudを見る上で重要だと思っています。
NC2は「Google Cloudへ移行するためのゴール」ではなく、「Google Cloud上でModernizationを始めるための中間地点」にもなり得る点はポイントですね。
NC2 × Vertex AIという組み合わせ
Google CloudならではなのがAIです。例えば、
既存業務Application
↓
NC2
↓
Vertex AI
↓
Generative AI / AI Model
既存Application自体をいきなりCloud Native Applicationとして作り直さなくても、
ApplicationはNC2上に維持しつつ、新しいAI機能だけVertex AIから利用する
といったModernizationが考えられます。
さらに最近では、NutanixからNC2 WorkloadとGoogle CloudのGemini Enterprise Agent Platformを組み合わせるArchitecture Exampleも公開されています。
Legacy Application
+
Cloud Native / AI
という組み合わせは、今後NC2が活躍しそうな領域の一つだと思います。
Google CloudのBare Metalには複数の選択肢がある
2026年9月時点では、Nutanixが公開しているNC2 on Google Cloudの構成として、
- C3
- Z3
- C4
のBare Metal Instanceが掲載されています。
ざっくり整理すると次のようになります。
| Type | CPU | Memory | Local Storage | 想定される特徴 |
|---|---|---|---|---|
| C3 | 96 Physical Cores | 512 / 768 / 1536 GB | なし | 汎用・柔軟性重視 |
| Z3 | 96 Physical Cores | 1536 GB | 72 TB NVMe SSD | Storage Intensive |
| C4 | 144 Physical Cores | 1080 / 2232 GB | 18 TB NVMe SSD | 高性能な汎用Workload |
C3 Bare Metal NodeにはLocal Diskがありません。
では、Nutanix AOSのStorageをどう実現するのでしょうか。
C3ではHyperdiskをAOSのStorageとして利用する
C3構成ではGoogle Cloud Hyperdisk Balancedを利用します。
Nutanixによると、C3はDiskless Nodeであり、HyperdiskをNC2のPrimary Storage Tierとして利用することで、ComputeとStorageを分離しています。
従来のNutanix HCIをイメージすると、
Compute + Local Storage
が1Nodeにまとまっている印象があります。
一方C3では、
Compute
+
Network Attached Hyperdisk
という構造になります。
NutanixによるとHyperdiskはAOS StackからLocal NVMeとして認識され、ComputeとStorage Capacityをより柔軟に調整できるようになっています。
Flow Virtual Networking
NetworkingではNutanix Flow Virtual Networking（FVN） が利用されます。
NC2 on Google CloudではFVNを利用してOverlay Networkを構成し、VM NetworkをGoogle Cloud側のNetwork Infrastructureと統合できます。
このOverlay Networkによって、Cloud間でWorkloadを移動するときのNetwork設計を柔軟にすることができます。オンプレミスNutanixからNC2へWorkloadを移す際、ComputeだけではなくNetworkも含めて「なるべく同じ運用体験」を提供しようとしている のがNC2の特徴です。
Disaster Recoveryとしても使える
NC2はMigrationだけでなく、Disaster Recoveryの用途も想定されています。
Nutanixは2026年に、Google Cloud Storageを利用するMulticloud Snapshot Technology（MST） をNC2 on Google Cloudへ追加しました。
これにより、
通常時
オンプレミス → Snapshot → Google Cloud Storage
災害時
Google Cloud Storage → NC2 → Workload Recovery
といった構成を考えることができるようになりました。
常時同規模のDR Clusterを稼働させるのではなく、必要時にCloud側のCapacityを利用する、というPublic Cloudならではの選択肢も見えてきます。
「Cloudに行く = 全部Cloud Native」ではない
今回のイベントを通じて改めて感じたのは、EnterpriseのCloud Journeyは必ずしも一直線ではないということです。
よく描かれるCloud化は、
On-Premises
↓
Public Cloud
↓
Cloud Native
↓
Container / Serverless / AI
という一本道ですが、こんなにうまくいくわけはなく、
- Legacy Application
- 大量のVM
- Windows Server
- Commercial Software
- 特殊なMiddleware
- Regulatory Requirements
などが様々な課題が出てきますので、すべてを一度にCloud Native化するのは簡単ではありません。
NC2が提示しているのは段階的なアプローチです。
まずInfrastructureの置き場所を変える。
Applicationは、その後必要なものからモダナイズする。
という選択ができます。
この「移行とモダナイズを分離できる」という点が、NC2の価値を理解する上で重要です。。
Google Cloud目線で見たNC2
Google Cloudを普段触っている側から見ると、NC2は少し不思議な存在です。
Google Cloudには、
- Compute Engine
- Google Kubernetes Engine
- Cloud Run
- Cloud Storage
- Cloud SQL
- BigQuery
- Vertex AI
など、さまざまなNative Serviceがあります。普通に考えれば、
既存VMをCompute Engineに移行すればよいのでは？
という疑問も出ますし、もちろん、それが適しているWorkloadも多数あるでしょう。
一方、大量の既存VMを抱えている環境では、Infrastructureの変更とApplicationの変更を同時に実施することがリスクになります。
NC2はその間に、
既存Nutanix環境
↓
Google Cloud上のNutanix環境
↓
Google Cloud Native Service
というBridgeを作る存在だと理解すると分かりやすいです。
VMware代替だけで見るともったいない
昨今の仮想化市場の状況から、NutanixがVMwareの代替候補として語られる機会も増えています。
もちろんその観点は重要ですが、今回のイベントやNC2を見ると、**Nutanixを単なるHypervisor Replacementとして捉えるだけでは、少しもったいない（贅沢すぎる）**と感じました。
Nutanixが現在訴求しているのは、
VM
+
Containers
+
Data
+
AI
+
On-Premises
+
Public Cloud
を一つのOperating Modelで扱うことです。NC2 on Google Cloudも、その戦略の延長にあります。
NC2が向きそうなケース
ここまでを踏まえると、NC2 on Google Cloudが特に検討しやすそうなのは、例えば次のようなケースです。
既にNutanixを利用している
オンプレミスですでにAOS / AHV / Prismを利用している場合、既存Operationを大きく変えずにGoogle Cloudへ展開できることは大きなメリットです。
大量のVMを短期間でCloudへ移したい
Application RefactoringをMigrationの前提としないため、Infrastructure MigrationとApplication Modernizationを分離できます。
DR環境をCloudへ持ちたい
Google CloudをRecovery Siteとして活用する構成も可能です。
一部だけGoogle Cloud Native Serviceを使いたい
ApplicationはNC2上に残しながら、
BigQuery
Vertex AI
Cloud Storage
Cloud SQL
GKE
などを組み合わせることができます。
Hybrid Cloudを長期的に維持したい
Cloud Migrationを「最終的に100% Public Cloudへ移行するもの」と考えるのではなく、Workloadごとに最適な配置先を選択する戦略とも相性があります。
考えるべきポイント
もちろんNC2ですべて解決するわけではありません。例えば設計時には、
- Bare Metal NodeのSizing
- Google Cloud Network設計
- FVN設計
- On-PremisesとのConnectivity
- License
- Google Cloud Cost
- Data Transfer
- Backup / DR
- Google Cloud Native化する範囲
などを考える必要があります。単純なLift & Shiftだけで終わる場合、
Datacenter Cost
↓
Cloud Cost
へ置き換えただけになる可能性もありますので、、、
イベントを終えて
今回.NEXT On Tourに参加して、口を揃えて言っていたのが、Nutanixが「Infrastructureをどこに置くか」より、「どこに置いても同じように運用できること」を重視している
これが最大のコンセプトであり価値なのでしょう。
On-Premises
AWS
Azure
Google Cloud
Edge
はそれぞれ別のInfrastructureとして考えることが一般的でした。Nutanixが目指しているのは、その差をソフトウェア側で吸収して、
Application
↓
Nutanix Cloud Platform
↙ ↓ ↘
On-Prem Cloud Edge
というワンストップな世界を作ることなのだと思います。
NC2 on Google Cloudは、その考え方がGoogle Cloudまで広がったものと見ることができます。
まとめ
NC2 on Google Cloudについて整理すると、以下のようになります。
- Google CloudのBare Metal Instance上でNutanix Cloud Platformを実行する
- AOS / AHV / Prismなど、NutanixのOperating ModelをGoogle Cloud上にも展開できる
- 既存Applicationを大きく変更せずにCloud Migrationする選択肢を提供する
- BigQueryやVertex AIなどGoogle Cloud Native Serviceと組み合わせられる
- Migration、DR、Hybrid Cloud、Application Modernizationなど複数の用途を持つ
参考情報
本記事の製品仕様・技術情報は、イベントおよび公式情報をもとに記載しております。