GitHub Copilot Extensions終了｜MCP・Agent Pluginsへの移行【2026年版】

GitHub Appとして作るGitHub Copilot Extensionsは、2025年11月10日で完全に無効化されました。以後、GitHub App型の拡張機能を@拡張機能名で呼んでも、単なるプレーンテキストとして扱われます。一方で「Copilot Extensions」と総称されてきたもののうち、VS Code側にインストールするクライアントサイド拡張は終了しておらず、@での呼び出しも従来どおり動きます。同じ名前で語られてきた2つの仕組みのどちらが終わり、どちらが残ったのか。そして後継となるMCPサーバーとAgent Plugins 1.0をどう書くのかを、公式アナウンスと仕様書、実際に動かしたコードの出力で確認していきます。

まとめ

• 終了したのはGitHub App型のCopilot Extensions。2025年11月10日 11:59 PM PSTに全機能が無効化されました。
• 終了していないのはVS Codeのクライアントサイド拡張。公式アナウンスは「remain fully supported」と明記し、@呼び出しも維持されると述べています。
• 後継はMCPサーバー。旧拡張機能はCopilotのチャット内でしか動きませんでしたが、MCPなら他のMCP対応ホストからも同じサーバーを呼べます。
• 2026年8月6日にAgent Plugins 1.0.0が公開され、8月12日からVS Code・Copilot CLI・Copilot SDK・Copilot appが対応。全Copilotプランが対象です。
• MCPの設定ファイルはVS Code・Copilot CLI・Agent Pluginsで3形式に分かれています。コピー流用は動きません。

GitHub App型Copilot Extensionsのサンセット日程と影響範囲

新規作成停止から完全無効化までの経過

GitHubは2025年9月24日付のChangelog「Sunset notice: GitHub App-based Copilot Extensions」で終了を告知しました。告知と同時に新規作成が止まり、約7週間後に機能そのものが消えています。

ブラウンアウトは一時的に停止して影響を可視化する期間で、本番停止の前に自社の業務フローが壊れるかどうかを検知できるよう置かれています。無効化後の挙動について、公式アナウンスは「@mentions of retired extensions will be treated as plain text」と述べています。エラーが出るのではなく、拡張機能を呼んだつもりの文字列がそのままLLMへのプロンプトに混ざるだけです。気づきにくい壊れ方でした。

終了していないVS Codeクライアントサイド拡張

ここが最も誤解されている点です。同じChangelogは、クライアントサイドのVS Code Copilot拡張について「remain fully supported」と明記し、さらに「Existing VS Code extensions will remain unchanged and can still be invoked with an @mention.」と続けています。VS Code拡張は@で呼べます。プレーンテキスト化されるのはGitHub App型だけです。

VS Code拡張としてチャット参加者を実装するChat Participant APIにも、2026年8月時点の公式拡張ガイドに廃止告知はありません。vscode.chat.createChatParticipantでチャット参加者を作り、package.jsonのchatParticipantsコントリビューションポイントで登録する書き方はそのまま使えます。ただしVS Code公式は、自律的なエージェント動作の中で呼ばれてほしい機能なら、チャット参加者ではなく言語モデルツールかMCPサーバーとして実装することを勧めています。会話全体を自分で受け持ちたいならChat Participant、エージェントに部品として使わせたいならMCP、という住み分けです。

Marketplace掲載アプリの扱いと、旧ドキュメントの現在地

Copilot Extensions機能しか持たないGitHub Appは、GitHub Marketplaceから削除されました。他のGitHub App機能も備えたハイブリッド構成のアプリは、11月10日 11:59 PM PSTまでにアプリ設定でCopilot Extensionの構成を無効化すればMarketplaceに残せる扱いでした。自社アプリが消えたか残ったかは、この期限までに設定を触ったかどうかで決まっています。

公式ドキュメントも整理されました。2026年8月17日時点で/copilot/building-copilot-extensions/about-building-copilot-extensionsは301リダイレクトでMCPの解説ページへ着地し、/copilot/reference/copilot-extensionsのような個別ページは404を返します。ブックマークが飛ぶ先が変わっているだけで、ページが生きているわけではありません。

後継となるMCPサーバーの最小実装と実測した応答

