Claude Code プラグイン完全ガイド｜導入から厳選おすすめ・落とし穴まで【2026年版】

「10個テストして、残したのは4個だけだった」。海外テックブログBuild to Launchの検証記事（Substack）がこのタイトルで公開されたとき、Claude Codeプラグインの現実が一気に見えた。

Claude Codeプラグインとは、AIコーディングアシスタント「Claude Code」に追加機能を後付けできる拡張パーツだ。スマートフォンにアプリを入れる感覚に近い。コードレビューの自動化、外部ツールとの連携、開発フローの効率化など、自分の業務に合わせてClaude Codeをカスタマイズできる。

2026年3月時点で、Claude Codeのプラグインエコシステムは公式101個＋コミュニティ含め9,000以上にまで膨らんでいる（AI Tool Analysis）。Anthropic純正33個、パートナー製68個が公式マーケットプレイスに並び、GitHub・Slack・Figma・Supabase・Vercelといった主要ツールとの連携が揃った。

だが、数が増えればいいという話ではない。この記事では、プラグインの仕組みを理解した上で、本当に使う価値があるものと入れると逆効果になるケースの両面を掘り下げる。

Claude Codeプラグインの3つの構成要素

Claude Codeのプラグインは、以下の3つの要素を組み合わせたパッケージだ（公式ドキュメント）。

Skills（スキル）: /feature-devのようなスラッシュコマンドで呼び出すカスタム命令。実行するたびにトークンを消費する。必要なときだけ起動するので、コンテキストへの常時負荷は小さい。

Hooks（フック）: ファイル保存時やコミット時に自動で走るシェルスクリプト。セッション開始時に読み込まれ、イベントごとに発火する。便利だが、常にコンテキストを消費し続ける点に注意が要る。

MCPサーバー: GitHub、Slack、データベースなど外部サービスとの接続レイヤー。ツール定義がコンテキストウィンドウ（AIが一度に把握できる情報量の上限）に載るため、数が増えるほどClaudeの実効的な作業領域が狭まる。

Claude Codeプラグインのインストール方法

プラグインの導入は拍子抜けするほど簡単だ。

# 1. 公式マーケットプレイスから探す
/plugin
# → Discoverタブでブラウズ

# 2. インストール（公式プラグインの場合）
/plugin install feature-dev@claude-plugins-official

# 3. 使う
/feature-dev Add user authentication with OAuth

公式マーケットプレイス（claude-plugins-official）はClaude Code起動時に自動で利用可能になる。サードパーティのマーケットプレイスを追加したい場合は、/plugin marketplace add <URL>で登録できる。

npmレジストリからのインストールにも対応しており、npx claude-plugins install @anthropics/claude-code-plugins/feature-devでも導入できる（公式ドキュメント）。

おすすめClaude Codeプラグイン厳選5つ

数百のプラグインから「フリーランスの実務で実際に使えるか」という基準で5つに絞った。派手な機能より、日常の開発ループに組み込めるかを重視している。

プラグイン	用途	おすすめ度	注意点
feature-dev	機能開発の構造化	★★★	トークン消費多め
code-review	コードレビュー自動化	★★★	プラグイン版を使うこと
Deep Trilogy	大規模設計+TDD	★★☆	別途APIキーが必要
connect-apps	外部サービス連携	★★☆	案件に応じて入れる
caffeinate	スリープ防止	★★☆	macOS限定

1. feature-dev（公式）

/feature-devで起動する7フェーズの構造化ワークフロー。要件整理→コードベース探索→アーキテクチャ設計→実装→テスト→レビュー→ドキュメントを一気通貫で走らせる（Anthropic公式）。

code-explorer、code-architect、code-reviewerの3つの専門エージェントがそれぞれ独立して動く。探索エージェントが既存コードの実行パスを追跡し、設計エージェントが複数の実装案をトレードオフ付きで提示し、レビューエージェントがバグ・セキュリティ・規約違反を信頼度スコア付きで報告する。

