> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # Pluginとは — エージェント設定をまとめる配布単位 > Pluginは、カスタムコマンド・エージェント・Skill・フック・MCP設定を1つの配布単位に束ね、実証済みのワークフローをチーム全体へ導入・更新できるようにします。 ## 概要 Pluginは、AIコーディングエージェントの拡張、すなわちカスタムコマンド・エージェント定義・Skill・フック・MCP設定を、1つのインストール可能なパッケージに束ねる配布単位です。設定ファイルをマシン間で個別にコピーする代わりに、チームメンバーはPluginを一度インストールするだけで同じ作業環境を手に入れられます。 この仕組みは特定の製品に固有のものではありません。本ページではPluginを「エージェント拡張のパッケージングと配布」という一般的なパターンとして扱い、ツールごとの具体的なディレクトリ構成は構成要素の節で示します。 Pluginの範囲は、パッケージングと配布です。束ねられる個々の拡張が何をするかは、それぞれのページで解説しています。再利用可能なワークフローの単位は[Skill](/ja/ai/skill)を、エージェントと外部システムの接続は[MCP](/ja/ai/mcp)を参照してください。 本ページでは、Pluginがなぜ必要なのか、何で構成されるのか、どのように展開するのか、そしてチームで運用するときに何を考えるべきかを解説します。 ## なぜPluginが必要なのか エージェントの設定は、放っておくと個人のものに留まります。カスタムコマンド・Skill・MCP設定は各開発者のマシンに蓄積され、ある人にとってうまく機能しているワークフローが、他の開発者のマシンへ共有されることはありません。「このファイルを設定にコピーしてください」というドキュメントベースの共有では、コピーがそれぞれ独立に編集され、バージョンが気づかないうちに食い違っていきます。 Pluginは、その個人の設定を、名前とバージョンと配布経路を持つ管理された成果物に変えます。効果は3つの場面に現れます。 * **標準化。** Pluginをインストールした全員が同じコマンド・同じレビュー手順・同じ規約で動くため、コードだけでなく開発手法そのものがチームで共有されます。 * **ワンステップのオンボーディング。** 新しいメンバーは設定を1ファイルずつ組み立てる代わりにPluginを1つインストールするだけで、初日からチームの標準環境に到達できます。 * **更新の維持しやすさ。** 改善はPluginのリポジトリで一度だけ行い、更新を通じてすべてのインストール先へ届きます。手作業での再周知や再コピーは不要です。 ## 構成要素 Pluginは、マニフェストと5種類の拡張の任意の組み合わせを含むディレクトリです。どの拡張も必須ではなく、コマンド1つだけのPluginも作れますが、1つのワークフローを構成する拡張が一緒に配布されるほど価値は高まります。 | 構成要素 | 役割 | | -------- | -------------------------------------------------------------------------------------------------- | | カスタムコマンド | ユーザーが明示的に呼び出す名前付きの入口（スラッシュコマンド）です。チームの定型的な依頼を固定の形にまとめます。 | | エージェント | 固有の指示とツール範囲を持つサブエージェントの定義です。レビューや調査など、役割特化の作業に使います。 | | Skill | エージェントが必要なときだけ読み込む、再利用可能なワークフローの単位です。構造と設計原則は[Skill](/ja/ai/skill)で解説しています。 | | フック | ツール呼び出しの前や編集の後など、決まったライフサイクルイベントで自動実行されるスクリプトです。チェックや規約を強制します。 | | MCP設定 | MCPサーバーへの接続設定です。Pluginをインストールすると、ワークフローが必要とする外部システムへの接続も一緒に整います。プロトコル自体は[MCP](/ja/ai/mcp)で解説しています。 | 具体的なディレクトリ構成はツールごとに異なりますが、形はどれも同じです。Pluginを識別するマニフェストと、束ねる拡張ごとのファイル・ディレクトリで構成されます。Pluginを置くリポジトリには、これに加えてカタログファイル（`marketplace.json`）を置きます。カタログの中身は後述のマーケットプレイスの節で説明します。 ```text Claude Code theme={null} dev-plugins/ # マーケットプレイスのリポジトリ ├── .claude-plugin/ │ └── marketplace.json # マーケットプレイスのカタログ └── my-dev-plugin/ ├── .claude-plugin/ │ └── plugin.json # 名前・説明・バージョン・著者 ├── commands/ # カスタムスラッシュコマンド ├── agents/ # エージェント定義 ├── skills/ # Skill（それぞれSKILL.mdを持つ） ├── hooks/ # フックの設定とスクリプト └── .mcp.json # MCPサーバー設定 ``` ```text GitHub Copilot CLI theme={null} dev-plugins/ # マーケットプレイスのリポジトリ ├── .github/ │ └── plugin/ │ └── marketplace.json # マーケットプレイスのカタログ └── plugins/ └── my-plugin/ ├── plugin.json # Pluginルート直下のマニフェスト ├── agents/ # エージェント定義（*.agent.md） ├── skills/ # Skill（それぞれSKILL.mdを持つ） ├── hooks/ │ └── hooks.json # フックの設定 └── .mcp.json # MCPサーバー設定 ``` ```text Codex CLI theme={null} dev-plugins/ # マーケットプレイスのリポジトリ ├── .agents/ │ └── plugins/ │ └── marketplace.json # マーケットプレイスのカタログ └── plugins/ └── my-plugin/ ├── .codex-plugin/ │ └── plugin.json # 名前・説明・バージョン ├── skills/ # Skill（それぞれSKILL.mdを持つ） ├── .mcp.json # MCPサーバー設定 └── .app.json # アプリ統合のマッピング ``` ### マーケットプレイス マーケットプレイスは、Pluginモデルの配布側です。1つ以上のPluginを列挙したカタログで、クライアントはそこからPluginを名前で発見してインストールできます。多くのツールでは、カタログは通常のGitリポジトリ内のファイルで、1つのリポジトリに複数のPluginを置けます。 カタログファイルには、Pluginごとに1つのエントリとして、名前・取得元（`source`）・説明やバージョンなどのメタデータを列挙します。スキーマの詳細はツールごとに異なりますが、役割は同じです。クライアントはこの1ファイルを読んで、マーケットプレイスが何を提供しているかを把握します。 ```json Claude Code theme={null} { "name": "dev-plugins", "owner": { "name": "Your Org" }, "plugins": [ { "name": "review-plugin", "source": "./review-plugin", "description": "セルフレビューのワークフローとレビュー用コマンド" } ] } ``` ```json GitHub Copilot CLI theme={null} { "name": "dev-plugins", "owner": { "name": "Your Org", "email": "plugins@example.com" }, "metadata": { "description": "チーム向けにキュレーションしたPlugin", "version": "1.0.0" }, "plugins": [ { "name": "review-plugin", "description": "セルフレビューのワークフローとレビュー用コマンド", "version": "1.0.0", "source": "./plugins/review-plugin" } ] } ``` ```json Codex CLI theme={null} { "name": "dev-plugins", "interface": { "displayName": "Dev Plugins" }, "plugins": [ { "name": "review-plugin", "source": { "source": "local", "path": "./plugins/review-plugin" }, "policy": { "installation": "AVAILABLE", "authentication": "ON_FIRST_USE" }, "category": "Development" } ] } ``` マーケットプレイスを一度登録すれば、以降はPluginを名前でインストールできます。 ```text Claude Code theme={null} /plugin marketplace add your-org/dev-plugins /plugin install review-plugin@dev-plugins ``` ```text GitHub Copilot CLI theme={null} copilot plugin marketplace add your-org/dev-plugins copilot plugin install review-plugin@dev-plugins ``` ```text Codex CLI theme={null} codex plugin marketplace add your-org/dev-plugins codex plugin add review-plugin@dev-plugins ``` マーケットプレイスは通常のリポジトリなので、配布にはチームがすでに持っているインフラをそのまま使えます。アクセス制御はリポジトリの権限で、レビューはプルリクエストで、更新の公開はデフォルトブランチへのプッシュで行えます。 配布範囲も、リポジトリの可視性で制御できます。マーケットプレイスをprivateリポジトリに置けば、そのリポジトリにアクセスできるメンバーだけがPluginをインストールできます。追加のインフラなしで、組織内限定の配布チャネルになります。 ## 導入プロセス Pluginの展開は、段階を踏むのが最も確実です。各段階で検証しながら、ワークフローを1人のマシンから組織へと広げていきます。 日々の利用ですでに機能しているコマンドやSkillから始めます。Pluginは中身が何であれそれを増幅するため、繰り返し使われて価値が実証された手順をパッケージ化します。一度も動かしていないアイデアは対象にしません。 実証済みの部品をPluginのディレクトリ構造へ移し、マニフェストを書きます。マシン固有のパスや個人の前提を取り除き、どのメンバーの環境でも動く状態にします。 マーケットプレイスのリポジトリを作成または再利用し、カタログにPluginを追加して、最初の利用者グループにインストールしてもらいます。名前が分かりにくい、前提条件が足りないといった利用者のつまずきが、この段階のレビューフィードバックです。 チーム全体にPluginを告知し、プロダクトとして扱います。PluginリポジトリのIssueやプルリクエストでフィードバックを集め、改善をバージョン付きの更新として届けます。 このプロセスは意図的に漸進的です。誰も検証していない大きなカタログより、小さくても本当に役立つPluginが1つあるマーケットプレイスのほうが優れています。 ## CIからの呼び出し Pluginは対話セッション専用ではありません。CIでも同じPluginをインストールしてSkillを呼び出せるため、レビュー・チェック・レポート生成といったチーム標準の手順を、誰も触っていないコード領域も含めて、自動かつ定期的に適用できます。 たとえばGitHub Actionsのワークフローでは、マーケットプレイスのリポジトリを取得してPluginをインストールし、プルリクエストごとにSkillを呼び出せます。 ```yaml .github/workflows/plugin-review.yml theme={null} name: Plugin review on: pull_request: types: [opened, reopened, ready_for_review] jobs: review: if: github.event.pull_request.draft == false runs-on: ubuntu-latest timeout-minutes: 10 permissions: contents: read pull-requests: write steps: - uses: actions/checkout@v7 with: fetch-depth: 0 # 読み取り専用トークンでマーケットプレイスのリポジトリ（private）を取得 - name: Clone the plugin marketplace run: | git clone https://x-access-token:${{ secrets.PLUGIN_REPO_TOKEN }}@github.com/your-org/dev-plugins.git /tmp/dev-plugins # ローカルと同じ定義のPluginをインストールしてSkillを実行 - uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} github_token: ${{ github.token }} plugin_marketplaces: | /tmp/dev-plugins plugins: | review-plugin@dev-plugins claude_args: >- --allowedTools Read --allowedTools "Bash(git diff*)" --allowedTools "Bash(gh pr view*)" --allowedTools "Bash(gh pr comment*)" prompt: /review-plugin:self-review --no-interactive ``` このようなジョブを安定して動かす要点は2つあります。promptには非対話フラグを渡し、Skillが人間の入力待ちで止まらないようにします。許可するツールは、Skillが必要とするものだけに絞ります。 重要なのは、ローカルとCIでまったく同じPluginを実行することです。両者が1つの定義を共有するため、基準が場所によってずれることがありません。CIのジョブがコミットやプルリクエストを作成する場合は、成立する範囲で最も狭い権限の認証情報を渡し、人間の操作と同じチェックが発火するトークンを選びます。 ## 運用上の考慮点 Pluginが共有インフラになると、運用の中心は3つの関心事になります。更新をどう行き渡らせるか、改善を誰が担うか、そしてPluginができることを誰がレビューするかです。 ### バージョン管理と更新の追従 Pluginのバージョンはマニフェストに書き、リリースのたびに意図を持って更新します。semantic versioningは更新の安全度をインストール側に伝えるシグナルになり、短いchangelogは何がなぜ変わったかを伝えます。 配布はリポジトリに従います。マーケットプレイスのデフォルトブランチへプッシュするとリリースが利用可能になり、各インストール先は更新時にそれを取り込みます。これを確実に保つ習慣は2つあります。 * 定期的な更新を促します。インストール先が古いまま放置されると、Pluginが維持するはずのチーム標準から静かに取り残されます。 * コマンド名の変更や出力フォーマットの変更のような破壊的変更は、リリース前に告知します。インストール済みのPluginは、他のメンバーの日々のワークフローの一部だからです。 ### 貢献の開放とオーナーシップ マーケットプレイスは、全メンバーがインストールできるだけでなく、貢献もできるリポジトリとして運用します。導入はワンコマンドで済み、マーケットプレイスは通常のリポジトリなので、新しいSkillの追加も既存Skillの改善も通常のプルリクエストとして送れます。 貢献の開放は、標準のオーナーシップを変えます。導入した人しかPluginを変更できない場合、すべての改善はその1人を待つことになります。誰でも変更できる場合、共有ワークフローの改善はメンバー全員の仕事の一部になります。このように運用されるマーケットプレイスには、導入した本人が貢献していない期間にも、他のメンバーからの改善が届き続けます。 これは、PluginがAI活用を広げる仕組みとして機能する理由でもあります。組織でAI活用を推進する役割の仕事は、活用を個別に推し進めることではなく、活用がひとりでに広がる仕組みを作ることです。全メンバーがインストールでき、貢献もできるPluginのマーケットプレイスは、その仕組みの1つになります。 ### 権限とレビュー体制 Pluginのインストールは、実際の実行能力を渡す行為です。フックはスクリプトを実行し、MCP設定は外部サーバーへ接続し、コマンドはエージェントの動きを方向づけます。Pluginは、コード実行の権利を持つ依存関係の1つとして扱います。その能力が何に転用されうるか、どう範囲を区切るかは[セキュリティ](/ja/ai/security)で解説しています。 * インストールは、チームが管理しているか明示的に信頼しているマーケットプレイスからに限定します。 * カタログへ追加する前に、Pluginが束ねているもの、特にフックとMCP設定をレビューし、更新時にも再レビューします。 * 同梱する各Skillのツール権限は[Skill](/ja/ai/skill)で解説しているとおり最小限に保ち、Pluginの総合的な操作面を把握できる大きさに保ちます。 Pluginはワークフローを配布しますが、設計はしません。Pluginがパッケージ化する委任の設計は[Agentic Workflow](/ja/ai/agentic-workflow)を、その土台となる協働の実践は[Vibe Coding](/ja/ai/vibe-coding)を参照してください。 ## 関連ページ 単一のワークフローを、エージェントが必要なときだけ読み込む再利用可能な単位にまとめます。Pluginの最も一般的な中身です。 オープンな標準規格でエージェントと外部のデータソース・ツールを接続します。その接続設定はPluginで配布できます。 Pluginがチームへ標準化して届ける、計画・実装・検証の委任モデルを設計します。 Pluginをインストールする前に何をレビューするか、配布後に権限設定をどう揃え続けるかを扱います。