Microsoftの「主権的AI」の設計、日本の企業が今選べるものと待つもの

製造、医療、行政のシステムでは、機密性の高いデータを生成AIに渡したくても、国外や他社の管理下に出せないことがあります。

10月19日、Azureの公式ブログに「Designing for sovereign AI: A shared foundation from edge to cloud」が載りました。筆者はグローバルインフラストラクチャ担当のGeneral ManagerであるAlistair Speirs氏です。Intelとの協業を前提に、「主権的AI（sovereign AI）」の基盤をどう設計するかを述べています。新製品の発表というより考え方の整理で、具体的な更新は翌20日のOfficial Microsoft Blogに出ました。この記事では2つの記事の内容から、日本の企業が今使える部品と、提供を待つことになる機能を分けて書きます。

データの置き場所から、ワークロードごとの管理へ#

ブログはデジタル主権の議論が広がったと書いています。対象はデータをどこに保存して処理するかに加えて、ワークロードをどこで動かすか、誰がシステムにアクセスして運用するか、要件が変わっても安全に動き続けられるかです。

どこまで管理するかは、ワークロードによって変わるという立場です。判断の材料にはデータの機密度や規制のほか、遅延、接続の状況、運用のためのアクセス、障害への備えが挙がっています。そのため、パブリッククラウドと顧客が管理する環境、信頼できるパートナーの環境を、ワークロードごとに使い分ける形になるとしています。20日の発表にも「主権はワークロードから考える」という同じ立場が書かれていました。

ブログの終わりには経営層向けの問いが3つあります。

1. 何を自分たちの管理下に残す必要があるか（データ、インフラ、管理者のアクセス、ソフトウェアの運用、接続）
2. その管理が働いていることを、検証できるか（暗号化、分離、IDとアクセス制御、ポリシーの適用、構成証明、運用の透明性）
3. 要件が変わったときに、作り直さずに対応できるか（新しいモデルの採用、処理をデータの近くに移す、実行場所を変える）

3つ目の問いは見落とされやすそうです。今は接続して動かしているワークロードも、規制や接続の条件が変われば、切断した環境に移す必要が出るかもしれません。ブログはそのたびに管理とセキュリティの仕組みを作り直さずに済む設計を求めています。

機密VMと構成証明で「信頼を検証する」#

2つ目の問いについて、ブログは仕組みを具体的に挙げています。対応するAzureの機密VMの構成では、XeonのIntel TDX（Trust Domain Extensions）を使えます。TDXは使用中のワークロードをホストやハイパーバイザーから分離する仕組みです。ハードウェアに基づく構成証明（attestation）は、環境のセキュリティの性質を組織が自分の要件と照らし合わせるための証拠になる、という説明です。Intelの幹部は環境を信頼する段階から検証する段階へ移れると述べました。

機密VMの仕組みはMicrosoft Learnに説明があります。分離に必要な設定が欠けていると、Azure Attestationが起動時の正常性を証明せず、VMは起動しません。暗号鍵はプラットフォームに管理させるか、顧客が管理するかを選べます。Learnの説明にはAMDのSEV-SNPを例にした記述もあり、機密VMはIntelの製品だけで作る仕組みではありません。

20日の発表ではこの領域の更新が2つ一般提供になりました。1つはAzure Local上の機密VMで、自社の設備でも使用中のデータを守れます。もう1つはAzure Managed HSMの外部鍵管理です。ルートの暗号鍵を、自社か信頼できる第三者が運用するハードウェアに置けます。

ブログは保護の強さを各ワークロードのリスクに見合うものにするべきだとしています。分離や暗号化、構成証明、運用の管理は効果のある所にかけ、全体を運用できる形に保つという考え方です。

自社の環境で動かす部品と、提供の状況#

データの近くでAIを動かす部品は、Azure Localの上に組む「Sovereign Private Cloud」にまとまっています。状況は20日の発表と各製品のドキュメントで次のとおりです。

部品	中身	状況
Azure Local	自社が持つハードウェアで動くAzureの基盤。切断運用ではポータル、Resource Manager、RBAC、Key Vault、Azure Policyなどを手元で動かす	提供中。接続と切断を切り替える機能はパブリックプレビューに入る
Foundry Local（Azure Local上）	Arc対応のKubernetesでAIモデルの推論を動かす。OpenAI互換のREST API、CPUとGPU、切断環境に対応	プレビュー。Igniteで接続・切断とも一般提供の予定
GitHub Enterprise Local	GitHub Enterprise ServerをAzure Local上の仮想アプライアンスとして動かす	プレビュー。Igniteで一般提供の予定
Microsoft 365 Local	Exchange Server、SharePoint Server、Skype for Business ServerをAzure Local上で動かす	提供中。Foundry Localとの連携は、承認された顧客向けのプレビュー

