【Claude Codeの活用事例】よく使うカスタムスラッシュコマンド5選！

こんにちは。ファインディでソフトウェアエンジニアをしている千田（@_c0909）です。

2025年3月末頃からファインディに導入されたClaude Codeは、私たちの開発フローに大きな変化をもたらしました。特に私が注目し活用を進めてきたのが、カスタムスラッシュコマンドの機能です。

Claude Codeを初めて触った時は、CLAUDE.mdに長文で汎用的な指示を書いてコードを生成していました。しかし、全てのプロンプトを網羅するには限界があり、より効率的な活用方法を模索していました。そんな中で出会ったのが、このカスタムスラッシュコマンド機能です。

この機能は、日々のGit操作やコーディング作業の自動化を後押ししてくれます。本記事では、私が実際にどのようなカスタムスラッシュコマンドを作成し、どのように開発業務に役立てているのかを具体的な事例と共にご紹介します。

Claude Codeのカスタムスラッシュコマンドとは
実際に作成したカスタムスラッシュコマンド
まとめ

Claude Codeのカスタムスラッシュコマンドとは

Claude Codeでは、.claude/commands/ディレクトリにMarkdownファイルを配置することで、個人またはチーム独自のコマンドを作成できます。例えば/create-branchのようなコマンドを実行すると、事前に定義したルールに従ってClaude Codeが作業を進めてくれます。

docs.anthropic.com

実際に作成したカスタムスラッシュコマンド

まずはGitのコマンド実行です。Gitの操作は同じ内容をCLAUDE.mdにも書いていて、コードを書いてPR作成までの流れを一貫して依頼することもあります。ただ、コーディングとGit操作の工程を分けて、その間に人がチェックした方が手戻りが少ないため、敢えてカスタムスラッシュコマンドとして用意しています。

ブランチ命名やメッセージの作成などは、次のように自動化しています。

ブランチを作成

.claude/commands/git-create-branch.md

## branchを作成

- ブランチ名は [Conventional Branch](https://conventional-branch.github.io/) に従う
- feature/[FeatureName]-[実装した機能名]

例: feature/admin-user-role-edit-invite-form

毎回悩みがちなブランチ名の命名。Conventional Branchに従っていても、命名するタイミングで手が止まってしまうこともありますよね。このコマンドのおかげでブランチ名を考える手間がなくなり、開発がスムーズになりました。

次の画像は、コマンドを実行した時の結果です。

branchを作成

commitメッセージを作成

.claude/commands/create-commit.md

# commitメッセージを作成

## 実行手順
1. Read @~/.claude/commands/guideline-read-code.md
2. 違反があれば作業を中断
4. `git status`でファイルを確認
5. [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)に従ってコミットを実行

## 形式の指定
- type(scope): subject の形式に従う
- タイトルは50文字以内、本文は72文字程度で改行
- 動詞は原形を使用（add, fix, updateなど）
- scope は原則記述するが、適切なものがない場合は省略可
- コミットメッセージは小文字で始める

## 実装とテストが含まれる場合の優先ルール
- 実装とテストコードが含まれている場合、typeはtestよりもfeat/fixを優先する

このコマンドの特徴は、コミット前に必ずコーディングガイドラインをチェックすることです。手順1のRead @~/.claude/commands/guideline-read-code.mdの部分で読み込ませてます。

例えば、Reactのテストコードでhooksの関数を作成した場合、そのテストとしてコールバック関数がパラメータ付きで実行されることなどを確認しますが、実行回数やエラー時のコールバック関数が実行されていないことを必ずセットで検証します。このような内容をガイドラインとして盛り込んでいます。

機械的にできるレビューは、Commit前にClaude Codeが事前チェックすることで、レビューの負荷を下げます。

なお、弊社のテストコードの考え方については Findyの爆速開発を支える「システムを守るテストコード」の実例3選 - Findy Tech Blog で紹介しています。

Pull Requestを作成

.claude/commands/git-create-pr.md

# PRを作成

- Read @.github/PULL_REQUEST_TEMPLATE.md に従うこと
- Draftで作成すること
- push時は`git push -u origin <branch_name>` のように `--set-upstream` を指定すること
- コマンドの例: `gh pr create --draft --title "title" --body "body"`

PRのテンプレートに詳細な情報が記載されているため、ファイルを参照するだけのシンプルな構成です。エディターでもセルフレビューをしますが、GitHubのdiffの方が見やすいため、PRは必ずDraftの状態で作成してセルフレビューを実施するフローを標準化しています。

また、PULL_REQUEST_TEMPLATE.mdには「動作確認」の項目を用意しています。これはブラウザ上で目視で動作確認する目的で、Claude Codeに内容を列挙して貰っています。

一部抜粋すると次のイメージです。

## 動作確認
- [ ] レスポンシブ対応が正しく動作すること（スマートフォン、タブレット、デスクトップ）
- [ ] Xのシェアボタンが正しく表示されること
- [ ] 背景色がブレークポイントに応じて適切に変更されること

この対応により、特にフロントエンドの実装時はレビュー前にブラウザで動作確認をする時のチェック観点として、PRのレビュアーにも共有しています。

ブランチ, commit, PRの全てを一度に作成

.claude/commands/git-create-branch-commit-pr.md

# branch & commit & pr を作成

## 実行手順
1. Read @~/.claude/commands/create-branch.md を実行
2. Read @~/.claude/commands/create-commit.md を実行
3. Read @~/.claude/commands/create-pr.md を実行

ブランチ作成からPR作成までの一連の作業は、開発サイクルの中で何度も繰り返されます。この定型的なプロセスを自動化するコマンドを作成しています。

開発プロセスの中で事前にタスクを分解し、その粒度に沿ってPRを作成しています。そのため、PRの粒度が小さく、1つのPRに対してコミットは1件が多いです。これにより、ブランチ作成からPR作成までの自動化が容易に実現できています。

タスク分解の詳細は Findyの爆速開発を支えるタスク分解 - Findy Tech Blog で紹介しています。

頻出するコードを自動生成

カスタムスラッシュコマンドは、Git操作だけでなく、具体的なコーディング作業の自動化にも威力を発揮します。私の経験則ではIssueに作成したタスクリストに基づき、小さな単位で具体的なコードを指示すると期待した結果が得られやすいと感じます。

そのため、定型化できる実装はカスタムスラッシュコマンドで対応してもらいます。例えば、フロントエンドの実装では、次のよく使うコードはカスタムスラッシュコマンドで対応しています。

保存ボタンの連打防止の実装
テキスト入力の必須バリデーションの実装
フォーム入力中の離脱防止の実装

.claude/commands/[Repository name]-coding-is-saving.md

## 保存ボタンの連打防止を実装

作業対象のフィーチャー: $ARGUMENTS

### 参考情報
- PRの確認にghコマンドを使うこと
- https://github.com/Findy/[リポジトリ名]/pull/111

### 実装コードの例

<Button
  priority="primary"
  size="large"
  disabled={isSaving}
  type="submit"
>
  保存
</Button>

### テストコードの例

describe('isSaving', () => {
  it('should disable save button when isSaving is true', () => {
    // Arrange
    setup({
      isSaving: true,
    });

    // Act & Assert
    expect(screen.getByRole('button', { name: '保存する' })).toBeDisabled();
  });

  it('should enable save button when isSaving is false', () => {
    // Arrange
    setup({
      isSaving: false,
    });

    // Act & Assert
    expect(screen.getByRole('button', { name: '保存する' })).toBeEnabled();
  });
});