JustFit
ブログ
MXCが正式版に、AIエージェントの権限をOSで制限

MXCが正式版に、AIエージェントの権限をOSで制限

2026.10.08 JustFit編集部（運営：株式会社LEGAREA）

Microsoftは2026年10月7日、AIエージェントが使えるファイルやネットワークをあらかじめ決めておき、実行時にOSが守らせる仕組み「Microsoft Execution Containers（MXC）」を正式提供（GA）にしました。この記事では、発表された内容と、読むときに気をつけたい点を整理します。新規事業やシステム開発にとって何が変わるのかを、私たちJustFit編集部の見方として分けて書きます。

10月7日にMXCが正式提供になった

MicrosoftはWindowsとSurfaceの10月のイベントで、MXCがWindows 11で正式提供になったと発表しました。同じ日にWindows Developer Blogでも解説が公開されています。イベントの冒頭の基調講演は、AIエージェントの安全な運用が大きなテーマだったと報じられています。

MXCは、信頼できないコードや、実行のたびに動的に作られる処理のための、ポリシー駆動の実行レイヤーと説明されています。ここでいう「信頼できないコード」には、AIが生成したコードやプラグインなどが含まれます。開発者やIT管理者が、エージェントが使ってよいファイルやネットワークの接続先などを決めると、MXCが適切なコンテナで実行時にそのルールを守らせます。

囲う対象と、囲い方の選択肢

開発者は、モデルが生成した出力、プラグイン、ツール、エージェントの実行基盤、あるいはエージェント全体をMXCで囲えます。何か問題が起きたときの影響範囲を小さく保つためです。設定のしかたについては、統一されたJSON形式の設定とマルチ言語SDKを使い、MXCがWindows・macOS・Linuxそれぞれの実行環境に合わせて制御へ置き換えるとされています。Windows 365のMXC対応も同時に正式提供になり、クラウドPC上でもエージェントを分離して動かせます。

囲い方には強さの違いがあります。Windowsの情報サイトによると、方式は4つです。

プロセス単位のコンテナ：生成コードやツール呼び出しのような軽い処理向け。Windows・macOS・Linuxで使える
セッション単位のコンテナ：デスクトップを必要とする長時間のエージェント向け。Windows 11のみ
WSLコンテナ：Linux中心のツール向け。Windows 11のみ
MicroVM：リスクの高い処理向け。Windows 11とLinuxで、実験的な扱い

対応を表明しているツール

Microsoftによると、OpenAI Codex、GitHub Copilot、OpenClaw、Replit、LM Studio、NVIDIA OpenShell、Unsloth AIがすでにMXCに対応しています。今後の対応が見込まれる企業として、Anthropic（Claude Code）、Box、Egnyte、Manus、Perplexity、Raycast、Simularなどが挙げられています。MXCはBuild 2026で、WindowsとWSL向けの早期プレビューとして発表され、今回がその正式版です。

読むときに押さえておきたい点

ここまでが発表の内容です。採用を考えるときは、次の点を確かめておくと安心です。

プレビュー期間の注意書きとの違い：プレビュー中のGitHubのリポジトリには、MXCのプロファイルを現時点でセキュリティ境界として扱わないよう求める注意書きがありました。この注意書きはプレビュー期間のものなので、以前に試した人は正式版のv1.0で評価し直すべきだと、前述の情報サイトは指摘しています。
OSごとの機能差：すべての機能がすべてのOSで使えるわけではないと報じられています。上の4方式のうち、セッション単位とWSLコンテナはWindows限定です。
MXCが担うのは「囲い込み」の部分：Microsoftは、エージェントの安全運用に必要な要素を「封じ込め」「ID（人との区別）」「管理性」の3つに分けています。MXCは封じ込めの層にあたります。同じ情報サイトによると、IntuneやEntraによる管理機能は、これから提供される予定とのことです。

