4経路を塞いでも、2つの穴が残る：Copilotコンテンツ除外の設計を読む

Posted at 2026-09-04

AIコーディングエージェントに見せたくないコードを、管理者が一元的に除外できる範囲が広がった。
しかし、2026年9月2日にGAとなったGitHub Copilotの新対応は、秘密情報の完全な遮断機構ではない。
4つの利用経路を制御しても、IDEのAgent modeとファイルシステム境界には明示された穴が残る。

GitHubは2026年9月2日、Copilot appとCopilot CLIが、enterprise・organization・repository管理者の設定したcontent exclusion policyを尊重すると発表した。対象はCopilot BusinessとCopilot Enterpriseの2プランである。

重要なのは「対応面が増えた」というニュースそのものではない。除外はどの段階で効き、どこから先は効かないのか。本稿では公式ドキュメントを基に、その信頼境界を分解する。

まず結論：これは秘密管理ではなく、コンテキスト収集ポリシー

content exclusionを設定すると、公式ドキュメントは次の4つの効果を挙げている。

対象ファイル内でinline suggestionを出さない
対象ファイルの内容を、別ファイルのinline suggestionに使わない
対象ファイルの内容を、Copilotの応答に使わない
対象ファイルをCopilot code reviewでレビューしない

つまり制御点は、モデルへ渡すコンテキストを組み立てる手前にある。暗号化、アクセス権の剥奪、リポジトリからの削除ではない。この違いを見落とすと、.envを除外しただけで秘密管理が完了したと誤認する。

ルールがモデル入力へ届くまで

公式仕様から読み取れる処理を、概念的に並べると次のようになる。

管理者がパスルールを保存
        ↓
enterprise / organization / repository の適用範囲を決定
        ↓
クライアントが現在のrepository URLをGitHubへ送信
        ↓
GitHubが該当ポリシーをクライアントへ返す
        ↓
クライアントが候補コンテキストをパス照合
        ↓
除外後のコンテキストだけをCopilot機能へ渡す

最後の2段は、公開資料にある挙動を説明するための概念モデルであり、GitHubが内部実装順を公開したものではない。一方、repository URLをサーバーへ送り、対応するpolicyを受け取る点は公式に明記されている。GitHubによれば、このURLはログに記録されない。

パス照合はRubyのfnmatch記法を使い、大文字・小文字を区別しない。repository設定では、たとえば次のように指定する。

# どの階層にある secrets.json も除外
- "secrets.json"

# scripts 以下を再帰的に除外
- "/scripts/**"

# 拡張子が .cfg のファイルを除外
- "*.cfg"

organization / enterprise設定ではrepository参照をキーにできるほか、"*"を使ってGit管理外を含むファイルシステム上のパスも指定できる。

"*":
  - "**/.env"

git@github.com:example/payments.git:
  - "/internal/pricing/**"

repository URLはHTTPS、SSH、Git形式などで書ける。照合時にはuser@とport部分が無視されるため、clone方法の違いで同じrepository向けの規則が分裂しにくい設計だ。

対応範囲を表で見る

2026年9月4日時点の公式資料を、運用判断に必要な粒度へ整理した。

利用経路	content exclusion	状態・注意点
Copilot app	対応	2026年9月2日にGA発表
Copilot CLI	対応	2026年9月2日にGA発表
IDEのinline suggestion /通常Chat	対応	設定反映に最大30分かかる場合あり
GitHub上のCopilot code review	対応	対象ファイルはレビューされない
GitHub website / Mobile	対応	公式資料ではpublic preview
IDEのEdit mode / Agent mode	非対応	除外ファイルを扱わせない別対策が必要
symlink / remote filesystem上のrepository	非対応	現在の明示的制限

ここに最大の逆説がある。「agentic workflowsを保護する」と発表された同じ機能が、IDE内のAgent modeでは現在サポートされない。Copilot appやCLIと、IDEのAgent modeを同じ安全境界として扱ってはいけない。

2つの穴はなぜ残るのか

1. ファイルを除外しても、意味情報が迂回する

公式ドキュメントは、除外ファイル由来のsemantic informationをIDEが間接的に提供する可能性を認めている。例は型情報、hover definition、build configurationなどだ。

