その場でいきなり本番ファイルを触るから、あとで余計な手戻りが出る。Claude Code を使うときは、下書き、確定版、ドラフトをちゃんと分けたほうがいい。ここを雑にすると、内容も差分も散らかるし、何を直したのか追いにくくなる。
たとえば文書作成でも、ファイル整理でも同じだ。最初の試し書きは別の場所で済ませて、固まってから本番に反映する。Claude Code は会話の流れを保ったまま編集できるので、思いつきの修正までそのまま本番へ流し込みやすい。便利だが、便利すぎるせいで事故る。
筆者も最初は、既存の原稿を開いたまま「ちょっとだけ整えて」と頼んで、気づいたら段落の順番までいじられていた。人間なら「ここはまだ仮」とわかるところでも、曖昧な指示だとそのまま確定扱いになる。下書きと確定版を分けるだけで、この事故はかなり減る。
やり方は難しくない。まず、作業用の場所を決める。たとえば案件ごとのフォルダを切って、そこに試し書き用のファイルを置く。完成したら、確定版だけを本番の場所にコピーする。Claude Code に頼むときも、最初から「このファイルはドラフト」「最後に確定版へ反映」と言い切ると安定する。
mkdir -p ~/work/project-a/draft
mkdir -p ~/work/project-a/final
Claude Code への頼み方も、最初はドラフト前提に寄せる。
この文章は下書きとして扱ってください。
~/work/project-a/draft/outline.md にあるメモをもとに、
まずは読みやすいドラフトを作ってください。
本番のファイルは直接書き換えず、修正案を別ファイルに出してください。
ファイル整理なら、こういう言い方が効く。
このフォルダ内で重複しそうなファイル名を整理したいです。
まずは候補を一覧にして、削除や移動はまだしないでください。
確定した案だけを最後に実行してください。
この「先に案、あとで実行」が大事だ。Claude Code は説明と実作業をつなげて頼めるが、だからこそ途中の確認地点を作らないと危ない。試し書きの段階で本番を書き換えると、あとから「どこまでが思考で、どこからが確定か」が曖昧になる。人間の目でも追いづらいし、差分も読みにくい。
特に文書作成では、下書きをそのまま確定版に流し込まないほうがいい。ドラフトには、言い換え候補や構成メモ、迷っている表現が残る。そこを消さずに本番へ入れると、読み手にとってノイズになる。逆に、試し書きの場所で思い切り散らかしておけば、本番はすっきり締まる。これは地味だが効く。
筆者がやって痛かったのは、1つのファイルで下書きと完成文を往復したことだ。Claude Code に「ここだけ直して」と頼んでも、周辺の段落をまとめて整えたくなることがある。結果、意図しない言い換えまで混ざる。別ファイルに分けておけば、そういう余計な揺れを隔離できる。
実務では、こういう運用がいちばん扱いやすい。
1. draft/ に試し書きを作る
2. 内容が固まるまで draft/ だけを編集する
3. final/ には確定した版だけを置く
4. final/ に移す前に、見出し、固有名詞、日付、数字だけ目視確認する
ここで大事なのは、下書きを恥ずかしがらないことだ。雑に見えるくらいでちょうどいい。下書きは読み物ではなく、検討の場である。検討の場に完成品の顔をさせると、修正しづらくなる。人間もAIも、完成品らしい見た目に引っ張られるからだ。
非エンジニアの作業でも同じだ。たとえば契約書のたたき台、議事録の整形、問い合わせ文の素案、PDF化する前の案内文。どれも、いきなり確定版に触らせるより、まず別場所で試し書きしたほうが安心だ。案件フォルダの中に draft と final を分けるだけで、管理の感覚がかなり変わる。
少し進めるなら、Claude Code に「出力先を固定する」癖をつけるといい。毎回、どのファイルが下書きで、どれが確定版かを明示する。名前も雑にしない。notes.md だけだと曖昧だが、draft-notes.md と final-notes.md に分ければ迷いにくい。ディレクトリ名でも同じで、draft/ と final/ はかなり使いやすい。
最後にひとつ。試し書きを別場所で済ませる運用は、Claude Code の性能を引き出すためというより、自分の手戻りを減らすための仕組みだ。AI に任せる量が増えるほど、境界線をはっきりさせたほうがいい。下書きは散らかしていい。確定版は静かに締める。この分離だけで、作業はだいぶ楽になる。