Claude Code に雑に「このフォルダ見ていい感じにやって」と投げると、だいたい遠回りになる。
参照範囲を絞る、つまり材料の選別を先にやるだけで、出力の精度もスピードもかなり変わる。無関係なファイルまで読ませてコンテキストを浪費するより、使う材料と使わない材料を分けて渡したほうが、Claude Code は迷いにくい。
これは開発コードだけの話ではない。案件フォルダの整理、重複ファイルの洗い出し、議事録から要点だけ抜く作業でも同じだ。最初に「見るべきもの」と「見なくていいもの」を分ける。これが一番効く。
たとえば、リポジトリの中に src/、docs/、node_modules/、dist/ があるとする。ここで全部まとめて渡すと、必要のない生成物や依存関係まで拾ってしまう。逆に、作業対象を src/ と docs/ に絞り、node_modules/ と dist/ は明示的に除外すれば、Claude Code は本筋に集中しやすい。ファイル整理でも同じで、請求書 と 契約書 だけ見てほしいのに、昔の画像やキャッシュまで混ぜると、出力がぼやける。
実際の指示は、こういう形にすると使いやすい。
この作業では次の材料だけを使ってください。
使う材料:
- src/ 配下の TypeScript ファイル
- docs/usage.md
- README.md
使わない材料:
- node_modules/
- dist/
- .git/
- 画像ファイル
- lockfile の内容は今回は参照しない
目的:
- 実装の説明文を README に追記する
- 既存の設計と矛盾しない表現にする
もっと雑務寄りなら、こういう頼み方で十分だ。
このフォルダから、重複しそうなものと不要そうなものを分けてください。
使う材料:
- 今年の請求書
- 契約書
- 納品書
使わない材料:
- 画像
- ダウンロードフォルダの一時ファイル
- 古いバックアップ
- 中身が同じ圧縮ファイル
出力は「残す」「要確認」「捨ててよい」に分けてください。
ポイントは、単に「これを見て」と言うだけで終わらせないことだ。Claude Code は与えた範囲の情報を材料にする。だから、見せたくないものを先に外すだけでも結果が変わる。ここをサボると、余計なファイルの説明に引きずられて、出力が薄まる。筆者は最初、リポジトリ丸ごと放り込んで「設計を整理して」と頼み、関係のない生成物やテストデータまで前提に入った説明を返されて、後から手直しする羽目になった。あれはだるい。最初に切っておけば済む話だった。
注意点もある。使わない材料を明示するのは、単なる「除外リスト」ではない。除外の理由が曖昧だと、後で「実はそこに重要情報があった」が起きる。たとえば docs/ を全部除外したら、運用ルールまで落ちる。画像ファイルは不要 と言っても、図版の中に表の画像が混じっているなら話は別だ。材料の選別は、無視していいものを雑に切る作業ではなく、目的に対して参照範囲を絞る作業だと考えたほうがいい。
もう一つやりがちな失敗が、逆に材料を絞りすぎることだ。必要な背景まで削ると、Claude Code は丁寧に見えても、肝心の前提を外す。たとえば文書の修正なら、本文だけ渡して「トーンを整えて」で終えると、見出しの粒度や用語の統一が崩れることがある。本文とあわせて、表記ルールや既存の目次も材料に入れたほうがいい。使う材料は少なくても、判断に必要な骨組みは残す。ここを勘違いすると、修正が局所最適で終わる。
実務では、最初の依頼文にこの一文を足すだけでかなり安定する。
以下の条件で作業してください。
- 使う材料と使わない材料を必ず分ける
- 使わない材料には触れない
- 使う材料の範囲を超える推測はしない
この「分ける」は、ファイル整理でも文章作成でも効く。非エンジニアほど効果が分かりやすい。たとえば契約書の修正で、過去のメール全文を渡すより、関係する往復だけ渡したほうがいい。議事録の要約でも、全会議の記録を全部投げるより、対象日のメモと決定事項だけで足りることが多い。材料が増えるほど賢くなる、という発想は半分だけ正しい。実際は、ノイズも一緒に増える。
要するに、Claude Code に上手く働いてほしいなら、最初に「何を材料にするか」を決めることだ。
そして同じくらい大事なのが、「何を材料にしないか」をはっきり書くことだ。
この一手間で、出力のブレと手戻りはかなり減る。雑に広く見せるより、狭く正確に渡したほうが強い。これはかなり地味だが、効き目はでかい。