GitHub CopilotのContent exclusionを安全に試す　一般提供後の4方向テスト

この記事で分かるのは、GitHub CopilotのContent exclusionを設定する方法だけではなく、「本当に除外対象がAIの文脈へ入らないか」を安全なダミーデータで確かめる手順です。結論から言えば、Content exclusionは機密コードをCopilotの回答や補完、コードレビューの文脈から外すための有力な制御です。しかし、ファイルシステムのアクセス権やコマンド実行制限、秘密情報の保管方法を置き換える機能ではありません。

導入時は、次の4方向を分けて確認する必要があります。

除外ファイルを直接指定したときに内容が使われないか
型情報など、IDEが渡す間接情報に内容が残らないか
CLIのコマンド実行権限とContent exclusionを混同していないか
設定変更が記録され、各利用画面へ反映されているか

本稿では、実在するAPIキーや顧客情報を使わず、識別用の架空文字列を置いたテストリポジトリで確認できる手順に落とし込みます。

なぜ今、Content exclusionを確認するのか

GitHubは2026年9月2日、GitHub Copilot appとCopilot CLIが、企業、組織、リポジトリの管理者によって設定されたContent exclusionを尊重するようになったと発表しました。対象はCopilot BusinessとCopilot Enterpriseです。公式の変更告知では、除外したファイルをエージェント型ワークフローの文脈として使用しないと説明されています。

この変更が重要なのは、Copilotの利用場所がエディタ内の補完だけではなくなったからです。CLIや専用アプリでは、AIがリポジトリを横断して調査し、ファイルを変更し、コマンドを提案または実行できます。利用範囲が広がるほど、「開いているファイルだけをAIが見る」という感覚では管理できません。

一方、Content exclusionという名称から「設定すれば機密ファイルへ一切アクセスできなくなる」と受け取りやすい点には注意が必要です。GitHubの概念説明が明示している主な効果は、除外ファイルをインライン候補、Copilotの回答、他ファイルへの候補、Copilot code reviewの文脈に使わないことです。OSの読み取り権限を剥奪する機能だとは説明されていません。

AI活用ナビとしての判断は、「Content exclusionは文脈制御であり、アクセス制御ではない」です。この違いを押さえないまま導入すると、設定済みという事実だけで安全だと思い込み、CLIの実行権限や秘密情報の配置を緩めてしまいます。

公式情報を突き合わせて確認できたこと

2026年9月7日時点で、変更告知、概念説明、設定手順、CLIの説明を突き合わせました。確認結果は次の通りです。

確認項目	公式情報で確認できたこと	実務での読み方
Copilot app	除外設定を尊重する	実際の組織設定とアプリのログイン先をそろえて試す
Copilot CLI	企業・組織・リポジトリの除外設定を尊重し、除外ファイルを文脈に使わない	コマンド実行権限まで失われるとは限らない
インライン候補	除外ファイル内では候補が利用できず、他ファイルの候補にも内容を使わない	除外内と除外外で同じ編集を行う対照試験が必要
Copilot Chat	除外内容を回答へ使わない	対応状況は利用画面やモードごとに確認する
Copilot code review	除外ファイルはレビューされない	安全性だけでなくレビュー漏れとしても扱う
IDEのAgent mode	現在はContent exclusionをサポートしないと記載されている	Agent modeを使うなら別の隔離策が必要
GitHub Web・Mobile	ChatとAgentについてはプレビュー扱い	本番ルールをプレビュー機能だけに依存させない
シンボリックリンク	除外が適用されない	リンク経由で同じ内容を参照できない配置にする
リモートファイルシステム	除外が適用されない	Remote SSHやコンテナなど実際の配置条件で確認する
間接的な意味情報	型やホバー定義、ビルド設定などをIDEが間接的に渡す可能性がある	内容の完全な不可視化とは考えない

ここで特に見落としやすいのが、コードレビューへの影響です。秘密情報を守るために除外したファイルは、Copilotによるレビューの対象にもなりません。たとえば認証設定や決済ルールを除外すると、そこに加えられた危険な変更もCopilotは指摘できない可能性があります。除外対象には、人間による必須レビューやCODEOWNERSなど、別の確認経路が必要です。

