Claude Codeプラグイン入門｜インストールから自作・配布まで

Claude Codeのプラグインシステムは、AIエージェントの機能をモジュール単位で拡張できる仕組みです。Skills・Agents・Hooks・Commandsを1つのパッケージにまとめて配布できるため、コミュニティ製のプラグインを導入することも、自社の業務に特化したプラグインを自作して社内配布することもできます。

「スキルやエージェントの定義がプロジェクトごとにバラバラで、どれが最新版か分からなくなってきた」「新しいメンバーが加わるたびに、環境構築の手順を一からドキュメントで説明している」「便利そうなカスタムコマンドを見つけたけれど、自社のCRM運用に合わせてカスタマイズできるか判断がつかない」——こうした悩みを抱えている開発チームは少なくありません。なお、この記事のコマンドと設定は2026年10月時点の公式ドキュメントに沿っています。プラグイン機能は更新が早いため、実行前にclaude plugin --helpで手元のバージョンの内容を確認してください。

Claude Codeプラグインとは、Skills（再利用可能な自動化ツール）・Agents（カスタムエージェント定義）・Hooks（ライフサイクルフック）・Commands（カスタムコマンド）という複数の拡張要素をひとつのパッケージにまとめ、マーケットプレイス（プラグインのカタログ）を通じてインストール・配布できる仕組みです。VS CodeやJetBrainsの拡張機能と同じ発想で、Claude Codeの基本機能にサードパーティ製・自社製の機能を追加できます。

この記事でわかること

この記事は、Claude Codeのプラグインシステムを使って開発環境やAI業務自動化の仕組みを拡張したい方を想定読者として書いています。プラグインの全体像から自作・配布までを一通り押さえられる内容です。

• プラグインシステムの全体像 — Skills・Agents・Hooks・CommandsがどのようにひとつのプラグインにまとまるのかをHubSpot連携プラグインの例で説明します。
• plugin.jsonの構造と設定方法 — 唯一の必須項目であるnameと、主な任意フィールドを一覧表で整理し、何をどこまで定義すべきかを示します。
• マーケットプレイスの使い方 — マーケットプレイスの追加・インストール・スコープ設定までのコマンド手順を紹介します。
• LSPサーバーの同梱 — プラグインに言語サーバーを含めると何ができるかを解説します。
• 自作プラグインの開発から配布までの手順 — 雛形作成からローカルテスト、社内マーケットプレイスでの配布までをステップで追えます。

最後まで読むと、既存のスキル・エージェント・フックをプラグインとしてまとめる判断基準と、実際に開発・配布するまでの流れが一通り理解できるようになります。

Claude Codeプラグインとは何か

Claude Codeプラグインは、単体のスキルファイルやフックスクリプトを個別に管理するのではなく、業務単位・機能単位でひとつのパッケージにまとめるための仕組みです。個々の拡張要素をバラバラに管理していると、どのファイルがどの目的で使われているか分かりにくくなり、更新やチーム共有の手間も増えていきます。

Skills・Agents・Hooksを1つにまとめる仕組み

たとえば「HubSpot連携プラグイン」であれば、HubSpot APIの操作スキル、CRM設定専門エージェント、API呼び出し前のレート制限チェックフックを1つのプラグインとして配布できます。従来はこれらを個別のファイルとしてプロジェクトごとに配置していましたが、プラグイン化することで1つの単位としてバージョン管理・更新・配布ができるようになります。

拡張機能としての位置づけ

プラグインは、Claude Codeという1つのAIエージェント基盤の上に、業務ごとの専門知識や操作ロジックを積み重ねる拡張レイヤーとして位置づけられます。BtoBマーケティングの記事制作フロー、CRM運用フロー、テスト・CI連携フローといった一連の業務プロセスを、それぞれ独立したプラグインとして切り出しておくと、どのプラグインがどの業務を担っているかが把握しやすくなります。

以下の画面は、claude --helpを実行し、pluginに関する説明行をgrepで抜き出した実行結果です。プラグインの管理は、シェルではclaude plugin、セッション内では/pluginで行います。

プラグインの基本構造とplugin.jsonの設計

