Claude Codeのスキルの作り方と、58個まで増やして分かった作らないほうがいい作業

スキルの作り方そのものは、公式ドキュメントを読めば分かります。困るのはその先で、どこまで作ればいいのかが誰も書いていません。仕様の説明はそちらが正確なので、私は運用のほうを書きます。私の手元にはいま、どのプロジェクトでも使える個人スキルが58個、特定の仕事でしか使わないプロジェクトスキルが17個、入口をひとつにまとめる部門ルーターが25枚あります。数だけ並べると自慢に読めますが、正直なところ半年触っていないものも混ざっていますし、増やしたせいで面倒になったこともありました。作ってよかったもの、作らなくてよかったものを、実物の数ごと書いていきます。

Claude Codeのスキルとは、繰り返す手順に名前を付けたもの

スキルというと自動化の話に聞こえますが、実際に手元で起きていることはもっと地味です。毎月なり毎週なり繰り返している定型作業の段取りを、名前で呼べる形にまとめてあるだけです。

たとえば請求書の作成なら、スキルにする前は毎回こう打ち込んでいました。取引先の情報はこのファイルにある、表計算のテンプレートはこれを使う、金額を入れたらHTMLに変換してPDFで書き出す、保存先は年ごとのフォルダ、最後にフォルダを開いて見せてほしい。三行では終わらないので、依頼するたびに書き直していました。しかも書き漏らすと、保存先が違ったり書式が前回と変わったりします。

同じ内容をSKILL.mdというファイルに一度書いておくと、あとは「請求書作って」で通ります。スキルの本体は自動化ではなく、毎回同じ説明をしなくて済むことのほうです。取り違えると、作ってはみたけれど呼ばない、という置物が増えていきます。

プロンプト（AIへの指示文）に毎回書くのとの違いは、三つあります。書いた内容が残ること、次回も同じ順番で動くこと、そして呼ばなければ読み込まれないことです。三番目が地味に大事で、だからこそ数十個入れておいても普段の会話が重くなりません。理屈は後ろの段階的開示のところで書きます。

SKILL.mdに書くのは、見出し情報と手順だけ

スキルの実体は、フォルダひとつとマークダウンのファイル一枚です。スキル名/SKILL.md という形にして、決められた置き場所に入れておきます。

ファイルの先頭には、フロントマターと呼ばれる見出し情報を置きます。--- で挟まれた数行のことで、ここに入れるのは基本的に二つです。

• name：スキルの名前。フォルダ名と揃えます。日本語ではなく英数字とハイフンで付けるのが無難です
• description：どういうときに使うスキルなのか。スキルが呼ばれるかどうかを決める一行なので、あとで一節まるごと使って書きます

私の場合はもうひとつ、そのスキルに使わせる道具の一覧（allowed-tools）を書き足しているものがあります。ファイルを読む、書き換える、ブラウザを開く、といった許可の範囲を先に絞っておくと、想定していない場所を触られる心配が減ります。全部のスキルに付けているわけではなく、公開しているページを触るものや、外部と通信するものだけです。

フロントマターの下は、ただの手順書です。どこにデータの正本があるか、どのファイルは手で触らないか、作業の順番はどうか、終わったら何を確認するか。文章で書けばよく、コードは要りません。私が自分で書いたスキルは、短いもので30行、長いもので300行ほど、多くは100行前後です。まとめて配布される部品（プラグインと呼ばれます。スキルや設定を一式にして入れられる形式です）には600行を超える大作もありますが、長ければ良いというものでもなく、500行以内に収めるのが目安と言われています。

置き場所は3層。個人・プロジェクト・ルーター

個人的に、置き場所の話が一番使えるところだと思っています。同じスキルでも、置く場所によって性格が変わります。私は次の3層で分けています。

個人スキルは、どこで作業していても呼べます。画像生成や文字起こしのように、案件を問わず同じ手順で回るものを置いています。プロジェクトスキルは、そのフォルダで作業しているときだけ現れます。案件ごとの決まりごと、たとえば使ってはいけない言い回しや、提出前に必ず通す確認の順番などは、他の仕事に混ざると邪魔なのでこちらに閉じ込めます。

3つ目のルーターが、検索して出てくる解説記事にほとんど出てこない層です。中身の作業を持たず、「こう聞かれたらこのスキルへ」という振り分け表だけを書いた一枚のファイルを、部門ごとに用意しています。SEOまわりなら /seo、データ分析なら /data、自動化の開発なら /gas という具合に、まず部門の入口を叩けば、あとは表を見て担当のスキルへ渡してくれます。入口のうしろに言葉を足して渡すこともできるので（引数と呼ばれます）、案件名を続ければその案件の話から始まります。58個の名前を覚えていなくても、6つか7つの入口さえ覚えていれば全部に手が届く、という状態を作るための層です。

