結論：12個のスラッシュコマンドで「考える前に手が動く」開発体験が手に入る

Claude Codeのカスタムスラッシュコマンドは、公式ドキュメントでは数行しか触れられていないですが、正しく設計すれば 「AIに口頭で指示するより速い開発体験」 が手に入ります。

この記事では、設計・実装・レビュー・運用の全フェーズをカバーする 12個のカスタムスラッシュコマンド を、コピペで使える完全なソースコード付きで公開します。

この記事でわかること：

カスタムスラッシュコマンドの仕組みとディレクトリ構造
開発フロー全体を自動化する12個のコマンド設計
チームで共有するためのGit管理のコツ

環境・前提条件

項目	バージョン・条件
Claude Code	最新版（2025年7月時点）
OS	macOS / Linux / WSL2
シェル	Bash / Zsh
前提知識	Claude Codeの基本操作、Git基礎

カスタムスラッシュコマンドの仕組み

.claude/commands/ ディレクトリの構造

カスタムスラッシュコマンドは、プロジェクトルートの .claude/commands/ ディレクトリにMarkdownファイルを置くだけで登録できます。

your-project/
├── .claude/
│   └── commands/
│       ├── design.md        # /design で呼び出し
│       ├── breakdown.md     # /breakdown で呼び出し
│       ├── estimate.md      # /estimate で呼び出し
│       ├── scaffold.md      # /scaffold で呼び出し
│       ├── implement.md     # /implement で呼び出し
│       ├── test.md          # /test で呼び出し
│       ├── review.md        # /review で呼び出し
│       ├── refactor.md      # /refactor で呼び出し
│       ├── security.md      # /security で呼び出し
│       ├── doc.md           # /doc で呼び出し
│       ├── changelog.md     # /changelog で呼び出し
│       └── shipit.md        # /shipit で呼び出し
├── src/
└── ...

基本ルールはシンプルです：

ファイル名がそのままコマンド名になる（design.md → /project:design）
ファイルの中身がプロンプトとしてClaude Codeに渡される
$ARGUMENTS プレースホルダーでコマンド引数を受け取れる
ユーザー個人用は ~/.claude/commands/ に置く

開発ライフサイクル全体俯瞰

まず、12個のコマンドが開発フローのどこにマッピングされるか全体像を把握しましょう。

設計フェーズ：/design・/breakdown・/estimate

1. /design ― 要件からアーキテクチャ提案

.claude/commands/design.md

要件に基づいてアーキテクチャを設計してください。

## 入力要件
$ARGUMENTS

## 実行手順
1. プロジェクトの既存コードベースを読み取り、技術スタック・ディレクトリ構造を把握する
2. 入力要件を機能要件と非機能要件に分類する
3. 既存アーキテクチャとの整合性を考慮した設計案を最大3つ提案する
4. 各案について以下を明記する：
   - コンポーネント構成図（Mermaid記法）
   - 主要なデータフロー
   - 採用する設計パターン
   - メリット・デメリット
   - 既存コードへの影響範囲
5. 推奨案を1つ選び、理由を説明する

## 出力フォーマット
Markdownで出力し、`docs/design/` ディレクトリに保存すること。
ファイル名は `YYYY-MM-DD-<feature-name>.md` 形式にする。

使い方：

> /project:design ユーザー認証機能をOAuth2.0で実装したい。Google/GitHubログインに対応し、既存のセッション管理と統合する

2. /breakdown ― タスク分解

.claude/commands/breakdown.md

設計ドキュメントまたは要件をもとに、実装可能な粒度までタスクを分解してください。

## 対象
$ARGUMENTS

## 実行手順
1. 指定された設計ドキュメントまたは要件を読み込む
2. 以下の粒度でタスクを分解する：
   - Epic（大機能単位）
   - Story（ユーザー価値単位）
   - Task（1PR = 1タスクの粒度、目安: 2時間以内で完了）
3. 各タスクに以下を付与する：
   - 一意なID（例: TASK-001）
   - タイトル（動詞始まり）
   - 依存関係（ブロッカーとなるタスクID）
   - 推奨実装順序
   - 受け入れ条件（テスト可能な形式で）
4. 依存関係のDAGをMermaid図で出力する

## 出力フォーマット
Markdownのチェックリスト形式で出力する。

