2026.10.16 開発

GitHub Copilotのサンドボックスとは？有効化手順と組織で強制する管理設定【2026年10月】

GitHub Copilotのローカルサンドボックスは、Copilot CLI・GitHub Copilot app・VS CodeのAgent Hostセッションで、エージェントが実行するシェルコマンドをOSの隔離機構の中に閉じ込める機能です。2026年10月7日に一般提供となり、追加料金はかかりません。この記事では、/sandbox enable で有効にしてポリシーを確かめる手順、個人の settings.json とVS Codeの設定例、managed-settings.json で組織に必須化する記述と配布、そして必須化を見送るべき環境までを、2026年10月時点の公式ドキュメントにもとづいて整理します。

まとめ：GitHub Copilotのローカルサンドボックスを組織で必須にする判断

ローカルサンドボックスは既定でオフです。個人で試すならCopilot CLIで /sandbox enable を打ち、/sandbox policy で実際に許可されている範囲を見るところから始めます。既定の構成では作業ディレクトリへの書き込みと外向きの通信が許されたままなので、有効化しただけで情報の持ち出しまで止まるわけではありません。

組織で強制する場合は、.github-private リポジトリの copilot/managed-settings.json に sandbox.enabled と failIfUnavailable を書き、バイパスを禁じるなら allowBypass を false にします。ただし sandbox キーを足した時点で、Copilot CLI 1.0.93未満などの古いクライアントは接続できなくなります。配布の前にクライアントの版をそろえてください。

VMやユーザーアカウントの境界ではない点も変わりません。信頼できない第三者のコードを流すなら、クラウドサンドボックスやコンテナ側で隔離します。

ローカルサンドボックスがCopilotのどのコマンドをOSの境界で止めるか

最初に、何が隔離され、何が外れるのかを押さえます。ここを誤解したまま必須化すると、守れていない経路が残ります。

2026年10月7日のGAで対象になったCLI・app・VS Codeの3クライアント

GitHubのchangelogによれば、一般提供の対象はGitHub Copilot CLI、GitHub Copilot app、Agent Hostを使うVS Codeセッションです。制御できるのはファイルシステム、ネットワーク、GitとGitHub CLIの認証情報で、ローカルのMCPサーバーや言語サーバーにも同じポリシーを掛けられます。料金はCopilotのシートに含まれます。

GA前のCopilot CLIでは実験的機能の扱いで、--experimental を付けて起動する必要がありました。手元の古い手順書がこの前提で書かれていれば、更新が必要です。CLI自体の動作モードはGitHub Copilot CLIのAutopilotとはで扱っています。

MXCがOSごとの隔離機構へポリシーを変換するSeatbeltとbwrapの役割

中身は Microsoft eXecution Container（MXC）です。共通の書式で書いたポリシーを、各OSの仕組みに置き換えて適用します。GitHubの概要ページでは、macOSはSeatbeltでmacOS 15以降、LinuxはBubblewrap、Windowsはサンドボックス対応の更新を当てたWindows 11を使うと説明されています。

方式は軽量です。コマンドはVMやコンテナの中ではなく、手元のOS上でプロセスとファイルシステムの制限を受けて動きます。MXCのバックエンドの種類やSDKから直接使う方法は、親記事のMicrosoft Execution Containers（MXC）とはにまとめました。

シェルコマンドは隔離されファイル編集ツールとリモートMCPは外れる境界

ローカルサンドボックスの解説ページは、対象を明確に分けています。OSが直接強制するのは、シェルコマンドと組み込みの検索です。ローカルのMCPサーバーとLSPも既定で中に入ります。

一方、組み込みのファイル読み取り・編集ツールはCLIのプロセス内で動くため、OSの制限は掛かりません。公式はこれを「software-only safeguard」と書いています。リモートMCPサーバーもファイルシステムのポリシーの外です。さらに読み取りはリポジトリ全体に及ぶので、サブディレクトリの外にある機密ファイルも読める場合があります。

Copilot CLIで/sandbox enableを実行しポリシーを確かめる手順

ここからは、個人の端末でCLIを使って有効化し、許可範囲を確かめるまでの作業です。

Windows 11のKB更新とLinuxのbwrap 0.5.0以上という前提条件