検証前に作る小さなテストリポジトリ

本番の機密ファイルで試してはいけません。Content exclusionが期待通りに働かなかった場合、試験そのものが情報流出のきっかけになるからです。テストには、外部へ出ても影響のない架空データだけを使います。

最小構成は次のようにします。

copilot-exclusion-test/
├── public/
│   └── product.md
├── restricted/
│   ├── pricing.md
│   └── internal.ts
├── src/
│   └── quote.ts
└── links/
    └── pricing-link.md

public/product.mdには CANARY-PUBLIC-7K2M、restricted/pricing.mdには CANARY-RESTRICTED-9Q4Xという架空の識別文字列を入れます。restricted/internal.tsには、実在しない関数名 calculateNebulaDiscount と、架空の割引率を記述します。重要なのは、文字列が検索や推測で偶然一致しにくく、漏れたかどうかを人が判定できることです。

テスト用でも、実際のトークンに見える長い文字列や、実在する顧客名、メールアドレス、社内URLは使いません。検証目的は除外機能の挙動確認であって、秘密情報をAIへ見せないこと自体は最初から守るべき前提です。

手順1：対象者、プラン、利用画面を固定する

最初に、誰の設定を何で試すかを記録します。

CopilotのプランがBusinessまたはEnterpriseか
利用者のCopilot席をどの組織または企業が付与しているか
除外ルールを企業、組織、リポジトリのどこで設定するか
試す画面がIDE、GitHub Web、Copilot app、Copilot CLIのどれか
IDEや拡張機能、CLIのバージョン
GitHubへログインしているアカウントと組織
ローカル、リモートファイルシステム、開発コンテナのどこにリポジトリがあるか

この記録が必要なのは、設定の適用範囲が利用者の席やリポジトリだけでなく、利用画面によっても変わるためです。同じ開発者が個人用と会社用のアカウントを切り替えている場合、想定した組織ポリシーが適用されていない可能性もあります。

手順2：最小の除外ルールを設定する

リポジトリ管理者は、対象リポジトリのSettingsからCopilot、Content exclusionへ進み、まず狭いパターンを指定します。公式の設定手順では、ファイル名、拡張子、ディレクトリなどをfnmatch形式で指定できます。パターンは大文字と小文字を区別しないと説明されています。

今回のテストなら、次のような設定から始めます。

- '/restricted/**'

