Microsoft Execution Containers(MXC)の機能と利用影響を整理する

Techカテゴリを表すパンダのイラスト プログラミング・Web開発

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。参照元の情報をもとに整理していますが、筆者による実機確認は行っていません。

検証ステータス:unverified(実機未確認)

Microsoft Execution Containers(MXC)は、AIエージェントや動的生成コードがアクセスできるファイルやネットワークなどの権限をOSレベルで制限し、一般提供(GA)として導入されたポリシー主導型の実行分離基盤です。開発者や管理者が定義した境界を外部から強制することで、エージェントが利用者の想定を超えた操作を行うリスクを低減させます。

なぜエージェント専用の実行境界が必要なのか

AIエージェントは、ファイル操作、コマンド実行、ネットワーク通信など、システム全体の多様なリソースを横断して自律的に作業を行います。しかし、エージェント自身にセキュリティの判断権限を持たせることはできません。モデルやツールがタスク達成のために「妥当」と判断した行動であっても、システム管理者が意図した権限範囲を逸脱することがあるためです。

一次情報では、ウェブサイトの更新を依頼されたコーディングエージェントの例が挙げられています。エージェントが変更のビルドやデプロイ状況を把握するために本番サーバーの設定情報を参照する必要がある場合でも、その設定ファイルを書き換える権限までは与えるべきではありません。実行境界が管理されていない環境では、エージェントが最短の手順として本番設定を書き換えてしまい、サービス障害を招く危険性があります。

MXCは、エージェントの内部判断とは独立したOS側のポリシーによって「参照は許可するが更新は拒否する」といった境界を強制し、万が一の誤動作や意図しない変更が発生しても影響範囲を境界内に封じ込める仕組みを提供します。

Microsoft Execution Containers(MXC)の全体像

MXCは、信頼できないコードやモデルが動的に生成したワークロードを実行するためのポリシー主導型レイヤーです。エージェント全体だけでなく、モデル生成コード、プラグイン、個別ツール、エージェントハーネスなど、任意の単位でコンテナ内に閉じ込めることができます。

開発者は統一されたJSON設定スキーマとマルチ言語SDKを利用してリソース要件を定義します。MXCはその要求をWindows、macOS、Linuxといった対象OS固有のサンドボックス機構へ自動的にマッピングするため、OSごとの個別実装を意識することなく同一のポリシーモデルを適用できます。

また、ローカルデバイスだけでなくWindows 365のCloud PC上でのMXC利用も一般提供されており、クラウド環境とローカル環境の双方で一貫したエージェント分離を行える点が一次情報に記載されています。

用途に応じた4つのコンテナバックエンド

MXCでは、ワークロードの性質やセキュリティ要件、要求される応答性に応じて複数のバックエンドが用意されています。

バックエンド提供OS適したワークロード主な特徴
Process containerWindows 11, macOS, Linuxモデル生成コードやツール実行など、低遅延が求められる軽量なワークロードWindowsではAppContainer、macOSではSeatbelt、LinuxではBubblewrapといった各OSのプロセスサンドボックスを利用する
Session containerWindows 11 のみデスクトップ環境を必要とする長時間稼働エージェントや自動化処理独立したWindowsアカウントとセッションで稼働し、デスクトップ、クリップボード、UI、入力境界が対話ユーザーから完全に分離される
WSL container (WSLc)Windows 11 のみLinuxのパッケージや開発エコシステムに依存するエージェントツールチェーンWSL(Windows Subsystem for Linux)を介してLinux実行環境を提供する
MicroVMWindows 11, Linux (実験的機能)ハードウェア仮想化による境界を必要とする高リスクなワークロードハードウェアによる分離と完全なLinuxワークロード互換性を提供する

特にSession containerはWindows 11限定のバックエンドであり、対話中のユーザー環境とエージェントのUIやクリップボードを完全に切り離して安全に自動化を実行できる点が特徴です。

ポリシーで制御できる5つの領域

エージェントが利用できるリソースは、OSが強制する境界としてMXCポリシーに宣言します。サインインしているユーザーの全権限をエージェントにそのまま委譲するのではなく、タスクに必要な最小限のリソースだけを割り当てます。

一次情報で示されているポリシー制御の領域は以下の5つです。

  1. Containment(コンテナ環境)
    プロセスコンテナやセッションコンテナなど、ワークロードを実行する分離バックエンドの種別を指定します。

  2. Process(プロセス設定)
    実行コマンド、引数、作業ディレクトリ、環境変数など、ワークロード起動に関する基本パラメータを定義します。

  3. File system(ファイルシステム)
    読み取りのみ許可するパス、書き込み・変更を許可するパス、アクセスを完全に禁止するパスを個別に指定します。

  4. Network(ネットワーク接続)
    インバウンドおよびアウトバウンドの通信可否を設定します。ホストのループバックインターフェース(localhost)経由の通信を許可するかどうかも含まれます。

  5. User interface(ユーザーインターフェース)
    デスクトップ画面やUI関連リソースへのアクセスや対話操作を許可するかどうかを制御します。