GitHubが示した移行先はMCP（Model Context Protocol）サーバーです。サンセット告知は旧方式の限界を「GitHub Copilot Extensions only work within GitHub Copilot chat.」と説明し、移行先の利点を「Build your server once and it works with GitHub Copilot, Claude Code, and any other MCP-compatible host app」と述べています。チャット専用だった作り込みを、ホストを問わず再利用できる形に置き換えるという整理です。

Node.jsで動かす最小のMCPサーバー

社内のリリースノートを版番号で引くツールを1つだけ持つサーバーを書きます。以下はNode v26.5.0、@modelcontextprotocol/sdk 1.30.0（npm latest、2026年7月27日公開）、zod 4.4.3で実際に起動して応答を確認したコードです。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "release-notes", version: "1.0.0" });

server.registerTool(
  "get_release_note",
  {
    title: "リリースノート取得",
    description: "社内リリースノートを版番号で引く",
    inputSchema: { version: z.string().describe("例: 2026.8.0") },
  },
  async ({ version }) => ({
    content: [{ type: "text", text: `${version}: 認証基盤をOIDCへ移行。破壊的変更2件。` }],
  })
);

await server.connect(new StdioServerTransport());

実装量はこれだけです。GitHub App型の拡張機能では、エージェント用のHTTPエンドポイントを公開し、GitHub Appの登録と権限設定を通す必要がありました。stdio転送のMCPサーバーは標準入出力で会話するローカルプロセスなので、サーバーを公開する作業自体が消えます。

tools/listとtools/callの実際の応答

同じSDKのクライアントから接続し、ツール一覧と呼び出し結果を取得した出力です（inputSchemaの入れ子は読みやすさのため1行に畳んでいます）。

serverInfo: {"name":"release-notes","version":"1.0.0"}
tools: [
 {
  "name": "get_release_note",
  "title": "リリースノート取得",
  "description": "社内リリースノートを版番号で引く",
  "inputSchema": {
   "type": "object",
   "properties": { "version": { "type": "string", "description": "例: 2026.8.0" } },
   "required": [ "version" ],
   "$schema": "http://json-schema.org/draft-07/schema#"
  },
  "execution": { "taskSupport": "forbidden" }
 }
]
call: {"content":[{"type":"text","text":"2026.8.0: 認証基盤をOIDCへ移行。破壊的変更2件。"}]}

zodスキーマがJSON Schema draft-07へ変換され、requiredまで含めてクライアントへ渡っています。エージェントがこのツールを呼ぶかどうかはdescriptionと引数名だけを手がかりに判断するため、説明文は人間向けの体裁ではなく、呼ぶべき場面が読み取れる文にしておく必要があります。SDK 1.30.0ではexecution.taskSupportも応答に含まれ、既定はforbiddenです。

引数不足時のisError返却とtry/catchの落とし穴

MCPサーバーの実装で最も見落とされるのがエラーの返り方です。必須引数versionを省いて呼び出しても、クライアント側では例外がスローされません。

missing-arg result: {"content":[{"type":"text","text":"MCP error -32602: Input validation error: Invalid arguments for tool get_release_note: Invalid input: expected string, received undefined at version"}],"isError":true}
unknown-tool: {"content":[{"type":"text","text":"MCP error -32602: Tool nope not found"}],"isError":true}

存在しないツール名を指定した場合も同じ形です。isError: trueが立った通常の結果として返るため、try/catchだけで組んだ呼び出し側は失敗を検知できません。エージェントから見ると、これは失敗ではなく「エラー文という文字列を答えとして受け取った」状態です。引数名を勝手に変えて再試行したり、エラー文を根拠に作り話をしたりする原因がここにあります。呼び出し側ではisErrorを必ず分岐してください。

VS CodeとCopilot CLIでの設定ファイルの違い

VS Codeの.vscode/mcp.json

VS Codeでは、リポジトリ直下の.vscode/mcp.jsonにサーバーを書きます。GitHub公式ドキュメントが載せている最小構成は次の形です。

{
  "inputs": [
    { "type": "promptString" }
  ],
  "servers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    }
  }
}

APIキーのような秘密情報はinputsで受け取り、設定ファイルに直書きしません。ただし公式例は最小形でidが省かれており、実際に${input:api-key}のように参照するには{ "id": "api-key", "type": "promptString", "description": "APIキー", "password": true }のように識別子を付ける必要があります。サーバーが独自のプロンプトを提供している場合は、チャットから/mcp.servername.promptnameという書式のスラッシュコマンドで呼び出せます。リポジトリのコンテンツのように、サーバーがデータそのものを公開する仕組みは「リソース」と呼ばれ、ツール呼び出しとは別枠です。

