MXCとは｜AIエージェント隔離の設定と限界

「AIエージェントに社内のファイルを触らせて大丈夫なのか」「どこまで許して、どこから止めるのかを誰が決めるのか」——エージェントを業務に入れようとすると、必ずここで止まります。

結論から言うと、2026年10月7日に一般提供になった Microsoft Execution Containers（MXC）は、「遮断」は今日から本当に効きます。ただし管理者が全社に配る面——Intune での集中管理、Entra でのエージェントと人の区別、Agent 365 との連携——はすべて「近日」で日付が公表されていません。今日ポリシーを書くのは情報システム部門ではなく、エージェントを作った開発者の側です。

株式会社Fyveは中小企業のAI導入を月額で伴走しており、私自身も無人のエージェントを常駐マシンで毎日動かしています。この記事では公式ブログと GitHub の一次ドキュメントを実際に開いて、何が本当にGAなのか、何がまだできないのかを切り分けます。二次報道と食い違った点は、食い違っていること自体を書きます。

MXC（Microsoft Execution Containers）とは何か

MXC は、公式の Windows 開発者ブログ（2026年10月7日）の言葉では「信頼できないコード、または動的に生成されたワークロードのための、ポリシー駆動の実行レイヤー」です。AIモデルが出力したコード、プラグイン、ツールのような「何をするか事前に分からないもの」を、OS側の境界の中で走らせるための仕組みです。

要点は、許可を書かなければ何も通らないという既定値にあります。GitHub の一次ドキュメントは「MXC のサンドボックスは既定で拒否（deny-by-default）」と明記しており、ポリシーが許可していないファイルやレジストリキーに触ると、アクセスは遮断され、OSは通常の「アクセスが拒否されました」を返します。

私が確認した事実関係を並べます。

• 発表日: 2026年10月7日（Windows / Surface のイベントに合わせた公表）
• 提供状態: Windows 11 で一般提供（generally available）。公式ブログの表現は「Today, Microsoft Execution Containers (MXC), becomes generally available on Windows 11」
• 公開形態: GitHub の microsoft/mxc でMITライセンスのオープンソース。SDK・スキーマ・ドキュメント・サンプルを同梱
• リポジトリの実測: 2026年2月6日作成、2026年10月8日時点でスター1,465（GitHub APIを自分で引いて確認した数字）
• 対応OS: Windows 11・Linux・macOS。ただし封じ込めの方式ごとに対応範囲が違う（後述）

「2月に作られたリポジトリが10月にGA」という時間軸は、これが急ごしらえの発表ではなく、半年以上回してから出てきたものだと分かる程度の材料になります。

何の流れで出てきた機能なのか

同じ10月7日、Microsoft は Windows を「ハイブリッド インテリジェンス」の器にすると発表しました。Copilot が端末のファイルや直近の操作を文脈として読み、Windows 上で操作を代行し、端末側で動くモデルを使う——この3つです。公式ブログは順に Local Context・Local Actions・Local Models と呼んでいます。

ここで要約が出回る過程でずれていた点を1つ正しておきます。この機能について「外部送信の前に承認を求める」という整理を見かけますが、公式ブログがユーザーの許可について書いているのはそこではありません。原文は「With your permission, Copilot will be able to use local context from your PC, take action on your behalf, and tap into local models」で、許可の対象は端末の文脈を読むこと・代行して操作すること・端末のモデルを使うことです。データが端末の外へ出る場面を承認制にする、という記述は当該ページにはありません。

この差は小さく見えて、社内説明では結論が変わります。「外に出る前に必ず止まる」と説明してしまうと、実際の挙動と違ったときに信頼を直接損ねます。

なお Copilot 側のハイブリッド機能は、公式の表現では「今後数か月のうちに Copilot+ PC へ順次展開が始まる見込み」で、「提供状況と時期は、デバイス・市場・シリコンプラットフォームによって異なる可能性がある」と添えられています。今日すべての端末で使えるようになったわけではありません。GAになったのは MXC の封じ込めレイヤーの側です。

