Claude Code Skills ガイド｜Skill自作7パターン+配布【2026】

「コードレビューのたびに”セキュリティ観点でもチェックして”と打ち直している…」

先日、あるチームのコードベースにClaude Codeを導入した際、こんな状況に気づきました。メンバー全員が独自の長いプロンプトをコピペして使っていて、プロジェクト固有のコンテキスト（使用しているフレームワーク、命名規則、セキュリティ要件）がセッションをまたいで引き継がれない。毎回同じことを説明し直す無駄が積み重なっていたのです。

Claude Code Skillsは、この問題を解決するために設計された仕組みです。「いつも使う専門的なワークフロー」をMarkdownファイルに書き下ろし、特定のトリガー語句でClaudeが自律的に読み込む。設定不要、APIキーなし、10分で動き始めます。

この記事では、公式仕様の全貌と、実務で使える7パターンの自作Skill実装例を、コピペ可能なコード付きで解説します。

---

Claude Code Skillsとは何か：CLAUDE.mdとの違い

Claude Code Skillsを正しく理解するには、Claude Codeのメモリ体系全体を把握する必要があります。公式ドキュメントによると、Claude Codeの持続的記憶は大きく3層に分かれています。

種類	誰が書くか	読み込みタイミング	用途
CLAUDE.md	人間	全セッション・起動時に常時	プロジェクト規約、コーディング標準
Auto Memory	Claude自身	全セッション（最初の200行 or 25KB）	デバッグ知見、ビルドコマンド、発見したパターン
Skills	人間	呼び出し時のみ（オンデマンド）	特定タスク専用のワークフロー

最大の違いは「常時読み込みか、オンデマンドか」です。CLAUDE.mdはセッション開始時に毎回コンテキストウィンドウに載りますが、Skillsは「あなたが呼び出した瞬間にだけ」読み込まれます。

これはコンテキスト効率の観点で非常に重要です。コードレビューのSkillはコードレビュー時だけ、ドキュメント生成Skillはドキュメントを書く時だけ発火する。CLAUDE.mdを肥大化させずに済む設計になっています。

公式の定義（Claude Code公式ドキュメントより）
“Skills package repeatable workflows that load on demand. Unlike CLAUDE.md which loads every session, skills only activate when you invoke them or when Claude determines they’re relevant.”
（参照: Claude Code Skills 公式ドキュメント・2026年6月確認）

Skills ディレクトリ構造：どこに何を置くか

Skillsは.claude/skills/ディレクトリに格納します。以下が推奨の構成です。

your-project/
├── .claude/
│   ├── CLAUDE.md              # メインのプロジェクト指示書
│   ├── rules/                 # パス別ルール
│   │   ├── api-design.md
│   │   └── testing.md
│   └── skills/                # Skills置き場
│       ├── code-review/
│       │   └── SKILL.md       # コードレビューSkill
│       ├── test-generator/
│       │   └── SKILL.md       # テスト生成Skill
│       ├── security-audit/
│       │   └── SKILL.md       # セキュリティ監査Skill
│       └── doc-writer/
│           ├── SKILL.md       # ドキュメント生成Skill
│           └── templates/     # テンプレートファイル（任意）
│               └── jsdoc.md

ポイントは「Skill一つ＝サブディレクトリ一つ」の構成です。SKILL.mdがエントリーポイントになり、テンプレート・サンプル・リファレンスなどの補助ファイルを同じディレクトリに置けます。

SKILL.mdの必須構造

SkillのコアはSKILL.mdのYAMLフロントマターです。以下が最小構成です。

---
name: code-review
description: "コードレビューを実施する。'レビューして' 'コードチェック' 'review' と言われたら起動。"
allowed-tools: Read, Bash(grep:*), Bash(git:*), WebSearch
---

# コードレビュー Skill

## レビュー観点
1. ロジックの正確性（境界値、エラーハンドリング）
2. セキュリティ（インジェクション、認証漏れ、機密情報ハードコード）
3. パフォーマンス（N+1クエリ、不要なループ、メモリリーク）
4. 可読性（命名規則、コメント、関数の単一責任）
5. テスト（カバレッジ、エッジケース）

