プラグインとマーケットプレイス

Skillsを組織を超えて共有する

プラグインとは

Skills（第4章）を使いこなすうちに、必ずこの壁にぶつかります。「このSkill、別のプロジェクトでも使いたい」「チーム全員に同じワークフローを配布したい」 ――こうしたニーズに応えるのがプラグインです。

プラグインは、Skills（スキルコマンド）を配布可能な形にパッケージしたものです。 npmやpipのような仕組みで、他の人が作ったSkillsを簡単にインストールして使えます。claude plugin installコマンド一発で、誰かが作り込んだワークフローがそのまま自分の環境に入る。これがプラグインの基本コンセプトです。

# プラグインのインストール（npmと同じ感覚）
claude plugin install @company/code-review

# インストール完了後、すぐにSkillとして使える
# /code-review で呼び出し可能

Skillsがプロジェクトローカルな自動化定義であるのに対し、プラグインはバージョン管理・依存関係・配布チャネルを備えた正式なパッケージです。料理に例えるなら、Skillは個別のレシピ、プラグインはレシピブックです。レシピブックにはレシピだけでなく、調理器具の推奨設定（Hooks）や調理工程の自動化（Commands）、食材の調達先（MCP設定）まで含まれています。

ポイント: Skillsが「自分のための自動化」なら、プラグインは「チームのための自動化」。プロジェクトの.claude/ディレクトリを手動でコピーして回る時代は終わりました。claude plugin install一発で、チーム全員が同じワークフローを使える世界です。

私自身、最初は.claude/skills/をGitリポジトリ間でコピーする運用をしていました。プロジェクトが3つ、4つと増えるにつれてバージョンの不一致が頻発し、「どのプロジェクトに最新版があるか分からない」という状態に。プラグインに移行してからは、claude plugin update一発で全プロジェクトが最新版に揃うようになりました。

Marketplaceの仕組み

プラグインの配布基盤となるのがMarketplace（マーケットプレイス）です。 Claude Code公式のマーケットプレイスで、コミュニティが作ったプラグインを検索・インストール・評価できます。

プラグインの検索

claude plugin searchコマンドで、マーケットプレイスからプラグインを検索できます。キーワードやカテゴリで絞り込めるため、必要なプラグインを素早く見つけられます。

# キーワードで検索
claude plugin search "code review"

# カテゴリで絞り込み
claude plugin search --category verification

# 検索結果の例:
# @anthropic/code-review     v2.1.0  ★4.8  コードレビュー自動化
# @community/pr-reviewer     v1.3.2  ★4.5  PRレビューワークフロー
# @company/security-check    v3.0.1  ★4.9  セキュリティスキャン

信頼する配布者の設定

settings.jsonのplugins.trustedPublishersで、信頼する配布者（パブリッシャー）を設定できます。信頼済みのパブリッシャーからのプラグインは、確認プロンプトなしでインストールされます。

// settings.json
{
  "plugins": {
    "trustedPublishers": [
      "@anthropic",
      "@mycompany"
    ]
  }
}

品質基準

Anthropicの共同創業者であるThariq氏が推奨するマーケットプレイスの品質基準は3つ。明確なREADME、テスト付き、セキュリティレビュー済みです。この3つを満たさないプラグインは、公式マーケットプレイスには掲載されません。

逆に言えば、この基準を満たしているプラグインは一定の品質が保証されています。個人的にも、星の数よりもREADMEの充実度とテストの有無を見て判断することを推奨します。 READMEが薄いプラグインは、Gotchas（落とし穴）が未記載であることが多く、導入後にハマるリスクが高いです。

ポイント: プラグイン選定の判断基準は「READMEの充実度」と「テストの有無」。星の数やダウンロード数だけで判断すると、メンテナンスが止まったプラグインを掴むことがあります。

インストールと管理

プラグインの管理はシンプルなコマンド体系で完結します。 npmやpipに慣れている方なら、ほぼ直感的に操作できるはずです。

基本コマンド

# インストール
claude plugin install @publisher/plugin-name

# インストール済み一覧の確認
claude plugin list

# プラグインの更新
claude plugin update @publisher/plugin-name

# 全プラグインを一括更新
claude plugin update --all

# プラグインの削除
claude plugin remove @publisher/plugin-name

自動インストールと自動更新

settings.jsonでplugins.autoInstall: trueを設定すると、プロジェクトが要求するプラグインを自動でインストールします。plugins.autoUpdate: trueで、セッション開始時に自動で最新版に更新されます。

// settings.json
{
  "plugins": {
    // プロジェクトが要求するプラグインを自動インストール
    "autoInstall": true,

    // セッション開始時に自動更新
    "autoUpdate": true,

    // 信頼するパブリッシャー
    "trustedPublishers": ["@anthropic", "@mycompany"]
  }
}

