Microsoft Execution Containers（MXC）を解説｜AIエージェントをOSで閉じ込める仕組み

Microsoftは2026年10月7日、AIエージェント向けの実行基盤「Microsoft Execution Containers（MXC）」が一般提供になったと発表しました。ファイルやネットワークなど、エージェントが使う資源をJSONポリシーで宣言し、OSに対応したコンテナが実行時に境界を強制します。

企業のIT責任者にとっての意味は、モデルの判断やプロンプトの工夫だけに安全性を委ねず、エージェントが動く環境の権限を最小化できる点にあります。開発用リポジトリには書き込めても、個人フォルダーや不要な通信先には届かない構成を、実行基盤の側で設計可能です。

MXCにはProcess、Session、WSL container、MicroVMの4つの分離方式と、Enforcement、Learning、Permissiveの3つの動作モードがあります。一般提供という言葉だけで本番採用を決めず、OS要件、ポリシーの作り方、資格情報や外部ツールの残余リスクを順に見ていくことが重要です。

※本記事は2026年10月16日時点の情報です。

AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。

MXC一般提供｜エージェントの権限をOSの実行境界で制限

AIエージェントは、依頼に応じてファイルを読み書きし、コマンドを実行し、外部サービスへ通信します。人が一つずつ操作するアプリと違い、モデルが生成したコードやプラグインが処理の流れに入ります。サインイン中のユーザー権限をそのまま渡すと、影響範囲が広がるためです。

MXCは、この問題をエージェントの外側に置く実行境界で扱います。開発者はワークロードが必要とするファイル、ネットワーク宛先、プロセス、UI資源を宣言します。MXCが適切なコンテナで制御するため、エージェントや生成コードが自分でポリシーを変更し、アクセス範囲を広げる構造ではありません。

たとえばWebサイトを修正するコーディングエージェントには、ソースコードリポジトリの読み書きとGitなどの開発ツールを許可します。一方、デプロイ先のサーバー設定は読むだけにし、ユーザーのDocumentsフォルダー、不要なネットワーク接続、対話型デスクトップは対象外です。エージェントが「最短の方法」としてサーバー設定を変更しようとしても、許可されていない操作は実行境界で止めます。

ポリシーは、分離環境だけでなく、起動するコマンドと引数、作業ディレクトリ、環境変数、読み取り専用と読み書き可能なパスまで扱います。ネットワークの入出力、ホストのloopback、デスクトップやUIへのアクセスも対象です。要求する資源を先に書き出すことが、導入作業の出発点です。

4つの分離方式｜速度・互換性・分離強度で選ぶ

すべてのエージェントを同じ境界で動かす必要はありません。短いコード実行を素早く繰り返す開発作業と、デスクトップを使って長時間動く自動化では、必要な分離の形が異なります。MXCは同じJSONポリシーとSDKを使いながら、ワークロードに合わせて方式を選べます。

Process containerは、WindowsのAppContainer、macOSのSeatbelt、LinuxのBubblewrapなど、各OSに合ったプロセスサンドボックスを使います。開発者の内側ループで応答性を保ちやすい反面、プロセス境界で足りるかをワークロードごとに判断しなければなりません。

Session containerは、エージェントをユーザーとは別のWindowsアカウントとセッションで動かします。デスクトップ、クリップボード、UI、入力、アクティブなセッションが分かれるため、ユーザーの画面を操作する長時間処理に向きます。WSLcはLinuxのパッケージや開発エコシステムを前提にした処理をWindowsで扱う選択肢です。

MicroVMはハードウェアで強制する仮想化境界を使い、より高い分離を求める処理を想定しています。ただし、Microsoftの発表では実験的な方式です。実験的機能を本番の基準にせず、対応OS、更新頻度、障害時の代替経路を含めて評価します。

3つの動作モード｜観察からEnforcementへ移す

最小権限のポリシーを最初から完璧に書くのは困難です。エージェントが実際にどのファイルや通信先を必要とするかを把握しないまま強制すると、正当な処理まで止まります。MXCは、必要な資源を洗い出す段階と、本番で境界を強制する段階を分けています。

Learningでは、ポリシーにない操作をブロックしたうえで、JSONの活動レポートに記録します。失敗した処理を再現し、アクセス先を一つずつ見直すモードです。許可範囲を広げる前に、エージェントがその資源を本当に必要とするか、別の処理で代替できないかを判断します。

Permissiveでは、ポリシーなら拒否する操作も進めながら記録します。処理全体を動かしたまま利用資源を集められますが、コンテナの境界を緩めるため、Learningと同じ安全性ではありません。Permissiveでも、別のOS制限や組織の制限を迂回できるわけではありません。

