メインコンテンツへスキップ
BayashiLab LogoBayashiLab(バヤシラボ)
ブログ一覧

Claude Code Pluginsエコシステム完全ガイド — 厳選プラグイン10選からカスタム開発・npm配布・チーム展開まで

Claude Codeプラグイン開発開発ツールAI開発環境

Claude Codeの拡張機構として登場したPluginsは、Skills・Hooks・MCPサーバー・サブエージェント・LSPサーバーを1つのパッケージにまとめ、インストールひとつで環境を再現できる仕組みだ。2026年に入ってエコシステムは9,000超のプラグインを擁する規模に成長したが、「どれを入れればいいのか」「自作するにはどうすればいいのか」を体系的に整理した情報はまだ少ない。本記事では、実務で使えるプラグインの厳選紹介から、カスタム開発、npm配布、チーム展開までを一本で網羅する。

Pluginsの位置づけ — Hooks・Skills・MCPとの違い

Claude Codeには複数の拡張機構があり、それぞれ役割が異なる。

拡張機構 主な役割 誰が制御するか
Skills 手続き的な知識・ワークフロー定義 Claude（タスクに応じて自動選択）
Hooks ライフサイクルイベントへの自動応答 システム（Claudeは関与しない）
MCP 外部ツール・データソースへの接続 Claude（必要に応じて呼び出し）
Plugins 上記すべてを1パッケージにバンドル 開発者（配布・バージョン管理の単位）

Pluginsは「パッケージングレイヤー」だ。個別に.claude/ディレクトリへ配置していたSkillsやHooksを、再利用可能な単位にまとめて共有できるようにする。個人プロジェクトの設定は.claude/に直接置けばよいが、チームで共有したい、複数リポジトリで使い回したい場合はPluginにする、という判断基準でよい。

実務で使える厳選プラグイン10選

9,000超のプラグインのうち、本番で安定して使えるのは正直100程度という印象だ。以下は筆者が実際に導入して効果を実感したものを中心にまとめた。

開発ワークフロー系

  1. ship — PR作成からlint・テスト・レビュー・本番デプロイまでを1コマンドで完結させるパイプライン自動化プラグイン。CIの待ち時間が体感で半減する。
  2. Superpowers — ブレスト・TDD・デバッグ・コードレビューのライフサイクルをSkillsフレームワークとして提供。計画的な開発フローを強制できる。
  3. Plannotator — プランモードの出力を構造化・アノテーション付きで可視化。チームレビューに回しやすくなる。

コード品質系

  1. Local-Review — 並列エージェントによるローカルdiffレビュー。コミット前にバグや設計上の問題を検出する。
  2. TypeScript LSP Plugin — LSPを通じた型チェック・lint結果をClaude内部に直接フィード。型エラーの見落としが激減する。

外部連携系

  1. connect-apps — GitHub・Slack・Gmail・Notionなど500以上のSaaSと接続。Claude CLIからSlackメッセージを送る、といった操作が可能になる。
  2. Claude-Mem — セッション間の長期記憶を追加。過去のやり取りの文脈や好みを引き継げる。

テスト・検証系

  1. Dev-Browser — Playwrightベースのブラウザ操作より軽量なテストブラウジング環境。コンテキスト消費が少ない。
  2. Ralph Wiggum — Xcodeシミュレータを駆動してSwiftアプリのビジュアルテストを実行する、ニッチだが刺さる人には刺さるプラグイン。

インフラ・運用系

  1. Shipyard — IaCバリデーションとセキュリティ監査を統合したプロダクションワークフロー向けプラグイン。

プラグインは /plugin install <name>@<marketplace> でインストールできる。公式マーケットプレイスのものは自動で利用可能だ。

カスタムプラグイン開発チュートリアル

既存プラグインでは足りない場合、自作するのが最も確実だ。以下では、コードレビュー用のプラグインを例に手順を解説する。

ディレクトリ構造

code
my-plugin/
├── .claude-plugin/
│   └── plugin.json          # マニフェスト（ここだけ.claude-plugin内に置く）
├── commands/                 # スラッシュコマンド
├── skills/                   # Agent Skills
│   └── review/
│       └── SKILL.md
├── hooks/                    # イベントハンドラ
│   └── hooks.json
├── agents/                   # カスタムエージェント
├── .mcp.json                 # MCPサーバー設定
└── .lsp.json                 # LSPサーバー設定

よくあるハマりポイントとして、commands/やskills/を.claude-plugin/ディレクトリの中に入れてしまうケースがある。.claude-plugin/内に置くのはplugin.jsonだけだ。他はすべてプラグインルート直下に配置する。

