← ブログ一覧

Copilotプラグイン「作れば全部で動く」検証

GitHub Copilot Agent Plugins 1.0のGA発表を受け、Copilot CLIで実際にプラグインをインストール・確認し、移植性の主張を検証した記事。


この記事の結論: 「一度作ればどこでも動く」系の謳い文句は、CLI・拡張・アプリのうち自分が実際に触れるサーフェスだけでも動かして裏取りしてから信じる。今回Copilot CLI側だけ実測したら、統合インスペクタコマンドが動かない状態でGAを迎えていた。

リナ社長(高校生社長のやり手ギャル)× タクヤ(入社3年目)— 今回は、GitHub CopilotのAgent Plugins 1.0がGAになったのを受けて、Copilot CLI側だけ実際にインストールして中身を見てみた回。(登場人物について

「タクヤ、Copilotのプラグイン機能、ついに正式版になったらしいじゃん。VS CodeでもCLIでもアプリでも同じプラグインが動くって話、ウチのブログパイプラインに使えるかもって思ったんだけど」

「GA自体は僕も見ました。ただ気になるのは、copilotってCLIとVS Code拡張、内部の作りは絶対に違うはずなんですよね。GUI前提の拡張と、ヘッドレスで動くCLIで、本当に同じプラグインがそのまま動くのか。少なくともCLI側は認証なしでどこまで試せるか確認できるので、そこだけでもやってみようと思います」


Agent Plugins 1.0がGAになった、で終わらせない

GitHub Blogの2026年8月12日付changelogは、VS Code・Copilot CLI・GitHub Copilot SDK・Copilot appの4つに渡ってAgent Plugins 1.0がGA(一般提供)になったことを告知するものだった(タイトル自体にはSDKは明記されておらず、本文で言及されている)。プラグインはスキル・エージェント・hook・MCPサーバー・LSPサーバーをまとめて配布できる仕組みで、複数の製品面で共通して使えることが売りになっている。裏を返せば「一度作れば複数の場所で使い回せる」という主張が成立するかどうかが、この機能の価値をそのまま左右する。

この手の「Build once, use everywhere」的な主張は、宣伝としては強いが検証しないと実態が分からない。今回はCopilot CLI側だけ、実際にnpmでインストールしてコマンドを叩いて確認した。VS Code拡張側はGUI操作が必要でこのサンドボックスでは試せていないため、そちらは未検証として扱う。

実際にCLIへプラグインを入れてみた

サンドボックス環境でnpm経由でCopilot CLIをインストールし、バージョンとプラグイン関連コマンドを確認した。

$ npm view @github/copilot versions --json | tail
# → @github/copilot 1.0.80 が npm に公開されていることを確認

$ npm install @github/copilot@1.0.80
added 3 packages in 10s

$ copilot --version
GitHub Copilot CLI 1.0.80.

ヘルプを見ると、プラグイン関連のコマンドがplugin(単数)とplugins(複数)の2系統存在していた。

$ copilot plugin --help
Usage: copilot plugin [options] [command]
Manage plugins and plugin marketplaces.

$ copilot plugins --help
Usage: copilot plugins [options] [command]
Inspect plugins, MCP servers, skills, instructions, and language servers from a single command...

plugin(単数)は従来からのプラグイン個別管理、plugins(複数)はMCP・skill・instructionsまで横断して見られる統合インスペクタという役割分担らしい。ところが実際に叩くと差が出た。

$ copilot plugin list
No plugins installed.

$ copilot plugins list
The plugins command is not available.

plugin(単数)は正常に動いたが、plugins(複数)は「not available」でエラーになった。ログインも認証も一切していない状態でここまで確認できている。続けてマーケットプレイスからのインストールも試した。

$ copilot plugin marketplace browse copilot-plugins
Plugins in "copilot-plugins":
  • workiq - Query Microsoft 365 data with natural language...
  • spark - Spark plugin for GitHub Copilot.
  • power-pages - Create and deploy Power Pages sites using modern development approaches.
    Supports code sites (SPAs) with React, Angular, Vue, or Astro. ...
  (他 advanced-security, fabric-skills, powerbi-authoring, cpp-language-server 等、計18件)

$ copilot plugin install spark@copilot-plugins
Plugin "spark" installed successfully.

$ copilot plugin list
Installed plugins:
  • spark@copilot-plugins (v1.0.0)

$ find ~/.copilot -maxdepth 4
/root/.copilot/settings.json
/root/.copilot/installed-plugins/copilot-plugins/spark/skills
/root/.copilot/installed-plugins/copilot-plugins/spark/README.md
/root/.copilot/config.json

$ copilot plugin uninstall spark
Plugin "spark" uninstalled successfully.

一覧を眺めていて目についたのが、power-pagesプラグインの説明文に「Astro」がサポート対象として明記されていた点だ。実際にこのプラグインをインストールして使ったわけではなく、あくまでマーケットプレイスの一覧に載っているのを見つけただけだが、jinbei-labがAstro+Cloudflareで動いている以上、無関係とは言い切れない情報ではある。インストールされたプラグインの実体はskills/ディレクトリとREADME.mdというシンプルな構成でローカルに展開されており、MCPサーバーやhookのような複雑な設定ファイル群ではなかった。

第三者分析と突き合わせる

digitalapplied.comの分析記事は、タイトル自体が「Agent Plugins 1.0 Ships: What Still Does Not Port」——GA発表があっても、すべてがそのまま移植されているわけではない、という論旨を掲げている。ただし、その論旨の中身は今回自分たちが実測したGitHub一社のCLI内部でのplugin/pluginsコマンド不整合とは別軸の話だ。digitalappliedが指摘しているのは、OpenAIやCursorが依然として.codex-plugin/plugin.json.cursor-plugin/plugin.jsonといった独自プロプライエタリ形式を維持していること、Claude CodeやOpenAIの公式ドキュメントがAgent Plugins標準への言及を欠いていること、そしてOpenAIが自社の/import機能で他ベンダー(Claude Code, Cursor)の設定を読み込む「ベンダー個別ブリッジ」は作っているものの、標準そのものの採用者にはなっていないこと——つまりクロスベンダーでの移植性ギャップの話である。

今回こちらが確認したのは、統合インスペクタであるcopilot plugins(複数形)が「not available」でエラーになっている一方、旧来のcopilot plugin(単数)はきちんと機能していたという、GitHub一社のCLI内部での新旧コマンド体系の不整合にすぎない。切り口は異なるが、GA発表があっても「どこでも同じように動く」が無条件には成立しないという大枠の懸念は共通している。

さらに、マーケットプレイスからのプラグインインストールに認証が一切不要だったのも技術的には気になる点だ。VS Code拡張側はWebviewや拡張APIを経由する別の権限モデルを持っているはずで、CLIのように無認証でインストールできる前提とは違うだろう。この権限モデルの差が、digitalapplied.comが指摘する「まだ移植されない部分」とどう関係しているのかは、VS Code側を試せていない以上ここでは断定できない。ただし、少なくとも「作れば全部で同じように動く」という主張を無条件で信じるには、CLI内部のコマンド体系の不整合だけでも十分な留保材料になる。


評価が割れた

「Build once, use everywhereが本当なら、プラグイン開発・保守のコストを一本化できるってことじゃん。ウチみたいな小さいチームだと、複数の場所に同じ機能を作り込む余裕なんてないし、これはめちゃくちゃ実利ある話だと思うんだけど」

「そこは僕もいいと思ってます。ただ、実際に触ったplugins(統合インスペクタ)が使えない状態だったのは無視できないですよ。GA発表イコール『全部が今すぐ一本化されている』ではないんです。少なくとも今のバージョンでは、新旧コマンド体系が併存していて、片方はエラーになる。まだ移行の途中段階です」

「え、それってつまり今飛びついても損する可能性あるってこと?」

「損はしないと思います。むしろ評価できる点もあって、マーケットプレイスからのインストールに認証が一切不要だったのは、ウチみたいな小規模チームが自動化ツールを内製するとき、導入コストの低さとしてそのまま実利になります。ただ『期待した工数削減効果』を今すぐ鵜呑みにするのは早いというだけです」

「で、それウチの何が変わるの?」

「今すぐプラグインを自作してブログパイプラインに組み込む理由にはならない、が答えです。plugins統合インスペクタが直った後にもう一度見るくらいの温度感でいいと思います。ただ、認証なしでここまで試せる導入コストの低さ自体は、今後何か作る時の候補として覚えておく価値があります」

「なるほどね……じゃあ『すぐ乗り換える』はナシだけど、『一応マーケットプレイスは覗いておく』はアリってことか。それなら妥当かも」

まとめ・持ち帰り

  • GitHub Copilot Agent Plugins 1.0はVS Code・Copilot CLI・GitHub Copilot SDK・Copilot appの4つでGAになったと告知されている
  • Copilot CLI(v1.0.80)では、旧来のcopilot plugin(単数)は正常動作したが、統合インスペクタのcopilot plugins(複数形)は「not available」でエラーになった
  • マーケットプレイスからのプラグインインストール(copilot plugin install)は認証なしで成功し、実体はskills/ディレクトリ+README.mdとしてローカル展開される
  • マーケットプレイス一覧のpower-pagesプラグイン説明文にAstroサポートの記載を見つけたが、実際にインストール・使用はしていない
  • VS Code拡張側の動作・両サーフェス間の直接比較・実際のAIエージェント対話は認証やGUI操作が必要なため未検証

持ち帰り: 「複数のツール・環境で同じものが動く」という移植性の主張を見たら、自分が実際に触れるサーフェス(CLI・拡張・API等)だけでもいいから一度コマンドを叩いて、宣伝文句と実装の間にギャップがないか確認してから採用判断をする。

読者のみんなは、Copilot CLIとVS Code拡張、両方使ってる人いる? もし両方入れてたら、copilot plugins listが動くかどうかだけでも見てみてほしい。


参考

コメント