Sovereign Cloud / データ主権 — 欧州発の潮流と日本の含意

欧州では2025年から2026年にかけて「データ主権(Sovereign Cloud)」が一気に実装フェーズに入りました。規制の背景、各ハイパースケーラーの対応、そして日本のガバメントクラウドや規制産業が何を学ぶべきかを、一次情報にあたって整理します。

「クラウドはどこの国のものか」——数年前まで多くの日本企業にとって、この問いは抽象的な議論でした。ところが欧州では、2025年から2026年にかけてこの問いが具体的な製品・規制・調達要件として実装されました。シリコンバレーや欧州で先に起きたこの動きは、遅れて日本のエンタープライズにも到達します。本記事では、誇張なく一次情報にあたり、実務者が今のうちに理解しておくべき論点を整理します。

01「データ主権」とは何を指すのか — 3つのレイヤーに分解する

Sovereign Cloudという言葉は多義的です。営業資料では一括りにされがちですが、実務では次の3レイヤーに分解すると議論が噛み合います。

データ・レジデンシー(Data Residency)：データを特定の地理的範囲(例：EU域内)に保管・処理する。多くのクラウドが従来から「リージョン選択」で提供してきた最も基本的なレイヤーです。
オペレーショナル・ソブリンティ(Operational Sovereignty)：運用・保守・サポートに携わる人員を特定地域の居住者に限定し、外部からの技術的アクセスを遮断する。「誰がキーボードを触れるか」の統制です。
デジタル・ソブリンティ(Digital Sovereignty)：法人格・鍵管理・証明書発行までを域内で完結させ、域外国の法律(いわゆる域外適用)の影響を技術的・法的に排除する。最も強いレイヤーです。

顧客が「Sovereignにしたい」と言うとき、実際に必要なのはどのレイヤーなのか。ここを切り分けないまま最上位を前提に設計すると、コストと制約が跳ね上がります。

現場のコツ：要件定義の最初に「レジデンシーで足りるのか、オペレーショナルまで要るのか、それともデジタル主権まで必要か」を顧客と合意しておくと、後段のアーキ選定とコスト試算が一気に楽になります。多くのエンタープライズ案件は、実は中間レイヤーで十分です。

02規制が実装を駆動した — EU Data Actとその含意

欧州でSovereign Cloudが加速した最大の要因は、市場のムードではなく規制です。中でもEU Data Act(データ法)は2025年9月12日から適用が始まりました。実務上インパクトが大きいのは次の2点です。

クラウド・スイッチングの義務化：クラウド事業者は、顧客が他社やオンプレへ乗り換えることを妨げる契約上・技術上の障壁を撤廃し、移行を支援する義務を負います。データ・ポータビリティに必要な技術情報の公開も求められます。egress(データ持ち出し)料金についても、当面は「実費相当」までに制限され、段階的に撤廃される方向です。
域外国アクセスからの保護：EU域内に保管された非個人データについて、EU法・加盟国法に反する形での第三国政府によるアクセスを防ぐ技術的・法的・組織的措置が求められます。これがまさに「主権」の核心です。

ここには、米国CLOUD Act(米当局が米国企業に対し域外保管データの開示を求めうる法律)とEU法との緊張関係という、地政学的な背景があります。欧州の顧客にとってSovereign Cloudは、単なる「安心のブランド」ではなく、法的リスクへの具体的な対応策として位置づけられているのです。

03AWS European Sovereign Cloud — ハイパースケーラーが出した答え

この潮流に対する最も象徴的な回答が、2026年1月14日に一般提供が開始されたAWS European Sovereign Cloudです。総額78億ユーロの投資を伴うこの取り組みは、既存のAWSリージョンとは物理的にも論理的にも分離された独立クラウドとして設計されています。技術的な作り込みを、一次情報から具体的に押さえておきましょう。