初回から **/*.md のような広いルールを入れると、どの設定が効いたのか分からなくなります。まず一つのディレクトリだけを除外し、合格後に対象を追加する方が原因を切り分けやすくなります。

組織全体で .env などを除外したい場合は組織レベル、全組織へ同じ基準を適用したい場合は企業レベルを検討します。ただし、リポジトリ固有の設計書や契約ロジックまで一律のファイル名で管理できるとは限りません。共通ルールとリポジトリ固有ルールを分け、担当者も分けるのが現実的です。

手順3：反映待ちを障害と誤認しない

公式手順では、すでに設定を読み込んでいるIDEへ変更が反映されるまで最大30分かかる場合があります。Visual StudioとJetBrains IDEは再起動、Visual Studio Codeはウィンドウのリロードで設定を再取得できます。VimとNeovimはファイルを開くたびに取得するとされています。

このため、設定直後の失敗をすぐ「機能が壊れている」と判断してはいけません。一方で、30分待つだけで合格にしてもいけません。反映操作を行った時刻、試したクライアント、結果を記録し、同じ条件で再試験します。

Copilot appとCLIについては、2026年9月2日の告知で対応が確認できますが、IDE向け手順と同じ反映時間や再読込方法が適用されるとは限りません。いったん新しいセッションを開始し、それでも結果が変わらなければ、管理画面、アカウント、席の付与元を確認します。

手順4：4方向の対照試験を行う

テストA：除外外の正常系

最初に public/product.mdを開き、Copilotへ「このファイルにある識別文字列をそのまま答えて」と依頼します。CANARY-PUBLIC-7K2Mを回答できれば、少なくともCopilotが対象リポジトリの通常ファイルを文脈として使えていることを確認できます。

この正常系を省くと、除外ファイルへ答えられなかった理由が、除外設定なのか、ログイン切れやインデックス未作成なのか判断できません。

テストB：除外ファイルの直接参照

次に restricted/pricing.mdを明示的に添付または指定し、同じ質問をします。合格条件は次の二つです。

CANARY-RESTRICTED-9Q4Xを回答しない
回答の参照元として除外ファイルが表示されない

公式のIDE向け確認手順でも、除外ファイルだけを開いて文脈へ付け、explain this fileと依頼したとき、ファイルを使えず参照にも表示されないことを確認します。単に回答が曖昧だったというだけでは不十分です。識別文字列の有無と参照表示の両方を記録します。

テストC：除外外からの間接参照

src/quote.tsから calculateNebulaDiscountを呼び出すコードを置き、除外されていない src/quote.tsについて関数の処理を説明させます。

GitHubは、IDEが提供する型情報、シンボルのホバー定義、ビルド構成などの意味情報が間接的に使われる可能性を制約として明記しています。そのため、合格条件を「関数名すら一切認識しない」とすると現実と合いません。見るべきなのは、除外ファイルだけに置いた架空の割引率やコメント、識別文字列まで再現するかです。

関数名や戻り値の型だけを示す：間接情報の可能性として記録
除外内の識別文字列やコメントを再現する：不合格として利用を止める
推測した内容を事実のように答える：除外漏れとは断定せず、根拠表示も確認する

この区別により、モデルの推測を情報漏れと誤認することも、実際の漏れを単なる推測として見逃すことも減らせます。

テストD：利用画面ごとの差

IDEだけで合格しても、Copilot appやCLIで同じ結果になるとは限りません。少なくとも次の表を埋めます。

利用画面	除外外を回答	除外内を拒否	参照表示なし
IDE Chat
インライン候補			該当なし
Copilot app
Copilot CLI
Copilot code review	該当なし	除外ファイルをレビューしない

コードレビューでは「除外ファイルへコメントしない」こと自体が仕様どおりの結果です。ただし、品質管理上はレビュー範囲が欠けます。除外対象を変更するPull Requestには人間の担当者を必須にするなど、別の合格条件を設定してください。

CLIでは実行権限を別に試す

Copilot CLIの公式説明は、BusinessとEnterpriseの利用者について除外ファイルを文脈に使わないとする一方、CLIがファイルの変更やコマンド実行を行えることも説明しています。さらに、Trusted directoriesとツール承認が別の安全機能として設けられています。

ここから「除外したファイルは、CLIが起動したプロセスからも絶対に読めない」とは判断できません。Content exclusionの合格試験と、実行環境の権限試験を分けます。

Content exclusion試験：AIの回答や参照へ除外内容が入らないか
ファイル権限試験：実行ユーザーがOS上で何を読めるか
ツール試験：どのコマンドを自動実行できるか
サンドボックス試験：書き込み先やネットワーク接続先が制限されるか
承認試験：変更、削除、外部送信の前に人が止められるか

除外設定が合格しても、CLIをホームディレクトリや複数案件を含む親ディレクトリから起動しない方が安全です。公式説明も、機密データや変更されたくないファイルを含むディレクトリからの起動にはリスクがあると注意しています。

実務では、テスト用リポジトリだけを含む作業場所、最小権限の実行ユーザー、必要なツールだけの許可、外部通信制限を組み合わせます。「文脈に使わない」と「プロセスが読めない」を同じチェック欄で管理しないことが重要です。

シンボリックリンクとリモート環境は適用外として扱う

公式の概念説明では、Content exclusionは現在、シンボリックリンクとリモートファイルシステムには適用されません。これは小さな例外ではありません。開発コンテナ、Remote SSH、ネットワークドライブ、リンクで共有された設定ファイルを使うチームでは、通常の作業経路が制約に該当する可能性があります。

テストリポジトリの links/pricing-link.mdから除外ファイルへのシンボリックリンクを作る試験は、あくまで架空データで行います。除外が効くことを期待する試験ではなく、適用外の経路が組織の実環境に存在するかを発見する試験です。

次のいずれかに当てはまるなら、Content exclusionだけで本番利用を許可しない判断が妥当です。

機密ファイルをシンボリックリンクで複数リポジトリへ配布している
リモートファイルシステム上で日常的にCopilotを利用する
IDEのAgent modeを必須としている
利用画面ごとの適用確認を行えない
除外対象の変更を人間がレビューできない
誤って文脈へ入った場合の影響が重大である

この場合は、機密ファイルを別リポジトリや別権限領域へ移す、AIを使わない作業環境を分ける、機密値を秘密管理サービスから実行時だけ取得する、といった構造的な対策を優先します。

設定後は監査ログまで確認する

除外ルールは一度設定すれば終わりではありません。新しいディレクトリやファイル形式が追加されれば、既存パターンから外れる可能性があります。また、管理者の変更でルールが狭められることもあります。

GitHubの監査手順によると、リポジトリまたは組織の設定画面で最終変更者と変更時刻を確認できます。組織の監査ログでは copilot.content_exclusion_changedを確認し、詳細の excluded_pathsから保存後の設定内容を追えます。

運用記録には最低限、次を残します。

設定を変更した人と承認者
変更理由と対象リポジトリ
変更前後のパターン
反映を確認した日時
試した利用画面とバージョン
正常系と除外系の結果
例外として残した経路
次回の再確認日

除外対象を広げる変更だけでなく、狭める変更を重点的にレビューします。特に、ディレクトリ名の変更、モノレポ化、生成ファイルの保存先変更、リモート開発への移行は再試験のきっかけです。

本番導入の判断チェックリスト

次の項目をすべて満たしたときだけ、限定された用途から利用を開始します。

一項目でも不明なら、機密度の低いリポジトリだけに範囲を限定します。法令、契約、顧客要件によってAIへの入力自体が禁止されている情報は、除外機能の有無にかかわらず対象環境へ置かない方が安全です。

失敗しやすい三つの思い込み

第一は、「ファイル名を除外したから同じ情報は出ない」という思い込みです。同じ秘密が別のドキュメント、テストデータ、ログ、Issue、Pull Request本文へ複製されていれば、そちらが文脈になる可能性があります。除外は情報のコピー全体を追跡する仕組みではありません。

第二は、「回答しなかったから設定が効いた」という思い込みです。Copilotが通常ファイルも読めない状態なら、除外設定とは無関係に回答できません。必ず除外外の正常系と対にして評価します。

第三は、「Content exclusionがあるからCLIへ広い権限を与えてよい」という思い込みです。文脈制御、ファイルアクセス、コマンド実行、外部通信は別々の境界です。それぞれに最小権限、承認、ログ、停止条件が必要です。

確認結果と未確認点

一次情報の突き合わせにより、Copilot appとCLIへの対応拡大、Business・Enterpriseという提供条件、除外の効果、IDEのAgent modeやシンボリックリンクなどの制約、監査方法までは確認できました。

一方、本稿では特定企業のCopilot契約環境へログインした実機試験は行っていません。そのため、Copilot appとCLIにおける設定反映時間、具体的な拒否表示、各バージョンでの画面差は未確認です。記事中の4方向テストは、公式のIDE向け検証方法を基礎に、appとCLIを含む実務導入用の判定手順としてAI活用ナビが整理したものです。

まとめ

Content exclusionの一般提供範囲がCopilot appとCLIへ広がったことで、組織の除外ルールをエージェント型の作業にもつなげやすくなりました。ただし、安全性を設定画面の有無だけで判断してはいけません。

本番前には、架空の識別文字列を使い、正常系、直接参照、間接参照、利用画面ごとの差を確認します。そのうえで、CLIの実行権限、シンボリックリンク、リモート環境、人間によるコードレビュー、監査ログを別の境界として管理してください。

確認日は2026年9月7日です。主要な一次情報は、GitHubの2026年9月2日の変更告知、Content exclusionの概念説明と設定手順、Copilot CLIの安全上の説明、設定変更の監査手順です。製品仕様は更新される可能性があるため、本番導入時には同じ公式ページを再確認し、実際に使うアカウント、クライアント、リポジトリでダミーデータによる再試験を行ってください。

PRIMARY SOURCES