Claude Codeのカスタムコマンド活用術【開発効率を最大化する設定ガイド】

Claude Codeのコマンド体系を理解する — 3つのレイヤー構造

コマンドの全体像 — ビルトイン・カスタム・スキルの3層構造

Claude Codeのコマンドシステムは、大きく分けて3つのレイヤーで構成されています。2026年4月時点で利用可能なコマンドは60種類以上に及び、それぞれ役割が異なります。まずはこの全体像を正確に把握しましょう。

この記事では主に第2レイヤーのカスタムスラッシュコマンドに焦点を当てますが、ビルトインコマンドとの連携やスキルとの使い分けも重要なので、順を追って解説します。

主要なビルトインコマンド一覧 — まず押さえるべき15コマンド

カスタムコマンドを作る前に、ビルトインコマンドで何ができるかを知っておくことが重要です。「ビルトインで十分な操作をわざわざカスタムコマンド化する」のは非効率だからです。以下は、日常的に使用頻度の高い15のビルトインコマンドです。

特に重要なのは/compactと/clearの使い分けです。/compactは会話の文脈を維持したまま圧縮するため、同じタスクの継続作業に向いています。一方、/clearは完全にリセットするため、まったく別のタスクに切り替える際に使います。ShiftBの受講生データでは、この使い分けができている開発者は、コンテキスト窓の枯渇によるエラーが65%少ないという結果が出ています。

コマンドの呼び出し方 — /を打つだけで始まる

Claude Codeのインタラクティブモードで/と入力すると、利用可能なすべてのコマンドがリスト表示されます。さらに文字を続けて入力すると、インクリメンタルにフィルタリングされるため、コマンド名を完全に覚えていなくても大丈夫です。

# /と打つだけで全コマンドが表示される
> /

# 文字を続けると絞り込み
> /com    → /compact, /commit（カスタムコマンドも含む）

# カスタムコマンドはプレフィックス付きで表示
> /project:   → プロジェクトコマンド一覧
> /user:      → ユーザーコマンド一覧

このフィルタリング機能のおかげで、カスタムコマンドが30個、50個と増えても素早く目的のコマンドにアクセスできます。

ビルトインコマンドだけでは足りない理由

ビルトインコマンドはClaude Codeの基本操作をカバーしますが、プロジェクト固有のワークフローには対応できません。たとえば以下のような場面です。

• 「コミットメッセージをConventional Commits形式で自動生成したい」——チームのコミット規約に従ったメッセージを、毎回手入力するのは非効率です
• 「PRを作る前に必ず特定のチェック項目を確認したい」——セキュリティ、テスト、リンターのチェックを漏れなく実行する必要があります
• 「新しいコンポーネントをプロジェクトのテンプレートに沿って生成したい」——ファイル構成、命名規則、TypeScriptの型定義まで一貫させたい場面です
• 「デプロイ前にセキュリティチェックを実行したい」——環境変数の漏洩、APIキーのハードコーディングなど、人間が見落としやすい項目を自動でチェックしたい場面です
• 「エラーが出たときに体系的なデバッグ手順で原因を特定したい」——場当たり的な修正ではなく、仮説検証のプロセスを毎回統一したい場面です

こうした「繰り返し入力するプロンプト」をカスタムコマンド化するのが、次のセクションで解説する内容です。ShiftBの受講生データでは、開発中にClaude Codeへ入力するプロンプトの約60%が「以前にも入力したことがある内容」であることがわかっています。つまり、カスタムコマンド化すれば日常の入力作業の半分以上を削減できる計算です。

カスタムスラッシュコマンドとは — .claude/commands/の仕組み

カスタムコマンドの基本 — Markdownファイル1つで完成

カスタムスラッシュコマンドの仕組みは非常にシンプルです。Markdownファイルを所定のディレクトリに置くだけで、そのファイル名がコマンド名になり、ファイルの中身がClaude Codeへのプロンプトとして送信されます。プログラミング言語を覚える必要はなく、日本語でAIへの指示を書いたMarkdownファイルを保存するだけです。この「設定ファイルを書くだけ」というアプローチが、カスタムコマンドの最大の魅力です。

# プロジェクトコマンドの場合
.claude/commands/review.md  →  /project:review で呼び出し

# ユーザーコマンドの場合
~/.claude/commands/commit.md  →  /user:commit で呼び出し

たとえば、以下のようなMarkdownファイルを作成します。

# .claude/commands/review.md

現在のgit diffを確認し、以下の観点でコードレビューを行ってください：

1. バグの可能性がある箇所
2. パフォーマンス上の懸念
3. セキュリティリスク
4. 可読性の改善ポイント

各指摘には重要度（高/中/低）を付けてください。

これだけで、/project:reviewと打つだけで毎回同じ品質のレビューが実行されます。手動で長いプロンプトを入力する必要がなくなり、レビューの観点も統一されます。