編集部の見方：AIエージェントの「動ける範囲」が、開発の仕様として書けるようになる

ここからは、事実ではなく私たちの見方です。

設定として書けると、レビューの対象になる

これまで「AIエージェントに何を触らせるか」は、使う人の注意や、ツールごとの確認画面に任されがちでした。MXCのように、ファイルやネットワークの範囲をJSONで宣言し、OSが守らせる形になると、その設定自体を人が読んで確認できます。コードレビューと同じ感覚で、「このエージェントはここまで」と合意できる点が、実務では大きいと考えています。

開発中のAIと事業で動くAIは別の問いになる

囲いが必要な場面は2つあります。1つは、開発チームがコーディングエージェントを使う場面です。もう1つは、作ったシステムでAIエージェントがお客様の代わりに動く場面です。

前者は、開発環境の安全をどう保つかという問題です。後者は、お客様に「このAIは、ここまでしか触れません」と説明できるかという問題で、事業の信頼に直結します。システムそのものが事業になるような新規事業では、後者が要件の一部になるはずです。エージェント同士の連携や「誰がどこまでできるか」は、Personal Agent Protocolの記事でも触れています。

OSやハードウェアの側で守る流れは、他社にも広がっている

この方向はMicrosoftだけのものではありません。NVIDIAは9月28日（現地時間）に、AIエージェントを決められた範囲に収めるためのOpen Agent Safety Platformを発表しています。NVIDIAの説明では、その中のOpenShellはClaude Code、Codex、GitHub Copilot CLIなどに対応しています。前述のとおり、MXC側もOpenShellへの対応を挙げています。守る仕組みをモデルや各ツールの外側に置くという考え方が、複数の会社で共通になりつつあるように見えます。

囲いがあっても、「何を許すか」と「出力が正しいか」は人が決める

MXCは、エージェントが許可された範囲の外へ出ないようにする仕組みです。許可した範囲の中で、エージェントが何をどう作るかが正しいかどうかは判断しません。何を許可するかを決めるのも人です。AI開発でも品質に人の確認が必要な理由で整理したとおり、囲いは品質確認の代わりではなく、確認と組み合わせる安全装置だと私たちは考えています。

試すときの確かめどころ

新規事業の試作でMXCのような仕組みを検討するなら、次の3点を見ておくと迷いにくいです。

使っているAI開発ツールが、MXCの対応ツールに入っているか
データの重さに、どの強さの囲い（プロセス、セッション、WSL、MicroVM）が合うか
許可と拒否の記録が、読める形で残るか

これらを試作の段階で決めておくと、本番に近づいてから権限の作り直しになる手戻りを減らせます。ただし、いずれも提供開始直後の仕組みです。自社の環境で、実際に確かめてから判断するのが堅実です。開発ツール側の変化については、Claude Code「Mods」の記事やIBM Bobセルフホスト版の記事も参考になります。

まとめ

Microsoftは2026年10月7日、AIエージェントの動作範囲をポリシーで決めてOSが実行時に守らせる仕組みのMXCを、Windows 11で正式提供にしたと発表しました。
囲う強さは、プロセス単位からMicroVMまで選べます。OpenAI Codex、GitHub Copilotなどが対応を表明しています。
新規事業やシステム開発では、「エージェントに何を許すか」が設定として書け、レビューできる項目になります。システムの中でAIが動く事業では、お客様への説明に使える材料にもなりそうです。
一方で、MXCは囲い込みの層です。何を許可するかの判断と、出力の確認は、MXCではなく引き続き人の仕事です。

私たちJustFitも、AIを活用した開発基盤「LAF」で、複数の専門AIが開発を進める形を取っています。そこで人の役割は、何を作るかを決めることと、品質の最終判断です。AIの動ける範囲が仕組みで守られるようになるほど、この判断がより大切になると考えています。構想段階のご相談は、JustFitのサービス紹介からお受けしています。

参考にした情報

← ブログ一覧へ