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

土曜日, 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)の提供終了について」

月曜日, 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 ProtectionVMware 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・各サービス公式ページで確認してください。

月曜日, 6月 22, 2026

マネージドAI推論プラットフォーム徹底比較:Amazon Bedrock / Azure AI Foundry / Google Vertex AI / OCI Generative AI(2025〜2026年6月版)

クラウド上で生成AIを本番利用する際、インフラ運用を意識せずに多様なLLMを呼び出せる「マネージドAI推論プラットフォーム」の重要性が急速に高まっている。2026年6月時点で主要プレイヤーとなっているのが、Amazon BedrockAzure AI FoundryGoogle Vertex AIOCI Generative AIの4サービスだ。本記事では、対応モデル・料金・日本リージョン/主権AI対応・RAG/エージェント機能・セキュリティ・市場シェアの6軸で徹底比較する。

1. サービス概要と位置づけ

まず4サービスの基本的な立ち位置を整理する。いずれも「APIを叩けば複数のLLMを呼び出せるマネージドサービス」という点では共通だが、強みの方向性は大きく異なる。

項目 Amazon Bedrock Azure AI Foundry Google Vertex AI OCI Generative AI
提供元 Amazon Web Services Microsoft Google Cloud Oracle Cloud Infrastructure
最大の強み モデルの幅・AWSエコシステム統合・JP Geo推論 OpenAI最新モデルへの最速アクセス・M365統合 Gemini自社モデル・MLOps・BigQuery統合 Oracle DB統合・コスト・ZDR・ソブリンAI
主な対象ユーザー AWS中心の企業・金融・公共 Microsoft/Azure中心・Office利用企業 GCP利用企業・データサイエンス重視 Oracle DB資産保有・コスト重視・規制業界
旧名称/統合経緯 —(2023年4月GA) 旧Azure AI Studio + Azure OpenAI Serviceを統合(2024年) 2026年Cloud NextでGemini Enterprise Agent Platformへ統合 —(2024年1月US GA、同年12月大阪提供開始)

2. 対応モデル・LLMラインナップ

モデルの選択肢はサービスの根幹だ。4社の提供モデルを比較する。

カテゴリ Amazon Bedrock Azure AI Foundry Google Vertex AI OCI Generative AI
自社ファーストパーティ Amazon Nova(Micro/Lite/Pro/Premier) OpenAI GPT-5.1/GPT-4o/o系/Phi-4シリーズ(Microsoft独占契約) Gemini 2.5 Pro/Flash/Flash-Lite、Gemini 3.x系、Imagen、Veo なし(マルチプロバイダー特化)
Anthropic Claude Opus 4.6/4.7、Sonnet 4.5/4.6、Haiku 4.5(東京・大阪) Claude系はModel Catalog経由で一部提供 Model GardenでClaude Opus/Sonnet/Haikuを一級市民として提供 非対応(2026年6月時点)
Meta Llama Llama 3.3 70B、Llama 4系 Llama 3系 Model GardenでLlama対応 Llama 3.3/4 Maverick/Scout(大阪で提供)
Cohere Command R+ 一部提供 Model Garden経由 Command A(256Kコンテキスト)、Command A Vision/Reasoning(大阪)
xAI Grok Grok系をModel Catalog経由で提供 Grok 4系(OCI DCでホスト、大阪対応)
OpenAI gpt-oss(オープンウェイト) 2025年9月〜。ただし東京での日本国内限定提供は未確認。 gpt-5.1など最新クローズドモデルが主力 gpt-oss-120b/20b(大阪でGA、2025年12月〜)。OpenAI互換APIキーで接続可能
Mistral Large 2、Ministral 3B等 各種Mistralモデル Model Garden経由 一部提供
総モデル数 15社以上のプロバイダー 11,000以上(コミュニティ含む) 200以上(Model Garden) 十数モデル(厳選型)

⚠️ 注意:Azure AI FoundryでのOpenAIモデルは「Microsoft FoundryモデルとしてAzureが販売」する形態と「パートナー・コミュニティモデル」に分かれる。最新GPT系は前者(Azure直販)、その他はModel Catalog経由。モデルのリージョン提供状況は頻繁に変わるため、本番採用前に公式ドキュメントを要確認。

3. 料金・コスト構造

代表的なモデルの料金(2026年6月時点、オンデマンド、100万トークンあたりUSD)を比較する。なお料金は頻繁に変動するため、本番採用前は各社公式ページで最新値を必ず確認すること。

モデル 入力($) 出力($) 経由サービス 備考
Claude Sonnet 4.5/4.6 $3.00 $15.00 Bedrock / Vertex AI 200K超は2倍料金。JP Geo使用時は+10%(Bedrock)
Claude Opus 4.6/4.7 $5.00 $25.00 Bedrock JP Geo(日本国内限定)は未対応。グローバルCRISのみ
Claude Haiku 4.5 $1.00 $5.00 Bedrock / Vertex AI JP Geo対応(Sonnet 4.5と同様)
Gemini 2.5 Pro $1.25(200K以下)/ $2.50(200K超) $10.00(200K以下)/ $15.00(200K超) Vertex AI 推論トークンも出力として課金される点に注意
Gemini 2.5 Flash $0.30 $2.50 Vertex AI / Gemini API
Gemini 2.5 Flash-Lite $0.10 $0.40 Vertex AI / Gemini API 主要モデルで最安値クラス
Gemini 3.5 Flash(新) $1.50 $9.00 Vertex AI / Gemini API 2026年5月19日リリース。コーディング・エージェント性能改善
GPT-4o $2.50 $10.00 Azure AI Foundry Global Standard料金。Data Zone/Standardは異なる場合あり
GPT-4.1 $2.00 $8.00 Azure AI Foundry 1Mトークンコンテキスト。GPT-4oより若干安価
Amazon Nova Pro $0.80 $3.20 Bedrock AWS自社モデル。マルチモーダル対応
Amazon Nova Micro $0.035 $0.14 Bedrock 全主要プロバイダー中最安値クラス
Llama 3.3 70B(Bedrock) $0.72 $0.72 Bedrock 入出力均一料金
OCI gpt-oss-120b 約$0.15 OCI Generative AI(大阪) ※二次情報。公式価格ページで要確認
OCI Cohere Command(旧世代) 文字課金(1文字=1トランザクション) OCI Generative AI 新モデルはトークン課金に移行中

💡 コスト最適化のポイント:バッチ推論は各社50%割引。プロンプトキャッシュはBedrock/Vertexで最大90%削減。OCI gpt-ossは大阪リージョンでOpenAI互換APIキーを使えば、ベースURLを変えるだけでアクセス可能(2026年1月〜)。プロビジョンドスループット(Bedrock)・PTU(Azure)は月150〜200Mトークン超で損益分岐となる場合が多い。