Copilot CLIは.vscode/mcp.jsonを読まない

同じMCPでも、ターミナル側は設定ファイルが別です。公式ドキュメントは「The .vscode/mcp.json file for VS Code is not read by Copilot CLI. It uses the unsupported top-level key servers.」と明記しています。GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説で扱っているCopilot CLIが読むのは、作業ディレクトリからリポジトリルートまでの.mcp.json、またはリポジトリに commit して共有する.github/mcp.jsonです。

{
  "mcpServers": {
    "playwright": {
      "type": "local",
      "command": "npx",
      "args": ["@playwright/mcp@latest"],
      "env": {},
      "tools": ["*"]
    },
    "context7": {
      "type": "http",
      "url": "https://mcp.context7.com/mcp",
      "headers": { "CONTEXT7_API_KEY": "YOUR-API-KEY" }
    }
  }
}

ローカルプロセスを起動する場合のtypeは"local"です。後述するAgent Pluginsでは同じ用途の値が"stdio"になるため、ここは移し替えのたびに書き換えが必要になります。

@mentionからツール参照・自律呼び出しへの操作変化

操作感はGitHub App型の拡張機能から変わりました。旧来は@拡張機能名で名指しして会話を委ねる形でしたが、MCPではIDE上で#を使って個別のツールを参照します。加えてエージェントモードやCopilotのクラウドエージェントは、指示の文脈から必要と判断したツールを自分で呼びます。名指しが必須ではなくなった代わりに、ツールの説明文の質が呼ばれるかどうかを左右します。エージェント側の挙動はGitHub Copilotエージェントモードの使い方｜Ask・Edit・Agentの違いと有効化・料金【2026年版】で整理しています。

Agent Plugins 1.0によるスキルとMCPサーバーの同梱

MCPサーバーの配布方法を標準化したのがAgent Plugins 1.0.0です。仕様は2026年8月6日に公開され、GitHubは8月12日のChangelogで「Support is generally available in VS Code, Copilot CLI, the GitHub Copilot SDK, and the GitHub Copilot app, on all Copilot plans.」と告知しました。既存のCopilotプラグインは移行作業なしでそのまま動きます。

仕様リポジトリのMAINTAINERS.mdに記載されたコアメンテナは、Clare Liguori（Amazon）、Roshan Sadanani（Cursor）、Harald Kirschner（Microsoft）、Gav Verma（OpenAI）、Jonathan Hefner（Vercel）の5名で、Lead Core MaintainerはJonathan Hefnerです。GitHubのChangelogは同じ8月6日にGoogleもコアメンテナとして参加したと述べており、この記事の確認時点（2026年8月17日）ではMAINTAINERS.mdに未反映でした。Technical Charterには「No single vendor may control a majority of Core Maintainer seats」と書かれています。GitHub App型の拡張機能が1社の都合で終了した経緯を踏まえると、この一文が後継フォーマットに付いている意味は小さくありません。

plugin.jsonのclosed schemaと必須フィールド

プラグインはアーカイブではなくディレクトリで、ルートにplugin.jsonを置きます。マニフェストのスキーマはclosedで、許可されるトップレベルフィールドは10個だけです。

$schemaの値は自由なURLではなく、1.0.0ではhttps://agent-plugins.org/schemas/1.0.0/plugin.schema.jsonという正準識別子でなければなりません。しかもクライアントは読み込み時にスキーマを取得してはならないと規定されており、この値はダウンロード先ではなくローカルの検証ルールを選ぶための識別子です。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "release-notes",
  "version": "1.0.0",
  "description": "社内リリースノートをCopilotから引く",
  "license": "MIT",
  "extensions": {
    "com.github.copilot": {}
  }
}

ディレクトリ構成は、ルートのplugin.jsonに加えて、スキルを入れるskills/（直下の各サブディレクトリにSKILL.mdを置く）、MCPサーバー設定のmcp.json、クライアント固有ファイルを入れる逆ドメイン名のディレクトリという並びです。GitHub Copilot向けの追加ファイルはcom.github.copilot/に置きます。リポジトリ共通のルールをCopilotへ読ませるcopilot-instructions.mdとは？書き方・配置場所とAGENTS.md・.instructions.mdの違いを解説のような設定ファイルとは別の階層なので、混同しないでください。

