GitHub Copilot CLI のローカルサンドボックスを試してみた

GitHub Copilot CLI のローカルサンドボックスを試してみた

2026.06.16

製造ビジネステクノロジー部の小林です。

2026 年 6 月 2 日、GitHub Copilot にローカルサンドボックスとクラウドサンドボックスが Public Preview として追加されました。

https://github.blog/changelog/2026-06-02-cloud-and-local-sandboxes-for-github-copilot-now-in-public-preview/

これまで Copilot CLI 周りでは Hooksツール許可 で「実行前に止める/許可する」アプローチが用意されていましたが、今回のサンドボックスは実行そのものを隔離するレイヤーで、ガードレールの層が一段増えることになります。

本記事ではローカルサンドボックスの有効化から /sandbox の各タブの挙動、クラウドサンドボックスの起動と料金の考え方までを実際に試してみました。

先にまとめ!

  • ローカルサンドボックスは /sandbox enable で有効化、/sandbox で対話的に設定 UI が開く
  • 設定 UI の全般タブには 4 項目(Sandboxing / MCP servers / LSP servers / Keychain)が並ぶ
  • シェルコマンドだけでなく、MCP サーバーや LSP サーバーもサンドボックス内で実行できる
  • ローカルは標準の Copilot シートに含まれる(追加料金なし)

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

GitHub Copilot は当初、IDE のサジェスト機能としてスタートしましたが、今や CLI で実際にコマンドを叩いてファイルを書き換えてくれる、エージェントへと進化してきました。Autopilot や並列セッション(Fleet)みたいに「すべてを任せる」というシーンが増えるほど、こんな不安が顔を出します。

  • ファイル、勝手に壊されてない?
  • 外部に余計な通信、飛んでない?
  • 認証情報、意図せず読み取られていない?

これまでは「このコマンド実行する?」みたいな許可ダイアログで都度判断してきましたが、件数が増えてくるとちょっと大変。流れで Yes を連打してしまい、意図しない操作を実行してしまう可能性があります。

そこで、許可を毎回問うのではなく、実行環境そのものを箱に閉じ込めて、許可した範囲の外には物理的に手が届かないようにしてしまおう。これが今回のサンドボックスの狙いです。

ローカルサンドボックスについて公式は次のように位置付けています。

「シェルコマンドの実行の隔離に焦点を当てており、エージェント型ワークフローが成熟するにつれて、より広範な CLI レベルの隔離の基盤となる」

https://github.blog/changelog/2026-06-02-cloud-and-local-sandboxes-for-github-copilot-now-in-public-preview/

つまり今回は「シェルコマンド」に対する隔離が出発点であり、今後さらに広い範囲に拡張されることが示唆されています。

ローカルサンドボックスを試す

前提

  • macOS
  • Copilot CLI をインストール済み
  • 組織で利用する場合は、組織または Enterprise の所有者がサンドボックスポリシーを有効化している必要があります

有効化と無効化

サンドボックスは 2026 年 6 月 15 日現在パブリックプレビュー中です。そのため、まずは Copilot CLI のターミナルで下記のコマンドを実行し、サンドボックスを有効化するスラッシュコマンドを使えるようにします。

/experimental on

スクリーンショット 2026-06-15 21.25.48

次にサンドボックスを有効化します。

/sandbox enable

スクリーンショット 2026-06-15 21.26.14

ちなみにサンドボックスを無効化したいときは /sandbox disable を入力します。

/sandbox enable でサンドボックスを有効化した後、Copilot がユーザーに代わって実行するシェルコマンドはサンドボックス内で走り、ファイルシステム・ネットワーク・システム機能へのアクセスが制限された状態になります。

スクリーンショット 2026-06-15 21.26.26

対話 UI で詳細設定: /sandbox

引数なしで /sandbox を実行すると対話式の構成 UI が開きます。タブは 3 つ。

全般 (General)
スクリーンショット 2026-06-15 21.27.10

ファイルシステム (Filesystem)
スクリーンショット 2026-06-15 21.47.56

ネットワーク (Network)
スクリーンショット 2026-06-15 21.47.56

Tabか矢印キーでタブ切り替え、Esc で保存して終了。設定の永続化先は Copilot CLI の settings.jsonsandbox キー配下です(CLI 構成ディレクトリの場所は ドキュメント 参照)。

