Claude Skills の使い方｜自作3系統で業務常用、MCP/Slash との違いも整理

Q: Claude Skills の使い方を最短で知るには、どこから読めばいいですか？

使い方の最短ルートは「①何ができるか → ②既存 Skill を入れて動かす → ③自作する」の順です。本記事なら、まず [セクション 3](#sec-3)「できること 5 つ」で用途を掴み、[セクション 5](#sec-5)「入手経路」で anthropics/skills GitHub リポや公式 Skill を導入して 1 つ動かし、慣れてから [セクション 7](#sec-7)「自作手順」で SKILL.md を書く、という流れが私の業務での立ち上げ方に近いです。Claude.ai と Claude Code で動作が少し違う点は [セクション 4](#sec-4) を先に押さえておくと迷いません。

Q: Claude Skills は無料プランでも使えますか？

「絶対使える」とは申し上げません。2026年5月時点では、Claude Skills は Pro / Max プランで利用可能と公式で案内されており、Team / Enterprise プランでも利用範囲が広がる設計です。無料プラン（Free）での扱いは段階的に変わる可能性があるため、Anthropic 公式ドキュメントで必ず最新状況を確認してください。私自身は Max プランで Skill を日常的に使っています。

Q: Claude Skills と Claude Code の Slash commands は何が違いますか？

大きな違いは「誰が呼び出すか」です。Skills は Claude が自動判断で呼び出す（SKILL.md の description を Claude が読んで「いつ呼ぶか」を決める）、Slash commands はユーザーが /command で明示的に呼び出す（.claude/commands/ に配置）。業務手順を覚えさせて自動発火させたいなら Skills、特定タイミングで手動呼び出ししたいなら Slash commands、というのが両方を業務で使っている私の感覚です。

Q: Skill に機密情報を埋め込んでも大丈夫ですか？

「絶対大丈夫」とは申し上げません——むしろ、機密情報を Skill に直書きするのは強く避けるべきというのが業務利用での原則です。API キー / 個人情報 / 顧客リスト / 社内コードの一部などは、環境変数に分離、.gitignore 配下に外部ファイル化、Skill 経由でも Anthropic サーバに送信される前提を理解、の3点が最低条件です。最終判断は社内情シス・コンプラ部門・法務にご確認ください。

Q: 自分で Skill を作るのに、プログラミングは必要ですか？

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

Q: anthropics/skills の GitHub リポジトリにある Skill は、そのまま業務で使えますか？

「絶対そのまま使える」とは申し上げません。Skill の中身（SKILL.md / scripts / resources）を必ず人間がレビュー、scripts が外部 API を叩く場合は通信先・送信内容を確認、商用利用条件は各 Skill のライセンスを確認、機密情報を含む業務データを扱う場合は社内ガバナンス確認、の4点が最低条件です。公式 Anthropic 提供 Skill は比較的安心して使える立ち位置ですが、商用利用条件・送信前提は公式で確認するのが筋です。

Claude を毎日触っているうちに、「同じプロンプトを毎回コピペするのが面倒」「業務手順を Claude に覚えさせたい」と感じてきたのではないでしょうか。ラッコキーワード実測（2026 年 5 月時点）でも「Claude Skills」は月 8,100 件・SEO 35・+788% の新興 KW。私自身は Claude.ai と Claude Code の両環境で、コード系・ドキュメント系・業務テンプレ系の 3 系統の Skill を自作して日常的に使っています。

結論から言うと、Claude Skills は「既存を探して使う」だけで止めず、「自分の業務手順を覚えさせる側」に踏み込むと、Claude が自分専用のアシスタントになる——というのが、業務で 3 系統の Skill を動かしている私の率直な感覚です。本記事では Skill の中身、Claude.ai と Claude Code の違い、入手経路、自作手順、類似機能との違いまで整理します。

最短で「自作 Skill の最小形」を触りたい方は、Skill の正体と自分で Skill を作るから読み始めると、本日中に最初の SKILL.md が書けます。

Claude Skills の基礎｜正体・構造・できること

📖 この章で使う用語

Claude Skills：Claude（Claude.ai / Claude Code）に「機能・指示・ファイル」をパッケージ化して渡せる仕組み。2025-10 に Anthropic が公式発表した新機能。

SKILL.md：Skill のメタ情報（呼び出し条件・手順）を書く Markdown ファイル。YAML frontmatter で name / description を記述。

scripts/ / resources/：それぞれ Skill 内の実行コード（bash / Python / TypeScript）と参照ファイル（テンプレ・サンプルデータ）の置き場。

まず結論から。Claude Skills は 「Claude に機能 + 指示 + ファイルをパッケージで渡せる仕組み」 です。覚えていただきたいのは、次の 3 つの住み分けです。

Skill の中身 ＝ SKILL.md（メタ情報・呼び出し条件）+ scripts/（実行コード）+ resources/（参照ファイル）の 3 要素を 1 フォルダにまとめる
既存を使う側 ＝ anthropics/skills GitHub リポ + Anthropic 公式 Skill（pdf / docx / pptx）+ コミュニティ Skill を入手して動かす
自作する側 ＝自分の業務手順を SKILL.md 化し、Claude が「いつどう呼び出すか」を自動判断できるようにする

新しい話題が出てきても「これは中身の話か、既存を使う話か、自作する話か」を確かめれば、置き場所に迷いません。私自身は Claude.ai Max プランと Claude Code の両環境で、コード系・ドキュメント系・業務テンプレ系の 3 系統を自作して日常的に使っています。docx / pdf / pptx 生成も自作 Skill が主軸で、公式 Skill は要所で使い分ける程度です。

本記事は Claude 使い方（Claude プロダクト全体ハブ）から派生するスポークとして「Skill という新しい仕組み」だけを取り出して扱います。Claude Code の CLI 全体は Claude Code 使い方、AI コーディング全体地図は AI コーディングをご覧ください。

なお Claude Skills は 2025-10 リリースの新機能で、UI・配布経路・利用条件が変わりやすい領域です。本記事の手順・利用可能プラン・公式 Skill リストはすべて 2026 年 5 月時点のもので、最新の状況は Anthropic 公式ドキュメントと anthropics/skills GitHub リポジトリで必ず事前確認してください。

Claude Skills とは——3 要素で構成されるパッケージ

Claude Skills の正体を整理します。まず Skill の構造を図で書くと、次の通りです。

~/.claude/skills/<skill-name>/     ← Skill のフォルダ（グローバル）
  または
.claude/skills/<skill-name>/       ← Skill のフォルダ（プロジェクトローカル）
├── SKILL.md                       ← メタ情報 + 呼び出し条件 + 手順
├── scripts/                       ← 実行コード置き場（任意）
│   ├── helper.py
│   ├── runner.sh
│   └── ...
└── resources/                     ← 参照ファイル置き場（任意）
    ├── template.md
    ├── sample-data.csv
    └── ...

この 3 要素を 1 フォルダにまとめると、Claude が「いつどう呼び出すか」を自動判断できる Skill になります。

SKILL.md：Skill の心臓部。先頭の YAML frontmatter に name（Skill 名）と description（いつ呼び出すか）、本文に手順を書きます。Claude は会話の流れから description を読んで「この場面で呼ぶべきか」を判断します。
scripts/：実行可能ファイル（bash / Python / TypeScript）の置き場。SKILL.md 単体でも動きますが、scripts/ を足すと外部ツール連携・データ加工・ファイル生成が自動化できます。最初は SKILL.md だけで始め、必要になったら追加する流れが現実的です。
resources/：テンプレ（メール文面・議事録構造・提案書の骨格）、サンプルデータ（CSV / JSON）、参考ドキュメントの置き場。私の業務では、業務テンプレ系 Skill の多くが「SKILL.md + resources/ だけ」（scripts/ なし）で動いています。

利用可能プランは、公式発表時点で Claude.ai Pro / Max と案内されました。Team / Enterprise では管理権限の単位が変わり、無料プラン（Free）での扱いは段階的に変わる可能性があるため、Anthropic 公式の Skills ドキュメントで必ず最新状況を確認してください。プラン選びは Claude 料金プランで別建てしています。

理解にいちばん効くアナロジーは、Skill = Claude に「お客様別の対応手順書」を渡す行為です。営業時代の私は得意先ごとに「この担当者は対面、この製品から提案、価格交渉はこのライン」といった手順を頭に入れていました。それを AI に対してやるのが Skill で、SKILL.md に書いておけば毎回ゼロから指示しなくても Claude が自動的に手順書を開いて動いてくれます。

Claude Skills でできること 5 つ

Claude Skills で「実際に何ができるか」を 5 つに整理します。①〜③・⑤は私が日常的に使っているもの、④は公式情報をもとに補足します。

できること	内容	具体例
① コード作業の自動化	テスト生成・リファクタ提案・差分指摘	`.claude/skills/generate-test/` を置けば「この関数のテスト書いて」で自動発火
② ドキュメント生成	Markdown / docx / pdf の生成・整形	生メモ→構造化 Markdown、自作テンプレから Word / PDF を組み立て
③ 業務テンプレ呼び出し	メール・議事録・提案書の定型文書	取引先別メール文面、議事録の 3 軸構造化、提案書の骨格生成
④ 外部ツール連携	scripts/ から外部 API 接続	Slack 投稿・Notion 取得など（私は MCP 経由が常用、後述）
⑤ プロンプト集の再利用	よく使うプロンプトを呼び出し化	構成案 5 案・レビュー雛形・決定事項抽出を各 Skill に

②は Anthropic 公式の pdf / docx / pptx Skill とは別系統で、業務固有のテンプレを resources/ に詰めて運用しています。③は AI 議事録おすすめと連動。④を Skill 経由でなく MCP で扱う理由は類似機能との違いで整理します。コード系の具体は業務で常用する 3 系統で 3 例扱います。

Skill 化の最初の候補は毎週 3 回以上やる定型作業で、それ以下の頻度なら通常のプロンプトで十分、というのが私の線引きです。

入手と環境｜2 環境の違い・3 つの入手経路・公式 Skill

📖 この章で使う用語

CLAUDE.md：Claude Code がプロジェクトルートで読む指示書ファイル。Skill と組み合わせて発火条件を制御。

anthropics/skills：Anthropic が GitHub に公開している公式 Skill リポジトリ。

コミュニティ Skill：個人開発者が GitHub 等に公開している Skill。品質・セキュリティは自己責任。

SERP 上位がほぼ触れない論点——Claude.ai と Claude Code での Skill 動作の違い——を、両環境を業務常用している立場から整理します。本記事のユニークな差別化軸です。

Claude.ai（Web / Desktop）では Skill を GUI で管理 します。設定画面で有効化・無効化を切り替え、プロジェクト単位で使う Skill を選ぶ運用で、対話の流れの中で Claude が description を読んで自動的に呼び出します。私の業務では、自分専用のメール文面・議事録整形・ブログ構成案のような 個人のワークフロー に向いています。

Claude Code（CLI）では、Skill を .claude/skills/<skill-name>/SKILL.md の形でリポジトリ内に直接配置します（全プロジェクトから呼ぶなら ~/.claude/skills/<skill-name>/）。最大の特徴は リポジトリ単位でチーム共有できる こと。.claude/skills/ を Git 管理に入れておけば、clone した全員が同じ Skill セットを使えます。チーム共通のコードレビュー・テスト生成 Skill のように「共有したい業務手順」を置く運用が中心です。CLI 環境構築は Claude Code はじめ方で別建てしています。

CLAUDE.md（プロジェクト全体の指示書、起動時に必ず読む）に「テスト生成は generate-test Skill を使うこと」と書いておくと、Claude が該当 Skill を確実に発火させる、という連携も組めます。配置の判断は次の通りです。

判断軸	Claude.ai 上の Skill	Claude Code 上の Skill
管理場所	GUI（設定画面）	ファイル（`.claude/skills/`）
発火タイミング	対話の流れで自動	CLI で対話 or CLAUDE.md 経由
共有方法	個人 or プロジェクト機能	Git リポジトリで共有

「迷ったら、個人のワークフロー = Claude.ai、チーム共有 = Claude Code リポ配下」が一行マップです。同じ Skill を両環境に 2 重に持つと管理が煩雑なので、最初は片側に寄せます。

既存 Skill の 3 つの入手経路

既存 Skill の入手経路は、大きく 3 系統に整理できます。

経路	概要	入手方法	注意点
anthropics/skills GitHub リポ	Anthropic 公式の Skill リポジトリ	`git clone` または zip ダウンロード	公式サンプルが中心
Anthropic 公式 Skill	pdf / docx / pptx 等の標準 Skill	Claude.ai で標準提供	標準機能として利用可
コミュニティ Skill	個人開発者が GitHub に公開	`git clone` または直接配置	品質・セキュリティは自己責任

anthropics/skills GitHub リポを覗いてみる

Anthropic は 2025-10 の Skill 発表と同時に anthropics/skills GitHub リポジトリを公開しました。公式の Skill サンプル（pdf / docx / pptx 生成等）と、ベストプラクティスを示すリファレンス Skill が並んでいます。入手手順は次の 3 通りです。

# パターン 1: リポジトリ全体を clone
git clone https://github.com/anthropics/skills.git
cd skills

# パターン 2: 必要な Skill だけ取り出す（sparse-checkout）
git clone --no-checkout https://github.com/anthropics/skills.git
cd skills
git sparse-checkout init --cone
git sparse-checkout set pdf-generator

# パターン 3: GitHub の Web UI から zip ダウンロード
# → https://github.com/anthropics/skills の「Code」→「Download ZIP」

clone した Skill フォルダは、Claude.ai では設定画面からアップロード、Claude Code では .claude/skills/ または ~/.claude/skills/ にコピーします。なお公式マーケットプレイスは 2026 年 5 月時点で段階的整備中で、GitHub リポ + 公式ドキュメント + コミュニティ配布が並走している段階です。今後の整備状況は Anthropic 公式で必ず最新確認してください。

コミュニティ Skill とセキュリティの注意

GitHub には個人開発者が公開する Skill も多数あり、「Notion 連携」「Slack 投稿」「カレンダー登録」など業務直結のものが見つかります。ただし入れる前に 必ず確認すべき 4 点 があります。

Skill の中身（SKILL.md / scripts / resources）を人間がレビュー
scripts/ が外部 API を叩く場合は通信先・送信内容を確認
商用利用条件を各 Skill のライセンス（LICENSE ファイル）で確認
機密データを扱う場合は社内ガバナンス（情シス・コンプラ部門）に確認

コミュニティ Skill は便利な反面、コードが何をするか分からないまま動かすと事故の元です。必ず人間がレビューしてから入れるのが業務利用の原則です。

Anthropic 公式提供 Skill（pdf / docx / pptx）

Claude.ai では pdf / docx / pptx 生成などの公式 Skill が標準提供され、「これを PDF にして」「Word にして」「PowerPoint にして」と頼むと自動発火します。代表的な 3 つの棲み分けは次の通りです。

Skill	用途	入力形式	業務利用シーン
pdf 生成 Skill	レポート・契約書・配布資料の PDF 化	Markdown / プレーンテキスト	顧客提出用レポート、社内配布資料、講演資料
docx 生成 Skill	編集可能な Word ドキュメント	Markdown / プレーンテキスト	上司・チームに渡して編集してもらう文書、契約書ドラフト
pptx 生成 Skill	スライド形式のプレゼン資料	Markdown / プレーンテキスト	営業提案・社内発表・講演スライドの素案

公式 Skill の強みは Anthropic 自身が品質と互換性を保証している こと。出力 PDF が壊れていないか・docx が Word で正しく開けるかといった基本品質が安定しやすい、というのが公開情報の評価です。

一方、私の業務では 自作 Skill が主軸 です。理由は、(1) 業務固有テンプレ（社内承認印・ロゴ位置・段組み）を resources/ に詰めて手直しをほぼゼロにできる、(2) 社内 DB・スプレッドシートから動的にデータを引く scripts/ を組める、(3) 出力ファイル名・保存先を業務フローに合わせられる、の 3 点。公式 Skill で 70% カバー、残り 30% を自作で埋める配分が現実的です。最新の公式 Skill リストは anthropics/skills GitHub リポと Anthropic 公式ドキュメントでご確認ください。

自分で Skill を作る｜SKILL.md・scripts・resources の書き方

📖 この章で使う用語

プロジェクトローカル / グローバル：.claude/skills/<name>/（特定リポジトリ配下）と ~/.claude/skills/<name>/（全プロジェクトから呼べる）の 2 種類の配置先。

YAML frontmatter：SKILL.md の先頭で --- に囲まれたメタ情報ブロック。name / description を記述。

Skill 自作が効くのは、同じ指示を何度も書く作業です。一度きりなら本章の無料サンプルで十分ですが、長編で同じ視点・構成技法・出力ルールを繰り返すなら、創作用 Skill にまとめる選択肢があります。実運用中の SKILL.md と、技法書から Skill に落とす工程を見たい方向けの ¥980 ガイドは、第1章まで note で無料試し読みできます（価格・内容の最新情報は note でご確認ください）。

私は業務でコード系・ドキュメント系・業務テンプレ系の 3 系統を運用しています。次は、議事録を整形する meeting-notes Skill の SKILL.md を表示した実画面です。先頭の frontmatter に name と description、その下に手順と出力ルールを書いた 1 ファイルが Skill の本体になります。

自作した meeting-notes Skill の SKILL.md を cat で表示した実際の画面。YAML frontmatter に name: meeting-notes と description（会議メモを議事録に整形する Skill）、その下に「いつ使うか」「手順」「出力ルール」が書かれている

SKILL.md の frontmatter（`name` / `description` の書き方）

まず Skill 用フォルダを作ります（チーム共有なら .claude/skills/<skill-name>/、個人グローバルなら ~/.claude/skills/<skill-name>/）。Skill 名は 動詞 + 目的語の短い名前（generate-test / review-pr / format-meeting-notes）が、Claude にとって読み取りやすい命名です。次に、フォルダ内の最小の SKILL.md は以下の構成です。

---
name: format-meeting-notes
description: 会議の生メモを「アクション / 決定事項 / 課題」の3軸で構造化された議事録に整形する。生メモが渡されたとき、または「議事録整形して」と依頼されたときに呼び出す。
---

# format-meeting-notes Skill

このSkillは、会議の生メモを構造化された議事録に変換します。

#### 出力フォーマット
```
## アクション
- [ ] 担当者 / 期日 / 内容

## 決定事項
- 内容（背景つき）

## 課題
- 内容 / 影響 / 対処方針
```

#### 手順
1. 入力された生メモを読み込む
2. 上記3軸（アクション / 決定事項 / 課題）に分類
3. 各項目に担当者・期日・背景が書かれていない場合は「未記載」と明記
4. 出力フォーマットに従って整形して返す

最重要は frontmatter の name と description です。description は「何ができるか」と「いつ呼び出すか」をセットで書く のが安定発火のコツで、「議事録整形」だけだと曖昧、「生メモが渡されたとき、または『議事録整形して』と依頼されたときに呼び出す」と明記すると発火率が上がります。

scripts/ にヘルパーを配置する

scripts/ には Skill が呼び出す実行コード（bash / Python / TypeScript）を置きます。最小の Python ヘルパーは次の通りです。

# scripts/format_notes.py
# 生メモを「アクション / 決定事項 / 課題」の3軸で整理する補助スクリプト

import sys
import re

def categorize_lines(raw_notes: str) -> dict:
    """生メモの行を3カテゴリに分類する最小実装"""
    categories = {"アクション": [], "決定事項": [], "課題": []}
    for line in raw_notes.splitlines():
        line = line.strip()
        if not line:
            continue
        # 簡易ルール：「やる」「する」を含めばアクション扱い
        if re.search(r"(やる|する|完了|提出)", line):
            categories["アクション"].append(line)
        elif re.search(r"(決定|決まった|合意)", line):
            categories["決定事項"].append(line)
        else:
            categories["課題"].append(line)
    return categories

if __name__ == "__main__":
    raw = sys.stdin.read()
    result = categorize_lines(raw)
    for cat, items in result.items():
        print(f"\n## {cat}")
        for item in items:
            print(f"- {item}")

これは「議事録の叩き台」を生成するだけの最小実装で、実運用では Claude が scripts/ を呼び出し、その出力を受け取って最終整形を Claude 自身が仕上げる二段構えで動きます。bash ヘルパーも見ておきましょう。

#!/bin/bash
# scripts/run-tests.sh
# テスト生成 Skill の補助：プロジェクトの既存テストを一覧表示する

set -euo pipefail

PROJECT_DIR="${1:-.}"
echo "## 既存テストファイル一覧"
find "$PROJECT_DIR" -type f \( -name "*_test.py" -o -name "*.spec.ts" -o -name "*_test.rb" \) \
    | head -20

resources/ にテンプレ・参照ファイルを配置する

resources/ には Skill が参照するテンプレ・サンプルデータ・参考資料を置きます。例えば業務テンプレ系なら、メール文面のひな型や出力例を置く構成です。

.claude/skills/generate-email/
├── SKILL.md
├── scripts/
│   └── compose.py
└── resources/
    ├── template-thanks.md       # お礼メールのひな型
    ├── template-followup.md     # フォロー連絡のひな型
    └── template-reschedule.md   # 日程変更依頼のひな型

SKILL.md から「resources/template-thanks.md を読み込み、入力されたお客様情報で差し込み」と指示すると、Claude が中身を読んで素材として使ってくれます。

呼び出しテストとデバッグ

Skill を作ったら必ず呼び出しテストをします。Claude.ai なら新しい会話で description に書いたシーンを再現するメッセージを投げ、想定の Skill が発火するかを確認します。呼び出されない典型原因は 3 つで、description を書き直して再テストを 2〜3 回回せば安定発火するようになります。

description が曖昧（「議事録系」だけだと拾えない）
name が長すぎ・曖昧（do-something のような名前は判定が難しい）
他の Skill と competing（似た説明文が複数あって判定が分散）

最初の Skill は「失敗しても良い練習台」として小さく作り、慣れてから本格的な業務 Skill に移行する流れが現実的です。

Skill 設計のベストプラクティス（命名 / 粒度 / 再利用性 / セキュリティ）

業務で実感している範囲で、設計の勘所を 4 点にまとめます。

命名（動詞 + 目的語、description の書き方）

Skill 名は 動詞 + 目的語 が原則で、generate-test / review-pr / format-meeting-notes のように「何をする Skill か」が名前で完結する形にします。

description には、(1) 何をする Skill か、(2) どんなときに呼び出すべきか、(3) 入力として何を渡すか、の 3 点を入れます。100 文字前後で簡潔に書くと、Claude の発火判断が安定します。

# 良い例
description: TypeScript / Python の関数を渡すと、Jest / pytest 形式のユニットテストを生成する。「テスト書いて」と頼まれたとき、または関数定義が渡されたときに呼び出す。

# 悪い例
description: テスト関連のお手伝い

粒度（1 Skill = 1 タスク）

1 Skill = 1 タスク が原則です。「テスト生成 + コードレビュー + リファクタ提案」を 1 つに詰め込まず、3 つの別 Skill に分けます。(1) Claude が呼ぶ場面を判断しやすい、(2) 改善時に他タスクへ影響しない、の 2 点が理由。最初から細かく分けるほうが運用が楽です。

再利用性（汎用 vs プロジェクト固有の分離）

配置場所で「汎用」と「プロジェクト固有」を分けます。議事録整形・メールテンプレなどの汎用はホーム配下 ~/.claude/skills/<name>/、社内 API 連携などの プロジェクト固有 はリポジトリ配下 .claude/skills/<name>/ に置く線引きです。固有 Skill をホーム配下に置くと別プロジェクトで誤発火するので、分離は最初からきちんとやります。

セキュリティ（機密情報を埋めない、scripts のレビュー）

業務利用で最重要なのがセキュリティです。次の 4 点は 絶対に守るべき原則 です。

機密情報を Skill に直書きしない：API キー / 個人情報 / 顧客リスト / 社内コードの一部などは、SKILL.md / scripts / resources いずれにも直書きしません
API キーは環境変数（.env / export）に分離：scripts/ から os.environ.get("API_KEY") で読む形にして、Skill 本体には書きません
scripts/ の実行内容は必ず人間がレビュー：自動実行されるコード、特にファイル操作・外部 API 呼び出しは、最初の利用前に必ず内容を確認します
外部送信内容を明示：scripts/ が外部 API を叩く場合、SKILL.md に「通信先・送信データの種類」を明記して、後から見ても何が外に出るか分かる形にします

# 環境変数で API キーを管理する例
# ~/.zshrc または .env
export ANTHROPIC_API_KEY="sk-ant-xxxxx"
export NOTION_API_KEY="secret_xxxxx"

# scripts/ 内では os.environ.get() で読む

用途・チーム文化・社内ガバナンスで振れる部分は残ります。最終判断は社内情シス・コンプラ部門・法務にご確認ください。

業務で常用する 3 系統（コード系 / ドキュメント系 / 業務テンプレ系）

私が常用している コード系 / ドキュメント系 / 業務テンプレ系の 3 系統 を、各 3 例で深掘りします。

コード系 Skill（テスト生成 / 差分指摘 / リファクタ）

テスト生成（generate-test）：TypeScript / Python / Ruby の関数を入力すると Jest / pytest / RSpec 形式のテストを返す。雛形を resources/ に置き、引数・戻り値・例外をテストケースに展開させます。型は AI コードレビューのセクション 5 で扱っています。
差分指摘（review-pr）：git diff main を入力すると変更点ごとのレビューコメントを返す。観点（バグ / 設計 / 命名 / テスト不足 / セキュリティ）を resources/ にチェックリストとして置き、機械的にスキャンします。
リファクタ（propose-refactor）：対象ファイルを入力すると関数分割・命名改善・重複抽出の案を返す。.claude/skills/ に置けばチーム全員が同じ基準で提案を受けられ、レビュー文化の標準化にも効きます。

CLI 全体の使い方は Claude Code 使い方で別建てし、本記事は「Skill としてコード系作業を組む」軸に絞っています。

ドキュメント系 Skill（Markdown 整形 / docx / pdf）

Markdown 整形（format-markdown）：雑なメモ（箇条書きの羅列・誤字あり）を、見出し・リスト・強調を整えた Markdown に変換。Claude が H1/H2/H3 の階層を判断して読みやすく組み直します。
自作 docx 生成：公式 docx Skill とは別系統で、業務固有テンプレ（社内ロゴ・承認印位置・段組み）を resources/ に詰め、scripts/ に python-docx の組み立てコードを置く構成。
自作 pdf 生成：月次レポート・顧客向け提案書など定型 PDF を自動生成。scripts/ に reportlab / weasyprint、resources/ にテンプレを置きます。

公式 Skill が「汎用品質を担保」するのに対し、自作 Skill は「業務固有のテンプレと差し込み」を組み込めるのが強みで、両方を併用するのが現実的です。

業務テンプレ系 Skill（メール / 議事録 / 提案書）

メールテンプレ（compose-email）：用途と相手情報を入力すると、お礼 / フォロー / 日程変更などのテンプレから差し込んだメール本文を返す。
議事録テンプレ（format-meeting-notes）：生メモを「アクション / 決定事項 / 課題」の 3 軸に分類し、担当者・期日・背景を抽出。議事録 AI 全般は AI 議事録おすすめで別建てしています。
提案書テンプレ（draft-proposal）：顧客情報 + 商談メモ + 提案商品を入力すると、背景・課題・提案内容・期待効果・概算費用の骨格を返す。営業時代の「ゼロから 2 時間」が呼び出し + 調整で 30 分に縮むイメージです。

この 3 系統に落ち着いているのは、「コードを書く・ドキュメントを書く・業務テンプレを呼ぶ」というエンジニアの日常作業の 3 大柱に Skill が一番効くからです。

使い分けと運用｜類似機能との違い・定着の体験談・失敗とYMYL

📖 この章で使う用語

Slash commands：Claude Code の /command 型コマンド。.claude/commands/ に配置し、ユーザーが明示的に呼び出す。

MCP（Model Context Protocol）：外部リソース・データソースへの統一プロトコル。Cursor / Claude Code 等が対応。

Tools（Function Calling）：API レベルで関数を Claude に渡す機能。Anthropic API / OpenAI Function Calling 系。

混同しやすい4機能（Skills / Slash commands / MCP / Tools）の使い分けマップ。Skills は Claude が自動判断で呼ぶ業務手順のパッケージ、Slash commands はユーザーが /command で明示呼び出し、MCP は外部リソース接続、Tools は API の tools 引数でプログラム組み込み、と『誰が呼び出すか』で見分ける構造を表した概念図

Skills と混同しやすい 3 機能（Slash commands / MCP / Tools）との違いを 4 軸で整理します。

4 機能の一行比較

Skills：.claude/skills/ に置き、Claude が自動判断で業務手順を呼び出します。
Slash commands：.claude/commands/ に置き、ユーザーが /command で定型操作を呼びます。
MCP：別プロセスのサーバーを介し、外部データへ接続します。
Tools：API の tools 引数で、Claude をプログラムへ組み込みます。

Skills と Slash commands の使い分け

いちばん混同しやすいのが Skills と Slash commands です。両方とも .claude/ 配下に Markdown を置くため見た目は似ていますが、違いは 「誰が呼び出すか」 です。

Skills は Claude が自動判断で呼び出す：description を読んで「いま呼ぶべきか」を判断。会話の流れで自然に発火させたい業務手順向き
Slash commands はユーザーが /command で明示呼び出し：「/review でレビュー開始」のように明確なタイミングで打ち込む

自動発火させたいなら Skills、特定タイミングで手動呼び出ししたいなら Slash commands、というのが両方使っている私の感覚です。同じ機能を「自動発火は Skill、明示呼び出しは Slash command」と 2 つの入口で持つパターンもあります。

Skills と MCP の使い分け

MCP は GitHub / Postgres / Slack / 社内 API などへの 接続プロトコル です。MCP は「外部リソースへの接続」、Skills は「業務手順のパッケージ化」 という役割分担で、両者は連携します。

GitHub の PR 情報を取りたい → MCP（GitHub MCP サーバ経由）
取った PR 情報をレビューコメントに変換したい → Skill（review-pr）

MCP で外部からデータを引き、Skill で後続の業務処理を組む形です。Cursor MCP の設定は Cursor 使い方で別建てしています。

Skills と Tools（Function Calling）の使い分け

Tools は Claude API のリクエストに tools 引数で関数定義を渡す API レベルの機能 です。Tools は「API 経由で Claude をプログラムに組み込む仕組み」、Skills は「対話インターフェース上で動く仕組み」 という棲み分けです。

# Tools の例：Anthropic API を Python から呼び出して関数を渡す
import anthropic

client = anthropic.Anthropic()

tools = [
    {
        "name": "get_weather",
        "description": "指定都市の天気を取得",
        "input_schema": {
            "type": "object",
            "properties": {
                "city": {"type": "string"}
            },
            "required": ["city"]
        }
    }
]

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "東京の天気は？"}]
)

