「Claude Code Skillsって結局どう使えばいいの?」
「SKILL.mdを自分の仕事にも活かしたい!」
そう感じたまま、名前だけ知って終わっている方は多いはずです。
SKILL.mdというファイルを1つ用意するだけで、毎回同じ指示を打ち込む手間を省くことができます。
この記事では、Claude Code Skillsの使い方について、以下の内容を解説します。
この記事でわかること
- Claude Code Skillsの仕組みと、CLAUDE.mdやカスタムコマンドとの違い
- 実際に手を動かして覚える3つの手順
- 使ってみてわかった、うまくいったことと最初につまずいたポイント
- 呼び出し方や権限を制御する応用テクニック
- コーディング以外の業務でも使える、今すぐ試せるテンプレート7選
私自身、最初は「結局なにが便利なのか」がぴんと来ていませんでした。実際に手を動かしてみて初めて、「これは毎日の細かい指示出しを肩代わりしてくれる仕組みだ」と腑に落ちました。その実感を踏まえてお伝えします。
Claude Code Skillsとは?仕組みを解説
Claude Code Skillsの使い方を覚える前に、まず押さえておきたいのは「これが何をする仕組みなのか」という土台の部分です。ここがわかると、あとの手順がぐっと飲み込みやすくなります。
SKILL.mdに書く2つの要素

Claude Code Skillsは、ひとことで言えば「Claudeに業務のやり方を覚えてもらう仕組み」です。
毎回同じ説明を繰り返さなくても、一度SKILL.mdというファイルに手順を書いておけば、スラッシュコマンド1つ、あるいは会話の流れの中で、Claudeが同じ品質の作業をこなしてくれるようになります。
SKILL.mdの中身は、大きく2つの要素に分かれています。
SKILL.mdの2つの要素
- フロントマター……ファイル冒頭の「—」で囲まれた部分。スキルの名前や説明など、いつ・どう呼び出すかをClaudeに伝えるメタ情報
- 指示の本文……フロントマターより下に書く、実際にClaudeへ渡すマークダウンの指示文
料理のレシピカードに例えるとわかりやすいかもしれません。カードの上部に「料理名」や「向いている場面」を書いておき、下部に手順を書いておく。Claudeは必要なときにカードを取り出し、その手順どおりに動いてくれます。
また、SKILL.mdが置かれているフォルダの中には、テンプレートや実行用のスクリプトなど、補助的なファイルを一緒に入れておくことも可能です。
複雑な作業を任せたい場合は、こうした補助ファイルを組み合わせることで、指示の本体をすっきりと保ったまま、必要な情報だけを必要なときに読み込ませる構成にできます。
CLAUDE.mdやカスタムコマンドとの違い
Claude Code Skillsの使い方を調べていると、「CLAUDE.mdとどう違うのか」「カスタムコマンドと何が違うのか」という疑問にぶつかる方も多いはずです。
この3つは似たもの同士に見えますが、役割の重心が少しずつ異なります。違いを整理すると、次のようになります。
| 仕組み | 主な役割 | 読み込まれるタイミング |
|---|---|---|
| CLAUDE.md | プロジェクト全体に関わる前提知識・方針を伝える | セッション開始時に常に読み込まれる |
| カスタムコマンド | 決まった操作をスラッシュコマンドで呼び出す | コマンドを呼び出したときだけ |
| Skills | 手順・チェックリストなど「やり方」を必要なときだけ読み込ませる | 呼び出されたとき、または関連すると判断されたとき |
CLAUDE.mdは、いわば「会社に入った日に渡される案内資料」のようなものです。常に手元にあり、いつでも参照されます。
一方でSkillsは「特定の業務のときだけ取り出すマニュアル」に近い存在です。普段は引き出しにしまわれていて、必要な場面になって初めて開かれます。
この違いがあるおかげで、長い手順書をCLAUDE.mdに詰め込まなくても、使うときにだけ読み込ませることができ、普段のやり取りを軽く保てます。
カスタムコマンドは現在Skillsに統合されており、新しく作るのであればSkillsの形式で書いておくほうが、補助ファイルなどの拡張機能も使えて柔軟です。
CLAUDE.mdの書き方を詳しく知りたい方は、「Claude Code CLAUDE.mdの書き方|動作カスタマイズを自在にする実践ガイド」もあわせてご覧ください。
ポイント
CLAUDE.mdは「常に持ち歩く前提知識」、Skillsは「必要なときだけ取り出す手順書」と捉えると、使い分けに迷いにくくなります。
descriptionは「呼び出すための検索クエリ」と考える
SKILL.mdのdescriptionは、単なる説明文ではありません。
Claude Codeは会話の内容と各スキルのdescriptionを照らし合わせて、どのスキルを読み込むかを判断しています。descriptionは、Claudeが検索するときの「検索クエリ」のようなものだとイメージすると理解しやすいです。
descriptionを書くときのコツ
- 「何をするスキルか」だけでなく「どんなときに使うか」まで書く(Claude Code公式ドキュメントも同様に案内)
- スキル数が増えると一覧の表示文字数に上限があり、優先度の低いスキルから説明が削られる
- 「一番伝えたい用途」を先頭に書くと、途中で切られても肝心な情報が残る
Claude Code Skillsを使い始める3つの手順

