IDCFクラウド・ランサムウェア事案を整理する：ISMAP登録サービスで何が起きたか

2026年10月7日、IDCフロンティアが提供する「IDCFクラウド」の東日本リージョン1の一部がランサムウェア攻撃を受け、仮想サーバーが停止して再起動できない状態になりました。影響を受けたのは495の企業・自治体です。同社は、teslaなど4ゾーンに保管された顧客データを「取り出しや復元が困難な見通し」とし、現時点の見解として、復元は顧客自身が持つバックアップからのみ可能だと説明しています。

IDCFクラウドのコンピュートなどは、政府情報システムのためのセキュリティ評価制度「ISMAP」の登録対象です。では、登録されていれば安心なのか。運営側はこの事案をどう扱うのか。利用する側は何をすべきか。公表されている情報から整理しました。

結論を先に書きます。

• 事実として確認できるのは、ランサムウェア攻撃、4ゾーンのデータ復元困難、495の企業・自治体への影響までです。侵入経路と情報漏えいの有無は、10月9日夜の時点で公表されていません。
• ISMAPについて、運営委員会などがIDCFを名指しした措置（登録の一時停止や再監査の開始）を公表した形跡は、筆者の確認した範囲ではありません。再監査に進む可能性は十分にありますが、現時点では未決定です（筆者の推定）。
• ISMAP登録は統制の評価であり、サービスが止まらないこと、データが失われないことの保証ではありません。バックアップを事業者の外に持つこと、委託先・再委託先の利用クラウドを把握することが、利用側の現実的な備えになります。

本記事は2026年10月9日夜時点の公開情報に基づきます。IDCFの公式発表を一次情報とし、報道に基づく部分はその旨を書いています。見通しや評価は筆者の推定・見解です。続報が出た場合は内容が変わる可能性があります。

1. IDCFクラウド事案：公式発表で確認できること

公表	日付	主な内容
第1報	10月7日	第三者からの不正アクセスにより、東日本リージョン1で障害が発生。対象の顧客には個別に連絡。
第2報	10月7日	原因を「第三者からの不正アクセス（ランサムウェア攻撃）」と特定。影響は495の企業・自治体。東日本リージョン1をネットワークから遮断し、システムを停止。
第3報	10月8日	対象を4ゾーン（tesla／henry／pascal／joule）に特定。データは取り出し・復元が困難な見通しで、復元は顧客自身のバックアップからのみ、と案内。他のゾーン・リージョンは不正アクセス未確認だが、自前のバックアップ取得を案内。全リージョンの管理コンソールを停止中。
第4報	10月9日	10月7日午前9時に緊急対策本部を設置し、親会社のソフトバンクと連携して対応。顧客窓口はソフトバンクの法人部門で、バックアップ手順の案内、移行環境の提案、仮想サーバーの起動・停止の代行を実施。外部の専門企業と詳細調査を進め、監督省庁や警察などへ報告・相談している。

出典：IDCフロンティア公表（第1報／第2報／第3報／第4報）

1-1. 確認できている事実

• 発生は2026年10月7日午前3時40分ごろで、第3報の時点では継続中とされています。
• 対象は東日本リージョン1の一部（tesla／henry／pascal／jouleの4ゾーン）です。仮想サーバーの停止と再起動不可が起きています。
• 4ゾーンの顧客データは「取り出しや復元が困難な見通し」で、同社は「現時点での当社の見解」として、復元は顧客自身のバックアップからのみ可能としています。今後の調査で見解が変わる可能性はあります。
• IDCFクラウド TypeS（旧ホワイトクラウド ASPIRE）とIDCFプライベートクラウドは、本事象の対象外です。

1-2. 未公表・未確認の事項

• 侵入経路と、攻撃の詳しい影響範囲（調査中とされています）。
• 顧客データが外部に持ち出されたか（情報漏えいの有無）。公式発表では確認も否定もされていません。
• どのストレージやバックアップが暗号化・破壊されたのか。事業者側のバックアップの構成も公表されていません。したがって、本件から事業者の設計上の不備を断定することはできません。
• 495の企業・自治体の内訳（ゾーン別の数、国の機関が含まれるか）。
• SNSでは、暗号化やスナップショット破壊を主張する画像が出回っています。攻撃者側の主張とされるもので、公式発表には含まれません。真偽は未確認です。

1-3. 影響を受けた利用者の例