業務プロダクトに Claude を組み込むなら Tools、対話上で業務手順を呼び出すなら Skills が目安です。4 機能の使い分けを 1 行ずつまとめると次の通りです。

業務手順を覚えさせる → Skills
手動でコマンド呼び出し → Slash commands
外部リソース接続 → MCP
API でプログラム組み込み → Tools

4 機能を並べて見比べ、その業務にいちばん馴染む選択肢を取るのが現実的です。CI/CD 統合との関係は Claude Code Action で別建てしています。

自作 Skill を業務に定着させるまで——詰まった3つの勘所

ここからは、私が実際に自作 Skill を業務で常用するまでに何をして、どこで詰まったかを、作った順につまずきとセットで振り返ります。

最初に詰まったのは「description」——Claude が Skill を拾ってくれない

最初に作ったのはドキュメント系でした。本文（手順）は丁寧に書いたのに Claude が一向に呼んでくれない——原因は本文ではなく description でした。「いつ呼び出すか」が曖昧だと、Claude は「今がそのタイミングだ」と判断できません。最初は「ドキュメントを整える」程度しか書いておらず、2〜3 回書き直しました。「どんな入力で・何を出力するか」を具体の動詞で書いたら急に拾われるようになり、最初に時間をかけるべきは本文ではなく description というのが、いちばんの勘所です。

