AIエージェントは、ファイルを読み、ネットワークにつなぎ、アプリをまたいで仕事を進められるぶん、便利さと危うさが表裏一体です。Microsoftはその問題に対して、「全部許すか、全部止めるか」ではなく、使わせる範囲をきちんと決めて動かすための仕組みをWindows側に用意し始めました。今回の発表は、その中核になるMicrosoft Execution Containers（MXC）を一般提供にした、という話です。単なる機能追加ではなく、AIエージェントを企業の業務に入れるときの前提を変えようとする動きだと見ていいでしょう。
Microsoftの説明はかなりはっきりしています。エージェントは生産性を大きく上げる一方で、ファイル、ネットワーク、アプリケーションにまたがって動けるため、新しいセキュリティリスクも生む。だから利用者は、エージェントに無制限の権限を与えて事故を祈るか、あるいは丸ごと止めて便利さを捨てるかの二択に追い込まれがちだ、とMicrosoftは言います。そこで同社は、AIエージェントをより安全に動かすためのWindows機能として、Containment、Identity、Manageabilityの3本柱を掲げました。
今回一般提供されたMicrosoft Execution Containers（MXC）は、そのうちContainment、つまり「何に触れてよくて、何を触ってはいけないか」を実行時に強制する層です。開発者やIT管理者が、エージェントに許すファイルやネットワーク先をポリシーとして定義すると、MXCが適切なコンテナを使ってその境界を守ります。ここで重要なのは、そのポリシーがエージェントの外側にあることです。モデルがどう考えようが、生成コードがどう書こうが、プラグインやツールが何をしようが、勝手に権限を増やせません。
Microsoftは、たとえばWebサイトを更新するcoding agentを例に挙げています。このエージェントは、リポジトリの読み書き権限や、buildとtestに必要な開発ツールへのアクセスは必要かもしれない。さらに、どうデプロイされているかを理解するためにproduction server configurationを読む必要はあるかもしれない。だが、設定そのものを書き換える必要はないはずです。もし制約がなければ、エージェントは最短経路として本番設定を書き換え、サイトを壊すかもしれない。MXCはそうした操作を、モデル側の判断とは無関係に止めることを狙っています。
MXCは、こうした不確実なコードや動的に生成される処理のための、policy-driven execution layerだと説明されています。対象は model-generated output、plugins、tools、agent harness、場合によってはエージェント全体まで含みます。開発者はJSONベースの共通スキーマとmulti-language SDKで必要資源を宣言し、MXCがWindows、macOS、Linuxそれぞれのバックエンドに合わせて制御を当てます。バックエンドには、軽量なProcess container、Windows 11専用のSession container、WSLを使うWSL container、実験的なMicroVMがあり、用途に応じて選べます。Windows 365でもMXCが一般提供され、Cloud PC上で既存作業と並走させやすくなった点も押さえておきたいところです。
さらにMicrosoftは、組織ポリシーと開発者ポリシーを分けて扱う方向を示しています。開発者は「このエージェントは何が必要か」を宣言し、企業はIntuneなどで「組織としてどこまで許すか」を上乗せできる。つまり、アプリ側に企業のセキュリティ方針を書き込まなくても、同じエージェントを部署や環境ごとに違う境界で動かせる設計です。加えてWindows上では、LearningやPermissiveのような運用モードで、実際に何へアクセスしようとしたかをJSONのactivity reportとして観測しながら、最小権限のポリシーを詰めていけます。Microsoftは、許可されなかった操作が起きたときにエージェントが黙って失敗するのでなく、完了できなかった理由を伝えたり、安全な代替を選んだりすべきだとも書いています。
この発表で面白いのは、MicrosoftがAIエージェントを“賢いソフトウェア”としてではなく、“信用しすぎてはいけない実行主体”として扱っていることです。これはかなり現実的な見方だと思います。生成AIは、たしかに指示に従うのですが、企業システムの中では「指示に従う」だけでは足りません。最短で成果を出そうとして、本番や個人フォルダに踏み込む可能性があるからです。人間なら「それは違う」と止められる場面でも、エージェントは権限の境界を理解しているとは限らない。MXCは、その弱点を前提にした設計に見えます。
特に、ポリシーをエージェントの外側に置いた点は重要です。AIアプリの多くは、モデルの出力をアプリ側で検査して止めるだけで済ませがちですが、それでは抜け道が残ります。モデル自身がツールを呼び出せるなら、出力の検査をすり抜ける形で危険な操作に近づくこともあり得る。Microsoftはそこを、実行環境そのものの制御に寄せた。これは「AIを信用する」のではなく「AIが信用できなくても壊れない」方向です。企業導入では、こちらの方がずっと筋が通っています。
一方で、運用は簡単ではなさそうです。Least privilege、つまり最小権限のポリシーを作るのは、人間相手でも面倒です。ましてや、エージェントはタスクごとに必要な資源が変わる。MicrosoftがLearningやPermissiveモードを用意したのは、その難しさを認めているからでしょう。私はここに、プロダクトとしての誠実さを感じます。いきなり完全遮断にせず、まず観測して詰める段階を作っているからです。ただし、ここで集めたデータをどう扱うか、どこまで管理者の責任にするかは、実際の導入現場でかなり揉めそうです。
MXCのバックエンドが1種類ではなく、Process container、Session container、WSL container、MicroVMと分かれているのは、かなり現場目線の設計です。軽いコード生成ならProcess containerで十分かもしれないし、長時間動く自動化や、ユーザーの通常作業と明確に切り分けたい用途ではSession containerが効く。Linux前提の開発基盤ならWSL containerが自然ですし、より危険なワークロードにはMicroVMのような強い隔離が要る。つまり、AIエージェントは「同じものをどこでも動かす」存在ではなく、仕事の性質で必要な隔離が大きく違う、とMicrosoftは見ています。
この考え方は、AI導入の失敗パターンにも通じます。多くの現場では、「とりあえずAIを入れる」ことが先に来て、後から権限や監査を考えます。すると、便利そうに見えた機能が、結局は全社展開できない。MXCはその逆で、最初から隔離モデルを選ばせる。私は、この順番こそが本質だと思います。AIエージェントは万能な一個の製品ではなく、軽い補助から高リスクの自動化まで幅が広い。ならば、実行環境も一つでは足りません。
ただ、気になるのは、選択肢が増えるほど導入判断も難しくなることです。どのバックエンドが「十分安全」で、どこから先が過剰なのかは、現場のリスク許容度で変わります。特にWindows、macOS、Linuxをまたいで共通スキーマをうたう一方で、Session containerはWindows 11限定、MicroVMは実験的とされている。つまり、統一感はあるけれど、完全に同じ体験にはまだならない。Microsoftはそこを隠していませんが、逆に言えば、企業側には「標準機能だから安心」というより、「自社の使い方に合わせて設計する」姿勢が求められます。
今回の発表で、私はContainmentだけでなくIdentityとManageabilityの扱いが印象に残りました。Microsoftは、Windows上でMicrosoft Entraを使い、エージェントの活動と人間の活動を見分ける方向も示しています。さらに、Microsoft Agent 365のコントロールをローカルのエージェントにも広げ、ITチームがMXCコンテナやポリシー、活動監視を管理できるようにするとしています。これは単なるセキュリティ機能ではなく、端末管理そのものの拡張です。人のアカウント、端末、アプリに続いて、AIエージェントも管理対象に入るわけです。
ここには、企業向けWindowsの進化の方向がはっきり出ています。PCはもはや「人が使う箱」だけではなく、「人とAIが同居する作業場」になる。そのとき、従来のアクセス制御やMDMだけでは足りません。AIは、人間の操作より速く、広く、時に予測不能に振る舞うからです。だからこそ、エージェントのidentityを分け、操作履歴を追い、必要なら組織ポリシーで締めるという三層構造が必要になる。私はこれを、AI時代のWindows管理の下地づくりだと見ています。
同時に、これはMicrosoftが自社プラットフォームの中でAIエージェントの標準を握りに来た、とも読めます。開発者が好きなAIモデルを使えても、実行時の囲い込み、監査、管理はWindowsとMicrosoftのルールに乗る。企業にとっては安心材料ですが、プラットフォーム依存も深まる。ここは評価が分かれるでしょう。それでも、少なくとも「AIをどう安全に業務へ入れるか」という問いに、Microsoftが空論ではない答えを出そうとしているのは確かです。便利だから入れる、ではなく、管理できるから使える。今回のMXCは、その転換点を示しているように見えます。
参考: Microsoft Execution Containers: Policy-driven containment for AI agents