• シックス・アパート：Movable Typeクラウド版のサーバー31台がIDCFクラウド上では復旧できない見込みとなりました。Google Cloudに保管していたバックアップ（7世代）を使い、さくらのクラウドへ移行する方針と報じられています（ITmedia NEWS）。
• 小平市：市のホームページが停止し、委託先のクラウド基盤がランサムウェア攻撃を受けたと公表しました。問い合わせフォームなどに入力された住民情報が漏えいした「おそれ」があるとしています（セキュリティ対策Lab）。自治体が直接契約していない委託先のクラウドが影響した例です。
• 茨城県：県庁と県警のホームページが閲覧できなくなったと報じられています（時事通信）。
• ニッスイ（日水物流）：物流拠点の入出荷に影響が出たと公表しましたが、事業者名は明記していません。IDCFクラウドの影響と報じられている段階です（報道）。

2. ISMAP登録サービスとしての位置づけ

2-1. 登録範囲

IDCFが2024年1月10日に公表したリリースによると、ISMAPクラウドサービスリストへの登録範囲は次のとおりです（IDCF）。

• IDCFクラウド：コンピュート、インフィニットLB、RDB、DNS、GSLB、コンテナ
• IDCFプライベートクラウド（TypeV 2020など）と、IDCFクラウド ベアメタルサーバー（クラウドタイプ）

今回停止したのは仮想サーバー、つまりコンピュートで、登録範囲に含まれます。なお、プライベートクラウドも登録対象ですが、IDCFは今回の事象の対象外としています。また、登録は「サービス単位の統制の評価」であり、特定のリージョンやゾーンの安全性を個別に認定したものではありません。

2-2. 規程上の枠組み

ISMAP基本規程（英語参考訳。原文は日本語）には、関係する規定が次のように書かれています（ISMAP）。

• 報告（3.7）：登録事業者は、利用者に重大な影響を及ぼし得る情報セキュリティインシデントが起きた場合、ISMAP運営委員会または運用支援機関に直ちに報告する責任を負います。確認を求められたときは速やかに対応する必要があります。
• 再監査（5.2）：モニタリングの結果などを踏まえ、運営委員会は事業者に再監査を求めることができます。
• 一時停止・取消し（5.4）：モニタリングや再監査の結果、またはインシデントが起きた場合に、運営委員会は登録を一時停止または取り消すことができます。

ここで重要なのは、いずれも「できる」規定であることです。インシデントが起きただけで、登録が自動的に停止されるわけではありません。個別の運用を定めた登録規則では、第9章（インシデント報告）、第11章（モニタリング）、第12章（再監査）が再監査の手続きの根拠として引かれています（過去の事案についてのITmedia NEWS）。具体の判断は、現行規則と事実関係に基づき運営委員会が行います。

2-3. 現状（10月9日夜時点）

• ISMAP運営委員会、国家サイバー統括室、デジタル庁のいずれも、IDCFを名指しした登録の一時停止や再監査の開始を公表した形跡は、筆者が確認できた範囲ではありません。
• IDCFは「監督省庁」などへの報告・相談を進めていると述べています。ただし、その中にISMAPへの報告が含まれるかは、公開情報からは分かりません。
• 筆者の推定では、コンピュートが登録対象で、停止とデータ復元困難という影響の重さから、IDCFが報告対象に当たるインシデントと判断する可能性は高いと考えます。

2-4. 過去の再監査と今後の見通し

公開情報で確認できる、インシデント後の再監査の前例は次の2件です。

時期	対象サービス	きっかけ	経過
2022年9月〜2023年3月	ニフクラ、FJcloud-V	2022年5月、ロードバランサーの脆弱性を悪用した不正アクセスで、情報が盗まれた可能性が公表された。	約6か月の再監査の結果、運営委員会は「要求事項が適切に実施されていることが確認できた」としてリストに残留。
2023年9月28日〜	FJcloud	採用するネットワーク接続サービスのトラブル（2023年2月に、ネットワーク機器に不正なプログラムが仕込まれていたと公表）。事業者は当時、FJcloudへの影響はないと説明していた。	登録規則の第9・11・12章に基づき再監査を開始。再監査中も登録リストには掲載。終了時期は発表時点で未定。

出典：ITmedia NEWS「富士通の“政府認定クラウド”が再監査に」（2023年9月29日）

この2件は、事案の性質も被害の規模もIDCF事案とは違います。それでも、重大インシデントの後にISMAP運営委員会が再監査を行った実績があること、再監査は数か月単位で進み、その間も登録がリストに残ったことは、見通しを考える材料になります。再監査は登録の取消しとは別物です。

筆者の推定：IDCF事案が再監査に進む可能性は十分にあります。ただし、前例は2件しかなく、「可能性が高い」と確率を付けられる根拠はありません。現時点では未決定と見るのが妥当です。結論は、IDCFの報告内容、調査で分かる侵入経路、復旧と再発防止の実施状況、統制が実際に機能していたかの確認に左右されるでしょう。論点になり得るのは、管理系の分離や、バックアップを含む復旧性に関する統制の実効性です。ただし、事業者のバックアップ構成が未公表の現段階で、監査の不備を指摘できる根拠はありません。

