GitHub Copilotのローカルサンドボックスとは？一般提供開始・MXCの仕組み・有効化の方法とポリシー設定【2026年10月】

GitHub Copilotのローカルサンドボックスは、Copilotが開発者のPC上で実行するコマンドやツールについて、ファイル・ネットワーク・認証情報に触れられる範囲をOSの仕組みで制限する機能です。2026年10月7日に一般提供（GA）となり、追加料金はかかりませんが、初期状態ではオフなので自分で有効にする必要があります。

この記事でわかること

• ローカルサンドボックスで何を制限できるか、有効にしたときの既定値
• 基盤のMXC（Microsoft Execution Containers）の仕組みとOSごとの実装
• Copilot CLI・Copilotアプリ・VS Codeそれぞれの有効化手順
• 組織で強制するためのポリシー設定（managed settings）の書き方
• サンドボックスでは守れない範囲と、クラウドサンドボックスなど他の手段との違い

この記事の対象読者

• Copilot CLIやエージェントモードを使っていて、コマンドの自動実行に不安がある開発者
• 社内でCopilotのエージェント機能を許可するかどうか判断する情報システム部門・開発リーダー
• MXCが何なのか、Copilot以外のエージェントにも関係するのかを知りたい人

GitHub Copilot全体の機能やプランはGitHub Copilotとはで解説しています。

GitHub Copilotのローカルサンドボックスとは

出典：GitHub Changelog

Copilotが実行するコマンドを、自分のPCの中の決められた範囲でしか動けないようにする仕組みです。どのモデルを使っていても、ツールの実行にはサンドボックスのポリシーがかかります。

GitHubのChangelog（2026年10月7日）によると、一般提供の対象は次の3つです。

基本情報

6月のプレビューからの経緯

6月時点の解説記事には「--experimental が必要」「WindowsはInsider版が必要」といった記述がありますが、GA後の現行仕様とは異なります。古い手順を見て設定する場合は注意してください。Build 2026全体の発表内容はMicrosoft Build 2026まとめにまとめています。

なぜ今サンドボックスが必要なのか

Copilotのエージェント機能は、依存パッケージのインストールやテストの実行、git操作までをコマンドで進めます。便利な反面、リポジトリ内のファイルやIssueの文面、依存パッケージに仕込まれた指示（プロンプトインジェクション）によって、意図しないコマンドが実行されるおそれがあります。

ローカルサンドボックスは、そうしたコマンドが実行されてしまった場合でも、届く範囲を作業ディレクトリや許可した通信先に限定するための防御層です。AIエージェントのリスク全般はAIエージェントのセキュリティ対策ガイドで整理しています。

ローカルサンドボックスで制限できること

制限できるのは「ファイル」「ネットワーク」「認証情報」「ローカルのMCPサーバー・言語サーバー」の4つです。ただし、有効にしただけではネットワークも認証情報も閉じません。既定値を把握してから設定を詰める必要があります。

制御できる項目

• ファイルシステム: エージェントが実行するコマンドが読み書きできるファイル・ディレクトリを制限する。明示的に許可していないパスにはアクセスできない（拒否が既定）
• ネットワーク: インターネットへの外向き通信、ローカルネットワークへのアクセス、宛先ホストごとの許可・拒否
• 認証情報: GitとGitHub CLI（gh）の認証、環境変数に入ったシークレットのマスク
• MCPサーバー・言語サーバー: 対応環境では、ローカルで動くMCPサーバーや言語サーバー（LSP）にもサンドボックスをかける
• 組織による強制: エンタープライズの管理設定で有効化を必須にし、開発者が緩められないようにする

MCPの基本はMCPとはを参照してください。

有効にしたときの既定値（Copilot CLI）

GitHub Docsに記載された既定値をまとめると次のとおりです。

つまり、既定のままで防げるのは主に「作業ディレクトリの外への書き込み」と「ローカルネットワークへの接続」です。外部への通信やGitHubへのpushは通るため、機密性の高いリポジトリでは追加の設定が必要になります。

認証情報のマスクの仕組み