利用手順のページは、Windowsに25H2のKB5124010以降、または26H1のKB5124006以降を求めています。ProcessContainerのBaseContainer層に対応している必要があるためです。Linuxでは bwrap 0.5.0以上と slirp4netns がPATH上に要ります。

要件を満たさないホストでは、CLIは弱い制限で動かすのではなく、要件不足を報告して止まります。VS Code側は後述のとおり別のKB番号を案内しているので、両方を使う部署は2つの表記を突き合わせてください。

/sandbox status・policyで実効ポリシーをコマンド実行前に確かめる

有効化の内容は個人設定ファイル（既定は ~/.copilot/settings.json）の sandbox.enabled に保存され、以後のセッションにも引き継がれます。手順は次のとおりです。

/sandbox enable
/sandbox status
/sandbox policy
/sandbox policy npm install

# 1回だけ使う場合の起動オプション
copilot --sandbox -p "テストを実行して、失敗したケースを要約して"

/sandbox policy は、個人設定・自動付与・管理ポリシーを合成した結果を表示します。コマンド名を続けると、実行せずにそのコマンドが受け取る開発ツールのアクセスだけを確認できる仕組みです。既に開いているセッションには即時反映されないため、copilot --continue で開き直すか、そのセッションで有効化します。

settings.jsonのsandboxキーで認証情報マスクと拒否パスを書く例

API用のトークンを環境変数で渡している場合は、マスクの設定を入れます。設定ページの記述例は次の形です。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "envVars": {
        "EXAMPLE_API_TOKEN": {
          "injectHosts": ["api.example.com"]
        }
      }
    }
  }
}

サンドボックス内のツールにはプレースホルダーが渡り、実際の値はローカルプロキシが api.example.com へのHTTPSリクエストにだけ差し込みます。injectHosts は通信の許可ではないので、ネットワーク側のルールでも同じホストを許す必要があります。平文のHTTP、リクエスト本文、URLに埋めた値には実値が入りません。リポジトリ内の設定ファイルにはサンドボックス設定を書けない点にも注意してください。

存在しない.envを拒否するとディレクトリが作られる失敗とその回避策

拒否パスに、まだ存在しないパスを指定すると、CLIはコマンド開始前にその場所へディレクトリを作ります。親ディレクトリも含めて作られ、自動では消えません。まだ無い .env を拒否すると、ファイルではなく .env という名前のディレクトリができてしまいます。

ファイルとして守りたいなら、サンドボックスの外で先に空ファイルを作ってから拒否します。Windowsで必要な更新が未適用だと、PowerShellのカレントディレクトリが C:\ と報告されることもあり、公式は git -C で絶対パスを渡す回避策を示しています。

Copilot appとVS Code Agent Hostで設定する場所と既定値の違い

CLIとappの設定は互いに同期しません。VS Codeもキー体系が別です。同じポリシーにしたいなら、3か所に書く前提で計画します。

Copilot appのSandbox new sessionsが新規だけに効く理由

Copilot appでは「Settings」から対象プロジェクトの「Sandbox」を開き、Sandbox new sessions をオンにします。これはプロジェクトの既定値で、既存のセッションには反映されません。実行中のセッションだけを切り替えたいときは、チャット欄で /sandbox on または /sandbox off を使います。

ポリシーの変更は新規セッションか再起動で効きます。履歴を残して再起動するなら /restart-session です。クラウドサンドボックスやリモートホストのセッションでは、この切り替えは使えません。

VS Codeのchat.agent.sandbox設定で外向き通信を絞る記述例

VS Codeのドキュメントでは、Copilot harnessセッションの設定キーは chat.agent.sandbox.* です。既定は off で、有効にしても外向き通信は既定で止まらないと注意書きがあります。通信先を絞る例は次のとおりです。

{
  "chat.agent.sandbox.enabled": "on",
  "chat.agent.sandbox.network.allowNetwork": true,
  "chat.agent.sandbox.network.allowedDomains": [
    "api.github.com"
  ],
  "chat.agent.sandbox.network.deniedDomains": [
    "example.com"
  ]
}

WindowsのVS Codeはまだ実験的扱いで、24H2・25H2はKB5124008、26H1はKB5124012が必要とされています。LinuxとWSL2では bubblewrap と socat が要り、WSL1は対象外です。

CLI・app・VS Codeで設定が同期しない3か所の既定値の比較