具体的に書けると、こうなります。次は meeting-notes Skill が入った状態で、Claude Code に打ち合わせメモを貼り「議事録にして」と頼んだ画面です。Claude が「合致する Skill がある（There's a matching skill）」と判断し Skill(meeting-notes) Successfully loaded skill と表示して自動読み込みし、決定事項 / アクション / 課題の 3 区分に整形しています。description に「整理して・議事録にしてと頼まれたとき」と書いたから、ユーザーが何も指定しなくても発火した——これが肝です。

Claude Code に打ち合わせメモを貼って議事録化を頼むと、meeting-notes Skill が自動で合致判定され Successfully loaded skill と表示され、決定事項・アクション・課題の3区分に整形された実際の画面

コード系で学んだ「粒度」——1 つに詰め込みすぎない

次に作ったコード系（テスト生成・差分指摘・リファクタ補助）での失敗は 1 つの Skill に機能を盛りすぎたことです。「コード作業ぜんぶ」を 1 個に詰めたら description が曖昧になり、また呼ばれなくなりました。機能ごとに役割を 1 つに絞ったら呼び出しが安定。「あれもこれも、いい感じに」より「この入力を、この形に」と狭く渡すほうが、人に仕事を頼むときと同じでお互い迷いません。

業務テンプレ系で実感した「定着」——作って終わりにしない

