AIコーディングエージェント 2026.05.31 更新: 2026.06.01

Claude Codeのpluginをチームで使う前に：skills・hooks・marketplaceを分ける基準

3行まとめ

VisualClaude Code拡張の分け方手順、制御、共有、配布を分けます。

Skills

繰り返す作業手順を小さく残す。

Hooks

実行前後の制御と記録に使う。

Plugins

team共有と更新の単位にする。

Marketplace

配布元の信頼境界を分ける。

拡張を全部pluginにせず、用途と共有範囲で分けます。

Claude Codeの拡張は、作業手順を残すskills、実行前後を制御するhooks、複数projectへ配るplugins、配布元を扱うmarketplaceに分けると管理しやすくなります。
個人や1つのrepoで試す段階ではstandaloneの .claude/ 設定で十分です。複数projectで同じ手順を使うようになってからplugin化します。
marketplaceを追加することは、plugin catalogを信頼する判断です。公式、community、自社配布を同じ扱いにせず、install前のreviewと更新責任を決めます。

本文の事実確認には、Claude Code公式docsのCreate plugins、Discover plugins、Skills、Hooks referenceを使っています。Xで見かけるClaude Code skills、hooks、plugin marketplaceへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Visual導入前に決める項目チームで迷いやすい判断です。

Where

個人、project、pluginの置き場所。

Trigger

手動起動か自動発火かを決める。

共有範囲と更新責任を分ける。

Trust

marketplaceの信頼を確認する。

先に境界を決めると、設定が増えても追いやすくなります。

Claude Codeのskills、hooks、plugins、marketplaceの使い分け
個人設定、project設定、plugin、enterprise配布の分け方
plugin化する前に決める所有者と更新責任
hooksを作業手順ではなく制御として使う判断
marketplaceを追加するときの信頼境界
初週にどこまで導入すればよいか

Claude Codeを個人で使っている間は、便利なskillやslash commandを増やしてもあまり困りません。ところがチームで使い始めると、「誰の設定が正なのか」「repoごとの手順なのか」「pluginとして配るべきなのか」「hookで止めるべきなのか」が混ざります。

この記事では、Claude Codeの拡張をチーム導入する前に、置き場所、起動条件、共有範囲、信頼境界を分けて整理します。

前提知識

Visual公式docsで見る対象この記事で扱う拡張機構です。

項目	内容	見方
Skills		SKILL.mdで手順を定義します。
Hooks		eventに反応してshell commandを実行。
Plugins		skills、agents、hooks、MCPを束ねます。
Marketplace		plugin catalogからinstallします。

Claude Codeの拡張は、役割ごとに置き場所が異なります。

Claude Code公式docsでは、pluginsをskills、agents、hooks、MCP serversを含めてClaude Codeを拡張する仕組みとして説明しています。standaloneの .claude/ directoryは個人workflow、project固有のcustomization、quick experimentに向き、pluginsはteam共有、複数project、versioned release、marketplace配布に向くとされています。

Skills docsでは、skillは SKILL.md を中心にした手順で、frontmatterのdescriptionによりClaudeがいつ使うかを判断できると説明されています。Hooks referenceでは、SessionStart、UserPromptSubmit、UserPromptExpansion、PreToolUseなどのeventに対してshell commandを実行できる仕組みが説明されています。

この記事の扱う範囲

項目	役割
skills	繰り返し使う作業手順、review観点、release手順を残す
hooks	tool実行前、prompt投入時、command展開時などを制御する
plugins	skills、agents、hooks、MCP serversを束ねて共有する
marketplace	plugin catalogを追加し、個別pluginをinstallする
namespace	plugin由来のskill名を衝突しにくくする
MCP servers	pluginに含める場合、tool権限の配布として扱う

2026年5月31日時点で公開されているClaude Code公式docsを確認しています。導入時には、Claude Code version、社内のtool利用規程、plugin配布元、MCP serverの権限を確認してください。

注意点

