「オンプレに置けるクラウド」が多すぎるので、整理してみた（後編） ─ Outposts / Alloy / GDC、結局なにが違うの？

これは前後編の後編です。

• 前編：外部との接続を保ったまま主権を手元に寄せるタイプ（①延伸・接続型 / ②独立運営型）。→「オンプレに置けるクラウドが多すぎるので整理してみた（前編）」
• 後編（この記事）：接続を切って自律する世界（③遮断型 / ④自前）。完全閉域（air-gapped）が要件の人向け。

前編を読んでいなくても大丈夫なように、2軸の要点は最初に振り返ります。

この記事は特定製品の推奨をするものではありません。分類の考え方の共有が目的です。なお本記事の分類（4タイプ・2軸）は、各社の公式ドキュメントをもとにした筆者の整理であって、各社の公式見解ではありません。仕様は変わりやすい領域なので、採用検討時は必ず各社の最新ドキュメントを確認してください（本記事は2026年7月時点の公開情報に基づきます）。

振り返り：2つの問いで4タイプに分ける

この領域の製品（Outposts、Alloy、GDC、Azure Local、OpenShift……）は名前がバラバラで覚えきれません。なので前編では、製品名ではなく2つの問いで分類しました。

1. コントロールプレーン（司令塔）が自律して動くか？ ── 外部（クラウドや遠隔の運用者）への接続なしで管理操作を続けられるか、それとも接続前提か。（司令塔が物理的にどこにあるかは別問題。ローカルにあっても、運用のため接続前提なら"自律"はしていません。）
2. それを誰が運営・管理するのか？ ── クラウド事業者か、現地パートナーか、自組織か。

この2軸で4タイプに分かれます。

タイプ	司令塔は自律してるか	運営するのは誰か	（結果）切断したら	代表例
① 延伸・接続型（前編）	接続前提（自律しない）	クラウド事業者	管理操作が止まる	Outposts / GDC connected / Dedicated Region / Azure Local
② 独立運営型（前編）	接続前提（自律しない）	現地の独立法人・パートナー	製品による	Alloy / GCD / European Sovereign Cloud / National Partner Clouds
③ 遮断型（この後編）	自律（接続不要）	自組織（パートナー運営も可）	動く（切断が前提）	GDC air-gapped (Google), Isolated Region (Oracle), Azure Local (Microsoft)
④ 自前（この後編）	自律（接続不要）	自組織	動く（自分で全部握る）	OpenShift (Red Hat), Nutanix

前編で扱った①②は「接続を保ったまま主権を手元に寄せる」タイプでした。この後編で扱う③④は、その先──「接続を切って自律する」世界です。切ってでも自律したいのはどんな時か、その代わりに何を背負うのか。ここが本題です。

タイプ③：遮断型 ── 制御を内包して、切っても動く

タイプ③は、コントロールプレーンを手元に内包し、外部との接続なしで完結して動くものです。代表は GDC air-gapped (Google) と Isolated Region (Oracle)。

⚠️ 名前の注意。GDCには connected と air-gapped があり、名前が2語違いなので混同されやすいのですが、司令塔の所在が真逆です。connectedはタイプ①（クラウドの延伸・接続前提）、air-gappedはこのタイプ③。「どっちだっけ？」となったら、"gap"（断絶）があるのがair-gappedと覚えればOK。名前がちゃんと機能を表している数少ない例です。

GDC air-gappedは、ローカルにコントロールプレーンを内包し、Google Cloudやインターネットへの接続を一切必要とせず、恒久的に切断されたまま運用できるよう作られています¹。ハードウェア・ソフトウェア・ローカルコントロールプレーン・運用ツールまで含んだフルスタックの閉域プライベートクラウドです²。

どのくらい徹底しているかというと、ソフトウェアの取り込みすら、いったんインターネット接続環境でバイナリをダウンロードし、USBメモリや外付けドライブなどの物理媒体でエアギャップ環境に運ぶ、という手順を踏みます³。ネットワーク経路が本当に一切ない、ということです。

運営主体は自組織とは限りません。air-gappedにはパートナー運営モデルもあり、ベルギー・ルクセンブルクのProximusのように、現地の信頼できるプロバイダが運営を担う形態があります⁴。「司令塔は手元に内包（問1）、運営は自組織かパートナーか（問2）」——2軸のうち問2が選べるタイプ、とも言えます。

Oracleの Isolated Region も、防衛・情報機関向けに同じ発想で提供されています。運用主体はOracle・顧客・パートナーから選べる（＝問2が可変）ので、GDC air-gappedと同じく「司令塔は自律、運営は選択制」の③です。

Azure Local の切断運用も、この③に来る

前編で「境界事例」として触れた Azure Local は、ここでも顔を出します。通常はAzureをコントロールプレーンとする接続型（①）ですが、「Disconnected Operations（切断運用）」モードを使うと、ローカルコントロールプレーンで完全に切断された状態で動きます⁵——つまりこの③になります。

