Claude CodeのCustom Slash Commandsで定型作業を効率化しよう
Claude Codeは、CLAUDE.mdをかなり読んでくれているなという印象がありますが、やっぱり指示に従ってくれないことありますよね。
例えばこんな指示を入れています。
## 重要な開発ルール
**タスクを完了する前に、必ず以下のコマンドがすべてエラーなく通過することを確認してください:**
pnpm lint # Biomeによるリントチェック(warning含めすべて修正)
pnpm format # Biomeによるフォーマット
pnpm typecheck # TypeScriptの型チェック
これらのチェックが通らない場合は、タスクは完了していません。
重要な開発ルール
って書いてるのになかなか守ってくれないんですよ。
そこで、Custom Slash Commands です!
ルールを徹底してくれないのであれば、こちらから簡単に指示して動くようにしましょう。
Custom Slash Commands とは
よく使うプロンプトをMarkdownファイルに保存しておき、Claude Codeから簡単に実行できる仕組みのことです。
Hooksとの違い
Hooksは最近入った機能なんですかね(日本語訳もないし)。どっちも似たような機能なのかなと気になったので違いをまとめました。
特徴 | Hooks | Custom Slash Commands |
---|---|---|
実行方法 | 自動(イベント駆動) | 手動(コマンド入力) |
実行内容 | シェルコマンド | プロンプト(Markdown) |
用途 | システム動作の拡張 | プロンプトの再利用 |
設定方法 | JSONで設定 | Markdownファイルを作成 |
引数 | JSON入力を受け取る | $ARGUMENTSで引数を受け取る |
簡単な説明
- Hooks:Claude Codeの動作を自動化・カスタマイズするための機能
- Custom Slash Commands:よく使うプロンプトをショートカット化するための機能
ユースケースと例
「毎回やってほしいことを確実に実行してほしい」という課題に対して、HooksもCustom Slash Commandsも同じような解決策を提供します。
使い分けのポイントは実行タイミングと頻度にあります。
コードフォーマットのような単純な処理は、ファイル編集後の自動実行(Hooks)が適しています。一方、lintチェックやテスト修正のような複雑なタスクは、Claude Codeの実行計画に組み込むには重すぎるでしょう。
公式ドキュメントのmatchersを見る限り、Hooksは比較的シンプルな処理を想定しているようです。
実際に私が使っているCustom Slash Commandの例を紹介します。ちなみに、Markdown自体もClaude Codeに書かせていますので、特段難しい点はないかなと思います。
コードの品質をチェックする
---
description: Run all quality assurance checks (lint, format, typecheck, test)
allowed-tools:
- Bash
---
プロジェクト全体の品質保証チェックを実行します。
## 1. Lintチェック(Biome)
!pnpm lint
## 2. フォーマットチェック(Biome)
!pnpm format
## 3. 型チェック(TypeScript)
!pnpm typecheck
## 4. テスト実行(Vitest)
!pnpm test
CLAUDE.mdに記載されている通り、これらすべてのチェックがエラーなく通過する必要があります。
適切な粒度でコミットする
---
description: Commit changes with appropriate granularity
allowed-tools:
- Bash(git add:*)
- Bash(git commit:*)
- Bash(git status:*)
- Bash(git diff:*)
- Bash(git log:*)
---
## 適切なコミット粒度
### 基本原則
- 1つのコミットには1つの論理的な変更のみを含める
- 関連する変更はまとめて、無関係な変更は分離する
- コミットメッセージから変更内容が明確に理解できる粒度にする
### 良いコミットの例
- ✅ 単一機能の追加: `feat: メニュー取得APIを実装`
- ✅ 単一バグの修正: `fix: ログイン時のセッションエラーを修正`
- ✅ 関連するリファクタリング: `refactor: 認証ロジックを共通化`
### 避けるべきコミットの例
- ❌ 複数の無関係な変更: `feat: ログイン機能追加、メニュー表示修正、READMEリファクタリング`
- ❌ 大きすぎる変更: `feat: 連携機能全体を実装`
- ❌ 小さすぎる変更: `fix: タイポ修正` (複数のタイポはまとめる)
### コミット分割の判断基準
1. **機能的な独立性**: 他の変更なしに動作するか
2. **レビューの容易さ**: 差分が理解しやすいサイズか
3. **履歴の追跡性**: 後から特定の変更を見つけやすいか
### 実行例
```bash
# 変更内容を確認
git status
git diff
# 関連する変更のみをステージング
git add packages/agent/src/tools/weather.ts
git add packages/agent/src/types/weather.ts
# コミット
git commit -m "feat(agent): 天気取得ツールを追加"
# 別の変更を別コミットで
git add packages/web/app/routes/weather.tsx
git commit -m "feat(web): 天気表示画面を実装"
困ったこと・工夫したところ
allowed-tools
でgit commitを許可しているのに、毎回実行前に聞かれる。
おそらく、git commit -a ~~ のあとが可変なので自動許可にひっかかってないのかなぁと思います。コミットは最終段階なので、手動でapproveすることにしましたが、余裕があれば改善したいです。
あとタスクが終わったことを知りたいので、通知できないか調べていたらこんな素敵な記事を見つけました。
まとめ
Custom Slash Commandsを設定することで、タスクの遂行からコード品質チェック、git commitまでを省力化して確実に回せるループができ、コードレビューや動作確認に専念できるようになりました。
Claude Codeはどんどん新機能が出てくるのでキャッチアップが大変ですが、Hooksも積極的に使っていこうと思います。
Discussion