MXCでAIエージェントの行動範囲を制限できる

コーディングエージェントに「このリポジトリを直しておいて」と頼むとき、実行を許可するボタンを押す手が一瞬止まることがある。エージェントはリポジトリの外にあるファイルにも、ネットワークにも、普段使っているデスクトップにも、技術的にはアクセスできてしまうからだ。

止めたい操作だけを止める方法はないのか。Microsoftが2026年10月7日に正式リリースした「Microsoft Execution Containers(MXC)」は、この問いへの公式な答えになる。Windows Developer Blogの発表によれば、エージェントが触れてよいファイル・ネットワーク・画面をポリシーで指定できる。違反した操作は強制的にブロックされる。隔離の強さが異なる4つの実行環境から、作業の性質に応じて選べる設計だ。

なぜ二択しかなかったのか

これまでAIエージェントを動かす側は、2つの選択肢の間で揺れていた。公式ブログはこの状況を「制限なしで任せて祈るか、ブロックして生産性を失うかの二択」と表現している。全権限を与えて結果を祈るか、危なそうな操作を一律禁止して使い物にならなくするか、どちらかしかなかったということだ。

なぜ中間がなかったのか。公式ブログが挙げる例がわかりやすい。Webサイトを更新するよう頼まれたコーディングエージェントが、作業を早く終わらせるために本番サーバーの設定まで変更してしまう、というケースだ。この仮の例でのエージェントの判断は、与えられた目的(早く終わらせる)に対しては合理的だった。問題は、それが開発者の与えたつもりの権限を超えていたことにある。

公式ブログはここで一文を置く。“An agent cannot be its own security authority.”(エージェント自身が、自分の安全性の判断主体にはなれない)。自分は最初、「このリクエストは実行していいか」をエージェント自身に判断させればいいのではと考えていた。しかし上の例を読んで、エージェントは目の前の目的に対して合理的に動いているだけで、その合理性と開発者が許可したい範囲は別物だと気づいた。境界はエージェントの判断の外側に、独立して置く必要がある。MXCは、この境界を人間でもエージェントでもなくOSの側に強制させる仕組みになる。

では、その境界は具体的に何を指定できるのだろうか。

ポリシーで指定できる5つの軸

MXCのポリシーは、次の5つの軸で定義する。

• コンテナ: プロセス単位か、別アカウントのセッションかなど、隔離環境の種類
• プロセス: 起動するコマンド・引数・作業ディレクトリ・環境変数
• ファイルシステム: 変更可能な場所、読み取りのみの場所、アクセス不可の場所
• ネットワーク: 受信・送信できる接続先、ホストのループバック経由の接続可否
• ユーザーインターフェース: デスクトップなどの画面へのアクセス可否

公式ブログが挙げるコーディングエージェントの例では、対象のリポジトリへの読み書きとGitの利用だけを許可する。ユーザーのDocumentsフォルダー・ネットワーク・デスクトップへのアクセスは拒否する構成だ。先ほどの「本番サーバーを書き換えかねない」という例は、この構成なら最初から成立しない。ネットワークへの接続自体がポリシーで止まるからだ。

ポリシーは統一されたJSON形式のスキーマで書き、Rust・.NET・Node.jsのSDKから呼び出せる。公式ブログは、開発者自身がAIエージェントを使ってポリシーの初稿を作り、試しながら調整するという使い方も紹介している。

試しながら調整する、という工程を支えるのが3つの運用モードだ。

まずPermissiveでエージェントの動きを観察し、次にLearningで想定外の操作を洗い出す。問題がなければEnforcementに切り替える、という順で育てられる設計になっている。ただし、このアクティビティレポートは現時点でWindowsのプロセスコンテナでのみ利用できる。

5つの軸と3つのモードで「何を」制限するかは決まった。次に気になるのは、その制限を実際に強制する「箱」そのものの強さだ。

隔離の強さが違う4つの実行環境