## 出力フォーマット
- 🔴 Critical（必修正）
- 🟡 Major（推奨修正）
- 🟢 Minor（提案）

## プロジェクト固有のルール
- TypeScript strict mode必須
- `any`型の使用禁止
- async/awaitを優先（コールバック地獄回避）

フロントマターの各フィールドの意味を整理します。

フィールド	必須	説明
name	推奨	Skillの識別子。スラッシュコマンドの名前に使われる場合あり
description	必須	Claudeがこのスキルを発火させるかを判断するトリガー文。自然言語で書く
allowed-tools	推奨	このSkillが使えるツールをホワイトリスト指定。省略すると通常の権限に準拠

Allowed Tools の設計：最小権限の原則

allowed-toolsはセキュリティ観点で最も重要なフィールドです。Skill実行中にClaudeが使えるツールを明示的に宣言します。

---
name: security-audit
description: "セキュリティ監査。'セキュリティチェック' 'security audit' ' 脆弱性確認'で起動。"
# ファイル読み込みと静的解析ツール呼び出しのみ許可
allowed-tools: Read, Glob, Grep, Bash(grep:*), Bash(npm:audit), Bash(semgrep:*)
# WebSearchは許可しない（外部通信を最小化）
---

指定の書き方には2種類あります。

• ツール名のみ（例: Read, Write, Glob）: そのツール全体を許可
• コロン区切りで絞り込み（例: Bash(git:*)）: gitコマンドのみ許可、rmなどは不可

注意：本番環境で使うSkillは、必ず必要最小限のtoolsだけをallow-listに入れてください。特にBash(*)のような全許可は避けましょう。

自作Skill 7パターン：コピペ可能な実装例

実務で頻繁に使われる7パターンのSkillを紹介します。各パターンはそのままコピーして使えます。

パターン1：コードレビューSkill

---
name: code-review
description: "コードレビューを実施。'review' 'レビューして' 'コードチェック' 'PR確認'で起動。"
allowed-tools: Read, Glob, Grep, Bash(git:diff), Bash(git:log)
---

# コードレビュー Skill

## チェックリスト
- [ ] ビジネスロジックの正確性
- [ ] エラーハンドリング（try-catch、null check）
- [ ] セキュリティ（SQL injection, XSS, 認証漏れ）
- [ ] パフォーマンス（N+1, 不要な再描画）
- [ ] テスト（ハッピーパス + エッジケース）

## 出力フォーマット
🔴 Critical: [問題] → [修正方法]
🟡 Major: [問題] → [推奨]
🟢 Minor: [提案]

## プロジェクトルール（カスタマイズしてください）
- ESLint/Prettierに準拠
- コメントは日本語でOK
- 関数は単一責任原則を守る

パターン2：テスト生成Skill

---
name: test-generator
description: "テストコードを生成。'テスト書いて' 'test生成' 'unit test' 'spec作成'で起動。"
allowed-tools: Read, Write, Glob, Bash(npm:test), Bash(jest:*)
---

# テスト生成 Skill

## テスト設計方針
1. Arrange-Act-Assert (AAA) パターンを使う
2. テスト名は「〜のとき〜すること」形式（例: `it('入力が空のとき、エラーを返すこと')`）
3. ハッピーパスとエッジケースの両方をカバー
4. 外部依存（API, DB）はモックする

## テスト生成手順
1. 対象ファイルを読み込む
2. パブリックな関数・メソッドをリストアップ
3. 各関数の入出力パターンを列挙
4. Jestで実装（TypeScript対応）
5. `npm test` で実行確認

## 優先度
- P0: 外部公開API、認証ロジック
- P1: ビジネスロジックの中核
- P2: ユーティリティ関数

パターン3：リサーチSkill

---
name: research
description: "技術調査・情報収集。'調べて' 'リサーチして' 'research' '〜の最新情報'で起動。"
allowed-tools: WebSearch, WebFetch, Read, Write
---

# リサーチ Skill

## 調査フロー
1. キーワードを英語・日本語で各3件WebSearch
2. 公式ドキュメントを必ずWebFetchで確認
3. 信頼性評価（公式 > 査読論文 > 著名エンジニアブログ > SNS）
4. 矛盾する情報は両論を記載し、信頼性の高い方を推奨

