Claude Codeの/checkupで環境を棚卸ししてみた——未使用プラグインを消す基準・残す基準
はじめに
Claude Code に /checkup というコマンドが追加されました。従来からあった診断コマンド /doctor の進化版で、v2.1.205 から /doctor は「診断結果を表示するだけ」のコマンドではなくなり、問題を見つけて修正まで提案・実行するフルセットアップチェックアップに生まれ変わりました。/checkup はその新しい呼び名（エイリアス）で、従来どおり /doctor と打っても同じものが動きます。既存の使い方を壊さない後方互換の形での進化です。
何ができるかは、Claude Code の生みの親である Boris Cherny 氏が X でアナウンスしているポストにまとまっています。これを見てさっそく自分の環境で実行してみたところ、思っていた以上に未使用プラグインが溜まっていたことが分かり、まとめて整理することになりました。
ただ、実際にやってみると「未使用と診断されたものを機械的に全部消せばよい」という単純な話でもありませんでした。この記事では /checkup で何ができるかの紹介と合わせて、未使用プラグインを消すメリット・消しすぎるデメリット・残すべきものの判断基準を、実体験ベースで整理します。
この記事で得られるもの
/checkupで何が診断・修正できるかが分かる- 未使用プラグインを削除するメリットと、有用なものまで消してしまうリスクを両面から理解できる
- 「消す・残す」を迷わず判断するためのフローを持ち帰れる
/checkupコマンドとは
/checkup（= /doctor）は、Claude Code のセットアップ全体を健康診断して、問題があれば修正まで提案してくれる組み込みコマンドです。
/checkup
公式の週次ダイジェスト（Week 28）とアナウンスによると、診断・修正の対象はおおむね次のとおりです。
- インストール状態の健全性チェックと、Claude Code 本体の最新版への更新
- 未使用のスキル・MCP サーバー・プラグインを、それぞれのコンテキストコストと突き合わせて洗い出し
- ローカルの CLAUDE.md とリポジトリにチェックインされた CLAUDE.md の重複排除
- 肥大化した CLAUDE.md の整理提案（ネストした CLAUDE.md やスキルへの切り出し、コードベースから導出できる記述の削減）
- 実行の遅いフックの検出・無効化
- オートモードの有効化や、毎回拒否している読み取り専用コマンドの事前承認といった設定改善の提案
従来の /doctor との違いを整理するとこうなります。
| 観点 | 従来の /doctor | v2.1.205以降の /doctor・/checkup |
|---|---|---|
| 役割 | 読み取り専用の診断レポート | 診断 + 修正提案 + 実行 |
| 対象 | インストール状態が中心 | プラグイン・スキル・MCP・CLAUDE.md・フック・設定まで |
| 変更 | 行わない | ユーザーの確認を取ったうえで実施 |
重要な仕様として、勝手に変更はしません。まず診断結果を一覧で報告し、変更を加える前に必ず確認を求めてきます。「診断ツールに設定を触らせるのは怖い」という人でも、提案を見てから個別に判断できます。
実際に実行してみた
自分の環境で実行してみた結果と、そこからの気づきです。
未使用プラグインが9個見つかった
これまで「おすすめ」で入れたり試しに入れたりしたプラグインのうち、生涯利用回数が0のものが9個見つかりました。内訳は大きく2グループに分かれました。
- 自前のスキルやエージェントと役割が重複していたもの — コードレビュー・コード整理・GitHub 操作・機能開発支援など。すでに自分のワークフローに合わせたスキルを整備していたため、汎用プラグインの出番が一度もなかった
- 現在の開発領域と関係ないもの — AWS 移行支援や Amplify 連携など、「いつか使うかも」で入れたまま一度も触っていなかったもの
これらは提案に従ってまとめて無効化しました。無効化前の設定はバックアップとして残してあるので、戻したくなったらすぐ戻せます。この気軽さもあって、整理の心理的なハードルはかなり低かったです。
「使うべきなのに使えていない」プラグインも見えた
面白かったのはこちらです。未使用リストの中に、「不要だから使っていない」のではなく「ワークフローに組み込めていないだけ」のものが混ざっていました。
- LSP 系プラグイン — 毎日 PHP や TypeScript を書いているのに呼び出しが0。コード解析に本来役立つはずが、組み込めていなかった
- ドキュメント検索系プラグイン — ライブラリ調査で使えるはずが、Web 検索で済ませてしまっていた
/checkup の診断は「削除リスト」であると同時に、宝の持ち腐れの発見装置でもあります。未使用イコール不要と決めつけず、「なぜ使えていないのか」を一度考えてから消すのがよいと感じました。
未使用プラグインを削除するメリット
そもそも、使っていないだけで実害のなさそうなプラグインを、なぜわざわざ消すのか。理由は大きく3つあります。
1. コンテキストの固定費が減る
プラグインが提供する MCP サーバーの説明文やツール定義は、実際に使うかどうかに関係なく毎ターン注入され続けます。つまり未使用プラグインは「タダで置いてあるだけのもの」ではなく、会話のたびにコンテキストウィンドウを消費し続ける固定費です。本来モデルがコードやあなたの指示の理解に使えたはずの領域を、使いもしないツールの説明文が占有している状態と言えます。
2. 誤った呼び出しのリスクが下がる
ツールの数が増えるほど、モデルが状況に合わないツールを選んでしまう余地は広がります。特に利用頻度の低いプラグインは、無関係な文脈で名前や説明文がたまたまマッチして誤って呼び出される事故の温床になりがちです。選択肢を減らすことは、そのまま呼び出し精度の向上につながります。
3. セキュリティ運用の対象が減る
プラグインや MCP サーバーは入れて終わりではなく、配布元の確認、アップデートへの追従、認証が絡むものならトークンの管理といった継続的な運用コストがかかります。管理対象の母数が減れば、その分だけ一つひとつの確認が現実的になります。
有用なプラグインまで消してしまうデメリット
一方で、「全部消せば身軽になる」という話でもありません。消しすぎには消しすぎのリスクがあります。
存在に気づかないまま、劣化した自力実装で進んでしまう
最大のリスクはこれです。プラグインなら一発だった作業を、その存在を忘れているせいで手作業や精度の低い代替手段でこなしてしまう。しかも本人は困っている自覚がないので、この損失は表面化しません。「知らないうちに損をしている」状態が静かに続きます。
再導入には探し直すコストがかかる
一度消すと、後で必要になったときに「あれ、なんというプラグインだったっけ」から始まります。マーケットプレイスを探し直し、入れ直し、設定し直す手間はゼロではありません。頻繁に出入りさせるくらいなら、最初から残しておいた方が安上がりなこともあります。
消す・残すの判断フロー
メリットとデメリットを踏まえて、自分は次の3つの質問で判断しました。
図: 未使用プラグインを消すか残すかの判断フロー
このフローを運用するうえでのポイントは2つあります。
残すものには必ず理由を明文化する。 CLAUDE.md やメモに「なぜ残すか・どんな場面で使うか」を書いておくと、デメリットとして挙げた「存在に気づかないまま損をする」問題を、あとから発見できる状態に変えられます。次回の /checkup で同じものを削除提案されて毎回悩む、という無駄も防げます。私は残したプラグインごとに保持理由と再検討の条件を CLAUDE.md に記録しました。
よく分からないなら、checkupの提案どおり消してしまうのもあり。 /checkup は変更前に必ず確認を挟みますし、プラグインは消してもまた入れ直せます。判断できないまま固定費と誤爆リスクを抱え続けるより、いったん身軽になってから本当に必要なものだけ戻す方が健全です。
具体例で言えば、認証・決済・インフラ検証のように間違えたときの事故コストが大きい領域を支援するものは残す価値が高く、ドキュメント検索のようにWeb検索で代替が利くものは削除候補になりやすい、という整理になります。
自前のスキルがあればプラグインは不要になる
今回の棚卸しでいちばんの学びはこれでした。
自分の場合、コードレビューは観点や手順を明文化した自前のスキルをすでに整備しており、汎用のコードレビュー系プラグインとは役割が完全に重複していました。しかも自前のスキルは自分のコーディング規約やレビュー観点に合わせて書いてあるため、この用途に限れば汎用プラグインより自分の環境での精度が高い。こうなると、プラグイン側を残す理由はもうありません。
一般化すると、プラグインは2種類に分けられます。
- スキルで代替できるもの — レビュー・コミット手順・ドキュメント生成のような、手順とプロンプトの工夫で実現できるもの。自分のプロジェクトに最適化したスキルの方が強いことが多い
- プラグインでしか得られないもの — LSP のような外部プロセスとの連携、外部サービスとの認証付き連携など、プロンプトでは代替できない実体を持つもの
プラグインを評価するときは「便利かどうか」だけでなく、「これはスキルとして自分で書けるものか」を一度考えてみると判断がクリアになります。書けるなら、プラグインは卒業できます。
まとめ
/checkup を実際に使ってみて、次のことが分かりました。
- v2.1.205 で
/doctorは診断から修正提案まで行うフルチェックアップに進化し、/checkupという新しい名前でも呼べるようになった。既存の/doctorはそのまま使える後方互換 - 実行してみると生涯利用0のプラグインが9個見つかった一方、「使うべきなのに組み込めていない」プラグインの存在にも気づけた
- 削除のメリットはコンテキスト固定費の削減・誤呼び出しリスクの低減・セキュリティ運用対象の縮小。デメリットは存在を忘れて劣化した自力実装で進むリスクと再導入コスト
- 全消し・全温存の二択ではなく、「代替できるか」「使う場面を説明できるか」「消したときの損失が大きいか」の3問で仕分けし、残すものは理由を明文化する
- 自前のスキルが上位互換になっているプラグインは、迷わず消してよい
おすすめ記事やマーケットプレイスを見て「便利そうだから」と入れたプラグインが、意味をよく分からないまま溜まっている方は多いと思います。/checkup なら診断から整理までを対話的に進められるので、これを機に一度、自分の環境を棚卸ししてみてはどうでしょうか。
なお、プラグインを導入する段階での選び方はプラグイン選定基準の記事に、日常的に利用状況の数字を眺める方法は /usage コマンドの記事にまとめています。導入時の選定・日常の観測・定期の棚卸しをセットで回すと、Claude Code の環境をずっと軽く保てるはずです。