ポリシー作成と検証を支援する3つの動作モード

最小権限の原則に基づくポリシーを作成する場合、エージェントが必要とするすべてのリソースを最初から網羅することは容易ではありません。Windows上のMXCプロセスコンテナでは、エージェントのアクティビティレポートを生成して段階的にポリシーを洗練させるための3つの動作モードが提供されています。

動作モード未許可アクセスの挙動アクティビティレポート主な用途
Enforcementブロックなし本番環境での通常実行。設定されたポリシーを厳格に適用する
Learningブロックして記録あり失敗原因の診断と、過剰な権限を与えていないかの検証。未許可操作はブロックされJSONレポートに出力される
Permissive許可して記録ありポリシー策定前の調査。拒否対象のアクセスも許可しながら記録を収集する(OSや組織の他制限はバイパスしない)

Permissiveモードで動作を観察した後にLearningモードでブロック動作を確認し、最終的にEnforcementモードで運用するという段階的な適用が可能です。

エージェントのID識別と組織管理の連携

エージェントのガバナンスを成立させるためには、分離(Containment)に加えて「ID識別(Identity)」と「運用管理(Manageability)」の連携が不可欠です。

一次情報によると、Windowsでは今後Microsoft Entraとの連携が有効化され、Microsoft Agent 365においてエージェントの活動と人間のユーザーの活動を区別できるようになる予定です。エージェント単位で行動やリスクを評価できるため、特定のエージェントがポリシー違反を起こした場合でも、そのエージェントのアクセス権のみを遮断し、利用している従業員本人の作業やアカウント権限を停止させずに運用できます。

また、Microsoft Intuneによる管理ポリシーも近日提供される予定であり、IT管理者はWindows 11上でエージェントが要求するコンテナ作成の評価基準や、適用されるリソース境界を集中管理できるようになります。

エージェント開発側においては、組織ポリシーによって特定リソースが遮断された場合、サイレントに異常終了するのではなく、権限不足でタスクを完了できない理由をユーザーに明示したり安全な代替手段を選択したりする実装が求められます。

MXCの採用事例とエコシステム

MXCは既に主要なエージェントや開発環境で採用・統合が進んでいます。

  • NVIDIA: OpenShellをMXCに統合し、推論サービスやファイルへのアクセス制御、高度なネットワーク制御、認証情報管理、エンタープライズ向けのOCSF監査機能を提供。

  • 既存の対応ツール・フレームワーク: GitHub Copilot、OpenClaw、OpenAI Codex、Replit、LM Studio、Unsloth AI。

  • 今後対応予定のツール: Anthropic Claude Code、Box、Egnyte、Heidi Health、Hermes Agent(Nous Research)、Manus、Perplexity、Raycast、Simular など。

GitHub CopilotやReplitなどの開発支援ツールでは、プロジェクトリポジトリ内のコードやビルドツールの実行を許可しつつ、無関係な個人フォルダや外部ネットワークへの不正アクセスをMXCによって確実に遮断する構成が取られています。

まとめ

Microsoft Execution Containers(MXC)は、AIエージェントの自律的な実行権限をOSレベルで制御するための重要な基盤です。

導入にあたって考慮すべき要件と制約は以下の通りです。

  • 利用前の確認事項:

    • 対象ワークロードの特性に応じた適切なバックエンド(Process、Session、WSL、MicroVM)の選定。

    • エージェントが必要とするファイルパス、コマンド、ネットワーク接続先などの洗い出し。

    • LearningモードやPermissiveモードを活用したアクティビティレポートに基づくポリシー調整。

  • プラットフォームの制約と注意点:

    • Session containerやWSL containerはWindows 11のみ対応。

    • MicroVMバックエンドは現在実験的機能のステータス。

    • アクティビティレポート機能はWindows環境のプロセスコンテナに限定。

    • EntraによるID識別連携およびIntuneによる集中ポリシー管理は近日提供予定(ロールアウト待ち)。

    • 実機へのポリシー投入や挙動確認は未実施のため、環境固有の詳細な挙動は公式SDKやリポジトリのドキュメントを参照のこと。

参考情報

  • Microsoft Execution Containers: Policy-driven containment for AI agents: https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/

文書情報

記事タイトル
Microsoft Execution Containers(MXC)の機能と利用影響を整理する
作成日
更新日
Source URL
https://papanda925.com/?p=18021

ライセンス: 本記事のうち、当サイトが権利を有する本文・自作図表は、特記なき限り CC BY 4.0 で利用できます。生成AIを活用して作成・編集した内容を含みます。コードについて、別途ライセンス表示またはリンク先GitHubリポジトリのライセンスがある場合は、その条件を優先します。引用・第三者資料・画像・商標等は本ライセンスの対象外です。 利用ポリシー

タイトルとURLをコピーしました