3. 利用側（府省庁・自治体・委託先）に求められる対応

• 影響の棚卸し：自組織だけでなく、委託先や再委託先（保守業者、SaaS事業者など）がIDCFクラウドを使っていないか確認します。小平市の例のように、直接契約していない委託先経由で影響が及ぶことがあります。
• 4ゾーンの利用者：IDCFは別環境を用意しての再構築を案内しており、データは自前のバックアップから復元する前提です。
• それ以外のゾーン・リージョンの利用者：不正アクセスは確認されていませんが、管理コンソールは停止中です。IDCFが順次案内するバックアップ手順に従い、自前のバックアップを取得しておきます。
• 個人情報が保存されていた場合：個人情報保護法上の報告・本人通知の要否を検討します。小平市は「おそれ」の段階で公表しました。
• 被害情報の共有：国家サイバー統括室は10月9日、事業者向けの文書で、被害に遭った組織が攻撃に関する技術的な情報を同室や所管省庁に速やかに共有するよう呼びかけています。

同じ文書は、対策のポイントを3分野で示しています（ITmedia NEWS、原文）。

• ウェブシステム等の適切な管理：OSやCMSへのパッチの速やかな適用、サポート終了製品の利用停止、多要素認証の導入
• サプライチェーンを通じた侵害への対策：委託先の対策状況を契約時だけでなく継続的に確認、漏えい時の報告義務を契約に盛り込む、業務終了後にデータを確実に削除させる
• データの適切な管理：情報資産の棚卸し、不要な情報の削除、保存データと通信経路の暗号化、クラウド利用時の公開設定とアクセス権限の確認、アクセスログの点検・分析

4. 調達・設計への示唆（筆者の見解）

以下は事実ではなく、筆者の見解です。

• ISMAP登録の位置づけ：登録は、政府調達に必要な統制を事業者が整備・運用していることの評価です。侵害されないこと、止まらないことの保証ではありません。2026年9月にはデジタル庁のGSSも、既知のVPN脆弱性から侵入されたと公表されています。
• バックアップの置き場所：重要システムでは、本番と異なる障害・認証・管理ドメインにバックアップを持ちます。別アカウント、別リージョン、別媒体、別クラウドのどれにするかは、RTO／RPO、情報区分、データ所在の要件で決めます。すべてのシステムに別事業者への保管を一律に課すのは、現実的ではありません。
• バックアップの堅牢性：イミュータブル（変更・削除できない）な構成にし、本番の管理者資格情報だけでは消せないようにします。
• 復元の実証：バックアップがあるだけでは足りません。定期的なリストア試験を、契約やSLA、運用報告に含めます。
• 契約条件：重大インシデント発生時の顧客通知期限、証拠保全、出口戦略、データの持ち出し手段、ISMAPへの報告の有無の共有を、契約で定めます。
• 新規採用の判断：IDCFの新規採用は、侵入経路と再発防止策が公表され、ISMAP側の手続きの方向が見えるまで保留するのが、重要な本番システムでは合理的な選択です。検証環境や代替しやすいシステムまで一律に止めるかは、バックアップ設計や契約上の補償措置を含めて個別に判断すべきです。

5. 政府・当局の動き

• 10月8日　JPCERT/CC：国内で相次ぐ不正アクセスについて注意喚起（JPCERT-AT-2026-0030）を公表しました。確認された手口として、既知の脆弱性や管理不備を突く攻撃、スマホアプリの解析による内部APIの不正操作、BIツールMetabaseのSQLインジェクション脆弱性（CVE-2026-72898）の悪用が挙げられています（マイナビニュース）。
• 10月8日　関係省庁会議：サイバー攻撃の多発を受けて緊急に開かれ、被害情報は国家サイバー統括室に集約する方針が示されました。古川大臣は、危急の状況だとして政府一丸での対策を訴えています（Impress Watch）。
• 10月8日報道　個人情報保護委員会：強い多要素認証やEDRの導入、不要な個人データの消去などを、緊急に例示したと報じられました（ITmedia NEWS）。
• 10月9日　国家サイバー統括室：大量の個人情報を扱う事業者向けに、対策の徹底を求める文書を公開しました（第3節の3分野）。

6. 同時期の主要な情報漏えい・不正アクセス

IDCF事案と並行して、国内では大規模な漏えいの公表が続いています。件数は各社が公表した最大値や「可能性」を含みます。「漏えいを確認」と「漏えいの可能性」は区別してください。

6-1. 9月