Microsoftの公式ドキュメントによれば、Disconnected OperationsはAzureパブリッククラウドへの接続なしにAzure Localインスタンスをデプロイ・管理でき、ローカルコントロールプレーン上でAzure Arc対応サービスの一部を使ってVMやコンテナアプリを動かせます⁵。ポータルやCLIの操作感はAzureのまま、というのが売りです。

ただし、ローカルコントロールプレーンをホストするぶん、最小ハードウェア要件が接続時より大きくなります⁵。さらにプレビュー段階のリリースノートには、ワークロードクラスタが20を超えるとコントロールプレーンの安定性に影響しうるため20以下に抑えることを推奨、といった具体的な制約も書かれています⁶。同じ製品でも、切断運用を選んだ瞬間に③の世界の"重さ"が乗ってくる——このあたりが、①②との地続きでありながら別世界である所以です。

タイプ④ 自前：OpenShift / Nutanix ── 「自分のオンプレを、クラウドっぽく運用する」ためのツール

③まではクラウドベンダーの「クラウドをオンプレに持ってくる」製品でした。最後のタイプ④は、逆方向のアプローチです。もともと自分で持っているオンプレ環境（自前のサーバやデータセンター）に、クラウドのような運用体験を後付けするプラットフォーム製品群。代表格が Red Hat OpenShift と Nutanix です。

①〜③が「クラウド側から歩み寄る」なら、④は**「オンプレ側から歩み寄る」**。自前の資産や運用主権は完全に握ったまま、その上にマネージドっぽい体験（コンテナ基盤、宣言的な構成管理、ライフサイクル自動化）を乗せます。

• OpenShift：Kubernetesをベースにした、コンテナアプリの実行・運用基盤。素のKubernetesに、運用に必要なもの（レジストリ、CI/CD、監視、オペレータによる自動化）を乗せてくれます。
• Nutanix：HCI（ハイパーコンバージドインフラ）が出発点で、サーバ・ストレージ・仮想化をまとめて、クラウドのように扱えるようにします。LCM（Life Cycle Manager）で更新やファームウェア管理を自動化してくれる。コンテナを載せたいなら NKP（Nutanix Kubernetes Platform）、その上でLLMなど生成AIを動かすなら NAI（Nutanix Enterprise AI） と、Kubernetes・AI基盤まで揃っています。どちらも切断（air-gapped）環境でのデプロイに対応します⁷。

air-gapped対応は「エディション」ではなく「モード」

ここで大事な補足。OpenShiftもNutanixも、切断（air-gapped）環境に対応していますが、それは"別製品・別エディション"ではなく、"切断モードで構築・運用する"という選択です。

• OpenShiftでは、インターネットに接続した構築（connected）と、切断環境向けの構築（disconnected / air-gapped）を選べます。切断構築では、必要なコンテナイメージをいったんミラーレジストリに複製し、そこからインストールする方式をとります⁸。oc-mirror のような、この面倒なミラーリングを楽にするツールも用意されています⁹。
• Nutanixでは、インターネット非接続の環境を 「Dark Site」 と呼び、LCMをdark siteモードに切り替えることで、ローカルのWebサーバー経由で更新を配布できます¹⁰。さらに新しめのバージョン（NCI 7.5）では、切断環境の更新作業を自動化する LCM DUO（Dark Site Upgrade Orchestrator） という機能まで出ています¹¹。

つまり「OpenShift＝air-gapped対応、Nutanix＝非対応」みたいな単純な話ではなく、どちらも"切断モードで組むかどうか"を選べます。そして重要なのは、切断環境の一番のツラさ（オフラインでのイメージ管理・更新配布）を楽にするツールが、ちゃんと用意されているという点。③で「遮断型は運用が重い」と書きますが、その重さを軽くするための道具立てが、このタイプ④の世界には揃っています。だからこそ、自前で握りつつクラウドっぽく回す、という選択が現実的になるわけです。

ちなみに：グラデーションを"跨ぐ"移植性の話

前後編を通して4タイプを見てくると、①〜④が**「クラウド側に預ける」から「手元で握る」へのグラデーション**になっているのが分かります。上（①）ほどクラウドの使い勝手が残り、下（④）ほど自分で握れる。

このグラデーションを跨ぐ移植性には、2つの流儀があります。ベンダー自身がAPI互換の層をパブリックからair-gappedまで揃える方向（Googleは「一度開発すれば、どこにでもデプロイできる」を方針として明言しています¹²）と、ベンダー非依存の基盤層を被せる方向（OpenShiftやNutanixはパブリッククラウド上でも同じスタックを動かせます）。ここは移植性・ロックインという"もう一つの軸"の話になるので、掘るのはまた別の機会に。

遮断型は覚悟が要る。だからこそ、この製品群に価値がある

最後に、この後編で扱った③④（遮断型）について、実務的な一言を。

