Claude Skills を自作する｜SKILL.md の書き方から業務3系統・チーム配布まで現役エンジニアが実演

Claude Skills を使っているうちに、「公式の Skill や他人が公開している Skill を入れるだけでは、自分の業務にピタッとは合わない」と感じてきたのではないでしょうか。ラッコキーワード実測（2026 年 5 月時点）でも親キーワード「Claude Skills」は月 8,100 件・SEO 35・+788% の急成長中で、その先にある「自作」は検索結果がほぼ Anthropic 公式の紹介一色です。私自身は Claude.ai と Claude Code の両方で、コード系・ドキュメント系・業務テンプレ系の 3 系統の Skill を自作して毎日使っています。

結論から言うと、Claude Skills の本当の価値は「自作」に踏み込んだ瞬間に出る——というのが、3 系統を業務で動かしている私の率直な感覚です。本記事では、SKILL.md の中身、scripts と resources の配置、3 系統それぞれの実物の作り方、チームへの配布、失敗の避け方まで、自作の手順を再現できる粒度で整理します。

とりあえず最短で「自分の最初の Skill」を作りたい方は、セクション 1「結論」と セクション 3「SKILL.md の書き方」から読み始めると、本日中に最初の SKILL.md が動きます。なお Claude Skills の全体像や「使う側」の話は Claude Skills の使い方を別記事でまとめています。本記事は終始「作る側」に視点を固定します。

01 — 結論：Claude Skills の真価は「自作」にある（一行マップ）

📖 この章で使う用語

  • Claude Skills：Claude（Claude.ai / Claude Code）に「機能・指示・ファイル」をパッケージ化して渡せる仕組み。2025 年 10 月に Anthropic が公式発表しました。営業時代の「お客様別の対応手順書」を AI に渡すイメージです。
  • 自作 Skill：既存の Skill を入れるのではなく、自分で SKILL.md を書いて作る Skill のこと。
  • SKILL.md：Skill の心臓部。呼び出し条件と手順を書く Markdown ファイル。本でいう「目次 + 表紙」の役割です。

一行でまとめると、自作 Skill とは「自分の業務手順を SKILL.md にパッケージ化して、Claude が必要なときに自動で呼び出せるようにする行為」です。既存の Skill を探して入れる「使う側」から、自分の手順を覚えさせる「作る側」へ一歩踏み込むこと、と言い換えてもいいと思います。

迷ったら、この 3 行だけ覚えておけば大丈夫です。

  1. 最小なら SKILL.md 1 枚だけで作れる
  2. 必要に応じて scripts/ で実行コード、resources/ で参照ファイルを足す
  3. 1 Skill = 1 タスクで分ける（詰め込まない）

なぜ「使う側」で止まらず「作る側」に踏み込むと価値が出るのか。理由はシンプルで、業務というのは会社ごと・チームごとに固有の手順を持っているからです。公開されている Skill は「世の中の平均的なやり方」に最適化されています。それはそれで便利なのですが、自分の会社の議事録フォーマット、自分のチームのレビュー観点、自分の取引先向けの提案書の型までは、当然ながらカバーしていません。営業時代に例えるなら、市販の営業マニュアルは役に立つけれど、自分の担当エリア・自分のお客様に合わせた一手は、結局自分で書き足すしかなかった——あの感覚に近いです。

ここで、本記事の立ち位置を正直にお伝えしておきます。私が業務で実際に作って毎日使っているのは、コード系・ドキュメント系・業務テンプレ系の 3 系統の自作 Skill で、Claude.ai と Claude Code の両方に置いています。この範囲は自分の言葉で具体的に書きます。一方で、Anthropic が公式提供している Skill（pdf / docx / pptx などを扱うもの）の細部や最新仕様、配布経路については、私が業務で常用しているわけではないので、公式ドキュメントで確認した範囲を出典付きで整理する形にします。実物のコードや設計判断は前者、仕様の話は後者、という線引きで読み進めていただければと思います。

Claude Skills は 2025 年 10 月にリリースされた比較的新しい機能で、UI や仕様の変化が早い領域です。本記事の手順やフィールド名は執筆時点（2026 年 6 月）の整理であり、最新の正確な仕様は必ず Anthropic 公式ドキュメント（取得：2026-06-02）でご確認ください。

なお、「絶対にこの型どおりに動く」と断定するつもりはありません。Claude のバージョンや環境によって挙動は振れます。本記事は「私の業務での作り方の型」をベースにした再現手順、という前提で読んでいただければと思います。

02 — 自作 Skill とは：「使う側」から「作る側」へ踏み込むということ

📖 この章で使う用語

  • 使う側 / 作る側：既存の Skill を入手して動かすのが「使う側」、SKILL.md を自分で書くのが「作る側」です。
  • 定型作業：毎週繰り返す、決まった手順の作業のこと。自作 Skill の最初の候補になります。

「使う側」と「作る側」の境界線は、ひとことで言えば「SKILL.md を自分で書くかどうか」です。GitHub で公開されている Skill を git clone して入れて動かすのは使う側。自分の業務手順を Markdown に書き起こして Claude に覚えさせるのが作る側です。

では、いつ作る側に踏み込むべきか。私の判断基準はシンプルで、「毎週 3 回以上やる定型作業」が自作 Skill の最初の候補です。たとえば私の場合、議事録の整形は毎日のように発生していたので、最初に Skill 化したもののひとつでした。逆に、月に 1 回あるかどうかの作業をわざわざ Skill にするのは、作る手間に見合わないことが多いです。

