WindowsにAI専用の実行環境「MXC」――ファイルやネットワークへのアクセスをどう制限する？

AI , , , , , ,

Microsoftは2026年10月7日、AIエージェントの操作範囲を制限する「Microsoft Execution Containers（MXC）」の一般提供を発表しました。AIエージェントとは、ファイルの編集やコマンドの実行などを、利用者に代わって進めるAIです。［1］

MXCは、AIに「触ってはいけない」と指示するだけでなく、実行環境の側でアクセスを制限する仕組みです。開発者や管理者が、読み取れるファイル、変更できる場所、利用できる通信などを決めます。

ただし、Windows上のすべてのAIアプリが自動的に保護されるわけではありません。アプリ側の対応と適切な設定が必要です。この記事では、公式資料をもとに仕組みを説明し、権限を絞った場合の独自試算と、制限が働いているかを確かめる操作例を紹介します。

MXCとは？AIの「作業場所」を区切る仕組み

MXCは、AIが生成したコードや、AIが使うツールを、アクセスが制限された環境で動かすための基盤です。AIモデルの出力に加え、プラグインやエージェント全体も対象にできます。制限を定めるポリシーは、その環境で動くAIが管理できない場所に置かれます。［1］

ポリシーとは、許可する操作や対象を定めたルールです。AIが「仕事を終わらせるには権限が必要だ」と判断しても、自分で許可の範囲を広げられない設計になっています。

建物に例えるなら、作業部屋の鍵だけをAIに渡す仕組みです。別の部屋へ入ろうとしても、AIの判断だけでは扉を開けられません。ただし、鍵を渡した部屋で何をするかは、別に確認する必要があります。

開発者は、ソフトウェア開発キット（SDK）を使って、この仕組みをアプリに組み込みます。Rust、.NET、Node.js向けがあり、10月7日には最初の安定版となるSDK v1.0.0が公開されました。Windowsに加え、LinuxやmacOSも対象です。［2］［3］

ファイルは「読み書き可」「読み取り専用」「アクセス禁止」に分ける

資料を読む権限と、資料を書き換える権限は、分けて与えられます。公式リポジトリでは、読み書きを許可する場所、読み取り専用にする場所、アクセスを禁止する場所を指定する機能が説明されています。［2］

例えば、Webサイトの修正をAIに任せる場合、作業用のコードは編集できるようにします。参考資料は読み取り専用にし、仕事に関係のない個人文書や秘密情報へのアクセスは禁止します。

対象の例設定する権限の例狙い
修正対象のコード読み書き可編集とテストを進める
仕様書や参考資料読み取り専用内容を参照し、原本の変更を防ぐ
本番用の設定ファイル必要な部分だけ読み取り専用運用環境を勝手に変更させない
APIキーや秘密鍵アクセス禁止認証に使う秘密情報を渡さない
個人の文書や写真アクセス禁止作業に無関係なデータを保護する

これは権限の設定を考えるための例であり、そのまま実行できる設定ファイルではありません。作業フォルダーにも、APIキーを保存したファイルが紛れている場合があります。フォルダー名だけで判断せず、中身を確認し、利用する隔離方式でどこまで制限できるかを確かめる必要があります。

独自試算：2万ファイルを丸ごと渡す場合と、400ファイルに絞る場合

必要なファイルだけを渡せば、AIがアクセスできる範囲を大きく減らせます。ただし、その削減率を、安全性の向上率とみなすことはできません。違いを数字で比べるため、次の仮定で計算します。

対象は、利用者の文書とコードを合わせた既存ファイル2万個です。このうち、作業用が200個、参考資料が200個、残りが1万9,600個とします。OSや開発ツールの動作に必要なファイルは、この集計に含めません。

比較項目すべての対象に読み書きを許可作業用と参考資料に限定
読める既存ファイル20,000個400個
書き換えられる既存ファイル20,000個200個
読み取り対象の削減率基準98％
書き換え対象の削減率基準99％

