Microsoft Execution Containers (MXC)とは？AIエージェント向けOSサンドボックスの仕組み・分離モード・採用事例を解説

Microsoft Execution Containers（MXC、エムエックスシー）は、Microsoftが2026年6月2日のBuild 2026で発表した、AIエージェント向けのポリシー駆動型OSサンドボックスです。
開発者が「エージェントが触れていいファイル・ネットワーク・UI」をJSONポリシーで宣言すると、Windows・Linux・macOSそれぞれのOSネイティブなサンドボックスバックエンドが実行時にその境界を適用します。

本記事では、MXCの主要な分離パターン（early previewのプロセス／セッション分離、ロードマップ段階のマイクロVM／Linuxコンテナ）、TypeScript SDKとJSONポリシーの設計、Windows Sandbox・Hyper-V isolationなど既存技術との違い、GitHub Copilot CLI・NVIDIA OpenShell・OpenClaw等の採用事例、Microsoft Agent 365・Windows 365 for Agentsとの統合ロードマップ、料金と提供時期、そして企業がMXC世代に備える実務指針までを、2026年6月時点の公式情報で体系的に解説します。

Microsoft Execution Containers（MXC）とは？AIエージェントをOS側で囲い込むポリシー駆動サンドボックス

Microsoft Execution Containers（MXC、エムエックスシー）は、Microsoftが2026年6月2日のBuild 2026で発表した、AIエージェント向けのポリシー駆動型OSサンドボックスです。

Microsoft Build 2026のキーノートで発表（出典：Microsoft Official Blog）

正式名称は「Microsoft Execution Containers」、コードネームとして公式リポジトリ上で「MXC」と表記されています。Windows・Linux・macOSにまたがるクロスプラットフォーム実行レイヤーで、SDKはgithub.com/microsoft/mxcで早期プレビューとして公開されています。

MXCが従来のWindows SandboxやHyper-V isolationと根本的に違うのは、仕組みとしてVMを1台立ち上げるのではなく、「エージェントが何に触れてよいか」を宣言したポリシーをOSカーネルが実行時に強制するという設計思想です。

開発者やIT管理者が「エージェントは/home/agent/workだけ書き込み可、ネットワークはhttps://api.example.comのみ、クリップボード・ディスプレイは触らせない」といった条件をJSONで書き、その境界をWindowsのProcessContainer・LinuxのBubblewrap/LXC・macOSのSeatbeltといった、各OSのサンドボックスバックエンドが守ります。

つまりMXCは「エージェントを動かす仮想マシン」ではなく、「エージェントが暴れたときに被害が漏れない、薄くて速い実行レイヤー」と捉えるのが正確です。

MXCが生まれた背景——AIエージェントの「実行する手」をどう囲うか

2026年に入り、コード生成・ブラウザ操作・ファイル整理を自律的にこなすAIエージェントが本格的に普及し始めました。便利な一方で、「重要ファイルを誤って削除する」「資格情報をネットワークに送り出す」「ユーザーの画面を勝手にキャプチャする」といったリスクが現実的な問題として浮上しています。

MXCは、この問題に対して**「エージェントのモデル（脳）と、それが実際にOSを叩く実行レイヤー（手）の間に、OSが強制する境界を1枚はさむ」**という解で応えるものです。

AnthropicがClaude Codeで「brain（モデル＋ハーネス）」と「hands（サンドボックス）」を切り離す設計を取っているのと方向性は同じですが、MXCはOSベンダー自身がカーネルレベルで境界を提供する点でレイヤーが一段下です。

Microsoft Build 2026におけるMXCの位置づけ

MXCはBuild 2026のキーノートで発表された、Windowsを「AIエージェントの実行基盤」へ位置づけ直す戦略の中核機能です。同時に発表されたコンポーネントとMXCの関係を整理すると、それぞれの役割が見えやすくなります。

以下の表で、Build 2026のAIエージェント関連発表とMXCの位置づけを並べました。

Microsoft Build 2026で示されたエージェントプラットフォームの全体像（出典：Windows Developer Blog）

図に示されているとおり、ユーザーとエージェントの間に「Policy-based controls」が一段はさまり、その下にMXC SDK、さらにWindows 365 for AgentsをはじめとするインフラがWindows統制スタックを形成しています。

この対応関係を踏まえると、MXCは単独のセキュリティ製品ではなく、Microsoftが描く「Windows＋Microsoft 365＝AIエージェントのOS」というスタックの最下層、実行レイヤーの安全弁として組み込まれていることがわかります。

Project Solaraはエージェントが複数の場所・デバイスで動くためのagent-first platform / reference design（出典：news.microsoft.com Build 2026）

Project Solaraは、エージェントが badge・desk・cloud といった複数の場所・デバイスで動く「agent-first world」を見据えた chip-to-cloud のリファレンスデザインで、MXCはそのうち「実行レイヤーをどう包むか」を担います。

Agent 365がID・統制・監査の制御プレーンを担い、Windows 365 for AgentsがクラウドPCという受け皿を提供し、MXCがそのどちらの環境でも共通して使える「分離の仕組み」を担う構造です。

Microsoft IQはエージェントの「知る」レイヤーを担い、MXCの「できる範囲を制限する」レイヤーと役割が対をなす（出典：news.microsoft.com Build 2026）

Microsoft IQはWork IQ・Fabric IQ・Foundry IQを統合したナレッジ・グラウンディング基盤で、Web IQはそれをWebグラウンディングAPIとして拡張する位置づけです。エージェントが業務データ・分析基盤・モデル群・Webのそれぞれから「何を参照できるか」を提供する役割で、MXCの「参照したあと何ができるか」を制限する役回りと相互補完の関係になります。

