Claude Codeには汎用的なAIアシスタントが搭載されています。「スキル（Skills）」を使用すると、それを専門特化させることができます。スキルとは、Kubernetesへのデプロイ、データベースマイグレーションの作成、プルリクエストのレビュー、チームのコーディング規約の遵守など、特定の種類のタスクを処理する方法をClaude Codeに教えるMarkdownファイルのことです。
「Reactコンポーネントを書いて」と「当社のデザインシステムに従い、カスタムフックを使用し、適切なエラー境界とアクセシビリティ属性を備えたReactコンポーネントを書いて」の違いを生むのがスキルです。
Claude Codeの公式ドキュメントでは、現在一つのことが明文化されています。それは、カスタムコマンドがスキルに統合されたことです。`.claude/commands/`にある既存のファイルも引き続き動作しますが、より豊かなメタデータ、サポートファイル、自動読み込みをサポートしているため、スキルが推奨される抽象化レイヤーとなっています。今日、チームのワークフローを標準化するのであれば、まずはスキルとして構築し、レガシーなコマンドは互換性のためのパスとして扱うようにしてください。
スキルの実体とは
スキルは、`SKILL.md`をエントリポイントとするディレクトリ内に配置されます。Claudeは、説明が現在のタスクと一致したときに自動的に読み込むことも、`/skill-name`で直接呼び出すこともできます。
.claude/
skills/
deploy/
SKILL.md # /deploy
review-pr/
SKILL.md # /review-pr
write-test/
SKILL.md # /write-test
Claudeは依然として`.claude/commands/deploy.md`をサポートしており、スラッシュコマンドも機能します。しかし、モダンなバージョンは`.claude/skills/deploy/SKILL.md`です。
これは些細な名称変更のように聞こえるかもしれません。しかし、スキルはサポートファイル、フロントマター、呼び出し制御、サブエージェントへのヒントを保持できるため、非常に重要です。単純なコマンドファイルはClaudeに「何をすべきか」を伝えるだけですが、スキルは「チームがどのように作業が行われることを期待しているか」を伝えることができます。
最初のスキルを書く
実践的な例として、チームのコミットメッセージ規約を強制するスキルを紹介します。
`.claude/skills/commit/SKILL.md`を作成します：
---
name: commit
description: Generate and validate conventional commits for this repo.
---
# Commit Workflow
## Steps
1. Run `git diff --staged` to see what's being committed
2. Analyze the changes and categorize: feat, fix, refactor, docs, test, chore
3. Write a commit message following our convention:
- Format: `type(scope): description`
- Scope is the package or module name
- Description is imperative mood, lowercase, no period
- Body explains WHY, not WHAT
4. If changes touch multiple scopes, create separate commits
5. Run `git commit -m "message"` with the generated message
## Rules
- Never use `--no-verify` to skip hooks
- Never amend published commits
- If tests fail in pre-commit, fix the issue first
## Examples
- `feat(billing): add stripe webhook handler`
- `fix(auth): handle expired refresh tokens`
- `refactor(api): extract rate limiter to shared package`
これで、`/commit`を実行すると、Claude Codeは「変更をコミットして」という曖昧な指示ではなく、構造化されたワークフローを実行するようになります。
既存のレガシーなコマンドファイルがある場合は、移行中も動作させ続けて構いませんが、古いレイアウトへの投資は控えてください。公式ドキュメントでは、スキルが今後の標準であることが明示されています。
スキルの配置場所
Claude Codeは現在、4つの場所からスキルを検出します：
- 個人スキル: `~/.claude/skills/<skill-name>/SKILL.md`
- プロジェクトスキル: `.claude/skills/<skill-name>/SKILL.md`
- モノレポ内のネストされたプロジェクトスキル
- プラグインによって提供されるスキル
これにより、以下のように明確に使い分けることができます：
- 個人スキル：自分自身の作業スタイル用
- プロジェクトスキル：リポジトリの規約用
- プラグインスキル：再利用可能なパッケージ化されたワークフロー用
チームで導入する場合は、プロジェクトスキルをリポジトリにコミットしてください。これが、「自分のPCに便利なプロンプトがある」状態と、「チームが再現可能なワークフローを持っている」状態の差になります。
スキル設計パターン
チェックリストパターン
複数の検証ステップが必要なタスクに最適です。
# Pre-Deploy Checklist
Before deploying, verify each item:
- [ ] `pnpm typecheck` passes
- [ ] `pnpm test` passes
- [ ] No console.log statements in production code
- [ ] Environment variables documented in .env.example
- [ ] Database migrations are reversible
- [ ] API changes are backward compatible
If any check fails, stop and report the issue. Do not proceed with deployment.
決定木パターン
文脈に応じてアプローチが変わるタスクに最適です。
# Bug Fix Workflow
1. Reproduce the bug (find or write a failing test)
2. Identify the root cause:
- If it's a type error → fix the type definition at the source
- If it's a race condition → add proper locking/sequencing
- If it's a missing validation → add schema validation at the boundary
- If it's a logic error → fix and add regression test
3. Verify the fix doesn't break existing tests
4. Write a test that would have caught this bug
テンプレートパターン
一貫した出力を生成するのに最適です。
# New API Endpoint
Create a new API endpoint following our conventions:
## File Structure
- Route handler: `apps/api/src/routes/{resource}/{action}.ts`
- Schema: `apps/api/src/schemas/{resource}.ts`
- Test: `apps/api/src/routes/{resource}/__tests__/{action}.test.ts`
## Required Elements
- Zod schema for request validation
- Authentication middleware
- Rate limiting
- Structured error responses using errorResponse()
- Success responses using successResponse()
- OpenAPI documentation comments
コミュニティスキルのインストール
Claude Codeのエコシステムでは、コミュニティスキルが次々と公開されています。以下のコマンドでインストールできます：
npx add-skill username/repo-name -y
人気のスキルコレクション：
- `coreyhaines31/marketingskills` (29個のマーケティング/SEOスキル)
- `hedging8563/lemondata-api-skill` (LemonData API連携)
インストールされたスキルは`~/.claude/commands/`に表示され、すべてのプロジェクトで使用できます。 インストールされたスキルパックは、単なるスラッシュコマンドのMarkdownではなく、適切なスキルとして公開されることが増えています。独自のリポジトリを管理している場合は、OpenCode + LemonDataのパターンがここでも当てはまります。スキルはアドホックなプロンプトファイルに隠すのではなく、ワークフローの近くに置いてください。
プロジェクトスキル vs グローバルスキル
| 場所 | スコープ | ユースケース |
|---|---|---|
.claude/skills/ |
このプロジェクトのみ | プロジェクト規約、デプロイワークフロー |
~/.claude/skills/ |
すべてのプロジェクト | 個人の好み、再利用可能な習慣 |
.claude/commands/ |
レガシー互換性 | 引き続き動作する古いスラッシュコマンドファイル |
プロジェクトスキルは、チーム全体が恩恵を受けられるよう、リポジトリにコミットすべきです。グローバルスキルは、個人のワークフローの好みのために使用します。
高度な機能：フックを備えたスキル
スキルは、自動的な強制実行のためにフック（特定のイベントで実行されるシェルコマンド）を参照できます：
# Pre-Commit Check
Before any commit, the following hooks run automatically:
- `pre-commit`: runs typecheck + lint
- `post-commit`: updates changelog
If a hook fails, investigate the error output and fix the issue.
Do not use --no-verify to bypass hooks.
フック自体は`.claude/settings.json`で設定します：
{
"hooks": {
"pre-commit": "pnpm typecheck && pnpm lint-staged"
}
}
ここで、スキルは単なるプロンプトの断片以上の存在になります。有用なチーム設定には、多くの場合3つのレイヤーがあります：
- Claudeにワークフローを伝えるスキル
- ワークフローを強制するフック
- 人間にワークフローを説明するリポジトリドキュメント
これらのレイヤーのいずれかが欠けると、システムは脆弱になります。フックのないスキルは単なる推奨事項になり、スキルのないフックは不透明なものになり、どちらもないドキュメントは誰も従わない古いポリシーになってしまいます。
サポートファイルこそが真のアップグレード
古いコマンド形式のMarkdownよりもスキルを優先すべき最も重要な理由は、サポートファイルです。
コマンドファイルでは、すべてを一つの塊の中に記述しなければなりません。スキルディレクトリを使用すると、以下のようなものを分けて保持できます：
- テンプレート
- 例（Examples）
- シェルヘルパー
- 長文のリファレンスノート
- バリデータースクリプト
これにより、`SKILL.md`を短く情報の密度が高い状態に保ちつつ、必要なときにClaudeが参照できる構造化された資料を提供できます。
これは特に以下のような場合に役立ちます：
- デプロイワークフロー
- スキーママイグレーションのチェックリスト
- 多段階のコードレビュープロセス
- 製品固有の統合プレイブック
チームで複数のモデルやコーディングツールを使用している場合は、このページと併せてコーディングモデル比較やCursor / Cline / Windsurfセットアップガイドも参照してください。優れたスキルは、基盤となるモデルやエディタが変わったときにこそ、より重要になります。
効果的なスキルのためのヒント
ファイルパスや命名規則を具体的に指定する。「コンポーネントを作成して」は曖昧です。「`src/components/ui/`にPascalCaseの命名規則でコンポーネントを作成して」であれば実行可能です。
正しい出力の例を含める。Claude Codeは抽象的なルールよりも、例からより良く学習します。
「やってはいけないこと」を定義する。「`any`型は絶対に使用しない」は、「適切な型を使用する」よりも強制力があります。
スキルを絞り込む。1つのワークフローにつき1つのスキルにします。すべてを網羅した200行のスキルよりも、それぞれ1つのタスクを適切に処理する40行の5つのスキルの方が有用です。
スキルをバージョン管理する。規約が進化するにつれて、スキルも更新してください。古いスキルは、古いパターンを強制してしまうため、スキルがないよりも悪影響を及ぼします。
スキルを自動読み込みにするか、手動実行のみにするかを決定する。多くのチームがこれを忘れ、無関係な会話の中でClaudeがデプロイスキルを呼び出してしまうことに困惑しています。
実社会でのインパクト
スキルを導入したチームからは、一貫した改善が報告されています：
- レビュー前に規約が遵守されるため、コードレビューのサイクルが短縮される
- 新しい開発者がベテランと同じガイダンスを受けられるため、オンボーディング時間が短縮される
- AIがプロジェクト標準に関する明示的なコンテキストを持つため、AIが生成するコードの品質が向上する
投資はわずか（最初の数個のスキルを書くのに30分程度）であり、その見返りはあらゆるインタラクションを通じて蓄積されていきます。
最も有用な考え方はこれです：スキルはClaudeのためのショートカットではありません。チームのためのバージョン管理されたワークフロー資産なのです。
もしスキルを1つだけ書くなら、コードベースにおいて最もコストの高い、繰り返される意思決定をエンコードしたものにしてください。
独自のルールに導かれ、AIと共に構築しましょう。LemonDataは、プロバイダーをまたいでコーディングモデルを利用できる単一のAPIキーを提供します。ワークフローをスキルとしてエンコードしてしまえば、ツールチェーン全体を再構築することなくモデルを切り替えることができます。