概要
Pluginは、AIコーディングエージェントの拡張、すなわちカスタムコマンド・エージェント定義・Skill・フック・MCP設定を、1つのインストール可能なパッケージに束ねる配布単位です。設定ファイルをマシン間で個別にコピーする代わりに、チームメンバーはPluginを一度インストールするだけで同じ作業環境を手に入れられます。 この仕組みは特定の製品に固有のものではありません。本ページではPluginを「エージェント拡張のパッケージングと配布」という一般的なパターンとして扱い、ツールごとの具体的なディレクトリ構成は構成要素の節で示します。 Pluginの範囲は、パッケージングと配布です。束ねられる個々の拡張が何をするかは、それぞれのページで解説しています。再利用可能なワークフローの単位はSkillを、エージェントと外部システムの接続はMCPを参照してください。 本ページでは、Pluginがなぜ必要なのか、何で構成されるのか、どのように展開するのか、そしてチームで運用するときに何を考えるべきかを解説します。なぜPluginが必要なのか
エージェントの設定は、放っておくと個人のものに留まります。カスタムコマンド・Skill・MCP設定は各開発者のマシンに蓄積され、ある人にとってうまく機能しているワークフローが、他の開発者のマシンへ共有されることはありません。「このファイルを設定にコピーしてください」というドキュメントベースの共有では、コピーがそれぞれ独立に編集され、バージョンが気づかないうちに食い違っていきます。 Pluginは、その個人の設定を、名前とバージョンと配布経路を持つ管理された成果物に変えます。効果は3つの場面に現れます。- 標準化。 Pluginをインストールした全員が同じコマンド・同じレビュー手順・同じ規約で動くため、コードだけでなく開発手法そのものがチームで共有されます。
- ワンステップのオンボーディング。 新しいメンバーは設定を1ファイルずつ組み立てる代わりにPluginを1つインストールするだけで、初日からチームの標準環境に到達できます。
- 更新の維持しやすさ。 改善はPluginのリポジトリで一度だけ行い、更新を通じてすべてのインストール先へ届きます。手作業での再周知や再コピーは不要です。
構成要素
Pluginは、マニフェストと5種類の拡張の任意の組み合わせを含むディレクトリです。どの拡張も必須ではなく、コマンド1つだけのPluginも作れますが、1つのワークフローを構成する拡張が一緒に配布されるほど価値は高まります。
具体的なディレクトリ構成はツールごとに異なりますが、形はどれも同じです。Pluginを識別するマニフェストと、束ねる拡張ごとのファイル・ディレクトリで構成されます。Pluginを置くリポジトリには、これに加えてカタログファイル（
marketplace.json）を置きます。カタログの中身は後述のマーケットプレイスの節で説明します。
マーケットプレイス
マーケットプレイスは、Pluginモデルの配布側です。1つ以上のPluginを列挙したカタログで、クライアントはそこからPluginを名前で発見してインストールできます。多くのツールでは、カタログは通常のGitリポジトリ内のファイルで、1つのリポジトリに複数のPluginを置けます。 カタログファイルには、Pluginごとに1つのエントリとして、名前・取得元（source）・説明やバージョンなどのメタデータを列挙します。スキーマの詳細はツールごとに異なりますが、役割は同じです。クライアントはこの1ファイルを読んで、マーケットプレイスが何を提供しているかを把握します。
導入プロセス
Pluginの展開は、段階を踏むのが最も確実です。各段階で検証しながら、ワークフローを1人のマシンから組織へと広げていきます。1
個人でワークフローを実証する
日々の利用ですでに機能しているコマンドやSkillから始めます。Pluginは中身が何であれそれを増幅するため、繰り返し使われて価値が実証された手順をパッケージ化します。一度も動かしていないアイデアは対象にしません。
2
Plugin化する
実証済みの部品をPluginのディレクトリ構造へ移し、マニフェストを書きます。マシン固有のパスや個人の前提を取り除き、どのメンバーの環境でも動く状態にします。
3
マーケットプレイスに公開する
マーケットプレイスのリポジトリを作成または再利用し、カタログにPluginを追加して、最初の利用者グループにインストールしてもらいます。名前が分かりにくい、前提条件が足りないといった利用者のつまずきが、この段階のレビューフィードバックです。
4
組織へ展開して改善を続ける
チーム全体にPluginを告知し、プロダクトとして扱います。PluginリポジトリのIssueやプルリクエストでフィードバックを集め、改善をバージョン付きの更新として届けます。
CIからの呼び出し
Pluginは対話セッション専用ではありません。CIでも同じPluginをインストールしてSkillを呼び出せるため、レビュー・チェック・レポート生成といったチーム標準の手順を、誰も触っていないコード領域も含めて、自動かつ定期的に適用できます。 たとえばGitHub Actionsのワークフローでは、マーケットプレイスのリポジトリを取得してPluginをインストールし、プルリクエストごとにSkillを呼び出せます。.github/workflows/plugin-review.yml
運用上の考慮点
Pluginが共有インフラになると、運用の中心は3つの関心事になります。更新をどう行き渡らせるか、改善を誰が担うか、そしてPluginができることを誰がレビューするかです。バージョン管理と更新の追従
Pluginのバージョンはマニフェストに書き、リリースのたびに意図を持って更新します。semantic versioningは更新の安全度をインストール側に伝えるシグナルになり、短いchangelogは何がなぜ変わったかを伝えます。 配布はリポジトリに従います。マーケットプレイスのデフォルトブランチへプッシュするとリリースが利用可能になり、各インストール先は更新時にそれを取り込みます。これを確実に保つ習慣は2つあります。- 定期的な更新を促します。インストール先が古いまま放置されると、Pluginが維持するはずのチーム標準から静かに取り残されます。
- コマンド名の変更や出力フォーマットの変更のような破壊的変更は、リリース前に告知します。インストール済みのPluginは、他のメンバーの日々のワークフローの一部だからです。
貢献の開放とオーナーシップ
マーケットプレイスは、全メンバーがインストールできるだけでなく、貢献もできるリポジトリとして運用します。導入はワンコマンドで済み、マーケットプレイスは通常のリポジトリなので、新しいSkillの追加も既存Skillの改善も通常のプルリクエストとして送れます。 貢献の開放は、標準のオーナーシップを変えます。導入した人しかPluginを変更できない場合、すべての改善はその1人を待つことになります。誰でも変更できる場合、共有ワークフローの改善はメンバー全員の仕事の一部になります。このように運用されるマーケットプレイスには、導入した本人が貢献していない期間にも、他のメンバーからの改善が届き続けます。 これは、PluginがAI活用を広げる仕組みとして機能する理由でもあります。組織でAI活用を推進する役割の仕事は、活用を個別に推し進めることではなく、活用がひとりでに広がる仕組みを作ることです。全メンバーがインストールでき、貢献もできるPluginのマーケットプレイスは、その仕組みの1つになります。権限とレビュー体制
Pluginのインストールは、実際の実行能力を渡す行為です。フックはスクリプトを実行し、MCP設定は外部サーバーへ接続し、コマンドはエージェントの動きを方向づけます。Pluginは、コード実行の権利を持つ依存関係の1つとして扱います。その能力が何に転用されうるか、どう範囲を区切るかはセキュリティで解説しています。- インストールは、チームが管理しているか明示的に信頼しているマーケットプレイスからに限定します。
- カタログへ追加する前に、Pluginが束ねているもの、特にフックとMCP設定をレビューし、更新時にも再レビューします。
- 同梱する各Skillのツール権限はSkillで解説しているとおり最小限に保ち、Pluginの総合的な操作面を把握できる大きさに保ちます。
Pluginはワークフローを配布しますが、設計はしません。Pluginがパッケージ化する委任の設計はAgentic Workflowを、その土台となる協働の実践はVibe Codingを参照してください。
関連ページ
Skill
単一のワークフローを、エージェントが必要なときだけ読み込む再利用可能な単位にまとめます。Pluginの最も一般的な中身です。
MCP
オープンな標準規格でエージェントと外部のデータソース・ツールを接続します。その接続設定はPluginで配布できます。
Agentic Workflow
Pluginがチームへ標準化して届ける、計画・実装・検証の委任モデルを設計します。
Security
Pluginをインストールする前に何をレビューするか、配布後に権限設定をどう揃え続けるかを扱います。