3 つめの業務テンプレ系で分かったのは、Skill は作った瞬間がゴールではなく、毎日自然に呼ばれて初めて意味があるということです。最初は「つい手作業に戻る」期間があり、description を実際の言い回しに寄せ、resources のテンプレを実務表現に直して、ようやく「考えずに呼ぶ」状態に定着しました。

未経験から学ぶ方には、Skill を 1 つ自作すること自体がいちばんの教材だと伝えたいです。SKILL.md の書き方・frontmatter の構造・scripts/ の配置・呼び出しの仕組みは、すべて生成AIエンジニアの実務で日常的に触る要素。読むだけより、小さくても 1 個手で動かすほうが圧倒的に身につきます。学習全体像は生成AI 入門で別建てしています。

失敗パターン 5 個——Skill 設計でよくある落とし穴

業務で見つかった失敗パターンを 5 つ整理します。

① 複雑すぎて呼ばれない：複数タスクを 1 Skill に詰め込むと、Claude が呼ぶ場面を判定できない。1 Skill = 1 タスクに分割すると発火率が上がる。
② 複数 Skill の competing：似た description（generate-test と write-test 等）があると判定が不安定。命名を分け、守備範囲を明記し、不要な古い Skill は削除する。
③ 機密情報の直書き：API キー等を SKILL.md / scripts / resources に直書きすると、Public リポ公開時に即漏洩。環境変数 + 外部ファイル参照（.gitignore 配下）+ レビュー時チェックで防ぐ。
④ scripts が無レビューで動く：ファイル削除・外部 API・DB 書き換えを読まずに動かすと事故る。導入前に人間が読み、最初の数回はドライランで確認する。
⑤ 配置ミス：プロジェクト固有 Skill をグローバル ~/.claude/skills/ に置くと別プロジェクトで誤発火。汎用と固有の線引きを最初に決める。