自動起動を左右するdescriptionの書き方

スキルの起動には二つの入口があります。ひとつは自分でスラッシュコマンドとして名前を打つ方法、もうひとつはClaudeが会話の内容から判断して勝手に立ち上げる方法です。後者では、依頼したときの言葉そのものが呼び出しのきっかけ（トリガー）になります。

判断の材料になるのがdescriptionです。会話が始まった時点で読み込まれているのは、各スキルの名前とdescriptionだけなので、AIから見えているのは実質そこだけになります。中身にどれだけ丁寧な手順を書いても、descriptionが薄ければ選ばれません。

私の手元で自動起動がうまく立ち上がるスキルは、descriptionに「その依頼を、自分が普段どういう言葉で言うか」を並べてあります。商品ページを更新するスキルなら、何をするスキルなのかを一文で書いたうえで、「アイテム追加して」「使ってるものに〇〇を足して」「アイテムリスト更新」といった実際の言い回しを続けて置いてあります。逆に、説明を一行で済ませているスキルは、こちらから名前を出さないと動かないことが多いです。

ついでに、呼ばれてほしくない条件も書いておくと事故が減ります。私が使っている画像生成のスキルには「ラフや数出しはこれ、高品質な仕上げや動画は別の道具を使う」と書き添えてあります。descriptionは説明文ではなく、どういうときに呼ぶかの条件文だと思って書くと、狙ったときに立ち上がるようになります。

何十個入れてもコンテキストが埋まらない仕組み

スキルを増やしていくと必ず気になるのが、AIが一度に読んでおける文章量（コンテキスト）を食い潰さないのか、という点です。段階的開示、英語ではプログレッシブ・ディスクロージャーと呼ばれる仕組みで解決されています。

読み込まれる順番は三段階です。まず常時読まれているのは、各スキルの名前とdescriptionだけ。次に、そのスキルが呼ばれた時点でSKILL.mdの本文が読まれます。さらに、本文の中から参照している別のファイルは、そこまで進んで初めて開かれます。

私の請求書スキルが分かりやすい例になっています。SKILL.md自体は79行しかなく、取引先ごとの情報は別のファイル、書式のテンプレートはさらに別のHTMLファイルに置いてあります。請求書を作る場面にならなければ、取引先の一覧が読まれることはありません。動画の文字起こしを取ってくるスキルも同じで、字幕ファイルを整形する小さなプログラム（スクリプト）を別ファイルで持っていて、必要になったときだけ実行されます。

手順の本体はSKILL.mdに置き、量のあるデータや書式は別ファイルへ逃がしておきます。分け方さえ守っていれば、数が増えても普段の会話は軽いままです。実際、私は75個（個人58＋プロジェクト17）を抱えたまま普通に使えています。

スキルの作り方は4手順

手順そのものは、書き出してみると短いです。

1. 置き場所にフォルダを作る（個人なら ~/.claude/skills/スキル名/）
2. フォルダの中に SKILL.md を作り、フロントマターと手順を書く
3. Claude Codeを立ち上げ直して、名前で呼んでみる
4. 思ったように動かなかった箇所を書き足す

私はゼロから書くより、直前にやってもらった作業をそのまま見せて「いまの手順をSKILL.mdにまとめて」と頼むほうが多いです。実際に一度通した作業なので、抜けが少なく、自分では言語化できていなかった前提まで拾ってくれます。スキルを作るためのスキル（skill-creatorと呼ばれるもの）も配布されているので、書き方の型から入りたい場合はそちらを使う手もあります。

四番目が肝心で、初回から完成させようとしないほうが続きます。二回目に呼んだときに「保存先が違った」「確認の順番が抜けていた」と気づくので、そのつど一行ずつ足していきます。私のスキルはどれも、足し算の跡で今の長さになっています。

あとから読み返しても使えるSKILL.mdの型

書き足していくうちに、長く使えているスキルには共通の形があると気づきました。守っているのは4つです。

• ひとつのスキルに目的をひとつだけ：請求書を作るスキルに「ついでに入金の確認も」と足したくなりますが、混ぜると呼ぶ場面が曖昧になり、descriptionも書きづらくなります。別のスキルに分けたほうが両方とも呼ばれます
• 固有名で書く：「テンプレートを使う」ではなく、ファイル名・保存先のフォルダ名・確認する項目名まで書きます。曖昧に書いた箇所は毎回聞き返されるか、勝手に別の場所へ保存されます
• やらないことを先に書く：触ってはいけないファイル、消していい／悪いの線引き、確認を取ってから進む箇所。私は削除の扱いだけは必ず書いていて、消すのではなく別フォルダへ移すところで止めるようにしてあります
• 長くなったら外へ出す：500行が目安と言われていますが、実感としては目で追えなくなった時点で分けどきです。取引先の一覧や書式のような「データ」は別ファイルに移すと、手順だけが残って読みやすくなります

