Claude Code Skillsとは？会社の仕事を「スキル」にして教え直しをなくす全手順｜15個を実運用する記録

Claude Code の Skills は、名前のせいで開発者向けの機能に見えます。 実際、検索して出てくる解説のほとんどはコード生成の文脈です。ところが、うちで一番効いたのはコードとまったく関係のない場所でした——応募文、営業リスト、請求書、議事録。つまり、毎回同じ説明を書いていた業務です。

CLAUDE.mdに会社のルールを書くところまでは、以前に書きました。会社の前提——うちは何の会社か、誰が社長か、数字は捏造しない——をファイルに置いておけば、毎回説明せずに済む。ここまでは想像がつきます。

それでも「また同じ説明をしている」は消えませんでした。

CLAUDE.mdでは消えなかったもの

残ったのは、前提ではなく手順でした。

「応募文は800字で、実績カードから2枚選んで、最後に橋渡しの一文を入れて」。この指示を、応募のたびに書いていました。CLAUDE.mdに書けばいいと思われるかもしれません。ただ、CLAUDE.mdは毎回まるごと読み込まれるファイルです。営業もマーケも経理も全部の手順をそこに書くと、記事を1本書くだけのときにも請求書の手順を読むことになります。

手順は、必要なときだけ開かれてほしい。この一点がSkillsの存在理由でした。

この違いが分かると、置き場所の判断が一気に楽になります。「どの仕事にも効くならCLAUDE.md、特定の仕事にだけ効くならSkills」。うちはこの一行で切り分けています。

実際に動いている15個

現在うちで動いているスキルは15個です。部署ごとに並べるとこうなります。

加えて、頻繁に呼ぶ組み合わせを短縮したスラッシュコマンドが9本（/apply『応募一式』、/mail『客先メールの下書き』など）と、大量に読んで短く返す調査役のサブエージェントが3体あります。

並べると立派に見えますが、この15個は一度に作ったものではありません。同じ説明を3回書いた時点で1個作る、を繰り返しただけです。順番も計画していません。応募が続いた週は営業のスキルが増え、納品が続いた週は制作のスキルが増えました。

作り方は4ステップしかない

スキルの実体は、~/.claude/skills/<名前>/SKILL.md というMarkdownファイル1枚です。冒頭に名前と説明を書き、あとは手順を日本語で書く。それだけです。実際に使っている応募文のスキルなら、こういう中身になります。

プログラムではないので、書けるのは「文章として説明できること」だけです。逆に言えば、人に引き継ぐ手順書が書けるなら、そのまま1個作れます。

作るときの順番はこうしています。

1. 直近で3回書いた指示を、そのままコピーする。 ゼロから書こうとすると手が止まります
2. 迷いどころを表にする。 「800字か400字か」「実績カードをどれにするか」——判断が分かれる場所だけ表で書き切る
3. descriptionに"呼ばれ方"を書く。 ここが一番重要で、後述します
4. 1回使って、間違えたところを直す。 完成させてから使うのではなく、使いながら直す

3番だけ補足が要ります。description は「何をするスキルか」ではなく「どんな言い方で頼まれたときに開くか」を書く欄です。うちも最初は「応募文を作成するスキル」とだけ書いていて、まったく呼ばれませんでした。「サンカクの応募文」「この案件に応募したい」という実際に自分が使う言い回しを並べてから、狙いどおりに開くようになりました。

分量は、22行から488行まで開いた

作る前は「1個あたりどれくらい書けばいいのか」が一番分かりませんでした。実測はこうです。

中央値は87行でした。原稿用紙にして2枚強です。この数字を先に知っていれば、うちも最初の1個を書くのに悩まずに済んだはずです。

長くなりすぎたスキルは、参照ファイルに逃がします。gig-application は本体188行のほかに references/achievements.md（実績カードの一覧）を持っていて、本体からはそこを見るよう指示するだけにしています。営業リストのスキルも同じ構造で、判定基準のプリセットを別ファイルに置いています。本体は判断を書く場所、referencesは事実を置く場所、という分け方です。

事実を別ファイルにしておくと、実績が増えたときに直す場所が1箇所で済みます。これは効きました。

増やすほど良いのか

ここが、正直まだ答えを出せていないところです。

15個まで増やしたことで、明らかに速くなった実感はあります。一方で、似た名前のスキルが2つあると呼び分けを間違えることも起きました。うちで実際に起きた失敗を3つ挙げます。

① 似たスキルを2つ作ってしまった。 自社ブログとクライアント記事で別々のスキルを作ったところ、どちらを使うべきかが曖昧になりました。今はお互いの description に「クライアント記事は milky-article が担当（混同しない）」と相手の名前を明記して排他にしています。

② やったことのない仕事をスキルにした。 これが一番まずい失敗でした。判断基準が空のまま手順だけが書かれているので、それらしい嘘が量産されます。実績が2〜3回たまってから作る、を後からルールにしました。

③ 数字を本体に直接書いた。 実績の件数をスキル本体に書いてしまい、更新のたびに複数のファイルを探すことになりました。今は「同じ数値を2箇所以上に直書きしない」を全社ルールにしています。

3つとも、共通しているのは「先回りして作った」ことです。

最初の1個をどこから作るか

これから作るなら、今週すでに2回書いた指示を探すところから始めるのが一番速いはずです。営業でも経理でも記事でも構いません。うちの15個も、全部そこから始まっています。

作る順番として迷うなら、Claude Codeでできる業務一覧に業務カテゴリ別の整理があります。会社の前提そのものがまだファイルになっていない場合は、Skillsより先にCLAUDE.mdを書くほうが効きます。役割の設計から入りたい場合はAI社員のつくり方が入口になります。

冒頭の問いに戻ります。Skillsは開発者向けの機能なのか。機能としてはそうです。ただ、うちで一番働いているスキルは、コードを1行も書きません。