3. /estimate ― 工数見積もり

.claude/commands/estimate.md

タスクリストに対して工数を見積もってください。

## 対象
$ARGUMENTS

## 実行手順
1. 指定されたタスクリストを読み込む（ファイルパスまたはタスク内容）
2. プロジェクトの既存コードの複雑度を分析する
3. 各タスクに対して以下を見積もる：
   - 楽観値（Optimistic）
   - 最頻値（Most Likely）
   - 悲観値（Pessimistic）
   - 三点見積もり = (O + 4M + P) / 6
4. リスク要因を洗い出し、バッファを提案する
5. 合計工数とクリティカルパスを算出する

## 出力フォーマット
テーブル形式で出力する。単位は時間（h）。
不確実性が高い項目には ⚠️ マークを付ける。

実装フェーズ：/scaffold・/implement・/test

4. /scaffold ― ボイラープレート生成

.claude/commands/scaffold.md

指定されたコンポーネントのボイラープレートコードを生成してください。

## 対象
$ARGUMENTS

## 実行手順
1. プロジェクトの既存コード規約を分析する：
   - ディレクトリ構造のパターン
   - 命名規則（ファイル名、変数名、クラス名）
   - インポートスタイル
   - 既存の類似コンポーネントの構造
2. 既存パターンに完全に準拠したボイラープレートを生成する
3. 以下のファイルをセットで生成する：
   - メインのソースファイル
   - テストファイル（空のテストケース付き）
   - 必要に応じてindex/barrelファイルを更新
4. 生成したファイル一覧を報告する

## 制約
- 既存のLinter/Formatter設定に準拠すること
- 既存コードで使われていないライブラリを勝手に追加しないこと
- TODOコメントで実装すべき箇所を明示すること

5. /implement ― Issue番号指定で実装

.claude/commands/implement.md

指定されたIssueまたはタスクの内容に基づいて実装してください。

## 対象
$ARGUMENTS

## 実行手順
1. 指定されたIssue番号・タスクID・または要件テキストを解釈する
2. 関連する設計ドキュメント・既存コードを読み込む
3. 実装計画を立て、ユーザーに確認を求める：
   - 変更するファイル一覧
   - 追加するファイル一覧
   - 実装アプローチの概要
4. 承認後、以下の順序で実装する：
   a. 型定義・インターフェースの追加/変更
   b. メインロジックの実装
   c. エラーハンドリングの追加
   d. 既存コードとの統合ポイントの調整
5. 実装完了後、変更内容のサマリーを出力する

## 制約
- コミットは論理単位で分割すること
- 各コミットメッセージはConventional Commits形式にすること
- 既存テストが壊れていないか確認すること

6. /test ― テストコード自動生成

.claude/commands/test.md

指定されたファイルまたはモジュールに対してテストコードを生成してください。

## 対象
$ARGUMENTS

## 実行手順
1. 対象のソースコードを読み込み、テスト対象の関数・メソッドを列挙する
2. プロジェクトの既存テストコードを分析し、以下を把握する：
   - テストフレームワーク（Jest, pytest, Go testing 等）
   - テストのディレクトリ構造・命名規則
   - モック・スタブの使い方
   - テストヘルパー・フィクスチャの有無
3. 以下のカテゴリでテストを生成する：
   - 正常系テスト（Happy Path）
   - 境界値テスト（Edge Cases）
   - 異常系テスト（Error Cases）
   - 必要に応じて統合テスト
4. テストを実行し、全てパスすることを確認する
5. カバレッジが不足している箇所を報告する

## 制約
- テスト名は「何を」「どういう条件で」「どうなるか」が分かる命名にする
- 1テスト1アサーションを原則とする（複合アサーションが適切な場合は除く）
- テストの実行時間を意識し、不要なsleep等を入れない

レビューフェーズ：/review・/refactor・/security

7. /review ― 差分レビュー

.claude/commands/review.md

現在のGit差分をコードレビューしてください。

## 対象
$ARGUMENTS

## 実行手順
1. `git diff` または指定されたブランチとの差分を取得する
2. 以下の観点でレビューする：

### 正確性
- ロジックの誤り、off-by-oneエラー
- null/undefinedの未処理
- 競合状態・レースコンディション