## 出力形式
### 概要（3行サマリー）
### 詳細（箇条書き、出典付き）
### 実装への示唆
### 注意点・制約
### 参考URL（取得日付付き）

## 禁止事項
- 知識から推測して出典なしで断言しない
- 最終更新日が1年以上前の記事を唯一の根拠にしない

パターン4：ドキュメント生成Skill

---
name: doc-writer
description: "ドキュメントを生成・更新。'ドキュメント作って' 'README更新' 'JSDoc' 'API仕様書'で起動。"
allowed-tools: Read, Write, Glob, Bash(git:log)
---

# ドキュメント生成 Skill

## ドキュメント種別と優先度
| 種別 | トリガー | テンプレート |
|------|---------|-------------|
| README | "README" "使い方" | ./templates/readme.md |
| JSDoc | "JSDoc" "関数コメント" | - (インライン生成) |
| API仕様書 | "API仕様" "OpenAPI" | - |
| アーキテクチャ | "設計書" "構成図" | - |

## README必須セクション
1. プロジェクト概要（1-2文）
2. クイックスタート（コピペで動く手順）
3. インストール
4. 使用方法（コード例付き）
5. 設定オプション
6. コントリビューション

## 品質基準
- コードブロックには言語指定を付ける
- コピペで動くコマンド例を入れる
- 「詳細は〜を参照」で逃げない（最低限の情報をインラインで書く）

パターン5：セキュリティ監査Skill

---
name: security-audit
description: "セキュリティ監査を実施。'セキュリティチェック' 'vulnerability check' '脆弱性確認'で起動。"
allowed-tools: Read, Glob, Grep, Bash(grep:*), Bash(npm:audit), Bash(git:diff)
---

# セキュリティ監査 Skill

## チェック観点（OWASP Top 10準拠）
1. **A01: アクセス制御の不備** — 認証・認可のバイパス、権限昇格
2. **A02: 暗号化の失敗** — 平文保存、弱い暗号アルゴリズム
3. **A03: インジェクション** — SQL injection, XSS, コマンドインジェクション
4. **A04: 安全でない設計** — シークレットのハードコード、不適切なCORS設定
5. **A07: 認証・セッション管理** — JWTの検証漏れ、セッション固定

## 自動チェック手順
```bash
# 依存パッケージの脆弱性スキャン
npm audit --audit-level=moderate

# シークレットの漏洩チェック（grepで簡易確認）
grep -rn "api_key\|password\|secret\|token" --include="*.ts" --include="*.js" src/

# ハードコードされた認証情報を検索
grep -rn "sk-\|Bearer \|password=" src/
```

## 出力フォーマット
- Critical（即時修正必須）
- High（今リリース前に修正）
- Medium（次スプリントで対応）
- Low（情報として記録）

パターン6：翻訳Skill

---
name: translator
description: "テキストを翻訳。'翻訳して' 'translate' '英訳' '和訳' '〜に訳して'で起動。"
allowed-tools: Read, Write, WebSearch
---

# 翻訳 Skill

## 翻訳方針
- **技術用語**: 業界標準に従う（例: "repository" = "リポジトリ"、"merge" = "マージ"）
- **UIテキスト**: 短く、動詞起点で（例: "Submit" = "送信する" より "送信"）
- **エラーメッセージ**: ユーザーに次のアクションを促す形に
- **マーケティング文**: 原文のトーンを保ちつつ、自然な日本語に

## 翻訳フロー
1. 原文の意図・トーンを確認
2. 技術用語は業界標準の訳語を使用
3. 文化的なニュアンス（ジョーク、慣用句）は注釈付きで意訳
4. 翻訳後、逆翻訳で意味ズレを確認（重要な文書の場合）

## 日英技術用語対応表（プロジェクト固有に追記してください）
- deploy → デプロイ
- staging → ステージング
- pull request → プルリクエスト

パターン7：業界固有Skill（SaaS企業向けカスタマーサクセス例）

---
name: cs-response
description: "CS対応文を生成。'CSメール' '顧客返信' 'サポート文章' 'お詫び文'で起動。"
allowed-tools: Read, WebSearch
---

# カスタマーサクセス対応 Skill

