Claude Codeのプラグインは「機能を増やす仕組み」というより、拡張一式をまとめて配る仕組みです。スラッシュコマンド、サブエージェント、スキル、hooks、MCPサーバー設定。この5種類はそれぞれ置き場所も設定ファイルも違いますが、プラグインは全部を1つの箱に入れて、1回のインストールで導入できるようにします。逆に言うと、1人で1リポジトリを回しているだけなら、急いで使う必要はありません。効いてくるのは「同じ構成を複数の場所へ揃えたくなったとき」です。
この記事は、Claude Codeでカスタムスキルやコマンドを作り始めた人と、チームに同じエージェント環境を配りたい人に向けて、プラグインの構造・導入手順・配布の仕組みを整理します。素材は公式ドキュメントと公式チェンジログ、それに自分の運用（スキル13個を無人Routineで常時運用）でプラグイン化を検討した判断です。
Claude Code公式ドキュメント: PluginsUnderstand what a Claude Code plugin is, when you need one instead of a standalone skill or MCP server, and which page to read to install or create one.code.claude.com
拡張が増えると、置き場所が散らばる
Claude Codeを使い込むと、拡張は自然に増えます。定型手順はスキル（SKILL.md）に、審査はサブエージェントに、破らせたくない操作はhooksに、外部サービスはMCPサーバーに。ただ、これらは置き場所がバラバラです。
- スラッシュコマンド:
.claude/commands/ - サブエージェント:
.claude/agents/ - スキル:
.claude/skills/ - hooks:
settings.jsonのhooks設定 - MCPサーバー:
.mcp.json
1リポジトリで完結しているうちは、これで困りません。困るのは、別のリポジトリでも同じ構成を使いたくなったとき、あるいはチームメンバーの環境に同じものを入れたくなったときです。5か所からのコピーを人手でやると、どこかが古いまま残ります。私も過去に、複数エージェント向けの指示書が微妙に食い違っていく「ドリフト」を止めるためにAGENTS.mdへ1本化した経緯があり、拡張の配布でも同じ問題が起きるのは想像がつきます。
プラグインの構造——5種類の拡張を1つの箱に入れる
プラグインは、この散らばった拡張をディレクトリ1つにまとめたパッケージです。公式ドキュメントの構造をそのまま示すと、次の形になります。
my-plugin/
├── .claude-plugin/
│ └── plugin.json # 名前・説明・バージョンなどのマニフェスト
├── commands/ # スラッシュコマンド
├── agents/ # サブエージェント
├── skills/ # スキル（SKILL.md）
├── hooks/ # hooks設定
└── .mcp.json # MCPサーバー定義
.claude-plugin/plugin.json が唯一の必須ファイルで、name と、任意で description や version を持ちます。あとは配りたい拡張の種類だけディレクトリを置けばよく、スキル1個だけのプラグインも成立します。
インストールされたプラグインのコマンドやスキルは、通常の拡張と同じように呼び出せます。つまり作る側の書き方は今までと同じで、変わるのは「入れ方」と「配り方」だけです。既にスキルの書き方を押さえていれば、プラグインのために新しく覚えることは梱包の作法くらいです。
Claude Codeのカスタムスキル作成ガイド｜SNS運用自動化の実例で学ぶ設計の勘所Claude Codeのカスタムスキル（SKILL.md）の作り方を、SNS運用を自動化している実際の構成を例に解説。最小構成の作成手順から、1スキル1責務・審査の分離・バージョン管理まで、運用で効いた設計の勘所をまとめます。www.tentspace.net導入は /plugin から——マーケットプレイスの正体はgitリポジトリ
プラグインの入手経路が「マーケットプレイス」です。名前は大げさですが、正体は .claude-plugin/marketplace.json というカタログファイルを置いたgitリポジトリ（またはURL）で、誰でも作れます。中央ストアに審査を通す、といった仕組みではありません。
導入は対話中の /plugin コマンドで完結します。
# マーケットプレイスを登録（GitHubのowner/repo形式やURLを指定）
/plugin marketplace add <owner>/<repo>
# カタログからプラグインをインストール
/plugin install <plugin名>@<マーケットプレイス名>
/plugin を引数なしで開くと、登録済みマーケットプレイスの一覧、インストール済みプラグインの有効・無効の切り替えができます。この「一覧できる」ことが、後で書くとおり運用上は重要になります。
チームへ配る——リポジトリのsettings.jsonで自動案内
チーム配布は、リポジトリの .claude/settings.json に使うマーケットプレイスとプラグインを宣言する方式です。公式ドキュメントの extraKnownMarketplaces と enabledPlugins を設定しておくと、そのリポジトリを信頼したメンバーがClaude Codeを起動したときに、宣言されたプラグインの導入が案内されます。
これで「新しいメンバーはREADMEの手順に沿って5か所へコピーしてください」がなくなります。プラグイン側を更新すれば配布先にも行き渡るので、冒頭に書いたドリフト問題への回答にもなっています。
便利な配布経路は、そのまま「入ってくる経路」になる
ここまでが入門の範囲ですが、公式チェンジログを追っていて認識が1つ変わりました。配る仕組みを持った瞬間、それは外から入ってくる経路にもなるということです。
2.1.251（確認日2026-08-30）には、プラグイン関連の修正が同時に3件入っています。マーケットプレイスのエントリが宣言するコマンドがプラグインディレクトリの外を指せた問題をpath-traversalエラーとして拒否する変更、MCPサーバー名のサニタイズ改善、マーケットプレイスの同時更新でバックグラウンドセッションがプラグインのスキルなしで起動してしまう不具合の修正です。
Claude Code公式チェンジログRelease notes for Claude Code, including new features, improvements, and bug fixes by version.code.claude.com1件目が示すのは、カタログファイルの記述次第でプラグインの外のファイルへ手が届きかけた、という事実です。マーケットプレイスは誰でも作れる分、「どこから入れるか」は自分で判定する必要があります。誰でも配れる経路は、パッケージレジストリと同じく供給網（サプライチェーン）として扱う必要がある——私はそう捉えています。
この方向は他社も同じで、GitHub CopilotはCustomizeタブをGAにして、MCPサーバー・プラグイン・スキルを1か所へ集約しました（2026-08-28の週次リリース）。集約する理由は利便性だけではなく、何が入っているかを数えられる場所を作るためだと私は読んでいます。
私はまだプラグイン化していない——直置きで足りる境界線
では自分の運用ではどうしたか。私はSNS運用をClaude Codeの無人Routineで回していて、.claude/skills/ にスキルが13個、審査用のサブエージェント、hooksのガードが常時入っています。プラグインの題材としては十分な規模ですが、現時点ではプラグイン化していません。理由は2つです。
1つ目は、配布先が1リポジトリしかないこと。拡張はすべてそのリポジトリの .claude/ 配下にあり、git管理そのものが配布とバージョン管理を兼ねています。動く環境が1つなら、梱包しても取り出す相手がいません。
2つ目は、無人運用では更新経路を増やしたくないこと。上で見たとおり、マーケットプレイス経由の配布は「外から更新が入ってくる経路」です。人が画面の前にいる開発なら気づけますが、無人のRoutineでは、スキルが変わったことに誰も気づかないまま実行が走ります。私の運用ではスキルの変更をPRとCHANGELOGで記録する決まりにしているので、この統制の外側に更新経路を足すことがマイナスになります。
逆に、次のどれかに当てはまるなら、プラグインを使う側に倒れると考えています。
- 同じ拡張セットを複数のリポジトリで使う（コピーの同期が発生している）
- チームメンバーの環境に同じ構成を揃えたい（オンボーディング手順が長い）
- 社内の共通スキルを1か所で更新して行き渡らせたい（配布とバージョン管理を分けたい）
判断軸は「箱が便利か」ではなく「配布先が複数あるか」。1か所なら直置き、複数ならプラグイン。それだけの話でした。
まとめ——作り方は変わらない、変わるのは配り方
プラグインは、スラッシュコマンド・サブエージェント・スキル・hooks・MCP設定という既存の拡張を1つの箱にまとめ、/plugin で導入・配布できるようにする仕組みです。拡張そのものの書き方は変わらないので、まずスキルやMCP設定を素で作れるようになってから、配布先が複数になった時点で梱包を考える、という順番で困りません。
そして配布を持つということは、入ってくる経路を持つということでもあります。どのマーケットプレイスを信頼するか、何が入っているかを定期的に数えるか。この2つを決めてから使い始めると、後で棚卸しに追われずに済みます。
次の一歩としては、箱に入れる中身側の記事が参考になるはずです。スキルの作り方と、MCPサーバー設定のスコープ設計をそれぞれまとめています。
Claude CodeにMCPサーバーを追加する設定ガイド｜3つのスコープと.mcp.jsonの使い分けClaude CodeへMCPサーバーを接続する設定方法を解説します。claude mcp addの基本、local・project・userの3スコープの使い分け、.mcp.jsonのチーム共有と環境変数展開、接続確認と権限設定、サーバーを足しすぎない判断軸をまとめます。www.tentspace.net