プラグインを自作する際にまず理解しておきたいのが、ディレクトリ構成とplugin.jsonの役割です。この2つを押さえておくと、既存のスキルやエージェント定義をプラグイン化する作業の全体像を把握しやすくなります。

ディレクトリ構成

Claude Codeプラグインは、以下のディレクトリ構造に従って作成します。

my-plugin/
├── .claude-plugin/
│   └── plugin.json      ← プラグインのメタデータと設定（省略可）
├── skills/              ← スキル定義（1スキル1フォルダ）
│   └── my-skill/
│       └── SKILL.md
├── agents/              ← エージェント定義
│   └── my-agent.md
├── hooks/               ← フック定義
│   └── hooks.json
├── commands/            ← カスタムコマンド（新規はskills/を推奨）
│   └── my-command.md
├── scripts/             ← フックから呼ぶスクリプト
│   └── rate-limit-check.sh
├── .mcp.json            ← MCPサーバー定義
└── .lsp.json            ← LSPサーバー定義

2026年10月時点の公式ドキュメントでは、plugin.jsonは.claude-plugin/の中に置き、それ以外のフォルダはすべてプラグインのルート直下に置くと定められています。plugin.json自体も省略でき、その場合は上記の標準の場所にあるファイルが自動で読み込まれます。

plugin.jsonの中核フィールド

.claude-plugin/plugin.jsonはプラグインの中核となる設定ファイルです。以下はHubSpot CRM操作を自動化するプラグインの設定例です（2026年10月時点の公式仕様に沿った書き方です）。

{
  "name": "hubspot-toolkit",
  "version": "1.2.0",
  "description": "HubSpot CRM操作を自動化するClaude Codeプラグイン",
  "author": {
    "name": "StartLink Inc."
  },
  "license": "MIT",
  "skills": ["./skills/"],
  "agents": ["./agents/crm-operator.md"],
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PLUGIN_ROOT}/scripts/rate-limit-check.sh"
          }
        ]
      }
    ]
  },
  "userConfig": {
    "hubspot_portal_id": {
      "type": "string",
      "title": "HubSpotポータルID",
      "description": "操作対象のHubSpotポータルID",
      "required": true
    },
    "api_rate_limit": {
      "type": "number",
      "title": "APIレート上限",
      "description": "10秒あたりのAPIリクエスト上限",
      "default": 100
    }
  }
}

この例では、skills/配下のプロパティ作成・ブログ公開・リードスコアリングといったスキルと、CRM操作を統括するエージェント、そしてBash実行前にAPIのレート制限を確認するフックが、1つのプラグインの中に位置づけられています。userConfigに宣言した値は、プラグインを有効にするときにユーザーへ入力を求める仕組みです。sensitive: trueを付けるとAPIキーのような値を入力時に伏せ字にでき、設定ファイルではなく安全な保管場所に保存されます。コンタクトへのプロパティ設定からブログ公開、リードスコアリングまでの一連のCRM運用フローを、個別のスキルとしてではなく1つのパッケージの中で連携させて管理できる点がポイントです。

フィールド一覧表

プラグインマーケットプレイスの使い方

Claude Codeのプラグインは、マーケットプレイス（プラグインのカタログ）から入れます。Anthropic公式のマーケットプレイス（claude-plugins-official）は初めて対話セッションを起動したときに自動で追加され、ほかのマーケットプレイスは自分で追加します。自作前にまず既存プラグインで似たものが無いか探してみる、という順序をおすすめします。

追加からインストールまでの手順

セッション内では/pluginでプラグイン画面を開き、Discoverタブで一覧から探してインストールできます。シェルからは次のコマンドで操作できます（2026年10月時点）。

# マーケットプレイスを追加（GitHubのowner/repo形式）
claude plugin marketplace add your-org/your-marketplace

# プラグインをインストール（名前@マーケットプレイス名）
claude plugin install hubspot-toolkit@your-marketplace

# インストール済みプラグイン一覧
claude plugin list

# プラグインのアップデート
claude plugin update hubspot-toolkit@your-marketplace

# プラグインのアンインストール
claude plugin uninstall hubspot-toolkit@your-marketplace