4. 日本リージョン・主権AI対応

日本の金融・公共・製造業では「データを国内処理する」要件が重要だ。各社の対応状況を詳細に確認する。

項目 Amazon Bedrock Azure AI Foundry Google Vertex AI OCI Generative AI
日本リージョン 東京(ap-northeast-1)/ 大阪(ap-northeast-3) 東日本(Japan East) 東京・大阪リージョンあり 大阪(Japan Central)のみ。東京はGenerative AI未提供
日本国内推論完結 JP Geo CRIS対応(Claude Sonnet 4.5・Haiku 4.5のみ)。東京↔大阪のみでルーティング。Opus系は国内限定未対応 Japan Data Zoneなし。最新モデルはGlobal Standard(全世界ルーティング)またはData Zone(EU/US)経由が多い 「ML Processing in Japan」を訴求。Gemini世代によって日本リージョン未対応のケースあり(要確認) 大阪でOCIホストモデル(gpt-oss/Llama/Grok/Cohere)は国内完結。ただし大阪のGemini 2.5 Pro/Flashは外部呼び出し(Google Asia Pacific経由)で国内完結ではない
ISMAP登録 ✅ 登録済み(2021年3月〜、更新継続) ✅ Azure OpenAI Service ISMAP登録済み(2024年2月) ✅ Vertex AI ISMAP登録済み ✅ OCI ISMAP登録済み(2021年6月)
ガバメントクラウド ✅ 採択済み(令和4年度〜) ✅ 採択済み(令和4年度〜) ✅ 採択済み(令和4年度〜) ✅ 採択済み(令和4年度〜)
主権AI・ソブリンクラウド JP Geo CRISがデータレジデンシー要件に対応。SCP/IAMで国内強制可能 日本向けソブリン構成は非公式。Azure Sovereignは特定国向け 国内処理完結を訴求するが、モデル世代ごとに要確認 ZDR(ゼロデータ保持)エンドポイント、専用AIクラスタ、富士通・NTTデータとのOracle Alloyソブリンクラウドで差別化
日本向け投資 2027年までに2.26兆円を東京・大阪インフラに投資予定(2024年1月発表) 日本でのデータセンター拡張継続中 東京・大阪リージョン継続強化 富士通・NTTデータ・NRI・SoftBank・NS SolutionsとOracle Alloy展開中

⚠️ ファクトチェック重要注意:BedrockのJP Geo(日本国内クロスリージョン推論)はClaude Sonnet 4.5・Haiku 4.5のみ対応(2026年6月時点)。Claude Opus 4.7は東京リージョンで利用可能だが、JP Geo(日本国内限定ルーティング)は未対応で、グローバルCRISまたはシングルリージョン利用となる。また、OCI大阪でのGemini 2.5 Pro/Flashは推論がGoogleのAsia Pacific設備で処理されるため、日本国内完結とはならない点に注意が必要。

5. RAG・エージェント機能

単なるLLM呼び出しを超えた「RAG構築」「エージェント」「ワークフロー自動化」機能が各社の差別化点になっている。

機能カテゴリ Amazon Bedrock Azure AI Foundry Google Vertex AI OCI Generative AI
RAG・ナレッジベース Knowledge Bases(Managed/Self-managed)。S3 Vectorsでベクトルストアコスト最大90%削減 Foundry IQ(SharePoint/Fabric/Bing grounding)、Azure AI Search統合 RAG Engine(GA)、Vertex AI Search(現Agent Search)、Vector Search ベクトル検索、NL2SQL(SQL Search)、OCI Responses APIのFile Search
エージェント機能 Bedrock AgentCore(Runtime/Gateway/Memory/Identity/Browser/Code Interpreter)、Bedrock Flows Foundry Agent Service、Microsoft Agent Framework(2025年12月〜) Agent Builder(ADK+Agent Engine)、100以上のコネクタ OCI Generative AI Agents(大阪:2025年4月〜)、ホスト型エージェント
MCP対応 ✅ AgentCore Gateway経由でMCP対応 ✅ 1,400以上のMCP対応ツール、Toolbox(MCP互換エンドポイント) ✅ MCP対応(A2Aプロトコルも提唱・Linux Foundationへ寄贈) ✅ OCI Responses APIのMCP Calling対応
マルチエージェント・A2A ✅ A2A対応、LangChain/CrewAI/LlamaIndex/Strands統合 ✅ A2A対応、Entra Agent ID(エージェントID管理) ✅ A2Aプロトコル(Googleが提唱) マルチエージェント構成可能だがA2A対応は限定的(要確認)
OpenAI互換API —(独自SDK/API) ✅ Azure OpenAI Service互換 —(独自SDK) OCI Generative AI APIキー(2026年1月〜)でOpenAI互換、ベースURL変更だけで移行可能

6. セキュリティ・コンプライアンス

項目 Amazon Bedrock Azure AI Foundry Google Vertex AI OCI Generative AI
認証・認可 IAM、PrivateLink(VPCエンドポイント) Entra ID/RBAC、Private Networking(BYO VNet) IAM、VPC Service Controls IAM、専用AIクラスタ(テナンシー専有GPU)
プロンプト保護・ガードレール Bedrock Guardrails(コンテンツフィルタ・PII・プロンプトインジェクション対策・Automated Reasoning checks) Content Safety、Azure AI Guardrails(XPIA対策含む)、Purview連携 Model Armor(プロンプトインジェクション対策)、Content filters OCI Guardrails、ZDRエンドポイント
主要認証 SOC2、ISO 27001/27017/27018、HIPAA、GDPR、CSA STAR Level 2、FedRAMP High(GovCloud) SOC2、ISO、HIPAA、HITRUST、FedRAMP High SOC2、ISO 27001、HIPAA、FedRAMP High(2025年3月取得) SOC2、ISO、PCI DSS、FISC安全対策基準、3省ガイドライン、政府統一基準、FedRAMP
ISMAP ✅(157サービス、東京・大阪含む) ✅(Azure OpenAI Service) ✅(2021年6月〜)
学習データ利用 デフォルトでモデル学習に使用しない デフォルトでモデル学習に使用しない 有償API利用時はモデル改善に使用しない ZDRエンドポイント利用でデータ保持ゼロ

