
Claude Code skillsとは?SKILL.mdの作り方と使い分け

※本記事にはプロモーション(アフィリエイト広告)を含みます。
Claude Codeの「skills(スキル)」が気になって、こんなことで迷っていませんか?
- skillsとは何か、CLAUDE.mdやスラッシュコマンドと何が違うのか分からない
- SKILL.mdをどこに置いて、何を書けば動くのか知りたい
- 作り方の記事は読んだが、実際の運用でどう使われているのかが見えない
- スキルを作れば作業の質が上がるのか、正直なところを知りたい
先に結論を書きます。Claude Codeのskillsとは、作業の手順をSKILL.mdというファイルに書いて置いておき、必要な時だけClaudeに読ませる「手順書」の仕組みです。
当ブログの運営者は、Claude Codeで3つのサイトの記事を毎日自動投稿しています。その運営で大事にしているのは、失敗が見つかったら手順とルールを文書に足し、毎回同じ手順を踏ませることです。
この記事で分かること
- Claude Code skillsとCLAUDE.md・サブエージェント・hooksの違い
- SKILL.mdの置き場所とfrontmatter(設定欄)の書き方
- 定期実行(ルーチン)で使うときの注意点
- 毎日の自動投稿の失敗から分かった、手順を文書にする価値
結論|Claude Code skillsとは「必要な時だけ読み込まれる手順書」
Claude Codeのskills(スキル)は、作業の手順をSKILL.mdに書いてフォルダごと置いておく仕組みです。依頼に合うスキルがあれば、Claudeはその手順書を読んでから作業します。
一言でいうと「呼ばれた時に開くマニュアル」
公式ドキュメント(Claude をスキルで拡張する)は、同じ指示やチェックリストを何度も貼っているならスキルにするよう勧めています。「/スキル名」で自分で呼ぶことも、Claudeが依頼から選んで使うこともあります。
2026年10月時点では、以前のカスタムスラッシュコマンドもスキルに統合されています。/code-reviewや/debugなど、最初から入っているスキルもあります。
状況別の答え|あなたはスキルを作るべきか
同じ説明を週に何度も書いている人は、スキルを作る価値があります。月に数回だけ毎回違うことを頼む人は、その都度の依頼文で十分です。
当ブログのように定期実行で同じ作業を毎日回す人には、手順書はほぼ必須だと考えています。人が見ていない時間に動くので、毎回同じ手順を踏むことを文書で担保するしかないからです。
Claude Code skillsとCLAUDE.md・サブエージェント・hooksの違い
Claude Codeには、指示や処理を仕込む場所がいくつもあります。よく比べられる4つを、公式ドキュメント(2026年10月時点)をもとに並べました。
| 仕組み | 動く時 | 向いている内容 |
|---|---|---|
| CLAUDE.md | 起動のたびに毎回 | どの作業でも守るルール |
| スキル | 説明文は常に 本文は使う時だけ | 作業ごとの手順 |
| サブエージェント | 作業を任された時 | 別の会話で済ませる作業 |
| hooks | 決まった時点で必ず | 毎回確実に走らせる処理 |
この表から分かるのは、4つが「いつ読まれるか・誰が動かすか」で分かれていることです。毎回か、必要な時だけか、確実に実行したいかで振り分けると迷いません。
CLAUDE.mdは毎回読む、スキルは使う時だけ読む
CLAUDE.mdは、起動のたびに必ず読まれるメモです。公式は、CLAUDE.mdの一部が「事実」ではなく「手順」に育ってきたら、スキルに分けるよう勧めています。
サブエージェントは「別の担当者」、スキルは「手順書」
Claude Codeのサブエージェントは、自分専用の会話の枠で作業し、要約だけを返す別の担当者です。公式では .claude/agents/ などにMarkdownで定義し、nameとdescriptionが必須とされています。
当ブログでは、書いた記事を別の確認役(サブエージェント)に照合させてから公開しています。書いた本人に見直させるより、手順書と記事を突き合わせる係を分けたほうが見落としを拾いやすいと判断しているためです。
hooksは「Claudeの判断を通さず必ず動く」
Claude Codeのhooksは、ファイル編集の後など決まった時点で自動実行されるシェルコマンドで、settings.jsonに書きます。公式は、LLMの判断に頼らない「決定論的な制御」と説明しています。
スキルはClaudeが読んで従う文章なので、守られない可能性はゼロではありません。絶対に毎回動かしたい処理はhooks、判断を伴う手順はスキルと分けるのが基本です。
Claude Code skillsの仕組み|説明文だけが先に読まれる
スキルがどう選ばれるかを知っておくと、SKILL.mdの書き方で迷わなくなります。流れは次の4段階です。
スキルが使われるまでの流れ
- STEP 1一覧を読む名前と説明文だけ
- STEP 2依頼と照合合うスキルを選ぶ
- STEP 3本文を読むSKILL.mdの中身
- STEP 4作業する必要なら補助資料も
説明文(description)で呼ばれるかどうかが決まる
Claudeは、スキルの名前と説明文の一覧を依頼と照らし合わせて、使うスキルを決めます。つまり自動で呼ばれるかどうかは、ほぼ説明文の書き方で決まります。
2026年10月時点の公式ドキュメントでは、descriptionとwhen_to_useは合わせて1,536文字で切り詰められます。大事な使い道ほど、説明文の先頭に書くのがコツです。
本文は使う時に読まれ、置きすぎると説明文が削られる
本文は使われた時に初めて読まれるため、公式はSKILL.mdを500行以内に収め、細かい資料は別ファイルに分けるよう勧めています。スキル一覧に使える量はコンテキストの1%が目安で、超えるとあまり使われないスキルから説明文が削られます。
Claude Code skillsの保存場所|個人用とプロジェクト用の違い
スキルは置く場所によって、読み込まれるセッションが変わります。個人で使うなら、まずは個人用とプロジェクト用の2か所を覚えれば十分です。
| 種類 | 置く場所 | 使える範囲 |
|---|---|---|
| 個人スキル | ~/.claude/skills/ スキル名/SKILL.md | そのPCの全プロジェクト クラウド実行は対象外 |
| プロジェクトスキル | .claude/skills/ スキル名/SKILL.md | そのリポジトリの中 コミットで共有できる |
| プラグインのスキル | プラグイン内のskills/ | プラグインを入れた環境 |
| 組織のスキル | 管理者が配る設定の場所 | 組織のメンバー全員 |
この表で見落としやすいのは、個人スキルがクラウドで動くセッションには届かない点です。同じ名前なら組織、個人、プロジェクトの順に優先されます。
自分専用なら個人、サイト専用ならプロジェクト
返信の言語など自分の癖に関わるものは ~/.claude/skills/ の個人スキルが向いています。特定のサイト専用の手順は、プロジェクトの .claude/skills/ に置いてGitで管理すると、チームやクラウドにもそのまま届きます。
ルーチン(定期実行)で使うなら置き場所に注意
公式ドキュメント(2026年10月時点)によると、クラウドで動くルーチンは ~/.claude/skills/ を読み込みません。使うには、リポジトリの .claude/skills/ にコミットするか、claude.aiのアカウントでスキルを有効にして同期します。
一方、デスクトップアプリの定期タスクは手元で動くため、個人スキルも読まれます。当ブログも定期実行で毎日動かしているので、定期実行がどこで動くかを先に確かめてから置き場所を決めるのが安全だと考えています。
Claude Code skillsの作り方|4つの手順
スキルは、フォルダを1つ作ってSKILL.mdを置くだけで作れます。ここでは公開前チェックをスキルにする「例」で説明します(当ブログの実物ではありません)。
手順1:スキル用のフォルダを作る
個人スキルなら、公式の手順と同じく ~/.claude/skills/ の中にスキル名のフォルダを作ります。フォルダ名がそのままコマンド名になり、この例なら「/blog-check」で呼べます。
mkdir -p ~/.claude/skills/blog-check
手順2:SKILL.mdに設定欄と本文を書く
フォルダの中にSKILL.mdを作り、1行目から「—」で囲んだ設定欄(frontmatter)を書きます。その下に、してほしい手順を普通の文章で書きます。
---
name: blog-check
description: ブログ記事の公開前チェック。記事のHTMLを渡されたときや「公開前に確認して」と頼まれたときに使う。
---
# 公開前チェック(例)
1. 見出しの直後に段落があるか確かめる
2. 料金や仕様に、確認した年月が書いてあるか確かめる
3. 問題があれば、直す前に一覧で報告する
公式によると、設定欄が読まれるのは「—」がファイルの1行目にある時だけです。
手順3:説明文に「いつ使うか」を書く
説明文には、何をするかに加えて、どんな言葉で頼まれたら使うのかを書きます。公式も、自然に言う言葉が説明文に入っているかを最初に確かめるよう勧めています。
手順4:呼び出して動きを確かめる
「/blog-check」で呼ぶのに加え、「公開前に確認して」と頼んで自動で選ばれるかも試します。編集は再起動なしで反映されます。
SKILL.mdの書き方|frontmatterの主な項目
SKILL.mdの冒頭の「—」で囲んだ部分がfrontmatterです。2026年10月時点の公式ドキュメントでは、すべての項目が任意で、descriptionだけが推奨とされています。
| 項目 | 意味 |
|---|---|
| name | 「/」で呼ぶ名前 省くとフォルダ名 |
| description | 何をするか・いつ使うか |
| when_to_use | 呼ぶきっかけの言葉の例 |
| allowed-tools | 確認なしで使える道具 |
| user-invocable | falseで「/」一覧から隠す |
| context / agent | forkで別の担当に任せる |
最初はnameとdescriptionの2つで十分
本番公開のように手動でしか動かしたくない作業だけ、自動で呼ばれなくする disable-model-invocation: true を足します。ただし公式によると、この設定を付けたスキルは定期タスクから呼ばれても実行されません。
そのため、無人で動かすスキルには disable-model-invocation を付けないよう注意が必要です。
項目名を書き間違えてもエラーは出ない
公式には、知らない項目名はエラーを出さずに無視されると書かれています。たとえば user-invocable を user_invocable と書くと、設定は効かないのに何も警告されないので、公式の表記と見比べるのが近道です。
毎日の自動投稿で分かった「手順を文書にする」価値
ここからは、3サイトに毎日自動投稿している運営者としての判断です。スキルの中身の公開ではなく、手順を文書にして守らせてきた経験から書きます。
手順書に入れておきたい3つのこと
- POINT 1作業の順番毎回同じ順で進める
- POINT 2過去の失敗の対策同じミスを繰り返さない
- POINT 3最後の確認別の確認役に照合させる
失敗を直したら、手順書に書き足して二度と起こさない
当ブログでは、内部リンクのブログカードをURLだけの段落で書いたせいで、カードが崩れていたことがあります。埋め込みブロック(wp:embed)で書き直して直し、今はその書き方をルールの文書に明記しています。
AIが描いた図も、PCでは綺麗なのにスマホでは文字が小さすぎて読めませんでした。2026年10月7日に気づき、スマホで縦に並ぶ形への作り直しを進めながら、図の作り方をルールとして決めています。
AIは毎回まっさらな状態から作業を始めます。直した内容を手順書に残さない限り、同じ失敗は何度でも起こるというのが、毎日動かしてきた実感です。
「確認しました」を信じず、確認の方法まで書く
AIに「スマホで確認しました」と言わせても、Chrome系の検査だけではiPhone(Safari系)での崩れを見逃していました。今はiPhoneと同じ表示エンジン(WebKit)で全ページを撮り、目で見て確かめています。
この経験から、手順書には「確認する」とだけ書かず、何を使ってどう確認するかまで書くべきだと考えています。
手順書があっても、最後の確認は別の役に任せる
手順書に決まりを書いても、毎回その通りになるとは限りません。スキルは同じ手順を踏ませる道具で、結果の正しさまでは約束しないので、当ブログでは確認役のサブエージェントに照合させてから公開しています。
自動投稿の仕組みそのものは、次の記事で詳しく書いています。


