Microsoft Execution Containers（MXC）とは？9バックエンドの選び方とSDKの実装手順【2026年9月時点】

AIエージェントにコードを書かせて実行させる場面が増えるほど、そのプロセスがログイン中のユーザーと同じ権限で動いてしまう点が問題になります。Microsoft Execution Containers（MXC）は、エージェントに許す範囲をポリシーとして宣言し、OS側が実行中ずっとその境界を強制し続けるためのSDKです。ここでは2026年9月23日時点のリポジトリ・スキーマ定義・リリースノート・公式ブログを照合し、9つのバックエンドの使い分けから最小実装までを整理します。本文の表と手順は原則としてリポジトリのmainを基準にしており、npmで入る公開版0.8.0との差は後述の対照表で示します。

まとめ

結論として、MXCは「エージェントを動かしてよいか」を起動前に判断する仕組みではなく、動き続けているプロセスに対してファイル・ネットワーク・UIの境界を実行時に当て続ける層です。ただし早期プレビューであり、公式リポジトリは現時点のプロファイルをセキュリティ境界として扱わないよう明記しています。

• バックエンドは9種類で、実験扱いはwindows_sandbox・microvm・hyperlightの3つだけです。残る6つは実験フラグなしで使えます。
• 新規のポリシーで宣言する版は0.9.0-alphaです。0.4.0-alphaと0.5.0-alphaは下限を割って受け付けられなくなりました。
• Node.jsの要件はリポジトリ現行で24以上です。Windowsではさらに24.21.0以上か26.8.0以上が要り、26.8.0以上が推奨されています。
• WindowsのProcessContainerは3つの隔離ティアを実行時に選びますが、実際に全リリースで動くのは最下層のAppContainer＋DACLだけです。
• v0.8.0のリリースノートは、24H2と25H2にはOS側の変更がまだ入っていないと明記しています。最新機能を試すにはInsider Preview Build 26340.9212以上が必要です。
• ネットワークは0.3.0以降つねに既定拒否です。networkを書かなければ通信できず、process.cwdを指定してもそのパスへのアクセス権は付きません。
• GitHub Copilot CLIがプロセス分離を採用していますが、そのローカルサンドボックスは実験的機能で既定はオフです。
• npmで入る0.8.0とリポジトリmainでは、Node.js要件・安定スキーマ・バックエンドの安定判定が食い違います。どちらを見ているかを意識して読む必要があります。

以下では、MXCの位置づけ、9バックエンドの選択基準、ProcessContainerが実際に強制できる範囲、版とNode.jsの要件、SDKの最小実装、既存の隔離手段との違いを順に示します。

MXCがAIエージェントに対して解こうとしている問題

従来のエンドポイント制御は、バイナリの信頼性やマルウェア定義との照合など、起動の可否を入口で判断する設計でした。エージェントはこの前提と相性が良くありません。起動時点では無害な実行ファイルでも、プロンプトごとに新しいコードを生成し、その場で実行するためです。

Build 2026で早期プレビューとして公開されたSDK

MXCは2026年6月2日のBuild 2026で公開されました。Windows Developer Blogはwe are introducing an early preview of the Microsoft Execution Containers (MXC) SDK, a cross-platform, policy-driven execution layer for agents on Windows and WSLと書いています。購入する製品ではなく、開発者が自分のアプリやエージェントに組み込むSDKという提供形態です。Build 2026の発表全体はMicrosoft Build 2026のGitHub・GitHub Copilot発表まとめ｜企業の導入判断と新機能にまとめています。

実装はgithub.com/microsoft/mxcでMITライセンスのまま公開されています。GitHub APIで2026年9月23日に取得した時点でスター1,355・フォーク81・未解決Issue 41（未マージのプルリクエスト20件は別）で、リポジトリ自体は2026年2月に作られています。Rustで書かれたネイティブ実行体とTypeScript SDKの二層構成で、リポジトリにはsdk/dotnetも追加されています。

MXCによる実行時の境界強制という設計転換

