Microsoft Azureの「Welcome to Microsoft Sovereign Cloud」は、Azure利用者の環境を自動で切り替える更新ではありません。2026年5月9日時点で確認すべきポイントは、Microsoft Sovereign Cloud関連の公式ドキュメントが、ソブリン パブリック クラウド、ソブリン プライベート クラウド、ナショナル パートナー クラウド、Azure Local上のAI活用へ整理されたことです。
特に管理者や開発者にとって重要なのは、「どのAzureサービスを使えるか」よりも、「データ所在地、暗号鍵、運用監査、ポリシー適用、AIワークロードの実行場所をどう設計するか」です。規制対象業界、公共機関、EU/EFTA関連のデータを扱う企業、オンプレミスに残すべき機密データをAIで活用したい組織は、Azure Policy、Sovereign Landing Zone、Key VaultやManaged HSM、Azure Local、Azure Arcの設計を見直す必要があります。
Microsoft Azureの「Welcome to Microsoft Sovereign Cloud」は何を示すページか
「Welcome to Microsoft Sovereign Cloud」は、Microsoft Sovereign Cloud関連ドキュメントへの入口となるMicrosoft Learnのハブページです。ページ内では、ソブリン プライベート クラウド、ソブリン パブリック クラウド、ナショナル パートナー クラウド、ソブリン プライベート クラウド上のAIスイートが整理されています。(Microsoft Learn)
今回の更新をAzure管理者の視点で見ると、単なるリンク集の変更ではありません。Microsoft Sovereign Cloudを「特殊な国別クラウド」だけでなく、既存のAzure、Azure Local、Azure Arc、Microsoft 365、AIワークロードを組み合わせて主権要件に対応する設計領域として扱う流れが明確になっています。
なお、公式GitHub履歴では、ハブページとTOCに「AI workloads on Azure Local」へのリンクを追加するコミットが確認できます。変更量自体は小さいものの、ソブリン環境におけるAI活用の導線が強化された点は見逃せません。(GitHub)
何が変わるのか：Azure環境そのものより「設計判断」が変わる
今回の情報から読み取るべき変更点は、既存のAzureテナントに新しい設定が強制適用されることではありません。変わるのは、規制やデータ主権を意識したAzure設計で確認すべき範囲です。
| 観点 | 変更・整理された内容 | 管理者・開発者への影響 |
|---|---|---|
| ドキュメント構成 | Microsoft Sovereign Cloudの入口が、Public Cloud、Private Cloud、National Partner Clouds、AI suiteに整理された | どのモデルで要件を満たすべきかを比較しやすくなった |
| Sovereign Public Cloud | 既存のMicrosoftハイパースケールクラウドに、データ所在地、運用監視、顧客管理暗号化などの制御を追加する位置付けが明確化 | Azure Policy、暗号鍵、リージョン、ログ監査の設計が重要になる |
| Sovereign Landing Zone | Azure Landing Zoneをベースに、主権要件向けのポリシーや管理グループ設計を追加 | 既存のLanding Zoneをそのまま使うのではなく、機密度別の管理構造を検討する必要がある |
| Azure Local上のAI | AI workloads on Azure Local、Foundry Local、Edge RAG、Azure AI Video Indexer enabled by Arcへの導線が強化 | 機密データをクラウドへ送らずにAI処理したいケースで、Azure LocalとArcの検証が必要になる |
| National Partner Clouds | ローカル事業者が運用するクラウドモデルが整理された | 対象国、提供範囲、サービスマトリックスを個別に確認する必要がある |
特に重要なのは、Sovereign Public Cloudが「Azureとは別物の閉じたクラウド」ではなく、既存のAzureやMicrosoft 365のハイパースケールクラウドに、データ所在地、運用透明性、顧客管理暗号化などの制御を重ねる考え方である点です。(Microsoft Learn)
対象者：すべてのAzure利用者ではなく、主権要件がある組織が中心
Microsoft Sovereign Cloudの主な対象は、政府機関、自治体、医療、金融、エネルギー、重要インフラなど、データの所在地や運用者、暗号鍵の管理、監査証跡に厳しい要件がある組織です。Microsoft Learnでも、政府や規制対象業界がデータ所在地、運用監視、コンプライアンス要件を満たしながらクラウドを活用するためのアプローチとして説明されています。(Microsoft Learn)
一方で、一般的なWebサイト、社内ポータル、開発環境、テスト環境まで、すぐにMicrosoft Sovereign Cloud前提で再設計する必要はありません。まず確認すべきなのは、自社のAzureワークロードに以下のような条件があるかです。
| 確認項目 | 該当する場合に検討すべきこと |
|---|---|
| 個人情報、医療情報、金融情報、公共データを扱う | データ分類、保存リージョン、暗号鍵、監査ログを設計する |
| EU/EFTA地域の規制や顧客契約に関係する | EU Data Boundary、Data Guardian、データ処理場所の確認が必要 |
| クラウド事業者の運用アクセスを監査したい | Data Guardianや改ざん検知可能なログの対象範囲を確認する |
| 暗号鍵をMicrosoft管理外で保持したい | Customer Managed Key、Managed HSM、External Key Managementを比較する |
| AI処理のために機密データをクラウドへ送れない | Azure Local、Arc-enabled Kubernetes、Edge RAG、Foundry Localを検証する |
| 国や地域ごとの独立運用が必要 | National Partner Cloudsの提供国、提供サービス、運用主体を確認する |
日本のAzure利用者にとっては、「日本で新しいソブリンAzureリージョンが自動的に提供される」と読み替えないことが重要です。現時点で実務上の第一歩は、利用中のAzureサービス、データ分類、リージョン、暗号鍵、ネットワーク、監査ログの棚卸しです。
Sovereign Public Cloudで押さえるべき3つの制御
Sovereign Public Cloudでは、既存のAzureパブリッククラウドを活用しながら、主権要件を満たすための制御を追加します。公式情報では、中心となる制御として、データ所在地、暗号化、コンフィデンシャル コンピューティングが整理されています。(Microsoft Learn)
データ所在地：リージョン指定だけでは不十分
データ所在地は、「リソースをどのリージョンに作成したか」だけでは判断できません。Azureにはリージョンを指定してデプロイするサービスが多くありますが、Azure Front Door、Traffic Manager、Azure Policy、Azure DNSなどのグローバルまたは非リージョンサービスでは、単一リージョン内にデータが留まる保証とは異なる扱いになる場合があります。(Microsoft Learn)
実務では、次のように確認します。
| 確認対象 | 見るべきポイント |
|---|---|
| Azureサービスの種類 | リージョンサービスか、グローバルサービスか |
| 保存されるデータ | 顧客データ、ログ、メタデータ、設定情報のどれか |
| 処理場所 | 保存場所だけでなく、処理やキャッシュの場所も確認する |
| バックアップ・レプリケーション | geo冗長、DR、CDN、ログ転送の設定を確認する |
| 監視・セキュリティ製品 | Microsoft Defender、Sentinel、Log Analyticsなどのワークスペース配置を確認する |
よくある失敗は、「リソースグループをJapan Eastに作ったからデータ所在地要件は満たせている」と判断してしまうことです。実際には、利用サービスごとのデータ処理特性、ログ保存先、バックアップ先、外部連携先まで見る必要があります。
暗号化：PMK、CMK、Managed HSM、EKMを使い分ける
Azureサービスの多くは、保存データをプラットフォーム管理キーで暗号化します。ただし、主権要件や規制要件が強いワークロードでは、Customer Managed Key、Azure Key Vault、Azure Key Vault Managed HSM、External Key Managementの検討が必要です。公式情報では、要件が高いワークロードではManaged HSMが推奨される一方、すべてのAzureサービスがManaged HSMに対応しているわけではないと説明されています。(Microsoft Learn)
判断基準は次の通りです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Platform Managed Key | 一般的な業務システム、低リスクデータ | 鍵の所有・ローテーションを自社で細かく制御しにくい |
| Customer Managed Key | 機密データを扱い、鍵のローテーションや失効を自社で管理したい | サービスごとのCMK対応状況を確認する |
| Managed HSM | 鍵管理の分離、HSM要件、強いコンプライアンス要件がある | コスト、運用、対応サービスの制約を確認する |
| External Key Management | 鍵をMicrosoftクラウド境界外に保持したい | 可用性、SLA、運用負荷、障害時の影響を事前に評価する |
開発者は、暗号鍵の要件を後工程で追加するのではなく、アプリケーション設計時点で「どのサービスがCMKに対応しているか」「鍵をどこに保存するか」「鍵が利用不能になった場合の挙動はどうなるか」を確認しておくべきです。
コンフィデンシャル コンピューティング：処理中のデータ保護を設計に入れる
コンフィデンシャル コンピューティングは、保存中や転送中だけでなく、メモリ上で処理中のデータを保護する考え方です。Azureでは、Trusted Execution Environmentを活用し、処理中のデータやコードへの不正アクセスリスクを下げる設計が説明されています。(Microsoft Learn)
ただし、すべてのワークロードに最初から強制すべきものではありません。公式情報でも、Level 3の制御は段階的に扱い、対応SKUやアテステーション信号を測定してから強い拒否ポリシーを適用する考え方が示されています。(Microsoft Learn)
実務では、まず以下のワークロードから検討すると現実的です。
| 対象ワークロード | 検討理由 |
|---|---|
| 個人識別情報や金融取引を処理するAPI | 処理中データの保護が重要 |
| 研究データ、知財、機密分析基盤 | クラウド運用者からの可視性を最小化したい |
| AI推論や分析処理 | 入力データやモデルの機密性を守りたい |
| 鍵を使う復号処理 | Secure Key Releaseなどの設計と組み合わせやすい |
Sovereign Landing Zoneは「主権要件向けのAzure Landing Zone」
Sovereign Landing Zoneは、Azure Landing Zoneをベースに、主権要件を満たすための追加制御を組み込んだ設計パターンです。公式情報では、Hub & Spoke、Virtual WAN、管理グループ階層などの構成例が示され、通常のAzure Landing Zoneと同じ基盤に、主権要件向けの制御やポリシーを追加する位置付けになっています。(Microsoft Learn)
特に注目すべき違いは、管理グループ構成です。Sovereign Landing Zoneでは、Landing Zones配下にPublic、Confidential Corp、Confidential Onlineといった管理グループを追加する設計が示されています。また、Security、Management & Governance領域では、組織の主権要件に応じて追加のAzure Policyを適用または要求する考え方が示されています。(Microsoft Learn)
既存環境へ導入する時の安全な進め方
既存のAzure環境にSovereign Landing Zoneの考え方を入れる場合、いきなり拒否ポリシーを適用するのは危険です。まずは影響を可視化し、段階的に強制範囲を広げます。
| フェーズ | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | サブスクリプション、リソースグループ、利用サービス、リージョンを棚卸し | 実験用・部門管理のサブスクリプションを見落とす |
| データ分類 | Public、Internal、Confidential、Secretなどに分類 | システム単位で分類し、データ単位の差を無視する |
| ポリシー設計 | allowed locations、CMK必須、Private Endpoint必須などを定義 | 例外条件を作らず、運用が止まる |
| 監査モード適用 | Azure PolicyをAuditで適用し、違反リソースを把握 | 監査結果を見ずにDenyへ切り替える |
| IaC修正 | Bicep、Terraform、ARMテンプレート、CI/CDを修正 | 手動作成リソースだけ直し、パイプラインが再び違反を作る |
| 本番適用 | 管理グループ単位で段階的にDenyを適用 | 開発環境と本番環境で例外管理が混乱する |
Sovereign Landing Zoneは、導入すれば自動的にコンプライアンスが完了する仕組みではありません。組織のデータ分類、規制要件、例外承認プロセス、監査運用とセットで設計して初めて効果を発揮します。
ワークロード実装では「サービスごとのデータ特性」を表にする
Sovereign Public Cloudでワークロードを実装する際、Microsoft Learnでは、データを機密度や規制要件に基づいて分類し、Azureサービスごとのデータ保存、CMK対応、コンフィデンシャル コンピューティング、データ所在地を評価する考え方が示されています。(Microsoft Learn)
実務では、次のようなサービス評価表を作ると判断しやすくなります。
| サービス | 扱うデータ | データ所在地 | CMK対応 | ネットワーク制御 | 判断 |
|---|---|---|---|---|---|
| Azure Storage | 顧客ファイル、添付資料 | 指定リージョン中心。冗長化設定を確認 | 対応状況を確認 | Private Endpointを検討 | 機密データではCMKと閉域化を優先 |
| Azure SQL Database | 業務データ、個人情報 | データベース配置リージョンを確認 | TDE、CMK対応を確認 | Private Linkを検討 | 高リスクなら鍵管理と監査を強化 |
| Azure Front Door | 配信・キャッシュ | グローバルサービスとして扱いを確認 | 用途により異なる | WAF、TLS、ルール設計 | 機密データ配信には慎重に利用 |
| Azure Policy | ガバナンス設定・評価情報 | 非リージョンサービスの特性を確認 | 対象外の場合あり | 管理プレーン制御 | データ所在地要件の解釈を確認 |
| Azure Arc | オンプレミス/他環境の管理情報 | 送信されるメタデータを確認 | ワークロード次第 | 送信先・ポートを確認 | 接続要件と監査ログを事前確認 |
この表を作る目的は、サービスの採用可否を感覚で決めないことです。たとえば「ロードバランサーはデータを保存しないため保存時暗号化の観点では対象外になりやすいが、TLS終端やトラフィック検査をするなら別の制御が必要」といった判断ができます。(Microsoft Learn)
Azure Local上のAIワークロードは何が重要か
今回のハブ更新で実務上目立つのは、AI workloads on Azure Localへの導線です。Azure Localは、Azureの管理・セキュリティの考え方を使いながら、自社インフラ上でAI処理を行う選択肢です。公式情報では、Azure Local上のAIワークロードはAzure Arc-enabled Kubernetes上で動作し、データ処理をローカルに保ちながらクラウド一貫の管理を利用できると説明されています。(Microsoft Learn)
代表的な選択肢は次の通りです。
| ワークロード | 主な用途 | 確認すべき注意点 |
|---|---|---|
| Foundry Local on Azure Local | 生成AI・予測AIモデルのローカル推論 | プレビュー提供。利用にはアクセス申請や対応リージョン確認が必要 |
| Edge RAG enabled by Azure Arc | オンプレミス文書に対するRAG、社内チャット、検索 | プレビュー。データ取り込み、ベクトル検索、権限制御を設計する |
| Azure AI Video Indexer enabled by Arc | 動画・音声解析をエッジで実行 | 事前承認、接続モード、ハードウェア、ネットワーク要件を確認する |
Foundry Local on Azure Localはプレビューとして説明されており、Arc-enabled Kubernetesクラスター上でAIモデルをデプロイし、OpenAI互換のRESTパターン、CPU/GPU推論、APIキーやMicrosoft Entra IDによる保護などが示されています。(Microsoft Learn)
Edge RAGは、オンプレミスデータを対象にRAGを実行するAzure Arc拡張です。データ取り込み、埋め込み、ベクトル検索、ローカル言語モデル、Azure RBACなどを含み、政府、金融、医療、製造など、データをオンプレミスに残す必要がある業種での利用シナリオが示されています。(Microsoft Learn)
Azure AI Video Indexer enabled by Arcは、動画や音声の分析をエッジ環境で行うArc拡張です。公式情報では、処理はエッジ側で行われ、クラウドには課金や監視のためのコントロールプレーン情報が送られる一方、インデックス対象の動画や生成されたインサイトなどの顧客データは送信されないと説明されています。(Microsoft Learn)
AI導入で特に注意すべき点
Azure LocalやAzure Arcを使うと、すべてのAI処理を完全なエアギャップ環境で動かせると誤解しがちです。しかし、公式情報では、Azure Localが制限付きまたは断続的な接続をサポートする一方、本番展開前に各AIワークロードが完全な切断モードに対応するか確認するよう求めています。また、AIワークロード選択表では、完全な切断またはエアギャップ運用はサポート対象として示されていません。(Microsoft Learn)
本番検討時は、少なくとも次を確認してください。
| 確認項目 | 理由 |
|---|---|
| プレビューかGAか | プレビュー機能は仕様、制限、提供条件が変わる可能性がある |
| Azure Arc接続要件 | 管理、課金、監視、拡張機能更新に必要な通信がある |
| GPU・CPU要件 | 推論モデルや動画解析ではハードウェア要件が大きく変わる |
| 認証方式 | APIキー、Microsoft Entra ID、RBACの使い分けが必要 |
| データの残留場所 | 顧客データ、メタデータ、ログ、テレメトリを分けて確認する |
| ネットワーク許可先 | ファイアウォール、プロキシ、名前解決、証明書管理が必要 |
National Partner Cloudsは「国別・地域別の独立運用モデル」
National Partner Cloudsは、Microsoftの技術を使いながら、地域のパートナーが所有・運用するクラウドモデルです。公式情報では、ローカル所有、ローカル運用、物理的・論理的分離、国内法や認証フレームワークへの適合が特徴として説明されています。(Microsoft Learn)
例として、フランスのBleu、ドイツのDelos Cloudが挙げられています。ただし、重要なのは「Microsoft AzureとMicrosoft 365の機能を提供する」とされていても、提供範囲、サービススコープ、遅延特性、ロールアウト順序は国や実装ごとに異なる可能性がある点です。(Microsoft Learn)
日本企業が海外拠点や公共案件でNational Partner Cloudsを検討する場合は、以下を必ず確認します。
| 確認項目 | 確認内容 |
|---|---|
| 対象国・地域 | その国でNational Partner Cloudが提供されているか |
| 利用可能サービス | Azure、Microsoft 365、ID、監視、AIサービスの対象範囲 |
| 認証・準拠基準 | 現地法、業界基準、政府調達要件への適合 |
| 運用主体 | Microsoft、パートナー、共同運用の範囲 |
| 既存Azureとの接続 | ID連携、ネットワーク接続、データ移行、運用監視 |
| サポート体制 | サポート窓口、言語、SLA、障害対応プロセス |
管理者が確認すべき設定チェックリスト
Microsoft Sovereign Cloud関連の情報を受けて、Azure管理者が最初に確認すべき項目は次の通りです。
| 項目 | 確認内容 | 優先度 |
|---|---|---|
| 管理グループ構成 | 機密度や事業単位でポリシーを分けられる構造か | 高 |
| Azure Policy | リージョン制限、CMK必須、Public IP制限、Private Endpoint必須などを監査できるか | 高 |
| リージョン利用状況 | 許可していないリージョンにリソースがないか | 高 |
| グローバルサービス | Azure Front Door、DNS、Traffic Manager、Policyなどの扱いを整理したか | 高 |
| 鍵管理 | Key Vault、Managed HSM、CMK、EKMの使い分けを定義したか | 高 |
| ログ保存先 | Log Analytics、Sentinel、Defender、診断ログのリージョンと保持期間 | 高 |
| ネットワーク | Private Link、VPN、ExpressRoute、MACsec、TLS要件を整理したか | 中 |
| IaC | Bicep、Terraform、ARMテンプレートがポリシー違反を生まないか | 中 |
| 例外管理 | 例外承認、期限、監査証跡を残せるか | 中 |
| Azure Arc | オンプレミスやKubernetesからAzureへ送信される情報と通信先を把握したか | 中 |
ネットワーク面では、ExpressRouteを使っているだけで全通信が暗号化されると考えないことも重要です。公式情報では、ExpressRouteは標準構成ではネイティブ暗号化を提供しないため、必要に応じてVPN over ExpressRouteやExpressRoute MACsecを検討する必要があると説明されています。(Microsoft Learn)
開発者が確認すべき実装上の注意点
開発者は、Azureリソースを作成できるかどうかだけでなく、アプリケーションの設計が主権要件を壊さないかを確認する必要があります。
| 実装領域 | 確認ポイント |
|---|---|
| API設計 | 機密データを外部APIやグローバルサービスへ送っていないか |
| ストレージ | Blob、DB、キャッシュ、ログに同じ機密度のデータを混在させていないか |
| 認証・認可 | Microsoft Entra ID、RBAC、マネージドIDを適切に分離しているか |
| シークレット管理 | アプリ設定やCI/CD変数に鍵や接続文字列を直書きしていないか |
| ログ出力 | 個人情報、トークン、プロンプト、AI応答をログに出していないか |
| AI利用 | 入力データ、モデル、推論結果、評価データの保存場所を把握しているか |
| デプロイ | IaCテンプレートにリージョン、SKU、暗号化、Private Endpointを明示しているか |
特にAIアプリケーションでは、プロンプト、検索対象文書、RAGのチャンク、埋め込みベクトル、推論ログ、評価データが新たな機密データになります。Azure LocalやEdge RAGを使う場合でも、どのデータがオンプレミスに残り、どのメタデータがAzure側へ送られるかを確認してから設計すべきです。
移行・展開で失敗しやすいポイント
Microsoft Sovereign Cloud対応を進める際、失敗しやすいのは技術的な設定ミスだけではありません。要件定義の曖昧さが、後から大きな手戻りになります。
| 失敗例 | 何が問題か | 回避策 |
|---|---|---|
| リージョン制限だけで主権要件を満たしたと判断する | 非リージョンサービス、ログ、メタデータ、キャッシュを見落とす | サービスごとのデータ処理表を作る |
| CMK対応を後から確認する | 採用済みサービスがManaged HSMやCMKに対応しない場合がある | 設計段階で暗号鍵要件を確認する |
| Azure PolicyをいきなりDenyで適用する | 既存運用やCI/CDが停止する | Audit、DeployIfNotExists、例外管理を段階的に使う |
| PreviewのAI機能を本番前提で採用する | 仕様や提供条件が変わる可能性がある | PoC、本番判定、代替案を分ける |
| Azure Arcの通信要件を軽視する | ファイアウォールやプロキシで拡張機能が動かない | 必要エンドポイントとポートを事前に確認する |
| 監査ログの保存先を後回しにする | インシデント時に証跡が不足する | Log Analytics、Sentinel、保持期間、アクセス権を先に決める |
| 法務・監査部門を最後に巻き込む | 技術的には可能でも契約・規制解釈で差し戻される | データ分類と要件定義を共同で作る |
まず取るべき行動
Microsoft Azureで「Welcome to Microsoft Sovereign Cloud」関連の更新を確認したら、最初にやるべきことは移行作業ではありません。まず、現在のAzure環境がどの程度ソブリン要件に耐えられるかを可視化します。
実務では、次の順番で進めると失敗しにくくなります。
- Azure上のワークロードを、Public、Internal、Confidential、Secretなどに分類する
- 各ワークロードで使っているAzureサービス、リージョン、ログ保存先、外部連携先を一覧化する
- Azure PolicyをAuditモードで適用し、リージョン、暗号化、ネットワーク、タグ、公開設定の違反を確認する
- CMK、Managed HSM、External Key Managementが必要なデータを切り分ける
- Sovereign Landing Zoneの管理グループ構成を参考に、機密度別のサブスクリプション設計を検討する
- AIでオンプレミスデータを扱う場合は、Azure Local、Arc-enabled Kubernetes、Foundry Local、Edge RAGをPoCで検証する
- 本番適用前に、法務、監査、セキュリティ、インフラ、アプリ開発の各担当者で例外承認プロセスを決める
今回のポイントは、Microsoft Sovereign Cloudを「特殊なクラウド製品」として見るのではなく、Azure設計のガバナンス、データ主権、暗号鍵、運用透明性、AI実行場所を見直すための枠組みとして捉えることです。
既存のAzure環境をすぐに作り替える必要はありません。ただし、規制対象データや高機密データを扱う組織は、Azure Policyによる監査、サービスごとのデータ所在地確認、暗号鍵管理、Sovereign Landing Zoneの検証を早めに始めるべきです。これにより、将来の規制対応や公共案件、AI活用で「設計からやり直し」になるリスクを抑えられます。
コメント