### 設計
- SOLID原則への準拠
- 適切な責務分離
- 既存パターンとの一貫性

### パフォーマンス
- N+1クエリ
- 不要なメモリ確保
- 計算量の問題

### 可読性
- 不明瞭な命名
- 過度に複雑な処理
- コメントの過不足

3. 各指摘に重要度を付与する：
   - 🔴 MUST FIX: バグまたはセキュリティリスク
   - 🟡 SHOULD FIX: 設計改善・パフォーマンス
   - 🟢 NIT: スタイル・好みの範囲
4. 良い点も具体的に褒める（LGTM ポイント）

## 出力フォーマット
ファイルごとに指摘をグルーピングし、該当行番号を明記する。

8. /refactor ― リファクタ提案

.claude/commands/refactor.md

指定されたコードのリファクタリングを提案・実行してください。

## 対象
$ARGUMENTS

## 実行手順
1. 対象コードを読み込み、以下のコードスメルを検出する：
   - 重複コード（DRY違反）
   - 長すぎるメソッド/関数（20行超）
   - 深すぎるネスト（3段超）
   - 肥大化したクラス/モジュール
   - 原始型への執着（Primitive Obsession）
   - フィーチャーエンビー
2. 検出したスメルごとに以下を提示する：
   - 現状の問題点
   - 適用するリファクタリングパターン名
   - Before / After のコード例
   - リスク評価（既存機能への影響）
3. ユーザーの承認後、リファクタリングを実行する
4. 既存テストが全てパスすることを確認する

## 制約
- 動作を変えない（振る舞い保存）ことを最優先とする
- 一度に複数のリファクタリングを混ぜない
- テストがない箇所は、先にテストを追加してからリファクタする

9. /security ― セキュリティチェック

.claude/commands/security.md

指定されたコードまたはプロジェクト全体のセキュリティチェックを実施してください。

## 対象
$ARGUMENTS

## 実行手順
1. 対象コードを読み込み、OWASP Top 10を基準にチェックする：
   - A01: アクセス制御の不備
   - A02: 暗号化の失敗
   - A03: インジェクション（SQL, XSS, Command等）
   - A04: 安全でない設計
   - A05: セキュリティの設定ミス
   - A06: 脆弱なコンポーネント
   - A07: 認証の不備
   - A08: ソフトウェアとデータの整合性の不備
   - A09: ログとモニタリングの不備
   - A10: SSRF

2. 追加チェック項目：
   - ハードコードされたシークレット・APIキー
   - 不適切なエラーメッセージ（情報漏洩）
   - 入力値バリデーションの不足
   - 依存パッケージの既知の脆弱性

3. 各指摘に以下を付与する：
   - 深刻度: Critical / High / Medium / Low / Info
   - CWE番号（該当する場合）
   - 修正方法の具体的なコード例
   - 参考リンク

## 出力フォーマット
深刻度の高い順にソートして出力する。

運用フェーズ：/doc・/changelog・/shipit

10. /doc ― ドキュメント自動生成

.claude/commands/doc.md

指定されたコードのドキュメントを生成してください。

## 対象
$ARGUMENTS

## 実行手順
1. 対象のソースコードを読み込む
2. 以下のドキュメントを生成する：

### APIドキュメント（公開関数/メソッドが対象の場合）
- 関数シグネチャ
- パラメータの説明と型
- 戻り値の説明
- 使用例（コードブロック）
- 例外/エラーの説明

### モジュールドキュメント（ファイル/ディレクトリが対象の場合）
- モジュールの責務と概要
- 主要なクラス/関数の一覧と簡単な説明
- 依存関係
- 使い方のクイックスタート

### READMEの更新（プロジェクト全体が対象の場合）
- セットアップ手順の更新
- 新機能の使い方を追記
- 設定項目の更新

3. 既存のドキュメントスタイルに合わせる
4. JSDoc / docstring / GoDoc 等の形式でインラインコメントも追加する

## 制約
- 実装の内部詳細ではなく「使い方」にフォーカスする
- 自明なことは書かない（getter/setterの説明等）

11. /changelog ― 変更履歴作成

.claude/commands/changelog.md

最近の変更から変更履歴を作成してください。

## 対象
$ARGUMENTS

