Agent Plugins:AIエージェント拡張機能の新しいオープン標準

Agent Pluginsが実際に何なのか

私は連携機能を仕事として作っているので、新しい標準を見るとまず、どこまでが本物の仕様でどこからがプレスリリースなのかを確認する。今回はほとんどが本物の仕様だった。

Agent Pluginsは自らを、AIエージェントを拡張する再利用可能なコンポーネントをパッケージ化するためのオープンでベンダー中立な標準だと説明している。実際に標準化しているのは1つ、フォルダの形だけだ。マニフェストがどこに置かれるか、どのフィールドを含められるか、クライアントがどこでスキルを探すべきか、どこでMCPサーバーの設定を探すべきか。インストール、マーケットプレイス、権限管理、ユーザー体験全体を含むそれ以外のすべては、各クライアントに委ねられている。

何かを実行する最小のプラグインは、3つのファイルで構成される。

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

そしてマニフェストはわずか2行で済む。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin"
}

それだけだ。必須フィールドは$schemaとnameのみ。version、description、author、homepage、repository、license、keywords、extensionsなど、それ以外はすべて任意である。

解決しようとしている問題は、地味だが確かに実在する。あらゆるエージェントクライアントが独自のプラグイン形式を育ててきたため、同じスキルをクライアントごとに作り直す必要があり、あるクライアント向けに作ったパッケージは別のクライアントで読み込ませる前に手直しが必要だった。同じSKILL.mdを4つの異なるリポジトリ構成で維持した経験があれば、この痛みの形はもうわかるはずだ。これは数年前にChatGPTプラグインやGPTsとActionsを扱いにくくしていたのと同じ断片化であり、今はクライアントの数が増えているだけだ。

プラグインに含まれるもの、含まれないもの

バージョン1が定義するコンポーネントタイプはちょうど2つ、スキルとMCPサーバーだけだ。これは意図的に絞り込まれた数であり、この文書全体の中で最も興味深い設計判断でもある。

どちらも、マニフェストが上書きできない固定の場所に置かれる。スキルはskills/に置かれ、それぞれがサブディレクトリとなってSKILL.mdを含む。MCP設定はルートのmcp.jsonに置かれる。仕様は、クライアントが追加のスキルを探してさらに深く再帰してはならないこと、plugin.json内にインラインで宣言されたMCP設定を受け入れてはならないことを明記している。

SKILL.mdのフォーマット自体については、仕様は完全に委ねている。スキルはAgent Skills仕様に準拠しなければならず、フロントマターやscripts/、references/、assets/の構成については引き続きそちらが正となる。Agent Pluginsが定めているのは、それらをどこで見つけるかだけだ。

何が持ち運べて、何が持ち運べないかは以下の通りだ。

クライアントが独自に追加したいものは何であれ、逆ドメイン形式のネームスペースに置かれる。マニフェストのextensions配下のキーとしてか、com.example.client/という名前のトップレベルディレクトリとしてだ。他のクライアントは、自分が実装していないネームスペースを、中身を検証すらせずに無視することが求められている。これは小さなルールだが影響は大きい。プラグインはクライアント固有の追加要素を持ちながら、他の場所でも問題なく読み込まれるのだ。

MCP側は想像していたより手厳しい。認識されるトランスポートはstdio、streamable-http、そして非推奨のsseの3つで、準拠クライアントは少なくとも最初の2つのうちどちらかをサポートしなければならない。リモートエンドポイントは、ホストがループバックでない限りHTTPSを使わなければならない。すべてのstdioサブプロセスにはPLUGIN_ROOTとPLUGIN_DATAという環境変数が渡され、${PLUGIN_ROOT}と${PLUGIN_DATA}はargs、env、cwdの中でのみ展開され、それ以外では展開されない。パスの封じ込めは全体を通じて強制されており、../bin/serverのようなcommandは単に非推奨なのではなく、無効として扱われる。

障害の分離こそ、実運用で実際に頼りになる部分だ。壊れたMCPエントリはそのサーバーだけを無効化し、プラグイン全体は止めない。不正なSKILL.mdはそのスキルだけをスキップし、フォルダ全体はスキップしない。ただし、マニフェストのスキーマ検証に失敗したプラグインは完全に拒否され、そのコンポーネントは1つも動かない。こうした境界がひとつひとつ明記されているのは、実際にこの手のものを世に出してきた人たちが書いたという良い兆候だ。中途半端に読み込まれたMCP連携をデバッグした経験がある人なら、この精密さのありがたみがわかるはずだ。

拡張機能のどの部分が実際に持ち運べるのか

同じ内容をもう一度説明するのではなく、自分で触って確認できる形で用意した。コンポーネントを選んで、クライアント間の移動に耐えられるかどうかを見てほしい。

実際に誰が支えているのか

標準の生死はガバナンスで決まる。だからこそ、私はまずこのセクションから読む。