atama plusのテックブログ（Zenn）では、「必要最小限のプロンプトを与える状況下において、『動くは動くけど…』という状態から『ほぼそのまま使える』状態に近づいた感覚」と評価されている。一方で「トークンの消費量は素のClaude Codeより多くなる」とも指摘されており、小規模な修正にはオーバースペックだ。中規模以上の機能開発で真価を発揮する。

PMとしてこれを見ると、要件定義からレビューまでの流れが人間のプロジェクト進行と一致していて自然だ。「とりあえずコード書いて」ではなく、「まず既存を把握して、設計を考えて、それから書く」という順序が強制される。

2. code-review（公式）

/code-reviewで複数の独立エージェントが並列に走り、CLAUDE.md準拠チェック・バグ検出・git blame履歴分析・PRコメント履歴の確認をそれぞれ行う（Anthropic公式）。すべての指摘に0〜100の信頼度スコアが付き、閾値（デフォルト80）以上の問題だけがレポートに載る。

注意点がある。Canlyのテックブログ（Zenn）によれば、マネージド版のCode Review（有料のManaged API経由）は2つのPRで100ドル超かかったという報告がある。一方、無料のプラグイン版なら「追加コスト0ドルかつ4分少々でレビューが得られた」とのこと。プラグイン版の/code-reviewを使うのが正解だ。

自分のClaude Code記事（Claude Code Review完全ガイド）でも詳しく書いたが、マルチエージェントによるレビューは人間の見落としを拾うのに向いている。フリーランスでレビュー相手がいない環境では特に価値がある。

3. Deep Trilogy（コミュニティ）

Pierce Lamb氏が開発した3つのプラグインセット。/deep-projectで曖昧なアイデアをコンポーネントに分解し、/deep-planで各コンポーネントの実装計画をマルチLLMレビュー付きで立て、/deep-implementでTDD＋コードレビュー付きの実装に入る（Medium）。

Lamb氏自身が「Claudeにいきなりコードを書かせると中途半端なアーキテクチャになりがち。計画と分解を先にやることで、品質が根本的に変わる」と述べている（Medium）。

注意点として、Gemini/OpenAIのAPIキーが別途必要になる。計画段階で複数のLLMに意見を聞く設計だからだ。トークン消費も大きいので、小規模な修正にはオーバースペックだと感じる。大きな機能開発のキックオフに使うのが正しい場面だ。

4. connect-apps（パートナー）

Gmail、Slack、GitHub、Notion、Linear、Stripeなど500以上のサービスとClaude Codeを接続するプラグイン（Composio）。「このIssueの内容を確認して実装して」とClaude Codeに指示するだけで、Linearからチケットを取得し、コードを書き、PRを作成する流れが実現できる。

フリーランスにとっては、クライアントのプロジェクト管理ツールとClaude Codeを繋ぐ橋渡し役になる。ただし、500個のツール定義がコンテキストに載るわけではなく、使用するサービスだけを選択的に有効化する設計になっている。

5. caffeinate（コミュニティ）

Claude Codeの長時間セッション中にPCがスリープするのを防ぐプラグイン（Zenn - hiropon22）。地味だが、リモートセッションで作業を放置しているときにスリープで接続が切れる問題を解決する。

Hookとして動作し、セッション開始時にmacOSのcaffeinateコマンドを自動で起動する。フリーランスが夜間にClaude Codeを走らせて翌朝結果を確認する、というワークフローを安定させる。

プラグイン疲労：入れすぎると逆効果

ここからが本題の「影」の部分だ。

Build to Launchの検証（Substack）は「10個テストして4個しか残さなかった」と結論づけた。問題はプラグインの品質ではなく、コンテキストウィンドウの圧迫にある。

MCPサーバーをインストールするたびに、そのツール定義がClaude Codeのコンテキストに載る。10個のMCPサーバーを入れれば、Claudeがコードについて考え始める前に数千トークンが消費される。BSWENの分析（BSWEN）によれば、コンテキスト使用量が20〜40%に達するとAIの”注意力”が分散し、コード生成の精度が目に見えて落ちる。トークン（AIの処理単位）が枯渇する前に、集中力が先に落ちるのだ。