## 対応テンプレート選択ガイド
| 問い合わせ種類 | 使うテンプレート |
|--------------|----------------|
| 機能の使い方 | how-to-template |
| バグ報告 | bug-report-template |
| 解約申し出 | retention-template |
| 機能要望 | feature-request-template |

## 文章スタイルガイド
- 一文60字以内（長いと読みにくい）
- 受動態より能動態（「〜されています」より「〜しています」）
- 謝罪より解決策を先に（「ご不便をおかけして…」より「解決策は…です」）
- 専門用語に(括弧で補足)

## 禁止表現
- 「確認いたします」単体（いつ回答するか不明）
- 「できかねます」単体（代替案がない）
- 「ご理解ください」（一方的）

## 必須確認事項
1. 顧客名・社名は間違いなしか
2. 解決策は技術的に正しいか
3. 期日・約束事項を明記したか

5ステップ：Skillを作って動かすまでの手順

1. ディレクトリを作成する
   プロジェクトルートでmkdir -p .claude/skills/your-skill-nameを実行。Skill名は英数字ハイフン区切りにする。

2. SKILL.mdを作成する
   .claude/skills/your-skill-name/SKILL.mdを作成し、YAMLフロントマターにname・description・allowed-toolsを書く。descriptionにはトリガー語句を自然言語で含める。

3. Skill本文を書く
   フロントマターの下に、Claudeへの指示を書く。見出し・箇条書き・表を使って構造化すると遵守率が上がる。重要なルールは太字かcode blockで強調。

4. テスト発火させる
   Claude Codeで/your-skill-nameとスラッシュコマンドを入力するか、descriptionに書いたトリガー語句を自然に含んだプロンプトを送る。/memoryでSkillが認識されているか確認できる。

5. Gitにコミットしてチームに共有する
   git add .claude/skills/ && git commit -m "feat: add code-review skill"でコミット。以降はpull/cloneした全メンバーが同じSkillを使える。個人専用のSkillは~/.claude/skills/に置く（リポジトリ外）。

公式Skillと自作Skillの違い

Anthropicが公式に配布しているSkillと、自分で作るカスタムSkillにはいくつかの違いがあります。

観点	公式Skill（Anthropic提供）	自作Skill
配置場所	Claude Code内部に組み込み済み	.claude/skills/ または ~/.claude/skills/
有効化方法	Claude Codeインストールで自動	SKILL.mdを作成することで有効化
カスタマイズ	不可（読み取り専用）	自由に編集可能
スコープ	全プロジェクト共通	プロジェクト固有 or 個人用
チーム共有	自動（全員同じ環境）	Gitリポジトリを通じて共有
適している用途	汎用的なコーディングタスク	業界・プロジェクト固有のワークフロー

注目すべきは、公式Skillはオーバーライドできないという点です。例えば「claude-codeレビュー」という公式Skillと名前が衝突する自作Skillを作った場合、動作が予測不能になる可能性があります。自作Skillのnameは意図的にプロジェクト固有のプレフィックスを付けると安全です（例: myapp-code-review）。

チーム配布の2パターン：Git管理 vs シンボリックリンク

パターンA：リポジトリに含めてGit管理（推奨）

# プロジェクトリポジトリに skills を追加
git add .claude/skills/
git commit -m "feat: add team skills for code-review and testing"
git push

# チームメンバーは pull するだけで使える
git pull
# → .claude/skills/code-review/SKILL.md が自動で有効化される

この方法の利点は、Skillとコードベースのバージョンが同期する点です。フレームワークやコーディング規約が変わったとき、Skillも同じPRで更新できます。

パターンB：ユーザーレベルに共有Skills（個人横断）

# 共有Skills置き場を用意
mkdir -p ~/shared-skills

# 各プロジェクトからシンボリックリンクを張る
ln -s ~/shared-skills/security-audit .claude/skills/security-audit
ln -s ~/shared-skills/translator .claude/skills/translator

# これで複数プロジェクトで同じSkillを再利用できる
# ~/shared-skills/ を更新すると全プロジェクトに即時反映される

個人の汎用Skillは~/.claude/skills/に置くと全プロジェクトで自動利用可能になります。