Claude Code Skillsの使い方は、覚えてしまえば驚くほどシンプルです。ここでは、初めての方でもそのまま試せる3つの手順を順番に紹介します。
【ステップ1】スキル用フォルダをつくる
まず、スキルを置くためのフォルダを用意します。個人的に使うスキルであれば、ホームディレクトリの中に専用フォルダをつくり、その中にスキルごとのフォルダを作成してください。
mkdir -p ~/.claude/skills/meeting-notes
プロジェクト固有のスキルにしたい場合は、プロジェクトのフォルダ直下に同じ構成をつくれば、そのプロジェクトだけで使えるスキルになります。
「個人用にするか、プロジェクト用にするか」で迷ったときは、ひとまず個人用フォルダに置いてみるのがおすすめです。あとからプロジェクト用に移すのも難しくありません。
【ステップ2】SKILL.mdを書く
フォルダができたら、その中に「SKILL.md」という名前でファイルを作成します。中身は、前のセクションで説明したとおり、フロントマターと指示の本文の2段構成です。
---
description: 打ち合わせメモを要点ごとに整理し、次のアクションを抽出する。打ち合わせの内容を要約してほしいときに使う。
---
## 指示
以下のメモを読み、次の3つに整理してください。
1. 決まったこと(箇条書きで簡潔に)
2. 持ち越しになった論点
3. 次回までに誰が何をするか
## 入力
ここに打ち合わせメモを貼り付けて使います。
フロントマターの「description」には、「何をするスキルか」「どんなときに使うか」を具体的に書いておくのがコツです。
ここがあいまいだと、Claudeが「いつ使えばいいスキルなのか」を判断しづらくなってしまいます。
実際にAIへ相談しながら指示文の輪郭を決めていくと、スムーズに形になります。
私が最初のスキルをつくったときのやり取りは、次のような流れでした。
私:打ち合わせのメモを「決定事項」「持ち越し」「次のアクション」の
3つに整理するスキルをつくりたい。SKILL.mdの形にしてほしい。
Claude:かしこまりました。descriptionには「打ち合わせメモを要約し、
決定事項・持ち越し論点・次のアクションに分類する」と書くと、
関連する依頼のときに自動的に呼び出されやすくなります。
本文の指示は、出力フォーマットを箇条書きで固定しておくと
毎回ぶれにくくなりますが、その形で進めてよいですか。
私:それでお願いします。次回までの担当者も書き出せるようにしてほしい。
ポイント
思いついたことをそのまま伝えるだけで、descriptionの書き方や本文の構成について提案を返してくれます。一人で完璧な指示文を考え込む必要はありません。
【ステップ3】呼び出して試す
SKILL.mdを保存したら、さっそく試してみましょう。呼び出し方法は2通りあります。
2通りの呼び出し方
- 名前で直接呼び出す……「/meeting-notes」のように、フォルダ名をそのままスラッシュコマンドとして入力する
- 会話の中で自動的に呼び出させる……「この打ち合わせメモを整理して」のように、descriptionに近い言い方で依頼する
どちらの方法でも、期待どおりに整理された結果が返ってくれば成功です。もし思ったように動かない場合は、descriptionの言葉を、自分が実際に話しかけそうな表現に近づけてみてください。多くの場合、それだけで呼び出されやすさが変わります。
スキルの内容は、保存し直すだけで次のやり取りからすぐに反映されます。Claude Codeを再起動する必要がないため、「ちょっと言葉を変えてみる→試す」を気軽に繰り返せるのも、心強いところです。

