0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shoki-kanno

Claude Code カスタムコマンド完全ガイド - プロンプトを資産化する

Posted at

はじめに

Claude Code を使っていると、こんな場面に遭遇しませんか?

  • 「毎回同じ手順を説明するのが面倒...」
  • 「新機能実装のたびに『まず要件確認して、調査して、計画立てて...』と繰り返している」
  • 「チームメンバーによって実装の進め方がバラバラ」

これらの悩みは カスタムコマンド で解決できます。

本記事では、実際のモノレポプロジェクトで運用しているカスタムコマンドを例に、プロンプトの資産化と共有方法を解説します。

カスタムコマンドとは

カスタムコマンドは Markdown ファイルで保存されたプロンプト です。

# Before: 毎回手順を説明
> NestJSで新機能作りたい。まず要件確認して、既存コード調査して、
> PR分割計画立てて、基盤実装して、API実装して...

# After: 1コマンドで実行
> /backend:new-feature ユーザー管理

コマンドを実行すると、定義したワークフローに沿って Claude が自動的に進行します。

プロジェクト構成

NestJS（バックエンド）と Expo（フロントエンド）のモノレポを例に説明します。

project/
├── backend/                 # NestJS バックエンド
├── frontend/                # Expo フロントエンド
└── .claude/
    ├── commands/            # カスタムコマンド
    │   ├── backend/
    │   │   ├── new-feature.md
    │   │   ├── bug-fix.md
    │   │   └── refactoring.md
    │   └── frontend/
    │       ├── new-feature.md
    │       ├── bug-fix.md
    │       └── refactoring.md
    └── settings.json        # グローバル設定

コマンド一覧

コマンド 用途
/backend:new-feature NestJS 新機能実装（PR分割）
/backend:bug-fix NestJS バグ修正
/backend:refactoring NestJS リファクタリング
/frontend:new-feature Expo 新機能実装
/frontend:bug-fix Expo バグ修正
/frontend:refactoring Expo リファクタリング

コマンドの配置場所

カスタムコマンドは 2つのスコープ で配置できます。

スコープ パス 用途
個人用 ~/.claude/commands/ 自分だけの汎用コマンド
プロジェクト用 .claude/commands/ チームで共有、Git 管理

ファイル名とディレクトリがコマンド名になります:

.claude/commands/backend/new-feature.md  →  /backend:new-feature
.claude/commands/frontend/bug-fix.md     →  /frontend:bug-fix

基本構文

$ARGUMENTS で引数を受け取る

# NestJS 新機能実装テンプレート

NestJS バックエンドの新機能実装を行います。

機能名: $ARGUMENTS

実行例:

> /backend:new-feature ユーザー管理
# → 機能名: ユーザー管理

実例: 新機能実装コマンド

/backend:new-feature の構成を見てみましょう。このコマンドは PR 分割まで含む複雑なワークフローを自動化します。

全体構成

# NestJS 新機能実装テンプレート（並列型PR分割）

機能名: $ARGUMENTS

---
## ブランチ構成（並列型）
---
## フェーズ1: 要件確認（AskUserQuestion）
---
## フェーズ2: Explore（コードベース調査）
---
## フェーズ3: Plan（PR分割計画）
---
## フェーズ4: PR1（基盤）実装
---
## フェーズ5: API PR実装（PR2〜PR6）
---
## 完了報告
---
## 並列型の注意点

--- で区切ることで、各フェーズの境界を明確にしています。

ブランチ構成を最初に明示

## ブランチ構成（並列型）

feature/${FEATURE_NAME}（親ブランチ）
  ├── feature/${FEATURE_NAME}-base（PR1: 基盤）
  ├── feature/${FEATURE_NAME}-create（PR2: create API）
  ├── feature/${FEATURE_NAME}-get（PR3: get API）
  ├── feature/${FEATURE_NAME}-list（PR4: list API）
  ├── feature/${FEATURE_NAME}-update（PR5: update API）
  └── feature/${FEATURE_NAME}-delete（PR6: delete API）

全てのブランチは親ブランチから分岐する。
PR1のマージを待たずにPR2〜PR6の実装を開始できる。

全体像を最初に示すことで、Claude が迷わず進行できます。

AskUserQuestion で情報収集

## フェーズ1: 要件確認（AskUserQuestion）

`AskUserQuestion`ツールで以下を確認する:

