先に結論を書きます。
私は Claude Code の Skills(.claude/skills/*.md)を 4ヶ月で 60個作りました。呼び出しログを掘り返して稼働率別に並べたら、毎日使うのは 10個、週次が 12個、月次が 6個、そして 32個は 4ヶ月間で 1度も走っていませんでした。数え直したので何度でも書きます。60個中 32個、およそ 53% が死蔵です。「Skills は溜め込むほど便利になる」というのは、少なくとも私の運用では嘘でした。
10個で回す前提で作らないと、書いた本人が忘れます。
この記事のスコープと既存記事との差分
Claude Code の周辺機能は名前が似た兄弟が多いので、位置づけを先に切ります。
- 本記事は Skills =
.claude/skills/*.mdの話です - CLAUDE.md(プロジェクト規約や振る舞い定義)とは別コンポーネント
- Memory 機能(会話をまたぐ長期記憶)とも別
- Sub-agents(独立コンテキストで走る子エージェント)とも別
だから「CLAUDE.md は何行まで効くのか」や「Memory 設計 3つの方法」を読んだ方には、重ならない内容になっているはずで、本記事は Skills を 4ヶ月使い続けたあとの「使ってもらえた/もらえなかった」の分解で、Skills の書き方指南でも Marketplace 予想でもありません。
検証セットアップ
対象は私が sns-operations リポジトリ配下で運用している .claude/skills/*.md = 60個です。手元でカウントすると sns-operations/.claude/skills/ に 60ディレクトリ。その他 iris-hub や zenn-content 側は本記事の集計対象外にしました。他リポジトリを混ぜると「共通skill」の呼び出しが二重にカウントされてしまうためです。
| 項目 | 内容 |
|---|---|
| 対象 | sns-operations/.claude/skills/ 配下 60個 |
| 期間 | 2026-04-01 〜 2026-08-01(4ヶ月) |
| モデル | Claude Opus 4.6 → 4.7(途中でアップグレード) |
| 判定材料 | 呼び出しログ + 実タスク履歴(週次の運用記録) |
| 除外 | 他リポジトリ配下の skills、廃止済み skill |
分類の定義
呼び出し頻度で 4カテゴリに割り振りました。
- 毎日: 週 5日以上、実タスクで自然に呼ばれる skill
- 週次: 週 1〜4回、特定曜日の作業で使う skill
- 月次: 月 1〜4回、キャンペーン/締めなどで使う skill
- 未使用: 4ヶ月間、私が呼び出した記録が 0回の skill
判定境界の記事(たとえば週 4.5回)は 5件ほどありました。この 5件は「週次」に寄せて集計しています。境界サンプルの分類差で結論が動くことはありません。
実測結果
まず全体の内訳。
| カテゴリ | 件数 | 割合 |
|---|---|---|
| 毎日 | 10 | 17% |
| 週次 | 12 | 20% |
| 月次 | 6 | 10% |
| 未使用 | 32 | 53% |
| 合計 | 60 | 100% |
「Skills は増やすほど強くなる」と思って作り続けていましたが、実測は逆で、60個作った後半戦では、書いても書いても未使用が積み上がりました。呼ばれない skill は存在しないのと同じで、CLAUDE.md の推薦テーブルを重くしているだけです。
稼働率分布のグラフ的まとめ
上位 20% (毎日 + 週次の一部)で全呼び出しの 8割以上を占めていました。パレートの法則がそのまま出ています。当たり前と言われそうですが、書いている本人としては 60個を全部大事に育てているつもりだったので、この偏りは想像以上でした。
作った時期と稼働率の相関も見ました。直近1ヶ月で書いた skill の方が呼び出し率が高い、というシンプルな傾向がありました。書いた直後は名前も用途も覚えていて手癖で呼べるので、当然と言えば当然です。逆に言うと、3ヶ月前に書いた skill を「まだ残す価値があるか」で判定するのは、私の記憶力では無理でした。機械的に「前四半期に 0回なら退場」の方が現実的です。
毎日使う 10個の中身
匿名化しつつ、私の毎日 skill 10個を並べます。「よく使う skill」を晒すだけで新しい skill を書きたくなる副作用があるので、機能カテゴリで整理します。
| # | カテゴリ | 用途 | 呼び出し頻度(推定) |
|---|---|---|---|
| 1 | 記事レビュー | 完成原稿の AI Slop チェック | 1日 3〜5回 |
| 2 | 記事レビュー | プラットフォーム別の投稿前一括レビュー | 1日 2〜4回 |
| 3 | 画像生成 | HTML + Puppeteer で図解生成 | 1日 2〜3回 |
| 4 | 画像レビュー | anti-patterns.yaml 照合の画像QA | 1日 2〜3回 |
| 5 | 出版 | 記事APIポスト+カレンダー登録 | 1日 1〜2回 |
| 6 | 通知 | 完了/ブロックの Telegram 送信 | 1日 3〜6回 |
| 7 | 出版 | 記事ネタの事前スコアリング | 1日 1〜2回 |
| 8 | 出版 | 記事の 6フェーズ受け予測 | 1日 1〜2回 |
| 9 | 出版 | 記事の 4フェーズ全対応レビュー | 1日 1〜2回 |
| 10 | 運用 | Book/Kindle への導線ブロック生成 | 1日 1回 |
10個中 6個が「記事を出す一連のパイプラインの部品」で、書いている自分の日次業務は「記事を書いて、レビューして、画像を作って、投稿する」に尖っていて、そこに沿った skill だけが自然と呼ばれています。
逆に言うと、業務の中心から外れた skill は、私が忘れます。
もう1つ、集計してから気づいたことがあります。毎日の 10個は、どれも「単独で完結する道具」ではなく「他の skill を呼び出す/呼び出されるハブ」になっていました。たとえば「記事の一括レビュー」skill は、その中で「AI Slop チェック」と「画像レビュー」を呼び出しています。パイプラインの結節点にある skill は、隣接する作業のたびに引っ張り出されるので、稼働率が自然に上がります。単独ノードの skill は、記事本文で言うところの脚注と同じで、書いた本人しか場所を覚えていません。
死蔵 32個の理由 — なぜ書いたのに使われなかったか
未使用 32個を眺め直して、「作ったけど呼ばなかった理由」を私自身の記憶で 5タグに振り分けました。理由が複数ある skill は主因 1つに寄せています。
| 理由タグ | 件数 | 割合 |
|---|---|---|
| A. 一度きりの用途を汎用化しすぎた | 11 | 34% |
| B. 別 skill と機能重複 | 8 | 25% |
| C. 起動プロンプトを忘れた | 6 | 19% |
| D. 対象システムが廃止/変更された | 4 | 13% |
| E. そもそも自動化する必然性がなかった | 3 | 9% |
一番多かったのは A、「一度きりの用途を汎用化しすぎた」11件 です。ある1日の作業で不便を感じて汎用skillに仕立てましたが、その作業自体がその後発生しない。汎用化のコストだけ払って回収がゼロというパターンです。
理由A: 汎用化しすぎた 11件
具体例(匿名化)としては、「Pinterest のインサイトを DL して集計する skill」がありました。作った当日は 3ボード ×4週分を回して便利でしたが、翌週から Pinterest 運用そのものを一旦停止したので、それきり呼ばれていません。私の場合、単発の作業を skill にする前に「これは 3週間後にもやるか?」を自問しない限り、9割はここに落ちます。
理由B: 別 skill と機能重複 8件
これは自分の記憶容量の問題。
似た機能の skill が 2つあると、あとから作った方は呼ばれません。たとえば「記事レビュー系」で古い版と新しい版が並走してしまい、新しい方に統合したあとも古い方をディレクトリごと消し忘れて残っていました。CLAUDE.md 側の記述で新しい方を推薦していると、古い方は永遠に呼ばれません。
もう1つ、「画像生成系」でも似たことが起きました。最初は用途別に 4個に分けていたのですが、実際には汎用の 1個で十分で、細かい調整は CLAUDE.md 側のプロンプトで賄えていました。「用途別に分けた方が便利」と書いた瞬間は思っていましたが、その判断が正しかったかどうかは、書いてから 4週間後に呼び出しログを見るまでわかりません。
理由C: 起動プロンプトを忘れた 6件
書いた瞬間は「よし、今度から /xyz で呼ぼう」と決意しますが、翌週になると /xyz の存在を忘れています。skill 名が英字略語のパターンで多発しました。「これは何をする skill か」を思い出せない名前は、私にとっては呼び出し不能です。
対策として、書いた直後に「今週この skill を呼ぶ場面はいつか」を予定表に書き出したこともありました。ですが、その予定表そのものを翌週忘れていたので、リマインドの上にリマインドを積む形になっただけでした。名前で用途が自明でない skill は、後付けの工夫を何段積んでも呼ばれません。
理由D: 対象システムが廃止/変更 4件
これは自分だけの責任ではないですが、外部APIの仕様変更や社内ツールの廃止で使えなくなった skill です。skill 自体は残るので、清掃をサボると「動かない skill」だけが積みあがります。四半期に 1回は掃除した方がいいのですが、私はまだ 1度しかやっていません。
理由E: 自動化の必然性がなかった 3件
「これは skill にするほどでもなかった」パターンです。
ワンライナー相当のことを skill 化してしまい、Claude Code に呼ばせるより自分でコマンドを打った方が速い。skill にする閾値を下げすぎた典型例です。
死蔵率 53% を下げる 3つの運用ルール
4ヶ月で失敗してきた自分向けに、8月から次の 3ルールに切り替えました。
1. 「3週間後にもやるか?」の自問を skill 化前の必須ステップにする
理由A(汎用化しすぎ)の 11件は全部これで防げたはずです。skill 化する前に、私は今その作業を今月中にもう 2回やる予定があるか、自分に聞くことにしました。
答えが No なら、その場限りのプロンプトで済ませます。
2. 名前は「動作 + 対象」で日本語混じりも可にする
「起動プロンプトを忘れた 6件」は、名前が抽象すぎて思い出せなかったパターンです。今後は qiita-記事レビュー のように、日本語混じりでも動作+対象がわかる命名に統一しています。
英字4文字略語は禁じ手にしました。
3. 四半期ごとに全 skill を「1呼び出し以上あったか」で棚卸し
四半期の頭に、前四半期に 0呼び出しの skill を強制退場ゾーンに移し、次の四半期でも呼ばれなければアーカイブへ落とし、skill を捨てるのは書いた本人が一番惜しく感じる作業なので、機械的なルールで押し切るしかありません。
Skills を書いていない読者の方へ
ここまでは書いた側の反省会でしたが、Skills をまだ書いていない Claude Code ユーザーの方向けに、私が今の視点で「最初の 3個」を挙げるとしたら次です。
- 週次以上で走る「投稿レビュー」「投稿実行」「通知」の 3つに寄せる
- 名前は動作+対象、英字略語禁止
- 3週間後にもやるかを自問して、Yes だけ skill 化
60個を勢いで書いた 4ヶ月の結論は、書く数より、書いた後に呼ぶ回数 に尽きました。skill の総数は履歴書ではありません。
呼ばれない skill は、いないのと同じ。
Skills 3層に整理した書籍
Skills / CLAUDE.md / Memory の使い分けは、Claude Code の 4ヶ月運用で私が一番迷った領域でした。CLAUDE.md 全体設計、Skills の粒度、Memory の使い所を 3層で整理した書籍を出しています。よかったら手に取ってみてください。
Claude Code Mastery — CLAUDE.md × Skills × Memory の実務ガイド
まとめ
- 4ヶ月で作った Skills 60個のうち、毎日 10個 / 週次 12個 / 月次 6個 / 未使用 32個(53%)
- 未使用の主因は「一度きりの用途を汎用化した」34%、次点で「別 skill と機能重複」25%
- 毎日使う 10個は「記事を出すパイプライン」に集中していて、業務の中心から外れた skill は書いた本人が忘れる
- 8月からの新ルール: 「3週間後にもやるか?」を skill 化前の必須ステップ、名前は動作+対象、四半期棚卸し
Skills はナレッジベースではなく、日次業務の道具箱です。道具箱に工具を 60本詰め込んでも、腕は 2本しかありません。10本届く場所に置く運用にしないと、書いた本人が最初に忘れます。
私の 4ヶ月はその実演。