ClaudePR

Claude Codeスラッシュコマンドの命名規約｜チームで統一するための設計パターン

カスタムスラッシュコマンドを作れるようになったのはいいものの、チームメンバーが自由に作り始めると「似た名前のコマンドが乱立」「機能がわからないコマンドが増殖」という問題が起きます。
命名規約とテンプレートを最初に整備しておけば、コマンドが増えても見通しのよい状態を維持できます。
本記事では、プレフィックスルール、標準テンプレート、コマンドカタログの作成方法まで、チームでスラッシュコマンドを標準化する具体的な手順を解説します。

目次

前提知識

Claude Codeの対話セッションでBuilt-inコマンドが使えること、.claude/commands/ にマークダウンファイルを配置してカスタムスラッシュコマンドを作成できることを前提とします。Skill由来コマンドの基本（ファイル名=コマンド名、$ARGUMENTS による引数）を理解していればスムーズに読み進められます。

前提知識について詳しく知りたい人は、以下の記事を参考にしてください。

なぜ命名規約が必要か

Skill由来コマンドは、ファイル名がそのままコマンド名になります。ルールなしにコマンドを追加し続けると、以下の問題が発生します。

  • 発見性の低下: どんなコマンドがあるか見つけられない
  • 名前の衝突: 似た名前のコマンドが複数存在し混乱する
  • 意図の不明確さ: コマンド名から機能が推測できない
  • 保守性の低下: 誰が何のために作ったか不明なコマンドが蓄積する

命名規約の4つの設計原則

1. プレフィックスによる分類

コマンド名の先頭に機能カテゴリを示すプレフィックスを付けます。/ 入力時の候補リストで自動的にグループ化され、発見性が大幅に向上します。

/check-xxx    → チェック・検証系
/gen-xxx      → 生成系
/ops-xxx      → 運用操作系
/report-xxx   → レポート出力系
/fix-xxx      → 修正・修復系

2. ケバブケース（kebab-case）の統一

ファイル名は小文字＋ハイフン区切りで統一します。

良い例: project-setup, daily-check, code-quality
悪い例: projectSetup, daily_check, CodeQuality

3. 動詞＋対象の構造

「何をするか（動詞）＋何に対して（対象）」でコマンド名を構成します。

良い例: check-code, gen-test, fix-lint, report-coverage
悪い例: code, testing, linter, coverage-report

4. 簡潔さと明確さのバランス

2〜4語で、短すぎず長すぎない名前を目指します。

良い例: check-deps (明確で入力しやすい)
悪い例: c (意味不明) / check-all-dependency-versions-and-report (長すぎ)

ハンズオン：命名規約を実装する

既存コマンドをリファクタリングする

前回作成したコマンドを命名規約に沿ってリネームします。

旧名新名理由
project-setup.mdops-project-setup.md運用操作系プレフィックス追加
daily-check.mdreport-daily.mdレポート出力系として再分類
check-file.mdcheck-file.md既に規約準拠（変更不要）
cd ~/project-ops-commands/.claude/commands
mv project-setup.md ops-project-setup.md
mv daily-check.md report-daily.md

注意: リネーム後は旧ファイルが確実に削除されていることを確認してください。残っていると二重登録になります。

コマンドファイルの標準テンプレートを用意する

新しいコマンドを作成する際のテンプレートです。先頭にHTMLコメントでメタ情報を記載し、本文は目的・実行内容・出力形式・エラー時対応の構成にします。

<!--
command: コマンド名をここに記入
version: 1.0.0
author: 作成者名
description: コマンドの1行説明
arguments: $ARGUMENTS の説明（不要なら「なし」）
created: 作成日
updated: 最終更新日
-->

# コマンド名

## 目的
このコマンドの目的を1〜2文で記述。

## 実行内容

以下の手順を実行してください:

1. **手順1のタイトル**
   - 具体的な指示

2. **手順2のタイトル**
   - 具体的な指示

## 出力形式

結果は以下の形式で出力してください:

=== コマンド名 結果 ===
日時: (実行日時)

[項目1]
- 結果

=== 完了 ===

## エラー時の対応

エラーが発生した場合は、エラー内容・推定原因・推奨対処法を報告してください。

このテンプレートを .claude/commands/_template.md として保存しておくと、新規コマンド作成時にコピーするだけで使えます。

補足: _template.md を .claude/commands/ に配置すると、/_template としてコマンド候補一覧に表示されます。実行しても実害はありませんが、気になる場合はプロジェクトルート直下など別の場所に置いてください。

コマンドカタログを作成する

チーム全員がどのコマンドを使えるかすぐ把握できるよう、カタログを作成します。

# プロジェクト運用コマンドセット - カタログ

## チェック・検証系 (check-)
| コマンド | 説明 | 引数 |
|---------|------|------|
| /check-file | 指定ファイルの品質チェック | ファイルパス |

## 運用操作系 (ops-)
| コマンド | 説明 | 引数 |
|---------|------|------|
| /ops-project-setup | プロジェクト初期セットアップ | なし |

## レポート出力系 (report-)
| コマンド | 説明 | 引数 |
|---------|------|------|
| /report-daily | 日次開発チェックレポート | なし |

## コマンド追加手順
1. _template.md をコピーする
2. 命名規約に従ってファイル名を決める
3. テンプレートに沿ってコマンド内容を記述する
4. 動作テスト → カタログ追記 → Gitコミット

カタログを作成するスラッシュコマンドを作成しておき定期的に実行することで、カタログへの記載漏れを防ぐことができます。

CLAUDE.mdにも命名規約サマリーを記録する

/memory を使って、CLAUDE.mdにルールを追記しておきます。

## Slashコマンド命名規約
- ケバブケース（kebab-case）で記述する
- プレフィックスで分類: check-, gen-, ops-, report-, fix-
- 「動詞-対象」の構造にする
- 詳細は .claude/commands/CONVENTIONS.md を参照
- 新規コマンドは .claude/commands/_template.md をベースに作成する

まとめ

  • 命名規約は「ケバブケース」「プレフィックス分類」「動詞＋対象」「2〜4語」の4原則で設計する
  • プレフィックス（check-, gen-, ops-, report-, fix-）で機能カテゴリを一目で判別できる
  • 標準テンプレートにメタ情報・目的・実行内容・出力形式・エラー時対応を含める
  • コマンドカタログにより、チーム全体でコマンドの発見と利用がスムーズになる
  • リネーム時は旧ファイルの削除とドキュメント参照の更新を忘れずに

次に試してみよう

自分のプロジェクトにある既存コマンド（あれば）を命名規約に沿って見直してみましょう。新規に作る場合は、テンプレートをコピーして1つコマンドを作成し、カタログに追記するところまで一気通貫で試してみてください。

さらに深く学びたい方へ
Claude Codeの Skills・MCP・Agent・Hooks・Plugin を体系的に学べる実践ガイドを Zenn Book で公開中です。
全5章・41記事のハンズオン教材を、章ごとに順次公開しています。現在公開中の章は無料で読めます。
Claude Code 実践ガイド｜Skills・MCP・Agent・Hooks・Plugin（Zenn Book）

アーカイブ