ラベル Azure の投稿を表示しています。 すべての投稿を表示
ラベル Azure の投稿を表示しています。 すべての投稿を表示

日曜日, 10月 18, 2026

Windows Serverの今後10年：OSは継続するが、運用・課金・延長保守の重心はAzure Arcへ移る

Windows Server は今後どうなるのか。クラウド移行が語られるたびに「そろそろ終わるのでは」という声が出ますが、現時点で公式に確認できるのは、現行の Windows Server 2025 が2034年11月まで延長サポート対象であること、そして次期 LTSC（長期サービスチャネル）の Insider プレビューが続いていることです。2036年に製品系列が残っている可能性は高いと考えますが、これは予測であり、次期版の名称・提供時期・サポート期間は未発表です。

変わりつつあるのは OS そのものより、運用・課金・延長保守の窓口です。Microsoft は、更新管理、従量課金、管理特典、ESU（拡張セキュリティ更新）、非 Azure 環境向けの Hotpatch といった「ハイブリッド環境の運用価値」を Azure Arc に寄せています。ただし Arc は Windows Server を別の OS に変えるものではなく、サーバーに Azure の管理面を追加する仕組みです。この記事では、この違いを意識しながら、現状と今後10年（2026〜2036年）の見通しを整理します。

本記事は2026年10月18日時点の公開情報に基づきます。根拠の強さを3段階で書き分けています。【Microsoft発表】公式文書で確認できる事実、【外部データ】第三者調査や報道に基づく推論、【筆者の仮定】筆者のシナリオ設定です。確率や時期の予想はすべて【筆者の仮定】であり、Microsoft の公式見解ではありません。

1. 現在地：サポート期限と Windows Server 2025

【Microsoft発表】Windows Server 2025 は2024年11月1日に一般提供が始まり、メインストリームサポートは2029年11月13日、延長サポートは2034年11月14日までです（リリース情報の表の日付）。Lifecycle ページは時刻付きで11月14日（メインストリーム）・11月15日（延長サポート）と表示されるため、資料に使う際は出典を併記してください。サードパーティのサイトには「2034年10月」「2035年」といった異なる記載もあるため、日付は Microsoft の公式ページで確認してください。

バージョン メインストリーム終了 延長サポート終了 備考
2016 2022年1月11日 2027年1月12日 ESU は最長3年（2030年まで）。Arc 経由で2026年8月から Azure portal で設定でき、請求開始は2027年1月13日（Microsoft Learn）
2019 2024年1月9日 2029年1月9日 ESU は未発表
2022 2026年10月13日（終了済み） 2031年10月14日 メインストリーム終了後も、延長サポート期間中はセキュリティ更新が続く。「メインストリーム終了」と「サポート終了」は別物
2025 2029年11月13日 2034年11月14日 現行の LTSC。2024年11月1日に一般提供開始

出典：Microsoft Learn「Windows Server release information」、Microsoft Lifecycle ページ、Microsoft Learn「Arc 対応 ESU の準備」

【Microsoft発表】Windows Server 2025 の主な機能強化は次のとおりです。Hyper-V の Gen2 VM は最大メモリ240TB、仮想プロセッサ2,048に拡張されました（2,048 は PowerShell のみでの構成で、ゲスト OS 側の上限は別です）。ネイティブ NVMe スタックは2025年10月以降の累積更新でオプトイン機能として利用可能になりました。Microsoft の測定（Intel 2ソケット機、NVMe SSD、DiskSpd の 4K ランダムリード、NTFS）では、WS2022 比で IOPS が最大約80%向上し、I/O あたりの CPU サイクルが約45%減っています。結果は構成によって変わると注記されており、機能は既定で無効です。実ワークロードでの検証が前提になります。

2. Azure Arc は何で、何ではないか

Azure Arc は、オンプレミスや他社クラウド上のサーバーに、Azure の管理・ガバナンスの面を追加する管理プレーンです。Windows Server を別の OS に変換するものではありません。一方、Azure Local（旧 Azure Stack HCI）は仮想化・HCI を含む別のインフラ製品で、Arc とは位置づけが異なります。「Windows Server が Arc や Azure Local という OS になる」という読み方は技術的に不正確です。

また、「価値がすべて Arc 前提になる」とも言えません。Arc が前提になるのは運用・商用面の機能で、OS 本体の機能は Arc なしでも使えます。

機能 Arc 接続 条件・補足
Hotpatch（オンプレ・他社クラウド） 必要 WS2025 Standard／Datacenter が対象で、VBS の有効化と Arc 接続が前提（その他の対応プラットフォーム要件は Microsoft の Hotpatch 文書で確認）。2026年5月19日以降は追加料金なし（それ以前は月額課金）。四半期のベースライン月は再起動が必要
Hotpatch（Datacenter: Azure Edition） 不要 Azure 上で既定で有効
Windows Server Management enabled by Azure Arc（Update Manager など） 必要 SA 付きライセンスまたはサブスクリプションの顧客は追加費用なし（ネットワーク・ストレージ・ログ取り込みは別途）。権利の申告が必要（Windows Server の従量課金に登録していれば自動で付与）。Hotpatch は別枠で、この権利の対象外
ESU（2016） 主要経路が Arc Arc 以外の経路もあるため「Arc のみ」とは言えない。詳細は4章
Hyper-V、AD、AD CS、PQC の API、ネイティブ NVMe 不要 OS 本体の機能。NVMe は既定無効のオプトイン

出典：Microsoft Azure Arc ブログ、Azure Update Manager ドキュメント、Windows Server ブログ

3. リリースモデルと次期バージョン

3-1. LTSC は10年サポートを維持している

【Microsoft発表】Microsoft Learn は、LTSC の新しいメジャーバージョンを「通常2〜3年ごと」に出し、メインストリーム5年＋延長5年のサポートを提供すると説明しています。実績は2016、2019（2018年11月）、2022（2021年8月）、2025（2024年11月）で、およそ3年周期です。これは現行制度の説明であり、2036年まで制度が変わらない保証ではありません。

3-2. Annual Channel は縮小しているように見える

【Microsoft発表】Annual Channel（コンテナホスト向け）のリリースは2023年10月の23H2が最後で、後継は出ていません。Microsoft Learn は Annual Channel を通常12か月ごとにリリースすると説明していますが、23H2 の後継は確認できませんでした。AKS では Annual Channel のノードイメージはプレビュー扱いで、2026年5月15日に新規作成と更新が終了し、既存イメージは2027年5月15日に削除されます。ライフサイクルページ上は Annual Channel 自体がまだ「サポート中」と表示されており、Microsoft が全体の終了を宣言したわけではありません。【筆者の仮定】コンテナ用途は LTSC と Kubernetes 側に吸収され、Annual Channel は実質的に縮小すると見ています。「AKS 自体のサポート終了」ではない点にご注意ください。

3-3. 次期 LTSC：公式に言えること、言えないこと

【Microsoft発表】Windows Server Insider の告知では、次期版のプレビュー（Build 29641、2026年8月）の有効期限が2027年10月15日に延長されました。プレビュー中の機能としては、VM の Trusted Launch、Quick Machine Recovery、NVMe-oF イニシエーター、ReFS ブートなどが告知されています。製品名、一般提供日、サポート期間はいずれも未発表です。コードネームや「Windows Server 2028」といった名称を載せたファンサイトの情報は、Microsoft が確認していないため、ここでは採用しません。

【Microsoft発表】2026年9月21日公開の KB5129631 では、Windows Deployment Services（WDS）サーバーロールを「次の Windows Server リリースから非推奨にする計画」と案内しています。非推奨は削除とは別で、WDS は Windows Server 2025 以前の現行サポート版では引き続き使えます。Microsoft Configuration Manager の OS 展開は影響を受けないと説明されています。

4. ESU と課金モデル

【Microsoft発表】Microsoft は2026年2月25日に Windows Server 2016 の ESU を発表し、Azure Arc 経由で提供すると案内しました。Microsoft Learn によると、対象は Standard／Datacenter で、Arc 経由で購入するにはボリュームライセンス経由の Software Assurance（SA）が必要です。SPLA やサーバーサブスクリプションのライセンスなら SA は不要とされています。提供されるのはクリティカルと重要のセキュリティ更新で、最長3年（2030年まで）です。Azure portal では2026年8月から設定でき、請求は2027年1月13日に始まるとされています。VDI のマシンは Arc ではなく MAK で提供するなど、Arc だけが唯一の経路という整理にはなりません。Windows Server 2016 の ESU 価格は、今回確認した Microsoft の公開ページには掲載されていません。

価格の扱いには注意が必要です。Microsoft は2026年3月27日の Microsoft Licensing の告知で、2026年4月1日以降に提供する新規の ESU について、Azure・オンプレミス・他社クラウドのどこで買っても、また購入チャネルによらず同じ list price にする「標準化」を案内しています（Windows Server 2012 など既存の ESU には適用されません）。そのため、Windows Server 2012 のときのように「Azure に移せば ESU は無償」という前提は、2016 ではそのまま置けないと考えられます。一方で Microsoft Learn は、Azure VMware Solution と Azure Local 上の VM は無償の ESU の対象で、Arc では登録しないと説明しています。Azure 上の通常の VM の扱いは今回確認できておらず、適用条件は Windows Server 2016 向けの公式 FAQ と Product Terms で個別に確認してください。

【外部データ】CSP 経由の購入では、2026年10月1日から、年間契約を月払いにしているソフトウェアサブスクリプション（Windows Server、SQL Server、CAL、System Center など）に5%の上乗せが適用されると、Microsoft の2026年8月の Partner Center 告知を紹介する解説記事が伝えています（既存契約は2026年10月1日以降の更新時から。年払いと月単位の契約は対象外とされています）。Microsoft の価格設計は、Arc に接続して SA 特典や従量課金を使う方が有利に見えるよう組まれていますが、これは外部から見た傾向であり、Microsoft がそう明言しているわけではありません。

5. セキュリティ：NTLM 縮退と PQC

5-1. NTLM

【Microsoft発表】NTLMv1 は Windows Server 2025 で削除されました。Microsoft は2026年10月の更新で、Credential Guard が無効で BlockNtlmv1SSO が未設定のデバイスについて、NTLMv1 由来の SSO 資格情報の既定動作を Audit から Enforce に切り替える計画を示しています（日程は暫定で、変更の可能性があるとされています。実際の適用は KB で確認してください）。さらに Microsoft は段階計画として、次期メジャーリリースで NTLM を既定で無効にする方針を示しています。完全削除ではなく、ポリシーで再有効化できる前提で、変更の可能性があると断られています。古い複合機、NAS、業務パッケージなど NTLM に依存する資産の棚卸しは、次期 LTSC を待たずに始められる作業です。

5-2. PQC（耐量子暗号）：段階的に対応が進んでいる

【Microsoft発表】2025年11月の更新で、ML-KEM と ML-DSA が CNG の API として一般提供されました。2026年5月の更新（KB5087539）では、WS2025 の AD CS が ML-DSA 証明書の発行に対応しています。ただし既存の CA をその場で ML-DSA に移行することはできず、新規の ML-DSA CA を構築する必要があります。CA 階層、証明書テンプレート、クライアント互換性を含めた PKI の再設計が前提になります。

TLS のハイブリッド鍵交換については、Microsoft の Tech Community の FAQ が、Windows Server 2025 では2026年7月14日の更新（KB5099536）を使うよう案内しています。一方で Microsoft Learn の文書では、ML-KEM 系のグループは Schannel がサポートするものの既定では有効でない扱いとされています。有効化の状態は環境や構成に依存するため、導入時は FAQ と Learn の最新版で確認してください。

6. 主要機能の行方：Active Directory、WSUS、IIS、コンテナ

