この記事のポイント
- Microsoft eXecution Containersについて説明しているよ
- Microsoft eXecution Containersをハンズオンしているよ
- なぜ、Microsoft eXecution Containersが必要なのか解説しているよ
はじめに
この記事ではMicrosoft Build 2026で発表されたMicrosoft eXecution Containers（以下、MXC）について書いています。登場したばかりのツールということもあり、今後のアップデート次第では、このブログに書かれているハンズオンが機能しなくなる可能性もあります。
Microsoft eXecution Containers（MXC）とは
MXCはMicrosoft Build 2026で発表されたサンドボックス型コード実行システムです。
※Microsoft Build 2026ではAIエージェントのためのサンドボックス型コード実行システムという説明がされていました。
OSSとしてGitHub上で公開されており、だれでも貢献、コミットすることができます。なお、リポジトリでは次のように説明されています。
MXC is a sandboxed code execution system for running untrusted code (model output, plugins, tools) on Windows, Linux, and macOS. It provides multiple containment backends — from OS-native process sandboxes to full VMs — behind a unified JSON configuration schema and TypeScript SDK.
ちょまどさんによる解説
ちなみにMXCはGitHub Copilotのサンドボックス機能にも採用されている機能でもあります。
※Makiさんによる解説
ハンズオン
では、実際にハンズオンしていきましょう。
今回はmacOS上でMXCを実行します。
macOSの環境
- macOS
- Tahoe 26.5.1
- Visual Studio Code
- Version: 1.124.0
- node --version
- v20.19.5
- cargo
- 1.96.0 (30a34c682 2026-05-25)
- MXC SDK
- v0.6.1
ハンズオンのおおまかな流れ
- Setup
- mxc-exec-macのビルド
- config.jsonの作成（今回はもとからあるものを動かす）
- mxc-exec-macの実行
まずはmacOS上でやるための手順を紹介します。そのあとGitHub Codespacesによる手順を紹介します。
Setup
まずはリポジトリをクローンします。
gh repo clone microsoft/mxc && cd mxc
git clone https://github.com/microsoft/mxc.git && cd mxc
次にRust upでRustをインストールします。
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
PATHにRustを通します。これは一時的なものなので恒久的な対応をしたい場合はPATHに追加してください。(bashrcあるいはzshrc)
source "$HOME/.cargo/env"
# ドットを使ってもよい
. "$HOME/.cargo/env"
最後にNode.jsをnvmでインストールします。インストール手順
これでセットアップは完了です。
Native Binaryをビルドして動かす
まずはNative Binaryをビルドします。ビルドで生成された成果物を実行することで後述のSDKビルドをスキップできます。
./build-mac.sh --rust-only # Only Rust binary, skip SDK
実行結果
=== Build complete ===
Binary: /Users/{Username}/Desktop/personal/mxc/src/target/aarch64-apple-darwin/release/mxc-exec-mac
Note: this binary is unsigned. Codesigning + notarization happen at
release time (see docs/macos-support/seatbelt-backend.md, codesign-notarize todo).
これでNative Binaryをビルドできました。
MXCを実行
ビルドした成果物を使ってMXCを動かしてみましょう。まずはhelpが開けるか確認します。
# cd ./sdk/bin/arm64
./mxc-exec-mac --help
実行結果
macOS sandbox executor for MXC
Usage: mxc-exec-mac [OPTIONS] [CONFIG_PATH]
Arguments:
[CONFIG_PATH] Path to config JSON file (positional)
Options:
--config <CONFIG> Path to config JSON file
--config-base64 <CONFIG_BASE64> Base64-encoded JSON config
--debug Enable debug/console output
--experimental Enable experimental features
--dry-run Parse and validate config then exit without executing
--log-file <LOG_FILE> Path to diagnostic log file (appends, creates if missing)
-h, --help Print help
上記のようにhelpが参照できれば、問題なくビルドできています。ここでポイントとなる点は--configというところでしょう。--configではconfig.jsonを指定します。
config.jsonを使ってMXCを動かす
スクラッチでconfig.jsonを書くのは慣れが必要なので今回はtestsにあるconfig.json（26_mac_gui_access.json）を動かします。※後述：config.jsonの解説
./sdk/bin/arm64/mxc-exec-mac --experimental --config ./tests/examples/26_mac_gui_access.json
実行結果
GUI access enabled — custom GUI apps can create windows under this profile
デバッグモードで動かす場合
./sdk/bin/arm64/mxc-exec-mac --experimental --config ./tests/examples/26_mac_gui_access.json --debug
実行結果
Script code length: 83
Working directory:
Script timeout: 0
Container name:
Seatbelt: applying sandbox via sandbox_init
GUI access enabled — custom GUI apps can create windows under this profile
Runner completed in 15ms
Exit code: 0 (0x00000000)
問題なく動作したところで設定ファイルを見てみましょう。config.jsonは以下のとおりです。※スキーマバージョンは0.7.0-devです。
{
"$schema": "../schemas/dev/mxc-config.schema.0.7.0-dev.json",
"version": "0.7.0-alpha",
"containment": "seatbelt",
"process": {
"commandLine": "echo 'GUI access enabled — custom GUI apps can create windows under this profile'"
},
"ui": {
"disable": false,
"clipboard": "all"
},
"experimental": {
"seatbelt": {
"guiAccess": true
}
}
}
config.jsonとは
config.jsonは簡単に説明するとMXCの構成ファイルです。
スキーマはあった。
testsを見るといくつか参考となる例が書いてありますので参考にしていただければと思います。
※別の機会に深堀りしていきたい
参考：tests/configs
参考：tests/examples
MXC Playgroundの紹介
MXCを起動することもできました。しかし、config.jsonを書いてから実行するとなると設定ファイルの作成に難儀すると思います。そこでMXC Playgroundというものを使うと実行前にconfig.jsonを試すことができます。※config.jsonはSDKで表現できます
ただし、今回は実行環境がmacOSということもあって利用はできなかったです。※選択肢にseatbeltがない。見つけられなかった。
起動はできるが、活用は難しいという状態です。とはいえ、今回は自分でビルドしているのでパラメータを自分で追加することも可能です。次にMXC Playgroundの起動方法を紹介します。
MXC Playgroundの起動方法
起動方法は簡単、ディレクトリのルートから./tests/playgroundに移動してnpm install => npm startを実行するだけです。
cd ./tests/playground
npm install
npm start
README.mdをよく読んでみよう
ハンズオンとPlaygroundの紹介は以上です。ここからはREADME.mdをベースにMXCがどんなものか見ていきます。参考：README.md
MXC特徴
ここまでの内容とREADME.mdの内容をもとにMXCについてまとめると以下のとおりです
- 手軽に実行できる小さなサンドボックス
- マルチプラットフォームで動作
- プラットフォーム毎に起動できるbackendsが変わる。WindowsやLinuxで検証することを推奨
- Native BinaryはRust、SDKはTypeScript
- 起動するサンドボックスはconfig.jsonで構成（スキーマに沿っていれば名前はなんでもいい）
- サンドボックスはone-shotとstate-aware APIsの2つがある
- ハンズオンではone-shotでNative Binaryを試した
- state-aware APIsではサンドボックスが状態を持つ
- MXCの設定ファイルとなるconfig.jsonはSDKで表現できる
- TypeScriptで表現可能
- サンドボックスがアクセスするネットワーク、ファイルシステムを設定ファイル(
config.json)で制限できる
さらに深掘り、なぜMXC？
今回のハンズオンではmacOSのネイティブサンドボックス（Seatbelt）を利用して起動しましたが、MXCのアーキテクチャやリポジトリを探索すると「micro VM（マイクロVM）」という言葉が重要なキーワードとして登場します。
筆者が思い当たるマイクロVMというと、AWSがオープンソースで開発しているKVMベースの「Firecracker」などがあります。これは軽量なゲストカーネルを高速に立ち上げる技術です。
MXCの最大の強みは、統一されたインターフェース（JSON/TypeScript）の裏側で、OSネイティブのプロセス隔離から、カーネルが完全に独立したマイクロVMまで、実行環境やセキュリティ要件に応じてバックエンドを柔軟に切り替えられる点にあります。
コンテナ型仮想化との決定的な違い
これらと従来の「コンテナ（Dockerなど）」との決定的な違いは、「ホストOSのカーネルを共有しているか、それとも分離しているか」という点です。これはDevSecOpsの観点からも極めて重要なポイントです。
コンテナは、Linuxカーネルの namespaces で空間を区切り、cgroups でリソースを制限しているだけに過ぎません。そのため、もしカーネルの脆弱性を突いた「コンテナ脱出（Container Escape）」が発生した場合、ホストOS全体の権限が奪取され、その上で動いている他のすべてのコンテナも丸見え・操作可能になってしまいます。
あまり意識されませんが、マルチテナント環境において「共有カーネル」は、セキュリティ境界における一種の単一障害点（SPOF）といえます。
一方で、マイクロVM（カーネル分離）や厳格に隔離されたサンドボックスであれば、仮に内部で悪意あるコードが実行されてゲスト環境が破壊されても、被害はその内部だけに封じ込められ、ホストOSや他のプロセスには影響が及びません。
AIエージェントに「LLMが生成した任意のコード」や「出所のわからないサードパーティ製プラグイン」を動的に実行させるユースケースにおいて、このレベルの厳格な隔離は、もはや必須の要件と言えるでしょう。これはDevSecOpsの観点からも優れたポイントです。
point
- コンテナと違う点はカーネルを分離している点であり、ホストOSのカーネルを共有していない
- カーネルを共有するコンテナ型仮想化の場合はカーネルへの侵害（いわゆるコンテナ脱出）が発生する可能性
- そのホスト上で動いている他のすべてのコンテナやデータまで芋づる式に侵害されてしまう
以上のようにそれぞれ動作するうえで分離レベルが異なるため、たとえば、マルチテナント環境のホストにおいてはマイクロVMの採用が良いです。
もちろん、カーネルが分離されているサービスを利用されているのであれば、コンテナでも問題ありません。
ただし、共有カーネル環境でセキュリティを担保するためには、どのコンテナが不正なシステムコールを発行しているかを検知できるよう、カーネルレベルの可観測性（Observability）を高める必要があります（eBPFや、MicrosoftがOSSで公開しているRetinaの活用など）。
AIエージェントに「任意のコード」や「信頼できないプラグイン」を実行させるユースケースにおいて、この「カーネルレベルの隔離」は必須の要件と言えるでしょう。
まとめ
今回はMicrosoft Buildで発表されたMicrosoft eXecution Containerについて紹介しました。
リクエストを発行したい&安全にコマンドを実行したい用途では重宝すると思いました。また従来ではコンテナを起動するなどしてサンドボックスを構築することをしていましたが、やりたいことによってはtoo muchになりがちなのでそういった用途では大活躍間違いなしです。
※サンドボックス面倒でAzure FunctionsなどのFaaSを使いたくなるが、それもそれで場合によっては面倒
MXCはクラウドがないとこでAIエージェントを安全にどう動かす？みたいな場合やGitHub Copilot CLIのSandboxに採用されている点を見るとエッジでどう小さく安全に動かすかというところにぴったりハマるものです。
また、TypeScriptで実行できる点は注目ポイントです。Node.jsあるいは既存のJava Scriptのエコシステムで動作することは非常に強力な点です。
さらに、マルチエージェントとして大量のインスタンスを並列起動するようなケースでも、MXCであればミリ秒単位で起動するため、オーバーヘッドがほぼありません。高速かつ軽量に動作し、ホストのリソース消費を最小限に抑えられる点はまさに「夢が詰まったサンドボックス」としての未来を感じます。
参考
- Microsoft Build 2026: Securing code, agents, and models across the development lifecycle
- microsoft/mxc
- Build 2026: 信頼できる開発プラットフォームとして、進化する Windows
- macOS Sandbox Container Backend
- Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能
おまけ：トラブルシューティング
ここからは実際にやってみて遭遇したトラブルについて書きます。
なお、公式のトラブルシューティング一覧もあります。
Rustがインストールされていない場合
build-mac.sh実行時、cargoが利用できない場合はErrorで止まります。Rustをインストールしましょう。
=== Checking prerequisites ===
Error: cargo is not installed. Install Rust via https://rustup.rs/
インストールされているの動作しない場合は環境変数PATHを確認しましょう。以下の操作はbash上で一時的にPATHを通す方法です。
source "$HOME/.cargo/env"
# ドットを使ってもよい
. "$HOME/.cargo/env"
cargo buildによるNative Binaryのビルド
Cargoでもビルドできます。Rustを利用されている方はもしかするとこっちのビルド方法が直感的でわかりやすいかもしれません。
# Rust workspace (from src/)
cd ./src
cargo build --release -p mxc_darwin --target aarch64-apple-darwin # macOS
SDKをビルドする場合は以下のとおりです。（SDKはTypeScriptなのでnpmによるビルドです）
# SDK (from sdk/)
cd ./sdk
npm install && npm run build