結論:Claude Code のプラグインは、skills・commands・subagents(agents)・MCP サーバー・hooks・LSP サーバーなどを1つのディレクトリに束ねて配布する仕組み。マーケットプレイスを追加してインストールし、.claude/settings.json 経由でチームへ一括展開できます(2026年6月時点・公式仕様ベース)。
- 何を束ねられるか:skills / commands / agents / hooks / MCP / LSP / monitors を1リポジトリに同梱
- 導入の流れ:
/plugin marketplace addでカタログを登録 →/plugin installで個別に入れる - チーム共有:
extraKnownMarketplacesとenabledPluginsをプロジェクト設定に書く
対象読者:複数プロジェクトや複数人で Claude Code を使っていて、独自の skill・agent・hook を毎回コピーするのに疲れている開発者・PM・テックリード。
今日できること:手元の .claude/ 設定を plugin.json 付きディレクトリに切り出し、ローカルマーケットプレイスとして --plugin-dir で読み込んで動作確認するところまで。
正直に言うと、私が複数のクライアント案件で Claude Code を回し始めて最初にぶつかったのが「設定の使い回し問題」でした。あるプロジェクトで作った /deploy スキルや PostToolUse の lint フックを、別のリポジトリにも入れたい。けれど .claude/commands/ や settings.json を毎回コピペすると、どこかで版がズレて「あっちのリポでは動くのにこっちでは動かない」が必ず起きる。100社以上の現場を見てきましたが、これは規模を問わず発生します。
その答えがプラグインです。公式ドキュメントでも、スタンドアロン(.claude/ ディレクトリ)はあくまで「個人・単一プロジェクト・実験用」、共有や版管理が要るなら「プラグイン」と整理されています。この記事では、その境界線と、実際にどう束ねてどう配るかを実装視点でまとめます。
プラグインとは何か — 何を1つに束ねられるのか
Claude Code のプラグインは、独立したディレクトリに各種コンポーネントを置き、必要なら .claude-plugin/plugin.json というマニフェストで「名前・説明・バージョン」を宣言したものです。プラグイン経由で配布したスキルは /plugin-name:skill-name のように名前空間付きで呼ばれます。これは複数のプラグインが同名スキルを持っても衝突しないようにするためです。
公式の「Plugin structure overview」に従うと、プラグインのルート直下に置けるディレクトリ・ファイルは次のとおりです。
| ディレクトリ / ファイル | 役割 |
|---|---|
.claude-plugin/plugin.json |
マニフェスト(名前・説明・バージョン等)。これだけは .claude-plugin/ 内に置く |
skills/ |
<name>/SKILL.md 形式のスキル。新規プラグインはこちらが推奨 |
commands/ |
フラットな Markdown のスキル。互換用(新規は skills/ を使う) |
agents/ |
カスタムサブエージェント定義 |
hooks/hooks.json |
イベントハンドラ(PostToolUse 等) |
.mcp.json |
MCP サーバー設定 |
.lsp.json |
LSP サーバー設定(コードインテリジェンス用) |
monitors/monitors.json |
バックグラウンド監視(ログ追従など) |
bin/ |
有効時に Bash の PATH へ追加される実行ファイル |
settings.json |
プラグイン有効時に適用される既定設定 |
ここで 最大のハマりどころを1つ。公式が Warning として明示しているのですが、commands/ agents/ skills/ hooks/ を .claude-plugin/ の中に入れてはいけません。.claude-plugin/ に入れるのは plugin.json だけ。残りはすべてプラグインのルート直下に置きます。私も最初これを取り違えて「スキルが一覧に出ない」と30分溶かしました。
マニフェストの最小形は次のとおりです。version は任意ですが、設定するとその文字列を変えたときだけ利用者に更新が届きます(git 配布で省略するとコミット SHA が版になります)。
{
"name": "my-first-plugin",
"description": "A greeting plugin to learn the basics",
"version": "1.0.0",
"author": {
"name": "Your Name"
}
}
commands と skills の違いでつまずく人が多いので補足します。歴史的に commands/(フラットな .md)が先にあり、現在は skills/(<name>/SKILL.md のフォルダ形式)が新規プラグインの推奨です。どちらも「呼べるスキル」になりますが、これから作るなら skills/ 一択で考えて差し支えありません。
関連して、サブエージェントを束ねたいならサブエージェントの並列実行の解説、MCP サーバーを同梱するならClaude Code の MCP 実践ガイドも合わせて読むと、各コンポーネント単体の作法が掴めます。