もう少し具体的に、自作の候補を見つけるときのチェックポイントを挙げておきます。「同じプロンプトを毎回コピペしている」「出力の形を毎回同じように指示し直している」「決まった参照ファイルを毎回貼り付けている」——このどれかに当てはまる作業があれば、それは Skill 化の有力候補です。私はこの 3 つを目印に、日々の作業の中から「これ、毎回やってるな」というものを拾って、少しずつ Skill にしてきました。頻度が高くて、手順が決まっていて、毎回ほぼ同じ指示を出している。この 3 条件が揃った作業ほど、Skill 化の効果が大きかったです。

自作 Skill には、作る側が責任を持つべき 3 つの構成要素があります。

  • SKILL.md：呼び出し条件（いつ呼ぶか）と手順（何をするか）を書く本体
  • scripts/：Skill が呼ぶ実行コードの置き場（bash / Python / TypeScript など）
  • resources/：Skill が参照するテンプレやサンプルの置き場

営業時代、私は自分専用の「お客様対応のチェックリスト」を、誰に頼まれるでもなく自分の手で書き起こしていました。何度も同じ場面に出くわすうちに、頭の中の手順を紙に落としておいたほうが結局ラクだったからです。自作 Skill も感覚としては同じで、自分がいつもやっている手順を、自分の手で AI 向けに書き起こす作業だと思っています。

ここで一点、最初に踏み込むときの心構えをお伝えしておきます。最初から完璧な Skill を作ろうとしないことです。私の場合、最初に作った Skill は SKILL.md 1 枚だけの素朴なものでした。それを 1 週間使ってみて、「ここの指示が足りない」「この場面で呼ばれない」と気づくたびに、少しずつ手を入れていきました。結果的に、いきなり作り込むより、小さく作って育てるほうが、実際に使われる Skill になりました。これは営業時代に提案書を作っていたときと同じで、最初の 1 枚を完璧にしようとするより、お客様の反応を見て直していくほうが、結局よい提案書になったのと似ています。

なお、「作る側に踏み込むには、ある程度コードが書けないといけないのでは」と身構える方もいると思いますが、そんなことはありません。後で詳しく見ますが、業務テンプレ系・ドキュメント系の Skill は、SKILL.md と参照ファイルだけで作れます。コードを書く必要が出てくるのは、scripts/ で実行コードを組む段階だけです。最初の一歩は、Markdown が書ければ十分に踏み出せます。

03 — SKILL.md の書き方：frontmatter・命名・粒度・再利用性・セキュリティ

📖 この章で使う用語

  • YAML frontmatter（フロントマター）：Markdown ファイルの先頭を --- で囲んだ設定ブロック。name や description を書きます。料理レシピでいう「材料表」のイメージです。
  • description（呼び出し説明）：Claude が「いつこの Skill を呼ぶか」を判断するための文章。ここが曖昧だと拾われません。
  • 粒度：1 つの Skill がカバーする範囲のこと。1 Skill = 1 タスクに揃えます。
  • 再利用性：複数のプロジェクトで使い回せる設計のこと。汎用部分とプロジェクト固有部分を分けます。
  • 環境変数：API キーなどの機密情報を、コードの外側（OS の設定）に持たせる仕組み。.env や export を使います。

ここが本記事の心臓部です。SKILL.md は、frontmatter（設定ブロック）と本文（手順記述）の 2 段で構成されます。まず frontmatter から見ていきます。

公式ドキュメントで確認した範囲では、SKILL.md の frontmatter で最低限必要なフィールドは name と description の 2 つです（Agent Skills overview｜Anthropic Docs、取得：2026-06-02）。これ以外のフィールド（allowed-tools など）が定義される場合もありますが、細部は変化が早いため、最新は公式でご確認ください。

name の付け方：動詞 + 目的語で短く

name は、その Skill が何をするかを表す識別名です。私が業務で守っているルールは「動詞 + 目的語、ハイフン区切り、短く」です。

良い例悪い例理由
generate-testtest動詞がなく何をするか不明
review-prpr-review-helper-tool-v2長すぎ・冗長
format-meeting-notesmeeting名詞だけで動作が不明
compose-emailemail_skill_final末尾の _final _v2 は混乱の元

名前が長すぎたり名詞だけだったりすると、Claude が「いつ呼ぶか」を判定しにくくなります。動詞を頭に置くだけで発火率が上がる、というのが私の体感です。

description の設計：何をする + いつ呼ぶ + 何を入力する

description は、自作 Skill の出来を左右する最重要フィールドです。Claude はこの文章を読んで「今この Skill を呼ぶべきか」を判断するので、ここが曖昧だと、せっかく作った Skill が一度も呼ばれません。

私が守っている型は「何をする + いつ呼び出す + 何を入力する」の 3 点を盛り込むことです。良い例と悪い例を並べます。

# ❌ 悪い例：何をするかしか書いていない
description: "議事録を整形する"

# ❌ 悪い例：曖昧で、いつ呼ぶか判定できない
description: "ドキュメント関連の作業を手伝う"

# ✅ 良い例：何をする + いつ呼ぶ + 何を入力する
description: "会議の文字起こしやメモを、決定事項・アクション・課題の3軸に整形する。ユーザーが議事録の整形や会議メモのまとめを依頼したときに呼び出す。入力は会議の文字起こしテキストまたは手書きメモ。"

