Claude Code を使い始めて1ヶ月、徐々に「毎回同じ説明をしている」ことに気付きました。
「ブログ書いて。Hugo + PaperMod 構成で、Cloudflare Pages にデプロイ。記事は
content/posts/に置いて、frontmatter には title と displayTitle を分けて…」
毎回これを書くのは無駄です。Claude Code には スキルという仕組みがあって、こういう「プロジェクトの運用ルール」を Claude に永続的に覚えさせられます。
今回はそのスキルの作り方と、実際に運用しているスキルの実例を紹介します。
スキルとは
Claude Code のスキルは、「特定のリクエストパターンに対して、Claude がどう振る舞うべきか」を記述したファイル群です。
~/.claude/skills/<skill-name>/SKILL.md
ここに置いた Markdown ファイルが、Claude Code 起動時に「使えるスキル一覧」として読み込まれます。ユーザーが特定のキーワードで話しかけると、Claude が自動でそのスキルを呼び出して、指示通りの作業を始めます。
スラッシュコマンドとの違い
似ているのが /foo のようなスラッシュコマンドですが、役割が違います。
| 比較 | スラッシュコマンド | スキル |
|---|---|---|
| 起動方法 | 明示的に /cmd と打つ | キーワードから自動判定 |
| 使う場面 | 単発のクイック作業 | 文脈つきの一連の作業 |
| 保存先 | プロジェクト or グローバル | 主にグローバル |
| サイズ感 | 数行〜数十行 | 数百行〜長め |
スラッシュコマンドが「電卓の M+ ボタン」だとすれば、スキルは「この案件専用の手順書」です。
スキルの最小構成
~/.claude/skills/my-blog/SKILL.md という1ファイルだけで動きます。
---
name: my-blog
description: 個人ブログ「foo.com」の記事作成・運用を支援するスキル。「ブログ書いて」「foo.com を更新して」のようなリクエストで起動する。
---
# 個人ブログ運用スキル
「foo.com」ブログの制作・運用を支援する。
## プロジェクト基本情報
- ローカルパス: `C:\Users\sakae\Desktop\blog\foo`
- スタック: Hugo + PaperMod + Cloudflare Pages
- 公開コマンド: `git push`（Cloudflare Pages 自動デプロイ）
## 文体ルール
- カジュアル口調（です・ます混在OK）
- 絵文字は控えめに
## 投稿手順
1. `content/posts/<slug>.md` を作成
2. frontmatter に title / displayTitle / date / category を書く
3. `git push` でデプロイ
ポイントは frontmatter の description。ここがトリガーワード設計の中核で、Claude は description を見て「このリクエストはこのスキルに該当するか」を判定します。
トリガーワードの設計
スキルが反応するかどうかは、description によくあるリクエスト例を入れているかで決まります。私のブログ運用スキルではこう書いています。
description: やきいもテックブログ (https://yakiimo-tech.com) の記事作成・デザイン調整・デプロイを支援するスキル。Hugo + PaperMod + Cloudflare Pages 構成で、「やきいもテックに記事を書いて」「ブログを更新」「yakiimo-tech のデザインを変えて」「ブログを deploy」のようなリクエストで起動する。
「〜のようなリクエストで起動する」 の後ろに、想定される言い回しを2〜4個並べておくのがコツです。Claude が「ユーザーの言葉」と「スキルが対応するパターン」を結びつけやすくなります。
逆に description が漠然としていると、関係ないリクエストでもスキルが立ち上がってしまったり、逆に必要な時にスキップされたりします。
本文に書く内容
SKILL.md の本文部分には、Claude に守ってほしいルールや手順を書きます。私が運用しているスキルでは、以下のセクションをよく入れます。
- プロジェクト基本情報: ローカルパス・GitHub・スタック・デプロイ方法
- 運用者情報: 筆名・文体ルール・してほしくない表現
- 作業フロー: 「記事公開時の手順」「デプロイ確認方法」など
- 既存資産の扱い: 「既存記事と被ってないか必ず grep で確認」のようなルール
- ハマりどころ: 過去に踏んだ落とし穴を Claude にも伝えておく
ハマりどころの記載は特に効きます。私は「記事の date は JST 午前6時より前に固定」というルールを書いてあって、これを入れてからビルド除外事故が止まりました（buildFuture の罠を参照）。
実プロジェクトでの利用例
例1: ブログ運用スキル
「やきいもテックに記事を書いて」と頼むだけで、ブログのリポジトリに移動 → 既存記事と被り検出 → frontmatter 自動生成 → ドラフト保存 → 公開承認待ち → デプロイ確認まで一連の流れが走ります。
例2: SNS連携スキル
「この記事をショート動画にして TikTok に投稿して」のようなリクエストで、記事URL → ナレーション台本生成 → TTS で音声化 → 動画合成 → TikTok 下書き投稿、までの長いパイプラインがスキル1つで動きます。
例3: 自動メッセージ生成スキル
特定のSNSで定型メッセージを送りたい時に、相手プロフィールを取得 → 直近の投稿を読む → パーソナライズしたメッセージを生成、というスキルを作っておくと、毎回ゼロから書くより圧倒的に楽です。
作る時のコツ
1. まず「説明文を毎回書く面倒さ」を感じてから作る
最初から完璧なスキルを作ろうとしないこと。3回同じ説明をしたらスキルにする、くらいの感覚がちょうどいいです。
2. description は「Claude にも読ませる」
description は人間向けではなく Claude 向け。「○○のようなリクエストで起動する」 の例を増やすほど起動精度が上がります。
3. ハマりどころを必ず書く
過去に詰まった対処法は、Claude にも伝える。次回別の Claude セッションでも同じ罠を踏まなくなります。
4. ファイル更新後は Claude Code を再起動
スキルファイルの変更は、Claude Code セッションの起動時に読み込まれます。書き換えたら一度終了して立ち上げ直す。これは CLAUDE.md と同じ挙動です。
まとめ
- スキル = 「特定リクエストパターンに対する Claude の振る舞い」を記述した手順書
~/.claude/skills/<name>/SKILL.mdに置くだけで動くdescriptionフィールドのトリガーワード設計が肝- 本文には基本情報・文体ルール・作業フロー・ハマりどころを書く
- 「3回同じ説明をしたら」スキル化のサイン
Claude Code を「自分のプロジェクトの新人スタッフ」として育てていく感覚です。スキルが充実するほど、毎回の説明コストが下がって、本来やりたい作業に集中できる時間が増えます。
次回は、スキル同士を連携させて「1つのリクエストで複数のスキルがリレー式に動く」サブエージェントの話を書く予定です。