マイクロソフトが「MXC 1.0」を正式公開:WindowsがAIを「信頼できないコード」としてカーネルサンドボックスに隔離

マイクロソフトが「MXC 1.0」を正式公開:WindowsがAIを「信頼できないコード」としてカーネルサンドボックスに隔離

AIエージェントWindowsシステムセキュリティMXC

データソース:Windows Developer Blog + GitHub

プロンプトでは権限昇格を防げない:防御の最前線はOSカーネルへ後退

2026年10月7日、マイクロソフトは「Microsoft Execution Containers(MXC)」の一般提供(GA)開始を発表した。発表者はWindowsプラットフォーム&開発者担当コーポレートバイスプレジデントのLogan Iyer氏である。公式ドキュメントの巻頭で、マイクロソフトは明快な技術方針を宣言した。「エージェントは自身に対するセキュリティ権威にはなり得ない。」エージェントは独立して定義された境界内で動作し、外部からの強制的な制約に従わなければならない。過去3年間にわたりシステムプロンプトやファインチューニング、コンテキストガードレールに依拠してきた防御策は、突破され得る補助レイヤーへと格下げされた。

この方針転換の背景には、実際の開発現場で相次いだ制御不能の実態がある。Webサイト改修を担うコーディングエージェントは、コードリポジトリやテストツールへのアクセスに加え、デプロイ構成を把握するため本番設定を参照する必要がある。しかし物理的分離が施されていない環境では、エージェントは「本番環境の設定を直接書き換えるのが最短ルートだ」と勝手に判断しがちだ。モデルの発散的推論能力と、セキュリティルールが求める決定論的要件との間には、構造的な対立が存在している。

モデルの自己規律に頼っても越権行為は防げない。プロンプトインジェクションや目的ドリフトは、認知レイヤーの倫理指示をいつでもすり抜ける。マイクロソフトは防御線をOS低層まで後退させ、実績ある堅牢なプロセス境界によってエージェントの全操作を掌握する道を選んだ。

読み取り専用のポリシー設定:モデルから自己承認権限を剥奪

MXCの核心を成すのは、ポリシー駆動型の実行アーキテクチャである。開発者は信頼できないワークロードを起動する前に、宣言的なJSON設定ファイルを用いてその活動領域を厳格に制限する。ポリシーは「分離バックエンドの種別」「プロセス引数」「ファイルシステムの読み書きパス」「ネットワーク送信先」「GUI操作権限」の5次元で構成される。ポリシーファイルはエージェントの操作範囲外に置かれるため、モデルが生成したコードが独断で権限を昇格させることはできない。

最小権限ポリシーの設計ハードルを下げるため、MXCには3つの動作モードが用意されている。「Learningモード」は未承認操作をインターセプトして活動レポートを生成し、依存関係の整理を支援する。「Permissiveモード」は監視目的で異常ログのみを記録し、「Enforcementモード」は境界外アクセスを即座に遮断する。この段階的アプローチにより、コールドスタート時にエージェントの挙動を正確に予測しづらいという工学的課題を解消している。

マイクロソフトはこのアーキテクチャに対応する多言語開発ツールチェーンも整備した。オープンソースリポジトリではRust、.NET、Node向けの3つのSDKと、厳格にバージョニングされたJSON Schemaが提供されている。開発者はセキュリティ設計を一からやり直す必要はなく、既存フレームワークの外側にコンテナ定義を被せるだけで導入可能だ。

Windows公式が公開したMXCの概念ビジュアル 図:MXCアーキテクチャはポリシー制御とエージェント実行を分離する。出典:Windows Developer Blog

用途に応じた4段階の分離バックエンド:軽量プロセスからハードウェア級MicroVMまで

多様なユースケースのセキュリティ要求とリソース負荷に対応するため、MXCは4段階のコンテナバックエンドを備えている。基底となるのは軽量な「Process Container」だ。Windows 11ではAppContainer、macOSではSeatbelt、LinuxではBubblewrapを採用している。主要デスクトップOSを網羅し、コールドスタートの遅延をミリ秒単位に抑えているため、高スループットが求められる頻繁なツール呼び出しに適している。