私自身、最初の Skill では 5 つすべてを少しずつやらかしました。失敗を 1 つずつ潰しながら、自分の業務に馴染む運用に育てるのが現実的です。

YMYL 警戒——機密情報 / Anthropic 送信前提 / 商用利用条件

業務利用で必ず通過すべき YMYL 警戒を、本記事でいちばん慎重に整理します。

機密情報を Skill に埋めない：API キー / 個人情報 / 顧客リスト / 社内コードは SKILL.md / scripts / resources いずれにも 直書きしません。(1) Public リポ公開時に即漏洩、(2) チーム共有時に他メンバーから見える、(3) Skill 経由でも Anthropic サーバに送信される、が理由です。環境変数 + 外部ファイル参照 + .gitignore の 3 段構えで防ぎます。

Anthropic への送信前提を理解：Skill を経由しても入力は通常会話と同じく Anthropic サーバに送信され、ローカル完結ではありません。Anthropic は API 経由データをデフォルトで学習に使わない方針ですが（最新は Anthropic 公式の利用規約で確認）、「社外送信そのものが NG」の環境では社内ガバナンス（情シス・コンプラ部門）の事前確認が必須です。完全ローカルが要件なら、ローカル LLM の検討が選択肢——詳しくは LLM ローカルで別建てしています。