ロケーション：初回リージョンはドイツ・ブランデンブルク州。パーティション名は aws-eusc、リージョン識別子は eusc-de-east-1 という、既存リージョンとは別系統の名前空間です。
独立性：全構成要素がEU域内に所在し、外部との接続が遮断されても継続稼働できるよう設計されています。EU域外からのアクセスを技術的に遮断する制御が組み込まれています。
ガバナンス：ドイツ法に基づく専用の欧州法人が運営。マネージング・ディレクターはEU市民・EU居住者で、運用・技術サポート・カスタマーサービスは最終的にEU居住者のみで完結させる方針です。
信頼の起点(Root of Trust)：証明書認証局(CA)の運用に欧州の信頼サービスプロバイダを充て、ネームサーバも欧州のトップレベルドメインのみを使用します。

注目すべきは、この独立クラウドが機能面で見劣りしない点です。初期提供サービスには、Amazon SageMakerやAmazon Bedrock といったAI/ML基盤まで含まれます。「主権のために機能を諦める」という従来のトレードオフを、真正面から潰しにきた設計だと言えます。

図：データ主権の3レイヤー。上位ほど統制は強いが制約とコストも増す。要件をどのレイヤーに置くかが設計の起点。

04Azure と Google Cloud — 二つの異なるアプローチ

ハイパースケーラーの対応は一枚岩ではありません。アプローチの違いを理解しておくと、顧客への提案の幅が広がります。

Microsoft Azure：EU Data Boundaryによる段階的レジデンシー強化。 Microsoftは2025年2月にEU Data Boundaryの完成を宣言しました。2023年1月の顧客データ保管(フェーズ1)、2024年1月の仮名化個人データ(フェーズ2)に続き、2025年2月には技術サポート時のプロフェッショナルサービスデータ(ログやサポートケースのメモ)までEU/EFTA域内に留める(フェーズ3)、という段階的な積み上げです。M365・Dynamics 365・Power Platform・大半のAzureサービスが対象で、AI処理も域内で完結する方向へ拡張しています。既存プラットフォーム上でレジデンシーとオペレーショナル主権を厚くしていく路線です。

Google Cloud：現地パートナーとの合弁による分離。 GoogleはフランスでS3NSという、Thales(過半数株主)とGoogle Cloudの合弁会社を通じ、PREMI3NSという主権クラウドを提供します。2025年12月17日にフランスのサイバーセキュリティ庁ANSSIによるSecNumCloud 3.2の認定を取得しました。これは域外法から機微データを遮断する仏国の最上位基準です。さらに2026年5月には、同じ運用モデルをドイツに展開するThalesとの新パートナーシップも発表されました。「ハイパースケーラーの技術+現地の信頼できる運営主体」という構図です。

現場のコツ：3社は「どこまで自前で、どこから現地パートナーに委ねるか」で戦略が分かれています。提案時は「機能の豊富さ」と「主権の強度」のどちらを顧客が優先するかを先に握ると、比較表が書きやすくなります。AI基盤まで主権リージョンで完結させたいならAWS、既存M365資産と統合したいならAzure、仏SecNumCloud級の認定が要件ならGoogle/S3NS、といった具合に軸が定まります。

05日本への含意(1) — ガバメントクラウドとISMAP

ここからが本題です。欧州の動きは、日本の公共・規制領域にどう効いてくるのでしょうか。

日本には既にISMAP(政府情報システムのためのセキュリティ評価制度)があり、政府調達の前提としてクラウドサービスを事前評価・登録する仕組みが機能しています。デジタル庁のガバメントクラウドは、ISMAP登録を応募の前提条件としつつ、さらに独自審査を課す構造です。なお、ISMAPの管理基準についても、ISO/IEC 27002:2022の4区分(＋クラウド固有)に整合する形で管理策を1,081項目から253項目へと大幅に整理する改定が検討されています。ただしこの改定管理基準はパブリックコメントを経て現在も改定作業中で、正式な公表・実施は2027年3月頃が予定されており、本記事執筆時点(2026年)では現行の管理基準が有効です。

