Claude Code Skills完全ガイド|作り方・使い方・コピペOKテンプレート5選

chars:4001 tbl:4 code:8 int:5 ext:0 faq:3

Claude Code Skillsって何?どう作るの?——この記事では、Skillsの仕組み・作り方・使い方・おすすめの活用法を、コピペで使える実例付きで解説します。

Skillsを使えば「毎回同じ指示を打つ」手間がゼロになる。よく使うワークフローを1回登録するだけで、スラッシュコマンドで何度でも呼び出せる。公式ドキュメントでもSkillsの活用を推奨している。

Claude Code Skillsとは?

Skillsは、よく使う指示やワークフローを保存して再利用する仕組みです。Markdownファイルに手順を書いて配置するだけで、スラッシュコマンドとして呼び出せる。1度作れば何十回でも再利用可能。

イメージとしては「マクロ」や「ショートカット」です。「コードレビューしてフィードバックを箇条書きで出して」という長い指示を、/review-codeの一言で実行できるようにするのがSkillsです。

Skillsの3つの種類

種類場所誰が使えるか
プロジェクトSkills.claude/commands/このプロジェクトの全メンバー
ユーザーSkills~/.claude/commands/自分だけ(全プロジェクト共通)
バンドルSkillsClaude Code組み込み全員(/code-review, /simplify等)

Skillsの仕組みを図で理解する

Claude Code Skillsの仕組み図解

ポイントは「セッション開始時にロードされない」という点です。CLAUDE.mdは毎回ロードされるため肥大化するとパフォーマンスが落ちますが、Skillsはいくら増やしても影響ゼロです。呼び出した時だけ読み込まれます。

つまり、CLAUDE.mdに書いていたワークフロー(「コードレビューの手順」「テスト作成の規約」等)をSkillsに移すだけでCLAUDE.mdが軽くなり、遵守率が上がるという副次効果もあります。

Skillsの作り方|3ステップで完成

Step 1: commandsディレクトリを作る

# プロジェクト用(チーム共有)
mkdir -p .claude/commands

# ユーザー用(個人)
mkdir -p ~/.claude/commands

Step 2: Markdownファイルを作る

ファイル名がスラッシュコマンド名になります。例えば review-code.md を作ると、/review-code で呼び出せる。1度作れば何十回でも再利用可能。

# .claude/commands/review-code.md

このプロジェクトの最新の変更をレビューしてください。

以下の観点でチェック:
1. バグや論理エラーがないか
2. セキュリティの問題がないか
3. パフォーマンスの問題がないか
4. コーディング規約に沿っているか

フィードバックは箇条書きで、重要度順に出してください。

Step 3: 使う

# Claude Codeセッション内で
/review-code

たったこれだけ。所要時間は3分。ファイルを置くだけで自動的にスラッシュコマンドとして認識される。

YAML frontmatterで詳細設定

Markdownファイルの冒頭にYAML frontmatterを書くと、Skillの動作を詳細に制御できる:

# .claude/commands/deploy.md
---
description: "本番環境にデプロイする"
allowed-tools: ["Bash", "Read", "Write"]
model: opus
---

本番環境へのデプロイを実行してください。

手順:
1. テストを全て実行して通ることを確認
2. git statusで未コミットの変更がないか確認
3. mainブランチにマージ
4. デプロイコマンドを実行: vercel --prod
5. デプロイ後のヘルスチェック
フィールド説明
descriptionコマンド一覧に表示される説明文「本番環境にデプロイする」
allowed-toolsSkillの実行中に使えるツールを制限[“Bash”, “Read”]
modelこのSkillで使用するモデルを指定opus / sonnet

frontmatterはなくても動作する。シンプルなSkillにはなしで十分。デプロイや本番操作のような慎重さが必要なSkillにのみ設定するのがおすすめ。

Skill Creatorで自動生成する

Claude Codeの/skill-creatorスキルを使うと、対話形式でSkillを設計・テスト・最適化できる。

# Skill Creatorの使い方
/skill-creator

