🛠
Claude Code で使える自作スキル10選 ── コピペで動く実務ワークフロー

2026/02/15に公開
 Claude Code で使える自作スキル10選Claude Code を業務で使い始めると、毎回似たような指示を書いていることに気づきます。「このエラーログ調べて」「PR のレビューして」「セキュリティ大丈夫か見て」。
指示のたびに文脈を説明し直すのは非効率です。そこで、よくある作業を 再利用可能なスキル（ワークフロー） として整備しました。角括弧 [...] の中身を書き換えて Claude Code に貼り付けるだけで動きます。
この記事では、GitHub で無料公開している 10 本のスキルを紹介します。

 スキルの使い方（共通）どのスキルも同じ手順で使えます。
スキルの .md ファイルを開く

## 入力（Claude Code に渡す内容） セクションをコピー

[角括弧] を自分のプロジェクトの情報に書き換える
Claude Code に貼り付けて実行
# 例：bug-triage を使う場合
claude

> 以下のエラーログからバグの原因を切り分けてください。
>
> - 対象リポジトリ: [my-app]
> - エラーログ:
> [ここにスタックトレースを貼り付ける]
> - 発生環境: [本番 / ステージング / ローカル]

 バグ調査（2本）
 1. bug-triage ── エラーログからのバグ切り分け何をするか： スタックトレースやエラーログを起点に、バグの原因箇所を特定します。ログの量が多くても、Claude Code が関連部分を抽出して原因の仮説を立ててくれます。
使い方：
> 以下のエラーログからバグの原因を切り分けてください。
>
> - 対象リポジトリ: [my-app]
> - エラーログ:
> [スタックトレースを貼り付け]
> - 発生頻度: [毎回 / 時々 / 特定条件下]
> - 最後に正常動作した時期: [日付やコミットハッシュ]
出力イメージ： 原因箇所の候補リスト（ファイル名・行番号付き）、原因の仮説、確認すべき追加情報の一覧。
実行例（collect_context.sh の jq エラーを調査）：
## エラー概要
- エラー種別: コマンド未検出（command not found）
- 発生箇所: collect_context.sh:76-77行目
- エラーメッセージ: bash: line 15: jq: command not found

## 原因候補

### 1. jq がインストールされていない — 可能性: 高
- 根拠: jq は外部パッケージ。スクリプト内にインストール案内なし。
  PowerShell版は jq を使わず Get-Content で回避している。
- 該当コード: collect_context.sh:76 `if command -v jq > /dev/null 2>&1;`
- 確認方法: `which jq` を実行

### 2. command -v のチェックがバイパスされている — 可能性: 中
- 根拠: 76行目の事前チェックは実装済み。エラー行番号(15)と
  実際のjq使用行(76-77)が不一致 → 別バージョンの可能性
- 確認方法: `bash -x collect_context.sh` でトレース実行

### 3. set -euo pipefail との複合問題 — 可能性: 低
- 根拠: 6行目の -u オプションが未定義変数展開で早期終了を引き起こす
  可能性。ただしフォールバック構文 `jq ... || cat` で吸収されるはず
- 確認方法: 一時的に `set -eo pipefail` に変更して再実行
実際のコードを読んで原因候補を出してくれるので、深夜のトラブル対応で頭が回らないときに助かります。

 2. bug-reproduce ── 再現手順の確立と原因の分離何をするか： 曖昧な不具合報告（「なんか動かない」）から、最小再現手順を作成します。再現できれば原因特定は半分終わったようなものです。
使い方：
> 以下の不具合報告から最小再現手順を作成してください。
>
> - 報告内容: [バグ報告の原文を貼り付け]
> - 対象機能: [ログイン / 決済 / 検索 など]
> - 対象ファイル: [心当たりがあれば記載]
> - 環境: [OS、ブラウザ、Node バージョンなど]
出力イメージ： 番号付きの再現手順、原因の切り分け結果（フロントエンド / バックエンド / DB 等）、修正方針の提案。
実行例（「検索が動かない」という曖昧な報告から再現手順を作成）：
## 不具合報告（原文）
「検索ページで何か入力しても結果が出ない。昨日までは動いてた」

## 再現手順（Claude Code が生成）
1. 検索ページ /search にアクセスする
2. テキストボックスに任意の文字列を入力する
3. Enter キーまたは検索ボタンを押す
4. → 期待: 検索結果が表示される
5. → 実際: 結果0件 or エラー画面