MXCが担うのは、許可したパスとネットワーク範囲をJSONで宣言し、その外側への到達をOSが実行中に拒否し続けることです。ポリシーの対象はファイルシステム・ネットワーク・UIの3領域で、UIにはクリップボードやディスプレイ、GUIアクセスの制御が含まれます。

すでに実運用に入っている例もあります。同ブログはGitHub Copilot CLI has adopted MXC process isolation to constrain what dynamically generated and executed code can do.と述べており、Copilot CLIが生成コードの実行範囲をMXCのプロセス分離で絞っています。ただし採用と提供状態は別です。GitHubのドキュメントはIn Copilot CLI, local sandboxing is currently an experimental feature.およびLocal sandboxing is turned off by default.と書いており、使うには--experimentalを付けて起動するか、セッション中に/experimental onを入れる必要があります。Copilot CLI自体の動作モードや料金はGitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説で扱っています。

セキュリティ境界として扱えないという明示的な制約

導入を検討するうえで最も重要な制約は、リポジトリのREADMEが冒頭の警告でno MXC profiles should be treated as security boundaries currentlyと書いている点です。現時点で生成されるポリシーには過度に緩いケースが既知であり、一般提供の前に対処するとされています。つまり多層防御の1枚として足す分には意味がありますが、これ1つで信頼できない第三者のコードを安全に隔離できるとは公式が言っていません。

9つのバックエンドと選択基準

MXCは単一の隔離技術ではなく、同じポリシーを複数の隔離方式へ振り分ける抽象層です。READMEが列挙するバックエンドはProcessContainer、Windows Sandbox、LXC、Bubblewrap、Seatbelt、MicroVM（NanVix）、Hyperlight、IsolationSession、WSLCの9種類です。

バックエンド一覧と最小スキーマ・安定/実験の別

実験扱いの3つはSandboxSpawnOptionsに{ experimental: true }を渡すか、CLIで--experimentalを付けないと選べません。Hyperlightはさらに出荷バイナリに含まれておらず、--with-hyperlightを付けてソースからビルドする必要があります。

抽象インテントと具体名の使い分け

バックエンドはcreateConfigFromPolicy(policy, containment)の第2引数で選びます。可能な限りprocess・vm・microvmという抽象インテントを渡し、ホストに合う実体はSDKとネイティブ側に解決させる設計です。ホストごとに分岐を書かずに済みます。

注意点として、同じprocessでも必要な版が変わります。macOSではSeatbeltへ解決されるため0.7.0-alpha以上が要り、WindowsとLinuxでは0.6.0-alphaのままです。vmインテントは0.10.0-alphaを要求します。

Build時点のロードマップと現在の実装差

Build 2026の発表では、マイクロVM・Linuxコンテナ・Windows 365 for Agentsとの統合はSome other MXC containment capabilities currently on our roadmap are:の配下に並ぶ予定項目でした。3か月後の現在、マイクロVMはmicrovmとして実験バックエンドに、WSL経由のLinuxコンテナはwslcとして安定バックエンドに実装されています。一方でWindows 365 for Agentsは一般提供済みですが、MXC統合そのものはWith the future addition of MXC integration＝将来の追加という位置づけのままです。

マイクロVMという隔離方式自体の仕組みはFirecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分けを実装者目線で解説が詳しく、WSL側の準備はWSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処を参照してください。

ProcessContainerがWindowsで実際に強制できる範囲

Windowsの既定バックエンドであるprocesscontainerは、ドキュメント上は最小ビルド26100（24H2）と書かれています。実施範囲の正本はWindows OS-version policy supportです。ただし実際に何が強制されるかはビルドによって変わり、ここを読み違えると「ポリシーを書いたのに効いていない」という状態になります。

実行時に選ばれる3つの隔離ティア

T1はPSEC（CreateProcessSecurityEnvironment）の契約が有効な25H2+（ビルド26600以降）でしか成立せず、25H2までのビルドや契約が無効な環境ではT3へ落ちます。T2はbfscfg.exeの呼び出しが25H2でホストをデッドロックさせうるため、tier2_bfsというCargoフィーチャーが全出荷ビルドでオフになっています。事実上、手元で確実に効いているのはT3のAppContainer＋DACLだと考えて設計するのが安全です。