同じ「サンドボックスをオン」でも、どこに書き、何が既定で許されているかが少しずつ違います。

項目	Copilot CLI	Copilot app	VS Code
保存先	個人のsettings.json	プロジェクト設定	VS Codeのsettings.json
外向き通信	許可	許可	許可
ローカルネットワーク	拒否	許可	拒否
Git・gh認証	許可	許可	許可
サンドボックス外の実行要求	承認制で可	承認制で可	承認制で可

ローカルネットワークの既定がappだけ「許可」になっている点は見落としやすい差です。開発サーバーへの接続を前提にした設計かどうかを、端末の利用形態と合わせて決めてください。

managed-settings.jsonでサンドボックスを組織に強制する設定と配布

個人設定は利用者が戻せます。組織として外せない状態にするには、エンタープライズの管理設定を使います。管理設定は利用者の設定を狭めることはできても、広げることはできません。

failIfUnavailableとallowBypassで抜け道を塞ぐ記述例

管理設定のリファレンスにある基本形へ、拒否パスと遮断ホストを足した例です。userPolicy の部分はリファレンスのプロパティ名に合わせて筆者が組み立てたもので、パスとホストは自社の値に置き換えます。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowBypass": false,
    "sandboxMcpServers": true,
    "sandboxLspServers": true,
    "userPolicy": {
      "filesystem": {
        "deniedPaths": ["/Users/Shared/secrets"]
      },
      "network": {
        "blockedHosts": ["paste.example.com"]
      }
    }
  }
}

enabled だけでは、要件を満たさないホストでサンドボックスなしのまま動く余地が残ります。failIfUnavailable を併せて true にすると、強制できない端末ではモデルへのリクエストとツール実行そのものが停止する設定です。allowBypass を false にすると、1回ごとの外での実行承認もセッション単位の無効化もできなくなります。

userPolicyで拒否パスと許可ホストを絞るときの合成ルール

管理ソースが複数あっても、どれか1つが上書きするのではなく、最も制限の強い方向で合成されます。拒否パスはすべてのソースから足し合わされ、利用者が自分で足した許可パスは、管理側すべてに同じパスがある場合にだけ有効です。

ホストは allowedHosts が空でなければ、一致しない宛先がすべて遮断されます。blockedHosts は allowedHosts より優先され、ドメインを指定するとサブドメインも止まります。最初から許可リスト方式にすると、パッケージレジストリや社内ミラーを書き漏らした時点でビルドが止まるので、まずは遮断リストから始める方が安全です。

sandboxキー追加でCLI 1.0.93未満が接続を止められる版の下限

リファレンスには、sandbox キーを追加すると、対象の利用者は最小版以上のクライアントが必要になると書かれています。古いクライアントは更新するまでCopilotに接続できません。

クライアント	sandboxキーの対応	最小版
Copilot CLI	対応	1.0.93
VS Code	対応（Agent Host）	1.141.0
GitHub Copilot app	対応	1.1.26
Copilot cloud agent	非対応	なし
JetBrains IDEs	非対応	なし

JetBrains系IDEのCopilotはこの管理キーの対象外です。全社に配っても、JetBrains利用者のエージェント実行はサンドボックスで縛れていないことになるため、利用IDEの棚卸しを先に済ませます。

.github-private経由は約1時間・ファイル配布は再起動で反映

管理設定の始め方によると、エンタープライズが指定した組織の .github-private リポジトリに copilot/managed-settings.json を置き、既定ブランチへコミットします。対応クライアントには約1時間で届き、再起動かサインインで即時に取り込まれます。MDM配布は1時間ごとの確認、ファイル配布は再起動が必要です。

一部のチームだけ例外にしたい場合は、sandbox の直下を overridable だけにして既定値を宣言し、copilot/team-mappings.json でチーム用ファイルを割り当てます。チーム用ファイルの sandbox は既定値全体を置き換えるので、部分的な上書きにはなりません。同じ管理設定でComputer Useを止める方法はGitHub Copilot Computer Useとはで解説しています。

ローカルサンドボックスを全社で必須にすべき組織と見送る開発環境

ここまでの仕様を踏まえ、どこから強制し、どこで止めるかを言い切ります。

MCPサーバーと認証トークンを扱うリポジトリから先に必須化する判断