Claude Code Skillsを使ってみてわかったこと
Claude Code Skillsの使い方を覚えたあとに気になるのは、「実際に使い続けてどうだったか」という部分だと思います。ここでは、私自身が試してみて感じたことを、率直にお伝えします。
うまくいったこと
もっとも実感したのは、「指示を考える時間そのものが減った」ということです。
これまでは、似たような作業のたびに「今回はどう伝えればうまく汲み取ってもらえるか」を考え直していました。スキルとして手順を固定してしまうと、その都度の試行錯誤がなくなり、頼みたいことだけに集中できるようになります。
もうひとつ意外だったのは、スキルの本体が「呼び出されたときだけ読み込まれる」という性質です。
長い手順書をCLAUDE.mdに書き足していくと、関係のない作業のときにもその情報が一緒に読み込まれてしまい、会話が重たくなりがちでした。スキルに切り出してからは、必要なときにだけ呼び出される形になり、普段のやり取りが軽くなったように感じています。
うまくいったこと
- 同じ説明を繰り返す手間がなくなり、依頼そのものに集中できる
- 手順が固定されるぶん、結果のばらつきが小さくなる
- 必要なときだけ読み込まれるので、普段の会話が重くならない
最初につまずいたポイントと対処
良いことばかりではなく、最初はうまくいかない場面もありました。
一番つまずいたのは、descriptionをあいまいに書いてしまい、Claudeが「これは関係のある依頼だ」と判断してくれなかったことです。
「メモを整理する」とだけ書いていたときは、なかなか自動的に呼び出されず、結局「/meeting-notes」と直接打ち込む場面が続きました。
そこで、descriptionに「打ち合わせメモを要約し、決定事項・持ち越し論点・次のアクションに分類する」というように、自分が実際に依頼しそうな言葉を具体的に盛り込んでみたところ、自然な会話の中でも呼び出されるようになりました。
本文を書きすぎないための工夫
指示が読み込まれている間は、その内容がやり取りの中に残り続けるため、長すぎる本文はかえって扱いにくくなります。実行する内容を簡潔に書き、詳しい説明や参考資料は別ファイルに分けておくと本体をすっきり保てます。
💬 コラム
最初は「便利な機能らしいから、とりあえず触ってみよう」くらいの軽い気持ちで始めました。
実際に手を動かしてみると、「自分の言葉でうまく説明できないこと」に気づかされる場面が何度もあり、それ自体が良い振り返りの機会になりました。

