GitHub Copilotの実行隔離が正式提供。AI開発の委託先に確認する4点

開発を外注するとき、発注側が気にするのは「その会社が AI を使っているか」ではなくなってきた。ほぼ全社が使っているからである。残った問いは 2 つで、自社のコードがどこへ送られるかと、AI が開発者のパソコンで何を実行できるかである。

2026 年 10 月 7 日、GitHub が GitHub Copilot のローカルサンドボックス（実行の隔離）を正式提供（一般提供）に切り替えたと公表した。開発者の手元の機械で AI が動かすコマンドに、ファイル・ネットワーク・認証情報の制限をかける仕組みである。発注側にとっては、委託先に聞くべきことが一段具体的になった出来事である。

公表されている事実

公式の変更履歴（2026 年 10 月 7 日）に書かれているのは次の内容である。

• 対象: GitHub Copilot CLI、Copilot アプリ、Agent Host を使う VS Code のセッション
• 目的: 手元の機械で動くエージェント処理に「安全な実行の境界」を与えること
• 制限できるもの: エージェントが実行したコマンドが読み書きできるファイルとディレクトリ、インターネットと社内ネットワークへの接続、Git の認証情報、GitHub CLI の認証情報
• 対象に含まれるもの: ローカルで動く MCP サーバーや言語サーバーなど、手元のツール・サービスも（対応している範囲で）隔離の対象になる
• 組織による強制: 企業が管理する設定でサンドボックスの利用を必須にし、開発者側で緩められないようにできる
• 仕組み: Microsoft eXecution Container（MXC）を利用し、共通のポリシーを Windows・macOS・Linux それぞれの OS 機能へ割り当てる
• モデルに依存しない: ポリシーは、Copilot がどのモデルを使っていてもツールの実行に適用される
• 費用: GitHub Copilot に含まれ、追加費用はかからない

公表されているのはここまでである。既定で有効かどうか、設定項目の名称、対応しないツールの具体名は変更履歴には記載がなく、別のドキュメントに委ねられている。

発注者・企業への影響

ここから先は見立てである。

1. 聞くべきは「AI を使うか」ではなく「どこまで実行できるか」

これまで委託先への質問は「生成 AI を使いますか」「使う場合は学習に使われない契約ですか」が中心だった。送信先の話である。

実行の隔離が標準的な機能になると、問いがもう 1 つ増える。エージェントが開発者のパソコンで、どのディレクトリまで触り、どこへ接続できるかである。これは送信先の話ではなく、事故の範囲の話である。設定を誤ったエージェントが、別の案件のソースコードが置かれたディレクトリを読み、外部へ接続できる状態だったとしたら、契約上の守秘義務と実態が合わない。

外部へ出してよいデータの線引き自体は、委託先任せにせず発注側で先に決めておくのが基本である。分け方はAI開発で外部APIに送ってよいデータの決め方に整理した。

2. 「組織で強制できる」は、委託契約の確認項目になりうる

今回の発表で実務的に効くのは、開発者が個人の判断で緩められない形にできる点である。これは、委託先の社内統制としてどこまで実装されているかを確認できる、ということでもある。

とはいえ、相見積もりの段階で踏み込みすぎると候補が減る。聞き方としては次の 3 段階くらいが現実的である。

段階	聞くこと
最低限	AI コーディングツールの利用有無と、入力が学習に使われない契約かどうか
標準	案件ごとに作業領域を分けているか。他案件のコードが同じ機械の同じ領域に無いか
厳しめ	エージェントの実行制限を組織の設定として強制しているか。開発者が無効化できるか

3 段目まで求めるかは、扱うデータの機微さで決めればよい。すべての案件で厳しくする必要はない。相談の段階でどこまで情報を出すかはAI開発の相談はNDA前にどこまで話せるかに書いた。

3. 追加費用なしは「工数ゼロ」ではない

機能そのものに追加費用がかからないことと、案件の工数が増えないことは別である。隔離を厳しくすると、外部パッケージの取得やテスト用の外部接続が通らなくなり、例外を 1 つずつ設計する作業が発生する。この種の作業は見積書の行になりにくく、着手後に「思ったより進まない」という形で現れやすい。

発注側が気にすべきなのは金額そのものより、その前提が見積書に書かれているかである。厳しい制限を要求するなら、それを条件として最初に伝える。あとから足すと、開発環境の作り直しになることがある。

4. 隔離は情報漏えいの対策であって、品質の保証ではない

ここは混同されやすい。サンドボックスが防ぐのは「意図しない読み書きと接続」であって、出力されたコードが正しいかどうかには関係しない。AI が書いたコードのレビュー体制、テストの書き方、精度の測り方は別の問題である。

特に、外部の文書やチケットを読ませて作業させる使い方では、読み込んだ内容に指示が紛れ込む経路が残る。仕組みはプロンプトインジェクションとはに整理した。隔離はその影響範囲を狭めるが、発生そのものを止めるものではない。AI を使った開発の品質の見方はAI駆動開発と従来型開発の違いにまとめた。

見積もり・契約で書く 4 行

複数社に同じ条件で出すなら、次の 4 行を揃えると比較しやすい。

1. 開発に AI コーディングツールを使うか。使う場合、入力が学習に使われない契約か
2. 案件ごとに作業領域を分離しているか（他案件のコードと同じ領域に置かないか）
3. エージェントが接続できる先の制限を、誰の設定で管理しているか
4. 上記を満たすための環境構築の工数が、見積もりに含まれているか

4 行目を入れておくと、金額の差が「安いから省いた」のか「別途になっている」のかを見分けられる。無料で相見積もり・相談の案件票では扱うデータの区分を選択式で揃えているため、各社が同じ前提で体制を見積もったかを横並びで確認できる。

まとめ

今回の発表そのものは、1 つの開発ツールの機能が正式提供になったという話である。発注側にとって意味があるのは、「AI に何をさせないか」を設定として示せる状態が普通になりつつあることである。

やることは 2 つ。扱うデータの機微さに応じて、委託先へ聞く段階を決めること。そして、厳しい制限を求めるなら見積依頼の時点で条件として書くことである。あとから足すほど高くつく項目である。

参考・出典

• GitHub Changelog「Local sandboxing for GitHub Copilot now generally available」（2026 年 10 月 7 日） https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/
• GitHub Changelog 一覧 https://github.blog/changelog/