Claude Code に「とりあえず全部見ておいて」は危ない。雑に広い場所で動かすと、余計なファイルまで巻き込み、指示も散る。まずやるべきは、作業フォルダの固定、つまり触らせる範囲を狭めることだ。
これを先に決めておくと、Claude Code は仕事しやすいし、こちらも安心して見ていられる。開発用のリポジトリだけを触らせたいときも、書類整理で特定の案件フォルダだけを見せたいときも、考え方は同じだ。対象を絞るほど、意図しない変更や探索の無駄が減る。
Claude Code は、いま開いているディレクトリを起点にして動かすのが基本だ。だから、最初に「ここだけ触ってよい」というフォルダを決めて、その中で起動するのがいちばん素直で強い。
たとえば、案件ごとにフォルダを分ける。書類整理なら、年度別や案件別のフォルダを分ける。大事なのは、Claude Code に見せる範囲を最初から小さく保つことだ。
cd ~/work/project-a
claude
この形にしておけば、少なくとも起点は project-a になる。逆に、ホームディレクトリや巨大な親フォルダで起動するのはやめたほうがいい。関係ないファイルまで候補に入りやすく、あとで「なんでそこを触った」という話になる。
非エンジニアなら、もっと単純に考えていい。たとえば「請求書整理用」「契約書下書き用」「会議メモ整形用」とフォルダを分け、その作業のたびに該当フォルダへ移動してから起動する。これだけで事故率がかなり下がる。
起動場所を決めても、依頼文が雑だと、Claude Code は周辺ファイルを広く読みに行こうとする。そこで、最初の指示に「このフォルダ内だけを対象にする」と書くのが効く。
たとえばこんな感じだ。
このフォルダ配下のファイルだけを対象にしてください。
他の場所には触れないでください。
まず構成を確認して、必要なら変更前に方針を短く出してください。
もう少し用途を絞るなら、こうなる。
この案件フォルダ内のPDFとテキストだけを見て、重複しているファイル名候補を整理してください。
外部のフォルダは参照しないでください。
ここで大事なのは、「何をしたいか」だけでなく、「どこまで触っていいか」を一緒に渡すことだ。Claude Code は手が速いぶん、範囲が曖昧だと余計な探索に吸い込まれる。結果として、読み取りコストが増え、差分も大きくなる。
筆者は最初、ここを甘く見ていた。大きめの作業フォルダで「不要ファイルを整理して」とだけ投げたら、関係薄いサブフォルダまで見にいかれて、確認が面倒になった。やること自体は合っていても、見てほしい場所がぼやけていると、人間の側のレビューがだるくなるのだ。
これは地味だが効く。作業対象が project-a なのに、~/work で Claude Code を起動すると、ほぼ確実に無駄が増える。似た名前の別案件が混ざるし、README や設定ファイルの候補も増える。探索の幅が広がるだけで、いいことは少ない。
フォルダ構成がこうだとする。
~/work/
project-a/
project-b/
archive/
このときは ~/work ではなく、必ず project-a に入ってから動かす。archive まで見えている状態は、整理作業では特にまずい。古いファイルに引っ張られて、意図しない提案が混ざることがあるからだ。
ディスク整理でも同じで、削除候補を探したいなら「このフォルダ内のキャッシュだけ」「この案件の添付だけ」と分けたほうが安全だ。広く見せれば賢くなる、という話ではない。雑に広い範囲は、むしろ雑にされる。
作業フォルダを決めたら、次は頼み方だ。ここをセットで固めると、手戻りが減る。
たとえばファイル整理なら、こういう依頼が扱いやすい。
このフォルダ配下の文書を見て、内容が重複しているもの、名前があいまいなもの、古い版らしいものを洗い出してください。
削除はまだしないで、候補を一覧にしてください。
文書作成なら、こうだ。
このフォルダ内の資料だけを使って、提案書の下書きを作ってください。
外部資料は参照しないでください。
必要な追加情報が足りない場合は、先に不足点を列挙してください。
コード作業なら、さらに素直にする。
このリポジトリの `src` 配下だけを中心に見て、ログ出力を整えてください。
変更前に影響範囲を短く説明してください。
「どこで」「何をして」「どこまでやらないか」を1セットにする。これでかなり安定する。曖昧なまま投げると、Claude Code は親切に広く見にいく。その親切が、今回は余計なお世話になる。
作業フォルダを固定する一番の効能は、ミスをゼロにすることではない。ミスが起きても、小さく済むことだ。
範囲が広いと、変更や参照の候補が増える。すると、確認すべき差分も増えるし、こちらの理解も追いつかなくなる。逆に、フォルダを絞っておけば、たとえ方向が少しずれても被害は局所化しやすい。
筆者は、整理対象のフォルダを広げすぎて、似た名前のファイル群を見分けるのに時間を取られたことがある。以後は「案件ごとにひとつの親フォルダ」「さらにその中で用途別の子フォルダ」という形に切り替えた。これだけで、Claude Code に渡す前の迷いがかなり減った。
厳密な正解はない。だが、あとで自分や他人に説明しやすい単位は、だいたい安全だ。
開発なら、1 リポジトリ単位が自然だ。案件文書なら、1 案件フォルダ単位が自然だ。写真整理なら、年別やイベント別が自然だろう。要は、「この範囲だけ見れば話が通る」と言える粒度にすることだ。
逆に、意味のない大箱は避ける。all, misc, temp のような何でも箱は、Claude Code だけでなく人間にも向かない。こういうフォルダは、だいたい触らせる前から負けている。
作業フォルダを先に決める習慣は、派手ではないが効く。Claude Code を賢くするというより、仕事の前提を整える作法だ。範囲を狭めるだけで、読み取りの無駄、差分の膨張、確認のだるさがまとめて減る。まずは一つのフォルダに閉じて動かすところから始めればいい。そこができると、次は「どのファイルを見せるか」「何を見せないか」まで、ずっと整理しやすくなる。