Google Distributed Cloud Air-gappedとは？ 完全分離環境で動くGoogleクラウドってなんなのかを整理してみた

はじめに

近年、AIの発達によりデータを守りたい・管理したいニーズが増え、クラウドからオンプレミスに逆行しているケースは少なくありません。
上記のようなこのニーズに合わせて、各クラウドベンダは対応してきています。

私が触っているGoogle CloudからもGoogle CloudやPublic Internetへの接続を必要とせず、オンプレミス環境でクラウドサービスを利用するための「Google Distributed Cloud（GDC）」 という製品群が登場しています。ご存じでしょうか？

特に特徴的なのが、Google Distributed Cloud Air-gapped（以下、GDC Air-gapped） で、
GDC Air-gappedは、Google Cloudへ接続せず、ユーザー側のデータセンターなどでインフラやサービスをホスト・制御・管理するためのプラットフォームで、ControlPlaneまで含めた完全なオンプレ環境となっています。

Googleは、これを「厳格なデータ主権やコンプライアンス要件に対応するため、GDC Air-gappedを完全に分離された環境で利用できるソリューション」として位置付けています。

この記事では、

• Google Distributed Cloudとは何なのか
• Air-gappedとはどういう意味なのか
• どのような機能を利用できるのか
• Google Cloudとは何が違うのか
• Kubernetesが重要なのか
• AIはどのように利用できるのか

といった内容を、Googleが公開している情報をもとに読み解いていきます。

注意

本記事は2026年9月時点のGoogle公式公開情報をもとに整理したものです。
GDC Air-gappedは継続的にアップデートされているため、必ず最新の公式ドキュメントを確認してください。

Google Distributed Cloudとは

まず、GDC Air-gappedの前に「Google Distributed Cloud」について整理します。
Google Distributed Cloudは、Google Cloudのインフラストラクチャ、サービス、Kubernetesなどを、オンプレミスのデータセンターやエッジなどへ拡張するための製品群です。
現在のGoogle公式ドキュメントでは、大きく次のような選択肢が整理されています。

• Google Distributed Cloud Air-gapped
• Google Distributed Cloud Connected
• Google Distributed Cloud Software only

このうち、今回扱うのがAir-gappedです。イメージすると、以下のような位置付け。

GDC Connectedは、オンプレミスに配置したハードウェアをGoogle Cloudへ接続し、Google Cloud側から統合的に管理するモデルです。一方、GDC Air-gappedはGoogle Cloudへの接続を必要としません。
なので、Google Cloudから切り離された環境に、クラウドとして利用できるプラットフォームを構築するみたいなもので、GoogleもGDC Air-gappedについて、インフラやサービスをオンプレで直接ホスト、制御、管理できるものとして説明しています。

そもそも「Air-gapped」とは

エアギャップは重要システムやネットワークをインターネットなどの安全でない外部ネットワークから物理的に完全に隔離するセキュリティ対策のことを指します。

GDC Air-gappedの最大の特徴もここにあります。Google公式FAQには、

Distributed Cloud is a fully disconnected, air-gapped solution.

と明記されており、Google Cloudへの接続に依存しません。
一般的なGoogle Cloud利用と比較すると、イメージは次のようになります。

Air-gappedだからネットワークが存在しないわけではなく、当然GDC内部では当然ネットワークが存在します。
VMやPod間の通信に加えて、Firewall、Service Discovery、Load Balancingなどのネットワーク機能も提供されていますし、GDCではOrganizationごとに分離されたVirtual Networkが構成されます。

GDC Air-gappedは単なるソフトウェアではない

GDC Air-gappedは、一般的なオンプレミスにインストールするソフトウェア製品とは少し異なるようです。
GDC Air-gappedはHardwareとSoftwareから構成されるConverged Solutionとされています。

ざっくりイメージすると次のようになります。

ユーザーが任意に用意したサーバへGDC Air-gappedのソフトウェアだけをインストールする、という単純な製品ではありません。Googleの現在のGDCポートフォリオでは、フルデータセンターラックに加えて、より小型のApplianceや検証用Sandboxなども案内されています。

何ができるのか

