GitHub Copilot 完全ガイド

GitHub Copilot CLIの企業管理プラグイン：Skills・Hooks・MCPを全社配布する設計

対象 / ポイント

対象: GitHub Copilot CLIを個人利用からチーム・企業標準へ広げたい開発基盤チーム、Platform Engineering、情シス、AI推進担当。

ポイント:

• enterprise-managed pluginsは、Copilot CLIの拡張を企業側で配布する仕組みである。
• Skills・Hooks・MCPを個人設定から全社標準へ移せる。
• いきなり全開放せず、標準プラグイン・監査・例外運用を分けて設計する。

2026年5月6日、GitHubはGitHub Copilot CLIのenterprise-managed pluginsをpublic previewとして公開した。¹ 重要なのは、プラグインが増えたことではない。 企業管理者が、Copilot CLIに入る拡張をまとめて配れるようになったことだ。

これまでSkills、Hooks、MCPは、便利だが個人設定に寄りやすかった。 開発者ごとに入っているスキルが違う。 危険コマンドを止めるHookも、あるリポジトリにはあるが別のリポジトリにはない。 MCPサーバーの設定も、手元のJSONに散らばる。

この記事の問いは1つだ。 GitHub Copilot CLIの企業管理プラグインを、全社AIエージェント運用の標準配布レイヤーとしてどう設計するか。

何が変わったのか

enterprise-managed pluginsで変わるのは、Copilot CLIの拡張を管理者が標準化できる点である。

GitHubの発表では、エンタープライズ管理者がCopilot CLIユーザー向けにプラグインを設定・配布できるようになったと説明されている。¹ 対象はCopilot BusinessまたはCopilot Enterpriseのライセンスを持つユーザーで、CLIが企業側の設定を自動的に取得して適用する。 設定ファイルは、企業の.github-privateリポジトリ配下に置く。²

最小構成はこの形だ。

{
  "extraKnownMarketplaces": {
    "company-plugins": {
      "source": {
        "source": "github",
        "repo": "OWNER/REPO"
      }
    }
  },
  "enabledPlugins": {
    "secure-copilot-cli@company-plugins": true
  }
}

extraKnownMarketplacesは、利用者に見せるプラグインマーケットプレイスを定義する。 enabledPluginsは、認証時に自動で有効化するプラグインを指定する。² つまり、管理者は「どこから入れてよいか」と「最初から入れるもの」を分けて制御できる。

この分離が大きい。 全員に必須のセキュリティHookは自動有効化する。 チーム別のRails、Terraform、Kubernetesスキルは社内マーケットプレイスから選ばせる。 配布と選択の境界を、企業側で決められるようになった。

プラグインは何を運べるのか

Copilot CLIのプラグインは、単なるコマンド追加ではない。 エージェントの振る舞いを形作る部品を、ひとつの配布単位にまとめる。

GitHub Docsでは、CLIプラグインに含められるものとして、 custom agents、skills、hooks、MCP server configurations、LSP server configurationsが挙げられている。³ この一覧を見ると、企業管理プラグインの本質が見える。 これは「便利機能集」ではなく、AIエージェントの作業環境を配るパッケージである。

配布するもの	役割	企業での使いどころ
Agent Skills	手順知識をオンデマンドで読ませる	リリース、障害調査、IaCレビュー
Hooks	ツール実行前後に検査・記録する	危険コマンド拒否、監査ログ、secret検査
MCP設定	外部ツールや社内データへ接続する	GitHub、チケット、ドキュメント、検証環境
Custom agents	役割別のエージェントを用意する	DB移行担当、セキュリティレビュー担当

個人設定でこれを配ると、すぐに崩れる。 ある人は古いHookを使い続ける。 別の人は本番DBに触れるMCPを追加してしまう。 チームごとにSkillの言葉遣いが違い、レビュー観点も揃わない。

企業管理プラグインは、このばらつきを減らす。 全員の手元を完全に同一にするというより、最低限そろえる層を作るための仕組みだ。

設計は3層に分ける

最初に決めるべきは、何を全社必須にし、何をチーム選択に残すかである。

全部を全社必須にすると、開発者の現場適合性が落ちる。 逆に全部を任意にすると、企業管理プラグインを入れる意味が薄い。 現実的には、3層に分ける。

層	配布対象	例	管理方針
Core	全員必須	危険操作Hook、監査ログ、社内基本Skill	enabledPluginsで自動有効化
Domain	部門・技術別	Terraform、Rails、データ基盤、モバイル	社内marketplaceで選択
Experiment	検証中	新しいMCP、外部ツール連携、PoC agent	限定チームで試す

Coreは、個人の好みに任せない。 たとえばrm -rf、秘密情報を含むファイル、会社指定外の外部送信を止めるHookは、標準プラグインに入れる。 Copilot agentsのHooksは、セッション開始、終了、ツール実行前後などのタイミングで動かせる。⁴ ここに監査と拒否の境界を置く。

Domainは、現場に選ばせる。 全社にKubernetesスキルを入れても、多くの開発者にはノイズになる。 必要なチームが社内マーケットプレイスから入れる形にすれば、発見可能性とコンテキスト効率を両立できる。

Experimentは、最初から標準にしない。 MCPは便利だが、接続先の権限とログ設計を間違えると、AIエージェントに見せるべきでない情報まで開く。 小さく試して、ログ、失敗例、撤退条件を見てからDomainかCoreへ昇格させる。

Skillsは「標準手順」、Hooksは「強制線」、MCPは「接続口」

Skills、Hooks、MCPを同じプラグインに入れられるからといって、同じ責任を持たせてはいけない。