いちばん失敗したのは、2つ目を守らずに「いい感じにまとめて」と書いた箇所でした。呼ぶたびに結果が変わるので、結局そこだけ毎回口で説明することになり、スキルにした意味が半分消えていました。

よく呼んでいるClaude Codeのスキル8つ

おすすめの一覧を作ろうとすると、どうしても公式カタログの紹介になりがちなので、私が実際に呼んでいる頻度の順に並べます。案件が特定できるものは外してあります。

1. 記事を通しで作るスキル：キーワードの調査から構成、執筆、校正、入稿までを一続きで回します。私のスキルの中では一番出番が多いです
2. 画像生成：記事の図やラフを出すためのもの。どの道具を使うか、保存先はどこか、何枚出すかまで書いてあります
3. ブラウザ操作でページを確認する：公開したページを実際に開いて、崩れていないか、リンクが生きているかを見るところまでやらせます
4. 動画から文字起こしを取る：字幕があればそれを取り、無ければ手元で音声を文字にするところまで落ちてくれます
5. 請求書の作成：月末にまとめて呼びます。取引先の情報とテンプレートを別ファイルに持たせている例です
6. 商品ページの更新：紹介しているものが増えたときに、データを直してサーバーに反映し、実ページを見るところまで
7. 壁打ち：企画の初期に、賛成側と反対側を分けて意見を出させます。判断そのものは自分でやります
8. 作業の記録をまとめる：その日触ったファイルを作業単位でまとめて記録に残すもの

並べてみて自分でも思いますが、派手なものは一つもありません。全部、月に何度も繰り返す事務作業です。ちなみに一番上の記事制作スキルは、中でリサーチ担当・執筆担当・校正担当と役割を分けて動かしています。役割で分ける話はサブエージェントを役割で分けて仕事を渡す方法のほうに詳しく書いたので、複数体で動かしたい方はあわせて読んでみてください。

スキルにしないほうがいい作業

増やすほど良い、という話にはなりません。作らなくてよかったと思う条件が三つあります。

1つ目は、一回しかやらない作業です。書く手間のほうが大きくなります。2つ目は、毎回条件が変わる判断です。たとえば「この記事を出すべきか」のような判断は、そのときの状況で答えが変わるので、手順に固めた瞬間に嘘になります。3つ目は、口で説明したほうが早いものです。三行で伝わる依頼をスキルにすると、呼ぶ名前を思い出す手間のほうが増えがちです。

私が使っている目安は、二回やったら手順をメモ、三回目でスキルにするという順番です。二回目の時点ではまだ形が固まっていないことが多く、三回目でようやく「毎回ここでつまずく」が見えてきます。

58個に増えてから困ったこと

増やした結果どうなったかも、正直に書いておきます。

まず、名前を思い出せなくなりました。半年前に作ったものは、存在自体を忘れています。ルーターを足したのは、名前を探す手間を減らすためです。入口を部門ごとにまとめて、そこから振り分ける形にしてから、探す手間はだいぶ減りました。

次に、同じ名前が二箇所にできました。数えてみたら、スキル側とルーター側の両方に同じ名前が置かれているものが三つありました。内訳は個人スキルと重なっているものが二つ、プロジェクトスキルと重なっているものが一つです。どちらが呼ばれているのか自分でも分からない状態です。フォルダを分けて運用していると、片方を作ったことを忘れてもう片方を作ってしまいます。

3つ目は、呼んでほしくない場面でスキルが立ち上がることです。descriptionを広く書きすぎると、関係のない会話でも当たってしまいます。逆に狭くしすぎると呼ばれません。一度で決まらないので、外れたときにdescriptionを直す、を繰り返しています。

そして最後に、使わないスキルが残り続けます。呼ばなくなったものも、名前とdescriptionは読まれ続けます。数が増えるほど選択肢のノイズになるので、たまに一覧を出して、半年呼んでいないものを別のフォルダに移すようにしています。消すのではなく、いったん退避させるだけです。判断がつかないものを消して困った経験があるので、退避で止めておくくらいがちょうどいいと思っています。

カスタムコマンドはどうなったか

以前から .claude/commands/ にカスタムコマンドを溜めていた方は、作り直しが要るのかどうかが気になると思います。私の手元では、25枚のカスタムコマンドを今もそのまま使っています。書き直していません。

ただし役割は変えました。作業の中身を書いていたコマンドは順にスキルへ移し、コマンド側には振り分け表だけを残しています。「こう聞かれたらこのスキル」という一覧なので、中身が変わってもコマンド側はほとんど触らずに済みます。

