GitHub Copilotアプリに​「ローカルサンドボックス」が​入った​ ──初期設定は​オフ、​オンに​しても​開いたままの​もの

気になるAIツールを、分かりやすく

2026年9月23日、GitHubはGitHub Copilotアプリに「ローカルサンドボックス」を追加しました（パブリックプレビュー）^[1]。AIが手元のPCで実行するコマンドについて、触れるファイル・つながるネットワーク・使える認証情報をプロジェクトごとに絞れる機能です。

公式ドキュメントを読んで分かった要点は3つです。初期設定はオフで、オフのままだとAIのコマンドは使っている人と同じ権限で動きます。オンにしても、初期状態ではネット接続とGit・GitHubの認証情報は通ったままで、閉じるのは主に「作業フォルダの外のファイル」です。そしてOSが制限をかけられないとき、アプリは止まり、同じ会社のCopilot CLIは制限なしで続行します——同じ仕組みで、倒れる向きが逆です。

1. 何が発表されたか
2. オフのとき、AIのコマンドに何ができるか
3. オンにしても開いたままのもの
4. 守れないときの倒れ方（アプリとCLIの違い）
5. 「その場だけ外で実行」を止められるのは誰か
6. 社内で強制するための設定ファイル

CAGはCopilotアプリで実機検証をしていません。GitHubの公式changelogと公式ドキュメントの突合だけで書いています^[7]。

01 何が​発表されたか

「サンドボックス」は、プログラムを囲いの中で動かし、外に手が届かないようにする仕組みです。GitHub Copilotアプリは、AIエージェントに複数の作業を並行で任せるデスクトップアプリで、Copilotの全プランで使えます（BusinessとEnterpriseでは組織の「GitHub Copilot app」ポリシーが有効である必要があり、初期値は有効）^[2]。

今回入ったのは、そのアプリの中でAIが実行するコマンドを、OSの機能を使って囲う設定です。設定はプロジェクトごとで、対象は手元のリポジトリと作業ツリーのセッションです。GitHubのクラウド上で動かすセッション（クラウドサンドボックス）や、リモートのマシンで動くセッションは対象外です^[1][3]。

絞れるのは3種類です。

種類	設定できること	初期状態
ファイル	読み書きを追加で許すフォルダ／読み取りだけ許すフォルダ／禁止するフォルダ	作業フォルダ（ワークスペースと現在のディレクトリ）だけ読み書きできる
ネットワーク	インターネットへの接続／ローカルネットワークへの接続	どちらも許可
認証情報	Gitの認証（HTTPSでのpushなど）／GitHub CLIの認証	どちらも許可

料金は、ローカルサンドボックスはCopilotの席料金に含まれ、追加費用はかかりません。クラウドサンドボックスは従量課金で、2026年9月25日時点で実行時間が1秒あたり$0.000024、メモリが1GiB秒あたり$0.000003、停止中のスナップショット保存が1GiB月あたり$0.005です^[4]。

02 オフの​とき、​AIの​コマンドに​何が​できるか

ローカルサンドボックスは初期設定でオフです。公式ドキュメントは、オフのときの状態をこう書いています^[4]。

有効にするまで、Copilotが実行するシェルコマンドはあなたのユーザーアカウントと同じ権限で直接動く。あなたが読み書き・削除できる場所ならどこでも読み書き・削除でき、PCから届くネットワークならどこへでもつながり、あなたの認証情報を制限なく使える。

GitHub Docs「About cloud and local sandboxes for GitHub Copilot」（CAG訳）

ここで誤解しやすいのが「作業ツリー」です。Copilotアプリは並行する作業ごとに別の作業ツリー（ブランチごとの作業フォルダ）を作りますが、公式は「作業ツリーはセッションどうしのブランチとファイルを分けるが、そのコマンドがPCのほかの場所に触れることは制限しない」と書いています^[3]。作業ごとに分かれて見えても、囲いにはなっていません。

有効にするには、アプリの設定でプロジェクトを選び、「Sandbox」のSandbox new sessionsをオンにします。これは新しく始めるセッションに効き、動いているセッションは変わりません。動いているセッションだけ切り替えるときは、入力欄で/sandbox onと打ちます^[3]。