スキルで記事やサイトを作っても、公開するにはWordPressとサーバーが必要です。レンタルサーバーならエックスサーバー公式やConoHa WING公式が候補になるので、料金や機能を比べて選ぶとよいでしょう。
Claude Code skillsが向いている人・向いていない人
スキルは誰にでも必要な機能ではありません。運営者の立場から向き不向きを分けます。
skillsが向いている人
同じ作業を週に何度も頼み、毎回同じ説明を書いている人に向いています。記事作成やサイト更新のように順番が決まった作業や、無人で回したい作業ほど効果が出やすいです。
skillsが向いていない人
Claude Codeを月に数回、毎回違う内容で使う人は、無理に作る必要はありません。また、2026年10月時点の公式の料金ページでは、Claude Codeは無料プランに含まれず、Pro以上の有料プランで使えます。


Claude Code skillsのよくある質問
最後に、Claude Codeのスキルについてよく検索されている疑問に答えます。仕様は2026年10月時点の公式ドキュメントをもとにしています。
スキルは日本語で書いても動きますか?
説明文も本文も日本語で書けます。当ブログでも、AIに読ませている運営ルールの文書は日本語です。
ただし設定欄の項目名は、公式の英字の表記どおりに書く必要があります。
スキルとサブエージェントは組み合わせられますか?
組み合わせられます。設定欄で context: fork を指定すると、そのスキルを別の担当(サブエージェント)に任せ、元の会話を散らかさずに実行できます。
確認の多さに疲れている場合は、承認疲れを減らす方法も参考になります。
スキルを使うと追加料金はかかりますか?
スキルはClaude Codeに含まれる機能で、別に申し込むものではありません。ただし本文や資料を読み込む分だけ、ふだんの使用量は増えます。
当ブログも週の使用量の上限を意識して、2026年10月3〜4日の土日は自動投稿を止めました。手順書を短く保つことは、使用量の節約にもつながると考えています。
まとめ|Claude Code skillsは「毎回の説明」を手順書に変える仕組み
Claude Codeのskillsとは、作業の手順をSKILL.mdに書いて置き、必要な時だけ読み込ませる仕組みです。
- 毎回守るルールはCLAUDE.md、作業ごとの手順はスキル
- 必ず実行したい処理はhooks、任せたい作業はサブエージェント
- 自動で呼ばれるかは説明文(description)でほぼ決まる
- クラウドのルーチンでは個人スキルが読まれない
- 失敗を直したら手順書に書き足し、確認は別の役に任せる
いきなり完璧な手順書を作る必要はありません。毎回同じ説明を書いていると気づいた作業から、1つずつスキルにしていくのが続けやすい進め方です。
スキルで作った記事やサイトを公開するなら、WordPressを置くサーバーを用意しておきましょう。たとえばエックスサーバー公式なら、公式サイトから申し込めます。
-
URLをコピーしました!
