ここは実際の採用側にも効いてきます。GitHubのドキュメントはWindows uses the BaseContainer tier of the ProcessContainer backend. Copilot CLI does not use the AppContainer fallback tiers.と書いており、Copilot CLIはT1しか使いません。BaseContainerを用意できないWindowsビルドでは、サンドボックス非対応として扱われます。

24H2・25H2でProcessContainerの機能が揃わない事情

v0.8.0のリリースノートはWindows 11 24H2 and 25H2 machines do not yet include all of the required OS-side changes, so ProcessContainer will not be fully featured on those builds.と明記しています。最新のProcessContainer機能を今すぐ試すにはInsider Preview Build 26340.9212以上が要り、24H2と25H2への反映は今後の更新で入る見込みとされています。isolation_sessionバックエンドの最小ビルドも同じ26340.9212です。

Learning Modeによる拒否の記録とポリシー調整

ポリシーを一発で書ききるのは現実的ではないため、v0.8.0でWindowsのProcessContainerに拒否内容の記録機能が入りました。processContainer.learningModeは拒否したまま記録する動作で、逆にCLIの--auditはpermissiveLearningModeを注入して「拒否されたはずの操作を通しつつ記録する」動作になります。

後者はAppContainerの制限がその実行中は効かなくなるため、ポリシー作成専用です。本番のワークロードに付けるものではありません。--auditはWindows Sandbox・WSLC・IsolationSessionを含む他のバックエンドでは拒否されます。

スキーマ版とNode.jsの要件

MXCはSDKの版とポリシースキーマの版が別に動きます。正本はschemas/schema-version.jsonで、ここに現行の安定版と開発版が書かれています。SDK側の対応表はsdk/node/README.md、公開版の内容はv0.8.0のリリースノートにあります。

ポリシースキーマの登録済みの版と失効した版

版は登録済みの文字列と完全一致でなければ通りません。0.6.1-alphaのように範囲内でも未登録の値を書くとPolicy version '<x>' is not a registered schema contractで弾かれます。ステートフル実行の既定版はバックエンドごとに独立していて、IsolationSessionとWSLCが0.9.0-alpha、Windows Sandboxだけが0.10.0-alphaです。

npm公開版0.8.0とリポジトリmainの差分

ここは実際に詰まる箇所です。npm installで入るのはタグv0.8.0の内容で、上の版一覧を含む本記事の表はmainの内容です。両者は次の点で食い違います。

つまりnpm installは古いNodeでも警告なく通る一方、mainのREADMEが要求する構成には足りません。公開版のまま0.9.0-alphaを宣言したり、wslcを実験フラグなしで選んだりすると弾かれます。

READMEはWindowsについてさらに細かく、fs.ReadStreamとfs.WriteStreamが使うwindowsHandleオプションのため、Node.js 24系なら24.21.0以上、あるいは26.8.0以上が必要で、26.8.0以上を推奨としています。ソースからビルドする場合はRustツールチェーンもsrc/rust-toolchain.tomlで1.93に固定されています。Node側の版選びはNode.js 26の新機能・変更点とLTSスケジュール総まとめも参考にしてください。

なおパッケージは0.2.0からPure ESMです。CHANGELOGはこの変更について、CommonJSからの同期的なrequireが使えなくなったとし、await import()への切り替えかプロジェクト側のESM化を案内しています。

SDKの最小実装

インストールはnpm install @microsoft/mxc-sdkです。以下のコードはすべてリポジトリのREADMEに載っている形をもとにしています。

SDKによる一回限りのサンドボックス実行

推奨される経路はcreateConfigFromPolicyで設定を組み立て、spawnSandboxFromConfigで起動する形です。ホスト上のツールや一時ディレクトリは、探索ヘルパーに列挙させるとポリシーを環境非依存にできます。以下の3例はいずれもTypeScriptで、ESMとして実行できる構成が前提です。

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

if (!getPlatformSupport().isSupported) {
  throw new Error('MXC not available on this host');
}

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