この記事は、第三者pluginやcommunity marketplaceを無条件に推奨するものではありません。Claude Codeの拡張は、手順だけでなくshell command、hooks、MCP server、外部接続を含む場合があります。install前に中身と配布元を確認する前提です。

まず4つの置き場所に分ける

Visual置き場所の判断個人用か共有用かで分けます。

項目	内容	見方
Personal		自分の全projectで使う手順。
Project		repo固有の作業やreview基準。
Plugin		複数projectへ配る共通機能。
Enterprise		組織全体へ配る統制済み設定。

最初は小さく置き、共有が必要になってからplugin化します。

Claude Codeの拡張は、最初に置き場所を分けます。置き場所を決めずに便利なものを増やすと、同じ名前のskill、似たhook、古い手順が複数のrepoに散らばります。

置き場所	向くもの	避けたいもの
personal	自分だけの作業補助、試作skill	チームの必須手順
project	repo固有のreview基準、release手順	複数repoへ広げたい共通処理
plugin	チームで共有するskills、hooks、MCP設定	まだ試していない個人案
enterprise	組織全体の統制済み設定	projectごとの細かな例外

公式docsでは、quick iterationはstandalone設定から始め、共有できる段階になってからpluginへ変換する流れが示されています。この順番は実務でも扱いやすいです。

いきなりplugin化しない

初日にpluginを作ると、配布、更新、version、名前、review、rollbackを同時に考えることになります。まずproject skillとして使い、実際に何度も使われたらplugin化します。

repo固有のものはprojectに残す

たとえば、あるrepoだけのrelease手順、database migrationの確認、domain固有のreview観点はproject設定に残します。全repoに配ると、関係ないteamにも余計な文脈が入ります。

skillsは作業手順を小さく残す

Visualskillに向くものClaudeに読ませる作業手順です。

Review

diff確認やrisk整理の型。

Release

手順と確認項目を固定。

Docs

文書生成や要約の型。

Support

補助fileやscriptを同梱。

skillは大きな仕様書ではなく、迷いやすい作業の道しるべにします。

Skillは、Claudeへ「この作業ではこう進めてほしい」と渡す手順です。公式docsでは、SKILL.md にYAML frontmatterとmarkdown本文を書き、descriptionがClaudeの自動読み込み判断に使われると説明されています。

skillに向いているのは、毎回少しずつ忘れやすい作業です。PR説明の確認、release note作成、migration review、障害一次報告、ドキュメント整形など、手順と出力の型があるものに向いています。

skillに入れるもの

入れるもの	例
起動条件	どんな依頼で使うか
手順	先に確認するfile、見る順番
出力形式	summary、risks、tests、not run
補助file	template、example、reference
script	必要な検証commandやhelper

Skills docsでは、supporting filesをskill directoryに置けること、SKILL.md は要点に絞り、詳細なreferenceやexampleを別fileにできることも説明されています。これはチーム運用で大事です。1つのskillに全部詰め込むと、更新しにくくなります。

判断基準

skillは、作業者が迷う部分を減らすために使います。権限を止める、実行を強制する、危険操作をblockするためのものではありません。その役割はhooksに寄せます。

hooksは実行前後の制御に使う

Visualhookで制御する場面agentの行動前後で確認します。

項目	内容	見方
PreToolUse		危険なtool実行前に止める。
UserPromptSubmit		prompt投入時に文脈を足す。
UserPromptExpansion		skillやcommandの直接実行を制御。
SessionStart		session開始時に準備を行う。

hooksは作業手順ではなく、制御と記録のために使います。

Hooksは、Claude Codeのlifecycle eventに反応してshell commandを実行する仕組みです。Hooks referenceでは、SessionStart、UserPromptSubmit、UserPromptExpansion、PreToolUseなどのeventが説明されています。

skillが「どう進めるか」を伝えるものなら、hookは「このタイミングで確認する」「この操作は止める」「この情報を足す」という制御です。作業手順をhookへ入れると、見えないところで処理が増え、team memberが挙動を理解しにくくなります。