同じ操作はセッション内でも、/plugin marketplace add your-org/your-marketplace、/plugin install hubspot-toolkit@your-marketplaceのように実行できます。プラグインの検索は/plugin画面のDiscoverタブで行えます。インストール済みのプラグインについては、シェルからclaude plugin details <名前>を実行すると、同梱されるスキル・エージェント・フック・MCPサーバー・LSPサーバーの一覧と、常時消費するトークン量の見込みを確認できます。

インストール先のスコープ設計

インストールには--scopeでuser・project・localの3つのスコープを指定できます。省略するとuserになります。チームで使うプラグインはprojectで、自分専用のものはuserやlocalで入れる、という使い分けが基本パターンです。

projectスコープの設定をコミットしても、チームメンバーの手元にプラグインがダウンロードされるわけではありません。各メンバーが一度、同じインストールコマンドを実行する必要があります。マーケットプレイス自体をチームで共有したい場合は、claude plugin marketplace add your-org/your-marketplace --scope projectで.claude/settings.jsonに登録し、そのファイルをコミットします。

LSPサーバーの同梱によるコード理解の強化

LSP（Language Server Protocol）は、エディタとプログラミング言語のサービスを接続するための標準プロトコルです。Claude Codeプラグインは言語サーバーの起動方法を.lsp.jsonで宣言でき、有効にするとClaudeが編集後の型エラーなどの診断情報や、シンボル単位のコード移動を使えるようになります（2026年10月時点）。

LSPとは何か

もともとLSPは、コード補完や診断（Diagnostics）といったエディタの言語支援機能を、各エディタ・各言語ごとに個別実装せずに済むよう標準化したプロトコルです。Claude Codeのプラグインは、プラグイン自身がLSPサーバーとして動くのではなく、既存の言語サーバー（Goならgopls、Pythonならpyrightなど）を起動するコマンドと対象の拡張子を宣言する役割を担います。言語サーバー本体は、別途手元にインストールしておく必要があります。

連携の仕組みと活用例

連携の流れは、プラグインの.lsp.json→Claude Codeが言語サーバーを起動→診断情報・定義ジャンプ・参照検索の結果がClaudeに渡る、という経路になります。具体的には、Claudeが自分の編集で入れた型エラーや未解決のimportをビルド前に把握できる、テキスト検索ではなくシンボル単位で定義や参照を探せる、といった効果があります。主要な言語向けのプラグインは、Anthropic公式のマーケットプレイスにコードインテリジェンス（code intelligence）プラグインとして用意されています。

用意されていない言語は、自分で.lsp.jsonを書いて接続できます。ただし、言語サーバーが手元に無いとプラグインは起動に失敗するため、チームに配るプラグインでは必要なバイナリを案内しておきます。まずはSkillsとHooksだけのシンプルなプラグインから作り始め、必要になった段階でLSPの同梱を検討する、という順序が現実的です。

自社の業務に合わせたプラグイン化の判断基準

すべてのスキルやコマンドをプラグイン化する必要はありません。StartLinkでは、プラグイン化を検討する際に「再利用性（複数のプロジェクトで使う見込みがあるか）」「独立性（Skills・Agents・Hooksが複数連携する業務か）」「配布範囲（個人利用か、チーム・社内配布が前提か）」という3つの軸で判断することをおすすめしています。この3つのうち2つ以上に当てはまる業務は、プラグイン化する価値が高いと考えられます。例えばBtoBコンテンツ制作のように、複数のスキル・エージェント・フックが連携し、チームで共通利用する業務は3軸すべてに当てはまるためプラグイン化の優先度が高くなります。反対に、個人の環境で時々使うだけのコマンドは配布範囲・独立性のいずれにも当てはまりにくいため、優先度は下がります。

プラグイン化に向く業務・向かない業務

ただし、1回限りの一時的な作業や、他のプロジェクトで再利用する見込みがないスクリプトまでプラグイン化すると、かえって管理コストが増えてしまいます。プラグイン化にはplugin.jsonの保守やバージョン管理、更新時の再配布といった維持の手間が伴うため、使う頻度や範囲に対して管理コストが上回る形になります。単独で使うカスタムコマンドは.claude/commands/への直接配置で十分で、複数のスキルやエージェントと連携するものだけをプラグインにまとめる、という切り分けが現実的です。

