ENECHANGE Developer Blog

ENECHANGE開発者ブログ

Claude Codeカスタムスラッシュコマンド集 Part1

こんにちは、ENECHANGEエンジニアの片田です。

前回の岡本さんの記事では、「エンジニア採用はどこへ向かう?AIエージェント時代の"選ばれる現場"とは」というテーマで、AIエージェントの活用能力が採用の重要な判断材料になっているという興味深い内容でした。まさに現在進行形で起きている変化ですね。

tech.enechange.co.jp

さて、弊社ではClaude CodeのMaxプラン(100$)を一部エンジニアに向けて経費申請で使えるようにしてもらっています。

今回は、Claude Codeのカスタムスラッシュコマンドを活用して、開発・業務効率を向上させるために作成したコマンドをいくつか紹介します!(タイトルに「Part1」と付けているのは、後続のリレーで同じタイトルで書きたい人がいるかもしれないからです)

  • カスタムスラッシュコマンドを作ることができるのは知っているけどどんなものを作ればいいのか迷っている
  • 他の人がどんなコマンドを作っているのか知りたい

という方にぜひ読んでいただければと思います!

カスタムスラッシュコマンドとは?

色々な記事で紹介されているので、Claude Code使いの方はご存知かもしれませんが、Claude Codeには、繰り返し使うプロンプトを保存して簡単に呼び出せる「カスタムスラッシュコマンド」という機能があります。

簡単に言えば、「よく使うプロンプトのショートカット」のようなものです。

詳細な機能や作り方については、公式ドキュメントをご参照ください。

簡単な作り方

基本的には、特定のディレクトリにMarkdownファイルを作成するだけです。 公式の例を参考に簡単な作り方を紹介します。

# プロジェクト固有のコマンド(チームで共有)
mkdir -p .claude/commands
echo "このコードのリファクタリング案を提案してください" > .claude/commands/refactor.md

# 個人用コマンド(全プロジェクトで使用可能)
mkdir -p ~/.claude/commands
echo "このコードの単体テストを作成してください" > ~/.claude/commands/test.md

これで/project:refactor(リファクタリング案提案)や/user:test(テスト作成)が使えるようになります。

実際に作成したコマンドたち

1. branch-commit-push-pr.md(チェックアウト〜PRを作成する)

公式の例(スラッシュコマンド - Anthropic)を活用して、実装内容のPR作成までをワンライナーで実施できるようなコマンドを作成しました。 軽量なタスクを実行する時に役立ってます。

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git push:*), Bash(git checkout:*)
description: Create a git commit
---

## Context

- Current git status: !`git status`
- Current git diff (staged and unstaged changes): !`git diff HEAD`
- Is on base branch: !`current=$(git branch --show-current); default=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main"); [ "$current" = "$default" ] && echo "Yes" || echo "No"`
- Recent commits: !`git log --oneline -10`
- PR template exists: !`test -f .github/PULL_REQUEST_TEMPLATE.md && echo "Yes" || echo "No"`
- PR template content (if exists): !`test -f .github/PULL_REQUEST_TEMPLATE.md && cat .github/PULL_REQUEST_TEMPLATE.md`

## Your task

- 現在のブランチがベースブランチの場合は、変更内容を確認して適切なブランチ名を提案し、チェックアウトが必要かどうかをユーザーに確認してください
- チェックアウトが必要な場合はチェックアウトを実行してください
- コミットを適切な粒度に分けて、適切なコミットメッセージでコミットしてください
- コミットメッセージは日本語で記載してください
- コミット完了後は、リモートリポジトリへのプッシュを実行してください
- PR作成のための文言を考えて、ユーザーに提供してください。`.github/PULL_REQUEST_TEMPLATE.md`がある場合は、その形式に準拠してください

実行してみた結果を一部抜粋します。 いい感じにできてそうです!ちゃんとリポジトリ内の PULL_REQUEST_TEMPLATE.md も読んでくれてます。

⏺ 作業完了

  ✅ コミットとプッシュが完了しました

  - コミット: xxxxxx テストファイルとコード生成ファイルを更新
  - プッシュ: feature/add-test ブランチをリモートリポジトリにプッシュ

  PR作成用の文言

  以下のテンプレートに従ってPRを作成してください:

  ## What
  充電状態画面コントローラーのテストに関連するファイル更新

  ## How
  - 充電状態画面コントローラーのモックファイル(`controller_test.mocks.dart`)を追加
  - コード生成ファイル(Freezed、json_serializable、国際化)を更新
  - Google Place検索アプリケーションサービスのテストを修正

  ## Why ( option )
  テストの実行やコード生成の結果として自動的に生成されたファイルの更新

  ## 特にレビューして欲しい部分 ( option )
  - 新規追加されたモックファイルの内容
  - テストファイルの修正内容

  ## Links ( Asanaチケットやその他共有したいリンク )
  (該当する場合は追加)

  ## Other
  自動生成ファイルの更新が主な内容のため、手動でのコードレビューは最小限で問題ありません。

  ## Screenshot ( option )
  テストファイルの更新のため、スクリーンショットは不要です。

2. quality-check(コードベース品質チェック)

どうして開発チームはClaude Codeをうまく活用できないのかという記事を読んで、自分たちのリポジトリの現状を客観的に把握したいと思いました。

記事内で参考指標として記載されている内容が、指定したリポジトリに当てはまるかをチェックするコマンドを作成しました。 あくまでも最終的にはチームで議論して現状分析を行いますが、パッと客観視した結果が欲しかったので作成してみました。

Vite + React プロジェクトにフィットさせてみました。

---
description: コードベースの品質を包括的にチェックし、改善点を特定する
---

# コードベース品質チェック

プロジェクトのコードベース品質を包括的に分析し、改善が必要な項目を特定します。