商用利用条件は公式で確認：商用利用はベースの Claude プラン（Pro / Max / Team / Enterprise）の利用規約に従います。プランごとに条件が異なるため、(1) どのプランで利用するか、(2) 入力データの取り扱い、(3) 出力物の権利関係、(4) 監査ログ取得可否、を社内法務・コンプラ部門に確認するのが筋です。プラン選びは Claude 料金プランで別建てしています。

scripts の実行内容は人間がレビュー：ファイル操作（削除・上書き）・外部 API・DB 書き換えのコードは、最初の利用前に必ず人間が読んで理解してから動かします。コミュニティ Skill なら、中身を 1 行ずつ読む・通信先と送信内容を確認・ファイル操作の対象パスを確認、が最低条件です。

訂正連絡先

本記事の事実誤認・記述漏れにお気づきの際は、bon-bon-tools.com のお問い合わせフォーム（/contact/）または send@bon-bon-tools.com までご連絡ください。Claude Skills は仕様変更が早い領域のため、随時更新します。

メタ否定の三段安全網：「絶対安全とは申し上げません」「最終判断は法務・情シス・コンプラ部門の事前確認」「個人差・組織方針で振れる」——この 3 段は、本記事のすべての記述に共通する前提です。本記事の手順・利用可能プラン・送信前提はすべて 2026 年 5 月時点のもので、最新の状況は Anthropic 公式で必ずご確認ください。