マスク対象に指定した環境変数は、サンドボックス内のツールには本物の値ではなくプレースホルダーとして渡されます。本物の値は、ローカルのプロキシが「承認されたHTTPSの宛先」に送る通信にだけ差し込みます（設定キーは sandbox.credentials.envVars.<NAME>.injectHosts）。APIキーを使うテストは通しつつ、別のホストへ持ち出されるのは防ぐ、という使い方を想定した設計です。

MXC（Microsoft Execution Containers）の仕組み

出典：GitHub（microsoft/mxc）

MXCは、AIエージェントのように「信頼しきれない、その場で生成される処理」を、ポリシーに沿って隔離して実行するためのMicrosoftの実行レイヤーです。共通のポリシーを、Windows・macOS・Linuxそれぞれに備わった隔離機能の設定に変換して適用します。

Windows Developer Blog（2026年10月7日）では、Windowsのエージェント向け機能を「封じ込め（containment）」「ID（identity）」「管理性（manageability）」の3本柱で説明しており、MXCはこのうち封じ込めを担います。ポリシーはエージェント自身が書き換えられない場所に置かれ、実行時にOSが強制する、という考え方です。

Copilotが使っているのは「プロセスコンテナ」

MXCには複数の隔離方式（バックエンド）があり、Copilotのローカルサンドボックスが使っているのは最も軽量なプロセスコンテナです。

MXCのリポジトリには、このほかWindows SandboxやHyperlight（いずれも実験的）、LinuxのLXCも記載されています。

ポリシーと動作モード

MXCのポリシーで指定できる領域は、隔離環境の種類、プロセス（コマンド・引数・作業ディレクトリ・環境変数）、ファイル（読み取り・書き込み・ブロック）、ネットワーク（受信・送信・ループバック）、UI（デスクトップへのアクセス）です。

動作モードは3種類あります。

活動レポートはWindowsのプロセスコンテナでのみ出力されます。CLIツール wxc-exec.exe の --audit オプションはサンドボックスを無効にして記録するため、公式は信頼できないコードには使わないよう明記しています。

オープンソースでCopilot専用ではない

MXCはMITライセンスで公開されており、Rust・.NET・Node.js向けのSDK（npmの @microsoft/mxc-sdk は1.0.0）が用意されています。Microsoftの発表では、GitHub Copilotのほか、OpenAI Codex、OpenClaw、Replit、LM Studio、Unsloth AIが対応済みで、Anthropic Claude Code、Manus、Perplexity、Raycastなどが今後対応予定とされています。

Windowsの管理面では、Windows 365（Cloud PC）でのMXC対応がGAとなった一方、Intuneによるポリシー配布やMicrosoft Entra・Agent 365によるエージェント活動の識別は「近日提供」の段階です。

なお、Hacker NewsでのMXC 1.0.0の話題には「1.0と呼ぶには早い」「ドキュメントやエラーメッセージが不十分」「bubblewrapを直接使うのと何が違うのか」といった懐疑的な声も多く、評価は割れています。企業での管理機能に期待する意見もあり、今後のIntune連携などの提供状況を見て判断するのが現実的です。

ローカルサンドボックスの有効化の方法

出典：Visual Studio Code Documentation

Copilot CLIは /sandbox enable、Copilotアプリはプロジェクト設定の「Sandbox new sessions」か /sandbox on、VS Codeは設定 chat.agent.sandbox.enabled を on にします。3つの環境で設定は別々に管理されるので、使う環境ごとに有効にしてください。

Copilot CLIで有効にする

1. 対話セッションで /sandbox enable を実行する。そのセッションに加え、以降に開く対話セッションやプロンプトモードの実行にも適用され、/sandbox disable するまで続く
2. すでに開いていた別のセッションには反映されない。copilot --continue で開き直すか、そのセッションでも /sandbox enable を実行する
3. 1回だけサンドボックスで動かしたい場合は copilot --sandbox で起動する。プロンプトモードと組み合わせるなら copilot --sandbox -p "PROMPT"
4. /sandbox status で有効かどうか、/sandbox policy で実際に読める・書ける・ブロックされるパスを確認する
5. 有効中はステータスラインに「sandbox enabled」と表示される（表示の切り替えは /statusline）

