はじめに
前回、Claude Codeを使った記事を書きました。
実際に運用してみると、かなり実用レベルで使えることがわかってきました。
- バグ調査
- 不具合修正
- コードレビュー
このあたりは、1回の指示で完結するケースも増えてきたと思います。
ただ、しばらく使っていると気づきます。
「毎回ちゃんと指示を書くの、めんどくさくない？」
Claude Codeを使っていて気づいたこと
Claude Codeを使っていて感じたのは、
アウトプットの質が「プロンプトに大きく依存する」という点です。
例えば、
-
指示がざっくりしている場合
→ それなりに意図を汲んでくれる -
指示が具体的な場合
→ かなり精度の高いアウトプットになる
つまり、
👉 Claude Codeの性能を引き出せるかは、プロンプト次第
とはいえ、
- 毎回しっかり書くのは大変
- できれば短く指示したい
この「楽をしたい」と「精度を出したい」の間で悩むことが増えてきました。
解決策：指示を“書く”のをやめる
やったことはシンプルです。
👉 「指示を毎回書く」のをやめて、コマンド化しました。
カスタムコマンドの仕組み
.claude/commands ディレクトリを作成して
その中に .md ファイルとしてコマンドを定義します。
例：調査コマンド（investigate）
あなたはシニアエンジニアです。
以下の手順で調査してください：
1. 提供された情報（コード・エラーログ・画像）を整理する
2. 問題の発生箇所を特定する
3. 原因の仮説を3つ出す
4. 各仮説の検証方法を書く
5. 最も可能性の高い原因を特定
6. 修正方針を提示
注意：
- ログや画像の内容を根拠として判断する
- 不足している情報があれば明示する
例：改修コマンド（fix）
あなたはシニアエンジニアです。
以下を実施してください：
1. バグの原因を特定
2. 修正コードを提示
3. 影響範囲を説明
4. 必要ならテスト観点も提示
制約：
- 既存仕様を壊さない
- 最小変更で対応
使い方
これを用意すると、普段のやり取りがこう変わります。
Before（従来）
このエラーの原因を調査して、
仮説を出して、
修正方針も教えてください...
After（コマンド化）
/investigate このエラーなんで出る？
(実際のエラーの情報)
👉 「指示を書く」から「コマンドを呼ぶ」に変わります。
気づいたこと
この運用をしてみて一番大きかったのはこれです。
👉 Claude Codeは“賢さ”よりも“文脈”に強く依存する
つまり、
- 適切な前提と指示を与えることで、安定して高い精度を出せる
👉 だからやるべきは
「いい指示を毎回書くこと」ではなく
「いい指示を再利用すること」
補足：ログやスクリーンショットの扱い
エラーログやスクリーンショットを渡す場合でも、
このコマンドで問題なく解釈できます。
ただし、対象箇所を明示すると精度がより安定します。
例：
/investigate
添付の画像のエラー（赤枠の部分）について
さらに一歩：コマンドを自動生成する
ここまでやると、次の問題が出てきます。
- コマンドを増やしたい
- でも作るのがめんどくさい
👉 そこでやったのがこれ
コマンド生成コマンド（metaコマンド）
あなたはプロンプトエンジニアです。
以下の指示を、再利用可能なコマンドに変換してください。
要件：
- 汎用的に使える形にする
- 手順を明確にする
- md形式で出力
使い方
/command-gen
この調査の指示をコマンド化して
（実際の指示内容）
すると、Claudeがそのまま使える .md を生成してくれます。
👉 コマンドをClaudeに作らせる運用になります。
まとめ
Claude Codeを使っていて感じたのはこれです。
- 指示を書くのはコスト
- でも指示の質は重要
- だからコマンド化する
そしてさらに一歩進むと
👉 「コマンドすら自分で書かない」
Claude Codeの使い方は色々ありますが、
個人的にはこの運用が一番しっくりきています。
もう、プロンプトは書かない。