よくある質問（FAQ）

Q1: Claude Skills の使い方を最短で知るには、どこから読めばいいですか？

A. 使い方の最短ルートは「①何ができるか → ②既存 Skill を入れて動かす → ③自作する」の順です。本記事なら、まずできること 5 つで用途を掴み、入手経路で anthropics/skills GitHub リポや公式 Skill を導入して 1 つ動かし、慣れてから自作手順で SKILL.md を書く、という流れが私の業務での立ち上げ方に近いです。Claude.ai と Claude Code で動作が少し違う点は 2 環境の違いを先に押さえておくと迷いません。

Q2: Claude Skills は無料プランでも使えますか？

A. 「絶対使える」とは申し上げません。2026 年 5 月時点では、Claude Skills は Pro / Max プランで利用可能 と公式で案内されており、Team / Enterprise プランでも利用範囲が広がる設計です。無料プラン（Free）での扱いは公式リリースで段階的に変わる可能性があるため、Anthropic 公式ドキュメントで必ず最新状況を確認してください。私自身は Max プランで Skill を日常的に使っています。詳細は Claude Skills とはをご参照ください。

Q3: Claude Skills と Claude Code の Slash commands は何が違いますか？

A. 大きな違いは「誰が呼び出すか」です。Skills は Claude が自動判断で呼び出し、Slash commands はユーザーが /command で明示的に呼び出します（.claude/commands/ に配置）。業務手順を自動発火させたいなら Skills、特定のタイミングで手動実行したいなら Slash commands、というのが両方を使う私の感覚です。詳細は類似機能との違いをご参照ください。