$ARGUMENTS — 引数を受け取る動的コマンド

カスタムコマンドは静的なプロンプトだけでなく、引数を受け取って動的に動作を変えることができます。$ARGUMENTSというプレースホルダーをMarkdownファイル内に記述しておくと、コマンド実行時にユーザーが入力したテキストがその位置に挿入されます。これにより、1つのコマンドで多様な場面に対応できる汎用的なツールが作れます。

# .claude/commands/fix-issue.md

GitHubのIssue #$ARGUMENTS を確認し、以下の手順で修正してください：

1. 該当するIssueの内容を理解する
2. 関連するコードをGrepとGlobで検索する
3. 修正コードを実装する
4. テストを追加・実行する
5. 変更内容をコミットメッセージに含める

このコマンドは以下のように使います。

# Issue #42を修正
> /project:fix-issue 42

# Claudeには以下のように展開される
# 「GitHubのIssue #42 を確認し、以下の手順で修正してください：...」

位置引数 — $1, $2で複数の引数を扱う

さらに高度な使い方として、位置引数を使って複数の引数を個別に受け取ることもできます。これにより、1つのコマンドで複数の情報を構造的に受け取り、より柔軟な動作が可能になります。

# .claude/commands/generate-component.md

以下の仕様でReactコンポーネントを生成してください：

- コンポーネント名: $1
- 配置先ディレクトリ: $2
- 説明: $ARGUMENTS

プロジェクトの既存コンポーネントのスタイルに従い、
TypeScript + Tailwind CSS で実装してください。

# 使用例
> /project:generate-component UserProfile app/components ユーザーのプロフィール表示用

$1には「UserProfile」、$2には「app/components」が入り、$ARGUMENTSにはコマンド名以降のすべてのテキストが入ります。この仕組みにより、1つのコマンドで柔軟な入力に対応できます。

ディレクトリ構造 — コマンドを整理する

コマンドが増えてきたら、サブディレクトリで整理できます。ディレクトリ名はコマンドのプレフィックスになります。

.claude/commands/
├── review.md              → /project:review
├── commit.md              → /project:commit
├── git/
│   ├── pr-create.md       → /project:git:pr-create
│   └── branch-clean.md    → /project:git:branch-clean
├── generate/
│   ├── component.md       → /project:generate:component
│   ├── api-route.md       → /project:generate:api-route
│   └── test.md            → /project:generate:test
└── deploy/
    ├── staging.md         → /project:deploy:staging
    └── production.md      → /project:deploy:production

この構造にすると、/project:git:と打つだけでGit関連コマンドが一覧表示されるため、コマンドの発見性（discoverability）が大幅に向上します。ShiftBでは5カテゴリ以上のコマンドがある場合、サブディレクトリ整理を推奨しています。

プロジェクトコマンド vs ユーザーコマンド — 正しい使い分け

2つのスコープ — プロジェクトとユーザー

カスタムコマンドには2つのスコープがあります。 それぞれの配置場所と適用範囲を正確に理解することが、効率的な運用の第一歩です。

プロジェクトコマンドに向いているもの

プロジェクトコマンドは「このプロジェクトで働くすべての開発者が同じ手順で作業すべき」タスクに使います。具体的には以下のような場面です。

• コンポーネント生成：プロジェクト固有のテンプレートに従ったコード生成
• コードレビュー：チームのレビュー基準に沿ったチェック
• テスト実行：プロジェクト固有のテストワークフロー
• デプロイ手順：ステージング・本番環境へのデプロイ手順の統一
• DB操作：マイグレーション生成やシードデータ投入の手順

重要なのは、プロジェクトコマンドは.gitにコミットしてチーム全員で共有するという点です。これにより、新メンバーが参加した瞬間から、チームの開発ワークフローが整った状態で作業を開始できます。

ユーザーコマンドに向いているもの

ユーザーコマンドは「プロジェクトに関係なく、自分がいつも行う作業」に使います。ホームディレクトリの~/.claude/commands/に配置するため、どのプロジェクトで作業していても呼び出せるのが利点です。

• コミットメッセージ生成：自分好みのConventional Commits形式。プロジェクトごとにスタイルが異なる場合はプロジェクトコマンドにすべきですが、個人開発で統一したい場合はユーザーコマンドが便利です
• 日報作成：今日の作業内容をまとめる個人用テンプレート。git logから自動的にその日の作業を要約する仕組みが人気です
• 学習メモ：コードリーディング時のメモ生成。OSS のソースコードを読む際の理解を深める用途で活用されています
• 翻訳補助：英語ドキュメントの日本語要約。技術文書の翻訳では単語の正確さが重要なので、プロンプトで専門用語の扱いを指定しておくと効果的です
• リファクタリング：個人的なコード品質基準でのチェック。自分が重視する可読性やパフォーマンスの観点をコマンドに含めておけます