OS 全体の見通しに加えて、利用者の多い4つの機能が今後どうなるかを整理します。次期版の Insider ビルド 29641 の告知には、AD・IIS・コンテナ・WSUS に関する変更も、非推奨項目の記載も含まれていません（NTLM の既定無効化と WDS の非推奨は、別の告知によるものです）。そのため、次期 LTSC での扱いは現時点では読み取れず、以下は現行版までの公式情報と筆者の仮定を分けて書いています。

機能 公式に確認できる現状 特に注意する点 筆者の見立て（仮定）
Active Directory WS2025 で機能レベル10、32k ページ（任意）、LDAP の署名・暗号化の既定必須化（新規展開）、dMSA を追加。廃止の発表は確認できず NTLM は次期メジャーで既定無効の方針。Kerberos の RC4 縮退は進行中（外部解説）。機能レベル10は WS2019／2022 に後付けされない 2036年も多くの組織で残る可能性が高い。変わるのは「古い互換性」の切り落とし
WSUS 2024年9月に非推奨化を発表。新機能の開発は止まるが、現行機能と更新の配信は継続。WS2025 にも含まれる 削除日は未公表。代替は Intune、Azure Update Manager、Windows Autopatch。Configuration Manager には影響しない 次期 LTSC にも残るが、機能は凍結される可能性（確度は低め）
IIS IIS 自体の廃止の発表は確認できず。WS2025 で IIS 6 管理コンソールと SMTP サーバーを削除。TLS 1.0／1.1 は既定無効 VBScript は将来オンデマンド機能になった後に削除予定。クラシック ASP への影響は公式回答なし ロールとして継続しつつ、レガシー部分が切り落とされる。新規の Web は IIS 以外へ
コンテナ AKS の Windows ノードは LTSC の WS2025／2022 のみ（プロセス分離）。Annual Channel の AKS サポートは2026年5月に終了 AKS 上の WS2022 は2028年6月30日で終了。OS の延長サポート（2031年10月）より先に期限が来る 既存の .NET Framework 系アプリの延命用途が中心。新規は Linux コンテナが主流

出典：Microsoft Learn（Windows Server 2025 の新機能、削除・開発終了の機能、AKS の Windows ベストプラクティス）、Windows IT Pro Blog（WSUS 非推奨）、Insider ビルド 29641 の告知。見立ての列は筆者の仮定

6-1. Active Directory：残るが、古い互換性は切り落とされる

【Microsoft発表】Windows Server 2025 の AD DS には、新しい機能レベル（DomainLevel／ForestLevel 10）と、任意機能の 32k データベースページサイズが入りました。32k ページは Windows 2000 以来の 8k に代わるもので、複数値属性が持てる値の数が約1,200から約3,200に増えます。新規に構築する DC は 32k ページで導入できますが、アップグレードした DC は従来の形式（8k）のままです。32k への移行はフォレスト全体で行う必要があり、すべての DC が対応していなければなりません。Microsoft は、この機能レベルを Windows Server 2019／2022 に後付けする予定はないと明記しています。AD の新機能の一部は、WS2025 以降の DC を揃えないと使えないということです。AD DS は64を超えるコアにもスケールできるようになりました（NUMA 対応）。

【Microsoft発表】セキュリティ面では、新規 AD 展開で LDAP の署名と暗号化（sealing）が SASL bind 後に既定で必須になり、機密属性の操作は暗号化された接続でのみ許可されます。LDAP over TLS 1.3 にも対応しました。コンピューターアカウントの既定パスワードの設定は DC が拒否し、旧来の SAM RPC パスワード変更メソッドはリモートから既定でブロックされます。Kerberos では KDC が RC4 の TGT を発行しなくなり、PKINIT は暗号アルゴリズムを固定しない構成になりました。サービスアカウントについては、既存アカウントから移行しやすい委任管理サービスアカウント（dMSA）が追加されています。

【外部データ】Kerberos の RC4 は、CVE-2026-20833 に関連して段階的に縮退していると解説されています。専門ベンダーの解説では、2026年1月13日の更新で監査（KDCSVC イベント 201〜209）を始め、4月に既定を AES のみ（DefaultDomainSupportedEncTypes が 0x18 相当）に切り替え、7月に監査モードを廃止して強制する、という3段階です。この解説は影響を受ける Windows Server のバージョンを示していないため、対象と日程は Microsoft の KB と CVE の公式情報で確認してください。解説どおりなら7月の強制段階はすでに過ぎており、RC4 に依存したサービスアカウントや古い機器は、障害の形で表面化しうる時期に入っています。

【Microsoft発表】次期版の Insider ビルド 29641 の告知は、既知の問題として、TLS のハイブリッド鍵交換の競合状態により LSASS がクラッシュしうること、回避策としてハイブリッドグループを無効にする方法を挙げています。プレビュー版の話ですが、DC を含む認証基盤で PQC 関連の機能を有効にする際は、段階的な検証が必要という示唆になります。

【筆者の仮定】Microsoft が AD DS の廃止を発表したことは、今回の調査では確認できていません。AD DS は WS2025 の延長サポート（2034年11月）までロールとして提供され、DC の世代交代は WS2019（2029年1月）、WS2022（2031年10月）の終了日に沿って進むと考えます。Entra ID と組み合わせたハイブリッド ID が標準になる一方、Kerberos、GPO、LDAP に依存する業務アプリ、ファイルサーバー、機器が残る限り、オンプレの AD は2036年にも多くの組織で残る可能性が高いと見ています。変わるのは AD の存在そのものではなく、NTLM、RC4、弱い LDAP 設定といった古い互換性が、NTLM の既定無効化（5章）のような形で順に切り落とされていく点です。

6-2. WSUS：非推奨だが、すぐには消えない

【Microsoft発表】Microsoft は2024年9月に WSUS の非推奨化を発表しました。新機能への投資と新規の機能要望の受付は止めるが、現行機能は維持し、WSUS チャネル経由の更新の公開と、すでにそのチャネルで公開されたコンテンツのサポートは続ける、という内容です。WSUS ロールは Windows Server 2025 にも含まれ、Microsoft Configuration Manager のサポートには影響しないと説明されています。代替として、Intune、サーバー向けの Azure Update Manager、クライアント向けの Windows Autopatch が案内されています。

非推奨は削除ではありません。削除日は公表されておらず、Microsoft Learn の Q&A では回答者（MVP）が、WS2025 のライフサイクルから少なくとも2034年までは使えるはずだと推論していますが、これは Microsoft の約束ではなく【外部データ】の推論です。同じ構図は、2026年9月に告知された WDS の非推奨（3章）とも共通します。

【筆者の仮定】次期 LTSC にも WSUS ロールは残る可能性が高い一方、機能追加は期待できず、削除は次の次以降の LTSC で告知される可能性があります（確度は低めです）。実務では、オンプレの更新配布は、Azure Update Manager（非 Azure のサーバーでは Arc 接続が前提）への移行、Configuration Manager の継続、WSUS の現状維持のいずれかになります。閉域環境やソブリン要件の強い環境で Azure Update Manager が使えるかは、構成ごとに公式文書で確認が必要です。

6-3. IIS：ロールは続くが、周辺のレガシーが整理される

【Microsoft発表】IIS 自体の廃止や非推奨を示す公式発表は、今回の調査では確認できませんでした。一方、Windows Server 2025 向けの「削除・開発終了の機能」の一覧（プレビュー期の版）には、IIS 周辺の整理が並んでいます。IIS 6 管理コンソールは削除され、SMTP サーバーも削除されて OS 内に代替はありません。TLS 1.0／1.1 は既定で無効、WMIC は新規インストールで既定無効、VBScript は将来のリリースでオンデマンド機能（FOD）になった後に OS から削除される予定とされています。

クラシック ASP には注意が必要です。VBScript の削除計画が IIS の ASP に及ぶかどうかは、Microsoft Learn の Q&A スレッドで回答者の見解が割れており、Microsoft からの公式な回答は出ていません。WS2025 のプレビューで ASP が動作したという報告と、VBScript の FOD を無効にした環境で動作しなかったという報告が併存しています。【外部データ】これはコミュニティの情報で、Microsoft の公式見解ではありません。クラシック ASP を使う資産では、VBScript の FOD の有無をテスト項目に入れ、移行計画を持っておく方が安全です。SMTP サーバー機能に依存するアプリも、WS2025 では代替の確保が必要です。

【筆者の仮定】IIS は OS のロールとして各バージョンのサポート期間に沿って提供され続け、.NET Framework 系の既存アプリのホストとして残ると考えます。新規の Web アプリは ASP.NET Core や Linux コンテナに流れていくでしょう。IIS 周りで確実に進むのは、プロトコルと暗号の既定値の厳格化と、古い互換コンポーネントの切り落としです。

6-4. コンテナ：LTSC に一本化され、AKS の期限が先に来る

【Microsoft発表】AKS は Windows ノードのホスト OS として、LTSC の Windows Server 2025 と 2022 をサポートし、分離はプロセス分離のみです。Windows Server 2025 が既定になるのは Kubernetes 1.36 以降で、それ以前は 2022 が既定です。Windows ノードプールには制約もあり、最初のシステムノードプールは Linux である必要があること、特権コンテナーは使えず HostProcess コンテナーで代替すること、Windows の自動更新はなくノードイメージのアップグレードで対応することなどが挙げられています。

AKS の Windows ノード 期限・状況 備考
Windows Server 2025（LTSC） サポート中。Kubernetes 1.36 以降で既定 Microsoft は Windows ノードプールに WS2025 を推奨
Windows Server 2022（LTSC） 2028年6月30日にノードプールのサポート終了（Kubernetes 1.37 以降は非対応）。ノードイメージは2029年6月30日に削除 OS の延長サポートは2031年10月14日まで。AKS 上の期限の方が先に来る
Windows Server 2019 Kubernetes 1.33 以降ではノードプールを作れない。ノードイメージは2027年4月1日に削除 削除後はスケール操作が失敗する
Annual Channel（プレビュー） 2026年5月15日に新規ノードプールと更新を終了。イメージは2027年5月15日に削除 LTSC への移行を推奨。HostProcess などの特権系コンテナーは追加テストが必要

出典：Microsoft Learn「Windows containers on AKS のベストプラクティス」「Windows と Linux のコンテナー」。AKS 以外（Azure Local など）の期限は別途確認が必要

【Microsoft発表】Windows Server 2025 の機能としては、コンテナーイメージとそのデータを、変更なしでホスト間や環境間で移せる「コンテナーのポータビリティ」が挙げられています。表のとおり、AKS は LTSC に一本化し、古いバージョンと Annual Channel を整理する方向です。AKS 上の期限が OS の延長サポートより早い点は、Windows コンテナーの更新計画で見落としやすいところです。

【筆者の仮定】Windows コンテナーは、.NET Framework 系の既存アプリを OS から切り離して延命する用途が中心になり、新規開発の主流は Linux コンテナーだと考えます。AKS で Windows Server 2025 が既定になる時期が Kubernetes のバージョンに連動していることから、次期 LTSC が出た後も、AKS で段階的に新しい LTSC が既定になるパターンが続くと見ています（時期は未定です）。

7. 市場環境：Microsoft の収益構造と VMware 移行

【Microsoft発表】FY26 の決算説明で、Satya Nadella CEO は Azure の年間売上が1,000億ドルを超え、前年比41%増だと述べました（41%が報告ベースか為替一定ベースかは、確認した範囲では明示されていません）。Q4 単独では、Azure and other cloud services の売上が43%増でした。一方、オンプレミスのサーバー事業について Amy Hood CFO は、Q4 の売上は前年並みで、為替一定ベースでは1%減と説明しています。通期のオンプレ向け数値は今回確認できていないため記載しません。なお財務諸表上は、Azure 単独の売上明細ではなく「Server products and cloud services」などの区分で開示されます。経営陣が補足する Azure の売上・成長率と、報告セグメントの数字は基準が違うため、混ぜて読まないでください。【筆者の仮定】このため、Microsoft はオンプレ OS の売上そのものより、Arc や Azure の利用につながる機能と価格の設計を優先しやすいと考えます。