Technical Steering Committeeは5人で構成され、企業が議席を持つのではなく、それぞれが所属先を添えた個人として名を連ねている。

Vercelの発表では、もう少し広いグループがクレジットされており、Amazon Web Services、Anysphere、GitHub、Microsoft、OpenAI、Vercelがこの標準を共同開発したとしている。

この憲章には、二度読む価値のある条項が3つある。単一のベンダーがコアメンテナー議席の過半数を支配してはならない。すべてのガバナンス上の役割は個人が保持し、企業向けに予約された議席は存在しない。そして名称、ロゴ、ドメイン、GitHub組織は、委員会が指定する中立的な団体が信託として保有し、いかなるベンダーもプロジェクトのアイデンティティを独占的に管理することは許されない。

記録もそれを裏付けている。このリポジトリはvercel-labs/open-plugin-specとして立ち上がり、現在は別組織のagentplugins配下にあり、仕様書はCC-BY-4.0、コードはApache 2.0でライセンスされている。中立性の主張がいつか崩れたとしても、このライセンス形態のおかげで、乗っ取られるのではなくフォークできる状態が保たれる。これは業界がagentic commerce protocolの取り組みで実行したのとほぼ同じ手法であり、リポジトリの裏付けのないコンソーシアムのプレスリリースよりも良い兆候だ。

Anthropicの形をした不在

Anthropicはメンテナーのリストに登場せず、Claude CodeもVercelが挙げるローンチクライアントには含まれていない。これはじっくり考える価値がある。というのも、実際のプラグイン制作の非常に大きな割合が現在Claude Code上で行われており、Agent Skillsもそこから始まったからだ。

両者のフォーマットは近いが互換性はない。Anthropicのドキュメント化されたプラグインレイアウトでは、マニフェストは.claude-plugin/plugin.jsonに、MCP設定は.mcp.jsonに置かれ、どちらも隠しパスだ。一方Agent Pluginsはルートに可視のplugin.jsonとmcp.jsonを使う。Claude Codeはこの標準がまったくカバーしていないコンポーネントタイプも提供しており、同じ形はCowork pluginフォーマットやIDEプラグインでも再び現れる。

これらはファイルパスの違いにすぎず、あらゆる非互換性の中でも最も解消しやすい種類だ。今この瞬間でも、プラグインは大した手間なく両方のマニフェストを持たせることができる。しかし誰かがその作業をするまでは、両方のエコシステムを対象とする作者は依然として2つのレイアウトを維持し続けることになり、これはまさに標準が取り除こうとしていた問題そのものだ。私はこの不在を拒絶とは読まないし、どちらの方向にも公式な声明は出ていない。私はこれを、まだ終わっていないだけだと読んでいる。

同じパターンが他の場所でも起きている点は指摘しておく価値がある。AtlassianはRovoエージェントスキルを提供し、ServiceNowは独自のエージェントスキルを提供し、Freshworksはプリビルドのスキルライブラリを提供している。これらはいずれもコーディングエージェント向けの仕様の対象範囲外だが、同じアイデアが5通りの異なる形でパッケージ化されているという事実は、この分野全体がいかに黎明期にあるかを物語っている。

バージョン1.0.0が意図的に残した部分

誰かが何かをインストールする前に、セキュリティレビュアーに読んでほしいのがこのセクションだ。

メンテナーたちは、こうしたギャップについて驚くほど率直だ。専用のfuture considerations文書には、v1.0.0が定義していないものとして次が挙げられている。

• 信頼モデル、権限システム、サンドボックス化。 ケイパビリティ宣言も、同意フローも、段階的な信頼レベルもない。
• 来歴の検証。 署名確認も、公開されたプラグインを元のソースリポジトリに結びつけるアテステーションもない。
• シークレットの扱い。 仕様はenvやHTTPのheadersに認証情報を入れることを禁じているが、可搬性のある代替手段は用意していない。
• エンタープライズ向けの制御。 アローリストも、ブロックリストも、組織単位のレジストリも、一元管理されたポリシーの上書きもない。
• 監査証跡。 インストール、有効化、更新、アンインストールに関する標準的なイベントスキーマがない。
• 依存関係の解決。 プラグインは他のプラグインへの依存関係を宣言できない。

仕様は、可能な範囲では実際の安全ルールを備えている。パスはプラグインルート内にとどまらなければならない、ループバックでないMCPエンドポイントはHTTPSを使わなければならない、設定されたヘッダーはユーザーの明示的な許可なしに別オリジンへのリダイレクトを跨いで転送してはならない、クライアントはプラグインの読み込み中にネットワーク経由でスキーマを取得してはならない、といった具合だ。どれも理にかなっている。ただしこれらはすべてパッケージそのものに関するルールであり、パッケージがその後何をすることを許されるかについてのルールではない。