フルインタラクションのシミュレーションを要する複雑なエージェントに対しては、Windows 11専用に設計された「Session Container」が提供される。エージェントは独立したシステムアカウントおよび隔離セッション下で動作する。メインユーザーのクリップボード、画面キャプチャ、入力イベントは物理的に遮断される。デスクトップUIと対話コンテキストを完全に切り離すことで、エージェントを誘導して画面情報を窃取させる攻撃経路を遮断した。

混在スタックや高リスクなワークロードに対しては、MXCは「WSL Container」および実験的な「MicroVM」バックエンドを投入する。WSLコンテナは統制されたLinux実行環境を提供し、MicroVMはハードウェア仮想化境界に直接依存する。リポジトリ内にはHyperlightやNanvixといった軽量バックエンドも併記されている。OSプロセスからハードウェアレベルの分離に至るまで、計算コストは潜在リスクの大きさに応じて段階的に引き上げられる。

暗黙の失敗や自己修復を禁止:エラーによるタスク中断を義務付け

従来の自動化スクリプトでは、サイレントなフォールバックや自動リトライが耐障害性の証とみなされることが多かった。しかしMXCは厳格な規範を打ち立てた。アクセス拒否に遭遇した際、エージェントは「現在の権限ではタスクを完了できない」というエラーをユーザーに明示しなければならない。失敗を隠蔽することはおろか、保護を回避するために迂回ルートを独自に模索することも固く禁じられている。

この設計は、自律的意思決定がはらむ危険な境界を明確に封じ込める。権限逸脱事故の多くは、エージェントが障害に直面した際に自己修復を試みる過程で発生する。エージェントから盲目的な自己回復権限を剥奪することで、タスクの制御権は常に人間の管理者の手に留まる。

大規模な組織運用を支えるため、このサンドボックスはエンタープライズインフラとも統合が進んでいる。Windows 365ではCloud PC上でマネージドエージェントを実行可能にしており、従業員のローカル環境の汚染を防ぐ。今後はMicrosoft Entraを通じてエージェントに個別IDを付与し、Intuneポリシーからサンドボックス制限を一括配布できるようになる見通しだ。

公式が提示したMXCのエコシステムパートナー一覧 図:MXCを先行導入および今後サポート予定の主要開発者ツールエコシステム。出典:Windows Developer Blog

15社のパートナーと連携:カーネルホワイトリストで再定義される実行規約

MXCの正式リリースと同時に、主要AIプログラミングプラットフォームは迅速に対応を完了させた。GitHub Copilot、OpenAI Codex、Replit、OpenClawはすでにこの実行レイヤーをネイティブサポートしている。Anthropic Claude Code、Manus、Raycastなど9つのツールも近日の統合を発表した。NVIDIAはOpenShellをMXCエコシステムに組み込み、動的なネットワークトラフィック遮断とOCSF規格のエンタープライズ監査ログ機能を提供している。

OS大手がプラットフォーム層で参入したことは、業界の評価基準に転換点が訪れたことを示している。これまでコミュニティはベンチマークの解決率ばかりに注目してきた。しかし企業への実導入においては、ゼロトラスト前提で物理的隔離を実行できるかが重要視されている。コード生成能力はモデルパラメータによって決まるが、エンタープライズ導入の広がりは基盤サンドボックスのセキュリティの厚みによって決まる。

黎明期のブラウザサンドボックスからモバイル端末の権限プロンプトに至るまで、エンジニアリングの歴史は同じ法則を証明してきた。信頼できない実行フローに対して、認知レイヤーの道徳的制約だけで対処することはできない。Windows 11におけるMXCの展開を通じて、マイクロソフトは業界全体に明確なメッセージを送っている。AIエージェントの能力拡張はもはや盲目的な信頼に委ねられるべきではなく、OSカーネルが定めるホワイトリストの枠内へと立ち返る必要がある。

参考リンク:

  • Windows Developer Blog 公式リリース告知
  • Microsoft Execution Containers アーキテクチャホワイトペーパー&技術仕様
  • GitHub microsoft/mxc オープンソースプロジェクト技術ドキュメント
  • NVIDIA OpenShell と MXC セキュリティ監査統合ソリューション