【外部データ】VMware（Broadcom 買収後）からの移行は、Windows Server にとって追い風になりうる材料です。Nutanix の CEO は2026年8月の FY26 決算説明の質疑で、顧客数を約3万1,000〜3万2,000社と述べ、FY26 の新規顧客は約3,000社（3年連続の水準）と報じられています。VMware からの移行は今後5年も続くとの見方も示されました（SDxCentral）。ただし調査の読み方には注意が必要です。CloudBolt の調査（2026年1月実施、北米の従業員1,000人以上の企業で VMware 関連の意思決定権を持つ幹部302人）では、86%が VMware の利用を積極的に縮小中で、54%は VMware を維持しつつ依存を減らす段階的な移行でした。移行先の上位は、パブリッククラウド IaaS（72%）、Hyper-V／Azure Stack（38%）、SaaS（34%）と紹介されています（分母の定義は原典で確認が必要です）。いずれもベンダー実施の調査や報道で、母数も限られます。全面移行より部分移行が主流という見方が妥当で、Windows 中心の環境では Datacenter エディションの仮想化権利を使った Hyper-V が受け皿になりやすい、というのが筆者の推論です。

サーバー OS 全体の市場シェアについては、IDC や Gartner の最新の一次データを今回確認できていないため、数値は掲載しません。

8. 日本市場とソブリン要件

【外部データ】MM総研は2025年10〜12月に、国内企業の情報システム部門の担当者を対象に Web アンケートを実施しています（スクリーニング調査の有効回答は45,172件、本調査は Windows Server 2016 や仮想化環境の利用者を対象とした967件）。協賛記事の見出しではこの調査を引用して「約25万台が稼働」と紹介されていますが、台数の推計方法は原典で確認できていません。移行に動けない理由の最多は「社内の人材不足」（約45%）、次いで「予算の確保、経営層への上申理由、理解」（32.2%）と紹介されています。また、クラウドへの移行を選ぶ回答は約5%で、Windows Server 2012 の調査時より低いとされています（分母の定義は原典で確認が必要です）。これらはいずれもベンダー協賛の解説記事経由の数字です。解説では、既存のオンプレミス環境を前提に、OS と仮想化基盤の見直しを優先する企業が多いという分析も紹介されています（ベンダー側の解釈です）。

【Microsoft発表】ソブリン要件への対応では、Azure Local の存在感が増しています。2026年2月には切断運用（disconnected operations）を一般提供し、2026年4月27日には、Azure Local が単一のソブリン環境で「数百から数千台」のサーバー規模まで拡張できると発表しました。DCD の報道では、2025年11月の拡張以前は最大16台とされていたとのことで、規模は大きく変わっています。ただし数千台という上限の具体的な構成は公式ブログからは読み取れず、実際の設計では構成上限や検証済み構成の公式文書で確認が必要です。Microsoft は検証済みのパートナーとして、DataON、Dell Technologies、Everpure、Hitachi Vantara、HPE、Lenovo、NetApp などを挙げていると報じられています。【筆者の仮定】ライセンスの再販や OS の導入作業より、運用設計や移行支援に SIer の付加価値が移っていくと考えます。

9. 今後10年（2026〜2036年）の見通し

ここからは、公式発表と筆者の仮定を分けて整理します。出発点になる事実は3つです。Windows Server 2025 は2034年11月までサポートされること、次期 LTSC のプレビューが続いていること、そして運用・課金の窓口が Arc に寄っていることです。

時期 予想される出来事 根拠の強さ
〜2028年 2016 の延長サポート終了（2027年1月）と ESU。次期 LTSC の一般提供（2027年後半〜2028年前半が有力）。NTLM が次期版で既定無効に 2016 の日程と NTLM 方針は【Microsoft発表】。次期版の時期はプレビュー期限と3年周期からの推論【筆者の仮定】
〜2031年 2019（2029年1月）・2022（2031年10月）の延長サポート終了。両者に ESU が提供される可能性。次の LTSC（2030年前後）。新規基盤では Arc 接続が標準的な選択肢に 終了日は【Microsoft発表】。ESU の提供、LTSC の時期、Arc の普及度は【筆者の仮定】
〜2036年 WS2025 の延長サポート終了（2034年11月）。LTSC はさらに1世代（2033年前後）。Windows Server は主に既存資産（AD、ファイル、VDI、.NET Framework 系業務アプリ）の基盤として残る。運用の自動化が進む 2034年11月は【Microsoft発表】。それ以外は【筆者の仮定】で確度は低め

以下は【筆者の仮定】によるシナリオと確率です。独立した根拠のある数字ではなく、現時点の判断を可視化するためのものとして読んでください。

シナリオ 確率（仮定） 概要 見分ける兆候
基本：ハイブリッド管理への漸進的な移行 60% LTSC は続き、運用価値の重心が Arc 側へ。新規ワークロードは Linux や PaaS が中心になり、Windows Server は既存資産の更新需要で安定 次期 LTSC が予定どおり出る。ESU の購入経路が Arc 中心に収れんする
楽観：再評価 20% VMware からの移行、ソブリン需要、Hotpatch の無償化で、Hyper-V／Azure Local と Datacenter の需要が伸びる Azure Local の国内事例の増加。VMware 乗り換えの事例で Hyper-V が目立つ
悲観：縮退とロックインの強化 20% SA 必須化や値上げ、主要機能の Arc／Azure 限定化が進み、顧客が Linux や他の基盤、SaaS へ流れる。または規制によりクラウド接続前提の機能が使えない Arc 未接続ではセキュリティ機能が使えなくなる。LTSC の周期が延びる。日欧でクラウド依存への規制が強まる

今後の追跡に向く指標は、次期 LTSC の公式発表（Ignite などの場）、Insider プレビュー期限の更新、2019／2022 の ESU の発表時期と提供経路、NTLM 既定無効化のスケジュール、Azure Local の構成上限の更新、Microsoft の四半期決算でのコメントです。機能面では、WSUS・WDS といった非推奨ロールの削除告知、AD の機能レベルや認証まわりの既定値の変更、AKS の Windows ノードの期限更新も、見通しを修正する材料になります。

10. 実務への示唆

  • 2016 の扱いを早めに決める。ESU で時間を稼ぐか、WS2025 などへ移すか。ESU は価格が未公表で、適用条件も経路ごとに異なるため、見積もりの前提を公式 FAQ で固めてください。
  • Arc 接続の方針を先に決める。Hotpatch、管理特典、ESU の窓口が Arc に寄っているため、ネットワーク要件とソブリン要件の折り合いをアーキテクチャ段階で整理します。
  • 新規構築は、原則 WS2025 を第一候補にする。ただし ISV の認証、ハードウェア互換性、バックアップ・監視製品、アプリのサポート条件によっては、延長サポート期間中の WS2022 も選択肢になります。
  • NTLM 依存の棚卸しを始める。監査機能で利用状況を把握し、Kerberos への移行を計画します。
  • PKI は新規設計として扱う。ML-DSA CA は既存 CA からのインプレース移行ができないため、アルゴリズム移行、CA 階層、テンプレート、クライアント互換性を含めて設計します。
  • AD は DC の世代と古い互換性を洗い出す。機能レベル10や 32k ページを使うかを判断し、LDAP の署名設定、RC4 に依存するサービスアカウント、NTLM 依存の機器を棚卸しします。
  • 更新配布の将来像を決める。WSUS を現状維持するか、Configuration Manager を使い続けるか、Azure Update Manager（Arc 接続）へ移すか。閉域環境での可否は公式文書で確認します。
  • IIS 上の資産は、ASP・VBScript・SMTP への依存を確認する。クラシック ASP は VBScript の FOD を無効にした状態でのテストを計画に入れます。
  • Windows コンテナーは、AKS の期限から逆算する。WS2022 ノードは2028年6月30日で終了するため、OS の延長サポートではなく AKS 側の期限を基準に更新計画を立てます。

11. まとめ

Windows Server は少なくとも2034年11月までは現行製品としてサポートされ、次期 LTSC の開発も続いています。2036年にも製品系列が残る可能性は高いと見ていますが、将来版の名称、提供時期、ライフサイクルは未発表です。Microsoft が Windows Server そのものを Azure Arc に置き換えるのではなく、非 Azure 環境向けの Hotpatch、更新管理、従量課金、管理特典、ESU といった運用・商用面の価値を Arc 中心に移している、というのが現時点の実像です。

主要機能については、AD は NTLM や RC4 といった古い互換性を切り落としながら残り、WSUS は非推奨でも当面は動き続け、IIS はロールとして続きつつ周辺のレガシーが整理され、Windows コンテナーは LTSC に一本化されて AKS の期限が OS より先に来る、というのが現時点で確認できる姿です。次期版でのこれらの扱いは未発表です。

導入や更改に関わる立場では、OS の更新という単位ではなく、Arc の接続方針、Hyper-V／Azure Local の選択、VMware からの移行、NTLM 依存の解消、PKI と PQC、ソブリン要件までを含めた基盤の再設計として検討する方が、10年のスパンでは筋が通ります。

主な参考資料

時刻: 0 件のコメント:
ラベル: ,

月曜日, 8月 17, 2026

データの置き場所より、事業者の管轄——米中クラウドの外国法リスクを数字で見る

「データを国内リージョンに置いているから安心」——クラウド調達の議論でいまだによく聞くフレーズです。しかし米国のCLOUD Actが問題にしているのはデータの所在地ではなく、事業者がどの国の管轄に服しているかです。日本のデータセンターに保管されていても、事業者が米国の管轄下にある限り、米国の令状は及びます。同じ問いは中国資本のクラウドにも向けられます。日本国内にリージョンを持つ中国系事業者に対して、中国の国家情報法はどこまで及ぶのか。

この二つは「外国政府がデータを見にくるリスク」として同じ棚に並べられがちですが、リスクの構造はかなり違います。米国側は司法審査があり、件数が公表され、事業者が争う制度上の手段がある。中国側はそのいずれも公開情報からは確認できない。一方で発動の蓋然性という点では、米国のエンタープライズデータ開示は統計的に見て極めて少ない。構造と蓋然性を混ぜて議論すると、判断を誤ります。

結論を先に書きます。データ所在地（residency）ではなく管轄（jurisdiction）を基準に分類すること、機微度の高いデータには暗号鍵の自己管理を必須にすること、そして米中いずれの外国資本クラウドについても「完全に排除できる」という前提を置かないこと。これがデジタル庁のガイドラインの記述とも整合する、現時点で取りうる最も現実的な線です。以下、法の条文、透明性レポートの実数、日本政府の制度対応の順に根拠を示していきます。

本記事は2026年8月時点の公開情報に基づいています。FISA第702条の失効をはじめ、状況が流動的な論点を含みます。また記事後半には今後の見通しに関する記述がありますが、これは筆者の推定であり、精密な予測ではありません。法的評価が分かれている論点については、両論を併記しています。

1. CLOUD Actが可能にしていること

CLOUD Act（Clarifying Lawful Overseas Use of Data Act）は2018年3月23日、統合歳出法（Pub. L. 115-141）のDivision Vとして成立しました。1986年の通信記録保存法（Stored Communications Act, 18 U.S.C. §§2701-2712）を改正するもので、中核は新設された18 U.S.C. §2713です。

電子通信サービスまたはリモートコンピューティングサービスの提供者は、通信・記録その他の情報が米国内外いずれに所在するかにかかわらず、自己の占有・保管・支配（possession, custody, or control）の下にある顧客・加入者に関する通信内容および記録を保全・バックアップ・開示する義務を遵守しなければならない。（18 U.S.C. §2713、筆者訳）

