はじめに
Claude Codeを使っていると、次のような場面によく出くわします。
- 「毎回同じような指示を長々とコピペしている」
- 「MCPとSkillsって結局何が違うの?」
- 「CLAUDE.mdに全部書けばいいのでは?」
Anthropicが提供するSkillsは、こうした「よくある依頼パターンに対する再利用可能なノウハウ」を、必要な時だけ読み込まれる形でClaudeに持たせる仕組みです。
本記事では、Skillsの仕組みをMCP・CLAUDE.md(Rules)・サブエージェントと比較しながら整理し、実際に既存Skillを探して使う方法、そしてskill-creatorを使って自作Skillをゼロから作り、eval(評価)で効果を定量的に検証するところまで、手を動かした結果を交えて紹介します。
Skillsとは何か
Skillは一言でいうと、「特定の状況になったときだけ動的に読み込まれる、手順書」(Markdownファイル)です。SKILL.mdというファイルに、
- どんな時にこのSkillを使うべきか(
description) - 実際に何をどう進めるか(手順)
- 出力フォーマット
を書いておくと、Claudeがユーザーの依頼内容を見て「今回はこのSkillを使うべきだ」と判断し、必要になった時だけ手順を読み込んで実行してくれます。
似たような概念と並べると違いがわかりやすくなります。
| 仕組み | 役割 | 読み込まれるタイミング |
|---|---|---|
| CLAUDE.md(Rules) | プロジェクト全体の前提・ルール | 常に(セッション開始時から常時コンテキストに乗る) |
| MCP | 外部ツール・データソースへの接続(DB、API、SaaSなど) | ツールとして常時利用可能、実行するとその結果を取り込む |
| サブエージェント | 独立したコンテキストで動く「作業者」。親と切り離して並列実行できる | 明示的に呼び出した時 |
| Skills | 特定タスクの「やり方」の手順書。プロンプトの延長線上にある | 該当しそうな依頼が来た時だけ、必要な分だけ |
CLAUDE.mdは常に全部読み込まれるので、書きすぎるとコンテキストを圧迫します。一方Skillsは「使いそうな時だけ読み込む(progressive disclosure)」設計になっているため、大量の手順やノウハウを持たせても普段のやり取りを圧迫しません。「同じような依頼への対応方法」を外部ファイルとして切り出し、必要な時だけ動的に読み込ませる、というのがSkillsの核心です。
外部システムとの連携が主目的ならMCP、独立した並列タスクの実行が主目的ならサブエージェント、繰り返し依頼される定型タスクの「やり方」を持たせたいならSkills、という住み分けで考えると設計しやすくなります。
既存Skillsの探し方: find-skills
Skillを自作する前に、まずは既に公開されているSkillを探すのが効率的です。find-skillsは、GitHub上で公開されているSkillリポジトリを検索してインストールできるSkillです。
skills.sh add find-skills
このようなコマンドでインストールすると、skills-lock.jsonにインストール履歴が記録されます。
{
"version": 1,
"skills": {
"find-skills": {
"source": "bytedance/deer-flow",
"sourceType": "github",
"skillPath": "skills/public/find-skills/SKILL.md"
}
}
}
実際にfind-skillsへ「UIを最適化するようなSkillを探して」というあいまいな依頼を投げてみたところ、Claudeが「デザイン改善系」「パフォーマンス系」「アクセシビリティ系」の3方向に候補を自動で整理し、それぞれのSkillのセキュリティリスク評価(Safe / Low Riskなど)まで添えて提示してくれました。最終的にdesign・design-system・accessibilityという3つのSkillをインストールする、という流れになりました。
あいまいな要望から候補を絞り込み、安全性の目安まで示してくれるので、「そもそもどんなSkillが世の中にあるのか分からない」という状態からでも探索しやすいのが利点です。
skill-creatorで自作Skillを作る
既存のSkillで要件を満たせない場合は、Anthropic公式のskill-creatorを使って自作します。題材として、「長文のテキスト(記事やメモ)を渡すと、バズりやすいX(Twitter)投稿文を作ってくれるSkill」(tweet-from-text)を作成しました。
skill-creatorは以下のような定型プロセスを自動で回してくれます。
- 意図のヒアリング(どんな時に使うSkillか)
-
SKILL.mdのドラフト作成 - eval(評価用タスク)を複数生成 — 今回は「転職・独立の体験談」「生産性に関する気づき」「失敗から学んだ教訓」という3種類のテストケースを用意
- Skillあり/なしでそれぞれ複数回実行し、定量ベンチマーク + 人間が見るHTMLレポートで定性チェック
- フィードバックを反映してSkillを改善
- 再ベンチマークで効果を確認
「作って終わり」ではなく、効果を数値で検証しながら育てていくワークフローになっている点が特徴的です。
ベンチマーク1回目: Skillなし vs あり
evalの判定基準(assertions)は、たとえば以下のようなものです。
- 【案1】【案2】【案3】のように3案が独立して提示されているか
- 各案に文字数が明記され、実際の文字数と一致しているか(自己申告と実測がズレていないか)
- 140文字以内に収まっているか
- 3案がそれぞれ違う切り口(フック)になっているか
- 元の文章の具体的な数字が残っているか
- 単なる要約ではなく、読み手の反応を誘う一文になっているか
このevalで最初にとったベンチマーク結果がこちらです。
| Metric | Skillなし | Skillあり |
|---|---|---|
| Pass Rate | 41% ± 14% | 100% ± 0% |
| Time | 43.5s ± 2.4s | 91.3s ± 20.4s |
Skillなしでも「なんとなくのTweet案」は出てきますが、文字数チェックが甘かったり、3案が似たような構成になったりして、合格率は4割程度にとどまりました。Skillを与えることで安定して合格するようになっています。時間は伸びますが、これは手順(文字数の実測、3案の切り口分けなど)を律儀にこなすようになった分の増加です。
フィードバックしてSkillを改善する(2回目のベンチマーク)
1回目のSkillには「一文ごとに機械的に改行する」「〜だ。〜だった。と言い切りで畳みかける」というルールがありました。これを実際の出力で見ると、狙いとは裏腹に広告コピーのような硬い印象になってしまうことがわかりました。
そこで、以下の改善を加えました。
- 改行は「読点では収まらない、話の切れ目」にだけ入れる(1文ごとの機械的な改行をやめる)
- 「〜な気がする」「〜んですよね」のような、ひと呼吸置いた柔らかい語尾も混ぜる
- Skillが呼ばれすぎないよう
disable-model-invocation: trueを追加(明示的に呼んだ時だけ動くように)
改善後に2回目のベンチマークを取った結果がこちらです。
| Metric | 旧Skill | 改善後Skill |
|---|---|---|
| Pass Rate | 76% ± 8% | 100% ± 0% |
「柔らかい文章にして」「改行と言い切り文を少なくして」という短いフィードバック一つで、Skillの中身(判断基準・文章のトーン)が具体的な手順として書き換わり、合格率が数値として改善する様子を確認できました。
実際の出力例
完成したSkillに、「7年勤めた会社を辞めて独立した」という体験談のテキストを渡した時の出力はこちらです。
【案1】(128文字)
貯金300万円、独立後3ヶ月は収入ゼロ。それでも7年勤めた会社を辞めた。
両親には「安定を捨てるなんて馬鹿げている」、上司には「お前には無理だ」と言われたけど、2年経った今、月の売上は会社員時代の年収を超えた。何より、毎朝起きるのが楽しみになった。
#独立
【案2】(125文字)
「このまま定年まで働く自分」を想像したことある?
私はしてみたら、ちっとも嬉しくなかった。だから7年勤めた会社を辞めて独立した。
貯金300万円、最初の3ヶ月は収入ゼロ。両親にも上司にも反対されたけど、2年経った今は毎朝起きるのが楽しみになっている。
【案3】(133文字)
「安定を捨てるなんて馬鹿げている」と両親に、「お前には無理だ」と上司に言われた。
7年勤めた会社を辞めて独立し、貯金300万円、最初の3ヶ月は収入ゼロだった。
それでも2年経った今わかった。「安定」は思っていたよりずっと脆くて、「自分で選んだ道」の方がずっと強い。😌
一番拡散を狙えそうなのは案2。「想像したことある?」という問いかけが
自分ごと化を誘い、リプやRTで自分の状況を語りたくなる余地を残しているのが強い。
3案とも同じ元テキストから作られていますが、切り口(数字押し/問いかけ/逆説)が明確に分かれていて、単なる要約とは違う「拡散を狙ったコピー」になっていることがわかります。
つまずいたところ: ネットワーク環境の落とし穴
公式のskill-creatorをインストールしようとした際、git cloneやgh CLI経由のGitHubアクセスがTLSハンドシェイクで失敗する、というトラブルに遭遇しました。原因はツールの権限やコマンドの誤りではなく、接続していたVPNでした。VPNを切断したところ問題なく解決しました。
「権限を許可しているのにコマンドが失敗する」場合、ローカルのネットワーク環境(VPN・プロキシ・社内ファイアウォールなど)が原因になっていることがある、という地味だけど実務的に役立つポイントでした。
どんな業務をSkill化すべきか
実際に触ってみて感じた「Skill化に向いている業務」の条件はこんな感じです。
- 同じような依頼を繰り返している(毎回似たプロンプトを打っている)
- アウトプットに一定の型・品質基準がある(文字数、フォーマット、トーンなど、evalの合否基準として書き出せる)
- 判断のコツが暗黙知になっている(「バズる文章の作り方」のように、言語化しないとブレる勘所がある)
- 常時使うわけではない(常時使うルールならCLAUDE.mdの方が適している)
逆に、外部システムとの連携が主目的ならMCP、独立した並列タスクの実行が主目的ならサブエージェント、というように使い分けると全体の設計がすっきりします。
まとめ
- Skillsは「必要な時だけ読み込まれる手順書」で、CLAUDE.md(常時)・MCP(外部接続)・サブエージェント(並列実行)とは役割が異なる
-
find-skillsで既存のSkillsを探してから、なければskill-creatorで自作する、という流れが効率的 -
skill-creatorはSkillのドラフト作成だけでなく、eval設計・ベンチマーク・改善サイクルまで面倒を見てくれる - 「Skillあり/なし」を定量的に比較できると、フィードバックの効果が数字(合格率41%→100%など)で見えるので、勘に頼らずSkillを磨き込める
普段Claudeに同じ指示を繰り返している業務がある方は、一度Skill化を試してみる価値は大いにあると感じました。