03 オンに​しても​開いたままの​もの

オンにすれば全部閉じる、とはなりません。01章の表のとおり、初期状態で閉じるのは作業フォルダの外のファイルだけで、ネット接続と2種類の認証情報は通ったままです。

これはGitHubが意図した設計です。公式ドキュメントは「たいていのプロジェクトは初期のポリシーから始める」ことを勧めています。初期ポリシーなら依存パッケージのインストール、ローカルの開発サーバーへの接続、ブランチのpush、プルリクエストの作成といった普段の作業が通るからです。そのうえで「機密性の高いフォルダが近くにある」「ネットが要らない」「認証情報を使わせるべきでない」プロジェクトでは、制限を足すよう書いています^[3]。

もう1つ、画面に出てこない入口があります。企業向け管理設定の説明にallowDevToolAccessという項目があり、falseにすると「開発ツールの設定・キャッシュ・レジストリ・ツールチェーンへの自動アクセスを禁じる。これらの場所にはパッケージレジストリの認証情報やトークンが含まれうる」とあります^[5]。裏返すと、何も設定しなければ、そうした場所には自動で届くということです。Copilotアプリのプロジェクト設定で変えられるのは「ファイル・ネットワーク・認証情報」の3種類だけで、この項目は画面にありません^[4]。

囲いの強さについても、公式ははっきり書いています。仕組みはMicrosoftのMXC（Microsoft eXecution Container）で、macOSではSeatbelt、Linuxではbubblewrap、WindowsではBaseContainerというOSごとの機能を使います。公式の言葉では「隔離の強さの中で、現状は軽い側にある。何を読み書きし、どこにつながるかは制限するが、コマンドを別の仮想マシンやコンテナの中で動かすわけではない」^[4]。

04 守れない​とき、​アプリは​止まり、​CLIは​続行する

OSや環境によっては、頼んだ制限をかけられないことがあります。そのときの動きが、CopilotアプリとCopilot CLI（ターミナルで使う版）で逆です。

場面	Copilotアプリ	Copilot CLI
OSが制限をかけられない	シェルが「未対応」のエラーで失敗し、制限なしでは動かない	その場でサンドボックスを切り、通知を出したうえで制限なしで続行。企業が必須にしている場合だけ止まる
守れるかの確認	設定は保存できる。最初のシェル起動時に初めて確認される	確認のタイミングは公式に記載なし（不足していれば上のとおり続行）
Windowsで禁止フォルダを指定	保存できる。守れなければコマンドは失敗し、禁止フォルダに触れる状態では動かない	使わないよう案内されている（指定するとコマンドが失敗する）
Linuxのローカルネットワーク	シェルコマンドやローカルのMCPサーバーについては個別に制御できない（アプリ内部の通信には効く）	シェルコマンドやローカルのMCPサーバーについては個別に制御できない
提供状況	パブリックプレビュー	実験的機能（--experimentalで有効化）

公式ドキュメントの言葉では、アプリは"does not run unsandboxed"（囲いなしでは動かない）、CLIは"run without a sandbox"（囲いなしで動く）です^[4]。CLIでも止める側に倒したいときは、06章の管理設定でenabledとfailIfUnavailableを両方trueにします。こうするとサンドボックスを検証・適用できない場合に、モデルとツールの実行そのものが止まります^[5]。

もう1つ、アプリとCLIは設定が別々です。アプリで有効にしてもCLIは変わらず、その逆も同じです^[1][4]。社内で両方を使っているなら、片方だけ設定して安心することがありえます。

8月の記事では「管理者が何もしないと、設定はどちらに倒れるか」を扱いました。今回の倒れ方は、同じ会社の2つの製品の間で向きが分かれています。

関連記事 ｜ 放置したとき、設定はどちらに倒れるか社員のAI利用を、会社はどこまで見られるか ──8月26日に重なった3つの統制機能と、放置したときに倒れる向き →

05 ​「その​場だけ外で​実行」を​止められるのは​誰か

サンドボックスの中で許されていない操作が必要になると、アプリは「Run outside the sandbox?（サンドボックスの外で実行しますか？）」と聞いてきます。選べるのは3つです^[3]。

