GitHub Copilot Agent Pluginsを社内導入する前に：MCPと実行権限の確認5項目

先に結論です。plugin.jsonを読めても、それだけでMCPなし、読み取り専用、更新なしとは判断しません。

最初に行うのは、実アカウントへインストールしてCopilot sessionを始めることではありません。source、manifest、component、有効化設定、ロード順、hook、MCP、LSP、更新経路を静的に確認します。実行可能なcomponentを特定でき、読者環境で実効性を確認できる制御と人の承認で境界を設けられる場合だけ、低リスクの1件を試します。分からない場合は保留です。

この記事は、実アカウントへのインストール、MCP接続、hook実行、ファイル変更、外部送信を行っていません。公式仕様と、MASTER key株式会社・AX事業部による導入前の編集提案を分けて説明します。

まず業務側が決める4点

Level 2の導入判断で、業務側がmanifestの探索順や管理設定を実装する必要はありません。次の4点を決め、技術担当へ確認を渡します。

1. 初回対象を、顧客対応、請求、採用、権限変更、本番デプロイではない社内手順1件に絞る。
2. 顧客・従業員・個人情報、認証情報、秘密、本番リポジトリを使わない検証用リポジトリを分ける。
3. 業務責任者、repository責任者、Copilot管理担当のうち、確認を引き受ける人と停止担当を決める。
4. source、hookのcommand、MCPまたはLSPの設定、実効的な優先順位のどれかが分からなければ、インストール・session開始・実行を止める。

この4点がそろわない段階で全社導入へ進めないことも、導入判断です。

plugin.jsonだけでは導入判断にならない理由

[公式仕様] GitHub DocsのS1は、pluginを再利用可能なagent、skill、hook、MCP server configuration、LSP server configurationなどを含み得る導入可能なパッケージとして説明しています。各pluginがすべてを含むわけではないため、manifestと実ファイルの個別確認が必要です。

[公式仕様] S2では、plugin.jsonのcomponent path、marketplaceのplugin entry、source、version、ref、full SHA、manifestの探索場所、ロード順と優先順位を確認できます。marketplaceを使わない導入形態もあるので、marketplace.jsonを全導入形態の必須ファイルとは扱いません。

確認対象は、次の4層に分けます。

固定点は、sourceが信頼できること、更新後も安全であること、期待どおりの出力になることの証明ではありません。同じ対象を後から確認するための記録です。

導入前に見る5項目

次の5項目は、GitHubが全企業に要求する必須手順ではありません。[編集部提案] 少人数の社内導入で、技術確認と業務判断を結び付けるための確認カードです。

1. 出所・配布・固定点を記録する

[公式仕様] S1とS2によれば、導入元にはmarketplace、GitHub repositoryやsubdirectory、Git URL、local pathがあります。source typeによって確認できる欄は変わります。

指定がないこと自体を欠陥とは扱いません。何が指定され、何が未指定かを残します。

2. 宣言・別設定・ロード順を一覧にする

[公式仕様] S2では、manifestやcomponentに複数の探索場所と既定pathがあり、同名のagent、skill、MCP serverには優先順位があると説明されています。

技術担当へ渡す質問は、次の4つで構いません。

1. 表示されたファイルと設定から、hookのcommandを特定できるか。
2. MCPまたはLSPの設定、接続先、利用するtoolやdata sourceを特定できるか。
3. pluginのsourceと、指定されているversion・ref・SHAを特定できるか。
4. user・project・親ディレクトリ・管理設定を含む実効的な優先順位を説明できるか。

一つでも答えられなければ、インストール・session開始・実行を保留します。これは業務側が設定を実装する作業ではなく、導入判断を止めるための照会です。

3. 静的preflightと実行試験を分ける

[公式仕様] S3は、hookをagent実行中にcustom shell commandを動かせる仕組みとして説明し、command、cwd、env、timeout、secret logging、shell escaping、外部network callへの注意を示しています。

[編集部提案] 自然言語の依頼文は作業範囲を伝えるもので、アクセス制御そのものではありません。hook、MCP、LSPに対する実効的な制御の有無は、実際に使うclient、plan、設定、実行経路で技術担当が確認します。

静的preflightでは、実行前に次を整理します。

1. source、該当するmarketplace entryまたはmanifest、plugin.json、全componentを記録する。
2. hookのcommand・cwd・env・timeout、MCP・LSPの接続先、参照するtoolやdata sourceを一覧化する。
3. enabledPlugins、extraKnownMarketplaces、managed settings、user・project・親ディレクトリの設定を確認し、ロード順と重複名を整理する。
4. client、plan、organization policy、MCP allow・deny、管理設定の適用範囲を確認する。

実行試験へ進めるのは、実行可能なcomponentを特定し、次のいずれかを確認できた場合だけです。

• hook・MCP・LSPが不在または無効である。
• 読者環境で、実効性を確認できる制御と人の承認によって、操作・接続・変更の境界を設けられる。

どちらも確認できなければ、試行せず保留します。

4. 管理設定は確認対象であって安全保証ではない

[公式仕様] S4からS6は、Enterpriseでのagent管理、plugin・marketplace管理、MCP allow・deny、managed settingsを説明しています。S5で確認できる項目には、allowedMcpServers、deniedMcpServers、permissions.disableBypassPermissionsModeがあります。S6は、対応clientで利用可能なmarketplaceや自動インストールするpluginをmanaged-settings.jsonで定義できると説明しています。

