Copilot CLIが除外設定に対応、ただしシンボリックリンクは対象外

GitHubは2026年9月2日、GitHub Copilot appとGitHub Copilot CLIが管理者のcontent exclusion（コンテンツ除外）設定に従う機能を一般提供した。GitHub Changelogの発表 では、企業、組織、リポジトリの各管理レベルで設定されたポリシーが対象となり、利用できるプランはCopilot BusinessとCopilot Enterpriseとされている。

9月2日の一般提供により、設定に一致する通常のファイルはCLIの直接コンテキストから除外できるようになった。ただし、BaristaLabsの独立した解説 も確認しているように、シンボリックリンクなど別経路まで遮断する包括的な情報漏えい防止機能ではなく、利用面ごとに境界を分けて考える必要がある。

一般提供でCLIにも管理ポリシーを適用

今回の変更点は、管理画面で定義した除外ルールの適用先に、ターミナルで動くCopilot CLIとGitHub Copilot appが加わったことだ。リポジトリ管理者は自身のリポジトリ、組織所有者と企業所有者はそれぞれの管理範囲についてポリシーを設定できる。

除外対象のファイルは、Copilotが回答や処理を組み立てる際のコンテキストとして使われない。CLIが作業ディレクトリ内のコードを探索する場面にもこの制御が及ぶため、エディター外のエージェント利用と管理ポリシーの間にあった適用範囲の差が縮まった。

一方、content exclusionの管理機能は全プラン向けではない。対象はCopilot BusinessまたはCopilot Enterpriseを導入している組織であり、個人向けプランに同じ管理機能が一般提供されたという発表ではない。また、除外はCopilotへ渡す文脈を制御するもので、利用者やCLIプロセスが持つOS上のファイル権限を取り消す仕組みではない。

直接のファイル内容は除外、三つの経路は残る

通常ファイルへの直接参照には効くが、そのファイルに関係する情報の全経路を閉じるわけではない。GitHubのcontent exclusion文書 によると、除外されたファイルではインライン候補が提供されず、その内容は別ファイルの候補、Copilotの回答、Copilot code reviewにも利用されない。

同じ文書は、現在の適用範囲から外れる経路も明記している。

• シンボリックリンク：content exclusionはシンボリックリンクに適用されない。実体ファイルの直接パスを除外しても、そのファイルへリンク経由で到達する経路まで保護されたとは判断できない。
• リモートファイルシステム：リモートファイルシステム上にあるリポジトリも対象外となる。ローカルリポジトリでの適用結果を、ネットワークマウントなど異なる配置へそのまま当てはめることはできない。
• IDEが間接提供する意味情報：除外ファイルの本文を直接使わなくても、IDEから型情報、シンボルのホバー定義、ビルド構成などが渡された場合、その情報をCopilotが利用する可能性がある。

クライアント間の対応差にも注意が必要だ。GitHubの文書では、Visual Studio CodeなどのエディターにあるCopilot ChatのEditモードとAgentモードは、現在content exclusionをサポートしていない。Copilot appとCLIへの一般提供を、名称の似たIDE内機能にも適用されたと読み替えることはできない。

脅威モデル別に見る適用範囲

除外設定の有効性は、「設定済み」という一項目ではなく、守る情報がどの経路からCopilotへ届き得るかで変わる。今回確認された範囲を利用面と配置ごとに整理すると、判断基準は次のようになる。

• CLIが通常ファイルを直接参照する経路：BusinessまたはEnterpriseの管理下で、有効な除外パターンに一致するファイルはコンテキストに使われない。今回の一般提供が直接カバーする中心的な経路である。
• 同じ実体へのシンボリックリンク経路：公式に適用対象外とされているため、除外ルールだけを防御境界にできない。リンクを残す環境では、作業領域の分離やファイル権限など別の制御が必要になる。
• リモート配置のリポジトリ：content exclusionの対象外として扱う必要がある。ローカルで確認できた挙動は、リモートファイルシステム上の同一リポジトリに対する証拠にはならない。
• IDE由来の意味情報：ファイル本文が回答に現れないことと、そのファイルに由来する情報が一切使われないことは同義ではない。型名や定義情報、プロジェクト構成に由来する内容は別経路として残り得る。
• app、CLI、IDE内Agentモードの併用：同じリポジトリでも利用面によって対応状況が異なる。CLIで除外が機能しても、未対応のIDEモードまで保護されたことにはならない。

したがって、content exclusionは、正当にアクセスできる作業領域の中でCopilotへ渡す文脈を狭める追加制御と位置付けるのが適切だ。本来その端末や利用者が保持すべきでない認証情報や規制対象データを、保存してよい理由にはならない。

合成ファイルで直接コンテキストを確認する

適用結果を確かめる場合は、実際の秘密情報ではなく、意味を持たない固有文字列を入れた合成ファイルを使える。除外対象と許可対象に異なる文字列を置き、CLIが前者を文脈として扱わず、後者は利用できるかを対にして確認する。

1. 利用プラン、ポリシーの管理レベル、対象リポジトリ、除外パターン、CLIのバージョンを記録する。
2. 除外対象の合成ファイルについて、内容をプロンプトへ貼らずに、正確なパスの要約や固有文字列を求める。
3. 隣接する許可ファイルにも同種の質問を行い、リポジトリのコンテキスト自体が失われていないことを確かめる。
4. ルール変更後に同じ確認を繰り返し、新たに除外したパスと除外を解除したパスの双方を比較する。
5. app、CLI、IDEなど利用面ごとに結果を分け、シンボリックリンクとリモート配置は対象外として記録する。

この方法で確認できるのは、特定のアカウント、リポジトリ、クライアント版、ポリシーにおける直接コンテキストの挙動に限られる。間接的な意味情報の不使用や、製品全体の安全性まで証明する試験ではない。

現時点で確定しているのは、Copilot BusinessとCopilot Enterpriseの管理者によるcontent exclusionが、Copilot appとCopilot CLIでも一般提供されたことだ。通常ファイルを直接のコンテキストから外せる一方、シンボリックリンク、リモートファイルシステム、IDE経由の意味情報には制限が残る。これらの例外や、IDEのEditモードとAgentモードへの対応時期は示されていない。