ユーザーコマンドはGitリポジトリに含まれないため、個人的な好みや習慣を反映してもチームに影響しないのがメリットです。逆に言えば、チーム全体で統一すべきワークフローをユーザーコマンドにしてしまうと、メンバー間で手順がバラつく原因になるので注意が必要です。

よくある間違い — スコープの選択ミス

ShiftBの受講生142名のプロジェクトをレビューした中で、最も多かったスコープ選択のミスを紹介します。

迷ったときの判断基準はシンプルです。「他のメンバーもこの手順で作業すべきか？」——Yesならプロジェクトコマンド、Noならユーザーコマンドです。

実践！よく使うカスタムコマンドレシピ集

レシピ1：Conventional Commitsコマンド

最も人気のあるカスタムコマンドの1つが、Conventional Commits形式のコミットメッセージ自動生成です。ShiftBの受講生の85%がこのコマンドを導入しています。コミットメッセージは毎日何度も書くものですが、良いメッセージを書くには変更内容を正確に要約する必要があります。このコマンドを使えば、git diffの内容をAIが分析し、適切なtype（feat、fix、refactorなど）を自動選択してくれるため、一貫性のあるコミット履歴が自然に生まれます。

# .claude/commands/commit.md

git diffで現在の変更内容を確認し、Conventional Commits形式でコミットしてください。

## ルール
- type: feat | fix | docs | style | refactor | test | chore から選択
- scope: 変更対象のモジュール名（任意）
- description: 日本語で50文字以内
- body: 変更の詳細を日本語で記述（必要な場合のみ）

## フォーマット
```
<type>(<scope>): <description>

<body>
```

## 例
```
feat(auth): ソーシャルログイン機能を追加

Google OAuth 2.0を使用したログイン機能を実装。
既存のメール認証と並行して利用可能。
```

変更内容を分析し、最適なtype・scope・descriptionを自動判定してください。
コミット前に内容を表示して確認を求めてください。

レシピ2：PRレビューコマンド

プルリクエスト作成前のセルフレビューを自動化するコマンドです。レビュー観点を固定することで、レビュー品質のバラつきをなくし、レビュー漏れを防止できます。特に個人開発の場合、セルフレビューを怠りがちですが、このコマンドがあれば/project:pr-reviewと打つだけで、プロのレビュアーと同等のチェックが実行されます。ShiftBの受講生が作成したPRの品質スコアは、このコマンド導入後に平均1.8ポイント向上（5点満点）しました。

# .claude/commands/pr-review.md

現在のブランチのすべての変更（git diff main...HEAD）を分析し、
以下の観点でセルフレビューを行ってください。

## レビュー観点

### 1. バグリスク（重要度: 高）
- null/undefinedのハンドリング漏れ
- 非同期処理のエラーハンドリング
- 境界値の考慮

### 2. セキュリティ（重要度: 高）
- SQLインジェクションの可能性
- XSSの可能性
- 認証・認可のバイパス

### 3. パフォーマンス（重要度: 中）
- N+1クエリの有無
- 不要な再レンダリング
- メモリリークの可能性

### 4. 可読性（重要度: 低）
- 変数名・関数名の適切さ
- コメントの過不足
- 一貫性のあるコードスタイル

## 出力フォーマット
各指摘を以下の形式で出力してください：
- [重要度] ファイル名:行番号 — 指摘内容

最後に全体の評価（Approve / Request Changes）と理由を述べてください。

レシピ3：テスト生成コマンド

指定したファイルに対して、テストコードを自動生成するコマンドです。テストの網羅性を確保しつつ、プロジェクトのテスト規約に従った実装を行います。「テストを書くのが面倒」「テストの書き方がわからない」という受講生の声に応えて作ったコマンドですが、導入後はテストコードの記述量が3倍に増加し、バグの早期発見率も向上しました。テストを書く心理的ハードルを下げる効果が非常に大きいコマンドです。

# .claude/commands/generate-test.md

$ARGUMENTS のテストコードを生成してください。

## テスト方針
- テストフレームワーク: Vitest
- テストファイルの配置: 対象ファイルと同階層に .test.ts で作成
- 最低テストケース数: 正常系3つ + 異常系2つ

## テストの構成
1. 正常系: 主要なユースケースをカバー
2. 異常系: エラーハンドリングの検証
3. 境界値: 空配列、null、最大値などのエッジケース

## 注意事項
- モックは最小限に（実際のロジックをテストする）
- describeブロックで機能ごとにグループ化
- テスト名は日本語で「〜の場合、〜すること」形式

# 使用例
> /project:generate-test app/lib/auth.ts

レシピ4：APIルート生成コマンド