hookに向くもの

event	使いどころ
PreToolUse	危険なcommandやfile操作の前に止める
UserPromptSubmit	prompt投入時に注意事項やcontextを足す
UserPromptExpansion	skillやslash commandの直接実行を制御する
SessionStart	session開始時に準備や案内を出す

Hooks referenceでは、UserPromptExpansionがskillやcustom commandの直接起動にも反応し、blockやadditional contextを返せることが説明されています。これは、PreToolUseだけでは拾えない経路を制御したい時に重要です。

hookを増やしすぎない

hookは便利ですが、増やしすぎると「Claudeがなぜ止まったのか」「どのhookがcontextを足したのか」が追いにくくなります。最初は、危険な操作を止めるhook、必須contextを足すhook、ログを残すhookのように数を絞ります。

pluginは共有と更新の単位にする

Visualplugin化する条件teamへ配るかで判断します。

Shared

複数projectで同じ手順を使う。

Versioned

更新履歴とreleaseを持たせる。

Bundled

skills、hooks、MCPを束ねる。

Namespaced

名前衝突を避けやすい。

pluginは便利な箱ですが、所有者と更新責任も一緒に生まれます。

Pluginは、teamやcommunityへ配るための単位です。公式docsでは、pluginは .claude-plugin/plugin.json を持つdirectoryで、skills、agents、hooks、MCP serversを束ねられると説明されています。

plugin化する条件は、「便利だから」ではありません。複数projectで同じ拡張が使われ、更新責任者がいて、versionやreleaseを管理したい場合にplugin化します。

plugin化する前の確認

確認	内容
利用範囲	何repo、何teamで使うか
所有者	誰が更新し、誰がreviewするか
rollback	壊れた時に戻せるか
release note	変更内容を読めるか
test	skillやhookの動作をどう確認するか

pluginは、共有しやすい一方で、壊れた時の影響範囲も広がります。特にhooksやMCP serverを含むpluginは、単なるprompt集より強い影響を持ちます。

namespaced skillの利点

公式docsでは、plugin skillsは plugin-name:skill-name のnamespaceを持つため、他levelのskillと衝突しにくいと説明されています。短い名前の便利さより、チームでは衝突しにくさが大事です。

marketplaceは配布元の信頼で分ける

Visualmarketplaceの分類install元を混ぜないための整理です。

項目	内容	見方
Official		Anthropic公式のcatalog。
Community		第三者pluginを個別に評価。
Demo		仕組み理解やsample用途。
Internal		自社pluginを管理して配る。

marketplace追加は、pluginをinstallする前の信頼判断です。

Claude CodeのDiscover plugins docsでは、marketplaceはplugin catalogであり、まずmarketplaceを追加し、その後で個別pluginをinstallする2段階の流れだと説明されています。app storeを追加してから、必要なappを選ぶイメージです。

公式docsでは、official Anthropic marketplaceがClaude Code起動時に利用可能で、/plugin install <name>@claude-plugins-official の形でinstallできると説明されています。community marketplaceやdemo marketplaceは、必要に応じて手動で追加します。

marketplaceの分類

種類	扱い
official	公式catalogとして扱うが、plugin単位で内容を見る
community	third-partyとして中身、権限、更新履歴を見る
demo	仕組み理解やsampleとして扱う
internal	自社でreview、pin、配布する

community marketplaceは、第三者pluginを使える便利な入口です。一方で、automated validationやsafety screeningがあるとしても、自社のsecurity reviewを置き換えるものではありません。

marketplace追加時の質問

誰がこのmarketplaceを追加してよいか
pluginのinstall申請は必要か
pluginのversionやcommitを固定するか
hooksやMCP serverを含むpluginを許可するか
uninstallやrollback手順はあるか

marketplaceを増やすほど、install候補は増えます。候補が増えること自体は悪くありませんが、信頼境界が曖昧なまま増やすと、後で棚卸しが大変になります。

