Claude Code PluginでClaudeでの開発をポータブルな共有知にする
この記事は#GauDev Advent Calendar 2025の20日目の記事です。
はじめに
2025年12月現在、Claude Code, Codex, GeminiなどAIツールはさまざまありますが、チーム開発という観点で見るとエコシステムが充実しているClaude Codeを使っているチームも多いのではないでしょうか?
私の所属するチームでもClaude Codeを使っており、FE/BE実装に始まりTerraform・GitHub Actions実装からGit 操作・コード品質チェックなどをSlash CommandやSubagents、SkillsといったClaude Codeの機能で実装し効率的にAI駆動開発を進めようと試行錯誤してきました。
それ自体は開発の効率化に繋がっているのですが、1つのGithub Repoに依存する形で実装していたため汎用的に使えるものであっても他のRepoでは使えず、使うためには他のRepoにも同様の機能を実装する必要がありました。
そこで Claude Code Plugin を活用してみることにしました。
この記事ではClaude Code Plugin の作り方から配布方法、そして私たちの実装例まで紹介していきます!
Claude Code Plugin とは
Claude Code Plugin は、Slash Commands、Subagents、Skills、Hooks などのカスタム定義をパッケージ化して配布できる機能です。ユーザー単位だけでなくプロジェクト単位でも使用できるためチーム開発でも使いやすくなっています。
ユーザーはPluginをインストールすることでカスタム定義された機能を自分で実装することなく使えるようになります。
例えば/commit のようなコミットをするSlash Commandが定義されていればPluginをインストールすることでどのRepoでも共通して使えるようになります。便利ですね。
Pluginの作り方
簡単にPluginの作り方も説明します。詳細は公式ドキュメントを参考にしてください。
また、公式からPluginを開発するためのPluginも提供されています。Plugin開発のベストプラクティスに沿って開発を進められるのでPlugin開発の際は使ってみることをおすすめします!
Pluginの構造は以下のようになっています。
my-plugin/
├── .claude-plugin/
│ └── marketplace.json # 必須: Marketplace マニフェスト
│ └── plugin.json # 必須: Plugin マニフェスト
├── commands/ # Slash Commands(オプション)
│ └── my-command.md
├── agents/ # Subagents(オプション)
│ └── my-agent.md
├── skills/ # Skills(オプション)
│ └── my-skill/
│ └── SKILL.md
├── hooks/ # Hooks(オプション)
│ └── hooks.json
├── .mcp.json # MCP サーバー定義(オプション)
└── README.md
commands/、agents/、skills/ 、hooks/ などのディレクトリは .claude-plugin/ と同階層に配置する必要があります。
必須ファイルはMarketPlaceやPluginのメタデータを定義するmarketplace.json , plugin.json です。
.claude-plugin/plugin.json は Plugin のメタデータを定義する必須ファイルです。Plugin名やバージョンなどを定義します。
{
"name": "plugin-name",
"version": "1.0.0",
"description": "Plugin Description",
"author": {
"name": "Author"
},
"repository": "https://github.com/[org-name]/[repo-name]",
"license": "MIT",
}
.claude-plugin/marketplace.json は Pluginを公開するMarketPlaceに関するメタデータを定義する必須ファイルです。MarketPlace名やバージョンなどを定義します。
{
"name": "sample-marketplace",
"owner": {
"name": "Owner Name
},
"plugins": [
{
"name": "plugin-name",
"source": "./plugin-name",
"description": "Plugin Description"
}
]
}
これらのファイルを作成したら、あとはPluginとして配布したいSlash CommnadやSubagentsを実装していけばOKです。
ちなみに一つのMarketPlaceに複数のPluginを定義することも可能です。MarketPlaceは組織として1つ持っておいて、役割や目的ごとにPluginを作成して各チームにとって必要なものだけインストールするといったようなことができます。
複数Pluginを定義する場合の構造は以下になります。
.claude-plugin/ と同階層に plugins/ を用意します。その中に各Pluginディレクトリを用意して単一Pluginと同じ構造で作成します。
ここでの必須ファイルは.claude-plugin/marketplace.json と各Pluginのplugins/[plugin-name]/plugin.json になります。
my-plugin/
├── .claude-plugin/
│ └── marketplace.json # 必須: Marketplace マニフェスト
├── plugins/
│ ├── plugin-a/
│ │ ├── .claude-plugin/
│ │ │ └── plugin.json # 必須: Plugin マニフェスト
│ │ ├── commands/ # Slash Commands(オプション)
│ │ ├── agents/ # Subagents(オプション)
│ │ ├── skills/ # Skills(オプション)
│ │ ├── hooks/ # Hooks(オプション)
│ │ ├── .mcp.json # MCP サーバー定義(オプション)
│ │ └── README.md
│ └── plugin-b/
│ ├── .claude-plugin/
│ │ └── plugin.json # 必須: Plugin マニフェスト
│ ├── commands/ # Slash Commands(オプション)
│ ├── agents/ # Subagents(オプション)
│ ├── skills/ # Skills(オプション)
│ ├── hooks/ # Hooks(オプション)
│ ├── .mcp.json # MCP サーバー定義(オプション)
│ └── README.md
各Plugin実装が完了したら.claude-plugin/marketplace.json に各pluginの定義を追加したら完成です。
{
"name": "sample-marketplace",
"owner": {
"name": "Owner Name"
},
"plugins": [
{
"name": "plugin-a",
"source": "./plugin-a",
"description": "PluginA Description"
},
{
"name": "plugin-b",
"source": "./plugin-b",
"description": "PluginB Description"
}
]
}
複数Plugin実装をする際は公式のRepoがかなり参考になります。
このRepoは公式が用意しているPlugin集になっていてPluginの作り方のヒントとしてとても参考になるだけでなく、そのまま使えるPluginもあるので一度目を通してみることをおすすめします!
Pluginの配布
Pluginが実装できたらあとは配布するだけです。MarketPlaceを追加して各Pluginをインストールするという流れになります。
ユーザー単位でインストールする方法とプロジェクト単位でインストールする方法があります。
ユーザー単位はユーザーのClaudeの設定に直接インストールされるため、どこでも使いたい場合に便利です。
- MarketPlaceの追加
# Claude Code を起動
claude
# Marketplace を追加
# Repo名がsample/my-pluginの場合
/plugin marketplace add sample/my-plugin
- Pluginのインストール
# Plugin をインストール
# MarketPlace名がsample-marketplaceの場合
# Plugin名がplugin-aの場合
/plugin install plugin-a@sample-marketplace
これでplugin-aで定義されているSlash CommandやSubagentsなどがClaude Codeを使うどこでも利用できるようになります。
プロジェクト単位はRepo単位でMarketPlaceとPluginを事前設定することができ、Repoをクローンしたチームメンバーに自動インストールを促すことができます。チーム開発で共通のSlash CommandやSubagentsなどを使いたいときに便利です。
プロジェクト単位で設定するにはプロジェクトの .claude/settings.json に設定を追加します。
extraKnownMarketplaces に追加したいMarketPlaceの定義を、enabledPlugins にインストールさせたいPluginを定義します。
# sample-marketplaceを設定する場合
{
"extraKnownMarketplaces": {
"sample-marketplace": {
"source": {
"source": "github",
"repo": "[org]/[repo]"
}
}
},
# Pluginの中から使いたいものをEnableにする
"enabledPlugins": {
"plugin-a@sample-marketplace": true,
"plugin-b@sample-marketplace": true,
}
}
私たちのPlugin実践例
ここからはPlugin実装の参考例として、私たちのチームが実際に作成したPlugin の内容を紹介します。
全体構成
基本的には普段私の所属するチームで使っていた機能の中から汎用的に使えそうなものを抽出して作成していて、Plugin化に向けてより汎用的に作り直すなどしています。
現状は以下のような構成にしていて、Git操作やTerraform操作、Code品質系をメインに実装しています。
plugins/devkit/
├── commands/
│ ├── git/
│ │ ├── sync.md
│ │ ├── commit.md
│ │ ├── commit-push-pr.md
│ │ ├── ci-fix.md
│ │ ├── review-fix.md
│ │ └── review-pr.md
│ ├── terraform.md
│ ├── gha.md
│ ├── guide.md
│ ├── store-review.md
│ └── code/
│ ├── quality-check.md
│ ├── refactor.md
│ └── deslop.md
├── agents/
│ ├── terraform/
│ ├── gha/
│ ├── pr-review/
│ └── code/
└── skills/
├── terraform/
├── gha/
├── spanner/
└── protobuf/
いくつかピックアップして紹介します!
Git 操作
日常的に使う Git 操作をワンコマンドで実行できる機能です。
| コマンド | 説明 |
|---|---|
/devkit:git:sync |
main ブランチに切り替えて最新を取得 |
/devkit:git:commit |
変更をコミット |
/devkit:git:commit-push-pr |
コミット → プッシュ → PR 作成を一気通貫 |
/devkit:git:ci-fix |
CI 失敗を自動検出・修正して PR を更新 |
/devkit:git:review-fix |
PR レビューコメントを自動修正 |
例えば/devkit:git:ci-fixコマンドは、PRのCI が失敗したときにログを解析して自動修正するためのコマンドです。
# devkit/git/ci-fix.md
## Execution Steps
1. **Detect CI Failures**
- Identify all failed CI checks from the PR status
- For each failure, get detailed logs using: `gh run view <run-id> --log-failed`
2. **Analyze and Fix**
- Read the error logs carefully
- Identify the root cause of each failure
- Apply appropriate fixes based on the error type
3. **Commit and Push**
- Create a descriptive commit message
- Push changes to update the PR
これまでCIの失敗を手動で確認していたのをこのコマンドを使うことで、ghコマンドを使用してAIが確認し修正提案をしてくれるようになります。
Terraform 操作
Terraform の各種操作を実装するためのコマンドです。
/devkit:terraform <subcommand> [args]
# GCPのSAを作りたい時のコマンド例
/devkit:terraform create xxx PJにxxx用のサービスアカウントを作成したい。
| サブコマンド | 説明 |
|---|---|
create |
新規リソース/モジュール作成 |
plan |
plan 実行と差分分析 |
import |
既存リソースのインポート |
refactor |
コードのリファクタリング |
upgrade |
バージョンアップグレード |
debug |
エラー分析と修正 |
explain |
コードの説明 |
サブコマンドごとにSubagentsを定義していてユーザーの入力によって呼び出すSubagentsを切り替えるようにしています。
devkit/terraform.md
### Step 3: Invoke Terraform Agent
Based on the identified subcommand, invoke the corresponding agent:
{{Task(subagent_type="devkit:terraform:<subcommand>", prompt="<remaining_arguments>")}}
また各SubagentsではTerarform MCPやその他のTerraform関連の知識をまとめたSkillsを参照するようにプロンプトしています。Terraformの公式MCPはかなり精度も良くこれなしではもうTerraformの実装ができないくらいです。
devkit/agents/terraform/create.md
3. Documentation Retrieval
Retrieve official documentation using the terraform skill:
{{Skill(skill="devkit:terraform")}}
Get resource details with mcp__terraform__get_resource_docs
コード品質
コードの品質チェックやリファクタリングなどをするためのコマンドです。
| コマンド | 説明 |
|---|---|
/devkit:code:quality-check |
format, lint, typecheck, testなどを実行してコード品質を確認 |
/devkit:code:refactor |
コード規約に沿ってリファクタリング |
/devkit:code:deslop |
AI生成時の不要なコメントなどを除去 |
/devkit:code:deslopコマンドはAI が生成したコードで発生する冗長なコメントなどを除去するためのコマンドです。
# devkit/code/deslop.md
---
description: "Remove AI-generated code slop"
---
# Remove AI code slop
Check the diff against main, and remove all AI generated slop:
- Extra comments that a human wouldn't add
- Extra defensive checks that are abnormal for that area
- Casts to `any` to get around type issues
- Any other style that is inconsistent with the file
Report with only a 1-3 sentence summary of what you changed.
AIに書かせたコードにはコードが何をやっているかを説明しているだけの不必要なコメントが混ざることがよくあると思います。そのようなコードを削除してコードの可読性を高めるためにこのコマンドを使っています。
Skills の活用
開発で利用しているTerraformやGithub Actions、Spannerなどの知識をSubagentsに与えるためにSkillsもPluginに実装してます。
ユーザーが明示的に呼び出すことなく、定義した専門知識としてSkillsをClaude がユーザーのプロンプトから自動で選んで使ってくれるのでチームの共有知として役立ちます。
| Skill | 説明 |
|---|---|
terraform |
Terraform ベストプラクティス、設計パターン、MCP活用 |
gha |
GitHub Actions ワークフロー構文、セキュリティ |
spanner |
Cloud Spanner スキーマ設計、ベストプラクティス |
protobuf |
Protocol Buffers 設計パターン |
Plugin作ってみて・使ってみて
実際にPluginを作ったり配布する中で当初の課題感であったClaudeでの開発をポータブルにすることはPluginを通して達成できたと感じています。
新規Repoを立ち上げる場合でも自前で車輪の再開発をすることなく、すぐにSlash CommandやSubagentsなどが使えるのは開発生産性の向上にも繋がっているし、チームとして同じ機能を使うことで個々人のAIの使い方の差分を少なくすることができていると思います。
ここではPlugin開発や実際に使ってみての工夫した点や現時点での課題感を改めてまとめてみます。
工夫したポイント
- Slash Command、Subagents、Skillsの使い分け
- メインコンテキストの圧迫を抑制するためにSlash Command→Subagents→Skillsという依存関係を厳守するようにしました。
- メインコンテキストでは基本的にSlash Commandの呼び出しだけを行い、具体的な処理はSubagentsに移譲する。そしてSubagentsがSkillsを参照することでメインコンテキストの使用量を抑えるようにしています。(auto compactionの恐怖から抜け出したい)
- ルーターコマンドを用意
-
/devkit:terraform createのように親コマンド + サブコマンドの形式で統一しました。 - 使い方が直感的になったり、SlashCommandの中でSubagentsを使うように明記することで確実に使いたいSubagentsを使えるようになりました。
-
- 小さな機能でも入れてみる
- 小さな機能や自分しか使わないかも?という機能までとりあえず入れてみるということを意識しました。
- Plugin導入や新しい機能追加のハードルを下げたいという狙いがありました。
現時点での課題
- 汎用的に作ることの難しさ
- Pluginは色々な人が使えるという特性上、汎用的に作る必要があります。
- ただし汎用的に作りすぎると意味のない機能になってしまう可能性もあるため、Pluginで提供するものと自前で作成するものの境界を決めておく必要があり管理が複雑になる可能性があると感じています。
- 機能の検索性
- Plugin 内の機能が増えると、何があるか把握しづらくなります。README.mdなどで機能一覧を書いていてもPluginの数が増えていくと検索性も悪くなります。
- Pluginの中にある機能を検索するためのSlash Commandを用意することでこの問題を回避するようにしています。
まとめ
Claude Code Plugin を使うことでClaudeを使った開発をポータブルにして、開発チーム内や社内で誰でも利用できる状態にすることができました。チームで共通の機能を使うことができるため、コード品質や水準を一定に保ったり定型的な作業をチーム単位で自動化することができるようになります。
Plugin自体は作るのも配布するのも比較的簡単です。公式が用意してくれているPlugin開発Pluginを使えばつまづくことなく作ることができると思います。
まずは自分が使っているSlash CommandやSubagentsの中で自分以外でも使えそうなものととりあえずPluginとして提供してみるのも良いアプローチになると感じています。
ぜひみなさんのチームでも Plugin を作って、Claude での開発を「共有知」にしてみてください!
参考リンク
#GauDev Advent Calendar 2025 明日の担当はso99ynoodlesさんです!
Gaudiy(ガウディ)グループ所属エンジニアの個人発信をまとめたPublicationです。 公式Tech Blog:techblog.gaudiy.com/
Discussion