必須化を急ぐべきなのは、ローカルMCPサーバーを複数つないでいるチームと、本番系のトークンを環境変数で渡しているリポジトリです。エージェントが生成したコマンドは、利用者と同じ権限で動けば、作業ディレクトリの外の鍵ファイルや社外への送信にも届きます。sandboxMcpServers と認証情報マスクの2つは、この経路を狭める具体的な手段です。

反対に、ドキュメント修正しか任せないリポジトリから全社展開を始める必要はありません。コーディングエージェントを業務システムに組み込み、権限設計や監査まで含めて整えたい場合は、AIエージェント開発で要件整理から支援しています。

Windows旧ビルドやWSL1が混ざる開発チームでは即時の強制を見送る

failIfUnavailable を true にした状態で要件未達の端末が残ると、その端末ではCopilotのエージェントが実質使えなくなります。WindowsのKB未適用、bubblewrapの入っていないLinux、WSL1が混在する部署では、先に端末の更新を終えるべきです。

移行期間は enabled だけを配り、failIfUnavailable は付けない運用が現実的です。サポート外のホストではセッション中だけ無効になり通知が出るので、どの端末が要件を満たしていないかを把握する材料になります。

クラウドサンドボックスやDev Containerへ切り替えるべき境界の目安

VS Codeのドキュメントは、サンドボックスはVMやユーザーアカウントの境界ではなく、エンドポイントセキュリティの代わりにもならないと明記しています。取得元の分からない第三者のコードを実行させる用途には、ローカルサンドボックスを使うべきではありません。

その場合はGitHubのクラウドサンドボックスが候補です。Azure Container Apps Sandboxes上の使い捨てLinux環境で、2026年10月時点はパブリックプレビュー、組織側の「Cloud Sandbox access」ポリシーは既定でオフになっています。課金ページのとおり従量課金で、概要ページで示されている単価は、コンピュート1秒あたり0.000024ドルなどです。Copilot以外のエージェントも同じ場所で隔離したいならDocker Cloud Sandboxesとはも比較対象になります。隔離の考え方そのものはサンドボックスとはで整理しています。

GitHub Copilotのサンドボックス導入でよく挙がる質問と回答

検討時に繰り返し聞かれる論点を、2026年10月時点の公開情報にもとづいて整理します。

ローカルサンドボックスに追加料金はかかりますか？

かかりません。changelogと概要ページのいずれも、ローカルサンドボックスは通常のCopilotのシートに含まれると説明しています。費用が発生するのは、GitHubがホストするクラウドサンドボックスを使った場合です。こちらはコンピュート時間・メモリ・ストレージの使用量で計測されるため、長時間止めずに置いたセッションがあると請求が積み上がります。

サンドボックスを有効にすれば外部への通信は止まりますか？

既定では止まりません。CLIもVS Codeも、外向きの通信は既定で許可されたままです。止めたい場合は、CLIのNetworkタブで外向き接続をオフにするか、ホストルールで宛先を絞ります。どこまで強制できるかはOSによって差があり、Windowsではプログラムがプロキシ設定を守ることに依存するため、macOSやLinuxより直接接続への保護が弱いとされています。

サンドボックス設定をリポジトリに置いてチームで共有できますか？

できません。Copilot CLIのサンドボックス設定は個人の設定ディレクトリにある settings.json に保存され、リポジトリ単位の設定ファイルには対応していません。チームで同じポリシーをそろえたい場合は、エンタープライズの管理設定で配るのが正規の方法です。チームごとに差を付けたいときは team-mappings.json で割り当てます。

サンドボックスの外での実行を承認すると何が変わりますか？

その1回のコマンドは、通常の環境で実行されます。このとき認証情報のマスクとサンドボックスのプロキシも外れるため、実際のシークレットを含む環境変数がそのまま見える状態になります。OSの管理者権限が付くわけではありませんが、気軽に承認してよい操作ではありません。組織で禁じるなら allowBypass を false にします。

MXCのSDKを自分で組み込む必要はありますか？

Copilotのサンドボックスを使うだけなら不要です。MXCはCopilot CLIやappに組み込まれており、利用者は /sandbox や設定画面で操作します。自社のアプリやエージェントに同じ隔離層を組み込みたい場合に限り、@microsoft/mxc-sdk を直接扱う形です。その場合はSDKの版とポリシーの版を合わせる作業が別に必要になります。