Agent Skillsは、エージェントに「この仕事はこう進める」と教えるための手順知識である。 GitHub Docsは、skillsを「instructions, scripts, resources」のフォルダとして説明している。⁵ 社内では、リリース手順、障害一次対応、Terraform変更レビューのような反復業務に向く。

Hooksは、相談ではなく制御に使う。 GitHubのHooks解説では、tool executionの承認・拒否、secret scanning、監査ログなどの用途が示されている。⁴ つまり「守ってほしい手順」はSkillに書き、「破ってはいけない境界」はHookで止める。 ここを混ぜると、ガードレールがお願いになる。

MCPは、外部コンテキストとツールをCopilot CLIに渡す接続口である。 GitHub MCP serverはCopilot CLIに組み込まれており、追加のMCPサーバーは/mcp addまたは設定ファイルで追加できる。⁶ 社内MCPを配るなら、接続先、ツール一覧、認証方式、ログの責任者をセットで決める必要がある。

3つの役割はこう分けるとよい。

• Skill: 望ましい作業手順を教える
• Hook: 禁止・監査・検証を強制する
• MCP: 必要な情報源と操作先を渡す

この分担なら、Copilot CLIの振る舞いを説明しやすい。 レビュー時にも「なぜ止まったか」「なぜその資料を読めたか」「どの手順で進めたか」を分けて追える。

最小プラグインは小さく作る

最初の標準プラグインは、欲張らない方がよい。

いきなり全社の開発手順、全MCP、全Hookを入れると、失敗時の原因が見えなくなる。 まずは「安全にCopilot CLIを使い始めるためのCore」に絞る。 たとえば、この程度で十分だ。

secure-copilot-cli/
├── plugin.json
├── skills/
│   └── release-check/
│       └── SKILL.md
├── hooks.json
└── .mcp.json

plugin.jsonは配布単位のマニフェストである。 GitHub Docsでは、プラグインの最小要件としてルートのplugin.jsonが示され、任意でagents、skills、hooks、MCP設定を含められる。⁷ この構造なら、まず1つの手順、1つのHook、1つのMCP接続から検証できる。

運用で見る指標は、導入数より失敗の質だ。 Hookが止めた操作は妥当だったか。 Skillは古い手順を読ませていないか。 MCPは必要な情報だけを渡せているか。 この3点を見ないまま全社展開すると、標準化ではなく設定の押し付けになる。

既存記事との接続

この機能は、Copilot CLI単体の記事では終わらない。 SmartScope内では、既存のCopilot運用記事をつなぐハブになる。

すでに Agent Skillsガイド では、SKILL.mdを手順知識として扱う考え方を整理している。 Hooks完全ガイド は、ツール実行の制御と監査ログの設計に近い。 AGENTS.md統一管理ガイド は、複数AIツールで共通ルールを扱う文脈と相性がよい。

今回のenterprise-managed pluginsは、これらを個別テクニックから配布設計へ引き上げる。

既存テーマ	これまでの論点	今回の追加論点
Skills	どう書くか	どのSkillを全社配布するか
Hooks	どう止めるか	どのHookを必須にするか
MCP	どう接続するか	どの接続を誰に配るか
企業AI	どう導入するか	どう標準化し、監査するか

ここまで来ると、Copilot CLIは「個人の便利なターミナルAI」ではない。 企業がAIエージェントの実行環境を配るためのクライアントになる。

導入判断チェックリスト

enterprise-managed pluginsを使うべき組織は、すでにCopilot CLIを複数チームで使い始めている組織である。

まだ個人検証の段階なら、まずは手元でSkills、Hooks、MCPを試す方が速い。 一方で、複数チームに広がり始めたら、個人設定のまま放置すると後で回収が難しくなる。 次の5項目を満たすなら、企業管理プラグインを設計する価値がある。

• Copilot BusinessまたはCopilot EnterpriseでCLI利用者が増えている
• 共通で配りたいSkillが2つ以上ある
• 危険操作や外部送信をHookで止めたい
• MCP接続先の権限とログを管理したい
• 部門別に標準プラグインを分けたい

注意点もある。 この機能は2026年5月7日時点でpublic previewであり、GitHub Docsも変更可能性を明記している。² 本番標準にするなら、設定ファイルの差分レビュー、ロールバック方法、例外申請フローを先に用意する。

最後に見るべき指標は、プラグインの数ではない。 同じ仕事を、同じ安全境界で、同じ証拠を残して任せられるかである。 企業管理プラグインの価値は、Copilot CLIを賢くすることより、AIエージェントの仕事を組織で説明可能にすることにある。

まとめ

enterprise-managed pluginsは、Copilot CLIの拡張配布機能である。 ただし実務上の意味は、AIエージェントの作業環境を企業側で設計できることにある。

最初に配るべきものは、多機能な社内マーケットプレイスではない。 安全境界、最低限の手順、承認済みの接続先を小さく束ねたCoreプラグインである。 そこからDomainとExperimentへ広げると、標準化と現場適合性を両立しやすい。

関連記事

• GitHub Copilot Agent Skills ガイド
• GitHub Copilot Hooks完全ガイド
• GitHub Copilot CLI GA 調達構造分析
• 企業内AI活用
• MCP関連記事ガイド

---

1. Enterprise-managed plugins in GitHub Copilot CLI are now in public preview ↩↩

2. Configuring enterprise plugin standards for Copilot CLI ↩↩↩

3. About plugins for GitHub Copilot CLI ↩

4. About hooks ↩↩

5. About agent skills ↩

6. Adding MCP servers for GitHub Copilot CLI ↩

7. Creating a plugin for GitHub Copilot CLI ↩