const config = createConfigFromPolicy({
  version: '0.9.0-alpha',
  filesystem: {
    readonlyPaths:  tools.readonlyPaths,
    readwritePaths: temp.readwritePaths,
  },
  timeoutMs: 30_000,
});
config.process!.commandLine = 'python -c "print(1)"';

const child = spawnSandboxFromConfig(config, { usePty: false });
child.stdout!.on('data', (d) => process.stdout.write(d));
child.stderr!.on('data', (d) => process.stderr.write(d));
child.on('close', (code) => console.log('exit:', code));

createConfigFromPolicyはcommandLineを空のまま返すため、起動前に必ず自分で入れます。usePty: falseにすると標準出力と標準エラーが分かれた状態で受け取れるので、サンドボックス側が出した失敗理由を取りこぼしません。

スキーマ0.8以降の方向別ネットワークポリシー

ネットワークは0.3.0の破壊的変更以降、つねに既定拒否です。0.8.0-alphaからは送信と受信を分けた方向別の記法に変わり、宛先をCIDR・プロトコル・ポートで指定します。

{
  "version": "0.8.0-alpha",
  "containment": "process",
  "process": { "commandLine": "node agent.js" },
  "network": {
    "egress": {
      "default": "deny",
      "allow": [
        { "to": [{ "cidr": "192.0.2.0/24" }],
          "ports": [{ "protocol": "tcp", "port": 443 }] }
      ]
    },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  }
}

旧来のallowOutbound・allowedHosts・blockedHosts・network.proxyとは併用できません。どちらか一方の記法に寄せる必要があり、混ぜた設定は拒否されます。ホスト名によるアローリストとブロックリストはWindowsでは未実装です。直接通信を塞いでループバックのプロキシだけ通す構成にしたい場合は、runtimeConfig.networkProxyにプロキシのエンドポイントを渡します。

provisionからdeprovisionまでのステートフル実行

エージェントのループのように、1つのサンドボックスへ何度もコマンドを流す用途には、状態を持つライフサイクルAPIがあります。provision・start・exec・stop・deprovisionの順に呼びます。途中で失敗してもサンドボックスを残さないよう、provisionに成功した後はtryとfinallyで囲みます。

import {
  provisionSandbox, startSandbox, execInSandboxAsync,
  stopSandbox, deprovisionSandbox,
} from '@microsoft/mxc-sdk';

const { sandboxId } = await provisionSandbox('isolation_session', {
  network: {
    egress: { default: 'allow' },
    ingress: { default: 'allow', hostLoopback: 'allow' },
  },
});

try {
  await startSandbox(sandboxId);
  await execInSandboxAsync(sandboxId, { process: { commandLine: 'echo hello' } });
} finally {
  try {
    await stopSandbox(sandboxId);
  } finally {
    await deprovisionSandbox(sandboxId);
  }
}

このAPIに対応しているのはisolation_session・windows_sandbox・wslcの3つで、いずれもWindows専用です。mainのSDK READMEによれば、Nodeから実際に出力を受け取れるのはIsolationSessionだけで、残る2つはexecInSandboxAsync(sandboxId, config, { dryRun: true })によるリクエスト検証にとどまります（optionsは第3引数です）。IsolationSessionのprovisionには上記のとおり全許可の方向別ネットワーク指定が必須で、規則やプロキシ、省略はいずれも拒否されます。

失敗時はMxcErrorが投げられます。分岐に使ってよいのは閉じた列挙であるcodeだけで、operationとnativeCodeは診断用です。この2つはIsolationSessionのステートフル操作でしか埋まらず、値も版を上げずに変わりうるとされています。

import { MxcError } from '@microsoft/mxc-sdk';

try {
  await startSandbox(sandboxId);
} catch (err) {
  if (err instanceof MxcError) {
    if (err.code === 'stale_id') {
      // サンドボックスが消えているので provision からやり直す
    }
    console.error(err.message, err.remediation);
  }
}

既存の隔離手段との違いと詰まりやすい点

MXCはコンテナ技術の置き換えではありません。設計目的が違うため、比較するなら「何を守るための境界か」で並べたほうが判断しやすくなります。

コンテナ技術との設計目的の違い