自社にどこまでプラグイン化が必要かは、扱う業務の性質によって変わってきます。BtoBのコンテンツ制作を主軸にする組織であればBtoBマーケティング自動化プラグインの優先度が高く、CRM運用が業務の中心にある組織であればCRM連携プラグインから着手するのが合理的です。このように、企業様によって最適な形は異なりますので、自社の業務フローのどこにプラグイン化のニーズがあるかを最初に洗い出しておくと、開発の優先順位をつけやすくなります。

実務での活用パターン3つ

いずれのパターンにも共通しているのは、担当者の記憶や確認漏れに頼らず、フックによる自動チェックやコマンド1つでの環境構築といった「仕組み」で品質と再現性を担保している点です。新メンバーへの引き継ぎのたびに口頭やドキュメントで手順を説明する運用から、プラグインをインストールすれば誰が実行しても同じ環境が再現される運用へと切り替えられます。

自作プラグインの開発から配布までのステップ

自作プラグインは、既存のスキル・エージェント・フックをすでに持っている場合、それらをディレクトリに配置し直すだけで完成に近づきます。いきなり大きなプラグインを作ろうとせず、まずは自分がよく使っているカスタムコマンドを1つプラグイン化するところから始めて、動作を確認できたらSkillsやHooksを段階的に追加していく、という進め方をおすすめします。

雛形作成からローカルテストまで

# ステップ1: プラグインの雛形を生成（~/.claude/skills/my-plugin/ に作られる）
claude plugin init my-plugin

# ステップ4: 作成した場所（~/.claude/skills/my-plugin/）のまま、マニフェストと部品ファイルを検証
claude plugin validate ~/.claude/skills/my-plugin

# 読み込みの確認: 次のセッションから my-plugin@skills-dir として読み込まれ、インストール操作は不要
claude plugin details my-plugin

claude plugin initは~/.claude/skills/<名前>/に雛形を作り、場所を変えるフラグはありません。次のセッションから<名前>@skills-dirとして自動で読み込まれるため、このパスで作った場合は--plugin-dirを付ける必要はありません。作業用ディレクトリなど任意の場所で作りたい場合は、my-plugin/.claude-plugin/plugin.jsonを手作業で用意したうえで、次のように読み込みと検証を同じパスに揃えます。

# 任意の場所に作ったプラグインを、このセッションだけ読み込み
claude --plugin-dir ./my-plugin

# 同じパスを検証
claude plugin validate ./my-plugin

ステップ2では既存のスキルやエージェント定義をskills/・agents/・hooks/ディレクトリに配置し、ステップ3では標準の場所以外に置いたものだけplugin.jsonの対応するフィールドにパスを追加する流れが基本です。ステップ4のローカルテストで、意図したとおりにプラグインが読み込まれるかを確認してから配布に進みます。--plugin-dirで読み込んだプラグインはそのセッション限りで、インストールはされません。

パッケージングと配布方法

# 配布前に、作成されるリリースタグの内容を確認（--dry-run ではタグは作られない）
claude plugin tag ./my-plugin --dry-run

# 内容に問題がなければ、--dry-run を外して実際にタグを作成（--push を付けるとリモートへ送信）
claude plugin tag ./my-plugin

# 利用者側: 社内マーケットプレイスを追加して、プラグインを入れる
claude plugin marketplace add your-org/internal-marketplace
claude plugin install hubspot-crm-automation@internal-marketplace

配布の単位は、プラグインではなくマーケットプレイスです。.claude-plugin/marketplace.jsonでプラグインの一覧を記述したGitリポジトリ（GitHub・GitLabなど）、またはHTTPSで配信するmarketplace.json、共有フォルダに置いたカタログを用意し、利用者がmarketplace addで追加します。社内でしか使わないプラグインは、アクセス権を絞った社内用のリポジトリをマーケットプレイスにする形が適しています。新しい版を配るときはversionを上げます。versionを上げないと、利用者は手元のキャッシュ版のまま更新を受け取りません。

運用上の注意点とセキュリティ