この表とは別に、同じ発表は「Sovereign Control Panel」を、自社の環境ではなくMicrosoftのクラウド（Sovereign Public Cloud）側の機能として紹介しています。Azure portalで主権の状態、リスク、移行のしやすさをまとめて見るもので、Igniteでパブリックプレビューに入る予定です。

Learnの説明で、Microsoft 365 Localに挙がっているのはサーバー製品の3つだけです。TeamsやMicrosoft 365 Copilotの名前はありません。サブスクリプション版のこの3製品は、少なくとも2035年までサポートされます。

AIの処理について、ブログが挙げているのはXeon 6のIntel AMXでCPU上の推論を速くする方法と、モデルを最適化するIntelのOpenVINOです。GPUについては4月の発表が高性能なGPUのインフラへの対応を挙げています。同じ発表で、Azure Localを1つの主権の境界で数千台のサーバーまで広げられるようになったと説明していました。

日本でCopilotの国内処理が使える時期と、ほかの選択肢#

日本で検討するときに、一番影響が大きいのは時期です。Microsoftは2025年11月、Microsoft 365 Copilotの処理を国内で行う選択肢を15か国に広げると発表しました。日本はオーストラリア、英国、インドとともに2025年末までの対象でした。

同じページに2026年4月3日付の追記があり、時期と範囲が見直されました。国内で行うのはモデルがプロンプトを処理して応答を作る「推論」の段階だと明記され、対象の製品にCopilot Studio、Power Platform、Dynamics 365も挙がりました。2026年末までの予定はオーストラリアやインド、UAE、英国、米国で、カナダは2027年、日本は2028年です。Copilotの推論を国内で行うことを社内の条件にしている場合、2028年とされる提供までは条件を満たせない見込みです（月は示されていません）。

同じ4月3日、Microsoftは日本に2026年から2029年で100億ドルを投資すると発表しました。さくらインターネットとソフトバンクがGPUの計算資源をAzure経由で提供し、データは国内に置く計画です（さくらインターネットは提供の可能性を検討している段階）。GitHub Enterprise Cloudは、日本でのデータ所在地の選択に対応したと書かれています。

20日の発表のうち、Data GuardianはEUとEFTAの顧客向けで、日本は対象に挙がっていません。Microsoftの技術者による、対象の本番システムへのリモートアクセスを、EUの信頼できるパートナーが監督する仕組みです。そのアクセスと実行された操作を、改ざんを検知できる形で記録するProduction Touch Ledgerも、EUとEFTAで順に提供されます。独立して運用される国別のクラウドとして名前が挙がったのも、フランスのBleu CloudとドイツのDelos Cloudでした。

日本で2028年より前に、機密データをAIに国内で処理させたいなら、候補はFoundry Localのように自社の環境でモデルを動かす形になりそうです。ただし、これはMicrosoft 365 Copilotをそのまま手元で動かすものではありません。

切断運用の条件と、残る依存#

Azure Localの切断運用は、申し込めば誰でも使えるものではありません。Learnには次の条件があります。

• 対象の契約が必要で、Microsoft Online Subscription Program（MOSA）は対象外
• Standard以上のサポートプランか、それを持つパートナー
• 接続できない事情（接続の問題や規制）があること
• 運用できる人員か、代わりに運用するパートナー
• Azure Localの「Premier Solutions」のハードウェアと、専用の管理クラスター

手元で管理の仕組みを動かす分、最低限必要なハードウェアは接続時より多くなります。申し込みはフォームから行い、承認・却下などの結果は10営業日以内に届きます。

依存がなくなるわけでもありません。Network Worldの取材に、GartnerのAshish Banerjee氏は「完全な管理とは呼ばない」と答えています。IDやソフトウェアの更新、管理、サポートに、Microsoftが関わり続けるかを確かめる必要があるという指摘です。記事は同氏の見方として、切断した環境では全てのAzureのサービスが同時に提供されるとは限らないこと、専用の設備や人材が要る場合があること、伸縮性や規模の利点の一部を失う可能性があることも挙げています。最大限の主権は追加の複雑さに見合うワークロードだけに使うべきだという意見です。EIIRTrendのPareekh Jain氏は、Microsoftは米国の法律、制裁、輸出規制の対象であり続けると述べています。

KuppingerColeも、米国のCLOUD Actによる合法的なアクセスの根拠は残ると評価しています。技術を使えるかどうかはMicrosoftのライセンスが決めるので、法的・政治的な理由で使えなくなる危険も残るとしています。

ブログの3つの問いは、この依存をどう扱うかには答えていません。3つの問いを社内の検討に使うなら、ワークロードごとに「何を管理下に残すか」を決める表に、「Microsoftへの依存がどこに残るか」の列を足すのがよさそうです。Copilotの国内処理を2028年まで待つか、一部の処理を自社の環境に移すかは、その表で切り分けられます。