計算式は、読み取りが「1－400÷20,000＝98％」、書き換えが「1－200÷20,000＝99％」です。これは本記事で仮定した条件に基づく試算であり、MXCを使った実測結果ではありません。

ファイルの数を減らすだけでは十分ではありません。読める400個の中に顧客名簿や秘密鍵が1個あれば、その1個が大きな問題につながります。数を絞るとともに、重要な情報を渡さないようにする必要があります。

ネットワークは、外部への送信とPC内の接続を分けて考える

インターネットへの接続に加え、通信の受信や、同じPC内のサービスへの接続も確認が必要です。Microsoftの説明では、ネットワークのポリシーに、送受信とホストのループバック接続が含まれています。［1］

ループバックとは、同じPCで動くサービスへの接続です。「localhost」や「127.0.0.1」が代表的な宛先です。外部通信を止めても、PC内の別のサービスからデータを取得できる設計なら、そのサービスへのアクセス権限も確認する必要があります。

「特定の接続先だけを許可する」という制御に対応しているかは、隔離方式によって異なります。公式リポジトリでも、接続先のフィルタリングは方式に依存すると説明されています。必要に応じて、通信を仲介して制限するプロキシなどを組み合わせます。［2］

PC内で完結するファイル整理なら、外部通信を許可しない設計も選択肢になります。クラウドAIや外部の開発サービスを使う場合は、必要な通信を許可しておく必要があります。その際も、「接続できる相手」と「送ってよい情報」は別々に決めるべきです。

独自分析：「読み取り専用」でも情報の持ち出しは防げない

読み取り専用は原本の変更を防ぐ設定であり、内容の外部送信を防ぐ設定ではありません。どの情報を読めるかと、どの通信を使えるかを組み合わせて考えると、残るリスクが分かります。

以下は、同じ隔離環境で動くプログラムが、ファイルを読んで直接送信する場合を整理したものです。MXCの性能測定ではなく、権限の組み合わせに基づく分析です。

機密ファイルの読み取り外部への通信この経路での持ち出し
許可許可通信先や送信内容に追加の制限がなければ、持ち出しが可能
許可禁止直接の外部送信は止められる。ただし、出力など別の経路は確認が必要
禁止許可対象のファイルは取得できない。ただし、別途渡された情報は送信できる
禁止禁止ファイルの読み取りと直接送信の両方を止められる

例えば、顧客名簿を読み取り専用にしても、送信を許可すれば内容を外部に渡せます。接続を許可したクラウドサービスであっても、その情報を送ってよいとは限りません。

AIアプリが隔離環境の外で情報を読み、クラウドへ送る場合も考える必要があります。MXCでコードの実行部分だけを隔離しているなら、アプリ全体の通信まで制限したことにはなりません。利用者は、どの処理が保護の対象なのかを確認する必要があります。

3つの動作モード：「記録している」と「止めている」は違う

Permissiveモードは、本来ポリシーで拒否する操作も許可して記録するため、アクセスを制限するモードとは区別する必要があります。Microsoftは、次の3つの動作モードを示しています。［1］［4］

モード許可していないアクセス活動レポート主な用途
Enforcement遮断このモードでは活動レポートなし定めたポリシーに従って実行する
Learning遮断し、記録あり拒否された操作を調べる
Permissive許可し、記録あり必要な権限を調査する

活動レポートは、Windowsのプロセスコンテナー向けの機能です。この表の「なし」は、ほかの製品やOSにもログが存在しないという意味ではありません。

公式リポジトリでは、監査用の「–audit」を使う際に、信頼できないコードを実行しないよう注意を促しています。必要な権限を調べるために、制限を緩める機能だからです。ただし、Permissiveでも、OSや組織が別途設けた制限まで無効になるわけではありません。［2］［4］

作業が止まったときは、まずLearningで拒否された対象を調べる方法が考えられます。記録されたアクセスをすべて許可するのではなく、その仕事に本当に必要かを確認します。