MXCの正式な定義と公式の注意書き

Microsoft公式GitHubリポジトリ（microsoft/mxc）では、MXCを「信頼できないコード（モデル出力・プラグイン・ツール）をWindows・Linux・macOSで実行するためのサンドボックス化されたコード実行システム」と定義しています。

統一されたJSON設定スキーマとTypeScript SDKの背後で、OSネイティブのプロセスサンドボックスからフルVMまで複数のコンテインメントバックエンドを提供する設計です。

ただしリポジトリのREADMEには**「現状の段階では、本リポジトリの内容を安全境界として扱うべきではない」**という重要なディスクレーマが明記されています。

これは「機能としては動くが、ポリシー生成が現状では必要以上に許容的で、本番のセキュリティ境界としてはまだ早い」という意味で、企業導入を検討する段階では、GAのAgent 365による制御プレーンとDefender/Intuneのpublic preview機能を組み合わせ、監視・統制を段階的に補う前提で扱う必要があります。

MXCの主要な分離パターンと「composable sandbox spectrum」

MXCの中核は、**用途とリスクに応じて分離強度を動的に切り替えられる「composable sandbox spectrum（組み合わせ可能なサンドボックスのスペクトル）」**という考え方です。

Windows Developer Blogでは、early previewのプロセス分離・セッション分離と、ロードマップ段階のmicro-VM・Linuxコンテナ・Windows 365 for Agents統合を組み合わせるspectrumとして整理されています。

主要な分離パターンの全体像（early preview ＋ ロードマップ）

以下の表で、MXCの主要な分離パターンと用途を整理しました。

これらのパターンで重要なのは、「重さ＝安全度」と引き換えに「速さ＝開発者体験」を選べる点です。

Windows SandboxやHyper-V isolationが「VMを丸ごと1台立てる」前提の重量級だったのに対し、MXCはコーディング系の軽い用途ならプロセス分離、機密データを触る用途ならマイクロVMといった具合に、ユースケースごとに分離強度を変えられます。

加えて、micro-VMとLinuxコンテナは現時点でロードマップ段階です。評価導入を検討する企業は、プロセス分離とセッション分離の2つを当面のスコープとして扱うのが現実的です。

プロセス分離——軽量・高速、コーディングエージェント向け

プロセス分離は、MXCの主要な分離パターンのうち最も軽量で、実装としては最も成熟しているモードです。

エージェントが起動するプロセスに対して、ファイルシステムの読み書き範囲・ネットワークのアウトバウンド可否・UIへのアクセス可否を制限します。VMを立ち上げる必要がないため起動が高速で、コーディングエージェントのように「数秒で1コマンド実行→結果を受けて次へ」を繰り返す用途に向きます。

GitHub公式のChangelogによれば、GitHub Copilot CLIのローカルサンドボックスはこのMXCのプロセス分離を基盤として採用しており、macOS・Linux・Windowsで一貫した分離体験を提供しています。

Copilot CLIが実行するシェルコマンドは、ファイルシステム・ネットワーク・システム機能への許可されたアクセス範囲を超えにくい設計になっており、許可範囲外のファイルやネットワークに触れるリスクを抑えるための土台になっています（許可範囲内での破壊的操作は別途レビューやガードが必要）。

ただしプロセス分離は「カーネルは共有」の構造のため、カーネル脆弱性経由のエスケープに対しては境界として弱い側面があります。これがmicro-VMが後段で用意される理由です。

セッション分離——UI・クリップボード・入力デバイスから切り離す

セッション分離は、プロセス分離に加えて**「エージェントの実行をユーザーのデスクトップセッションから切り離す」**モードです。

エージェントが画面に表示されるUI要素を読み取ったり、クリップボードを盗み見たり、キーボード・マウスの入力を傍受したりできない状態で実行します。長時間動き続けるブラウザ操作エージェントや、ユーザーの作業画面の裏で動く自動化エージェントに向きます。

セッション分離が必要になる典型例は、UIスプーフィング攻撃（エージェントが偽の確認ダイアログを表示してユーザーに誤クリックさせる）の緩和です。エージェントの描画権限をユーザーセッションから切り離すことで、偽ダイアログを表示するリスクを抑える設計です。

加えて「ユーザーが別のアプリで作業中にエージェントが勝手にコピーしたデータを盗まれる」といったクリップボード経由の情報漏えいも、セッション分離下では発生しにくくなります（公式の文言は「mitigates UI spoofing / cross-session data leakage」で、完全防止までは謳っていません）。

画面に個人情報が表示される業務（ヘルスケア・コンタクトセンター・金融カスタマーオペレーション等）でエージェントを動かす場合は、プロセス分離だけでは画面要素やクリップボード経由の漏えいを完全には防げないため、Windows 365 for Agentsのような独立Cloud PC環境やセッション分離など、ユーザー環境から切り離した実行環境を検討する必要があります。

マイクロVMとLinuxコンテナ——ロードマップ段階の重い選択肢

マイクロVMは、ハイパーバイザーによるハードウェアレベルの分離を提供する、MXCの中で最も重量級の選択肢です。

公式リポジトリでは MicroVM バックエンドとして NanVix と Hyperlight が列挙されており、軽量なVMイメージで起動して「フルVMほど重くないが、プロセス分離より強い境界」を実現する位置づけになっています。サンドボックス回避（プロセス分離やセッション分離をすり抜けてホストOSに到達する攻撃）への対策として、機密データを処理するエージェントに割り当てる想定です。実装の詳細やCPU側のセキュリティ機能との連携範囲はREADMEと今後の発表を確認してください。