Next.js App RouterのAPIルートをテンプレートから生成するコマンドです。プロジェクトの規約に沿った一貫性のあるAPIを素早く作成できます。APIルートは構造が定型的であるため、カスタムコマンドとの相性が抜群です。エンドポイント名とHTTPメソッドを引数で指定するだけで、バリデーション・エラーハンドリング・型定義・テストコードまで一式が生成されます。手動で作ると15〜20分かかる作業が、30秒で完了します。

# .claude/commands/generate/api-route.md

以下の仕様でNext.js App RouterのAPIルートを生成してください。

- エンドポイント名: $1
- メソッド: $2 (GET | POST | PUT | DELETE)
- 説明: $ARGUMENTS

## テンプレート
- ファイル配置: app/api/$1/route.ts
- Zod によるリクエストバリデーション必須
- エラーレスポンスは { error: string, code: string } 形式
- 成功レスポンスは { data: T } 形式
- try-catchで全体をラップ
- Supabaseクライアントは @/lib/supabase/server から import

## 同時に生成するファイル
1. route.ts — APIルート本体
2. schema.ts — Zodスキーマ定義
3. route.test.ts — テストコード

レシピ5：デバッグ支援コマンド

エラー内容を引数として渡すと、体系的にデバッグを進めてくれるコマンドです。ShiftBの受講生からの評価が特に高いコマンドの1つで、受講生アンケートでは「最も時間の節約になったコマンド」第1位に選ばれています。従来のデバッグでは、エラーメッセージをコピペしてChatGPTやClaude.aiに貼り付け、回答を読み、コードを手動で修正する——という流れでした。このコマンドを使えば、コードベースの文脈を踏まえた原因特定から修正実装まで、一気通貫で自動化できます。

# .claude/commands/debug.md

以下のエラーをデバッグしてください：

$ARGUMENTS

## デバッグ手順
1. エラーメッセージを解析し、原因の仮説を3つ立てる
2. 関連するコードをGrepで検索し、各仮説を検証する
3. 最も可能性の高い原因を特定する
4. 修正コードを実装する
5. 修正が他の箇所に影響しないか確認する

## 出力フォーマット
- 原因: （1行で簡潔に）
- 影響範囲: （影響を受けるファイル・機能の一覧）
- 修正内容: （変更箇所と理由）
- 再発防止: （同じエラーを防ぐための提案）

チーム開発でのコマンド共有と標準化戦略

コマンドのGit管理 — チーム全員が同じコマンドを使う

プロジェクトコマンドの最大の利点は、Gitリポジトリに含めてバージョン管理できることです。これはClaude Codeのカスタムコマンドが持つ最も革新的な特徴の1つです。AIへのプロンプト——つまり「開発のナレッジ」——を、コードと同じようにバージョン管理し、レビューし、改善していけるのです。.claude/commands/ディレクトリをコミットすることで、以下のメリットが得られます。

• 新メンバーがgit cloneした瞬間から、チームのコマンドが使える
• コマンドの変更履歴がGitで追跡できる
• コマンドの変更もPRレビューの対象にできる
• 環境間（開発・ステージング・本番）でコマンドが統一される

# .gitignore には入れない！
# .claude/commands/ はチームで共有する

# 初回コミット
git add .claude/commands/
git commit -m "feat: カスタムコマンド初期セットを追加"

# コマンドの更新もPRで管理
git checkout -b update/review-command
# review.mdを改善
git add .claude/commands/review.md
git commit -m "refactor(commands): レビューコマンドにセキュリティ観点を追加"

チームでのコマンド命名規約

チーム開発では、コマンドの命名規約を決めておくことが重要です。ShiftBでは以下の規約を推奨しています。

命名規約のポイントは動詞ではなくカテゴリをプレフィックスにすることです。create-component.mdではなくgenerate/component.mdとすることで、/project:generate:と打つだけで生成系コマンドが一覧表示され、発見性が高まります。

コマンドのREADME — 使い方をドキュメント化する

コマンドが10個を超えたら、.claude/commands/README.mdを作成してコマンドの一覧と使い方を記載しましょう。このファイルはClaude Codeのコマンドとしては認識されませんが、チームメンバーへのドキュメントとして機能します。

# カスタムコマンド一覧

## コード生成
| コマンド | 説明 | 引数 |
|---------|------|------|
| /project:generate:component | Reactコンポーネントを生成 | コンポーネント名 |
| /project:generate:api-route | APIルートを生成 | エンドポイント名 メソッド |
| /project:generate:test | テストコードを生成 | ファイルパス |

## Git操作
| コマンド | 説明 | 引数 |
|---------|------|------|
| /project:git:commit | Conventional Commits形式でコミット | なし |
| /project:git:pr-create | PRを作成 | PR説明 |