Claude Code Skillsをもっと使いこなす応用テクニック4つ
基本の使い方に慣れてきたら、次はClaude Code Skillsを運用面から使いこなす工夫を知っておきたいところです。
ここでは、以下の内容について詳しく解説します。
Skillsの運用でつまずきやすいポイント
- 呼び出し方をコントロールする設定
- 使えるツールの範囲を絞る設定
- スキル同士が重なったときの優先順位
- 指示が長くなったときの分割方法
呼び出し方をコントロールする
デフォルトの状態では、スキルは自分でも「/スキル名」で呼び出せますし、Claudeが会話の流れから自動的に呼び出すこともできます。ただし、スキルの内容によっては、この両方が有効なままだと都合が悪い場面もあるでしょう。
たとえば本番環境へのデプロイのように、実行するタイミングを自分でコントロールしたい処理があります。そうしたスキルには、フロントマターにdisable-model-invocation: trueを追加しておきましょう。
これを設定すると、Claudeが会話の流れだけで自動的に実行することがなくなり、自分で「/デプロイ」のように直接呼び出したときだけ動くようになります。
---
description: 本番環境へのデプロイを実行する
disable-model-invocation: true
---
1. テストを実行する
2. ビルドする
3. デプロイ先にプッシュする
逆に、ユーザーが直接呼び出す必要はないけれど、Claudeには知っておいてほしい背景知識のようなスキルもあるはずです。その場合はuser-invocable: falseを設定すると、「/」メニューには表示されなくなりますが、Claudeは必要な場面で参照してくれます。
目的に合わせて使い分けるのがコツです。
使えるツールの範囲を絞る
スキルの中でgitコマンドなどを繰り返し実行したい場合、毎回の実行のたびに許可を求められると、テンポが悪くなってしまいます。
そんなときに使えるのがallowed-toolsフィールドです。スキルを呼び出したそのターンに限り、指定したツールを確認なしで使えるようになります。次の例は、commitスキルにgit関連のコマンドをあらかじめ許可しておく設定です。
---
description: 現在の変更をステージしてコミットする
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---
反対に、特定のツールをそのスキルの実行中だけ使わせたくない場合はdisallowed-toolsで除外できます。バックグラウンドで動かす自動処理系のスキルから、確認を求めるツールを外しておきたいときなどに便利です。
注意点
allowed-toolsで許可されるのは、そのスキルを呼び出したメッセージの間だけです。次にメッセージを送信すると許可はリセットされるため、「一度設定すればずっと確認なしで動く」というものではありません。
セッション全体で常に許可しておきたい場合は、スキルの設定とは別に、通常の権限設定側にルールを追加しておいてください。
スキル同士が重なったときの優先順位を知る
個人用・プロジェクト用と使い分けているうちに、同じ名前のスキルが複数の置き場所に存在してしまうことがあります。そんなときClaude Codeがどちらを優先するのか、あらかじめ知っておくと混乱を防げるでしょう。
優先順位は、組織全体で配布される設定・個人用フォルダ・プロジェクト用フォルダの順に強くなります。組織の設定が個人用フォルダの内容を上書きし、個人用フォルダの内容がプロジェクト用フォルダの内容を上書きする形です。
また、同じ名前のスキルがどの階層にあっても、Claude Codeにあらかじめ組み込まれている標準スキルより優先されます。
| 置き場所 | 適用範囲 | 優先度 |
|---|---|---|
| 組織設定 | 組織内の全ユーザー | 最も高い |
| 個人用フォルダ | 自分の全プロジェクト | 2番目 |
| プロジェクト用フォルダ | このプロジェクトのみ | 3番目 |
なお、モノレポのようにサブフォルダごとにスキルを分けている場合は、名前が重なっても両方が使える形で共存するので安心してください。
サブフォルダ側のスキルには「フォルダ名:スキル名」という区別された名前が付き、Claudeは作業しているファイルの場所に応じて、適切なほうを判断して使い分けてくれます。
SKILL.mdが長くなってきたら補助ファイルに分割する
使い込んでいくうちに、SKILL.mdの指示がどんどん長くなってしまうことがあります。指示の本文は呼び出されるたびに会話の中に残り続けるため、長くなりすぎると、かえって扱いにくくなるので注意が必要です。
Claude Codeのスキルは、必要な情報を段階的に読み込む仕組みになっています。起動時にはスキルの名前とdescriptionだけが読み込まれ、呼び出されたときに初めて本文が読み込まれ、本文中で参照している補助ファイルは、実際に必要になったときだけ読み込まれる仕組みです。
この段階構造を意識すると、SKILL.mdを軽く保つコツが見えてきます。

SKILL.md本体には要点だけを残し、詳しい手順やAPIリファレンスのような細かい情報は、別ファイルに切り出して本文からリンクしておくのがおすすめです。こうしておけば、普段は軽いままで、必要なときだけ詳しい情報を読み込ませられます。
ポイント
- SKILL.md本体は500行程度を目安に収める
- 詳細な手順・API仕様は別ファイル(reference.mdなど)に分ける
- 実行用のスクリプトはscriptsフォルダにまとめて、本文からは呼び出すだけにする
【業務別】Claude Code Skillsの今すぐ使えるテンプレート7選
Claude Code Skillsの使い方は、コードを書く作業に限った話ではありません。文章を扱う日常的な業務との相性のよさに加えて、エンジニアの開発フローとの相性も抜群です。ここでは、今日から試せるテンプレートを7つ紹介します。