では、GDC Air-gappedでは何ができるのでしょうか。
Google公式ドキュメントを見ると、クラウドっぽいサービスが提供されています。
代表的なものを整理すると、次のようになります。

カテゴリ	主な機能
Compute	Virtual Machine
Container	Kubernetes
Storage	Block Storage / Object Storage
Network	Virtual Network / Firewall / Load Balancerなど
IAM	Roleベースのアクセス制御
Observability	Metrics / Logs
AI / ML	Vertex AI / Generative AI
Management	GDC Console / gdcloud CLI / kubectl / API
IaC	Terraform

Googleの概要ドキュメントでは、GDC Air-gappedではKubernetesとVMの双方を利用でき、Data Management、AI、Machine Learning、Security、Observability、Computeなどのサービスが提供されると説明されています。

ここから主要な機能を少し掘り下げてみます。

Virtual Machine

GDC Air-gappedでは、Virtual Machine（VM）を作成できます。Kubernetes専用基盤ではありません。GDCのVM管理機能では、VMの作成から削除までのライフサイクル管理が可能で、

• GDC Console
• gdcloud CLI
• kubectl
• API

などから操作できます。また、

• OS Image
• Custom Image
• Network
• Boot Disk
• Secondary Disk
• Snapshot
• Backup

など、VM基盤として一般的に求められる機能も提供されています。Google Cloudを利用したことがある人であれば、Compute EngineのようなVMサービスがGDCに存在すると考えるとイメージしやすいでしょう。

ただし、GDCのVMはCompute Engineそのものではなく、サービスやAPI、管理方法などはGDC独自のものなので、オンプレ版Compute Engineと完全に同一視しない方がよいように見えます。

Kubernetes

GDC Air-gappedではコンテナワークロードも実行できます。
加えて、GoogleはKubernetesをGDCの重要な基盤技術として利用しています。

後述しますが、特徴として

「アプリケーションをKubernetesで動かせる」だけではなく、GDC自体のControl Plane APIにもKubernetesの仕組みが利用されている

という点は特色があり、GDCを調べていると、おなじみのkubectlコマンドが頻繁に登場します。

Storage

Storageとしては、大きく

• Block Storage
• Object Storage

が提供されています。

Block Storage

Block StorageはVMやContainerからディスクのように利用できます。
VMやContainerとは独立して存在するため、ワークロードを削除した後もStorageを保持することが可能です。

Object Storage

Object Storageも提供されており、大量の非構造化データをObjectとして保存できます。
さらにObject Storageの管理APIにも、後述するKubernetes Resource Model（KRM）が利用されています。
つまりGDCでは、ComputeだけでなくStorageなどのPlatform ResourceについてもKubernetes的な管理方法がかなり深く入り込んでいます。

Networking

GDC Air-gappedにはVirtual Networking Layerが存在します。
Google公式ドキュメントでは、このNetwork Layerが

• Connectivity
• Firewall
• Service Discovery
• Load Balancing
• Observability

などを制御するとされています。
構造をかなり単純化すると、次のように考えることができます。

各Organizationには独立したVirtual Networkが存在し、Project間の通信はProject Network Policyなどによって制御できます。
また、VMやPod向けにInternal / External Load Balancerを構成することもできます。
Air-gappedとはいえ、内部を見るとかなり本格的なCloud Networking Platformになっていることが分かります。

リソース階層はGoogle Cloudっぽい

Google Cloudでは、

Organization
 └ Folder
    └ Project
       └ Resource

というResource Hierarchyに馴染みがある人も多いと思います。GDC Air-gappedにもResource Hierarchyがあります。代表的な構造は次のようになります。

GDCで認識されるResource Typeには、

• Organization
• Project
• Shared Kubernetes Cluster
• Service Resource

などがあります。

OrganizationはResource Hierarchyの最上位に位置します。
その配下にProjectがあり、さらにVM、Standard Kubernetes Cluster、Database、Storage Bucket、BackupなどのService Resourceが配置されます。このあたりはGoogle Cloud経験者にとって比較的理解しやすい概念だと思います。一方で、Google CloudとGDCではResource Hierarchyは完全に同じではありません。

例えばIAMに関する公式比較でも、GDCは基本的に

Organization
  └ Project

という階層であるのに対し、Google CloudにはFolderも存在するという違いが説明されています。

