GitHub Copilotのサンドボックスとは？法人が決める設定と管理ポイント

Q: 有効化すれば外部への通信は止まりますか？

止まりません。有効化後も外向きインターネットは既定でオンです。通信を絞るには、管理設定で allowOutbound や allowedHosts を設定します。

Q: 利用者が /sandbox disable で無効化できますか？

管理設定で強制していれば、通常設定、--no-sandbox、/sandbox disable では無効化できません。allowBypass: false で、バイパスも禁止できます。

GitHub Copilotのローカルサンドボックスは、有効化するだけでは外向きの通信も Git の認証情報も止まりません。既定値のまま「入れた」ことにすると、守れているつもりで何も守れていない状態になります。

2026年10月7日に一般提供が始まったこの機能は、Copilot が実行するシェルコマンドの権限を OS の仕組みで絞り込むものです。GitHub の changelogによれば追加料金はなく、Copilot のシートに含まれます。ただし既定はオフで、組織で強制するには管理設定を自分たちで書く必要があります。

社内で Copilot のエージェント機能を使わせたい管理者・情報システム担当向けに、2026年10月時点の公式情報から、設定キーの対応表と配布経路ごとの違いまで整理します。

この記事でわかること

ローカルサンドボックスが「何を隔離し、何を隔離しないのか」
CLI・Copilot app での有効化手順と、有効化後の既定値
管理者が上書きすべき設定キーの対応表と、ビルドが壊れる副作用
組織で強制するときの決定順と、配布経路(MDM・ファイル・サーバー管理)ごとの違い
Claude Code・OpenAI Codex のサンドボックスとの違い

ローカルサンドボックスは「エージェントの手元作業を囲う仕組み」

ローカルサンドボックスは、Copilot が自分のマシン上で動かすコマンドに対して、読み書きできる場所・通信先・使える認証情報を OS レベルで絞る機能です。

承認ダイアログとは別の層で止める

従来の Copilot のエージェントは、コマンドを実行する前に人が「許可」を押す設計が中心でした。人が見て判断する方式です。

サンドボックスはこれと別の層で働きます。人が許可を押したコマンドでも、実行された後にできることを OS が制限します。承認が「実行してよいか」の関門だとすれば、サンドボックスは「実行してもここから外へは出られない」という壁です。

中身を読まずに許可を連打する運用は現実にあります。壁が別にあれば、そのときの被害範囲を小さくできます。

制御できる対象

公式の説明では、制御対象は次のとおりです。

エージェントが実行するコマンドが読み書きできるファイルとディレクトリ
インターネットとローカルネットワークへの通信
Git の認証情報と GitHub CLI(gh)の認証情報
ローカルの MCP サーバーと言語サーバー(対応する範囲)

ポリシーは、使うモデルに関係なくツール実行に適用されます。

実装はコンテナではなく OS ネイティブの軽量な封じ込め

中身は、Microsoft が公開している MXC(Microsoft eXecution Container) です。共通のポリシーを各 OS のネイティブな仕組みへ変換して適用します。仮想マシンやコンテナではないため起動が軽い反面、隔離の強さもそれらには及びません。

OS ごとの前提は次のとおりです。

OS	使われる仕組み	公式が示す前提
macOS	Seatbelt	macOS 15 以降(それ未満は未検証)
Linux	bubblewrap	bubblewrap 0.5.0 以降。外向き通信には slirp4netns、util-linux 2.35 以降、iptables/ip6tables(nf_tables 推奨)、`/dev/net/tun` も必要
Windows	MXC	最近の Windows 11 ビルド(機能がビルドに依存)

Linux は追加パッケージが多く、社内の標準イメージによっては通信まわりで動かないことがあります。非対応のホストでは、CLI は保存済みの有効化設定をそのセッションだけオフにして /sandbox enable を拒否します。Copilot app はセッションを開始できるものの、コマンドの起動が失敗します。

一般提供の範囲と、範囲外のもの

一般提供の対象は、Copilot CLI、GitHub Copilot app、Agent Host を使う VS Code のセッションです。OS は Windows、macOS、Linux。

範囲外の線引きは、管理者が最初に押さえる部分です。

