最初にやるべきことを飛ばして、いきなりClaude Codeに「これ直して」と投げる人は多い。で、あとからコンテキストが足りない、差分が広がりすぎる、同じ説明を何度も繰り返す、となって手戻りする。もったいない。
Claude Codeは、ただ起動して雑に命令する道具ではない。最初にプロジェクトの輪郭を整えると、以後のやり取りがかなり軽くなる。ここでやるべき設定は、細かい小技ではない。CLAUDE.md を置くこと、作業対象をきちんと閉じること、そして危ない自動実行を避けることだ。この3つを先に固めるだけで、迷走がかなり減る。
CLAUDE.md を置いて、プロジェクトの約束事を先に渡すClaude Codeは、毎回ゼロから空気を読むわけではない。プロジェクトのルール、よく使うコマンド、触ってはいけない場所を先に書いておくほうが強い。これが CLAUDE.md だ。リポジトリのルートに置くのが基本になる。
たとえば開発案件なら、こんな内容で十分だ。
# CLAUDE.md
このプロジェクトでは次のルールに従う。
- 既存のコードスタイルに合わせる
- 変更は必要最小限にする
- 依存関係の追加は事前確認する
- テストは `npm test` で実行する
- 重要な設定ファイルは勝手に書き換えない
よく使う作業コマンド:
- 開発: `npm run dev`
- テスト: `npm test`
- ビルド: `npm run build`
非エンジニア寄りの使い方でも同じだ。たとえば書類整理のプロジェクトなら、こう書けばいい。
# CLAUDE.md
このフォルダでは次の方針で作業する。
- 元ファイルは残す
- 変更後のファイル名は必ず確認する
- 送付版、下書き、確定版を混同しない
- 同じ内容の重複ファイルは削除候補として提案するだけにする
- 個人情報が入るファイルは勝手に外部共有しない
これをやると何が変わるか。毎回「このプロジェクトではこうして」と説明しなくて済む。しかも、Claude Codeの返答が急に安定する。筆者は最初、毎回口頭で注意していたが、途中から説明漏れが出て、提案の粒度もぶれた。CLAUDE.md に落としてから、ようやく話が通るようになった。
大事なのは、きれいな長文にしないことだ。守るべきことだけを書けばいい。長い社内規約を丸ごと貼り込むと、読む側も使う側もだるい。Claude Codeに渡す情報は、短くて具体的なほうが効く。
次にやるべきは、プロジェクトのルートをちゃんと見極めることだ。Claude Codeは、開いている作業ディレクトリを前提に動く。ここが雑だと、関係ないファイルまで見にいく。結果、コンテキストが無駄に広がる。
やりがちな失敗は、親フォルダを丸ごと開くことだ。たとえば、次のような構成で、workspace の親を開いてしまうケースがある。
workspace/
project-a/
project-b/
archive/
downloads/
これだと、project-a だけ直したいのに、archive や downloads まで視界に入る。必要なファイルを探すだけで会話が重くなる。ファイル整理や文書作成で使うときも同じだ。案件フォルダ、年度フォルダ、納品フォルダをまとめた親を開くより、今触る単位まで掘ったほうがいい。
実務では、こういう感覚で切ると扱いやすい。
Claude Codeに渡す指示も、最初から範囲を明示するといい。
このフォルダの中だけを対象にして、重複しているファイル名の候補を洗ってほしい。
元ファイルは削除せず、削除候補だけ出してほしい。
ここで雑に「このパソコン全部を見て」とやると、話が散る。Claude Codeは便利だが、無限に広い作業場を与えると、当然だが重くなる。最初に対象範囲を狭くするのは、ケチではなく節約だ。
最後にやるべきなのは、変更をどこまで自動で進めるかを決めることだ。Claude Codeはファイル変更やコマンド実行に関わる場面がある。ここを曖昧にしたまま使うと、意図しない修正が混ざったときに気づきにくい。
少なくとも、最初のうちは「勝手に大きく変えない」方針にしておくほうが安全だ。CLAUDE.md にも書いておくといい。
- 変更前に方針を短く確認する
- 大きな修正は一括で進めず、段階的に出す
- 破壊的な操作は必ず確認を取る
Claude Codeへの依頼も、最初はこう切ると事故が減る。
まず変更方針だけ出してほしい。
ファイルはまだ編集しないで、直す候補と理由を箇条書きで示して。
削除してよい候補ファイルを挙げて。
実行はせず、理由だけ説明して。
筆者は一度、確認を省いて差分を広げすぎたことがある。ちょっとした文言修正のつもりが、関連ファイルまで連鎖して、レビューに余計な時間を食った。Claude Codeが悪いのではない。最初の前提が雑だっただけだ。小さく始めて、結果を見てから進めるほうが、結局は速い。
ここで「自動化を止めるのは面倒だ」と感じるかもしれない。でも、初動で事故るほうがもっと面倒だ。特に文書整理やディスク削減の用途では、削除対象の見極めが命になる。元ファイルを残す、候補だけ出す、最後は人間が決める。この線引きは先に決めておくべきだ。
この3つを最初に済ませると、Claude Codeはだいぶ扱いやすくなる。CLAUDE.md でルールを渡し、対象フォルダを絞り、自動実行の境界を決める。それだけで、毎回の説明が短くなり、差分も小さく保ちやすい。
次に効くのは、依頼文の書き方だ。目的、対象、やってほしいこと、やってほしくないことを1回で言い切る。ここが整うと、Claude Codeはかなり素直に動く。