正直に言うと、完全に切り離して自前で動かすのは、運用の負荷が段違いに高いです。オフラインでのコンテナイメージ管理、インターネット無しでのパッチ適用、厳格な変更管理、ハードウェアのライフサイクルとスペア管理……。air-gappedのチュートリアルでも、接続型やハイブリッドで要件を満たせるならまず遮断型は避けよ、という趣旨のことが書かれているくらいです¹³。「閉域＝安全」というイメージだけで飛び込むと、運用コストが大変です。

でも、だからこそ、この製品群には価値があります。

昔なら「切断して自律運用したい」＝「全部自前で手作りして、その重い運用を丸ごと背負う」しかありませんでした。この製品群は、その覚悟が要る部分に、クラウドのような使い勝手を持ち込んでくれます。Azure Localの切断運用は、ローカルコントロールプレーンでありながらAzureポータルやCLIの操作感をそのまま提供します⁵。GDC air-gappedは、恒久切断の閉域でありながらKubernetesベースのマネージド体験とISVマーケットプレイスまで用意しています¹⁴。

そして、その重さ自体を背負いたくないなら、前編のタイプ②（独立運営型）という逃げ道もあります。「握りたいものは握る、任せたいものは任せる」——どこまで自分で運用を持つかも、選べるということです。

つまりこれらは、「主権のために背負わざるを得ない運用の重さ」を、クラウドの体験でどれだけ軽くできるかという挑戦の産物です。前編の冒頭で書いた「主権は欲しい、でも使い勝手も手放したくない」——あのわがままに、各社がそれぞれのバランスで答えを出しています。

そして製品を選ぶときは、結局この2軸に戻ってきます。製品名ではなく、「切っても自律して動くか？」「誰が運営する？」で位置づける。 新しい名前が出てきても、この2つを聞けば、4タイプのどこかに落ちます。名前の洪水に流されず、構造で捉える。それだけで、この領域はだいぶ見通しが良くなります。

---

参考（一次情報）

1. Google Distributed Cloud air-gapped（Google Cloud/インターネットへの接続なしで恒久的に切断運用できるフルスタックの閉域クラウド）. https://cloud.google.com/distributed-cloud-air-gapped ↩ ↩²

2. Fully disconnected: A beginner's guide to Google Distributed Cloud air-gapped（フルスタックの閉域プライベートクラウド／ローカルコントロールプレーン内包）. https://services.google.com/fh/files/misc/introductory_ebook_v2.pdf ↩

3. About Google Distributed Cloud air-gapped（エアギャップ環境への物理媒体でのバイナリ搬入手順）. https://docs.cloud.google.com/distributed-cloud/hosted/docs/latest/gdcag/overview ↩

4. Google Distributed Cloud air-gapped FAQ（パートナー運営モデル／Proximus）. https://docs.cloud.google.com/distributed-cloud/hosted/docs/latest/gdcag/resources/faq ↩ ↩²

5. Disconnected operations for Azure Local overview — Microsoft Learn（ローカルコントロールプレーンで切断運用、最小HW要件が上がる）. https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-overview ↩ ↩² ↩³ ↩⁴

6. Release Notes for Disconnected Operations for Azure Local — Microsoft Learn（20クラスタ超で安定性に影響しうる制約）. https://learn.microsoft.com/en-us/azure/azure-local/manage/disconnected-operations-known-issues ↩

7. Nutanix Kubernetes Platform (NKP)（air-gappedデプロイ対応。NAIはNKP Catalogに統合され、fully disconnectedインストールに対応）. https://www.nutanix.com/products/kubernetes-management-platform ↩

8. Installing a cluster in a disconnected environment — OpenShift（切断構築ではミラーレジストリにイメージを複製してインストールする）. https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/disconnected_environments/index ↩

9. Simplify OpenShift installation in air-gapped environments | Red Hat Developer（oc-mirror等でair-gapped構築を簡素化）. https://developers.redhat.com/articles/2025/10/14/simplify-openshift-installation-air-gapped-environments ↩

10. Nutanix LCM — Dark Site（LCMをdark siteモードにしローカルWebサーバー経由で更新配布）. https://www.nutanix.dev/2024/09/02/nutanix-lcm-v4-apis-and-ncm-self-service-integration-update/ ↩

11. Simplifying Dark Site Upgrades with Nutanix LCM DUO（NCI 7.5、切断環境の更新を自動化するLCM DUO）. https://www.nutanix.com/blog/simplifying-dark-site-upgrades-with-lcm-duo ↩

12. Delivering a secure, open, and sovereign digital world | Google Cloud Blog（GCDは切断後にキーローテーション、最大12ヶ月運用継続／「一度開発すれば、どこにでもデプロイ」方針）. https://cloud.google.com/blog/products/identity-security/delivering-a-secure-open-sovereign-digital-world ↩

13. Google Distributed Cloud air-gapped tutorial（接続/ハイブリッドで足りるなら遮断型は運用負荷が重い旨）. https://cloud.google.com/distributed-cloud-air-gapped ↩