JetBrains 向けの enterprise-managed sandbox は、2026年9月時点でパブリックプレビュー。管理ポリシーがユーザー設定に優先する形ですが、一般提供の3サーフェスには含まれません。
クラウドサンドボックスは別機能です。パブリックプレビューで、計算・メモリ・スナップショット保存が従量課金。ローカルはシート込みで、課金体系が異なります。
Copilot app のローカルサンドボックスは、ローカルのリポジトリ/ワークツリーのセッションが対象です。クラウドサンドボックスやリモートホストのセッションは対象外。

詳しい仕様は Copilot の公式ドキュメントにまとまっています。

守れる範囲と守れない範囲は、ドキュメントに明記されている

サンドボックスを入れても安全になるのは、シェルコマンドの経路が中心です。公式が自ら認めている抜け道を知らないまま「セキュリティ対策済み」と説明すると、後で社内監査で詰まります。

守れること

有効化すると、シェルコマンド、ファイル検索、既定ではローカルの MCP/言語サーバーがポリシーの内側に閉じ込められます。

認証情報の扱いも工夫されています。追加の環境変数をマスクでき、ツールにはプレースホルダだけが渡ります。ローカルのプロキシが、承認済みの HTTPS 宛先にだけ本物の値を注入する方式です。API キーを環境変数に置いていても、コマンドの中に生の値が見えにくくなります。

守れないこと

公式の注意書きを整理すると、次の穴があります。

守れないもの	理由
CLI の組み込みファイルツール	プロセス内で動き、OS のサンドボックスから見えない。ポリシーは best-effort(できる範囲で効く)でしか働かない
リモート MCP サーバー	サンドボックス化されることはない
Linux のローカルネットワーク制御	起動した個々のプロセス(シェルコマンド、ローカル MCP/LSP)に個別適用できない
Windows のホスト単位の通信制御	プログラムがプロキシ設定に従うことが前提で、直接接続を macOS/Linux ほど厳密には止めない

リモート MCP は、社内の別システムへの入口になりがちです。これを許可する場合の統制は、サンドボックスではなく MCP サーバー側の権限設計で考える必要があります。

もう1点。強制できない拒否パスがある場合、弱い制限で黙って実行するのではなく、コマンドが失敗します(アプリと Windows)。安全側に倒れる挙動ですが、現場からは「急に動かなくなった」という問い合わせとして届きます。

プレビュー期の実機検証では、ホスト制限が効かない場面があった

一般提供前の2026年6月に、macOS で試した検証記事があります。そこでは、ホスト単位の許可・拒否が Seatbelt では効かない旨の警告が出て、許可外のホストへの curl も通ったと報告されています。組み込みの web_fetch もサンドボックスの外でした。キーチェーンをオフにすると git push は失敗しています。

これはプレビュー版時点の挙動です。一般提供後に変わったかどうかは、公式の情報では確認できていません。

通信制限を前提にした設計は、自社の端末で実際に試してから入れてください。ドキュメントの記述と手元の挙動は別物です。

個人の有効化手順と、有効化後の既定値

有効化の操作は簡単ですが、有効化後の既定値は「閉じている」とは限りません。

CLI と Copilot app での有効化

既定はオフです。有効化するまで、シェルコマンドはユーザー権限のまま動きます。

Copilot CLI では、セッション内で次を実行します。

/sandbox enable

設定は以降のセッションにも保持されます。解除は /sandbox disable。補助コマンドも用意されています。

コマンド	用途
`/sandbox`	General・Credentials・Filesystem・Network のタブで設定を開く
`/sandbox status`	現在の状態を確認する
`/sandbox policy [command]`	実際に効いているポリシーを確認する

/sandbox policy は、管理設定を配った後の検証で使えます。端末ごとに「結局、何が許可されているか」を確認できます。

Copilot app では、対象のプロジェクトを選び、設定の Sandbox で「Sandbox new sessions」をオンにします。反映されるのは新規セッションだけです。稼働中の1セッションだけ有効にしたいなら /sandbox on。ポリシーを変えた後は、新規セッションを開始するか /restart-session を実行します。

CLI とアプリの設定は互いに独立しています。片方を有効にしても、もう片方は有効になりません。VS Code の個人向け設定キーは、公式ドキュメントでは確認できていないため、ここでは扱いません。

有効化しただけでは外向き通信も認証情報も開いたまま

有効化した場合の既定値は、次のとおりです。