💡 ISMAP生成AIの重要動向(2026年1月):ISMAPポータルが「生成AIサービスに関する留意点」を公表。Bedrock・Vertex AI・Azure OpenAI等の開発基盤がISMAP登録対象範囲に含まれていれば、その上で動く個々のLLMモデル(Claudeなど)は個別のISMAP登録が不要と整理された。政府機関が生成AIを調達しやすくなった点で、エンタープライズ向けに大きな意味を持つ。

7. 市場シェア・普及状況

クラウドインフラ市場(IaaS+PaaS)のシェアは、Synergy Research Group 2025年Q3時点でAWS 29%、Microsoft Azure 20%、Google Cloud 13%(上位3社で約62%)。生成AI市場の成長率はGartner予測で2025年に+76.4%(支出$644B)に達するとされる。エンタープライズAI推論プラットフォームは「Bedrock(モデル幅)」「Azure(OpenAI深度+Microsoft統合)」「Vertex(ML/MLOps+BigQuery)」の三つ巴で、OCIはOracle DB統合・コスト・主権AIで独自ポジションを確立している。

日本国内では、ソニーグループがBedrock AgentCoreで全社Agenticプラットフォームを構築、ベネッセ・パナソニックコネクト・宮崎銀行等がAzure OpenAIを採用、みずほ銀行はOracle Autonomous AI Databaseを共通データベース基盤に採用するなど、各社に有力な採用事例がある。

8. 選定推奨:どのサービスを選ぶべきか

こんな要件なら 推奨サービス 理由
AWS中心の企業 + 日本国内データ完結必須(金融・公共) Amazon Bedrock JP Geo CRIS(Claude Sonnet 4.5/Haiku 4.5)でデータが東京↔大阪のみ。IAM/SCPでリージョン強制可能
Microsoft 365/Azure中心 + OpenAI最新モデルを優先利用 Azure AI Foundry GPT-5.1等の最速アクセス。ただしJapan Data Zoneなし。データレジデンシー要件がある場合は処理ロケーションを事前検証すること
Google Cloud/BigQuery中心 + MLOps・データパイプライン重視 Vertex AI FedRAMP High取得済み(2025年3月)、BigQuery・Workbench・Data Catalogとのシームレスな統合。Gemini日本リージョン対応状況は世代ごとに要確認
Oracle DB資産活用 + OSS系モデルを大阪で完結 + コスト最優先 OCI Generative AI gpt-oss/Llama/Grokを大阪でホスト、ZDRエンドポイント、OpenAI互換APIキーで移行容易。Gemini系はGoogle外部呼び出しのため国内完結要件には不適
ソブリンAI・日本専用クラウド要件(Oracle Alloy) OCI Generative AI + Oracle Alloy 富士通Alloy(NRI/Fujitsu/NTT Data/SoftBank/NS Solutions)でソブリン要件を満たしたAI推論が可能

まとめ

4サービスはいずれもISMAP登録・ガバメントクラウド採択済みで「政府・金融が使えない」サービスはない。選定の実質的な差は次の3点に集約される。

① 使いたいモデル:GPT-5.x系を最速で使いたい → Azure AI Foundry一択。Claude・LlamaをAWSエコシステムで使いたい → Bedrock。Gemini自社モデルを使いたい → Vertex AI。gpt-ossを大阪でOSSとして使いたい → OCI。

② データレジデンシー要件の厳しさ:「推論処理も日本国内のみ」という最厳格要件 → BedrockのJP Geo CRISかOCI大阪(OCIホストモデル限定)。AzureとVertexはリージョン内処理を保証しにくいケースがある。

③ 既存クラウド資産:多くの企業にとって「今使っているクラウドのAI推論サービス」が最初の選択肢になることが多い。マルチクラウド戦略では、モデルごとに使い分ける「ベストモデル選択」アプローチも現実的だ。

※本記事は2026年6月時点の公式ドキュメント・二次情報に基づく。モデルラインナップ・料金・リージョン対応は週次で変動するため、本番採用前に各社公式ページで最新情報を必ず確認すること。OCI Generative AIの一部料金は動的読み込みのため二次情報に依拠している箇所があり要確認。

木曜日, 6月 18, 2026

ソブリンクラウドとOracle Alloy 徹底解説 ― 日本の「データ主権」競争で何が起きているか

地政学リスク・経済安全保障・生成AIの台頭を背景に、企業・官公庁の「データ主権」意識が急速に高まっている。その中核を担う概念がソブリンクラウドだ。日本ではNRI・富士通・NTTデータ・ソフトバンク・日鉄ソリューションズの5社がOracle Alloyを採用し、国内ソブリンクラウド市場の事実上の基盤になりつつある。本記事ではソブリンクラウドの本質からグローバル動向、Oracle Alloyの仕組み、日本国内の各サービス比較、そして「Alloyは本当にソブリンクラウドか」という本質的な問いまで徹底解説する。

1. ソブリンクラウドとは何か

1-1. 定義:主権は多層構造

ソブリン(Sovereign)は「主権・独立性」を意味する。ソブリンクラウドとは、特定の国・地域の法律・規制に準拠し、データ主権を確保することを目的としたクラウドサービスの総称だ。重要なのは、これが新技術ではなく「概念・運用形態」であることである。

国際的に統一定義は存在せず、各社が必要に応じて以下の主権概念を組み合わせて定義している:

主権の種類 内容 関連リスク
データ主権 データの所在地を制御し、外部への強制開示・越境リスクを排除する 米CLOUD Act、GDPR違反
運用主権 クラウドの管理・運用を国内で完結し、運用担当者を自国民・自国居住者に限定する 外国人スタッフによる不正アクセス
法的主権 自国の法律・規制のみが適用され、外国法(米CLOUD Act等)の域外適用を排除する 米国政府による令状・召喚
セキュリティ主権 セキュリティポリシーを自社で策定・運用し、外部監査を受け入れる ベンダー側の構成ミス・バックドア
技術(テクノロジー)主権 基幹技術・供給部品の選定を自社で行い、特定ベンダー製品に依存しない ベンダーロックイン、サービス停止リスク

この5つの主権すべてを満たすことを「完全なソブリンクラウド」と呼ぶ場合もあるが、実際には各組織の要件・予算・運用能力に応じて、どの主権をどの程度確保するかをトレードオフで決める。後述するOracle Alloyは「技術主権を除く4主権」を実現できる「準ソブリン」に位置する。

1-2. 通常クラウドとの違い

パブリッククラウドは利便性・最新機能・グローバルスケールで優れる反面、データの所在や適用法が不透明になりがちだ。プライベートクラウドは専用環境を確保できるが、基盤技術・運用ツールを海外ベンダーに依存するケースも多い。ソブリンクラウドは「どの国・地域をターゲットとし、どの法制度に準拠するか」をあらかじめ明示して設計・認定を受ける点が決定的に異なる。

