GitHub Copilotアプリに「ローカルサンドボックス」——ファイル・ネットワーク・認証情報を3項目で制御

GitHubは、GitHub Copilotアプリに「ローカルサンドボックス」機能をパブリックプレビューとして追加したと発表しました。ローカルリポジトリやワーキングツリーでのセッション実行時に、意図しないコマンドがファイルやネットワーク、認証情報に及ぼす影響を、プロジェクト単位の設定であらかじめ制限できる仕組みです。エージェントに自律的な作業を任せる場面が増えるなか、実行範囲を事前に絞り込める点は実務上の安心材料になりそうです。コーディングエージェントがリポジトリの外側にあるファイルを誤って書き換えたり、想定外の外部ホストと通信したりするリスクは、自律性が上がるほど無視しにくくなっており、今回の機能はそうした懸念に正面から応える位置づけといえます。

サンドボックスで制御できる3項目

ローカルサンドボックスでは、プロジェクトごとに「ファイルシステム」「ネットワーク」「認証情報」の3つの観点でアクセス範囲を設定します。ファイルシステムでは、追加の読み書き許可フォルダ、追加の読み取り専用フォルダ、アクセス拒否フォルダをそれぞれリストで指定可能です。ネットワークは、外部インターネットへの送信とローカルネットワークへのアクセスを個別に制御できます。認証情報については、HTTPS経由のGit操作に使う認証情報と、GitHub CLIの認証情報を分けて扱う設計になっており、セッションが不必要に広い権限を持たないようにする狙いがうかがえます。

プロジェクト単位の設定と有効化の流れ

これらのプロジェクト設定は、サンドボックス化されたセッションを開始する際にアプリが要求するポリシーとして扱われます。GitHub Copilotアプリの設定画面からプロジェクトを選び、「Sandbox」欄にある「Sandbox new sessions」を有効にすることで利用が始まります。デフォルトはオフで、既存の実行中セッションには適用されず、新規セッションか、既存セッションの再起動時から設定が反映されます。すでに動いているローカルセッションに一時的にサンドボックスをかけたい場合は、セッション内で/sandbox onと入力することでそのセッション限定の設定変更も可能です。細かい単位で制御できるため、プロジェクトの性質に応じて段階的に適用範囲を広げていく運用がしやすくなっています。

エンタープライズ管理と適用範囲の注意点

実際に適用されるポリシーは、エンタープライズ管理設定が存在する場合、プロジェクト側の設定よりも制限が強くなることがあります。組織として一定のセキュリティ水準を強制したい場合に有効な仕組みです。また、OSが要求されたポリシーを実施できない場合は、サンドボックスなしでコマンドを実行してしまうのではなく、サンドボックス化されたシェル自体がエラーで失敗する「フェイルクローズ」の設計になっている点も安全性への配慮を感じさせます。なお、ローカルサンドボックスはクラウドサンドボックスセッションやリモートホスト上のセッションには適用されず、GitHub CopilotアプリとCopilot CLIのサンドボックス設定はそれぞれ別々に行う必要がある点にも注意が必要です。

エージェントにローカル環境での自律的な作業を任せる機会が増えるほど、実行前に「どこまで触れてよいか」を明示できる仕組みの重要性は増していきます。まずは影響範囲の小さいプロジェクトからサンドボックスを有効にし、読み書き可能なフォルダやネットワークアクセスの範囲を確認しながら、自分のワークフローに合った制限の粒度を探ってみるとよさそうです。パブリックプレビュー中は仕様が変更される可能性がある点も踏まえ、本番運用に組み込む前に挙動を確かめておくことをおすすめします。

Source GitHub Changelog

Local sandboxing in the GitHub Copilot app

Local sandboxing helps reduce the potential impact of unintended commands by limiting access to files, network resources, and credentials on your machine. In the GitHub Copilot app, you configure it per project for local repository and working tree sessions.