Microsoftは2026年10月7日、Microsoft Execution Containers（MXC）の一般提供を発表しました。AIエージェントが提案したコマンドを実行するチームにとって、実務上の論点は、そのコマンドが必要とするファイルやネットワーク接続と、制限を適用できるMXCバックエンドです。Microsoftのローンチ記事は隔離の目的を説明し、リポジトリの利用者向けドキュメントは設定方法を説明しています。このガイドはこれらの文書に基づいています。BIG CHANGEはMXCをインストールしておらず、隔離環境でワークロードを実行していません。

大きな変化

  • 変わったこと： 開発者はコマンドとリソースポリシーを1つのMXC SDKインターフェースに渡せます。インターフェースは、対応するホストバックエンドを選択します。10月7日のリリースにより、モデルが自発的にポリシーに従うことを期待するのではなく、エージェントツール向けの文書化された統合経路が利用できるようになりました。
  • 重要な理由： チームは、コーディングコマンドに作業ディレクトリへのアクセスを許可しつつ、ほかのファイル領域や外部への接続をワークロードの権限外にできます。効果は選択したバックエンドとホストによって異なるため、制限を信頼する前に、バックエンドが実際に何を適用するか確認する必要があります。
  • 注目点： Microsoftのポリシー作成モードは、対応するWindows ProcessContainerホストでブロックされた操作の診断に役立ちます。次に検討すべきなのは、提案された許可が必要か、ポリシーを絞った後の本番実行が強制モードを使用するかです。

まずホストとコマンドを確認する

MXCはワークロードを起動するアプリケーションに組み込むライブラリです。そのREADMEには、Rust、.NET、Node SDKのほか、SDKを組み込めないアプリケーション向けのネイティブ実行ファイルが記載されています。Nodeパッケージにはネイティブランタイム資産が含まれ、Node.js 24以降が必要です。Windowsでネイティブstdio転送を使う場合、リポジトリはNode 24.21.0以降、または26.8.0以降を指定しています。公開APIはパッケージのルートではなく、@microsoft/mxc-sdk/v1からインポートします。.NETパッケージにもネイティブ資産が含まれます。RustクレートはSDK、エンジン、選択したバックエンドを利用側のアプリケーションに組み込んでビルドします。ネイティブ実行ファイルには対象プラットフォーム向けのリポジトリビルドが必要です。

ポリシーを書く前にバックエンドを選びます。リポジトリによると、Windows 11の既定はprocesscontainer、Linuxの既定はbubblewrap、macOSの既定はseatbeltです。Windowsではwslcとisolation_sessionも利用できます。windows_sandbox、microvm、hyperlightは実験的とされています。Linuxでは、既定のバックエンドに使うBubblewrapなど、選択したランタイムが必要です。Windowsのバージョン表には、ProcessContainerとIsolationSessionの最小ビルドが記載されています。作業を実行するマシンで、ホストが利用可能か、要求するポリシーに対応しているかを検証してください。

実際のコマンド、作業ディレクトリ、読み取る必要があるファイル、変更する必要があるファイル、必要なネットワーク接続先を書き出します。これらはアプリケーションまたはオペレーターが指定するポリシー入力として扱います。Microsoftによれば、ポリシーはエージェントのワークロード外にあるため、生成コードが自ら権限を拡大することはできません。コマンドの通常の出力はstdout、stderr、終了ステータスであり、SDKから警告や任意のメタデータが返される場合もあります。アクティビティレポートは、対応するWindows ProcessContainerホストの、文書化された診断モードでのみ利用できます。

Node SDKで最小限のポリシーを宣言する

次の Node SDKガイドでは、このV1形式が説明されています。対応するNodeリリースを実行するアプリケーションにSDKをインストールします：

Terminal
npm install @microsoft/mxc-sdk

この例は、Microsoftの実行完了まで処理するサンプルを応用し、アプリケーションの現在のディレクトリに読み取り専用アクセスを要求する一方、外部接続を拒否します。コマンドは1行を表示するだけなので、どちらの制限も試していません。これは文書に基づく出発点であり、BIG CHANGEによるテストではありません。隔離するワークロードに合わせてコマンドとパスを置き換え、変更が必要なディレクトリに限ってreadwritePathsを使います。

TypeScript
import { getPlatformSupport, run } from '@microsoft/mxc-sdk/v1';
import type { ContainerRequest } from '@microsoft/mxc-sdk/v1';

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

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  filesystem: { readonlyPaths: [process.cwd()] },
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const result = await run(request);
console.log(result.stdout, result.stderr, result.exitCode, result.warnings);