悪い例の「議事録を整形する」だと、Claude は「議事録という単語が出たときだけ」拾うかどうか、判定が不安定になります。良い例のように「いつ呼ぶか」を具体的に書くと、発火が安定します。

私が業務で description を書くときに意識しているのは、「読者（＝Claude）に、この Skill を呼ぶべき場面を、はっきり想像させる」ことです。営業時代、お客様に提案するときも、抽象的に「便利です」と言うより「こういう場面で、こう困っているなら、これが効きます」と具体的な場面を示したほうが、相手に伝わりました。description も同じで、「議事録の整形や会議メモのまとめを依頼したとき」のように、読み手が場面を思い浮かべられる粒度まで書くと、ぐっと安定します。

逆に、description に「ドキュメント」「作業」「サポート」のような広い言葉を多用すると、似たような Skill と判定が競合しやすくなります。後述する失敗パターンの「命名衝突・description の競合」にもつながるので、description は「広く拾おう」ではなく「狙った場面だけ拾おう」という方向で書くのがコツです。

本文（手順記述）の書き方

frontmatter の下、本文には「Claude にやらせたい手順」を書きます。私が意識しているのは次の 3 点です。

  • 出力フォーマットを明示する：「決定事項 / アクション / 課題 の 3 見出しで出力」のように、欲しい形を先に指定する
  • ステップを列挙する：番号付きで「①〜する ②〜する」と順を追って書く
  • 欠損時の扱いを書く：「アクションが見当たらない場合は『なし』と記載」のように、空のときの振る舞いも決めておく

粒度の原則：1 Skill = 1 タスク

自作で一番やりがちな失敗が「1 つの Skill に何でも詰め込む」ことです。私も最初は「ドキュメント全般を扱う万能 Skill」を作ろうとして、結局どの場面でも中途半端に発火する Skill になってしまいました。

原則は 1 Skill = 1 タスクです。「議事録整形」「メール作成」「提案書骨子」は、それぞれ別の Skill に分けるほうが、発火も安定し、後からの手入れもラクでした。

粒度の見極めに迷ったら、「この Skill を一言で説明できるか」を自分に問うのが分かりやすいです。「議事録を 3 軸に整形する Skill」のように一言で言えるなら、粒度は適切です。「ドキュメント関連を色々やる Skill」のように、説明が「色々」「など」で濁るなら、それは複数タスクが混ざっているサインでした。一言で言えるまで分割する、という基準が、私には一番使いやすかったです。

再利用性：汎用とプロジェクト固有を分ける

Skill の置き場所には、ざっくり 2 種類あります。

# 汎用 Skill（どのプロジェクトでも使う）→ ホームディレクトリ配下
~/.claude/skills/format-meeting-notes/SKILL.md

# プロジェクト固有 Skill（その案件専用）→ プロジェクトの .claude 配下
./.claude/skills/draft-proposal/SKILL.md

議事録整形のような「どの仕事でも使うもの」は汎用側、特定案件の独自フォーマットに依存するものはプロジェクト固有側、と分けておくと、使い回しがきいて整理もしやすくなります。

セキュリティの最低ライン

最後に、これだけは外せないという 3 つです。

  • 機密情報を SKILL.md に直書きしない（API キー・顧客名・社内コードを本文に書かない）
  • API キーは環境変数に逃がす（後述の セクション 13 で詳しく扱います）
  • scripts は実行前に人間がレビューする

ここまでを踏まえた、最小の SKILL.md フルサンプルを示します。これ 1 枚で、議事録整形 Skill が動きます。

---
name: format-meeting-notes
description: 会議の文字起こしやメモを、決定事項・アクション・課題の3軸に整形する。ユーザーが議事録の整形や会議メモのまとめを依頼したときに呼び出す。入力は会議の文字起こしテキストまたは手書きメモ。
---

# 議事録整形 Skill

渡された会議メモを、以下の3つの見出しに整理して出力してください。

## 出力フォーマット

### 決定事項
- （会議で決まったことを箇条書き）

### アクション
- （誰が・いつまでに・何を、の形で箇条書き。担当者が不明なら「担当未定」と記載）

### 課題・保留
- （持ち越しになった論点を箇条書き。なければ「なし」と記載）

## 手順

1. メモ全体を読み、決定・行動・保留の3種類に仕分けする
2. アクションは可能な限り「担当者 + 期限 + 内容」の形に整える
3. 重複する内容はまとめ、簡潔な日本語に整形する

04 — コード系 Skill を自作する：テスト生成・差分指摘・リファクタ

📖 この章で使う用語

  • ユニットテスト：関数 1 つを単独で動かして、期待どおり動くか確認するテストのこと。
  • 差分指摘（PR レビュー）：変更箇所（差分）にレビューコメントを付ける作業のこと。
  • リファクタリング：動きを変えずにコードを整理し直すこと。部屋の模様替えのイメージです。
  • scripts/：Skill が呼ぶ実行コードの置き場。bash / Python / TypeScript などを置きます。

ここからは、私が業務で実際に作って使っている 3 系統を、作り方を再現できる粒度で見ていきます。まずはコード系から。なお、AI を使ったコードレビューのツール全般については AI コードレビューの記事で扱っているので、本記事ではあくまで「Skill 化する」観点に絞ります。

テスト生成 Skill（generate-test）

対象のコードを渡すと、ユニットテストの雛形を作ってくれる Skill です。SKILL.md と、テスト雛形を持つ resources、補助的な scripts の 3 点で構成します。