名前衝突とnamespaceを先に決める

Visualcommand名の決め方呼び出し名の混線を防ぎます。

項目	内容	見方
Personal		短い名前でも衝突に注意。
Project		repo固有の名前を明確に。
Plugin		plugin-name:skillで区別。
Command		skillとcommandの優先関係を見る。

共有するほど、短い名前より衝突しにくさが大事になります。

Claude CodeのSkills docsでは、skillの置き場所によってcommand nameの決まり方が変わると説明されています。personalやprojectのskillはdirectory nameがcommand nameになり、plugin内のskillはplugin nameでnamespaceされます。

チームで問題になりやすいのは、/review、/deploy、/release のような短い名前です。個人では便利ですが、projectやpluginが増えると意味が揺れます。

命名の方針

用途	名前の考え方
personal	自分がわかる短い名前でもよい
project	repo固有だとわかる名前にする
plugin	namespace込みで読める名前にする
enterprise	組織標準とわかる名前にする

Skills docsでは、skillとcommandが同じ名前を持つ場合、skillが優先されることも説明されています。既存の .claude/commands/ があるteamでは、skill導入前に名前を棚卸しします。

MCP serverをpluginに含める時の注意

VisualMCP同梱の確認点tool権限を一緒に見ます。

Scope

どのprojectで使うtoolかを限定。

Secrets

tokenやkeyをpluginに入れない。

Network

外部接続先を説明できるように。

Approval

危険操作はhookや手順で止める。

MCPを配る時は、手順だけでなくtool権限も配っていると考えます。

Claude Codeのpluginは、skillsやhooksだけでなくMCP serversも束ねられます。これは便利ですが、MCP serverはtool権限を増やす入口でもあります。

たとえばbrowser操作、GitHub、database、社内API、file操作をするMCP serverをpluginに含める場合、そのpluginをinstallしたteam memberは、手順だけでなくtoolの入口も受け取ります。plugin reviewでは、promptやskill本文だけでなく、MCP serverの接続先、必要なsecret、実行可能な操作を確認します。

MCP同梱pluginのreview観点

観点	確認すること
接続先	外部API、社内API、local process
secret	tokenやpasswordをpluginに含めていないか
権限	read-onlyかwrite可能か
audit	tool callの記録を残せるか
rollback	server停止やplugin uninstallで戻せるか

MCP serverの権限設計は、MCP更新で壊さないための確認手順でも扱っています。plugin化する時は、MCPの仕様更新やclient側のtool表示も確認します。

最小構成の始め方

Visual最初の構成小さく始める形です。

項目	内容	見方
One skill		review手順を1つ作る。
One hook		危険操作の前だけ止める。
No MCP		初回はtool追加を避ける。
No marketplace		自社評価前は個別installにする。

最初からmarketplace化せず、使われる手順だけ残します。

最初の1週間は、plugin marketplaceを増やすより、使われる手順を1つ作る方が効果的です。おすすめは、project skillを1つ、hookを1つ、内部リンクされた手順docを1つだけ置く形です。

最初の構成例

.claude/
  skills/
    pr-review-check/
      SKILL.md
      examples/
        output.md
  settings.json

pr-review-check には、PRを見る順番、テスト確認、risk、not runの書き方を入れます。settings.json には、危険なcommandを止める最小限のhookだけを入れます。MCP serverやmarketplace追加は、初回から入れません。

初回skillに入れる内容

いつ使うかをdescriptionに書く
見るfileやdiffの順番を書く
出力形式を短く固定する
実行してよいcommandと、実行しないcommandを分ける
うまくいった出力例を1つ置く

この構成なら、チームが使うかどうかを観察できます。使われないskillをplugin化しても、管理対象が増えるだけです。

導入初週の進め方

Visual1週間の導入順拡張を段階的に共有します。

