社員のPCでコーディングエージェントを動かすと、エージェントは社員本人と同じ権限でファイルを読み、コマンドを実行し、外部へ通信します。Documentsフォルダーの中身も、保存済みの認証情報も、原理的には届く範囲です。
この問題に対するMicrosoftの答えが、2026年10月7日にGA（一般提供）となった Microsoft Execution Containers（以下MXC）です。エージェントの外側に柵を作り、触れてよいフォルダー、通信先、画面操作の範囲をポリシーで固定します。
ただし、GAと言っても全部が完成したわけではありません。バックエンドごとに成熟度が違い、Claude Codeは「対応予定」の段階で、IntuneやEntraによる組織管理は「近日提供（soon）」とされる段階です。この記事は2026年10月時点の情報で、GAの範囲、ポリシー設計、既存手段との使い分け、導入の段取りまでを整理します。
この記事でわかること
- MXCが何を閉じ込め、何を閉じ込めないのか
- GAの範囲と、実験的（experimental）なまま残っている部分
- ファイル・ネットワーク・画面のポリシー設計と、3つの動作モードの使い分け
- Windows Sandbox、Dev Container、WSL、各エージェント標準のサンドボックスとの違い
- Intune未提供の今、社員PCに統制をかける暫定運用と導入前チェックリスト
MXCはエージェントの外側に置く柵を作るSDK
MXCは、信頼できないコードをポリシーで決めた範囲に封じ込めて実行するための基盤です。対象はモデルが生成したコード、プラグイン、ツール、エージェント本体のいずれも含みます。ポリシーはエージェントの外側に置かれるため、エージェント自身が権限を広げることはできません。
先に押さえておきたいのは、MXCが社員向けの単体製品ではない点です。公式リポジトリの説明どおり、アプリに組み込むSDK依存として提供されます。ライセンスはMITで、GitHub上でオープンソースとして公開されています。社員がMXCをインストールして使うのではなく、対応したエージェントが内部でMXCを呼び出す形が基本です。
「お願い」ではなく「OSが強制する境界」という違い
従来のエージェントの安全策は、多くが「確認ダイアログを出す」「プロンプトで禁止する」という、エージェント側の振る舞いに依存するものでした。エージェントが誤作動しても、プロンプトインジェクション（外部の文書やWebページに仕込まれた命令に従ってしまう攻撃）を受けても、境界は守られるでしょうか。依存型の安全策では、守られません。
MXCは境界をOSの機構で作ります。Windowsでは AppContainer、macOSでは Seatbelt、Linuxでは Bubblewrap という、各OSが持つ隔離機能に、共通のポリシー記述を割り当てる構造です。エージェントが許可されていないフォルダーを開こうとすれば、エージェントの意図に関わらずOSが拒否します。
情シスは「禁止か全面解放か」の二択をやめられる
開発部門が先にエージェントを使い始め、後から情シスが追いかける。そうなりやすい構図です。そこで必要になるのは、範囲を決めて許可する運用です。
MXCの公式ブログが示すコーディングエージェントの例が、そのまま設計の出発点になります。ローカルのリポジトリの読み書きとGitなどの開発ツールは許可し、Documentsフォルダー、ネットワークの送受信、対話型デスクトップは禁止する、という構成です。
GAの範囲はバックエンドごとに成熟度が違う
「Windows 11でGA」は正しい表現ですが、すべての機能がGAという意味ではありません。SDKとプロセスコンテナは3OS対応、セッションコンテナとWSLcはWindows 11のみ、MicroVMは実験的です。報道では「3OSでGA」とだけ書かれることがあり、そのまま社内展開の根拠にすると判断を誤ります。
4つのバックエンドと成熟度
公式ブログが整理しているバックエンドは次の4種類です。
| バックエンド | 対象OS | 仕組み | 成熟度 |
|---|---|---|---|
| プロセスコンテナ | Windows 11 / macOS / Linux | AppContainer、Seatbelt、Bubblewrap。軽量で、Windowsの既定 | 実験的の表記なし（GA範囲） |
| セッションコンテナ | Windows 11のみ | 別アカウント・別セッションで実行。デスクトップ、クリップボード、UI、入力を利用者から分離 | 実験的の表記なし（GA範囲） |
| WSLコンテナ（WSLc） | Windows 11のみ | WSL経由のLinux実行環境 | 実験的の表記なし（GA範囲） |
| MicroVM | Windows 11 / Linux | ハードウェアが強制する仮想化の境界 | 実験的 |
使いどころは、リスクの大きさで分かれます。数分で終わるコマンド実行や、リポジトリ内のテスト実行なら軽量なプロセスコンテナで足ります。一方、数時間かけて自走するエージェントがブラウザーやGUIアプリを操作する場合は、操作が社員の画面に影響しないセッションコンテナが向きます。
実験的なMicroVMは、検証用途までです。GAの範囲に入っていないものを、全社標準の前提に置くことはできません。
GitHubのREADMEには、公式ブログが整理した4種類より多くのバックエンドが載っています。Windowsには windows_sandbox、hyperlight なども実験的な選択肢として存在します。公式ブログも「バックエンドごとにセキュリティ特性が異なるため、ワークロードごとに適合性を評価する」と明記しています。
社内PCのOS棚卸しに使うビルド番号
プロセスコンテナとセッション隔離には、Windows 11の更新状況に依存する最低ビルドがあります。GitHubのドキュメントによると、必要なビルドは次のとおりです。
| Windows 11 | プロセスコンテナ | セッション隔離（isolation_session） |
|---|---|---|
| 24H2 | 26100.9278以上 | 26100.9550以上 |
| 25H2 | 26200.9278以上 | 26200.9550以上 |
| 26H2 | 26300.9550以上 | 26300.9550以上 |
| 26H1 | 28000.2804以上 | 28000.3086以上 |
この表はWindows 11の資産管理台帳と突き合わせる材料になります。Windows 10は表に載っておらず、対象外とみられますが、明記は確認できていません。Windows 10が残る環境は、MXC前提の統制設計から外して考えるのが安全です。
もう1点、Learningモード（後述）の記録は実行時の機能検出で可否が決まり、必須機能がないと backend_unavailable で失敗します。OSの更新が遅れたPCでは、この失敗が出ます。
対応済みのエージェントと対応予定のエージェント
公式ブログが「現在対応」としているのは、GitHub Copilot、OpenClaw、OpenAI Codex、Replit、LM Studio、Unsloth AIです。NVIDIA OpenShellはMXCに統合済みです。
Claude Codeは「対応予定（coming soon）」で、時期は公表されていません。一部の報道は対応を発表済みのように書いていますが、公式の対応済みリストにClaude Codeは入っていません。Box、Egnyte、Manus、Perplexity、Raycastなども同じ予定の側にいます。
Claude Codeを使う企業にとって、MXCは「今すぐ使える」ではなく「将来の選択肢」です。それまでの運用は後ほど扱います。
ポリシーは5つの領域で書き、3つのモードで詰める
ポリシー設計の要点は、最初から正解を書こうとしないことです。観察用のモードで実際の動きを記録し、そこから必要最小限の許可を逆算します。
ポリシーが制御する5つの領域
統一されたJSONスキーマで、次の領域を記述します。
- Containment（どの隔離方式で動かすか）
- Process（実行できるプロセス）
- File system（書き込み可、読み取り専用、アクセス不可）
- Network（送信と受信。ループバックも対象）
- User interface（デスクトップ、クリップボード、ディスプレイ）
組織側が、開発者の定義したポリシーに追加の制約を重ねられる設計になっています。エージェントの開発元が許可した範囲を、組織側でさらに狭められます。
READMEの最小コード例（Node）は次の形で、外向き通信を既定で拒否し、30秒でタイムアウトさせています。
import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';
const request: ContainerRequest = {
command: '...',
network: { egress: { default: 'deny' } },
timeoutMs: 30_000,
};
await spawn(request);スキーマ本体はリポジトリの schemas/stable/ にあります。READMEに完全なポリシー例は載っていないため、実際の設計時はスキーマと API リファレンスを読み込む必要があります。SDKを組み込めないツールには、JSONを渡して実行する wxc-exec.exe も用意されています。
3つの動作モードの使い分け
| モード | 未許可のアクセス | レポート | 用途 |
|---|---|---|---|
| Enforcement | 遮断 | なし | 本番 |
| Learning | 遮断して記録 | JSONで出力 | 権限不足の診断、最小権限の特定 |
| Permissive | 許可して記録 | あり | ポリシー作成時の観察 |
Permissiveは許可して記録するだけで、OSや組織の他の制限を回避する機能ではありません。また、アクティビティレポートの対象はWindowsのプロセスコンテナのみで、Enforcementでは出力されません。本番運用中の監査ログとしては使えない点に注意が必要です。
最小権限を決める手順
ポリシーの固め方は、次の順序が現実的です。
- 検証用PCで、Permissiveモードで代表的な作業（ビルド、テスト、Git操作）を実行し、アクセスの実態を記録します
- 記録されたレポートから、本当に必要なフォルダー、通信先、プロセスを選びます
- Learningモードに切り替え、2で絞ったポリシーで同じ作業を実行します。遮断された項目がレポートに出るので、必要なものだけ追加します
- 業務に支障がなくなった時点で、Enforcementに切り替えて展開します
READMEの --audit オプションには強い警告があります。解析対象のサンドボックス保護をすべて無効化するため、信頼できないコードに使ってはいけません。ポリシー作成用の観察は、必ず社内の検証環境で、信頼できるコードだけを対象に行います。
既存のサンドボックスとの使い分けと封じ込めの限界
MXCは既存の隔離手段を置き換えるものではありません。守りたい対象が違うため、重ねて使う前提で考えるのが正確です。
Windows Sandbox・Dev Container・WSLとの違い
| 手段 | 隔離の単位 | 向いている用途 | 弱点 |
|---|---|---|---|
| MXC | 1つのエージェントの実行。ファイル、通信、UIをポリシーで制御 | 社員PC上でエージェントを動かす | 対応エージェントが限られる。組織管理（Intune等）は近日提供予定 |
| Windows Sandbox | 使い捨ての軽量仮想マシン | 怪しいファイルの検証 | 日常の開発環境としては毎回作り直しになり不便 |
| Dev Container | 開発環境のコンテナ化 | 環境の再現性、依存関係の隔離 | エージェントの権限制御が目的ではない |
| WSL2 | Linux環境の分離 | Linux前提の開発、後述のClaude Code | ホストのファイルを許可すれば触れてしまう |
Dev Containerは、開発環境を揃えるための仕組みです。コンテナ内にマウントしたフォルダーはエージェントから見えますが、デスクトップやクリップボードまでは制御対象になりません。MXCはその領域まで制御対象に含められる点が設計目的として違います。Windows Sandboxは、MXCの実験的バックエンドの1つ（windows_sandbox）としても選択肢に入っています。
WSLについては、MXC側がWSLcとしてバックエンドの1つに内包しています。
Claude Codeを使う場合の現状
Claude Codeのサンドボックスは、ネイティブWindowsでは動作しません。WSL2内で実行すればBubblewrapで利用でき、WSL1は不可です。macOSはSeatbelt、Linuxは Bubblewrap を使います。
管理者は managed settings で sandbox.enabled、failIfUnavailable、allowUnsandboxedCommands: false を強制できます。サンドボックスを無効にできない構成を、配布する設定ファイルで固定できるということです。
ただし、Read、Edit、Write、WebFetchなどの組み込みツール、hooks、ローカルMCPはサンドボックスの外側で動きます。Claude Codeのセキュリティ設定の詳細はClaude Codeのセキュリティルール、全社導入の進め方はClaude Codeの法人導入で扱っています。
MXC対応前のWindows社員PCでClaude Codeを隔離するなら、現状の選択肢はWSL2かDev Container系です。GitHub Copilot CLIは、Windowsではプロセスコンテナを使い、/sandbox コマンドで設定できます。既定では作業ディレクトリだけが読み書き可で、他は主に読み取り専用かアクセス不可です。
封じ込めで防げないこと
境界を作ることと、被害が出ないことは別です。MXCが防ぐのは、未許可のファイルや通信先へのアクセスです。許可された経路の中で起きる事故は防げません。
具体的には、次のようなケースが残ります。
- 許可した外部サービスへ、プロンプトインジェクション経由で機密情報が送られる
- リポジトリ内の秘密情報（.envファイルなど）が、読み書き可のフォルダーにそのまま置かれている
- エージェントが対応していても、一部の機能がコンテナ外で動く
最後の点は具体例があります。Copilot CLIでは、シェルコマンドとローカルのMCPサーバー、言語サーバーは境界内で動きますが、組み込みのファイルツールはCopilot内部で動いており、OSの子プロセスによる分離ではありません。リモートMCPもサンドボックスの外です。
この限界は、ツール認可、機密データの取り扱いルール、高リスク操作への人間の承認と組み合わせて埋めます。多層防御の考え方はAIエージェントのハーネス設計とハーネスエンジニアリングが参考になります。Cursorを使う場合はCursorのセキュリティ設定も確認してください。
法人導入は統制機能の提供状況を前提に段取りを組む
MXCの組織管理機能は、2026年10月時点でまだ出揃っていません。この前提を知らずに「全社導入」を決めると、運用開始後に統制が効かない事態になります。
Intune・Entraによる管理は近日提供の予定
Windows 11のプロセスコンテナを管理するIntuneのポリシーは「近日提供（will soon be available）」とされ、提供時期は示されていません。提供されれば、管理対象デバイス全体でコンテナの作成とリソースへのアクセスを統制する想定です。
IDの面でも、Microsoft Entraでエージェントの活動と利用者の活動を区別する機能は「soon」とされ、Microsoft Agent 365の統制をオンデバイスのローカルエージェントへ広げる計画も同様に「近日」の位置づけです。いずれも提供時期は示されていません。
現時点では、MXCのポリシーを組織全体に一括配布して強制する仕組みは使えません。ここは、公式発表を待つ前提で計画に組み込む必要があります。
管理機能が出るまでの暫定運用
Intune提供前でも、次の組み合わせで統制の穴を狭められます。
- MXC対応済みのエージェントを選ぶ: 対応済みのCopilot CLIなどは、エージェント側の設定で既定のサンドボックスを有効にします
- Claude CodeはWSL2とmanaged settingsで固める: サンドボックスの無効化を許可しない設定を配布します
- ログの取り方を決める: MXCのレポートはEnforcementで出ないため、通信やファイルアクセスの監査はEDRやプロキシ側で補います
- テレメトリの同意を確認する: 送信できるのは公式Microsoftビルドのみで、実行ごとのオプトイン、Windowsユーザーの同意、管理ポリシーの許可が必要です。OSSビルドは送信しません
ログ収集の観点で補足すると、SIEMへの連携や集中収集の仕組みは、公式資料では確認できていません。監査要件が厳しい業種は、この点を確認が取れるまで導入判断の保留項目に入れてください。
エージェント導入の運用ルール、承認の流れ、事故時の対応といった「人の側の設計」は、ツールの機能とは別に必要です。AI駆動開発研修では、AIエージェントを安全に業務へ組み込むための運用ルールづくりを実務の形で学べます。
導入前チェックリスト
導入判断は、次の順で確認していきます。
- 対象PCのWindows 11のビルド番号が、必要な最低ビルドを満たしているか
- 使いたいエージェントが、MXCの「対応済み」か「予定」か（予定なら代替の隔離手段があるか）
- 使うバックエンドがGAか実験的か。全社標準にはGAのものだけを使う
- 検証PCでPermissiveとLearningを使い、業務ごとの最小権限を決めたか
- 本番はEnforcementにし、社員が許可範囲を広げられないことを確認したか
- 監査ログをMXCの外（EDR、プロキシなど）で確保できているか
- 機密情報が置かれたフォルダーを、許可範囲から除外できているか
- Intune、Entra連携の提供後に、設定を移行する計画があるか
MXC自体はMITライセンスのOSSで、利用料はかかりません。Windows 365で使う場合の課金は、確認できていません。
よくある質問
MXCは社員が自分でインストールして使うものですか？
違います。MXCはアプリに組み込むSDKで、対応したエージェントが内部で呼び出す形が基本です。社員向けの有効化手順の公式ガイドは、確認できていません。
Claude CodeはMXCで隔離できますか？
2026年10月時点では、公式が「対応予定」としている段階で、時期は未公表です。当面はWSL2でのサンドボックスとmanaged settingsによる強制が現実的です。
GAなら全バックエンドを本番で使ってよいですか？
使えません。プロセスコンテナ、セッションコンテナ、WSLcがGAで、MicroVMは実験的です。READMEにあるWindows Sandboxなども実験的な位置づけです。
MXCがあればプロンプトインジェクションは防げますか？
防げません。MXCは許可されていないアクセスを遮断しますが、許可した経路での情報漏えいは止まりません。ツール認可や人間の承認と組み合わせます。
Windows 10のPCでも使えますか？
Windows 11が対象で、必要ビルドの表にWindows 10は載っていません。Windows 10での動作は、公式に明記された情報を確認できていません。
まとめ
MXCは、社員PCでエージェントを動かすための封じ込めの土台として、導入を検討する価値があります。ただし今日の時点で全社標準にできる企業は限られます。
最初の一手は、Windows 11の資産棚卸しです。必要ビルドを満たすPCがどれだけあるかを確認し、並行して、使いたいエージェントがMXCの対応済みか予定かを仕分けます。そのうえで、検証PCでPermissiveからLearningへ進み、業務ごとの最小権限を実測で固めてください。
Intune・Entra連携が出るまでは、エージェント側の設定、WSL2、EDRやプロキシでの監査を組み合わせて統制を補います。MXCの提供状況は変わり続けるため、導入前に公式ブログとGitHubのリリースを確認する運用を組み込んでおくと、判断の更新が楽になります。
エージェントの隔離は技術だけで完結しません。どの業務にどこまで任せ、誰が承認し、事故時にどう止めるかという運用ルールがあって初めて、柵が意味を持ちます。当協会のAI駆動開発研修では、AIエージェントを安全に業務へ組み込む運用ルールの設計を扱っています。
