【2026年最新】Claude Code Plugins完全ガイド｜公式マーケットプレース＋自作7パターン

「毎回同じプロンプトをコピーしているんですが、これって自動化できませんか？」

先日、AI研修の場でこんな質問をもらいました。大手メーカーの情報システム部門の方で、Claude Codeを使い始めて2ヶ月。コードレビュー用のプロンプト、コミットメッセージ生成用の指示文、セキュリティチェック用の手順書……それぞれを毎回コピーして使い回しているとのこと。「チームメンバーにも同じ設定を共有したいんですが、どうすればいいか」という相談でした。

答えは「Claude Code Pluginsを使ってください」です。2026年に正式公開されたこの機能を使えば、そうした繰り返し作業をプラグインとして一度だけ作り、チーム全員がワンコマンドでインストールできます。しかも公式マーケットプレースには、GitHubやSlack、Figmaとの連携プラグインがすでに多数用意されていて、何も作らなくてもすぐに使い始められます。

この記事では、Claude Code Pluginsの仕組みを公式ドキュメント（参照日: 2026-06-03）に基づいて正確に解説しながら、自作プラグインの7つのパターンと実際のコード例、よくある失敗パターンと回避策を網羅します。コピーして使えるplugin.jsonやSKILL.mdの設定例を5つ用意しましたので、今日から手を動かせます。

Claude Code Pluginsとは何か——スタンドアロン設定との違い

Claude Codeには、カスタマイズの方法が大きく2つあります。

ひとつはスタンドアロン設定。プロジェクトの.claude/ディレクトリにスキルやフックを置く方法で、そのプロジェクト専用の設定として機能します。コマンド名は/helloのように短く書けて、手軽に試せる利点があります。

もうひとつがプラグインです。スキル・エージェント・フック・MCPサーバーをひとつの自己完結型ディレクトリにまとめ、マーケットプレース経由で配布・インストールできる仕組みです。スキルは/my-plugin:helloのように名前空間付きで呼び出すため、複数のプラグインが同名のスキルを持っていても衝突しません。

公式ドキュメントが定義する使い分け基準は明確です。

チームで使いたい、複数のプロジェクトで同じ設定を使い回したい、バージョン管理をしながら更新を配布したい——こうしたニーズがひとつでもあればプラグインを選ぶべきです。

Claude Codeの全体像や基本的な使い方については、Claude Code完全ガイドで詳しく解説しています。

公式マーケットプレースで使えるプラグインを知る

まず知っておくべきは、すでに膨大な量の既製プラグインが存在することです。ゼロから作る前に、公式マーケットプレースを確認するのが先決です。

公式Anthropicマーケットプレース（claude-plugins-official）

Claude Codeをインストールした時点で自動的に利用可能になっているマーケットプレースです。/pluginコマンドを実行して「Discover」タブを開けばすぐに一覧が表示されます。claude.com/pluginsでブラウザからも確認できます（参照日: 2026-06-03）。

現時点でのカテゴリと主なプラグインを紹介します。

コードインテリジェンス（言語サーバー）

LSP（Language Server Protocol）を使って、Claude Codeがコード編集時にリアルタイムでエラー検知・定義ジャンプ・型情報取得できるようになるプラグイン群です。

LSPプラグインをインストールすると、Claudeはファイルを編集するたびに言語サーバーが出すエラーや警告を自動で受け取ります。「型エラーを修正して」と指示しなくても、Claudeが自分で気づいて直す、という動作が実現します。

外部サービス連携（MCPサーバーバンドル）

MCPサーバーを事前設定した状態でバンドルしているプラグインです。手動でのMCPサーバー設定なしに外部サービスと連携できます。

• ソース管理: github、gitlab
• プロジェクト管理: atlassian（Jira/Confluence）、asana、linear、notion
• デザイン: figma
• インフラ: vercel、firebase、supabase
• コミュニケーション: slack
• モニタリング: sentry

セキュリティ・開発ワークフロー