Zennの検証記事（modokkin）でも、公式プラグイン13個を一括導入した結果、セッション開始が遅くなり、コード生成の精度が落ちたと報告されている。

対策：遅延読み込みとプラグインの棚卸し

MCP Tool Searchを有効にすれば、MCPサーバーのツール定義は必要時にだけ読み込まれる。コンテキスト消費は最大95%減る（Morph）。

それでもSkillsとHooksは遅延読み込みに対応していない。定期的に/plugin listで有効なプラグインを確認し、使っていないものは/plugin uninstallする習慣が要る。

Claude Codeプラグインを自作する

公式マーケットプレイスに欲しいものがなければ、自分で作るのも現実的な選択だ。

DataCampのチュートリアル（DataCamp）によれば、最小構成のSkillプラグインなら数分で作れる。Markdownファイルにプロンプトを書き、plugin.jsonでメタデータを定義するだけだ。

my-plugin/
├── plugin.json          # メタデータ・依存関係
├── skills/
│   └── my-skill.md      # プロンプト（Markdownで記述）
└── hooks/
    └── pre-commit.sh    # 任意のフック

作ったプラグインはGitHubリポジトリとして公開すれば、他のユーザーが/plugin installでインストールできる。npm経由での配布にも対応している。

Enterprise向けには、Coworkの管理画面からプライベートマーケットプレイスを構築し、社内専用プラグインを配布する仕組みも用意されている（ALM Corp）。実際にCybozuのkintone AIチームは社内プラグインマーケットプレイスを構築し、2ヶ月で1個から10個以上にプラグインが増えた。「暗黙知がコードになった」という表現が印象的だ（Cybozu Inside Out）。

電脳狐影の判断：何を入れて、何を入れないか

PMとしての判断を書く。

自分のClaude Codeには現在、code-reviewとfeature-devの2つだけ入れている。理由は単純で、この2つがPMとしての「レビュー」と「要件から実装への変換」に直結するからだ。

Deep Trilogyは魅力的だが、マルチLLMのAPIキー管理とトークンコストを考えると、個人開発には重すぎる。チーム開発や大規模プロジェクトのキックオフで使うのが適切だろう。

connect-appsは、クライアントワークでLinearやSlackを使う案件が来たら入れる。常時入れておく必要はない。

**「少なく持って、深く使う」**がプラグイン運用の鉄則だと思っている。

Claude Codeのプラグインエコシステム、これからどうなるか

2026年1月時点では43マーケットプレイスに834プラグインだった。3月には9,000を超えた（ClaudeMarketplaces.com）。VS Codeの拡張機能エコシステムが辿った道と似ている。数は爆発的に増えるが、実際に定着するのは一握りだ。

Anthropicが2月に追加した13のMCPコネクタ（Google Calendar、Gmail、DocuSign、WordPress等）は、プラグインを「開発者ツール」から「業務ツール」に広げる動きだ。ClaudeがCoworkでタスク管理を始め、Channelsでメッセージングに対応した流れと一致する。

遅延読み込みがSkillsとHooksにも拡張されれば、プラグイン疲労の問題はかなり緩和されるはずだ。それまでは、「入れたら速くなる」ではなく「入れたら何を失うか」を考えてからインストールする慎重さが要る。

まとめ：今日やること

1. まずはfeature-devかcode-reviewの1つだけ入れて、1週間使い倒す
2. /plugin listで今入っているプラグインを棚卸しし、使っていないものは外す
3. MCP Tool Searchを有効にして、コンテキスト（AIの作業メモリ）の消費を抑える

---

免責事項: 本記事の情報は2026年3月24日時点のものだ。プラグインのインストール数・仕様・料金は変更される可能性がある。導入前に公式ドキュメント（code.claude.com）で最新情報を確認してほしい。