AIエージェントのセキュリティ対策とは？主なリスクとMXCでできること・できないこと

AIエージェントは、依頼に応じて手順を考え、ファイル操作や通信まで進めるAIです。安全に使うには、AIに許可する操作（権限）を絞り、社内ルールと人の確認を組み合わせる必要があります。

本記事では、情報システム担当者（情シス）に向けて主なリスクを整理します。WindowsのMXCで守れる範囲と限界を解説し、自社で追加する対策をチェックリストにまとめました。

社員PCでAIエージェントが動くときの主なリスク

リスク	起きること	想定する具体例
ファイルの誤操作	不要な閲覧・削除・上書き	資料整理の途中で、保存すべき原本を削除する
社外への情報漏洩	外部サービスへデータを送る	分析のために顧客情報を未承認のサービスへアップロードする
プロンプトインジェクション	Webページや文書に混ぜられた指示で動作が変わる	読み込んだ文書に誘導され、依頼と無関係な送信を試みる
過剰な権限・シャドーAI	不要な操作が許可され、会社が把握していないAIも使われる	社員の広い権限を引き継いだ未申請ツールが共有資料を扱う

AIエージェントに作業を任せると、関連するツールも使いながら処理を進めます。文章を回答するだけの使い方に比べて、判断の誤りがPC上の操作に及ぶ点に注意が必要です。

チャット形式でも外部ツールが接続されていれば、同じ問題が生じます。画面の見た目ではなく、AIに何を読み取らせ、どの操作を許可しているかでリスクを確認しましょう。

意図しないファイルの閲覧・削除・書き換え

AIに広いファイル権限を与えると、依頼に不要な資料の閲覧や原本の変更につながるおそれがあります。例えば「フォルダを整理して」と頼んだ際、名前の似たファイルを重複と判断して削除するケースが考えられます。

同じフォルダでも、読む権限と書き換える権限は別です。参照用の資料を読み取り専用にすれば変更を制限できますが、閲覧できる情報そのものは減りません。

まずは作業用のコピーを用意し、閲覧と変更の権限を分けることが基本です。原本のバックアップと復元手順も準備し、誤操作が起きた場合に戻せる状態にしておきましょう。

社外へのデータ送信による情報漏洩

AIエージェントが外部サービスを使う場合、処理の途中で社内データがPCの外へ送られる可能性があります。例えば表の分析を依頼したところ、AIが外部の変換サービスを選び、顧客情報を含むファイルを渡すといった場面です。

許可した通信先と、送ってよいデータは別に管理する必要があります。業務で使うサービスへの通信を認めていても、全ての機密情報を送ってよいとは限りません。

AIモデルへの入力送信と、AIが操作する別のツールからの送信も区別しましょう。利用するAIサービスのデータ取扱条件を確認したうえで、追加ツールの送信先や添付内容にも確認の範囲を広げることが大切です。

外部の文書に仕込まれた指示に従ってしまう（プロンプトインジェクション）

プロンプトインジェクションとは、AIが受け取る情報に悪意ある指示を混ぜ、本来の依頼とは異なる動作へ誘導する攻撃です。社員が直接入力する文章だけでなく、AIが参照するWebページ・文書・メールも入り口になります。

ソフトウェアの安全性に関する情報を公開するOWASPの解説は、外部コンテンツを介した誘導を「間接的なプロンプトインジェクション」と説明しています。例えば資料の要約中に、文書内の指示を社員の依頼と誤認するケースです。そのまま別の情報の送信に進む危険があります。

対策は、AIへの注意書きだけに任せず、実行できる操作を狭めることです。外部文書を読む権限とデータを送信する権限を切り分け、影響の大きい操作には人の承認を挟みます。

権限の持ちすぎと、会社が把握していないAIツール

社員に必要な権限でも、AIの一つの作業には広すぎる場合があります。資料作成を任せるだけなのに、社員が閲覧できる共有フォルダ全体や管理画面まで使える状態にすると、誤った判断の影響も広がります。