/sandbox policy npm install のようにコマンドを付けると、そのコマンドを実行せずに、必要な開発ツールへのアクセスが許可されているかを確かめられます。ビルドが通らないときの原因調査に役立ちます。

設定は ~/.copilot/settings.json の sandbox キーに保存されます。リポジトリ単位の設定ファイルには対応していない点に注意してください。

Copilotアプリで有効にする

• プロジェクトの既定にする: Settings > Projects > Sandbox で「Sandbox new sessions」をオンにすると、そのプロジェクトで新しく始めるセッションがサンドボックスで動く
• 実行中のセッションだけ切り替える: /sandbox on（再起動後もそのセッションでは継続し、プロジェクトの既定より優先）／/sandbox off
• セッションを始める前に /sandbox on を実行すると、プロジェクトの既定が変わる
• 設定の変更は新しいセッションか /restart-session で反映される

アプリの初期設定では、ワークスペースと現在のディレクトリは読み書きでき、外向き通信・ローカルネットワーク・Git／GitHub CLIの認証もオンです。依存パッケージのインストール、開発サーバーの起動、ブランチのpush、PR作成はそのままできます。

対象はローカルのリポジトリやワークツリーで動くセッションだけで、クラウドサンドボックスのセッションやリモートホストのセッションには適用されません。また、アプリとCLIのサンドボックス設定は別管理です。アプリそのものの機能はGitHub Copilotアプリとはで紹介しています。

VS Codeで有効にする

1. 実行するマシンでOSの前提条件を満たす（macOSは特別な準備不要、Linuxは bubblewrap と socat が必要）
2. 設定 chat.agent.sandbox.enabled を on にする（既定は off）
3. 新しいエージェントセッションを始める
4. /sandbox policy でポリシーを確認する。結果は sandbox-policy.md として出力され、サンドボックスがオフの状態でも実行できる。モデルの呼び出しは発生しない

セッションごとの切り替えは、Permissionsメニューの「Sandboxing for terminal」で行えます。

VS Codeでの主な設定キーと既定値は次のとおりです。

旧設定の chat.agent.sandbox.enabledWindows は削除され、chat.agent.sandbox.allowNetwork は network.allowNetwork に移っています。古いブログの設定例をそのまま貼らないようにしてください。

VS Codeで対象になるのは、Agent Hostが標準で使うCopilot SDKのツールです。従来のLocalチャットのハーネスや、独自に用意したターミナルには適用されません。また、権限レベルを「Allow all」にしてもサンドボックスは有効なままです。コマンドを確認なしで実行するかどうか（承認）と、実行されたコマンドが何に触れられるか（サンドボックス）は、別々の仕組みとして動きます。VS CodeでのCopilotの設定変更の例としては、VS Codeの共同作成者表記の既定変更も参考になります。

細かい設定：ファイル・ネットワーク・認証情報

CLIでは /sandbox を実行すると設定画面が開き、General・Credentials・Filesystem・Networkの4つのタブで項目を調整できます（Tabで切り替え、Escで保存して閉じる）。厳しくしたい場合に役立つのは、通信先の許可リスト、拒否パス、gh認証の停止の3つです。

ファイルのルール

• 許可していないパスにはアクセスできない（拒否が既定）
• より具体的なパスの指定が優先される。たとえば /project を書き込み可、/project/secrets を読み取り専用にできる
• VS Codeでは優先度が「拒否 > 読み取り専用 > 読み書き」と明記されている

注意したいのは、拒否したパスが存在しないと、Copilotがそのパスを作ってしまう点です。たとえば存在しない .env を拒否パスに入れると、.env という名前のディレクトリが作られ、プロセス終了後も残ります。また、Linuxではシンボリックリンクの拒否が確実に効かないため、リンク先の実体ディレクトリを拒否してください。

ネットワークのルール

• ホストごとに許可（allow）と拒否（deny）を設定できる。UIで追加したルールの既定は拒否
• 拒否が許可より優先される
• 許可ルールを1つでも置くと、一致しないホストはすべてブロックされる（許可リスト方式になる）
• 社内のプロキシ経由で出したい場合はリモートプロキシを設定する

npmレジストリとGitHubだけに通信を絞る、といった運用は許可ルールで実現します。

