Agent Pluginsとは何か？スキル、MCPサーバー、そして何が変わるのか (2026)
Agent Pluginsは、Agent SkillsとMCPサーバーを1つのポータブルなディレクトリにパッケージ化するための、オープンでベンダーニュートラルな仕様です。バージョン1.0.0は2026年8月6日に公開されました。単一のマニフェストファイルと単一のフォルダレイアウトを規定しているため、互換性のあるすべてのAIエージェントクライアントで同じパッケージを読み込むことができます。
アイデアのすべてはそこにあります。ここには新しいプロトコルも、新しいランタイムもありません。すでに存在していたパーツはそのまま機能し続け、この仕様はそれらをどのように1つの箱に収めるかだけを定めています。
本ガイドでは、何がリリースされたのか、そしてプラグインの中身に何が含まれているのかを解説します。また、この仕様があえて定義していないことや、エージェントを使って分析を行うユーザーにとって何が変わるのかについても触れます。
2026年8月6日にリリースされたもの
同日、2つの公式記事が公開されました。VercelはJonathan Hefnerが執筆した発表記事を公開しました。Googleは、Kevin Hou、Haoyu Wang、Alan Blountによる独自の記事をGoogle Developers Blogに掲載しました。
Vercelの投稿によると、この提案はVercelが主導したとのことです。その後、Amazon Web Services、Anysphere、GitHub、Microsoft、OpenAI、Vercelの代表者がこれを洗練させ、1.0.0へと仕上げました。
また、この投稿では、ローンチ時にこのフォーマットをサポートするクライアントとして、ChatGPT、Codex、Cursor、GitHub Copilot、Kiro、VS Codeが挙げられています。Googleの投稿では、同社の2つの製品であるAgents CLIとData Agent Kitが挙げられています。Data Agent Kitには、BigQuery、Spanner、Cloud SQL用のプラグインが含まれています。
1つ整理しておくべき詳細があります。仕様のリポジトリは2026年4月3日に作成されたため、8月6日は作業の開始ではなく、1.0.0のリリースを意味します。これら2つの日付を同一視する報道は、このプロジェクトがいかに迅速にまとまったかを誇張しすぎています。
開発を主導しているメンバー
このプロジェクトは、技術運営委員会（Technical Steering Committee）をMAINTAINERS.mdファイルで公開しています。2026年8月現在、5人のコアメンテナー（Core Maintainers）がリストアップされています。AmazonのClare Liguori、CursorのRoshan Sadanani、MicrosoftのHarald Kirschnerです。また、OpenAIのGav VermaとVercelのJonathan Hefnerの名前もあります。Hefnerはリードコアメンテナー（Lead Core Maintainer）として記載されています。
Googleの発表によると、GoogleもKevin Houを代表としてコアメンテナーに加わったとのことです。この追加は、公開されているメンテナーファイルにはまだ反映されていません。
ライセンスは分かれています。リポジトリ独自のライセンス通知では、仕様のテキスト、ドキュメント、サンプルはCC BY 4.0に分類されています。スキーマ、ソースコード、スクリプトはApache 2.0の対象となります。
プラグインの実際の中身
プラグインとはディレクトリのことです。仕様では、必須となる要素を意図的に最小限に抑えています。
マニフェストはplugin.jsonであり、必須のフィールドは2つだけです。$schemaフィールドは、パッケージがターゲットとする仕様のバージョンを宣言します。1.0.0の場合、その値はhttps://agent-plugins.org/schemas/1.0.0/plugin.schema.jsonになります。
2つ目の必須フィールドはnameです。これはa-z、0-9、-、.からなる1〜64文字で、先頭と末尾は英数字である必要があります。--や..のようにセパレータが連続するものは拒否されます。
マニフェスト内のそれ以外の項目（version、description、author、homepage、repository、license、keywords）はすべて任意です。
コンポーネントはインラインで宣言されるのではなく、固定のパスに配置されます。スキルはskills/フォルダから取得され、SKILL.mdファイルを含む直下の各子ディレクトリが1つのスキルとしてカウントされます。MCPサーバーはmcp.jsonで宣言されます。
この最後の制約は興味深い点です。マニフェストはコンポーネントの場所を移動できず、インラインで定義することもできません。したがって、読み手は2つのパスをリストアップするだけで、プラグインに何が含まれているかを知ることができます。
具体的な例を見ると、その構造がよくわかります。月次の収益サマリーを作成するプラグインの場合、レポート作成の指示を保持する1つのスキルフォルダと、ウェアハウスを指す1つのmcp.jsonエントリが含まれることになります。この構成にはクライアント固有の要素は一切なく、それこそが最大のポイントです。
仕様があえて除外していること
除外事項のリストは要件のリストよりも長く、それらは率直に明記されています。
この仕様は、Agent Skills仕様に属するスキルフォーマット自体を定義していません。また、Model Context Protocolに属するMCPの通信動作も定義していません。クライアント固有の拡張機能の内容や検証、トランスポート接続が失敗した後のフォールバック動作についても定義していません。
Googleの投稿では、それ以外の境界線についても補足されています。インストールメカニズム、配信プロトコル、権限、サンドボックス化、信頼性の検証、ユーザーエクスペリエンスはすべてスコープ外です。
信頼性の検証が省略されている点については、少し考えてみる価値があります。プラグインは任意のエンドポイントに到達するMCPサーバーを宣言できますが、仕様はそのエンドポイントがアクセス権に値するかどうかを判断しません。審査は依然として人間の仕事であるか、あるいはパッケージを読み込むクライアントの役割となります。
これはパッケージングフォーマットに過ぎません。審査や署名を備えたアプリストアのようなものを期待しても、ここにはありません。
なぜデータ業務においてパッケージング規格が重要なのか
エージェントにグラフの作成を依頼する人のほとんどは、パッケージングについて考えることはありません。接続は依然として直接的です。
エージェントが実際に成果物を生成できるようにするには、タスクの指示とデータへのアクセスの2つに到達できる必要があります。スキルが前者を担い、MCPサーバーが後者を担います。これまでは、この両方を一緒に提供するには、クライアントごとに異なるラッパーを用意する必要がありました。
重複には予想通りのコストが伴います。ラッパーにズレ（ドリフト）が生じるのです。あるクライアントには修正が適用され、別のクライアントには適用されないといったことが起こります。その結果、ウェアハウスを読み取るバージョンが、サマリーを書き出すバージョンよりも遅れてしまうことになります。この不具合は、完成したレポート内の古い数値として現れます。
自社独自の内部スキルを維持しているチームは、これを最も痛感しています。決算処理スキルとウェアハウスコネクタを持つ財務グループは、現在これらを個別に提供し、チームが使用するエディタごとに接続設定を繰り返しています。1つのパッケージにすることで、これがバージョン管理内の1つのフォルダに置き換わります。
共通のパッケージフォーマットは、この種の特有のズレを解消します。これによってエージェントの分析能力が向上するわけではなく、そのように宣伝されるべきでもありません。
プラグイン規格が役に立たなくなる境界線
パッケージング仕様は、すでにパーツが揃っていることを前提としています。パーツの品質については何も言及しませんし、スキルが信頼できるグラフを生成するかどうかも教えてくれません。
これこそが、率直に指摘しておくべきギャップです。Powerdrill Bloomは、このフォーマットがパッケージ化する両方の要素をすでに提供しています。リサーチ、分析、自動化、実行のためにClaude Skillsを実行します。また、独自のMCPサーバーも提供しているため、互換性のあるクライアントはデータセットを閲覧し、リクエストに応じてジョブを実行できます。
配管（インフラ）を超えて同製品が提供する付加価値こそが、仕様が関与しない部分です。スプレッドシートをアップロードし、自然言語で質問すると、グラフ、文章によるサマリー、またはスライド資料が返ってきます。パッケージングレイヤーは、ツールがクライアント間でどのように移動するかを決定するだけです。回答が優れているかどうかを決定するわけではありません。
このエコシステムをより広く見渡すために、当社のMCPプラットフォームおよびデータ分析とレポート作成のためのエージェントスキルのまとめ記事で、現在の状況を網羅しています。
知っておくべき関連規格
現在、3つの仕様が並んで存在しており、これらは混同されやすいものです。
| 規格 | 定義内容 | スコープ |
|---|---|---|
| Agent Skills | 単一のスキルの記述方法 | 指示とリソース |
| Model Context Protocol | エージェントがツールやデータソースと通信する方法 | ランタイムプロトコル |
| Agent Plugins | スキルとMCPサーバーを1つのユニットとして提供する方法 | パッケージングのみ |
カテゴリのエラーを避ける最も手っ取り早い方法は、スコープの列を読むことです。エージェントがデータベースに対してどのように認証を行うかという疑問は、MCPの範疇です。セットアップ全体を同僚にどのように渡すかという疑問は、パッケージングの範疇です。
これら3つは、設計上、相互に補完し合う関係にあります。プラグインにはスキルとMCPサーバーの宣言が含まれており、それぞれプラグインの外部でも独立してポータブルな状態を維持できます。
結論
Agent Plugins 1.0.0 is a small specification with a narrow job. One manifest, two required fields, two fixed component paths, and an explicit refusal to define installation, permissions or trust.
その価値は、初日ではなく、数ヶ月かけて現れてきます。ラッパーが減るということは、ツールが同期しなくなる箇所が減ることを意味します。これは、出力結果が誰かが意思決定に使う数値である場合に最も重要になります。配管（インフラ）ではなく分析レイヤーをお求めの場合は、お手持ちのファイルでPowerdrill Bloomをお試しください。また、当社のauto insightsページもご覧ください。
この記事の事実は、2026年8月11日に公式情報源と照合して検証されました。仕様の詳細は変更される可能性があるため、フィールド名に依存する前にリンク先のページを確認してください。
よくある質問
Agent Pluginsとは、簡単に言うと何ですか？
エージェントのスキルとMCPサーバーの宣言を1つのフォルダにまとめる標準的な方法です。互換性のあるクライアントであれば、クライアント固有のラッパーを必要とせずに、そのフォルダを読み込むことができます。
Agent PluginsはMCPと同じものですか？
いいえ、異なります。MCPは、エージェントがツールやデータソースと通信する方法を規定するランタイムプロトコルです。Agent Pluginsはパッケージングのみを規定し、プラグインの内部でMCPサーバーを宣言することができます。
plugin.jsonには何が必要ですか？
2つのフィールドだけです。$schema値はターゲットとする仕様のバージョンを宣言し、nameはプラグインを識別します。versionやlicenseを含むそれ以外のものはすべて、任意のメタデータです。
どのツールがAgent Pluginsをサポートしていますか？
Vercelのローンチ時の投稿では、ChatGPT、Codex、Cursor、GitHub Copilot、Kiro、VS Codeが挙げられています。Googleは別途、同社のAgents CLIおよびData Agent Kitでのサポートを発表しています。
Agent Pluginsはインストールや権限を処理しますか？
いいえ、処理しません。インストール、配信、権限、サンドボックス化、信頼性の検証はすべて明示的にスコープ外となっています。この仕様はパッケージのレイアウトのみをカバーしており、それ以外のことは対象外です。