本流のフォルダにそのまま試作を混ぜると、だいたいろくなことにならない。差分は膨らむし、どこまでが本番でどこからが試行錯誤かも見えなくなる。Claude Code を使うなら、最初に「別作業場所を切る」「作業ディレクトリを分ける」「サンドボックスで試す」を先にやるだけで、後の会話がかなり静かになる。
この静かになる、というのは大げさな言い方ではない。Claude Code は、いま置かれているディレクトリの中身を前提に動く。だから、本番の文書やファイルの山の中でいきなり試させると、読ませたくないものまで文脈に入る。逆に、試作用の小さい作業場所を切ってしまえば、指示も差分も小さくなる。手戻りが減る。何より、あとで消していい場所として割り切れるのが強い。
たとえば、弁護士が案件ごとに書面を作る、経理担当が月次のファイル整理をする、非エンジニアが散らかった文書をClaude Codeに整えさせる。こういう場面では、元のフォルダで直接いじらせるより、まずコピーを置いた別ディレクトリで試したほうが安全だ。本番の資料が壊れる心配がないし、出力の確認もしやすい。
やり方は単純だ。試作専用の場所を作って、そこに必要なファイルだけ入れる。CLIを使うなら、まず作業用フォルダを作る。
mkdir -p ~/work/claude-playground
cd ~/work/claude-playground
本番のフォルダから、必要なものだけコピーする。丸ごとコピーでもいいが、不要な巨大ファイルまで持ち込むと意味が薄れる。書類整理なら、対象のPDFやテキストだけを入れる。開発なら、触る予定のファイルだけを置く。ディスクを節約したいなら、コピー先を最小限にするのが筋だ。
cp /path/to/original/report.md ~/work/claude-playground/
cp /path/to/original/notes.txt ~/work/claude-playground/
Claude Code には、その作業場所でやりたいことをはっきり伝える。曖昧な指示だと、別のファイルまで気にしてしまうからだ。依頼文は短くていいが、前提は外さない。
このディレクトリ内の report.md を読み、内容を重複なく整理してください。
元のファイルは変更しないでください。
必要なら新しい案を report_draft.md に出してください。
もう少し実務寄りに書くなら、こうなる。
このフォルダを試作用の作業場所として扱ってください。
既存ファイルを直接上書きせず、修正版は別ファイルに出してください。
本番へ反映する前提ではなく、まず差分が見やすい形に整えてください。
ここで大事なのは、「何を触ってよくて、何を触ってはいけないか」を先に決めることだ。Claude Code に限らず、作業場所が曖昧だと、出力も曖昧になる。特に、文書の修正やファイル整理では、元ファイルを直接編集させると後で戻しづらい。筆者は最初、雑に本番フォルダを開いたまま依頼して、関係ないメモまで巻き込んで差分を増やしたことがある。内容は悪くないのに、どこが試作でどこが確定版か分からなくなって、確認の手間だけが増えた。あれはかなりだるい。
別ディレクトリに逃がす利点は、見た目より実務的だ。まず、Claude Code に見せる情報量が減る。次に、生成したファイルをまとめて捨てやすい。さらに、試作の途中で方針を変えても痛くない。ここが本流でやるのと決定的に違う。失敗しても、元の資料は汚れない。
ただし、雑に分ければいいわけでもない。よくある失敗は、コピーしたはいいが、本番と同じ名前のファイルを何度も増やして自分で迷子になるパターンだ。draft、tmp、work など、役割が分かる名前を付けておくとよい。日付を付けるのも効く。
mkdir -p ~/work/2026-09-06-report-draft
もう一つの落とし穴は、試作場所を作ったのに、元のフォルダをClaude Code に見せたままにすることだ。これでは作業場所を分けた意味が薄い。シンボリックリンクや広すぎる親ディレクトリを渡すと、結局コンテキストが散る。試作は小さく閉じる。これがコツだ。
ファイル整理でも同じだ。たとえば、重複ファイルの候補を洗い出したい、PDFの名前を整えたい、不要なキャッシュを見たい、こういう作業は本番のフォルダで直接やらせるより、コピーした検証用フォルダで試すほうがいい。先に小さく試して、問題がなければ本番へ戻す。順番を逆にすると、削除や移動の事故が起きる。人間の手でもAIの手でも、そこは変わらない。
実際の依頼文は、こんな具合で十分だ。
この作業用フォルダ内だけを対象に、ファイル名の揺れを整理してください。
本番のファイルは触らず、変更案を別ファイルに出してください。
削除はしないで、候補の一覧だけ作ってください。
あるいは、文書作成ならこうだ。
このディレクトリは試作用です。
本文の構成だけ整えて、確定版は作らず、差し替え候補を別ファイルで出してください。
不要な重複表現を減らし、読みやすさを優先してください。
この「別ファイルに出す」という逃がし方は、かなり使える。Claude Code に直接上書きさせないだけで、確認のハードルが下がるからだ。差分を見る側も楽になる。非エンジニアなら、まずは「元の書類は残したまま、下書きだけ別名で作る」と覚えておけばいい。技術者なら、変更前後の差が追いやすい。どちらにも効く。
最後に、少しだけ進めるなら、試作ディレクトリを「毎回捨てる前提」にしてしまうことだ。終わったら消す。残すのは採用した成果物だけ。これを徹底すると、作業場所にゴミが溜まらない。Claude Code の会話も、その都度クリアになる。長い案件ほど、この差は大きい。
本流を静かに保ちたいなら、最初に作業場所を分ける。試作は別ディレクトリに逃がす。たったそれだけで、指示は短くなり、差分は小さくなり、戻し作業も楽になる。実務では、この地味な一手がいちばん効く。