Claude Codeに毎回同じ指示を打っていませんか。「この文体で」「このチェックをしてから」「終わったらここに記録して」。同じ説明を繰り返しているなら、その手順はカスタムスキル（SKILL.md）に移せます。
この記事は、Claude Codeでスキルを自作したい人向けの作成ガイドです。最小構成の作り方をまず示し、後半では私がSNS運用の自動化で実際に運用している12個のスキル構成を例に、設計の勘所を説明します。単発の便利ワザではなく、「壊れにくいスキル群をどう設計するか」まで踏み込みます。
Claude Codeのスキルとは
スキルは、Claude Codeに特定の作業手順を教えるためのMarkdownファイルです。プロジェクトの .claude/skills/<スキル名>/SKILL.md に置くと、Claude Codeがそのスキルを認識します（公式ドキュメント）。
ポイントは読み込まれ方です。スキルの名前と説明（frontmatterの name と description）だけが常に参照され、本文の手順は関連する依頼が来たときに読み込まれます。Anthropicはこの設計を、コンテキストを浪費せずにエージェントへ専門知識を渡す仕組みとして説明しています（Anthropicのエンジニアリングブログ）。
つまり、スキルを何十個置いてもコンテキストはほとんど消費しません。ここが「長いCLAUDE.mdに全部書く」やり方との一番の違いです。
ディレクトリ構成はこうなります。
.claude/
└── skills/
└── release-note/
├── SKILL.md # 手順の本体（必須）
└── references/ # 長い参考資料は別ファイルへ（任意）
└── template.md
最小のスキルを作る
前提はClaude Codeが動くプロジェクトがあることだけです。追加のインストールは不要です。
まずディレクトリを作ります。
mkdir -p .claude/skills/release-note
次に SKILL.md を書きます。frontmatterの name と description、それに手順があれば動きます。
---
name: release-note
description: リリースノートの下書きを作る。ユーザーが「リリースノート」「変更履歴のまとめ」を依頼したときに使う。
---
# リリースノート下書き
## 境界
- 参照してよいのは git log とマージ済みPRのタイトルだけ。
- 下書きの作成まで。タグ付けや公開はしない。
## 手順
1. 前回タグから現在までのコミットとPRタイトルを集める。
2. 変更を「新機能」「改善」「修正」に分類する。
3. 利用者向けの言葉に書き直す。内部リファクタは1行にまとめる。
4. `docs/releases/` に日付付きのMarkdownとして下書きを保存する。
保存したら、Claude Codeに「リリースノートの下書きを作って」と依頼してみてください。説明文に合致する依頼だとスキルが読み込まれ、手順どおりに動きます。期待どおりに動かないときは description を依頼の言葉に近づけるのが先決です。本文より先に、説明文がスキル選択の決め手になるためです。
やめたいときはディレクトリを消すだけで元に戻ります。コードもプロセスも汚さないので、気軽に試して捨てられます。
実例：SNS運用を12個のスキルに分割した構成
ここからは実例です。私はSNSとブログの運用（調査、執筆、公開前審査、予約投稿、計測、振り返り）をClaude Codeのスキル群で自動化していて、現在は12個のスキルで回しています。
分割はこうなっています。
| 役割 | スキル | やること |
|---|---|---|
| 調査 | research | 許可済みの情報源だけを見て、題材候補をデータベースへ保存 |
| 執筆 | write-threads / write-blog など媒体別に5個 | 下書きを作り、審査待ちとして登録 |
| 修正 | critic-fix | 審査で落ちた原稿を、指摘箇所だけ最小修正 |
| 実行 | post-due | 予約時刻が来た承認済み投稿を投下するだけ |
| 計測 | daily-metrics | 前日の指標をデータベースへ記録 |
| 振り返り | weekly-pdca / improvement / seo-audit | 週次・月次で仮説を更新 |
最初から12個あったわけではありません。承認前の原稿が審査で正しく止まった実例を踏まえ、執筆・審査・公開の境界が曖昧にならないよう役割を分けて、現在の構成にしています。
運用して効いた設計の勘所5つ
1. 1スキル1責務にする
「書くスキルは公開しない。公開するスキルは考えない」。この分離が一番効きました。上の表でいうと、執筆系スキルには投稿ツールを呼ばせず、公開は実行スキル（post-due）だけに許しています。実行スキル側は逆に、原稿の中身を考え直すことを禁止しています。役割が混ざると、不調時にどこを直せばいいか分からなくなります。
2. 冒頭に「境界」を書く
各スキルの先頭に、手順より先に「境界」の節を置いています。見てよい情報源、呼んでよいツール、してはいけないことを最初に列挙する形です。手順は状況で変わりますが、境界は変わりません。エージェントが予想外の動きをしたときに疑う場所も、まず境界の書き漏れです。
3. 検査を書き手から分離する
公開前の審査は、執筆スキル自身にやらせず、独立したサブエージェントに固定のチェックリストで判定させています。書いた本人のセルフチェックは甘くなるからです。審査がPASSしたものだけが次の工程に進み、執筆スキルは審査結果を書き換えられません。
4. 失敗時の動きを先に決める
自動修正は2回まで、それでも通らない原稿は隔離して人間向けに報告し、パイプライン自体は止めずに次へ進む。このルールをスキルに明記しています。失敗時の挙動を決めていなかった頃は、1つの失敗原稿への修正が延々と繰り返される事態が起きました。リトライ上限と「諦めて続行」の定義は、自動運用では本体の手順と同じくらい重要です。
5. スキルにバージョンを付ける
frontmatterに metadata.version を持たせ、変更のたびにCHANGELOGへ適用日と根拠を1行残しています。スキルはただのMarkdownなので、つい直接書き換えたくなりますが、「いつ何を変えたか」が残っていないと、成果指標が動いたときに原因を特定できません。プロンプトもコードと同じように変更管理する、が結論です。
スキルとCLAUDE.md、サブエージェントの使い分け
作り込むほど迷うのが「どこに何を書くか」です。私は次の基準で分けています。
- 常に守るルールはCLAUDE.md（またはAGENTS.md）へ。禁止事項、データの境界、ブランチ規約など。量を絞るほど守られやすくなります。AGENTS.mdの形式はagents.mdに公開されています。
- 特定の作業手順はスキルへ。読み込みが必要時だけなので、詳細に書いてもコンテキストを圧迫しません。
- 独立した判定はサブエージェントへ。審査のように「書き手と利害が対立する役割」は、別のコンテキストに分けると判定が安定します。
CLAUDE.mdが長くなってきたら、手順をスキルへ切り出すサインだと考えています。
まとめ
Claude Codeのスキルは、SKILL.md を1枚置くだけで始められます。まずは繰り返し打っている指示を1つ選んで、最小構成で切り出してみてください。
そのうえで、複数のスキルを連携させて運用に載せるなら、順番としては責務の分割、境界の明文化、検査の分離、失敗時の挙動、バージョン管理。SNS運用の自動化を回してみて、結局効いたのはこの5つでした。手順を増やすより、構造を先に決める。スキル設計はエージェント設計そのものです。