# → 「どんなSkillを作りたいですか?」と聞かれる
# → 「コードレビューのSkillを作りたい」と回答
# → 要件をヒアリングしてSkillファイルを自動生成
# → テスト実行して品質を確認
# → 問題があれば自動修正

手動でMarkdownを書くのが面倒な場合や、最適な記述方法が分からない場合に活用する。Skill Creatorが生成したファイルを手動で微調整すると、さらに精度が上がる。

コピペで使えるSkill集5選

1. /seo-check(SEO改善チェック)

# .claude/commands/seo-check.md

このページのSEOを分析してください。

チェック項目:
- title タグにターゲットKWが含まれているか
- meta description が120文字以内か
- H1が1つだけか
- H2にKWが含まれているか
- 画像にaltタグがあるか
- 内部リンクが3本以上あるか

問題があれば修正案を提示してください。

2. /commit-ja(日本語コミット)

# .claude/commands/commit-ja.md

変更内容を確認し、日本語のコミットメッセージを作成してコミットしてください。

コミットメッセージのルール:
- 1行目:変更の要約(50文字以内)
- 2行目:空行
- 3行目以降:変更の詳細(箇条書き)

例:
記事タイトルのSEO改善

- CTRが低い3記事のタイトルを変更
- KW「Claude Code 使い方」を含める形に修正

3. /test-write(テスト生成)

# .claude/commands/test-write.md

$ARGUMENTS のテストを書いてください。

ルール:
- テストフレームワークはプロジェクトの既存テストに合わせる
- 正常系と異常系の両方を書く
- エッジケース(空文字、null、境界値)を含める
- テスト名は日本語で書く

$ARGUMENTS はスラッシュコマンド実行時に渡す引数です。/test-write src/utils/calculate.ts のように使います。

4. /explain(コード解説)

# .claude/commands/explain.md

$ARGUMENTS のコードを初心者にも分かるように解説してください。

解説のルール:
- 各行の役割を日本語コメントで説明
- 使われているデザインパターンがあれば説明
- 改善できる箇所があれば提案

5. /fix-error(エラー修正)

# .claude/commands/fix-error.md

以下のエラーを修正してください。

$ARGUMENTS

手順:
1. エラーの原因を特定
2. 修正案を提示(変更前/変更後を明示)
3. 修正を適用
4. テストを実行して動作確認
5. 修正内容を日本語で報告

Skills vs CLAUDE.md vs rules|何が違う?

機能用途読み込みタイミング
CLAUDE.mdプロジェクト全体のルールセッション開始時(毎回)「sedでPHPを編集しない」
rules/ファイル種別ごとのルール条件付き(特定ファイル操作時)「PHPファイルはPythonで編集」
Skills再利用可能なワークフロー呼び出し時のみ「/review-code」で起動

最も重要な違い:Skillsはセッション開始時にロードされない。つまりSkillsをいくら増やしても、CLAUDE.mdの肥大化問題が起きません。これがSkillsの最大のメリットです。

CLAUDE.mdの書き方は「書き方ガイド」、CLAUDE.mdとは何かは「CLAUDE.mdとは?」をご覧ください。

Skillsの設計思想:Progressive Disclosure

Skillsの設計にはProgressive Disclosure(段階的開示)という重要な概念があります。これは「必要な情報を、必要な時にだけ読み込む」という設計思想です。

Layer何が読まれるかいつ読まれるか
Layer 1: CLAUDE.mdプロジェクトの最重要ルールセッション開始時(毎回)
Layer 2: .claude/rules/ファイル種別ごとのルール該当ファイル操作時
Layer 3: Skillsワークフロー・手順書呼び出し時のみ

Skills(Layer 3)はセッション開始時に一切ロードされません。つまりSkillsをいくら増やしても、セッションの起動速度やトークン消費に影響しないのです。これがCLAUDE.mdとの最大の違いです。

実務では「CLAUDE.mdが60行を超えそうになったら、ワークフロー部分をSkillsに移す」のがベストプラクティスです。

