Claude Codeおすすめプラグイン集 2026年版——実際に使っている構成と選定基準
はじめに
Claude Codeのプラグインエコシステムが急速に広がっています。
公式マーケットプレイスに登録されたプラグインだけでも相当な数があり、「何を入れればいいのかわからない」「入れすぎてもコンテキストが圧迫されるのでは」という声をよく聞きます。
この記事では、自分が実際にClaude Codeに導入しているプラグインを用途別に整理し、それぞれの有用性と注意点を解説します。ただし主眼は「どのプラグインが便利か」ではなく、自分の開発スタイルに必要なプラグインを安全性チェックリストに基づいて判断するスキルを持ち帰ってもらうことです。
この記事で学べること
プラグインの機能カタログとして読むより、次の判断軸を身につける教材として読んでもらえると役立ちます。
- 5点の安全性チェックリスト — 提供元・ソース公開・権限範囲・通信先・メンテ状況の5観点で、導入前に1つずつ確認する手順
- 選定の意思決定フロー — 「便利そうだから入れる」ではなく「自分の開発対象との相性で判断する」考え方
- 月1回の棚卸し運用 — 入れっぱなしを防ぎ、攻撃対象面を最小化する習慣
- 使わないプラグインの見直し — 「入れたけど使っていない」を正直に把握し、必要なものだけに絞る判断
- CLAUDE.md肥大化への対処 — 構成の整理をClaude自身に依頼して、管理負担を抑える運用
各プラグインの機能説明は判断の参考情報として読み、判断軸そのものを学びの中心に置いてください。
プラグイン選定の基準
プラグインを導入する前に、自分が設けている基準を共有します。
安全性のチェックポイント
- 提供元が信頼できるか — 公式（Anthropic、AWS等）またはGitHub上で広く利用されているか
- ソースコードが公開されているか — クローズドなバイナリは避ける
- 権限の範囲が適切か — ファイルの読み書き、ネットワーク通信、外部API呼び出しなど、必要以上の権限を要求していないか
- MCPサーバーの通信先が明確か — どこにデータを送っているかが分かるか
- メンテナンスが継続しているか — 最終更新が数ヶ月以上前のものは要注意
なぜ厳選するのか——2つの一般原則
「入れすぎない」を感覚ではなく原理から理解しておくと、判断がぶれません。これは個別の実測値ではなく、構成上一般に説明できる枠組みとして整理できます。
1. コンテキスト消費の原理
プラグインを入れるほど、セッション開始時に読み込まれるスキル定義・ルールが増えます。これはコンテキストウィンドウを消費するため、本当に使うものだけに絞るほど、本来のタスクに使える文脈が広く残ります。「とりあえず全部入れる」と、使わないプラグインの定義が常時オーバーヘッドとして乗り続けます。
2. 攻撃対象面の拡大
プラグインの多くは外部と通信し、ファイルやネットワークに触れる権限を持ちます。導入するプラグインが増えるほど、権限を持つコンポーネントの数＝攻撃対象面が広がります。これはどんなソフトウェアでも成り立つ一般原則で、不要な権限保持物を減らすことがリスク低減の基本です。
この2点から、本当に使うものだけを厳選すること、そして自分の開発スタイルに合ったものだけを選ぶことが、効率とセキュリティの両面で合理的になります。
関連記事との棲み分け
このブログにはClaude Code関連の記事が複数あります。重複して読まなくて済むよう、役割を整理しておきます。
- 本記事 — プラグインを「どう選ぶか」の判断軸（安全性チェックリスト・棚卸し運用）が主題。汎用の選定スキルを学ぶ
- Claude CodeのAWSプラグインが便利すぎる — AWS公式プラグイン群に絞った詳しい使い方。AWS開発者向けの深掘り
- Claude Codeの初期セットアップ — プラグイン以前の、Claude Code自体の導入・設定まわり
「まず全体の選び方を知りたい」なら本記事、「AWSプラグインの中身を詳しく」なら前者、「導入そのものから」なら後者、という使い分けです。
現在の構成：用途別プラグイン一覧
| カテゴリ | プラグイン | 提供元 | 用途 |
|---|---|---|---|
| 開発ワークフロー | superpowers | コミュニティ | ブレスト・TDD・デバッグ・コードレビュー等の包括的支援 |
| 開発ワークフロー | feature-dev | コミュニティ | 機能開発に特化した探索・設計・レビュー |
| 開発ワークフロー | code-review | コミュニティ | PR単位のコードレビュー |
| AWS連携 | deploy-on-aws 他 | AWS公式 | AWSデプロイ・サーバーレス・Amplify等 |
| 品質向上 | frontend-design | コミュニティ | フロントエンドのデザイン品質向上 |
| ドキュメント参照 | context7 | コミュニティ | ライブラリの最新ドキュメント取得 |
| デバッグ・監視 | sentry | Sentry公式 | エラー監視・本番障害対応 |
| セカンドオピニオン | codex | コミュニティ | 別のAIモデルによる診断・実装支援 |
| 自動化 | ralph-loop | コミュニティ | 定期的なタスク実行 |
| ブラウザテスト | Playwright MCP | Anthropic対応 | ブラウザ操作の自動化・E2Eテスト |
以下、カテゴリごとに詳しく解説します。
開発ワークフロー系
superpowers — 開発プロセスをまるごと底上げする
おすすめ度： 最も影響の大きいプラグイン
superpowersは、Claude Codeの開発ワークフロー全体を強化するプラグインです。単一の機能ではなく、複数のスキルを束ねた総合パッケージという位置づけです。
ブレスト・計画立案・TDD・体系的デバッグ・コードレビュー・完了前検証・並列エージェント実行といった開発プロセス各段階のスキルが含まれます（収録スキルの一覧は公式マーケットプレイスを参照）。
なぜ便利か：
素のClaude Codeは「すぐにコードを書き始める」傾向があります。superpowersを入れると、まずブレストし、計画を立て、テストを先に書き、実装後に検証するという規律あるワークフローが自然に適用されます。
特にsystematic-debuggingは強力です。バグに遭遇したときに「とりあえず修正を試す」のではなく、仮説を立て、根本原因を特定してから修正するという手順を踏むため、場当たり的な修正が減ります。
注意点：
- スキル数が多いため、コンテキストの消費が大きい。セッションが長くなると影響を感じる場合がある
- 簡単なタスクに対しても「まずブレストしましょう」と提案されることがある。そのときは「不要、すぐ実装して」と指示すればスキップできる
- コミュニティ製のため、アップデートのタイミングでスキルの挙動が変わることがある
feature-dev — 機能開発に特化した3つの視点
feature-devは、機能開発を探索・設計・レビューの3段階で支援するプラグインです。既存コードの実行パスを追跡するエージェント、既存パターンに沿って設計図を作るエージェント、バグ・セキュリティ・品質を検出するエージェントが連携します（各エージェントの詳細は公式ドキュメント参照）。
なぜ便利か：
「この機能を追加して」と依頼するだけで、まず既存コードを深く分析し、プロジェクトの規約やパターンに沿った設計を提案してくれます。既存のコードベースが大きいプロジェクトほど効果を発揮します。
注意点：
- superpowersのブレストやプラン機能と一部重複する部分がある。両方入れる場合は、どちらを優先的に使うか意識しておくとよい
- サブエージェントとして動作するため、呼び出しのたびにコンテキストの一部が消費される
code-review — PRレビューの自動化
/code-review コマンドでPRのレビューを実行できるプラグインです。
なぜ便利か：
人間のレビューの前にClaude Codeでレビューを走らせておくことで、明らかなミス（型の不一致、未使用変数、セキュリティリスク）を事前に検出できます。人間のレビュアーはより本質的な設計判断に集中できます。
注意点：
- AIによるレビューは人間のレビューの代替ではなく補完。認証・決済・インフラ変更などの重要な領域は、必ず人間がレビューすること
- 大きなdiffに対しては精度が下がることがある
AWS連携系
Agent Plugins for AWS — 公式のAWS開発支援
AWS公式が提供する6つのプラグイン群です。デプロイ、サーバーレス開発、Amplify、データベース管理、GCPからの移行、位置情報サービスをカバーしています。
| プラグイン | 用途 |
|---|---|
| deploy-on-aws | コード分析 → サービス選定 → コスト見積 → IaC生成 → デプロイ |
| aws-serverless | Lambda・API Gateway・Step Functionsの開発 |
| aws-amplify | Amplify Gen 2でのフルスタック開発 |
| databases-on-aws | Aurora DSQLの管理・マイグレーション |
| migration-to-aws | GCPからAWSへの移行計画 |
| amazon-location-service | 地図・ジオコーディング・ルーティング |
詳細は別記事で解説しています： Claude CodeのAWSプラグインが便利すぎる
なぜ便利か：
MCPサーバー経由でAWSの最新料金やドキュメントをリアルタイム参照するため、古い情報に基づく間違いが起きにくい。IaCコードもセキュリティベストプラクティスがデフォルトで適用されます。
注意点：
- AWS CLIのクレデンシャル設定が前提。クレデンシャルの管理は慎重に
- deploy-on-awsは実際にAWSリソースを作成する。デプロイ前の確認は必ず行うこと
- コスト見積もりは参考値。実際の利用パターンによって変動する
- 全プラグインを入れるとスキル定義が大量に読み込まれる。使うものだけインストールすることを推奨
品質向上系
frontend-design — AIっぽくないUIを作る
フロントエンドのコンポーネントやページを作る際に、デザイン品質を引き上げるプラグインです。
なぜ便利か：
素のClaude Codeでフロントエンドを作ると、機能的には正しいが見た目が「いかにもAI生成」という仕上がりになりがちです。frontend-designを入れると、余白の取り方、カラーバランス、タイポグラフィなどに配慮した、より洗練されたUIが生成されます。
注意点：
- デザインの「好み」は主観的。生成されたUIが必ずしもプロジェクトのデザインシステムに合うとは限らない
- 既存のデザインシステムがある場合は、CLAUDE.mdにその指針を書いておくとより一貫した結果が得られる
context7 — ライブラリの最新ドキュメントを即座に参照
ユーザーがライブラリやフレームワークについて質問したとき、最新のドキュメントをリアルタイムで取得するMCPプラグインです。
なぜ便利か：
Claude Codeのトレーニングデータには時間的な限界があります。context7を入れると、React、Next.js、Tailwind CSS、Prisma、Django、Spring Bootなど主要なライブラリの最新バージョンのドキュメントを参照して回答してくれます。
バージョンアップでAPIが変わったり、非推奨になった機能を使ってしまうリスクが大幅に減ります。
使用例：
Next.js 16のApp Routerでキャッシュの設定方法を教えて
こう聞くだけで、context7がNext.js 16の最新ドキュメントを取得し、それに基づいた正確な回答が返ってきます。
注意点：
- 外部のドキュメントサーバーと通信するため、ネットワーク接続が必要
- 対応していないライブラリもある。マイナーなライブラリの場合は手動でドキュメントを渡す方が確実
- ドキュメント取得に若干の時間がかかるため、レスポンスが遅くなることがある
デバッグ・監視系
sentry — 本番エラーとコードを直結させる
Sentry公式が提供するプラグインで、本番環境のエラーをClaude Codeの作業に直結させます。自然言語でのSentry環境への問い合わせ、SDKの初期セットアップ、アラート設定、本番エラーの修正・トリアージといったスキルが含まれます（収録スキルの詳細は公式ドキュメント参照）。
なお正直に言うと、このsentryプラグインは本ブログにSentryを導入していないため自分では実質未使用です（後述の使用頻度セクションで詳しく書きます）。業務プロジェクトで効くタイプのプラグインという位置づけで紹介しています。
なぜ便利か：
「このエラーを修正して」とSentryのイシューURLを渡すだけで、スタックトレースの分析からコードの修正案まで一気通貫で対応してくれます。エラーの発生頻度や影響範囲もSentryから取得するため、優先度判断の材料にもなります。
注意点：
- Sentry側の認証が必要。APIトークンの管理は慎重に
- 本番環境のエラー情報がClaude Codeのコンテキストに含まれる。機密性の高い情報（ユーザーデータ等）がスタックトレースに含まれていないか注意
- Sentryを使っていないプロジェクトでは当然ながら不要
codex — 別のAIモデルにセカンドオピニオンを求める
Claude Codeが行き詰まったときに、OpenAIのCodexランタイムに処理を委譲するプラグインです。
先に正直なところを書いておくと、自分はOpenAIアカウントが無料プランのため精度面の懸念があり、基本的にはこのプラグインを常用していません。ただし「ClaudeとCodexで同じタスクを並走させて比較レビューする」という用途で一度試しており、セカンドオピニオンとしての動作自体は確認済みです。以下の「便利か」は、その確認した範囲での評価です。
なぜ便利か：
同じ問題を別のモデルの視点で見ることで、Claude Codeが見落としていた原因や、別のアプローチを発見できることがあります。特に根深いバグの調査や、複数の解決策を比較検討したい場面で有効です。
使用例：
- Claude Codeで何度修正しても同じテストが通らないとき
- 実装方針に迷っていて別の視点がほしいとき
- 大規模なリファクタリングの妥当性を検証したいとき
注意点：
- OpenAIのAPIを使用するため、別途OpenAIのAPIキーと料金が必要
- コードの一部がOpenAIのサーバーに送信される。機密性の高いコードを扱うプロジェクトでは、送信されるデータの範囲を事前に確認すること
- あくまでセカンドオピニオン。最終判断は人間が行う
自動化系
ralph-loop — 定期実行で「見回り」を自動化する
プロンプトやスラッシュコマンドを一定間隔で繰り返し実行するプラグインです。
なぜ便利か：
「5分ごとにデプロイの状況を確認して」「10分ごとにテストを実行して」といった定期的なポーリング処理を設定できます。CIの結果待ちや、長時間かかるプロセスの監視に便利です。
使用例：
/ralph-loop 5m /code-review
5分ごとにコードレビューを実行し、問題があれば通知してくれます。
注意点：
- 実行間隔が短すぎると、APIコストが増加する
- バックグラウンドで動き続けるため、不要になったら明示的に停止すること
- Claude CodeのMonitorツールと使い分けが必要。リアルタイムのログ監視にはMonitor、定期的な「確認」にはralph-loopが適している
ブラウザテスト系
Playwright MCP — ブラウザ操作をClaude Codeから直接実行
Playwrightをmcpサーバーとして組み込むことで、Claude Codeからブラウザの操作・テストを直接実行できます。
できること：
- ページの表示確認（スクリーンショット撮影）
- フォーム入力・ボタンクリック等の操作
- ネットワークリクエストの監視
- コンソールエラーの確認
- E2Eテストの実行
なぜ便利か：
「このページを開いて表示を確認して」と言うだけで、Claude Codeがブラウザを操作し、スクリーンショットを撮影して結果を報告してくれます。フロントエンドの開発では、コードの変更後に目視確認が必要な場面が多いので、このサイクルを自動化できるのは大きなメリットです。
注意点：
- ローカルでPlaywrightが動作するため、ブラウザのインストールが必要（
npx playwright install） - ブラウザ操作は比較的重い処理。頻繁に呼び出すとレスポンスが遅くなる
- ログインが必要なページのテストでは、認証情報の取り扱いに注意
その他のおすすめ：claude-api
Claude APIやAnthropic SDKを使ったアプリケーションを開発するためのスキルです。
なぜ便利か：
Claude APIを使ったアプリを開発する際、ツール利用、拡張思考、プロンプトキャッシュ、Managed Agentsなどの最新機能の実装パターンをスキルが提供してくれます。APIの仕様変更が頻繁なため、スキルとして最新情報を持っているのは心強い。
注意点：
- Claude APIを使った開発をしない場合は不要
- APIキーの管理は環境変数で行い、コードにハードコードしないこと
導入していないが注目しているプラグイン
SaaS連携系（Slack、Linear、Notion等）
Claude Codeのマーケットプレイスには、Slack、Linear、Notion、HubSpot等のSaaS連携プラグインも用意されています。
メリット： Claude Codeから直接Slackにメッセージを送ったり、Linearのイシューを作成・更新したりできる
導入していない理由：
- 権限の範囲が広い。SaaSアカウントへの書き込み権限を持つため、意図しない操作のリスクがある
- 「Claudeが勝手にSlackにメッセージを送った」という事故は十分に起こりうる
- 現時点では、SaaS操作は自分で行う方が安全と判断している
導入するなら：
- autoモードでの使用は避け、都度確認を挟む設定にする
- 書き込み権限のあるプラグインは特に慎重に。読み取り専用で十分な場合はそちらを選ぶ
実際の使用頻度——「入れたけど使っていない」もある
プラグインは一覧で紹介していますが、全部が同じ頻度で使われているわけではありません。数ヶ月使い込んだ上での、自分の中での実際の使用状況を正直に書きます。
自動的に毎回使われているもの
以下のプラグインは、明示的に呼び出さなくても文脈に応じてClaude Codeが自動判断で使っているため、「入れておくだけで常時恩恵を受ける」系です。
- superpowers: ブレスト・計画・TDDなどの規律を提案してくれる
- feature-dev: 機能追加時に自動で3段階の分析が走る
- context7: ライブラリのドキュメント参照が必要な場面で自動的に呼ばれる
- deploy-on-aws: AWS関連の質問で自動的にAWS専門知識が注入される
- frontend-design: UI改善の文脈で効いている
ほとんど使っていないもの
正直に書くと、以下は入れているが出番がないか、限定的です。
- sentry: 本ブログにSentryを入れていないため、実質未使用。業務プロジェクトでは効くはず
- ralph-loop: 定期タスクを回す用途がまだないため未使用。ブログ運用が自動化対象になればアクティブ化したい
- codex: OpenAIアカウントが無料プランのため、精度面の懸念があり基本的には使っていない。ただし「ClaudeとCodexで同じタスクを並走して比較レビューする」という用途では一度試しており、セカンドオピニオンとしての動作自体は確認済み
「全部入れれば強い」というわけではなく、自分の開発対象との相性で使用頻度が決まります。未使用でも定期的な棚卸しをすれば問題ないので、過度に削除する必要はないと考えています。
プラグインの安全な管理方法
定期的な棚卸し
月に1回程度、インストール済みプラグインを確認し、使っていないものは削除しましょう。プラグインが多いほど攻撃対象面が広がります。
/plugin list
権限モードの活用
Claude Codeの権限モードを適切に設定することで、プラグインの暴走を防げます。
- defaultモード（推奨）：ファイル編集やコマンド実行のたびに確認が入る
- autoモード：確認なしで実行。信頼できるタスクにのみ使用
- 特に外部通信を伴うプラグイン（Sentry、context7、SaaS連携等）は、defaultモードでの運用が安全
MCPサーバーの通信先を把握する
プラグインの多くはMCPサーバーを通じて外部と通信します。どのプラグインがどこに通信しているかを把握しておくことは、セキュリティ上重要です。
| プラグイン | 通信先 |
|---|---|
| context7 | context7のドキュメントサーバー |
| deploy-on-aws | AWSドキュメント・料金API |
| sentry | SentryのAPI |
| codex | OpenAIのAPI |
| Playwright | ローカルのみ（外部通信なし） |
CLAUDE.md肥大化への対処
プラグインを増やすと、それぞれが暗黙的に注入するスキル・ルールが増え、結果的にコンテキストウィンドウの消費が大きくなります。自分は厳密な管理をしているわけではなく、定期的にClaudeに「現状のCLAUDE.md構成をベストプラクティスに整理して」と依頼する運用にしています。
これだけでも、不要になったルールの削除や、重複の解消、優先順位の明確化が自動で進むため、CLAUDE.mdを自分で管理する負担は大きく減らせます。プロジェクトのCLAUDE.mdが肥大化してきたら、試してみる価値があります。
まとめ
- プラグインは安全性を最優先に選定する。提供元の信頼性、権限の範囲、通信先を確認してから導入する
- 入れすぎない。コンテキストの消費とセキュリティリスクの両面で、厳選が重要
- 開発ワークフロー系（superpowers）とドキュメント参照（context7）は汎用性が高く、多くの開発者におすすめ
- AWS開発者はAgent Plugins for AWSを入れるだけで開発効率が大きく向上する
- SaaS連携系は便利だが権限リスクが高い。導入する場合はdefaultモードでの運用を推奨
- 月に1回程度、プラグインの棚卸しを行い、使っていないものは削除する
「便利そうだから入れる」ではなく、「自分の開発スタイルに本当に必要か」を基準に選ぶこと。それがプラグインと安全に付き合うコツです。