---
name: generate-test
description: 関数やクラスのコードを渡すと、ユニットテストの雛形を生成する。ユーザーがテストの作成やテストケースの追加を依頼したときに呼び出す。入力は対象のソースコード。
---

# テスト生成 Skill

渡されたコードに対して、ユニットテストを生成してください。

## 手順
1. resources/test-template.py のテンプレート構造に合わせる
2. 正常系・異常系・境界値の3観点で最低1ケースずつ作る
3. テスト名は test_<対象>_<条件> の形にする

resources には、チームで揃えたいテストの書き方を雛形として置いておきます。

# resources/test-template.py
# 週次で増えるテストの「最小の一手」を揃えるための雛形
import pytest

def test_target_normal_case():
    # 正常系：期待どおりの入力
    pass

def test_target_boundary_case():
    # 境界値：ゼロ・空・上限など
    pass

def test_target_error_case():
    # 異常系：不正な入力で例外が出るか
    pass

差分指摘 Skill（review-pr）

変更差分を渡すと、レビュー観点に沿ってコメント候補を出してくれる Skill です。これは resources にレビュー観点のチェックリストを持たせるのがポイントでした。

---
name: review-pr
description: コードの変更差分を渡すと、レビュー観点に沿った指摘候補を出す。ユーザーがコードレビューやPRの確認を依頼したときに呼び出す。入力はdiffまたは変更後のコード。
---

# 差分レビュー Skill

resources/review-checklist.md の観点に沿って、変更差分をレビューしてください。
指摘は「観点 / 該当箇所 / 提案」の形で出してください。
<!-- resources/review-checklist.md -->
# レビュー観点チェックリスト
- 命名：意図が読み取れるか
- エラー処理：異常系が握りつぶされていないか
- テスト：変更に対応するテストがあるか
- セキュリティ：機密情報の直書き・未検証入力がないか
- 可読性：1 関数が長すぎないか

全社で AI 活用を進める立場として実感しているのは、レビュー観点を Skill の resources に書いて Git で共有すると、レビューの基準がチームで揃いやすいという点です。レビュアーによって指摘の粒度がバラついていた状態から、最低ラインが揃う方向に動いてくれました。

ここで一つ補足です。AI のレビューはあくまで「指摘候補」を出すものであって、最終的な判断は人間が行う、という前提は崩さないようにしています。Skill が出してきた指摘をそのまま採用するのではなく、「この指摘は妥当か」を人が確認した上でコメントする。この一手間を省かないことが、チームでの信頼を保つ上で大事でした。AI が便利になるほど、最後の確認を人がやる、という線引きはむしろ大切になると感じています。

リファクタ Skill（propose-refactor）

リファクタ案を提案させる Skill は、scripts なしで SKILL.md だけでも十分動きます。「動きを変えない」という制約を本文に明記しておくのがコツでした。

---
name: propose-refactor
description: コードを渡すと、動作を変えないリファクタ案を提案する。ユーザーがコードの整理・改善・リファクタを依頼したときに呼び出す。入力は対象のソースコード。
---

# リファクタ提案 Skill

外部から見た動作を変えずに、可読性・重複・命名の3点でリファクタ案を提案してください。
動作が変わる可能性のある変更は「要注意」と明記してください。

これらのコード系 Skill は Claude Code の .claude/skills/ 配下に置いて、Git でチームに配るのが私の運用です。AI コーディング全般の地図は AI コーディングの全体像をまとめた記事もあわせてどうぞ。

05 — ドキュメント系 Skill を自作する：Markdown 整形・docx・pdf

📖 この章で使う用語

  • python-docx：Python から Word（docx）ファイルを組み立てるライブラリです。
  • reportlab / weasyprint：Python から PDF を生成するライブラリです。
  • resources/：Skill が参照するテンプレ・サンプルの置き場（前章で登場済み）。

ドキュメント系は、出力フォーマットを揃えたいときに効きます。私が業務で作っているのは、Markdown 整形・自作 docx 生成・自作 pdf 生成の 3 つです。

Markdown 整形 Skill（format-markdown）

社内ドキュメントの体裁を揃える Skill です。これは scripts なし、SKILL.md だけで動きます。

---
name: format-markdown
description: 雑に書いたメモやテキストを、社内標準のMarkdown体裁に整える。ユーザーがドキュメントの整形・体裁調整を依頼したときに呼び出す。入力は整形前のテキスト。
---

# Markdown 整形 Skill

渡されたテキストを、見出しレベル統一・箇条書き整形・冗長表現の削減の3点で整えてください。
元の情報は落とさず、構造だけ整えるのが原則です。

自作 docx 生成 Skill

Word ファイルを生成する Skill は、scripts に python-docx を使った骨格を置きます。業務固有のテンプレ（ロゴ位置・見出しスタイルなど）は resources に持たせます。

# scripts/build_docx.py
# 社内テンプレに沿った docx を組み立てる最小の骨格
from docx import Document

def build_docx(title: str, body: str, out_path: str) -> None:
    doc = Document()  # テンプレを使うなら Document("resources/template.docx")
    doc.add_heading(title, level=1)
    for para in body.split("\n\n"):
        doc.add_paragraph(para)
    doc.save(out_path)

ここで立ち位置を正直にお伝えします。自作の docx / pdf 生成 Skill は私が業務で常用しているものなので、上記は自分の言葉で書いています。一方、Anthropic が公式に提供している pdf / docx / pptx 系の Skill については、私が業務で常用しているわけではないので、公式ドキュメントで確認した範囲での紹介にとどめます。