## チェック項目

以下の品質指標を確認します:

1. **自動テスト**
   - テストファイルの存在と実行状況
   - テストカバレッジ
   - 失敗しているテストの特定

2. **CI/CD設定**
   - GitHub Actions、AWS CodeBuild等の設定確認
   - デプロイプロセスの状態

3. **依存関係**
   - 古いパッケージの特定
   - セキュリティ脆弱性の確認

4. **コード品質**
   - 巨大ファイル(500行以上)の検出
   - 型定義の網羅性
   - エラーハンドリング状況

5. **ツール設定**
   - Linter/Formatterの設定確認
   - API文書の自動生成設定

## 追加オプション

$ARGUMENTS

## 実行されるチェック

!`find . -name "*.test.*" -o -name "*.spec.*" | grep -v node_modules | wc -l`
!`npm outdated | head -20`
!`find app -name "*.ts" -o -name "*.tsx" | xargs wc -l | sort -nr | head -10`
!`grep -r "TODO\|FIXME" app/ --include="*.ts" --include="*.tsx" | head -10`
!`grep -r "try\|catch\|throw" app/ --include="*.ts" --include="*.tsx" | wc -l`

## 結果の出力

分析結果を以下の形式で出力します:

- ✅ 満たしている項目
- ⚠️ 改善が必要な項目(詳細な対応方法を含む)
- 🔍 追加の品質指標
- 📋 推奨される改善順序

結果は `code-quality-report.md` としてプロジェクトルートに保存します。

## 使用例

### 基本的な品質チェック
`/quality-check`

### 特定の項目にフォーカス
`/quality-check テストカバレッジを重点的に確認`

### セキュリティ関連に特化
`/quality-check セキュリティ脆弱性と依存関係の更新を優先`


@package.json
@vitest.config.ts
@codegen.config.ts

このコマンドを実行してみた結果の要約も添付しておきます。 実際はそれぞれの項目についてより詳細に記載されています。ざっと確認するにあたっては十分すぎる内容でした!

**✅ 満たしている項目**
- Linter/Formatter完備(ESLint、Prettier、Stylelint)
- 自動テスト導入済み(Vitest + React Testing Library、9ファイル32テストケース)
- GraphQL Code Generatorによる型安全な API ドキュメント自動生成
- Clean Architecture採用、統一されたコードスタイル
- 最新技術スタック(React 19、TypeScript 5.7、React Router v7)
- 豊富なエラーハンドリング(604箇所でtry/catch/throw使用)

**⚠️ 改善が必要な項目**
- CI環境未整備(GitHub Actions不在、AWS CodeBuildのみ)
- 依存関係の更新放置(61パッケージが古い、ESLint 8→9等のメジャーアップデート未対応)
- 巨大ファイル存在(FirebaseAuthUI.tsx: 4,884行、MapSearchTemplate.tsx: 1,318行等)
- テスト失敗中(4つのテストでモック設定不備)
- デプロイプロセスが煩雑

3. daily(日次スケジュール管理)

毛色が異なりますが、毎日のタスク管理を効率化するために作成したコマンドです。特定のフォルダ構造で日次のMarkdownファイルを自動生成し、前日の未完了タスクを引き継ぐ機能を持っています。

こんな感じのルーティンワークもカスタムスラッシュコマンドにするにはうってつけだと思います。

# コマンド
- 1日のスケジュールを作成します。

# 実行手順
1. !`date "+%F"`を実行してその日の日付を取得
2. 取得した日付を元に @/01_Daily_Activities 配下の該当の年月のフォルダに !`date +'%Y%m%d'` で実行した結果のファイル名でMarkdownファイルを作成
    - 必ず1で取得した日付を使う、推測で日付を決定しないこと
    - すでに該当するフォルダがある場合は `mkdir` は実行しないこと
3. 直近の日付のMarkdownファイルを検索
4. 検索結果のファイル内の継続中含めた完了していないタスクを引用してくる(検索結果が存在しない場合はそのまま)
    - 困っていることの内容は引用しない、同じ困りごとが継続するわけではないので

私は日頃こんな感じのMarkdownでTODO管理してます。

# 2025/07/09 TODOリスト

## 💡 重要(2個まで)

- [ ]  XXXXX

## PJ A
- [x]  YYYYY
- ZZZZZ
- [x] AAAAA
- [x] BBBBB
- CCCCC

## PJ B
- [x] DDDDD
- [ ]  EEEEE
- [x] FFFFF
- [継続] GGGGG
- [x]  HHHHH
- [ ] [IIIII]()

## その他
- [ ] JJJJJ
- [x] KKKKK

これに /daily を実行してあげると、20250710.mdのファイル名で下記の内容が出力されます!

# 2025/07/10 TODOリスト

## 💡 重要(2個まで)

- [ ] XXXXX

## PJ A
- ZZZZZ
- CCCCC

## PJ B
- [ ] EEEEE
- [継続] GGGGG
- [ ] [IIIII]()

## その他
- [ ] JJJJJ

あとはその日にやることを足してあげればTODOリストが完成するという流れです。 独自のTODO管理方法があると思うので、ぜひ加工して使ってみてください。

まとめ

Claude Codeのカスタムスラッシュコマンドは、単純ながら強力な機能です。また、プロジェクトコマンドとして共有することで、チーム全体の生産性向上にもつながります。

今後の課題として、コマンドが増えてきた時の管理方法や、コマンドの命名規則などがあがりそうですが、運用しながら考えていきたいと思います。

皆さんもぜひ、自分なりのカスタムスラッシュコマンドを作って、Claude Codeをさらに便利に使いこなしてみてください!


次回は私と同じチームの木原さんもClaude Codeに関連した内容について語ってくださる予定です。お楽しみに!