Linuxコンテナは、WSL（Windows Subsystem for Linux）経由でLinuxネイティブのML・データ処理パイプラインをMXCポリシー配下で動かすためのモードです。PythonベースのLangChainエージェントやHugging Faceモデルを使ったエージェントを、Windowsホスト側でMXCポリシーに従わせながら実行できます。

ただし両モードは本記事執筆時点（2026年6月）ではまだロードマップ段階で、early previewにも入っていません。評価導入を計画する場合は、Microsoft公式が予告する2026年下半期以降の追加発表を待つ必要があります。

サンドボックスバックエンドの一覧——OSごとの実装

MXCはJSONポリシーを統一フォーマットとしつつ、実際の分離処理はOSごとに最適なバックエンドへ委譲しています。

以下の表で、公式リポジトリで公開されている主要なバックエンドとプラットフォーム対応を整理しました。

注目すべきは、「実験的」とマークされたバックエンドが半数を占める点です。windows_sandbox、wslc、microvm、hyperlight、isolation_session、seatbeltの各バックエンドは実装途上で、本番ワークロードを直接走らせる前提ではありません。

公式READMEで「experimental flagなしで使えるstable one-shot backend」として挙げられているのはProcessContainer・Bubblewrap・LXCの3つで、それ以外は「動くが境界保証は今後の改善待ち」と理解しておく必要があります（stableに分類されたバックエンドであっても、READMEのsecurity boundaryに関する注意書きは引き続き適用されます）。

MXCのポリシーSDK——JSON schemaとTypeScript SDKで何ができるか

MXCの開発者向けインターフェースは、JSON schemaで宣言したポリシーをTypeScript SDKから呼び出すという構造です。

公式リポジトリのREADMEで公開されているサンプルを基に、SDKでどこまでできるかを整理します。

TypeScript SDK（@microsoft/mxc-sdk）の基本

SDKはnpmパッケージ「@microsoft/mxc-sdk」として配布されており、Node.js環境からインポートして使います。MXCの実行モードは「One-shot API」と「State-aware API」の2系統です。

One-shotは「1回のコマンド実行で完結する」用途向け、State-awareは「サンドボックスを長く起動しっぱなしにして、複数回のコマンドを送り込む」用途向けの設計です。

以下のコード例は、One-shot APIで「/tmp だけ書き込み可、ネットワーク全面禁止、30秒でタイムアウト」のポリシーを宣言してコマンドを実行する最小構成です。

import {
  spawnSandboxFromConfig, createConfigFromPolicy,
  getAvailableToolsPolicy, getTemporaryFilesPolicy
} from '@microsoft/mxc-sdk';

const tools = getAvailableToolsPolicy(process.env);
const temp = getTemporaryFilesPolicy();

const config = createConfigFromPolicy({
  version: '0.6.0-alpha',
  filesystem: {
    readonlyPaths: tools.readonlyPaths,
    readwritePaths: temp.readwritePaths
  },
  network: { allowOutbound: false },
  timeoutMs: 30_000
});

config.process!.commandLine = 'echo test';
const child = spawnSandboxFromConfig(config, { usePty: false });

このアプローチの利点は複数あります。

第一に、ポリシー定義とコード本体が分離しているため、エージェントの動作を変えずに「何を許可するか」だけを差し替えられます。ステージング環境ではネットワーク全面禁止、本番では特定APIだけ許可、といった切り替えが設定変更で済みます。

第二に、getAvailableToolsPolicy()やgetTemporaryFilesPolicy()のようなヘルパー関数が、環境変数からツール検索パスや一時ファイルパスを自動収集してくれるため、開発者が「Windows・Linux・macOSのどこにどのファイルがあるか」を意識せずにポリシーを書けます。

第三に、One-shotとState-awareの両方が同じConfigスキーマを共有しているため、「短いコマンドの繰り返しから始めて、必要に応じて長期サンドボックスに切り替える」といった段階的な移行が容易です。

State-aware APIのライフサイクル

長時間稼働するエージェントを実行する場合は、State-aware APIで明示的にライフサイクルを管理します。

以下の流れで、サンドボックスをプロビジョン→起動→コマンド実行→停止→廃棄と段階的に制御できます。

• provisionSandbox
  ディスクの確保・ベースイメージの準備など、起動前のセットアップを行う
  
  

• startSandbox
  プロビジョン済みのサンドボックスを起動状態にする
  
  

• execInSandboxAsync
  サンドボックス内でコマンドを実行。同一サンドボックスに対して何度でも呼べる
  
  

• stopSandbox
  実行を停止するが、サンドボックス自体は保持
  
  

• deprovisionSandbox
  サンドボックスを完全に廃棄し、リソースを解放

長時間稼働するブラウザ操作エージェントや、複数のスクリプトを連続実行するワークフローでは、毎回サンドボックスを立ち上げ直すと起動コストが効いてしまいます。State-aware APIは、この「サンドボックスを温めたまま使う」運用に対応する設計です。

JSONポリシーの主要項目

ポリシーは以下のカテゴリで構成されています。バージョン番号は記事執筆時点で「0.6.0-alpha」です。

• Filesystem Policy
  読み取り専用パス（readonlyPaths）と読み書き可能パス（readwritePaths）をリストで指定。エージェントはこれ以外のパスにアクセスできない
  
  

• Network Policy
  アウトバウンド接続の可否（allowOutbound）、許可ホストの絞り込み、プロキシ設定。「特定APIだけ叩かせる」用途で重宝する
  
  

• UI Policy
  クリップボード・ディスプレイ・GUIアクセスの制御。セッション分離と組み合わせて使う
  
  

• Process Policy
  実行コマンドライン、引数、環境変数、PTY（疑似端末）の有無
  
  

• Timeout / Lifecycle
  実行のタイムアウト（timeoutMs）、起動・停止フックなど

