目次

AIコーディングエージェントが、失敗しているテストを修正するとします。プロジェクトを読み、ソースファイルを編集し、テストスイートを実行できる必要があります。しかし、その同じエージェントに、個人の文書を開く権限や、別のディレクトリにある認証情報を読む権限、見知らぬサーバーへファイルを送信する権限まで与えるべきでしょうか。

普段使っているWindowsアカウントでエージェントを動かすと、こうした権限がひとまとめに付与されがちです。1つのリポジトリへのアクセスだけで済む作業でも、結果としてはるかに広い範囲へアクセスできてしまいます。

Microsoft Execution Containers（MXC）は、この境界を明確にするための仕組みです。提供されたリリースレポートによると、MicrosoftはWindows 11でMXCの一般提供を開始し、エージェントがアクセスできるファイルやネットワークに制限を設定できるようにしました。2026年10月7日付のWindows Developerの発表では、これらのポリシーは実行時に適用されると説明されています。

実用上の変化は明快です。開発者は、AIモデルに与える指示とは別に、エージェントの動作範囲を定義できます。これは、エージェントに慎重に振る舞うよう頼むよりも、確かな基盤になります。

MXCはエージェントの実行をどう変えるのか#

従来のデスクトップアプリケーションは通常、起動したユーザーから引き継いだ権限で動作します。AIエージェントは、ターミナル、ブラウザー、ファイル操作、アプリケーション連携など、与えられたツールを通じてそれらの権限を利用できます。

ここにずれが生じます。ユーザーが許可するのは「フォルダーを整理する」といった成果である一方、ソフトウェアには無関係なデータまで変更できるアクセス権が与えられる可能性があります。

MXCは、エージェントを実行するための隔離環境を提供します。リリースレポートによると、エージェント全体をその環境内に配置することも、プラグイン、ツール、エージェントハーネスなどの個別コンポーネントを隔離することもできます。生成された成果物も、その環境内に保持できます。

これは、エージェントシステムの各部分が、それぞれ異なるリスクを持つため重要です。計画を立てるコンポーネントは、テキストを出力するだけでよいかもしれません。一方、生成されたコマンドを実行するツールには、より慎重に定義した境界が必要です。

報告されている機能には、アクセス制限、人間とエージェントの活動の分離、エージェントの操作の監視が含まれます。これらを組み合わせることで、開発者はエージェントができることを制限し、その操作をユーザー自身の作業と区別しやすくなります。

ただし、これらの機能はエージェントの判断が正しいことを保証しません。編集を許可されたファイルに対して、エージェントが有害な変更を加える可能性は残ります。

用途に応じた4つの隔離方式#

MXCは、すべてのエージェントを同じ種類のワークロードとして扱うのではなく、複数のバックエンドを提供します。リリースレポートでは、次の4つが挙げられています。

| バックエンド | レポートに記載された境界 | 適した用途 | |---|---|---| | AppContainer | Windows AppContainerによるプロセスの隔離 | コーディングエージェントや個々のツール実行 | | セッションコンテナー | アカウントと対話型セッションのリソースを分離 | デスクトップを操作する長時間稼働のエージェント | | WSLコンテナー（WSLc） | WSL内でのコンテナーベースの隔離 | Linux環境を必要とするワークロード | | MicroVM | ハードウェアレベルの隔離 | ハードウェアに裏付けられた境界を必要とするワークロード |

これらの選択肢は、作業内容と、問題が起きた場合の影響を踏まえて評価する必要があります。入手できるレポートには性能測定結果や完全な互換性一覧がないため、どれか1つを、あらゆる導入環境に最適な標準のバックエンドと断定する根拠はありません。

AppContainer：プロセスを制限する#

AppContainerは、Windowsに既存の隔離機構です。MXCではプロセス単位の選択肢として提供され、レポートではコーディングエージェントやツール実行向けに位置付けられています。