## 実行手順
1. 以下の情報源から変更内容を収集する：
   - `git log`（指定されたタグ/コミット範囲）
   - 差分のあるファイル一覧
   - コミットメッセージ
2. Keep a Changelog形式で分類する：
   - Added: 新機能
   - Changed: 既存機能の変更
   - Deprecated: 非推奨になった機能
   - Removed: 削除された機能
   - Fixed: バグ修正
   - Security: セキュリティ修正
3. 各エントリは以下を含む：
   - ユーザー目線の簡潔な説明（技術用語を最小限に）
   - 関連するIssue/PR番号
   - Breaking Changeの場合は ⚠️ マークと移行手順
4. CHANGELOG.md を更新する（既存内容は保持）

## 制約
- Conventional Commitsのprefixを活用する
- マージコミット・CI系コミットは除外する

12. /shipit ― PR作成〜マージ準備

.claude/commands/shipit.md

現在のブランチからPull Requestを作成し、マージ準備を整えてください。

## 対象
$ARGUMENTS

## 実行手順
1. 現在のブランチの状態を確認する：
   - 未コミットの変更がないか
   - ベースブランチとの差分
   - コンフリクトの有無

2. PR作成前のチェックリストを実行する：
   - [ ] 全テストがパスする
   - [ ] Linter/Formatterのエラーがない
   - [ ] 不要なconsole.log / print / debugコードがない
   - [ ] .envや秘匿情報がコミットに含まれていない
   - [ ] CHANGELOG.mdが更新されている

3. PR本文を生成する：
   - タイトル: Conventional Commits形式
   - 概要: 変更の背景と目的
   - 変更内容: 変更したファイルと内容の要約
   - テスト: 実行したテストと結果
   - スクリーンショット: UI変更がある場合のプレースホルダー
   - チェックリスト: レビュアー向け確認項目
   - 関連Issue: closes #xxx 形式

4. `gh pr create` コマンドでPRを作成する

## 制約
- PRが大きすぎる場合（変更ファイル20以上 or 差分500行超）は警告する
- draft PRにするかどうかユーザーに確認する

チームで共有する際のディレクトリ設計とGit管理のコツ

プロジェクト共有 vs 個人用の使い分け

# プロジェクト全員で共有（Gitにコミット）
your-project/.claude/commands/
    ├── design.md
    ├── implement.md
    └── ...

# 個人用（Gitにコミットしない）
~/.claude/commands/
    ├── my-snippet.md      # 自分だけのショートカット
    └── my-translate.md    # 翻訳用コマンド等

Git管理のベストプラクティス

# .gitignore には入れない（チーム共有するため）
# .claude/commands/

# ただし個人的なカスタマイズは除外する場合
.claude/commands/local-*.md

推奨ルール：

コマンドファイルもコードレビュー対象にする — プロンプトの品質がチームの生産性に直結します
命名規則を統一する — 動詞1語（design, review, ship）で揃えると覚えやすいです
READMEを置く — .claude/commands/README.md に各コマンドの一覧と使い方を書いておくと新メンバーのオンボーディングが楽になります
バージョニングを意識する — コマンドの変更履歴もコミットログで追えるようにしましょう

プロンプト設計のTips

12個のコマンドに共通する設計指針をまとめます。

設計指針	理由
`$ARGUMENTS` で入力を柔軟に受け取る	ファイルパス、Issue番号、自由テキストなど様々な入力に対応
「実行手順」を番号付きで明記する	Claude Codeが手順を飛ばさず実行する確率が上がる
「制約」セクションを設ける	やってほしくないことを明示しないと勝手に余計なことをされる
「出力フォーマット」を指定する	毎回出力が安定し、後工程で使いやすくなる
既存コードの読み取りを指示に含める	プロジェクトの規約に合ったコードが生成される

まとめ

カスタムスラッシュコマンドは .claude/commands/ にMarkdownを置くだけ で使える。12個のコマンドで設計から出荷まで、開発フローの全フェーズをカバーできる
プロンプト設計の鍵は「手順の明示」「制約の明示」「出力フォーマットの指定」の3点。これを守るだけでコマンドの再現性が大幅に向上する
チームで .claude/commands/ をGit管理し、コードレビュー対象にする ことで、AI活用のナレッジがチーム全体の資産になる

参考リンク