AIエージェント入門第六章！プラグインの基本と導入前に知っておきたいリスク

ここまでスキル（第二章）・フック（第三章）・エージェント（第四章）・MCP（第五章）と、エージェントを拡張する仕組みを順に見てきました。「便利な設定を作ったから、チーム全員にも配りたい」と思ったとき、これらを まとめて配布するためのバンドル機構 が プラグイン です。

スキル単体・フック単体を Git で配るのは面倒ですが、プラグインなら「このリポジトリを追加して」の一言で済みます。ただし、プラグインの仕組みは3ツールでサポート状況も思想も大きく異なります。

第六章では、バンドル範囲・配布エコシステム・バージョン管理・チーム配布といった機能面を3ツールで比べたうえで、プラグインだからこそ気をつけないといけない サプライチェーンリスクやプラグイン衝突 の問題にも踏み込んでいきます。便利さに飛びつく前に、安全に導入するためのポイントをセットでお届けします。

プラグインとは何か

プラグインは、第二章〜第五章で見てきたスキル・ルール・フック・コマンド・MCP サーバー・エージェント定義などを 1つのバンドルにまとめて配布する仕組み です。受け取った側はワンコマンド（または管理者ポリシー経由）で全部入りで導入できます。

たとえば、チームで「コード変更後に必ずセキュリティレビューを通す」というワークフローを運用したい場合。レビュー用のスキル + コード編集後に自動実行するフック + 脆弱性データベースに繋ぐ MCP サーバーを1つのプラグインにまとめて、チーム全員に /plugin install security-review@team-tools してもらうだけで導入完了、という使い方ができます。

3ツールのサポート状況は次のとおりです。

ツール	プラグイン機構	代替手段
Claude Code	✅ ネイティブ対応	—
Cursor	✅ ネイティブ対応	—
Antigravity	❌ 非対応	MCP Store・VS Code 拡張で部分的に補う

Antigravity には現時点でプラグイン相当の機構がなく、MCP サーバーは MCP Store から、エージェントの定義は .agents/agents.md をリポジトリにチェックインして共有する、という形で個別に対応する必要があります。

参考リンク

バンドル範囲 — 1プラグインに何を詰め込めるか

「プラグイン」と呼んでも、何を入れられるかはツールによって違います。

Claude Code — "全部入り"

Claude Code のプラグインはルートに .claude-plugin/plugin.json というマニフェストを置いた上で、以下のディレクトリを置いておくだけで自動的に検出されます。

ディレクトリ／ファイル	内容
`.claude-plugin/plugin.json`	プラグインのマニフェスト（必須）
`commands/`	コマンド（Markdown ファイル）
`agents/`	カスタムエージェント定義
`skills/`	Agent Skills（`SKILL.md` 入りのフォルダ）
`hooks/hooks.json`	フックの定義
`.mcp.json`	MCP サーバー設定
`bin/`	プラグイン有効中に Bash の `PATH` に追加される実行ファイル
`settings.json`	プラグイン有効時に適用されるデフォルト設定

特に bin/ の実行ファイル が他ツールにはない要素です。bin/ にシェルスクリプトやバイナリを置いておくと、プラグイン有効中は Bash の PATH に自動追加され、ツール内からコマンドとして直接呼べるようになります。

settings.json を含められるのも特徴的で、たとえばプラグイン内に security-reviewer というカスタムエージェントを定義しておき、settings.json で { "agent": "security-reviewer" } と指定すれば、そのプラグインを有効化するだけで Claude Code のメインスレッドが「セキュリティレビュー特化モード」に切り替わります。

Cursor — Rules を中心に主要コンポーネント

Cursor のプラグインは .cursor-plugin/plugin.json をルートに置く形式で、以下のコンポーネントをバンドルできます。

コンポーネント	内容
Rules	永続的な AI ガイダンス・コーディング規約（`.mdc` ファイル）
Skills	複雑なタスク向けの専門エージェント機能
Agents	カスタムエージェントの設定とプロンプト
Commands	エージェントが実行可能なコマンドファイル
MCP Servers	MCP インテグレーション
Hooks	イベントトリガーで動く自動化スクリプト

Cursor 独自の .mdc フォーマットの Rules を同梱できるのが特徴です。チーム全員に共通の AI ガイドラインを配布するのに便利な作りになっています。

Antigravity — 機構なし

Antigravity にはプラグイン機構がありません。MCP サーバーだけは MCP Store 経由で個別にインストールできますが、スキルやエージェント定義をバンドルしてチーム配布する公式の仕組みは現時点では用意されていません。

参考リンク

配布エコシステム — 公式審査 vs Git ネイティブ