これらを組み合わせることで、「/workspace 配下のみ読み書き可、api.openai.com にだけ通信可、クリップボードは触らない、60秒でタイムアウト」のように、エージェントの権限を必要最小限に絞れます。

ただし公式リポジトリのDisclaimerでは「Windowsでは現時点で拒否パスリストとネットワークポリシーが未実装」「macOSではプロキシが未対応」「現在のポリシー生成は必要以上に許容的」と明記されています。本番投入時はポリシーをそのまま信用せず、Defender for Endpoint等の検知層と重ねるのが前提です。

対応OS・対応プラットフォーム

MXCはクロスプラットフォーム設計で、以下の環境で動作確認されています。

• Windows 11 24H2以降（25H2で検証済）
• Linux x64 / ARM64
• macOS ARM64 / x64（スキーマ0.6.0-alpha以降）
• WSL（WSLCバックエンド経由）

「WindowsのAIエージェントセキュリティ」と聞くとWindows限定の印象を受けがちですが、MXCはLinuxとmacOSにも対応する設計です。ただしバックエンドごとに成熟度や未対応制限は異なり（例：macOS Seatbeltはexperimental扱い）、「GitHub Copilot CLIのようなクロスプラットフォームエージェントが、開発者の端末OSを問わずMXCポリシーで動く」ことを意図しつつ、対応範囲は今後の改善で段階的に整っていく形です。

Microsoftが投資しているクロスプラットフォーム開発体験の方針と整合しており、エージェントの実行レイヤーを「Windowsだけのもの」にしない設計判断が見て取れます。

MXCと既存のサンドボックス・競合エージェント実行基盤との違い

MXCを評価するときに最も誤解されやすいのが、「これは新しいWindows Sandboxなのか」「Dockerと何が違うのか」という点です。

MXCはOSベンダーが提供する「ポリシー駆動の薄い実行レイヤー」であり、フルVMでもコンテナランタイムでもありません。この立ち位置を、Windows既存技術・競合エージェント実行基盤・専業サンドボックスプロバイダの3軸で整理します。

Windows既存の分離技術との位置関係

WindowsにはMXC以前にも複数のサンドボックス・分離技術が存在しています。

それぞれが想定するユースケースが違うため、「軽量だが境界が弱い」から「重量級で境界が強い」までグラデーションになっています。以下の表で、MXCを含めた既存技術の位置を整理しました。

この比較から分かるのは、MXCは「AppContainerより堅く、Windows Sandboxより軽い」中間レイヤーを埋める存在だという点です。

Windows Sandboxは「VMを丸ごと立ち上げる」前提のため、エージェントが1コマンド実行するだけのワークロードには明らかに重すぎます。一方でAppContainerは「ユーザーモードでの権限制限」止まりで、AIエージェントのように「何をするかコード生成時点では予測できない」用途には境界として薄い側面があります。

MXCはこのギャップを「OSカーネルが宣言ポリシーを実行時に強制する」という形で埋めます。Windowsコンテナのhypervisor isolationより軽く、AppContainerより堅く、JSONポリシーで宣言的に書ける——という位置取りです。

NVIDIA OpenShell・OpenAI Codex CLI・Claude Codeとの比較

MXCはAIエージェント向けサンドボックス領域でも単独の存在ではなく、複数の競合製品が並行して進化しています。設計思想の違いを整理すると、MXCの特徴がより鮮明になります。

特に差が出るのが「分離境界を誰が強制するか」の部分で、MXCはOSベンダー自身がポリシー駆動の薄い境界レイヤーをカーネルレベルで提供する代表的な選択肢です。

NVIDIA OpenShellはユーザー空間で動く複数の分離技術を選択する形、Codex CLIはOpenAI CLI内蔵の権限モード、Claude CodeはDevContainerやBubblewrapに依存する設計です。これらは「アプリ側で工夫して分離する」アプローチに対し、MXCは「OSが提供する分離APIをアプリが呼び出す」アプローチを取っています。

実務的にはMXCとOpenShellが競合に見えますが、Microsoftの公式発表によればNVIDIAはOpenShellのWindowsバックエンドとしてMXCを利用しており、「ユーザー空間のオーケストレーション層（OpenShell）＋OS強制の境界層（MXC）」という補完関係として整理されつつあります。

専業サンドボックスプロバイダ（Docker・E2B・Modal・Northflank）との違い

Docker、E2B、Modal、Northflankといった専業プロバイダも、AIエージェント向けサンドボックスを提供しています。

ただしこれらはクラウド側のリモートサンドボックスが主戦場で、MXCのローカル＋OS統合とは設計の出発点が違います。以下の点で住み分けが見えます。

• デプロイ先
  専業プロバイダ：クラウド上のリモート実行環境。ユーザーのコードをサーバーに転送して動かす
  MXC：ユーザーのローカルPCまたはWindows 365 Cloud PC。Defender・Entra・Intuneとの統合を活かす
  
  

• ID・統制との接続
  専業プロバイダ：独自IDか各社のSSO統合
  MXC：Agent 365 / Windows統合を通じてEntra ID・Intuneポリシー・Defender for Endpointと接続
  
  

• 対応OS
  専業プロバイダ：Linuxが主。Windowsアプリの分離は限定的
  MXC：Windows 11・WSL・Linux・macOSのいずれもサポート

つまり実務で選ぶ際のポイントは、「クラウド上で大量のエージェントを並列実行したい」なら専業プロバイダ、「企業の管理下にあるPCやCloud PCでエージェントを動かしたい」ならMXCという使い分けになります。両者は競合というより、エージェント実行のレイヤーが違うと捉えるのが実態に近い理解です。