• 操作を取り消す
• その操作だけ、1回サンドボックスの外で実行する
• そのセッションの残りすべてでサンドボックスを切り、操作を実行する

3つ目を選ぶと「Sandbox off for this session」と表示され、セッションを再起動するまで切れたままです。

この問いかけ自体を出させない設定は、アプリのプロジェクト設定にはありません。公式は「外で実行を許すかどうかは、プロジェクト設定では構成できない」と書いています^[4]。止められるのは企業の管理設定のallowBypass: falseだけです^[5]。

さらに1点、画面の見え方について公式が注意書きを置いています。アプリが表示するのは利用者のプロジェクト設定で、実際に効いている管理ポリシー全体ではなく、項目ごとに管理側でロックされているかも表示しない^[5]。管理側で厳しくしてあれば画面より厳しく動き、画面を見ても分かりません。

06 社内で​強制するなら、​設定ファイルを​1つ置く

会社として「必ずサンドボックスの中で動かす」を強制する方法が、企業向け管理設定（managed-settings.json）です。配り方は3通りあります^[6]。

配り方	効く相手	置き場所・反映
サーバー管理（.github-privateリポジトリ）	自社のenterpriseからCopilotライセンスを受けている人だけ	リポジトリに置く。約1時間で反映
MDM（端末管理ツール）	ライセンスの出どころに関係なく、配られた端末の利用者	macOSとWindowsのみ。1時間ごとに確認
ファイル配置	ライセンスの出どころに関係なく、ファイルがある端末の利用者	macOSは/Library/Application Support/GitHubCopilot/、Windowsは%ProgramFiles%\GitHubCopilot\、Linuxは/etc/github-copilot/。アプリ再起動で反映

中小企業にとって効きそうなのは3つ目です。公式は、ファイル配置は「Copilotライセンスをどこから受けているかに関係なく適用される」と書いています。Copilot Businessだけでenterpriseを持っていない会社でも、社用PCにファイルを置けば効くと読めます（CAGは実機で確かめていません）。一方で「ファイルを受け取っていない端末は、このポリシーで制限されない」とも明記されています^[6]。

GitHubが例に載せているサンドボックス部分はこの形です^[5]。

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

enabledでサンドボックスを必須にし、failIfUnavailableで守れないときは止め、allowBypassで「その場だけ外で実行」を封じます。接続先を絞る（allowedHosts）、認証情報を渡さない（gitAuth・ghAuthをfalse）、開発ツールの設定に自動で届かせない（allowDevToolAccess: false）もここで指定できます。ただし認証情報を切るとpushやプルリクエストの作成ができなくなり、開発ツールへのアクセスを切るとパッケージの取得やビルドが失敗しうる、と公式自身が書いています^[3][5]。

注意点が2つあります。

• このsandbox設定が効くのはCopilot CLIとCopilotアプリだけです。対応表ではVS Code・JetBrains・Copilotクラウドエージェントは「非対応」です^[5]
• 複数の配り方を併用すると、通常はMDM、サーバー、ファイル、利用者の順で優先されますが、sandboxは例外で、いちばん厳しい向きに合成されます^[6]。どこか1か所で厳しくすれば、ほかで緩められません

07 導入前に​確かめる​6点

• 使っているのはCopilotアプリか、CLIか、両方か。サンドボックスの設定は別々です
• プロジェクトごとに「Sandbox new sessions」をオンにしたか。初期はオフです
• ネット接続・Git認証・GitHub CLI認証を、そのプロジェクトで開けておく必要があるか。オンにしても初期状態では開いています
• 機密フォルダを「禁止」に入れたか。Windowsでは守れないとコマンドが失敗します
• 「その場だけ外で実行」を利用者の判断に任せてよいか。止めるなら管理設定のallowBypass: falseです
• 強制するなら、設定ファイルを全端末に配ったか。配っていない端末は制限されません

ローカルサンドボックスはパブリックプレビューで、仕様は変わりえます^[1]。

囲いがあることより、どこが開いているかを知っていることが、事故の大きさを決めます。