mcp.jsonのtype必須要件と、3形式の差分

MCPサーバーの設定はplugin.jsonにインラインで書けません。仕様は「MCP configuration MUST NOT be declared inline in plugin.json」と定め、プラグインルートのmcp.jsonだけを読み込み対象にしています。トップレベルに置けるのは$schemaとmcpServersの2つのみです。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "release-notes": {
      "type": "stdio",
      "command": "node",
      "args": ["./server.mjs"]
    }
  }
}

ここまでに出てきた3つの設定ファイルは、キーもtypeの値も揃っていません。

公式スキーマをajvで読み込み、typeを落とした設定を検証すると次のように弾かれます。

plugin.json => valid
mcp.json => valid
mcp.json(type欠落) => INVALID: data/mcpServers/x must have required property 'type', data/mcpServers/x must have required property 'type', data/mcpServers/x must have required property 'url', data/mcpServers/x must NOT have additio
plugin.json(未知フィールドmain) => INVALID: data must NOT have additional properties

typeが1つ欠けただけで複数のメッセージが並ぶのは、サーバー設定がoneOfで複数の転送方式に分岐しており、どの分岐にも当てはまらないと全分岐分のエラーが返るためです（urlを要求しているのはHTTP系の分岐）。上の出力はerrorsTextを200文字で切っているので末尾が欠けています。原因を1行で読みたい場合はerrors[0].messageだけを表示させてください。

4行目のplugin.json(未知フィールドmain)は、仕様を読んでから見ると解釈に注意が要ります。仕様§5.2は未知のトップレベルフィールドについて「it does not conform to the schema」と述べたうえで、「Clients MUST report and ignore each unknown field and MUST continue loading the plugin」と続けます。つまりスキーマ上は違反、クライアント実行時は報告して継続という二段構えが意図された設計です。npmのpackage.jsonの癖でmainを書き足すと、Copilotでは動くのにCIのスキーマ検証だけが赤くなる、という現象がここから生まれます。

commandの制約も見落としがちです。シェルコマンド文字列ではなく単一の実行可能トークンでなければならず、書けるのは実行ファイル名そのものか、./で始まるプラグイン相対パスに限られます。node server.mjsとまとめて書くことはできず、引数はargsへ分けます。パッケージに実行ファイルを同梱する場合は相対パス指定が必須です。

配布先のマーケットプレイスと企業側の統制

作ったプラグインの配布先として、GitHubは「Awesome Copilot marketplace」を挙げており、VS Code・Copilot CLI・Copilot appでは既定で利用できます。企業側の制御はmanaged-settings.jsonで行い、enabledPluginsで特定プラグインの自動導入やブロック、extraKnownMarketplacesで配布元の追加、strictKnownMarketplacesで管理下のマーケットプレイスのみに限定できます。この管理設定はCopilot BusinessとEnterpriseの顧客向けで、VS Code、Copilot CLI、GitHub Copilot app、Copilotクラウドエージェントに適用されます。Python側の実装で揃えたい場合はFastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】が参考になります。

移行を急がなくてよい場合と、MCPにすべきでない場合

GitHub App型の拡張機能を持っていたなら選択の余地はなく、すでに動いていません。判断が必要なのは、これから何かを作る側です。

会話の流れを設計したいならChat Participant

MCPサーバーにすべきでない代表例が、会話の流れ全体を自分で設計したいケースです。MCPのツールはエージェントが必要に応じて呼ぶ部品なので、どの順番で何を聞くかを作り手が決められません。ウィザード形式の対話や、途中で確認を挟む承認フローを作りたいなら、VS CodeのChat Participantとして実装するほうが要件に合います。公式ガイドが両者を並べて説明しているのは、上位互換の関係ではないからです。

規約や知識の共有だけならMCPサーバーは過剰

コーディング規約や技術スタックを毎回読ませたいだけなら、プロセスを起動するMCPサーバーではなく、Markdownの指示ファイルやAgent Pluginsのskills/で足ります。MCPサーバーは外部システムへの問い合わせや副作用のある操作、つまりモデルが自力では持てない情報と権限を扱うために使ってください。テスト生成のようにCopilot単体で完結する作業に外部ツールを噛ませる必要はなく、その領域はGitHub Copilotでテストコードを自動生成する方法｜/testsコマンドと活用のコツ【2026年版】で扱っている標準機能で足ります。