ハードウェア側では、同時に発表された Surface Laptop Ultra が最大128GBのユニファイドメモリを積み、1,200億パラメータを超えるモデルを端末内で動かせるとされています（価格は 2,599ドルから・提供開始は10月16日、2026年10月8日時点の公表値）。購入を検討する場合は、必ずその時点の公式製品ページで条件をご確認ください。

MXCで縛れるものは3つ

一次ドキュメントが挙げているポリシーの対象は、次の3種類です。

• ファイルシステム: 読み取り専用・読み書き・拒否、それぞれのパス一覧で指定する
• ネットワーク: 外向き（egress）と内向き（ingress）を方向別に指定する。プロキシ経由にもできる
• UI: クリップボード・画面表示・GUIへのアクセスを制御する

3つ目のUIは見落とされがちですが、画面を操作させる型のエージェントでは本質的な項目です。クリップボードを渡すかどうかは、それ自体が情報の経路になります。

封じ込めの方式と、対応OSが同じではないこと

MXC は1つの方式ではなく、強さの違う複数の「背後の実装」を同じポリシーの書き方で選べる構造になっています。ここで方式ごとに対応OSが違う点は、設計前に押さえておく価値があります。

つまり3OS対応と言えるのはプロセスコンテナだけで、常駐エージェントをデスクトップごと分けたい用途は現状 Windows 11 に限られます。

本題1｜「止める」と「記録する」は二者択一ではない

ここが本記事でいちばん伝えたい点です。

MXC の動作モードについて、「本番のモードでは活動レポートが書き出されない」「遮断は効くが何を止めたかの記録は出ない」という整理が流通しています。この整理だと、守りを取るか証跡を取るかの二択に見えます。実務ではかなり困る話です。

そこで GitHub の一次ドキュメント（docs/logging-access-denied.md）を開いたところ、実際には遮断を維持したまま記録する選択肢があります。一次は2つの能力を挙げ、「意味的に別物であり、混同してはならない」と明示的に注意しています。

前者について一次は「ワークロードは学習モードが無い場合と全く同じように振る舞いながら、何に触ろうとして失敗したかの記録を出す」ため「診断の補助として安全に使える」と書いています。守りを下げずに証跡が取れる、ということです。

有効化の入口も別です。

• 拒否して記録（遮断を維持）: ポリシーに {"processContainer": {"learningMode": true}} を書く
• 許可して記録（遮断が弱まる）: CLI で wxc-exec --audit --config <config> を叩く

一次は、この2つの能力名を processContainer.capabilities に直接書くことを大小文字を問わず拒否するとも書いています。矛盾したモードを同時に選んだり、security-sensitive な入口を迂回したりできないようにするためです。設定ファイルに手で書き足して回避する、という抜け道が最初から塞がれている設計です。

本題2｜「IT管理者向け」と書かれた経路が、いちばん防御を緩める

一次ドキュメントは、学習モードの使われ方を3つの流れに分けています。この表は誰が走らせるかと遮断が維持されるかが対応しており、そのまま読むと居心地の悪い結論が出ます。

3行目です。一次が「IT管理者」の流れとして示している入口は、既定で拒否を強制しなくなる側です。全社のエージェントが何に触っているかを棚卸ししようとすると、その棚卸しをしている時間帯だけ封じ込めが緩むことになります。

これは欠陥というより性質です。「何も止めなかったら、このワークロードは何に触るのか」を知るには、実際に触らせてみる必要があるからです。一次自身も permissiveLearningMode を「security-sensitive」と呼んでいます。

重要なのは、緩めたことが必ず痕跡として残る設計になっている点です。この能力が有効なときは必ず security warning が記録され、しかもライブラリは「埋め込み先プロセスの端末に黙って書き込むべきではない」として、呼び出し側に明示的に渡す形を取っています（Rust は Sandbox::warnings()、C# は RunResult.Warnings、CLI は実行後に標準エラーへ出力）。