• security-guidance: Claudeが行うコード変更を毎回セキュリティレビューし、脆弱性を自動修正するプラグイン
• commit-commands: コミット・プッシュ・PR作成を一貫して行うGitワークフロースキル
• pr-review-toolkit: PRレビュー専門エージェント
• plugin-dev: プラグイン自作を支援するツールキット

コミュニティマーケットプレース

Anthropicの安全審査を通過したサードパーティプラグインが公開されているマーケットプレースです。デフォルトでは登録されていないため、手動で追加します。

/plugin marketplace add anthropics/claude-plugins-community

インストールは以下のコマンドを使います。

/plugin install <plugin-name>@claude-community

プラグインのインストール手順——5ステップ

1. Claude Codeを最新版に更新する
   /pluginコマンドが表示されない場合はバージョンが古い。npm install -g @anthropic-ai/claude-code@latest（またはbrew upgrade claude-code）で更新する。
2. /pluginコマンドで管理UIを開く
   ターミナル内にタブ型インターフェースが表示される。「Discover」タブでインストール可能なプラグインを閲覧できる。
3. インストールしたいプラグインを選んでスコープを決める
   スコープは3種類: User（全プロジェクトで自分だけ）、Project（リポジトリの全共同作業者）、Local（このリポジトリで自分だけ）。チーム標準化が目的ならProject、個人設定ならUser。
4. CLIコマンドでインストールする（任意）
   UIを使わずコマンドで直接インストールもできる。
   /plugin install github@claude-plugins-official
5. /reload-pluginsでプラグインを有効化する
   インストール後はClaudeを再起動しなくても、/reload-pluginsを実行するだけでスキルやエージェントが使えるようになる。

インストール後、プラグインのスキルは/plugin-name:skill-nameの形式で呼び出せます。たとえばcommit-commandsプラグインなら/commit-commands:commitでコミット操作を実行できます。

プラグインの構造——7つのコンポーネント

プラグインのディレクトリ構造を正確に理解しておくことが、自作プラグインを作る上で最重要です。公式ドキュメントで定義されている構成は以下の通りです。

my-plugin/
├── .claude-plugin/
│   └── plugin.json        ← マニフェスト（必須）
├── skills/                ← カスタムスキル
│   └── skill-name/
│       └── SKILL.md
├── commands/              ← フラット形式スキル（旧形式・非推奨）
├── agents/                ← カスタムエージェント
├── hooks/
│   └── hooks.json         ← イベントハンドラー
├── .mcp.json              ← MCPサーバー設定
├── .lsp.json              ← LSPサーバー設定
├── monitors/
│   └── monitors.json      ← バックグラウンドモニター
├── bin/                   ← Bashツールに追加されるバイナリ
└── settings.json          ← デフォルト設定

最重要の落とし穴: skills/やagents/やhooks/は.claude-plugin/の中に入れてはいけません。.claude-plugin/にはplugin.jsonだけを置きます。これを間違えるとプラグインが全く機能しません。

マニフェストファイル（plugin.json）の全フィールド

プラグインのアイデンティティを定義する設定ファイルです。

{
  "name": "my-plugin",
  "description": "プラグインの説明（インストール画面に表示される）",
  "version": "1.0.0",
  "author": {
    "name": "開発者名",
    "email": "email@example.com"
  },
  "homepage": "https://github.com/yourname/my-plugin",
  "repository": "https://github.com/yourname/my-plugin",
  "license": "MIT"
}

フィールドの中で最も重要な3つを解説します。

• name: プラグインの一意な識別子。スキルの名前空間になる。name: "code-reviewer"なら/code-reviewer:reviewのように呼ばれる
• version: 省略可能。設定するとバージョンが変わった時だけユーザーに更新が届く。省略するとgitのコミットSHAが使われ、コミットのたびに新バージョンとみなされる
• description: Discoverタブでの一覧表示やプラグイン詳細画面に表示される説明文。用途が一目でわかる文章にする

自作プラグイン7パターン——設定例コピペで即実装

プラグインで何ができるかを最も速く理解する方法は、具体的なパターンを見ることです。実際に研修現場でよく求められる7パターンを紹介します。