MXCの採用事例とパートナー連携

MXCは早期プレビュー段階ですが、Build 2026の発表時点ですでに複数の主要パートナーが採用・統合を表明しています。

実装が確認できているものから、統合計画段階のものまで、レイヤー別に整理します。

GitHub Copilot CLI——プロセス分離をpublic previewで採用

最初の本格採用事例として最も重要なのが、GitHub Copilot CLIです。

GitHub Changelog（2026年6月2日）によれば、Copilot CLIのローカルサンドボックスはMXCのプロセス分離を基盤として実装されており、macOS・Linux・Windowsの3OSで一貫した分離体験を提供しています。

Copilot CLIが実行するシェルコマンドは、ユーザーが明示的に許可した範囲外のファイルやネットワークに触れにくい仕組みになっており、許可していないディレクトリの破壊や、想定外のエンドポイントへの資格情報送信といったリスクを抑える設計です（許可範囲内での誤操作は別レイヤーでガードする想定）。

これはMXCにとって重要な実績です。「early previewのSDKを、実利用者のいる開発者向けプロダクトのpublic previewで採用した」という事実が、SDKの実装成熟度を一定水準で裏付けています（cloudサンドボックスはGitHub hosted Linux sandboxで、localサンドボックスにMXCが使われている設計）。

GitHub Copilot CLIのクラウドサンドボックス起動画面（出典：GitHub Changelog）

ターミナルには「Creating remote session and provisioning sandbox」（完了）と「Connecting to the remote session in the cloud」（進行中）の2ステップが表示されており、「copilot --cloud」コマンド1つで分離環境が立ち上がる体験になっています。なおcloudサンドボックスはGitHub hostedのephemeral Linux sandboxで、MXCが基盤になるのは同時発表されたローカルサンドボックスの方です。

NVIDIA OpenShellのWindows対応——MXCをバックエンドに採用

NVIDIAはOpenShellをWindowsで動かす際のサンドボックスバックエンドとしてMXCを採用する方針を公式ブログで表明しています。

OpenShellはもともとLinux向けの自律エージェント実行基盤で、Docker・Podman・MicroVM・Kubernetesといった複数のcompute platformを切り替えて使う設計です。これをWindows対応する際に「Windows側の分離はMXCに任せる」とすることで、OpenShellは「ポリシー・オーケストレーション層」に専念できる構造になります。

これは前述の「ユーザー空間のオーケストレーション層＋OS強制の境界層」という補完関係の最も明確な実装例で、MXCが「他社の自律エージェント基盤の足回り」として機能し始めていることを示しています。

OpenClaw・Hermes Agent等のオープンソース／スタートアップ採用

OSS・スタートアップ側でもMXC統合の動きが進んでいます。

• OpenClaw
  オープンソースの常時起動型AIエージェントプロジェクト。Windows対応のためMXCを採用し、ノードとゲートウェイをMXC上で実行する構成を発表
  
  

• Hermes Agent
  Nous ResearchのAIエージェント。OpenShell経由でMXCバックエンドの活用を予定
  
  

• Manus
  中国系の自律エージェントスタートアップ。MXC統合により、Windowsホスト環境での実行をサポート予定

これらの採用が示すのは、MXCが「Microsoft純正のエージェントだけのもの」ではなく、サードパーティ自律エージェントの実行基盤として開かれているという点です。OpenClawのような常時起動型のエージェントが「ファイル誤削除や情報漏洩」のリスクを抱えていた問題に対し、MXCが「OS側で境界を引いて被害を局所化する」解として機能し始めています。

Microsoft 365管理センターでOpenClawエージェントに対してIntuneポリシーを設定する画面（出典：Microsoft Security Blog）

画像はMicrosoft 365管理センターからOpenClawに対するIntuneポリシーを構成している画面で、Agent 365経由でサードパーティのAIエージェントにもIT統制を適用できる枠組みが示されています。MXC側の実行レイヤーと組み合わせれば、ポリシー違反の動作を実行時に止める運用に近づきます。

OpenAIとの連携——CodexのMXC統合検討

OpenAIは、Codex CLIの能力とMXCの統合を検討中であることを表明しています。

現状のCodex CLIは自前の3モード分離（read-only / workspace-write / danger-full-access）を持っていますが、これらをMXCポリシーにマッピングできれば、Windows・Linux・macOSの3OSで同じCodex体験を、OS側でポリシーを強制する一貫した分離体験として提供できる構図になります。

ただし統合の具体的なタイミング・実装範囲は2026年6月時点で未発表で、続報を待つ段階です。

Build 2026での発表時点での採用全体像

採用パートナーをまとめると、現状のMXCエコシステムは以下のレイヤー構造になっています。

つまり実務で参考になるのは、「GitHub Copilot CLIで動いているから、コーディングエージェントの実行にはMXCのプロセス分離が使える」という点と、「NVIDIA・OpenAI・OSSコミュニティが標準化に向けて足並みを揃え始めている」という点の2つです。

ここまでの採用幅は、Microsoft単独の構想で終わらず、標準化に向けた動きが見え始めた状態と読み解けます。

Agent 365・Windows 365 for AgentsとMXCの関係

MXCは単独の機能ではなく、Microsoftが描く「AIエージェント向けエンタープライズスタック」の最下層を担う部品です。

上位レイヤーにはMicrosoft Agent 365、Windows 365 for Agents、そしてDefender・Entra・Intune・Purviewのセキュリティ統制が積み重なります。

Agent 365——エージェントの制御プレーン（GA：2026年5月1日、$15/user）

Microsoft Agent 365は、2026年5月1日に一般提供開始されたAIエージェント向けの制御プレーンです。