私の業務での配分感としては、**公式 Skill で 70%、自作で残り 30%**くらいの感覚です。汎用的な変換は公式に任せ、社内固有のテンプレ・命名規則・保存先のルールといった「うちの会社ならでは」の部分を自作で埋める、という分担に落ち着いています。

具体的にどこを自作で埋めるかというと、たとえば「生成した docx を、社内の決まったフォルダ構成で保存する」「ファイル名を 提案書_顧客名_日付 の規則で付ける」「表紙に社内標準の見出しスタイルを当てる」といった、いわば「会社の作法」の部分です。こうした作法は、世の中の公式 Skill が知るはずもないので、自作の resources や scripts で吸収するしかありません。逆に「Markdown を docx に変換する」という変換の本体は、公式が提供しているなら、わざわざ自作する必要はないと考えています。この「変換の本体は公式、会社の作法は自作」という分け方は、私の中ではかなりはっきりした基準になっています。

自作 pdf 生成 Skill

PDF も同様に、reportlab や weasyprint を使った scripts を置く形です。

# scripts/build_pdf.py
# weasyprint で HTML から PDF を起こす最小の骨格
from weasyprint import HTML

def build_pdf(html_str: str, out_path: str) -> None:
    HTML(string=html_str).write_pdf(out_path)

06 — 業務テンプレ系 Skill を自作する：メール・議事録・提案書

📖 この章で使う用語

  • テンプレ（ひな型）：差し込み項目を空けておいた、定型文書の骨組みのこと。
  • 差し込み：ひな型の空欄に、その時のデータ（取引先名・金額など）を入れることです。

業務テンプレ系は、SKILL.md + resources だけで動く（scripts なし）パターンが多いのが特徴です。コードを書かずに作れるので、最初の自作 Skill としても入りやすいと思います。

メールテンプレ Skill（compose-email）

用途別のメールひな型を resources に持たせ、状況に応じて差し込みさせる Skill です。

---
name: compose-email
description: 用途を指定すると、社内標準のトーンでメール下書きを作る。ユーザーがメールの作成・下書き・返信案を依頼したときに呼び出す。入力は用途と要件。
---

# メール作成 Skill

resources/email-templates/ のひな型から、用途に合うものを選んで下書きを作ってください。
件名・宛名・本文・結びの4ブロックで出力してください。

resources のフォルダ構成はこんな形です。

compose-email/
├── SKILL.md
└── resources/
    └── email-templates/
        ├── apology.md       # お詫び
        ├── follow-up.md     # フォローアップ
        └── proposal.md      # 提案案内

議事録テンプレ Skill（format-meeting-notes）

セクション 3 で最小サンプルを示したものの、resources を足した実運用版です。3 軸（決定 / アクション / 課題）のテンプレを resources に外出しして、Skill 本体から参照させます。議事録ツール全般の話は AI 議事録のおすすめをまとめた記事もどうぞ。

提案書テンプレ Skill（draft-proposal）

これは私にとって思い入れのある Skill です。営業時代、提案書はゼロから組むと 2 時間ほどかかっていました。お客様の課題を整理し、章立てを考え、各章の要点を書き、体裁を整える——この一連の流れが、毎回ほぼ同じなのに、毎回ゼロからやっていたのです。骨格生成を Skill 化してからは、課題と要件を渡して呼び出し、出てきた骨格を調整するだけで、30 分前後に収まるようになりました。

---
name: draft-proposal
description: 顧客の課題と要件を渡すと、提案書の骨格を生成する。ユーザーが提案書・営業資料の作成を依頼したときに呼び出す。入力は顧客の課題・予算感・要件。
---

# 提案書骨格 Skill

resources/proposal-skeleton.md の章立てに沿って、提案書の骨格を作ってください。
各章は見出しと2〜3行の要点だけにとどめ、詳細は人が肉付けする前提です。

営業時代の私が「自分専用の対応手順書」を書いていたように、業務テンプレ系の Skill は、自分の頭の中の段取りを AI 向けに書き起こす作業に近いと感じます。

07 — Claude.ai と Claude Code で自作 Skill の挙動はどう違うか

📖 この章で使う用語

  • Claude.ai：Anthropic 公式の Web / デスクトップのチャットアプリ。GUI で Skill を管理します。
  • Claude Code：Claude を CLI（コマンドライン）から呼ぶ公式ツール。ファイルで Skill を管理します。
  • CLAUDE.md：Claude Code がプロジェクトのルートで読み込む、指示書ファイルのこと。
  • GUI：マウスでクリックして操作する画面のことです。

自作した Skill を「どちらに置くか」で、運用が変わります。一行で言えば、個人ワークフローは Claude.ai、チーム共有は Claude Code のリポジトリ配下です。

両者の違いを表に整理します。

観点Claude.aiClaude Code
管理場所GUI 上で Skill を管理.claude/skills/<name>/SKILL.md をファイルで管理
共有方法個人 or プロジェクト機能単位Git でリポジトリごと共有
向いている用途個人の日常ワークフローチームで基準を揃える運用
連携プロジェクト機能と組み合わせCLAUDE.md との連携

私の場合、自分だけが使う議事録整形のようなものは Claude.ai 側、チーム全員に同じ基準で使ってほしいコードレビュー系は Claude Code のリポジトリ配下、と置き分けています。Claude Code の環境構築そのものは Claude Code のはじめ方を別記事でまとめています。Claude プロダクト全体の話は Claude の使い方の記事もどうぞ。