隔離方式は主に4種類――一般提供でもMicroVMは試験的な段階

MXCが一般提供されたからといって、すべての隔離方式が同じ完成度や保護範囲に達しているわけではありません。Microsoftは、用途に応じて隔離方式を選ぶ設計を示しています。［1］

方式主な対応環境特徴
プロセスコンテナーWindows 11、macOS、Linuxプログラム単位で、軽量なアクセス制限を行う
セッションコンテナーWindows 11別のアカウントと作業画面を使い、利用者の操作環境から分離する
WSLコンテナーWindows 11Windows上でLinuxの実行環境を使う
MicroVMWindows 11、Linuxハードウェアを使った仮想化で隔離する。試験的な提供

短いコードを実行する場合と、画面を使って長時間の自動操作を行う場合では、必要な環境が異なります。方式の名前だけで選ばず、ファイルへのアクセス、通信、画面操作を、その方式でどこまで制限できるかを確かめる必要があります。

Windows 11なら使える？対応アプリとOSビルドの確認が必要

Windows 11を使っているだけでは、利用したい隔離方式の対応条件を満たしているとは判断できません。公式資料では、プロセス分離とセッション分離で、対応するOSビルドが異なります。［5］

Windows 11のバージョンプロセス分離の対応ビルドセッション分離の対応ビルド
24H226100.927826100.9550
25H226200.927826200.9550
26H226300.955026300.9550

表は、2026年10月9日時点で確認した公式の対応資料から抜粋したものです。24H2・25H2の「.9278」はKB5120998、「.9550」はKB5124010の更新資料に対応します。実際に利用できるかは、アプリ側の対応や端末の状態も含めて確認します。［5］

Microsoftは、GitHub Copilot、OpenAI Codex、OpenClaw、Replit、LM Studio、Unsloth AIなどを対応済みとして挙げています。一方、Anthropic Claude Codeなどは、今後の対応予定として区別しています。製品名が載っていても、使用中のアプリのバージョンや実行方法でMXCが有効になるかは、別に確認が必要です。［6］

IntuneによるMXCプロセスコンテナーの管理や、Entraと連携したエージェント活動の識別は、10月7日の開発者向け発表では近日提供とされています。MXC本体と企業向け管理機能では、提供時期が異なる点に注意が必要です。［1］

過去事例・競合比較：隔離の仕組みは以前からある。MXCは何を加える？

MXCの特徴は、既存の隔離技術を共通の仕組みで扱い、AIの実行処理に組み込みやすくすることです。AIの操作を制限する考え方そのものは、以前からあります。

Anthropicは2025年10月20日、Claude Code向けのサンドボックスを発表しました。同社の社内利用では、許可を求める確認が84％減ったとしています。ただし、これは確認回数の削減率であり、事故が84％減ったという数字ではありません。［7］

仕組み制限の設け方比較するときのポイント
MXCSDKとポリシーを通じて、各OSの隔離方式を利用対応アプリ、隔離方式、動作モードを確認する
Windows Sandbox分離したWindows環境を起動し、共有フォルダーや通信を設定既定では通信とクリップボード共有が有効
2025年に発表されたClaude CodeのサンドボックスOSの機能とプロキシで、ファイルと通信を制限確認回数の削減と、安全性の評価を分ける

Windows Sandboxも、共有フォルダーを読み取り専用にしたり、通信を無効にしたりできます。ただし、名前に「Sandbox」と付いているだけで通信が遮断されるわけではありません。公式資料では、初期設定で通信とクリップボード共有が有効になっていると説明されています。［8］

MXCは、WindowsではAppContainer、LinuxではBubblewrap、macOSではSeatbeltというOS側の仕組みを利用します。Claude Codeの過去の発表でも、BubblewrapとSeatbeltが使われています。違いを判断するには、名称よりも、どの処理を隔離し、何へのアクセスを制限するのかを確認する必要があります。［2］［7］