「シャドーAI」は、会社が導入や利用を把握していないAIツールのことです。利用状況が見えなければ、何のデータを扱い、どこへ送信したかの確認も難しくなるでしょう。

利用申請では製品名に加えて、対象業務・データ・接続先を確認します。社員の権限をそのまま渡さず、AIの作業に必要な範囲だけ認める運用にすると、承認済みツールに不要な権限が残っていないかも点検できます。

AIエージェントの仕組みや業務への取り入れ方を知りたい方は、次の記事もご覧ください。

MXC（Microsoft Execution Containers）とは？

MXCは、プログラムが使えるファイルや通信などをルールで定め、実行中にその範囲を守らせる仕組みです。Microsoftは2026年10月7日の発表で、Windows 11向けの一般提供を公表しました。

AIへの文章による指示に加えて、プログラムを動かす側で操作を制限する点が特徴です。AIの作業を他の作業から分け、使える範囲を制限することを「隔離」と呼びます。対応ツールへの組み込みや設定が必要で、PC内の全てのAIに自動適用されるわけではありません。

MXCの仕組み：AIが触れる範囲を決めて守らせる

隔離方式	主な対象環境	仕組みの概要
プロセスコンテナ	Windows 11・macOS・Linux	基本ソフト（OS）ごとの仕組みで、プログラムが使えるファイルや通信を制限する
セッションコンテナ	Windows 11	別のアカウントと作業画面を使い、画面やコピーした内容の一時保管場所（クリップボード）を分ける
WSLコンテナ（WSLc）	Windows 11	WindowsでLinux環境を使うWSLを通じて、Linux向けのプログラムを動かす
MicroVM（試験的）	Windows 11のx64構成（64ビット構成の一種）のみ	PC内に別のコンピューター環境を作り、ハードウェアの仕組みで隔離する

MXCの「ポリシー」は、AIが使える範囲を定めるルールです。AIの作業の外側で管理されるため、AIや生成されたプログラムが自分で許可範囲を広げることはできません。

制限対象は、起動するプログラムとその条件、ファイルの読み書き、通信などです。画面やクリップボードへのアクセスも対象になります。例えば資料フォルダは読み取り専用、成果物フォルダは書き込み可能という設計です。

3つの動作モード（強制・学習・許容）

モード	ルールで認めていない操作	操作の把握
Enforcement（強制）	止める	モードによる学習用の記録は行わない
Learning（学習）	止める	拒否したアクセスを記録する
Permissive（許容）	通す	アクセスを記録する

MXCの学習モード資料で押さえておきたいのは、Learningが操作を止めたまま記録する点です。例えばテスト用データで通常業務を試し、拒否されたアクセスのうち本当に必要なものだけを許可した後、Enforcementで運用する流れが考えられます。

拒否の記録を全て許可へ置き換えると、制限を広げすぎる原因になります。Permissiveは制限対象の操作も通すため、機密情報を扱う本番運用の安全な初期設定とは考えないようにしましょう。

MXCに対応しているAIツール・今後対応予定のツール

ツール	対応区分	公式資料で確認できた範囲
GitHub Copilot	対応済み	公式発表でCLI（文字で操作指示を入力する方式）・アプリ・コード編集ソフトのVS Codeを案内。VS CodeはAIの作業を実行するAgent Hostの利用時が対象
OpenAI Codex	対応済み	Windows向け資料にMXCの利用条件と確認手順を掲載
OpenClaw	対応済み	機能を追加する公式プラグインを提供。ただし正式版の前の試験公開版（プレリリース）と明記
Unsloth AI	対応済み	リリース情報でWindowsのMXC利用と設定画面を案内
Replit・LM Studio・NVIDIA OpenShell	対応済みとして発表	Microsoftの2026年10月7日発表に記載。製品ごとの配布条件は別途確認が必要
Claude Code・Perplexity・Manus・Raycast	対応予定として発表	同発表で予定に分類。利用開始済みとは扱わない

