開発や情シスでGitHub Copilotを使い始めた会社から、こんな声を聞きます。
「AIエージェントにコマンドを実行させると、PCの中のどこまで触られるのかが分かりません」
「サンドボックスが正式提供になったと聞きました。入れれば、もう安心と考えていいのでしょうか」
「社員ごとに設定がばらばらになりそうで、会社として何を決めればいいのか迷っています」
結論を先に言います
GitHub Copilotのローカルサンドボックスとは、AIエージェントがアクセスできるファイル・ネットワーク・認証情報を制限する機能で、2026年10月9日にCopilot CLI・Copilotアプリ・Agent Hostを使うVS Codeのセッションで正式提供になりました。
ただ、正式提供になっても、既定はオフです。 なので、入れるかどうかより先に、「AIエージェントに何を触らせないか」を会社で決めておくのがいいかなと思います。
この記事で持ち帰れること
- ローカルサンドボックスで何が変わったのか（既定はオフ）
- 有効にしたとき、既定で通るものと止まるもの（CLIとアプリで違う）
- 管理者が設定で強制できること
- 対応OSと、使う前に確認すること
- 会社として先に決める3つのことと、部署別の当てはめ方（弊社の考え）
ローカルサンドボックスとは：10月に正式提供になったこと
GitHub Changelogの「GitHub Copilot weekly releases — October 5」（https://github.blog/changelog/2026-10-09-github-copilot-weekly-releases-october-5/）は2026年10月9日付で、ローカルサンドボックスがCopilot CLI、Copilotアプリ、Agent Hostを使うVS Codeのセッションで正式提供（generally available）になったと伝えています。AIエージェントがアクセスできるファイル・ネットワーク・認証情報を制限する機能で、Copilotに追加費用なしで含まれる、とされています。
GitHub Docsの「About cloud and local sandboxes」（https://docs.github.com/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes）には、押さえておきたい前提が書かれています。
- ローカルサンドボックスは、既定ではオフ
- オフのままだと、Copilotが実行するシェルコマンドは、利用者のユーザーアカウントと同じ権限で、手元のマシンの上で直接動く
- つまり、利用者が読み書き・削除できる場所はどこでも触れ、マシンが届くネットワークにはどこでも届き、認証情報も制限なく使える
- ローカルサンドボックスは、コマンドを別の仮想マシンやコンテナの中で動かすものではない
同じページでは、似た名前の「クラウドサンドボックス」も説明されています。この2つは別物です。
| ローカルサンドボックス | クラウドサンドボックス | |
|---|---|---|
| 提供の状態 | 正式提供 | パブリックプレビュー（実験的な機能） |
| 費用 | 標準のGitHub Copilotのシートに、追加費用なしで含まれる | 使った量に応じた課金 |
| 既定 | オフ | 組織では既定で無効。オーナーが「Cloud Sandbox access」のポリシーを有効にする必要がある |
有効にすると、何が通り何が止まるか（CLIとアプリで既定が違う）
Copilot CLIでは、/sandbox enable で有効にします。About cloud and local sandboxesによると、サンドボックスの中で動くのは、シェルコマンド、ファイル検索、そして既定ではローカルのMCPサーバーと言語（LSP）サーバーです。一度有効にすると、/sandbox disable で無効にするまで、次のセッション以降も使われ続けます。
一方で、対象にならないものもあります。
- リモートのMCPサーバーは、サンドボックスの対象にならない
- CLIの内蔵ツール（ファイル操作など）は、CLI自体がサンドボックスの外で動くため、OSのサンドボックスからは見えない。内蔵ツールはサンドボックスのポリシーを自分で確認し、設定に「ベストエフォート」で従う作りになっている
既定で何が許されるかは、GitHub Docsの「Configuring local sandbox settings」（https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings）に書かれています。CLIとアプリで既定が違う点があるので、並べておきます。
| 項目 | Copilot CLIの既定 | Copilotアプリの既定 |
|---|---|---|
| 有効にする方法 | /sandbox enable | 設定 > Projects > Sandbox の「Sandbox new sessions」をオン（新しいセッションから反映） |
| ファイル | 作業ディレクトリとその下はすべて読み書きできる。Gitリポジトリの中なら .git も読み書きでき、作業ディレクトリより上のリポジトリは読み取りだけできる | ワークスペースと作業ディレクトリを読み書きできる |
| 外向きの通信 | 許可（Allow outbound connections がオン） | 許可（Outbound internet がオン） |
| ローカルネットワーク | 不可（Allow local network がオフ） | 許可（Local network がオン） |
| gitの認証 | 有効。本物の認証情報は、元のホスト・ポート・リポジトリのパスにだけ渡される | 有効（Git credentials） |
| GitHub CLI（gh）の認証 | 有効。サンドボックスの中には仮の GH_TOKEN を渡し、本物のトークンは github.com・api.github.com・uploads.github.com にだけ渡される | 有効（GitHub CLI credentials） |
| macOSのキーチェーン | 不可 | — |
認証情報の扱いについて、About cloud and local sandboxesでは、サンドボックスの中のツールは仮の値（プレースホルダー）を受け取り、ローカルのプロキシが、承認されたHTTPSの宛先にだけ本物の認証情報を渡す、と説明されています。
管理者が設定で強制できること
About cloud and local sandboxesによると、企業はローカルサンドボックスを必須にし、その設定を、サーバー管理・MDM管理・ファイルによる管理設定（managed settings）で強制できます。管理設定でサンドボックスが必須になっていると、通常の設定や起動時のオプションではオフにできません。
Configuring local sandbox settingsには、管理者が押さえておきたい設定がほかにも書かれています。
| 設定・ルール | 公式ドキュメントの内容 |
|---|---|
| 個別の迂回（Allow sandbox bypass） | CLIでは既定でオン。管理設定で sandbox.allowBypass を false にすると、個別のコマンドをサンドボックスの外で動かす承認も、そのセッションの残りでサンドボックスを無効にすることもできなくなる |
| 迂回の範囲 | 迂回で外れるのはCopilot自身のサンドボックスの制限だけで、OS側の制限は外れない |
| 通信先の許可ルール | 許可（Allow）のルールを1つでも追加すると、許可に当てはまらないホストは、自動で入るlocalhostの項目を除いて遮断される。許可ルールが無ければ、拒否ルールなどで止めない限り、ほかのホストは許可のまま |
| 拒否ルール | 拒否（Deny）は許可より優先される。拒否したドメインは、そのサブドメインも拒否される。CIDR表記のIPアドレス範囲は使えない |
| 企業のルール | 企業のルールは許可リストを狭めることしかできず、広げることはできない。ホストが許可されるのは、利用者のルールと企業のルールの両方が許可したときだけ |
| 設定の置き場所 | Copilot CLIの設定ディレクトリの settings.json の sandbox キーに保存される。リポジトリ単位の設定ファイルでは、サンドボックスの設定は使えない |
さらに、GitHub Changelogの「Enterprise managed settings enforcement updates」（https://github.blog/changelog/2026-10-13-enterprise-managed-settings-enforcement-updates）は2026年10月13日付で、管理設定の強制について2つの更新を伝えています。
forceRemoteSettingsRefreshをtrueにすると、対応するCopilotのクライアントは、キャッシュしたポリシーに頼らず、起動時に最新のサーバー管理設定を取りに行く。最新のポリシーを確認できないときは、古いポリシーのまま動かずに止まる（fail closed）。対応はCopilot CLI、VS Code、Copilotアプリ- 正式提供になったローカルサンドボックスに合わせて、
sandboxキーに「最低限必要なクライアントのバージョン」の強制が加わった。このキーが管理設定に入っていると、古いバージョンのCopilotのクライアントに固定している利用者は、Copilotを使い続けるために更新を求められる
対応OSと、使う前に確認すること
About cloud and local sandboxesとConfiguring local sandbox settingsに書かれている、対応OSの条件は次のとおりです。
| OS | 条件 |
|---|---|
| macOS | macOS 15（Sequoia）以降。古いmacOSでもCopilot CLIは止めないが、動作は検証されていない |
| Linux | bubblewrap（bwrap）0.5.0以降と slirp4netns を入れて、PATHから使えるようにする |
| Windows | Windows 11 バージョン25H2（更新プログラムKB5124010以降）、またはバージョン26H1（KB5124006以降） |
対応していないマシンで /sandbox enable を実行すると、拒否されます。Windowsについては、要求された機能にマシンが対応していない場合、Copilot CLIは制限を弱めてコマンドを動かすのではなく、必要な条件を知らせる、とされています。また、Windowsのサンドボックスは、プログラムがプロキシの設定に従うことを前提にしています。
Copilotアプリでは、ポリシーの変更は、新しいセッションか、再起動したセッションから反映されます。CLIでは /sandbox policy で、実際に効いているポリシーを確認できます。
管理者が先に決める3つのこと（ここからは弊社の考え）
ここからは公式ドキュメントの記載ではなく、弊社がAIエージェントを業務で動かしてきた立場からの考えです。
既定がオフなので、何も決めないと、社員それぞれの判断で「オンの人」と「オフの人」が混ざります。なので、入れる前に次の3つを決めておくのがいいかなと思います。
| 決めること | 弊社が考える判断の目安 |
|---|---|
| 1. 必須にするか | 顧客データや本番環境の認証情報を扱う端末があるなら、管理設定で必須に寄せる。まず検証用の端末から始めるのも手 |
| 2. 通信先の許可リストをどこまで絞るか | 許可を1つ置くと他は遮断されるので、いきなり絞らず、まず実際の通信先を洗い出してから決める |
| 3. 個別の迂回を許すか | 迂回を許すと、急ぎの場面で「とりあえず外す」が起きやすい。許すなら、誰がどんな場面で外してよいかまで決める |
あとは、リモートのMCPサーバーは対象外という点も、社内に伝えておきたいところです。サンドボックスを入れたから全部守られる、と受け取られると、外部のサービスにつなぐ部分の確認が抜けやすいかなと思います。MCPと権限の線引きは「ChatGPTのMCP Eventsとは」でも書いています。
部署別の使いどころ（ここからは弊社の考え）
ここも公式の記載ではなく、弊社が部署ごとに当てはめた考えです。
| 部署・使い方 | 弊社が考える設定の寄せ方 |
|---|---|
| 開発（本番の認証情報やお客様のデータに触れる） | 必須に寄せる。迂回は原則許さない。通信先は許可リストで絞る |
| 開発（検証用・個人の試作） | 有効にしたうえで、まずは既定のまま使い、必要な通信先を洗い出す |
| 情シス・社内ツールの管理 | 管理設定で必須にし、最低限のクライアントのバージョンもそろえる |
| 業務部門（スクリプトやデータ整理にCLIを使う） | 作業フォルダの外を触らせない前提で使う。キーチェーンなど認証情報への許可は広げない |
業務で使うAIツールに、管理者が先に決めておく設定の考え方は「Microsoft CopilotのClaudeとは」、社内で契約済みのツールでAIエージェントを作るときの任せる範囲は「社内AIエージェントは契約済みツールで作れる」にまとめています。
CodeClimbの見解
ここまでは公式ドキュメントに書かれていることと、それを前提にした弊社の考えを並べました。ここでは、弊社の経験から書きます。
まず正直に書いておくと、弊社はGitHub Copilotのローカルサンドボックスを、社内で運用したことはまだありません。 なので、使い込んだ感想ではなく、AIエージェントを業務で動かしている側の考えです。
弊社は社内で、Claude CodeとCodexを業務に合わせて使い分けています。そこで最初に決めたのは、AIに「何を任せるか」と同じくらい、「何に触らせないか」でした。たとえば、毎晩のブログ記事の制作はAIに任せていますが、公開は検査を通る1本のスクリプトからだけにして、AIが直接公開できる経路は使わせていません。画像の生成をCodexに任せるときも、書き込める範囲を作業フォルダに限る設定で動かしています。
AIにコードやシステムを触らせると、仕事はかなり速くなります。弊社でも、システムの不具合の原因調査が、半日かかっていたのが10分ほどで特定できるようになりました。ただ、速くなるほど、触れる範囲が広いままだと、間違えたときの影響も大きくなります。なので、今回のような仕組みが公式に用意されたのは、会社として使いやすくなる方向かなと思います。
やっておくのは、この3つかなと思います。
- 既定がオフであることを、社内に伝える。正式提供＝自動で守られている、ではない
- 触らせないものを先に書き出す。本番の認証情報、お客様のデータ、社内ネットワーク。ここが決まれば、必須にするか・許可リスト・迂回の3つは決めやすい
- サンドボックスの外にあるものを別に確認する。リモートのMCPサーバーなど、外部につなぐ部分は、つなぐ前に何を渡すかを決める
AIに任せない業務の分け方は「AI導入で任せない業務4分類」、Claude Codeを業務に入れる前に決めておくことは「Claude Codeの「mods」とは」をご覧ください。
よくある質問
Q. ローカルサンドボックスを使うのに、追加の費用はかかりますか
About cloud and local sandboxesでは、ローカルサンドボックスは標準のGitHub Copilotのシートに、追加費用なしで含まれる、とされています。一方、クラウドサンドボックスはパブリックプレビューの機能で、使った量に応じて課金されます。
Q. リポジトリに設定ファイルを置いて、チーム全員に同じサンドボックスの設定を配れますか
Configuring local sandbox settingsでは、リポジトリ単位の設定ファイルでは、サンドボックスの設定は使えない、とされています。設定はCopilot CLIの設定ディレクトリの settings.json の sandbox キーに保存されます。会社として必須にする場合は、サーバー管理・MDM管理・ファイルによる管理設定を使います。
Q. 古いバージョンのCopilot CLIを使い続けている社員がいる場合は、どうなりますか
10月13日付のEnterprise managed settings enforcement updatesによると、sandbox キーに最低限必要なクライアントのバージョンの強制が加わりました。このキーが管理設定に入っていると、古いバージョンのCopilotのクライアントに固定している利用者は、Copilotを使い続けるために更新を求められます。
まとめ
GitHub Copilotのローカルサンドボックスは、2026年10月9日に、Copilot CLI・Copilotアプリ・Agent Hostを使うVS Codeのセッションで正式提供になりました。AIエージェントがアクセスできるファイル・ネットワーク・認証情報を制限する機能で、Copilotに追加費用なしで含まれます。
ただ、既定はオフで、オフのままだと、Copilotが実行するシェルコマンドは利用者と同じ権限で動きます。CLIとアプリではローカルネットワークの既定が違い、リモートのMCPサーバーは対象になりません。企業は管理設定でサンドボックスを必須にでき、sandbox.allowBypass で個別の迂回も止められます。入れるかどうかより先に、何に触らせないかを決めておく。この順番で考えておくのがいいかなと思います。
AIエージェントに任せる範囲から、一緒に決めませんか
CodeClimbは、AIツールを売る側ではなく、業務に合わせてAIの仕組みを作る側の会社です。社内でもAIエージェントを業務で動かしていて、何を任せ、何に触らせないかを決めるところからお手伝いしています。
「使い始めたけれど、会社としてのルールがまだ無い」という段階からでも構いません。AI活用支援のサービス内容をご覧いただいたうえで、お問い合わせから今の状況をお聞かせください。
出典
https://github.blog/changelog/2026-10-09-github-copilot-weekly-releases-october-5/ ｜ GitHub Changelog ｜ 2026年10月
https://docs.github.com/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes ｜ GitHub Docs ｜ 参照 2026-10-17
https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings ｜ GitHub Docs ｜ 参照 2026-10-17
https://github.blog/changelog/2026-10-13-enterprise-managed-settings-enforcement-updates ｜ GitHub Changelog ｜ 2026年10月