ローカルのプロジェクトを変更するエージェントを考えてみましょう。必要な作業範囲は、リポジトリ、一時ディレクトリ、選択した開発ツールで構成できるかもしれません。それ以外のユーザーファイルへのアクセスは、作業に役立たないままリスクを増やします。

この場合、作業を範囲の限られたツール操作として表せるため、プロセスの隔離が適しています。アプリケーションに具体的にどのような権限を付与できるか、またMXCを通じてどう設定するかについては、Microsoftのドキュメントで確認する必要があります。

セッションコンテナー：エージェントのデスクトップ操作を分離する#

長時間稼働するデスクトップエージェントには、別の要件があります。アプリケーションを操作し、画面上を移動し、対話型セッションを維持する必要があるかもしれません。

リリースレポートによると、セッションコンテナーはエージェントを別のアカウントで実行し、そのデスクトップ、クリップボード、ユーザーインターフェース、入力、アクティブなセッションを人間のユーザーから分離します。

この違いには意味があります。人間と同じセッションでデスクトップエージェントを動かすと、フォーカスの移動、クリップボードの上書き、意図しないウィンドウへの入力といった干渉が起こり得ます。

セッションの分離は、この種の問題に対処します。同時に、アプリケーションのセットアップ、認証、共有リソースへのアクセスを、エージェント専用の環境できちんとテストする必要があることも意味します。

WSLcとMicroVM：ワークロードに必要な境界を選ぶ#

報告されているほかの選択肢は、WSLコンテナーとMicroVMです。

WSLcは、Windows Subsystem for Linux内でコンテナーベースの隔離を提供します。MicroVMは、ハードウェアレベルの隔離を提供します。

検討すべきなのは、ワークロードを正常に動かしながら、各バックエンドで何を分離できるかです。Linuxでの開発作業とWindowsのデスクトップ自動化では、要件が異なる可能性があります。信頼できない入力を処理するツールには、小規模で管理の行き届いたリポジトリを編集するエージェントとは異なる境界が必要になるかもしれません。

どちらのバックエンドを選ぶ場合も、前提条件、対応するワークフロー、運用時の挙動を確認してください。発表だけでは、これらの詳細までは分かりません。

ファイルの権限は作業内容に合わせる#

「プロジェクトファイルへのアクセス」は明確に聞こえますが、プロジェクトに認証情報、非公開データ、デプロイ設定が含まれていると、話は変わります。

実用的なポリシーを作るには、まず、エージェントが読む必要のあるものと変更する必要のあるものを分けます。コーディング作業なら、たとえば次のように設定できます。

  • 作業対象のリポジトリへの読み取り・書き込みアクセス。
  • 別の参照用ディレクトリへの読み取り専用アクセス。
  • 一時ファイルと生成物を置く専用の場所。
  • 無関係な個人用フォルダーや認証情報ストアへのアクセスは禁止。

これは導入パターンの提案であり、MXCの設定構文や、すべてのバックエンドで指定できる制御の細かさを示すものではありません。そうした詳細はドキュメントで確認する必要があります。

それでも、原則は有用です。権限は、その時点の作業内容に合わせるべきです。エージェントがドキュメントを更新するだけなら、アプリケーション設定への広範な書き込みアクセスが本当に必要か、慎重に検討する必要があります。

実行後に何が起きるかも考えてください。出力ファイルは、コンテナーの外で誰かが開いたり実行したりすると、依然として害を及ぼす可能性があります。隔離環境は生成物を検査する場所にはなりますが、生成物そのものを信頼できるものにするわけではありません。

ネットワークアクセスには独自のポリシーが必要#

エージェントには、モデルプロバイダーへの接続、依存関係のダウンロード、社内サービスへの問い合わせが必要な場合があります。一方、制限のないネットワーク接続は、誤動作したり不正に誘導されたりしたエージェントに、データを外部へ送る経路を与えることにもなります。

そのため、MXCでネットワークアクセスをカスタマイズできるという報告は、ファイルの境界と同じくらい重要です。