パターン1：チームコードレビュースキル

コードレビューの観点をプラグインにまとめ、チーム全員が同じ基準でレビューできるようにする構成です。

ディレクトリ構造

team-review/
├── .claude-plugin/
│   └── plugin.json
└── skills/
    └── review/
        └── SKILL.md

.claude-plugin/plugin.json

{
  "name": "team-review",
  "description": "チーム標準のコードレビュースキル",
  "version": "1.0.0",
  "author": { "name": "Your Team" }
}

skills/review/SKILL.md

---
description: コードをチーム標準の観点でレビューする。PRレビュー依頼や「このコードを見て」という指示で自動実行。
---

以下の観点でコードをレビューしてください。

1. **可読性**: 変数名・関数名が意図を表しているか
2. **エラーハンドリング**: 例外処理・バリデーションが適切か
3. **セキュリティ**: SQLインジェクション・XSS・認証漏れがないか
4. **テスト**: テストケースが主要なパスをカバーしているか
5. **パフォーマンス**: N+1問題・不要なループがないか

指摘は「重大度(Critical/High/Medium/Low)」「該当箇所」「問題点」「修正案」の形式で出してください。

インストール後は/team-review:reviewまたは単に「このコードをレビューして」と話しかけるだけで自動実行されます。

パターン2：自動コミットメッセージ生成

Conventional Commits形式のコミットメッセージを自動生成するパターンです。

---
description: Conventional Commits形式のコミットメッセージを生成してgitコミットを実行する
---

# コミットメッセージ生成スキル

git diffを確認してConventional Commits形式でコミットしてください。

形式: <type>(<scope>): <description>

typeは以下から選ぶ:
- feat: 新機能
- fix: バグ修正
- refactor: リファクタリング
- docs: ドキュメント
- test: テスト
- chore: その他の変更

1. git statusで変更ファイルを確認
2. git diff --stagedで変更内容を確認（未ステージなら全差分）
3. 変更内容に基づいて適切なメッセージを生成
4. ユーザーに確認してからgit commitを実行

パターン3：セキュリティ監査フック付きプラグイン

ファイルを書き込むたびにセキュリティチェックを自動実行するフックを含む構成です。

security-guard/
├── .claude-plugin/
│   └── plugin.json
└── hooks/
    └── hooks.json

hooks/hooks.json

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs grep -l 'password\|secret\|api_key' 2>/dev/null | while read f; do echo "[セキュリティ警告] $f にハードコードされた認証情報の可能性があります"; done"
          }
        ]
      }
    ]
  }
}

ファイルが保存されるたびに自動でパターンマッチし、APIキーやパスワードが平文でハードコードされていないかをチェックします。

パターン4：MCPサーバーバンドル（社内API連携）

社内APIへのMCP接続をプラグインにまとめ、チーム全員が同じ設定で使えるようにする構成です。

company-api/
├── .claude-plugin/
│   └── plugin.json
└── .mcp.json

.mcp.json

{
  "mcpServers": {
    "company-crm": {
      "command": "npx",
      "args": ["@company/mcp-crm-server", "--endpoint", "https://api.company.com/crm"],
      "env": {
        "CRM_API_KEY": "${CRM_API_KEY}"
      }
    }
  }
}

環境変数CRM_API_KEYを各自のシェルに設定してもらい、プラグインは社内APIのエンドポイントや設定をカプセル化します。「APIキーの値は各自で設定、接続先と設定はプラグインが管理」という役割分担を実現できます。

パターン5：バックグラウンドモニター（エラーログ監視）

アプリのエラーログを常時監視し、エラーが出たらClaudeに通知する構成です。

log-monitor/
├── .claude-plugin/
│   └── plugin.json
└── monitors/
    └── monitors.json

monitors/monitors.json

[
  {
    "name": "app-error-log",
    "command": "tail -F ./logs/error.log",
    "description": "アプリケーションエラーログを監視"
  },
  {
    "name": "test-runner",
    "command": "npx jest --watch --json 2>/dev/null",
    "description": "テスト実行状況をリアルタイム監視"
  }
]