# 個人用の汎用翻訳Skillを追加
mkdir -p ~/.claude/skills/translator
cat > ~/.claude/skills/translator/SKILL.md <<'EOF'
---
name: translator
description: "翻訳。'translate' '翻訳して' '英訳' '和訳' で起動。"
allowed-tools: Read, Write
---
# 翻訳Skill
...（内容省略）
EOF

# 以降は全プロジェクトで「翻訳して」と言うだけで発火する

【要注意】よくある失敗パターン3つ

失敗1：descriptionのトリガー語句が被って混乱する

# ❌ NG: 複数のSkillで同じ語句を使うと競合する
# skill-A/SKILL.md
description: "コードをチェックして改善提案。'チェックして' 'check' で起動。"

# skill-B/SKILL.md
description: "型エラーをチェック。'チェックして' 'check' で起動。"  # ← 競合！

# ✅ OK: 固有のトリガー語句を使う
# skill-A/SKILL.md
description: "コードレビュー全般。'コードレビュー' 'code review' 'PR確認' で起動。"

# skill-B/SKILL.md
description: "TypeScript型チェック専用。'型チェック' 'type check' 'tsc確認' で起動。"

失敗2：allowed-toolsを全許可にしてセキュリティホールを作る

# ❌ NG: Bash全許可はリスクが高い
allowed-tools: Read, Write, Bash(*), WebSearch, WebFetch

# ✅ OK: 必要なコマンドを明示的にリスト
allowed-tools: Read, Glob, Bash(npm:test), Bash(jest:*), Bash(git:status)

特にBash(*)やWriteの全許可は、意図しないファイル削除やシステムコマンド実行のリスクがあります。Skill設計は「最小権限の原則」に従って、本当に必要なツールだけを列挙してください。

失敗3：SKILL.mdが長すぎてClaudeが発火しなくなる

# ❌ NG: 500行超のSKILL.md（コンテキスト消費が大きすぎて発火率が下がる）
SKILL.md: 600行
- 詳細なルール: 200行
- テンプレート: 200行
- 事例集: 200行

# ✅ OK: 本体はシンプルに、詳細は別ファイルに分離
SKILL.md: 80行（コアルールとトリガーのみ）
templates/
  code-review-output.md: 詳細なフォーマット
  checklist.md: チェックリスト全量

SKILL.mdはClaude Codeのコンテキストウィンドウに読み込まれます。1Skill=100行以内を目安にし、詳細な指示は同じスキルディレクトリ内の別ファイルに分けて@./templates/checklist.mdで参照させるとコンテキスト効率が上がります。

Skillが発火しないときのデバッグ手順

Skillが期待通り動かないときの調査ステップを整理します。

1. /memoryコマンドで読み込み確認
   セッション中に/memoryを実行。Skillのリストに目的のSkillが表示されるか確認。表示されない場合はファイルパスが間違っているか、YAMLフロントマターの構文エラーの可能性。

2. descriptionのトリガー語句を明示的に使う
   自動発火しない場合は/skill-nameのスラッシュコマンドで明示起動。それでも動かなければフロントマターを確認。

3. YAML構文を検証する

   python3 -c "
   import yaml
   with open('.claude/skills/your-skill/SKILL.md') as f:
       content = f.read()
   # YAMLフロントマターを抽出してパース
   front = content.split('---')[1]
   data = yaml.safe_load(front)
   print('OK:', data)
   "
   

4. ファイル権限を確認する
   ls -la .claude/skills/your-skill/でパーミッションを確認。644（読み取り可能）になっているか。

企業でのチーム導入：settings.jsonとの組み合わせ

組織全体にSkillsを展開する場合、settings.jsonと組み合わせてSkillの動作を制御できます。

// .claude/settings.json（プロジェクト共有）
{
  "autoMemoryEnabled": true,
  "permissions": {
    "deny": [
      // セキュリティ監査Skill以外でのnpm publish禁止
      "Bash(npm:publish)"
    ]
  }
}

マネージドポリシー（IT/DevOpsが全ユーザーに強制する設定）は以下のパスに置きます。

• macOS: /Library/Application Support/ClaudeCode/CLAUDE.md
• Linux/WSL: /etc/claude-code/CLAUDE.md