初回の導入では、作業に必要な接続先を一覧にしてください。どのサービスがソースコードや文書の内容を受け取るのか、どのサービスがダウンロード専用なのかを明確にします。そのうえで、選択したバックエンドでMXCが何を強制できるかを確認してください。

「ネットワークポリシー」という記述だけで、ドメインによるフィルタリング、プロトコルの制御、暗号化された通信の内容の把握まで保証されると考えてはいけません。提供されたレポートでは、そうした機能は明示されていません。

目指すのは、テストできるポリシーです。エージェントが承認済みのパッケージ配布元にアクセスする必要があるなら、そのアクセスが機能することを確認します。次に、拒否されるべき接続を試し、その結果を確認してください。

隔離は被害を抑えるが、プロンプトインジェクションを解決するわけではない#

文書、Webページ、リポジトリ内のファイルには、エージェントを別の行動へ誘導する文章が含まれていることがあります。エージェントがその文章を指示として扱うと、ユーザーが依頼していない操作を試みる可能性があります。

実行時の制限は、その影響の一部を封じ込められます。境界が正しく設定され、適用されていれば、許可された範囲外の読み取りは失敗するはずです。

しかし、エージェントは許可されたアクセスを悪用する可能性もあります。機密文書を読み、その内容を許可済みのサービスに送信できる場合、隔離だけでは、その送信がユーザーの意図に沿うかどうかを判断できません。

このため、アクセス制御と操作の確認は、別々に考える必要があります。MXCは、操作可能な範囲を定義できます。その範囲内でも、重大な結果を伴う操作、特にメッセージの送信、共有データの削除、変更の公開については、アプリケーション側で適切に扱う必要があります。

サンドボックスのテストに成功したことは、境界が機能している証拠になります。その境界内で行われるすべての判断が安全だという証拠にはなりません。

提供済みの機能と、確認が必要な点#

2026年10月19日時点で、提供されたレポートは、MXCがWindows 11で一般提供されていると説明しています。また、Microsoft Intuneによる組織単位のポリシー管理も計画されていると報告しています。

この違いは慎重に扱ってください。ランタイムが一般提供されていても、発表された管理機能がすべて利用可能になっているとは限りません。

レポートでは、MXC対応に関連するパートナーとしてOpenClawとAnthropic Claude Codeが挙げられています。ただし、どの製品バージョンに連携機能が含まれるのか、標準で有効なのか、どのバックエンドに対応するのかまでは分かりません。

展開する前に、Microsoftと各パートナーの最新ドキュメントで、Windowsの要件、インストール手順、利用可能なバックエンド、ポリシー設定を確認してください。実際に導入する予定のバージョンで、連携が機能することを確かめる必要があります。

範囲を限定した1つの作業から始める#

最初のテストには、使い捨てのリポジトリでドキュメントを更新するなど、必要なアクセスを説明しやすいワークフローが適しています。

次の4つの手順で評価してください。

1. 成功条件を定義する。 エージェントが変更すべきファイルと、生成すべき出力を指定します。 2. 境界を設定する。 バックエンドを選び、必要なファイルアクセスとネットワークアクセスを設定します。 3. 拒否されるべき操作をテストする。 無関係なフォルダーの読み取り、ワークスペース外への書き込み、未承認の接続先への通信を試します。 4. 結果を確認する。 成果物と、失敗した操作を含む取得可能な活動記録を調べます。

最初のテストでは、認証情報や重要なデータを環境に入れないでください。作業が正常に進むことを確認したら、必要性が実証された場合に限って権限を追加します。

MXCの価値は、こうした運用の徹底にかかっています。設定可能な境界は、実際の作業内容に合い、想定どおりに動かない状況でもテストされてこそ役立ちます。

エージェントのワークフローを1つ選び、必要なアクセスを書き出してください。そして、使い捨てのWindows 11環境で、MXCが必要な作業を許可しつつ、その範囲外の操作をブロックすることを確認しましょう。

出典: https://www.publickey1.jp/blog/26/windowsaimicrosoft_execution_containersmxc.html

目次