使い分けの感覚としては、自分の指で打って呼びたいものはコマンド、会話の流れで勝手に立ち上がってほしいものはスキル、という分け方に落ち着きました。両方に同じ名前を置くと前述のとおり混乱するので、そこだけ気をつけてください。

スキル・サブエージェント・MCP・hooks・CLAUDE.mdの分担

スキルの記事を読んでいて一番分かりにくいのが、似た仕組みが複数あることだと思います。私の手元での分担は次のようになっています。

迷ったときの分け方はシンプルで、いつでも守ってほしいならCLAUDE.md、たまに呼ぶ作業ならスキルです。CLAUDE.mdに手順を全部書き足していくと、関係のない作業のときまで読まれるので、あっという間に長くなります。

MCPは、スキルとは層が違います。スキルは手順書なので、そもそも外のデータに触れなければ何も始まりません。検索データを取ってくる、ブラウザを動かす、といった接続はMCPが担当し、その道具を使う順番をスキルが書く、という関係です。既製のものを繋いでも足りないときは作ることもできて、私も一つだけ自作しました。コードを書けない状態でどう作ったかは必要になった道具をAIに作らせた記録に書いています。

hooksだけは性格が違います。スキルもCLAUDE.mdも、結局はお願いなので破られることがあります。実行の直前に割り込んで止める仕組みが要る場面もあって、私は本番のデータ基盤を触らせないためにそこを使っています。仕掛け方はClaude Codeのhooksで、破られては困るルールを止める話にまとめました。手順で済むのか、強制力が要るのかで選ぶといいと思います。

よくある質問

Q. 無料プランでもスキルは使える？ 追加で料金はかかる？
A. スキルそのものに追加の課金はありません。ファイルを置くだけの仕組みなので、費用が乗るとすればスキルを動かした分のやり取りのほうです。ただし、どのプランでClaude Codeがどこまで使えるかは変わることがあるので、契約前に公式の案内で確認してください。私の実感としては、スキルを増やすとまとめて長い作業を任せる回数が増えるため、結果的に消費は増えます。

Q. プログラミングができなくてもスキルは作れる？
A. 作れます。SKILL.mdはただのテキストファイルで、書くのは手順の説明です。私も自分でコードは書けません。むしろ難しいのは書式より、自分がいつもやっている手順を言葉にすることのほうです。うまく書けないときは、一度作業をやってもらった直後に「いまの手順をまとめて」と頼むと形になります。

Q. 作ったスキルが自動で起動しない。どこを見ればいい？
A. 順に三つ見てください。置き場所が合っているか（フォルダ名とファイル名は スキル名/SKILL.md）、フロントマターのnameがフォルダ名と揃っているか、そしてdescriptionに「自分が実際に言いそうな言葉」が入っているか。私の場合、外れる原因はほぼ3つ目でした。それでも動かないときは、いったん名前を直接打って呼び、動くこと自体は確かめておくと切り分けが早いです。

Q. 作ったスキルはチームに共有できる？
A. できます。プロジェクトの側（作業フォルダの .claude/skills/）に置いて、ファイルの変更履歴を共有する仕組み（バージョン管理と呼ばれ、Gitが代表的です）に載せておけば、同じフォルダで作業する人に同じ手順が渡ります。個人の側に置いたものは自分の手元だけなので、配りたいものはプロジェクト側に、自分の癖に合わせたものは個人側に、と分けるのが分かりやすいでしょう。共有する場合は、社外に出せない情報がSKILL.mdや添付ファイルに紛れ込んでいないかだけ、先に見ておいてください。

まとめ

Claude Codeのスキルは、繰り返す手順に名前を付けて、呼んだときだけ読ませる仕組みです。書くのはSKILL.mdというテキストファイル一枚で、決まっているのはフロントマターのnameとdescriptionくらい。あとは自分の段取りをそのまま日本語で書けば動きます。

数を抱えるつもりなら、置き場所を分けておくと後が楽です。どこでも使うものは個人側、その仕事だけのものはプロジェクト側、そして入口をまとめるルーターを部門ごとに一枚。私は58個まで増えたところで名前を思い出せなくなり、慌ててルーターを足しました。先に作っておけばよかったと思っています。

それから、数を増やすこと自体が効率化ではありません。一回きりの作業、毎回条件が変わる判断、口で言ったほうが早いもの。三つに当てはまるものは作らないでおくと、一覧が読みやすいまま保てます。私の目安は、二回やったらメモ、三回目でスキルにする、くらいの粗さです。増やすほど便利になるわけでもないので、当面はこのくらいで様子を見るつもりです。