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」を作りたい方は、結論とSKILL.md の書き方から読み始めると、本日中に最初の SKILL.md が動きます。なお全体像や「使う側」の話は Claude Skills の使い方の記事にまとめています。本記事は終始「作る側」に視点を固定します。

結論と自作の考え方｜SKILL.md にパッケージ化する・1 Skill = 1 タスク

📖 用語：Claude Skills＝Claude（Claude.ai / Claude Code）に「機能・指示・ファイル」をパッケージ化して渡せる仕組み（2025 年 10 月に Anthropic が公式発表）。自作 Skill＝既存を入れるのでなく自分で SKILL.md を書いて作る Skill。SKILL.md＝呼び出し条件と手順を書く Markdown ファイルで、Skill の心臓部。

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

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

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

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

本記事の立ち位置を正直にお伝えします。私が業務で実際に作って毎日使っているのは、コード系・ドキュメント系・業務テンプレ系の 3 系統で、Claude.ai と Claude Code の両方に置いています。この範囲は自分の言葉で書きます。一方、Anthropic 公式提供の Skill（pdf / docx / pptx など）の細部や最新仕様は、常用しているわけではないので公式ドキュメントで確認した範囲を出典付きで整理します。

Claude Skills は 2025 年 10 月リリースの新しい機能で、UI や仕様の変化が早い領域です。本記事の手順やフィールド名は執筆時点（2026 年 6 月）の整理であり、最新の正確な仕様は必ず Anthropic 公式ドキュメント（取得：2026-06-02）でご確認ください。挙動は環境で振れるので、「私の業務での作り方の型」をベースにした再現手順として読んでください。

いつ「作る側」に踏み込むか：定型作業を見つける

「使う側」と「作る側」の境界線は「SKILL.md を自分で書くかどうか」です。私の判断基準はシンプルで、「毎週 3 回以上やる定型作業」が最初の候補です。議事録の整形は毎日のように発生していたので、最初に Skill 化したもののひとつでした。逆に、月 1 回あるかどうかの作業を Skill にするのは手間に見合いません。

候補を見つける目印は次の 3 つで、どれかに当てはまれば有力候補です。頻度が高く・手順が決まっていて・毎回ほぼ同じ指示を出している作業ほど、Skill 化の効果が大きかったです。

• 同じプロンプトを毎回コピペしている
• 出力の形を毎回同じように指示し直している
• 決まった参照ファイルを毎回貼り付けている

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

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

心構えは「最初から完璧を狙わない」ことです。私の最初の Skill は SKILL.md 1 枚だけの素朴なもので、1 週間使って「指示が足りない」「この場面で呼ばれない」と気づくたびに手を入れました。いきなり作り込むより、小さく作って育てるほうが、実際に使われる Skill になりました。

なお「作る側はコードが書けないと無理では」と身構える必要はありません。業務テンプレ系・ドキュメント系は SKILL.md と参照ファイルだけで作れます。コードが要るのは scripts/ で実行コードを組む段階だけで、最初の一歩は Markdown が書ければ十分です。

SKILL.md の書き方｜frontmatter と description 設計・1 Skill = 1 タスク・セキュリティ

📖 用語：frontmatter＝先頭を --- で囲んだ設定ブロックで name・description を書く。description＝Claude が「いつ呼ぶか」を判断する文章で、曖昧だと拾われない。粒度＝1 Skill がカバーする範囲（1 Skill = 1 タスクに揃える）。環境変数＝API キーなどをコードの外側に持たせる仕組み。

ここが本記事の心臓部です。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-test：test より、動作が分かります。
• review-pr：pr-review-helper-tool-v2 のような長い名前を避けます。
• format-meeting-notes：meeting のような名詞だけにしません。
• compose-email：email_skill_final のような版番号を名前に混ぜません。

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

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

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

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

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

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

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

悪い例の「議事録を整形する」だと、Claude が「議事録という単語が出たときだけ」拾うかどうか不安定になります。良い例のように「いつ呼ぶか」を具体的に書くと発火が安定します。意識すべきは「Claude にこの Skill を呼ぶべき場面をはっきり想像させる」ことで、「議事録の整形や会議メモのまとめを依頼したとき」のように場面を思い浮かべられる粒度まで書くのがコツです。

逆に「ドキュメント」「作業」「サポート」のような広い言葉を多用すると、似た Skill と判定が競合します。後述の「命名衝突・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 キーは環境変数に逃がす（機密情報の扱いで詳しく扱います）
• scripts は実行前に人間がレビューする

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

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

# 議事録整形 Skill

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

## 出力フォーマット

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

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

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

## 手順

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

自作 Skill の応用｜創作技法・コード・ドキュメント・業務テンプレ

📖 用語：ユニットテスト＝関数 1 つを単独で動かし期待どおりか確認するテスト。差分指摘（PR レビュー）＝変更箇所にレビューコメントを付ける作業。リファクタリング＝動きを変えずコードを整理し直すこと。scripts/＝Skill が呼ぶ実行コードの置き場。