管理方法もGoogle Cloudとは違う

GDCを調べ始めたときに個人的に分かりやすい違いだと感じるのが、管理ツールです。
Google Cloudでは一般的に、

GUI : Google Cloud Console
CLI : gcloud
API : Google Cloud API

を利用しますが、GDC Air-gappedでは、

GUI        : GDC Console
CLI        : gdcloud
Kubernetes : kubectl
API        : KRM APIなど
IaC        : Terraform

という形になります。

Google公式のDeveloper Toolsに、

• GDC console
• gdcloud CLI
• kubectl CLI
• Terraform

が主要ツールとして掲載されています。
対応関係を単純化すると、次のようなイメージかと。

Google Cloud	GDC Air-gapped
Google Cloud Console	GDC Console
gcloud CLI	gdcloud CLI
Google Cloud API	GDC API / KRM API等
IAM	GDC IAM
Organization / Folder / Project	Organization / Project
Terraform	Terraform
kubectl	kubectl

名前や考え方が似ている部分もありますが、GDCはGoogle Cloudとは別のControl Planeを持ったCloud Platformとして考える方が理解しやすいです。

KRM

特徴的なのが Kubernetes Resource Model（KRM） です。Google公式ドキュメントでは、GDC Air-gappedのControl Plane APIはKubernetes上に構築され、KRMを利用すると説明されています。

多くのGDC APIは、Kubernetes APIの拡張として実装されています。つまり、KubernetesでDeploymentなどを管理するときと同じように、宣言型ResourceとしてGDC Platformの各種Resourceを管理する考え方をもっているようです。

例えばResource Manager APIもKubernetes Custom ResourceとKRMを利用しており、OrganizationやProjectなどのLifecycleを管理します。Networking API/Object Storage APIにもKRMが利用されています。

つまり、

という世界観になっています。
Kubernetesを単純に「コンテナ実行基盤」として使っているだけではなく、Cloud Platformそのものを操作するためのResource ModelとしてKubernetesを利用している ことになります。

IAM

完全に独立した環境だからといって、各ユーザーが自由にすべてのリソースへアクセスできるわけではありません。GDCにもIAMがあり、RoleとPermissionを使ってアクセス制御します。

権限は、

• Organization
• Project

などのResource Scopeに対して付与できます。Organization Levelで付与されたRoleは、配下のProjectやResourceへ継承されます。考え方としては、Google CloudのIAMを利用したことがあれば比較的理解しやすいと思います。ただし認証方式やResource Hierarchy、APIへの接続方法などはGoogle Cloudと異なりますので、権限セットも異なりそうです。

AI利用

GDC Air-gappedにはVertex AIが用意されています。
GoogleはVertex AI on GDC Air-gappedについて、Machine Learning PlatformとGenerative AI ModelをSecure On-premises Environmentへ提供するものと説明しています。

公開されている機能には、例えば、

• Generative AI
• Online Prediction
• OCR
• Speech-to-Text
• Translation
• Vertex AI Workbench

などがあります。なお、機能によって提供ステージが異なるため、利用時には最新のFeature Stageを確認する必要があります。
また、現在のGoogle公式製品ページではGeminiがGDCで利用可能であることも明記されています。

GDC Air-gappedでは、AI ServiceをオンプレミスのAir-gapped Infrastructure内で実行することを前提としているため、データをSovereign Perimeter内に保持しながらAIを活用する
というユースケースは１つ大きな特徴になりそうですね。

「オンプレ版Google Cloud」なのか？

ここまで読むと、要するにGoogle Cloudをオンプレに持ってきたもの？
と思うかもしれませんが、個人的には違うと思っています。

Google Cloudと似た概念は数多くあります。例えば、

• Organization
• Project
• IAM
• VM
• Kubernetes
• Object Storage
• Block Storage
• Load Balancer
• Vertex AI
• Terraform

などは聞きなじみのあるものです。

しかし、Control Planeの持ち方ややAPI、CLIなどは異なります。
比較すると以下のようになります。

