Claude Codeスキルは何個入れるべきか──入れすぎの弊害と現役の選定基準
「Claude Codeスキルのおすすめまとめをブックマークしたまま、消化できていない」。そんな状態になっていないでしょうか。2026年7月末、X上では「入れるべきスキル22選」というまとめ投稿が2,000いいね・4,000ブックマークを超えて拡散し、plugin marketplaceから数コマンドでスキルを追加できる環境が一気に整いました。一方で「とりあえず入れた結果、どのスキルが効いているのか分からない」「コンテキストを圧迫して逆に精度が落ちた気がする」という声も出始めています。
この記事は、Claude Codeのスキルを何個・どういう基準で入れるべきかを、導入コマンドから選定基準、削り方まで具体的に整理する実践ガイドです。対象は、Claude Codeを日常業務で使っていて、スキル拡張を検討している現役エンジニア。僕自身、GitHub CopilotとCursorをやめてClaude Code一本に絞った経験から「足すより絞る」という判断軸を持っており、その基準をスキル選定に落とし込みます。読み終える頃には、バズまとめを鵜呑みにせず、自分の業務に必要なスキルだけを最小構成で運用する手順が手に入るはずです。
背景・課題──Claude Codeスキル「入れ放題」時代の到来
まず前提を整理します。Claude CodeのスキルはSKILL.mdというMarkdownファイルを核にしたフォルダで、特定のタスク手順や専門知識をパッケージ化したものです。個人用なら ~/.claude/skills/、プロジェクト用なら .claude/skills/ に置くだけで認識されます。詳細はAnthropic公式ドキュメントのスキル解説にまとまっています。
2025年10月にAnthropicがAgent Skillsを発表して以降、スキルは個人が手元で書くものから、コミュニティで配布・共有するものへと性格を変えました。配布経路の中心がplugin marketplaceです。次の2コマンドで、公開されているスキル群を数十秒で導入できます。
# マーケットプレイスを登録する
/plugin marketplace add <GitHubのowner/repo>
# スキルを含むプラグインをインストールする
/plugin install <プラグイン名>@<マーケットプレイス名>コミュニティのレジストリ経由なら、ターミナルから npx skills add <owner/repo> の1行で追加できるものもあります。導入の摩擦は、もうほとんどゼロと言っていい状況です。
この手軽さを背景に、2026年7月末のXでは「You installed Claude Code and stopped there.（Claude Codeを入れて、そこで止まっていないか）」という書き出しの「入れるべきスキル22選」まとめが2,062いいね・4,000ブックマーク超まで拡散しました。同時期には、marketplace経由で配布される動画要約スキルの紹介投稿も2,000いいね規模でバズっており、「スキルは入れるほど強くなる」という空気が広がっています。
ただ、ここに落とし穴があります。スキルは起動時に全スキルの名前と説明文がコンテキストに読み込まれる設計です（本文は使うときに読み込まれるProgressive Disclosure方式）。つまり1個あたりの負荷は小さくても、数が増えれば常駐する説明文の総量は確実に増えます。22個入れれば、22個分の説明文が毎セッション、あなたの本来のタスクと同じコンテキストを分け合うことになる。さらに、使っていないスキルが意図しない場面で発動して挙動が読みにくくなる、という副作用もあります。「全部入れる」は、実は無料ではないのです。
僕がCopilotとCursorをやめて「絞る」ことにした理由
ここで僕自身の話をひとつ。僕はSaaS企業でAI/OCR関連の開発をしている現役エンジニアだけど、2026年時点で、AIコーディングツールはClaude Code一本に絞っている。MAXプランの月$100だ。以前はGitHub Copilotも使っていたし、Cursorも試していた。ただCursorは僕の環境ではPCのメモリ負荷が大きすぎて、開発中に重さがストレスになった。Copilotも役割がClaude Codeと重なっていたのでやめた。ツールは多く使えばいいわけじゃない。自分に合うものに絞ったほうが、明らかに集中できる──これが実際に絞ってみて得た実感だ。
もうひとつ実感していることがある。Claude Codeはゴールが明確なほど正しく動く、ということ。曖昧なまま投げるとズレた出力が返ってくるので、先にClaudeと壁打ちしてゴールを整理してから実装に入るようにしている。つまり、精度を決めているのはスキルの数じゃなくて、素の使い方の質なんだよね。
この2つの経験をスキル選定という視点で見ると、結論はシンプルです。スキルを足す前に、素のClaude Codeで精度を出す基本が先。そのうえで足すなら、ツール本体で下したのと同じ「絞る」判断をスキルにも適用する。次のセクションで、その具体的な基準に落とし込みます。
Claude Codeスキルを選ぶ3基準と導入・削除の手順
選定の3基準
僕がスキルを入れるかどうかを判断するときの基準は3つです。
- 週1回以上使う頻度があるか。月1回しか使わないスキルは、常駐させる価値がありません。必要になったときに入れれば数十秒で済みます
- コンテキスト消費に見合うか。そのスキルの説明文が毎セッション読み込まれるコストを払ってでも、自動発動してほしいタスクか。
/contextコマンドで現在のコンテキスト内訳を確認し、スキルやツール定義がどれだけ占めているかを見る習慣をつけると判断しやすくなります - プロンプトで代替できないか。「コミットメッセージはこの形式で」程度の指示なら、CLAUDE.mdに1行書けば足ります。スキルにする価値があるのは、手順が複数ステップにわたる、参照ファイルやスクリプトを伴う、毎回書くには長すぎる、といった場合だけです
3つすべてにYESと答えられるものだけ入れる。これだけで、22選のうち残るのはたいてい2〜4個になります。
導入・確認・削除の具体手順
導入から削除までの流れをコマンドで示します。
# 1. マーケットプレイスを登録（例: Anthropic公式のスキル集）
/plugin marketplace add anthropics/skills
# 2. 対話UIで内容を確認してからインストール
/plugin
# 3. 現在のコンテキスト消費を確認
/context
# 4. 使わないと判断したプラグインを削除
/plugin uninstall <プラグイン名>手動で置いたスキルなら、ディレクトリごと消すだけです。
rm -rf ~/.claude/skills/<スキル名>ポイントは、2の段階で必ず中身を読むことです。スキルの実体はMarkdownとスクリプトなので、インストール前にGitHubリポジトリでSKILL.mdを開けば、何をするものか数分で把握できます。Anthropic公式のskillsリポジトリのように、ソースが読める場所から入れるのが基本です。
自作スキルの最小構成を知っておく
marketplaceから探す前に、自作という選択肢も知っておくと判断の幅が広がります。スキルの実体は、フォルダにSKILL.mdを1枚置くだけで成立します。
---
name: release-note-draft
description: リリースノートの下書きを社内フォーマットで作成する。リリース準備やタグ作成の依頼時に使う
---
# リリースノート下書き
1. 前回タグ以降のコミットを git log で取得する
2. 変更を「機能追加」「修正」「内部改善」に分類する
3. docs/templates/release.md のフォーマットで下書きを出力するこれだけで動きます。要になるのはdescriptionです。Claude Codeはこの説明文を見て発動するかどうかを判断するため、「何をするか」だけでなく「いつ使うか」まで具体的に書くほど、誤発動が減ります。僕の場合、基準3の「プロンプトで代替できないか」でスキル化を決めたものは、まずこの最小構成で書いて、参照ファイルやスクリプトは実際に必要になってから足すようにしています。そのほうが手戻りが少ない。そして副次効果として、この形を一度自分で書いておくと、marketplace製スキルのSKILL.mdを開いたときに「descriptionが広すぎる」「手順が曖昧」といった問題点にすぐ気づけるようになります。他人のスキルを評価する目は、自分で1個書くのがいちばん早く育ちます。
入れる価値が高いスキル・保留すべきスキルの見分け方
観点別に、優先していいスキルと保留すべきスキルを整理すると次のようになります。
| 観点 | 入れる価値が高いスキル | 保留すべきスキル | |---|---|---| | 使用頻度 | 毎日の業務フローに組み込まれる（PDF/Excel処理、定型レビューなど） | デモで面白かっただけで業務に接点がない | | 代替可能性 | 複数ステップの手順・参照資料・スクリプトを伴う | CLAUDE.mdの1〜2行で同じ効果が出る | | 提供元 | 公式リポジトリ、または自分でソースを読んで理解できるもの | 作者不明・ソース未確認・スター数だけが根拠 | | 発動条件 | 発動してほしい場面が明確に限定されている | 説明文が広すぎて意図しない場面で発動しそう | | 検証可能性 | 効果の有無を自分のタスクで確認できる | 「精度が上がる気がする」以上の検証ができない |
僕の推奨は、まず0個から始めることです。素のClaude Code＋整理されたCLAUDE.mdで1〜2週間仕事をして、「毎回同じ長い指示を書いている」と気づいた箇所だけをスキル化、またはmarketplaceから導入する。最初の構成は、自分の業務で頻度が高いドキュメント処理系を1個、リポジトリ固有の手順を自作で1〜2個、合計2〜3個で十分です。そこから先は「1個足したら、使っていない1個を削る」を目安にすると、把握できる範囲を超えません。
運用の定期メンテナンス
入れて終わりにせず、月1回の棚卸しをおすすめします。やることは3つだけです。
/pluginでインストール済み一覧を開く- 過去1ヶ月で発動した記憶がないスキルを特定する
- 迷ったら削除する。本当に必要なら、必要になった日に数十秒で再導入できます
「消すのがもったいない」と感じるかもしれませんが、再導入コストがほぼゼロである以上、常駐させておく理由にはなりません。この非対称性が、スキル運用でいちばん大事な感覚だと思います。
削除するときは、「スキル名・入れた日・消した理由」を1行だけメモに残しておくと後で効いてきます。「PDF処理スキル、6月導入、月2回しか使わなかったので削除」程度で十分です。数ヶ月後に「またあれを入れようかな」と思ったとき、このログがあれば同じ検討を最初からやり直さずに済みます。
課題・批判的意見──スター数とセキュリティの罠
ここまで選定基準を述べてきましたが、コミュニティ製スキル固有のリスクにも触れておきます。
第一に、バズまとめの数字は検証できないことが多い点です。「スター数◯◯k」といった表記が短縮URL経由で紹介され、実際のリポジトリを開くと数字が一致しない、あるいはリンク先がまとめ主の宣伝ページだったというケースがあります。いいね数やブックマーク数は「注目されている」ことの証明にはなっても、「品質が高い」ことの証明にはなりません。
第二に、セキュリティです。スキルは実行環境で動くスクリプトを含められるため、サードパーティ製スキルを入れることは、素性の分からないコードに自分の開発環境へのアクセスを渡すことと同義です。Anthropic公式ドキュメントも、信頼できるソースからのみスキルを導入するよう明記しています。最低限、SKILL.mdと同梱スクリプトに目を通してから入れる。読んで理解できないものは入れない。この原則は崩さないほうがいいです。
第三に、前述のコンテキスト圧迫です。スキルが増えるほど常駐する説明文が増え、本来のタスクに使える文脈が目減りします。効果が検証できていないスキルを10個常駐させるくらいなら、ゼロのほうがましというのが僕の感覚です。
そして忘れてほしくないのは、「入れない」も立派な選択肢だということです。スキルはClaude Codeの精度の主因ではありません。ゴールを明確にして渡す、曖昧なら先に壁打ちで整理する。この基本ができていないままスキルを積んでも、曖昧な指示が曖昧に増幅されるだけです。
まとめ──最小構成から始めて、効いたものだけ残す
要点を整理します。
- スキルを足す前に、素のClaude Codeで精度を出す基本（ゴール明確化・壁打ち）が先
- 入れるかどうかは3基準で判断する。週1回以上使うか、コンテキスト消費に見合うか、プロンプトで代替できないか
- 導入前にSKILL.mdと同梱スクリプトを必ず読む。読めないものは入れない
- いいね数・スター数は品質の証明にならない。バズまとめは候補リストとして使い、判断は自分の業務基準で行う
- 月1回棚卸しし、発動した記憶のないスキルは削る。再導入は数十秒でできる
今日できる次のアクションをひとつ挙げるなら、/plugin と /context を開いて、現在入っているスキルの一覧とコンテキスト消費を眺めてみることです。1ヶ月使っていないものが1個でも見つかったら、それを削るところから始めてみてください。
