Claude Codeおすすめプラグイン集 2026年版——実際に使っている構成と選定基準
はじめに
Claude Codeのプラグインエコシステムが急速に広がっています。
公式マーケットプレイスに登録されたプラグインだけでも相当な数があり、「何を入れればいいのかわからない」「入れすぎてもコンテキストが圧迫されるのでは」という声をよく聞きます。
この記事では、自分が実際にClaude Codeに導入しているプラグインを用途別に整理し、それぞれの有用性と注意点を解説します。安全性を重視した選定基準も示すので、プラグイン選びの参考にしてください。
プラグイン選定の基準
プラグインを導入する前に、自分が設けている基準を共有します。
安全性のチェックポイント
- 提供元が信頼できるか — 公式（Anthropic、AWS等）またはGitHub上で広く利用されているか
- ソースコードが公開されているか — クローズドなバイナリは避ける
- 権限の範囲が適切か — ファイルの読み書き、ネットワーク通信、外部API呼び出しなど、必要以上の権限を要求していないか
- MCPサーバーの通信先が明確か — どこにデータを送っているかが分かるか
- メンテナンスが継続しているか — 最終更新が数ヶ月以上前のものは要注意
入れすぎない原則
プラグインを入れるほど、セッション開始時に読み込まれるスキル定義が増えます。これはコンテキストウィンドウを消費するため、本当に使うものだけを厳選するのが重要です。
「とりあえず全部入れる」ではなく、自分の開発スタイルに合ったものだけを選びましょう。
現在の構成：用途別プラグイン一覧
| カテゴリ | プラグイン | 提供元 | 用途 |
|---|---|---|---|
| 開発ワークフロー | 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の開発ワークフロー全体を強化するプラグインです。単一の機能ではなく、複数のスキルを束ねた総合パッケージという位置づけです。
含まれる主なスキル：
| スキル | 用途 |
|---|---|
| brainstorming | 機能開発やコンポーネント作成の前にアイデアを整理する |
| writing-plans | 実装計画を構造化して書き出す |
| executing-plans | 計画をステップごとに実行する |
| test-driven-development | TDDのサイクルを強制する |
| systematic-debugging | バグの根本原因を体系的に調査する |
| requesting-code-review | 作業完了時にレビューを依頼する |
| receiving-code-review | レビュー指摘を受けて対応する |
| verification-before-completion | 完了前に検証コマンドを実行する |
| dispatching-parallel-agents | 独立したタスクを並列エージェントで実行する |
なぜ便利か：
素のClaude Codeは「すぐにコードを書き始める」傾向があります。superpowersを入れると、まずブレストし、計画を立て、テストを先に書き、実装後に検証するという規律あるワークフローが自然に適用されます。
特にsystematic-debuggingは強力です。バグに遭遇したときに「とりあえず修正を試す」のではなく、仮説を立て、根本原因を特定してから修正するという手順を踏むため、場当たり的な修正が減ります。
注意点：
- スキル数が多いため、コンテキストの消費が大きい。セッションが長くなると影響を感じる場合がある
- 簡単なタスクに対しても「まずブレストしましょう」と提案されることがある。そのときは「不要、すぐ実装して」と指示すればスキップできる
- コミュニティ製のため、アップデートのタイミングでスキルの挙動が変わることがある
feature-dev — 機能開発に特化した3つの視点
feature-devは、機能開発を探索・設計・レビューの3段階で支援するプラグインです。
3つのサブエージェント：
| エージェント | 役割 |
|---|---|
| code-explorer | 既存コードの実行パスを追跡し、アーキテクチャを理解する |
| code-architect | 既存パターンに基づいて新機能の設計図を作る |
| code-reviewer | バグ、セキュリティ、品質の問題を検出する |
なぜ便利か：
「この機能を追加して」と依頼するだけで、まず既存コードを深く分析し、プロジェクトの規約やパターンに沿った設計を提案してくれます。既存のコードベースが大きいプロジェクトほど効果を発揮します。
注意点：
- 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の作業に直結させます。
4つのスキル：
| スキル | 用途 |
|---|---|
| seer | 自然言語でSentry環境に質問する |
| sentry-sdk-setup | SDKの初期セットアップ |
| sentry-feature-setup | アラート・OpenTelemetry等の設定 |
| sentry-workflow | 本番エラーの修正・トリアージ |
なぜ便利か：
「このエラーを修正して」とSentryのイシューURLを渡すだけで、スタックトレースの分析からコードの修正案まで一気通貫で対応してくれます。エラーの発生頻度や影響範囲もSentryから取得するため、優先度判断の材料にもなります。
注意点：
- Sentry側の認証が必要。APIトークンの管理は慎重に
- 本番環境のエラー情報がClaude Codeのコンテキストに含まれる。機密性の高い情報（ユーザーデータ等）がスタックトレースに含まれていないか注意
- Sentryを使っていないプロジェクトでは当然ながら不要
codex — 別のAIモデルにセカンドオピニオンを求める
Claude Codeが行き詰まったときに、OpenAIの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モードでの使用は避け、都度確認を挟む設定にする
- 書き込み権限のあるプラグインは特に慎重に。読み取り専用で十分な場合はそちらを選ぶ
プラグインの安全な管理方法
定期的な棚卸し
月に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 | ローカルのみ（外部通信なし） |
まとめ
- プラグインは安全性を最優先に選定する。提供元の信頼性、権限の範囲、通信先を確認してから導入する
- 入れすぎない。コンテキストの消費とセキュリティリスクの両面で、厳選が重要
- 開発ワークフロー系（superpowers）とドキュメント参照（context7）は汎用性が高く、多くの開発者におすすめ
- AWS開発者はAgent Plugins for AWSを入れるだけで開発効率が大きく向上する
- SaaS連携系は便利だが権限リスクが高い。導入する場合はdefaultモードでの運用を推奨
- 月に1回程度、プラグインの棚卸しを行い、使っていないものは削除する
「便利そうだから入れる」ではなく、「自分の開発スタイルに本当に必要か」を基準に選ぶこと。それがプラグインと安全に付き合うコツです。