Build 2026で示されたMicrosoft FoundryとAgent 365の連携セッション（出典：news.microsoft.com Build 2026）

Build 2026では「Microsoft Foundryで開発したエージェントを、Agent 365経由でEntra ID付与・ポリシー配布・監査まで一気通貫で管理する」シナリオが公式デモとして示されました。

Microsoft Security Blogによれば、Agent 365は「エージェントにEntra IDを付与し、Defender・Purview・Intuneで統治する」という制御フレームワークを提供します。料金は$15/userで、Microsoft 365 E7プラン（E5＋Agent 365＋Entra Suite）にも含まれます。

MXCとAgent 365の役割分担は、レイヤーで分けると整理しやすくなります。

• Agent 365
  「誰のエージェントか（ID）」「どんなポリシーで動くか（統制）」「何をしたか（監査）」を扱う制御プレーン
  
  

• MXC
  「エージェントが実行時に何に触れていいか」を扱う実行レイヤー。Agent 365で定義したポリシーをOS側で強制する役回り

つまり、Agent 365がIT管理者向けの「observe・govern・secure」の制御プレーンとしてポリシー定義・配布・監査・Defender/Intune連携によるブロックを担い、MXCがOSレベルでエージェントの実行境界そのものを適用する——という二段構えです。Agent 365のランタイム統制を超える「OS側で何にアクセスできるか」をJSONポリシーで宣言・強制する部分をMXCが受け持つ役割分担になっています。

Microsoft Defenderがエージェント・MCP・ID・クラウドリソース間の関連性を可視化する画面（出典：Microsoft Security Blog）

Defenderの「Map」画面では、ローカルAIエージェント（画像中のChatGPT Desktop）を起点に、IAMユーザー・AWS VPC・S3バケット・Bedrock Agentなど接続先リソースが放射状に可視化されます。IT管理者はこの俯瞰図から「どのエージェントがどこに到達しているか」を一望でき、MXCのポリシー強制と組み合わせて「許可した経路だけに絞り込む」運用が成立します。

Windows 365 for Agents——エージェント専用のクラウドPC

Windows 365 for Agentsは、Build 2026のタイミングで一般提供開始されたAIエージェント専用のCloud PCサービスです。

Microsoft Tech Communityの発表によれば、各Cloud PCは隔離されたAzure仮想ネットワーク内で動き、Entra結合・Intune管理・条件付きアクセスがすべて適用される設計です。エージェントが何らかの理由で侵害された場合でも、影響範囲は使い捨てのCloud PCインスタンスに封じ込められます。

MXCとWindows 365 for Agentsの関係は、「ローカルPCでもCloud PCでも、同じMXCポリシーで同じ分離が効く」という共通基盤を目指す方向です。ただしMXCのWindows 365統合は本記事執筆時点（2026年6月）でロードマップ段階で、early previewにも入っていません。

現時点でWindows 365 for Agentsを使う場合、Cloud PC自体はEntra・Intuneで統制できますが、Cloud PC内のエージェント実行をMXCで分離する機能は将来のアップデート待ちです。

Defender・Entra・Intune・Purviewによる統合保護（June 2026 preview〜coming soon）

Microsoftは、MXCをDefender for Endpoint、Entra ID、Intune、Microsoft Purviewと統合し、企業のセキュリティ・IT部門が一元的にエージェントを統制できる構造を計画しています。

統合内容と提供時期は以下のとおりです。

実務で選ぶ際のポイントは、「MXC単体導入」より「Agent 365経由でMXCポリシーをIntune配布する運用」が現実的な運用になりやすいという点です。個々の開発者が手元のWindowsにMXCをインストールしてポリシーを書く形ではなく、IT管理者がIntuneでテンプレートを配布し、開発者はそのテンプレート配下でエージェントを動かす——という運用設計を想定する必要があります。

Microsoft 365管理センターのAgent 365 Registry SyncでAmazon BedrockやGoogle Cloudのエージェントを取り込むプレビュー画面（出典：Microsoft Security Blog）

画像のRegistry sync画面では、Amazon Bedrock connectionで4つのエージェント（Incident resolution / Decision brief / Dependency radar / Knowledge pulse）が同期完了している様子が確認できます。MicrosoftはAWSやGoogle Cloud上で動くサードパーティエージェントもAgent 365のレジストリに取り込んで一元統制できる設計を取っており、結果的にMXC＋Agent 365のスタックはマルチクラウドにまたがるエージェント統制レイヤーになります。

CSO Onlineが「Microsoft builds a security perimeter for AI agents」と評したのも、この統合スタック全体を指してのものです。MXCだけを切り出して「軽量サンドボックス」と呼ぶより、Agent 365＋MXC＋Defender/Entra/Intune/Purviewの統合パッケージとして読み解くほうが、実態に即した理解になります。

MXCの料金と提供時期

MXCの料金体系は、SDK本体と統合機能で扱いが分かれます。本セクションでは費用感の読み解きとロードマップを整理します。

SDK本体は無料・オープンソース、料金はAgent 365側で発生

MXC SDKそのものは、github.com/microsoft/mxcで公開されているオープンソースです。npm経由で「@microsoft/mxc-sdk」を導入する分には追加コストはかかりません。

費用が発生するのは、MXCを企業全体に展開する際の上位レイヤーです。以下の表で、料金の発生ポイントと2026年6月時点の水準を整理しました。

この料金構造から読み取れるのは、「MXC単体導入」のコスト負担は事実上ゼロだが、企業全体での評価・運用に必要なAgent 365・Defender・Intuneの統合には、エンタープライズ向けライセンスのスタックが前提になるという点です。