ここにOrgレベルの共通Skillへの@importを書くことで、全開発者が同じベースラインのSkillを使える環境を作れます。

実際に100社以上のAI活用支援をしてきた経験からいうと、Skillsを最も効果的に使っているチームは「コードレビューのコメント品質が均一になった」という効果を真っ先に実感します。シニアエンジニアのレビュー観点をSkillに落とし込むことで、ジュニアメンバーのレビューにも同等のフィードバックが出るようになるのです。

よくある質問（FAQ）

Q1：SkillsはCLAUDE.mdと何が違うのですか？

CLAUDE.mdはセッション開始時に毎回コンテキストウィンドウに読み込まれる「常時有効な指示書」です。一方SkillsはPushオンデマンドで、呼び出した時だけ読み込まれます。毎回必要なルール（コーディング規約など）はCLAUDE.md、特定タスク時だけ必要な深い指示（コードレビュー詳細観点など）はSkillsに書くのが最適な分担です。

Q2：Skillのdescriptionはどう書けばいいですか？

Claudeがそのユーザー発話を見たときに「これはこのSkillを使う場面だ」と判断できる文章を書きます。具体的なトリガー語句を括弧内に列挙する形が効果的です。例："コードレビューを実施する。'review' 'レビューして' 'PR確認' 'コードチェック' で起動。"

Q3：チームメンバーに共有する最も簡単な方法は？

.claude/skills/ディレクトリをGitリポジトリにコミットするだけです。git pullを行えば全メンバーが同じSkillを使える状態になります。個人専用のSkillは~/.claude/skills/（ホームディレクトリ下）に置くと、リポジトリを汚さずに管理できます。

Q4：Skillの数が増えすぎるとどうなりますか？

公式ドキュメントでは特定の上限は示されていませんが、descriptionのトリガー語句が多すぎると発火の曖昧さが生じる場合があります。実務では5〜10個程度で十分なケースがほとんどです。使わなくなったSkillは_deprecated/サブフォルダに移すか削除してください（2026年6月時点）。

Q5：allowed-toolsを省略した場合の動作は？

allowed-toolsを省略した場合、そのSkill実行中はClaudeの通常の権限（セッションの設定に準じたもの）が使われます。Skillの外で許可されていないツールはSkill内でも使えません。セキュリティの観点から、本番環境向けSkillは必ずallowed-toolsを明示することを推奨します。

まとめ：今日から始める3つのアクション

1. 今日やること：プロジェクトに.claude/skills/code-review/SKILL.mdを1つ作り、よく使うレビュー観点を書き込む（パターン1のコードをコピペするだけでOK）。
2. 今週中：チームで「どのワークフローをSkillにしたいか」を話し合い、上位3つのSkillをGitリポジトリに追加してチームで使い始める。
3. 今月中：各Skillの発火ログをレビューし、descriptionのチューニングとallowed-toolsの最小化を行い、セキュリティと使いやすさを両立させる。

Skillsは「プロジェクトの知識をコードと同じようにバージョン管理する」ための仕組みです。スタートはSKILL.md一枚。チームの暗黙知をClaudeが扱える形式に変換するだけで、開発者全員の作業品質が引き上げられます。

---

あわせて読みたい：

• Claude Code Hooks 完全ガイド｜PreToolUse/PostToolUse/Stop 7パターン実装
• コンテキストエンジニアリング完全ガイド｜AI管理・圧縮・予算設計

---

参考・出典

• Claude Code Skills — Anthropic公式ドキュメント（参照日: 2026-06-03）
• How Claude remembers your project — Anthropic公式ドキュメント（参照日: 2026-06-03）
• Claude Code Memory System Explained: 4 Layers, 5 Limits, and a Fix — Milvus Blog（参照日: 2026-06-03）

関連記事（自動）

• ▸ AIエージェント実装ロードマップ｜RAG・実行・運用の必須技術【2026】
• ▸ ReAct・Reflexion他｜AIエージェント推論パターン【2026】
• ▸ ストリーミング応答 実装ガイド｜SSE・トークン逐次表示【2026】
• ▸ コンテキストエンジニアリング完全ガイド｜AI管理・圧縮・予算設計【2026】
• ▸ 本番で落ちないAIエージェントの作り方｜信頼性設計【2026】