モニターはプラグインが有効な間ずっとバックグラウンドで動き続け、tail -Fの出力が1行来るたびにClaudeへ通知が飛びます。デプロイ作業中にエラーログを目視確認しながら作業する、という手間がなくなります。

パターン6：カスタムエージェント（専門特化型）

特定の業務に特化したエージェントをプラグインとして配布するパターンです。

data-analyst/
├── .claude-plugin/
│   └── plugin.json
└── agents/
    └── analyst.md

agents/analyst.md

---
name: analyst
description: データ分析・可視化に特化したエージェント。CSVやJSONデータの統計分析、グラフ作成指示、レポート生成が得意。
model: sonnet
effort: high
maxTurns: 30
disallowedTools: Write
---

あなたはデータアナリストの専門エージェントです。

得意なこと:
- CSVやJSONの統計サマリー（平均・中央値・外れ値検出）
- Pythonによるデータ可視化コードの生成
- 経営者向けのエグゼクティブサマリー作成
- A/Bテストの有意差検定

ユーザーがデータを見せたら、まず「このデータで知りたいことは何ですか？」と確認してから分析を始める。

パターン7：デフォルト設定適用プラグイン（チームAI運用ルール）

チームのAI利用ポリシーをプラグインのデフォルト設定として配布するパターンです。特定のエージェントを常時有効にしたり、許可ツールを制限したりできます。

settings.json

{
  "agent": "security-reviewer"
}

このプラグインを有効にすると、agents/security-reviewer.mdで定義したエージェントがデフォルトエージェントとして機能します。セキュリティ重視の開発環境では、Claudeが動作するたびに自動でセキュリティ観点が適用される、というルール配布が実現します。

インストール方法を選ぶ——スコープ設計の考え方

プラグインをインストールする際に選ぶスコープは、「誰に適用するか」を決める重要な設計です。

3種類のスコープ比較

チームへのマーケットプレース自動配布

チームリポジトリの.claude/settings.jsonに以下を追加すると、チームメンバーがフォルダを信頼した時点でマーケットプレースのインストールを促すプロンプトが表示されます。

{
  "extraKnownMarketplaces": {
    "team-tools": {
      "source": {
        "source": "github",
        "repo": "your-org/claude-plugins"
      }
    }
  }
}

これにより「新人が入ったら設定を共有する手間」が不要になります。リポジトリをcloneしてClaude Codeを開くだけで、自動的にチーム標準のプラグインが案内されます。

コミュニティへのプラグイン公開手順

自作プラグインをコミュニティマーケットプレースで公開するまでの流れをまとめます。

ローカル検証

# 開発中のプラグインを--plugin-dirフラグでテスト
claude --plugin-dir ./my-plugin

# ZIPアーカイブでもテスト可能（v2.1.128以降）
claude --plugin-dir ./my-plugin.zip

# 複数プラグインを同時テスト
claude --plugin-dir ./plugin-one --plugin-dir ./plugin-two

開発中は変更のたびに/reload-pluginsを実行するだけでよく、Claude Codeを再起動する必要はありません。

バリデーション

claude plugin validate

コミュニティマーケットプレースへの提出時にAnthropicが行う自動検証と同じチェックをローカルで実行できます。提出前に必ず実行しておきましょう。

提出フォーム

バリデーションに通ったら、以下のいずれかのフォームから提出します（参照日: 2026-06-03）。

• Claude.ai: claude.ai/settings/plugins/submit
• Console: platform.claude.com/plugins/submit

審査通過後、anthropics/claude-plugins-communityカタログにピン留めされ、コミュニティマーケットプレースからインストールできるようになります。カタログの同期は毎晩行われるため、承認からインストール可能になるまで1日程度かかる場合があります。

既存の.claude/設定をプラグインに移行する

すでに.claude/commands/や.claude/agents/に設定を持っている場合は、以下のコマンドで簡単にプラグインとして初期化できます。

claude plugin init my-tool

