Claude Code に大きなフォルダを丸ごと渡して、「あとはよろしく」はかなり危ない。
余計なファイルまで見に行かせると、コンテキストを食うし、意図しない場所まで修正しやすい。対象フォルダを限定する、作業範囲の制御を先にやる、巻き込み事故を防ぐ。これだけで、手戻りは目に見えて減る。
特に、ファイル整理、ディスク削減、文書作成みたいな用途では効き目が大きい。開発者でも非エンジニアでも同じだ。触らせる場所を狭めると、Claude Code は雑になりにくい。
たとえば、案件ごとにフォルダを分けているなら、その案件の中だけを見せればいい。
古い書類の整理をしたいなら、家全体ではなく「この年の請求書フォルダだけ」に絞る。
これをやらずに全体を渡すと、関係ないドラフトや一時ファイルまで拾ってしまい、出力がぼやける。実務ではそれがいちばんだるい。
Claude Code を使う前に、作業対象を言葉で固定するのが先だ。
「このフォルダの中だけ」「この案件の書面だけ」「この掃除対象の範囲だけ」とはっきり切る。曖昧にすると、AI はいい感じに広く見に行く。人間が見れば不要な範囲まで、平気で拾う。
たとえば文書整理なら、こういう頼み方が効く。
このフォルダ内のファイルだけを見て、重複している下書きと不要な一時ファイルを洗い出してください。
他のフォルダには触らないでください。
削除候補は一覧だけ出して、削除は私の確認後にしてください。
この言い方の肝は、作業範囲と操作範囲を分けている点だ。
「見る範囲」と「変更していい範囲」は同じではない。ここを分けないと事故る。
Claude Code は、プロジェクト内の情報を広く参照できると便利だが、そのぶん視界も広がる。広すぎる視界は雑さに直結する。人間の目でも、机の上が散らかると判断が鈍るのと同じだ。
実用上は、Claude Code を起動する場所を狭くするのが一番わかりやすい。
つまり、余計なものが入っている親フォルダではなく、目的のフォルダそのものを作業場所にする。案件単位、顧客単位、書類単位で分けておくと楽になる。
たとえばこんな構成だ。
work/
client-a/
draft/
contract/
notes/
client-b/
draft/
contract/
このとき、work/ で全部まとめて扱うより、client-a/ だけを対象にするほうが安全だ。
似た名前のファイルが別案件にあるだけで、うっかり混ぜる。そういう事故は本当に起きる。筆者も昔、同名の「final」を複数案件で扱っていて、確認のつもりが別フォルダの下書きをいじりかけたことがある。差分を見る前に気づいたが、あれは冷や汗ものだった。
ファイル整理やディスク削減でも同じだ。
「全部の写真」ではなく「2022年の不要キャッシュだけ」。
「全書類」ではなく「この案件の旧版だけ」。
範囲を切るだけで、判断の精度が上がる。
範囲を狭めるとき、意外と効くのが「何をしないか」を書くことだ。
Claude Code は、やってほしいことだけでなく、やるなもちゃんと伝えたほうがいい。
たとえばコード修正なら、こんな感じになる。
このリポジトリの src/components だけを確認してください。
他のディレクトリは参照しないでください。
変更はこのフォルダ内に限定してください。
テストの追加も、この範囲に関係するものだけにしてください。
文書作成ならこうだ。
この案件フォルダ内のメモだけを使って、報告書の下書きを作ってください。
別案件のメモ、過去のテンプレート、関係ない参考資料は使わないでください。
必要なら不足点を質問してください。
ここで大事なのは、Claude Code に「全部見ていい」と思わせないことだ。
AI は親切なので、関連しそうなものを拾いに行く。その親切が、時に巻き込み事故になる。だから先に門を閉める。
事故が起きるパターンはだいたい決まっている。
広いフォルダを開いたまま、名前の似たファイルを複数置いたまま、曖昧な指示で頼む。すると、余計な参照、余計な修正、余計な差分が出る。
Claude Code は万能なロボットではない。雑に渡した情報を、雑に広く扱うことがある。
それで「なんでここまで触った？」となる。人間側の設計ミスだ。
筆者が手戻りしたときも、原因は単純だった。作業フォルダを分けずに、古い草案と新しい草案を同じ場所に置いていたのだ。Claude Code が悪いというより、見せ方が悪かった。どれが現行か分からない状態は、AI にとっても地雷原だ。
だから、次のどれかは先にやっておくといい。
archive など分かる名前を付けるこのへんは地味だが、効き方は派手だ。事故の大半は、作業前の片付けで消える。
Claude Code を使うときは、「見てよいが、変えてはいけない場所」も決めるといい。
これをやると、調査や下書きは広めに、編集は狭めにできる。
たとえばこんな運用だ。
このフォルダ内の資料は読んでよいですが、編集してよいのは draft/ のみです。
final/ と archive/ は参照だけにしてください。
この切り分けがあると、誤編集の確率が落ちる。
特に、提出直前の文書や、保存版のファイルがある運用では効く。ひとつのフォルダに「作業中」と「完成版」を混ぜるのは、わざわざ事故を呼ぶやり方だ。
開発用途でも同じで、設定ファイルや生成物、実験用のコードが同居していると危ない。見ていい場所、変えていい場所、触るなを分ける。これが作業範囲の制御の基本になる。
細かい理屈より、まず運用で効かせるなら次の順で十分だ。
この5つだけで、巻き込み事故はかなり減る。
Claude Code は雑に広く使うほど危ないが、狭く切るほど頼れる。これはかなり単純な話だ。
もし迷ったら、こう考えればいい。
「全部見せる」より「必要なものだけ見せる」。
そのほうが、速いし、静かだし、あとで痛い目を見にくい。
そして、より大きな作業に広げたくなったら、そのときに範囲を一段ずつ広げればいい。最初から全部を触らせる必要はない。
Claude Code は、狭い作業場で使うほうがうまい。広い倉庫を一気に任せる発想は捨てたほうがいい。