またガバメントクラウド(行政クラウド)とソブリンクラウドは別概念だ。ガバメントクラウドは政府・自治体の業務効率化が主眼であるのに対し、ソブリンクラウドは「主権確保」が主眼。日本のガバメントクラウドにはAWS・Google Cloud・Azure・OCI・さくらのクラウドが選定されているが、これ自体は「ソブリン認定」ではない。

2. なぜ今、ソブリンクラウドか ― 規制・地政学・AIの三重圧力

2-1. 地政学リスクが現実化した瞬間

ソブリンクラウドが絵に描いた餅でないことを証明した出来事がある。2022年3月、ロシアのウクライナ侵攻から約3時間後、Oracleは全ロシア事業の停止を一方的に発表した。現地利用者のクラウド可用性が一夜にして失われた。米国企業のクラウドサービスは、地政学的判断で停止しうるという事実が明白になったのだ。これは「ロシアだから起きた」のではなく、外国企業に依存するすべての国・企業にとってのリスクである。

2-2. 規制強化:EU・日本の動向

規制・法令 地域 重要時期 ソブリンクラウドへの影響
GDPR EU 2018年適用 EU市民データのEU域外移転制限、違反時制裁金最大全世界売上4%
DORA(デジタル運用強靭性法) EU 2025年1月17日全面適用 金融機関にICT第三者リスク管理・出口戦略の厳格化を義務付け
EU AI Act EU 2026年8月本格適用 高リスクAIシステムの透明性・説明責任を要求。学習データの所在管理が焦点
米CLOUD Act 米国 2018年制定 米国企業は、サーバーが海外にあっても令状に応じてデータを米当局に提供する義務。外資クラウド利用の最大リスク
経済安全保障推進法 日本 2022年制定 クラウドプログラムを特定重要物資に指定。電力・金融・運輸等15分野の基幹インフラ事業者に主権要件対応を促進
FISC安全対策基準 第13版 日本 2025年3月公表 経済安保・オペレーショナルレジリエンス対応、AI利用安全対策を新設。第12版から全体の約3割を改訂

CLOUD Act問題の深刻さを象徴するのが、2025年6月の仏上院調査委員会における証言だ。Microsoft France公共・法務担当のAnton Carniaux氏が宣誓下で、「仏市民データが米政府の命令により仏当局の明示的同意なく移転されないことを保証できるか」との問いに「Non, je ne peux pas le garantir(いいえ、保証できない)」と明言した。外資系クラウドが「法的主権」を完全に保証できないことが公式に認定された瞬間だ。

2-3. 生成AIが「ソブリンAI」需要を生む

生成AIの急速な普及は、ソブリンクラウド需要をさらに加速させている。LLMの学習・ファインチューニングには企業の機密データが利用される可能性があり、「学習データを国内の法制度下でのみ扱う」というソブリンAIの需要が急増している。NRIのNVIDIA H100搭載Alloy環境、ソフトバンクの国産LLM「Sarashina」搭載ソブリンクラウドは、まさにこの需要を取り込む動きだ。

3. グローバルのソブリンクラウド動向

ハイパースケーラー4社はいずれもソブリンクラウド戦略を本格化させている。特に欧州市場は、規制の厳格さから最も競争が激しい。

プロバイダー ソブリンサービス名 主要ポイント 状況(2026年時点)
AWS AWS European Sovereign Cloud 78億ユーロを投資。EU市民経営の新法人をドイツに設立。Stéphane Israël(元Arianespace CEO)がMD就任。Nitro Systemで物理的分離 2026年1月14日GA(独ブランデンブルク州)。約90サービスで提供開始
Microsoft Bleu(仏)、Delos Cloud(独) Bleu:Capgemini+OrangeがMS技術でcloud de confianceを提供。Delos:SAP子会社が独公共向けに運用 Bleuは2024年1月商用活動開始、SecNumCloud取得を目標
Google Cloud S3NS(仏)、T-Systems(独) S3NS:Thalesとの合弁PREMI3NSがSecNumCloud 3.2を2025年12月17日取得。独ではThales/T-Systemsと提携。2025年11月ミュンヘンにSovereign Cloud Hubを開設 稼働中(欧州主要国)
Oracle EU Sovereign Cloud、Alloy EU専用パブリッククラウドは独フランクフルト・スペインマドリードの2拠点、7つのEU法人、130超の運用チーム・EU居住者1,500名超が担当。Alloyは分散クラウド戦略 EU Sovereign Cloudは2023年7月GA。日本Alloyは5社(NRI・富士通・NTTデータ・ソフトバンク・日鉄ソリューションズ)が提供中または提供予定

⚠️ 重要な限界:前述の仏上院証言が示す通り、米系プロバイダーがどれほど技術的・組織的分離を謳っても、CLOUD Act・FISA 702に基づく法的強制に応じる可能性を完全否定できない。「ソブリン」を名乗るサービスの法的独立性は、常に精査が必要だ。

欧州クラウド市場の現実は厳しい。Synergy Research Groupの調査によれば、米系3社(Amazon・Microsoft・Google)が欧州クラウド市場の約70%を占め、欧州地場プロバイダーの合計シェアは15%にとどまる(2017年の29%から半減)。欧州独自の技術主権確保がいかに困難かを物語っている。

アジア太平洋では、タイのAIS(モバイル加入者4,500万超)がOracle Alloyを採用し「AIS Cloud」を構築(2024年8月発表、2025年第1四半期提供開始)。2030年まで最大80億バーツを投資し、タイ初の地場所有・運用ハイパースケールクラウドを実現している。主権クラウドの新興市場での展開が加速している。

4. Oracle Alloyとは何か ― クラウドの民主化

4-1. Oracle Alloyの定義と仕組み

Oracle Alloyは2022年10月18日のOracle CloudWorld(ラスベガス)で発表された、「パートナー企業がOCIの技術を使って自らクラウド事業者になれる」完全なクラウドインフラプラットフォームだ。

従来のクラウド提供モデルとの最大の違いは、「パートナー自身がクラウドベンダーになる」点にある。パートナーのデータセンターにOCI同等のインフラ(ハードウェア+ソフトウェアが事前統合された「クラウド・イン・ア・ボックス」)を展開し、200以上のOCIサービスを自社ブランドで提供できる。

パートナーが独自に管理できる要素:

  • ブランド・価格設定・課金(Oracle Fusion基盤)
  • SLA・サポート・顧客ライフサイクル管理
  • 独自サービスや独自ハードウェア(メインフレーム等)の追加
  • アクセスを許可するユーザー・国籍・所在地の制限