「作ったプラグインをどこに公開するか」の文化にも違いがあります。

Cursor — 公式 Marketplace は審査制

Cursor には公式の Cursor Marketplace があり、ここに掲載されているプラグインはすべて Cursor チームによる 手動レビュー を経ています。プラグインは Git リポジトリとして配布されますが、掲載されるためには公式に申請が必要です。

コミュニティ向けには cursor.directory というディレクトリもあり、こちらはコミュニティ運営で、公式 Marketplace のような手動レビューは明示されていません。「公式の審査済みの棚」と「コミュニティの広い棚」が並立している形です。

Claude Code — Git リポジトリがあればそれが Marketplace

Claude Code は Marketplace の概念がもっと軽く、任意の Git リポジトリのルートに .claude-plugin/marketplace.json を1つ置くだけ で、それがプラグイン Marketplace になります。承認プロセスもありません。

marketplace.json には複数のプラグインを並べて、それぞれを別のソースから取得するように設定できます。サポートされているソースタイプは次の5種類です。

ソース	用途
相対パス（`./plugins/...`）	同じ Marketplace リポジトリ内のプラグイン
`github`	GitHub リポジトリから取得
`url`	任意の Git URL（GitLab・自前 Git サーバーなど）
`git-subdir`	モノレポの一部だけをスパースクローンで取得
`npm`	npm パッケージとして公開されたプラグイン

git-subdir がモノレポにやさしく、url で社内 GitLab 等にも対応できる、という柔軟さが Claude Code 流です。npm ソースなら社内プライベートレジストリも registry フィールドで指定できます。

{
  "name": "company-tools",
  "owner": { "name": "DevTools Team" },
  "plugins": [
    {
      "name": "deployment-tools",
      "source": {
        "source": "github",
        "repo": "company/deploy-plugin"
      }
    },
    {
      "name": "monorepo-plugin",
      "source": {
        "source": "git-subdir",
        "url": "https://github.com/acme-corp/monorepo.git",
        "path": "tools/claude-plugin"
      }
    }
  ]
}

公式の Anthropic Marketplace に提出することもでき、その場合は claude.ai または Anthropic Console から専用フォームで申請する形です。

Antigravity — 機構なし

Antigravity には公式の Marketplace もコミュニティディレクトリもありません。あくまで MCP Store に並んでいる MCP サーバーをインストールする、という形になります。

参考リンク

バージョン管理とリリースチャネル — Claude Code 独自の強み

エンタープライズ運用で意外と効いてくるのが「どのバージョンのプラグインを誰に配るか」のコントロールです。ここは Claude Code が一歩抜けています。

Claude Code — `ref` + 40文字 SHA でピン留め

marketplace.json の各プラグインエントリで、ref（ブランチ・タグ）と sha（40文字のコミット SHA）を両方指定でき、特定のコミットに完全にロックできます。

{
  "name": "github-plugin",
  "source": {
    "source": "github",
    "repo": "owner/plugin-repo",
    "ref": "v2.0.0",
    "sha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"
  }
}

ref と sha の両方が使えるソースは github / url / git-subdir の3種類で、npm の場合は version フィールドで ^2.0.0 などの semver レンジを指定できます。

stable / latest の2チャネル運用

同じプラグインを2つの異なるブランチ（たとえば stable と latest）にそれぞれ向けた Marketplace を用意して、ユーザーグループごとに使い分けるパターンが公式ドキュメントで紹介されています。たとえば「安定版グループ」には stable-tools Marketplace、「アーリーアクセスグループ」には latest-tools Marketplace を managed settings 経由で配る、という運用が可能です。

{
  "name": "stable-tools",
  "plugins": [
    {
      "name": "code-formatter",
      "source": {
        "source": "github",
        "repo": "acme-corp/code-formatter",
        "ref": "stable"
      }
    }
  ]
}

このとき注意したいのが、プラグインの plugin.json の version を ref ごとに変えておく必要があることです。同じ version のままだと Claude Code が「同一プラグイン」と判断してアップデートをスキップしてしまいます。

Cursor — Marketplace 審査がそのまま品質ゲートに

Cursor は明示的な ref 指定や SHA ロックの仕組みはありませんが、その代わり Marketplace の手動レビューが品質ゲート として機能します。リリースサイクルが安定しやすい代わりに、エンタープライズ向けの細かなバージョン制御は Claude Code ほど作り込まれていません。

参考リンク

チーム・エンタープライズ配布

組織でプラグインを使うとなると、「誰がどのプラグインを使えるか」「自動でインストールされるか」のガバナンスが重要になります。

Cursor — Team Marketplaces と SCIM 連携

Cursor は Team Marketplaces という機能で、組織内専用の Marketplace を立てられます。プランごとの上限は次のとおりです。

