最初に何も決めずに Claude Code を走らせると、だいたい雑に広がる。コンテキストは無駄に食うし、差分はでかくなるし、あとで「それじゃない」を言い直す羽目になる。あれは地味にだるい。
プロジェクトを開いたら、まずやるべき設定は3つだけだ。
「作業範囲を固定する」「出力の粒度を揃える」「触ってほしくないものを先に塞ぐ」。この3つを最初に入れておくと、Claude Code が勝手に遠回りしにくくなる。非エンジニアでも同じで、たとえば書類整理やフォルダ整備を頼むときほど効く。何を見て、何を見ないかが曖昧だと、ツールはすぐ迷子になる。
CLAUDE.md を置いて、そのプロジェクトのルールを固定するClaude Code は、プロジェクト内の指示を置いておくとそれを読みやすい。ここでやるべきなのは、毎回口頭で説明していた前提を CLAUDE.md に逃がすことだ。
コードベースなら「どのディレクトリを主に触るか」「テストの走らせ方」「命名の癖」。文書作成なら「書式」「表記ゆれの方針」「触ってはいけない原本」。この手の話は、毎回チャットで打つには細かすぎるし、打ち忘れやすい。
たとえば、こんな感じで置く。
# CLAUDE.md
## 作業方針
- 変更は最小限にする
- 既存の書き方に合わせる
- 迷ったら先に確認する
## 触ってよい範囲
- src/
- docs/
## 触らないもの
- secrets/
- .env
- generated/ 配下の自動生成ファイル
## 依頼の進め方
- まず対象ファイルを確認する
- 変更案を短く示す
- 大きい変更は一気に広げない
これだけでも効く。筆者は以前、プロジェクトの背景説明を毎回その場で書いていて、同じ注意を3回も4回も繰り返して疲れた。しかも途中で一つ抜ける。結果、Claude Code が余計なファイルまで読み、修正のつもりが説明の追加で終わる。あれは完全に無駄だ。
CLAUDE.md は「長文のお願い」を保存する場所じゃない。短いルールを積む場所だ。長く書きすぎると読むコストが上がるので、重要なことだけに絞るのがいい。
次にやるべきなのは、Claude Code に何をどう返してほしいかを先に決めることだ。ここを曖昧にすると、説明だけ立派で、実際には広く浅く触る。差分が大きくなって、あとで人間が直す時間が増える。かなりありがちな失敗だ。
たとえば最初の依頼で、こう言っておく。
このプロジェクトでは、最初の返答は次の順でお願いしたい。
1. いま見えている問題点を3つまで挙げる
2. 変更候補を小さく切って提案する
3. いきなり大きく書き換えず、先に確認を取る
実装に入る前に、対象ファイルと理由を短く説明してほしい。
これで十分だ。要するに、「先に全部やれ」ではなく「まず見立てを出せ」にしておく。
Claude Code は賢いが、曖昧な要求には普通に広く返す。とくにリファクタリングや文書整備では、要望がふわっとしていると、見た目は整っても中身の意図がずれる。筆者は一度、「重複を減らして」とだけ頼んで、似た文書を広範囲に統合されかけたことがある。そこまでやる話じゃなかった。あの手戻りは痛い。
非エンジニアの用途でも同じだ。たとえば案件フォルダの整理なら、「まず重複候補の一覧だけ出す」「削除はしない」「原本らしきものは触らない」と先に縛る。これを言わないと、整理の勢いで大事なものまで動かしかねない。ツールは便利だが、勢い任せには弱い。
三つ目は地味だが重要だ。作業に不要なフォルダやファイルを、最初から見せないようにしておくことだ。
Claude Code に全部見せる必要はない。むしろ見せないほうがいいものがある。巨大な node_modules/、ビルド成果物、キャッシュ、秘密情報、生成済みファイル。こういうものはコンテキストを浪費するだけで、だいたい役に立たない。
Claude Code 側で使える設定は環境や置き方で少し変わるので、細部は公式ドキュメントで確認したほうがいいが、考え方は単純だ。対象外を明示すること。
プロジェクト内のルールとして書いてもいいし、CLI のオプションやツール側の除外設定があるならそれを使ってもいい。大事なのは「読み込ませない」ことだ。
たとえば、こういう依頼の前置きが効く。
この作業では、以下は触らないでください。
- .env
- secrets/
- build/ や dist/ の生成物
- 画像や添付の原本
- 依存関係フォルダ
必要なら対象外にする理由を先に確認してください。
ここを雑にすると、結局「見なくていいもの」を見にいく。そうなると遅いし、変更範囲の見通しも悪い。
筆者はディスク整理の作業で、キャッシュと成果物をまとめて扱わせようとして、逆に「消していいもの」と「残すもの」の境目を説明し直すはめになったことがある。整理は、広く触るほど難しくなる。最初に境界線を引いておくほうが、ずっと楽だ。
流れにすると単純だ。
最初に CLAUDE.md でルールを置く。次に、最初の返答の形を決める。最後に、触らないものを明示する。これだけで、初手の暴走はかなり減る。
実際の依頼は、たとえばこう組める。
このプロジェクトを見て、まずは次をやってください。
1. CLAUDE.md の方針に従って全体を把握する
2. 変更候補を小さく区切って提示する
3. 生成物や秘密情報は触らない
4. 実装前に、対象ファイルと理由を短く説明する
いきなり広範囲に書き換えず、最小の一歩から進めてください。
これで十分実務になる。最初の一発で完璧を狙うより、迷わない土台を先に作るほうが早い。Claude Code は、こういう地ならしがうまいほど働きやすい。
少し進めるなら、次に考えるべきは「どこまで自動でやらせるか」だ。テストまで任せるのか、差分だけ出させるのか、文書なら校正までか。それを決めると、さらに手戻りが減る。逆にそこを決めずに突っ込むと、だいたい最後に人間がまとめて尻ぬぐいする。あれは本当に損だ。