運用では、開発環境でLearningまたはPermissiveを使ってレポートを集め、ポリシーをレビューし、検証環境で再実行します。不要な許可を削った後にEnforcementへ移し、拒否されたときのエージェントの説明や人への引き継ぎもテストが必要です。活動レポートを生成できるのはWindowsのMXC process containerだけなので、OSが違う場合は別の観測方法も用意します。

導入前の確認｜ポリシーとID・監査を分けて設計

MXCを導入するときは、エージェントを閉じ込める仕組みと、誰が操作したかを追跡する仕組みの切り分けが必要です。Microsoftは、containmentはエージェントが何をできるか、identityはどのエージェントが実行したかを扱うと説明しています。Entraによるエージェント単位の識別やAgent 365による管理は、MXCの一般提供とは別に段階的に広がる機能です。

導入の最初に、エージェントごとの作業を資源へ分解します。読み取りだけのパス、書き込み可能なパス、実行コマンド、許可するネットワーク宛先、UI操作の要否を一覧化し、通常のユーザー権限から削る範囲を明確にする設計です。AIエージェントの権限管理では、個人ではないIDの扱いも別の論点になります。非人間IDの権限管理と合わせて、発行、棚卸し、停止の責任者を置きます。

• 対象資源：リポジトリ、秘密情報、生成物、ネットワーク宛先をワークロード単位で分ける。
• 分離方式：OS、UI、Linux依存、処理の機密度からProcessなどを選ぶ。
• モード移行：Learning／Permissiveの記録をレビューし、Enforcementの変更手順を決める。
• 周辺境界：MCP、資格情報、リモートサービス、監査ログをMXCの外側も含めて点検する。

MXCはすべての通信相手を安全にする機能ではありません。GitHub Copilotの公式解説でも、ローカルのシェルや一部のMCPと言語サーバーはプロセス境界内で動くと説明されています。組み込みファイルツールはアプリ内部のポリシー確認で、リモートMCPサーバーはローカルサンドボックスの外側です。MCPサーバーの公開範囲と認証は別に点検します。

公式READMEは、Windows Sandbox、MicroVM、Hyperlightを実験的バックエンドとし、--experimentalなどの指定が必要です。

Process containerの製品サポート下限はWindows 11 24H2（build 26100）です。23H2欄は実行時の強制能力を示す参考情報で、製品サポートの確約ではありません。

--auditはポリシー作成用で、実行中はAppContainerの制限が適用されません。本番の保護状態を測るモードにせず、AIエージェントのサンドボックス脱出のような境界逸脱時の停止運用を用意します。

Microsoft Copilotなど既存の業務基盤へ広げる場合は、対象ユーザー、データの分類、監査の保存先、エージェント停止時の業務継続を先に決めます。Microsoft Copilotの大規模導入で扱うようなコストや統合の判断に、OSレベルの実行境界と運用責任を加えるイメージです。

よくある質問

Q. MXCは何を制限しますか？

ファイルシステム、プロセス、ネットワーク、ユーザーインターフェースなど、エージェントが使う資源をJSONポリシーで制限します。

Q. 4つの分離方式はどう使い分けますか？

低遅延の実行はProcess、UIや入力の分離はSessionです。Linux向けツールチェーンはWSL container、高い分離を求める処理はMicroVMを候補にします。

Q. LearningとPermissiveの違いは何ですか？

Learningは未許可アクセスをブロックして記録するモードです。Permissiveはポリシーなら拒否するアクセスを許可しながら記録します。

Q. MXCだけでエージェントの監査は完了しますか？

いいえ。MXCは実行時の封じ込めを担うため、エージェントのID、資格情報、MCPやリモートサービス、監査ログの保存と分析は別に設計します。

まとめ

Microsoft Execution Containers（MXC）は、AIエージェントが触れるファイル、プロセス、ネットワーク、UIをポリシーで定義します。OSに対応した実行境界で制限する仕組みです。一般提供により、開発者は共通のJSON設定とSDKで方式を選べます。

企業が導入する際は、対象資源を洗い出し、ProcessやSessionなどの方式を選び、Learning／Permissiveで必要権限を集めてからEnforcementへ移します。MXCの外側にあるID、資格情報、MCP、リモートサービス、監査と停止手順も同じ設計書で管理することが、本番運用の条件です。

関連記事

• Claudeのサンドボックス脱出事例を解説｜AIエージェントの封じ込めと供給網リスク
• MCPサーバーのセキュリティ実態を解説｜21000台超が露出・92%認証なしの点検ポイント
• 非人間IDを解説｜AIエージェントの権限管理と監視のポイント
• Microsoft Copilotの大規模導入を解説｜コスト・統合と選定のポイント
• Agent Plugins 1.0を解説｜主要ベンダー横断のAIエージェント拡張規格と選定ポイント

▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。