バンドルSkills一覧(組み込み済み)

Claude Codeには最初から使えるバンドルSkillsが含まれています。

コマンド内容
/code-reviewdiffをレビューしてバグをチェック
/simplifyコードのクリーンアップ(再利用性・簡潔化)
/batch大規模タスクを分解して並列実行
/claude-apiClaude APIのリファレンスを読み込み
/install-github-appGitHub Actionsアプリのセットアップ

全コマンドの一覧は「コマンド早見表」をご覧ください。

Skillsを効果的に設計する5つのコツ

  1. 1 Skill = 1タスク — 「レビュー+テスト+コミット」を1つのSkillに詰め込まない。分けた方がClaude Codeの精度が上がる。分けたSkillを連続実行することは可能(/review-code/test-write/commit-ja
  2. 出力形式を指定する — 「箇条書きで」「テーブルで」「Markdown形式で」と書くだけで出力が安定する。フォーマットを統一すると、後続の処理(他のSkillへの入力や人間によるレビュー)が楽になる
  3. $ARGUMENTSを活用する — 汎用的なSkillにして引数で対象を指定する方が再利用性が高い。例えば/test-write src/auth.tsのように使えば、1つのSkillで全ファイルのテスト生成をカバーできる
  4. YAML frontmatterでメタデータを書く — descriptionフィールドを書くとコマンド一覧に説明が表示される。allowed-toolsで使用ツールを制限すればセキュリティも向上
  5. チームで共有する — プロジェクト用Skillsは.claude/commands/に置いてGit管理。「うちのチームの標準レビュー手順」として共有

Skillのデバッグ方法

Skillが思い通りに動かない場合のトラブルシューティング:

問題原因対処法
スラッシュコマンドが表示されないファイルの場所が間違っている.claude/commands/直下にあるか確認。サブディレクトリは非対応
$ARGUMENTSが空引数なしで実行した/skill-name 引数テキストのようにスペースの後に引数を記述
指示通りに動かない指示が曖昧「〜してください」→「以下のステップで実行: 1. 2. 3.」のように手順化
出力形式がバラバラ出力フォーマット未指定「箇条書きで出力」「テーブル形式で」等を明記
他のSkillと名前が競合同名ファイルが複数存在プロジェクト用とユーザー用で同名の場合、プロジェクト用が優先
# Skillの一覧を確認
# セッション内で / を入力すると、利用可能なコマンド一覧が表示される
/

# Skillの内容を確認
# Claude Codeに直接聞く
> /review-code のスキルの内容を教えて

実際に役立ったSkillの実例

私が実際のプロジェクトで使って特に役立ったSkillを紹介する:

WordPressサイト向け: /wp-qa(品質監査)

# .claude/commands/wp-qa.md

$ARGUMENTS の記事の品質を以下の観点でチェックしてください。

SEOチェック:
- titleタグにKWが含まれているか
- meta descriptionが120文字以内か
- H2/H3構造が適切か
- 画像altタグが全て設定されているか
- 内部リンクが3本以上あるか
- 外部リンクが1本以上あるか

読者目線チェック:
- 初心者が読んで理解できるか
- 専門用語に説明がついているか
- 「結局どうすればいいの?」に答えているか

問題があれば具体的な修正案を出してください。

このSkillでWordPressサイトの130記事以上のQAを実施した。手動なら1記事10分×130記事=21時間以上かかる作業が、/wp-qaを使うことで1記事2分×130記事=約4時間に短縮された。Skillの「再利用性」が最も活きた事例。

よくある質問

Q: Skillsの数に制限はある?

ありません。セッション開始時にロードされないため、数を増やしてもパフォーマンスに影響しない。10個作っても100個作ってもゼロ。

Q: SkillsをGit管理すべき?

プロジェクトSkills(.claude/commands/)はGit管理してチーム共有するのがおすすめです。ユーザーSkills(~/.claude/commands/)は個人用なのでGit管理不要です。

Q: $ARGUMENTSとは?

スラッシュコマンド実行時にスペースの後ろに書いたテキストが$ARGUMENTSに入る。/test-write src/utils.tsと打つと、Skill内の$ARGUMENTSsrc/utils.tsに置き換わる。複数引数を渡すことも可能で、Skill側で「1番目の引数はファイルパス、2番目は操作内容」のように解釈させることもできる。

Q: Skillを自動で作ってくれる機能はある?

ある。Claude Codeに「このワークフローをSkillとして保存して」と指示すると、Markdownファイルを自動生成してくれる。さらに/skill-creatorというビルトインSkillを使えば、対話形式でSkillを設計できる。→公式のSkill作成ガイド

Q: Agent Skills(SKILL.md)との関係は?

2026年からAgent Skills規格が導入された。従来のカスタムコマンド(.claude/commands/*.md)に加えて、SKILL.mdファイルにAgent Skills仕様で記述すると、Claude.ai・Claude Code・Claude APIで横断的に利用できる。ただし従来のコマンド方式でも問題なく動作するため、まずはこの記事のテンプレートで始めて、必要に応じてAgent Skillsに移行するのがおすすめ。

Skillsの実践的な運用Tips

CLAUDE.mdの肥大化をSkillsで解決する

CLAUDE.mdが60行を超えた場合、ワークフロー部分をSkillsに移すのがAnthropicのベストプラクティスで推奨されている。

Before: CLAUDE.md 120行(コードレビュー手順30行+テスト規約20行+デプロイ手順25行+ルール45行)

After: CLAUDE.md 45行(ルールのみ)+ Skills 3本(/review-code, /test-write, /deploy)

Skillsに移すことで、CLAUDE.mdのトークン消費が1/3に削減され、ルール遵守率が改善した。→「CLAUDE.md書き方ガイド」「肥大化対策

チームでSkillsを標準化する

チーム開発では、プロジェクトSkills(.claude/commands/)をGit管理して「チームの標準ワークフロー」として共有する。新メンバーが入ったら「まず/review-codeと/commitを使ってみて」と案内するだけで、チーム全体の品質が統一される。

Skills変更はCLAUDE.mdと同様にPRベースでレビューすると、「なぜこの手順を変えたか」の記録が残る。

非エンジニア向けSkill活用例

Skillsはプログラマーだけのものではない。ビジネス用途でも強力に使える:

Skillやること対象者
/csv-reportCSVデータを読み込んで月次レポートを自動生成営業・経理
/translate-docドキュメントを指定言語に翻訳マーケター
/meeting-summary議事録テキストから決定事項・TODO・次回議題を抽出PM・ディレクター
/blog-outlineターゲットKWからブログ記事のH2/H3構成案を生成ライター
/data-cleanCSVの重複削除・空白行除去・日付フォーマット統一データ担当

これらはプログラミング知識ゼロでも作れる。「何をしてほしいか」を日本語で書くだけ。→「非エンジニア活用術

まとめ|Skillsで「毎回同じ指示を打つ」をゼロに

Skillsは「Markdownファイルを置くだけ」で作れる、最も手軽な自動化の仕組み。

今すぐ始める3ステップ:

  1. mkdir -p .claude/commands でディレクトリを作る
  2. 上の5つのテンプレートから1つをコピペして.claude/commands/に保存
  3. Claude Codeセッション内で/コマンド名を実行して動作確認

1つ作って動くことを確認したら、自分の業務で「毎回同じ指示を打っている」作業をSkillにしていく。130記事のQAを/wp-qaで21時間→4時間に短縮したように、Skillsは使えば使うほど時間を取り戻してくれる仕組み。Skillsをいくら増やしてもCLAUDE.mdと違ってセッション開始時のトークン消費に影響しないので、気軽にどんどん作ってよい。

Claude Codeの使い方は「使い方ガイド」、始め方は「始め方ガイド」、コマンド全一覧は「コマンド早見表」、CLAUDE.mdの書き方は「書き方ガイド」、料金は「料金ガイド」を参照。

参考文献・公式リソース