そしてもう1つ、名前から誤解しやすい注意があります。--audit は「監査モード」という語感ですが、分析対象のワークロードについてサンドボックスの安全機構を切るフラグです。一次は信頼できないコードをこれで走らせてはならないと明記しています。「監査だから安全側だろう」と読んで本番に当てると逆になります。

本題3｜外向きの遮断はIPとポートで効く。ホスト名では効かない

ネットワークの一次ドキュメント（docs/backends/process-container/networking.md）を読むと、外向き通信の塞ぎ方がはっきり書かれています。

プロセスコンテナでは、コンテナのSIDに紐づく2つの強制手段が、起動ごとのUACプロンプト無しで適用されます。

• WFPによる外向きフィルタ: 既定で外向きの通信を遮断し、そのうえでIPアドレスまたは範囲・プロトコル・ポートで特定の宛先を許可または拒否する（IPv4・IPv6の両方）。明示的な拒否は常に許可に勝つ。ルールはそのコンテナにのみ適用される
• コンテナ単位のプロキシ: WinHTTP系のクライアントを、呼び出し側が用意したループバックのプロキシへ向ける。HTTP_PROXY・HTTPS_PROXY とその小文字版も設定される

ここで注目したいのは、許可の単位がIPアドレスとポートであって、ホスト名ではないことです。そして一次が推奨として挙げているのは、宛先を列挙する方式（Model 1）ではなくプロキシ経由のみに限る方式（Model 2）で、その理由を「封じ込めの境界は、直接インターネットに出る能力が存在しないことである」と説明しています。

私はこの設計判断に強く納得しました。宛先の一覧で塞ぐ発想は、どうしても開けておくしかない口から破れるからです。名前解決の口を残したまま宛先リストで絞っても、問い合わせるホスト名自体に情報を載せる経路が残ります。実際に起きた事例を別の記事で詳しく分解しています。

AI業務効率化AIエージェントの通信制限｜DNSに残る抜け道

MXC の推奨が「直接出る能力をそもそも持たせない」になっているのは、この形の穴を塞ぐには宛先リストの精度を上げても足りない、という同じ結論に立っているからだと読めます。

なお内向きについては、Windows が privateNetworkClientServer を双方向の1つの能力として扱うため、社内ネットワークと通信させたい場合は ingress.default を allow にする必要があり、それを有効にすると内向きのサーバー通信も一緒に許可されます。片方だけ開ける、ができない組み合わせがあるということです。

動く条件——「24H2なら大丈夫」では確認にならない

ここは二次情報が割れていた箇所なので、慎重に書きます。

私が見た報道では、ある記事が「Windows 11 24H2 の Enterprise と Pro から」と書き、別の記事が「25H2 に KB5124010、または 26H1 に KB5124006 以降」と書いていました。条件の指定方法そのものが食い違っています。

一次（docs/backends/process-container/os-version-support.md）は、版ごとにビルド番号で示しており、しかもプロセス分離とセッション分離で床が別です。

24H2 と 25H2 ではセッション分離のほうが高いビルドを要求します。「版は満たしているのにセッションコンテナだけ使えない」が起こり得る形です。この粒度は、私が見た二次情報のどれにも出ていませんでした。

そしてエディションの条件（Pro か Enterprise か）は、この一次ページには書かれていません。書かれていないことを「Home でも動く」とも「Home では動かない」とも読み替えないのが正しい扱いです。

実務上の確認手順はこうなります。版の名前で判断せず、端末の winver でビルド番号を見て、使いたい分離方式の列と突き合わせる。これなら報道の食い違いに左右されません。

今日できないこと——「近日」で日付が無い3つ

GAという言葉は強いので、ここを曖昧にすると導入判断を誤ります。公式ブログが「近日」として挙げているのは次の3つで、いずれも日付が公表されていません。