08 — MCP との違いと併用判断：自作するなら Skill か MCP か

📖 この章で使う用語

  • MCP（Model Context Protocol／モデル・コンテキスト・プロトコル）：外部のリソースやデータソースへつなぐための統一規格。家電の「共通コンセント規格」のイメージです。
  • MCP サーバー：社内 API や自社 DB などを、MCP 経由で扱えるようにする仲介プログラムのことです。

「自作するとき、Skill にすべきか MCP にすべきか」は、よく迷うポイントです。役割の違いを押さえると判断しやすくなります。

ざっくり言うと、MCP は外部からデータを引く仕組み、Skill は引いた後の業務処理をパッケージ化する仕組みです。たとえば「社内 DB から先月の売上を取ってくる」のは MCP の領分、「取ってきた売上データを月次レポートの形に整える」のが Skill の領分、というイメージです。

自作するときの選定軸は次のとおりです。

  • 社内 API や自社 DB に接続したい → MCP サーバーを自作する
  • 業務手順を覚えさせたい → Skill を自作する

私は Cursor から MCP を使う側としても、社内 API・自社 DB を MCP サーバー化して本番運用する側としても、業務で常用しています。その経験から言うと、両者は競合するものではなく、組み合わせて使うものです。MCP で外部とつなぎ、Skill でその後の処理を定型化する、という分担が自然でした。

もう少し具体的に、判断に迷ったときの考え方を共有します。私は「データの出どころが外部にあるかどうか」で切り分けています。社内 DB・社内 API・外部サービスなど、Claude の外側にあるデータを取りに行く必要があるなら、その部分は MCP の仕事です。一方、取ってきたデータをどう加工するか、どう整形して出力するか、という「処理の段取り」は Skill の仕事です。最初に MCP でデータの蛇口を用意し、その先の業務処理を Skill で型にする——この順で考えると、どちらで作るべきか迷わなくなりました。MCP 自体の深掘りは AIエージェント MCP の記事にまとめてあります。

09 — Slash commands / Tools との使い分け：自作するとき、どの形で作るべきか

📖 この章で使う用語

  • Slash commands（スラッシュコマンド）：Claude Code の /command 型コマンド。ユーザーが手で打ち込んで呼び出します。.claude/commands/ に配置します。
  • Tools / Function Calling（関数呼び出し）：Claude の API リクエストに関数定義を渡し、必要なときに呼ばせる、API レベルの仕組みです。

Skill・Slash commands・Tools は似ていて混同しやすいので、「自作するときどれを選ぶか」の選定軸に絞って整理します。

一行マップはこうです。

  • 業務手順を覚えさせて自動で発火させたい → Skill
  • 特定のタイミングで手動で呼びたい → Slash command
  • プログラムに組み込んで呼ばせたい → Tools（Function Calling）

一番の違いは「誰が呼び出すか」です。Skill は Claude が description を読んで自動判断で呼び出す。Slash command はユーザーが /command で明示的に呼び出す。Tools はプログラム側から API リクエストで呼ばせる、という棲み分けです。

同じワークフローを Skill と Slash command の両方で持つこともできますが、私の感覚では、まず Skill で自動発火を試し、「狙った場面以外で発火してしまう」「逆に呼ばれない」など制御したくなったら、Slash command で手動呼び出しに切り替える、という順が扱いやすいです。CI/CD と組み合わせたい場合は Claude Code Action の記事もあわせてどうぞ。

10 — チームへの展開：社内配布・Git 管理・バージョニング・レビュー運用

📖 この章で使う用語

  • Git 管理：ファイルの変更履歴を記録し、チームで共有する仕組みのことです。
  • バージョニング：Skill の版を管理し、更新を追えるようにすることです。
  • clone（クローン）：GitHub のリポジトリを、自分の PC にコピーすることです。

ここは親記事ではあまり触れていない、本記事の独自テーマです。自作 Skill は、チームに配って初めて本当の効果が出ます。

.claude/skills/ を Git 管理に入れる

Claude Code なら、.claude/skills/ をリポジトリの Git 管理に入れておくだけで、リポジトリを clone した全員が同じ Skill セットを使えるようになります。

# Skill をリポジトリに追加してチームに配る
git add .claude/skills/
git commit -m "feat: 議事録整形・差分レビュー Skill を追加"
git push
# → clone した全員の Claude Code で同じ Skill が使える

バージョニングと更新の伝え方

Skill を更新したときは、チームへの周知が要ります。私が意識しているのは、SKILL.md の本文末尾に簡単な変更履歴を残しておくことと、コミットメッセージで「何が変わったか」を伝えることです。description を変えたときは特に、発火条件が変わるので、チームに一言伝えるようにしています。

チーム導入のステップ

全社で AI 活用を進めてきた経験から、Skill のチーム導入は段階を踏むのが結局スムーズでした。

  1. 1 人が試作する（まず自分の業務で 1 週間使ってみる）
  2. 小チームで検証する（数人に使ってもらい、発火やズレを直す）
  3. リポジトリに正式投入する（.claude/skills/ に入れて全員へ）
  4. CLAUDE.md で発火を明示する（「この場面ではこの Skill を使う」と書いておく）

レビュー運用

Skill 自体も、コードと同じように PR レビューの対象にするのが安全です。特に scripts を含む Skill は、実行内容の安全性チェックと、機密情報が混ざっていないかの確認を、レビューの観点に入れておくと安心でした。