全般タブ

項目 内容
Sandboxing enabled /sandbox enable と同じスイッチ。ON でシェルコマンドをサンドボックス内で実行
Sandbox MCP servers ON で MCP サーバーをサンドボックス内で実行
Sandbox LSP servers ON で LSP サーバーをサンドボックス内で実行
Allow keychain access ON でサンドボックスされたコマンドが macOS Keychain(git / gh の credential helper 等)を利用可能

スクリーンショット 2026-06-15 21.27.10

MCP / LSP サーバーまでサンドボックスに入れられる

Copilot CLI ではユーザー定義の MCP サーバーや LSP サーバーをセットアップできますが、これらは外部プロセスとして手元で動いており、シェルコマンドと同じくファイルや通信に触れます。

Sandbox MCP servers を ON にすれば、Copilot から呼ばれた MCP サーバーの実行までサンドボックス境界の中に押し込めるので、

  • 信頼度が未知のサードパーティ MCP サーバーを試したいとき
  • LSP の node プロセスがプロジェクト外のファイルを読みに行かないか心配なとき

といったケースで「シェル経由じゃないから」と気にせずサンドボックスの恩恵を受けられます。MCP 周りを業務で本格運用するならこの 2 つは ON 推奨だと思います。

キーチェーンアクセスの制御

Allow keychain access を OFF にすると、サンドボックス内のプロセスから macOS Keychain にアクセスできなくなります。画面上の説明文では git, gh credential helpers が例として挙がっていますが、要は Copilot 経由のコマンドが勝手にトークンを取って外部 push しないようにする保険です。

ファイルシステムタブ

項目 内容
Include working directory ON で現在の CWD が自動的に読み書き可リストに入る
Clear policy on exit ON でセッション終了時にファイルシステムの権限が初期化される

A キーで読み取り専用 / 読み書きパスを追加でき、Enter で編集、D で削除。プロジェクト外で参照したいフォルダがあれば個別に許可していく形です。

スクリーンショット 2026-06-15 21.52.10

ネットワークタブ

ネットワーク接続に関する設定を行うタブです。

項目 内容
送信接続を許可する OFF にすると、外部インターネットへの接続をすべて遮断します
ローカルネットワークを許可する OFF にすると、localhost や LAN 上のホストへの接続を遮断します

このタブでも A キーを押すことで、ホスト単位の allow/block ルールを追加できます。
たとえば、「外部接続は基本的にブロックしつつ、npm と github.com だけは許可する」といった、きめ細かい制御が可能です。

スクリーンショット 2026-06-15 21.53.55

実際にブロックされるか試してみた

ここからは実際に試してみます。

ケース 1: 作業ディレクトリ外への書き込み

サンドボックスを有効にした状態で、Copilot に「/tmp/foo.txt にメモを書いて」と依頼してみます。
作業ディレクトリの外にあるパスへの書き込みを試みることで、サンドボックスがどのように動作するかを確認します。

スクリーンショット 2026-06-15 22.00.52

Copilot は /tmp/foo.txt への書き込みを試みましたが、サンドボックスによってブロックされていることがわかります。作業ディレクトリ外への書き込みが拒否され、許可されたディレクトリに作成を求めるプロンプトが表示されました。

ケース 2: 外部ホストへの curl

ネットワークタブで「送信接続を許可する」を OFF にした状態で、Copilot に「example.com の HTML を取得して」と頼みます。

まずは「送信接続を許可する」を OFF にします。

スクリーンショット 2026-06-15 22.04.31

続いて Copilot に「example.com の HTML を取得して」と頼みます。

スクリーンショット 2026-06-15 22.17.01
スクリーンショット 2026-06-15 22.17.54

サンドボックスを ON にしているのに普通に取得できてしまいました。ログを見ると、Copilot は curl ではなく web_fetch ツール(モデル側に組み込まれたビルトインツール)を呼び出していました。

公式 Changelog にも明記されているとおり、

"This release focuses on isolating shell command execution initiated by Copilot, laying the foundation for broader CLI-level isolation as agentic workflows mature."

https://github.blog/changelog/2026-06-02-cloud-and-local-sandboxes-for-github-copilot-now-in-public-preview/