ここに「データセンターの所在地」という概念は出てきません。米国と十分な接点を持つ事業者が支配下に置いているデータであれば、それが東京にあってもロンドンにあっても、米国の令状・召喚状の対象になります。この構造こそがリスクの本体であり、リージョン選択では動かせない部分です。

もっとも、事業者側に対抗手段がないわけではありません。18 U.S.C. §2703(h)は「国際礼譲（comity）」の分析を規定しており、対象顧客が米国人でなく、開示が米国と行政協定を締結した外国政府の法に抵触する場合、事業者は令状の取消を申し立てることができ、裁判所は米国と外国の利益を衡量します。ただし後述するとおり、この条項が実効的に働く前提には「行政協定を締結した外国」という限定がかかっています。

この立法の直接の引き金は、いわゆるMicrosoftアイルランド事件です。2013年12月、ニューヨーク南部地区の治安判事が麻薬取引捜査でSCAに基づく令状を発付し、Microsoftにダブリンのサーバーに保管された電子メールの開示を命じました。Microsoftは「米国の令状は国境を越えない、刑事共助条約（MLAT）を使うべきだ」として拒否し、第2巡回区控訴裁判所で勝訴。政府が上告し2018年2月27日に連邦最高裁で口頭弁論が行われましたが、その約1か月後にCLOUD Actが成立して争点が立法的に解決されたため、最高裁は2018年4月17日に本件を訴えの利益なし（moot）として下級審判決を破棄・差戻しました。つまりCLOUD Actは、政府が同事件で主張していた立場を議会が追認した立法です。

2. どれだけ発動されているのか——透明性レポートの実数

構造上のリスクと、実際の発動頻度は別の話です。Microsoftは半期ごとに法執行機関からの要求件数を公表しており、これが数少ない定量データになります。最新の2025年下半期（7〜12月）の数字を見てみます。

同期間、Microsoftが世界中の法執行機関から受け取った消費者向けサービスに関する要求は27,412件。これに対してエンタープライズ顧客（商用クラウドを50シート超購入している組織、またはAzureサブスクリプション契約者）に関する要求は190件にとどまります。同社は「年間数万件の法的要求のうち、エンタープライズ顧客データを求めるものは1%を大きく下回る」と説明しています。

項目（エンタープライズ顧客関連） 2024年下半期 2025年下半期（最新）
法執行要求の総数 173件 190件
却下・撤回・データ不存在・顧客への誘導 107件（62%） 96件（51%）
開示を強制されたもの 66件（38%） 94件（49%）
うちコンテンツデータの開示 26件（うち20件が米国法執行関連） 45件（うち31件が米国法執行関連）
うち非コンテンツデータの開示 40件 49件
越境開示（米国外保管の非米国エンタープライズ顧客のコンテンツを米国法執行機関へ） 5社分（いずれもEU/EFTA域外の顧客） 3社分（うち1社はEU/EFTA域内）
Azureのコンテンツデータ開示 なし なし（商用・公共・教育のいずれも）

越境開示が半期あたり数社分という水準は、率直に言って少ない。ただしこれをもって「リスクは無視できる」と結論づけるのは早計です。三つ留保があります。

  • 件数は事業者の自己申告である。独立した検証手段はありません。
  • 秘匿命令の存在。Microsoftは2025年下半期、米国の法的要求の32%（1,823件、うち1,473件は連邦当局発）に顧客への通知を禁じる秘匿命令が付されていたと公表しています。件数は事後に集計されますが、当該顧客がその時点で知ることはできません。
  • 消費者向けサービスでは桁が違う。同期間、米国法執行機関からの消費者データ要求は5,587件あり、そのうち115件は米国外に保管されたコンテンツを求める令状でした。CLOUD Actが日常的に使われていることは、この数字からわかります。

3. FISA第702条という別の経路

CLOUD Actの議論でしばしば混同されるのが、外国情報監視法（FISA）第702条です。両者は別制度で、リスクの性質も異なります。CLOUD Actは刑事捜査における令状・召喚状であり、裁判官による相当理由の審査を伴います。第702条は米国外にいる非米国人を対象とした外国情報の収集であり、個別の令状を要しません。日本の企業や個人にとって直接関係が深いのは、むしろ後者です。

この第702条は、2024年のRISAA（Reforming Intelligence and Securing America Act）で2年間再授権され、2026年4月20日が失効期限とされていました。以後、10日間・45日間といった短期延長が繰り返されましたが、下院が2026年6月11日に短期延長案を198対218で否決し、第702条は2026年6月12日深夜に失効しました。2008年の制定以来初めてのことです。

ただし失効＝収集停止ではありません。第702条の運用は外国情報監視裁判所（FISC）が承認する年次認証に基づいており、この認証は法律が失効しても有効期限まで存続します。FISCは2026年3月17日に認証を出しており、これにより収集は2027年3月頃まで法的に継続可能とされています。とはいえ、根拠法が失効した状態で事業者がどこまで応じるかについては法的な不確実性が指摘されており、本記事執筆時点で再授権は成立していません。

日本企業にとっての含意は単純です。米国資本クラウドの外国法リスクを評価するなら、CLOUD Actだけを見ていては不十分で、第702条の帰趨も監視対象に入れる必要がある、ということです。

4. 「ソブリンクラウド」は管轄を切り離せるか

欧州の主権要求に応えるかたちで、各メガクラウドはソブリン提供を打ち出しています。最も踏み込んだのがAWSで、AWS European Sovereign Cloud（ESC）が2026年1月15日に一般提供を開始しました。ドイツ・ブランデンブルク州の第一リージョンはグローバルAWSとは物理的にも論理的にも分離された独立パーティション（aws-eusc）で、IAM・課金・DNS・認証局も独立、運用はEU居住者に限定され、ドイツ法人を親会社とする専用のガバナンス構造が置かれています。投資額は78億ユーロ超とされ、ベルギー・オランダ・ポルトガルへのLocal Zone拡張も発表されています。トレードオフとして、提供サービス数がグローバルリージョンより少なく、開始時点でアベイラビリティゾーンは2つでした。

では、これでCLOUD Actの適用は排除されるのか。法的にはされません。AWS European Sovereign Cloud GmbHはAmazon.com, Inc.の100%子会社であり、この点は欧州のアナリストからも指摘されています。運用主体をEU居住者に限定し、法人をドイツ法の下に置いても、親会社が米国企業である限り「占有・保管・支配」の議論は残ります。

この論点を最も明確にしたのが、2025年6月10日のフランス上院での証言です。「公共調達とデジタル主権」調査委員会の宣誓聴取で、Microsoft Franceの公共渉外・法務ディレクターAnton Carniaux氏は、フランス市民のデータが仏当局の同意なく米当局に渡らないことを保証できるかと問われ、公式議事録上「保証はできない。ただし繰り返すが、そうした事態はこれまで一度も起きていない」と答えました。正当な根拠を欠く要求は拒否しており、欧州の企業・公共部門への発動事例はないと付言していますが、技術的措置と契約上の約束では米国法の適用そのものは排除できないことを、事業者自身が公の場で認めた形になります。

なお、Microsoftは自社FAQで、EU域内のサービスはアイルランド法人Microsoft Ireland Operations Limited（MIOL）が提供し、欧州のデータセンターはMIOLとその子会社が所有・賃借していると説明しています。法人の所在を欧州に置く構成は共通の設計思想です。

CLOUD Actの直接の適用とは別に、欧州の危機感を高めた出来事として、2025年に国際刑事裁判所（ICC）主任検察官が米国の制裁対象に指定された件があります。同氏のMicrosoftアカウントが遮断されたと報じられ（Microsoftはサービスの停止・中断を否定）、ICCは2025年10月31日、Microsoft Officeからドイツ製オープンソースの「OpenDesk」への移行を確認しました。データを読まれるリスクではなく、サービスを止められるリスク——可用性の側面が主権議論の中心に入ってきたのは、この時期からです。

5. 日米間の非対称性

CLOUD Actのもう一つの柱が18 U.S.C. §2523の行政協定（executive agreement）です。一定の人権・プライバシー基準を満たす外国政府と協定を結ぶことで、相互に事業者へ直接データを請求できるようにする枠組みで、従来のMLAT（司法省と裁判所の個別承認を要する、時間のかかる手続）を迂回します。

2026年8月時点で発効しているのは米英協定（2019年10月署名、2022年10月3日発効）と米豪協定（2021年12月15日署名、2024年1月30日発効）の二つだけです。Microsoftも自社の透明性レポートで、米国政府が協定を締結しているのは英国と豪州であり、カナダおよびEUとは交渉を公表している、と明記しています。いずれの協定も重大犯罪に限定され（豪州協定では3年以上の拘禁刑）、5年の有効期間を持ちます。

日本との協定は存在せず、公開情報上、交渉開始の事実も確認できません。日米間には2003年8月に署名され2006年に発効した刑事共助条約があり、日本の当局が米国事業者からデータを取得しようとすればこのMLAT経路になります。ここに構造的な非対称性があります。

  • 米当局は、日本国内に保管されたデータでも、§2713により米国事業者へ直接請求できる。
  • 日本の当局は、米国事業者へ直接請求する迅速な経路を持たず、MLATを経由するしかない。
  • §2703(h)の礼譲条項が想定する「協定締結国の法との抵触」という抗弁も、協定がない以上、日本を対象としては働きにくい。

6. 日本政府はどう扱っているか

日本政府はこの問題を明示的に制度に書き込んでいます。デジタル社会推進標準ガイドラインDS-310「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2025年5月27日 デジタル社会推進会議幹事会改定）の3.2節は、次のように定めています。

クラウドの利用にあたっては、国内法以外の法令及び規制が適用されるリスクを評価し、情報が取扱われる場所及び契約に定める場所と準拠法・国際裁判管轄に留意する必要がある。（中略）政府情報システムが利用する場合、クラウドのデータセンタの設置場所に関しては、国内であることを基本とする。（DS-310 3.2節）

さらに踏み込んでいるのが、利用者データを国外クラウドに保管する場合の対策です。CRYPTREC暗号リスト掲載の暗号による暗号化を求めた上で、機密性によっては「利用者自身の暗号鍵によるデータの保護と鍵管理（BYOK等）を行い、クラウド（CSP）や監督権限を持った政府等が利用者データを判読不能とする措置を行うこと」と明記しています。「監督権限を持った政府等」——つまり外国政府による閲覧を、鍵管理によって無効化せよと政府自身が書いている。可用性についても、外国法令によるデータ域内保存義務等でリスクが予見される場合には「当該法令の効力の及ばない場所（国）にバックアップ等を保持する」よう求めています。

調達側の制度としてはISMAP（政府情報システムのためのセキュリティ評価制度）があり、政府調達は原則としてISMAP等クラウドサービスリスト登録サービスから選定されます。DS-310の3.1節は、サプライチェーン・リスクに注意を要する場合は「IT調達に係る国等の物品又は役務の調達方針及び調達手続きに関する申合せ」（平成30年12月10日関係省庁申合せ）に従って事前確認を行うことも求めています。この申合せが、後述する中央省庁での中国製通信機器の事実上の排除の根拠になっています。

ガバメントクラウドについては、長らくAWS・Azure・Google Cloud・Oracleの外資4社のみという状態が続きましたが、2023年11月に条件付きで採択されたさくらインターネットが約300項目の技術要件をすべて満たし、2026年3月27日に正式認定されました。国産事業者としては初、5番目の採択事業者となります。