全社推進をやってみて実感したのは、ツールを配るだけでなく「Skill を共有する文化」を作ることが大事だ、ということです。誰かが作った便利な Skill が、チーム全体に行き渡る流れができると、効果が一気に広がりました。

逆に言うと、配って終わりにしてしまうと、せっかくの Skill が一部の人だけのものになって埋もれてしまいます。私が意識しているのは、Skill を作った人に「どんな場面で使えるか」を一言添えてもらうこと、そしてリポジトリに Skill の一覧をまとめておくことです。営業時代、よく売れる商品の話を朝礼で共有すると、チーム全体の数字が底上げされたのと似ていて、「この Skill が便利だった」という情報が回る仕組みがあると、自然と使われる Skill が増えていきました。地味ですが、この共有の流れを作ることが、ツールそのものの良し悪しと同じくらい効きました。

11 — 自作で陥りやすい失敗パターン 5 個

📖 この章で使う用語

  • 競合（competing）：似た description の Skill が複数あり、Claude がどれを呼ぶか判定に迷う状態のことです。
  • 車輪の再発明：すでにあるもの（公式 Skill など）を知らずに、自分で同じものを作り直してしまうことです。

正直に言うと、私自身、最初の Skill では以下の 5 つを少しずつやらかしました。同じところで止まらずに済むよう、対処とセットで共有します。

失敗① 粒度が大きすぎる 1 つの Skill に複数タスクを詰め込むと、どの場面でも中途半端に発火し、結局使われなくなります。対処は、タスク単位で分割することです。「ドキュメント全般」ではなく「議事録整形」「Markdown 整形」と分ける、という具合です。

失敗② 再利用性ゼロ 特定の案件専用に書きすぎて、別の仕事では使えない Skill になってしまうパターンです。対処は、汎用部分とプロジェクト固有部分を分けること。汎用は ~/.claude/skills/、固有は ./.claude/skills/ に置き分けます（セクション 3 参照）。

失敗③ 命名衝突・description の競合 似た description の Skill が複数あると、Claude の判定が分散して、狙った Skill が呼ばれなくなります。対処は、命名を明確にし、役割が重なる古い Skill は思い切って削除することです。

失敗④ セキュリティ漏れ 機密情報を SKILL.md に直書きしたり、scripts を無レビューで配ったりするのは危険です。対処は、機密情報を環境変数に逃がすことと、scripts を必ず人間がレビューすることです（詳しくは セクション 13）。

失敗⑤ 公式 Skill との重複（車輪の再発明） Anthropic 公式の Skill があるのに、それを知らずに自作してしまうケースです。私自身、pdf を扱う Skill を一から作りかけて、後から公式に同等のものがあると気づいて作業が無駄になった経験があります。対処は、作り始める前に、公式提供 Skill や anthropics/skills の GitHub リポジトリ に同等のものがないかを一度確認してから、自作するか判断することです。確認に 10 分かければ、半日の作り直しを防げることもあります。

この 5 つを振り返って思うのは、失敗の多くは「最初に大きく作りすぎたこと」と「最初に確認を省いたこと」に集約される、ということです。小さく作る・先に公式を確認する・機密と動作を疑う——この 3 つを意識するだけで、私が経験した失敗のほとんどは避けられたはずでした。

なお、「これさえ守れば絶対に失敗しない」と言い切るつもりはありません。環境や運用で躓きどころは変わるので、上記はあくまで私がよく見かける典型例、という前提で受け取っていただければと思います。

12 — 自作 Skill を、エンジニアでない人がどう活かせるか

📖 この章で使う用語

  • Before / After：いま手作業でやっていることが、Skill 化で何に変わるか、という対比です。
  • 初期構築時間 / 運用時間：Skill を最初に作る時間と、作った後に 1 回呼び出すときの時間のことです。
  • 最初の壁：未経験の方が最初につまずきやすい、具体的なポイントのことです。

自作 Skill は、エンジニア専用のものではありません。業務テンプレ系・ドキュメント系の Skill は、SKILL.md と resources だけで作れるので、コードを書けなくても十分作れます。職種別に、考えられる使い方を 5 つ挙げます（あくまで「こういう使い方が考えられます」という条件付きの提案です）。

1. 営業：顧客別の提案書生成 Skill（draft-proposal） Before：提案書をゼロから組むのに 2 時間ほどかかる。 After：課題と要件を渡すと骨格が出てきて、調整して 30 分前後に。 初期構築：SKILL.md + 章立てテンプレで 30 分ほど。運用：1 回 5 分程度。 最初の壁：章立てテンプレを resources に切り出す作業に慣れること。

2. 事務：議事録整形 Skill（format-meeting-notes） Before：会議メモを手で「決定 / アクション / 課題」に整理して 20 分。 After：メモを渡すと 3 軸に整形され、確認・微修正だけで済む。 初期構築：SKILL.md 1 枚で 15 分ほど。運用：1 回 3 分程度。 最初の壁：出力フォーマットを言葉で具体的に指定すること。

3. 個人事業主：請求書テンプレ Skill Before：請求書の文面を毎回コピペして金額や宛名を直す。 After：取引先と金額を渡すと、定型文面が差し込み済みで出てくる。 初期構築：SKILL.md + ひな型で 20 分ほど。運用：1 回 2 分程度。 最初の壁：機密情報（取引先情報）を直書きしない設計に気をつけること。