中小規模で開発者個人がエージェントの実行分離を試すレベルなら、MXC SDKを直接使うだけで完結します。一方、企業全体でエージェントを統制する段階に入ると、Agent 365を中心とした$15/userのライセンスコストが軸になります。

提供時期とロードマップ

機能ごとの提供時期は、2026年6月時点で以下のように整理されます。

当面の評価導入の現実解は、**「プロセス分離はGitHub Copilot CLI経由で先に触れ、セッション分離はDefender/IntuneのJune 2026 public preview以降に検証、Purview統合はcoming soonの正式発表後に組み込む」**という段階的アプローチになります。マイクロVMやWindows 365統合は2026年下半期以降の発表を待つ前提で計画を立てる必要があります。

公式disclaimerと運用上の制約

公式リポジトリのREADMEには、企業導入を検討する段階で必ず確認すべき注意書きが複数記載されています。

• セキュリティ境界としての扱い
  「現状のプロファイルは、まだ安全境界として扱うべきではない」と明示。ポリシーの過剰許容性も「公開前に改善予定」と記載
  
  

• 未実装機能
  Windowsでは「拒否パスリスト」「ネットワークポリシー」が未実装、macOSではプロキシ未対応
  
  

• 実験的バックエンド
  windows_sandbox、wslc、microvm、hyperlight、isolation_session、seatbeltは実装途上で、本番ワークロード向けではない

つまり実務で扱う際のポイントは、**「MXCは現時点ではevaluation・preview段階で、本番のセキュリティ境界として単独利用しない」**という前提に立つことです。プロセス分離の境界も「Defender for Endpoint等の追加検知層を重ねた前提で運用する」のが現状の正しい使い方になります。

Cloudflareが脆弱性管理について述べた「アプリケーション前段の防御＋コンパートメンタライゼーション＋一括展開能力」の3点と同じ発想で、MXC単体に境界保証を求めず、複数レイヤーで防御を重ねる設計が求められます。

企業がMXC世代に備える実務指針

MXCは早期プレビュー段階ですが、その登場が示す方向性は、Microsoft環境でAIエージェントを動かすすべての企業のセキュリティ運用に影響します。

本セクションでは、AI総合研究所が支援している企業の傾向も踏まえ、ケース別に「いま何をすべきか」を整理します。

MXC世代に備える企業タイプ別アクションプラン

まずは大枠の整理として、企業タイプ別の優先アクションを以下の表にまとめました。

これらは、Project Glasswingに参加できるかどうかとは無関係に、すべての開発企業がいま着手できる取り組みです。

各ケースの背景を以降で深掘りします。

AIエージェントを開発するベンダー・SIerの場合

自社製品としてAIエージェントを開発・提供している企業にとって、MXCの登場は「自社エージェントの実行レイヤーをどう設計するか」を見直す節目になります。

特に重要なのが、**「自社エージェントを顧客のWindows環境で動かす場合、MXCポリシーで包めるか」**という観点です。顧客のIT部門がIntune経由でMXCポリシーを配布する運用に踏み出した場合、MXCポリシー配下で動かないエージェントは採用候補から外れやすくなります。

GitHub Copilot CLIがプロセス分離を採用したように、自社エージェントもMXC SDKに対応させる準備を進めるのが妥当な選択です。最低限、以下の3点が優先度高めです。

• 自社エージェントの「必要権限」をJSONポリシーで宣言できる状態にする
• One-shot API・State-aware APIのどちらに適するワークロードかを整理する
• 顧客のIntune配布ポリシーと自社推奨ポリシーが衝突した場合のフォールバック設計を決める

これは技術的な対応だけでなく、製品設計のドキュメントにも反映が必要な領域です。営業段階で「お客様のMXCポリシー配下で動作確認済み」と言えるかどうかが、エンタープライズ商談で確認項目になりやすい状況です。

Microsoft 365利用のエンタープライズ企業の場合

Microsoft 365を全社導入している企業にとって、MXCは「Agent 365経由で配布されるIntuneポリシーの一部」として降りてくる機能です。

導入判断で詰まる論点は、次の3点に集約されます。

• どの部門・どの業務に、どの分離強度（プロセス分離 or セッション分離）を適用するか
• 自部門エージェントと外部ベンダー製エージェントで、ポリシーをどう使い分けるか
• パッチ未提供期間や障害時の暫定対策（エージェント実行の一時停止・例外申請プロセス）をどう運用するか

これらは技術論というより運用設計の話で、Defender/IntuneのJune 2026 public preview開始時点で「テンプレートが用意できているか」が成否を分けます。AI総研の支援現場でも、Microsoft Agent 365を契約した企業から「MXCポリシーのテンプレート設計」を相談されるケースが増えてきています。

特に金融・公共・製造といったセキュリティ重視業種では、社内ガイドラインに「OS分離なしのエージェント実行は禁止」と明記する検討が進む可能性があります。MXC前提のエージェント運用設計を、Agent 365の契約と同時に始めるのが現実的な備えになります。

Mac/Linuxメインの開発組織の場合

開発者がMac/Linux中心で、Windowsはあまり使わない組織にとっても、MXCは無関係ではありません。

MXCはmacOSのSeatbelt、LinuxのBubblewrap/LXCをバックエンドとしてサポートしており、JSONポリシーで宣言した境界をWindows・Linux・macOS共通の記述で書ける設計です。ただしバックエンドごとの成熟度と未対応制限は異なるため（macOS Seatbeltはexperimental扱い等）、実際の挙動はREADMEとプラットフォームごとに確認する必要があります。GitHub Copilot CLIがmacOS・Linux・WindowsすべてでMXC基盤の同じ分離体験を提供しているのが、その実装例です。

