スラッシュコマンドのまとめ記事は読んだ、でも「自分だけのコマンド」を作れることを知っていますか？
結論から言います。 Claude Codeでは .claude/commands/ ディレクトリにMarkdownファイルを置くだけで、チーム専用のスラッシュコマンドを作成できます。これにより、コードレビュー・テスト生成・PR作成といった繰り返しワークフローを「型化」し、チーム全員が同じ品質で実行できるようになります。
本記事では、組み込みコマンドとの違いから、実践レシピ5選、引数の設計、Git管理戦略までを網羅的に解説します。
環境・前提条件
| 項目 | 内容 |
|---|---|
| Claude Code | 最新版（2025年7月時点） |
| OS | macOS / Linux / Windows（WSL） |
| 前提知識 | Claude Codeの基本操作、Markdownの記法 |
| Git | チーム共有にはGitリポジトリ管理を推奨 |
1. 組み込みコマンド vs カスタムコマンド ― 何が違うのか
Claude Codeには、最初から使えるスラッシュコマンドがいくつか用意されています。まず、両者の違いを整理しましょう。
| 比較項目 | 組み込みコマンド | カスタムコマンド |
|---|---|---|
| 提供元 | Anthropic公式 | ユーザー / チーム |
| 例 |
/init, /compact, /review, /clear
|
/project:review-ja, /user:gen-test など |
| カスタマイズ | 不可 | 自由にプロンプトを設計可能 |
| 配置場所 | Claude Code本体に内蔵 |
.claude/commands/（プロジェクト）または ~/.claude/commands/（ユーザー） |
| 引数 | コマンドごとに固定 |
$ARGUMENTS で自由に受け取り可能 |
| チーム共有 | 全員同じ | Gitで共有・管理できる |
ポイント: 組み込みコマンドは「汎用的な便利機能」、カスタムコマンドは「チームの文脈に最適化された専用ツール」です。
2. .claude/commands/ ディレクトリの構造と命名規則
カスタムコマンドの仕組みは非常にシンプルです。
ディレクトリ構造
your-project/
├── .claude/
│ └── commands/ # プロジェクトスコープ（/project: で呼び出し）
│ ├── review.md
│ ├── gen-test.md
│ └── create-pr.md
└── src/
└── ...
~/.claude/
└── commands/ # ユーザースコープ（/user: で呼び出し）
├── my-refactor.md
└── my-doc.md
命名規則
-
ファイル名 = コマンド名（拡張子
.mdを除いた部分） - ファイル名にはケバブケース（
gen-test.md）を推奨 - プロジェクトスコープは
/project:ファイル名で呼び出し - ユーザースコープは
/user:ファイル名で呼び出し
コマンドファイルの中身
Markdownファイルの中身がそのまま Claude Codeへのプロンプト になります。
<!-- .claude/commands/review.md -->
以下のコードを日本語でレビューしてください。
## レビュー観点
- バグの可能性
- パフォーマンス上の懸念
- 可読性・命名の改善点
- セキュリティリスク
## 対象
$ARGUMENTS
これだけで /project:review src/main.ts と実行すれば、指定ファイルを上記の観点でレビューしてくれます。
3. 実践レシピ5選
現場ですぐ使えるカスタムコマンドを5つ紹介します。
レシピ①: コードレビュー依頼 (review.md)
以下のファイルを日本語でコードレビューしてください。
## レビュー観点（優先度順）
1. **バグ・ロジックエラー**: 実行時に問題を起こす可能性のあるコード
2. **セキュリティ**: インジェクション、認証漏れ、機密情報の露出
3. **パフォーマンス**: N+1クエリ、不要なループ、メモリリーク
4. **可読性・保守性**: 命名、関数の長さ、責務の分離
## 出力フォーマット
各指摘は以下の形式で出力してください:
- 🔴 **Critical** / 🟡 **Warning** / 🔵 **Info**
- 該当行番号
- 問題の説明
- 改善案（コード例付き）
## 対象
$ARGUMENTS
使い方: /project:review src/services/auth.ts
レシピ②: テスト生成 (gen-test.md)
指定されたファイルのユニットテストを生成してください。
## 要件
- テストフレームワーク: このプロジェクトで使用しているものを自動検出してください
- カバレッジ: 正常系・異常系・境界値を網羅
- テストの命名: 日本語の説明文（`it("ユーザーが未認証の場合403を返す")` 形式）
- モック: 外部依存は適切にモック化
## 出力
テストファイルを適切なディレクトリに作成してください。
ファイル作成後、テストを実行して結果を報告してください。
## 対象
$ARGUMENTS
使い方: /project:gen-test src/services/user-service.ts
レシピ③: PR作成 (create-pr.md)
現在のブランチの変更内容からPull Requestの説明文を生成してください。
## 手順
1. `git diff main...HEAD` で変更差分を取得
2. 変更内容を分析
## PR説明文のフォーマット
概要
（1-2文で変更の目的を説明）
変更内容
- （主要な変更を箇条書き）
影響範囲
- （影響を受けるコンポーネント・API・画面）
テスト
- ユニットテスト追加/更新
- 動作確認済み
スクリーンショット
（UI変更がある場合のみ）
## 追加コンテキスト
$ARGUMENTS
使い方: /project:create-pr ログイン機能のリファクタリング
レシピ④: 設計ドキュメント生成 (design-doc.md)
以下の機能について設計ドキュメントを生成してください。
## ドキュメント構成
1. **概要**: 機能の目的と背景
2. **要件**: 機能要件・非機能要件
3. **アーキテクチャ**: コンポーネント図（Mermaid）
4. **データモデル**: ER図（Mermaid）
5. **API設計**: エンドポイント一覧（テーブル形式）
6. **シーケンス**: 主要フローのシーケンス図（Mermaid）
7. **考慮事項**: セキュリティ、パフォーマンス、後方互換性
8. **マイルストーン**: 実装フェーズの提案
## 出力先
docs/design/ ディレクトリにMarkdownファイルとして保存してください。
## 機能概要
$ARGUMENTS
使い方: /project:design-doc ユーザー招待機能：既存ユーザーがメールアドレスで新規ユーザーを招待できる
レシピ⑤: リファクタ提案 (refactor.md)
指定されたコードのリファクタリングを提案してください。
## 分析観点
- **DRY原則**: 重複コードの抽出
- **単一責任原則**: 関数/クラスの責務分離
- **複雑度**: 循環的複雑度が高い箇所の簡素化
- **型安全性**: any型の排除、型ガードの追加
- **モダン化**: 古いパターンの最新構文への置き換え
## 出力フォーマット
1. リファクタリング箇所の一覧（影響度順）
2. 各箇所について:
- Before（現状コード）
- After（改善コード）
- 理由（なぜ改善になるか）
3. リファクタリング手順（安全に進めるための順番）
## 注意
- 振る舞いを変えない（リグレッションを起こさない）
- 一度に大きく変えず、段階的に適用できる単位で提案
## 対象
$ARGUMENTS
使い方: /project:refactor src/controllers/order-controller.ts
4. 引数・$ARGUMENTSの使い方とプロンプトテンプレート設計
$ARGUMENTS の基本
$ARGUMENTS は、スラッシュコマンド実行時にコマンド名の後ろに入力したテキストすべてが展開されるプレースホルダーです。
/project:review src/main.ts
^^^^^^^^^^^^
ここが $ARGUMENTS に展開される
設計のコツ
1. 引数なしでも動くようにする
## 対象
$ARGUMENTS
上記が空の場合は、直前のコンテキスト（開いているファイルや直前の会話）を対象としてください。
2. 複数の引数を受け取るパターン
$ARGUMENTS は単一の文字列として展開されるため、構造化したい場合はフォーマットを指定します。
以下の情報をもとにコンポーネントを生成してください。
## 入力情報（スペース区切り）
$ARGUMENTS
入力は「コンポーネント名 配置ディレクトリ 説明」の順で解釈してください。
例: UserCard src/components ユーザー情報を表示するカード
3. プロンプトテンプレート設計の原則
テンプレートの構造として意識すべき5層:
- 役割定義 — Claudeの振る舞いを決める
- コンテキスト — プロジェクト固有の前提（使用技術、コーディング規約）
- タスク指示 — 具体的にやってほしいこと
- 出力フォーマット — 出力の形式・構造を明示
- 制約条件 — やってはいけないこと、注意事項
上級テクニック: 他ファイルの参照
コマンドのMarkdown内で、プロジェクトの設定ファイルやルールファイルを参照するよう指示できます。
まず以下のファイルを読み込み、プロジェクトの規約を理解してください:
- CLAUDE.md（プロジェクトルール）
- .eslintrc.js（Lint設定）
- tsconfig.json（TypeScript設定）
その上で、以下のコードをレビューしてください。
$ARGUMENTS
5. チームで共有する際のGit管理戦略とオンボーディング活用
Git管理のベストプラクティス
.claude/
├── commands/
│ ├── review.md # コードレビュー
│ ├── gen-test.md # テスト生成
│ ├── create-pr.md # PR作成
│ ├── design-doc.md # 設計ドキュメント
│ └── refactor.md # リファクタ提案
└── settings.json # プロジェクト設定（許可コマンド等）
ポイント:
-
.claude/commands/はGitで追跡する（.gitignoreに入れない） -
~/.claude/commands/は個人用なのでGit管理外 - コマンドの変更もコードと同様にPRでレビューする
チーム運用のルール
| ルール | 理由 |
|---|---|
| コマンド追加・変更はPR経由 | 品質管理とチーム合意 |
| READMEにコマンド一覧を記載 | 発見可能性を高める |
| コマンド名はチームで命名規約を統一 |
review vs code-review の混乱を防ぐ |
| 定期的に棚卸し（四半期に1回） | 使われていないコマンドの整理 |
オンボーディングでの活用
新メンバーがチームに参加したとき、カスタムコマンドは「チームの暗黙知を形式知にする装置」として機能します。
活用例:
<!-- .claude/commands/onboard.md -->
あなたは新しいチームメンバーのオンボーディングをサポートするメンターです。
## やること
1. このプロジェクトの README.md と CLAUDE.md を読み込む
2. ディレクトリ構造を分析して、アーキテクチャの概要を説明する
3. 主要な技術スタック・ライブラリを一覧にする
4. 開発環境のセットアップ手順を確認し、不足があれば補足する
5. 利用可能なカスタムスラッシュコマンドの一覧と使い方を紹介する
## 出力
日本語で、新メンバーが30分以内にプロジェクトの全体像を掴める説明を作成してください。
## 新メンバーの背景情報
$ARGUMENTS
使い方: /project:onboard バックエンドエンジニア歴3年、TypeScript経験あり、このプロジェクトは初めて
これにより、誰がオンボーディングしても一定品質の説明が提供されます。
まとめ
-
カスタムスラッシュコマンドは「Markdownファイルを置くだけ」で作れる —
.claude/commands/に.mdファイルを配置し、$ARGUMENTSで引数を受け取るだけのシンプルな仕組みです - 繰り返しタスクを「型化」することでチームの品質が安定する — レビュー観点の抜け漏れ、PR説明文のフォーマットばらつき、テスト品質の差が解消されます
- Git管理してPRでレビューすることで、コマンド自体もチームの資産になる — オンボーディング、コーディング規約の浸透、暗黙知の形式知化に活用できます