公表日	組織・サービス	規模	概要・状態
9月11日	デジタル庁 ガバメントソリューションサービス（GSS）	約24.6万件	VPN機器の既知の脆弱性を悪用した侵入。漏えいの可能性。マイナンバーや口座情報は含まないと公表。
9月15日	ムラウチドットコム	771万6,811件	Webシステムの脆弱性を悪用された。持ち出しを確認。
9月16日	Gyazo（Helpfeel）	ユーザー関連データ約2,362万件、画像メタデータ約4.9億件	不正アクセスによる流出。9月25日の続報で、削除済み画像のメタデータ約1.74億件の流出も判明。
9月25〜29日	タイムズカー（タイムズモビリティ）	約660万アカウント（うち本人確認書類を含むのは約160万件）	9月25日に検知。第三者による取得を確認。クレジットカード情報は含まない。
9月27日	OZmall（スターツ出版）	最大44万2,779名	海外からの大量の不正アクセス。メールアドレスなどが閲覧された可能性。件数は10月1日の第2報で精査された値。
9月29日	セイコーマートアプリ	約57万アカウント	第三者に閲覧された可能性。
9月30日	VOISING	約17万件	BIツールの既知の脆弱性を悪用された。

出典：@IT（GSS）、ムラウチ、Helpfeel、Impress Watch（タイムズカー）、OZmall、セイコーマート、VOISING

6-2. 10月

公表日	組織・サービス	規模	概要・状態
10月5日	焼肉きんぐ公式アプリ（物語コーポレーション）	1,078万8,963件	会員管理システムへの不正アクセス。氏名、メールアドレス、電話番号など。パスワード・決済情報は含まない。登録者のほぼ全員が対象。
10月6日	ミスターマックス（アプリ・オンラインストア）	最大173万5,154人	ソフトウェアの機能を不正利用したサーバー侵入。住所・カード情報などは対象外。
10月6日	スカラコミュニケーションズ FAQシステム「i-ask」（委託先）	最大5社・延べ最大71万3,126件	管理サイトへの不正ログインと不正プログラムの設置。件数は問い合わせ単位の延べ件数で、重複を含む。利用企業の公表は、大和証券（10月5日、約11万人）、シチズン時計（10月6日、約10万人）、損保ジャパン（10月7日、延べ約6万件）。
10月7日	HIS（タイ現地法人）	最大627名	パスポート情報とアレルギー情報の流出の可能性。2025年12月11日に検知し、2026年10月7日に公表。
10月7日	IDCフロンティア「IDCFクラウド」	495の企業・自治体	ランサムウェア攻撃による障害（第1節）。情報漏えいの有無は未公表。
10月9日	ブックオフグループホールディングス（子会社の会員管理システム）	最大約643万件	不正アクセスによる会員情報の流出（報道ベース）。

出典：焼肉きんぐ、ミスターマックス、Internet Watch（i-ask）、ITmedia NEWS（損保ジャパン）、トラベルWatch（HIS）、ITmedia NEWS（ブックオフ）

このほか、10月6日前後には、GMOリサーチ＆AIのアンケートサービス「infoQ」（最大約95万件）や「楽天ドライブ」（約1.5万アカウント）の不正アクセスも報じられています。

7. まとめと今後の注目点

今期の情報漏えいの多くは、個人情報の窃取です。一方、IDCFクラウド事案は、クラウド基盤そのものが止まり、その上で動く自治体サイトや企業のサービスが同時に影響を受けました。漏えいの件数では他の事案が大きくても、可用性とサプライチェーンへの波及という点では、最も重大な事案の一つだと言えます。

今後、次の点に注目しています。

• IDCFの続報：侵入経路、情報漏えいの有無、復旧計画、再発防止策
• ISMAP運営委員会の対応：再監査や登録の扱いに関する公表の有無
• 国家サイバー統括室や個人情報保護委員会による、クラウド利用時の追加の指針

利用する側としては、ISMAPのリストに載っているかどうかに加えて、事業者が止まったときに自分のデータをどこから復元できるかまで、調達や設計の段階で確認しておくことが重要です。

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

「データを国内リージョンに置いているから安心」——クラウド調達の議論でいまだによく聞くフレーズです。しかし米国の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で、外国法リスクの評価、国内データセンターの原則、そして鍵の自己管理という三点を書き込んでいます。民間の実務も、そこから出発するのが筋が通っているように思います。

南海トラフ巨大地震は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)の提供終了について」

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

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

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

📋 目次

1. ソブリンクラウドとは何か
2. なぜ今、ソブリンクラウドか ― 規制・地政学・AIの三重圧力
3. グローバルのソブリンクラウド動向
4. Oracle Alloyとは何か ― クラウドの民主化
5. 日本のOracle Alloy 5社を徹底比較
6. AlloyはソブリンクラウドたりうるかのWill分析
7. Alloy以外の国産ソブリンクラウド全マップ
8. 日本企業・官公庁のソブリンクラウド採用戦略
9. 採用判断フレームワーク：3層分類で選べ
10. 2026〜2030年の展望
11. まとめ

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）でご確認ください。