設定項目	アプリ	CLI
外向きインターネット	オン	オン
ローカルネットワーク	オン	オフ
Git 認証	オン	オン
`gh` 認証	オン	オン
MCP のサンドボックス化	(CLI のみの項目)	オン
言語サーバーのサンドボックス化	(CLI のみの項目)	オン
作業ディレクトリを含める	(CLI のみの項目)	オン
開発ツールへのアクセス	(CLI のみの項目)	オン
macOS キーチェーン	(CLI のみの項目)	オフ
バイパスの許可	(CLI のみの項目)	オン

外向きインターネットも Git 認証も gh 認証も、既定ではオンです。有効化直後でも、エージェントは外へ通信でき、Git のトークンでの push や gh での操作ができます。守られるのは主にファイルシステム側。入れたのに安心できない理由がここにあります。

バイパスは便利だが、穴にもなる

allowBypass は既定でオンです。サンドボックス内で失敗したコマンドを、ユーザーが承認すればサンドボックスの外で再実行できます。

バイパスで外れるのは Copilot のサンドボックス制限だけで、OS の管理者権限が付くわけではありません。それでも「失敗したら承認すれば通る」経路が残るため、統制を重視する組織では次章のとおり管理側で閉じます。

CLI 個人設定の settings.json には sandbox キーがあり、sandbox.enabled、sandbox.credentials.envVars.<NAME>.injectHosts(ワイルドカード可、単独の * は不可)、sandbox.userPolicy.seatbelt.keychainAccess を置けます。リポジトリ単位の設定ファイルでは、この設定は使えません。リポジトリに設定を置いて全員に配る、という運用はできないということです。

組織で強制するには、決める順番がある

組織への強制は、設定キーを書く前の判断が成否を分けます。順番は、対象クライアントとバージョンの把握、必須化の強さ、通信と認証情報のポリシー、配布経路の選択、検証の5段階です。

まず対象クライアントと最低バージョンを洗い出す

最初に把握するのは、社内で誰がどのクライアントを使っているかです。一般提供の対象は CLI、Copilot app、VS Code の Agent Host。JetBrains の利用者は、別のプレビュー機能の管理に回ります。

次にバージョンです。sandbox キーを管理設定に入れると、古いクライアントは更新するまで Copilot に接続できなくなります。公式が示す最低バージョンは次のとおり。

クライアント	最低バージョン
VS Code	1.141.0
Copilot CLI	1.0.93
GitHub Copilot app	1.1.26

VS Code の Agent Host 対応自体は 1.138.0 からです。2026年10月13日の更新で、sandbox キーに対する最低クライアントバージョンの強制が始まりました。他のガバナンス系のキーにも順次広げる予定とされています。

告知なしに配ると、開発者の Copilot が突然つながらなくなります。配布前に必ず周知してください。

必須化の強さを3段階から選ぶ

管理設定の sandbox キーは「制限を課すもので、既定値ではない」と位置づけられています。強制系は true で強制、false または省略ならユーザー設定のままです。

強さ	設定	利用者への影響
弱い	`enabled: true` のみ	有効化は強制。非対応ホストでの扱いは配布経路に依存する
中	`enabled: true` + `failIfUnavailable: true`	検証・強制できない端末では、モデルへの要求とツール実行をブロック
強い	上記 + `allowBypass: false` + MCP/LSP のサンドボックス化	バイパスと解除を禁止。承認しても枠の外へ出られない

failIfUnavailable は単独では有効化しません。enabled: true と併用して初めて意味を持ちます。

最小の記述例は次のとおりです。

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

allowBypass: false にすると、コマンド単位のバイパスとセッション単位の解除が禁止されます。CLI の /sandbox disable も使えません。ただしアプリでのバイパス要求の可否は、ドキュメント上で管理者が設定できないと読める記述があり、管理設定のキーとの整合は確認できていません。アプリでの挙動は、自社環境で検証してください。

通信と認証情報のポリシーを対応表で決める

「必須化」だけでは通信も認証情報も開いたままです。上書きするキーを次の表で決めます。

やりたいこと	設定キー	注意点
外向き通信を止める/絞る	`userPolicy.network.allowOutbound`、`allowedHosts`、`blockedHosts`	`blockedHosts` が優先される。Windows や macOS の Seatbelt ではホスト単位の制御が厳密でない場面がある
社内プロキシを通す	`userPolicy.network.proxy.url`	通信経路を社内に寄せたいときに使う
ローカルネットワークを止める	`userPolicy.network.allowLocalNetwork`	Linux では個別プロセスに適用できない
Git の認証情報を渡さない	`auth.git: false`	push や private リポジトリの取得に影響する
`gh` の認証情報を渡さない	`auth.gh: false`	PR 作成など `gh` を使う作業に影響する
作業ディレクトリを枠に含めない	`addCurrentWorkingDirectory: false`	能力系。false で禁止
開発ツールへのアクセスを止める	`allowDevToolAccess: false`	パッケージ復元やビルドが壊れる可能性がある
読み書きできる場所を限定する	`userPolicy.filesystem.readwritePaths`、`readonlyPaths`、`deniedPaths`	前二者は管理元すべてに完全一致する文字列だけが残る。`deniedPaths` は加算される
macOS キーチェーンを禁止する	`userPolicy.seatbelt.keychainAccess`	macOS のみ