民間側の主権対応としては、Oracleが提供するOracle Alloy（OCIと同一基盤をパートナーが自社データセンターで設置・運用する形態）を採用する事業者が複数あります。国内では富士通、NTTデータ、野村総合研究所などがこれを採用し、それぞれ自社ブランドのクラウドサービスを構築しています。日本オラクル自身も2025年7月、日本国内在住者のみで構成する「ジャパン・オペレーション・センター」を開設しました。運用要員の国籍・居住地まで管理対象に含めるという発想は、AWS ESCがEU居住者限定運用を掲げているのと同じ設計思想です。ただしこれらも、親会社の管轄という論点を法的に解消するものではない点は同様です。

7. 中国資本クラウドの日本国内展開

では中国資本のクラウドはどうか。まず事実関係として、日本国内に相当規模のインフラが存在します。

アリババクラウドは2016年に東京リージョンを開設しました。当初はソフトバンクとの合弁SBクラウドが運営していましたが、同社は2021年10月1日付でソフトバンクに吸収合併され消滅。現在はアリババクラウド・ジャパンサービス株式会社が国内事業を担っています。注目すべきは近年の拡張速度で、2026年3月に日本国内4か所目のデータセンターを開設し、その数か月後の2026年6月18日には5か所目を東京に開設。日本リージョンは5つのアベイラビリティゾーンで構成されるまでになりました。同時にAI開発プラットフォーム「Model Studio」の日本リージョン提供も始まっています。撤退どころか、AI需要を背景に日本での投資を加速させているのが実態です。

テンセントクラウドは東京に2ゾーンを持ち、2025年4月15日から16日にかけて、国内3拠点目のデータセンターを大阪に開設し大阪をリージョンとして設定すると発表しました（大阪リージョンのローンチ時期は2026年と説明されています）。日本法人はTencent Japan合同会社。同社カントリーマネージャーによれば顧客の約95%は日本国内のクライアントで、ゲーム・配信などエンターテインメント領域が約半分を占め、金融・小売分野も伸びているとのことです。

つまり「中国資本クラウドは日本ではほとんど使われていない」という前提は、事実に反します。少なくともゲーム・エンタメ・越境ECの領域では、実運用の基盤として定着しています。

8. 中国法の域外適用をめぐる二つの読み方

議論の中心にあるのが、2017年6月27日に可決され翌28日に施行された国家情報法（2018年改正）の第7条です。

いかなる組織及び国民も、法に基づき国家の情報活動を支持し、援助し、協力し、知り得た国家情報活動の秘密を守らなければならない。（国家情報法第7条、筆者訳）

この条文が中国企業の海外子会社にまで及ぶかについては、評価が割れています。

広く読む立場。スウェーデンの法律事務所Mannheimer Swartlingが2019年1月に公表した報告書は、国家情報法はすべての中国国民に適用され、中国企業グループの海外子会社も対象となりうる（親会社が同法の適用を受ける以上、国際公法の観点からは海外子会社にも管轄が及びうるし、親会社は子会社に対するガバナンス権限を持つ）と結論づけました。ただし同報告書自身が、これは英語版の客観的な読解と国際公法の原則に基づく分析であって、中国国内法体系の下での解釈ではないと明示的に留保しています。

限定的に読む立場。China Law Translate創設者のJeremy Daum氏は2024年、第7条が情報収集・共有への能動的な参加を求める趣旨であったかは全く明らかでないと指摘しています。同条には実効的な執行メカニズムがなく、罰則は情報活動が「妨害された」場合に限られ、その活動も「法に基づき」行われることが前提になっている、という読み方です。

重要なのは、この対立が公開情報だけでは決着しないという点です。中国資本クラウドには透明性レポートが存在しません。したがって「日本国内で開示事例が確認されていない」という事実は、事例が存在しないことの証明にはならず、確認する手段がないことを意味するにすぎません。米国資本クラウドについて件数を数えて議論できるのとは、そもそも土俵が違います。

関連する法制度としては、サイバーセキュリティ法（2017年）、データ安全法（2021年9月1日施行）、個人情報保護法（PIPL、2021年11月1日施行）があります。PIPLは域外適用条項を持ち、データの越境移転には安全評価・専門機関認証・標準契約のいずれかを要します。日本側から見ると、日本国内データの持ち出しを直接命じる規定というより、中国側の規制環境全体が国家の管理を前提に設計されている、という理解が実務的です。

9. 二つのリスクの構造比較

観点 米国資本クラウド 中国資本クラウド
主な根拠法 CLOUD Act（18 U.S.C. §2713）、SCA、FISA第702条 国家情報法、国家安全法、反スパイ法、サイバーセキュリティ法、データ安全法、PIPL
取得の主体 裁判官発付の令状・大陪審の召喚状（刑事）／FISC承認の認証（情報監視） 国家情報機関・公安機関
独立した司法審査 あり（刑事は相当理由の審査を伴う） 公開情報からは確認できない
透明性 半期ごとの件数公表が定着。越境開示件数も区分掲載 透明性レポートは存在しない
事業者による異議申立て §2703(h)の礼譲分析、裁判所での争訟が制度上可能 実効的な手段は公開情報上確認できない
越境協定の枠組み 米英・米豪の行政協定が発効。加・EUと交渉中。日本とは未締結 相当する相互協定の枠組みなし
確認できる発動実績 2025年下半期の越境エンタープライズ開示は3社分（Microsoft） 公開情報上、日本での開示事例は確認できない（確認手段自体がない）
日本政府の扱い ISMAP登録可、ガバメントクラウド採択。DS-310で外国法リスクを明示的に評価対象化 中央省庁は2018年の申合せで通信機器を事実上排除。自治体調達も認定制で限定する方針が報じられている
緩和策の効き方 鍵の自己管理は有効。ソブリン提供は運用・法人を分離するが、親会社の管轄は残る 運用主体とデータ所在で蓋然性は変わるが、透明性の欠如は技術では埋められない

日本政府の対中対応は、時系列で見ると一貫した方向を持っています。2018年12月の関係省庁申合せにより中央省庁・自衛隊のIT調達から中国製通信機器が事実上排除され、2024年5月17日には経済安全保障推進法の基幹インフラ事前審査制度が本格運用に入りました。そして2026年4月には、総務省が自治体のIT機器・サーバー・クラウド調達を政府認定品（経済産業省のJC-STARおよびISMAP）に限定する方針を固めたと報じられ、地方自治法関係の総務省令を改正のうえ2027年夏からの運用開始が見込まれています。JC-STARもISMAPも中国製品を認定していないため、事実上の排除になるという整理です。ハードウェアからクラウドへ、中央省庁から自治体へと、規制の網が段階的に広がってきたと見るのが自然でしょう。

10. 実務上の判断軸

以上を踏まえた実務的な整理です。順序が重要で、技術的対策から入ると必ず失敗します。

第一に、データを機微度で分類し、管轄をマッピングする。①一般業務データ、②個人情報・営業秘密、③基幹インフラ・国家安全保障に関わるもの、程度の粗い三分類で構いません。その上で各クラウド利用について「データ所在地」ではなく「運用主体の法人格と、その法人が服する管轄」を棚卸しします。ここで初めて、リージョン選択では動かせない部分が可視化されます。

第二に、機微度②③には暗号鍵の自己管理を標準化する。BYOK/HYOK、confidential computing、外部鍵管理サービスの利用です。判断軸は単純で、鍵を事業者が保持しているかどうか。事業者が復号できる構成である限り、令状は意味を持ちます。DS-310が「CSPや監督権限を持った政府等が利用者データを判読不能とする措置」と書いているのは、まさにこの点です。ただし同ガイドラインも、クラウド外で鍵を作成・保管・管理する場合は運用負荷と処理の複雑さが大幅に増すため導入前に十分な検討が必要だと注意喚起しています。実際、鍵の紛失は暗号化されたデータの永久喪失を意味します。

第三に、機微度③は管轄そのものを切り離す。国産クラウド、あるいは国内法人が国内要員で運用するソブリン提供を選択肢に入れます。政府・自治体関連業務では、2027年夏の自治体調達制限を先取りして認定制度（ISMAP、JC-STAR）への適合を要件化しておくのが安全です。

中国資本クラウドについては、機微度③には用いないというのが素直な結論になります。日本国内リージョンを使い、運用主体が日本法人であっても、透明性レポートが存在しない以上、リスクを定量的に評価できないからです。逆に言えば、中国向けEC・ゲーム配信のように業務上の必然性がある領域で機微度①のデータを扱う限りにおいて、これを一律に忌避する理由も薄い。用途で切り分ける話です。

判断を見直すべきトリガーとしては、日米CLOUD Act行政協定の交渉開始または締結、FISA第702条の再授権の帰趨（現在失効中で、FISCの認証は2027年3月頃まで）、メガクラウドの日本向けソブリン提供が非米国法人運営を実現するかどうか、あたりが挙げられます。いずれも制度の前提を動かす要素です。

まとめ

米国資本クラウドのCLOUD Actリスクは、構造としては不可避だが、エンタープライズ・非米国データに対する発動の蓋然性は統計的に低い。半期あたり数社分という越境開示の実績は、そのことを示しています。一方でその低さは事業者の自己申告に依存しており、秘匿命令の存在と、FISA第702条という別経路の不透明さがつきまといます。技術的措置と契約でCLOUD Actの適用を排除することはできない——これは事業者自身が公の場で認めた事実です。

中国資本クラウドのリスクは、蓋然性の高低以前に評価する手段が存在しないという設計上の問題を抱えています。国家情報法第7条の域外適用は法的評価が割れており、否定しきることも肯定しきることもできない。にもかかわらず日本国内には相当規模のインフラが存在し、拡張が続いています。「使われていないから問題にならない」という前提は成り立ちません。

結局のところ、外国資本クラウドの利用は「安全か危険か」の二択ではなく、どの管轄のどの制度に、どのデータを、どの緩和策を伴って預けるかという設計の問題です。日本政府自身がDS-310で、外国法リスクの評価、国内データセンターの原則、そして鍵の自己管理という三点を書き込んでいます。民間の実務も、そこから出発するのが筋が通っているように思います。

時刻: 0 件のコメント:
ラベル: , , ,

土曜日, 7月 04, 2026

南海トラフ巨大地震はITシステムをどう襲うか──2025年新想定で読み解くクラウド・通信・BCPの防災設計

2025年3月31日、内閣府の南海トラフ巨大地震対策検討ワーキンググループが約13年ぶりに被害想定を全面改定した。最大クラスの地震が発生した場合、直接死は最大29万8000人、経済被害は約292兆円に達するという、日本社会がこれまで経験したことのない規模の災害想定である。

本稿では、この新想定を踏まえ、データセンター・クラウド基盤、通信インフラ、企業のBCP、政府系システムという4つの切り口から、南海トラフ巨大地震がITシステムに与える影響を整理する。エンジニア・IT企画担当者が自組織の防災設計を見直す際の参考になれば幸いである。

1. 2025年新被害想定の要点

新想定の最大の特徴は、2012〜2013年の前回想定から死者数（前回32万3000人→今回29万8000人、約1割減）が若干改善した一方で、経済被害額（前回約220兆円→今回約292兆円）は建設費高騰や被害評価手法の高精度化により大幅に増加した点である。また今回初めて、避難生活に伴う体調悪化等で生じる「災害関連死」を試算し、2万6000〜5万2000人という数字が示された。これは直接死とは別枠のカウントであり、両者を合算した報道も見られるため注意が必要である。

項目 2012〜2013年想定（前回） 2025年3月新想定
死者数（直接死・最大） 約32万3000人 約29万8000人
災害関連死 試算なし 2万6000〜5万2000人（今回初試算）
経済被害額 約220兆3000億円 約292兆3000億円
震度7の市町村数 143市町村 149市町村
停電（最大） － 最大約2950万軒
断水（最大） － 最大約3690万人