plugin.jsonの記述

json
{
  "name": "my-review-plugin",
  "description": "チーム標準のコードレビューワークフロー",
  "version": "1.0.0",
  "author": {
    "name": "Your Team"
  },
  "homepage": "https://github.com/your-org/my-review-plugin",
  "license": "MIT",
  "keywords": ["review", "quality"]
}

nameがそのままスキルのネームスペースになる。/my-review-plugin:reviewのように呼び出される点に注意。

Skillの作成

skills/review/SKILL.mdを作成する。

markdown
---
name: review
description: コードの品質・セキュリティ・パフォーマンスをレビューする。PRレビューやコード分析時に使用。
---

コードレビュー時に以下の観点でチェックしてください:
1. バグや境界値の見落とし
2. セキュリティ上の懸念（インジェクション、認証不備など）
3. パフォーマンス問題
4. 可読性の改善余地

指摘は具体的かつ修正案付きで提示すること。

Hooksの追加

ファイル編集後に自動でlintを走らせるHookを追加する。hooks/hooks.jsonに記述する。

json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx eslint --fix"
          }
        ]
      }
    ]
  }
}

ローカルテスト

bash
claude --plugin-dir ./my-plugin

--plugin-dirフラグでインストールなしにプラグインを読み込める。複数プラグインを同時にテストしたい場合はフラグを複数回指定する。

bash
claude --plugin-dir ./plugin-one --plugin-dir ./plugin-two

スキルが動作するか、Hookが発火するかを確認したら、/plugin validate .で構造のバリデーションも通しておく。

npm配布とプライベートMarketplace

npm経由での配布

プラグインをnpmパッケージとして公開すれば、marketplace.jsonのsourceに指定するだけでインストール可能になる。

json
{
  "name": "my-npm-plugin",
  "source": {
    "source": "npm",
    "package": "@your-org/claude-review-plugin",
    "version": "^1.0.0"
  }
}

社内npmレジストリを使う場合はregistryフィールドを追加する。

json
{
  "source": {
    "source": "npm",
    "package": "@your-org/claude-review-plugin",
    "version": "^1.0.0",
    "registry": "https://npm.internal.example.com"
  }
}

プライベートMarketplaceの構築

チームでプラグインを配布するには、GitHubリポジトリにMarketplaceを作るのが最も手軽だ。

  1. リポジトリを作成し、.claude-plugin/marketplace.jsonを配置する。
json
{
  "name": "acme-tools",
  "owner": { "name": "Acme DevTools Team" },
  "plugins": [
    {
      "name": "review-plugin",
      "source": "./plugins/review-plugin",
      "description": "チーム標準コードレビュー"
    },
    {
      "name": "deploy-tools",
      "source": {
        "source": "github",
        "repo": "acme-corp/deploy-plugin"
      },
      "description": "デプロイ自動化"
    }
  ]
}
  1. チームメンバーは以下のコマンドで追加・インストールする。
bash
/plugin marketplace add acme-corp/acme-tools
/plugin install review-plugin@acme-tools

プライベートリポジトリの場合、git cloneが通る認証情報があればそのまま動作する。自動更新にはGITHUB_TOKEN環境変数の設定が必要になる。

チーム展開の自動化

全メンバーに手動でMarketplaceを追加させるのは現実的ではない。プロジェクトの.claude/settings.jsonに以下を記述すれば、フォルダを信頼した時点で自動的にMarketplaceが提案される。

json
{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": {
        "source": "github",
        "repo": "acme-corp/acme-tools"
      }
    }
  },
  "enabledPlugins": {
    "review-plugin@acme-tools": true,
    "deploy-tools@acme-tools": true
  }
}

企業でより厳格な制御が必要な場合は、managed settingsでstrictKnownMarketplacesを設定することで、許可されたMarketplace以外の追加を禁止できる。

json
{
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "acme-corp/acme-tools"
    }
  ]
}

これにより、個人が勝手に外部プラグインを導入するリスクを排除できる。

まとめ

Claude Code Pluginsは、個別の拡張機構（Skills・Hooks・MCP・LSP）を束ねる「パッケージングレイヤー」として、チーム開発のワークフロー標準化に大きな力を発揮する。

  • まずは公式Marketplaceから厳選プラグインを試す
  • 足りなければ.claude/で個別設定を試作し、安定したらPluginに変換する
  • チーム展開はextraKnownMarketplaces + enabledPluginsで自動化する

9,000超のエコシステムは玉石混交だが、正しく選べばCLI上の開発体験が一段階上がる。個人的には、まずship・Local-Review・TypeScript LSPの3つを入れるだけでも日常の開発が変わると感じている。