インストールスコープ

プラグインはプロジェクトレベルとユーザーレベルの 2つのスコープでインストールできます。

プロジェクトレベル（デフォルト） — そのプロジェクトでのみ有効。.claude/plugins/に記録される。チームメンバーと共有される
ユーザーレベル（--globalフラグ） — 全プロジェクトで有効。~/.claude/plugins/に記録される。個人の開発環境カスタマイズ向け

# プロジェクトレベル（デフォルト）
claude plugin install @company/code-review

# ユーザーレベル（全プロジェクト共通）
claude plugin install --global @personal/my-utils

ポイント: チームで統一すべきプラグインはプロジェクトレベル、個人の生産性ツールはユーザーレベル。この使い分けを守ることで、チームの標準と個人のカスタマイズが共存できます。

プラグインの作り方

自分のSkillsをプラグインとして公開する手順を見ていきます。既にSKILL.mdを書いた経験があれば、追加の学習コストはほぼゼロです。

テンプレート生成

claude plugin initコマンドで、プラグインの雛形を自動生成できます。ディレクトリ構造とplugin.jsonが自動で作られます。

# プラグインの雛形を生成
claude plugin init my-awesome-plugin

# 生成されるディレクトリ構造
my-awesome-plugin/
  .claude/
    skills/
      my-skill/
        SKILL.md          # Skill定義
        scripts/          # 補助スクリプト
        references/       # 参照ドキュメント
  plugin.json             # プラグインメタデータ
  README.md               # 説明書

plugin.jsonの構成

plugin.jsonはプラグインのメタデータを定義するファイルです。名前、説明、バージョン、依存関係を記述します。

{
  "name": "@mycompany/code-review",
  "version": "1.0.0",
  "description": "社内コーディング規約に基づくコードレビュー自動化",
  "publisher": "mycompany",
  "keywords": ["code-review", "quality"],
  "dependencies": {
    "@anthropic/testing-utils": "^2.0.0"
  },
  "claude": {
    "skills": ["skills/code-review"],
    "hooks": ["hooks/pre-commit"],
    "commands": ["commands/review"]
  }
}

ディレクトリ構造

プラグインの内部構造は、通常のClaude Codeプロジェクトの.claude/ディレクトリとほぼ同じです。 SKILL.md、scripts/、references/という馴染みのある構成がそのまま使えます。

my-plugin/
  .claude/
    skills/
      code-review/
        SKILL.md              # コードレビューSkill
        scripts/
          check-style.sh      # スタイルチェックスクリプト
        references/
          coding-standards.md # コーディング規約
      test-generator/
        SKILL.md              # テスト生成Skill
    hooks/
      pre-commit.sh           # コミット前チェック
    commands/
      deploy.md               # デプロイCommand
  plugin.json                 # メタデータ
  README.md                   # ドキュメント

公開

プラグインの準備ができたら、claude plugin publishでマーケットプレイスに公開します。公開前に自動でバリデーションが走り、README不足やバージョン未設定などの問題を検出してくれます。

# バリデーション（公開前の事前チェック）
claude plugin validate

# マーケットプレイスに公開
claude plugin publish

# 特定バージョンとして公開
claude plugin publish --version 1.1.0

組織内Marketplaceの運営

Thariq氏のガイダンスに基づく、社内限定のプラグインレジストリの運営方法です。重要なのは、トップダウンの管理委員会ではなく、ボトムアップのオーガニックな発見が機能するという点です。

プライベートレジストリの追加

settings.jsonのplugins.extraKnownMarketplacesで、社内のプライベートレジストリを追加できます。公式マーケットプレイスと並行して、社内プラグインの検索・インストールが可能になります。

// settings.json
{
  "plugins": {
    // 社内プライベートレジストリを追加
    "extraKnownMarketplaces": [
      "https://plugins.internal.mycompany.com"
    ],

    // 社内レジストリからの自動インストールを許可
    "autoInstall": true,
    "trustedPublishers": ["@mycompany"]
  }
}

品質管理のルール

社内マーケットプレイスの品質を保つためのルールは、重くしすぎないのがコツです。 Thariq氏が推奨する基準は以下の3つだけ。

コードレビュー必須 — PRを通じて最低1人のレビューを受ける
テストカバレッジ基準 — 主要なSkillにはテストケースを付ける
バージョニング規約 — セマンティックバージョニング（semver）に従う

これ以上の基準を設けると、共有のハードルが上がってSkillが属人化します。「承認プロセスが重すぎて誰も共有しなくなった」――これが最悪のパターンです。

9カテゴリで整理する