なお、上の表は仕組みと設定の比較です。同じ攻撃条件で安全性や速度を測った試験ではなく、どれが最も安全かを順位付けしたものではありません。

独自の確認例：7つの操作で、許可と拒否の両方を確かめる

対応しているという表示に加え、必要な操作ができ、不要な操作が止まるかを確かめると、設定が実際に働いているかを判断しやすくなります。以下は、作業用コードだけを編集できる環境を想定した、本記事独自の確認例です。

実際の秘密情報は使わず、テスト用ファイルと、自分で管理できる接続先を用意します。利用するアプリが、確認したい操作を隔離環境の中で実行していることも確かめます。

確認する操作この設計で期待する結果
1．作業用ファイルを読む成功する
2．作業用ファイルを編集する成功する
3．参考資料を読む成功する
4．参考資料を書き換える拒否される
5．アクセス禁止のテスト用ファイルを読む拒否される
6．許可していない外部接続先へ通信するポリシーに従って拒否される
7．許可していないPC内のテスト用サービスへ接続するポリシーに従って拒否される

通信が失敗しただけでは、制限が働いた証拠になりません。接続先が停止していたり、別のファイアウォールが遮断していたりする場合もあります。テスト用の接続先が正常に動いていることを確かめたうえで、ポリシーによって拒否されたかを確認する必要があります。

この7項目で期待どおりの結果が得られても、すべての攻撃に耐えられるとは限りません。例えば、フォルダー内のリンクが別の場所を指す場合や、外部ツールが別の権限で動く場合には、追加の確認が必要です。

読者への影響：便利さを保ちながら、失敗したときの被害範囲を絞る

MXCが制限するのはAIの行動範囲であり、AIの判断が正しいことまでは保証しません。編集を許可したコードを壊したり、読み取った資料を誤って解釈したりする可能性は残ります。

外部の文章に埋め込まれた指示でAIを誘導する「プロンプトインジェクション」も、別に考える必要があります。アクセス制限は、AIが誘導された場合の被害を抑える役割を果たします。文章の意味を正しく判断させるための対策や、成果物の確認も必要です。

個人で使うなら、まずは作業用フォルダーを分け、原本のバックアップを残すことから始められます。企業では、処理ごとの権限に加え、送信先、認証情報、活動記録まで確認する必要があります。

利点は、必要な作業を許可しながら、関係のないデータへのアクセスを減らせることです。一方、権限を絞ると、ツールの起動や必要な通信が止まる場合があります。止まった理由を調べ、必要な部分だけを許可する調整が欠かせません。

今回の発表では、AIに任せる仕事を増やしながら、AIの権限を利用者の権限から切り分けようとする動きに注目したいところです。導入時に「MXCに対応しているか」「何を隔離しているか」「どの制限を強制しているか」の3点を確認すると、実際にどこまで保護されるかをつかみやすくなります。

関連ページ

実行権限の制限と、AIが作ったコードの品質確認を組み合わせると、任せられる仕事を判断しやすくなります。

出典・参考資料

提供状況や対応条件は、2026年10月9日時点で確認した一次情報に基づきます。独自試算と確認例は、実測結果やMicrosoftの認証基準ではありません。

  1. Microsoft「Microsoft Execution Containers: Policy-driven containment for AI agents」（2026年10月7日）
  2. Microsoft「microsoft/mxc 公式リポジトリ」
  3. Microsoft「MXC SDK v1.0.0」
  4. Microsoft「Logging access denied」
  5. Microsoft「Windows OS-version support」、KB5120998、KB5124010
  6. Microsoft「ハイブリッド インテリジェンスを実現する Windows」（日本語版、2026年10月8日）
  7. Anthropic「Beyond permission prompts: making Claude Code more secure and autonomous」（2025年10月20日）
  8. Microsoft Learn「Use and configure Windows Sandbox」

タグ

Related Posts

コメントを送信

You May Have Missed