要約

  • AWS は European Sovereign Cloud に具体的な運用・法務・アーキテクチャ上の約束を与えたが、それは所在地のラベルではなく、検証すべき制御関係図として読む必要がある。
  • 妥当な主権判断は、特権運用、ID と鍵、サポート、ソフトウェア供給、ガバナンス、緊急変更権限という六つの経路を検証する。

規制対象のワークロードが顧客データをすべてブランデンブルク州に保管していても、最も重要な例外時の判断が未解決なことはあり得る。通常の指揮系統が使えないとき、誰が緊急変更を承認するのか。この問いは障害や不正を想定するものではない。データが置かれる場所である「所在地」と、人、資格情報、法人、供給者のうち誰が次の状態を変えられるかを示す「運用主権」を分けるための問いだ。

AWS の提案は単なる地域バッジより具体的である。AWS European Sovereign Cloud は 2026 年 1 月 14 日に一般提供を開始し、最初のリージョンをブランデンブルク州に三つのアベイラビリティーゾーンで設けた。AWS は、他リージョンから物理的・論理的に分離し、専用の ID、請求、DNS を備え、顧客コンテンツと顧客作成メタデータを EU 内に保持し、世界の他地域との接続が途絶えても運用できる設計だと説明している。日常運用は EU 居住者が管理し、運用職は段階的に EU 市民へ移行する。専用のドイツ法人と EU 市民で構成される諮問委員会も設けられた。

これらは重要な制御である一方、供給者の説明と契約上の約束であり、すべての顧客構成が自動的に同じ結果になる証明ではない。ID 連携、サポート、監視、鍵管理、配備ツール、第三者ソフトウェアが境界外依存を戻す可能性がある。主権評価は依存関係の棚卸しから始まる。

第一は特権運用である。本番を変更できる役割、その法域と雇用主体、承認順序、緊急アクセスを明らかにする。第二は ID と暗号権限で、ルート資格情報、署名系、鍵素材の管理者と、外部 ID サービスが重要経路に残るかを調べる。第三はサポートである。複雑な障害が境界外の担当者や診断系へ上がるなら、現地窓口だけでは足りない。

第四はソフトウェア供給である。欧州で動くクラウドでも、ソース管理、ビルド、署名鍵、脆弱性情報、リリース権限を域外に依存し得る。AWS は非 EU インフラへの重大な依存はないとしている。調達側はこの説明を部品表、障害試験、証拠へ展開すべきだ。第五はガバナンスで、契約、雇用、再委託を行い、法的命令を受ける主体を確かめる。Addendum は人員、統治、再委託先、継続性、通知を扱い、一定の重要変更や計画的終了について例外付きで少なくとも十二か月前の通知を約束する。

第六は緊急権限である。法的対立、要員不在、更新経路の侵害、即時修正を要する深刻な脆弱性を演習する。誰が決め、誰が実行し、どのシステムが認可し、どの外部依存を使い、後に何が証拠として残るかを各シナリオで確認する。

欧州委員会が提案した Cloud and AI Development Act の四段階も同じ方向を示す。第一段階は EU 内のデータ所在地であり、上位段階では第三国法からの独立、ソフトウェア供給の透明性、EU の所有と支配、最終的には第三国の干渉を受けない供給網全体の制御を加える。法案は変わり得るが、所在地は保証論の入口であって結論ではないという構造は有効だ。

受入資料には、制御面の分離図、特権役割と法域の台帳、鍵の保管、サポートと再委託の経路、ビルドと署名の来歴、統治上の約束、隔離・緊急変更演習の結果が必要である。公開資料は個別ワークロードについてこれらを証明しない。実際の構成で取得し、試験しなければならない。

AWS は主権の議論を具体化した。公正な対応は無条件の承認でも疑念でもなく、同じ具体性での検証である。平常条件が崩れたときも決定的な依存が合意済みで監査可能な境界内に残る範囲でのみ、そのサービスは当該ワークロードに対して主権的だと言える。

情報源