公式ブログによれば、MXCは同じ「コンテナ」という言葉でくくられた4種類の実行環境(バックエンド)を用意している。どれも同じ強さの隔離ではなく、用途に応じた使い分けが前提になる。

表の中で一番発想が面白いのはセッションコンテナだ。プロセスを閉じ込めるのではなく、エージェント専用の別のWindowsアカウントを用意し、そのアカウントのセッションとして動かす。これだけで、デスクトップ・クリップボード・画面への入力・アクティブなセッションが、人間が使っている環境から分離される。長時間動き続けるエージェントに画面操作まで任せたい場合、プロセス単位の隔離だけでは防ぎきれない経路が残る。たとえば「クリップボードごしの情報の混入」のような経路も、アカウントを分けることでまとめて塞げる。

4つの中でどれが「正解」というわけではない。軽い処理はプロセスコンテナ、長時間動かすエージェントはセッションコンテナを使う。Linux向けツールチェーンはWSLコンテナ、一番リスクの高い作業はMicroVMという具合に、作業の性質で選ぶ設計になっている。公式ブログも、バックエンドごとにセキュリティ特性が異なるため、ワークロードごとに適合性を評価すべきだとしている。

ここまでで、何を・どの強さで制限できるかが分かった。残るのは、自分の環境でいつから使えるのかという点だ。

いつから自分も使えるのか

対応OSはバックエンドによって差がある。プロセスコンテナだけはWindows・macOS・Linuxの3つで使えるが、セッションコンテナとWSLコンテナはWindows 11専用になる。macOSやLinuxだけを使っている場合、選べるのはプロセスコンテナのみだ。

エージェント側の対応も、現時点で2段階に分かれている。公式ブログが名前を挙げているのは次のとおりだ。

• 現在対応しているパートナー: GitHub Copilot、OpenClaw、OpenAI Codex、Replit、LM Studio、Unsloth AI。NVIDIAはOpenShellをMXCに統合済み
• 今後対応を公開予定のパートナー: Anthropic Claude Codeを含む、Box、Egnyte、Heidi Health、Hermes Agent by Nous Research、Manus、Perplexity、Raycast、Simularなど

Claude Codeは後者の「今後対応予定」の一覧に名前があるだけで、公式ブログは現時点での対応を明言していない。自分が使っているエージェントがどちらに入っているかで、今すぐ試せるかどうかが変わる。

組織でまとめて管理する機能はまだ整っていない。Intuneによる管理ポリシーの配布は「近日提供」とされている。Microsoft Entraによるエージェントと人間の活動の区別、Agent 365によるオンデバイスのエージェント管理も「coming soon」で詳細は未発表のままだ。個人で試す分には、この2つを待つ必要はない。

実際に手を動かすなら、GitHubのmicrosoft/mxcリポジトリがMITライセンスで公開されている。Rust・.NET・Node.jsのSDKが、それぞれcrates.io・NuGet・npmで配布されている。SDKを使わず、実行ファイルにJSON形式のリクエストを渡す方法もある。対応パートナーのツールを使っていなくても、このSDKから自分のエージェントにポリシーを組み込める。

まとめ

MXCは、AIエージェントに「制限なしで任せて祈るか、ブロックして生産性を失うか」の二択しかなかった状態に、ポリシーで線を引くという第三の選択肢を公式に用意した。境界はエージェント自身の判断に委ねず、コンテナ・プロセス・ファイルシステム・ネットワーク・UIという5つの軸で指定し、OS側に強制させる。

隔離の強さが異なる4つの実行環境は、どれか1つが正解ではなく用途で使い分ける設計だ。なかでもセッションコンテナは、プロセスを閉じ込めるのではなく、別のWindowsアカウントごとエージェントに渡すという発想が目を引く。対応状況にはまだ差があり、セッションコンテナとWSLコンテナはWindows 11専用、Claude Codeは「今後対応予定」の段階にとどまる。自分が使っているエージェントとOSがどちらの対応段階にあるかを確認したうえで、GitHubで公開されているSDKから試すところまでが、今の時点でできることになる。