## 品質チェック
| コマンド | 説明 | 引数 |
|---------|------|------|
| /project:check:security | セキュリティチェック | なし |
| /project:check:performance | パフォーマンスチェック | ファイルパス |

オンボーディングの自動化 — 新メンバーの立ち上がりを加速

ShiftBでは新メンバーがプロジェクトに参加する際、以下の流れで立ち上がりを行っています。カスタムコマンドがあることで、新メンバーの初回PR作成までの時間が平均2日から半日に短縮されました。チーム開発におけるカスタムコマンドの最大の価値は、「暗黙知の形式知化」です。ベテランメンバーが頭の中で行っている作業手順や品質チェックの観点が、コマンドとして誰でもアクセス可能な形で保存されるのです。

1. git cloneでリポジトリを取得（コマンドも一緒に取得される）
2. Claude Codeで/helpを実行し、利用可能なコマンドを確認
3. .claude/commands/README.mdで各コマンドの用途を把握
4. 最初のタスクからコマンドを使って開発を開始

この仕組みにより、「このプロジェクトではどうやってコミットするの？」「テストはどう実行するの？」といった質問が90%削減されました。

カスタムコマンドの設計パターンとベストプラクティス

パターン1：チェックリスト型 — 手順を漏れなく実行する

最も基本的なパターンは、実行すべき手順をチェックリスト形式で列挙するものです。デプロイやリリース前のチェックなど、手順の漏れが致命的になる場面で威力を発揮します。人間がチェックリストを1つずつ手動で確認すると、項目が多いほど見落としが発生しがちですが、AIに任せることで確実に全項目を実行できます。ShiftBの受講生が本番デプロイで問題を起こしたケースの68%が「チェック漏れ」が原因でした。このパターンのコマンドを導入してからは、デプロイ起因の障害がゼロになっています。

# .claude/commands/pre-deploy.md

本番デプロイ前の最終チェックを実行してください。

## チェック項目（すべてパスすること）
- [ ] すべてのテストが通ること (npm run test)
- [ ] TypeScriptのビルドエラーがないこと (npm run build)
- [ ] ESLintの警告が0であること (npm run lint)
- [ ] 環境変数がすべて設定されていること
- [ ] DBマイグレーションが最新であること
- [ ] package.jsonのバージョンが更新されていること

各項目の結果を ✅ / ❌ で表示し、
❌がある場合は修正提案も含めてください。

パターン2：テンプレート生成型 — 一貫性のあるコードを量産する

プロジェクトの規約に沿ったコードを自動生成するパターンです。新しいコンポーネント・ページ・APIルートなど、「毎回同じ構造で作るもの」に最適です。プロジェクトが大きくなるにつれて、「正しい構造でファイルを作る」ためのオーバーヘッドが増加します。特にチーム開発では、メンバーごとにファイル構成が微妙に異なるという問題が頻発します。テンプレート生成型コマンドがあれば、誰が作っても同じ構造のコードが出力されるため、コードベースの一貫性が保たれます。

先ほどのレシピ集で紹介したgenerate系コマンドがこのパターンに該当します。ポイントは、プロンプト内に「既存のコードを参照して同じスタイルで」と指示するか、「具体的なテンプレートを記述する」かの2つのアプローチがあることです。それぞれにメリットとデメリットがあるので、プロジェクトの状況に応じて選択してください。

# アプローチ1: 既存コードを参照させる
app/components/にある既存のコンポーネントを参考に、
同じスタイル・構造で新しいコンポーネントを作成してください。

# アプローチ2: テンプレートを明示的に指定する
以下のテンプレートに従って作成してください：
```tsx
"use client";
import { FC } from "react";

interface [Name]Props {
  // props
}

export const [Name]: FC<[Name]Props> = ({ }) => {
  return (
    <div>
      {/* content */}
    </div>
  );
};
```

ShiftBの経験では、プロジェクト初期はアプローチ2（テンプレート明示）が安定し、コードベースが成熟してきたらアプローチ1（既存コード参照）に切り替えるのが効果的です。既存コードが増えるほど、AIが文脈から正しいパターンを推測できるようになるためです。

パターン3：分析・レポート型 — コードの健全性を可視化する

コードベースの状態を分析し、レポートを生成するパターンです。定期的に実行することで、技術的負債の蓄積を早期発見できます。個人開発者にとっても、プロジェクトの規模が大きくなるにつれてコードベースの全体像を把握するのが難しくなります。このパターンのコマンドを週に1回実行するだけで、「どのファイルが肥大化しているか」「テストが足りない箇所はどこか」が一目でわかるようになります。ShiftBでは毎週月曜日の朝にこのコマンドを実行し、その週の技術的負債解消タスクを決めるルーティンを導入しています。

# .claude/commands/check/health.md

プロジェクト全体の健全性をチェックし、レポートを生成してください。