社内プラグインが増えてきたら、以下の9カテゴリで整理すると見通しが良くなります。これはThariq氏が公開したSkillの分類フレームワークをそのままプラグインに適用したものです。

Library — ライブラリ・APIリファレンス
Verification — プロダクト検証・テスト
Data — データ取得・分析
Business — ビジネスプロセス自動化
Scaffolding — コードスキャフォールド・テンプレート
Quality — コード品質・レビュー
CI-CD — CI/CD・デプロイ
Runbook — 障害対応手順
Infra — インフラ運用

ポイント: 社内マーケットプレイスの立ち上げは、 Slackでの共有 → GitHubサンドボックス → 正式なレジストリ、という段階を踏むのが成功パターン。最初から完璧な仕組みを作ろうとすると、誰も使わないまま終わります。

実践パターン

プラグインの典型的な活用パターンを3つ紹介します。それぞれ異なるフェーズ・規模の組織で効果を発揮します。

スタートアップのオンボーディング

新メンバーがチームに参加したとき、claude plugin install @company/onboarding一発で開発環境のSkillsが揃うという運用です。

オンボーディングプラグインには、コーディング規約（Skills）、 PRテンプレート（Commands）、コミット前チェック（Hooks）、社内APIアクセス（MCP設定）がすべてバンドルされています。新メンバーは「何を設定すればいいか分からない」という状態から解放され、初日からチームの標準ワークフローで開発を始められます。

# 新メンバーのオンボーディング（これだけ）
claude plugin install @company/onboarding

# 含まれるコンポーネント:
# - Skills: コーディング規約、PR作成ガイド、テスト方針
# - Commands: /deploy, /review, /standup
# - Hooks: pre-commit（lint + 機密情報チェック）
# - MCP: 社内API認証、Slack通知、Jiraチケット連携

従来のオンボーディングでは、Confluenceのドキュメントを読み、各種ツールを個別にセットアップし、先輩エンジニアに暗黙知を聞く―― という流れに数日かかっていました。プラグイン化すると、この「暗黙知」がコードとして形式知化されるのが最大のメリットです。

QAチームのテスト自動化

テスト生成・実行・レポートのSkillsをプラグインで標準化するパターンです。 QAチームが作り込んだテスト方法論を、開発チーム全員が同じ品質で実行できるようになります。

# QAプラグインのインストール
claude plugin install @company/qa-toolkit

# テスト生成
# /generate-tests で対象コードのテストを自動生成

# テスト実行 + レポート
# /run-tests で実行し、カバレッジレポートを自動生成

# リグレッションチェック
# /regression-check でPR差分に対するリグレッションテストを実行

ポイントは、テストの「書き方」だけでなく「何をテストすべきか」という判断基準も Skillに含まれていること。 E2Eテストの境界条件、パフォーマンステストの閾値、セキュリティテストの観点――これらがプラグインとして配布されることで、テスト品質の属人化を防げます。

マイグレーション配布

フレームワーク更新のマイグレーションSkillを全チームに配布するパターンです。たとえばReact 18から19への移行、Next.js 14から15への移行といった大規模な技術的マイグレーションで威力を発揮します。

# マイグレーションプラグインの配布
claude plugin install @company/nextjs15-migration

# プラグインが提供する機能:
# - /migrate-check: 移行対象のファイルを自動検出
# - /migrate-run: 段階的な自動マイグレーション実行
# - /migrate-verify: 移行後の動作検証

# プラットフォームチームが作成 → 全チームに配布
# 各チームは自分のペースでマイグレーションを実行

マイグレーションプラグインの真価は、「ベストプラクティスの一元管理」にあります。プラットフォームチームがマイグレーション手順を1回作り込めば、各開発チームはそのプラグインをインストールするだけ。手順の抜け漏れや解釈の違いによるバグを防げます。マイグレーション完了後はプラグインを削除すれば、痕跡を残しません。

まとめ

プラグインは、Skillsを「個人の便利ツール」から「組織の標準ツール」へ進化させる仕組みです。claude plugin install一発で、誰かが作り込んだワークフローがチーム全員の手元に届く。 Marketplaceの品質基準（README・テスト・セキュリティレビュー）を守りながら、チーム固有のナレッジをコードとして蓄積・配布できます。

まずは既に運用実績のあるSkillを1つ選び、プラグインとして整備することから始めてください。社内マーケットプレイスはSlackでの共有 → サンドボックス → 正式レジストリ、というオーガニックなプロセスで育てていくのが成功の鍵。トップダウンで仕組みを作り込むより、ボトムアップで使われるプラグインを1つ生み出す方が、組織にとって遥かに価値があります。

Contact

導入のご相談はお気軽に

個別のご質問・導入相談を承っています。

無料相談・お問い合わせ