マーケットプレイスを追加してプラグインを入れる
プラグインの導入は「①マーケットプレイス(カタログ)を追加する → ②そのカタログから個別プラグインをインストールする」の2段階です。アプリストアを端末に登録してから、必要なアプリだけ落とすイメージ、と公式も説明しています。
まず手を動かすなら、公式が用意しているデモマーケットプレイス(anthropics/claude-code)で流れを掴むのが早いです。
- マーケットプレイスを追加する:
/plugin marketplace add anthropics/claude-codeを実行してカタログを取得 - プラグインマネージャを開く:
/pluginを実行。Discover / Installed / Marketplaces / Errors の4タブを Tab で切り替えられる - Discover タブで中身を確認する:選択するとそのプラグインが追加する commands・agents・skills・hooks・MCP/LSP サーバーの一覧と、コンテキスト消費の目安を確認できる
- インストールする:コマンドからなら
/plugin install commit-commands@claude-code-plugins(既定はユーザースコープ) - 反映する:
/reload-pluginsを実行して再起動なしで有効化 - 使う:プラグインのスキルは名前空間付きなので、たとえば
/commit-commands:commitのように呼ぶ
マーケットプレイスの追加元は GitHub の owner/repo 形式のほか、git URL、ローカルパス、marketplace.json を直接配信する URL に対応します。代表例を並べておきます。
# GitHub の owner/repo 形式
/plugin marketplace add anthropics/claude-code
# 非 GitHub の git ホスト(.git を付ける)
/plugin marketplace add https://gitlab.com/company/plugins.git
# ブランチ / タグを指定(# でref)
/plugin marketplace add https://gitlab.com/company/plugins.git#v1.0.0
# ローカルディレクトリ(開発・検証時)
/plugin marketplace add ./my-marketplace
インストール・無効化・削除のコマンドも押さえておきましょう。install は既定でユーザースコープ(全プロジェクト共通)です。
# インストール
/plugin install plugin-name@marketplace-name
# 一時的に無効化(アンインストールせず)
/plugin disable plugin-name@marketplace-name
# 再有効化
/plugin enable plugin-name@marketplace-name
# 完全に削除
/plugin uninstall plugin-name@marketplace-name
公式の Anthropic マーケットプレイス(claude-plugins-official)は起動時に自動で利用可能です。たとえば GitHub 連携を入れるなら /plugin install github@claude-plugins-official。コミュニティマーケットプレイスは手動追加で、/plugin marketplace add anthropics/claude-plugins-community 後に @claude-community 名でインストールします。
もし /plugin が「unknown command」になる場合は、Claude Code のバージョンが古い可能性が高いです。claude --version で確認し、Homebrew なら brew upgrade claude-code、npm なら npm install -g @anthropic-ai/claude-code@latest で更新してから再起動してください。
チームで共有する — 設定ファイルで配布する
ここがプラグインの真価です。1人で /plugin install するだけならスタンドアロン設定と大差ありませんが、チーム全員に同じ拡張を自動で配るとなると話が変わります。
やり方は、プロジェクトの .claude/settings.json に extraKnownMarketplaces を書くこと。リポジトリのフォルダを各メンバーが trust すると、Claude Code がそのマーケットプレイスのインストールを促します。
{
"extraKnownMarketplaces": {
"company-tools": {
"source": {
"source": "github",
"repo": "your-org/claude-plugins"
}
}
}
}
さらに「どのプラグインを既定で有効にするか」まで指定したい場合は enabledPlugins を併記します。キーは プラグイン名@マーケットプレイス名 形式です。
{
"enabledPlugins": {
"code-formatter@company-tools": true,
"deployment-tools@company-tools": true
}
}
運用上の注意を2点。1つ目、マーケットプレイスの状態はプロジェクトごとではなくユーザーごとに1回、~/.claude/plugins/known_marketplaces.json に保存されます。git worktree を使っていても相対パス指定はメインのチェックアウトを指すので、全 worktree で同じマーケットプレイスを共有します。2つ目、社内限定にしたいならプライベートリポジトリでマーケットプレイスをホストできます。手動インストール時は既存の git 認証情報(gh auth login 等)が使われ、背景での自動更新には GITHUB_TOKEN などの環境変数が要ります。
厳格に絞りたい組織向けには、管理設定(managed settings)の strictKnownMarketplaces で「追加できるマーケットプレイスの許可リスト」を強制できます。空配列 [] で全面ロックダウン、ソースの配列で許可リスト方式、という挙動です。
コードインテリジェンス系プラグインなどの実用例
「で、実際どのプラグインを入れると効くのか」。私が現場でまず勧めるのはコードインテリジェンス(LSP)系プラグインです。これは Claude Code 内蔵の LSP ツールを有効化し、編集直後に型エラー・未解決インポート・構文エラーを自動で拾ってその場で直してくれます。VS Code のコード補完を支えているのと同じ Language Server Protocol の仕組みです。
公式マーケットプレイスに収録されている主な LSP プラグインと、必要なバイナリは次のとおりです(利用には各言語サーバーのバイナリが端末に入っている必要があります)。
| 言語 | プラグイン | 必要バイナリ |
|---|---|---|
| TypeScript | typescript-lsp |
typescript-language-server |
| Python | pyright-lsp |
pyright-langserver |
| Go | gopls-lsp |
gopls |
| Rust | rust-analyzer-lsp |
rust-analyzer |
| Java | jdtls-lsp |
jdtls |
| PHP | php-lsp |
intelephense |
このカテゴリで Claude が得るのは大きく2つ。自動診断(編集ごとに言語サーバーが解析し、エラー・警告を自動報告。Claude が自分でミスに気づいて同じターンで直す)と、コードナビゲーション(定義ジャンプ・参照検索・ホバー型情報・実装検索・呼び出し階層)です。grep ベースより正確に追える、という公式の説明どおりで、体感としても「直したつもりの型ミスをその場で潰す」精度が上がります。
コードインテリジェンス以外の代表例も挙げておきます。いずれも公式マーケットプレイスのカテゴリです。
- 外部連携(MCP 同梱):
github/gitlab/linear/notion/slack/sentry/figma/supabaseなど。MCP サーバーを手設定なしで繋げる - 自動セキュリティレビュー:
security-guidance。Claude の各変更を一般的な脆弱性観点でレビューし、同セッション内で修正を指示 - 開発ワークフロー:
commit-commands(commit/push/PR 作成)、pr-review-toolkit(PR レビュー用エージェント群)、plugin-dev(プラグイン自作ツールキット)
フック(hooks)で format / test / 通知を自動化したい場合は、Claude Code の hooks 自動化の解説も参照してください。プラグインは、そうした hooks 設定ごとチームに配れるのが利点です。
自作プラグインの構造をつかむ — 既存設定からの移行
最後に、自分の .claude/ 設定をプラグイン化する流れを概観します。公式の「Convert existing configurations to plugins」に沿うと、ゼロから書く必要はなく既存ファイルの移設でほぼ完了します。
- プラグイン用ディレクトリと
.claude-plugin/を作る:mkdir -p my-plugin/.claude-plugin my-plugin/.claude-plugin/plugin.jsonを作成し、name/description/versionを書く- 既存ファイルをルート直下へコピーする:
commands/agents/skillsをmy-plugin/配下へ - フックを移す:
my-plugin/hooks/hooks.jsonを作り、settings.jsonのhooksオブジェクトをそのまま貼る(フォーマットは同じ) - ローカル読み込みで検証する:
claude --plugin-dir ./my-pluginで起動し、各コンポーネントを確認 - 変更を反映する:編集のたびに
/reload-pluginsで再起動なしに取り込む
移行時に変わるのは「保存場所と共有性」です。スタンドアロンでは .claude/commands/ にあり1プロジェクト限定だったものが、プラグインでは plugin-name/commands/ に移り、マーケットプレイス経由で共有・版管理できるようになります。フックは settings.json から hooks/hooks.json へ移ります。
動作確認には --plugin-dir が便利です。複数指定すれば同時に複数プラグインを読み込めます。
# 単体読み込み
claude --plugin-dir ./my-plugin
# 複数同時読み込み
claude --plugin-dir ./plugin-one --plugin-dir ./plugin-two
チーム配布まで持っていくなら、.claude-plugin/marketplace.json というカタログを作ってプラグインを列挙します。最小形は次のとおり。source に "./plugins/..." のような相対パスや GitHub リポジトリを指定できます。
{
"name": "company-tools",
"owner": {
"name": "DevTools Team",
"email": "[email protected]"
},
"plugins": [
{
"name": "code-formatter",
"source": "./plugins/formatter",
"description": "Automatic code formatting on save"
}
]
}
公開前のバリデーションは claude plugin validate .(または Claude Code 内で /plugin validate .)で行えます。マーケットプレイスディレクトリに対して実行すると、JSON 構文・プラグイン名の重複・パストラバーサル・各 plugin.json との版整合をチェックしてくれます。
よくある失敗パターン
現場で繰り返し見た落とし穴を、❌/⭕形式で4つ。
- ❌
commands/やskills/を.claude-plugin/の中に入れる → ⭕.claude-plugin/に置くのはplugin.jsonだけ。残りはルート直下 - ❌
plugin.jsonに"version": "1.0.0"を据え置いたまま新コミットを push → ⭕ 利用者には更新が届かない。リリースごとにversionを上げるか、省略してコミット SHA を版にする - ❌ プラグイン内から
../shared-utilsのように外部ファイルを参照する → ⭕ インストール時にキャッシュへコピーされ外は持ってこない。共有はシンボリックリンクで - ❌ URL 配信の
marketplace.jsonで相対パスのsourceを使う → ⭕ URL 方式はmarketplace.json本体しか落とさない。GitHub / npm / git URL ソースにする
FAQ
Q. プラグインとスタンドアロン設定、どちらを使うべき?
個人・単一プロジェクト・実験段階ならスタンドアロン(.claude/)で素早く回し、共有・複数プロジェクト・版管理が要るタイミングでプラグインに切り出す、という二段構えが公式推奨です。スキル名を /hello のように短くしたいならスタンドアロン、/my-plugin:hello の名前空間付きで衝突回避したいならプラグインです。
Q. プラグインを入れたら設定変更は即反映される?
セッション中にインストール・有効化・無効化したら /reload-plugins を実行します。再起動なしで plugins・skills・agents・hooks・MCP/LSP サーバーが読み直されます。
Q. 安全性は?
プラグインとマーケットプレイスはユーザー権限で任意のコードを実行しうる「高信頼コンポーネント」です。Anthropic は第三者プラグインの中身を検証していないため、信頼できるソースだけ追加・インストールしてください。組織は strictKnownMarketplaces で追加可能なソースを制限できます。
Claude Code をチームに定着させたい方へ
プラグイン化・マーケットプレイス運用は「設定を配る」だけでなく「チームの開発標準をコード化する」取り組みです。Uravation では Claude Code の社内導入・個別指導・受託開発を支援しています。今日の3アクション:
- 手元の
.claude/設定を1つplugin.json付きディレクトリに切り出し、--plugin-dirで読み込んでみる - コードインテリジェンス系プラグイン(自分の言語のもの)を
/plugin installして自動診断を体感する - チーム共有が要るなら
extraKnownMarketplacesをプロジェクトの.claude/settings.jsonに下書きする
次回は「プラグインに hooks を束ねて CI 相当の自動チェックを配る」実装編を予定しています。
出典
- Claude Code 公式ドキュメント「Create plugins」
- Claude Code 公式ドキュメント「Create and distribute a plugin marketplace」
- Claude Code 公式ドキュメント「Discover and install prebuilt plugins」
- Claude Code 公式ドキュメント「Plugins reference」
- Claude Code 公式ドキュメント「Settings」
著者:佐藤傑(さとう・すぐる) 株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。