認証情報のルール

• 「Authenticate git」「Authenticate gh」をオフにすると、サンドボックス内のコマンドにGitHubのトークンが渡らなくなる
• 「Masked environment variables」にAPIキーなどの環境変数名を入れると、プレースホルダーに置き換わる

機密リポジトリで使う場合の設定例（編集部の提案）

公式が示す推奨値ではありませんが、社外秘のコードを扱う場合は次のような組み合わせが考えられます。

組織でのポリシー設定（managed settings）

組織でサンドボックスを必須にするには、エンタープライズの管理設定（managed settings）の sandbox に enabled: true を書いて配布します。管理設定は「既定値」ではなく「制限」として働くため、開発者側で緩めることはできません。

配布方法

管理設定に対応するクライアントは、Copilot CLI、VS Code、Copilotアプリ、Copilot cloud agent、JetBrains IDEです（設定項目ごとに対応状況は異なります）。設定が正しく読み込まれたかは、エンタープライズのAI controls > Agentsタブにある「Copilot settings validation」で確認できます。MDMで使う具体的な設定ファイル名やレジストリキー、ファイルベースの配置場所は、公式ドキュメントで最新の記載を確認してください。

なお、ここでいうMDMでの配布は「Copilotの管理設定を配る」話で、Windows側のMXC用Intuneポリシー（近日提供）とは別のものです。

公式の記述例

GitHub Docsには、次の記述例が掲載されています。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowBypass": false,
    "sandboxMcpServers": true,
    "sandboxLspServers": true
  }
}

主な設定キー

運用で押さえておきたい点

• true/falseの意味が項目で異なる: 強制オンの項目は true で強制し、false や省略ではユーザー設定のままになる。一方、能力を与える項目は false で禁止になる
• パスの許可は積集合: userPolicy のファイルパスは、すべての管理ソースに同じ文字列で書かれている場合だけ許可される。拒否パスは足し算になる
• ホストの許可も両方を満たす必要がある: 管理側とユーザー側のホストルールの両方を満たすホストだけが許可され、重なりがなければすべて拒否される
• チームごとの上書きは sandbox 全体単位: overridable で sandbox オブジェクトごと包む。チーム用ファイルの sandbox は既定全体を置き換えるので、残したい制限は書き直す
• failIfUnavailable の副作用: OSの更新が遅れている端末では、Copilotそのものが使えなくなる。全社展開の前に端末のOSバージョンをそろえておく
• 管理されている値は、CLIなどのUIで「(managed)」と表示され変更できない。Copilotアプリはプロジェクト設定だけを表示し、管理ポリシーの全体は見せない

VS Code側では、管理設定に対応するのはバージョン1.138.0以上、セッションのサンドボックス切り替えをロックするには1.140.0以上が必要です。また、VS Codeのドキュメントでは「Managed sandbox enforcement」にPreviewの表記が残っています。

Copilotを業務で使う場合は、サンドボックスとあわせて学習利用の設定も確認しておくと安心です（Copilotの学習利用をオプトアウトする方法）。さらに、Copilotで作った試作ツールを社内の実データや既存システムにつないで使う段階になると、サンドボックスの設定だけでなく、認証情報の管理、テスト、運用の担当を誰が持つかを決める必要が出てきます。その段階で必要になる作業はAIで作ったアプリを開発会社へ引き継ぐにはで詳しく扱っています。

対応OSと前提条件

Windows 11・macOS・Linuxに対応していますが、OSごとに前提条件があります。条件を満たさない端末では、弱い制限のまま動くのではなく、サンドボックスが使えない旨を通知する（または失敗する）設計です。

Windowsの必要な更新プログラムは、公式ドキュメント間で記載が一致していません。GitHub Docsでは「25H2はKB5124010以降、26H1はKB5124006以降」とされ、VS Codeのドキュメントでは「2026年9月8日のセキュリティ更新（24H2/25H2はKB5124008、26H1はKB5124012）」と書かれています。さらにVS CodeではWindows対応が「Experimental」扱いです。正確な対応状況は、GitHubが案内している aka.ms/ghcp-sandbox-os-support で確認してください。

非対応の端末で起きることは次のとおりです。

