毎回同じ指示をClaude Codeに打ち込んでいませんか。
「コミットメッセージは日本語で、変更理由を1行目に」「このプロジェクトのコーディング規約に沿ってレビューして」——僕はこういう指示を、毎日のように手打ちしていました。
ある日、似た指示を何度も入力している自分に気づき、カスタムスラッシュコマンドとしてまとめることにしました。この記事では、実際に作って使っている3つのコマンドと、作ってみて分かったメリット・注意点を書きます。
きっかけ：同じ指示を何十回も打っていた
Claude Codeを終日起動して使うようになってから（この話は別の記事に書きました)、指示を出す回数自体が増えました。
その中で気づいたのが、「毎回ほぼ同じ文面を打っている指示」があるということです。
- コミット前に「変更内容をレビューして、コミットメッセージ案を出して」
- 新しいコンポーネントを作るときに「このプロジェクトの命名規則とディレクトリ構成に合わせて」
- リファクタリング依頼のときに「まず変更方針を説明してから、実装して」
同じ内容をタイプするたびに、地味に時間を取られていました。数秒の手間でも、1日に何度も繰り返すと馬鹿にできません。
カスタムスラッシュコマンドとは
Claude Codeには、プロジェクトの .claude/commands/ フォルダにMarkdownファイルを置くだけで、自分専用のコマンドを作れる機能があります。
ファイル名がそのままコマンド名になり、ファイルの中身がClaude Codeへの指示になります。たとえば .claude/commands/commit.md というファイルを作れば、ターミナルで /commit と打つだけで、そのファイルに書いた指示がそのままClaude Codeに送られます。
毎回打っていた「あの指示」を一度ファイルに書いておけば、以後はコマンド1つで済む、という仕組みです。
実際に作った3つのコマンド
① /commit ——コミットメッセージ生成
.claude/commands/commit.md
現在の変更差分を確認し、以下のルールでコミットメッセージ案を提示してください。
- 1行目：変更内容を日本語で簡潔に（40文字以内）
- 2行目は空行
- 3行目以降：変更した理由や背景を箇条書きで
- 提案のみ行い、私が確認するまでコミットは実行しないこと
一番使用頻度が高いコマンドです。差分を読んでメッセージ案を出してくれるので、「何を書こうか」と考える時間がなくなりました。
② /review ——セルフレビュー
.claude/commands/review.md
直近の変更差分に対して、以下の観点でレビューしてください。
- 命名は他のファイルの規則に沿っているか
- 同じ処理が既存のコードに存在しないか
- エラーハンドリングが必要な箇所を見落としていないか
指摘は箇条書きで、重要度が高い順に並べること。
自分の目で見る前に、一度このコマンドを通すようにしています。人に見せる前のセルフチェックのような感覚です。
③ /plan ——実装前の方針確認
.claude/commands/plan.md
これから依頼する実装について、いきなりコードを書き始めず、 まず以下を先に提示してください。
- 変更が必要なファイルの一覧
- 実装方針（箇条書きで3〜5点）
- 懸念点や確認したいこと
私が「進めてください」と言ってから、実装に入ること。
いきなりコードが返ってくると、方針がずれていたときの手戻りが大きくなります。先に「進め方」だけ合意する、というワンクッションを入れるためのコマンドです。
作ってみて分かったこと
指示の「質」が安定するようになりました。 毎回手で打っていた頃は、その日の気分や忙しさで指示の粒度がバラついていました。コマンド化すると、いつ使っても同じ精度の指示が飛ぶので、返ってくる answer の質も安定します。
「面倒だから省略する」がなくなりました。 セルフレビューなど、地味だけど省きがちな工程ほど、コマンド化する価値がありました。1コマンドで済むなら、面倒くさがって飛ばす理由がなくなります。
一方で、コマンドを作りすぎても使わなくなるという点は注意が必要だと感じています。最初は5個ほど作りましたが、実際に定着したのは3個だけでした。「週に1回も使わないコマンド」は、結局手打ちしたほうが早いことに気づき、今は本当によく使うものだけに絞っています。
まとめ
同じ指示を何度も打っている自覚があるなら、カスタムスラッシュコマンドにしてみる価値はあります。作り方自体は .claude/commands/ にMarkdownファイルを置くだけなので、難しい設定は要りません。
大事なのは、コマンドの数を増やすことではなく、本当に毎回使う指示だけを厳選することだと感じています。次は、プロジェクトごとに切り替えているコマンドの管理方法についても書いてみようと思います。