ここまでの型は、自分で書けば追加費用なしで使えます。そのうえで、同じ視点・構成技法・確認手順を長編で繰り返すなら、創作用 Skill への応用が分かりやすい題材です。実運用中の SKILL.md と、技法書から Skill に落とす工程を見たい方向けの ¥980 ガイドは、第1章まで note で無料試し読みできます（価格・内容の最新情報は note でご確認ください）。

以下では、私が業務で使うコード系・ドキュメント系・業務テンプレ系の実物を見ていきます。創作用も仕組みは同じで、特定作家の文体コピーではなく、構成や描写など技法の型を手順へ落とします。

コード系①：テスト生成 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 関数が長すぎないか

レビュー観点を resources に書いて Git で共有すると、レビュアーによる指摘の粒度のバラつきが減り、チームで最低ラインが揃いました。ただし AI のレビューは「指摘候補」であり、最終判断は人間が行う前提は崩しません。「この指摘は妥当か」を人が確認してからコメントする一手間が、チームでの信頼を保つ上で大事でした。

コード系③：リファクタ Skill（propose-refactor）

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

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

# リファクタ提案 Skill

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

これらのコード系 Skill は Claude Code の .claude/skills/ 配下に置き、Git でチームに配るのが私の運用です。AI コーディング全般は AI コーディングの全体像の記事もどうぞ。

ドキュメント系：Markdown 整形・docx・pdf（python-docx / weasyprint）

ドキュメント系は出力フォーマットを揃えたいときに効きます。私が業務で作っているのは、Markdown 整形・自作 docx 生成・自作 pdf 生成の 3 つです（python-docx＝Python から Word を組み立てるライブラリ、reportlab / weasyprint＝Python から PDF を生成するライブラリ）。

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 生成は業務で常用しているので自分の言葉で書いています。一方、公式提供の pdf / docx / pptx 系は常用していないので公式ドキュメントで確認した範囲の紹介にとどめます。配分感は 公式 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)

業務テンプレ系：メール・議事録・提案書（scripts なしで作れる）

業務テンプレ系は 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）

SKILL.md の書き方で示した最小サンプルに 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 向けに書き起こす作業に近いと感じます。

配置と使い分け｜Claude.ai vs Claude Code・MCP / Slash との切り分け・チーム展開

📖 用語：Claude.ai＝GUI で Skill を管理する Web / デスクトップアプリ。Claude Code＝CLI からファイルで Skill を管理する公式ツール。CLAUDE.md＝Claude Code がプロジェクトルートで読み込む指示書ファイル。

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

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

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

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

Skill か MCP か：外部からデータを引くなら MCP

「Skill にすべきか MCP にすべきか」はよく迷うポイントです。ざっくり、MCP は外部からデータを引く仕組み、Skill は引いた後の業務処理をパッケージ化する仕組みです（MCP＝外部リソースへつなぐ統一規格、MCP サーバー＝社内 API や自社 DB を MCP 経由で扱えるようにする仲介プログラム）。「社内 DB から先月の売上を取る」のは MCP、「取ってきた売上を月次レポートに整える」のが Skill の領分です。

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

私は Cursor から MCP を使う側としても、社内 API・自社 DB を MCP サーバー化して本番運用する側としても常用しています。両者は競合せず、組み合わせて使うものです。切り分けの基準は「データの出どころが外部にあるか」。Claude の外側にあるデータを取りに行くなら MCP、取ってきたデータの加工・整形という「処理の段取り」は Skill。最初に MCP でデータの蛇口を用意し、その先を Skill で型にする、と考えると迷いません。MCP の深掘りは AIエージェント MCP の記事にまとめてあります。

Skill か Slash command か Tools か：違いは「誰が呼ぶか」

Skill・Slash commands・Tools は混同しやすいので、選定軸に絞って整理します（Slash commands＝ユーザーが手で打つ /command 型コマンド、Tools / Function Calling＝API リクエストに関数定義を渡して呼ばせる API レベルの仕組み）。

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

一番の違いは「誰が呼び出すか」です。Skill は Claude が description を読んで自動判断、Slash command はユーザーが /command で明示的に、Tools はプログラム側から API リクエストで呼びます。まず Skill で自動発火を試し、「狙った場面以外で発火する」「逆に呼ばれない」と制御したくなったら Slash command で手動呼び出しに切り替える、という順が扱いやすいです。CI/CD と組み合わせる場合は Claude Code Action の記事もどうぞ。

チームへの展開：Git 管理・バージョニング・レビュー運用

親記事ではあまり触れていない独自テーマです。自作 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 を変えたときは発火条件が変わるので、チームに一言伝えるようにしています。

チーム導入のステップ

チーム導入は段階を踏むのが結局スムーズでした。

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

レビュー運用

Skill 自体もコードと同じく PR レビューの対象にすると安全です。特に scripts を含む Skill は、実行内容の安全性と機密情報の混入を、レビューの観点に入れておくと安心でした。

実感したのは、ツールを配るだけでなく「Skill を共有する文化」を作ることが大事だという点です。配って終わりにすると一部の人だけのものになって埋もれます。作った人に「どんな場面で使えるか」を一言添えてもらい、リポジトリに Skill の一覧をまとめておく。この共有の流れを作ることが、ツールの良し悪しと同じくらい効きました。

