はじめに
Claude Skillsという機能、名前は聞いたことがあるけれど「自分には関係ない」と感じていませんか？
実はSkillsは、「Claudeをよく使う人ほど恩恵が大きい機能」 です。
でも「どんな時に使えばいいの？」というのが一番わかりにくい部分でもあります。
■ 検索ボリューム（2026年時点の推定）
- 10～100: "claude skills 例", "claude skills おすすめ"この記事では、よくある利用シーン7パターン を具体的に解説します。「あ、これ自分のことだ」と感じたものがあれば、それがあなたにとってのSkill化のタイミングです。
「Skill化すべきサイン」チェックリスト
まず、以下の項目に当てはまるものはありますか？
- 同じ指示やプロンプトを1週間に3回以上コピペしている
- 「いつものやり方で」とClaudeに伝えることが多い
- チームで同じClaudeの使い方を揃えたいと思っている
- 間違えて実行されたくない重要な操作がある
- 複数ステップの作業を毎回手動で指示している
1つでも当てはまれば、Skills化が効きます。
パターン1：毎回同じ手順を繰り返している
こんな人に当てはまる
「GitHubにPRを出す前に、コードレビュー → テスト実行 → コミットメッセージ確認という手順を毎回Claudeに説明している」
Skill化するとどうなる
---
name: pre-pr-check
description: PRを出す前の事前チェックを実行する。Use when the user wants to
prepare a pull request or before submitting code for review.
---
PRを出す前に以下を順番に確認してください：
1. 変更ファイルの一覧を確認（git diff --name-only）
2. テストを実行して全件グリーンか確認
3. コミットメッセージが規約に沿っているか確認
4. レビュアーへのコメント案を作成/pre-pr-check と打つだけで全手順が流れます。
判断基準: 「また同じことを説明してるな」と感じた瞬間がSkill化のサイン
パターン2：長い説明をCLAUDE.mdに書いてしまっている
こんな人に当てはまる
「CLAUDE.mdにAPI設計の規約、コーディング規約、デプロイ手順、レビュー観点…と書き続けたら300行を超えてしまった」
Skill化するとどうなる
| 読み込みタイミング | CLAUDE.md | SKILL.md |
|---|---|---|
| セッション開始時 | 毎回全文を読み込む | descriptionのみ（軽量） |
| 作業時 | 常時消費 | 呼んだ時だけ読み込む |
CLAUDE.mdは「常に適用されるルール」だけに絞り、デプロイ手順や詳細なレビュー観点はSKILL.mdに移すと、コンテキストの無駄遣いが減ります。
CLAUDE.md → 言語設定、基本方針、短いルール（50行以内が理想）
SKILL.md → デプロイ手順、詳細なコーディングガイド、長い手順書判断基準: CLAUDE.mdが100行を超えてきたら、手順系はSKILL.mdへ移す検討を
パターン3：チームで作業の品質にバラつきが出ている
こんな人に当てはまる
「コードレビューの観点が人によって違う。Aさんはセキュリティ重視、BさんはパフォーマンスのみでOKを出してしまっている」
Skill化するとどうなる
.claude/skills/code-review/SKILL.md をgitリポジトリに追加するだけで、チーム全員が /code-review を使うと同じ観点・同じ品質でレビューできるようになります。
---
name: code-review
description: コードレビューを実施する。Use when reviewing code changes or
pull requests.
---
以下の観点でコードをレビューしてください：
## セキュリティ
- 入力値のバリデーションはされているか
- 認証・認可の漏れはないか
- SQLインジェクション、XSSのリスクはないか
## パフォーマンス
- N+1クエリが発生していないか
- 不要なループや重複処理はないか
## 可読性
- 変数名・関数名が意図を伝えているか
- コメントは必要な箇所に書かれているか判断基準: チームで「このやり方で統一しよう」と決めた作業はプロジェクトSkill化が最適
パターン4：間違えて実行されたくない重要な操作がある
こんな人に当てはまる
「デプロイコマンドを自動実行する設定にしていたら、開発環境向けコマンドが本番に流れてヒヤッとした」
Skill化するとどうなる
---
name: deploy-production
description: 本番環境へデプロイする
disable-model-invocation: true ← ユーザーが明示的に呼ばない限り絶対に起動しない
allowed-tools: Bash
---
本番環境へのデプロイを実行します：
$ARGUMENTS（staging / production）
1. テストスイートが全件グリーンであることを確認
2. ステージングでの動作確認を確認
3. デプロイコマンドを実行
4. デプロイ後のヘルスチェックを確認disable-model-invocation: true を設定すると、Claudeが「デプロイの話をしているな」と判断しても絶対に自動起動しません。/deploy-production と自分で打った時だけ動きます。
判断基準: 「うっかり実行されたら困る」操作は必ず
disable-model-invocation: trueを付ける
パターン5：複数ステップの調査・分析作業を繰り返している
こんな人に当てはまる
「バグ報告が来るたびに『ログ確認 → 関連ファイル検索 → 原因候補の列挙 → 修正案の提示』という手順を毎回Claudeに指示している」
Skill化するとどうなる
---
name: investigate-bug
description: バグを調査して原因と修正案を提示する。Use when a bug is reported
or something is not working as expected.
argument-hint: [bug-description]
---
以下の手順でバグを調査してください：
## 調査対象
$ARGUMENTS
1. エラーログを確認（logs/ ディレクトリを検索）
2. エラーメッセージに関連するファイルを特定
3. コードを読んで原因候補を3つ列挙
4. 各候補の修正案を提示
5. 最も可能性が高い原因と推奨対応を最後にまとめる/investigate-bug ログインボタンを押すと500エラーになる と一言で全プロセスが走ります。
判断基準: 「いつもこの手順で調査してるな」という作業はSkill化の候補
パターン6：特定のフォーマットで毎回アウトプットを出している
こんな人に当てはまる
「週次レポートをまとめる時、毎回『この形式で出してください』とフォーマットを貼り付けてからClaudeに依頼している」
Skill化するとどうなる
---
name: weekly-report
description: 週次レポートを作成する。Use when creating a weekly summary,
progress report, or status update.
argument-hint: [対象期間]
---
以下のフォーマットで週次レポートを作成してください：
---
## 週次レポート：$ARGUMENTS
### 今週の成果
- （箇条書きで3〜5件）
### 来週の予定
- （箇条書きで3〜5件）
### 課題・ブロッカー
- （なければ「なし」と記載）
### 数値実績
| 指標 | 目標 | 実績 | 達成率 |
|------|------|------|--------|
---/weekly-report 2026年3月第4週 だけで指定フォーマット通りのレポートが完成します。
判断基準: 「毎回このフォーマットで」と言っている場合はSkill化が有効
パターン7：大量のファイルを横断して調査・変換する作業がある
こんな人に当てはまる
「古い書き方のコードを新しい書き方に全部変換したい。でも100ファイルあって手動では無理」
Skill化するとどうなる
組み込みの /batch スキルがこのケースに最適です。
/batch 全ファイルのコールバック関数をasync/awaitに書き換えてください/batch スキルが自動で：
- コードベース全体を調査
- 対象ファイルを特定
- 作業を独立したユニットに分割（5〜30個）
- 並列で一括変換
- 各変更にPRを作成
大規模な一括変換が /batch 一発で完結します。
判断基準: 「同じ変換を大量ファイルに適用したい」は
/batchの出番
シーン別・使い分けクイックガイド
| こんな時 | 使うべきもの |
|---|---|
| 毎回同じ手順を繰り返している | カスタムSkill |
| CLAUDE.mdが長くなってきた | 手順をSKILL.mdに移す |
| チームで品質を統一したい | プロジェクトSkill（gitで共有） |
| 誤実行されたくない操作 | disable-model-invocation: true |
| 複数ステップの調査・分析 | カスタムSkill |
| 決まったフォーマットで出力 | カスタムSkill |
| 100ファイル以上の一括変換 | 組み込み /batch |
| デプロイ後の状態を定期監視 | 組み込み /loop |
| コードレビューを定型化 | 組み込み /simplify またはカスタムSkill |
まとめ：Skill化のタイミングを見極める3つの問い
Skill化すべきかどうか迷ったら、以下の3つを自問してみてください。
- 「また同じ説明をしているか？」 → Yes なら Skill 化
- 「チームで統一したい作業か？」 → Yes なら プロジェクトSkill
- 「間違えて実行されたら困るか？」 → Yes なら
disable-model-invocation: true
Skillsは「作るのが大変そう」に見えて、実はシンプルなテキストファイル1つから始められます。まずは 既存のCLAUDE.mdから1つの手順を切り出してSKILL.mdにする だけでも十分な効果があります。
関連記事
Skillsの仕組み・SKILL.mdの書き方・環境構築手順など、基礎から網羅した完全ガイドはこちら。
-->
コメント