1. **概要**: 何を実現したいか
2. **要件リスト**: 具体的な要件（CRUD、一覧、特殊操作）
3. **ベースブランチ**: 選択肢は「develop（推奨）」のみ

### 変数の確定

FEATURE_NAME=[kebab-caseの機能名]
FEATURE_BRANCH=feature/${FEATURE_NAME}

Claude に「何を聞くべきか」を指示し、収集した情報を変数として整理します。

サブエージェントの呼び出し

## フェーズ3: Plan（PR分割計画）

Task(subagent_type="planner", prompt="
【機能名】${FEATURE_NAME}
【要件】${REQUIREMENTS}

以下を作成してください:
1. API一覧の洗い出し
2. PR分割計画
3. ブランチ構成
4. 各PRの成果物リスト
")

### ユーザー承認（必須）

PR分割計画についてユーザーの承認を得る:
- **承認** → フェーズ4へ進む
- **修正要求** → Plan を更新

Task() でサブエージェントを呼び出し、専門的なタスクを委譲しています。

エージェント 役割
planner PR分割計画の作成
architect 基盤実装（Prisma/Entity/Repository）
engineer API実装（TDD）
reviewer コードレビュー

ユーザー承認ポイント

### ユーザー承認待ち（必須）

## PR1（基盤）実装完了

**次のステップに進む前に確認してください:**
- [ ] PR1の内容をレビュー
- [ ] 基盤の設計に問題がないか確認

**承認する場合**: 「PR2以降の実装を開始してください」と伝えてください

大きな作業の前に承認を挟むことで、手戻りを防止しています。

TDD の強制

## フェーズ5: API PR実装（PR2〜PR6）

Task(subagent_type="engineer", prompt="
【API名】${API_NAME}

TDDで実装してください:
1. Handler テスト作成
2. Command/Query + Handler 実装
3. DTO 実装
4. Resolver 実装
5. Repository メソッド実装
6. 全テスト実行
")

「テストを先に書く」という順序を明示。チーム全体で TDD を徹底できます。

CLAUDE.md への参照

backend/CLAUDE.md のコーディング規約に従ってください。

プロジェクト固有のルールを参照させることで、一貫したコードスタイルを維持。

settings.json でグローバル制約

.claude/settings.json でプロジェクト全体のルールを定義できます。

{
  "instructions": "絵文字を使用しない。any型を使用しない。"
}

どのコマンドを使っても、この制約が自動適用されます。

コマンド設計のパターン

パターン1: フェーズ分割

フェーズ1: 要件確認
    ↓
フェーズ2: 調査
    ↓
フェーズ3: 計画 + 承認
    ↓
フェーズ4: 実装
    ↓
フェーズ5: レビュー
    ↓
完了報告

パターン2: 承認ゲート

### ユーザー承認（必須）

計画についてユーザーの承認を得る:
- **承認** → 次のフェーズへ進む
- **修正要求** → Plan を更新

パターン3: 変数の確定

### 変数の確定

FEATURE_NAME=[kebab-caseの機能名]
BRANCH_PREFIX=feature/
BASE_BRANCH=[確認したベースブランチ]

パターン4: サブエージェント委譲

Task(subagent_type="engineer", prompt="
【タスク】API実装

TDDで実装してください:
1. テスト作成
2. 実装
3. リファクタリング
")

パターン5: 成果物の明示

## 成果物構成

src/modules/${FEATURE_NAME}/
├── commands/
│   └── create-xxx/
├── queries/
│   └── get-xxx/
└── domain/
    └── xxx.entity.ts

Tips

1. 名前空間でコマンドを整理

.claude/commands/
├── backend/     # /backend:xxx
└── frontend/    # /frontend:xxx

2. CLAUDE.md を参照させる

各コマンドで「〇〇/CLAUDE.md に従ってください」と明示することで、プロジェクト固有のルールを適用。

3. 完了報告のフォーマット統一

## 実装完了

| PR | API | 状態 |
|----|-----|------|
| PR1 | 基盤 | 完了 |
| PR2 | create | 完了 |
...

4. 並列型 vs 直列型

方式 特徴 適用場面
並列型 全PRが親から分岐、並列実装可能 大規模機能
直列型 前のPRに依存、順番に実装 小規模機能

まとめ

カスタムコマンドを活用することで:

  • 開発フローの標準化 - 誰が実行しても同じ手順
  • 品質の均一化 - TDD、レビュー、承認の強制
  • 知識の資産化 - ベストプラクティスを Git 管理

参考

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?