Claude Codeの「スキル」の作り方｜毎回貼っていた指示を、呼べば動く機能に変える
Claude Codeを使い込むと、必ずこの瞬間が来ます。「またこの指示、貼ってるな」
議事録のフォーマット。レビューで見てほしい観点。毎週書いているレポートの構成。手順は頭に入っているのに、同じ文章をコピペしている。しかも貼り忘れた回だけ、微妙に違う結果が返ってくる。
そんな経験をされている方も多いのではないでしょうか？
この「毎回貼っている指示」をファイルに切り出し、名前で呼び出せるようにする仕組みがスキル（Skills）です。
本記事では、作り方だけでなく「意図したときに呼ばれる」ようにするための方法まで解説します。Claude Codeをデスクトップアプリ版で使う前提なので、ターミナルに慣れていなくても進められます。
📌 Noteをご覧になっている方へ
WEELでは、生成AIを業務や事業に取り入れたい方向けの各種セミナーを開催しています。
「どんな活用ができるのか知りたい」「自社でどう始めればいい？」という方に向けて、現場視点のノウハウや最新事例をご紹介しています。
✅ セミナーに参加する
Claude Codeのスキルとは何か
スキルは、SKILL.mdというMarkdownファイルを入口に、Claudeのツールキットへ手順書を追加する仕組みです。
最小構成ならファイル1枚で完成しますが、必要に応じて参照用のMarkdown、スクリプト、テンプレートなどを同じフォルダに同梱できます。
SKILL.mdに「何をするスキルか」「どう動いてほしいか」を書いて所定の場所に置くと、次の2つが可能になります。
/スキル名で直接呼び出せる
Claudeが「今これが関係ありそうだ」と判断して自動で読み込むことがある
2つ目が、単なるテンプレート置き場と決定的に違うところです。「議事録にして」と言っただけで、決めておいたフォーマットのスキルが立ち上がります。
スキルを知ったあと、まず出てくる疑問がCLAUDE.mdとの違いではないでしょうか。違いは読み込まれるタイミングです。
こちらの記事でCLAUDE.mdについて触れているので、興味がある方は参考にしてください。
スキルにするかCLAUDE.mdに書くかの判断はシンプルです。
CLAUDE.mdの内容が「事実」ではなく「手順」に育ってきたら、スキルに切り出すタイミングです。「デプロイのときは①テスト②ビルド③……」のような番号付き手順が増えてきたら、まさにスキル化のタイミングです。
なお、以前からある.claude/commands/のカスタムコマンドは現在スキルに統合されています。既存ファイルは引き続き動きますが、新規なら補助ファイルを同梱でき、自動起動もするスキル形式が推奨です。
Claude Codeのスキルが「呼ばれる」仕組み
スキルを作る前に、1つだけ押さえておくポイントがあります。スキルは3段階で読み込まれます。
段階1：起動時
全スキルの名前とdescription（説明文）の一覧がコンテキストに入ります。Claudeが見ているのは、いわば目次だけで、この時点でSKILL.mdの本文全体はまだ読み込まれていません。
段階2：呼び出し時
/スキル名と打つか、Claudeが「この説明文、いまの依頼に合いそうだ」と判断すると、SKILL.mdの本文が会話に投入されます。
投入された内容はセッションの残りの間ずっと留まり、後のターンでファイルが読み直されることもありません。だから本文は「1回だけやる手順」ではなく「このタスクの間ずっと守る指示」として書くのが正解です。
段階3：必要に応じて
フォルダに置いたreference.mdなどの補助ファイルは、必要と判断されたときだけ読まれます。それまでコンテキストを消費しません。
ここから2つのポイントがわかります。
①descriptionが弱ければ呼ばれない
②本文は簡潔に
背景説明を延々と書くのも避けてください。Claudeにとって自明な解説は省き、タスク固有の指示を優先するのが基本です。
「自社だけでClaude Codeをうまく活用できるか不安」「どこから手をつければいいかわからない」という方がいらっしゃれば、私たちWEELにご相談ください。
Claude Codeの導入支援からプロンプト設計、社内展開のサポートまで、実務に即した形でしっかり伴走します。
最小スキルを1本作る
一番簡単なのはClaudeにスキルを書かせることです。
ClaudeはSkillの形式を理解しているので、「スキルにして」と頼めばSKILL.mdのたたき台を作ってくれます。
いま作ってもらった議事録のフォーマットを、スキルにしてください。
「議事録にして」「会議メモ整理して」と言ったときに呼ばれるようにしたいです。
保存先は個人用スキル（~/.claude/skills/）でお願いします。コツは、その作業を1回やり切った直後に頼むこと。
会話で与えた前提・好み・細かい注文がそのまま中身になります。ゼロから「議事録スキル作って」と頼むより、はるかに実用的なものが出てきます。
ただし生成物をそのまま信用せず、frontmatterの記述とdescriptionにトリガーとなる言葉が入っているかは必ず自分で確認してください。
中身はこれだけ
手で書く場合も、フォルダを1つ作ってSKILL.mdを置くだけです。
---
description: 会議メモや文字起こしを、決まったフォーマットの議事録に整える。「議事録にして」「会議メモを整理して」と言われたとき、打ち合わせの走り書きや文字起こしを渡されたときに使う。
---
# 議事録整理
渡されたメモを以下の構成に整える。原文にない情報は補わない。
### 決定事項
- 決まったことだけを箇条書き。決まっていないものは書かない
### ToDo
| 担当 | 内容 | 期限 |
|---|---|---|
担当が不明なものは「未定」と書く。勝手に割り当てない。
## ルール
- 言い回しは要約してよいが、数字・固有名詞・日付は原文のまま扱う
- 曖昧な表現（「たぶん」）は曖昧なまま残す。断定に書き換えない
- 判断に迷う箇所は、末尾に「確認が必要な点」として列挙するYAMLフロントマターとMarkdown本文。この2つがSKILL.mdの基本構造です。
置き場所と、間違えやすい2点
間違えやすいのが、この2種類のスキルではコマンド名がフォルダ名で決まること。frontmatterのnameは一覧に出るラベルにすぎません。
もう1つは再起動が要らないことです。編集はそのセッションですぐ反映されます。
作ったら2通りでテストします。/スキル名と直接呼んで動けばOKです。
「この会議メモ、議事録にして」で呼ばれればdescriptionが機能しています。前者は動くが後者で呼ばれない、が最も多い失敗です。
descriptionの書き方が9割
自動起動するかどうかを左右する最も重要な材料がdescriptionです。
鉄則1：「何をするか」＋「いつ使うか」を両方書く
多くの人は機能しか書かず、「機能は分かるが、いま呼ぶべきかは分からない」状態になります。
鉄則2：三人称で書く
システムプロンプトに注入されるため、「私がお手伝いします」のような一人称は発見精度を落とします。
鉄則3：自分が実際に打つ言葉を入れる
「呼ばれない」原因の多くがこれです。「競合リサーチ」だけでなく「競合調査」「市場調査」と、言い換えや表記ゆれを並べておくと効きます。
鉄則4：重要なユースケースを前半に
Claude Codeでは、descriptionと補助フィールドwhen_to_useの合算が一覧に載る際、デフォルトで1,536文字に切り詰められます（設定で変更可）。
さらにスキルが増えると全体の文字数予算に合わせて説明文が短縮されることがあり、削られるのは後ろからです。
なお、オープン標準であるAgent Skillsの仕様上は、description自体の上限が1,024文字である点にも注意してください。
実際に記載すると、こうなります。
description: 会議メモや文字起こしを、決まったフォーマットの議事録に整える。「議事録にして」「会議メモを整理して」と言われたとき、打ち合わせの走り書きや文字起こしを渡されたときに使う。分解すると、①何をするか（議事録に整える）→ ②実際に打つトリガー語（「議事録にして」「会議メモを整理して」）→ ③言葉以外の起動条件（走り書きや文字起こしを渡されたとき）、という順に並んでいます。
全体が三人称で、機能とトリガーが前半に寄っています。
逆に「議事録を作る」だけのdescriptionでは、②も③も無いので自動起動しません。この差が、呼ばれるスキルと呼ばれないスキルの差だと考えられます。
ただし最終的に呼ぶかどうかはモデルの判断です。書いたら終わりにせず、想定した言い回しで実際に起動するかは必ずテストしてください。
覚えておくと効果的なfrontmatter
Claude Codeではfrontmatterの各フィールドを省略でき、実質必要なのは descriptionだけです。
実務で効果的なのは次の2つです。
disable-model-invocation: true
Claudeによる自動起動が止まり、/で打ったときだけ動く手動専用になります。デプロイ、コミット、外部への送信など影響の大きい操作には、まずこれをつけましょう。
allowed-tools
そのスキルを呼び出したターンの間だけ、指定したツールを追加の承認なしで使えます。
---
name: commit
description: 変更をステージしてコミットする
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---ただしプロジェクトの.claude/skills/にあるスキルは他人が書いたものかもしれません。リポジトリを信頼する前にallowed-toolsには必ず目を通しておく必要があります。
このほか、本文中の$ARGUMENTSは呼び出し時の引数に置き換わります。また!`git diff HEAD`と書くと、Claudeが内容を見る前にコマンドが実行され、出力が本文に埋め込まれます。
スキルが呼ばれない・呼ばれすぎるときの直し方
/スキル名では動くが自然な依頼で呼ばれない → 原因の多くはdescriptionです。自分が使う言葉が入っているか、「いつ使うか」が書かれているかを見直します。
/スキル名でも指示が効いていない気がする → YAMLが壊れている可能性があります。書式が不正だとメタデータが空のまま本文だけ読み込まれ、/スキル名では動くのに、descriptionが無いため自動起動のマッチングができません。
スキルが増えたら一部が呼ばれなくなった → 仕様です。一覧の文字数予算を超えると、呼び出し回数の少ないスキルからdescriptionが削られます。/doctorで消費量と要因を確認できます。
途中から効かなくなった → 通常は内容が残っており、Claudeが別の手段を選び始めただけです。指示を強め（「〜してよい」ではなく「必ず〜する」）に直すか、もう一度呼び直します。
Claude Codeでは何をスキルにすべきか
スキルにすべきものは、同じ指示を何度も貼り付けているもの、出力フォーマットを毎回揃えたいもの、手順の順番が重要なもの、忘れがちなチェック項目、そしてCLAUDE.mdの中で「手順」に育ってしまったものです。
スキルにすべきでないものは、一度きりの作業、全会話に効かせたい前提、Claudeにとって自明な一般知識、そして頻繁に変わる情報です。
スキルは「呼ばれて」はじめて意味がある
フォルダを1つ作ってSKILL.mdを置けば、スキルは完成します。それでも多くのスキルが眠ったままなのは、中身がどれだけ良くても、呼ばれなければ存在しないのと同じだからです。
だからdescriptionに「何をするか」「いつ使うか」と自分が実際に打つ言葉を入れる必要があります。
逆に呼ばれてほしくない操作にはdisable-model-invocation: trueを付ける。押さえるのはこの3点です。
最初の1本は、繰り返し貼っている指示をClaudeと一度やり切り、その場で「スキルにして」と頼むのが一番簡単です。
翌日、スラッシュコマンドを使わずいつもの言葉で頼んでみて、呼ばれたら成功。呼ばれなければdescriptionを直す。それだけで実用レベルになります。
「毎回この指示を貼っているな」と感じた瞬間が、スキルを作る合図です。その面倒くささを、そのまま業務効率化に変えてください。
WEELでは
生成AIやAIエージェントに関する無料オンラインセミナーも開催中です！
この機会にぜひお気軽にご参加いただけますと幸いです！
✅ セミナーに参加する
生成AIの最新ニュース・事例・イベント情報をいち早く知りたい方は、ぜひWEELの無料メルマガをご購読ください！
✉️ メルマガに登録する
💡 AI活用、どこから始めればいいかお悩みの方へ
「Claude Codeの使い方を知りたい」
「業務効率化をして、仕事を楽にしたい！」
そんな方向けに、無料の個別相談をやってます！
現場での事例も交えて、わかりやすくお話しします。
✨今すぐAIの専門家と話す✨