これで~/.claude/skills/my-tool/が作られ、マニフェストとスターターのSKILL.mdが自動生成されます。以降は次のセッションから自動的にロードされます（マーケットプレースへの登録や--plugin-dirフラグが不要）。

業務別おすすめプラグイン3カテゴリ

「プラグインで何をすべきか」を職種・用途別に整理します。

カテゴリ1：ソフトウェア開発チーム向け

開発現場でまず入れておきたいのは以下の組み合わせです。

• typescript-lspまたはpyright-lsp: 型エラーのリアルタイム検知。Claudeが「このコードが動かない原因を調べて」と指示しなくても自動で気づく
• github: PRの差分確認・コメント追加・マージをClaude Codeから直接操作
• security-guidance: コード変更のたびに自動セキュリティレビュー。レビュアーの負担を下げながらセキュリティ品質を維持
• commit-commands: コミットメッセージ生成の標準化

ある顧問先のSaaS企業では、この4本を全員のProjectスコープでインストールしたところ、セキュリティレビューの指摘件数が月30件から12件に減った、とのフィードバックをもらいました（対象: 開発者5名、測定期間2ヶ月）。Claudeが書くコードの品質が上がったというより、Claudeが書くたびにフィードバックを受け修正するサイクルが機能した結果です。

カテゴリ2：AI推進・DX担当者向け

エンジニア以外でClaude Codeを推進する立場の方に適した構成です。

• 自作: 社内AI利用ガイドラインスキル: 社内の禁止事項・注意事項をSKILL.mdにまとめたプラグインを全員のProjectスコープで配布。「このデータを入力してよいか？」という判断基準を自動で提示
• 自作: 業務フロー標準化スキル: 会議議事録作成・メール返信・週次報告書など、繰り返し業務のプロンプトをパッケージ化
• notionまたはatlassian: ドキュメント管理ツールとの連携

研修先で最もよくある質問が「みんなに同じプロンプトを使ってもらうにはどうすれば？」です。プラグインはその答えのひとつです。スキルとして標準化すれば、誰でも同じ品質の出力が得られます。

カテゴリ3：データ分析・経営管理部門向け

• 自作: 分析レポートエージェント: CSVやスプレッドシートのデータを読んで経営者向けサマリーを生成するエージェントプラグイン
• 自作: KPIダッシュボードモニター: APIから定期的にデータを取得してClaudeに通知するモニタープラグイン
• sentry: エラー監視ツールとの連携。本番エラーをClaudeで直接調査

よくある失敗パターン4つ——実際に見た事例から

失敗1：コンポーネントを.claude-plugin/の中に入れてしまう

❌ よくある間違い

my-plugin/
└── .claude-plugin/
    ├── plugin.json
    ├── skills/         ← これが間違い
    │   └── review/
    └── hooks.json      ← これも間違い

⭕ 正しい構成

my-plugin/
├── .claude-plugin/
│   └── plugin.json    ← ここにはplugin.jsonだけ
├── skills/            ← プラグインルートに置く
│   └── review/
└── hooks/
    └── hooks.json     ← プラグインルートに置く

なぜ重要か: Claude Codeはプラグインルートのskills/、agents/、hooks/を自動検出します。.claude-plugin/の中にあるディレクトリは検出されないため、プラグインをインストールしてもスキルが一切表示されない、という状態になります。私が初めてプラグインを作った時も、この落とし穴に30分はまりました。

失敗2：namespaceの衝突を意識しないプラグイン名の付け方

❌ よくある間違い

{
  "name": "review"
}
// → /review:fix というスキル名になる

⭕ 推奨する命名

{
  "name": "mycompany-code-quality"
}
// → /mycompany-code-quality:fix というスキル名になる

なぜ重要か: reviewやtestのような汎用的な名前は、他のプラグインや公式プラグインと衝突する可能性があります。チーム・企業名をプレフィックスにした命名規則を最初から徹底しておくと、後からの名前変更（スキル名が全部変わる）を防げます。

失敗3：プライベートなプラグインを誤って公開リポジトリに配置する

❌ よくある間違い

