私はClaude Codeに大きなタスクを丸投げするのではなく、ペアプロのパートナーとして使っています。
本格的に使い始めてまだ日が浅いですが、その中で見つけた個人的ベストプラクティスをまとめました。
CLAUDE.mdはClaude Codeに書かせる
自分でざっくりとした方針だけ書いて、コードベースの構造やガイドはClaude Codeに書かせましょう。
内容は「どこに何があるか」程度のプロジェクトガイドに留めます。詳細を書きすぎると更新を忘れたときに誤った情報を与えてしまいます。Claude Codeは必要な情報を自分で探せるので、ガイドさえあれば十分です。
DRYを意識する
同じ情報が複数箇所にあると、更新漏れで「どれが正しいのか」が分からなくなります。そういった情報が増えるほど、Claude Codeのパフォーマンスも落ちていきます。
そもそもClaude Codeは情報を探して辿ることを苦としません。人間向けの読みやすさのためにDRYを犠牲にするようなアプローチの必要性も下がっています。CLAUDE.mdにルールとして書いておくと良いでしょう。
デフォルト権限を設定する
未設定だとClaude Codeはコマンド実行のたびに確認を求めてきます。~/.claude/settings.jsonで危険性の低いコマンドにはあらかじめ権限を与えておきましょう。
参考: 私のsettings.json
タスクは小さく
「このアプリ全体をリファクタリングして」より「この関数のエラーハンドリングを改善して」の方がうまくいきます。更に細かく「こう改善して」と伝えると、より期待通りの結果が得られます。
冒頭でも述べた通り、私は大きな仕事を丸投げするような使い方はしていません。
- 最終的な目標を伝えて、設計を相談する
- 「まずはこれを進めて」とステップごとに指示
- レビューし、git addしてから改善を求める
- 問題なくなったらコミットして次のステップへ
こうして小さい単位でレビューしながら進めることは、コードレビューのベストプラクティスを踏襲しています。
ヒントを与える
適度にタスクの文脈を与えることで、余計な検索を減らして、精度の向上と時間の節約ができます。
「投稿のコメントが見えない問題を修正して」というタスクがあり、自分に心当たりがある場合は「多分posts/comments/viewあたりが問題」と雑に情報を与えましょう。
TODOコメントを使う
「この場所でこういうコードを書いて欲しい」という具体的な指示をファイルに書き込んだあと、Claude Codeに「今書いたTODOを解消して」と頼むと、より簡単に特定の場所で具体的な指示を出せます。
よく使うプロンプトはコマンド化
繰り返し使うプロンプトは、コマンド化しましょう。プロジェクトに置きづらいものは~/.claude/commandsに個人用として定義します。
自己レビュー
Claude Codeが書いたコードを自身にレビューさせることもできます。自分が目を通す前にやらせることで、明らかな誤りをかなり減らせます。
コマンド化して/hard-reviewで呼び出せるようにしています。
---
description: 問題がなくなるまでレビューと修正を繰り返す
---
問題が見つからなくなるまで、以下を繰り返してください:
1. 対象を確認してレビュー
2. 問題があれば修正
3. 修正後、再度レビュー
コミットは任せる
コミットメッセージを考えるのが面倒なので、Claude Codeに書かせています。
ただし手動で編集を加えたときなど、Claude Codeの記憶が現実と食い違って誤ったメッセージを書くこともあります。コミット前にdiffを確認させましょう。
コマンド化して/commitで呼び出せるようにしています。
---
description: コミットを作成
---
diffを確認して適切なコミットメッセージを書き、コミットしてください。
生成ファイルは触らせない
生成ファイルを直接編集させてはいけません。特に package-lock.json や yarn.lock などのロックファイルは要注意です。直接編集させると、バージョンの不整合や存在しないバージョンが指定される恐れがあります。
CLAUDE.mdに生成コマンドと生成ディレクトリを明記し、「直接編集せず、コマンドを通して更新する」と書いておきましょう。
随時更新していこうと思います。
原文: https://sijiaoh.com/posts/my-claude-code-best-practices/