読み方は2通りあります。enabled や allowBypass などの強制系は「true で強制」。auth.git、auth.gh、allowDevToolAccess などの能力系は「false で禁止」。同じ「制限を課す」キーでも向きが逆なので、書き間違えると意図と反対の設定になります。

事故を起こしやすいのは allowDevToolAccess: false と、許可リスト方式の通信制限です。パッケージの取得やビルドが失敗して、開発が止まります。まず一部のチームで試し、止まった作業を洗い出してから全社へ広げてください。

Windows には learningMode というキーもあります。既定は deny で、allow にできるのはネイティブなデバイス管理経由の場合だけです。

組織の導入を進める段階では、ポリシーを作る側の知識も要ります。エージェントに何を任せ、どこで人が止めるかの設計は、ツールの設定画面だけでは決まりません。AI駆動開発研修では、AI エージェントを開発現場で安全に運用するための権限設計やレビューの回し方を、実際の開発フローに沿って身につけられます。

配布経路ごとに非対応ホストの扱いが違う

管理設定は、サーバー管理、MDM(Intune など)、ファイルベースのいずれかで配れます。通常設定や --no-sandbox、/sandbox disable では無効化できません。

配布経路の違いで、動作が変わる部分があります。

配布経路	非対応ホストでの `enabled: true`	補足
MDM	強制される(コマンドは未サンドボックスで動かず失敗する)	`forceRemoteSettingsRefresh` を初回サインイン前から要求できる
ファイルベース	強制される(同上)	同上
サーバー管理	非対応の CLI ホストでは拒否される場合がある	`failIfUnavailable: true` の併用が必要。`forceRemoteSettingsRefresh` は値を受領した後の次回起動から有効

端末管理(MDM)が整っている組織は、MDM が確実です。サーバー管理は GitHub 側の設定で配れる手軽さがある反面、端末の状態に左右されます。

2026年10月13日の更新で追加された forceRemoteSettingsRefresh: true を指定すると、起動時に最新のサーバー管理設定を取得させます。対象は Copilot CLI、VS Code、Copilot app で、確認できなければ fail closed(安全側に倒して利用させない)になります。ネットワーク障害や GitHub 側の不調のとき、開発者が Copilot を使えなくなる運用影響を許容できるか、事前に決めてください。

Windows のレジストリや macOS の managed preferences でこのキーを配る場合、値は文字列で保存します。DWORD や Boolean 型では効きません。

managed settings ファイルの配置場所や、設定が反映されるまでの時間については、公式ドキュメントで確認できていません。二次情報はありますが、断定はせず、公式のエンタープライズ管理設定のページで最新を確認してください。プラン別の提供条件も同様です。

クラウドサンドボックスの許可は別ポリシー

クラウドサンドボックスは、組織設定の「Cloud sandbox access」で制御します。組織・エンタープライズとも既定は無効。エンタープライズは「無効」「組織に任せる」「既定で有効」の3択です。手順は組織向けの有効化・無効化のドキュメントにあります。ローカルを必須化しても、クラウド側は別途判断になります。

検証してから段階的に配る

最後の段階は検証です。配布前に、各 OS の代表端末で次を確認します。

/sandbox status と /sandbox policy で、意図したポリシーが効いているか
実際のビルド、テスト、パッケージ取得が通るか
許可外ホストへの通信が、自社の OS で本当に止まるか
Git の push や gh の操作が、方針どおり通る/通らないか
非対応ホスト(古い OS、必要パッケージの欠けた Linux)で何が起きるか

3番目は、前章のプレビュー期の報告を踏まえると省略できません。結果は OS ごとに差が出る可能性があります。

Claude Code・Codex との比較は「有効化後の既定値」で見る

