2026年9月2日、GitHub Copilotの「コンテンツ除外」機能がCopilotアプリとCopilot CLIでも一般提供されました。IDEに限られていた保護範囲がエージェント型の実行環境にも広がった今回のアップデートについて、背景・設定方法・運用のポイントを一次情報から整理します。
GitHub Copilotの「コンテンツ除外」がCopilotアプリ・CLIに拡大
2026年9月2日、GitHub Copilotの「コンテンツ除外（Content Exclusion）」機能がCopilotアプリとCopilot CLIでも一般提供（GA）されました。これまでVS CodeなどIDE上のCopilotでは利用できていたこの機能が、エージェント型の実行環境にも広がったことで、機密情報を含むファイルをCopilotのコンテキストから確実に除外できる範囲が一段と広がっています。
何が変わったのか（2026年9月2日のアップデート概要）
GitHub公式のChangelogでは、今回のアップデートについて次のように説明されています。「The GitHub Copilot app and Copilot CLI now respect content exclusion policies configured by enterprise, organization, and repository administrators. Copilot won’t use excluded files as context, helping you protect sensitive code across agentic workflows.」（GitHub Copilotアプリおよび Copilot CLI は、エンタープライズ・組織・リポジトリの管理者が設定したコンテンツ除外ポリシーを尊重するようになりました。Copilotは除外対象のファイルをコンテキストとして使用しなくなり、エージェント型ワークフロー全体で機密コードを保護しやすくなります）。
つまり、リポジトリの設定画面などで「Copilotに読ませたくないファイル」をあらかじめ指定しておけば、Copilotアプリでの自律的なエージェント実行や、ターミナルから使うCopilot CLIでのタスク実行時にも、その除外ルールが効くようになったということです。
対象プランと設定できる人
コンテンツ除外は、Copilot BusinessまたはCopilot Enterpriseプランの利用者が対象の機能です。設定・変更ができるのはリポジトリ管理者、組織オーナー、エンタープライズオーナーで、リポジトリの「Maintain」ロールを持つメンバーは設定内容の閲覧のみ可能です。個人向けプラン（Copilot Free・Copilot Pro・Copilot Pro+）では利用できない点に注意してください。
そもそも「コンテンツ除外」とは何か
なぜ今、重要性が増しているのか
Copilotは当初、コード補完やチャットでの質問応答が中心でしたが、現在はリポジトリ内のファイルを横断的に読み込み、複数のファイルを自律的に編集・実行するエージェント型のワークフローが主流になりつつあります。関連記事「GitHub Copilotアプリとは？複数エージェントを1画面で操るデスクトップアプリ」でも紹介した通り、Copilotアプリでは複数の並列セッションが同時にリポジトリを操作します。
こうしたエージェントが参照範囲を広げるほど、.envファイルの認証情報や、社内向けドキュメントに書かれた顧客情報、契約書のドラフトなど、Copilotに読ませたくないファイルが意図せずコンテキストに入り込むリスクも高まります。コンテンツ除外は、こうしたファイルをあらかじめ「Copilotの視界の外」に置いておくための仕組みです。
これまでの対応範囲とのギャップ
コンテンツ除外自体は目新しい機能ではなく、IDE上のCopilot Chatや補完機能ではすでに一般提供されていました。しかし、Copilotアプリのようなエージェント実行環境やCopilot CLIといった、ファイルシステムへのアクセス範囲がより広いクライアントでは、これまで除外ポリシーが必ずしも一貫して適用されているとは限りませんでした。今回のアップデートは、そのギャップを埋めるものと言えます。なお、GitHub CLIやIDEのAgent modeなど機能ごとに対応状況が細かく異なるため、実際に運用する際は必ず公式ドキュメントの最新情報を確認することをおすすめします。
設定方法：リポジトリ・組織・エンタープライズの3階層
コンテンツ除外は、リポジトリ・組織・エンタープライズの3つの階層で設定でき、上位階層で設定したルールは下位のリポジトリに継承されます。
リポジトリ単位で除外する
対象リポジトリの「Settings」→「Copilot」→「Content exclusion」から設定します。「Paths to exclude in this repository」の欄に、- "/PATH/TO/FILE"の形式でパスを1行ずつ入力します。「#」で始まる行はコメントとして扱われます。
# kernel.rsファイルを除外
- "/src/some-dir/kernel.rs"
# ファイル名がsecretsで始まるファイルをすべて除外
- "secrets.json"
# scriptsディレクトリ以下をすべて除外
- "/scripts/**"組織単位で除外する
組織の「Settings」→「Copilot」→「Content exclusion」から、Gitリポジトリ内外を問わずファイルを指定できます。すべてのリポジトリ・ファイルシステムを対象にする場合は"*":、特定のリポジトリを対象にする場合はリポジトリの参照（https://github.com/org/repo.gitなど）をキーにして、除外パスをリスト形式で指定します。
# すべてのリポジトリ・ファイルシステムで.envファイルを除外
"*":
- "**/.env"
# 特定リポジトリのsecrets.jsonを除外
https://github.com/example-org/example-repo.git:
- "secrets.json"エンタープライズ単位で除外する
エンタープライズ設定画面の「AI controls」から同様の設定が可能です。エンタープライズ単位のルールはそのエンタープライズに所属するすべてのCopilotユーザーに適用される一方、組織単位のルールはその組織からCopilotシートを割り当てられたユーザーのみに適用される点が異なります。全社的に必ず守らせたいルールはエンタープライズ単位、部署やプロジェクト固有のルールは組織・リポジトリ単位で設定する、という使い分けが現実的です。
fnmatchパターンの書き方
パスの指定にはRubyのfnmatch記法が使えます。大文字・小文字は区別されません。secret*と書けばファイル名が「secret」で始まるすべてのファイル、*.cfgと書けば拡張子が「.cfg」のすべてのファイルが対象になります。ワイルドカードを組み合わせることで、命名規則さえ揃っていれば個別にファイルを列挙しなくても効率的に除外設定を行えます。
設定後の確認とトラブルシューティング
IDEへの反映には最大30分かかる
コンテンツ除外の設定を追加・変更しても、すでにIDEに読み込まれている設定にはすぐに反映されない場合があります。公式ドキュメントによれば、変更が反映されるまで、IDEによっては最大30分ほどかかることがあり、すぐに変更を確認したい場合は、IDE側で設定の再読み込みを手動で行う必要があります。「設定したはずなのにCopilotがファイルを参照してしまう」という場合は、まずこの反映待ちの時間を疑ってみてください。
除外設定が意図通り動くかテストする方法
設定が正しく機能しているかどうかは、実際にCopilot ChatなどでIDE上から該当ファイルの内容について質問してみることで確認できます。除外が正しく効いていれば、Copilotはそのファイルの内容を参照できない旨を返します。本番運用に入る前に、必ず主要な除外パターンについて動作確認を行うことをおすすめします。
REST APIでプログラム的に管理する
組織オーナー・エンタープライズオーナーは、GitHubのREST APIを使ってコンテンツ除外ルールをプログラムから管理することも可能です。多数のリポジトリを抱える組織では、Infrastructure as Codeの発想で除外ルールをバージョン管理し、CI/CDパイプラインの一部として自動的に適用・監査する運用も検討する価値があります。
実務での活用ポイント
.env・secrets.jsonなど典型的な除外対象
実務でまず優先的に除外を検討すべきなのは、.envファイルやAPIキーを含む設定ファイル、secrets.jsonのような機密情報ファイル、顧客の個人情報を含むテストデータやシードデータなどです。これらは"**/.env"のようなワイルドカードパターンで、リポジトリを横断して一括除外しておくと運用の抜け漏れを防げます。
MCPサーバーのallowlistと組み合わせたガバナンス
コンテンツ除外は「Copilotに何を読ませないか」を制御する仕組みですが、これと合わせて「Copilotがどの外部ツール・MCPサーバーを呼び出せるか」を制御する仕組みも重要です。以前の記事「GitHub CopilotのMCPサーバーを安全に管理する｜allowedMcpServers・deniedMcpServersの設定方法と評価ルール」で紹介したallowedMcpServers／deniedMcpServersによるMCPサーバーのallowlist機能と組み合わせることで、「読ませない情報」と「使わせないツール」の両面から、より多層的なガバナンス体制を構築できます。
Copilotアプリでのエージェント運用時の注意点
Copilotアプリのように複数のエージェントセッションを並列で走らせる環境では、1つのセッションが誤って機密ファイルを参照・出力してしまうと、生成されたコードやログを通じて情報が拡散するリスクがあります。エージェントに広い権限を与えて自律的にタスクをこなさせる運用に移行するほど、コンテンツ除外のようなガードレールをあらかじめ整備しておくことの重要性は増していきます。導入時には、まずリポジトリ単位で小さく試し、問題がなければ組織・エンタープライズ単位へと段階的に適用範囲を広げていくのが安全です。
まとめ
GitHub Copilotの「コンテンツ除外」機能がCopilotアプリ・CLIでも一般提供されたことで、IDEだけでなくエージェント型の実行環境全体で、機密ファイルをCopilotのコンテキストから確実に除外できるようになりました。設定はリポジトリ・組織・エンタープライズの3階層で行え、fnmatchパターンを使えば命名規則ベースで効率的に除外ルールを組めます。反映まで最大30分ほどかかる点や、除外設定の動作確認方法、REST APIによるプログラム管理といった運用面のポイントも押さえた上で、MCPサーバーのallowlist機能などとあわせて、エージェント時代に見合ったセキュリティ体制を整えていくことをおすすめします。
