Mxc: Microsoft Execution Containers バージョン 1.0.0

Microsoft Execution Containers: AIエージェントのためのポリシー駆動型コンテインメント Logan Iyer, Corporate Vice President, Windows Platform + Developer 著 2026年10月7日公開 エージェントは顧客に莫大な生産性向上をもたらしていますが、ファイル、ネットワーク、アプリケーションを横断して作業する能力は、新たなセキュリティリスクをもたらす可能性があります。これにより、顧客は、エージェントに無制限のアクセスを許可して何も問題が起こらないことを祈るか、ブロックして生産性上のメリットを失うかの二者択一を迫られているように感じることがあります。どちらの選択肢も許容できるものではありません。だからこそ、私たちはWindowsプラットフォームの機能を構築し、まずコンテインメント（エージェントがアクセスできるものや実行できるものを制限すること）、アイデンティティ（エージェントのアクティビティを個人のアクティビティと区別すること）、マネージビリティ（組織がアクセスを管理し、エージェントのアクティビティを監視するためのツールを提供すること）から、エージェントをより安全に実行・管理できるようにしています。現在一般公開されているMicrosoft Execution Containers (MXC) は、コンテインメントレイヤーを提供します。開発者やIT管理者は、エージェントが使用できるファイルやネットワーク宛先などのリソースを定義し、MXCは適切なコンテナを使用して実行時にそれらのポリシーを強制します。Windowsは間もなくMicrosoft Entraを有効にし、エージェントのアクティビティとユーザーのアクティビティを区別できるようにすることで、エージェントのアクセスに制限が必要な場合でもユーザーが生産性を維持できるようにし、Microsoft Agent 365のコントロールをローカルデバイス上のエージェントに拡張して、ITチームがMXCコンテナを管理し、ポリシーを適用し、エージェントのアクティビティを監視できるようにします。 なぜエージェントには管理された実行境界が必要なのか エージェントは、それ自体がセキュリティ権威を持つことはできません。それは、開発者または組織によって定義され、エージェント自体とは独立して強制される境界内で実行されなければなりません。ウェブサイトを更新するように依頼されたコーディングエージェントを考えてみてください。エージェントは、ウェブサイトリポジトリへの読み取りおよび書き込みアクセス、そして変更をビルドおよびテストするために必要な開発ツールへのアクセスを必要とします。アプリケーションがどのようにデプロイされているかを理解するために、本番サーバーの設定を読み取る必要があるかもしれませんが、その設定を変更することはできません。管理された実行境界がない場合、エージェントはタスクを完了するための最も速い方法としてサーバー設定を変更することが最善の策だと判断し、本番サイトを壊してしまう可能性があります。そのアクションは、エージェントの観点からは合理的であり、開発者が付与しようとした権限を超える可能性があります。コンテインメントは、その管理された境界を作成します。エージェントはリポジトリを読み書きでき、サーバー設定を読み取ることができますが、アクセスが付与されていない限り、他のものにアクセスすることは許可されません。エージェントがサーバー設定を変更しようとした場合、モデル、生成されたコード、プラグイン、またはツールが何を決定したとしても、コンテインメント環境はその操作を防ぐように設計されています。 Microsoft Execution Containers (MXC) とは何か？ Microsoft Execution Containers (MXC) は、信頼できないコードまたは動的に生成されたワークロードのためのポリシー駆動型実行レイヤーです。エージェントシナリオでは、開発者はMXCを使用して、モデル生成された出力、プラグイン、ツール、エージェントハーネス、またはエージェント全体をコンテインメントできます。これにより、問題が発生した場合の影響範囲をコンテインメントすることで、エージェントワークロードがアクセスできるものを制限します。開発者は、ファイルやネットワーク宛先などのワークロードが必要とするリソースを宣言し、MXCは適切なコンテナで境界を強制します。ポリシーはエージェントワークロードの制御外に残るため、エージェントまたは生成されたコードは追加のアクセス権を自身に付与できません。MXCはまた、ワークロード要件とプラットフォーム固有のコンテインメントの詳細を分離し、開発者エクスペリエンスを大幅に簡素化します。開発者は、統一されたJSON構成スキーマとマルチ言語SDKと統合し、MXCは要求されたコントロールをWindows、macOS、またはLinux上の選択されたバックエンドにマッピングします。開発者は、ローカルデバイスからクラウドまで、エージェントが実行する必要がある場所ならどこでも同じコンテインメントモデルを適用できます。Windows 365でMXCのサポートが一般公開されたことで、開発者はCloud PCで既存の作業と並行してエージェントを実行し、適切な分離モデルを使用してエージェント実行を分離して安全に保つことができます。 ワークロードに適したコンテインメントレベルを選択する さまざまなワークロードには、さまざまなレベルの分離が必要です。リポジトリで作業するコーディングエージェントは、低遅延と応答性を優先するかもしれませんが、機密データを処理するエージェントや信頼できないコードを実行するエージェントは、より強力な分離を必要とするかもしれません。MXCは、開発者や組織が各ワークロードに適切な分離レベルを選択できるように、さまざまなコンテインメントオプションを提供します。Windowsのみがセッションコンテナをサポートしており、これはユーザーのデバイス上で、独自のローカルエージェントIDと分離されたデスクトップ、クリップボード、UI、および入力境界を持つ、OS分離された別のセッションでエージェントを実行します。 バックエンドの可用性 最も適しているもの 重要な特徴 プロセスコンテナ Windows 11、macOS、およびLinux モデル生成コードやツール実行を含む、応答性の高いワークロードのための軽量コンテインメント。WindowsのAppContainer、macOSのSeatbelt、LinuxのBubblewrapを含む、プラットフォームに適したプロセスサンドボックスを使用します。 セッションコンテナ Windows 11のみ デスクトップまたは対話型ユーザーからのより強力な分離を必要とする、長時間実行エージェントおよび自動化。ユーザーからエージェントのデスクトップ、クリップボード、UI、入力、およびアクティブセッションを分離し、個別のWindowsアカウントとセッションで実行されます。 WSLコンテナ (WSLc) Windows 11のみ Linuxパッケージおよび開発エコシステムに依存する、Linuxファーストのエージェントツールチェーンおよびワークロード。WSLを介してLinux実行環境を提供します。 MicroVM Windows 11およびLinux、実験的 ハードウェアベースの仮想化境界からメリットを得る、リスクの高いワークロード。ハードウェアで強制される分離と完全なLinuxワークロード互換性を提供します。 各コンテインメントバックエンドは異なるセキュリティプロパティを持っており、ワークロードはコンテインメントバックエンドとの適合性を評価する必要があります。 MXCポリシーがワークロード境界を定義する方法 MXCは、ユーザーや組織がエージェントにより多くの作業を委任できるようにしながら、各タスクに必要なリソースに限定します。サインインしているユーザーの完全な権限をエージェントに与える代わりに、開発者やIT担当者はエージェントのワークロードの周囲にOSで強制される境界を定義できます。ウェブサイトのシナリオでは、MXCポリシーはコーディングエージェントにローカルソースコードリポジトリへの読み取りおよび書き込みアクセス、およびGitなどの必要な開発ツールへのアクセスを付与し、ユーザーのDocumentsフォルダなどの個人用場所へのアクセスをブロックすることができます。ポリシーはまた、インバウンドおよびアウトバウンドのネットワーク接続と対話型デスクトップへのアクセスをブロックすることもできます。 ポリシー領域 制御するもの コンテインメント ワークロードが実行される分離環境（例：プロセスまたはセッションコンテナ）。 プロセス ワークロードを開始するために使用されるコマンド、引数、作業ディレクトリ、環境などの設定。 ファイルシステム ワークロードが変更できる場所、変更せずに読み取ることができる場所、およびアクセスできない場所。 ネットワーク ワークロードがホストのループバックインターフェイスを介してサービスに接続できるかどうかを含む、インバウンドおよびアウトバウンド接続。 ユーザーインターフェイス ワークロードがデスクトップおよび関連UIリソースにアクセスまたは対話できるかどうか。 MXCサポートの追加は、エージェント開発者にとって簡単です。お気に入りのコーディングエージェントを使用してMXC SDKを統合し、初期ワークロードポリシーを作成してから、結果のコントロールを確認、テスト、および洗練することができます。 ワークロードと組織のポリシーが連携する方法 エージェント開発者は、エージェントワークロードが必要とする可能性のあるリソースを宣言します。組織はまた、Microsoft Intune管理ポリシーなどを使用して、追加の制約を管理ポリシーを通じて適用できます。これにより、同じエージェントが組織のセキュリティ体制をアプリケーションにエンコードする必要なしに、さまざまなエンタープライズ境界内で動作できるようになります。組織がコンテインメントを一貫して適用できる場合、その価値はさらに高まります。Intuneポリシーは、MXC統合エージェントによって使用されるMXCプロセスコンテナを管理するために間もなく利用可能になります。