Agent Pluginsは、AIエージェント向けのSkillとMCP serverを1つの配布単位でまとめるためのオープン仕様です。2026年8月6日にGoogle Developers Blogが、GoogleがCore Maintainerに加わり、Agents CLIとData Agent Kitで対応を始めたと発表しました。複数のAI coding agentに同じ拡張を配りたい企業にとって、これまで製品ごとに分かれていたmanifestや配置ルールを揃えやすくなったのが最大の変化です。
結論から言うと、社内向けのAgent Skill、社内DBにつなぐMCP server、製品別の拡張設定を1ディレクトリにまとめて運びたいチームには追い風です。一方で、単一クライアント向けのMCPだけを配るケースでは、Google自身もmcp.json単体の方がシンプルだと説明しています。
Agent Pluginsで何が変わったのか
Googleの発表では、Agent Plugins 1.0.0はvendor-neutralなdirectory specificationとして位置づけられています。Google、Amazon、Microsoftなど複数の陣営で同じ箱を共有し、SkillとMCP serverを配るための最低限の約束だけを標準化する設計です。つまり、クライアントごとの強みを消すのではなく、共通化できる配布部分だけを揃える考え方です。
従来は、同じSkillと同じMCP serverでも、製品ごとにmanifestの形、ディレクトリ名、MCP設定の書き方がずれ、別パッケージを維持しがちでした。今回のニュース価値は、Googleがその統一仕様を自社製品にも取り込み始めたことにあります。
標準ディレクトリ構成はどうなっているか
仕様書では、plugin root直下にplugin.jsonを置き、skills/配下に各Skill、mcp.jsonにMCP server定義、必要ならreverse-domain形式のclient extension directoryを置く構造を定義しています。Googleの解説でも、plugin.jsonの中身は最小限で、部品の場所を勝手に動かせないことが強調されています。
実務上の意味は明快です。レビュー担当は「どこにSkillがあるか」「MCP設定がどこか」を毎回探さずに済みます。障害時も、skills/は読めるが一部のMCP serverだけ起動失敗、といった切り分けがしやすくなります。Google blogでも、失敗したMCP entryがあってもplugin全体を止めず、独立して扱う思想が説明されています。
どこまで標準化し、どこは標準化しないのか
ここは導入判断で重要です。Agent Plugins v1.0.0はpackage formatに集中しており、install mechanism、distribution protocol、permission model、sandboxing、trust verification、user experienceまでは定義していません。仕様書上のStatusもWorking Draftです。つまり、配布の箱は揃う一方で、承認フローや社内統制は引き続き各クライアントや各社の運用設計が必要です。
この割り切りはむしろ健全です。IDE、CLI、managed platformでは、権限UIや承認責任が大きく違います。箱の標準化と、実行時ガバナンスの標準化を無理に一緒にしなかったので、既存の社内ルールを壊さずに採用しやすいとも言えます。
Google製品では何が今日から使えるのか
Googleは発表日時点で、Agents CLIとData Agent Kitが対応済みだと案内しています。Agents CLIは、ADKでのagent build、evaluation、deployment、observability、publishingを支援する7つのSkill群をまとめたCLI兼skills packageです。ドキュメントではCodexやClaude Codeのようなcoding agentでも使えると説明されています。
Data Agent Kit側は、BigQuery、Spanner、Cloud SQL、Firestore、LookerなどGoogle Data Cloud系のSkillやMCP serverを、好みのAI coding agentへ持ち込むためのハブとして紹介されています。データ基盤チームにとっては、BigQuery向けだけ別設定、Spanner向けだけ別配布、という分断を減らせるのが実利です。
どんなチームが先に検討すべきか
優先度が高いのは、1つの社内ナレッジや社内ツールを複数のagent clientへ横展開したい組織です。たとえば、営業用の提案書生成SkillとCRM参照MCP、情シス向けの監査SkillとDWH照会MCPを、Codex、Claude Code、Gemini系クライアントへ揃えて配りたい場合に向きます。
逆に、単一製品だけに閉じた実験段階なら、Google blogが書く通りplugin化を急がなくて構いません。単独MCP server、単独Skillの方が速く、保守対象も少ないからです。判断基準は「部品が複数あり、一緒に配りたいか」「複数clientへ持ち運ぶか」の2点です。
よくある質問
Q. Agent Pluginsを入れれば、権限管理や安全性も自動で揃いますか。 A. いいえ。v1.0.0はpermission modelやsandboxingを定義していないため、承認フローや接続先制御は各clientと各社運用で設計する必要があります。
Q. まず何から始めるべきですか。 A. 小さな社内ユースケースで、plugin.json、skills/、mcp.jsonだけを持つ最小構成を作り、どのclientでどこまで再利用できるかを確認するのが現実的です。そのうえで配布方法や審査手順を後付けすると、標準化の恩恵とガバナンス要件を切り分けやすくなります。
複数のAI agentにまたがるSkill/MCP配布設計や、社内向けpluginの審査フローを整えたい場合は、 HelloCraftAIへご相談ください 。要件整理からPoC設計、運用ルールづくりまで一緒に進められます。
