Opsfield
Claude Skillsを実際に使い始めると、自分の業務に合わせてカスタムスキルを作りたくなる場面が増えてきます。しかし、いざ作ろうとすると、SKILL.mdに何を書けばいいのか分からず、最初の1つでつまずいてしまいがちです。参考になる実例が少ないことも、その一因でしょう。
本記事では、Claude Skillsを作る前に知っておきたい基礎知識から、SKILL.mdの基本の型、実際の作成手順、うまく作るコツ、注意点、そのまま使えるテンプレートまでを、順を追って解説します。手順のなかにコツや応用を混ぜず、「まず作れる」ことを優先した構成にしているので、エンジニアでない方も最初の1本をつまずかずに作れるはずです。
Opsfieldは中小企業のAX（AIトランスフォーメーション）支援を専門としており、代表自身が日々の業務でカスタムスキルを設計・運用しています。その実務経験から、単なる文法解説にとどまらない「使われるスキル」の作り方を整理しました。仕組みや基本用語からしっかり確認したい方は、Claude Skillsとは何かを解説した記事もあわせてご覧ください。
目次
Claude Skillsを作る前に知っておきたいこと
作り方の手順に入る前に、前提となる3つのこと――スキルとは何か、どこで使えるか、どこに置くか――を先に解説します。ここが分かっていれば、後の手順で迷いません。
そもそもClaude Skillsとは何か
Claude Skillsを一言で言うと、「特定の作業のやり方をClaudeに覚えさせておき、以降の会話で自動的に使わせる仕組み」です。毎回同じ説明を書いて指示する代わりに、その手順やルールを一度ファイルにまとめておくイメージだと考えてください。
スキルの正体は、SKILL.mdという1枚のファイルを入れたフォルダです。Claudeはこのファイルに書かれた説明を読み、「今の依頼はこのスキルの出番だ」と判断すると、自動的に中身を読み込んで作業します。難しいプログラミングは必要なく、書くのはMarkdown（見出しや箇条書きで整形するテキスト）だけです。仕組みそのものをもっと詳しく知りたい方は、Claude Skillsとはの記事で図を交えて解説しています。
どこで使えるか（対応環境とプラン）
Claude Skillsは、Claude Code・Claude.ai・APIのいずれでも利用できます。
ただし、この記事で解説する「フォルダに設定ファイルを置いて管理する」方法が使えるのは、主にClaude Codeです。Claude.aiではブラウザ上でスキルをアップロードして使う形になり、置き場所の考え方が変わります。
そこで本記事は、Claude Codeでカスタムスキルを作ることを前提に進めます。なお、スキル機能や対応する操作は利用プランによって異なります。自社のプランで何ができるかは、着手前にAnthropic公式の対応状況を確認しておくと安心です。ここから先は、実際に手を動かす準備として、スキルをどこに置くかを見ていきます。
スキルの置き場所は「誰が使うか」だけで決まる
スキルの置き場所は2種類あります。自分だけが使う個人用（~/.claude/skills/）と、チームで共有するプロジェクト用（.claude/skills/）です。両者の中身の書き方はまったく同じで、違うのは「誰が使えるか」という適用範囲だけです。個人用は自分のすべての作業で使え、プロジェクト用はそのプロジェクトを開いたメンバー全員が使えます。
スキルはあとから別の場所へ移動もコピーもできるので、置き場所を最初から悩む必要はありません。まずは自分だけの個人用フォルダに作り、実際に役立つと分かってから、チーム用のプロジェクトフォルダへ移せば十分です。
チームで共有する場合は、プロジェクト用フォルダに置いてGitで管理すると、メンバー全員が同じスキルを使えるようになります。共有後の運用ルールづくりやチームへの定着については、Claude Skillsの使い方の記事でも取り上げています。
SKILL.mdの基本の型を知る
手順に入る前に、スキルの中身であるSKILL.mdがどんな形をしているかを見ておきましょう。この型が頭に入っていれば、次の作成手順で「何を書けばいいのか分からない」という状態になりません。
SKILL.mdは「設定」と「指示」の2部構成
SKILL.mdは、大きく2つの部分でできています。まずは、実際の例を見てみましょう。以下は「商談メモから提案書のたたき台を作るスキル」を、必要最低限まで削ったものです。本記事では、この提案書スキルを共通の例として使っていきます。
---
name: proposal-draft
description: 商談メモから提案書のたたき台を作成するスキル。商談後の提案書作成、見積もり前のたたき台づくりを頼まれたときに使う。
---
# 提案書ドラフト作成
## やること
1. 商談メモから課題・要望を抽出する
2. 自社サービスと紐づけて解決策を整理する
3. 見出し構成（課題→解決策→進め方→概算費用）でたたき台を作る
1つ目が、上半分の---で挟まれた「フロントマター」と呼ばれる設定欄です。ここには、name（スキルの名前）とdescription（何をするスキルで、いつ使うか）を書きます。2つ目が、その下に続く本文で、Claudeにやってほしい作業の手順そのものをMarkdownで書きます。この例では、提案書を作る3つのステップを箇条書きにしています。
たとえるなら、フロントマターは「このスキルは何者で、いつ呼ばれるべきか」を示す名札、本文は「呼ばれたら何をするか」を示す作業マニュアルです。この2つがそろって、はじめて1つのスキルとして動きます。まずはこの形が「スキルの最小の姿」だと覚えておけば十分です。
Claude Skillsの作成手順
基本の型が分かれば、あとは手を動かすだけです。ここでは、先ほどの提案書スキルを例に、フォルダを作ってから動作を確かめるまでの流れを5つの手順で追います。応用的な機能はいったん脇に置き、「まず1本を完成させて動かす」ことだけに絞って進めます。
手順1 スキル名のフォルダを作る
最初に、スキルを入れるフォルダを1つ作ります。
フォルダの名前が、そのままスキルの名前になります。今回は提案書のたたき台を作るスキルなので、個人用の置き場所にproposal-draftという名前でフォルダを作ります。パスにすると~/.claude/skills/proposal-draft/です。名前は半角英数字とハイフンで、中身がひと目で分かるものにしておくと、後で増えたときに探しやすくなります。
手順2 フォルダの中にSKILL.mdを作る
作ったフォルダの中に、SKILL.mdという名前のファイルを1つ作ります。
ファイル名は大文字のSKILL.mdで固定です。これがスキルの本体になります。現時点では中身は空のままでかまいません。フォルダとこのファイルが1つずつあれば、スキルの入れ物としては完成です。ここまでで、proposal-draftフォルダの中にSKILL.mdが1枚ある、という状態になります。
手順3 フロントマターに名前と説明を書く
SKILL.mdを開き、先頭に---で挟んだフロントマターを書きます。
ここに書くのは、name（スキルの名前）とdescription（いつ使うかの説明）の2つです。とくにdescriptionは、Claudeが「この依頼でこのスキルを使うか」を判断する材料になるため、いちばん大切な一行になります。今回の例なら「商談メモから提案書のたたき台を作成するスキル。商談後の提案書作成を頼まれたときに使う」のように、対象と使う場面がはっきり分かるように書きます。
手順4 本文にやってほしいことを書く
フロントマターの下に、Claudeにやってほしい作業を本文として書きます。
難しく考えず、人に仕事を頼むときと同じ言葉で、手順を箇条書きにするだけで十分です。提案書スキルなら「商談メモから課題を抜き出す」「自社サービスと結びつけて解決策を整理する」「決まった見出し構成でたたき台を作る」といった具合です。この段階では細かいルールまで盛り込まず、まずは大きな流れだけを書いておきます。中身を作り込むのは、動くことを確かめてからで問題ありません。
手順5 実際に頼んで動くか確かめる
最後に、いつもClaudeに話しかけるのと同じ言葉で依頼してみます。
提案書スキルなら「先日の商談メモから提案書のたたき台を作って」と頼み、作ったスキルが自動的に呼び出されるかを確認します。狙いどおり動けば、最初の1本は完成です。もし呼ばれなかったり、期待と違う結果が返ってきたりしても、慌てる必要はありません。どこを直せばよいかは、次の「うまく作るコツ」で具体的に説明します。
Claude Skillsをうまく作るコツ
最初の1本が動いたら、次は「狙いどおりに呼ばれ、期待した成果物が返ってくる」ように磨いていきます。
ここでは、実務で効いてくる作り込みのコツを、description・命名・本文設計・ファイル分割・テスト・応用機能の順に解説します。
descriptionは「何を・いつ使うか」を具体的に書く
スキルの出来を最も左右するのが、descriptionの書き方です。Claudeは依頼内容とこのdescriptionを照らし合わせて、スキルを使うかどうかを判断します。ここが曖昧だと、どれだけ本文を作り込んでも呼ばれません。悪い例と良い例を並べると、違いがはっきりします。
| 観点 | 悪い例 | 良い例 |
|---|---|---|
| 提案書作成のスキル | 提案書を手伝うスキル | 商談メモから提案書のたたき台をMarkdownで作成する。商談後の提案書作成、見積もり前のたたき台づくりを頼まれたときに使う |
| コードレビューのスキル | コードをレビューする | 差分を分析し、社内のコーディング規約に沿って指摘する。プルリクエストのレビューやコード品質確認を頼まれたときに使う |
良い例に共通するのは、成果物の形式（Markdown、指摘コメントなど）と、実際に頼まれる言い回しまで書き込んでいる点です。「どんな言葉で頼むか」を思い浮かべながら書くほど、精度は上がります。なお、descriptionを省略すると本文の最初の段落が代わりに使われます。
さらに細かく呼び出しを制御したくなったら、when_to_useという項目にトリガーとなる依頼例を分けて書く方法もありますが、これは慣れてからで十分です。
スキル名は動名詞形か名詞句で統一する
スキル名（フォルダ名）の付け方にも、ちょっとした型があります。Anthropic公式が推奨するのは、動名詞形（例：processing-pdfs、writing-proposals）か名詞句（例：proposal-draft、pdf-processing）での命名です。helperやutilsのような、何をするのか分からない曖昧な名前は避けるべきだとされています。
スキルの数が増えるほど、命名の一貫性が効いてきます。統一された名前は、「このスキル、何をするんだっけ」と迷う時間を減らしてくれるからです。似た名前のスキルが乱立してClaudeの判断が割れる事態も防げます。最初の1本の段階から命名ルールを決めておけば、10本、20本と増えても管理が破綻しません。
本文は「固定情報・テンプレート・ルール」で組み立てる
本文を何となく書き始めると、情報が入り混じって読み取りづらいスキルになりがちです。実務で効くのが、本文を「固定情報」「テンプレート」「ルール」の3つに分けて設計する考え方です。私自身、Claude Codeを自社の業務に組み込むなかで、この3層構造にたどり着きました。
固定情報は、自社サービスの一覧や訴求ポイントなど、毎回変わらない前提です。テンプレートは、出力してほしい文書の骨格を、決まった見出しと{変数}で示したものです。ルールは、「金額は必ず税別で書く」のように一貫して守ってほしい原則を指します。次のように書いておくと、担当者が変わっても成果物のばらつきを抑えられます。
## 提案書テンプレート
# {クライアント名}様向けご提案
## 課題
{商談メモから抽出した課題}
## ご提案内容
{自社サービスとの紐づけ}
無意識にやっていた判断の癖ほど、言語化するとClaudeの出力が自分の型に近づきます。属人化していた進め方が、誰でも再現できる資産へと変わっていきます。
長くなったら別ファイルに分ける
作り込むほど本文は長くなりますが、SKILL.mdが膨らむと、呼び出すたびに大量の情報が読み込まれ、他の作業に使える余地を圧迫します。Anthropic公式は、SKILL.md本文を500行以内に収めることを推奨しています。目安を超えそうなら、詳細を別ファイルに切り出しましょう。
分けても効率が落ちないのは、Claude Skillsが「段階的開示」という仕組みを土台にしているからです。参考資料やスクリプトをいくつ増やしても、実際に参照されるまではコンテキストを消費しません。
切り出したファイルへのリンクは、必ずSKILL.mdから直接1階層で張るのが原則です。2階層以上の深い入れ子にすると、Claudeがファイルの一部しか読み込まないことがあるためです。段階的開示の詳しい仕組みは、Claude Skillsとはの記事で解説しています。
作ったら必ずテストして育てる
スキルは、作った瞬間が完成ではありません。実際に使う言い回しで依頼し、狙いどおり呼ばれるか、期待した成果物が返るかを確かめながら育てていくものです。呼ばれないなら、多くの原因はdescriptionの曖昧さにあるので、対象や場面の言い回しを足します。呼ばれたのに結果がずれるなら、本文の手順や参照先を見直します。
この改善を仕組み化したいときに便利なのが、Anthropic公式が提供するskill-creatorというプラグインです。作りたい内容を伝えて雛形を生成させたり、既存スキルの改善点を洗い出させたりできます。テストケースを用意しておけば、修正前後を比較する評価まで回せるので、勘に頼らず精度を上げていけます。
さらに使いこなす応用機能
基本のスキルが作れるようになったら、フロントマターの応用項目にも手を広げられます。いずれも慣れてきてからで十分ですが、代表的な4つを知っておくと、作れるスキルの幅が広がります。
| フィールド | 何ができるか | 使いどころ |
|---|---|---|
allowed-tools | 指定したツールを承認なしで使える「事前承認」の設定（使えるツールを制限する設定ではない） | 定型作業のたびの確認を省きたいとき。使わせたくないツールはdisallowed-toolsで除外する |
$ARGUMENTS | 呼び出し時に渡した文字列を本文へ差し込む（$0・$1で順番に受け取ることも可能） | クライアント名など、毎回変わる値を渡したいとき |
context: fork | 会話履歴を引き継がず、独立したコンテキストでスキルを実行する | 調査など、本体の会話に余計な文脈を持ち込みたくないとき |
disable-model-invocation | trueにすると自動起動を止め、手動実行だけに限定する | 削除や外部送信など、副作用の大きい処理を安全に扱いたいとき |
これらは必須ではありません。まずは基本の形で運用し、「毎回この確認が面倒だ」「この値を渡したい」と感じた項目から、1つずつ試していくのがおすすめです。
作成時に注意したいこととよくある失敗
ここでは、最初のうちにつまずきやすいポイントを整理します。よくある失敗と、その避け方を知っておくだけで、遠回りをせずに済みます。
descriptionを雑に書く
最も多いのが、descriptionを名前の言い換え程度で済ませてしまうケースです。「提案書を作るスキル」のような一言では、Claudeが呼ぶべき場面を判断できません。せっかく本文を作り込んでも、入り口でつまずいて呼ばれないままになります。
解決策は、対象業務と成果物、そして呼ばれる際の言い回しまで、具体的に書き直すことです。例えば「提案書を作るスキル」なら、「商談メモから提案書のたたき台をMarkdownで作成する。商談後の提案書づくりを頼まれたときに使う」まで具体化します。
すると、どんな依頼で発火すべきかがはっきりします。descriptionは、スキルの実力を引き出す「呼び出しスイッチ」です。スイッチが精密なほど、狙った場面で確実に働いてくれます。
1つのスキルに詰め込みすぎる
例外処理や背景説明まで、すべて1つのSKILL.mdに書き込んでしまうのも、ありがちな失敗です。あれもこれもと盛り込むうちに本文が膨らみ、簡潔さという本来の利点が失われます。文量が増えれば、呼び出すたびに大量の情報が読み込まれ、他の作業に使える余地も圧迫してしまいます。
対策は、役割分担を意識することです。詳細な参考情報や長い事例は別ファイルへ切り出し、SKILL.md本文には手順の要点だけを残します。例えば提案書スキルなら、過去の提案サンプルはexamples.mdへ、細かいサービス仕様はservice-menu.mdへ逃がし、本体は流れだけにとどめます。
この「本体は薄く、詳細は外に」の形を保てば、読みやすさと動作の軽さを両立できます。目安として、本文が公式推奨の500行を超えそうになったら、分割の合図です。
最初から完璧を目指す
あらゆる場面で通用する万能なスキルを、最初から目指してしまうケースです。例外を想定するほど設計は複雑になり、いつまでも完成しません。結果として、動くものが手元に残らないまま熱が冷めてしまいます。凝った設計図を描くことより、まず動く1本を持つことのほうが、はるかに前へ進めます。
おすすめは、逆の進め方です。まずは自分専用の、具体的な1つの業務に絞って作り、実際に使いながら少しずつ広げていきます。例えば提案書スキルなら、最初は自分の担当案件だけを想定して作り、他のメンバーや別業種にも通じるルールは、必要になった時点で足していけば十分です。
小さく作って動かすほうが、改善のサイクルも早く回ります。1本を仕上げた経験は、2本目以降を作るときの確かな土台にもなります。
他人が公開したスキルをそのまま使う
最後に、GitHubやSNSで公開されているSKILL.mdを、中身を確かめずにコピーして使うのは危険です。SKILL.mdはAIへの指示書そのものなので、悪意のある指示が紛れ込んでいても、見た目には気づきにくい性質があります。
例えば「作業のついでに特定のファイルを外部へ送信する」といった一文が、正当な手順に紛れていても気づけないことがあります。構成が整っていて便利そうに見えるスキルほど、精査せずに取り込みがちなので注意が必要です。安全なのは、構成やアイデアだけを参考にし、中身は自分の言葉で書き直すことです。実際のテキストはそのままコピーしないと決めておけば、リスクは大きく下げられます。
実例とテンプレート
ここまでの内容を踏まえた、そのまま使えるテンプレートと、実際に業務でスキルを育ててきた考え方を紹介します。手元の1本を作るときの下敷きにしてください。
コピーして使える提案書スキルのテンプレート
以下は、これまで例に使ってきた提案書スキルを、固定情報・テンプレート・ルールまで盛り込んだ形にしたものです。自社サービス名や振込ルールなどを自分の業務に置き換えれば、そのまま使えます。
---
name: proposal-draft
description: 商談メモから提案書のたたき台をMarkdownで作成するスキル。商談後の提案書作成や、見積もり前のたたき台づくりを頼まれたときに使う。
---
# 提案書ドラフト作成
## 固定情報（自社の前提）
- 主力サービス：〇〇（訴求ポイント：△△）
- よく使う実績：導入企業□社、平均◯%改善
## やること
1. 商談メモから課題・要望を抽出する
2. 固定情報の自社サービスと紐づけて解決策を整理する
3. 下のテンプレートに沿ってたたき台を作る
## 出力テンプレート
# {クライアント名}様向けご提案
## 課題
{抽出した課題}
## ご提案内容
{自社サービスとの紐づけ}
## 概算費用と進め方
{次のステップ}
## ルール
- 金額は税別で書き、確定値は入れない（「概算」と明記）
- 箇条書きを多用し、1文は短くする
業務の中でスキルを育ててきた考え方
ここからは、私自身がOpsfieldの業務運営でスキルを設計してきた実例です。現在は、議事録の整理、SNS投稿の下書き、月次の経営レポート、提案書のたたき台づくりなど、数十本規模のスキルを日常的に運用しています。
最初に迷うのは「何をスキル化するか」ですが、有効だったのは、直近のやり取りやコミット履歴をClaude Codeに読み込ませ、「繰り返しているパターンを抽出して」と依頼する方法でした。週次の進捗報告や商談前の情報整理など、自分でも気づいていなかった定型作業が想像以上に見つかります。
そして、作った後も使いながら育て続けることが、精度を上げる近道です。私の場合、スキルごとに気づきを溜めるメモ（プレイブック）を併設し、月に一度は見直してルールへ反映しています。こうして、属人化していた自分の判断基準そのものが、いつでも再現できる資産へと変わっていきます。型を明文化して資産にするという発想は、AI戦略顧問・Fractional CTOとして複数の企業の技術組織づくりに携わってきた経験にも通じるものだと感じています（代表プロフィール）。
Claude Skillsの設計・作成ならOpsfieldにご相談ください
Claude Skillsの作り方は、置き場所の決定からdescriptionの書き方、固定情報・テンプレート・ルールの3層設計、そして評価しながら育てる運用まで、いくつもの判断が積み重なります。一つひとつは難しくありませんが、どの業務からスキル化すべきかの見極めや、自社ならではのルールの言語化には、実務での試行錯誤が欠かせません。
特に、開発組織やエンジニアリングチームでClaude Codeの活用を本格的に進めたい場合は、専門的な伴走が近道になります。OpsfieldのAI駆動開発研修では、開発組織向けにClaude Codeやカスタムスキルの設計・運用ノウハウを実践形式で伴走します。
業務全体でのAI活用を診断したい方にはAI活用診断、具体的な業務への実装まで伴走してほしい方にはAI業務変革伴走もご用意しています。Claude Skillsの作り方でお悩みの方は、ぜひ一度Opsfieldにご相談ください。