## 原因の切り分け
- フロントエンド: fetch リクエストは送信されている（DevTools で確認）→ OK
- バックエンド: /api/search が 500 を返している → ここが原因
- DB: 直近マイグレーション（2026-02-12）で search_index テーブルの
  カラム名が変更されていた → SQL がカラム不一致でエラー
「動かない」だけの報告から、どこが壊れているかの切り分けまで一気に出してくれます。

 テスト（1本）
 3. test-add ── ユニットテストの追加何をするか： テストが書かれていない関数やモジュールに対して、ユニットテストを生成します。正常系・異常系・境界値を網羅したテストを Claude Code が書いてくれます。
使い方：
> 以下の関数にユニットテストを追加してください。
>
> - 対象ファイル: [src/utils/calculate.ts]
> - 対象関数: [calculateTax]
> - テストフレームワーク: [Jest / Vitest / pytest など]
> - カバーしたいケース: [正常系、0入力、負数、オーバーフロー]
出力イメージ： テストファイル一式（describe / it ブロック構成）、テストケースの意図を説明するコメント付き。実行コマンドの提示。
実行例（calculateTax 関数にテストを追加）：
## 生成されたテスト（Jest）

describe('calculateTax', () => {
  // 正常系
  it('税率10%で計算される', () => {
    expect(calculateTax(1000, 0.1)).toBe(100);
  });

  // 境界値
  it('金額0円の場合は0を返す', () => {
    expect(calculateTax(0, 0.1)).toBe(0);
  });

  // 異常系
  it('負の金額でエラーを投げる', () => {
    expect(() => calculateTax(-100, 0.1)).toThrow();
  });

  it('税率が1を超える場合にエラーを投げる', () => {
    expect(() => calculateTax(1000, 1.5)).toThrow();
  });
});

## 実行結果: 4 tests, 4 passed（うち1件は既存コードにバグ発見 → 修正提案つき）
正常系だけでなく、境界値や異常系のケースも自動で網羅してくれるのが手書きとの違いです。

 PR・レビュー（3本）
 4. pr-write ── レビューしやすい PR の作成何をするか： 差分から PR のタイトル・説明文・レビューポイントを自動生成します。「差分は出したけど PR の説明を書くのが面倒」という場面で使います。