Microsoftは対応済み・対応予定のツール一覧を公表しています。ただし「対応済み」でも、全バージョンや全プランで自動的に有効になるとは限りません。

導入時は、利用する製品のバージョンとOS要件を確認し、MXCが選ばれているかを点検します。発表時の予定を、そのまま提供開始済みの機能と読み替えないことが大切です。

Windows 365・Intune・Entraとの関係

Windows 365はインターネット経由でWindows PCを使うサービスで、MXC対応は一般提供済みと発表されています。一方、端末を管理するMicrosoft IntuneでのMXCポリシー管理は「近日提供予定」という位置付けです。

利用者などの身元を確認・管理するMicrosoft Entraで、AIの操作と人の操作を区別する機能も予定として案内されました。Microsoftの発表では、実行の隔離と企業向けの管理機能で提供段階が異なります。

MXCが一般提供されても、関連する管理機能まで全てそろうとは限りません。端末の隔離設定と、管理者が一括適用・監視できる範囲を分けて確認しましょう。

MXCでできること・できないこと

観点	MXCでできること	企業側で決める・追加すること
ファイル	設定と隔離方式に応じて読み書きを制限する	参照してよい資料、変更してよい原本を決める
通信	設定した通信ルールを実行環境で適用する	送信先だけでなく、送ってよい内容を判断する
操作の記録	対応するモードでアクセスの記録を得る	確認担当者・保管期間・異常時の対応を定める
作業の判断	許可範囲を越えるアクセスを制限する	許可範囲内で作る文章や送信内容の正しさを確認する
適用範囲	MXCに組み込まれた対象プログラムを隔離する	未対応ツールや隔離の外で動く連携先を管理する

MXCは実行時のアクセスを制限する仕組みであり、業務の判断全体を代わりに引き受けるものではありません。「操作できるか」と「その操作をしてよいか」を分けて設計すると、追加すべき対策が見えてきます。

MXCでできること

適切に設定されたMXCでは、対象プログラムが許可されていないファイルや通信先へアクセスする操作を制限できます。AIが「作業に必要」と判断した場合でも、実行環境のルールが認めていなければ、権限は自動的には増えません。

例えば原本の読み取りを認め、書き換えを拒否する使い方が考えられます。Learningのような対応モードを使えば、拒否されたアクセスを調べ、業務に必要な許可が足りているかの確認にも役立つでしょう。

ただし、ファイルの読み取り制限と書き込み制限は別の設定です。作業フォルダを指定しただけで、外のファイルが全て見えなくなるとは限りません。

MXCだけではできないこと

MXCだけでは、自社の業務に必要な許可範囲やデータの分類は決まりません。「どの顧客資料を使うか」「どの送信に承認が必要か」は、企業が業務と情報の重要度に合わせて定める必要があります。

許可した範囲内での判断ミスも残ります。例えば承認済みサービスへ通信できる状態では、誤った資料を選んだり、送信文章に不要な情報を含めたりする問題を、アクセス制限だけで判定することはできません。

未対応ツールや隔離の外で行われる処理にも、自動で制限が及ぶわけではありません。GitHubの実装解説も、ローカルの隔離と外部サーバー上の連携ツールを区別しています。実行場所ごとに、誰の権限で何が動くかを確認することが大切です。

導入するときの注意点

MXCの説明資料（README）では、Windows向けの一部のバックエンドを「experimental（試験的）」としています。通信先の制限方法もバックエンドによって異なるため、MXCという名称だけで保護範囲をそろえて判断しないようにしましょう。

特に、動作を調べる監査オプションと学習モードの違いは確認が必要です。プログラムを制限された範囲で動かす環境を「サンドボックス」と呼びます。READMEは、–auditがこの保護を外すため、信頼できないプログラムに使わないよう注意しています。

導入前に確かめるのは、必要なOS更新と製品バージョンです。架空のデータで拒否動作も試しましょう。設定名や「監査」という言葉から安全性を推測せず、許可される操作と止まる操作を確かめることが必要です。

