AIエージェントを社員のPCで動かす。GitHub CopilotやOpenAIのCodexがファイルを読み、コマンドを実行し、ネットワークにつなぐ。便利さは分かっているが、情報システムの担当者にはもう1つの問いが残ります。このエージェントが、触ってはいけないフォルダーを触ったり、社外に何かを送ったりしたとき、誰がどこで止めるのか。

エージェントの中に「これはしない」と書いても、それは約束であって境界ではありません。境界はエージェントの外に要ります。2026年10月7日にMicrosoftが一般提供を始めたMicrosoft Execution Containers（以下、MXC）は、その境界をOSの側に置く仕組みです。発表の中にこういう一文があります。An agent cannot be its own security authority。エージェントは自分自身の安全の決定権者にはなれない、という意味です。

この記事は、MXCの中身と、9月29日に一般提供になったWSLコンテナとの関係、そして情報システムがこの2つをどう使うかを書きます。読者は、社内でエージェントの利用を許すかどうかを決める立場の情報システム担当者と、その判断を求められる経営者です。確認日は2026年10月13日です。

結論を先に書きます。

  1. MXCは、エージェントが触れるファイル・ネットワーク・画面をJSONのポリシーで決め、OSの仕組みで制限する層です。 ポリシーはエージェントの外にあり、エージェントや生成コードが自分に権限を足すことはできません
  2. ただし、MXCの保護は、エージェントの側がMXCを組み込んでいるか、MXCの実行ファイル経由で起動するときに効きます。 情報システムが後から任意のエージェントに被せる道具ではありません。情報システムの手が届くのは、MXCに対応したエージェントを選ぶことと、WSLコンテナのようにIntuneとDefender for Endpointで管理できる側を先に押さえることです
  3. 自社で決められるものが増えました。 どのフォルダーを読ませるか、どこに通信させるか、画面を触らせるか。この境界を自社のポリシーファイルとして持つことが、エージェント時代の情報システムの資産になります

MXCとは何か

MXCは、信頼できないコードや、その場で生成されるコードを実行するための、ポリシー駆動の実行層です。Microsoftはこれを「封じ込め（containment）」の層と呼んでいます。エージェントにPCの操作を任せるとき、OSが答えるべき問いは3つあると発表は書いています。何にアクセスできるか、誰が実行したか、何をしたか。MXCが受け持つのは1つ目です。

仕組みは単純です。アプリケーションの側が、コンテナの種類、封じ込めの規則、動かすコマンドをJSONで宣言します。MXCは要求を検証し、OSに合ったバックエンドを選び、その中でコマンドを起動します。ポリシーはエージェントの外で管理されるので、エージェントや生成コードが自分に追加のアクセス権を与えることはできません。

対応OSはWindows 11、macOS、Linuxです。Windows 11は方式ごとに対応するビルドが決まっており、プロセス方式とセッション方式で必要な更新が違います。導入前にGitHubの対応表で確かめてください。SDKはRust、.NET、Node.jsの3つで、パッケージはcrates.ioのmxc-sdk、NuGetのMicrosoft.Mxc.Sdk、npmの@microsoft/mxc-sdkです。GitHubのmicrosoft/mxcでMITライセンスで公開されており、リポジトリを複製しなくてもパッケージの取得だけで使えます。SDKを組み込めない場合は、wxc-exec.exeのような実行ファイルにJSONの要求を渡して、対象のコマンドをMXCの中で起動する使い方もあります。

発表の著者はWindows Platform + Developer担当のCorporate Vice President、Logan Iyer氏です。MXCは2026年6月2日のBuild 2026で、SDKとして早期プレビューの提供が発表されていました。10月7日の一般提供は、その4か月後です。

4つの隔離方式。何を分離するかで選ぶ

MXCの中心は、共通の設定形式で書いた要求を、分離する対象が違う4つのバックエンドで動かせることです。実現できる制御と条件はバックエンドごとに違うので、同じポリシーがどこでも同じ効き方をするわけではありません。

MXCの4つの隔離方式を4段で示した図。プロセスコンテナー、セッションコンテナー、WSLコンテナー、MicroVMの順に、分離する対象と対応OSと用途が変わる