Q4: Skill に機密情報を埋め込んでも大丈夫ですか？

A. 「絶対大丈夫」とは申し上げません——むしろ、機密情報を Skill に直書きするのは強く避けるべき というのが業務利用での原則です。API キー / 個人情報 / 顧客リスト / 社内コードの一部などは、(1) 環境変数（.env / shell export）に分離、(2) 外部ファイル参照（.gitignore 配下）に分離、(3) Skill 経由でも Claude の通常会話と同じく Anthropic サーバに送信される前提を理解、の 3 点が最低条件です。最終判断は社内情シス・コンプラ部門・法務にご確認ください。詳細は YMYL 警戒をご参照ください。

Q5: 自分で Skill を作るのに、プログラミングは必要ですか？

A. 「絶対必要」とは申し上げません。最小構成（SKILL.md だけ）なら、プログラミングなしで Markdown が書ければ作れます（呼び出し条件と手順を文章で書くだけ）。一方、scripts/ で実行コード（bash / Python / TypeScript）を組む段階に進むと、プログラミング知識が必要 になります。私の業務利用では、コード系 Skill では Python / bash を書きますが、業務テンプレ系・ドキュメント系 Skill は SKILL.md + resources（テンプレファイル）だけで動かしているものも多いです。詳細は自分で Skill を作るをご参照ください。

Q6: anthropics/skills の GitHub リポジトリにある Skill は、そのまま業務で使えますか？

A. 「絶対そのまま使える」とは申し上げません。(1) Skill の中身（SKILL.md / scripts / resources）を必ず人間がレビュー、(2) scripts が外部 API を叩く場合は通信先・送信内容を確認、(3) 商用利用条件は各 Skill のライセンス（リポジトリ内 LICENSE）を確認、(4) 機密情報を含む業務データを扱う場合は社内ガバナンス確認、の 4 点が最低条件です。公式 Anthropic 提供 Skill（pdf / docx / pptx 等）は比較的安心して使える立ち位置ですが、それでも商用利用条件・送信前提は公式で確認するのが筋です。詳細は入手経路と YMYL 警戒をご参照ください。

この記事は、法人営業を約 7 年やってから未経験 SE → 自社開発と移ってきた現役の生成AIエンジニア aikun が、Claude.ai と Claude Code の両方で自作 Skill（コード系・ドキュメント系・業務テンプレ系の 3 系統）を日常的に作り、業務で常用している手触りをもとに書いています。本文には実際に自作した SKILL.md と、Claude Code 上で Skill が呼び出された画面を載せています。

出典

Anthropic Claude Skills 公式ドキュメント（取得：2026-05-21）
anthropics/skills GitHub リポジトリ（取得：2026-05-21）
Anthropic 公式ブログ：Introducing Skills（取得：2026-05-21）
Anthropic 利用規約（取得：2026-05-21）
Claude.ai 公式（取得：2026-05-21）
Claude Code 公式ドキュメント（取得：2026-05-21）
Model Context Protocol（MCP）公式（取得：2026-05-21）
Anthropic Tool Use（Function Calling）ドキュメント（取得：2026-05-21）
Anthropic API リファレンス（取得：2026-05-21）
Claude Pricing（取得：2026-05-21）
ラッコキーワード「Claude Skills」検索ボリューム実測（取得：2026-05-20、aikun 実測：vol 8,100 / SEO 35 / CPC $35.11 / +788%）
Google サジェスト「claude skills」実測（取得：2026-05-20、aikun 撮影、10件サジェスト確認済）