具体的には、まずローカルでMXC SDKを評価し、自社が普段使うコーディングエージェント（Copilot CLI、Claude Code、Codex CLI等）の実行が、MXCポリシー配下で問題なく動くかを検証するのが現実的な第一歩です。

将来的にMicrosoft Foundry経由のクラウド実行や、Windows 365 for Agents経由のクラウドPC実行に移行する際、ローカルで確立した「MXCポリシー＋エージェント」のセットが流用しやすくなる可能性があります（W365統合はロードマップ段階で、対応範囲は今後の発表次第）。

業界全体の構造変化——「OS統合のAIエージェント基盤」が有力な候補に

MXC・Agent 365・Windows 365 for Agentsの3点セットが示す方向性は、**「AIエージェントの実行は、OSベンダーが提供する統制スタックの中で行うものになる」**という業界構造の変化です。

これは、これまで「Docker＋言語ランタイム＋アプリ側の権限管理」で完結していたエージェント実行が、「OS側のID・分離・監査・脅威検知」と一体化する方向へ動くことを意味します。AWS・Googleからも類似の動きが予想され、CISO層のスキル要件が「AIエージェントを評価・統制する力」へシフトする流れは加速しそうです。

AI総研の支援現場でも、エンタープライズ顧客から「自社のAIエージェント基盤がベンダーロックインに陥らないようにしたい」「複数のOSベンダー基盤を横断する統制設計をしたい」という相談が増えています。MXCを単独の製品としてではなく、業界全体の「エージェント実行レイヤー標準化」の文脈で捉えるのが、CISO・CTO層に求められる視点です。

AIエージェントを安全に業務へ組み込む統制設計

MXCのようなOS側の統制機構が登場したことで、AIエージェントを業務に組み込むうえで「どこに分離境界を引くか」「誰がポリシーを管理するか」が経営層の意思決定対象になりつつあります。

一方で多くの企業は、MXCのプレビュー機能を待つよりも先に、現行のCopilotエージェントやMicrosoft Foundry Agent Serviceを業務に組み込み、Agent 365による統制レイヤーを設計し始める段階にあります。

AI総合研究所では、エンタープライズAIエージェント基盤「AI Agent Hub」を提供しており、業務適用パターン、Microsoft Agent 365との接続性、エージェント実行の統制設計を支援しています。MXC世代を見据えたエージェント基盤の選び方を整理した紹介資料を無料で公開していますので、自社のエージェント運用設計を検討する第一歩として活用ください。

AIエージェントを安全に業務へ組み込む統制設計

MXC世代を見据えたエージェント基盤の選び方を1冊で

MXCのようなOS側の統制機構が登場したことで、AIエージェントを業務に組み込むうえで「どこに分離境界を引くか」「誰がポリシーを管理するか」が経営層の意思決定対象になりつつあります。AI Agent Hub紹介資料では、エンタープライズAIエージェント基盤の選定軸、業務適用パターン、Microsoft Agent 365との接続性を整理しています。

▶ 無料で資料をダウンロード

まとめ

本記事では、Microsoftが2026年6月のBuild 2026で発表したMicrosoft Execution Containers（MXC）について、主要な分離パターン・ポリシーSDK・既存技術との違い・採用事例・Agent 365およびWindows 365 for Agentsとの関係・料金と提供時期・企業の備え方まで、2026年6月時点の最新情報で解説しました。要点を改めて整理します。

• MXCはWindows・Linux・macOSの各OSネイティブなバックエンドが実行時にエージェントのアクセス境界を適用する、ポリシー駆動の薄い実行レイヤーで、Windows文脈ではAppContainerとWindows Sandboxの間を埋める「軽くて堅い」中間レイヤーとして設計されている
  
  

• プロセス分離・セッション分離に加え、マイクロVM・Linuxコンテナ・Windows 365 for Agents統合を組み合わせるcomposable sandbox spectrumが中核思想で、プロセス分離・セッション分離はWindows Insiders向けにBuild後まもなくearly previewで提供予定。マイクロVM・Linuxコンテナ・W365統合はロードマップ段階で、いずれも現時点では本番のセキュリティ境界として単独利用しない前提
  
  

• TypeScript SDK（@microsoft/mxc-sdk）とJSONポリシースキーマでクロスプラットフォーム対応しており、Windows・WSL・Linux・macOSのいずれでも同じポリシー記述で動作する設計
  
  

• GitHub Copilot CLIがプロセス分離をpublic previewで採用、NVIDIA OpenShellがWindowsバックエンドとしてMXCを採用予定、OpenAI Codexが統合検討中と、標準化に向けた動きが具体化し始めている
  
  

• 料金はSDK本体無料・OSS、企業全体運用はAgent 365（$15/user）＋Defender/Intune（June 2026 public preview）＋Purview（coming soon）の統合スタックが前提で、評価導入の現実解はプロセス分離からの段階的アプローチ

企業のセキュリティ責任者・AI推進責任者にとってMXCは、「自社が今すぐ使えるかどうか」よりも、「OSベンダー統合のエージェント実行レイヤーが有力な選択肢になる前提で、自社のエージェント基盤と統制設計を整え直せるか」という問いを突きつける動きです。まずはGitHub Copilot CLIで動いているMXCプロセス分離を実体験し、Defender/IntuneのJune 2026 public preview開始までにAgent 365中心の統制テンプレートを設計しておくことが、最も実用的な第一歩になります。

AIエージェントが業務の中核に入り込む2026年は、「エージェントの実行レイヤーを誰がどう統制するか」を業界全体が問い直す転換期になりそうです。MXCの登場を「Microsoft固有の新機能」と矮小化せず、自社のエージェント実行戦略を再設計するきっかけとして捉える視点が、企業の競争力を左右します。