Oracleは、重大な技術問題が発生した場合のエスカレーション対応とプラットフォーム更新のみを担う。

4-2. 競合の「箱」との根本的な違い

サービス 提供モデル データ完全分離 パートナーの自律性
Oracle Alloy パートナーが自社DCでフルスタックをホスト、パートナー自身がクラウド事業者化 ✅ 国外にデータが出ない設計 ✅ 高(価格・SLA・ブランドを自社管理)
AWS Outposts AWSが顧客DCに機材を設置・運用、AWSの一部 ⚠️ コントロールプレーン・バックアップがAWSパブリッドに流れる設計 ❌ 低(AWS主導)
Azure Stack Hub Microsoftの技術を顧客DCで展開 ⚠️ 切り離し設定に高コストが必要 △ 中程度
Google Distributed Cloud エアギャップ構成が可能な分散クラウド ✅(エアギャップ版) △ サービス範囲が限定的

Oracle Alloyが競合と根本的に異なるのは発想の転換にある。AWS Outpostsが「AWSの出張所を顧客DCに置く」モデルであるのに対し、Alloyは「パートナー自身がAWSになる」モデルだ。パートナーは単なる再販業者ではなく、フルスタックのクラウド事業者として顧客と直接向き合う。

技術面ではベアメタル中心でハイパーバイザーのオーバーヘッドがなく、Oracle Databaseを含むSaaS全スタックが利用可能な点が強みだ。一方、ハイパーバイザー非採用のため、他社との比較でリソース動的分配の柔軟性に劣る場面もある。

5. 日本のOracle Alloy 5社を徹底比較

日本ではNRI・富士通・NTTデータ・ソフトバンク・日鉄ソリューションズ(NSSOL)の5社がOracle Alloyを採用し、それぞれ異なる強みとターゲット市場で競争している。2026年は日本オラクル社長の三澤智光氏が「ソブリンクラウドが本格的に普及する元年」と宣言したとおり、採用パートナーの拡大が続いている。

5-1. NRI(野村総合研究所)― 金融SaaS基盤の先駆者

NRIはOracle Alloyの文脈で日本最重要プレイヤーだ。世界で初めてOCI Dedicated Regionを採用(2020年)し、国内でも最初にAlloyを稼働させた実績を持つ。

  • 拠点:東京(2024年2月稼働)・大阪(2024年12月稼働)の自社DC、DR構成
  • サービス:「NRIクラウド OCI区画」(2024年4月提供開始)。atlaxマネージドサービスと組み合わせ
  • 金融SaaS実績:BESTWAY(2021年7月)、T-STAR(2022年4月)、THE STAR(2023年4月)をAlloy環境へ移行
  • AI:2024年12月よりNVIDIA H100搭載GPU提供。2025年2月に「NRIデジタルトラスト(仮称)」「NRI金融AIプラットフォーム(仮称)」を発表。金融特化型LLMはNRI・日本オラクル・カナダCohereの協業
  • 差別化:証券・銀行・保険向けSaaS基盤の運用実績と金融規制対応(FISC等)の深い知見

5-2. 富士通 ― ミッションクリティカルとUvance連携

富士通は2025年4月14日に「Fujitsu クラウドサービス powered by Oracle Alloy」の提供を東日本から開始した(西日本リージョンも順次提供予定)。

  • サービス内容:OCIの150以上のサービス+日本のソブリン要件向け106機能を実装。2024年4月の協業発表以降、200社超の問い合わせ。3年で100社導入目標
  • ソブリン体制:日本国籍・日本居住者のみによるサポート体制。富士通は「運用・データ・法的・セキュリティの4主権」を確保するソブリンクラウドと位置づけている(執行役員専務 古賀一司氏)
  • コンプライアンス対応:経済安全保障推進法の15基幹産業に対応。PwC Japanと共同で特定社会基盤役務制度対応のリファレンスガイドを2025年12月に公表
  • 差別化:Uvance(マルチクラウド一元運用)との統合、グローバルSI実績、金融・製造・公共向けのミッションクリティカルシステムへの深い知見

5-3. NTTデータ ― 公共・金融の大規模実績

NTTデータは2024年10月23日にOracleと協業を発表し、「OpenCanvas Type-Oracle Alloy」を2025年12月18日に正式提供開始した。

  • 拠点:東日本は2025年12月末から稼働。西日本は2027年3月末までに提供開始予定(Oracle公式・NTTデータ公式の正式発表。なお2026年3月のOracleウェビナー資料では「2026年末」と記載されており、前倒しの可能性もある)
  • 採用顧客:発表時からNTT東日本・NTT西日本がエンドースメント。金融・通信・公共・公益向けに展開
  • 事業目標:OpenCanvas全体(非Alloy部分含む)で2030年までに1,000億円の売上目標
  • 将来展望:IOWNおよびNTT版LLM「tsuzumi」との連携も検討中
  • 差別化:NTTグループの通信インフラ・データセンター網と高セキュリティクラウドの組み合わせ。公共・大規模金融システムの豊富な実績

5-4. ソフトバンク ― GPU・生成AI基盤に特化

ソフトバンクは2025年10月8日にOracleとの協業を発表。「Cloud PF Type A」を東日本2026年4月・西日本2026年10月から提供している。

  • サービス特徴:OCIの200以上のサービス。Oracle KMS(OCI Vault)+独自KMSの多層鍵管理。SLA稼働率99.9%以上
  • GPU:NVIDIA HGX B200搭載のベアメタルサーバー(サーバー1台から専有)を2026年6月1日提供開始
  • AI:SB Intuitions開発の国産LLM「Sarashina」を搭載した生成AIサービスを2026年6月から順次提供
  • 採用事例:システナがノーコード基盤「Canbus.」で採用(2026年4月)
  • 差別化:国内通信事業者の強みを活かした閉域網(OnePort、SmartVPN)接続オプション、GPU・生成AI基盤としての尖った特化

5-5. 日鉄ソリューションズ(NSSOL)― 製鉄・製造・九州に強い重厚長大SIer