Windows Sandboxは「MXCと競合する製品」ではなく、MXCが抽象化した先の選択肢の1つとしてwindows_sandboxという名前で含まれています。ただし実験扱いで、1回の呼び出しごとに使い捨てのVMが立ち上がる方式へv0.7.0で変わりました。コンテナランタイム側の設計思想の違いはPodmanとdockerの違いは？デーモンレス・rootlessの仕組みと移行判断もあわせて読むと整理しやすくなります。

MXCの初回実行でつまずく5つの設定ミス

READMEが実際の質問をもとにまとめている注意点のうち、最初の実行で当たりやすいものを挙げます。

• UIポリシーを強制するのはWindowsのProcessContainerとmacOSのSeatbeltだけで、既定は拒否です。PowerShellは5.1も7も起動時にwin32kを呼ぶため、ui.allowWindows: trueを入れないと起動そのものに失敗します。逆にIsolationSessionとWSLCはuiの指定自体を拒否し、省略しても制限はかかりません。
• networkを書かなければ通信できません。同様にreadwritePathsがなければ一時ディレクトリにも書けず、uiがなければGUIは使えません。
• process.cwdや作業ディレクトリ引数を指定しても、そのパスへのアクセス権は付与されません。readonlyPathsかreadwritePathsに明示的に足す必要があります。
• Windowsで空白を含むパスを引用符なしでcommandLineの先頭に置くと、解析の段階で拒否されます。
• 実験バックエンドを選んだのに{ experimental: true }を渡していないと、'<x>' containment requires experimental modeで止まります。

なおテレメトリは既定でオフです。設定のtelemetry.enabled・Windowsでのユーザー同意・管理ポリシーの許可という3つのゲートがすべて開いたときだけ送信され、公開ソースからビルドしたバイナリはプロバイダーグループGUIDを持たないためローカルのETWにしかイベントを出しません。

よくある質問

MXCは無料で使えますか？

リポジトリとTypeScript SDKはいずれもMITライセンスで公開されており、利用に費用はかかりません。ただし早期プレビューであり、1.0までは版をまたいでスキーマとAPIが変わりうると明記されています。

Windows以外でも動きますか？

動きます。Linuxはx64とARM64で既定がBubblewrap、ほかにLXCが選べます。macOSはApple SiliconでSeatbeltが使え、スキーマ0.7.0-alpha以上が必要です（リポジトリのREADMEはx64も対応として挙げています）。ただしステートフルなライフサイクルAPIは現時点でWindows専用です。

ポリシーに書く版はどれを選べばよいですか？

現行の安定バックエンドを使うなら0.9.0-alphaです。Windows Sandbox・MicroVM・Hyperlightを使う場合だけ0.10.0-alphaが必要で、macOSのSeatbeltは0.7.0-alpha以上であれば動きます。

ポリシーを書いたのに制限が効いていないのはなぜですか？

WindowsのProcessContainerでは、ホストのビルドによって選ばれる隔離ティアが変わります。25H2+でOS側の契約が有効でなければBaseContainerは使われず、AppContainer＋DACLへ落ちます。v0.8.0時点では24H2と25H2に必要なOS側の変更がまだ入っていないため、最新機能の挙動を確かめるにはInsider Preview Build 26340.9212以上で試す必要があります。

信頼できない外部コードの実行をMXCだけに任せてよいですか？

現時点では避けるべきです。READMEはno MXC profiles should be treated as security boundaries currentlyと明記しており、生成されるポリシーが過度に緩いケースが既知であるとも書かれています。多層防御の1枚として位置づけ、境界そのものは別の手段でも確保しておくのが現実的です。

関連記事

• Firecracker（マイクロVM）とは？仕組み・KVMとの関係とgVisor・コンテナとの使い分けを実装者目線で解説
• Kata Containersとは？軽量VMで隔離するセキュアコンテナの仕組みとgVisor・runc比較・導入判断
• GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説
• Microsoft Build 2026のGitHub・GitHub Copilot発表まとめ｜企業の導入判断と新機能
• Node.js 26の新機能・変更点とLTSスケジュール総まとめ