企業が自分で足すべきAIエージェントのセキュリティ対策

企業側では、ツールの利用範囲とデータの扱いを決め、承認・記録・教育まで運用に落とし込む必要があります。WEELにも、社外のLLM（大量の文章を学習し、文章の理解や生成を担うAI）を安全に使いたい、重要文書を扱う環境づくりに悩んでいるといった相談が寄せられています。

まず対象業務を絞り、担当部門と情シスで必要な操作を洗い出しましょう。次の4点を具体化すると、技術的な制限と業務の手順を結び付けやすくなります。

使ってよいツールと権限を決める

承認済みツールの一覧には、製品名だけでなく用途と許可する操作も記載します。例えば「資料の要約は認めるが、社外へのメール送信は認めない」と決めれば、利用者と管理者が同じ基準で確認できます。

権限は、仕事に必要な最小限だけを与える「最小権限」の考え方で設定しましょう。共有フォルダ全体を渡す前に、必要な資料だけの参照で業務が成り立つかを検討します。

追加のツールや権限が必要になったときの申請先も明確にしましょう。利用する業務・データ・接続先の変更を再確認のきっかけにすると、一度の承認だけで利用範囲が広がり続ける状態を防ぎやすくなります。

機密データをAIの作業場所に置かない

AIの作業場所には、対象業務に必要なデータだけを置くことが基本です。顧客の連絡先が不要な集計なら、氏名やメールアドレスを除いたコピーを使い、原本は別の場所で管理します。

ただし、フォルダの分離と閲覧の禁止は別です。AIの実行権限が原本の保管先まで及んでいれば、移動後も読める場合があります。置き場所の整理とアクセス制限を併せて行いましょう。

作業用データの保管期限や削除担当者も決めておくと、処理後の放置を減らせます。入力ファイルだけでなく、要約結果や一時ファイルに機密情報が残っていないかも確認が必要です。

社外への送信や重要な操作の前に人が承認する

メール送信・外部へのアップロード・設定変更など、実行前に人が確認する操作を決めます。利用者が最初に依頼したという理由だけで、途中の全ての操作まで承認されたことにしない運用が大切です。

確認画面に示すのは、送信先・送る内容・添付ファイル・変更対象です。「実行しますか」だけでは影響がわからないため、何がどこへ渡るかを確認してから承認する形にしましょう。

承認後に送信内容が変わった場合は、再確認を求める設計が必要です。日常的な低リスク作業まで一律に承認対象とせず、取り消しにくい操作や機密データを扱う場面から優先して組み込みます。

記録を残して定期的に確認し、社員にも注意点を伝える

操作記録は、確認する担当者と頻度を決めて初めて運用に役立ちます。使ったツール・対象ファイル・送信先・承認結果などを必要な範囲で残し、通常と異なるアクセスや拒否の増加を点検しましょう。

記録自体に機密情報が含まれる場合もあるため、閲覧者と保管期間の管理も必要です。異常を見つけた際の利用停止、関係者への連絡、原因調査の担当まで決めておきます。

社員には、出所が不明な文書や不審な指示を見つけた場合の相談先を周知します。ただし隠された指示を全て人が見抜く前提にはせず、教育と権限制限・承認を組み合わせることが重要です。

【WEEL検証】AIエージェントの作業範囲を制限すると何が止まるか試してみた

今回のMXC設定では、作業内の保存が成功し、範囲外の読み取りと追記が拒否されました。文字で操作指示を入力するCodex CLIで依頼を送り、実行ログ（操作の記録）と保存ファイルの読み戻しで成否を確認しています。

検証の条件と手順

検証日は2026年10月26日、PCはASUS ROG Strix G513QRです。Windows 11 Pro 26H2（詳細な更新番号は26300.9711）上で、Codex CLI 0.162.1を使いました。画像は、起動時の設定と送信した依頼を文字で確認した記録です。