テンプレート1:打ち合わせメモを要点整理する
打ち合わせのたびに、議事録を一から整える作業に時間を取られている方は多いはずです。
「決定事項」「持ち越しになった論点」「次のアクションと担当者」の3項目に分けて出力するスキルをつくっておけば、メモを貼り付けるだけで共有しやすい形に整います。実際のSKILL.mdは次のように書いてみましょう。
---
description: 打ち合わせメモを要約し、決定事項・持ち越し論点・次のアクションと担当者に分類する。議事録を整理したいときに使う。
---
## 指示
以下のメモを読み、次の3項目に整理してください。
1. 決まったこと(箇条書きで簡潔に)
2. 持ち越しになった論点(結論が出ていない話題)
3. 次回までに誰が何をするか(担当者名があれば明記)
## 入力
{{ここに打ち合わせメモを貼り付ける}}
descriptionは、依頼するときに使いそうな言葉をそのまま書いておくと、自然な会話の中でも呼び出されやすくなります。
テンプレート2:週次・月次の定型レポートを自動作成する
毎週・毎月、似た構成のレポートを作成している方には特におすすめです。
数値や出来事を渡すだけで、見出しの整ったレポートのたたき台ができあがります。フォーマットを固定できるため、担当者が変わっても仕上がりの質を保ちやすくなります。
---
description: 週次または月次レポートのたたき台を作成する。実績や数値を渡せば、見出しの整ったレポート形式にまとめてくれる。
---
## 指示
以下の情報をもとに、週次レポートのたたき台を作成してください。
### 出力フォーマット
1. 今週の実績(箇条書き)
2. 先週との比較・変化点
3. 来週に向けた所感と予定
文体は「です・ます調」、各項目に小見出しを付けて読みやすく整えてください。
## 入力
{{今週の実績・出来事・数値などを箇条書きで貼り付ける}}
テンプレート3:SNS投稿文をトーン統一して複数案出しする
SNSの発信を続けていると、「今日はどんな言い回しにしようか」で悩む時間が積み重なっていくものです。
語り口・絵文字の使い方・文字数といった条件をスキルに固定しておけば、伝えたい内容を渡すだけでトーンの揃った候補が一度に手に入ります。毎回説明し直す手間がなくなるぶん、内容そのものを練る時間に回せます。
---
description: SNS投稿文を親しみやすいトーンで3案作成する。発信したい内容を渡すと、トーンを統一した候補をまとめて返してくれる。
---
## 指示
以下の内容をもとに、SNS投稿文を3案作成してください。
### 条件
- 文体:親しみやすい語り口、敬語なし
- 絵文字:各案に1〜2個まで
- 文字数:各案140字以内
- 3案の語尾や出だしができるだけ被らないようにする
## 入力
{{発信したい内容・テーマを書く}}
テンプレート4:記事や資料の校正・抜け漏れチェックをする
文章を仕上げたあとの見直しは、地味でありながら気力を使う作業です。
チェックする観点をあらかじめリスト化しておき、その観点に沿って指摘してもらうスキルをつくっておくと見落としを減らせます。観点を毎回書き出す必要がなくなるため、見直しの立ち上がりがぐっと軽くなります。
---
description: 文章の校正と抜け漏れチェックをする。誤字脱字・表記ゆれ・論理の飛躍などを観点ごとに指摘してくれる。
---
## 指示
以下の文章を、次の4つの観点でチェックしてください。
1. 誤字・脱字・変換ミス
2. 表記のゆれ(同じ意味の言葉が複数の表記になっていないか)
3. 説明が飛躍している箇所・読者に伝わりにくい表現
4. 結論や主張が不明瞭な段落
問題のある箇所は、元の表現と修正案をセットで挙げてください。
## 入力
{{チェックしたい文章を貼り付ける}}
テンプレート5:提案書・企画書のたたき台をつくる
白紙の状態から提案書を書き始めるのは、思いのほか腰が重いものです。
「背景」「課題」「提案内容」「期待できる効果」という骨組みを指示文に組み込んでおけば、要点を渡すだけでたたき台の構成ができあがります。ゼロから考える負担が減るぶん、内容を磨き込む時間に多く充てられます。
---
description: 提案書・企画書のたたき台を作成する。要点を渡せば、背景・課題・提案内容・期待効果の構成でまとめてくれる。
---
## 指示
以下の要点をもとに、提案書のたたき台を作成してください。
### 出力フォーマット
1. 背景(なぜこの提案が必要か)
2. 課題(現状の何が問題か)
3. 提案内容(何をどうするか、具体的に)
4. 期待できる効果
文体は「です・ます調」、各項目に小見出しを付けてください。
## 入力
{{提案の概要・解決したい課題・アイデアなどを書く}}
テンプレート6:コードレビューの観点を統一する
チームでコードレビューをしていると、レビュアーによって指摘する観点にばらつきが出がちです。
命名・エラーハンドリング・テストの有無といったチェック観点をスキルとして固定しておけば、誰がレビューを頼んでも同じ基準で指摘してもらえます。プロジェクト固有のコーディング規約がある場合は、指示文の中にそのまま書き込んでおくと、より実務に即したレビューになります。
---
description: 差分コードをレビューする。命名・エラーハンドリング・テストの有無を観点ごとに指摘する。
disable-model-invocation: true
---
## 指示
現在の差分を、次の観点でレビューしてください。
1. 命名が処理内容を正しく表しているか
2. エラーハンドリングが漏れていないか
3. 対応するテストが追加・更新されているか
4. 既存のコーディング規約から外れていないか
指摘は「箇所」「問題点」「修正案」をセットで挙げてください。
このスキルはdisable-model-invocation: trueにして、レビューしてほしいタイミングで自分から呼び出す運用にしておくと、意図しないタイミングで動き出す心配がありません。
テンプレート7:エラーメッセージから原因を調査する
見慣れないエラーに遭遇するたびに、調査の切り口をゼロから考え直すのは地味に時間がかかります。
「エラーメッセージの読み解き」「再現条件の切り分け」「疑わしい箇所の特定」という調査の型をスキルにしておけば、エラーを貼り付けるだけで、調査の手がかりを整理した状態から検討を始められるはずです。
原因が一つに絞れない場合でも、可能性の高い順に候補を並べてもらうよう指示しておくと、次に何を確認すればいいかが見えやすくなります。
---
description: エラーメッセージから原因を調査する。再現条件を切り分け、可能性の高い原因を順に挙げる。
---
## 指示
以下のエラーメッセージについて、次の順で整理してください。
1. エラーメッセージの意味(何が起きているか)
2. 考えられる原因を、可能性の高い順に3つまで
3. それぞれの原因を切り分けるための確認手順
## 入力
{{エラーメッセージと、発生したときの操作内容を貼り付ける}}
Claude Code Skillsを使うときに気をつけたいこと
Claude Code Skillsの使い方に慣れてくると、つい便利さばかりに目が向きがちですが、知っておきたい注意点もあります。
まず、Claude Code自体の利用には、最低限Proプランへの加入が必要です。無料プランでは利用できないため、気になる方はまずProプランで使用感を確かめてみるのがよいでしょう。
APIキーを使った従量課金での利用も選択肢にはありますが、想定外の費用が発生するリスクがあるため、初心者の方には積極的にはおすすめしていません。最初はProプランの範囲で使い方をつかみ、必要性を感じてから検討するくらいで十分です。
もうひとつ意識しておきたいのが、外部から取り込んだスキルを使う場面です。
インターネット上で公開されているスキルの中には、意図しない操作を含むものが混じっている可能性もゼロではありません。出どころのわからないスキルをそのまま取り入れるのではなく、まずは中身に目を通し、実行できる操作の範囲を絞った状態で試すようにしましょう。
外部ツールとの連携をさらに広げたい場合は、「Claude CodeのMCP設定方法を詳しく解説!」もあわせてご覧ください。
外部スキルを取り入れるときの注意点
- 誰が公開しているスキルなのかを確認する
- SKILL.mdの指示内容に目を通してから取り入れる
- 許可する操作の範囲を、必要な分だけに絞っておく
公式のSkillsを探す・参考にする
「ゼロから自分で書くのは大変そう」と感じたら、まずは公式が公開しているスキルを覗いてみるのがおすすめです。
Anthropicはanthropics/skillsリポジトリで、実用的なスキルの実例を公開しています。PDF処理やドキュメント作成など、実際に動くSKILL.mdの書き方を見られるので、自分でスキルをつくるときの参考になるはずです。
仕様の全体像を細かく確認したいときは、Claude Code公式ドキュメントにフロントマターの全フィールドがまとめられています。
いきなり全部を読み込む必要はありません。まずは公開されているスキルを1つダウンロードして、自分の環境で動かしてみるところから始めると、SKILL.mdの構造が体感としてつかみやすくなります。
スキルが思うように呼び出されないときの対処法
SKILL.mdを書いたのに、期待したタイミングでClaudeが呼び出してくれない。この記事で紹介した使い方を試した方の多くが、一度はぶつかる壁です。
そんなときは、次の順番で確認してみてください。
呼び出されないときの確認手順
- descriptionに、自分が実際に依頼するときに使いそうな言葉が入っているか見直す
- 「使えるスキルを教えて」とClaudeに尋ね、そのスキルが一覧に表示されているか確認する
- 依頼の言い方をdescriptionの表現に近づけてみる
- 「/スキル名」で直接呼び出せるかどうかを試す
反対に、意図しない場面でスキルが呼び出されすぎてしまう場合は、descriptionをより具体的に書き直すか、自分から呼び出したいだけであればdisable-model-invocation: trueを設定するのが手っ取り早い解決策です。
Claude Code Skillsに関するよくある質問
Claude Code Skillsの使い方を学び始めた方から、よく寄せられる質問に答えます。
Q:プログラミングの知識がなくても、スキルをつくれますか?
A:はい、つくれます。SKILL.mdは markdown で書く文章ファイルですので、コードを書く必要はありません。「どんなときに、どう動いてほしいか」を言葉で書き出せれば、それだけでスキルの土台になります。
慣れないうちは、Claudeに相談しながら一緒に形にしていくとスムーズです。
Q:スキルを保存したあと、Claude Codeを再起動する必要はありますか?
A:基本的には必要ありません。既存のスキルフォルダの中身を編集した場合は、保存した時点でその場のセッションに反映されます。新しくスキル用のフォルダそのものを追加した場合だけ、フォルダを認識させるために再起動したほうが確実です。
Q:チームで同じスキルを使うことはできますか?
A:できます。プロジェクトのフォルダの中にスキルを置き、バージョン管理の仕組みで共有すれば、同じ手順をチーム全体で使い回すことが可能です。担当者によって仕上がりがばらつきやすい作業ほど、共有の効果を実感しやすくなります。
Q:allowed-toolsを設定すれば、次回以降もずっと確認なしで使えますか?
A:いいえ、そこは誤解しやすいポイントです。allowed-toolsで許可されるのは、そのスキルを呼び出したメッセージのあいだだけで、次のメッセージを送ると許可はリセットされます。毎回確認なしで動かしたい場合は、通常の権限設定側にルールを追加しておく必要があります。
Q:複数のスキルを同時に使うことはできますか?
A:できます。メッセージの先頭で「/コードレビュー /エラー調査」のようにスキル名を並べて入力すると、両方のスキルがまとめて読み込まれます。関連するスキルを組み合わせて使いたい場面では、覚えておくと便利な使い方です。
まとめ
Claude Code Skillsの使い方は、覚えてしまえば「フォルダをつくる」「SKILL.mdを書く」「呼び出して試す」という3つの手順に集約されます。
難しいのは操作そのものではなく、「自分が普段どんな指示を繰り返しているか」に気づくことかもしれません。
この記事のポイントは、次のとおりです。
この記事の要点
- SkillsはCLAUDE.mdと違い、必要なときだけ読み込まれる「取り出し式の手順書」
- descriptionを具体的に書くほど、自然な会話の中でも呼び出されやすくなる
- disable-model-invocationやallowed-toolsで、呼び出し方と権限をコントロールできる
- コーディング以外の、文章を扱う日常業務との相性も良い
まずは、自分が日々繰り返している作業をひとつだけ思い浮かべて、それをSKILL.mdに書き出すところから始めてみてください。
「これくらいなら、自分にも書けそうだ」。そう思えた瞬間から、日々の作業との付き合い方は、少しずつ変わり始めるはずです。
Claude Codeの全体像をつかみたい方は、「Claude Codeの使い方まとめ|初心者向けに詳しく解説」もあわせてご覧ください。