使い方：
> 現在の差分からPRを作成してください。
>
> - ベースブランチ: [main]
> - 変更の目的: [ユーザー検索機能の追加]
> - 関連 Issue: [#123]
> - レビューで特に見てほしい点: [検索クエリのサニタイズ処理]
出力イメージ： PR タイトル、概要（変更理由・影響範囲）、レビュー依頼ポイント、テスト手順を含む PR 本文のドラフト。
実行例（develop ブランチの差分から PR を生成）：
## タイトル
Claude Code 日本語キット v1.0 -- スキル10本・マーケティング素材・公開準備一式

## 概要
Claude Code 向け日本語ワークフローキット（無料版 Phase 1）の全コンテンツを追加。
kit/ にスキル10本・ルール3本・セキュリティ設定を配置し、content/ に
マーケティング用記事5本・X投稿案・公開チェックリストを整備した。

## 変更内容
- スキル 10 本の SKILL.md を追加（バグ調査/テスト/PR/セキュリティ/リファクタ/障害対応）
- ルール 3 本を追加: コーディングスタイル・Git ワークフロー・セキュリティ
- .env 読み取りブロック用 permissions.deny 設定を追加
- 技術記事 5 本 + X 投稿案 + 公開チェックリストを追加

## レビューチェックリスト
- [ ] SKILL.md が統一フォーマットに準拠しているか
- [ ] settings.json の deny が .env を漏れなくブロックしているか
- [ ] プレースホルダ URL が公開前に差し替え必須であることが明確か
6コミット分の差分を読んで、変更理由・影響範囲・レビュー観点まで含む PR 本文を生成しました。手で書くと15分かかる内容が30秒で出てきます。

 5. pr-review ── コードレビューチェックリスト実行何をするか： PR の差分に対して、観点別のチェックリストでレビューを実行します。ロジック、セキュリティ、パフォーマンス、可読性の各観点で指摘を出します。
使い方：
> 以下のPRをレビューしてください。
>
> - PR URL または差分: [#456 または git diff の出力]
> - 重点チェック観点: [セキュリティ / パフォーマンス / 全般]
> - プロジェクトのコーディング規約: [あれば記載]
出力イメージ： 観点別の指摘リスト（重要度付き）、具体的な修正提案コード、全体の所感サマリ。
実行例（認証処理の PR をレビュー）：
## レビュー結果

### 🔴 重要（修正必須）
1. auth.js:45 — パスワードの平文比較
   修正案: bcrypt.compare() を使用する

### 🟡 推奨（改善推奨）
2. auth.js:23 — JWT の有効期限が 30 日は長すぎる
   修正案: 24時間 + リフレッシュトークン方式に変更
3. middleware.js:12 — エラー時にスタックトレースを返している
   修正案: 本番環境では汎用メッセージのみ返す

### 🟢 軽微
4. auth.js:67 — 変数名 `d` が不明瞭
   修正案: `tokenExpiresAt` に変更

## 全体所感
認証ロジックは概ね正しいが、パスワードの平文比較（#1）は
セキュリティ上の致命的な問題。マージ前に必ず修正すること。
観点別に重要度をつけてくれるので、「どこから直せばいいか」が一目で分かります。

 6. pr-quality-gate ── PR マージ前の品質チェック何をするか： PR をマージする前に、テスト・lint・型チェック・セキュリティスキャンの結果を総合判定します。CI が整備されていないプロジェクトでも、手元で品質ゲートを回せます。
使い方：
> この PR のマージ可否を判定してください。
>
> - 対象ブランチ: [feature/user-search]
> - チェック項目: [テスト / lint / 型チェック / セキュリティ]
> - マージ基準: [テスト全パス、lint エラー0、重大な脆弱性なし]
出力イメージ： 各チェック項目の合否判定（PASS / FAIL）、FAIL の場合の具体的な修正箇所、総合判定（マージ可 / 要修正）。
実行例（feature/user-search ブランチのマージ判定）：
## 品質ゲート判定結果

| チェック項目      | 結果   | 詳細                           |
|-------------------|--------|--------------------------------|
| テスト            | ✅ PASS | 48/48 passed, 0 failed         |
| lint              | ✅ PASS | エラー 0, 警告 2（許容範囲）   |
| TypeScript 型チェック | ✅ PASS | エラー 0                       |
| セキュリティ      | ❌ FAIL | SQL インジェクションの可能性 1件 |

## 総合判定: ❌ 要修正

### FAIL の詳細
- search.ts:34 — ユーザー入力をそのまま SQL に埋め込んでいる
const query = SELECT * FROM users WHERE name = '${input}';
修正案: プレースホルダを使用する
const query = SELECT * FROM users WHERE name = $1;
CI が整っていないプロジェクトでも、テスト・lint・型チェック・セキュリティの4観点でゲートを回せます。

 セキュリティ（2本）
 7. security-quick ── セキュリティクイックスキャン何をするか： コードベース全体をざっと走査し、よくあるセキュリティ上の問題（入力バリデーション不備、インジェクション脆弱性、認証の抜け穴など）を検出します。本格的な監査の前のスクリーニングとして使います。
使い方：
> このリポジトリのセキュリティクイックスキャンを実行してください。
>
> - 対象ディレクトリ: [src/]
> - 技術スタック: [Node.js + Express + PostgreSQL]
> - 特に気になる点: [ユーザー入力を扱う箇所]
出力イメージ： 検出された問題のリスト（重要度別）、該当箇所のファイル名・行番号、修正の方向性。
実行例（Express + PostgreSQL プロジェクトをスキャン）：
## セキュリティクイックスキャン結果

### 🔴 重大（3件）
1. routes/user.js:23 — SQL インジェクション
   `db.query("SELECT * FROM users WHERE id = " + req.params.id)`
   → プレースホルダ `$1` を使用すること

2. routes/upload.js:45 — パストラバーサル
   `fs.readFile(req.query.path)` でユーザー入力をそのまま使用
   → path.resolve + ホワイトリストチェックを追加

3. middleware/auth.js:12 — JWT シークレットがハードコード
   `jwt.sign(payload, 'my-secret-key')`
   → 環境変数 `process.env.JWT_SECRET` に移行

### 🟡 注意（2件）
4. app.js:5 — CORS が全オリジン許可
5. routes/api.js:30 — レートリミットなし

## サマリ: 重大 3件・注意 2件。#1 と #3 は即時対応推奨。
OWASP Top 10 ベースで走査してくれるので、「何を見ればいいか分からない」状態でもスクリーニングできます。

 8. security-secrets ── 秘密情報の漏洩スキャン何をするか： リポジトリ内に API キー、パスワード、トークンなどの秘密情報がハードコードされていないかスキャンします。.env に入れるべき値がソースコードに残っていないかを検出します。
使い方：
> このリポジトリ内の秘密情報漏洩をスキャンしてください。
>
> - 対象: [リポジトリ全体 / src/ のみ]
> - チェック対象: [APIキー, DBパスワード, JWT シークレット, AWS認証情報]
> - 除外ディレクトリ: [node_modules/, .git/]
出力イメージ： 検出されたシークレット候補の一覧（ファイル名・行番号・種類）、対処方法（環境変数化、git history からの削除手順）。
実行例（product/ ディレクトリ全体をスキャン、66ファイル対象）：
## シークレットスキャン結果

スキャン対象: 66 ファイル
ハードコードされた実際の秘密情報: 0 件

### 検出された候補（すべて LOW / ドキュメント内の例示）

| 重要度 | ファイル | 種別 | 内容 |
|--------|---------|------|------|
| LOW | secret-exposure-scan.md:157 | PASSWORD（例示） | Bad例のコードサンプル |
| LOW | config-externalization.md:166 | API_KEY（テンプレ） | .env テンプレート |
| LOW | api-error-diagnosis.md:29 | TOKEN（プレースホルダ） | curl コマンド例 |

### 推奨対応
1. 🔴 .gitignore にセキュリティパターン追加
   （.env / *.pem / *.key / credentials* が未設定）
2. 🟡 ドキュメント内のアンチパターン例のパスワードを
   より明示的なダミー値に変更
3. 🟢 pre-commit フック（git-secrets 等）の導入検討
「本物の秘密情報は 0 件だが、.gitignore に穴がある」という指摘まで出してくれます。一度回すだけでリポジトリ全体の衛生状態が分かります。

 リファクタ（1本）
 9. refactor-plan ── リファクタリング計画の作成何をするか： 「このコード汚いけど、どこから手をつければ」という状況で、リファクタリングの優先順位と計画を立てます。影響範囲の分析、段階的な実施手順、各ステップのリスク評価を出力します。
使い方：
> 以下のファイル/モジュールのリファクタリング計画を作成してください。
>
> - 対象: [src/services/userService.ts]（800行）
> - 課題: [1ファイルに責務が集中、テスト不可能、重複コード多数]
> - 制約: [稼働中サービスのため段階的に実施したい]
> - 期間: [2スプリント以内]
出力イメージ： 段階別のリファクタ計画（フェーズ分け）、各フェーズの変更内容と影響範囲、リスク評価と rollback 手順。
実行例（800行の userService.ts を段階的にリファクタ）：
## リファクタリング計画

### 現状分析
- ファイル: src/services/userService.ts（800行）
- 課題: 認証・CRUD・通知・バリデーションが1ファイルに混在
- 循環的複雑度: 平均 15（推奨上限 10）

### フェーズ1: 責務分離（影響範囲: 小）
1. バリデーションロジックを validators/user.ts に抽出
2. 通知処理を services/notification.ts に抽出
   - 変更ファイル数: 3
   - リスク: 低（純粋な関数の移動のみ）

### フェーズ2: 認証分離（影響範囲: 中）
3. 認証関連を services/auth.ts に分離
4. ミドルウェア経由のアクセスパターンに変更
   - 変更ファイル数: 8
   - リスク: 中（ルーティング変更を伴う）

### フェーズ3: テスト追加（影響範囲: なし）
5. 分離後の各モジュールにユニットテストを追加
   - 推定テストケース数: 24

### rollback 手順
各フェーズは独立してコミット。問題発生時は git revert で戻せる。
「どこから手をつければ」の判断に一番時間がかかるリファクタで、優先順位とリスクまで出してくれるのが大きな利点です。

 障害対応（1本）
 10. incident-debug ── 本番障害の初動調査何をするか： 本番環境で障害が発生した際の初動調査を支援します。エラーログ、メトリクス、直近のデプロイ履歴から原因の仮説を立て、確認手順を提示します。深夜の障害対応で頭が回らないときに頼れます。
使い方：
> 本番障害の初動調査を支援してください。
>
> - 症状: [決済APIが500エラーを返す]
> - 発生時刻: [2026-02-13 03:15 JST]
> - 影響範囲: [全ユーザーの決済処理]
> - 直近のデプロイ: [2026-02-12 18:00 にリリース v2.3.1]
> - エラーログ: [ログを貼り付け]
出力イメージ： 原因仮説の優先度付きリスト、各仮説の確認手順、暫定対処（ロールバック判断を含む）、復旧後の根本原因調査の TODO。
実行例（決済 API の 500 エラー、深夜3時の初動調査）：
## 障害初動調査

### 症状
- 決済 API が 500 エラーを返す（全ユーザー影響）
- 発生: 2026-02-13 03:15 JST
- 直近デプロイ: 2026-02-12 18:00（v2.3.1）

### 原因仮説（優先度順）

#### 1. 直近リリースの決済モジュール変更 — 可能性: 高
- v2.3.1 で payment.js の税率計算ロジックを変更
- 変更差分に null チェック漏れあり
- 確認: `git diff v2.3.0..v2.3.1 -- src/payment/`

#### 2. 外部決済 API のレスポンス形式変更 — 可能性: 中
- Stripe API の deprecation warning が直近のログにあり
- 確認: Stripe ダッシュボードで API バージョン確認

#### 3. DB 接続プール枯渇 — 可能性: 低
- 接続数は正常範囲内（現在 12/50）

### 暫定対処
v2.3.0 へのロールバックを推奨（仮説1が最有力のため）
深夜の障害対応で頭が回らないときに「まず何を確認すべきか」を整理してくれます。仮説の優先度づけが特に助かります。

 スキル一覧まとめ

#
スキル名
カテゴリ
一言で言うと


1
bug-triage
バグ調査
エラーログから原因箇所を特定

2
bug-reproduce
バグ調査
曖昧な報告から最小再現手順を作成

3
test-add
テスト
テスト未整備の関数にテストを追加

4
pr-write
PR・レビュー
差分から PR 本文を自動生成

5
pr-review
PR・レビュー
観点別チェックリストでレビュー

6
pr-quality-gate
PR・レビュー
マージ前の総合品質チェック

7
security-quick
セキュリティ
コードベースのセキュリティスクリーニング

8
security-secrets
セキュリティ
API キー等のハードコード検出

9
refactor-plan
リファクタ
リファクタリングの優先順位と計画策定

10
incident-debug
障害対応
本番障害の初動調査支援


 どれから使い始めるか迷ったら、以下の順番をおすすめします。

bug-triage -- 手元のエラーログを貼り付けるだけ。一番手軽に効果を体感できます

pr-write -- 次の PR で試せます。レビュー依頼までの時間が半分になります

security-secrets -- 一度回すだけ。問題が見つかれば即対処すべきものです

 使ってみてください自分も最初は Claude Code に毎回同じ指示を手打ちしていました。調査のたびに「エラーログ貼って、原因出して、修正方針も」と書くのが面倒で、結局コピペ用のメモを作って――それがこのキットの原型です。
.claude/ フォルダをコピーするだけで、バグ調査〜PR〜障害対応まで"型"で回せるようになります。セットアップは 3 分です。
📦 Claude Code 導入キット（40スキル+Hooks、無料）

→ GitHub でダウンロード

→ BOOTH でダウンロード（0円）
📖 実践ガイド（Zenn Book、500円）

→ Zenn で読む
※本キットは Anthropic 社の公式製品ではありません。
この記事が参考になったら、いいねとフォローをお願いします。Claude Code の実務活用に関する記事を引き続き書いていきます。
#	スキル名	カテゴリ	一言で言うと
1	bug-triage	バグ調査	エラーログから原因箇所を特定
2	bug-reproduce	バグ調査	曖昧な報告から最小再現手順を作成
3	test-add	テスト	テスト未整備の関数にテストを追加
4	pr-write	PR・レビュー	差分から PR 本文を自動生成
5	pr-review	PR・レビュー	観点別チェックリストでレビュー
6	pr-quality-gate	PR・レビュー	マージ前の総合品質チェック
7	security-quick	セキュリティ	コードベースのセキュリティスクリーニング
8	security-secrets	セキュリティ	API キー等のハードコード検出
9	refactor-plan	リファクタ	リファクタリングの優先順位と計画策定
10	incident-debug	障害対応	本番障害の初動調査支援
Claude Code で使える自作スキル10選

スキルの使い方（共通）

バグ調査（2本）

1. bug-triage ── エラーログからのバグ切り分け

2. bug-reproduce ── 再現手順の確立と原因の分離

テスト（1本）

3. test-add ── ユニットテストの追加

PR・レビュー（3本）

4. pr-write ── レビューしやすい PR の作成

5. pr-review ── コードレビューチェックリスト実行

6. pr-quality-gate ── PR マージ前の品質チェック

セキュリティ（2本）

7. security-quick ── セキュリティクイックスキャン

8. security-secrets ── 秘密情報の漏洩スキャン

リファクタ（1本）

9. refactor-plan ── リファクタリング計画の作成

障害対応（1本）

10. incident-debug ── 本番障害の初動調査

スキル一覧まとめ

どれから使い始めるか

使ってみてください

Discussion