たとえばinternal/pricing/**を除外しても、公開側コードが参照する型名、関数signature、定数の型がIDEのlanguage server経由で見える可能性がある。これは全文流出と同じではないが、「そのファイルから派生した情報はゼロになる」という保証でもない。

2. パス照合できない境界がある

symlinkとremote filesystem上のrepositoryには除外が適用されない。エージェントをdev container、SSH先、network mountで動かす組織では、ローカルcheckoutで通ったテストをそのまま信用できない。

content exclusionは、API keyやpasswordをGitへ保存してよい理由にはならない。secret manager、最小権限、短命credential、tool / network policyと組み合わせる必要がある。

API自動化にも落とし穴がある

organization ownerはREST APIでルールを取得・更新できる。2026年9月4日時点でendpoint自体はpublic previewで、例示されるAPI version headerは2026-03-10である。

GET /orgs/{org}/copilot/content_exclusion
PUT /orgs/{org}/copilot/content_exclusion
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2026-03-10

読み取りにはfine-grained tokenのCopilot content exclusion: read、更新にはwrite権限が必要になる。classic PATではGETにcopilotまたはread:org、PUTにcopilotscopeが必要だ。

さらに、APIはcommentsとduplicate keysをサポートしない。PUTすると既存コメントは削除され、同一キーが複数ある場合は最後の値だけが保存される。したがってUI上のYAMLをそのまま「人間向けコメント付きpolicy as code」として往復させる設計は壊れる。

安全な同期は、次の順序にする。

正規化した単一キーの構造をsource of truthにする
GET結果と生成予定のpayloadをdiffする
変更承認後にPUTする
copilot.content_exclusion_changedをaudit logで確認する
実クライアントでnegative testを行う

変更は既に設定を読み込んだIDEへ反映されるまで最大30分かかる。VS Codeならwindow reload、JetBrainsとVisual Studioなら再起動、Vim / Neovimならファイルを開くたびに再取得される。テストでは、非除外ファイルで補完が出ることを先に確認し、その後に除外ファイルで補完が出ないことを確認する。片側だけでは、単なるCopilot停止と区別できない。

実務への含意

content exclusionは「見せないつもり」を個人の注意から管理policyへ引き上げる。特にCopilot appとCLIまで同じ管理面へ入ったことは、terminal型エージェントを企業運用するうえで大きい。

ただし、導入順序は次が現実的だ。

第1層：repository accessとsecret managementで、読めるデータ自体を減らす
第2層：content exclusionで、通常のコンテキスト収集から機密ファイルを外す
第3層：agentのtool、network、filesystem権限を制限する
第4層：audit logとnegative testで、設定ではなく挙動を検証する

この4層は代替関係ではない。content exclusionは第2層を強くするが、第1層や第3層の責任を引き受けない。

限界と未確認事項

GitHubは除外判定のクライアント内部実装や、全コンテキスト供給元の評価順を公開していない。本稿の処理図には、公開挙動からの推論を含む。
対応表は2026年9月4日時点である。public previewのsurfaceとREST APIは変更され得る。
「除外された内容がモデル学習に使われるか」という論点と、「実行時contextへ入るか」は別問題である。本稿は後者だけを扱った。
間接的なsemantic informationが実際にどこまで渡るかは、IDE、拡張、language server、コード構造によって変わる。公式資料は完全な列挙や定量保証をしていない。
Business / Enterprise環境での実機検証結果ではなく、公式発表と公式仕様を分析した記事である。

まとめ

2026年9月2日のGAで、Copilot appとCLIにも管理者のcontent exclusionが届くようになった。だが、これは「指定ファイルをAIから完全に不可視にする魔法」ではない。

強い設計は、除外ルールの数ではなく、どの経路に適用され、どの経路に適用されないかを台帳化する。30分の伝播待ち、Agent mode非対応、symlink / remote filesystem、間接的な型情報まで含めてnegative testを作る。そこで初めて、content exclusionはチェックボックスから運用可能な信頼境界になる。

参考リンク

Content exclusions generally available in Copilot app and CLI - GitHub Changelog（2026-09-02）

Content exclusion for GitHub Copilot - GitHub Docs

Excluding content from GitHub Copilot - GitHub Docs

Reviewing changes to content exclusions for GitHub Copilot - GitHub Docs

REST API endpoints for Copilot content exclusion management - GitHub Docs

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up