だから正直な読み方はこうなる。Agent Pluginsは配布の問題を解決するが、信頼の問題は解決しない。プラグイン内のMCPサーバーは、あなたの環境で任意のプロセスを起動できるが、それが許されるべきかどうかについて、この標準は何も語らない。それで問題がないかどうかは、どのクライアントにインストールするか、そのクライアントがたまたまどんな権限管理機能を備えているかに完全に依存する。Claude Code側であればそれは管理者コントロールとsettings.jsonを意味し、それ以外の場所ではそのベンダーが決めたこと次第になる。

AIエージェントを自作せず購入する場合、これは何を意味するのか

プラグイン仕様についての記事を読む人の大半は開発者だ。だが二次的な影響は、業務機能のためにAIエージェントを評価しているすべての人に及ぶ。そして最もわかりやすいのがサポート業務だ。

持ち運び可能なプラグイン形式の売り文句は、拡張機能が特定のベンダーの人質にならないということだ。これは本物であり、これを採用しているクライアントを選ぶ良い理由になる。ただし響きほど広くはない。というのも、パッケージの可搬性は成果の可搬性ではないからだ。SKILL.mdが2つのクライアント間できれいに移動できたとしても、エージェントが両方で同じように振る舞うとは限らないし、同じツール権限を持つとも、同じ割合のチケットを解決するとも限らない。最後のその数字こそがプロジェクトの採算を左右するものであり、カスタマーサービス向けAIエージェントが実際に評価される基準なのだ。

同じ理屈は、自作か購入かをめぐる会話の中で常に繰り返されているのを目にする。私たちが一緒に仕事をしたあるエンジニアリングリードは、その計算を私よりも的確に言い表していた。

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

彼は300本以上の記事を抱えるConfluenceとTelegramのナレッジベースを運用するエンジニアリングリードであり、自作ではなく購入を選んだ。標準はパーツを組み立てるコストを下げてくれる。だが、その成果を所有し続けるランニングコストについては何もしてくれない。そして実際にこの手のプロジェクトが高くつくのは、まさにそこだ。

標準の有無にかかわらず、どんなベンダーにも私が投げかける3つの問いがある。

1. 教え込んだ内容をエクスポートできるか? プロンプト、ルール、エスカレーションロジック。答えがノーなら、持ち運び可能なプラグイン形式があってもロックインの状況は何も変わらない。
2. エージェントが何に触れられるかを誰が決めるのか? v1が権限モデルを定義していない以上、これはクライアントごとに異なる答えになる。実運用のキューに何かが届く前に、書面で確認しておくべきだ。規制の厳しいチームにとっては、これはそのままデータプライバシーレビューに組み込まれる。
3. 本番稼働前に、自社の履歴に対してテストできるか? 誰かが書いたシナリオに対するシミュレーションは、自社の過去のチケットに対するドライランとは違う。

3つ目については、私は妥協しない。自信ありげに聞こえるボットが黙って間違った回答をするのを、私たちは何度も見てきた。だからこそeeselでのすべての導入は、いきなりオンにして様子を見るのではなく、まず過去のチケットに対してシミュレーションされる。

すでに使っている環境にそのままつながるサポートとして、eeselを試す

eeselは、Agent Pluginsが追い求めているのと同じ発想、つまり「すでに使っている場所に合わせる」という発想をヘルプデスクに適用している。Zendesk、Freshdesk、Gorgiasに加え、Slack、Confluence、そのほかの社内ナレッジベースにも接続し、そこで学習した内容から返信を下書きしたり、解決したりする。

差別化のポイントは、先ほど挙げた3つ目の問いにある。eeselが実運用のチケットに1件でも返信する前に、自社のチケット履歴に対して実行し、どのチケットに対してどんな確信度で何を答えていたかを確認できる。そのうえで、どのチケットタイプに触れることを許可するかを選ぶ。無料で試すことができ、セットアップは四半期ではなく数分で終わる。

この先どうなるか

この仕様を1日かけて読んだうえでの私の見立てはこうだ。フォーマットは素早く採用できるほど小さくまとまっており、ガバナンスはたいていの初版標準よりも強固で、セキュリティ面の話は意図的に空けられた穴にロードマップが付いている状態だ。議論ばかりで動かない包括的な仕様よりも、出荷される最小限の仕様の方が勝る。そしてAgent Pluginsは明らかに後者だ。

私が注目している点は2つある。1つは、Anthropicが歩み寄るかどうかだ。ギャップは基本的にファイルパス2つと、1つのエコシステム分の追加コンポーネントタイプにすぎない。もう1つは、誰かが「あればよかった」と誰もが思うようなプラグインを出荷してしまう前に、v1.1が権限モデルを実現できるかどうかだ。

もし今まさにAIエージェントツールを選んでいるなら、それがCursorのようなコーディングエージェントであれ、エージェント型CLIであれ、Agent Pluginsへの対応は、そのベンダーのロックインに対する姿勢を示す軽いプラスのシグナルとして扱うといい。そして権限管理とテストについての回答こそが、実際に判断を左右するものだと考えてほしい。