なお、南海トラフ地震の30年以内発生確率については、2025年1月時点で「80%程度」とされていたが、その後、政府の地震調査委員会が不確実性を考慮した見直しを行い、2025年9月には「60〜90%程度以上」（算出方法によっては「20〜50%」という幅も存在）という表現に改められている。ブログや資料で「80%」という数字を引用する際は、この見直しの経緯を併記するのが望ましい。

2. データセンター・クラウド基盤への影響

2-1. 東京圏・大阪圏への一極集中という構造的リスク

総務省・経済産業省の有識者会合資料によれば、国内データセンターはサーバー面積ベースで約150万平方メートル（東京ドーム約30個分）存在するが、その8割強が東京圏・大阪圏に集中しており、この傾向は今後も続く見込みとされている。資料によって関東6割強・関西2割強程度という内訳も示されており、合計すると8〜9割が東京・大阪の2大都市圏に偏っている状況である。

この一極集中の背景には、インターネットサービスプロバイダーが相互接続を行うIX（インターネットエクスチェンジ）拠点が東京・大手町と大阪・堂島に集中しているという事情がある。IX接続数は関東が7割前後、関西が2割前後を占めるとされ、通信の遅延（レイテンシ）を抑えるためにデータセンターもこの2拠点周辺に立地する構造が続いてきた。

ここで重要なのは、南海トラフの想定震源域が静岡から九州にかけての太平洋沿岸に広がっており、大阪圏はこの震源域にきわめて近いという点である。新想定でも大阪府内の広い範囲で震度6弱以上、沿岸部では津波被害が想定されている。つまり「東京と大阪の2拠点に分散していればBCP的に安全」という従来の発想は、南海トラフ地震に関しては必ずしも成立しない。東京は首都直下地震、大阪は南海トラフ地震という異なる災害リスクにそれぞれ晒されているが、南海トラフが「全割れ」パターンで発生した場合、大阪圏のリスクは東京圏よりも直接的に高くなる可能性がある。

2-2. 主要クラウド事業者のリージョン構成

事業者 国内リージョン構成 備考
AWS 東京・大阪 ガバメントクラウドでも東京・大阪に限定
Microsoft Azure 東日本（東京・埼玉）・西日本（大阪） ガバメントクラウド認定
Google Cloud 東京・大阪 ガバメントクラウド認定
Oracle Cloud（OCI） 東京・大阪 ガバメントクラウド認定
FJcloud-V（富士通） 東日本4リージョン・西日本2リージョン 北米リージョン（us-east-1）は2025年9月30日にサービス提供終了、現在は国内6リージョン構成
さくらインターネット 石狩（北海道）・東京 2026年3月27日にガバメントクラウド正式認定。国産クラウドとして唯一かつ5番目の認定事業者

見ての通り、政府認定クラウドはAWS・Azure・Google Cloud・OCIの4社に加え、2026年3月27日にさくらインターネットの「さくらのクラウド」が正式認定を受け、5社体制となった。国産クラウドとしては唯一の存在であり、外資系4社が軒並み東京・大阪の2拠点構成であるのに対し、さくらインターネットは石狩（北海道）と東京という組み合わせを取っている点が構造的に異なる。

外資系4クラウドの東京・大阪2拠点構成は、通信遅延やデータ主権要件を満たす現実的な選択ではあるが、前述の通り大阪が南海トラフの震源域に近接している以上、「東京・大阪の2リージョン運用＝広域災害対策として十分」とは言い切れない構造である。その意味で、震源域から遠い石狩を含むさくらインターネットの構成は、南海トラフ地震という単一災害シナリオに対する耐性という観点では、外資系4社の東京・大阪構成よりもむしろ有利に働く可能性がある点は付記しておきたい（ただし、石狩・東京の組み合わせは首都直下地震と北海道地震という別の複合リスクを内包する点には留意が必要である）。

2-3. ガバメントクラウドの地理分散要件

この課題は政府側も認識しており、デジタル庁が公表しているガバメントクラウド調達仕様書（令和8年度募集分）には、データセンターは地理的に離れた日本国内の複数の地域（例えば、関東と関西、北海道と関東、関西と九州など）に設置するなど、大規模地震や電力供給障害を想定した災害対策を講じることという要件が明記されている。「関東と関西」だけでなく「北海道と関東」「関西と九州」という組み合わせも例示されている点は重要で、南海トラフの震源域から離れた北海道・九州を含めた分散が政府調達レベルでは想定され始めていることを示している。

実際の事例として、ガバメントクラウド先行事業に採択された神戸市では、東京リージョンと大阪リージョンの間でDR環境を構築した例が報告されている。ただし、これも本質的には「東京・大阪の2点間分散」であり、南海トラフの全割れシナリオに対する耐性という観点では、北海道・九州など震源域から十分離れた第三のリージョンを組み合わせる設計が今後より重要になると考えられる。

3. 通信インフラへの影響

3-1. 海底ケーブル陸揚局の太平洋側集中

総務省資料によれば、国際海底ケーブルの陸揚局は約5割が関東（房総半島・北茨城）、約3割が関西（志摩半島）に集中している。志摩半島は三重県、まさに南海トラフの想定震源域の直上に位置する。南海トラフ地震で志摩半島周辺の陸揚局が被災した場合、国際通信の分岐点としての機能が損なわれるリスクがあり、国内のインターネット接続全体への波及も懸念される。政府はこのリスクを踏まえ、国際海底ケーブルの多ルート化や陸揚局の分散を「デジタル田園都市国家インフラ整備計画」の一環として進めている。

3-2. 過去の大規模災害から見える通信インフラの限界

東日本大震災（2011年）では、非常用電源の枯渇等により通信各社合計で約2万9000の基地局が停波した。復旧には約1カ月半を要し、4月末時点でようやく福島第一原発周辺の対応困難エリアを除きほぼ復旧した。音声通話については輻輳対策としてNTTドコモ・KDDI・ソフトバンクの主要3社が最大70〜95%の通信規制を実施している。

北海道胆振東部地震（2018年）では、日本初となる全域停電（ブラックアウト）が発生し、約6500基地局が停波、停電は最大295万戸に及んだ。北海道電力の全域停電は約64時間後まで続いた。この際、さくらインターネットの石狩データセンターは非常用発電機で稼働を継続したものの、商用電源喪失を検知して非常用電源へ切り替える制御回路が正常に作動せず、一部ゾーンのサーバーが約5時間停止するというトラブルも発生している。自家発電設備を備えていても、切替機構そのものの信頼性検証（実負荷試験等）が欠かせないことを示す実例といえる。

両震災に共通する教訓は、①非常用電源の燃料備蓄量（東日本大震災当時は基地局の電源容量が不足し長時間停電に耐えられなかった）、②電源切替機構の信頼性、③通信規制による輻輳回避と業務影響の両立、の3点に集約される。NECや富士通のデータセンターが胆振東部地震で72時間分の燃料備蓄により無停止運用を実現した実績は、南海トラフ地震のような広域・長期停電（新想定では電柱被害による停電復旧に1〜2週間を要すると想定）に対しては、72時間備蓄でも不十分となり得ることを示唆している。燃料の追加供給契約や自治体・自衛隊との連携も含めた計画が必要である。

4. 企業のBCP・事業継続への影響

新想定では、停電の復旧について、需給バランスに起因するものは数日で復旧する一方、電柱等の設備被害による停電は復旧までに約1〜2週間を要するとされている。断水についても、東海3県で復旧率95%に達するまで約8週間かかるとの想定である。IT部門がBCPを検討する上では、「停電=数日で復旧する」という楽観的な前提ではなく、地域によっては1〜2週間規模の長期停電・断水を前提とした計画が必要になる。

また、南海トラフ沿岸には製造業・小売業が集積しており、新想定でも生産・サービス低下に伴う被害は45兆4000億円と見積もられている。サプライチェーンの寸断は、直接被災していない地域の企業にとっても、部材調達・物流の停止という形でIT基盤以外の側面からも事業継続に影響を与える点に留意したい。

5. 政府系システムへの影響

政府は2025年度末までに地方自治体の基幹システムをガバメントクラウドへ移行する方針を掲げてきたが、令和7年12月末時点で標準化対象約3万4592システムのうち特定移行支援システムに該当する見込みは約26%にとどまっており、移行は依然として進行中の段階にある。南海トラフ地震が今後30年以内に高い確率で発生し得ることを踏まえると、移行完了前の過渡期における自治体システムの災害耐性（オンプレミス環境の耐震性、ガバメントクラウドへの接続経路の冗長性等）も論点となる。

ガバメントクラウドの調達仕様書に明記された地理分散要件（前述）は、今後の自治体システム設計における重要な指針になる。特に、東京・大阪の2点間DRだけでなく、震源域から離れた北海道・九州を組み合わせた構成が推奨される方向性がうかがえる。

6. IT視点での対策の方向性

  • 3拠点以上への地理分散：東京・大阪の2リージョン運用に加え、震源域から離れた北海道・九州リージョンを組み合わせた3-2-1的なバックアップ設計を検討する。
  • 長期停電を前提とした電源設計：72時間の自家発電備蓄を基本としつつ、新想定が示す1〜2週間規模の停電復旧期間を踏まえ、追加燃料供給契約や複数系統からの調達を確保する。
  • 電源切替機構の実負荷試験：胆振東部地震の教訓として、UPS・自家発電への自動切替回路そのものの定期的な実負荷試験を行う。
  • RPO/RTOの数値化と定期的な検証：「クラウドだから大丈夫」という前提を避け、復旧目標時点（RPO）・目標時間（RTO）を具体的な数値で定義し、実際のフェイルオーバー訓練で検証する。
  • 通信手段の多重化：衛星通信（Starlink等）や複数キャリア回線の併用により、特定地域の基地局・海底ケーブル陸揚局の被災に備える。

まとめ

2025年の新被害想定は、死者数こそ微減したものの、経済被害額の増加や災害関連死の新規試算など、南海トラフ巨大地震の深刻さを改めて示すものとなった。ITシステムの観点で特に注意すべきは、国内データセンターの8割強、そして政府認定クラウドのうち外資系4社の国内リージョンが東京・大阪の2拠点に集中している一方、大阪が南海トラフの震源域にきわめて近いという構造的な脆弱性である。2026年3月に正式認定された国産唯一のさくらインターネットが石狩・東京という異なる組み合わせを取っている点は、分散の選択肢として注目に値する。ガバメントクラウドの調達仕様に見られるように、政府側でも北海道・九州を含めた分散の重要性が認識され始めている。「東京・大阪2拠点分散＝十分な災害対策」という従来の常識を見直し、震源域から十分離れた第三・第四の拠点を組み込んだ設計へと移行することが、今後のIT防災における重要な論点になるだろう。

参考文献・出典

  • 内閣府 南海トラフ巨大地震対策検討ワーキンググループ「南海トラフ巨大地震 最大クラス地震における被害想定について」（2025年3月31日）
  • 内閣府 中央防災会議「南海トラフ巨大地震対策について（報告書）」（令和7年3月）
  • 総務省・経済産業省「デジタルインフラ（DC等）整備に関する有識者会合」事務局説明資料（2024年5月）
  • 内閣官房 GX実現に向けた専門家ワーキンググループ（第8回）「データセンター等のデジタルインフラ整備の現状と課題について」（2024年10月）
  • デジタル庁「デジタル庁におけるガバメントクラウド等の整備のためのクラウドサービスの提供－令和8年度募集－調達仕様書」
  • 総務省北海道総合通信局「平成30年北海道胆振東部地震・ブラックアウト 通信・放送の被害状況と当局の対応」（2019年1月）
  • 参議院 総務委員会調査室「東日本大震災における情報通信分野の主な取組」
  • さくらインターネット「石狩データセンター10周年－挑戦の軌跡－」
  • 日経クロステック「データセンターと通信への影響、北海道地震で生かされた経験」
  • さくらインターネット株式会社「令和5年度および令和8年度 ガバメントクラウドサービス提供事業者に採択」（2026年3月27日）
  • ITmedia NEWS「さくらインターネットのクラウドサービス、ガバメントクラウド正式認定 技術要件満たす」（2026年3月27日）
  • FJcloud-V「北米リージョン(us-east-1)の提供終了について」
