AIエージェントに「触れてよい範囲」をつくる。Microsoft MXCが示す実行権限の設計
AIエージェントに「このリポジトリを直して」と頼むとき、どこまで触れてよいかは誰が決めるのか。モデルへの指示だけでは、作業中に呼び出すツールや生成したコードの動作まで確実に制限できない。Microsoftが10月7日に一般提供を発表したMicrosoft Execution Containers（MXC）は、その権限の境界を実行環境側に置く仕組みだ。
注目したいのは、AIの判断力を上げる機能ではなく、判断を誤ったときの影響範囲を狭める設計である。Hacker Newsでも話題になった今回の発表は、エージェントを職場のパソコンや開発環境で使い続けるための、地味だが欠かせない条件を示している。
「読める」と「書ける」を分けて渡す
例えば、Webサイトを修正するエージェントには、ソースコードの読み書きやビルドツールの実行は必要だ。一方、本番サーバーの設定は参照できても、書き換える必要はないかもしれない。MXCでは、ファイルの読み取り・書き込み、ネットワークの接続先、デスクトップへのアクセスなどをポリシーで指定し、コンテナが実行時に制限する。ポリシーはエージェントの作業領域の外にあるため、生成したコード自身が権限を増やすことは想定されていない。
Microsoftの公開資料によると、軽量なプロセスコンテナはWindows 11、macOS、Linuxに対応する。WindowsではAppContainer、macOSではSeatbelt、LinuxではBubblewrapなど、それぞれの環境に合う分離機構を使う。別のデスクトップやクリップボードを持たせるセッションコンテナと、WSLを使うコンテナはWindows 11向けだ。より強い分離を狙うMicroVMは実験段階であり、すべての方式が同じ保護を提供するわけではない。
まず観察し、必要な権限だけ残す
実務では、最初から必要なファイルや通信先を過不足なく列挙するのが難しい。MXCのWindows向けプロセスコンテナには、許可されない操作を遮断して記録する「Learning」と、操作を記録しつつ通す「Permissive」がある。後者はポリシー作成時の観察用で、未許可のアクセスを防ぐ運用モードではない。MicrosoftのGitHub上の説明も、監査用の設定ではサンドボックスの保護が無効になると警告している。
ここから得られる実践的な順序は明快だ。開発用のデータで必要な操作を調べ、読み取りと書き込みの範囲を分け、通信先を絞り、遮断を有効にした状態で作業を再現する。失敗したときは無制限の権限に戻すのではなく、何が不足したかを確認してから個別に許可する。秘密鍵、個人情報、本番環境への接続を含む作業では特に重要になる。
日本の現場で問われるのは運用の設計
MXCはSDKと設定スキーマを公開しており、Microsoftは複数のエージェント製品が対応すると説明する。ただし、製品名が対応一覧にあるだけで、その製品のすべての機能が常に同じ境界で動くとは限らない。導入時には、実際にどのプロセスやツールがコンテナ内に入り、認証情報とネットワークがどう扱われるかを確認したい。
また、エージェントの活動を人の操作から区別するMicrosoft Entraとの連携や、Intuneによる一部ポリシー管理は、発表時点では今後の提供予定だ。現在使える分離機能と、組織全体での管理構想は分けて評価する必要がある。
日本企業でも、AIにコード修正や資料処理を任せる場面は増えるだろう。そのときの問いは「エージェントを信頼できるか」だけではない。間違っても触れられない領域を、人が先に定義できるか。MXCの一般提供は、AIの仕事を広げるほど実行権限の設計が重要になることを、具体的な製品として示した。
出典：Microsoftの発表（2026年10月7日）、MXC公式リポジトリ、Hacker Newsでの議論。内容は2026年10月12日時点の公開情報に基づく。