プロセスコンテナー。 Windows 11、macOS、Linuxで使える、いちばん軽い封じ込めです。応答の速さが要る作業向けで、WindowsではAppContainer、macOSではSeatbelt、LinuxではBubblewrapというOS標準の仕組みの上に乗っています。READMEによると、各OSの既定のバックエンドはこれです。分離するのは、ファイルとネットワークへのアクセスです。

セッションコンテナー。 Windows 11だけです。別のWindowsアカウントと別のセッションで動かし、デスクトップ、クリップボード、画面、キーボードとマウスの入力を、利用者のものから切り離します。長く動き続けるエージェントや、デスクトップを操作する自動化に向きます。利用者が仕事をしている画面と、エージェントが操作している画面が別になる、と考えると分かりやすいです。分離するのは、画面と入力です。

WSLコンテナー（WSLc）。 Windows 11だけです。WSLを通してLinuxの実行環境を用意します。Linux中心のツールチェーン、たとえばPythonやNode.jsの開発道具をそのまま使うエージェント向けです。後の節で書くWSLコンテナそのものが、ここで使われます。分離するのは、Linuxの実行環境です。

MicroVM。 Windows 11とLinuxで、実験的な扱いです。ハードウェアで強制される仮想化の境界を持ち、Linuxの作業を完全な互換性で動かせます。発表もREADMEも実験的と書いているので、今は評価の用途で見ます。

READMEには、このほかにWindows Sandbox、Hyperlight、LinuxのLXCがバックエンドとして載っており、Windows SandboxとHyperlightは実験的です。

どれを選ぶかは、扱うデータ、動かすコード、画面の操作が要るか、どこまでのリスクを許すかで決めます。ファイルを読んで答えを返すエージェントと、画面を操作するエージェントと、Linuxの道具を動かすエージェントでは、分離すべき対象が違います。この選択をエージェントの開発者だけに任せず、情報システムが「うちではこの方式で、ここまで」と言えるのが、この仕組みの価値です。

3つのモード。いきなり縛らない

ポリシーを書いても、最初から正しく書けることはありません。エージェントがどのファイルに触るかは、動かしてみないと分からないからです。MXCには、そのための3つのモードがあります。

MXCの3つのモードを並べた表。Enforcementは許可されていないアクセスを遮断、Learningは遮断して記録、Permissiveは許可して記録する。用途はそれぞれ本番、診断、ポリシー作成

モード 許可されていないアクセス 活動レポート 用途
Enforcement 遮断する なし 本番のポリシーで動かす
Learning 遮断して記録する あり 失敗の原因を調べる。最小限の権限で足りるかを確かめる
Permissive 許可して記録する あり ポリシーを作るときの観察。OSや組織の他の制限はそのまま効く

Learningは、本番と同じように遮断しながら、何を遮断したかを記録します。ポリシーを厳しくしすぎてエージェントが動かなくなったとき、どこで止まったかを見るためのモードです。制限を保ったまま調べたいときは、こちらを使います。Permissiveは、ポリシーで拒否するはずのアクセスも通して、記録だけを残します。まだポリシーが無い段階で、エージェントが実際に何に触るかを観察するためのモードです。封じ込めを緩めるので、信頼できる作業と検証用のデータで使います。

活動レポートはJSONで出ます。ただし発表には、この機能はWindowsのプロセスコンテナーだけで使える、とあります。macOSやLinux、セッションコンテナーやWSLコンテナーでは、同じ形の記録は今のところ取れません。

READMEには、これとは別に--auditという起動の指定があります。アクセスを許可しながら記録する開発者向けの入口で、Permissive系の実行経路を使います。信頼できる道具のプロセスコンテナー用のポリシーを作るためのもので、READMEは、--auditは解析対象の作業に対する封じ込めを全部外す、信頼できないコードには決して使うな、と書いています。

ポリシーで決める5つのこと

ポリシーで宣言できる項目は、発表とREADMEを合わせると5つにまとまります。

  1. 封じ込めの種類。 プロセスかセッションか、どのバックエンドを使うか
  2. プロセスの起動設定。 コマンド、引数、作業ディレクトリ、環境変数
  3. ファイルシステム。 変更してよい場所、読むだけの場所、触れない場所の3つに分けて指定します
  4. ネットワーク。 外向きと内向きの接続、ホストのループバック経由の通信を許すか。READMEのNode.jsの例では、外向きの通信の既定を拒否にする指定が載っています。通信先の制限はバックエンドによって条件が違います
  5. 画面。 デスクトップ、クリップボード、GUIへのアクセス

