# 2026 年 Q2 のコミュニティプラグイン トップ 10
公式 `claude-plugins-official` の整備に呼応するように、コミュニティ側のプラグイン生態系も急速に成熟してきた。本稿では、ComposioHQ の `awesome-claude-plugins` や `awesome-claude-code-toolkit` といった集約情報を踏まえ、2026 年 Q2 時点で注目すべき 10 個を抜粋して紹介する。掲載順は私見であり、用途別に評価軸を添える。なお、コミュニティ製は公式と異なり統一審査がない場合が多いため、最後に採用時の落とし穴も整理する。
接続系・UI 系: 外部世界へつなぐプラグイン
第一に取り上げたいのが `connect-apps` である。Gmail・Slack・GitHub・Notion・各種データベースなど、500 を超えるサービスへ Claude Code から実アクションを送れるプラグインで、MCP の上に構築されている。API キー管理が苦手なチームでも共通の入口で扱えるのが利点だ。次に `frontend-design` は、いわゆる「AI スロップ」と呼ばれる量産感のある画面を避け、独自のタイポグラフィや配色で視覚言語を立てる支援を行う。中小企業のランディングページ刷新に向き、KGA IT が伴走する案件でも採用例が増えている。両者は性質が大きく異なるが、共通するのは「自社の外側との接点を整える」役割だ。連携先や視覚言語といった、組織の境界に出てくる要素を Claude Code 経由で扱えるようにするだけで、社外向けの作業の生産性が大きく変わる。
レビュー・セキュリティ系の汎用プラグイン
第三に `code-review` は、ベストプラクティス・パターン違反・改善提案を一括で出す汎用レビュープラグインである。公式の `security-review` と並走させると、設計と安全性の両輪を回しやすい。第四の `security-sweep` は、OWASP Top 10 (2025) や Mobile Top 10 (2024)、LLM Top 10 (2025) を網羅したスキャナで、ハードコードされた秘密情報や認証不備、AI 固有の脆弱性まで検知する。CI と組み合わせるとリリース前ゲートとして有効だ。両者を採用する際は、レビューの観点が重複しないよう、責務を文書化しておくことが重要である。社内ルールとして「設計レビューは `code-review`、脆弱性スキャンは `security-sweep`、PR ゲートは公式 `security-review`」と役割を分けて宣言しておけば、レビュー会議で誰がどの観点を担うかが明確になり、議論の流れも安定する。
Subagent と Skill の集合体
第五の `awesome-claude-code-subagents` は、100 種を超える専門 Subagent を集めたコレクションで、フロントエンド、バックエンド、DevOps、セキュリティといった役割別に分かれている。第六の ComposioHQ 系の `claude-skills` は、Skill を主軸に据えたツール群で、社内ドキュメントや手順書の Skill 化を支援する。CLAUDE.md に書ききれないナレッジを Skill に切り出すパターンに合う。両者は補完関係にあり、Subagent コレクションで「重い処理を委譲する型」を、Skill コレクションで「軽い助言を自動発火させる型」を学べる。コレクション系プラグインは「全部入り」のように見えて使い方を誤ると逆効果になる。必要な役割だけを選んで取り込み、残りはサンプルとして眺める姿勢を保つと、生態系の知見を取り込みつつ自社の動作を軽く保てる。
運用・観測・テスト系
第七に `plugin-marketplace` のリファレンス実装は、すべてのコンポーネント種別を含むサンプルとして読み解く価値が大きい。自社マーケットプレイス構築の出発点になる。第八の `data-skills` は、CSV・JSON・SQL の往復に強いスキル群で、業務オペレーションの Excel 依存を緩和する効果がある。第九の `observability-pack` 系は、ログとトレースの相互参照やダッシュボード雛形の生成を行うパッケージで、SRE 文脈で重宝する。第十に挙げる `test-harness` 系は、新規プラグインを安全に検証するための骨組みを提供する系統で、プラグイン作者の負担を下げる。これら運用系のプラグインは、開発フェーズより運用フェーズで真価を発揮するため、最初は派手さに欠けて見える。しかし、半年程度の運用を経ると「導入してよかった」と感じる類のもので、長期視点で導入を検討したい。
採用時の落とし穴と中小企業向けの組み合わせ
公開情報の指摘どおり、コミュニティ側のプラグインは公式と異なり統一的な審査がない場合が多い。導入時は `marketplace.json` の発信元、コミット履歴、依存関係を必ず確認し、PreToolUse フックで危険コマンドを遮断する保険をかけたい。具体的には、未署名のスクリプトを参照していないか、外部 API キーを要求するなら保管先が明示されているか、Skill が他の Skill を間接呼び出ししていないか、の三点を最低限チェックする。中小企業に導入する場合は、公式と組み合わせ、コミュニティ製は二、三個までに絞る方針を採るのが現実的だ。導入後は、初週・初月・四半期で振り返りを行い、本当に効果が出ているかを定量・定性の両面で検証する習慣を持っておきたい。漫然と入れたままにすると、攻撃面の拡大と運用負荷の増加だけが残ってしまう。
まとめ: 多すぎる選択肢への向き合い方
コミュニティプラグインの数は今後も増え続ける可能性が高く、追いきれなくなることが最大のリスクである。KGA IT では、四半期ごとに「今期入れるもの・外すもの・保留」を一枚の表に整理し、生煮えの導入を避けている。本稿で挙げた 10 個は、いずれも 2026 年 Q2 時点で公開情報から見て安定運用が期待できる候補だが、自社の優先課題と照らし合わせて選ぶ姿勢を保ってほしい。便利だから入れるのではなく、必要だから入れる、という順序を崩さなければ、コミュニティ生態系の恩恵を最大化できる。多すぎる選択肢に呑まれない最良の方法は、自社の文脈を言葉にすることだ。何を解きたいのかを書き出してから棚を眺めれば、ほとんどの棚は通り過ぎてよい棚であることに気づくはずである。導入候補の評価は単独ではなく、既存のツールセットとの相互作用を踏まえて行う必要がある。新しい一個を足すたびに、既存の責務分担が崩れていないかを確認する小さなレビュー会を挟むだけで、生態系の健全度は大きく変わる。最終的に「自分たちの開発を支える道具箱」として、何が必要で何が余剰かを語れる状態を維持できれば、コミュニティの賑わいに振り回されず、価値の高いものだけを残し続けられる。