Enterprise向けの設定が、すべての中小企業の契約、client、plan、organizationで利用できるとは限りません。自社では次を確認します。

1. 契約と利用clientで、その設定が使えるか。
2. organizationまたはEnterprise管理者が誰か。
3. plugin、marketplace、MCPにallow・deny方針があるか。
4. 管理設定を誰が変更できるか。
5. 承認、停止、監査ログの確認担当が決まっているか。

設定が存在することだけで、個別pluginの内容、接続先、出力、業務上の適切性が審査済みになるわけではありません。

5. 更新・自動導入・撤去を最初に書く

[公式仕様] S2はpluginのupdate、enable、disable、uninstallを説明しています。trusted working directoryでsessionを開始した際のfirst-party plugin更新や、extraKnownMarketplacesのautoUpdate: trueにも条件と適用範囲があります。repository-level設定で追加marketplaceの自動更新を有効化できるとは扱いません。

[編集部提案] 更新または自動導入の前後で、次を記録します。

1. manifest、該当するmarketplace entry、全component、指定されているversion・ref・SHA。
2. 組み込みplugin、追加marketplace、autoUpdate、managed settingsのうち関係する経路。
3. hook、MCP定義、LSP定義、接続先、file write・network・credential・外部送信の差分。
4. 検証用リポジトリでの期待結果、実際の出力、操作要求、変更・通信の有無。
5. 確認者、承認者、保留または撤去の判断。

静的preflightを通過してから1件だけ試す

ここからはMASTER key側の編集部提案です。GitHubの必須手順や安全保証ではありません。次は仮想例であり、実施済みの事例ではありません。

検証用リポジトリに、架空の部署名と数値だけで作ったREADMEを1つ置きます。たとえば、週次報告で確認する項目を記した短い手順です。顧客名、従業員情報、個人情報、認証情報、秘密、本番リポジトリは使いません。

業務側は、期待する出力と、初回に許可・禁止・要承認とする操作を整理します。技術担当は静的preflightでsource、component、設定の適用範囲、ロード順、接続先を確認します。確認できない項目があれば、ここで止めます。

条件を満たした場合だけ、次のように限定して試します。

手順書から、確認漏れの候補を3件まで抜き出し、それぞれの根拠箇所を示してください。ファイル変更、command実行、外部接続、外部送信はしないでください。

この依頼文は期待する作業範囲を示すだけです。技術担当が実効的な制御を確認し、人が必要な操作を承認できる場合にだけ試行します。記録するのは、期待した出力、実際の出力、実効構成、操作要求、人の確認、採用・保留・撤去の判断です。

ここで止める条件

次のどれかに当てはまる場合、全社展開や本番利用へ進めず、保留または撤去にします。

• source、必要な所有者情報、該当するmarketplace entryまたはmanifestを確認できない。
• 指定されているversion、ref、full SHAを確認できない。
• hookのcommand、MCPまたはLSPの設定、実効的な優先順位を特定できない。
• MCPやLSPの接続先、tool、data sourceを人が確認できない。
• 実行可能なcomponentを特定できない。
• 実効性を確認できる制御と人の承認で、操作・接続・変更の境界を設けられない。
• 自動更新または自動導入の対象、適用範囲、確認者、承認者、保留方法が決まっていない。
• 管理者、業務責任者、承認者、停止・撤去担当が決まっていない。
• 顧客対応、請求、採用、人事評価、本番deploy、権限変更を初回対象にしようとしている。
• 実在の秘密、個人情報、本番資格情報を入力しないと試せない。
• 予期しない書き込み、command、通信、外部送信が出たが、止める手順がない。

未評価は安全と同じではありません。分からない項目が残る候補は、確認できるまで保留します。

採用・保留・撤去を分ける

• 採用候補：低リスクの1業務に限定し、宣言・配布・有効化・実効構成、接続、権限、承認、更新・自動導入ゲート、撤去を記録できた。継続範囲は記録した業務から広げない。
• 保留：source、設定の適用範囲、接続、停止方法、ロード順、更新差分、承認のどれかが未確認。追加確認の担当と期限を決める。
• 撤去：予期しない操作・通信が発生した、承認前に有効化・実行された、または停止・uninstallを人が確認できない。記録を残してdisableまたはuninstallを行い、残存設定を確認する。

採用候補は、GitHubの安全性や業務成果の証明ではありません。確認できた範囲で限定的に続ける社内判断です。

このチェックで分かること、分からないこと

分かるのは、候補の構成要素、配布元、有効化経路、ロード順、接続先、実行・書き込みの可能性、更新差分、承認者、停止・撤去方法を整理できたかどうかです。

一方で、このチェックだけでは、自社環境での利用可否、第三者pluginやMCP serverの安全性、管理設定の実際の適用、日本語の出力品質、業務成果、検索需要、MASTER key株式会社やAX事業部の認知・問い合わせ・顧客成果は分かりません。

AIに任せる範囲を広げる前に、誰が静的に確認し、どこで実行を止め、どう戻すかを1件分だけ記録する。その次の一歩から始めます。

参照した公式資料

• S1: About GitHub Copilot plugins
• S2: GitHub Copilot CLI plugin reference
• S3: About hooks for GitHub Copilot
• S4: Agent management for enterprises
• S5: Enterprise managed settings reference
• S6: About enterprise-managed plugin standards
• S7: Creating a plugin for GitHub Copilot CLI

公式Docs、対象client、plan、組織設定は更新され得るため、実際に利用する前に自社環境で再確認してください。