日鉄ソリューションズは2026年1月30日にOracleとの協業を発表した国内5社目のAlloyパートナー。マネージド型IaaS「absonne(アブソンヌ)」をAlloyで刷新し、2026年度下期に次期サービスを提供開始予定だ。

  • 拠点:東京+九州(日鉄ゆかりの地)の2拠点。地理的分散でBCP対応。九州展開ではQsol・QTnet(九電グループ)と2026年4月15日に3社協業を開始
  • サービス内容:OCIの200以上のサービス(Oracle AI Database・OCI AI Agent Platform等含む)。NSSOLの運用サービス「emerald」・サイバー攻撃対策「NSSIRIUS」・コンサルティング「xSource」をAlloy環境に最適化してオプション提供
  • Oracleとの関係:30年超のパートナーシップ。Oracle Kudos for Support Qualityを2年連続取得(2025年)、Oracle Partner Awards「Japan Technology/Cloud Service Partner Customer Success Award」受賞(2025年)
  • 差別化:製鉄・電力・製造分野の大規模ミッションクリティカルシステムの運用実績(18年)。九州という地方都市での展開は「首都圏・関西圏以外でのソブリンクラウド」という新市場を開拓
  • ターゲット:製造・電力・公共・自治体。特に九州地域の半導体・製造業集積(TSMC熊本工場周辺)向けの需要を狙う

5-6. 5社 比較サマリー(先行4社)

項目 NRI 富士通 NTTデータ ソフトバンク
Alloy稼働開始 2024年4月(東京) 2025年4月(東日本) 2025年12月(東日本) 2026年4月(東日本)
強みの業界 金融(証券・銀行・保険) 製造・金融・公共 公共・通信・金融 通信・小売・生成AI
GPU・AI H100(2024年12月〜) OCIベースのGPU tsuzumi連携検討中 B200ベアメタル(2026年6月〜)+Sarashina
LLM提携 Cohere(金融特化) マルチベンダー tsuzumi(NTT) Sarashina(SB Intuitions)
経済安保対応 △(検討中) ✅(PwCと共同ガイド)
2拠点DR ✅(東京・大阪) ✅(東日本・西日本) ✅(東・西、2027年3月末まで完成予定) ✅(東・西、2026年10月)

※ 上記は先行4社。日鉄ソリューションズ(NSSOL)は2026年度下期に提供開始予定。東京・九州の2拠点、製造・電力・公共向け特化。

6. AlloyはソブリンクラウドたりうるかのWill分析

6-1. 主権適合度の精査

富士通は「ソブリンクラウドに必要と考える4つの主権(運用主権・データ主権・法的主権・セキュリティ主権)をAlloyで実現できる」と公式に主張している(執行役員専務 古賀一司氏)。一方、「技術(テクノロジー)主権」―特定ベンダー製品に依存しないこと―については、OCI技術に依存するAlloyでは実現できないと認めている。これはAlloyが「準ソブリン」であることを当事者自身が認めた重要な証言だ。

主権の種類 Alloyの達成度 評価根拠
データ主権 ✅ 達成可能 パートナーDC内にデータが留まり、国外転送が設計上発生しない
運用主権 ✅ 達成可能 パートナーが日本国籍・日本居住者のみで運用管理チームを構成できる
法的主権 △ 部分的 パートナーは日本法人だが、基盤はOracle(米国企業)の技術。米CLOUD Actリスクを完全排除できるか否かは法的解釈次第
セキュリティ主権 ✅ 達成可能 パートナーが独自セキュリティポリシーを策定・適用できる。各社ISO27001・ISO27017取得
技術主権 ❌ 達成困難 基盤はOCI(米Oracle技術)に完全依存。富士通自身も「技術主権はAlloyでは実現できない」と認めている

6-2. ISMAP・ガバメントクラウドの壁

標準のOCIはISMAP登録済み(2021年6月)かつガバメントクラウドに選定されているが、Alloy版(NRI・富士通・NTTデータ・ソフトバンク・日鉄ソリューションズが提供するサービス)としてのISMAP登録・ガバメントクラウド認定は2026年6月時点で確認されていない。各社は経済安全保障推進法対応を前面に出すが、ISMAP登録が政府調達の前提条件となる場面では、現状Alloy版は対象外となりうる。

Alloy版のISMAP登録は別途監査・登録プロセスが必要で、今後の重要注視ポイントだ。

6-3. AlloyのリスクとロックインへのRAR

Alloy最大の構造的リスクはOracleへのライセンス・技術依存だ。

  • ライセンス紛争リスク:OracleのソフトウェアライセンスはBroadcomによるVMware買収と同様の急激な価格改定が起きうる。Dedicated Region同様のコミットメントモデルには長期拘束が伴う
  • 出口条項(Exit Clause):契約段階で乗り換え条項を明文化しないと、契約終了時に長期コミットへ転換するリスクがある
  • ベンダーロックイン:200以上のOCIサービスへの依存度が高まるほど、他クラウドへの移行コストは増大する

契約上の必須チェックポイント:①コミット期間と解約違約金の上限、②Oracleライセンス価格改定への対応条項、③サービス終了時のデータポータビリティ保証、④ISMAP登録・認証取得に失敗した場合の解約権。

7. Alloy以外の国産ソブリンクラウド全マップ

Alloy系が注目を集める一方、日本には独自のソブリンクラウド基盤が複数存在する。これらをアーキテクチャ別に整理する。

7-1. さくらのクラウド ― 国産唯一のガバメントクラウド認定

国産ソブリンクラウドの象徴的存在がさくらインターネット(さくらのクラウド)だ。

  • ガバメントクラウド正式認定:2026年3月27日、デジタル庁が305項目の全技術要件充足を確認し正式認定(国産唯一)。令和5年度の条件付き採択から正式採択へ格上げされ、複数年度採択も国産初
  • インフラ:石狩データセンター中心(2025年9月に石狩第3ゾーン開設)。すべての施設・運用が国内完結
  • 料金:時間・日・月の最安が自動適用されるサブスク型。円建て(為替影響なし)。通常利用の転送量は実質無料
  • GPU:高火力GPUクラウド(NVIDIA H100専有プラン)を2026年1月開始。東大開発の医療特化LLMを2026年3月から研究者へ無償提供
  • ソブリン特性:技術スタック・ハードウェア・運用要員・データセンターがすべて国内完結。「技術主権」を含む5主権すべてに対応可能な国内唯一の大規模パブリッククラウド

7-2. 富士通 FJcloud-V / FJcloud-O ― 国産VMware・OpenStack

  • FJcloud-V(旧ニフクラ):VMware vSphere基盤の国産パブリッククラウド。7,000社超の実績。オンプレからのリフト&シフトが容易。ISMAP登録済み(ISO27001・ISO27017取得)
  • FJcloud-O:Red Hat OpenStack基盤でベンダーロックイン回避を志向。FJcloud-OとFJcloudベアメタルが2021年3月12日にISMAP初回登録
  • Broadcom買収への対応:Broadcomが2023年にVMwareを買収し、VCPPからVCSPへのライセンス移行で価格改定リスクが生じたが、富士通は2025年8月にVCSP認定パートナー継続を発表。既存顧客は継続利用可能
  • 位置づけ:Alloyが「4主権のソブリンクラウド」ならFJcloud系は「5主権すべてに対応」(技術主権を含む)の位置づけ。ただし機能・サービス数ではAlloy(OCI同等200+)に劣る