ここで欧州との対比が示唆に富みます。日本のISMAP/ガバメントクラウドは、現時点では「レジデンシー+運用統制」寄りで、欧州が到達した「デジタル主権(域外法の技術的排除)」までは制度として明示的に求めていません。地方公共団体の20業務システムの標準準拠システムへの移行が、2025年度末を原則の期限として進む中で、次に問われるのは「どこまでの主権レベルを国として要求するか」という論点になっていくと考えられます。欧州のData ActとCLOUD Actの緊張関係は、日本が今後この問いに向き合う際の先行事例です。

06日本への含意(2) — 金融・医療など規制産業の実務

公共に限らず、金融・医療・重要インフラといった規制産業でも、この論点は現実味を帯びます。実務上、次のような問いが顧客から出始めています。

「クラウド上のデータに、海外の当局が本国法に基づいてアクセスできる余地はあるのか」——これはFISC安全対策基準や各業法の委託先管理の文脈で、監査・当局対応の論点になりつつあります。
「特定ベンダーへのロックインは、事業継続(BCP)や規制対応上のリスクではないか」——EU Data Actのスイッチング義務は、日本の規制当局が将来求めうる可搬性要件の先行指標です。
「運用・保守に携わる人員の所在や国籍を、どこまで統制する必要があるか」——オペレーショナル主権の観点です。

重要なのは、これらすべてに「最上位のSovereign Cloud」で答える必要はない、という点です。多くの日本の規制産業案件では、適切なリージョン選択・鍵管理(顧客管理鍵/BYOK)・アクセス統制・監査ログの設計で、実質的な要件を満たせます。過剰にデジタル主権を追い求めると、AI基盤を含む最新サービスの利用可否や、運用コストで不利になります。要件のレイヤーを見極める設計力こそが、SIer・情シスの腕の見せ所です。

現場のコツ：マルチアカウント/マルチリージョンの統制設計は、主権要件を段階的に強化する「土台」になります。ガードレールと監査の基盤を先に固めておけば、後から主権レベルを引き上げる際の追加コストが小さく済みます。詳しくはマルチアカウント統制もご覧ください。

07実務者への提言 — 「翻訳」して自社の要件に落とす

欧州の潮流をそのまま輸入する必要はありません。むしろ、次のステップで自社・顧客の文脈に「翻訳」することをお勧めします。

要件のレイヤー分解：セクション01の3レイヤーで、自社の統制要件が本当はどこにあるかを言語化する。多くの場合、中間レイヤーで十分だと分かります。
可搬性の先取り：EU Data Actのスイッチング義務は、日本にも遠からず波及します。データ・ポータビリティ(標準フォーマットでのエクスポート、IaCによる再現性)を今のうちから設計に織り込む。
鍵とアクセスの統制を厚くする：主権の実装の多くは、突き詰めれば「鍵を誰が持つか」「誰がアクセスできるか」に帰着します。ここは主権リージョンでなくても強化できます。
ベンダーの主権ロードマップを監視する：AWS・Azure・Googleいずれも四半期単位で対応が更新されています。一次情報(公式ブログ)を定点観測し、顧客に翻訳して届けることが付加価値になります。

EMWの立場は一貫しています。海外で先に起きたことを、日本のエンタープライズの現場要件に翻訳し、手を動かして実装まで橋渡しする。Sovereign Cloudはまさにその典型的なテーマです。

—まとめ

欧州のSovereign Cloudは、規制(EU Data Act)が実装(AWS European Sovereign Cloud、Azure EU Data Boundary、Google/S3NS)を駆動した好例です。日本のガバメントクラウドや規制産業は、この動きを2〜3年遅れで追う可能性が高い。今すべきことは、パニックでも過剰投資でもなく、自社の要件を3レイヤーに分解し、可搬性と鍵・アクセス統制を先に固めておくことです。主権レベルの引き上げは、良い土台さえあれば後からでも間に合います。過去の統制設計の実績は導入事例もあわせてご覧ください。

—参考(一次情報)

自社の統制要件がSovereignレベルなのかResidencyレベルなのか、切り分けからご一緒します。まずはお問い合わせください。

相談する

← ブログ一覧へ戻る