正直に言うと、私は同じ指示文を7回入力してから、ようやく無駄に気づきました。
毎回「差分を見て、バグを優先して、軽微な表記ゆれは後で、Windows前提で」と書く。夜中のコーヒーが2杯目に入ったころ、これは人間がやる仕事ではないと思いました。
カスタムスラッシュコマンドを作ったら、47行の指示が1行になりました。便利すぎて少し悔しかったです。
なぜコマンド化したのか
Claude Codeは、依頼の書き方で結果が大きく変わります。
「レビューして」と頼むと、見た目の改善や好みの話まで混ざります。ところが「実行時エラー、例外処理、シークレット混入、Windows差分を優先」と書くと、急に仕事の顔になります。
問題は、その良い指示文が長いことです。
1日に3回レビューするなら、同じ前置きを3回書きます。5日続ければ15回です。私はそこで、指示文そのものを部品化すればいいと気づきました。
最初に作ったコマンド
最初は欲張らず、Pythonレビュー専用にしました。
# Python差分レビュー
現在の変更差分を確認し、次の観点だけを優先してください。
- 実行時エラーにつながるバグ
- 例外処理不足
- APIキーやパスワードの直書き
- Windows PowerShellで動かない可能性
- テストで確認すべき箇所
軽微な表記ゆれ、好みのリファクタ、命名だけの指摘は後回しにしてください。
結論は重要度の高い順に短く書いてください。
これを review-python.md のような名前で保存して、Claude Codeから呼び出します。
/review-python
たったこれだけです。初回の感想は「もっと早くやれ」でした。
失敗したコマンドは長すぎた
ただし、最初からうまくいったわけではありません。
私は勢いで、レビュー、修正、テスト、コミットメッセージ、ブログ化、反省点の整理まで1つのコマンドに入れました。合計83行です。
結果、Claude Codeの返答は立派でした。でも長い。長すぎる。肝心のバグ指摘が、丁寧な説明の森に埋もれました。
ここで学んだのは、スラッシュコマンドは万能リモコンではなく、単機能ボタンのほうが強いということです。
私の手元に残った5つ
今のところ、残しているのはこの5つです。
/review-python
/read-only-scan
/write-readme
/summarize-log
/draft-commit
特に使うのは /read-only-scan です。
# 読むだけ調査
リポジトリを確認してください。
この時点ではファイルを変更しないでください。
出力は次の3つだけにしてください。
1. 主要ファイルの役割
2. 実行方法
3. 変更前に確認すべき不明点
推測で仕様を補完しないでください。
この「変更しないでください」が地味に効きます。最初の30分は、AIに手を動かしてもらうより、状況を整理してもらうほうが失敗が少ないです。
コマンド一覧を忘れる問題
ここで、かなり人間くさい問題が起きました。
作ったコマンドを忘れます。
3日後には /summarize-log という名前だったか、/log-summary だったか分からなくなりました。猫がキーボードに乗ったせいにしたいところですが、普通に私の命名が雑でした。
対策として、リポジトリのREADMEに一覧を置きました。
## Claude Code commands
| command | use |
|---|---|
| /read-only-scan | 変更前の構成確認 |
| /review-python | Python差分レビュー |
| /write-readme | README下書き |
| /summarize-log | ログ要約 |
| /draft-commit | コミット文案 |
これだけで使用率が上がりました。道具は、見える場所に置かないと使いません。
コピペで使える短いレビューコマンド
私が一番使っている短縮版も置いておきます。
# 10分レビュー
差分を確認し、10分で判断すべき重大リスクだけを指摘してください。
見る観点:
- すぐ落ちるバグ
- データを壊す可能性
- 認証情報の混入
- 実行環境のズレ
出力形式:
- 重大: 必ず直す
- 注意: できれば直す
- 確認: 人間に聞く
ハマりポイント: きれいな改善案より、今止めるべき事故を優先してください。
レビューの目的を「品質向上」ではなく「事故を止める」に絞ると、返答がかなり鋭くなります。
数字で見る効果
導入前は、レビュー依頼を書くのに毎回2分から4分かかっていました。1日5回なら最大20分です。
コマンド化後は1回5秒くらいです。もちろん返答を読む時間は変わりません。でも、始めるまでの心理的な重さがかなり減りました。
特に夜中は効きます。疲れていると、指示文が雑になります。雑な指示は、雑な結果を呼びます。コマンド化は、疲れた自分を少しだけ救ってくれる仕組みでした。
作る順番を間違えない
コマンドは、思いついた順に増やすと散らかります。
私が一度やった失敗は、初日に8個作ったことです。名前も似ていて、review、review-short、quick-review の3つが並びました。どれを使うべきか迷う時点で、もう道具として負けています。
今なら、最初の1週間は1つだけで十分だと思います。毎日使ったら残す。3日使わなければ消す。これくらい厳しくしないと、コマンド一覧が引き出しの奥になります。
おすすめは、まずレビュー系です。理由は単純で、失敗した時のダメージが小さいからです。コードを直接変更させるコマンドより、差分を読むコマンドのほうが安全に価値を感じられます。
1つのコマンドが30回使われたら、そこで初めて2つ目を作る。このくらい遅い増やし方が、長く残ります。
コマンド名も、かっこよさより思い出しやすさを優先しました。
/audit より /review-python、/brief より /summarize-log のほうが、疲れている夜中でも間違えません。私はここで2回、存在しないコマンド名を打って虚無の時間を過ごしました。
道具は短ければよいわけではありません。3秒で意味が分かる名前のほうが、結局は速いです。
まとめ
カスタムスラッシュコマンドは、派手な機能ではありません。
でも、AI活用で一番崩れやすい「毎回ちゃんと指示する」を固定化できます。私のように、地方の部屋でコーヒーを飲みながら夜中にコードを見る人間には、この地味さがありがたいです。
Claude Codeを使い続けるなら、最初に作るべきは高度な自動化ではなく、自分の判断基準を保存した1行コマンドです。
コメント