プロダクトレビュー・ショーケース
AIをより安全に動かす「MXC」とは? 一般提供が始まった新機能によるアクセス制御を「RTX Spark」搭載PCで試してみた
ローカルAIの安全性をより高める仕組み導入の“初歩” text by 芹澤 正芳
2026年10月29日 10:00
AIにファイルを読ませ、文章をまとめ、その結果を保存してもらう。そんな使い方がPC上でも可能になってきているが、それと同時に、AIが触れてよい範囲、すなわちAIが使用可能な“権限”を制御する仕組みも重要になってきた。任せたい作業に必要な権限をAIに渡し、それを超える操作は実行環境側で制限するためにWindows 11に組み込まれた新技術が「Microsoft Execution Containers(MXC)」だ。
Microsoftは2026年10月7日、Windows 11向けにMXCの一般提供開始を発表した。注目のRTX Sparkのように、大規模なLLMをローカルで動かせるPCでも、AIをより安全に運用するための基盤になる。
今回はASUS「ProArt P16(H7607)」の64GB版(国内未発売仕様)と「OpenClaw Windows Hub」を使い、MXCによるフォルダのアクセス制御や外部通信の制限を試した。AIにメモの要約と保存を任せた実用例、オフラインでの動作も交えて、仕組みと使い方を見ていこう。
一般提供が始まったMXCでAIが実行する処理の権限を制御する
MXCは、AIが生成したコードや、エージェントが呼び出すツールなどを隔離した環境で実行するための仕組みだ。アクセスできるファイルやネットワークなどをポリシーとして定義し、処理の実行時にその制限を適用する。このとき、“AIの判断から独立した場所”で権限を制御することが重要な役割になる。
たとえば、「このメモを要約して」と頼んだ場合、必要なのは“原文を読むこと”と“要約を保存すること”だ。元のメモを書き換えたり、別の個人用フォルダやファイルにアクセスしたりできる必要はないので、その権限まで渡す必要はない。そこで、「素材を置く場所は読み取り専用」とし、「成果物の保存先だけに書き込みを許可」する。この操作の許可と拒否を、実行環境の側で制御する、というのが基本的な構造だ。
MXCには、処理単位で隔離する方式や、Windowsの別セッションで動かす方式などがある。Windowsのプロセス単位の隔離ではAppContainerを利用するなど、用途とプラットフォームに応じた実行基盤を使う。Windows以外のOS向けの仕組みも用意されている。
利用する際は、対応アプリがMXCを組み込み、ユーザーはそのアプリが用意した機能から、必要な権限を設定することになる。Microsoftの一般提供開始の発表では、OpenClawなど複数の対応アプリが紹介されている。
今回使用するWindows Hubは、MXCを使う環境を実際に設定して試せる例のひとつだ。アプリごとに組み込み方や対象の処理は異なるが、今回は「Windows Node」という、Windows側の機能をOpenClawへ提供する仕組みを通したコマンド実行を試した。
RTX SparkのローカルAIに、操作範囲を決める仕組みを組み合わせる
ローカルAIの利点は、処理する素材をPC内に置いたままLLMを使えることだ。筆者のような職種であれば仕事の打ち合わせメモや公開前の原稿など(他業種であれば機密や個人情報など)、外部のLLMサービスへ送らずに扱いたいデータにも活用しやすい。一方、PC内で動くエージェントにどのファイルを扱わせるかは、別に設定しておきたい。
このようなケースでは、ローカルLLMによって“データを扱う場所”は手元に置き、MXCによって“実行する操作の範囲”をコントロールする。両者を組み合わせることで、使わせる素材と保存先を選びながら、AIに作業を任せる環境を作れる。AIに利用できる大容量メモリを備えるRTX Sparkは、そこで使うLLMの実行を支えるハードウェアだ。
検証した64GB版ProArt P16では、NVIDIA AppのGPUメモリ割り当てを40GBに設定した。詳しくは後述するが、使用したモデルは「Qwen3.6 35B-A3B」。量子化方式はUD-Q4_K_Sで容量は約21.4GBのモデルだ。
Qwen3.6 35B-A3Bは、全体で約350億、生成時に使うパラメーターが約30億というMoE型。計算に使う部分が絞られても、モデル全体を保持するためのメモリは必要になる。大容量メモリを持つRTX Sparkの利点が分かりやすいモデルだ。
タスクマネージャーでは、モデル導入・起動後のGPUメモリ使用量が合計28.7GBと表示された。これはその時点のシステム全体のGPUメモリ使用量で、モデルファイルの容量そのものではない。今回はこの環境を使い、AIによるファイル処理と、MXCによるアクセス制御を確かめる。
OpenClaw Windows Hubで、MXCを使うローカルAI環境を用意
今回の検証に使うOpenClawは、LLMで依頼を解釈し、ツールを呼び出して作業を進めるAIエージェントだ。「読んで、要約して、保存する」という複数の処理をつなげられる。その導入や管理、Windows側で許可する機能の設定を行う窓口がOpenClaw Windows Hubで、画面やインストーラーにはOpenClaw Companionという名称も使われる。
今回は処理を取りまとめるGatewayとLLMをともにProArt P16内へ用意した。クラウドのLLMへ生成を依頼する設定にはせず、ローカルAIを利用する。モデルや必要なプログラムの取得はインターネット接続中に済ませる。
導入はGitHubのリリースページからOpenClaw Windows Hubのインストーラーを取得。今回使用したバージョンはv2026.9.8-1だ。ProArt P16はArm版WindowsのPCなので、「OpenClawCompanion-Setup-arm64.exe」を選ぶ。画面や推奨モデルは更新で変わる可能性があるため、以下はこのバージョンで確認した流れになる。
初回セットアップでは、PC内へネイティブGatewayを導入する経路を選んだ。機能の利用可否チェックを待ち、「Install a local native gateway」から進める。今回の環境ではGatewayは2026.10.6となり、Hub側のWindows Nodeとはバージョンが異なっていた。
AIの接続では「Local AI」を有効にし、推奨モデルの内容を確認して「Install and use Local AI」を選ぶ。モデルと実行プログラムの取得、検証、起動などはHub側が進めてくれる。大きなファイルなので、ダウンロード後も検証などで待ち時間が生じる。完了画面が出るまで待とう。
「Your AI is ready」が表示されたら「Talk to my agent」へ進む。今回は「日本語で簡単に自己紹介してください」と入力し、日本語の応答を確認できた。まずはここまでで、ローカルモデルと会話できる状態になる。
続いてPermissionsでNode modeとSystem toolsを有効にする。カメラや画面収録などは今回の実演には使わず、Exec PolicyのDefault actionはAskに設定した。処理の実行時に内容を確認して承認するためだ。
Nodeの承認要求が出た場合は、表示されたIDを使って承認する。今回は「clawctl pwsh」でGateway側のシェルを開き、「openclaw nodes approve ＜要求ID＞」を実行して再接続した。Nodeの接続と、個々のコマンド実行の承認は別の手続きになる。
読み出し用と保存用でフォルダを分け、MXCに作業範囲を設定
作業範囲を決めるため、通常のWindowsの操作でユーザーフォルダ内に[OpenClawDemo]フォルダを作り、その下へ[Input]フォルダと[Output]フォルダを用意する。[Input]は素材を置く場所、[Output]は成果物を受け取る場所だ。
一方、HubのSandboxでは「Node Sandbox」を「ON」にする。今回は「Locked Down」を基準に、[Documents]、[Downloads]、[Desktop]は「Blocked」、[Clipboard]は「None」、[Allow internet]は「OFF」とした。
「Custom folders」で[Input]だけを「Read only」、[Output]だけを「Read & write」として追加する。親の[OpenClawDemo]全体を許可せず、2つのフォルダを個別に登録するのがポイントだ。
このバージョンでPowerShellを使うため、[Allow Windows UI APIs]は「ON」にした。画面には「Win32k boundary disabled」という警告が出るが、Windows UI APIに関する境界を緩める設定を示したもの。ファイルやネットワークの制御まで無効になるわけではなく、今回の検証でも設定に沿った許可と拒否を確認できた。
コマンド実行の承認画面が出たら、実行する内容と対象パスを確認し、「Allow Once」を選ぶ。ここでの承認は処理を始めるためのものだ。[Input]への書き込みを試す場合も、コマンド自体を承認した上で、MXC側の権限によって拒否されるかを確認する。
設定した権限は働くか、書き込み拒否と通信を確認
まず、MXCに設定した権限が働くかを実際に操作して確かめた。[Input]フォルダのテキストの読み取りと[Output]フォルダへのファイル作成は成功。一方、[Input]に別のファイルを新規作成しようとすると、アクセス拒否となり、終了コード1で失敗した。読み取り専用にした素材置き場への書き込みが、実行環境側で止められた形だ。
この3件の実行ログには、いずれも「containment=mxc」が記録されていた。AIがチャットで成功や失敗を報告したことに加えて、MXC内で処理されたことを確認している。
通信も確認した。PCがインターネットにつながった状態で、通常のWindows側からcurlでexample.comへアクセスすると「HTTP 200」の応答を取得できた。同じコマンドを外部通信禁止にしたWindows Node経由で実行すると、ホスト名を解決できず終了コード6で失敗。ログでも外部通信禁止の設定とMXC内での実行を確認した。
承認画面で実行を許可した後も、MXC側のフォルダ権限は適用される。エージェントが書き込むコマンドを用意しても、読み取り専用の[Input]では拒否された。作業に必要な機能を使わせながら素材の置き場への書き込みを止められた点が、今回の検証で特に分かりやすい効果だった。
許可した範囲で要約と保存、オフライン動作も試した
検証として、架空のPCレビュー記事の打ち合わせメモを用意した。初心者向けに画面写真を中心とした導入手順を紹介すること、検証ではACアダプターを接続して電源モードを統一すること、販売価格と公開日が未確認であることなどを記載したテキストだ。UTF-8で[Input]へ保存し、チャットから要約と[Output]への保存を依頼する。
依頼には入力元と保存先のフルパスを入れ、Windows Nodeのsystem.runを使うこと、別の実行先へ切り替えないことも指定した。今回のユーザー名は「proart」だが、試す場合は自分のPCの実際のパスへ置き換える。最初は入力元と保存先をフルパスで書くと、対象を指定しやすい。
処理を進めると、[Output]に[review-summary.md]が作成された。入力したメモから要点と未確認事項をまとめたファイルができ、指定した場所へ取り出せる。チャットで文章を作るだけでなく、PC内の素材を使い、成果物をファイルにするまでをつなげられた。
一方、要約の内容には確認が必要だった。「指定フォルダー」が「指定フォーマット」に変わり、「電源モードを統一」が「統合モード」になる誤りが発生した。修正を頼んだ後も一部が残ってしまい、かつAIに「原文と一致している」と報告されてしまった。
そこで、通常のWindows側から原文と保存結果を直接開き、相違を確認。修正する文章を明示して上書きを依頼すると、最終的に指定どおりのファイルになった。なお、「作業を進める機能」と「文章の正確さ」については別途確認としたい。MXCは、実行時の権限を制御する仕組みであり、要約の内容を正しくする機能ではないからだ。
さらに、PCのインターネット接続自体を切って、ローカルAIによる処理を試した。Windows側のcurlも名前解決に失敗する状態で元のメモを読み直させ、過去の要約ファイルを使わず、新しい要約を作って[offline-summary.md]へ保存するよう依頼した。
結果は、454bytesの新しいファイルが作成され、Windows側からUTF-8で内容を読み出せた。要約には記事の対象読者、画面写真を中心にする方針、メモの要約と「指定フォルダー」への保存、検証条件、未確認事項が含まれており、本文の情報を外部のLLMへ送らず、この作業をPC内で完結できることを実際に確かめることができた。
MXCの使いどころは「任せる作業に合わせて権限を絞ること」
今回の検証では、[Input]からの読み取りと[Output]への保存を許可しながら、[Input]への書き込みを拒否する環境を作れた。外部通信禁止の設定も適用された状態で処理を実行し、ローカルLLMによる要約と保存はオフラインでも確認できた。つまり、AIを安全に運用するための、「勝手に元データを改変しない」、「勝手に別のところに保存しない」、「ローカルで完結する」の3点がきっちり設定できたということになる。
要約の内容には人の確認が必要だったが、ファイルのアクセス権は実行環境側で制御できる。AIに任せる内容に応じて、使わせる場所と権限を選ぶという運用を具体化するのがMXCの意義だ。RTX SparkのようにローカルAIを使いやすいPCが登場する中、演算性能に加えて、そのAIをどう動かすか、安全をどう確保するかにも目を向けたい。
