「バラバラ」が属人化を生む本当の理由─Agent Plugins標準化が教えてくれる、「一度考えたことを再利用できる」仕組みの価値

同じ機能を作っているのに、ChatGPT用とCopilot用とCursor用で、それぞれ別のパッケージ形式を用意しなければならない。

AIエージェントのプラグイン開発を経験した方なら、この煩雑さを実感しているはずです。
やりたいことは同じなのに、ベンダーが違うだけで構造も配置ルールも違う。

この「バラバラ問題」に対して、2026年8月6日、ひとつの標準規格が公開されました。

ただし、これは
「一度作ればどこでも確実に動く」
魔法ではありません。
パッケージの構造を共通化することで、対応クライアント間でプラグインを再利用しやすくするための規格です。

この記事では、規格の中身よりも、
「なぜバラバラだと問題が起きるのか」
「標準化すると何が本当に変わるのか」
を、IT現場の視点から掘り下げます。

第1章　何が起きたのか──6社が「共通の箱」を作った

Amazon（AWS）、Microsoft、OpenAI、Vercel、Cursor（Anysphere社）の5社が共同で「Agent Plugins v1.0.0」を公開。
同日、Googleもコアメンテナーとして参加を表明しました。
（参照：Google Developers Blog 2026年8月6日、OpenAI Developers公式発表）

この規格が共通化するのは、プラグインのパッケージ構造です。
具体的には、
・plugin.jsonというマニフェストファイル、
・Agent Skillsフォルダ（スキル定義の配置場所）
・mcp.json（MCPサーバー接続設定）
で構成されるディレクトリ構造が標準化されます。

対応クライアントは
ChatGPT、Codex、VS Code、GitHub Copilot、Cursor、Kiro（発表時点）。

ただし重要な注意点があります。
「共通のパッケージ形式」であっても、実際の動作可否は各クライアントの対応範囲、認証方式、実行環境、独自拡張によって変わります。
「対応クライアント間で再利用しやすくするための規格」であって、
「一度作ればどこでも確実に動く」ではありません。

また、v1.0.0はWorking Draft（作業草案）の段階であり、以下の領域は意図的にスコープ外とされています。↓

・配布の仕組み（統一ストアやマーケットプレイス
・セキュリティモデル（プラグインの権限管理、署名検証）
・来歴検証（作者の信頼性を検証する仕組み）
・認証（APIキーやOAuthトークンの受け渡し方法）

つまり、パッケージの「箱」は共通化されたが、「箱の中身を信頼してよいかどうか」や「箱をどこから入手するか」は、各クライアント・各企業の判断に委ねられているということです。
（参照：Agent Plugins仕様書 v1.0.0 Sections 6-9）

第2章　「バラバラ」は、なぜ属人化を生むのか

標準化のメリットとして
「開発コスト削減」
「属人化防止」
「トラブル対応の容易さ」
が挙げられます。
これ自体は正しいのですが、どんな標準化にも当てはまる一般論です。

もう一歩踏み込みたいのは、「なぜバラバラだと属人化するのか」という因果関係です。

こういう構造になっています。

仕様・方式がバラバラ → 同じことをするのに、毎回違う設計・設定・手順が必要 → 標準的なテンプレートや共通手順が使えない → 毎回「その担当者が考えて作る」必要がある → 文書化・テスト・運用設計まで個別対応になる → 「そこまで手をかける時間がない」 → 担当者の頭の中・経験・ローカルルールに依存する → 属人化 → 引き継げない／トラブル時に分からない／変更が怖い／教育コストが高い

つまり、属人化は「あの人しか知らない」という表面的な症状であって、
上流にある原因は「バラバラな仕様のせいで、毎回ゼロから考えなければならない構造」にあります。

ここを理解しておくと、「属人化を減らすために文書化しろ」という掛け声がなぜ現場で機能しないかも分かります。
そもそも毎回個別対応を強いられる環境で、文書化まで手が回るわけがないのです。

第3章　標準化の本当の効果──「一度考えたことを再利用できる」

では、標準化すると何が変わるのか。

一番大きいのは、
「一度考えたことを、次の人がもう一度考えなくて済むようになる」ことです。

標準化されていれば、プラグインの基本構造、スキルの配置ルール、MCP接続設定の書き方、命名規則、テスト項目などが共通部品として最初から存在します。

すると、毎回「作る」のではなく、
「標準を適用し、必要な部分だけ差分を記述する」になります。

これは「全部同じにする」こととは違います。

100の要素があったとして、共通化できる80を標準化し、自社・自部署固有の20だけを差分として扱う。
プラグインの基本構造やスキルの配置ルールは共通、その上に乗る業務ロジックや権限設定は個別　ーという考え方です。

この「共通部分と差分を分ける」発想は、AIエージェントのプラグインに限った話ではありません。
ITインフラの設計でも、プロジェクト管理でも、30年以上前から繰り返し証明されてきた原則です。

そしてここには、もうひとつ重要な効果があります。

トラブル時の原因特定が速くなる。

仕様がバラバラだと、問題が起きたとき
「これはプラグインの構造の問題なのか、クライアント側の問題なのか、認証の問題なのか」
の切り分けに時間がかかります。
共通規格があれば、「規格に沿っている部分」と「各クライアント独自の部分」の境界が明確になり、原因の所在をより速く絞り込める可能性があります。

ただし注意が必要です。
パッケージ形式が共通であっても、スキルの品質、命名、依存関係、接続先、運用文書がバラバラなら、属人化は残ります。
標準化は属人化を減らすための重要な条件のひとつですが、それだけで解決するわけではありません。