時刻: 0 件のコメント:
ラベル: , , , , , , , , , ,

月曜日, 6月 29, 2026

Amazon EVS（Amazon Elastic VMware Service）完全解説

Amazon EVS（Amazon Elastic VMware Service）完全解説

VMware on AWS後継の本命か？競合との徹底比較 ― インフラエンジニア向け技術解説（2026年6月時点）

⚡ TL;DR
Amazon EVSは2025年8月5日にGAした、VCF（VMware Cloud Foundation）を顧客自身のVPC内・EC2ベアメタル上でセルフマネージドで動かすAWSネイティブサービス。東京リージョン（ap-northeast-1）はGAから対応。最小4ホスト・最大32ホスト（2026年5月に16→32に拡張）、BYOLのVCFライセンスが必須。VMC on AWS「再販終了」後の実質的な移行先だが、パッチ・アップグレード・障害ホスト交換は顧客責任という点がVMCとの最大の違い。東京4ホスト最小構成でのAWS側コストはオンデマンドで約$40,600/月（VCFライセンス別途）。

1. Amazon EVSとは

Amazon Elastic VMware Service（Amazon EVS）は、AWSがVMware Cloud Foundation（VCF）を顧客のAmazon VPC内に自動デプロイし、EC2ベアメタルインスタンス（i4i.metal等）上でそのまま動かすためのAWSネイティブサービスだ。AWSがインフラプロビジョニングとハードウェア管理を担い、顧客はESXi・vCenter・NSX・SDDC Managerへのフルルート権限を持ちながらVMwareワークロードを運用できる。

沿革を整理すると、AWS × VMware（現Broadcom）の協業は2016年に始まり、フルマネージドの「VMware Cloud on AWS（VMC）」として展開されてきた。しかし2024年2月のBroadcomによるVMware買収後のライセンス改定、2024年4月30日のAWSによるVMC再販終了を経て、2024年末のre:Invent 2024でAWSがEVSを発表。2025年6月9日にパブリックプレビュー（東京含む5リージョン）、同年8月5日に一般提供（GA）を開始した。GA対応リージョンは米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（フランクフルト・アイルランド）の6リージョン。その後2025年11月にムンバイ・シドニー・カナダ中部・パリに拡張されている。

AWSによるVMware移行戦略の位置づけ
EVSはAWSが「プリミティブなサービス（ビルディングブロック）」と位置づけており、顧客がVMwareワークロードをそのままAWSで動かす最速経路として提供される。AWSには他にAWS Transform（エージェント型AI移行）、Application Migration Service（MGN）、コンテナ化（ECS/EKS）など複数の移行経路があるが、EVSは「再プラットフォーム・リファクタリング不要」の選択肢だ。

2. アーキテクチャと技術仕様

SDDC構成（Consolidated Architecture）

EVSはVCFの「Consolidated（統合）アーキテクチャ」を採用する。これは管理コンポーネントとワークロードVMを単一クラスタ上に同居させるモデルで、自動デプロイされる管理コンポーネントは以下の通りだ。

  • vCenter Server（1台）
  • SDDC Manager（1台）
  • NSX Manager（3台クラスタ構成）
  • NSX Edge（2台、Active/Standby）
  • Cloud Builder（デプロイ完了後に自動削除）

これらの管理VMはvSphereリソースプールで分離されるが、ワークロードVMと同一ESXiホスト上で動作する。VCFのSeparated Architecture（管理ドメインとワークロードドメインを物理分離）はEVSでは現時点で非対応。

ネットワーク構成

EVSのネットワークは2層構造だ。外側はAmazon VPC（アンダーレイ）、内側はNSXオーバーレイ（T0/T1ゲートウェイ）。T0ゲートウェイがVPC Route Server Endpointとの間でeBGPピアリングを確立し、NSXオーバーレイのCIDRをVPCルートテーブルにアドバタイズする仕組み。EVS環境ごとに2つのVPC Route Server Endpointが必須。

構成上の制約として、T0ゲートウェイは1環境あたり1台のみ、シングルAZ構成のみ（マルチAZ非対応）という点は設計で重要な検討事項となる。オンプレミスとの接続はTransit Gateway経由のDirect Connect（Transit VIF）またはSite-to-Site VPN（TGWアタッチメント）が必要で、Direct Connect Private VIFやVGWベースVPN、VPCピアリングは非対応。

ストレージ

プライマリストレージはvSAN（ローカルNVMeインスタンスストア）。i4i.metalでは1ホストあたり約20.5 TiB rawのvSANキャパシティが使用可能（vSAN圧縮・重複排除有効時の実効容量はワークロード依存）。インスタンスストアはEphemeralであるため、VCFコマンドを経ずにEC2インスタンスを停止・終了するとデータを失う。外部ストレージとしてAmazon FSx for NetApp ONTAP（NFS/iSCSI）やPure Cloud Block Storeが対応している。

デプロイ所要時間はAWSコンソールのガイド付きワークフローまたはCLI/CloudFormationから約3時間で完了する。

⚠️ 注意：VMCから移行時に失われる機能
VMC on AWSで利用できた vDefend Advanced Threat Protection と VMware Live Cyber Recovery はEVSでは現時点で非対応。vSphere HA/DRSはセルフマネージドでの構成が必要。EDRS（Elastic DRS）もEVSでは使用不可。

3. 最小構成・最大構成（東京リージョン）

項目 i4i.metal（GA当初） i7i.metal-24xl（追加） 東京リージョン対応
vCPU数 128 vCPU（64物理コア×HT） 96 vCPU（48物理コア×HT） 両タイプ対応
メモリ 1,024 GiB 768 GiB ―
ローカルNVMe 30 TB（vSAN: 約20.5 TiB raw/host） 約22.5 TiB raw/host ―
ネットワーク 75 Gbps 200 Gbps超 ―
CPU世代 第3世代 Intel Xeon (Ice Lake) 3.5 GHz 第5世代 Intel Xeon Scalable (Emerald Rapids) ―
最小ホスト数 4ホスト固定（環境作成時） 4ホスト固定（環境作成時） 4ホスト〜（キャパシティ予約推奨）
最大ホスト数 32ホスト（※1） 32ホスト（※1） クォータ引き上げリクエスト必要
VCFライセンス要件 最低256コア（4ホスト×64物理コア） 4ホスト×コア数分 BYOL必須（Broadcom購入）

（※1）2026年5月19日付けAWS What's NewにてGA当初の上限16から32へ倍増。サービスクォータ引き上げリクエストが必要。

その他の前提条件

  • AWSサポートプラン：Business Support以上が必須（環境作成失敗条件）。なお2027年1月以降、Business Supportは廃止予定でBusiness Support+（$29/月〜）が実質最低基準に移行する。
  • VPC：最小/22のCIDRブロック、Route Server Endpoint×2（それぞれ専用ピア）が必要。IPv6は現時点で非対応。
  • 対応VCFバージョン：5.2.1、5.2.2（2026年6月時点）。VCF 9は現時点で非対応。
  • デプロイ所要時間：約3時間（コンソールまたはCLI/CloudFormation）。

4. 最小構成で動くワークロードVM数の比較

インフラエンジニアがサービス選定で最も気にするポイントの一つが「最小構成でどれだけのVMを動かせるか」だ。各サービスの最小構成におけるワークロードVM稼働数の推計を以下の前提で比較する。

推計前提条件
標準VM：2 vCPU / 8 GiB RAM / 100 GiB diskの小中規模汎用VM想定。管理コンポーネント消費分（VCF: 約24 vCPU・200 GiB、Nutanix CVM: ノードあたり12 vCPU・32 GiB等）を控除。vSphere HAの1ノード分フェイルオーバー予約（25%相当）を控除。CPUオーバーコミット比は2:1適用。VDI（1 vCPU/4 GiB）は約2倍、DBサーバー（8 vCPU/32 GiB）は約1/4が目安。
サービス 最小ノード数・仕様 総vCPU / 総RAM 推計ワークロードVM数 制約要因・特記
Amazon EVS 4 × i4i.metal
128 vCPU / 1,024 GiB		 512 vCPU
4,096 GiB		 200〜400 VM 最小4ノードのため他サービスより容量大。HAで1ノード分（1,024 GiB）確保。RAM制約が支配的。vSAN容量は十分（FTT=1で約50 TiB usable）。
Azure VMware Solution 3 × AV36
36コア / 576 GiB		 216 vCPU
1,728 GiB		 70〜150 VM Microsoft管理コンポーネントが46 GHz CPU・171 GiB RAMを予約（3ノード中の約50%に相当）。RAM・CPUともに制約。HA1ノード分を除くと実効容量は小さい。
Google GCVE 3 × ve1-standard-72
72 vCPU / 768 GiB		 216 vCPU
2,304 GiB		 100〜200 VM AVS AV36よりメモリ1ノードあたり192 GiB多い（768 vs 576 GiB）。フルマネージドのためHA予約がGoogle任せで透明度低め。
Oracle OCVS 3 × BM.DenseIO.E4.128
128 OCPU / 2,048 GiB		 384 OCPU
6,144 GiB		 200〜500 VM 最大RAMを誇る構成。旧DenseIO2.52（52 OCPU/768 GiB）では80〜170 VM程度。標準shapeはOCI Block Storageを使いvSAN不要。東京リージョン（ap-tokyo-1）はOCVSの対応状況を個別確認要。
NC2 on AWS
（Nutanix）		 3 × i4i.metal
128 vCPU / 1,024 GiB		 384 vCPU
3,072 GiB		 150〜300 VM CVM（Controller VM）がノードあたり12 vCPU・32 GiB消費。最小3ノード。最大28ノード（7 placement group対応リージョン）。ハイパーバイザはAHV（ESXiではない）。

※ 推計値。実際のVM数はVMサイズ・CPUオーバーコミット率・ワークロード特性・vSAN利用可能容量によって大きく変動する。VDI（1 vCPU/4 GiB）なら約2倍、DBサーバー（8 vCPU/32 GiB）なら約1/4が目安。

📌 重要な注意点：最小ノード数の差
EVSは最小4ノード、他のサービスは最小3ノードという構造差がある。EVSの「200〜400 VM」はこの1ノード多い構成に起因する部分が大きい。同じ3ノードに換算すると3×i4i.metalで約150〜300 VM相当になり、NC2（AHV）と同程度の容量になる点に注意。

5. VMware Cloud on AWS（VMC）との比較

比較項目 Amazon EVS VMware Cloud on AWS（VMC）
サービスモデル セルフマネージド（AWSネイティブサービス） フルマネージド（Broadcom運営）
デプロイ先 顧客自身のVPC内 Broadcom管理SDDC（顧客VPC外）
vCenter/ESXi管理権限 フルルート権限あり（VIB導入等の自由度高い） Broadcomが管理、顧客は限定アクセス
パッチ・アップグレード責任 顧客（またはパートナー）責任 Broadcom責任
障害ホスト交換 顧客責任（AWSに連絡し交換手続き） Broadcom責任
ライセンスモデル BYOL必須（VCFポータビリティ） Broadcom直販サブスクリプション（ライセンス込み）
最小ホスト数 4ホスト 2ホスト〜（i3.metal）
EDRS（弾力的リソーシング） 非対応（セルフ管理必要） 対応
vDefend ATP 現時点で非対応 対応
AWSからの販売 AWSが提供（AWSアカウント直結） 2024年4月30日にAWS再販終了・Broadcom直販のみ