• Copilot CLI: 保存済みの有効化設定をそのセッションだけ無効にして通知する。/sandbox enable は受け付けない
• 管理設定で enabled と failIfUnavailable が true の場合: モデルの呼び出しとツールの実行がブロックされる
• Copilotアプリ: 起動時にサンドボックス対象のプロセスが失敗する

ローカルサンドボックスで守れないこと・注意点

ローカルサンドボックスは便利な安全網ですが、万能ではありません。GitHubもVS Codeも「VMやユーザーアカウントの境界ではなく、エンドポイントセキュリティの代わりにはならない」と明記しています。サンドボックス内のプロセスも、あなた自身のアカウントで動いています。

サンドボックスの外で動くもの

DevelopersIOのプレビュー期（2026年6月）の検証では、外向き通信をオフにしてもシェルの curl は遮断された一方、Copilot内蔵のWeb取得機能ではページを取得できたと報告されています。現行版で同じ挙動かは確認していませんが、「ネットワーク遮断＝Copilotが外部の情報を読めない」とは限らない点は覚えておくべきです。リモートMCPを使う場合の注意点はGitHub MCP Serverの使い方も参考にしてください。

OSごとの制約

• Windows: プロキシやホストルールは、プロキシ設定に従うプログラムにしか効かず、直接接続を完全には防げない。プロキシ・ホスト制限・認証情報マスクを使うには「Allow local network」が必要
• Linux: bubblewrapでは、起動したプロセス（シェル、ローカルMCP/LSP）ごとにローカルネットワークを細かく制御できない。サンドボックス内からホストのlocalhostへ直接はつながらない
• macOS: ローカルプロキシが有効なとき、ローカルアクセスを許可してもポートでの待ち受けはできるが、直接の接続はできない

設定面の落とし穴

• 既定はオフ。有効にし忘れると従来どおり全権限で動く
• 有効化しても外向き通信とgit/gh認証はオン。データの持ち出しやpushは既定のままでは止まらない
• allowDevToolAccess は既定で、レジストリのトークンを含む開発ツールの設定やキャッシュの読み取りを許可する（VS Codeのドキュメント）。厳しく運用するならオフにして必要なパスを明示的に許可する
• 書き込みできるキャッシュは、サンドボックス外のコマンドと共有されることがある

サンドボックスの外に出ようとするエージェントの挙動は実際に報告されています。事例はOpenAIのDNS経由のサンドボックス脱出の件を参照してください。自動承認とプロンプトインジェクションの関係はClaude Codeのオートモードとプロンプトインジェクションでも解説しています。

クラウドサンドボックス・他のサンドボックス手段との違い

出典：GitHub Changelog

ローカルサンドボックスは「自分のPC上で、無料で、軽く制限をかける」手段です。PCから完全に切り離したいならクラウドサンドボックス、環境ごと分けたいならコンテナやVMを使う、という選び方になります。

ローカルとクラウドのサンドボックスの比較

クラウドサンドボックスのプレビュー特典（対象アカウントに月10ドル分）は2026年7月末で終了しています。Copilotの料金体系全体はGitHub Copilotの料金プランで確認できます。

他の手段との選び分け

Claude Codeのサンドボックスや権限設定はClaude Codeのセキュリティガイド、両ツールの機能差はClaude CodeとGitHub Copilotの比較で比べています。

ローカルサンドボックスの有効化をおすすめする人・急がなくてよい人

Copilotにコマンドを自動実行させている人は、今すぐ有効にする価値があります。一方、補完やチャットだけで使っている人には、影響する場面がほとんどありません。

おすすめする人

• Copilot CLIやエージェントモードで、コマンドの承認を自動化している（Allow allなど）
• 他人が書いたリポジトリやIssue、外部のパッケージをエージェントに扱わせることが多い
• ローカルのMCPサーバーを複数つないでいる
• 社内でCopilotのエージェント機能を許可したいが、全権限での実行は認めにくい情報システム部門
• macOS 15以降、条件を満たすLinux、最新の累積更新を当てたWindows 11を使っている

急がなくてよい人・別の手段を検討したい人