発表の例には、Gitのような開発道具へのアクセスを許可の対象にする、という記述もあります。

情報システムにとって大事なのは、この5つが、社内のセキュリティ規程の言葉にそのまま対応することです。どのフォルダーを読んでよいか。社外のどこに通信してよいか。社員の画面を操作してよいか。これまで文書で「してはいけない」と書いていたことを、JSONで「できない」に近づけられます。

MXCの要求には、使い捨ての形と、残す形があります。使い捨ては、用意と実行と片付けを1回で済ませます。残す形は、用意、開始、実行、停止、解放の5段階を別々に呼べて、同じコンテナを何度も使えます。どちらも、PCの再起動をまたいで残ることは保証されません。

WSLコンテナとは何か。9月29日に一般提供

MXCの4方式のうち、WSLコンテナーは、WSLそのものに9月29日に入った機能を使います。こちらは情報システムが直接管理できる側なので、分けて書きます。

WSLコンテナは、WindowsのPCでLinuxのコンテナを作り、動かし、配る機能です。コマンドはwslc.exeで、container.exeという別名でも同じ命令が通ります。Microsoft Learnの手順では、WSLのバージョン2.9.3以上が要件で、wsl --updateで入ります。エンジンを別に入れる必要はありません。

9月29日の発表で加わったものを並べます。

  • wslc container restart、wslc container cp、wslc system info
  • wslc network connectとwslc network disconnect。wslc network createで、ネットワークドライバーの任意のオプションを指定できる
  • wslc eventsで、コンテナの活動を実時間で流す
  • コンテナのヘルスチェック。wslc createとwslc runの--stop-timeout（-1で無期限）と--mount
  • 既定のwslcセッションの置き場を変えられる
  • WSLコンテナAPI。Windowsのアプリから、手元のAI処理のような用途でLinuxコンテナをプログラムから動かせる

Compose対応はまだです。発表は、いちばん多い要望だと書き、既存のcompose.yamlがそのままwsl compose upで動くことを目標に作業を始めた、としています。

情報システムに関わるのは、次の2つです。

Intuneの設定が2つ増えました。 「Allow WSL containers access」で機能そのものを有効か無効にでき、「WSL containers registry allow list」でイメージの取得元を許可したレジストリに限れます。WSLをIntuneで管理する既存の設定、たとえばWSL1を無効にする、デバッグシェルを無効にする、カーネルの差し替えを無効にする、といった項目と同じ設定カタログに並びます。

Defender for EndpointのWSLプラグインがコンテナを見られるようになりました。 Microsoft Learnのプラグインの文書は、従来のWSL 2のディストリビューションとWSLコンテナの両方に対応すると書いています。コンテナの中のプロセス、ファイル、ネットワークの活動を取り出し、Windowsのホストに結びつけます。Defenderのポータルでは、ホストの名前にアプリの名前を足した形で、WSLコンテナが別の端末として並びます。要件はWSLのバージョン2.9.12以上、プラグインのバージョン2.26.921.1、端末がDefender for Endpoint Plan 2に登録されていることです。ARM64のプロセッサーには対応していません。登録には最大30分かかり、短時間で終わるWSLコンテナはポータルに現れない場合がある、と同じ文書にあります。

MXCとWSLコンテナの役割を左右に並べた図。MXCはエージェントの開発者が組み込み、ポリシーで境界を決める。WSLコンテナは情報システムがIntuneで可否と取得元を決め、Defender for Endpointで中を見る

MXCとWSLコンテナの関係を、役割で分けるとこうなります。MXCは、エージェントの開発者が組み込んで、エージェントが触れる範囲を決める側。WSLコンテナは、情報システムがIntuneで有効か無効かと取得元を決め、Defender for Endpointで中の活動を見る側。MXCのWSLコンテナー方式を使うエージェントは、この両方の下に入ります。

対応しているエージェント。Claude Codeはこれから