runは、キャプチャしたstdoutとstderr、終了コード、タイムアウト状態、警告を返します。ファイルアクセスが阻止されると、ワークロードには一般的なアクセス拒否エラーとして見えることがあります。正常終了だけでは、意図した制限をすべて検証したことにはなりません。課題の成功条件を満たすには、選択した対応バックエンド上で、許可されたリソースを使う信頼できるワークロードを実行し、許可されていないリソースへの意図的なアクセス試行も別途行います。エージェント生成コマンドにポリシーを適用する前に、操作結果と診断情報を確認してください。SDKのサンプルでは、ファイルシステムの許可、ネットワーク遮断、出力の取得、拒否の記録を扱っています。事前に準備したホストが必要です。BIG CHANGEはこれらを実行していません。

ネイティブ実行ファイルを使う場合、安定版JSONスキーマは1.0.0です。完全なリクエストにはversion、隔離方式の選択、process.commandLineが必要です。現在の開発版スキーマは1.1.0-alphaです。V1 SDKが通信形式を自ら選ぶため、型付きのContainerRequestにネイティブスキーマのバージョンを指定しないでください。スキーマガイドには、network.defaultPolicyやallowedHostsなどの旧フィールドは廃止されたとも記されています。現在のポリシーでは方向を指定するnetwork.egressとnetwork.ingressを使います。直接ルールとランタイムプロキシでは動作やバックエンドの対応状況が異なります。

拒否を診断してからポリシーを適用する

Microsoftの10月7日付のモード表は、3つの結果を区別しています。Enforcementは未許可のアクセスをブロックし、アクティビティレポートを生成しません。Learningは未許可のアクセスをブロックして記録します。Permissiveはポリシーで拒否されるアクセスを記録しますが、そのまま続行させます。Microsoftの拒否記録のリファレンスによると、こうしたLearning機能はAppContainerベースのWindows ProcessContainer経路に限られます。共通のポリシーフィールドを受け付けるだけで、ほかのホストも同等のレポートを得られるわけではありません。

ポリシー作成時に信頼できるツールを使う場合、Windowsのネイティブ実行ファイルはポリシー成果物を生成できる--auditフローに対応しています。Microsoftは、解析対象のワークロードでサンドボックスのセキュリティを無効にするため、信頼できないコマンドには適さないと警告しています。ホストが対応するなら、拒否しつつ記録する方式がより安全な診断方法です。アクセス試行をブロックしたまま、何が拒否されたかをレポートで確認できます。記録されたパスや機能をタスクに照らして確認し、コマンドに必要なものだけ許可して、最終的なワークロードはEnforcementモードで実行します。レポートには機密性の高いリソース名が含まれることがあるため、適切に取り扱ってください。

バックエンドの選択によって、ポリシーが保証できる内容は変わります。スキーマガイドによると、isolation_sessionはネットワークを制限できず、ネットワークを明示的に無制限にする設定が必要です。同ガイドでは、UI制限を適用するのはWindows ProcessContainerとmacOS Seatbeltで、ほかのバックエンドは実装していないと説明されています。WSLCとIsolationSessionは指定されたUIポリシーを拒否します。Seatbeltガイドによれば、macOSのネイティブプロファイルでは個別のリモートホストをフィルターできません。また、BubblewrapガイドはLinuxのランタイムとネットワークの前提条件を説明しています。複数のSDK型が同じJSONフィールドを受け付けても、すべてで同じように適用される証拠にはなりません。選択したバックエンドのガイドを確認し、対象ホストでリクエストを検証してください。

MicrosoftのリポジトリはMITライセンスですが、利用者向けドキュメントにはMXCパッケージの価格は記載されていません。ホスト、計算資源、モデルプロバイダーにはそれぞれ別の費用があります。Windowsの発表ではMXCは一般提供とされていますが、一部のバックエンドは実験段階で、ネイティブの開発版スキーマはalphaです。ワークロードの実行場所を決める際には、こうしたリリース段階を分けて考えてください。

出典・参考資料

  • Microsoft Windows Developer Blog、2026年10月7日は、ローンチの発表、エージェントでの利用目的、3つのモードの定義を裏付けています。Microsoftによる製品説明であり、BIG CHANGEのセキュリティテストではありません。
  • MXCリポジトリREADMEにはSDK、ホストの既定値、実験的なバックエンド、ビルド要件、ネイティブ実行ファイルの経路が記載されています。リポジトリは更新されるため、詳細は2026年10月8日に確認しました。
  • Node SDK利用者向けガイドでは、Nodeの要件、V1のインポート、型付きリクエスト、取得される出力を説明しています。上記コードはそのサンプルを応用したもので、ここでは実行していません。
  • 設定スキーマガイドは、安定版のネイティブJSON1.0.0と変更中の1.1.0-alphaを区別し、ポリシーフィールドとバックエンドごとの制限を説明しています。
  • Learningモードと拒否記録のリファレンスはWindows ProcessContainerの診断方法を説明し、Permissiveでの監査に警告しています。レポートの内容はホストとモードによって異なります。
  • バックエンドガイドとWindowsのバージョン表は、各ホストで確認すべき資料です。この記事は読者のマシン上の構成を認定するものではありません。