Teams プラン：最大1つの Team Marketplace
Enterprise プラン：無制限の Team Marketplace

Team Marketplace に登録した各プラグインは、配布グループに対して Required（必須・自動インストール）か Optional（任意）かを選んで割り当てます。Required にして保存すると、そのグループのメンバー全員に自動的にインストールされます。

さらに、配布グループは SCIM 連携 に対応しています。会社の ID プロバイダー（Okta・Azure AD など）でグループメンバーシップを管理しておけば、Cursor 側に自動で同期されます。Enterprise プランでは、Team Marketplace の追加は 管理者のみ が Dashboard → Settings → Plugins から行えます。

開発者側は Cursor の Marketplace パネルから自分のチーム向けのプラグインを発見し、Optional のものはその場でインストールできます。Required のものは自動で入っているので意識する必要すらありません。

Claude Code — managed settings + 正規表現許可リスト

Claude Code は単一の Marketplace を提供する形ではなく、managed-settings.json（管理者が配布する設定ファイル）にプラグイン関連の設定を書き込むことで組織配布を行います。主な設定キーは以下のとおりです。

`extraKnownMarketplaces` — Marketplace の自動提案

ユーザーがプロジェクトを信頼すると、ここに登録された Marketplace の追加が自動的に提案されます。

{
  "extraKnownMarketplaces": {
    "company-tools": {
      "source": {
        "source": "github",
        "repo": "your-org/claude-plugins"
      }
    }
  }
}

`enabledPlugins` — 自動有効化

特定のプラグインをデフォルトで有効化できます。

{
  "enabledPlugins": {
    "code-formatter@company-tools": true,
    "deployment-tools@company-tools": true
  }
}

`strictKnownMarketplaces` — 許可リスト

組織のセキュリティ要件が厳しい場合は、strictKnownMarketplaces で許可する Marketplace を制限できます。空配列 [] を指定すると 完全ロックダウン（ユーザーは新しい Marketplace を一切追加できない）にもできます。

特に強力なのが hostPattern による正規表現マッチ で、たとえば社内の GitHub Enterprise Server 全体を許可する場合はこう書けます。

{
  "strictKnownMarketplaces": [
    {
      "source": "hostPattern",
      "hostPattern": "^github\\.example\\.com$"
    }
  ]
}

pathPattern でローカルファイルシステムのパスも正規表現で制限できます。GitHub Enterprise や自前 GitLab を運用している組織にはぴったりの設計です。

オフライン環境向け：`CLAUDE_CODE_PLUGIN_SEED_DIR`

Claude Code のもう一つ コンテナイメージにプラグインを焼き込める というのが特徴的な仕組みとしてあるらしいのですが、今回は割愛。

Antigravity — 組織配布の仕組みなし

Antigravity には組織向けのプラグイン配布の仕組みがありません。MCP サーバーは mcp_config.json をユーザーごとに編集する形で、チームに一括展開する機構は現時点では用意されていません。

参考リンク

プラグイン導入で気をつけたいこと — npm install と同じリスクがここにもある

プラグインは便利ですが、「他人が作ったコードを自分の環境で動かす」という点では npm パッケージや Chrome 拡張と本質的に同じリスクを抱えています。

サプライチェーン攻撃のリスク

プラグインは hooks や bin/ ディレクトリ経由で 任意のシェルスクリプトを実行できます。つまり、悪意あるプラグインを入れてしまうと、ファイルの読み書き・環境変数の窃取・外部へのデータ送信など何でもできてしまいます。

第五章で MCP サーバーの Tool Poisoning リスクを紹介しましたが、プラグインはそれより攻撃面が広いです。MCP サーバーのリスクが「ツール説明文に隠し命令を仕込む」だったのに対し、プラグインは hooks でシェルスクリプトを直接実行でき、bin/ 経由でプラグイン内のバイナリを PATH に追加し、settings.json でエージェントの挙動そのものを書き換え、さらに MCP サーバーまでバンドルできる。つまり MCP のリスクを内包した上で、さらに広い攻撃面を持つ のがプラグインです。

各ツールの防衛線は以下のとおりです。

Claude Code：strictKnownMarketplaces で許可された Marketplace からしかプラグインを追加できないようにロックダウンできます。hostPattern や pathPattern の正規表現で社内サーバーだけを許可する運用が可能です。また、プラグインサブエージェントでは hooks・mcpServers・permissionMode フィールドが無視されるセキュリティ制限も入っています
Cursor：公式 Marketplace は手動レビュー済みなので、掲載されているものは一定の安全性が担保されています。Team Marketplaces も管理者のみが追加できる設計です
Antigravity：プラグイン機構がないため、このリスク自体が存在しません

