GitHubは2026年9月23日、GitHub Copilot appにlocal sandboxingのpublic previewを追加しました。対象はローカルリポジトリとworking treeのセッションで、エージェントが実行するコマンドの影響範囲をファイル、ネットワーク、認証情報の3軸で制限できます。AI codingを本番チームに広げる企業にとって、これは「便利な自動化」から「統制できる自動化」へ移るための重要な更新です。
概要：何が新しいのか
local sandboxingは、Copilot app内でエージェントが呼び出すツールをOSレベルのsandbox内で実行する仕組みです。GitHub公式ドキュメントでは、意図しないコマンドの影響を減らすため、ローカルマシン上のファイル、ネットワークリソース、認証情報へのアクセスを制限すると説明されています。設定はプロジェクト単位で行い、新規セッションや再起動後のセッションに反映されます。
重要なのは、working treeだけでは保護にならない点です。working treeは並行セッションのブランチやファイルを分けますが、別フォルダへのアクセスまでは止めません。local sandboxingは、その不足を補う追加の保護層です。
仕様表：3つの制御ポイント
制御ポイントは3つです。1つ目はFilesystemで、作業ディレクトリ以外に追加で読み書きできるフォルダ、読み取り専用フォルダ、拒否フォルダを指定できます。2つ目はNetworkで、インターネット接続とローカルネットワーク接続を制御できます。3つ目はCredentialsで、HTTPS Git操作用のGit credentialsとGitHub CLI credentialsをsandbox内で使わせるかを選べます。
既定では、sandbox化されたセッションはworkspaceとcurrent working directoryに読み書きでき、インターネットとローカルネットワークにも接続できます。認証済みGit操作とGitHub CLI認証も利用可能です。つまり、プロジェクトのリスクに合わせて追加制限を設計する機能です。
AI開発環境の権限制御やCopilot導入ルールを整理したい場合は、HelloCraftAIにご相談ください。既存の開発フローを壊さず、sandbox・権限・監査の設計を一緒に棚卸しできます。
設定方法：まずは新規セッションから有効化する
導入手順はシンプルです。GitHub Copilot appのsettingsを開き、対象projectを選び、Sandboxセクションで「Sandbox new sessions」をオンにします。この設定は新しいローカルセッションに適用されます。既存セッションへ適用したい場合は、セッションを再起動するか、アクティブなセッションで /sandbox on を入力します。
一方で、local sandboxingはcloud sandbox sessionやremote host上のセッションには適用されません。Copilot appとCopilot CLIのsandbox設定も別管理です。社内標準にするなら、「appのプロジェクト設定」「CLI利用時の設定」「cloud sandbox利用時のポリシー」を分けて運用表に落とす必要があります。
30日PoC：管理者が確認すべきチェックリスト
30日PoCでは、まず3種類のリポジトリで試すのがおすすめです。1つ目は一般的なWebアプリ、2つ目は社内APIキーや顧客データに近いリポジトリ、3つ目はモノレポや複数サービスにまたがる大きなリポジトリです。各リポジトリで、依存関係のインストール、ローカル開発サーバー起動、テスト実行、branch push、pull request作成がどの設定で通るかを記録します。
チェック項目は8つです。1. denyすべきフォルダを列挙する。2. read-onlyで十分な共有資料を分ける。3. 書き込み許可が必要な生成物フォルダを確認する。4. outbound internetが必要なpackage registryを洗い出す。5. local networkが必要なDBやdev serverを確認する。6. Git credentialsを許可する場面を決める。7. GitHub CLI credentialsを使う操作を限定する。8. sandbox外実行の承認ルールを決める。
料金・工数シミュレーション：100人チームでの見積もり
公式発表は価格変更ではありませんが、運用工数には影響します。100人の開発チームで10プロジェクトに導入している場合、初期PoCは1プロジェクト2時間、合計20時間程度で始められます。その後、失敗したコマンドの原因を分類し、どの制限を調整するかのレビューに10〜20時間を見込むと現実的です。
効果測定は「sandboxを有効化できた割合」だけでなく、「外部実行の例外申請数」「denied pathへのアクセス失敗件数」「credentialを無効化しても完了できたPR作成率」で見ると実務に近づきます。秘密情報を扱うリポジトリでは、人間が実行する操作とエージェントに許可する操作を分けることが重要です。
FAQ
Q1. local sandboxingをオンにすれば安全ですか？ A. 重要な保護層ですが、単体で十分とは言えません。deny path、network、credentials、レビュー承認、監査ログを組み合わせます。
Q2. 既存セッションにも自動で効きますか？ A. いいえ。プロジェクト設定の変更は新規セッション、または既存セッションの再起動後に反映されます。アクティブセッションでは /sandbox on で有効化できます。
Q3. ネットワークを止めると何が困りますか？ A. package install、API呼び出し、preview server、MCPやLSP連携などに影響します。まずは必要な通信を棚卸ししてから制限するのが現実的です。
Q4. WindowsやLinuxで注意点はありますか？ A. GitHub docsでは、OSが要求されたポリシーを強制できない場合、sandboxなしで実行するのではなくエラーにすると説明されています。またLinuxではlocal network制御に一部制限があります。
まとめ：3軸で「任せてよい作業」を定義する
GitHub Copilot appのlocal sandboxingは、AIエージェントに作業を任せる前提を変える更新です。ポイントは、ファイル、ネットワーク、認証情報の3軸で「このプロジェクトでは何を許すか」を明文化することです。30日PoCで失敗ログを集め、deny pathとcredential制御から段階的に固めるのが現実的です。