1日目
project skillを1つ作る。
2日目
direct invocationと自動起動を試す。
3日目
PreToolUse hookを1つ追加。
5日目
複数repoで使うかを確認。
7日目
plugin化とmarketplace方針を決める。

使われたものだけ共有物へ昇格させると、管理が軽くなります。

Claude Code拡張の導入初週は、便利なものを集める週ではありません。team memberが読める、直せる、止められる形にする週です。

日	やること	完了条件
1日目	project skillを1つ作る	`/skill-name` で直接起動できる
2日目	自動起動と直接起動を試す	descriptionが過剰に広くない
3日目	hookを1つ追加する	何を止めるhookか説明できる
5日目	2つ目のrepoで必要か確認する	共有価値があるか判断できる
7日目	plugin化するか決める	所有者、version、rollbackが決まる

plugin化の合図

2つ以上のrepoで同じskillが使われている
skill本文の修正が複数repoへ散らばっている
hookやMCP serverを一緒に管理したい
versionを固定したい
install手順を標準化したい

この条件を満たしてからplugin化します。チーム向けの基準や禁止操作は、チーム向けAGENTS.mdテンプレートと組み合わせると、Claude Code以外のagentにも展開しやすくなります。

FAQ

Visualよくある迷いClaude Code拡張で詰まりやすい点です。

Skill or plugin?

共有範囲で分けます。

Hook or skill?

制御か手順かで分けます。

Marketplace?

配布元の信頼で分けます。

MCP?

tool権限の配布として扱います。

迷ったら、誰が使い、誰が更新し、何を実行できるかを見ます。

skillとpluginは何が違いますか

skillは作業手順です。pluginは、skill、agent、hook、MCP serverを束ねて共有する配布単位です。1人や1repoだけで使うならskillで十分です。複数projectへ配り、更新責任を持つならpluginを検討します。

hookとskillはどう分けますか

skillはClaudeへ読ませる手順、hookはeventに応じてshell commandを実行する制御です。review手順はskill、危険なtool実行前のblockはhookに寄せます。

official marketplaceなら無条件で入れてよいですか

無条件にはしません。official marketplaceは信頼しやすい配布元ですが、pluginごとに含まれるskills、hooks、MCP server、必要権限を確認します。teamで使うならinstall申請や更新方針も決めます。

community pluginは使わない方がよいですか

使うかどうかは、配布元、commit固定、内容review、権限、更新頻度で判断します。第三者pluginは、特にhooksやMCP serverを含む場合、prompt集より強い影響を持ちます。

Codexや他のagentにも同じ考え方を使えますか

使えます。形式は違っても、作業手順、実行制御、共有単位、tool権限を分ける考え方は共通です。Codex側の基本設計は、Codex 101をチーム導入に使う手順でも整理しています。

参照した主な情報源

Claude Code Docs: Create plugins

https://code.claude.com/docs/en/plugins

Claude Code Docs: Discover and install prebuilt plugins through marketplaces

https://code.claude.com/docs/en/discover-plugins

Claude Code Docs: Skills

https://code.claude.com/docs/en/skills

Claude Code Docs: Hooks reference

https://code.claude.com/docs/en/hooks

次に読むなら

チーム向けAGENTS.mdテンプレート

agentへ渡す権限、禁止操作、テスト手順、レビュー基準をrepo側に残す考え方を確認できます。

Codex 101をチーム導入に使う

AI coding agentをチームに入れる時の権限、AGENTS.md、評価タスクの決め方を整理できます。

MCP更新で壊さないための確認手順

pluginにMCP serverを含める時に、仕様、SDK、認可、Toolsを分けて確認できます。

更新履歴

Visual確認と更新の記録Claude Code拡張は更新されるため確認日を残します。

2026年5月31日
Claude Code公式docsのplugins、discover plugins、skills、hooksを確認して初版を作成しました。

導入時には公式docsと利用中のClaude Code versionを確認してください。

2026年5月31日: Claude Code公式docsのplugins、discover plugins、skills、hooksを確認し、初版を作成しました。