Claude Code Skillsの使い方とおすすめSkill集｜再利用可能なノウハウを蓄積

Claude Codeを使い込んでいくと、「この指示の出し方がうまくいった」「このステップ順なら安定する」「この観点を入れると品質が上がる」といったノウハウが蓄積されていきます。しかし、それが個人の記憶やSlackの投稿に埋もれていては、チームの資産になりません。

Claude Code Skillsは、こうしたノウハウを構造化されたファイルとして定義し、チームで共有・再利用するための仕組みです。スラッシュコマンドと混同されがちですが、位置づけと用途が異なります。

本記事では、Skillsの仕組みとスラッシュコマンドとの違い・Skillファイルの作り方・実用的な5つの例・チーム共有の方法・Skill同士の組み合わせパターンを解説します。Claude Codeの基本についてはClaude Code完全ガイドを参照してください。

結論 — Skillsは「うまくいくプロンプトのパッケージ化」

Skillsの本質は、Claude Codeに対する効果的な指示パターンを、再利用可能な単位でパッケージ化することです。

試行錯誤の結果たどり着いた「この順番で、この観点で指示すると安定して良い結果が出る」という知見を、Markdownファイルに構造的に記述する。これにより、ノウハウが属人化せず、新メンバーでもベテランと同じ品質の作業ができるようになります。

Skillsとスラッシュコマンドの違い

混同されがちなこの2つの機能を整理します。

観点	スラッシュコマンド	Skills
定義場所	.claude/commands/	.claude/skills/ またはSkill Marketplace
呼び出し方	/command-name で直接実行	セッション中に自動的にロードまたは明示的に呼び出し
適用範囲	1回のタスク実行	セッション全体の行動ガイド
複雑さ	単一のプロンプト	構造化された手順・ルール・制約
再利用性	プロジェクト内	Marketplace経由でプロジェクト横断
典型的な用途	コミット作成、テスト生成	セキュリティ監査、設計レビュー

端的に言えば: スラッシュコマンドは「やってほしいことの指示」、Skillsは「どう振る舞ってほしいかの定義」です。

# スラッシュコマンド（/review）→ 1回のアクション
「この差分をレビューして、問題を報告して」

# Skills（security-review）→ 行動の指針
「セキュリティ観点でコードを分析するとき、
 常にこの手順・この観点・この出力形式に従って」

Skillファイルの作り方

基本構造

Skillsは .claude/skills/ ディレクトリにMarkdownファイルとして配置します。

.claude/
├── commands/        # スラッシュコマンド
│   ├── review.md
│   └── commit.md
└── skills/          # Skills
    ├── security-audit.md
    ├── performance-review.md
    └── api-design-review.md

Skillファイルの基本構造は以下の通りです。

# Skill: セキュリティ監査

## 目的
コードベースのセキュリティリスクを検出し、修正案を提示する。

## 対象
- 指定されたファイルまたはディレクトリ
- 指定がない場合は git diff --name-only で変更ファイルを対象とする

## 手順
1. 対象ファイルの一覧を取得する
2. 各ファイルについて以下の観点でレビューする
   - （観点リスト）
3. 検出した問題を分類する
4. 修正案を提示する

## 出力形式
（テーブルやリストの形式を定義）

## 制約
- 実装の変更は行わない（報告のみ）
- 誤検出の可能性がある場合はその旨を明記する

ポイントは「手順」「出力形式」「制約」を明確に定義することです。この3つが曖昧だと、Skillを実行するたびに異なる結果が出てしまい、再利用性が損なわれます。

Skill Marketplaceからのインストール

コミュニティや他の開発者が公開しているSkillsを、Skill Marketplaceからインストールして利用できます。

# Marketplaceからインストール
claude skill install security-audit

# インストール済みSkillの一覧
claude skill list

Marketplaceからインストールしたスキルは内容を確認してから使用することを推奨します。Skillsの定義はプロンプト（テキスト）ですが、その指示に従ってClaude Codeが実行するコマンドは実環境に影響を与えるためです。

5つの実用Skill例

1. セキュリティ監査Skill

# Skill: セキュリティ監査

## 目的
対象コードのセキュリティリスクを網羅的に検出し、重要度別に報告する。

## 対象
$ARGUMENTS で指定されたファイルまたはディレクトリ。
指定がない場合は git diff --name-only で変更ファイルを対象とする。

## チェック項目

### 1. 秘密情報の漏洩
- ハードコードされたAPIキー、トークン、パスワード
- .env ファイルがGit管理に含まれていないか
- ログ出力に秘密情報が含まれていないか

### 2. 入力バリデーション
- SQLインジェクション（パラメタライズドクエリの使用）
- XSS（ユーザー入力のサニタイズ）
- パストラバーサル（ファイルパスの正規化）
- コマンドインジェクション（シェルコマンドの組み立て）