作業用フォルダをworkspaceと名付け、専用の権限設定で、データの読み書きをこの中に限定しました。OSと、操作指示を実行するソフトのPowerShellに必要な場所には、読み取りの例外を残しています。AIが起動するコマンド（文字で入力する操作指示）の外部通信は無効にしました。

AIサービスへの接続は、このコマンド側の通信制限とは別です。

架空の会議情報を使い、要約の保存、隣のoutsideフォルダの読み取り・追記、公開サイトへのGETを自然文で依頼しました。GETはページを取得するリクエストで、今回はファイル内容を送信していません。初回のAIへの依頼では、拒否後の権限追加や、別経路での再試行も行わない条件にしています。

検証の結果とわかったこと

試した操作	結果	実行記録と確認内容
作業内の資料を読み、要約を保存	通った	読み取り・保存とも終了コード0（正常終了）。要約を保存したresult.txtの内容も読み戻して確認
作業範囲外のファイルを読む	止まった	アクセス拒否を示すAccess to the path … is denied.を返して失敗
作業範囲外のファイルへ追記	止まった	同じくアクセス拒否。元のファイルは初期内容のまま
公開サイトへGET	通信は成立せず	サイト名から接続先を調べるDNSの処理に失敗。同じGETはMXC外ではHTTP 200（取得成功）

範囲外の読み取りと追記は、AIが自主的に控えたのではなく、実行後に明示的なアクセス拒否となりました。許可した場所での作業は進み、拒否対象のファイルは変更されていません。

2026年10月27日には、DNS処理を除いた追加確認も行いました。接続先のネットワーク上の住所に当たるIPアドレスを直接指定しています。通信を暗号化するHTTPSを使い、正しい接続先かを確かめる証明書の確認も有効にしました。MXC外ではHTTP 200で成功し、外部通信を無効にしたMXC内では接続に失敗しました。

追加確認は、AIへの再依頼ではなく、同じ権限設定でのコマンド単体の試験です。DNS処理を除いても通信は成立しませんでしたが、通信先ごとの許可・拒否の仕組みや送信内容の安全性まで立証した結果ではありません。他のツールや設定でも同じように保護されるかは、個別の確認が必要です。

許可範囲内での要約の正しさや、送ってよい情報の判断も別の課題です。実行環境でアクセスを制限しながら、データの選択と重要な操作の承認を企業側で定める必要があります。

AIエージェントのセキュリティ対策チェックリスト

チェック項目	確認する内容	主な担当
利用ツールの把握	承認済み・未申請のツールと用途を把握したか	情シス・現場
利用方針	任せる業務と、許容しない操作を決めたか	経営・情シス
最小権限	読み取りの範囲と、変更を認める範囲を分けて設定したか	情シス
データの分離	作業用データを最小化し、原本へのアクセスも制限したか	現場・情シス
送信先と内容	通信先の許可と、送ってよいデータを別々に決めたか	情シス・現場
人による承認	送信・アップロード・設定変更の確認者を決めたか	現場
実際の保護範囲	対応バージョン・モード・隔離の外にある処理を確認したか	情シス
操作記録	記録の確認担当・頻度・保管期間を決めたか	情シス
教育と申請	不審な文書の相談先と、ツール追加の申請先を周知したか	現場・情シス
事故時の対応	利用停止・連絡・復元の手順と判断責任者を決めたか	経営・情シス

確認できていない項目には、担当者と対応期限を付けて管理しましょう。まず限定した業務で制限と承認の流れを確かめ、利用するツールや接続先が変わった際にも見直すことが大切です。

AIエージェントの安全な導入・運用ならWEELへご相談ください

MXCのような仕組みを使えば、AIエージェントが動く範囲を技術的に制限できます。許可する範囲のルールと、人による確認手順は、自社で用意する必要があります。まずは対象業務と扱うデータを整理し、権限・承認・記録の担当を決めるところから始めましょう。自社に必要な対策の整理に迷う場合は、WEELの無料相談や資料もご活用ください。

AIエージェントのセキュリティに関するよくある質問