製品に組み込まれたMXCの保護を使うには、その製品がMXCに対応している必要があります。発表の時点で対応済みなのは、GitHub Copilot、OpenClaw、OpenAI Codex、Replit、LM Studio、Unsloth AIです。NVIDIAはOpenShellをMXCに統合しており、ファイルや推論サービスへのアクセスのポリシー制御、ネットワーク制御、資格情報の管理、監査の記録を足しています。

これから対応すると発表に載っているのは、Anthropic Claude Code、Box、Egnyte、Heidi Health、Hermes Agent、Manus、Perplexity、Raycast、Simularなどです。

この一覧は、情報システムにとって選定の表です。社内で使いたいエージェントがMXCに対応していれば、OSの側で境界を引けます。対応していない場合、MXCの実行ファイルから対象のコマンドを起動する方法はありますが、互換性と起動経路の管理が自社の仕事になります。別の隔離の手段を選ぶこともできます。たとえばDockerのDocker Sandboxesは、手元の小さな仮想マシンでエージェントを隔離し、APIキーをホストの側に置いてサンドボックスに入れない仕組みで、Claude CodeやCodexに対応しています。当社はWSL上でこちらを先に試す予定です。

情報システムはどう使うか。6つの手順

ここからは、当社が情報システムの立場で考えた手順です。何をどの順で決めるかの話です。

情報システムがMXCとWSLコンテナを使うための6つの手順。エージェントの実態を棚卸しする、対応エージェントを選ぶ、WSLコンテナをIntuneとDefenderで押さえる、検証用の作業で観察する、Enforcementで縛る、Intune対応を待つ、の順に今日・標準の後・待ちの3つのレーンを進む

1. 今、社内で動いているエージェントを数える。 MXCの前に、社員のPCで何が動いているかを把握します。GitHub Copilotのエージェントモード、Codex、Claude Code、Cursor。会社が配ったものと、社員が自分で入れたものの両方です。Defender for Endpointを入れているなら、プロセスの一覧から拾えます。ここで数えたものが、次の手順の対象です。

2. 対応エージェントを選ぶ。 上の一覧と照らし合わせ、MXCに対応しているものを会社の標準にします。対応していないものは、対応を待つか、別の隔離の手段を決めるか、使わないかの3択です。標準を決める段階で、未対応の製品の扱いも一緒に決めておきます。すでに入っている製品についても、利用の停止や代替への移行を、この段階で検討します。

3. WSLコンテナをIntuneとDefenderで押さえる。 MXCのIntune対応より先に、WSLコンテナの側は今日から管理できます。Intuneの設定カタログで、WSLコンテナを許可するか、取得元のレジストリをどこに限るかを決めます。Defender for EndpointのWSLプラグインを配り、自社の実際の処理時間でコンテナの中の活動がポータルに出ることを確かめます。WSL1の無効化、デバッグシェルの無効化、カーネル差し替えの無効化は、Microsoft Learnが企業向けに推奨している既存の設定で、一緒に入れます。

4. 検証用の作業で観察する。 標準にしたエージェントを、Windowsのプロセスコンテナーで、ポリシーの変更と活動レポートの取得ができる構成で動かします。活動レポートが出るのはこの構成だけだからです。信頼できる作業と検証用のデータで、Permissiveモードで動かし、何に触るかを記録します。通常の業務と例外の処理を含む代表的な作業を一通り実行し、エージェントが実際に読んだフォルダー、つないだ先、使った道具を観察結果から拾います。制限を保ったまま調べたい作業は、Learningモードで動かします。ポリシーの候補は、この記録と業務上の必要性から書きます。

5. Enforcementで縛る。 観察から書いたポリシーをEnforcementモードにします。動かなくなった作業が出たら、Learningモードに落として、何が遮断されたかを見て、ポリシーを直します。ここで直したポリシーファイルが、会社の境界の正本です。文書の規程ではなく、動く規程です。

6. IntuneとEntraの対応を待つ。 発表には、Windows 11でMXC対応エージェントが使うプロセスコンテナーをIntuneのポリシーで管理できるようになる、と「近日」の予定で書かれています。Microsoft EntraがMicrosoft Agent 365の中でエージェントの活動と利用者の活動を区別できるようにする予定も「近日」です。ここが来ると、手順5のポリシーを端末ごとに配る形が変わります。来るまでは、ポリシーはエージェントの開発者が組み込む設定として持ちます。