### 3. 認証・認可
- 認証チェックの漏れ（ミドルウェアの適用忘れ）
- 認可チェックの漏れ（リソースの所有者確認）
- セッション管理の脆弱性

### 4. 依存パッケージ
- 既知の脆弱性（pnpm audit の結果）
- メンテナンスが停止しているパッケージ

## 出力形式
| 重要度 | カテゴリ | ファイル:行 | 問題 | 修正案 |
|--------|---------|-----------|------|--------|
| Critical | 秘密情報 | src/config.ts:15 | APIキーがハードコード | 環境変数に移動 |

## 制約
- コードの変更は行わない（報告のみ）
- 誤検出の可能性がある場合は「要確認」と付記する
- Critical/High は必ず対処、Medium/Low は推奨として報告する

2. パフォーマンス分析Skill

# Skill: パフォーマンス分析

## 目的
指定コードのパフォーマンスボトルネックを検出し、改善案を提示する。

## 対象
$ARGUMENTS で指定されたファイル。

## チェック項目

### データベース
- N+1クエリ（ループ内でのDB呼び出し）
- インデックスなしの検索条件
- 不要な全件取得（SELECT *）

### React（フロントエンド）
- 不要な再レンダリング（memo/useMemo/useCallbackの欠落）
- useEffect内の重い処理
- 巨大なコンポーネントツリー（コード分割の候補）
- 画像の最適化不足（next/image未使用）

### 一般
- ループ内のAPI呼び出し
- 同期処理で代替可能な非同期処理
- メモリリーク（イベントリスナーの解除忘れ）
- 巨大なJSON文字列のパース

## 出力形式
各問題について以下を報告：
- 問題の説明
- 影響度（高/中/低）
- 改善案（コード例つき）
- トレードオフ（可読性・保守性への影響）

## 制約
- 実測値ではなく静的分析に基づく推定であることを明記する
- 早すぎる最適化にならないよう、影響度が低い問題は「計測してから対処」を推奨する

3. API設計レビューSkill

# Skill: API設計レビュー

## 目的
APIエンドポイントの設計品質をレビューし、一貫性と RESTful 慣例への準拠を確認する。

## 対象
$ARGUMENTS で指定されたAPIルートファイル。
指定がない場合は src/app/api/ 配下の全ルートを対象とする。

## チェック項目

### エンドポイント命名
- リソースは複数形（/users, /orders）
- ネストの深さは2階層まで（/users/:id/orders まで）
- 動詞はHTTPメソッドで表現（POST /users, NOT POST /create-user）

### HTTPメソッド
- GET: 副作用なし、冪等
- POST: リソース作成
- PUT/PATCH: リソース更新（PUT=全体置換, PATCH=部分更新）
- DELETE: リソース削除

### レスポンス
- ステータスコードの妥当性（200/201/204/400/401/403/404/500）
- エラーレスポンスの形式統一（code, message, details）
- ページネーションの一貫性（cursor vs offset）
- Content-Typeの適切な設定

### セキュリティ
- 認証ミドルウェアの適用
- 入力バリデーション（Zodスキーマ）
- レート制限の設定

## 出力形式
エンドポイントごとに準拠/非準拠を表形式で報告し、
非準拠の項目には具体的な修正案を付記する。

4. マイグレーション安全チェックSkill

# Skill: マイグレーション安全チェック

## 目的
データベースマイグレーションの安全性を検証し、本番適用のリスクを評価する。

## 対象
未適用のマイグレーションファイル。

## チェック項目

### 破壊的変更
- カラムの削除（データ喪失のリスク）
- カラムの型変更（データ変換の失敗リスク）
- NOT NULL制約の追加（既存データとの整合性）
- テーブルの削除（依存するコードの確認）

### 実行時の影響
- 大規模テーブルへのALTER（ロック時間の見積もり）
- インデックスの追加（CREATE INDEX CONCURRENTLY の使用）
- データ移行を伴う変更（バッチサイズの考慮）

### ロールバック可能性
- 各マイグレーションに対応するロールバック手順の有無
- ロールバック時にデータが失われないか

## 判定
| 判定 | 基準 | 対応 |
|------|------|------|
| 安全 | 非破壊的、ロック時間短い | そのまま適用可能 |
| 注意 | 大規模テーブル対象、インデックス追加 | メンテナンスウィンドウで実行 |
| 危険 | 破壊的変更、ロールバック不可 | 段階的移行計画を策定 |

## 制約
- 「危険」判定の場合は代替手順（段階的移行、ダウンタイムなし移行）を提案する
- テーブルの行数が不明な場合は確認方法を提示する

5. コンポーネント設計レビューSkill

# Skill: コンポーネント設計レビュー

## 目的
Reactコンポーネントの設計品質をレビューし、保守性・テスタビリティの改善案を提示する。

## 対象
$ARGUMENTS で指定されたコンポーネントファイル（.tsx）。

## チェック項目