プラグインは便利な反面、外部のコードを自分の開発環境に取り込むという性質上、セキュリティ面の確認を省略しないことが重要です。確認の軸は大きく2つあります。1つは配布元の確認とインストール前に表示される内容の確認、もう1つは自社開発プラグイン側でどこまで部品を絞るか、という視点です。以下でそれぞれの確認ポイントを整理します。

マーケットプレイスのセキュリティレビュー

公式ドキュメントでは、インストールしたプラグインはユーザー権限で任意のコードを実行できると明記されています。フックはシェルコマンドとして動き、MCPサーバーやLSPサーバーもマシン上でプロセスとして起動します。Anthropicは、プラグインに含まれるMCPサーバーやファイルの中身を管理しておらず、動作や後からの変更を保証しないとしています。マーケットプレイス名は公開元を示すだけで、中身の安全性を示すものではないため、どのマーケットプレイスから入れる場合も、インストール前に表示される詳細画面で同梱される部品を読んでから入れます。マーケットプレイスの自動更新をオンにしている場合は、確認済みのファイルが後から変わり得る点にも注意が必要です。

なお、詳細画面の「Will install」には、フックが存在することは表示されても、フックが何を実行するかは表示されません。配布元のソース（詳細画面の「Open homepage」や「View on GitHub」、またはマーケットプレイスのリポジトリ）を開き、次のファイルを読んでから入れます。

• hooks/hooks.json：各フックが実行するコマンド
• .mcp.json：各MCPサーバーの起動コマンドまたはURL
• bin/：ディレクトリ内の全ファイル

リポジトリを手元に取得できる場合は、claude --plugin-dir <プラグインのディレクトリ> plugin details <プラグイン名>で、セッションを起動せずに同梱物の一覧を確認する方法もあります。

自社開発プラグインの権限最小化

自社開発プラグインの場合は、同梱する部品を必要最小限に絞ることをおすすめします。特にBashコマンドを実行するフックや外部APIを呼び出すスキルを含むプラグインは、フックが実行するスクリプトの内容をレビューし、userConfigのsensitiveでAPIキーを保護し、利用側のpermissions設定と組み合わせて操作範囲を狭める設計が安全です。ただし、permissionsやサンドボックスが制限するのは、Claudeが行うツール呼び出し（プラグインのMCPツールの呼び出しや、bin/の実行ファイルをBash経由で動かす操作など）です。フックやモニター、MCPサーバー・LSPサーバーのプロセスは、Claude Codeがサンドボックスの外でユーザー権限のまま起動するため、permissionsでは制限されません。フックの安全性は、スクリプト自体のレビューで担保します。

関連コマンドとの組み合わせ

プラグインは単独の拡張機能としてだけでなく、Claude Codeの他の仕組みと組み合わさることで、一連の業務フローを1つのパッケージとして完結させられます。

カスタムコマンドとの関係

カスタムコマンドはプラグインの一部として同梱できます。単独で使うカスタムコマンドは.claude/commands/に配置しますが、複数のスキルやエージェントと連携するコマンドはプラグインにまとめることで、依存関係を明示的に管理できます。

MCPサーバーとHooksとの連携

Claude CodeのMCP（Model Context Protocol）サーバーをプラグインから呼び出すことで、外部サービスとの連携をプラグインに組み込めます。たとえば、HubSpot MCPサーバーやNotion MCPサーバーへの接続設定を、プラグインの.mcp.jsonまたはplugin.jsonのmcpServersに同梱できます。dependenciesは他のプラグインへの依存を宣言する欄で、MCPサーバーの宣言には使いません。また、Claude Code Hooksの設定はhooks/hooks.jsonまたはplugin.jsonのhooksフィールドに記述でき、プラグインを有効にしている間は定義されたフックが自動で読み込まれるため、ユーザーが手動でフック設定を追加する手間が省けます。API連携、フック、カスタムコマンドをそれぞれ個別に管理するのではなく、1つのプラグインの中で一気通貫に扱えることが、プラグインシステムを使う一番の利点だと考えています。

よくある質問

Q1. プラグインとMCPサーバーの違いは何ですか？

