Markdownファイルで再利用可能なslash commandを定義し、gitでチームに共有。コードレビュー・テスト生成・PR説明文などの高頻度タスクをカバーする。
Claude Codeには標準でいくつかのslash commandが用意されている——/help、/clear、/compactなど。しかし実際にワークフローを加速させるのは、自分で書いたコマンドだ。
この記事では、再利用可能なslash commandの体系をどう設計するかを解説する。チームの誰もが同じプロンプトライブラリを使えるようにして、毎回タスクの説明を思い出しながら書き直す手間をなくすことが目標だ。
Claude Codeにおけるカスタムslash commandは、単なるMarkdownファイルだ。指定のディレクトリに置けばClaude Code起動時に自動認識され、/ファイル名で呼び出せる。
ファイルの内容がClaudeに送られるプロンプトになる。それだけだ。
特殊な構文もなく、設定フォーマットもない。.mdファイル1つが1つのコマンドだ。
2つの場所があり、役割が異なる：
| 場所 | パス | スコープ |
|---|---|---|
| プロジェクト | .claude/commands/ |
現在のプロジェクトのみ、gitにコミット可能 |
| ユーザー | ~/.claude/commands/ |
全プロジェクト、個人用 |
プロジェクトレベルがチーム共有の核心だ。.claude/commands/をgitにコミットすれば、リポジトリをcloneした全員が自動的にこのコマンドセットを手に入れる。
ユーザーレベルは個人の習慣的なコマンドに使う——自分好みのコードスタイルチェックや、自分だけが使うツール連携など。
プロジェクトのルートで：
mkdir -p .claude/commands
.claude/commands/review.mdを作成：
現在の変更のコード品質をレビューしてください。重点的に確認すること：
1. ロジックエラーと境界条件
2. 命名の明確さ
3. 抽出できる重複コードがないか
4. セキュリティ問題（SQLインジェクション、XSS、機密情報の露出）
具体的な修正提案を出すこと。抽象的なアドバイスは不要。
Claude Codeを再起動して/reviewと入力すれば動作する。
固定内容のコマンドは用途が限られる。$ARGUMENTSを使えばコマンドが柔軟になる——/commandの後にユーザーが入力した内容がプロンプトに埋め込まれる。
例：.claude/commands/test.md：
以下のコードのテストを書いてください：$ARGUMENTS
要件：
- 正常系とエッジケースをカバーする
- テスト名は自己説明的にする
- 実データが使えるところはmockしない
使い方：
/test UserAuthenticationクラスのloginメソッド
Claudeが受け取る実際のプロンプト：
以下のコードのテストを書いてください：UserAuthenticationクラスのloginメソッド
要件：
- 正常系とエッジケースをカバーする
...
$ARGUMENTSはプロンプトのどこにでも書けて、複数回使うこともできる。
1つのコマンド、1つの責務
すべてのタスクを詰め込んだ「万能」コマンドは作らない。/reviewはコードレビュー専用、/testはテスト作成専用、/prはPR説明文生成専用。粒度の細かいコマンドほど覚えやすく、再利用しやすい。
プロンプトは具体的に書く
悪い例：
このコードを最適化して
良い例：
```
このコードのパフォーマンスを最適化してください。優先順位：
1. 不要なデータベースクエリの削減（N+1問題）
2. ループ内の重複計算の排除
3. 線形探索をより効率的なデータ構造で置き換え
インターフェースは変更せず、内部実装のみ変える。
```
具体的な制約があってこそ、Claudeから的を絞った回答が得られる。
コマンドにfrontmatterを追加する
ファイル先頭にメタデータを追加すると、Claude Codeのコマンド一覧にdescriptionが表示され、チームメンバーが用途をすぐ把握できる：
---
description: 現在の変更をレビューし、コード品質フィードバックを提供
---
現在の変更のコード品質をレビューしてください...
Railsプロジェクトを例に、日常開発の頻出シーンをカバーするコマンドセットを紹介する：
.claude/commands/review.md — コードレビュー
git diffの変更をレビューしてください。確認事項：
- ロジックエラーと境界条件の処理
- SQLインジェクション、認可チェックなどのセキュリティ問題
- 命名の可読性
- 抽出できる重複ロジック
各問題について具体的な場所と修正提案を示すこと。
```
.claude/commands/test.md — テスト生成
このコードのテストを書いてください：$ARGUMENTS
RSpecを使用。カバー範囲：正常系、境界値、エラーケース。
テスト命名フォーマット：describe ... context ... it ...
デフォルトは実オブジェクトを使い、外部依存のみ必要に応じてmock。
```
.claude/commands/pr.md — PR説明文
git diffとcommit logを元に、PR説明文を生成してください。
フォーマット：
（何をしたか2〜3文で）
（背景と動機）
（この変更をどう検証するか）
簡潔に、コードレビュアー向けの文体で。
```
.claude/commands/explain.md — コード説明
$ARGUMENTS の役割を説明してください：
- 全体的な責務は何か
- 主要なロジックはどう動くか
- 注意すべき境界ケースはどれか
このコードを初めて触る開発者向けに、「何をしているか」ではなく「なぜそうするか」を中心に説明すること。
```
チーム全体に強制すべきでない個人的な習慣は~/.claude/commands/に置く：
~/.claude/commands/standup.md — 朝会準備
```markdown
今日のgit logと未解決のTODOを元に、朝会サマリーを作成してください：
- 昨日完了したこと
- 今日の予定
- ブロッカーがあるか
5文以内に収めること。
```
~/.claude/commands/refactor.md — リファクタリング提案
```markdown
$ARGUMENTS を分析し、リファクタリングの提案をしてください。
リファクタリングのためのリファクタリングは不要。本当に価値のある変更だけ挙げること。
各提案には：解決する問題、作業量の大きさ、リスクを説明すること。
```
カスタムコマンドの最大の価値は個人の生産性向上ではなく、チームの共通言語を作ることにある。
.claude/commands/をリポジトリにコミットし、READMEやCLAUDE.mdで利用可能なコマンドと用途を記載する。新メンバーがリポジトリをcloneした瞬間から、チームが積み上げたプロンプト資産を自分で探す手間なく使える。
プロジェクトが進化するにつれ、コマンドも進化する。効果の薄いプロンプトを見つけたら1行修正してpushするだけで、チーム全体に反映される。これがチームレベルでプロンプトエンジニアリングを浸透させる最もコストの低い方法だ。
.claude/
├── commands/
│ ├── review.md # コードレビュー
│ ├── test.md # テスト生成
│ ├── pr.md # PR説明文
│ └── explain.md # コード説明
└── settings.json