Markdown版

AI-translated from English; not yet reviewed by a fluent editor.

# エージェントが生成するコマンドのMXCポリシーを設定する方法

> MicrosoftのMXC SDKを使うと、開発者はコマンドとファイル・ネットワークのポリシーを宣言できます。ドキュメントのみを基にしたこのガイドでは、Node V1での設定方法、診断モード、バックエンドの制限を説明します。

By BIG CHANGE Editorial

Published: 2026-10-08T05:14:55.341Z
Updated: 2026-10-08T05:14:55.341Z
Canonical: https://bigchange.ai/blog/mxc-agent-command-containment-guide

![Conceptual charcoal illustration of a small computer with an external drive connected and a network cable lying unplugged beside its port.](https://bigchange.ai/api/media/file/mxc-explicit-connections-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no MXC product interface, hardware, security test or enforcement result is depicted.

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

## 大きな変化

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

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

MXCはワークロードを起動するアプリケーションに組み込むライブラリです。その[README](https://github.com/microsoft/mxc)には、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のバージョン表](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md)には、ProcessContainerとIsolationSessionの最小ビルドが記載されています。作業を実行するマシンで、ホストが利用可能か、要求するポリシーに対応しているかを検証してください。

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

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

次の [Node SDKガイド](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md)では、このV1形式が説明されています。対応するNodeリリースを実行するアプリケーションにSDKをインストールします：

```bash
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のサンプル](https://github.com/microsoft/mxc/blob/main/samples/README.md)では、ファイルシステムの許可、ネットワーク遮断、出力の取得、拒否の記録を扱っています。事前に準備したホストが必要です。BIG CHANGEはこれらを実行していません。

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

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

Microsoftの[10月7日付のモード表](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)は、3つの結果を区別しています。**Enforcement**は未許可のアクセスをブロックし、アクティビティレポートを生成しません。**Learning**は未許可のアクセスをブロックして記録します。**Permissive**はポリシーで拒否されるアクセスを記録しますが、そのまま続行させます。Microsoftの[拒否記録のリファレンス](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md)によると、こうしたLearning機能はAppContainerベースのWindows ProcessContainer経路に限られます。共通のポリシーフィールドを受け付けるだけで、ほかのホストも同等のレポートを得られるわけではありません。

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

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

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

## 出典・参考資料

- [Microsoft Windows Developer Blog、2026年10月7日](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)は、ローンチの発表、エージェントでの利用目的、3つのモードの定義を裏付けています。Microsoftによる製品説明であり、BIG CHANGEのセキュリティテストではありません。
- [MXCリポジトリREADME](https://github.com/microsoft/mxc)にはSDK、ホストの既定値、実験的なバックエンド、ビルド要件、ネイティブ実行ファイルの経路が記載されています。リポジトリは更新されるため、詳細は2026年10月8日に確認しました。
- [Node SDK利用者向けガイド](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md)では、Nodeの要件、V1のインポート、型付きリクエスト、取得される出力を説明しています。上記コードはそのサンプルを応用したもので、ここでは実行していません。
- [設定スキーマガイド](https://github.com/microsoft/mxc/blob/main/docs/schema.md)は、安定版のネイティブJSON`1.0.0`と変更中の`1.1.0-alpha`を区別し、ポリシーフィールドとバックエンドごとの制限を説明しています。
- [Learningモードと拒否記録のリファレンス](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md)はWindows ProcessContainerの診断方法を説明し、Permissiveでの監査に警告しています。レポートの内容はホストとモードによって異なります。
- [バックエンドガイド](https://github.com/microsoft/mxc/tree/main/docs/backends)と[Windowsのバージョン表](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md)は、各ホストで確認すべき資料です。この記事は読者のマシン上の構成を認定するものではありません。

## Sources

- [Microsoft Execution Containersのローンチ](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) — 一般提供の発表、ワークロードとリソースの境界、3つのモードの定義。ベンダーの主張は独立したテストではありません。
- [MXCリポジトリREADME](https://github.com/microsoft/mxc) — SDK、ホストの既定値、実験的なバックエンドの表示、ネイティブ実行ファイルの経路、ソースライセンス、ビルド要件。
- [MXC Node SDK README](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) — V1のインポート、Nodeの最低バージョン、型付きリクエスト、実行結果、ホスト検出。例は応用したもので、実行していません。
- [MXCスキーマガイド](https://github.com/microsoft/mxc/blob/main/docs/schema.md) — 安定版ネイティブJSON 1.0.0と開発版1.1.0-alphaの契約、ネットワークポリシー、バックエンドとUIの制限。
- [MXC拒否記録ガイド](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) — Windows ProcessContainerにおけるLearningとPermissiveの動作、--auditのセキュリティ警告、出力の上限。
- [MXC SDKサンプル](https://github.com/microsoft/mxc/blob/main/samples/README.md) — ファイルシステム、ネットワーク、出力取得、拒否記録に関する公式サンプルの一覧。
- [MXCのWindows OSバージョン対応状況](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) — ProcessContainerとIsolationSessionの最小Windowsビルド。
- [MXC Bubblewrapバックエンドガイド](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) — Linuxの既定バックエンドに必要な条件とネットワーク対応。
- [MXC Seatbeltバックエンドガイド](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) — macOSネイティブプロファイルとリモートホストのフィルタリングに関する制限。
Markdown版

記事を探す。

BIG CHANGEをチェック。

記事を探す。

BIG CHANGEをチェック。

Markdown版

大局を、あなたのペースで。

プライバシーはあなたが選ぶ。

プライバシーはあなたが選ぶ。