Chat took too long to get readyの切り分け手順

拡張機能まわりで頻出する「Chat took too long to get ready. Please ensure you are signed in to GitHub and that the extension GitHub.copilot-chat is installed and enabled.」というエラーは、Copilot Extensionsの終了とは無関係です。VS Code本体側でCopilot Chat拡張の初期化が完了しない事象で、microsoft/vscodeのIssue #282945（2025年12月12日起票、クローズ済み）とIssue #298878（2026年3月3日起票、オープン）に報告があります。

#282945のトレースログでは、エラーと同時に次の状態が記録されています。

{"agentActivated":true,"agentReady":false,"languageModelReady":false,"toolsModelReady":false}

拡張自体は起動しているのに、言語モデルとツールの準備が終わっていません。ただしこのIssueのログにはNode fetch failed with status: 429 Too Many Requestsも並んでおり、レート制限が絡んだケースです。#298878のほうはサインイン済み・拡張導入済み・有効化済みでも再現すると報告されており、原因が同一とは限りません。まずログを開いて、429が出ているのか、準備フラグが立たないまま止まっているのかを分けてください。

Issueの報告とは別に、拡張機能の登録情報が壊れている場合に有効な一般的な手当てとして、強制再インストールがあります。

code --install-extension github.copilot-chat --force

実行後にVS Codeを再読み込みします。これでも同じ状態が続くなら、拡張機能の一覧ファイルに残った古いエントリが再インストールを妨げていることがあります。macOSとLinuxは~/.vscode/extensions/extensions.json、Windowsは%USERPROFILE%\.vscode\extensions\extensions.jsonを開き、identifier.idがgithub.copilot-chatのオブジェクトを削除してから入れ直してください。

よくある質問

GitHub Copilot Extensionsは今も使えますか？

GitHub Appとして構築されたCopilot Extensionsは2025年11月10日 11:59 PM PSTに全機能が無効化され、使えません。GitHub App型の拡張機能を@で呼んでも、プレーンテキストとして扱われます。

VS Codeのチャット拡張も終了したのですか？

していません。公式アナウンスはクライアントサイドのVS Code Copilot拡張について「remain fully supported」と明記し、「Existing VS Code extensions will remain unchanged and can still be invoked with an @mention.」と述べています。vscode.chat.createChatParticipantを使ったチャット参加者の実装も、2026年8月時点の公式拡張ガイドに廃止告知はありません。

Copilot Extensionsの公式ドキュメントはどこにありますか？

旧Copilot Extensionsの解説ページは整理され、about-building-copilot-extensionsはMCPの解説ページへ301リダイレクトされ、個別のリファレンスページは404を返します（2026年8月17日実測）。参照すべきは、MCPサーバーの接続を扱う「Extending GitHub Copilot Chat with Model Context Protocol (MCP) servers」と、GitHub Changelogのサンセット告知（2025年9月24日付）、そしてAgent Plugins 1.0.0の仕様リポジトリです。

無料プランでもMCPサーバーやプラグインを使えますか？

使えます。Agent Plugins 1.0への対応について、GitHubは2026年8月12日のChangelogで「on all Copilot plans」と告知しています。ただしmanaged-settings.jsonによるプラグインの統制はCopilot BusinessとEnterpriseの顧客向けです。

Copilot CLIでもVS Codeと同じ設定ファイルを使えますか？

使えません。公式ドキュメントは.vscode/mcp.jsonがCopilot CLIに読まれないと明記しています。CLIは.mcp.jsonまたは.github/mcp.jsonを読み、トップレベルキーはmcpServers、ローカル起動のtypeは"local"です。Agent Pluginsのmcp.jsonともtypeの値が異なります。

関連記事

• FastMCPとは｜PythonでMCPサーバーを最速構築するフレームワークの使い方【2026年版】
• GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説
• GitHub Copilotエージェントモードの使い方｜Ask・Edit・Agentの違いと有効化・料金【2026年版】
• copilot-instructions.mdとは？書き方・配置場所とAGENTS.md・.instructions.mdの違いを解説
• GitHub Copilotでテストコードを自動生成する方法｜/testsコマンドと活用のコツ【2026年版】