複数のツールを併用する組織では、既定値の違いを把握しておくと統一ポリシーを作りやすくなります。以下は各社の公式ドキュメントにもとづく整理です。

観点	GitHub Copilot(ローカル)	Claude Code	OpenAI Codex
既定	オフ	オフ	モードにより異なる(バージョン管理下のフォルダでは workspace-write が推奨、信頼前は read-only で始まる場合あり)
macOS	Seatbelt	Seatbelt	Seatbelt
Linux	bubblewrap	bubblewrap + socat(WSL2 含む)	bwrap + seccomp
ネイティブ Windows	MXC で対応	非対応(サンドボックスなしで実行)	MXC に対応(`prefer_mxc` で優先、従来の方式もフォールバックとして残る)
対象範囲	シェル、ファイル検索、ローカル MCP/LSP(CLI の組み込みファイルツールは対象外)	シェルコマンドのみ。ファイルツール、MCP サーバー、フックは対象外	モードによる
有効化後のネットワーク	外向きは既定でオン	プロキシ経由で、許可ドメインの初期値は空	workspace-write では既定でオフ
管理側の強制	managed settings(`failIfUnavailable` など)	managed settings と `sandbox.failIfUnavailable`	承認ポリシーと MDM などの管理設定

Claude Code のサンドボックスは、書き込みが作業ディレクトリ等に限られる一方、読み取りは ~/.ssh を含めほぼ全域が既定です。OpenAI Codexは read-only、workspace-write、danger-full-access の3モードを持ち、workspace-write ではネットワークが既定でオフです。

違いが最も大きいのはネットワークの既定値です。Copilot は外向き通信が開いている一方、Codex の workspace-write は閉じています。社内の統一ルールは、製品名ではなく「外向き通信・認証情報・読み取り範囲をどうするか」で書くと、ツールを入れ替えても使い回せます。

ネイティブ Windows の端末が多い組織では、Copilot と Codex が MXC に対応している点が選定の材料になります。Claude Code のネイティブ Windows は非対応で、WSL2 経由の運用が前提です。

Claude Code 側の設定とセキュリティの考え方はClaude Codeのセキュリティルールの解説、Cursor 側はCursorのセキュリティ設定のポイントで整理しています。ツール選定の観点はCursorとGitHub Copilotの比較が参考になります。

サンドボックスが守るのは「実行時の被害範囲」です。AI が書いたコードそのものの品質は、別の仕組みで見る必要があります。レビュー体制の作り方はAIコードレビューの人とAIの運用設計を参照してください。

よくある質問

有効化すると追加料金はかかりますか？

ローカルサンドボックスに追加料金はなく、Copilot のシートに含まれます。従量課金になるのはクラウドサンドボックスで、これは別機能です。

有効化すれば外部への通信は止まりますか？

止まりません。有効化後も外向きインターネットは既定でオンです。通信を絞るには、管理設定で allowOutbound や allowedHosts を設定します。

JetBrains や Copilot の cloud agent も対象ですか？

一般提供の対象は CLI、Copilot app、VS Code の Agent Host です。JetBrains は別のプレビュー機能で、クラウドサンドボックスも別機能です。

利用者が `/sandbox disable` で無効化できますか？

管理設定で強制していれば、通常設定、--no-sandbox、/sandbox disable では無効化できません。allowBypass: false で、バイパスも禁止できます。

サンドボックスがあれば、承認ダイアログは不要ですか？

不要にはなりません。サンドボックスは実行後の被害範囲を絞る仕組みで、組み込みファイルツールやリモート MCP は対象外です。承認と併用します。

まとめ

最初にやるのは、Copilot 利用端末のクライアント種類とバージョンの棚卸しです。最低バージョンを満たさない端末が多いと、管理設定を配った瞬間に接続できない開発者が出ます。

次に、少人数のチームで enabled: true と failIfUnavailable: true を試し、/sandbox policy で実効ポリシーを確認します。ビルドが通るか、許可外ホストへの通信が自社の OS で止まるかを見て、問題がなければ allowBypass: false、Git・gh の認証、通信先の絞り込みを段階的に足してください。

リモート MCP と CLI の組み込みファイルツールはサンドボックスの外です。ここは MCP サーバーの権限設計やレビュー運用など、別の層で塞ぎます。

現場の開発者と管理者が同じ前提でエージェントの権限設計を議論できると、ポリシーの改訂も早く進みます。AI駆動開発研修では、エージェントを安全に使う考え方と実践を、チームの共通言語にできます。