Claude Code に何でも見せると、だいたい雑になる。人間でもそうだが、道具も広すぎる作業範囲を渡すと、余計なファイルまで見に行って、指示の解像度が落ちる。
だから先に作業フォルダを決める。対象フォルダ、作業領域、作業範囲を絞る。これだけで、読み違いも、関係ない差分も、やたら長い往復も減る。
筆者は最初、リポジトリのルートをそのまま渡して「この周辺を整えて」と投げたことがある。結果は見た目以上にだるかった。README、設定ファイル、試作メモ、昔の検証コードまで混ざった場所を見せたせいで、Claude Code が「どれを本当に触るべきか」を拾うのに余計な時間を食い、修正も散った。
逆に、最初から一つのフォルダを決めておくと話が早い。触っていい場所がはっきりするので、提案も差分も小さくなる。これはエンジニア作業でも、書類整理でも、原稿整備でも同じだ。
やることは単純だ。Claude Code を起動する前に、先に作業フォルダへ移動してから始める。
cd ~/Documents/案件A
claude
あるいは、最初の依頼文で対象をきっちり言う。
このフォルダの中だけを対象にしてください。
外のファイルは触らないでください。
案件A/契約書フォルダ内の重複ファイルを見つけて、削除候補だけ挙げてください。
CLI での使い方が許すなら、起動時点でそのディレクトリを作業場所にするのが基本だ。こうしておくと、Claude Code はその配下を前提に動く。あちこちのフォルダをまたがせるより、まずは一つの箱に閉じ込めたほうが安全で速い。
非エンジニアの用途でも、この考え方はかなり効く。たとえば、年度ごとの請求書を整理したいなら、いきなり「パソコン全体を見て」ではなく、請求書/2025 だけを見せる。不要キャッシュを消したいなら、ダウンロードフォルダや写真フォルダの一部だけを対象にする。弁護士や会計担当みたいに、案件単位・顧客単位でフォルダが分かれている仕事なら、まさに相性がいい。作業領域を狭めるほど、間違って別案件に手を突っ込む事故が減る。
ここでやりがちなのが、「あとで必要なものは見ればいい」と雑に広げることだ。これをやると、Claude Code は関係の薄いファイルまで拾って、判断のノイズが増える。しかも、文脈を食う。
コンテキストが無限ではない以上、広いフォルダを見せるほど本命の情報が埋もれる。人間が長い会議で要点を忘れるのと同じだ。だから、まず狭く、足りなければ広げる。順番を逆にしない。
まずは ./drafts の中だけを見て、文章の重複と古い下書き候補を整理してください。
外部フォルダには触れないでください。
必要なら最後に「追加で確認したい場所」だけ教えてください。
この頼み方のいいところは、Claude Code の動きが読みやすいことだ。対象が小さいので、どこを見て何を変えたかを追いやすい。差分も小さくなる。修正のやり直しが起きても被害が限定される。
筆者は、ここを甘く見て一度痛い目を見た。フォルダを絞らずに文書の体裁を整えさせたら、似た名前の古い原稿まで候補に上がり、どれが最新版かの確認で手戻りが発生した。狭い領域で始めていれば、そもそもその確認は要らなかった。
注意したいのは、「フォルダを絞る」と「必要な情報を隠す」は別物だという点だ。作業対象を限定するのはいいが、参照すべき設定ファイルやテンプレートまで切り離してしまうと、今度は精度が落ちる。
要するに、触ってほしい場所は狭く、読ませたい基準情報は明示する、が正解だ。
作業対象は ./project/docs だけです。
ただし、書式の基準は ./project/style-guide.md を参照してください。
変更は docs 配下に限定し、それ以外は触らないでください。
この切り分けができると、Claude Code はかなり扱いやすくなる。フォルダを先に決めるだけで、依頼が短くなる、差分が小さくなる、見直しが楽になる。地味だが効き目は大きい。
次にやるべきなのは、作業フォルダの中でさらに役割を分けることだ。たとえば「入力用」「出力用」「保管用」を分ける、あるいは案件ごとに空の作業箱を作ってから始める。こうしておくと、Claude Code に任せる範囲がさらに明快になる。