• Intune による集中管理: Windows 11 のプロセスコンテナに対する MXC のポリシーを、管理者が配って管理する面
• Entra によるエージェントと人の区別: エージェントの活動を、端末を使っている本人の活動と切り分ける仕組み
• Agent 365 の統制の拡張: 既存の統制を、端末上で動くローカルのエージェントへ広げる

この3つが揃っていないことの実務上の意味は1つに集約されます。今日、コンテナのポリシーを書いているのは管理者ではなく、エージェントを作った開発者です。組織として「このエージェントにはこの範囲」と決めて全台に配る、という運用は現時点では成立しません。

裏を返すと、すでに対応しているツールを使うなら、その作者が決めた境界を受け取ることになります。公式の Windows 開発者ブログが挙げている対応状況は次のとおりです（2026年10月8日時点）。

• すでに対応: GitHub Copilot・OpenAI Codex・Replit・LM Studio・Unsloth AI・NVIDIA（OpenShell 連携）
• 対応予定: Anthropic Claude Code・Box・Perplexity・Raycast ほか

導入検討の実務では、「MXC に対応しているか」と「どんなポリシーを既定で書いているか」は別の質問になります。前者はカタログで分かりますが、後者は実際に動かして記録を見ないと分かりません。ここで効くのが本題1の「拒否して記録」です。

Windows以外では黙って無視される

見落とすと事故につながる仕様があります。

学習モードの能力はWindows 限定で、AppContainer を基礎にした方式に適用されます。一次の表現は「他のプラットフォームでは、この能力を表す文字列は無視される」です。

つまり macOS や Linux で同じポリシーを使い回すと、エラーにならず、記録も出ません。設定したつもりで何も記録されていない状態になります。手元の Mac で書いたポリシーをそのまま Windows の常駐機へ持っていく（あるいは逆）運用をするなら、ここは必ず押さえておく箇所です。

「設定が効いていないことが、エラーではなく沈黙として現れる」のは、無人運用でいちばん厄介な壊れ方です。

無人でエージェントを回している側から見て、何が変わるのか

私は毎日、常駐マシンの上で無人のエージェントに定型作業をさせています。人が見ていない時間に動くので、境界は先に決めておくしかありません。実際に決めていたのは次の3つでした。

• 書き込める場所を1つに限る: 決めたディレクトリの外に書いた変更は、記録として残さず破棄し、通知を飛ばす
• 取り消せない操作は鍵の側で落とす: 削除の権限を、そもそも持たせる鍵から外しておく。指示で止めるのではなく能力として無くす
• 緩めたら必ず残る形にする: 一時的に広げた場合、広げたこと自体が記録に出るようにする

MXC が入って変わるのは、このうち1つ目と3つ目をOS側に移せることです。自前の見張りではなくカーネルが境界を強制し、緩めた事実は security warning として必ず残ります。自前で書いた関所は、書いた経路だけにしか効きません。そこをOSが持つのは率直に大きい変化です。

一方で2つ目は依然として鍵とアカウントの側の仕事です。MXC はファイル・通信・UIを縛りますが、「このAPIキーに削除権限を持たせない」はMXCの外側にあります。OSの封じ込めが入ったからといって、権限設計を省略できるわけではありません。

どの工程を手元で回し、どれをクラウドに残すかという前段の判断については、別の記事で整理しています。

AI業務効率化AIは全部クラウドに預けるな｜手元で回す工程の選び方

また、Copilot に画面操作そのものを任せる場合の設定と限界は、こちらで扱っています。

Copilot computer useとは｜設定と権限・限界

導入を検討する企業が、先に確認する5点

ここまでを実務の順番に並べ替えます。