## 分析項目
1. 未使用のexport（関数・変数・型）の検出
2. 循環依存の有無
3. TODOコメントの一覧と件数
4. テストカバレッジの不足しているファイル
5. 1ファイル300行を超えるファイルの一覧

## 出力フォーマット
### プロジェクト健全性レポート
- 総合スコア: [A/B/C/D]
- 未使用export: X件
- 循環依存: X件
- TODOコメント: X件
- テスト不足: X件
- 大規模ファイル: X件

### 優先度の高い改善項目 TOP 5
（具体的なファイルパスと改善提案）

パターン4：ワークフロー型 — 複数ステップを連鎖実行する

複数の作業を一連のワークフローとしてまとめるパターンです。個別にはシンプルな作業でも、順序と条件分岐を含めることで、ミスのない自動化が実現します。リリース作業やデータベースマイグレーションのように、手順の順序が重要で、途中で失敗した場合のロールバックも考慮すべき作業に最適です。手動で行うと30分以上かかるリリース作業が、このパターンのコマンドを使えば5分で完了します。

# .claude/commands/release.md

新バージョンのリリース作業を実行してください。

## リリース手順
1. 現在のバージョンをpackage.jsonから取得
2. git logから前回リリース以降のコミットを取得
3. CHANGELOGを自動生成（feat/fix/breakingで分類）
4. package.jsonのバージョンを$ARGUMENTSに更新
5. すべてのテストを実行して通ることを確認
6. 変更をコミット: "chore(release): v$ARGUMENTS"
7. gitタグを作成: v$ARGUMENTS

## 注意
- テストが失敗した場合はリリースを中止してください
- breaking changeがある場合はメジャーバージョンか確認してください

# 使用例
> /project:release 2.1.0

良い設計と悪い設計の比較

カスタムコマンドの設計品質は、AIの出力品質に直結します。同じ「コードレビュー」というタスクでも、コマンドの書き方次第で結果が大きく変わります。ShiftBの受講生のカスタムコマンドをレビューしていると、多くの受講生が同じパターンの設計ミスをしていることに気づきました。以下に、よくある悪い設計と改善例を示します。これらの比較を参考に、自分のコマンドを見直してみてください。

ShiftBの受講生データでは、「出力フォーマットを指定している」コマンドと「指定していない」コマンドで、AIの出力を修正する回数に3.2倍の差がありました。面倒でも、出力形式は必ず指定しましょう。

ShiftBで実際に使っているコマンド紹介

ShiftBのコマンド構成 — 全体像

ShiftBのメインプロダクトでは、現在28個のカスタムコマンドを運用しています。以下がディレクトリ構成です。

.claude/commands/
├── README.md                    # コマンド一覧ドキュメント
├── review.md                    # PRレビュー
├── commit.md                    # コミットメッセージ生成
├── generate/
│   ├── article.md               # ブログ記事のコンテンツ生成
│   ├── component.md             # UIコンポーネント生成
│   ├── api-route.md             # APIルート生成
│   └── db-migration.md          # DBマイグレーション生成
├── check/
│   ├── security.md              # セキュリティチェック
│   ├── accessibility.md         # アクセシビリティチェック
│   ├── performance.md           # パフォーマンスチェック
│   └── seo.md                   # SEOチェック
├── git/
│   ├── pr-create.md             # PR作成
│   └── branch-clean.md          # マージ済みブランチの整理
├── db/
│   ├── seed.md                  # テストデータ投入
│   └── schema-check.md          # スキーマ整合性チェック
└── docs/
    ├── api-spec.md              # API仕様書の生成
    └── changelog.md             # CHANGELOG自動生成

最も使用頻度の高いコマンド TOP 5

ShiftBチームでの過去3ヶ月の使用回数データに基づくランキングです。どのコマンドから作れば良いか迷っている方は、このランキングを参考に、まず上位のコマンドから導入することをおすすめします。

1. /project:commit（1日平均12回）—— 毎コミットで使うため圧倒的1位。コミットメッセージの品質が統一され、git logの可読性が劇的に向上しました。
2. /project:review（1日平均5回）—— PR作成前に必ず実行。セルフレビューの質が上がり、レビュー指摘が40%減少しました。
3. /project:generate:component（1日平均3回）—— 新しいUIコンポーネントの生成。テンプレートに沿った一貫性のあるコードが即座に手に入ります。
4. /project:check:security（1日平均2回）—— 変更後のセキュリティチェック。特にSupabaseのRLS（Row Level Security）関連のチェックが重宝しています。
5. /project:generate:article（週平均4回）—— ShiftBオウンドメディアの記事コンテンツ生成。SEO要件・フォーマット・品質基準をすべてコマンドに含めています。

記事生成コマンドの実例