MCPサーバーは「外部データソースとの接続」を提供する仕組みで、HubSpot・freee・Notionなどの外部サービスからデータを取得するためのインターフェースです。プラグインは「Claude Codeの機能拡張」を行う仕組みで、MCPサーバー経由で取得したデータをどう処理するかのロジック（スキル・エージェント・フック）を定義します。多くの場合、プラグインがMCPサーバーの接続設定（.mcp.json）を同梱し、その上にスキルやエージェントを重ねる構成になります。

Q2. プラグインのセキュリティはどう担保されていますか？

プラグインはユーザー権限でコードを実行できるため、マーケットプレイスの名前に関わらず、インストール前に詳細画面で同梱される部品を確認し、さらに配布元のソースでhooks/hooks.jsonや.mcp.jsonの実行内容まで読む必要があります。自社開発プラグインの場合は、同梱する部品を必要最小限に絞り、フックのスクリプトをレビューすることをおすすめします。

Q3. 既存のSkillsやCommandsをプラグインに移行するにはどうすればよいですか？

プラグインのディレクトリを作り、既存の.claude/commands/・.claude/skills/・.claude/agents/のファイルを、プラグインのcommands/・skills/・agents/にコピーするのが基本です。標準の場所に置けば、plugin.jsonにパスを書かなくても読み込まれます。フックはsettings.jsonのhooksの内容をhooks/hooks.jsonに移します。移行後はclaude --plugin-dirで読み込み、claude plugin validateで検証してから配布します。なお、プラグインの部品はplugin.jsonのnameを名前空間として呼び出されるため、元のコマンド名や呼び出し方が変わる点に注意してください。

Q4. プラグインの依存関係はどう管理されますか？

plugin.jsonのdependenciesフィールドに、先に有効化が必要なプラグインを"name"または"name@marketplace"の形で並べます。{ "name": "...", "marketplace": "...", "version": "..." }の形で版の制約も指定できます。同じマーケットプレイスのプラグインなら名前だけで解決されます。

依存先は、claude plugin installの実行時に自動でインストールされます。/reload-plugins、マーケットプレイスの自動更新、claude plugin marketplace addでも、不足している依存先が取得されます。ただし、取得できない条件があります。別のマーケットプレイスにある依存先は、既定ではインストールされません。例外は、利用者がその依存先を同じスコープですでに導入・有効化している場合です。それ以外で入れるには、利用者がインストールしようとしている親プラグインを配布するマーケットプレイス（依存先側ではありません）のmarketplace.jsonで、allowCrossMarketplaceDependenciesOnに依存先のマーケットプレイス名を加えておく必要があります。参照されるのはこの親側の許可リストだけです。また、commandソースのプラグインや、headersHelperを設定した配布元の依存先は、Claude Codeが自動では入れないため、利用者が先に手動でインストールします（2026年10月時点）。

まとめ

Claude Codeのプラグインシステムは、Skills・Agents・Hooks・Commandsを1つのパッケージにまとめて配布・管理できる拡張メカニズムです。.claude-plugin/plugin.jsonでメタデータと部品の場所を定義し、マーケットプレイスを通じて共有できます。社内向けは、社内用のマーケットプレイスを作って配ります。BtoBコンテンツ制作パイプライン、CRM連携、テスト・CI統合など、業務単位でプラグイン化することで、担当者の記憶や引き継ぎ資料に頼らず、誰が実行しても同じ環境を再現できる仕組みになります。

最初の一歩としては、次の3ステップをおすすめします。

1. 自分がよく使っているカスタムコマンドやスキルを1つ選び、プラグイン化の対象として棚卸しする
2. claude plugin initで雛形を作成する（~/.claude/skills/<名前>/に作られます）か、任意の場所に.claude-plugin/plugin.jsonを手作業で用意し、既存ファイルをskills/・agents/・hooks/に配置する
3. 雛形を作った場合はclaude plugin validateで作成先を検証し、手作業で作った場合はclaude --plugin-dir ./my-pluginでローカルテストを行う。動作確認できたら、チーム向けの社内マーケットプレイスでの配布を検討する

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Code × Stitchでワイヤーフレーム・UIデザインを自動生成する方法
• Claude Codeのモデル選択とeffort設定ガイド｜Opus・Sonnet・Haikuとultrathinkの使い分け
• Claude Code × Chatwork連携｜顧客コミュニケーションを自動化する方法