Agent Plugins 1.0.0で変わるAI開発環境の持ち運び
POINT
- 2026年8月6日、AWS・Anysphere・GitHub・Microsoft・OpenAI・Vercelの6社が、AIエージェント向けプラグインの共通規格「Agent Plugins」バージョン1.0.0を発表した。Googleもコアメンテナーとして参加している。
- 同時期にGitHub Copilot for JetBrainsが、セッションを跨いで記憶を保持する「Copilot memory」と、OllamaをBYOKプロバイダーとして使える機能を追加した。
- この記事を読むと、プラグインの権限分離とローカルモデルによる記憶の持ち運びを組み合わせた「ベンダーに縛られない開発環境」の設計思想がわかる。
MCPだけでは足りなかったもの
Model Context Protocol（MCP）はツール接続の共通語を作った。だがエージェントのスキルやワークフローをまとめて配布する仕組みは各社ばらばらだった。この空白を埋める規格として登場したのがAgent PluginsだVercel、OpenAI、GitHub、Microsoft、AWS、Anysphereらが参加、AIエージェントのプラグイン共通規格「Agent Plugins」発表 | gihyo.jp。
発表時点でChatGPT/Codex、Cursor、GitHub Copilot、Kiro、VS Codeが対応している。個人開発者が書いたスキル一式を、翌日には別のエディタで動かせる。MCPの次に来る話として押さえておきたい。
権限の線引きは各クライアントに委ねられる
Agent Pluginsの仕組み自体はシンプルだ。プラグインは固定のディレクトリ構造を持ち、plugin.jsonというマニフェストに仕様バージョンとプラグイン名を書く。スキルはskills/配下に格納し、MCPサーバーの接続情報はmcp.jsonで宣言する。トランスポートはstdio、Streamable HTTP、従来のHTTP+SSEから選べる。
規格が定めるのは「共有コンポーネントの構造」だけだ。配布方法やインストール手順、権限の扱いは各クライアントの裁量に残されている。スキルの中身は移植できても、どこまで信頼するかはCursorもVS Codeも自分で決める。単一ベンダーへの依存を避けつつ安全性を保つための線引きだ。
記憶とローカルモデルも持ち運べる
もう一つの軸が記憶とモデルの持ち運びやすさだ。GitHub Copilot for JetBrainsに、チャットセッションを跨いで情報を保持・想起するCopilot memoryが追加された。設定ポータルの「Copilot Memory」トグルでオン・オフを切り替えるCopilot memory and Ollama in GitHub Copilot for JetBrains。
同時にOllamaがBYOKプロバイダーとして使えるようになった。プロバイダー設定とモデル選択をJetBrains内で完結でき、クラウドのAPIキーに縛られずローカルモデルに切り替えられる。企業の管理者側では、プラグインの利用可否やMCPサーバーへのアクセス、権限バイパスの動作をまとめて制御できる。個人の記憶と組織の管理が、別レイヤーで両立する。
導入すべきか、まだ待つべきか
個人〜小規模チームでCodexやClaude Codeを使い、設計・実装フェーズの自動化に踏み込みたい人は、Agent Pluginsで書いたスキルをそのままCursorやVS Codeに持ち込む価値がある。mcp.jsonのトランスポート指定を理解しておけば、複数クライアントを渡り歩くコストが下がる。
一方、外部プラグインの導入に承認プロセスが必要な現場は、権限バイパスの動作やMCPサーバーへのアクセス管理がどう運用されるかを先に確認したほうがいい。規格自体は権限の扱いをクライアント任せにしているので、導入前にクライアント側の権限設定を読む作業は避けられない。
「配布、インストール、権限、使い勝手は各クライアントが制御する」という設計方針は、規格の柔軟さと導入側の見極めの必要性を同時に示している。
まとめ
Agent Pluginsは「スキルとMCP設定の持ち運び」を、Copilot memoryとOllama連携は「記憶とモデルの持ち運び」を担う。どちらも特定ベンダーへの閉じ込めを避ける方向だ。まずスキル資産をplugin.jsonの構造で整理し、権限設定を確認してから複数クライアントへ展開するのが現実的だ。