7-3. NEC Cloud IaaS ― 公共・製造向け純国産

  • ISMAP登録:2021年3月12日(ISMAP初回登録組)
  • SLA:サーバー稼働率99.99%保証、金融機関安全対策基準対応の建物・設備
  • ソブリン戦略:「包括的主権確保」(国内完結)と「部分的主権確保」(既存クラウド+NECセキュリティ機能)の両モデルを提供する方針を公表

7-4. 日立製作所 ― VMware Sovereign Cloud+Lumada

  • 認定:エンタープライズクラウドサービスG2が日本国内初のVMware Sovereign Cloud Initiative参画
  • ISMAP登録:2021年6月。ISO/IEC27001・27017取得
  • 特徴:国内DC保管・日立スタッフによる管理でデータ主権・管轄権を確保。Lumadaによるデータ利活用と組み合わせた重要インフラ向けソリューションが強み

7-5. IIJ(インターネットイニシアティブ)

  • ISMAP登録:IIJ GIO インフラストラクチャーP2が2021年12月20日に登録。その後クラウドネットワーク(2024年4月)、Cloud Proxy+Managed WAF(2025年7月)、IIJ IDサービス+政府向けSecure Web Gateway(2026年1月)と範囲を継続拡充
  • 特徴:通信事業者の強みを活かしたネットワーク統合型ソブリン環境。政府クラウド獲得を視野にISMAP対応を強化中

7-6. KDDI ― Google Cloud×ソブリン鍵管理

  • サービス:「KDDI暗号鍵管理サービス for Google Cloud」を2025年7月30日提供開始
  • 仕組み:Google Cloud Assured Workloads(データ所在地を国内限定)+KDDIによる暗号鍵代行管理を組み合わせ、クラウド事業者と鍵管理組織を分離するソブリン設計
  • 特徴:完全な国産クラウドではなくパブリッククラウド+日本の鍵管理という「ハイブリッドソブリン」モデル

7-7. 国産ソブリンクラウド全体マップ

事業者 サービス アーキテクチャ ISMAP状況 主な対象業界
さくらのクラウド さくらのクラウド フル国産 ✅ 登録済み・ガバクラ正式認定 政府・自治体・研究機関・中堅企業
富士通 FJcloud-O / FJcloud-V OpenStack/VMware系 ✅ 登録済み 金融・公共・製造・グローバル企業
富士通(Alloy) Fujitsu powered by Oracle Alloy OCI Alloy系 ⚠️ Alloy版は未確認 ミッションクリティカル系全般
NTTデータ OpenCanvas(非Alloy) 独自高セキュアクラウド ⚠️ 範囲確認中 公共・金融・通信
NEC NEC Cloud IaaS 独自IaaS ✅ 2021年3月登録 公共・製造・重要インフラ
日立 エンタープライズクラウドG2 VMware Sovereign Cloud ✅ 2021年6月登録 重要インフラ・製造・金融
IIJ IIJ GIO P2 独自IaaS ✅ 2021年12月登録 公共・通信・教育
KDDI 暗号鍵管理 for Google Cloud ハイブリッドソブリン ⚠️ 当サービス自体は別途 企業全般(Google Cloud利用者)

7-8. 政府主導の「計算資源主権」基盤

個別クラウドサービスの上流に位置する「インフラ層の主権」確保に向けた政府主導施策も進んでいる。

  • GENIAC(経産省/NEDO):国産基盤モデル開発向けの計算資源補助・実証・コミュニティ形成。フェーズ3(2025年7月選定)では24件を支援。Sakana AI、Preferred Networks、楽天、Mercariなどが採択。2026年は「GENIAC-PRIZE 2026」(賞金最大約6.3億円+計算資源最大約4億円)とフィジカルAIテーマを展開
  • FugakuNEXT(富岳後継機):富士通(CPU・システム)とNVIDIA(GPU)が協業開発。CPUは2nmのFUJITSU-MONAKA後継、NVIDIA NVLink FusionでGPUと高速接続。2030年頃稼働予定、富岳比で最大100倍のアプリ性能を目標
  • Rapidus(2nm半導体、北海道千歳):2022年8月設立(デンソー・キオクシア・MUFG・NEC・NTT・ソフトバンク・ソニー・トヨタの8社)。2025年7月に2nm GAAトランジスタ動作確認。2027年量産目標。半導体の国産供給能力確保という「最深層の技術主権」を担う

GENIAC(モデル開発資源)+FugakuNEXT(計算主権)+Rapidus(半導体主権)という3層構造が、Alloy系・国産クラウドというサービス層を下支えする「国家インフラ」として機能する設計だ。

8. 日本企業・官公庁のソブリンクラウド採用戦略

8-1. 政府・デジタル庁の動向

ガバメントクラウドは2026年度の対象サービスとしてAWS・Google Cloud・Microsoft Azure・OCI・さくらのクラウドの5サービスを選定している。国産はさくらのみだが、デジタル庁は選定基準を見直し、複数サービスの組み合わせによる要件充足を認める方針で、NEC・IIJ・日立など第2グループの参入可能性が高まっている。

自治体の基幹業務システムは2026年3月末を期限として標準準拠システムへの移行が求められており、ガバメントクラウドの利用システム数は急増している。

8-2. 金融業界

FISC安全対策基準第13版(2025年3月)の改訂は、金融機関のソブリンクラウド採用を加速する。改訂の核心は「経済安全保障上のリスク」の明文化と「オペレーショナル・レジリエンス」の強化で、外資クラウドへの依存が直接的な審査対象になった。NRIの金融SaaS基盤(BESTWAY・T-STAR・THE STAR)はAlloyベースのソブリン環境で稼働しており、証券・銀行向けのリファレンスモデルとなっている。

8-3. 製造業・重要インフラ

経済安全保障推進法の対象15分野(電気・ガス・石油・水道・鉄道・貨物自動車運送・外航貨物・航空・空港・電気通信・放送・郵便・金融・クレジットカード・石油コンビナート)の基幹インフラ事業者は、主権要件対応が事実上の義務となった。富士通がPwC Japanと共同作成したリファレンスガイドはこれら企業の採用判断を支援するための資料だ。

8-4. 日本のクラウド市場規模と外資依存の現実