今のサンドボックスが隔離するのは「Copilot が起動するシェルコマンド」のみ。web_fetch のような内蔵ツールはサンドボックスの境界外で実行されるので、ネットワーク設定をいくら絞っても効きません。

そのため、ネットワーク隔離の動作確認をしたい場合は シェルコマンドを明示的に指示する必要があります。

今度は curl で試してみます。

スクリーンショット 2026-06-15 22.18.29

Copilot は !curl https://example.com のようにシェル経由で実行に進むため、こちらは Allow outbound connections: OFF できちんとブロックされました。

シェル経由の操作(npm install、git push、curl、wget など)をガードするのが今回のサンドボックスの守備範囲で、ここは公式の "shell command execution" の文言どおり、と理解しておくのが正しい認識です。

将公式の Changelog では「laying the foundation for broader CLI-level isolation as agentic workflows mature」と記載されており、これは将来の拡張を示唆しています。今後のアップデートに期待です。

ケース 3: ホスト単位の allow

「送信接続を許可する」を OFF にしつつ、registry.npmjs.org だけ allow に登録。Copilot に npm install 系のコマンドを実行させて、想定通り npm 関連だけ通って他は通らないかを確認します。

まず、registry.npmjs.org を allow に追加します。
スクリーンショット 2026-06-16 7.58.52

追加できました。
スクリーンショット 2026-06-16 7.59.15

curl で呼び出してみます。シェルで curl -I https://registry.npmjs.org/ を実行して と依頼します。
スクリーンショット 2026-06-16 8.02.32

しかし、拒否されてしまいました。
画面をよく見ると、黄色い文字で次の警告が表示されています。

Outbound is off, so host rules below are not applied. Turn on "Allow outbound connections" to use them.

スクリーンショット 2026-06-16 8.04.53

これは「送信接続が無効になっているため、以下のホストルールは適用されません。『送信接続を許可する』を有効にしてください。」という意味です。

つまり、送信接続を OFF にしている状態では、allow ルールを登録しても適用されないということです。

というわけでアウトバウンド接続を有効化しました。
スクリーンショット 2026-06-16 8.16.25

すると、今度は別の黄色い警告が表示されました。

macOS Seatbelt can't block hosts individually - host entries are kept in settings but not enforced.

これは「macOS の Seatbelt では、ホストを個別にブロックすることはできません。ホストのエントリは設定に保存されますが、適用はされません。」という意味です。

本当にホスト単位の制御が効かないのか、実際に試してみます。

再度 curl で呼び出してみます。
スクリーンショット 2026-06-16 8.08.45

今回は成功しました。続いて、npm 以外のホストに対しても curl を実行してみます。
スクリーンショット 2026-06-16 8.11.01

こちらも成功してしまいました。

警告に記載されていたとおり、本検証環境(macOS)の Seatbelt では、ホスト単位のホワイトリスト(allow ルール)が機能していないことが確認されました。Linux や Windows での動作は異なる可能性があります。

ケース 4: キーチェーンアクセス OFF と git 操作

「キーチェーンアクセスを許可する」を OFF にした状態で、Copilot に git push を依頼します。この設定では、キーチェーンに保存された認証情報を取得できないため、git push は失敗するはずです。

まず、「キーチェーンアクセスを許可する」を OFF にします。
スクリーンショット 2026-06-16 8.14.48

この状態で、Copilot に git push を依頼します。
スクリーンショット 2026-06-16 8.29.19

想定どおり、認証情報を取得できず、操作は拒否されました。

おわりに

実際に触ってみて、ローカルサンドボックスは「Copilot が起動するシェルコマンド」を隔離するための仕組みだということがよくわかりました。/sandbox enable するだけで手元の作業に一段ガードレールが増えるのは、シンプルに嬉しいです。

一方で、検証してみると、現在のサンドボックスの守備範囲が明確になりました。

  • 守るのはシェルコマンドのみ。web_fetch のような内蔵ツールは境界の外
  • macOS の Seatbelt 環境では、ホスト単位の allow/block が効かない

なので「サンドボックスを ON にしたから安全だ!」と過信せず、何が隔離されて何が隔離されないのかを理解した上で使うのが大事ですね。

参考リンク

この記事をシェアする

関連記事