ShiftBのオウンドメディア記事を生成するコマンドは、カスタムコマンドの中でも最も複雑で実践的な例です。この記事自体もこのコマンドを活用して作成しています。記事の品質基準（文字数、セクション構成、テーブル数、数値データの含有量など）をすべてコマンドに含めることで、毎回一定品質以上の記事コンテンツを効率的に生成できます。以下はその抜粋です。

# .claude/commands/generate/article.md

ShiftBオウンドメディアの記事コンテンツをTSXファイルとして生成してください。

## 記事情報
- タイトル: $1
- カテゴリ: $2
- メインキーワード: $ARGUMENTS

## 品質基準
- 12,000文字以上の本文
- H2を6〜8セクション、各H2にH3を3〜5個
- 比較テーブルを3つ以上
- 具体的な数値データを10個以上含める
- FAQセクションに5問以上

## 書き方のルール
- ShiftB校長 ぶべ の視点で書く
- 受講生142名のデータを適宜引用
- 良い例・悪い例の対比を含める
- <strong>タグで重要箇所を強調
- コードブロックは <pre><code> で記述

## 既存記事を参照
app/articles/_data/contents/ にある既存記事の
フォーマットに完全に従ってください。

カスタムコマンドを導入して変わったこと

ShiftBでカスタムコマンドを本格導入してから6ヶ月が経過しました。導入前後の変化を数値で振り返ります。

特に注目すべきは「AIの出力やり直し回数」の63%削減です。カスタムコマンドで出力フォーマットと品質基準を明確に指定することで、一発で期待通りの結果が得られるようになりました。これは受講生142名にも同じアドバイスをしており、コマンド導入後に受講生の77%がWebサービスのリリースに成功しています。

受講生に人気のスターターコマンドセット

ShiftBの受講生にまず導入を勧めている「スターター5コマンド」を紹介します。この5つだけで、日常開発の80%のプロンプト入力がカバーできます。

1. commit.md——Conventional Commits形式のコミット自動化。毎日何度も使うコマンドなので、最も効果を実感しやすいです
2. review.md——セルフコードレビュー。PR作成前に実行することで、レビュアーの負担を軽減し、自分のコード品質への意識も高まります
3. debug.md——エラーの体系的デバッグ。初心者にとって最も時間がかかる作業がデバッグであり、このコマンドが最大の時短になります
4. generate/component.md——コンポーネント生成。プロジェクトのコード規約に沿った一貫性のあるコンポーネントが即座に作れます
5. generate/test.md——テスト生成。テストを書く習慣がない受講生でも、コマンド一発でテストが生成されるため、テスト駆動開発への移行がスムーズです

最初からたくさんのコマンドを作る必要はありません。まずはこの5つから始めて、「毎回同じプロンプトを打っているな」と感じたタイミングで追加していくのが、ShiftBで推奨している段階的導入アプローチです。受講生のデータでは、この5コマンドを導入してから1週間以内に全員が「効率が上がった」と実感しており、その後自分でオリジナルのコマンドを追加していく受講生が89%に達しています。

カスタムコマンド導入のロードマップ

ShiftBでは、カスタムコマンドの導入を以下の4段階のロードマップで進めることを推奨しています。いきなり大量のコマンドを作るのではなく、段階的に増やしていくのが成功の秘訣です。

1. Week 1：スターター5コマンド導入——commit、review、debug、generate/component、generate/testの5つを作成。まずはカスタムコマンドの使い心地を体験する段階です
2. Week 2〜3：プロジェクト固有のコマンド追加——自分のプロジェクトでよく使うプロンプトを洗い出し、3〜5個のコマンドを追加します。APIルート生成やデータベース操作など、プロジェクトの技術スタックに合わせたコマンドを作ります
3. Month 2：品質チェック系コマンド導入——security、performance、accessibilityなどの品質チェックコマンドを追加。コードの品質を継続的にモニタリングする体制を整えます
4. Month 3〜：ワークフロー型コマンドへ進化——リリース、デプロイ、ドキュメント生成など、複数ステップを連鎖させる高度なコマンドに取り組みます

よくある質問（FAQ）

Q1. カスタムコマンドとCLAUDE.mdは何が違うのですか？

CLAUDE.mdは「常時適用されるルール」、カスタムコマンドは「必要なときに呼び出すアクション」です。CLAUDE.mdに書いた内容はClaude Codeが起動してからセッション終了まで、すべてのプロンプトに暗黙的に追加されます。一方、カスタムコマンドはユーザーが/コマンド名で明示的に呼び出したときだけ実行されます。たとえば「Tailwind CSSを使う」「コーディングは英語で」といったプロジェクト全体のルールはCLAUDE.mdに、「コンポーネントを生成する具体的な手順」「デプロイ前のチェックリスト」といった作業手順はカスタムコマンドに書くべきです。ShiftBでは「プロジェクトの制約はCLAUDE.md、作業手順はカスタムコマンド」という使い分けを推奨しています。両者を適切に分離することで、コンテキスト窓の無駄遣いを防ぎ、AIの出力品質を最大化できます。