IDC Japanの調査(2025年2月20日発表)によれば、2024年の国内パブリッククラウド市場は前年比26.1%増の4兆1,423億円、2029年には8兆8,164億円(CAGR16.3%)に達する見通しだ。この巨大市場の大半を米系3社が占め、国産クラウドは小シェアにとどまる。GENIACなどの政策支援は「技術的競争力の確保」より「国産基盤の体力づくり」にとどまるという厳しい評価もある。Alloyは「外資技術を国内で適合させる現実的な折衷案」として、国産育成政策と並走する存在だ。

9. 採用判断フレームワーク:3層分類で選べ

ソブリンクラウドの採用判断に迷ったときは、ワークロードを以下の3層に分類することから始めるべきだ。

レイヤー ワークロード特性 推奨選択肢 判断の基準
Tier 1
最高機密・技術主権必須
防衛・国家機密・最重要インフラの制御システム 純国産(さくらのクラウド、FJcloud-V/O、NEC Cloud IaaS、日立G2) 外国法域外適用で事業継続が脅かされる、またはOracleライセンス依存を許容できない
Tier 2
機密・ミッションクリティカル
金融コアシステム・顧客PII・基幹業務・特定重要インフラ Alloy系(NRI/富士通/NTTデータ/ソフトバンク/日鉄NSSOL)または純国産 データ・運用・法的・セキュリティの4主権が必要。技術主権はOracleへの依存を許容できるか否かで判断
Tier 3
一般業務
メール・グループウェア・非機密データ分析・開発環境 パブリッククラウド(AWS/Azure/GCP/OCI) 主権要件が法的に課されておらず、コスト・機能・速度を優先できる

パートナー選定の指針:

  • 金融統制・金融AI基盤 → NRI(BESTWAY等の金融SaaSの運用実績)
  • マルチクラウド一元運用・ミッションクリティカル → 富士通(Uvance連携、経済安保ガイド整備済み)
  • 公共・大規模システム・NTTグループ連携 → NTTデータ(OpenCanvas、tsuzumi連携)
  • GPU・生成AI基盤・国産LLM活用 → ソフトバンク(B200ベアメタル、Sarashina)
  • 製造・電力・九州地域・Oracle DB集約 → 日鉄ソリューションズ(absonne次期、東京・九州の2拠点)
  • ガバメントクラウド・円建て・転送量コスト削減 → さくらのクラウド(国産唯一の正式認定)

✅ Alloyを選ぶ際の契約必須チェック:①コミット期間と解約違約金の上限を明記、②Oracleライセンス価格改定への対応条項、③サービス終了時のデータポータビリティ保証、④ISMAP登録・認証取得が失敗した場合の解約権。これらを契約段階で確保しないと、ベンダーロックインのリスクが残る。

10. 2026〜2030年の展望

今後4〜5年でソブリンクラウド市場を変える可能性のある重要イベントを整理する。

時期 イベント・指標 採用判断への影響
2026年中 EU AI Act本格適用(高リスクAIシステム)、ソフトバンクB200ベアメタル本格展開、日鉄NSSol absonne次期サービス開始(2026年度下期) 生成AI基盤のソブリン要件が明確化。GPU搭載Alloyの需要が加速
2026〜2027年 Alloy版ISMAP登録の可否判明(各社が検討中と推察)、Rapidus 2nm量産開始(2027年目標) ISMAP登録実現なら公共調達でのAlloy解禁。Rapidus量産なら「真の半導体主権」への道が開く
2027〜2028年 EUCS(欧州クラウドセキュリティ認証)確定、Oracle日本への10年80億ドル超投資の中間点 EU要件が日本のISMAP見直しに波及する可能性。Oracle国内運用体制の強化でAlloy版ISMAP登録環境が整備されるか注目
2029〜2030年 FugakuNEXT稼働(2030年頃)、NTTデータOpenCanvas 1,000億円目標達成時期 国産計算資源とAlloy系サービスが両輪として日本のソブリンAIを支える構図が確立するか

ベンチマーク(判断を変える指標):

  • Alloy版がISMAP登録・ガバメントクラウド認定を取得 → 公共調達での採用判断を根本から見直す機会
  • EUCSの「主権要件」が日本のISMAP基準にフィードバック → 外資依存リスクの再評価トリガー
  • ガバメントクラウドの「複数サービス組み合わせ容認」が正式化 → NEC・IIJ・日立など第2グループの参入加速
  • 富士通MONAKAやFugakuNEXT技術がAlloy/国産クラウドに統合 → 技術主権評価の再設計

11. まとめ

📌 本記事のキーポイント

  1. ソブリンクラウドに統一定義はない。データ・運用・法的・セキュリティ・技術の5主権のうち、何をどの程度確保するかをワークロードごとに設計することが出発点
  2. CLOUD Actは「対岸の火事」ではない。2025年仏上院証言で明らかなように、外資系クラウドは法的主権の完全保証を約束できない。機密ワークロードの主権設計は必須
  3. Oracle Alloyは「準ソブリン」。4主権(データ・運用・法的・セキュリティ)は達成可能だが、技術主権はOracle依存が残る。さらにISMAP登録がAlloy版では未確認という公共調達上の制約がある
  4. 日本のAlloy 5社は役割が異なる。NRI=金融SaaS、富士通=ミッションクリティカル、NTTデータ=公共大規模、ソフトバンク=GPU/生成AI、日鉄NSSOL=製造・電力・九州地域。業界・用途で選択先が決まる
  5. さくらのクラウドは「技術主権」の孤独なフロンティア。国産唯一のガバメントクラウド正式認定(305項目全充足)。最高機密ワークロードと国家主権要件では参照点となる
  6. Alloyは完全な答えではなく、現実的な折衷案。機能の豊富さ・運用実績・パートナーの信頼性を評価しつつ、ロックインリスクへの出口戦略を契約前に確保することが経営上の必須事項

ソブリンクラウドは「流行のバズワード」ではなく、地政学リスク・規制強化・生成AIが交差する現実の課題への解答だ。2026〜2030年に向けて、Alloy系(NRI・富士通・NTTデータ・ソフトバンク・日鉄ソリューションズ)と純国産(さくら・FJcloud・NEC・日立)、そして計算資源主権(GENIAC・FugakuNEXT・Rapidus)の三層が日本のデジタル主権を形成していく。その全体構造を理解したうえで、自組織のワークロード特性に応じた「主権の設計」に取り組んでほしい。


本記事は2026年6月時点の公開情報を基に作成しています。各社サービスの詳細・価格・ISMAP登録状況は変動する場合があります。最新情報は各社公式サイトおよびISMAPポータル(ismap.go.jp)でご確認ください。