Skillを10個ほど作ったあたりで、私は「どれが今も使われているのか」を即答できなくなりました。作り方の記事は多いのですが、増えたあとの維持の話はあまり見かけません。この記事は、SaaSの棚卸しと同じ発想でSkillを月次で見直している私の基準と、その運用で気づいたことのメモです。
前提
- 環境: Claude Code + Markdownの手順書（
skills/直下に10ファイル、合計1,708行。2026年10月21日にwc -lで確認） - 注意: 私の手元の手順書は
skills/*.mdに平置きで、公式の置き場所である.claude/skills/<name>/SKILL.mdの構成ではありません（リポジトリに.claude/skillsは存在しないことを確認済み）。以降の「基準」は置き場所に依存しない考え方なので、公式構成でもそのまま使えるはずですが、公式構成での運用は私は未検証です。 - 公式の仕様は次のとおりです（確認日: 2026-10-21）。Skillのdescriptionは通常のセッションで常にコンテキストへ載り、本文は呼び出されたときだけ載ります。
disable-model-invocation: trueを付けるとdescriptionもコンテキストから外れます。descriptionとwhen_to_useの合算は一覧上で1,536文字で切り詰められ、SKILL.mdは500行以内が推奨されています1。
この仕様から、作りすぎの何が問題かが見えます。Skillが増えるほど「常に載るdescription」の総量が増え、Claudeが選ぶ候補も増えます。本文は呼ばれるまで載らないので、行数そのものより「description＋鮮度」が棚卸しの主対象になります。
放置したSkillで実際に起きたこと
例1: 古い口調の例示が残っていた
2026年9月21日、私の環境では応答の口調が以前の設定に戻る現象が出ていました。対処としてコミットしたのは、CLAUDE.mdと4つのSkillファイルから旧設定の語尾の例示を取り除く変更です（変更は8行追加・7行削除）。
原因をこの変更だけで断定することはできません。ただ、「Skillの本文に書いた例示は、呼ばれるたびに会話へ入る」ため、古い前提が残ったまま呼ばれ続けると、その前提が出力に混ざる経路が存在します。本文は呼び出し時にロードされ、以降のターンにも残る、と公式にも書かれています1。
例2: 使われないSkillが3つ溜まっていた
2026年9月28日、使われていないSkill3つ（表紙生成・文章推敲・自動化の見直し）を廃止しました。3ファイルで計314行（118＋121＋75）です。
廃止後、別の手順書に「その旧Skillは廃止済み」という注記だけが残りました。これは意図的な履歴の注記ですが、別日にgrepで棚卸しをしたとき、廃止Skillへの言及として一度検出されました。棚卸しは削除したら終わりではなく、参照側の掃除までが1セットです。
例3: 同じ発想はSaaSで先に経験していた
以前、社内で使っていたSaaSが35個に膨れていたことがあります。試験導入のまま課金が続いているものや、退職者のアカウントが残っているものもありました。利用者数・月額・最終ログイン日を一覧にし、3か月以上未使用のものを解約して重複機能を統合した結果、35個が22個、月額は45万円から28万円になりました。
このとき学んだのは、放置されるのは「試しに入れたもの」が圧倒的に多い、ということです。Skillもまったく同じ形で溜まります。
棚卸しの基準（私の運用ルール）
次の3軸で、月1回、Skillごとに判定します。数値の閾値は私が決めた運用ルールであり、Claude Codeの仕様ではありません。
| 軸 | 何を見るか | 私の環境での測り方 |
|---|---|---|
| 最終利用 | 直近で使ったか | 利用ログは取っていないため、最終更新日と参照数で代用 |
| 呼び出し頻度 | 月に何回使うか | 手動呼び出しの記憶＋自動処理からの参照数 |
| 保守コスト | 前提が変わるたびに直す必要があるか | 本文が参照している他ファイルの数 |
判定は次の4つに分けます。
| 判定 | 条件（私のルール） | アクション |
|---|---|---|
| 残す | 月1回以上使う、かつ最近更新している | 何もしない |
| 統合する | 似た目的のSkillが2つ以上ある | 片方へ寄せて一方を廃止 |
| 凍結する | 年に数回しか使わないが、消すと再作成が高コスト |
disable-model-invocation: true でdescriptionをコンテキストから外す1
|
| 捨てる | 3か月以上使っておらず、再作成が30分以内 | 削除し、参照側も同時に掃除 |
「捨てる」の閾値は、MCPツール化したときの感覚が元になっています。社内APIをMCPツールとして1つ作るのに30分程度かかり、手動操作と比べて作業時間が約8割減りました。つまり、30分で作り直せるものは、持ち続ける保守コストより捨てて必要になったとき作るほうが安いという判断です。逆に作り直しに数時間かかるものは、捨てずに凍結に回します。
最終更新日を機械的に出す（実行済み）
利用ログがないので、最終更新日で代用します。次のコマンドを手元のリポジトリで実行しました（Git管理下の skills/ が対象。実行日: 2026-10-21）。
git log --format='D %cs' --name-only -- skills/ | awk '/^D /{d=$2;next} NF&&!seen[$0]++{print d, $0}'
出力（現存するファイルのみ抜粋）は次のとおりです。
2026-10-14 skills/browser-capture.md
2026-10-11 skills/machine-health.md
2026-10-11 skills/worklog.md
2026-10-05 skills/task-triage.md
2026-10-01 skills/write-blog.md
2026-09-28 skills/make-deck.md
2026-09-21 skills/interview-sim.md
2026-09-21 skills/write-book-review.md
2026-09-16 skills/council.md
2026-07-08 skills/validate-hypothesis.md
このコマンドが示すのは「最後にコミットで変更された日」だけで、使われたかどうかではありません。たとえば validate-hypothesis.md（405行・最終更新2026-07-08）は3か月以上動いていませんが、「新規事業の前に必ず通すゲート」なので、更新がないこと自体は問題ではありません。更新日が古い＝捨てる、とは判定しません。更新日は「疑う候補を出す」までで、残す・捨てるの判断は用途で決めます。
Skill化すべき作業・すべきでない作業
棚卸しを続けると、そもそも作るべきでなかったSkillが見えてきます。私の線引きは次のとおりです。
| Skill化する | Skill化しない |
|---|---|
| 手順と出力形式が固定されている（レビュー結果を重要度3段階で出す等） | 毎回前提が違い、判断の材料が変わる作業 |
| 月1回以上、繰り返す | 一度きり、または年1回以下 |
| 失敗したときの影響が大きく、手順を固定したい | 失敗しても影響が小さく、都度指示のほうが速い |
「出力形式が固定されている作業」は特にSkillと相性がよいです。コードレビューで指摘の粒度がバラバラだったとき、重要度（Critical/Warning/Info）の分類基準をFew-shotで3パターン添えたところ、出力が重要度別に整理され、確認時間は半分になりました。こういう「形が決まっている作業」は、毎回プロンプトを書くよりSkillにしたほうが安定します。
一方、「毎回考え直す作業」をSkillにすると、手順が固定されているのに状況が変わるので、本文がすぐ古くなります。Skillが腐る原因の多くは、作り方ではなく、作る対象の選び方にあると私は考えています。
Skill自体のバージョン管理
プロンプトが20種類を超えたとき、どれが最新で、どの変更が効いたのかが追えなくなりました。そこで各プロンプトをGitで管理し、変更理由をコミットメッセージに残す運用に変えたところ、「先週のほうがよかった」という場面でもすぐ戻せるようになりました。
Skillも同じです。上のコマンドが使えるのは、Skillをすべてgit管理しているからです。Git管理なしの個人用ディレクトリ（~/.claude/skills/）だけにSkillを置いていると、最終更新日も変更理由も追えず、棚卸しの判断材料が残りません。この点は、棚卸しを始める前に最初に確認したほうがよいところだと思います。
月次棚卸しの手順（そのまま使える形）
- 上のコマンドで最終更新日の一覧を出す
- 3か月以上更新がないものに印を付ける（まだ判定しない）
- 印を付けたものについて、他のファイルから参照されているかを
grepで数える - 用途で判定する（残す／統合／凍結／捨てる）
- 捨てる場合は、参照元の記述も同じコミットで直す
- 判定理由をコミットメッセージに一行残す
実際、廃止した3つのSkillは、5の手順（参照側の掃除）が抜けていて、廃止注記が別の手順書に残ったままでした。
限界
- 利用ログを取っていないため、「使われたか」は更新日と参照数の代用でしか測れていません。実際に呼び出された回数の集計は未実施です。
- 上の閾値（月1回以上、3か月、30分）は私の運用の経験則で、他の環境で成り立つとは限りません。
-
.claude/skills/<name>/SKILL.mdの公式構成でdisable-model-invocationを付けて凍結する運用は、仕様は公式で確認しましたが、私自身の環境では実行していません（私の手順書は平置きのため）。
まとめ
- Skillはdescriptionが常にコンテキストに載り、本文は呼び出し時に載る。増やすほど候補とロード対象が増える
- 月1回、最終更新・呼び出し頻度・保守コストの3軸で「残す・統合・凍結・捨てる」を決める
- 更新日が古いことは捨てる理由にならない。用途と作り直しコストで決める
- 捨てるときは参照側の掃除まで同じコミットで行う
結局、今回いちばん効いたのは「30分で作り直せるものは持たない」という割り切りでした。作る側にいると、手間をかけたものを消すのに抵抗が出ます。ただSaaSの棚卸しで35個が22個になっても業務は止まらなかったように、Skillも数を減らしたほうが、残したものの鮮度を保てると感じています。
今回は月次棚卸しの基準までを書きました。利用ログを取って「実際の呼び出し回数」で判定する運用に変えられたら、その結果は別記事で扱う予定です。Claude Codeや業務自動化まわりの実装で試したことを不定期に書いているので、続きが気になる方は フォロー をどうぞ。
-
Claude Code公式ドキュメント「Skills」 https://code.claude.com/docs/en/skills （"How descriptions and bodies load" / "Description length budget" の各節） ↩ ↩2 ↩3