失敗・活用・注意点｜陥りやすい 5 失敗・職種別の使い道・YMYL の押さえどころ

📖 用語：競合＝似た description の Skill が複数あり Claude がどれを呼ぶか迷う状態。車輪の再発明＝公式 Skill などの存在を知らず同じものを作り直すこと。

私自身、最初の Skill では以下の 5 つを少しずつやらかしました。対処とセットで共有します。

• ① 粒度が大きすぎる：複数タスクを詰め込むと中途半端に発火する。→ タスク単位で分割（「ドキュメント全般」でなく「議事録整形」「Markdown 整形」）。
• ② 再利用性ゼロ：特定案件専用に書きすぎる。→ 汎用は ~/.claude/skills/、固有は ./.claude/skills/ に置き分ける（SKILL.md の書き方参照）。
• ③ 命名衝突・description の競合：判定が分散して狙った Skill が呼ばれない。→ 命名を明確にし、役割が重なる古い Skill は削除する。
• ④ セキュリティ漏れ：機密の直書き・無レビュー配布。→ 機密は環境変数に逃がし、scripts は必ず人間がレビューする（機密情報の扱い）。
• ⑤ 公式 Skill との重複：公式があるのに自作してしまう。私も pdf Skill を一から作りかけて無駄にしました。→ 作る前に anthropics/skills の GitHub リポジトリに同等品がないか確認する。10 分の確認が半日の作り直しを防ぎます。

失敗の多くは「最初に大きく作りすぎた」「最初に確認を省いた」に集約されます。小さく作る・先に公式を確認する・機密と動作を疑う——この 3 つで私の失敗のほとんどは避けられたはずでした。とはいえ躓きどころは環境で変わるので、典型例という前提で受け取ってください。

エンジニアでない人がどう活かすか（職種別 5 例）

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

職種	Skill	Before → After	初期構築 / 運用	最初の壁
営業	提案書生成（draft-proposal）	ゼロから 2 時間 → 骨格を調整し 30 分前後	30 分 / 1 回 5 分	章立てテンプレを resources に切り出す
事務	議事録整形（format-meeting-notes）	手で 3 軸に整理 20 分 → 確認・微修正だけ	15 分 / 1 回 3 分	出力フォーマットを言葉で具体的に指定する
個人事業主	請求書テンプレ	文面を毎回コピペして直す → 差し込み済みで出力	20 分 / 1 回 2 分	取引先情報を直書きしない設計
副業ライター	見出し設計	構成を毎回ゼロから → 型に沿った見出し候補	15 分 / 1 回 3 分	「良い見出しの型」を言語化する
エンジニア志望（未経験）	テスト生成（学習目的）	写経で止まる → 作る過程が SKILL.md・scripts の学習に	1 時間 / 作ること自体が教材	scripts を書く段階でプログラミングが要る

未経験から学ぶ方は、生成AIの全体像から押さえると遠回りになりにくいです。生成AI 入門の記事に学習の全体像をまとめています。効果は業務内容や使い方で変わるので、まずは小さく 1 つ作って試す距離感がちょうどいいです。

YMYL の押さえどころ：機密情報・送信前提・商用利用・scripts レビュー

自作 Skill には、使う側にはない固有のリスクがあります（送信前提＝入力内容が Anthropic のサーバに送信されること、.gitignore＝Git 管理対象から外すファイルを指定する設定）。ここは慎重に押さえます。

機密情報を 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 は、外部に通信しないか・機密を扱っていないかをレビューの観点に必ず入れます。これらの判断について「絶対安全」とは申し上げません。最終判断は社内の情シス・コンプラ部門・法務にご確認ください。効果や運用の最適解も個人差・組織方針で振れます。

訂正について

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

よくある質問（FAQ）

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

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

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

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

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

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

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

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

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

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

---

関連記事

• AI 動画生成 自動化——Claude Code 7 サブエージェントで作った動画自動生成パイプラインの実装体験
• Vibe coding とは——感覚で AI に書かせ、人間はレビューと方向づけに回る新スタイルを業務実践視点で整理
• Claude Agent SDK とは（Claude Code の中身をアプリに組み込む）
• MCP サーバー 作り方——Python/TypeScript SDK で自作し本番運用まで「作る側」の完全マニュアル
• Claude Skills の使い方（親ハブ・全体像と使う側）
• Claude Code の使い方（CLI 上での Skill 配置）
• Claude 使い方（プロダクト全体の整理）
• Claude Code はじめ方（初回 30 分の環境構築）
• AI コーディングの全体像
• Claude Cowork 使い方（デスクトップ・エージェント）
• AIエージェント MCP（外部接続のもう一本の層）

---

出典

• Agent Skills overview｜Anthropic Docs（取得：2026-06-02）
• anthropics/skills｜GitHub（取得：2026-06-02）
• Introducing Agent Skills｜Anthropic（取得：2026-06-02）
• ラッコキーワード実測（親 KW「Claude Skills」月 8,100 件・SEO 35・+788%、2026-05-20 取得）