4. 副業ライター：見出し設計 Skill Before：記事の見出し構成を毎回ゼロから考える。 After：テーマを渡すと、見出し候補が型に沿って出てくる。 初期構築：SKILL.md 1 枚で 15 分ほど。運用：1 回 3 分程度。 最初の壁：自分の「良い見出しの型」を言語化して本文に書くこと。

5. エンジニア志望（未経験）：学習目的でテスト生成 Skill を自作する Before：テストの書き方が分からず、写経で止まってしまう。 After：自分でテスト生成 Skill を作る過程そのものが、SKILL.md・scripts の学習になる。 初期構築：SKILL.md + 雛形で 1 時間ほど。運用：作ること自体が教材。 最初の壁：scripts を書く段階でプログラミングが必要になること。

未経験から学習を始める方は、生成AIの全体像から押さえると遠回りになりにくいです。生成AI 入門の記事に学習の全体像をまとめています。なお「営業の方なら誰でも生産性が上がります」のような言い方をするつもりはありません。効果は業務内容や使い方で変わるので、まずは小さく 1 つ作って試してみる、くらいの距離感がちょうどいいと思います。

13 — YMYL 警戒：機密情報・送信前提・商用利用・scripts レビュー

📖 この章で使う用語

  • ガバナンス：組織として「どこに何を出してよいか」を統制するルールのこと。情シス・コンプラ部門の管轄です。
  • 送信前提：Claude を使うとき、入力した内容が Anthropic のサーバに送信される、という前提のことです。
  • .gitignore：Git の管理対象から外すファイルを指定する設定ファイル。機密ファイルの除外に使います。

自作 Skill には、使う側にはない固有のリスクがあります。ここは慎重に押さえておきたいところです。

機密情報を Skill に埋めない

API キー・個人情報・顧客リスト・社内コードなどは、SKILL.md や scripts に直書きしないのが大原則です。私が業務で守っている 3 段構えを共有します。

# ① API キーは環境変数に逃がす
export ANTHROPIC_API_KEY="...(直書きしない)"

# ② 機密ファイルは Skill の外に置き、参照だけする
#    （SKILL.md に値を書かず、外部ファイルのパスだけ持つ）

# ③ .gitignore で機密ファイルを Git 管理から外す
echo "secrets/" >> .gitignore
echo ".env" >> .gitignore

Anthropic への送信前提を理解する

Skill 経由であっても、入力内容は Anthropic のサーバへ送信されます。これは仕組み上避けられません。どうしても外部に出せないデータを扱う必要がある場合は、完全にローカルで動かす選択肢として ローカル LLM の記事も参考になると思います。

商用利用条件は公式で必ず確認する

「絶対この条件で使える」とは申し上げません。商用利用の可否や範囲は、プランや時期によって変わります。最新は Anthropic 公式で確認するのが筋です。料金プランの整理は Claude 料金プランの記事にまとめてあります。

scripts の実行内容は必ず人間がレビューする

scripts を含む Skill は、実行内容を必ず人間が確認してから配ります。特にチームに配布する scripts は、外部に通信しないか・機密を扱っていないかを、レビューの観点に必ず入れておきます。

最後に、メタな注意を 3 つ。これらの判断について「絶対安全」とは申し上げません。最終判断は社内の情シス・コンプラ部門・法務にご確認ください。そして、効果や運用の最適解は個人差・組織方針で振れます、という前提も添えておきます。

訂正について

本記事の内容に誤りや古い情報を見つけられた場合は、お問い合わせフォーム、または send@bon-bon-tools.com までお知らせいただけると助かります。気づいた点は随時反映していきます。

14 — よくある質問（FAQ）

Q1: Claude Skills を自作するのに、プログラミングは必須ですか？

A. 「絶対必要」とは申し上げません。最小構成（SKILL.md だけ）なら、Markdown が書ければ作れます。scripts/ で実行コードを組む段階に進むとプログラミングが必要になりますが、業務テンプレ系・ドキュメント系は SKILL.md + resources だけで動くものも多いです。私の業務でも、コードなしで動かしている Skill が複数あります。

Q2: 自作した Skill が Claude に呼び出されないのはなぜですか？

A. 典型的な 3 原因があります。①description が曖昧、②name が長い・曖昧、③似た Skill と競合している、です。まずは description を「何をする + いつ呼ぶ + 何を入力する」の 3 点で書き直して再テストするのが筋です。詳しくは セクション 3 を参照してください。

Q3: 自作 Skill はチームでどう共有しますか？

A. Claude Code なら .claude/skills/ を Git 管理に入れ、リポジトリを clone した全員が同じ Skill セットを使えます。Claude.ai は個人またはプロジェクト機能単位での共有になります。導入のステップは セクション 10 にまとめています。

Q4: Anthropic 公式の Skill があるのに、自作する意味はありますか？

A. 私の業務感覚では、公式 Skill で 70%、社内固有の要件（独自テンプレ・命名規則・データソース連携）は自作で残り 30% を埋める、という配分が現実的です。まず公式に同等のものがないか確認してから自作を判断すると、車輪の再発明を防げます。

Q5: 自作 Skill に機密情報を含めても大丈夫ですか？

A. 「絶対大丈夫」とは申し上げません。API キー・個人情報・顧客リストは直書きせず、環境変数 + 外部ファイル + .gitignore の 3 段構えが最低条件です。最終判断は社内の情シス・コンプラ部門・法務にご確認ください。詳しくは セクション 13 を参照してください。

関連記事

出典

新しい記事のお知らせを受け取る → 登録（準備中）