6つのうち、1から3は今日できます。4と5はMXC対応エージェントを標準にし、プロセスコンテナーで動かせる構成を用意してからです。6は待ちです。

注意点

当社の環境でのMXCの動作検証は未実施です。 この記事は、Microsoftの発表、GitHubのREADMEと文書、Microsoft Learnの読み取りです。

MXCは情報システムが後から被せる道具ではありません。 READMEは、MXCはアプリケーションに組み込むSDKの依存関係だと書いています。社員が自分で入れたエージェントに、情報システムがMXCを強制する手段は、Intune対応が来るまでありません。手順2で標準を決めることが、今できる最大の手です。

Windows 11は対応ビルドが要ります。 方式ごとに必要な更新が違うので、導入前にGitHubの対応表を確かめます。

活動レポートはWindowsのプロセスコンテナーだけです。 発表にそう書かれています。macOSやLinuxのプロセスコンテナー、セッションコンテナー、WSLコンテナーでは、同じ形の記録は取れません。WSLコンテナーの中はDefender for Endpointで見る、という分担になりますが、短時間で終わるコンテナは現れない場合があります。

MicroVMは実験的です。 READMEと発表の両方に、実験的と書かれています。本番の境界として頼る段階ではありません。

--auditとPermissiveは封じ込めを緩めます。 どちらも、信頼できる作業と検証用のデータでだけ使います。

Defender for EndpointのWSLプラグインは、見るための道具です。 マルウェア対策、脆弱性管理、応答のコマンドは、WSLの論理端末には使えない、とMicrosoft Learnにあります。止めるのはMXCのポリシーとIntuneの設定の仕事で、プラグインは記録と検知の仕事です。

ポリシーを書く人が社内に要ります。 JSONのポリシーは、書いた人がいなくなると誰も直せません。手順4の観察記録と、手順5のポリシーファイルを、社内の共有の場所に置き、変更の理由を残す運用まで含めて決めてください。

KOIYALの見解

エージェントの安全の話は、これまで「エージェントに何を言い聞かせるか」の話になりがちでした。指示文に禁止事項を書く、確認を求めさせる、危ない操作は人が承認する。当社も自社の仕組みでそうしてきましたし、これからも要ります。ただ、それは約束です。約束は破れます。MXCが変えたのは、約束の外側に、指示文とは独立してOSの仕組みでアクセスを制限する境界を置けるようになったことです。境界にも脆弱性や設定の誤りはありうるので、無条件の保証ではありません。それでも、約束だけの状態とは違います。

当社がこの仕組みを情報システムの話として書くのは、境界を決めるのが情報システムの仕事になるからです。どのフォルダーを読ませるか、どこに通信させるか、画面を触らせるか。これはベンダーが決めることでも、エージェントの開発者が決めることでもありません。自社の業務と資料の置き場を知っている人が決めることです。インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）を目指す会社にとって、エージェントの境界を自社のポリシーファイルとして持つことは、エージェントを使うこと自体と同じくらい大事な資産になると当社は考えています。

まだ揃っていないものも多い。Intune対応は「近日」で、Claude Codeの対応はこれから、MicroVMは実験的。それでも、今日できることが3つあります。社内のエージェントを数える、標準を決める、WSLコンテナをIntuneとDefenderで押さえる。この3つは、MXCが揃うのを待つ理由にはなりません。

次の行動

  1. 社員のPCで動いているエージェントを、会社が配ったものと社員が入れたものに分けて書き出す
  2. 書き出したものを、MXC対応済み、対応予定、未対応の3つに分ける
  3. WSLを使っている部署があるなら、Intuneの設定カタログで「Windows Subsystem for Linux」を検索し、WSLコンテナの許可と取得元の設定を確かめる

3つが書けたら、それを持って相談に来てください。AI・DXコンサルティングの初回の打ち合わせでは、社内のエージェントの一覧から、どこに境界を引くかを一緒に決めます。お問い合わせの本文に、使っているエージェントの名前と、いちばん心配な操作を1つ書いていただければ、初回の前に当社で4つの隔離方式のどれが合うかを仮置きします。

参考