• 1. 端末のビルド番号を見る。版の名前ではなく winver の番号で、使いたい分離方式の床を超えているか確認する。プロセス分離とセッション分離で床が違う
• 2. 使っているエージェントが対応しているか調べる。対応していなければ、MXC が入っていても関係がない
• 3. 遮断の記録が必要かを決める。必要なら「拒否して記録」を選ぶ。守りを下げずに証跡が取れるので、ここを二択だと思い込まない
• 4. 棚卸しの時間帯を織り込む。全台の実態を掴むために「許可して記録」を使うなら、その間は封じ込めが緩む。業務時間中に全台で走らせる運用にしない
• 5. 集中管理が要件なら、今日は満たせないと認める。Intune・Entra・Agent 365 の連携は近日で日付が無い。要件なら時期を待つ判断が正しい

5番目を曖昧にしたまま「Windows に統制機能が入ったので安心です」と社内に説明すると、後で必ず齟齬が出ます。入ったのは強制の仕組みで、配って管理する面はまだ来ていません。

よくある質問

MXCを入れれば、エージェントによる情報漏洩は防げますか

ファイル・通信・UIという経路については、既定で拒否から始まるぶん確実に硬くなります。ただし防げるのはポリシーで表現できる範囲です。許可した宛先の先で何が起きるか、許可したファイルの中身をどう使うかはMXCの管轄外です。鍵の権限設計と併せて考える前提の道具だと捉えるのが正確です。

「拒否して記録」と「許可して記録」は、どちらを使えばよいですか

本番で動かすものは「拒否して記録」です。遮断が維持されたまま、何に触ろうとして失敗したかが残るので、ポリシーを育てる材料になります。「許可して記録」は、立ち上げ時に必要な経路を洗い出す場面に限り、封じ込めが緩むことを分かって使うものです。

Windows 11 Home でも使えますか

一次のOS対応ページはビルド番号で条件を示しており、エディションの条件は書かれていません。報道側ではPro・Enterprise前提と書いたものもありました。確認できていない以上、使えるとも使えないとも言えません。実機の winver と、使うエージェント側の要件の両方で確かめてください。

macOSやLinuxでも同じように使えますか

プロセスコンテナは3OSに対応しますが、セッションコンテナとWSLコンテナは Windows 11 のみです。加えて学習モード（記録を取る仕組み）はWindows限定で、他のプラットフォームでは指定が無視されます。エラーにならないため、気づかないまま記録が無い状態になり得ます。

すぐに導入すべきですか、待つべきですか

すでにMXC対応のエージェントを使っていて、端末のビルドが足りているなら、「拒否して記録」で実態を観察し始めるのは今日からできて損がありません。一方、組織として全台にポリシーを配る運用が目的なら、管理面が揃うまで待つ判断が合理的です。

まとめ——GAになったのは「強制」、まだ来ていないのは「配って管理する面」

2026年10月7日に一般提供になった MXC は、エージェントに何を触らせるかをOS側で、カーネルに強制させる仕組みです。既定で拒否から始まり、ファイル・通信・UIを方向まで含めて縛れます。自前の関所が「書いた経路にしか効かない」のに対して、ここは質的に違います。

そのうえで、今日の実像を3点に絞ります。

• 守りと証跡は二択ではない。「拒否して記録」を使えば、遮断を維持したまま何を止めたかが残る。二次情報の「本番では記録が出ない」という整理は、一次を読むと選択肢を1つ落としている
• 「IT管理者向け」と示された棚卸しの経路は、封じ込めを緩める側。--audit は語感と逆に安全機構を切るフラグで、緩めた事実は security warning として必ず残る
• 管理者が配って管理する面は、日付未定で来ていない。今日ポリシーを書くのはエージェントの作者側。集中管理が要件なら待つのが正しい

新機能が出たときに最も危ういのは、「入った」と「使える」と「運用できる」を一つにまとめて社内に説明してしまうことです。この3つは別で、今回はそれぞれ到達点が違います。株式会社Fyveは、こうした新機能を自分たちの無人運用で先に踏んでから、お客様の環境でどこまで任せられるかを一緒に決めています。

本記事の数値・提供状況は2026年10月8日時点で公式ブログおよび GitHub の一次ドキュメントを確認したものです。導入判断の際は、その時点の公式情報を必ずご確認ください。