観点	Google Cloud	GDC Air-gapped
Infrastructure	Google Data Center	主にオンプレミス環境
Google Cloud接続	前提	不要
Public Internet	Serviceにより利用	完全分離環境で運用可能
GUI	Google Cloud Console	GDC Console
CLI	gcloud	gdcloud
Container	GKE等	Kubernetes / GKE on GDC
VM	Compute Engine	GDC VM
Storage	Cloud Storage / Persistent Disk等	Object / Block Storage
Resource Hierarchy	Organization / Folder / Project	Organization / Project等
API	REST / gRPC等	KRM API / XML / JSON / gRPC等
AI	Vertex AI	Vertex AI on GDC

感覚としては、GoogleのCloud Native技術やサービスの考え方を利用して、独立したCloud Platformをオンプレ側に構築する製品 と考える方が実態に近そうです。

Air-gappedでも更新は必要

Air-gappedだからといって、一度設置したら外部から何も持ち込まなくてよいという意味ではないです。アプデが必要ですね。
しかしながら、完全分離環境ではインターネット経由で直接ソフトウェアをDownloadすることができません。

ドキュメントでは、Air-gapped環境へSoftware Distributionを持ち込むため、Internet Accessが可能な環境でSoftwareをDownloadし、Portable Storage Deviceなどを利用してAir-gapped側へ移送する方式について説明されています。

つまりAir-gapped環境では、アップデートデータを安全に持ち込むための運用設計も重要になります。これはパブクラだとメンテしなくていい領域ですね。
（つまりオンプレと同じです)

Zoneの考え方がある

GDC Air-gappedには、Deployment Hierarchyとして

Universe
 └ Region
    └ Zone

という考え方があります。複数Zoneを利用することで、ApplicationやInfrastructureのHigh Availabilityを設計できます。例えばNetworkについても、Multi-zone環境ではZone間通信やGlobal Load Balancerなどの仕組みが提供されています。

どんな用途を想定しているのか

では、なぜここまでしてCloud PlatformをGoogle Cloudから切り離す必要があるのでしょうか。（もはやクラウドを名乗る必要はないのでは・・・）
GoogleはGDC Air-gappedについて、

• Data Sovereignty
• Regulatory Requirements
• Security
• Privacy
• National Security
• Classified / Sensitive Workloads

などの厳格な要件を持つ組織を主な対象として説明しています。
恐らく冒頭で話したような

• Cloud Nativeな開発・運用体験は欲しい
• でもデータやシステムを外部Cloudへ配置できない

というケースで価値が出てくる製品だと考えられます。
Air GapとCloud Nativeは一見すると対極にあるようにも見えますが、GDC Air-gappedは、その2つを同時に成立させることを狙ったプラットフォームと言え（そう？）です。

Google Cloud経験者から見たGDC

ここまでネットで拾ってきた情報をかき集めて紹介しましたが、
最後に、Google Cloudを触っている私目線で改めて簡単に整理してみます。

繰り返しになりますが、GDCには、Google Cloud経験者にとって馴染みのある要素がかなりあります。

Organization
Project
IAM
VM
Kubernetes
Object Storage
Block Storage
Load Balancer
Vertex AI
Terraform

一方で、

Google Cloud Console → GDC Console

gcloud → gdcloud

Google Cloud APIs → KRMベースのGDC APIsなど

という微妙な違いも見受けられました。
KRMのところで取り上げたKubernetesがWorkload Platformであるだけでなく、Cloud Platform自体を管理するResource Modelとして利用されている という概念は全然違うので、Google Cloudエンジニアというよりは、どっちかというとKubernetesを触ったことがある・詳しい人のほうがとっつきやすそう/向いてそうだなだなと思いました。

まとめ

Google Distributed Cloud Air-gappedについて、公開情報をもとに整理してみました。
特徴を4つにまとめると、

1. Google CloudやPublic Internetへの接続を必要とせず運用できる
2. VM、Kubernetes、Storage、NetworkなどCloud Platformとしての機能を持つ
3. Kubernetes Resource ModelをPlatform管理にも広く利用している
4. Data Sovereigntyや厳格なSecurity / Compliance Requirementsを持つ環境を主な対象としている

というPlatformであることを整理しました。

参考資料

本記事は、Google Cloudが公開している以下のドキュメントを中心に整理しています。

• Distributed Cloud エアギャップ