目次
GitHub CopilotへMCPサーバー、カスタムスキル、エージェント、プラグインを追加すると、開発者ができることは増えます。一方で、管理者が「何を許可したか」と「実際に何が使われたか」を別々の画面や曖昧な集計で管理していると、使われていない広い権限や、把握していない接続先が残りやすくなります。
GitHubは2026年10月22日、Copilot BusinessとCopilot Enterpriseに関する二つの変更を公表しました。一つは、未設定の一般提供機能へグローバル既定ポリシーを適用する変更です。もう一つは、Copilot利用メトリクスで組織独自のスキル、カスタムエージェント、MCPサーバー、スラッシュコマンド、プラグインを設定名で識別できるようにした変更です。
本稿は2026年10月23日にGitHub ChangelogとGitHub Docsを確認したAI×セキュリティの導入解説です。脆弱性や侵害事件の速報ではありません。GitHubが提供する機能と、本サイトが提案する運用手順を区別しながら、許可、観測、見直しを一つの管理サイクルにする方法を整理します。
スポンサーリンク
変わったのは有効化と利用状況を結び付けやすくなったこと
GitHub Changelogの既定ポリシー一般提供告知によると、グローバル既定ポリシーの適用は10月22日から26日にかけて段階的に行われます。対象は「Features & clients」と「MCP servers in Copilot」にある適格な一般提供機能です。未設定の項目は、Enabled、Disabled、Let organizations decideのいずれかとして定めた既定値に従います。
明示的に有効または無効を選んだ設定は維持され、プレビュー機能は原則としてオプトインのままです。今回の適用は一度きりで、適用後にグローバル既定値を変えても、すでに個別状態が付いた機能は自動で追随しません。したがって「既定を無効にしたから過去に有効になった機能も閉じる」とは考えず、個別設定を読み直す必要があります。
同日のGitHub Changelogの利用メトリクス更新では、従来otherやcustomへまとめられていた組織独自の拡張について、設定名をレポートへ出せるようになりました。対象配列はtotals_by_skill、totals_by_custom_agent、totals_by_mcp、totals_by_slash_cmd、totals_by_pluginです。各一覧は1レコード当たり最大25件へ拡張され、それを超える活動は引き続きotherへ集約されます。
本サイトの分析では、二つの変更を別々の管理機能として終わらせないことが重要です。既定ポリシーは入口を決め、利用メトリクスは利用傾向を観測します。ただし、メトリクスは権限の内容や操作結果を証明する監査ログではありません。許可した拡張の台帳、実行時の監査記録、定期的な利用見直しを組み合わせて初めて、AI拡張の統制に使えます。
最初に未設定をゼロへ近づける
GitHub DocsのDefault availability解説では、企業レベルの状態をEnabled everywhere、Disabled everywhere、Let organizations decideとして説明しています。組織側へ委任した場合は、組織の既定値と個別設定が次の判断になります。MCPの利用を企業で一括して許すのか、組織ごとに決めるのかで責任者も変わります。
注意したいのは、グローバル既定を「便利な自動更新」として扱うと、一般提供へ移った機能が審査を経ずに有効になる可能性がある点です。新機能をすぐ試したい開発組織と、顧客データや本番資格情報を扱う組織では、同じ既定値が適切とは限りません。企業全体の基準をDisabled everywhereまたは組織委任にし、低リスクの組織だけ明示的に有効化する方法が考えられます。
導入時にはAI Controls → Copilotで、未設定の件数に加え、「Features & clients」以外のページにあるMCPサーバーとコードレビューを含む関連設定を保存します。2026年10月23日の確認時点では、Docsに適用前の説明が一部残る一方、日付付きChangelogは10月22日から26日までの段階適用を案内しています。画面に表示された状態を正とし、告知だけから自社への反映完了を推測しないでください。
スポンサーリンク
利用メトリクスで分かることと分からないこと
| 確認対象 | メトリクスで確認できること | 別の証拠が必要なこと |
|---|---|---|
| MCPサーバー | 設定名と利用回数の傾向 | 接続URL、ツール一覧、権限、送信データ |
| カスタムスキル | どの名前のスキルが使われたか | スキル本文、実行コマンド、配布元、版 |
| カスタムエージェント | 利用の有無と利用者層 | 指示、利用ツール、承認、操作結果 |
| プラグイン・コマンド | 採用と定着の傾向 | 外部通信、秘密情報の扱い、変更履歴 |
名前が表示される対象には条件があります。GitHubの告知では、Copilot CLIの対話・prompt mode、GitHub Copilot app、JetBrainsなどのACP統合、Copilot SDKが対象です。prompt mode、アプリ、ACP統合にはCopilot CLI 1.0.97以降、Copilot SDKには1.0.21以降が必要とされています。SDKを使うIDE体験は名前を報告しますが、IDE内蔵チャットのテレメトリーでは名前が報告されないと説明されています。
また、設定名は前後の空白を除いて128文字まで報告され、ファイルパスのように見える名前はotherまたはcustomに残ります。古いクライアントや遮断されたテレメトリーによる過少計上もあり得るため、利用回数を課金や違反の厳密な証拠にしてはいけません。今回の公開後に処理されたレポート日から名前が現れ、過去のotherが遡って分解されるわけでもありません。
Copilot usage metrics REST APIの公式資料では、メトリクスAPIを使うために企業のCopilot usage metricsポリシーをEnabled everywhereへ設定する必要があるとしています。企業レポートには日次と最新28日、組織レポートにも日次と28日があり、取得権限も企業所有者、請求管理者、許可されたカスタムロールなどに限定されます。レポートの取得用URLは期限付き署名URLなので、定期処理では取得時刻と保存先も設計します。
許可リストと利用実績を一つの台帳へまとめる
本サイトでは、設定名だけでなく安定した内部IDを割り当てた拡張台帳を作ることを提案します。名前は利用者に分かりやすい一方、変更や重複が起きます。台帳には種別、表示名、所有チーム、配布元、承認日、許可組織、接続先、要求権限、扱うデータ、緊急停止方法、最終利用日、次回見直し日を記録します。
- 許可されているのに長期間使われていない拡張は、必要性を再確認して停止候補にする
- 利用実績があるのに台帳にない名前は、導入経路と所有者を調査する
- otherが増えた場合は、25件上限、名前形式、クライアント版、テレメトリー遮断を切り分ける
- 名前変更は旧名、新名、変更日を残し、突然の新規拡張と区別する
- 利用ゼロを安全の証拠にせず、権限と接続自体が残っているかを別に確認する
利用者単位のレポートを扱う場合は、閲覧者と利用目的も決めます。名前付きのスキルやMCP利用は、チームの作業内容を推測できる場合があります。必要以上に個人の順位付けへ使わず、未承認拡張の検知、導入支援、廃止判断といった目的を明示し、保持期間を限定します。GitHubも設定名を組織外へ共有する前に確認するよう案内しています。
スポンサーリンク
30日で回す導入手順
1日目に既定値と個別設定を保存する
企業と組織の既定ポリシー、未設定項目、明示的な有効・無効、MCPサーバーの設定をエクスポートまたは記録します。段階適用期間中は、同じ項目を翌日にも確認し、意図しない変更があれば個別設定で固定します。画面のスクリーンショットだけでなく、設定名と状態を検索できる形式で残します。
最初の7日で台帳と名前を合わせる
現在許可しているスキル、MCP、エージェント、プラグインを台帳へ登録し、メトリクスに現れる設定名と対応付けます。意味のない略称や個人名だけの名前は、所有者と用途が分かる命名規則へ変更します。ただし改名がレポート上の別項目として現れる可能性を考え、変更日を残します。
14日目に例外と欠測を調べる
利用実績と台帳を比較し、未承認名、otherの増加、想定より少ない利用を確認します。ここで「使われていない」と断定せず、対応クライアント版、IDE内蔵チャットの除外、テレメトリーの到達を調べます。監査ログやMCPサーバー側のアクセスログと時刻・利用者・接続名を突き合わせ、メトリクスの限界を把握します。
30日目に権限を縮小して再承認する
継続利用する拡張は、実際に使うツールとデータだけへ権限を絞ります。不要な拡張はポリシーで無効化し、サーバー側のトークンや接続許可も失効させます。Copilot側の表示を消しただけでは下流サービスの資格情報が残る可能性があるため、入口と接続先を両方閉じます。
メトリクスをセキュリティ監査ログと誤解しない
totals_by_mcpに名前が出ても、どのツールがどの引数で呼ばれ、何が返り、変更が成功したかまでは分かりません。機密データの送信や本番変更を追跡するには、MCPサーバー、対象API、リポジトリ、CI側の監査ログが必要です。相関IDを付け、利用者、拡張ID、ツール、対象資産、結果、承認を結び付けます。秘密情報や本文全体を無制限にログへ残さない設計も必要です。
MCPの認証・認可境界は「MCPが接続できれば安全？トークンの宛先と権限を確認する」で整理しています。今回の利用メトリクスは、同記事で扱うトークンの宛先、スコープ、失効を代替しません。どの接続が使われたかを把握する補助情報として組み合わせてください。
また、モデルと機能の既定値は別の管理対象です。「Copilotのモデル廃止にどう備える？ポリシーAPIで移行を管理」はモデルの許可と移行を扱っています。今回の変更は機能とMCPの既定値、利用中のカスタマイズの可視化が中心です。モデルを制限していても、広い権限のMCPが許可されていれば実行範囲は狭まりません。
導入判断のチェックリスト
- Copilot BusinessまたはEnterpriseの対象組織か
- グローバル既定値と組織への委任範囲を決めたか
- 未設定の一般提供機能とMCPポリシーを確認したか
- 利用メトリクスを有効にし、閲覧権限と保存先を限定したか
- 対応クライアント版と名前が報告されない経路を把握したか
- 拡張台帳と名前付きメトリクスを照合できるか
- 権限、操作結果、失効を別の監査記録で確認できるか
- 30日後の再承認と不要接続の停止日を決めたか
今回の更新で、GitHub Copilotの拡張を完全に自動監査できるようになったわけではありません。ただし、未設定の機能がどう有効になるかを事前に決め、実際に使われたカスタマイズを名前で追う材料は増えました。まず既定値を明示し、台帳とメトリクスの差を調べ、権限と操作ログを別に検証する。この順番なら、AI開発を止めずに接続先と実行範囲を狭く保てます。