### Props設計
- Props型がinterfaceで定義されているか
- Props数が3個以下に収まっているか（超過はオブジェクト引数に）
- 必須/オプショナルの区別が適切か
- children の型が適切か

### 責務の単一性
- 1コンポーネント1責務か
- 表示ロジックとビジネスロジックが分離されているか
- コンポーネントのファイルサイズが400行以内か

### 状態管理
- useState の数が適切か（3個以上は useReducer を検討）
- 状態のリフトアップが必要な箇所がないか
- 不要なグローバル状態がないか

### useEffect
- 依存配列が正しいか
- クリーンアップ関数が必要な処理で返されているか
- useEffect内で状態を更新していないか（無限ループリスク）

### アクセシビリティ
- インタラクティブ要素に適切なroleとaria属性があるか
- キーボード操作が可能か
- 画像にalt属性があるか

## 出力形式
各チェック項目について PASS/FAIL を表形式で報告し、
FAILの項目にはリファクタリング案（Before/After付き）を提示する。

チームでのSkill共有

.claude/skills/ をリポジトリに含める

プロジェクト固有のSkillsはリポジトリにコミットして共有します。チームメンバーがリポジトリをクローンするだけで、同じSkillsが利用可能になります。

.claude/
├── commands/        # アクション（/review, /commit）
├── skills/          # 行動ガイド（セキュリティ監査、設計レビュー）
└── settings.json    # Hooks設定

PRベースでSkillを改善する

Skillsの追加・修正もPRを通じて管理します。

# PRの例
feat: API設計レビューSkillにGraphQLエンドポイントのチェックを追加

REST APIのチェック項目は充実しているが、GraphQLの
リゾルバ・スキーマ設計のチェックが不足していたため追加する。

Skillの改善サイクル

Skillsは一度作ったら完成ではありません。以下のサイクルで改善していきます。

1. 使ってみる: Skillを実行して結果の品質を評価する
2. 誤検出を記録する: False Positiveが出た場合は、Skillの定義を修正する
3. 観点の追加: レビューで繰り返し指摘される項目をSkillに追加する
4. 定期的に棚卸し: 四半期ごとに、使われていないSkillの整理と新しいSkillの追加を行う

組織横断のSkill共有

複数のプロジェクトで共通して使えるSkills（セキュリティ監査、パフォーマンス分析など）は、組織共通のリポジトリで管理する構成が効率的です。

org-claude-skills/           # 組織共通のSkillsリポジトリ
├── security-audit.md        # 全プロジェクト共通
├── performance-review.md    # 全プロジェクト共通
└── accessibility-check.md   # 全プロジェクト共通

project-a/.claude/skills/
├── api-design-review.md     # プロジェクト固有
└── -> org-claude-skills/security-audit.md  # 組織共通をシンボリックリンク

Skill組み合わせパターン

直列実行パターン

1つのSkillの出力を次のSkillの入力として使う構成です。

セキュリティ監査Skill → 検出された問題リスト
    ↓
パフォーマンス分析Skill → パフォーマンス問題リスト
    ↓
問題の統合・優先度付け → 修正計画

Claude Codeのセッション中に「まずセキュリティ監査Skillを実行して、次にパフォーマンス分析Skillを実行して、最後に両方の結果を統合して優先度をつけてほしい」と指示することで、直列に実行できます。

並列実行パターン（Worktreeと組み合わせ）

Worktreeを活用して、複数のSkillを並列に実行するパターンです。

Worktree-1: セキュリティ監査Skill を実行中
Worktree-2: パフォーマンス分析Skill を実行中
    ↓
両方の結果を集約して修正計画を策定

対象範囲が大きい場合は、並列実行によって分析時間を短縮できます。

条件分岐パターン

あるSkillの結果に基づいて、次に実行するSkillを切り替えるパターンです。

コンポーネント設計レビューSkill を実行
    ↓
結果に「状態管理の問題」が含まれる場合
    → パフォーマンス分析Skill で再レンダリングの影響を分析
結果に「Props設計の問題」が含まれる場合
    → API設計レビューSkill でデータフローを確認

よくある質問

まとめ — Skillsでチームのノウハウを資産化する

Claude Code Skillsは、試行錯誤で得られたプロンプトのノウハウを、構造化されたファイルとしてチーム全体で共有・再利用する仕組みです。

スラッシュコマンドとの違いを理解し、適切に使い分けることが重要です。スラッシュコマンドは「単発のアクション」、Skillsは「行動のガイドライン」。この区分を意識すれば、どちらに定義すべきかの判断に迷うことはなくなります。

まずはチームで最も頻繁に行っている複合的な作業（セキュリティチェック、設計レビューなど）を1つSkillとして定義するところから始めてみてください。そのSkillが安定した結果を出すようになったら、次のSkillに取りかかる。この積み重ねが、チーム全体のAI活用レベルを引き上げていきます。

関連記事

• Claude Code完全ガイド｜開発組織が今知るべき導入判断の全体像