Claude Codeを毎日使っていると、こういう瞬間が必ずあります。
- 「このコミットメッセージ、いつものフォーマットで書いて」を毎回手打ちしている
- レビュー依頼のプロンプトが長くて、過去のチャットからコピペして探している
- PRの説明文を生成させる指示が人によって微妙に違い、出力がブレる
- 「テスト書いて」と言うたびに、毎回「正常系と異常系を分けて、モックは使わず…」と前提を書き直している
これ、全部同じプロンプトを毎回手で書いている無駄です。
賢いモデルを使っていても、入力が毎回ブレれば出力もブレます。そして何より、同じことを毎日タイプし続けるのは単純に時間の損失です。
これを解決するのがカスタムスラッシュコマンドです。.claude/commands/ にMarkdownファイルを1枚置くだけで、/コマンド名 という自作コマンドが生まれます。よく使うプロンプトを「コマンド化」して、ワンコマンドで呼び出せるようにする機能です。
この記事では、スラッシュコマンドを「なんとなく知っている」状態から「反復作業を実際に潰せる」状態まで持っていきます。作り方・引数・実例・運用のコツまで、すべてコピペで今日から試せます。
スラッシュコマンドの正体は「Markdownファイル1枚」
難しく考える必要はありません。カスタムスラッシュコマンドの実体は、プロンプトを書いたMarkdownファイルです。
置き場所は2つあります。
| 置き場所 | パス | スコープ | Git管理 |
|---|---|---|---|
| プロジェクト用 | .claude/commands/ |
そのリポジトリ内だけ | できる（チームで共有） |
| ユーザー用（個人） | ~/.claude/commands/ |
全プロジェクト共通 | 自分専用 |
ファイル名がそのままコマンド名になります。.claude/commands/review.md を作れば /review が、commit.md を作れば /commit が使えるようになります。
まずは最小の例を作ってみます。
mkdir -p .claude/commands
.claude/commands/commit.md:
現在のステージされた変更内容を確認し、Conventional Commits 形式で
コミットメッセージを1つ提案してください。
ルール:
- 1行目は `type(scope): 概要` 形式（72文字以内）
- type は feat / fix / docs / refactor / test / chore から選ぶ
- 本文には「何を」ではなく「なぜ」変えたかを書く
- 日本語で書く
これだけです。Claude Codeのチャットで /commit と打てば、このファイルの中身がそのままプロンプトとして実行されます。
Before（毎回手打ち）:
「ステージした変更を見て、Conventional Commits形式で
コミットメッセージ書いて。1行目は72文字以内で、本文には
なぜ変えたかを書いて、日本語で…」
（毎回この長文をタイプ or 過去ログからコピペ）
After（コマンド化）:
/commit
タイプ量が1/20以下になり、しかも毎回まったく同じ品質基準で出力されます。チームで .claude/commands/ をGitに入れておけば、全員のコミットメッセージのフォーマットが揃います。
引数を受け取る — $ARGUMENTS と $1 $2
固定プロンプトだけでも便利ですが、本領は引数を渡せるところにあります。
すべてまとめて受け取る $ARGUMENTS
コマンド名の後ろに書いた文字列は、$ARGUMENTS という変数に丸ごと入ります。
.claude/commands/explain.md:
次のコードまたは概念を、初学者にもわかるように説明してください。
専門用語には必ず一言の補足を付けること。
対象: $ARGUMENTS
使い方:
/explain useEffectのクリーンアップ関数
$ARGUMENTS の部分が「useEffectのクリーンアップ関数」に置き換わって実行されます。
位置引数 $1 $2 $3
複数の引数を別々に扱いたいときは、$1 $2 のように位置で受け取れます。
.claude/commands/rename.md:
プロジェクト全体で、シンボル名 `$1` を `$2` にリネームしてください。
手順:
1. まず `$1` の定義箇所と全参照箇所を grep で洗い出す
2. インポートパス・型定義・テストファイルも漏れなく対象にする
3. 文字列リテラル内の偶然の一致は変更しない
4. 変更したファイルの一覧を最後に報告する
使い方:
/rename getUserData fetchUserProfile
$1 が getUserData、$2 が fetchUserProfile に展開されます。引数の意味が固定されるので、「どっちが新旧だっけ」と毎回考えずに済みます。
| 変数 | 中身 | 使いどころ |
|---|---|---|
$ARGUMENTS |
引数全部を1つの文字列で | 自由テキスト1個を渡す（説明・検索語など） |
$1 $2 $3
|
スペース区切りの位置引数 | 旧名/新名、ファイル名/出力先など役割が決まっている |
コマンドを「ただのプロンプト」から「実行手順書」に進化させる
ここからが、スラッシュコマンドを本当に効かせるためのコツです。
コマンドファイルは単なる定型文の置き場ではありません。「このタスクをやるときの手順とルール」を全部書き込んだ実行手順書として設計すると、毎回の指示の質が一気に安定します。
例として、PR説明文を生成するコマンドを「雑な版」と「手順書版」で比べます。
雑な版（.claude/commands/pr.md）:
このブランチの変更からPRの説明文を書いて。
これでも動きますが、出力は毎回バラバラです。差分の見落としもあるし、フォーマットも安定しません。
手順書版:
現在のブランチと main の差分から、PR の説明文を作成してください。
## 手順
1. `git diff main...HEAD --stat` で変更ファイルの全体像を把握する
2. 主要な変更を `git diff main...HEAD` で読む
3. 下記テンプレートを埋める
## 出力テンプレート（このまま埋めて出力）
### 概要
（このPRが何を解決するか2〜3行）
### 変更内容
- （箇条書き。ファイル単位ではなく「機能/意図」単位で）
### 動作確認
- [ ] （レビュアーが確認すべき項目をチェックリストで）
### 影響範囲・注意点
（破壊的変更・マイグレーション要否があれば明記。なければ「なし」）
## ルール
- 推測で機能を書かない。差分から読み取れる事実だけを書く
- セキュリティに関わる変更（認証・権限・秘密情報）は冒頭に⚠️付きで明記
/pr と打つだけで、毎回この手順とフォーマットでPR説明文が出てきます。レビュアー視点の「動作確認チェックリスト」まで自動で付くので、PRの質そのものが底上げされます。
ポイントは3つです。
- 手順（何を読むか）を書く — Claudeに「どのコマンドで情報を集めるか」まで指示すると、見落としが減る
- 出力フォーマットを固定する — テンプレートを埋めさせると出力がブレない
- 禁止事項を書く — 「推測で書くな」のような制約が、ハルシネーションを抑える
そのまま使える実例コマンド5本
コピペして .claude/commands/ に置けば、すぐ使えるものを並べます。自分のプロジェクトに合わせて中身を調整してください。
1. /review — 差分のセルフレビュー
.claude/commands/review.md:
ステージ済み（なければ working tree）の変更をセルフレビューしてください。
観点:
- バグ・例外処理漏れ・nullチェック漏れ
- 命名と既存コードスタイルの一貫性
- テストが必要なのに無い箇所
- 秘密情報のハードコードや危険なログ出力
出力:
- 指摘ごとに「ファイル:行 / 重大度(高中低) / 内容 / 修正案」
- 重大度「高」が1件もなければ最後に「LGTM」と書く
2. /test — テスト生成の前提を固定
.claude/commands/test.md:
$ARGUMENTS のテストを作成してください。
前提（毎回これに従う）:
- 正常系・境界値・異常系を必ず分けて書く
- このプロジェクトのテストフレームワークと既存テストの書き方に合わせる
- 過剰なモックは避け、実際の入出力で検証する
- テストケース名は「何を検証するか」が日本語で読めるようにする
使い方: /test src/utils/parseDate.ts
3. /doc — 関数・モジュールのドキュメント化
.claude/commands/doc.md:
$ARGUMENTS について、ドキュメントコメント（JSDoc / docstring 等、言語に合わせる）を
追加してください。
- 引数・戻り値・投げうる例外を明記
- 使用例を1つ含める
- 実装の中身ではなく「使う側が知るべきこと」を書く
4. /refactor — 安全なリファクタの型
.claude/commands/refactor.md:
$ARGUMENTS をリファクタリングしてください。
鉄則:
- 外部から見た振る舞いは変えない（入出力・公開APIは維持）
- 1コミットで完結する小さな単位に絞る
- 変更前後で壊れうるテストを先に確認する
- リファクタの意図を3行で説明してから差分を提示する
5. /onboard — プロジェクト把握を一発で
.claude/commands/onboard.md:
このプロジェクトの全体像を把握して、次を報告してください。
1. 何をするプロジェクトか（README / package.json 等から）
2. 主要なディレクトリ構成と各役割
3. 開発を始めるためのセットアップ手順
4. テスト・ビルド・起動の各コマンド
5. 触る前に注意すべき箇所（設定ファイル・秘密情報・生成物など）
長文のファイル中身は貼らず、要点だけ箇条書きで。
新しいリポジトリを開いた直後やセッション再開時に /onboard を打つと、毎回同じ観点でプロジェクトを把握できます。
サブフォルダで名前空間を切る
コマンドが増えてくると一覧が散らかります。.claude/commands/ の下にフォルダを切ると、コマンド名に名前空間が付きます。
.claude/commands/
├── git/
│ ├── commit.md → /git:commit
│ └── pr.md → /git:pr
├── test/
│ └── unit.md → /test:unit
└── review.md → /review
git/commit.md は /git:commit として呼び出せます。種類ごとにフォルダを分けておくと、補完候補も見やすく、チームで共有したときに「どこに何があるか」が一目でわかります。
スラッシュコマンドとスキルファイルの使い分け
「再利用可能なスキルファイル」という、もう一歩進んだ仕組みもあります。両者は似ていますが、向いている用途が違います。
| スラッシュコマンド | スキルファイル | |
|---|---|---|
| 実体 |
.claude/commands/ のMarkdown |
スキルとして定義した手順書セット |
| 起動 |
/コマンド名 を手で打つ |
タスク内容に応じて自動的に参照される |
| 向いている用途 | 「今これをやれ」という単発の定型作業 | 「この種の作業はこう進める」という一連の方法論 |
| 例 |
/commit /pr /test
|
「リファクタはPlan→Implement→Verifyの3段で進める」等の作業フロー全体 |
ざっくり言うと、
- 毎回手で呼びたい定型作業 → スラッシュコマンド
- 作業の進め方そのもの（方法論）を再利用したい → スキルファイル
の使い分けです。まずはスラッシュコマンドから始めて、「同じ手順を何度もコマンドに書いている」と気づいたら、その手順をスキルファイルとして切り出す、という順番が現実的です。
運用のコツ — 作った後に効かせるための5つ
コマンドは作って終わりではありません。実際に「使われ続ける」状態にするためのコツをまとめます。
コツ1: 既に2回やった作業だけコマンド化する
最初から完璧なコマンド集を作ろうとすると挫折します。同じプロンプトを2回手で書いた瞬間が、コマンド化のサインです。「これ前も書いたな」と思ったらファイルにする。これだけで自然に必要なコマンドだけが揃います。
コツ2: コマンドは短く、責務を1つに
1つのコマンドに「テスト書いて、ドキュメントも書いて、コミットもして」と詰め込むと、毎回どれかが雑になります。/test /doc /commit と分けて、必要なものを順に打つほうが結果が安定します。
コツ3: 出力フォーマットを必ず固定する
前述の通り、テンプレートを埋めさせる形にすると出力がブレません。「箇条書きで」「この見出しで」「最後にチェックリストを」など、出力の形を明示するのが効果が大きいです。
コツ4: .claude/commands/ をGitに入れてチームで共有
プロジェクト用コマンドはリポジトリにコミットできます。チーム全員が同じ /review /pr を使えば、レビュー観点もPR形式も自動で揃います。コマンド集 = チームの作業標準のコード化です。
コツ5: 使わないコマンドは消す
増やしすぎると、自分でも何があるか把握できなくなります。1ヶ月使わなかったコマンドは消す。コマンド集は「資産」ではなく「よく使う道具箱」として最小に保つのがコツです。
まとめ
カスタムスラッシュコマンドは、「毎回同じプロンプトを書く無駄」を構造的に消すための機能です。
| やること | 効果 |
|---|---|
.claude/commands/xxx.md を置く |
/xxx で呼べる自作コマンドになる |
$ARGUMENTS $1 $2 を使う |
引数を渡して汎用化できる |
| 手順・出力フォーマット・禁止事項を書く | 毎回同じ品質で出力が安定する |
| サブフォルダで名前空間を切る | コマンドが増えても整理できる |
| Gitで共有する | チームの作業標準をコード化できる |
ポイントは、コマンドを「定型文の置き場」ではなく「実行手順書」として書くこと。手順・フォーマット・制約まで書き込んだコマンドは、賢いモデルの出力ブレを抑え、毎回安定した結果を返します。
まずは1本、いちばんよく手打ちしているプロンプト（多くの人は /commit か /review）をファイルにするところから始めてみてください。タイプ量と出力品質の両方が、その日から変わるはずです。
補足: 試すための無料リポジトリ
本記事の内容を実際のプロジェクトで試すには、土台となるCLAUDE.mdとフォルダ構成があるとスムーズです。私が使っているスターター構成を無料で公開しています。
無料スターター（GitHub）:
https://github.com/noguso245-jpg/claude-code-skills-starter
さらに踏み込んで、ワークフローやサブエージェント設計を「実行可能なスキルファイル」としてまとめたパッケージも用意しています。手元で /コマンド として呼び出せる形です。
-
スターターパック（¥1,980）: CLAUDE.mdテンプレ7種・Hooks・MCP設定
https://streamsolty.gumroad.com/l/gliwz -
ワークフローOS（¥9,800）: 79本のスキル + ワークフロー3本 + プロンプト10種
https://streamsolty.gumroad.com/l/vhcysn
まずは無料リポジトリから試して、もっと体系的に使いたくなったら検討してもらえれば十分です。記事の内容だけでも効果は出ます。
最新のTipsはXでも発信しています: @k___n___t_1125