実用的な指針は 「公式 Marketplace / 管理者が許可した Marketplace のプラグインだけを使う」 です。GitHub で見つけた野良プラグインを strictKnownMarketplaces を設定せずに入れるのは、出所不明の npm パッケージを --force でインストールするのと同じです。

プラグイン同士の衝突

複数のプラグインを同時に入れると、スキルやコマンドの名前がかぶる可能性があります。Claude Code はこの問題を ネームスペース で解決しています。プラグインのスキルは /plugin-name:skill-name の形式で呼ばれるため、2つのプラグインが同じ review というスキルを持っていても /plugin-a:review と /plugin-b:review で衝突しません。

hooks が衝突するケースはもう少し厄介です。2つのプラグインが同じイベント（たとえば PostToolUse の Write）にフックを登録していると、両方とも実行されます。片方がファイルを prettier でフォーマットし、もう片方が独自の整形をかけると、互いに上書きし合って意図しない結果になることがあります。プラグインを追加するときは、そのプラグインがどのイベントにフックを登録しているかを確認しておくのが無難です。

「プラグインにしなくていいもの」の見極め

ここまでの説明を読んで「全部プラグインにしよう」と思うかもしれませんが、実際にはプラグイン化すべきでないケースも多いです。判断の目安はこの表のとおりです。

条件	推奨
1プロジェクト × 自分だけ	standalone（`.claude/` や `.cursor/` に直接置く）
1プロジェクト × チーム	プロジェクト設定（`.claude/settings.json` にチェックイン）
複数プロジェクト × 自分だけ	ユーザー設定（`~/.claude/` や `~/.cursor/`）
複数プロジェクト × チーム	プラグイン化

つまり プラグイン化の判断基準は「複数プロジェクト × 複数メンバーで繰り返し使うか」 です。この条件を満たすなら、マニフェスト作成とバージョン管理のコストは十分に元が取れます。

それ以外のケースでは：

1プロジェクト専用のルールやスキル — standalone 設定で十分。プラグイン化のオーバーヘッド（マニフェスト作成・バージョン管理・Marketplace 登録）が見合いません
実験段階の設定 — まだ試行錯誤中のものはプロジェクトの .claude/ で回して、安定してから初めてプラグイン化を検討するのが Claude Code 公式ドキュメントの推奨でもあります
チーム内で1〜2人しか使わないもの — ユーザーレベル（~/.claude/ や ~/.cursor/）に置くだけで十分

参考リンク

まとめ

プラグインは「これまで作ってきたスキル・フック・MCP・エージェント定義をまとめて配布する」ための仕組みで、Claude Code と Cursor の2ツールがネイティブ対応しています。それぞれの個性は、配布のスタイルとガバナンスに表れます。

Claude Code は Git ネイティブで自由度が高く、エンタープライズ運用に作り込まれている 構成です。任意の Git リポジトリを Marketplace 化でき、ref + 40文字 SHA によるバージョンロック、stable / latest の複数チャネル運用、strictKnownMarketplaces の正規表現許可リストまで揃っています。bin/ 実行ファイルまで詰め込めるので、「全部入りのカスタム開発環境」を配布できます。社内ガバナンスを効かせながら配布したいエンタープライズ 向けです。

Cursor は 公式 Marketplace の審査制 + Team Marketplaces + SCIM 連携 という、ID プロバイダーと統合された組織管理の作りが強みです。Required / Optional の区別と、ID プロバイダーのグループ同期で「誰に何を配るか」を直感的に管理できます。.mdc フォーマットの Rules を同梱できるのも実用的なポイントです。チーム全員に同じ AI ガイドラインと拡張機能を一括配布したい 中〜大規模チームに向いています。

Antigravity は現時点でプラグイン機構を持たず、MCP Store 経由の個別インストールが主な拡張手段です。チーム配布や統一管理の仕組みは今後の拡張に期待、というところです。

そして、どのツールを選ぶにしても忘れてはいけないのが プラグイン導入のリスク です。プラグインは hooks や bin/ 経由で任意コードを実行できるため、MCP サーバーより攻撃面が広い仕組みです。strictKnownMarketplaces によるロックダウンや公式 Marketplace の審査は、まさにこのリスクへの防衛線です。導入時は「公式 or 管理者が許可した Marketplace だけ使う」を基本にし、プラグイン化すべきものとそうでないものの見極めも意識しておくと、運用がぐっと楽になります。

スキルもフックも MCP も「単体で作ること」はもう各ツールでできるようになりましたが、それを組織に安全に届ける最後の1ピースがプラグイン です。

このブログを検索

blog.kaname.dev