Claude CodeのSkills対Plugins — それぞれの役割と使い分け | OpenAIToolsHub

訳者注: この記事はAI翻訳ベースで、Jim Liu（シドニーの個人開発者）が用語と文章の自然さを校閲しました。誤訳や不自然な表現があれば、メールでご指摘ください。原文（英語）: English.

Claude Codeの「スキル（Skill）」vs「プラグイン（Plugin）」— それぞれの役割と使い分けの勘所

スキルとプラグインは、どちらもClaude Codeを拡張するための手段ですが、解決しようとする課題が異なります。スキルはオンデマンドで読み込まれる「再利用可能な指示（Markdownファイル）」です。対してプラグインは、複数のスキル、フック、サブエージェント、スラッシュコマンド、そしてMCPサーバーを1つにまとめた「配布ユニット」です。

混乱の元は、プラグインの中にスキルを含めることができる（0個でも複数でも可）という点にあります。つまり「スキルかプラグインか」という二択ではなく、スキルはプラグインを構成する部品の1つなのです。

TL;DR（要約）

スキル：YAMLフロントマターを含む単一のMarkdownファイル（例：~/.claude/skills/{name}/SKILL.md）。ユーザーの依頼内容がスキルの「説明（description）」と一致したときに、Claudeが自動的に読み込みます。

プラグイン：マーケットプレイスやGitリポジトリ経由で配布されるパッケージ。スキル、フック（特定イベントで実行されるBashスクリプト）、サブエージェント（特化型ペルソナ）、スラッシュコマンド、MCPサーバーを同梱できます。

スキルを作るべき時：週に2回以上行う、プロジェクト特有の知識（ファイルパス、内部API、命名規則など）に依存する繰り返しワークフローがある場合。

プラグインを導入すべき時：GitHub、Postgres、Figmaなどの外部システムと連携したい場合。すでに誰かが作成したツールセットを利用できます。

成熟したClaude Codeのセットアップでは、通常、チーム固有の慣習のための「ローカルスキル」を数個と、外部システム連携のための「プラグイン」を数個、両方を組み合わせて使用します。

スキル（Skill）の正体

スキルとは、特定のトリガー（説明文）によって制御され、必要に応じてコンテキストに注入されるプロンプトです。具体的には以下のような形をしています。

---
name: publish-blog
description: コードをデプロイせずに新しい記事を公開したい時に使用。スラッグの重複チェック、マルチロケールのINSERT、IndexNowへの送信を処理する。
---

まず `scripts/publish_blog.py --help` を読んでください。
その上で：(1) DBで重複チェック、(2) drafts/ ディレクトリの解析、(3) SSH経由でINSERT、(4) curlで公開確認、を行ってください。

Claudeは常に会話を監視しています。ユーザーの入力がスキルの description と一致すると、このMarkdownの内容がコンテキストに読み込まれ、Claudeはその指示に従います。これがスキルの全仕組みです。

スキルは単なるMarkdownファイルなので、Gitでのバージョン管理、差分の確認、Gist経由での共有も簡単です。ビルドステップやパッケージマネージャーも不要で、適切なディレクトリにファイルを置くだけで「インストール」が完了します。

スキルの使い所：

チームで週に2回以上行う、マルチステップのワークフローがある。
その手順が、プロジェクト固有の知識（特定のパス、内部API、命名規則）に依存しており、汎用的なツールでは対応できない。
Claudeの挙動を、成功が保証されている特定の手順に限定したい。

スキルでは力不足（または過剰）な時：

外部APIに接続したい場合（これはプラグインやMCPの領域です）。
一回限りのタスクの場合（スキル化せず、その場でClaudeに直接指示した方が速いです）。

プラグイン（Plugin）が同梱するもの

プラグインは、他のユーザーに配布するためにパッケージ化されたディレクトリです。標準的な構造は以下の通りです。

my-plugin/
├── manifest.json         # プラグインのメタデータとエントリポイント
├── skills/              # 0個以上のスキル
│   └── my-workflow/SKILL.md
├── hooks/               # イベント（PreToolUse, SessionStart等）で走るBashスクリプト
├── subagents/           # 特化型のClaudeペルソナ
├── commands/            # スラッシュコマンド (/my-command)
└── mcp-servers/         # MCPサーバーの設定

プラグインが存在する理由は「配布」の課題を解決するためです。チームメイトに1つのスキルファイルを送ることはできても、OAuth認証、Webhookフック、リポジトリの慣習を熟知したサブエージェントがセットになった完全なGitHub統合をメールで送ることは困難です。プラグインなら、インストール一発でこれらすべてがセットアップされます。

プラグインを作る（導入する）べき時：

指示（プロンプト）以上の機能が必要な時。イベント時にBashを実行する「フック」、ツールを公開する「MCPサーバー」、専門的な役割を担う「サブエージェント」など。
セットアップを他の人と共有・配布したい時。
外部の認証情報やサービス（GitHubトークン、DB接続など）が必要で、構造化されたインストールフローが必要な時。