• コード補完とチャットだけで、エージェントにコマンドを実行させていない人
• Windowsの更新が管理上すぐに当てられない環境（failIfUnavailable で業務が止まるおそれがある）
• 信頼できないコードを本格的に隔離して実行したい人（クラウドサンドボックスやVMの方が適している）
• JetBrains IDEでエージェントを使っている人（GAの対象はCLI・アプリ・VS Codeの3つ。JetBrainsでのローカルサンドボックス対応は現時点で確認できていない）

利用者別の始め方

よくある質問

Copilot Freeプランでもローカルサンドボックスは使えますか？

公式のChangelogと料金ドキュメントは「Copilotに含まれ、追加料金なし」としているだけで、Free・Pro・Business・Enterpriseなどプランごとの可否は明記していません。Freeプランで使えるかは、2026年10月12日時点で確認できていません。

サンドボックスを有効にするとCopilotの動作は遅くなりますか？

性能への影響について、公式の記載は見当たりません。方式はVMではなくOSのプロセス単位の制限なので重い仕組みではありませんが、プロキシ経由の通信などで差が出る可能性はあります。気になる場合は、普段使うビルドやテストで比べてみてください。

有効にしたら、ブロックされたコマンドはどうなりますか？

CLIでは、より広い権限で再試行するかを聞かれ、「1回だけ許可」「ブロックのまま」「このセッションで無効化」から選べます。アプリでは「Run outside the sandbox?」という確認が出ます。どちらも、バイパスを許可するとそのコマンドではシークレットのマスクも外れます。管理者が allowBypass: false にしている場合、この選択肢は出ません。

AIクレジット（GitHub AI Credits）は消費しますか？

ローカルサンドボックスは追加料金なしとされていますが、「AIクレジットを消費しない」とは公式に明記されていません。サンドボックス自体はモデルを呼ぶ機能ではないため、クレジットに影響するのは従来どおりモデルの利用分と考えられます。

Claude CodeでもMXCは使えますか？

MicrosoftはAnthropic Claude CodeをMXCの「今後対応予定」のエージェントとして挙げています。時期は発表されていません。現時点では、Claude Code自身のサンドボックス機能と権限設定を使うことになります。

クラウドサンドボックスとローカルサンドボックスは同時に使えますか？

別の機能で、Copilotアプリのローカルサンドボックス設定はクラウドサンドボックスのセッションには適用されません。なお、Copilotがタスクをローカルとクラウドのどちらで動かすかを自動で判断する機能は、GitHubとMicrosoftが2026年10月中の提供予定として発表しています。

まとめ

• GitHub Copilotのローカルサンドボックスは、Copilotが実行するコマンドのファイル・ネットワーク・認証情報へのアクセスを、MXCを通じてOSの仕組みで制限する機能。2026年10月7日にGAとなり、追加料金はかからない
• 対象はCopilot CLI・Copilotアプリ・VS CodeのAgent Hostの3つ。既定はオフで、CLIは /sandbox enable、アプリは「Sandbox new sessions」、VS Codeは chat.agent.sandbox.enabled で有効にする
• 有効にしても外向き通信とgit/gh認証は既定でオン。機密リポジトリでは許可ホストの登録、拒否パス、gh認証の停止を組み合わせる
• 組織では managed settings の enabled・allowBypass・failIfUnavailable で強制できる。failIfUnavailable はOS更新が遅れた端末でCopilotを止めるので、展開は段階的に進める
• 組み込みツール、リモートMCP、バイパスを許可したコマンドはサンドボックスの外になる。エンドポイントセキュリティや承認設定の代わりにはならない

AIエージェントの基本から押さえたい場合はAIエージェントとはもあわせてご覧ください。

主な出典

• GitHub Changelog: Local sandboxing for GitHub Copilot now generally available（2026年10月7日）
• GitHub Docs: About cloud and local sandboxes
• GitHub Docs: Using local sandboxing
• GitHub Docs: Configuring local sandbox settings
• GitHub Docs: Enterprise managed settings
• GitHub Docs: Billing for cloud and local sandboxes
• VS Code Docs: Sandbox agent terminal commands
• Windows Developer Blog: Microsoft Execution Containers（2026年10月7日）
• microsoft/mxc（GitHub）