VMC→EVS移行パス：VMware HCXを使ってVMC on AWS→EVSへのvMotion/Bulk/RAV移行が公式サポートされている。VMC GovCloudのEOLなども背景にあり、VMC利用中で将来不透明感を感じている組織にとってEVSは最も自然な移行先だ。EVSデプロイ時にHCXのプライベート接続方式（Direct Connect または Public Internet）を一度選択すると変更不可な点に注意。

6. NC2 on AWS（Nutanix）との比較

NC2 on AWSとEVSは「AWSベアメタル上でオンプレの仮想化環境をそのままクラウドに持ち込む」という方向性は共通しているが、ハイパーバイザと用途が根本的に異なる。

比較項目 Amazon EVS NC2 on AWS（Nutanix）
ハイパーバイザ VMware ESXi Nutanix AHV（VMware非依存）
管理ツール vCenter / SDDC Manager / NSX Prism Central / Prism Element
ストレージ vSAN（ローカルNVMe）＋外部（FSx等） Nutanix DSF（CVM管理）＋EBSストレージ拡張可
最小ノード 4ノード 3ノード（2ノードは非対応）
最大ノード 32ノード/環境 28ノード/クラスタ（7 placement group対応リージョン）
利用可能インスタンス i4i.metal、i7i.metal-24xl i3.metal、i3en.metal、i4i.metal、i7ie/i7i.metal-24xl/48xl、z1d.metal等
VMware移行ツール HCX（vMotion/Bulk/RAV） Nutanix Move（ESXi→AHV変換が必要）
クラスタHibernate 非対応 対応（S3退避でコスト最適化可）
位置づけ VMware継続（スキル・ライセンス・ツール維持） VMware脱却（AHVへのハイパーバイザ変換）

判断軸：VMwareからの移行時にESXi・vCenter・NSXのスキルとライセンスを維持したければEVS。Nutanixをオンプレで採用中・採用予定であればNC2。VMwareから完全脱却してコスト削減を狙うならNC2（ただしNutanix Moveでのハイパーバイザ変換工数が発生）。

7. 競合サービス比較（AVS / GCVE / OCVS）

比較項目 Amazon EVS Azure VMware Solution（AVS） Google Cloud VMware Engine（GCVE） Oracle Cloud VMware Solution（OCVS）
管理モデル セルフマネージド マネージド寄り（Microsoft管理） フルマネージド（Google管理） 顧客フルアクセス型（EVSに最も近い）
最小ノード 4ノード 3ノード 1ノード（PoC）/ 3ノード（本番） 1ノード（dev）/ 3ノード（本番）
最大ノード/クラスタ 32ノード/環境 96ノード/プライベートクラウド（最大12クラスタ×最大16ノード） 64ノード（全クラスタ合計） 64ノード/クラスタ（最大15クラスタ）
マルチAZ 非対応（シングルAZのみ） Stretched Cluster対応（マルチAZ） Stretched Cluster対応（マルチゾーン） フォルトドメイン単位（シングルAD）
VCFライセンス BYOL必須 2025年11月以降新規ノードはBYOL基本 Google包含（ライセンス込み） Oracle包含またはBYOL（移行フェーズ依存）
HCX 対応（HCX Advanced/Enterprise） HCX Advanced 包含 HCX 包含 HCX 包含
東京/日本リージョン ap-northeast-1（東京）対応済み Japan East（東日本）対応 asia-northeast1（東京）対応 ap-tokyo-1（東京）対応状況は要確認
デプロイ時間 約3時間 約3〜4時間 約30〜60分（高速プロビジョニング） 約2〜4時間

各サービスの特徴整理

  • AVS（Azure）：Azureエコシステム（Azure NetApp Files、Azure Elastic SAN等）との統合が強み。Stretched Clusterでマルチ可用性ゾーンに対応できる点がEVSと異なる大きな差別化。マネージド寄りのため運用負荷は低め。
  • GCVE（Google）：フルマネージドで運用負荷が最も低い。1ノードから試せる柔軟性と30〜60分の高速プロビジョニングが評価される。ve2世代（128 vCPU/2TB RAM）への世代交代が進行中。
  • OCVS（Oracle）：ESXiルートアクセスでEVSに最も近い運用モデル。OCI Block Storage（外部ストレージ）との組み合わせで「コンピュートとストレージの独立スケーリング」が可能という独自性を持つ。46以上のグローバルリージョンで最大のカバレッジ。

8. コスト・ライセンス（東京リージョン試算）

AWS側料金の構成（3要素）

  1. EC2インスタンス料金（i4i.metal）：オンデマンド・1年/3年 Savings Plan（ISP）・予約で割引選択可
  2. EVSコントロールプレーン：$0.92/usage-hour（ホスト数×時間）
  3. VPC Route Server Endpoint：$0.20/endpoint-hour（2 endpoint必須、標準料金の73%割引適用後）

東京リージョン（4×i4i.metal、730時間/月）試算

料金タイプ EC2（i4i.metal×4） EVSコントロールプレーン Route Server（×2） 合計/月（AWS課金のみ）
オンデマンド $12.883/hr × 4 × 730h
≒ $37,618		 $0.92 × 4 × 730h
≒ $2,686		 $0.20 × 2 × 730h
≒ $292		 約 $40,600 /月
3年 ISP（推計） ≒ $17,377 ≒ $2,686 ≒ $292 約 $20,355 /月

※ EC2 i4i.metalの東京オンデマンド単価はサードパーティ価格情報ベース。3年ISPは米国比から推計した参考値。正確な見積もりはAWS Pricing Calculator（ap-northeast-1）で実施のこと。VCFライセンスコスト（Broadcom別途購入）は含まず。

Broadcom VCFライセンスについて

  • BYOL（ライセンスポータビリティ）必須：VCFサブスクリプション＋ポータビリティ権が必要（2023年12月13日以降購入のVCF 5.1+に付帯）。
  • 最低コア要件：256コア（4×i4i.metal の初期デプロイ分）＋vSAN 110 TiB容量ライセンス。
  • 課金単位：物理コア単位（16コア/CPU最小）。かつて2025年4月に追加された「72コア/インスタンス最小」の要件は後に撤回された模様（契約時に最新条件を要確認）。
  • クラウドプロバイダー経由ライセンスにポータビリティ権なし：パブリッククラウドプロバイダー経由で取得したライセンスはポータビリティ対象外。
  • Windows Serverライセンス：EVSを通じてVM単位での取得が可能（$0.046/vCPU-hour）。

9. 移行シナリオ（VMware from ― HCX活用）

EVSはVMware HCX（VCF Operations HCX）を公式サポートする。HCXはデフォルトではEVS環境にインストールされておらず、EVSデプロイ後に別途構成が必要。

接続方式（デプロイ時に一度のみ選択・変更不可）

  • プライベート接続：Direct Connect（Transit VIF + Direct Connect Gateway + Transit Gateway）またはSite-to-Site VPN（TGW VPNアタッチメント）経由。本番・大規模移行に推奨。
  • パブリックインターネット接続：IPAMで公開IP割当、隔離されたHCX用パブリックVLANサブネットが必要。帯域幅制約に注意（WAN最適化機能HCX-WOの活用を推奨）。

主な移行パターン

  • オンプレVMware → EVS：HCXサイトペア設定→Service Mesh作成→vMotion/Bulk/RAV移行。IPアドレス変更不要、運用ランブック変更不要で移行可能。
  • VMC on AWS → EVS：HCXプライベート接続（Transit Gateway経由）でVMC→EVS間のvMotion移行。
  • DR用途（EVSをDRサイトに）：本番オンプレ/クラウド→EVSをDRターゲットとしてHCX RAVで非同期レプリケーション。

HCXの主な移行タイプ：Cold Migration、vMotion（無停止・単一VM）、Bulk Migration、Replication Assisted vMotion（RAV：並列・スケジュール・無停止）、OS Assisted Migration（非vSphere）、L2 Network Extension（IP変更不要）。

10. 強みと弱みまとめ

✅ 強み
  • VMwareスキル・ツール・ランブック維持のまま移行可能
  • 顧客VPC内デプロイで200以上のAWSサービスと同一VPC内で直結
  • ESXi/vCenter/NSX/SDDC Managerへのフルルート権限（VIBインストール等も可能）
  • 約3時間でVCF環境が自動展開
  • HCXによるIP変更不要のシームレス移行
  • VCFライセンスポータビリティでBroadcom投資を活用
  • Kyndryl・DXC・富士ソフト等のパートナーマネージドサービスで運用負荷を外出し可能
  • 2026年5月以降、最大32ホスト/環境に拡張（当初16）
❌ 弱みと制約
  • セルフマネージド：ESXi/vSAN/NSXのパッチ・アップグレード・障害ホスト交換が顧客責任
  • シングルAZのみ：マルチAZ（Stretched Cluster）非対応
  • VCF 9非対応（2026年6月時点）：5.2.1/5.2.2のみ
  • 最小4ホスト：競合（3ホスト〜）より参入コストが高い
  • T0ゲートウェイは1環境あたり1台のみ
  • vDefend Advanced Threat Protectionが現時点で非対応
  • Business Support（最低）以上が必須（2027年以降はBusiness Support+以上）
  • BroadcomのVCFライセンスを別途調達する必要があり、ライセンスコストが不確定
  • 接続方式（プライベート/パブリック）はデプロイ時の一度きりの選択で後から変更不可

11. まとめ ― 評価・選定の推奨ステップ

Amazon EVSは「VMware資産・スキルをそのまま維持しながらAWSクラウドの恩恵を受ける」という課題に対して2025年8月にGAした現実解だ。VMC on AWSの再販終了後を睨んだ選択肢として、特に大規模なVMwareデータセンター撤退・DR強化・段階的モダナイゼーションを検討している組織に刺さるサービスといえる。

一方で、セルフマネージドゆえの運用負荷（パッチ・アップグレード）、最小4ホストという参入コスト、VCF 9非対応、シングルAZ制約という限界点も明確だ。これらを踏まえた評価フローは以下になる。

評価・判断フロー
① VMwareを継続するか脱却するか → 脱却ならNC2（AHV）またはAWSネイティブ移行（MGN等）を検討
② マルチAZ（Stretched Cluster）が必須か → 必須ならAVS（Azure）またはGCVEを検討
③ 最小3ノードで十分か → 3ノードで十分ならAVS/GCVE/OCVSが有利
④ VCF 9が早期に必要か → 必要なら2026年時点でEVSは非対応のため待機またはオンプレVCFを維持
⑤ セルフマネージドの運用負荷を自社で吸収できるか → できない場合はKyndryl・DXC・富士ソフト等のパートナーマネージドを前提に検討
⑥ 3年コミットが可能なワークロードがあるか → あればSavings Planで東京でも月額$20,000台（4ホスト、AWS課金のみ）まで削減可能
本記事で修正・更新した主な情報（ファクトチェック結果）
・最大ホスト数：16ホスト → 32ホストに修正（2026年5月What's New確認）
・パブリックプレビュー開始：2025年6月9日（東京含む5リージョン）確認
・サポートプラン：Business Support以上（最低要件）を公式ドキュメントで確認。2027年1月以降はBusiness Support+が実質最低基準となる予定。
・EVSで現時点非対応機能（vDefend ATP、VMware Live Cyber Recovery）を追記
・NC2最大ノード数（28ノード/クラスタ）を追記
・AVSの管理コンポーネント予約（46 GHz CPU / 171.88 GiB RAM）に基づくVM数試算を追記

本記事は2026年6月時点の公開情報（AWS公式ドキュメント・What's New・各クラウドベンダー公式資料）に基づいています。料金・仕様・対応リージョンは変更されることがあるため、最新情報はAWS Pricing Calculator・各サービス公式ページで確認してください。

時刻: 0 件のコメント:
ラベル: , , , , , ,
登録: 投稿 (Atom)