Skillを1本書き終えると、そこで仕事が終わったように感じます。しかし実際にはここからが運用の始まりです。Claude Codeの仕様は変わり、業務のやり方も変わります。放置したSkillは少しずつ現実とずれていき、いつの間にか誰も使わなくなります。この章では、Skillが腐る兆候の見分け方と、改訂を安全に行う作法をまとめます。
Skillが腐る3つの兆候
Skillの劣化は突然起きるのではなく、次の3つの兆候として先に現れます。
1. 呼ばれなくなる
以前は毎日使っていたSkillが、いつの間にか呼び出されなくなっている状態です。原因の多くは、業務のやり方自体が変わり、Skillが書いた手順と現場の手順がずれてしまったことにあります。使用履歴を月1回でも見返せば気づけます。
2. 途中で質問が増える
実行中にAIから確認の質問が増えてきたら、判断基準が古くなっているサインです。第1章で触れたとおり、良いSkillは「迷ったらどちらを選ぶか」まで書いてあります。この判断基準が現状に合わなくなると、AIは自分で決められず質問を返してくるようになります。
3. 出力の手直しが増える
Skillの出力をそのまま使えず、毎回手で直す量が増えてきたら要注意です。完了条件が現状の期待水準より緩くなっている、あるいは前提としていた外部環境（フォーマット、ツールのバージョンなど）が変わっている可能性があります。
Claude Code側の変化と業務側の変化に追随する
Skillがずれる原因は大きく2種類に分かれます。1つはClaude Code側の仕様変更です。呼び出し方法やSkillの読み込み挙動が変われば、古い書き方のまま動かなくなることがあります。もう1つは業務側の変化で、担当者の交代、取引先のルール変更、使用ツールの入れ替えなどによって、Skillに書いた手順そのものが現実と合わなくなります。どちらも定期的に見直さない限り自然には直りません。
改訂の作法。動いている版を残して差分で直す
Skillを直すときにやってはいけないのは、いきなり本体を書き換えて上書きすることです。改訂中に別の作業でそのSkillが呼ばれると、不完全な状態のまま実行されてしまいます。Gitで管理していれば、動いている版はコミット履歴にすでに残っています。改訂は新しいコミットとして差分で加え、日付と理由を必ず記録します。
## 改訂履歴
- 2026-06-02: 完了条件に「見出しは32文字以内」を追加。読者アンケートで見出し長すぎの指摘が続いたため
- 2026-07-10: 参考資料のリンク先URLを更新。旧CMSの廃止に伴いURL体系が変わったため
- 2026-07-29: 判断基準に「表記が揺れたら常体に統一する」を追加。質問対応の履歴が3件続いたためこの改訂履歴はSKILL.mdの末尾に書いても、隣に置いた別ファイルに書いても構いません。重要なのは、変更内容と理由がセットで残っていることです。理由がないと、次に見直す人が「なぜこの条件があるのか」を判断できず、不用意に消してしまうことがあります。
定期棚卸しで使っていないSkillを整理する
改訂とは別に、一定の周期でSkill一覧そのものを見直す棚卸しが必要です。棚卸しでやることは主に2つです。
- 使っていないSkillの削除。呼ばれなくなって数か月経つSkillは、業務が変わって不要になった可能性が高いものです。残しておくと一覧が肥大化し、必要なSkillを探す手間が増えます。削除する前に、本当に不要か担当者に確認してから消します。
- 重複の統合。似た用途のSkillが複数本できていることがあります。担当者が違う、作った時期が違うといった理由で同じような手順が別々のSkillとして存在すると、どちらを直したのか分からなくなります。統合できるものは1本にまとめ、古いほうは削除します。
棚卸しの頻度に正解はありませんが、四半期に1回程度でも「呼ばれていないSkillはないか」を確認するだけで、一覧の鮮度は保てます。
Skillは一度書いたら終わりの成果物ではなく、コードと同じように保守が必要な資産です。腐る兆候に早く気づき、動いている版を壊さずに差分で直し、定期的に棚卸しをする。この3つを回し続けることが、Skillを長く使えるものにする唯一の方法です。