第4章　標準化の歴史が教えてくれること

パソコンの周辺機器がメーカーごとに接続端子がバラバラだった時代から、USBの登場で一変した歴史。
Webブラウザがそれぞれ独自仕様で動いていた時代から、HTML5の標準化で「どのブラウザでも同じように動く」世界が生まれた歴史。

これらは「標準化がうまくいった」歴史的な成功例です。

Agent Plugins v1.0.0にも、同じ方向性の試みが見えます。
ただし、USB-CもHTML5も、広範な普及と実装の定着を経て事実上の共通基盤になったものです。
Agent Pluginsは、まだWorking Draft段階の規格です。
USB-CやHTML5のような共通基盤に育つかどうかは、今後の実装・採用・ガバナンス次第であり、現時点で同列に語ることはできません。

もうひとつ、標準化の歴史から学ぶべきことがあります。

標準化にはコストもあるということです。

導入コスト、移行コスト、教育コスト、互換性テスト、例外管理──共通規格を採用すること自体にも手間がかかります。そして、標準規格に準拠することと、組織内で製品・構成・運用を統一することは、実は別の話です。前者は相互運用性の土台を作る行為であり、後者はガバナンス上の選択です。

この区別を理解しておくことは、自社でAIエージェントの導入を検討するときに重要になります。

第5章　Agent Pluginsの周辺で起きていること

この規格にはいくつか注目すべき構図があります。

Anthropicの不在。
Agent Pluginsの技術的な土台─Agent Skills仕様とMCP（Model Context Protocol）─を開発したのはAnthropicですが、Anthropicはこの標準化連合に参加していません。
TSC（Technical Steering Committee）にもAnthropicの名前はなく、Claude Codeは対応クライアントに今のところは含まれていません。

不参加の理由は公式には示されていません。ここから先は推測になるため、この記事では踏み込みません。

ただし実務的には、Agent Plugins形式のプラグインはClaude Codeでもインポートが可能であることが、複数の検証記事で確認されています。
「連合に参加していない＝使えない」ではないという点は、覚えておいてよいでしょう。
（参照：Qiita検証記事「Agent Plugins 1.0、Anthropicだけ仲間はずれ？ 実際にClaude Codeで動くか検証してみた」2026年8月）

セキュリティの空白。
v1.0.0が権限管理や署名検証をスコープ外としていることは、第1章で述べました。
これは、導入する企業側が自前で統制すべき領域があるということです。
少なくとも以下の点は、プラグインを導入する前に確認する必要があります。

・プラグインの入手元を、公式または社内承認済みリポジトリに限定しているか
・本番環境での書き込み・削除・外部送信の権限を、初期状態で制限しているか
・APIキーやOAuthトークンが、プラグイン定義ファイルに平文で保存されていないか
・導入前に検証環境で実行ログと権限要求を確認しているか
・プラグインごとに所有者・更新責任者・廃止基準を定めているか

これは規格の問題ではなく、導入する組織の責任として管理すべき領域です。

これらの確認項目は、自社内のチェックだけでなく、開発や導入を外部に委託する際の選定基準としても機能します。
「プラグインの入手元をどう管理していますか」
「APIキーの扱いはどうしていますか」
と聞いて、具体的な回答が返ってくるかどうか。
特別な専門知識を問う質問ではありません。

だからこそ、ここに答えられるかどうかが、セキュリティの基本を理解している相手なのかを見極める、シンプルで確実な判断材料になります。

第6章　「なぜ統一が大事か」を、真の原因から説明できる人になる

この記事で一番伝えたいのは、Agent Plugins v1.0.0の仕様解説ではありません。

「なぜバラバラだと問題が起きるのか」を、因果関係で説明できるようになることです。

社内でAIエージェントを導入するとき、部署ごとにバラバラなツール連携や独自のプラグイン構造を放置すれば、半年後には
「あのチームのやり方はこっちのチームでは通じない」
「あの人がいないと動かない」
という状態になります。

しかし、その原因は「文書化していないから」ではありません。そもそも毎回ゼロから作り直す構造になっているから、文書化する余裕も動機もないのです。

標準化とは、
「全部を同じにすること」ではなく、
「一度考えたことを再利用できる状態にすること」です。

共通化できる部分を標準化し、差分だけを個別に扱う。
そうすれば、文書化も、テストも、引き継ぎも、トラブル対応も、すべての「距離」が短くなります。

そしてこれは、前回の記事で取り上げたインシデント共有の話とも通じています。

インシデント管理にしても、標準化にしても、本質は同じです。
犯人探しや個人の努力への依存を減らし、真の原因にたどり着くまでの距離を短くする仕組みを作ること。

AIの時代に人間が判断すべきことは増えていきます。
だからこそ、
「同じ判断を毎回繰り返さなくて済む仕組み」
を設計できるかどうかが、これからのリテラシーのひとつになるのだと、筆者は考えています。

＜参考情報＞ ・Agent Plugins公式仕様 v1.0.0（https://agentplugins.codes/）
・GitHub Changelog「Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app」（2026年8月12日）
・Google Developers Blog「Agent Plugins package your skills, tools, and more」（2026年8月6日）

＜関連記事＞ →「失敗を隠す会社と失敗を共有する業界──SAFEが提案するAIインシデント共有の仕組み」（リンク） →「操作は消えるが判断は残る──IT史から読み解くAIリテラシー」（リンク）

皆さんの職場では、ツールやシステムの「バラバラ」に悩んだ経験はありますか？ 統一して楽になった話も、統一できずに苦しんだ話も、ぜひコメントで教えてください。