使い分け判断マトリックス

シチュエーション	スキルを使用	プラグインを使用
「コミットするたびにTypeScriptをリントしたい」	スキル（コミット関連のフレーズで発火）	プラグイン（`git commit`時のPreToolUseフックを使用）— 決定論的な強制力に勝る
「社内Wikiを検索したい」	スキル（Wikiがリポジトリ内のMarkdownの場合）	プラグイン（API連携と認証が必要な場合）
「自社の執筆スタイルでブログを書きたい」	スキル（スタイルガイドをMarkdownで記述）	プラグインにするには過剰
「ステージング環境にデプロイしたい」	スキル（単なるスクリプト実行の場合）	プラグイン（認証情報や確認UIが必要な場合）
「Postgresにクエリを投げたい」	どちらも可（psqlを直接叩くスキル）	プラグインが有利（MCP経由で型安全なツールが使える）

現場での実例

私は複数のサイトを運営するSEOエージェントとしてClaude Codeを運用していますが、以下のような構成にしています。

スキル（ローカル、プロジェクト固有）:

plan-seo-today — 500行に及ぶMarkdownで、日々のループ（重複チェック、KGRによるキーワード選定、優先度スコアリング）を駆動。個別性が高すぎてプラグインには向きません。
publish-blog — 下書きを読み込み、PostgresへINSERTし、確認する。私のサイト構成に特化したもの。
find-newword — 「ブルーオーシャンかレッドオーシャンか」という独自のルールに基づくKGRフィルタリング。

プラグイン（マーケットプレイス等から導入）:

postgres-best-practices — 自分で書かなくても、Claudeに構造化されたPostgresの知識を与えてくれる。
commit-commands — 標準的なコミット/PR支援ツール。
figma — MCP経由のFigma連携。

この比率はClaude Codeの開発チームが示しているドキュメントとも概ね一致します。多くのユーザーは、自分のワークフローに合わせた5〜10個のローカルスキルと、外部システム用の3〜5個のプラグインに落ち着きます。スキルは「書くもの」であり、プラグインは「インストールするもの」なのです。

正直なアドバイス

「プラグインとして汎用化すべきか」「特定プロジェクト専用のスキルに留めるべきか」の境界線は曖昧です。私は最初 publish-blog をプラグインにしようとしましたが、SSHの詳細やSQLのスキーマがインフラに密着しすぎていて、パッケージ化しても使いにくいテンプレートにしかならないと気づきました。結果として、スキルのまま運用しています。

ランタイムでの選択メカニズム

ユーザーがメッセージを入力すると：

Claudeはコンテキスト内の有効なスキルの description を読みます。
スキルがマッチすれば、それがプロンプトに注入され、実行されます。
スラッシュコマンド（例：/figma-use）にマッチするプラグインがあれば、そのフローがトリガーされます。
プラグインの「フック」は、ユーザーのメッセージに関わらず、イベント（ツール使用前、セッション開始時など）に基づいて実行されます。

スキルは Pull型（Claudeがいつ読み込むか決める）であり、プラグイン内のフックは Push型（ランタイムがスケジュール通りに実行する）です。この構造的な違いが、最も重要な使い分けのポイントです。「フックは強制し、スキルは提案する」のです。

最初に何を作るべきか？

もしあなたが初心者で、どこから手をつけるべきか迷っているなら、プラグインに触れる前に3つのスキルを書いてみてください。コードレビュー、リリースノートの作成、テストのスキャフォールディング（雛形作成）など、チームで繰り返しているワークフローをMarkdownにまとめてみましょう。

Claudeがそれらを確実に拾ってくれるか試してみてください。その経験こそが、いつプラグインにステップアップすべきかを教えてくれるはずです。

プラグインが必要になるのは、「フックを使ってルールを強制したい」あるいは「Claudeを社内APIと会話させたい」という壁にぶつかった時です。それまでは、スキルの方が圧倒的にフィードバックループが速く、強力な武器になります。

Jim LiuはOpenAIToolsHubの運営者であり、Claude Code、Cursor、CopilotなどのAI開発ツールをレビューしています。2026年初頭からSEO自動化のためのマルチエージェントClaude Codeセットアップを構築しており、一般的なワークフローをカバーするClaude Codeスキルのコレクションを公開しています。

日本のエンジニア視点で補足

国内ではClaude 3.5 Sonnetの日本語解釈能力への信頼が厚く、Zenn等ではMCP（Model Context Protocol）を活用したローカル開発の自動化が一大トレンドです。特に大規模SIや受託開発において、日本語ドキュメントの自動生成やプロジェクト固有のコーディング規約（スキル）をチームで共有するニーズが高まっています。プラグインで外部SaaSと連携し、スキルで社内規約を注入するハイブリッド運用が、日本独自の「開発効率化」の鍵となるでしょう。