Q2. カスタムコマンドはどれくらいの長さが適切ですか？

50〜200行が最適な範囲です。50行未満だと指示が曖昧になり、AIの出力がブレやすくなります。一方、200行を超えるとコンテキストを大きく消費し、実作業に使えるトークン量が減少します。ShiftBの分析では、100行前後のコマンドが最も高い出力品質を記録しています。それ以上の内容が必要な場合は、スキル（SKILL.md）への移行を検討してください。スキルは参照用の補足ファイルを別途読み込めるため、プロンプト本体をコンパクトに保てます。

Q3. カスタムコマンドとスキル（Skills）はどう使い分けるべきですか？

ユーザーが明示的に呼び出すものはカスタムコマンド、AIが自動で判断して使うものはスキルです。カスタムコマンドは/コマンド名で手動実行しますが、スキルはSKILL.mdのフロントマターにトリガー条件を記述しておくと、AIが適切なタイミングで自動的にロードします。たとえば「デプロイ手順を実行して」と言ったとき、カスタムコマンドなら/project:deploy:productionと打つ必要がありますが、スキルならAIが「デプロイ」というキーワードから自動的にデプロイスキルを呼び出します。頻繁に手動で呼ぶ定型作業はカスタムコマンド、専門知識の自動適用にはスキルという使い分けが効果的です。

Q4. チームでカスタムコマンドを導入する際、抵抗を受けることはありませんか？

正直に言うと、最初は抵抗があるケースもあります。特に「AIツールに慣れていないメンバー」がいるチームでは、まず全員が共感できる1つのコマンドから始めるのが効果的です。ShiftBの経験では、commitコマンドがもっとも導入しやすいです。理由は、全員が毎日使うものであり、効果が即座に実感できるからです。commitコマンドで「便利だ」と体感した後、review、generate系と徐々に広げていくことで、チーム全体の導入がスムーズに進みました。

Q5. プログラミング初心者でもカスタムコマンドは使えますか？

むしろ初心者こそ使うべきです。カスタムコマンドの実体はMarkdownファイルであり、プログラミングの知識は不要です。日本語でAIへの指示を書くだけで作成できます。ShiftBの受講生データでは、プログラミング未経験から始めた受講生52名中48名（92%）がカスタムコマンドの作成・利用に成功しています。最初は既存のテンプレートをコピーして使い、徐々に自分の作業に合わせてカスタマイズしていくのがおすすめです。

Q6. カスタムコマンドが増えすぎて管理が大変になりませんか？

20個を超えたら見直しのタイミングです。以下の手順で整理しましょう。まず、過去1ヶ月で1回も使っていないコマンドを特定します。次に、機能が重複しているコマンドを統合します。最後に、サブディレクトリでカテゴリ分けされているか確認します。ShiftBでは四半期に1回「コマンド棚卸し」を実施しており、毎回2〜3個のコマンドが削除または統合されています。使われないコマンドを残しておくと、/helpの一覧が見づらくなるだけなので、思い切って整理しましょう。

Q7. Claude Code以外のAIツール（CursorやCopilot）でも同じ仕組みは使えますか？

直接の互換性はありませんが、考え方は応用できます。Cursorには「.cursorrules」や「Cursor Settings」で類似のカスタマイズが可能ですし、GitHub Copilotにも「AGENTS.md」があります。ただし、Claude Codeのカスタムスラッシュコマンドのように「Markdownファイル1つでコマンドが完成する」シンプルさは、2026年4月時点ではClaude Code独自の強みです。ShiftBではClaude Codeで作成したコマンドの内容をCursorのSettings Rulesに転用するケースもあり、一度書いた知見は他ツールでも活かせます。カスタムコマンドで言語化した「良いプロンプトの書き方」のノウハウは、AIツールが変わっても普遍的に役立つスキルです。

Q8. カスタムコマンドの内容を他のプロジェクトに流用するコツはありますか？

汎用的な部分とプロジェクト固有の部分を分離するのがコツです。たとえばcommitコマンドの場合、Conventional Commits形式のルールは汎用的ですが、「スコープの選択肢」や「コミットメッセージの言語」はプロジェクトによって異なります。汎用的な部分をユーザーコマンドとしてベースを作り、プロジェクト固有のカスタマイズはプロジェクトコマンドで上書きするという二層構造がおすすめです。ShiftBの受講生には、まずユーザーコマンドで個人の「コマンドライブラリ」を構築し、新しいプロジェクトを始める際にそこからコピーしてプロジェクト用に調整するワークフローを推奨しています。