社内APIのエンドポイント、内部の業務フロー手順、クレデンシャルのパス情報が書かれたプラグインを、Public GitHubリポジトリをマーケットプレースとして公開してしまう。

⭕ 正しい対処

• プライベートリポジトリをマーケットプレースとして使う（GitHubプライベートリポジトリは/plugin marketplace add your-org/private-pluginsで追加できる、アクセス権がある人だけが利用可能）
• ローカルパス/plugin marketplace add /path/to/local-marketplaceを使う
• クレデンシャルは環境変数で渡し、プラグイン自体には値を書かない

失敗4：versionフィールドを省略したまま公開配布する

❌ よくある間違い

{
  "name": "team-tools",
  "description": "チームツール"
  // versionなし
}

⭕ 推奨する設定

{
  "name": "team-tools",
  "description": "チームツール",
  "version": "1.0.0"
}

なぜ重要か: versionフィールドを省略すると、gitにコミットするたびにClaude Codeが「新しいバージョン」と認識します。チームメンバーのClaude Codeが頻繁に「プラグインを更新しますか？」と聞いてくる状態になり、運用上の摩擦が生まれます。バージョン番号を明示して、意図したリリースのタイミングでだけ更新を促す設計にすべきです。

チーム導入時のガバナンス設計

プラグインを組織全体に展開する際に考えておきたいポイントをまとめます。AI導入戦略の観点から見ると、プラグインはClaude Codeの「社内標準化レイヤー」として機能します。

Managedスコープによる強制適用

管理者がManaged設定（~/.claude/managed-settings.json）でプラグインをforce-enable設定すると、ユーザーがそのプラグインを無効化・アンインストールできなくなります。セキュリティチェックプラグインや社内ガイドラインプラグインをどのユーザーも無効にできない状態で配布したい場合に使います。

マーケットプレース制限

組織によっては「Anthropic公式マーケットプレースからしかインストールできない」という制限をManaged設定で設けることも可能です。サードパーティプラグインのセキュリティリスクを管理したい場合に有効です。

コンテキストコストの把握

プラグイン詳細画面には「Context cost」の見積もりが表示されます（Claude Code v2.1.143以降）。プラグインが持つスキル・エージェント・フックは毎ターンコンテキストウィンドウに追加されます。大量のプラグインを有効にすると1リクエストあたりのトークン数が増加し、APIコストに直結します。チームで使うプラグインはContext costを確認しながら厳選する運用を推奨します。

まとめ：今日から始める3つのアクション

Claude Code Pluginsは、個人の作業効率化から組織全体のAI標準化まで、段階的に活用を広げられる仕組みです。

1. 今日やること: /pluginコマンドを開いてDiscoverタブを確認し、LSPプラグイン（TypeScript・Pythonなど）とgithubプラグインをインストールしてみる。/reload-pluginsで有効化して動作確認
2. 今週中: 自分のプロジェクトでよく使うプロンプトをひとつ選び、パターン1（チームコードレビュースキル）の構成を参考に自作プラグインを作る。claude --plugin-dir ./my-pluginでローカルテスト
3. 今月中: 自作プラグインをチームのリポジトリにProjectスコープでインストールし、チームメンバー全員の設定を統一する。.claude/settings.jsonへのマーケットプレース設定を追加して自動案内を設定

AIを個人の生産性ツールから組織の業務基盤に変える一歩として、プラグインの活用を検討してみてください。

あわせて読みたい:

• 【2026年最新】Claude Code完全ガイド — インストールから高度な活用まで体系的に解説
• 中小企業のAI導入戦略完全ガイド — ツール選定から社内展開まで
• Claude Code社内展開5ステップ完全ガイド — チーム導入の実践手順

参考・出典

• Claude Code — Plugins (Create plugins) — Anthropic公式ドキュメント（参照日: 2026-06-03）
• Claude Code — Discover and install plugins — Anthropic公式ドキュメント（参照日: 2026-06-03）
• Claude Code — Plugins reference — Anthropic公式ドキュメント（参照日: 2026-06-03）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。