それ、いきなり本番の場所で試すから詰まるのだ。Claude Code は手早く頼めるぶん、雑に使うと変更が広がる。下書きと確定版を分離する、試作品を別場所に逃がす。たったこれだけで、あとから直すときの面倒さがかなり減る。
ここで言っている「分ける」は大げさな話ではない。たとえば、文章なら本番の原稿とは別に draft/ を作る。ファイル整理なら、いきなり元フォルダを触らず、まず sandbox/ や tmp/ に複製を置く。コードなら、既存ブランチや本番ディレクトリを汚す前に、作業用の場所を切る。Claude Code はその場で手を動かす道具なので、まず逃がし先を作るのが正解だ。
一番わかりやすい使い方は、Claude Code に「試作品はここで作って、確定したら本体に反映して」と最初に言い切ることだ。依頼文は、あいまいにするとすぐ散る。たとえば文書整理ならこうだ。
このフォルダは本番用です。直接は触らず、別の作業用フォルダに試作品を作ってください。
まずは下書きを `draft/` にまとめ、その内容を見てから確定版へ反映します。
本番のファイル名や配置は、最後に私が確認してから変えてください。
コードや設定ファイルなら、もう少し機械的に指示したほうがいい。
本番の変更はまだしないでください。
まず作業用のコピーを作り、その中で案をまとめてください。
差分が大きくなりすぎないように、変更点を小さく分けて提示してください。
私がOKしたものだけを本番に反映してください。
ファイル整理で効くのは、Claude Code に「削除」や「移動」をいきなりやらせないことだ。先に候補を出させる。たとえば重複ファイルの整理なら、こんな流れにする。
このフォルダ内で、まず候補だけ一覧化してください。
削除や移動はしないでください。
重複らしきものは `review/` に逃がす案と、残す案を分けて出してください。
私が選んだものだけを実行してください。
筆者は以前、これをサボって痛い目を見た。原稿の修正を本体でそのまま頼んだら、途中で方針を変えたくなって、直しが一気にだるくなったのだ。差分が混ざると、どこまでが試行でどこからが確定なのか分からなくなる。Claude Code 側も、会話の文脈に引っ張られて「前に出した案」を拾い続けるので、戻すのに余計な指示が増える。試作品を別場所に逃がしておけば、この混線が起きにくい。
分けるときのコツは、名前をケチらないことだ。draft、sandbox、review、wip みたいに、役割が一目でわかる名前にする。test1 や new はあとで意味が消える。フォルダ名に気合いを入れる必要はないが、用途だけははっきりさせるべきだ。あとで自分が見ても迷わない名前がいい。
もうひとつ大事なのは、試作品を置く場所を本番と同じ階層にすることだ。完全に離れた場所にすると、あとで参照しづらい。逆に同じ作業ツリーの中にあると、Claude Code にも人間にも見通しがよくなる。たとえばこういう構成だ。
project/
final/
draft/
review/
draft/ で試し、review/ で確認し、final/ にだけ反映する。これだけで、手戻りのときに「どれを残して、どれを捨てるか」が明確になる。
ただし、分ければ何でも安全になるわけではない。試作品を放置すると、逆にゴミが増える。筆者は一度、draft/ を作って安心し、そのまま古い案を大量に残したことがある。結果、後で見ると候補が多すぎて余計に迷った。だから、試作品は「避難先」であって「倉庫」ではない。要るものだけ残し、残りは消す。ここを甘くすると、本番より散らかる。
Claude Code に頼むときは、最後に「確認ポイント」を入れておくといい。たとえば文章なら、見出し構成・文体・重複表現。ファイル整理なら、移動先・削除候補・残す理由。設定変更なら、どのファイルを触ったか。これを先に出させると、試作品から本番へ移す判断がしやすい。
試作品を作ったら、次の3点を先に一覧で出してください。
1. 何を変えたか
2. 本番に反映すべきか
3. 反映するとしたらどの順番か
その後で、私の承認があるものだけ本番側へ移してください。
この分け方は、エンジニアだけの話ではない。契約書のたたき台、提案書、会議メモ、写真やPDFの整理でも同じだ。本番を触る前に試作品を逃がす。たったそれだけで、気軽に試して、気楽に捨てられる。Claude Code を使うなら、まずこの逃がし先を作るところから始めるのがいちばん実務的だ。