Claude Code Skills 発火率10%

Claude Code Skills の SKILL.md を101本運用しています。28日測ったら、動いたのは9本 (+ workflow 起動型1本、合計10本)。残り92本は1回も呼ばれていません。

「発火」の定義はあとで詰めます。動いた9本と沈黙した92本の SKILL.md を並べると description の書き方が明確に違います。前記事「Skills を10個書いたら4個に統合された」と「Skills に入れると壊れる処理3種類」は Skill を残すかどうかの話でした。今回は残った Skill が description の書き方で呼ばれ方が変わる 話です。

何を測ったか (計測条件)

Claude Code の Skill は tool_use で発火します。ログの name: "Skill" を数えれば発火回数です。この定義で28日窓は 10種類 / 352回。うち9種類は SKILL.md 実体持ち、1種類 (kenimoto-dev-strategist-2026-06-25) はワークフロー起動型で SKILL.md ファイルは101本コーパスに入っていません。

実測: 動いた10本

「うち auto」の判定は素朴です。tool_use の直前の user メッセージが /skill-name で始まり skill 名と一致したら slash 起動、そうでなければ auto 起動 (モデルが description を読んで自律的に呼んだ扱い)。slash 278回 / auto 74回。

description の書き方が効くのは auto の74回のみ です。slash は description が空でも動きます。

動いた10本の description の共通点

動いた9本 (SKILL.md 実体持ち) の description を並べます。

avoid-ai-writing-ja-detect (148字):

日本語AI Slop検出専用スキル(slim版)。違反検出のみ、書き換え例なし。違反が見つかったら /avoid-ai-writing-ja-rewrite を呼び出して修正ガイダンスを取得する。avoid-ai-writing-ja-rewrite と組で使用してQCのトークン消費を削減する。

avoid-ai-writing-ja-rewrite (180字):

日本語AI Slop違反の書き換えガイダンス。/avoid-ai-writing-ja-detect が違反を検出した後にロードする。置換ルール、before/after例、false-positive 例外、second pass の variant migration check を提供。avoid-ai-writing-ja-detect と組で使用。

generate-image (105字):

スライド風/書籍用の図解画像を HTML + Puppeteer で生成する。記事サムネイル、図解、概念図、章扉、表紙の作成に使用。navy-mono スタイル、1 章あたり 3-5 枚の図解密度を目安にする。

3つの型が共存しています。

1. chain先の /skill-name を description に書く: detect 側は description の中で /avoid-ai-writing-ja-rewrite を呼び出せと書いてある。連鎖の相方を description が自己申告している。
2. 前段の起動条件を書く: rewrite 側は「detect が違反を検出した後にロードする」と自分が呼ばれる条件を明示している。
3. 具体的な用途 (成果物・使うタイミング) を書く: generate-image は「サムネイル、図解、概念図、章扉、表紙の作成に使用」と用途を並べる。「画像を作るスキル」だけでは足りず、Claude が「今この状況で必要」と判定するトリガー語 (図解、章扉) が要ります。

数値で見ると、動いた 9本のうち7本が description に他スキルへの /skill-name 参照を含む のに対して、沈黙した 92本では7本のみ です。7/9 と 7/92、比率で約10倍の差。

沈黙した92本に多い型

長い description = 発火する、ではありません。以下は沈黙側の抜粋です。

ship-x (367字、沈黙):

X (Twitter) 投稿のオーケストレーション。アルゴリズム知見(SimClusters/スコアリング重み/TweepCred)に基づく投稿設計。フォロワー段階別戦略・3戦略型・トップエンジニアパターンを参照し、ネタ選定→投稿文生成→品質チェック→…

wan2gp (469字、沈黙):

autocrew-pc の RTX 4070 12GB 上で Wan2GP のローカル画像生成 (—gen) と既存画像の指示ベース編集 (—edit) を扱うスキル。wgp.py —mcp を streamable-http:7861 で起動し…

長さは 48〜469字とバラバラですが、共通の書き方は 「これは X 用のスキル」で終わっている ことです。ship-x は「X 投稿のオーケストレーション」、wan2gp は「Wan2GP のローカル画像生成を扱うスキル」。名詞句で完結してしまい、Claude 側が「今の作業でこれを呼ぶべきか」を判定できません。

400字書いても沈黙する。私は description を書きすぎれば拾ってもらえると思っていたのですが、字数ではなく「今、呼ぶべきか」の材料でした。

相関の観察であり、実験ではない

これは因果の証明ではなく相関の観察です。動いた Skill は AI Slop QC と画像生成という、そもそも頻度が高い作業に紐付いています。description の書き方が良かったのではなく、需要が多かったから呼ばれただけかもしれません。因果を言うなら「同じ Skill を description だけ書き換えて A/B」が必要ですが、私はまだやっていません。

言えるのは、auto fire の74回はすべて description に slash chain または用途語句が入っている8本のスキル (SKILL.md 実体 7本 + workflow 1本) に集中していた という事実だけです。SKILL.md コーパス 101本の残り 94本は auto では1回も呼ばれませんでした。

私が明日からやること

沈黙している92本のうち、chain load を想定して置いてあった Skill (rewrite 系、pair skill 系) は description に slash 参照を追記します。ship-x のような単発オーケストレーションは、自律発火させたいのか常に手動起動なのかを決めて、後者なら description を極短にしてトークンを節約します。

Skill を消すか残すかの前に、SKILL.md の1行目が「これは何か」で終わっているか、「いつ呼ぶか」まで書いてあるかを見ます。書きすぎた description はまだ書き足りていない description です。

制約と再現性

Skill の設計と運用は Claude Code Mastery にまとめています。Skills / MCP / Hook / Sub-agent の分け方は、この本と冒頭の関連記事2本を先に読むと繋がります。